いいえ、それより少ない労力で済みます
(smartguess.is)- 開発チームの外から、新たな事実もないまま見積もりを下げるよう圧力がかかると、見積もりが交渉対象のように扱われ、信頼とアジャイル計画の質がともに悪化する
- 実際の作業量の大半は開発チームが自由に減らせるものではなく、チームはチームベロシティ、完了済みストーリーのデータ、現在のスループットを根拠に想定される労力を算定する
- 低い見積もりに合わせようとしてプロセスを飛ばしたり品質を下げたりすると、当面はスケジュールが短く見えるかもしれないが、その後より大きなコストとして返ってくる可能性が高い
- より生産的な対話は「もっと低く見積もれ」ではなく、予算、時間のかかる部分、大きな未知要素、代替案、ストーリー分割と早期検証を一緒に見ること
- 固定された機能範囲のまま数字だけを下げると、顧客に対して提供時期について誤った期待を生み出すため、労力が大きく価値の低い機能を外す議論が必要になる
新たな事実のない見積もり圧力が生む歪み
- 開発チーム外のステークホルダーが、技術的知識やコードベースへの理解が限られた状態で「いいえ、それより少ない労力で済みます」と言って見積もりを下げようとする状況はよく起こる
- 表向きは「より良い見積もり」を求めているが、実際にはより低い見積もりを望んでいる場合が多い
- 見積もりを交渉可能な数字として扱うと、ステークホルダーと開発チームの双方が不満を抱く合意に至り、ビジネス側は顧客にいつソフトウェアを提供できるかについて悪い期待値を持つことになる
- 関連する引用元として Is tasking developers with creating detailed estimates a waste of money? がリンクされている
見積もりは統制ではなく予測に近い
- 見積もりに異議を唱えられる場合はある
- 開発チーム内でストーリーを議論するとき
- 実際の作業量に影響する新たな事実があるとき
- 実装の詳細を理解していなかったり、新しい情報を提供していなかったりする外部ステークホルダーが低い見積もりを求めるのは、気象学者に「明日の予報は間違っていて、もっと良くなるはずだ」と言うのに似ている
- 気象学者は天気を制御するのではなく、知識と観測データに基づいて予報する
- 開発チームも実際の作業量をほとんど制御できず、知識とデータに基づいて想定労力を算定する
開発チームが制御できること、できないこと
- 開発チームは、確立されたチームベロシティ、完了済みストーリーのレビュー データ、スプリントごとに改善されるプロセスを使って見積もる
- 作業量を減らすために一部のプロセスを省略し、低品質のソフトウェアを提供することはできる
- 推奨される方法ではない
- 後でより大きなコストを支払うことが多い
- チームにベロシティを改善する余地はあるが、見積もり時点では期待される将来のスループットではなく、現在のスループットを基準にすべき
- 「もっと長く働けばよい」という類いの会話が社内で出てくるなら、そのような環境は災難を招く処方箋に近い
数字を削る代わりにすべき対話
- ソフトウェア開発は複雑で、人々が考えるより長くかかることが多い
- ステークホルダーが特定の金額までしか使えないと見ている状況なら、見積もりを下げる代わりに次を議論すべき
- このストーリーにいくら使えるのか
- ストーリーのうち、どの部分が最も時間を使うのか
- 最大の未知要素はどこにあるのか
- 時間のかかる部分と未知要素に対処する代替案は何か
- 検証と提供の方法を変える選択肢もあわせて検討すべき
- ストーリーを分割して複数の部分として提供する
- 各部分をできるだけ早く検証する
- 可能ならプロトタイプで検証する
- 特に多くの労力が必要だが価値が最も低い機能は、ストーリーから除外する方法を探すべき
スケジュールに関する質問をより有用に変える
- 見積もりを下げる質問よりも、機能とスケジュール・範囲の関係を明確にする質問のほうが生産的
- 別の記事で扱う質問として、次がリンクされている
- Feature A はいつ提供できるのか
- 次の四半期末までに何を提供できるのか
- Feature A を次の四半期末までに提供できるのか
- リンクされた記事: converting story points to hours
2件のコメント
記事の元タイトルをDeepLで翻訳するとこうなります:
「いや、それより手間はかからない！」と言う人はいますか？
Hacker News のコメント
「営業担当者に販売量／ノルマを増やせと圧力をかけるのは、気象学者に日差しを要求するようなものだ」という比喩は、この文脈ではそれほど不当には見えない
実際には、同じ仕事をより早く終わらせるためにより効果的に働けと求めているのに近い
営業担当者にノルマを自分で決めさせると、契約成立には複雑さや未知数が多いため、失敗して見えないように無難に達成できる数字を選ぶだろう
しかしその数字は事業が必要とする水準より低いかもしれず、だからより高いノルマを提示し、少し無理をしてでも達成させるのだ
特に報酬がその数字の達成と直接結びついているなら、なおさら重要だ
とはいえ営業担当者たちは、「自分で設定したノルマは神聖で、営業担当者だけが決めるべきであり、それを上回る成果を求める経営陣は無知だ」という記事を書き続けたりはしない
営業チームがある特定の案件について「成立確率70%、年間経常収益は約500万ドル」と言ったとき、経営陣が「それを80%と700万ドルにできるか？」と返すほうが、より近い比喩だ
成立確率を上げながら価格も上げることは可能かもしれないが、機能を半分の時間で終わらせるのと同じく、どこかで大きな変更や譲歩が必要になる
ただし見積もりを希望目標に変えるより、見積もりより早く終わらせることのほうがはるかによい
最善なのは、優先順位と前提条件を反映して作業を並べ、開発に着手できるストーリーを十分に確保し、急ぐときは長期的にチームの能力が偏るコストを引き受けて、戦略的にチケットを割り当てることだ
時間的なプレッシャーがあるなら、すべての機能から「あればよいもの」を取り除くかバックログの下のほうへ下げ、他チームや外部専門家への相談には厳格な時間制限を設けるべきだ
不要な会議や妨害をなくし、開発者が会議を断ったりカレンダーをブロックしたりできるようにし、リファクタリングの基準は締め切り前の費用対効果が明確な場合に引き上げることで、未来から借りてくるように進めるべきだ
ただし、こうしたやり方を標準的な作業方法にしないよう、非常に注意する必要がある
リードの10%をコンバージョンできるなら、4件ではなく5件のコンバージョンが必要なときは、おおよそ10人多く電話すればよい、という具合だ
ソフトウェアとよりよく比較できるのは、経験もなく、直面する問題もよく分からない状態で、新しいタイプの建物、たとえばジオデシック・ドーム住宅を建てることだ
しかも正確な見積もりを求められ、その次にはさらに削るよう圧力をかけられる状況に近い
最も重要なのは顧客を欺く行動であり、単に「会社にとって都合のよい普通の誇張」を言っているのではない
会社が守れない約束をしたり、品質と持続可能性を犠牲にするデスマーチを要求する将来機能を売ったりするようなことだ
Cレベルがそれを見ていなくても、結果は生じる
だからといって開発者の見積もりを無条件に信じるべきだという意味ではないが、それはもっと大きな沼なので、今掘り下げるには疲れる
単にスケジュールへの理解がより非現実的になるだけだ
同じ問題を解く別の創造的な解決策を探したり、目標に合わせるために削れる範囲を理解したりすることは十分に可能だ
しかし「まったく同じことをただもっと早くやれ」というのとは、まったく違う
見積もりの話になると、開発者はビジネス側の立場にほとんど立たず、なぜ見積もりが必要なのか、なぜ短いほうが長いほうより常によいのかを理解しようとしないことが多い。
その代わりに、ソフトウェア開発という聖域を守ろうとして、エンジニアと「それ以外の人たち」の違いをさらに大きくする。
そのとき皮肉や当てこすりが表に出て、結局は非現実的な見積もりにつながる。
開発者、PO、マネージャー、ディレクター、CTOまで経験してきたが、ほとんどの開発者が価値提供と時間という現実からあまりに離れていることには、今でも驚かされる。
開発者として、どのくらいかかるのかを尋ねてもらい、説明し、反論し、見積もりを擁護する機会を得られるのは、むしろ幸運なことだ。
悲しい現実として、開発者はビジネスレベルの会話に参加し、PMやマネージャーが作業の複雑さを見て健全な費用対効果の議論ができるように、考え、アイデア、懸念、提案を表現するのが不得手なことが多い。
リード開発者がビジネス会議に参加しているか、開発チームが数字や予算を見てロードマップに一緒に関わり、ユーザー調査や機能のブレインストーミングをビジネス／UXの人たちとともに行っているかを見る必要がある。
そうでなければ、開発者がビジネスを理解すると期待するのは難しい。
開発／ビジネスの分断は、それぞれがサイロにいながら、別の専門家が自分の問題をよく分かってくれることを期待させ、ソフトウェア開発の聖域化を生む。
多くの会社は、極端にサイロ化された役割にもかかわらず何とか回っているだけなのに、お金が入り続けているため、そのやり方で問題ないと勘違いしているように見える。
たいていは、誰かが社内政治用のPowerPointに数字を入れたがっているだけだ。
ときにはAをやるかBをやるかを決めようとしていることもあり、その場合に正当に必要なのは絶対的な見積もりではなく、相対的な見積もりだけだ。
まれに本当の締め切りがあるが、そのときに必要なのも見積もりではなく、「この日付に間に合わせられるか」あるいは、より有用には「その日付に間に合わせるには何をすべきか」だ。
ビジネスにできるだけ近いところで働くのはよいことだし、そもそもソフトウェアを使う理由も普通はビジネス上の必要を解決するためだ。
しかし見積もりに関しては、本当に彼らが間違っていて、こちらが正しいことが多い。
短いほうが常によいのなら、これからすべての見積もりは1日だと言えばいいが、それでよりよくなるのか？
開発者がコードを書き、見積もり、ビジネスのスケジュールに合わせて納品できるなら、その人は従業員ではなく創業者だ。
求められているのは、創業者のように納品するが、利益の持分は受け取らないお人よしだ。
あなたや私がどれだけ努力しても、赤ちゃんが早く生まれてくることはない。
曖昧な点はない。
不満は、開発者が完了時期を知っているかのように尋ねる言い方にある。
誰かが価値を素早く届ける能力は、所要時間を見積もる能力とは別物だ。
見積もりを完全に外しても、大きな価値を届けることはできる。
ソフトウェア作業時間を見積もる方法が実際にあるのなら、企業はプロダクトチームを置くように専門の見積もり担当者を雇っていたはずだ。
開発者にやらせる理由はない。
もちろん他の人にもできず、開発者は少なくとも下限は当てるので、彼らにしつこく求め続けているわけだが、そのプロセス自体は明らかに愚かだ。
ある仕事にどれくらいかかるかを知るには、その仕事を行うすべてのステップを列挙しなければならないが、ソフトウェア開発ではそれが不可能だ。
開発者は与えられた要件に対する下限を出すことはでき、予想外のことがまったくなければ正確な見積もりも可能かもしれないが、95〜98%のプロジェクトでは見積もりは実際より短く出る。
結局「開発者の見積もり」は、そのプロジェクトに開発者がどれだけバッファを入れたいかの尺度になる。
見積もりを求めることは、会話のフレーミングを完全に誤っている。
本当の質問は、今ビジネスが抱えている問題、6か月後に起こる可能性のある問題、そしてその問題を解く費用対効果について、開発者の意見を求めるものであるべきだ。
そのうえで、リスクを減らす方向で定性的な意思決定をすべきだ。
ソフトウェア見積もりの最良の結果は、全員が無視して忘れることであり、それ以外の結果はビジネス価値を破壊する。
要点は理解できるし、無責任な当事者がいる組織では実際のリスクも大きい。
ただし、気象学者のたとえはあまりよくない。
気象学者は天気を予測することが本業だが、一般的な開発者はその天気の中で作業する人であり、正確に予測した経験は相対的に少ない。
ステークホルダーとして苛立つのは、作業時間から始まりもせず、現実的な期間で終わりもしない、とんでもない見積もりだ。
特にマイクロタスクのレベルではなおさらで、アクセス権さえあれば自分で直接もっと早くできる、せいぜい30分の作業なのに、数週間という見積もりが返ってくることがある。
運用に深刻なコストを生み、「すべてを止めて対応すべき」範囲に入る場合でもそうだ。
もちろん30分の作業がテストやドキュメント化のために本当に30分だけで済むわけではないが、見積もりがでたらめに近いほど信頼関係はさらに損なわれる。
ある作業にかかる実作業時間を聞いているのか、今からデプロイされる瞬間までの経過時間を聞いているのかでは違う。
ほとんどすべてのチームでは、どちらも作業が何かを待つ時間に支配されるが、後者の場合は特にひどい。
実際にキーボードを打っている時間は、たいてい調整やスケジューリングに比べれば丸め誤差に近い。
チームが直感に反する作業方式に力を入れていなければ、平均的なチケットは実作業より圧倒的に長く待たされる。
さらにチームはその不均衡をまったく見ておらず、それが重要だということにも気づいていない。
さっさと直して渡したい。
問題は、完全に自動化された継続的デプロイがなければ、30分は30分ではないということだ。
その30分の作業は、他部署に影響しないかレビューされる必要があり、日程調整と通知、デプロイが必要で、さらに2〜3人が関わる可能性がある。
予定された作業なら複数人にまたがって2時間近く、ホットフィックスやサポートチケットなら自動テスト以上のQAプロセスがある場合、生産性の損失は4〜6時間になる。
ここに別の6人が、社内の他の人への影響が不明確な「30分作業」を依頼してきたら、何も終わらなくなる。
私たちのチームにはホットフィックスのフローがあるが、本当に会社運営が止まる緊急事態でなければならない。
きわめて明白な場合を除けば、部門長以上が依頼する必要がある。
すべての緊急チケットを即時に処理できないことによる損害よりも、1人のための修正が複数人に問題を起こしたり、戦略的に重要な大きなプロジェクトを終えられなくなったりする損害のほうがはるかに大きい。
組織には必要なアクセス権を付与する方法があるはずだ。
答えが「自分の仕事ではない」に近いなら、その組織は厳密な責任を持つ相互接続された部品を重視する構造なのだ。
そういう組織では、コミュニケーションコストがアウトプット性能を完全に支配するのは当然だ。
うまく調整されていれば品質は高く、職務が明確ならスループットも高くなり得るが、低レイテンシは絶対に得られない。
応答時間は他のもののために犠牲にされるからだ。
些細な作業に1週間の見積もりが出るのも、そういう構造なら予想できることだ。
スケジュールが詰まっている状態では、新しい作業は数週間後にようやく割り当てられる可能性が高く、細分化された責任のために2人以上が必要なら待ち時間はどんどん足し合わされる。
それが業務に合わないなら、組織自体がその作業に合っていないということだ。
関係者全員にとって非効率だ。
私たちのチームは自律性が高く、時間を計ったり外部から生産性を見られたりはしないが、必要なときにコードを整える時間がない。
「30分」の作業を見つけたら朝のレビューに載せ、そのテーマに手を付けるときに隣接するものも一緒にやるかを聞く。
何もなくても1日を確保し、よく知っているプロジェクトなら半日を確保する。
半日はコードをざっと見て、残りの半日は小さなコメント、バージョンアップグレード、コード改善、変数名変更のような更新に使う。
個々のコントリビューターにもそうするよう促すほうが、時間効率はよいと考えている。
新しく来た個々のコントリビューターは、その時間を通じて古いコードを学び、最終的に大きな変更をしない限りレガシー問題も減っていく。
ソフトウェア開発における唯一の魔法の杖は、要求の単純化だ。
要求は常に間違っている。
広すぎるか、曖昧すぎるか、誤った前提に基づいている。
本当に優れた能力とは、一部の前提を捨て、単純化された解決策を提案することだ。
スケジュールを短縮する最善かつ唯一の方法だ。
要求が単純であれば、より完全で正確になりやすいが、実際の要求が単純化できないこともある。
その場合に必要なのは、よりよい仕様だ。
シャトルのソフトウェアグループを扱った「They write the right stuff」は、基本的にそういうことをした話だ: https://www.fastcompany.com/28121/they-write-right-stuff
ほとんどのソフトウェアのバグは実は要求のバグであり、よい要求があるときにソフトウェアを作る速度は信じられないほど速くなる。
完全に明確でぶれない要求により、空のリポジトリから2カ月で本番デプロイまで行ったプロジェクトを見たことがある。
逆に、曖昧で変わり続ける要求のせいで、およそ30行の機能実装が何カ月も引き延ばされたのも見たことがある。
今は項目が数十個しかないが、数年後には数千個になると言う。
デザイナーは20ページの製品要求文書をもとにすべての検索フローを設計し、すべての計画と準備が終わってからようやくエンジニアリングを呼び、ストーリーを書かせて作業を見積もらせる。
たいてい十分なドメイン知識があり、この文脈で何を作るには何が必要かを知っている。
ステークホルダーに合った費用/便益のバランスのために、スコープをどう変えるかを議論する価値はある
開発者が必要な作業量を多く見積もりすぎているケースも見たし、非開発者が時間を増やす核心部分を無視しているケースも見た
ときには汎用的な解決策を作ろうとするが、実際に必要なのは誰かが1日スプレッドシートに向き合って処理することかもしれない
見積もりが高すぎると質問されることは多いが、低すぎると質問されることはほとんどない、という問題こそプランニングポーカーが扱おうとしている点
皆が互いに影響されずに作業の難易度を言い、その後で期待がずれていれば議論する、という考え方
誰かが何かを見落としている可能性は高い
自分が何かを単純だと思う理由も、問題の複雑な部分を見落としているからか、よりきれいな解決策が見えているからかもしれない
顧客が数学的または物理的に不可能な要求をする場合がよい例
こうした願望について一日中プランニングポーカーをしても、なお不可能な妥協案にたどり着くことがある
フリーランスだった頃は、問題について徹底した説明を聞き、必要なら現在その問題を解決している人の肩越しにプロセスを見てから、数日姿を消し、最もエレガントで信頼性高く解けると思う設計案を持ってくるやり方を好んでいた
複雑な問題の経験が豊富な人でない限り、たいていの人は自分の問題を説明するのはそこそこできるが、解決策を提案することはできない
解決策は常に、その人が知っている限られたものをモデルにするから
実際には誰も要求していないのに、複数人が仮定をつなぎ合わせてできた奇妙な要件をたくさん見てきた
たとえば、社内ユーザー12人にデータをExcelスプレッドシートとしてダウンロードさせるために、無限にスケール可能なマイクロサービスアーキテクチャと完全なシングルページアプリを作るようなもの
チームが機能セット全体に十分慣れていて、AはXでやり、BはX*3でやるという避けられない差を扱うシステムの使い方を理解している、という前提が必要
Scrumが誤って運用されているという議論を見るだけでも、これらの前提はまったく保証されない
離職や新機能によって、チームがいつでもその前提から外れ得る点も考慮していない
あまりにも頻繁に、互いに眉を上げるだけで「XがやるのだからXの見積もりが値だ」となったり、平均/最小値を選んで、より高く見積もった人だけが不利になったりする
それならそもそもなぜポーカーをするのか分からない
これはそれよりさらにマキャベリ的
中間者は表なら自分が勝ち、裏ならあなたが負ける取引を望んでいる
自分側の相手を説得するために低い数字を示して利益を得たい
だから開発者に自分が望む数字を言わせようと、あらゆる手法を使うが、命令や強要のようには見せない
そう見えれば、その数字が自分の数字になってしまい、場が台無しになるから
しかし必然的にはるかに時間がかかれば、開発者が出した数字を指して、自分は聞いたことを伝えただけで責任はないと言える
この手の人間が理解する唯一の言語は、見積もりの「レビュー」依頼の結果が必ず上がるようにしてメッセージを送ること
第一に、見積もりはビジネスが適応するために有用であるべきなのに、現実には何の適応もない
PMは自分の上司から、おおよその締め切りまでに終わらせろという圧力を受ける
どうせ自分の見積もりを気にしないなら、なぜ見積もるのか？
第二に、チームには現実的に見積もるインセンティブがない
正確ならメダルでももらえるのか？ 実際には、すべてのインセンティブが見積もりを通じて作業量を膨らませる方向に働く
第三に、この見積もりの踊りと儀式はすべて、管理者が実際よりも効果的で影響力があるように見せるために受け入れているものにすぎない
エンジニアのときは、「これはもっと早くやる方法がないのだから、聞きたい数字を得ようとして圧力をかけるな」ときっぱり言っていた
終わるときに終わるのであり、堅牢で良い状態にするから邪魔しないでくれ、という立場
しかし管理者としてより小さな見積もりを押し通したときは、決められた期間内に何かを納品することがビジネス上の現実として重要だったから
トランプの家を建て、角を切り落とさなければならなくても、少なくとも後でその問題に対処できる程度には生き延びる必要があった
そのときエンジニアリング側からは、自分がその立場だったらしたであろう反発が出た
これはひどい考えで、将来失敗させるし、後の苦痛を避けるには今足を使って動くべきだ、という反発
再びエンジニアに戻ったが、管理者経験のおかげでこうした隔たりに対処するときにかなり役立っている
彼らは「11まで上がる」人たち
Spinal Tapのアンプのように普段の最大出力を9に合わせておけば、彼らが望むときにもう一段上げる余地ができる
もちろんそうすれば本来より遅く働くことになる
だが「11まで行く」開発者を望むなら、機能する方法は一つしかないのは明らか
顧客が待っているからではなく、自分の上司に良く見せるために恣意的な締め切りを押し付ける自分のマネージャーとその上のマネージャーがまさにこれ
見積もりが必然的に失敗すると、皆が手を上げて、自分たちのひどい見積もりを理由に人々を業績改善計画に入れ始める
エンジニアとして、こうした継続的なストレスの中で生き、家族や友人と過ごす時間まで逃して得られるものは何か？
自分の管理者の無能な見積もりを良く見せようとすることだけ
古い手口の一つは、ビジョンを作って約束した後で「自分の仕事はやった、あとはエンジニアリングが自分たちの仕事をすればいい」と言うこと
リリースを仕上げている最中、時には数時間前に、何の断りもなく機能を追加していた管理者を思い出す
すでに終わったリリースにも機能を付け加えていた
その人の頭の中では、機能をリリースに付けるだけですぐ終わるように見えていたらしい
最大の難点は、プロジェクトがたった1段落の説明しかない段階で、人々がすぐ見積もりを求めてくること
しかも常に「コードを覗いてみて、技術的負債がどれだけあるか次第」という感じがする
これまで出した唯一合理的な答えは、「要件を固めるためにあなたをプッシュし、開始前にコードベースをいったん止めて監査し、リスクを探すのに1〜2日必要だ」だった
ここからさらにうまくやれることはあるだろうか？
目的は完璧なカードを作ることではなく、プロジェクトで必要になりそうなすべての作業について、少なくともチケットを1つずつ作ること
そうすると「一括作成APIエンドポイントを作る」「既存テーブルから新テーブルへデータをマイグレーションする」のような1行カードがいくつもできる
カードが5枚以上あれば、
((カード数 / 開発者数) * カードあたりの想定営業日) + 想定休暇日で見積もる正確ではないかもしれないが、PMとその上司には、その時点の見積もりがよく考えられていて妥当だと感じてもらえる
後で遅延が必要になっても、「すべてのカードが同じくらいの日数だと仮定したが、この2枚は予想より大きな外れ値だった」と説明しやすい
通常のスプリントプロセスに似ているが、スプリントベロシティを勘以上の精度で追跡する必要はない
会社のリーダー層は、情報がほとんどない状態で見積もりを要求し、もっと調べてコードベースを見る必要があると言うと、「とにかく」この作業を承認するか、プロジェクトを進めるかを決めるための見積もりが必要だと言う
そうして堂々巡りになり、大きな見積もりを出すことになるが、範囲すら分からないものを含むあらゆる未知数のせいで大きな数字になる
するとリーダー層にとっては大きすぎ、高すぎるものになる
Agileの用語では3ポイントのスパイクチケットで、成果物は検討済みのトレードオフを伴う詳細要件、納品物、見積もりになる
完全に普通のやり方
スパイク前に見積もりを出すことはできるが、できるだけ条件を付けるべき
たとえば「60%の確信で3週間未満、80%の確信で5週間、90%の確信で6週間」のように言える
一般的には1〜2週間を超える締め切り見積もりは拒み、できるだけ細かい単位ごとの見積もりを好む
たとえば「このプロジェクトは、それぞれ1〜2日かかる7つの納品物で構成される」という形
ある作業がエンジニアリング作業として10日分であることはあり得るが、優先順位が変わるなどの理由で締め切り計算は実質的に無意味になるから
「管理職」たちがこれを理解できないなら、残念ながら平穏に進めるのは難しい
コードの負債や品質を気にせず、かろうじて動くものを急いで出すこと
そうすれば彼らは満足するだろう
典型的なアクション映画のハッキング場面はこんな感じ
リーダー：「メインフレームをハックするのにどれくらいかかる？」
技術者：「相手のハッカーが本当に優秀なので、最低2時間です」
リーダー：「1時間やる。やれ」
その後、3Dファイルシステムの中を飛び回る
こういう場面を見るたび、技術者に心の中でナレーションを付けている
「実際の見積もりは20分だった。たぶん50分くらいで終わらせて、リーダーに変な考えを起こさせないように、あと10分は3Dファイルシステム内を忙しそうに飛び回っていればいい」
完全に正しいとは言えない
多くの機能は、非常に骨組みだけのやり方から、完全に金メッキしたやり方まで、いくつもの段階で作れる
ときどき同僚の開発者が、私には長くても1日で終わるように見える機能に2週間と見積もることがあるが、それは実際には要求されていない多くの追加機能を想定していたり、私が必要だと知らなかった部分を知っていたりするから
見積もりを変えてほしいと頼まれたら、要件と提案された実装についてもう少し議論しようという招待だと考えればいい
90%まで到達できる、はるかに単純な解決策が可能で、受け入れられるかもしれない
気象学者にはそういう選択肢はない
基本的なコンボボックス/選択ボックスを放り込むのと、状況により合ったはるかに良いカスタムUI要素を作ることの違いは、IT以外の人にはうまく伝わらない
図で説明することはできるが、ステークホルダーは見ても触ってもいないので、やはり何が起きるのか分からない
だからたいていは、実際に動くように作って見せる必要がある
「できるだけシンプルにしてほしい」と言っておきながら、プロトタイプGUIと完成デザインのGUI、さらにプロトタイプを見せると、前の2つは見もせず承認するクライアントがいる
迫るとプロトタイプを触っても「いいね、進めよう」と言うが、テストサーバー上で実際に動くものを触った後で「これは我々の意図したものではない」と言う
2人夫婦の店から、地域ディレクターやグローバルCTOが意見を出すFortune 500企業まで経験してきた
これはフロントエンドの話で、バックエンドとDevOpsはまたまったく別の問題だが、そこにも骨組みだけ作ることと金メッキすることの間には大きな違いがある
今ではこのゲームを理解していて、最近はこの壊れたプロセスでかなり稼いでいる
1975年にFred Brooksはこう書いた
「子どもを産むには、女性を何人投入しても9か月かかる」
これよりうまい表現はない
https://en.wikipedia.org/wiki/The_Mythical_Man-Month
人を1人増やすたびに、さらに時間がかかる
最速の納品は、ソロ開発者の邪魔をせず、ただ作業させておくこと