心理的安全性の育て方.pdf - Speaker DeckReactJS: Keep Simple. Everything can be a component!
開発の見積もりとスケジュール管理 - クックパッド開発者ブログ
こんにちは。会員事業部の丸山です。 エンジニアが開発を開始する時にはタスクの見積もりとスケジュールを作成行って、実装を進めていくと思います。 しかし1ヶ月を超えるような規模の開発をする場合、なかなか予定通りの期日に終わらなかったりすると思います。 そして大抵の場合、増える方向になりますよね。 今回はそういうことにならないために、私が気をつけていること・実践していることをいくつか紹介したいと思います。 見積もりとは まずは「見積もり」とは何なのかを正しく理解したいと思います。 一般的には「見積もり」＝「全タスクとその工数を洗い出す」というものだと思います。 しかしここで以下のことに気をつける必要があります。 見積もりとスケジュールとコミットメントは違う 見積もりとはあるタスクがどれだけの工数(規模)なのかを算出することです。 対して、スケジュールとはあるタスクがどれだけの工期(期間)なのかを
プロジェクトを成功させるために最初におこなっていること - $shibayu36->blog;
ディレクター時代に仕事でプロジェクトを受け持つ時にどうやったら成功させることが出来るのかについていろいろ考えていた。僕は開発フローをいろいろ考えるのが好きなのだけど、実際に自分がリーダーシップを取ってプロジェクトを進めることを経験すると、そもそもその前に考える・決めるべきことがたくさんあるということが分かったので、ブログに書いておこうと思う。 ここで言うプロジェクトとはサービスを一から作ったり、サービスの一機能を作ったり、受託案件一つだったりを指す。特に開発プロジェクトに限定するものでもない。 プロジェクトを成功に近づけるためには、まずプロジェクトの開始時に、プロジェクトの5W1Hを明確にし、個々のメンバーの責任範囲を決め、それらを一つの場所にまとめておくということをしておくと良いと考えている。 5W1Hを決める すごい基本的なことだけど、プロジェクトをやる上でやはり5W1Hは大事である。
「素人まがいのシステム開発」を見分ける方法
自分のプロダクトだっていう意識が皆無なのかテストしないやつ多いよね 最近転職したんだけど、テストしてもリリース後にバグが見つかるからテストは意味がないとかぬかすし 新卒から数年のクソガキが、なぜかプログラマを単純作業労働者かと何か勘違いして下に見ているし テストをしないプランナーとかディレクター プログラマーが単純労働者だったとしてもテストは必要。 単純労働ってことは、工業製品なんですよ。で、工業製品はテストと称する品質チェックをしてますけどね。 素人まがいなところで、単純労働者扱いされて働くのは、正直メンタル的にかなりつらいと思う。マトモなプログラマーほどそう。 給料がそこそこあっても、そういうところで働くは、ストレスがたまると思う。 一度もプロ的な仕事をしたことがない人たちは、そういうのは全然気にならないから、平気。 ということで、素人まがいの人たちが、量産されていく。 素人まがいな開
なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;
最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイク コーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良い本だった。この本を読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと
KAIZEN platformが伊藤直也氏とやってきた、開発現場の暗黙知をなくすチーム運営術【連載:エンジニアの幸せな職場】 - エンジニアtype | 転職type
2014.03.24 働き方 エンジニアにとって、本当に「働きやすい環境」ってどんなのだろう？ という疑問を解消すべく、組織づくりや職場環境に秀でたTech企業にインタビューを敢行するこの企画。インタビュアーは、エンジニアのためのポートフォリオサイト『Forkwell』や、エンジニア目線の求人・転職サイト『Forkwell Jobs』を運営する株式会社garbs取締役おおかゆかさん。エンジニアが「幸せに働ける職場」のあり方を探る！ 株式会社garbs 取締役 Forkwellプロダクトマネージャー おおか ゆかさん 関西学院大学経済学部を卒業後、独立系SIerを経てインフォシーク社に入社。楽天による買収後も含めて、インフォシークのログイン周辺機能や各種コミュニティサービスの開発を担当。その後フリーランスとして活動、業務委託で入ったgarbsで提案したエンジニアのスキルマッチングの企画が採用
開発をうまく回したいなと思って僕が意識している40くらいのこと - Mitsuyuki.Shiiba
自分がこの1年間開発チームを引っ張ってきた中でこういうところに気をつけてたよってこと。 ザーッと勢いで書いてみる。分類はある程度なもんです。組織パターンやFearlessChangeは好きです。 心構え 1 現状を受け入れる 環境に文句を言ってても、何も変わんないし。自分は本当はもっとできるはずなんだ、って言ってても、実際アウトプットはでてないんやろ。なるほど、今はこうなんだってことを受け止めて、じゃあそこからどう改善していけるだろう？と考えたい。 2 遷移状態を受け入れる 現状から、理想的な状態にぴょんって飛び移れるわけじゃないんだから、その途中って泥臭かったりごちゃごちゃしてたりするんだけど、それを受け入れる。練習せずにいきなりスポーツがうまくなるわけないのと同じで。 3 正しいことが選ばれるわけじゃない 政治や感情や時期や思惑や抵抗や。そういうのがあるので「正しいこと」が常に選ばれる
技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita
システムには障害がつきものです。どんなにしっかりと作られたサービスであっても思わぬところで、バグやミスが発覚して、トラブルになるものです。大事なのはこういった障害を次への糧にしていくこと。失敗というのは大事な資産なので、管理できるようにしましょうという話。 あわせて読みたい あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ メンタリングの方法について基礎をまとめました。内心でなく行動を変えることが障害報告とも共通します。 新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック 半年で40kg痩せた！ダイエットでわかるリーンなプロジェクトマネジメント手法 心理的安全性ガイドライン（あるいは権威勾配に関する一考察） 障害の種類と障害報告について 障害には、小さなもの、たとえば画面に表示されているテキストの乱れから、すべての画面で50xエラーが発生
高速にドッグフードを食べるエンジニアと一緒にデザイナーが仕事する方法 - Hatena Design Group
photo by wiccked こんにちは。はてな デザインチームの id:ueday です。 先日、はてなでは品川の日本マイクロソフトで「はてな エンジニアブロガー祭り」を開催しました。 そこで発表された、はてな アプリケーションエンジニアの id:hitode909 による 「高速にドッグフードを食べる方法」 のスライドが SpeakerDeck に公開されています。もうご覧になりましたか？ 高速にドッグフードを食べる方法 - Speaker Deck 高速にドッグフードを食べる方法 - hitode909の日記 はてなブログチームでは高速にドッグフードを食べながら開発していますが、この記事では 「エンジニアと一緒に高速にドッグフードを食べるデザイナー」 という視点から、はてなブログ開発の様子をご紹介します。 高速にドッグフードを食べるメリット 「ドッグフードを食べる」とは、実際にド
3年前の僕へ
DevLOVE現場甲子園2013にて、３年前の課題とそれに対する現在の気付きについて発表しました。Read less
あるソシャゲ会社のプロジェクトのひっくり返り方。 島国大和のド畜生
伝聞。 あるソシャゲ会社のプロジェクトのひっくり返り方。 １年目 新卒に運営の手伝いをさせる。 ２年目 運営を切り盛りさせる。 ３年目 開発の頭をやらせる。 （実際にはそれぞれ６ヶ月ぐらいと思われる） そりゃひっくり返るわ。 何一つ開発で学んでないじゃんか。なぜ開発ができると思うんだ。 運営業務はウィークリーでデイリーなので、関わってると運営に関しては結構いいスピードで詳しくなるが。 開発は少なくとも数ヶ月かかるので。詳しくなるには何本かの完成に付き合う必要があり数年を要する。 絵でも漫画でもゲームでも。１本仕上げる度に能力がつく。 １本まるっと面倒見ないと、それを作る間にどういうコストとリスクがあるのかを肌で理解できない。 どういうトラブルが発生し、それをどう解決したかの蓄積がたまらない。 そもそも今あるトラブルがどれぐらいのトラブルなのかも見当がつかない。 イベント１コつくるのとゲーム
くもりのち晴れ、ときどき、コストセンター - たごもりすメモ
直接成果が外に出ない僕らの仕事は大抵、最初は空模様が怪しい。いまいち見通しが悪くテンションも上がらない曇り空が続いたあと、努力が報われれば、ありがたくもそのうちに晴れ間が見えるようになる。たまにとんでもない快晴にめぐりあえることもある。 でも途中で目的地を見失ったり、脚が萎えてその場にくずれおちたりすると、天候はあっという間に変わる。動けないうちに嵐がやってくる。 その嵐には僕の中では、コストセンターというラベルが貼ってある。 http://www.picgifs.com/wallpapers/storm/wallpaper_storm_animaatjes-9-970507/ あまり好きな表現ではないが、コストセンターという言葉がある。この言葉の定義自体いろいろあるらしいというか、明確には定義があるようだというのはこのあたりを読むとふむふむという感じ。 だが、おそらく多くの人の頭には「コ
クソゲーを作る組織とそうでない組織 2012 05-12
1. クソゲーを作る組織と そうでない組織 株式会社 Aiming ジェネラルマネージャ / テクニカルディレクター 2012年5月12日 於 ゲームを作る勉強会 小林 俊仁 ( @toshi_k ) 2. About: 小林 俊仁 http://about.me/toshi_k オンラインゲームを作って早10年 基本はゲームも分かる web っ子 @toshi_k Community Engine でオンラインゲーム作って (2001~2003)、中国で子会社作っ てモバゲータウンの中国版（加加城）とか Play Online China とか作って (2003~2007)、子会社を閉じて日本に帰ってきて、その後オンゲの技術ディレク ターとかプロマネとかやってた 最近は、 ONE-UP → Aiming で組織横断的に開発プロセスの改善とかスクラム マスターとか
ウェブの「受託開発」が面白くないという8つの誤解 - Zerobase Journal
ぼく自身は多くのベンチャー企業とかよりよっぽど面白い仕事を「受託開発」でやってきているので（あ、もちろん「面白い」というのは主観的な問題だとお断りしておきますが）、ウェブ業界にはびこる「受託開発はダサい」という思想に強い反発を持ってきました。今日はそいつらをバッサリ斬ることにします。 ぼく自身は多くのダメなベンチャー企業とかよりよっぽど面白い仕事を「受託開発」でやってきているので（あ、もちろん「面白い」というのは主観的な問題だとお断りしておきますが）、ウェブ業界にはびこる「受託開発はダサい」という思想に強い反発を持ってきました。 今日はそいつらをバッサリ斬ることにします。 これまでに見聞きしてきた「受託開発が面白くない理由」を一つずつ取り上げて検証します。 × 受託開発なんて所詮「自分の事業」じゃないから自社事業がやりたい。 ○ 「受託開発」でも「自分の事業」としてコミットすることができる
受託開発脳から自社開発脳へ切り替えの7つの壁 - ヴェルク - IT起業の記録
これ、思ったより大変でした。 自分含め、うちにいるメンバー全員、 これまでの経歴では受託開発をメインにやっていたため、 自社サービス開発の経験はかなり少なかったです。 でも、ヴェルクでは、受託開発をしつつ、 時間を作って色々と作っていこう、というスタンスのため、 起業直後から色々と企画を考えていました。 でも、受託開発脳から自社開発脳への切り替えは思った以上に苦労しました。 要件定義等でお客さんと一緒に要件を考えたりしますが、 最終的に「やりたい事」を持っているのはお客さんになります。 要件定義の前の企画やグランドデザインと言った分野は お客さんの戦略に沿ったものになります。 だから、最終的には、誰かが答えを持っている事が殆どです。 そのため、ゼロからそれを考える事があまりないんですよね。 いざ、ゼロから自分たちで企画を考えようと思った時、 いろいろと壁がありました。 1. 本当の意味での
「どうしましたか？」「お腹が痛いんですけど…」「もっと詳しくおしえてください」「えっ、お腹が痛いだけですけど」「それでは診断できません」 - uzullaがブログ
医者「今日はどうしましたか？」 患者「今は落ち着いてるんですが、最近どうも腹痛がひどくて…」 医者「もうちょっと具体的に言ってください」 患者「そうですね、なんとなくシクシクと…」 医者「なんとなくとかいわれても困りますね、もっと具体的に現象を教えてください」 患者「えっ」 医者「たとえば、脇腹に針をさしたようにいたい、とか。みぞおちに重い鈍痛があるとか、具体的に」 患者「ううん、そうですね…みぞおちが痛かったかも…」 医者「かも！？」 患者「みぞおちがいたいです！刺すように！」 医者「みぞおちがいたい、刺すように、なるほど（カリカリ」 患者「どうなんでしょう…胃炎とか…」 医者「素人が症状を断定しないでください」 患者「すみません…」 医者「今の症状はわかりましたから、どこで、いつ、どうやったら腹痛になったか、状況を詳しく、順番に教えてください。まず痛くなったのは何時何分何秒で、その何分
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
"OSSにコントリビュート" なんてしてる場合じゃない！
ふつうの受託開発チームのつくりかた
IDEA * IDEA
