【IT現場の生態系】現場を蝕む「開発者バイアス／甘い見積もり」の正体

「あと微調整だけです」という言葉の重み

　金曜日の夕方、オフィスに軽快なキーボードの音が響いています。進捗を確認すると、彼は笑顔でこう答えました。
　　「ほぼ出来上がってます。あとは微調整だけなので、月曜の朝には確認できるようにしておきますね」。

　しかし月曜の朝、デスクにいたのは目が血走った彼でした。画面には無数のエラーログ。
　　「いや、思っていたよりちょっと手強くて……」。

　ITの現場で、私たちはこの映画のワンシーンのような出来事を何度も繰り返し見てきました。
　　「進捗80%です」
と言われてから完成するまでに、なぜか全体の半分以上の時間がかかる。これは決して、彼らがサボっているからでも、能力が足りないからでもありません。

　人間の脳が仕掛ける巧妙な罠、「開発者バイアス」のせいなのです。

エンジニアの脳内で起きている「楽観という名の麻薬」

　見積もりが甘くなる背景には、大きく分けて三つの勘違いが潜んでいます。

　一番大きいのは、無意識に「ハッピーパス」だけを思い描いてしまうことでしょう。
　ハッピーパスとは、エラーも起きず、仕様変更もなく、すべてが理想通りに進むルートのことです。旅行に例えるなら、赤信号にも一度もかからず、渋滞もゼロという前提で到着時間を計算するようなもの。そんなドライブ、現実にはあり得ないのに、コードを書く前の脳内ではなぜかそれが「標準」になってしまうのです。

　二つ目は、「コードを書いている時間だけが開発である」という錯覚です。
　実際の仕事には、過去のコードを解読したり、やり方を調べたり、レビューを待ったりする時間が山のように含まれています。キーボードを叩いているのは全体のほんの数割に過ぎないのに、見積もりの瞬間、私たちは「キーボードを打っている時間」しか頭に浮かびません。

　そして三つ目が、周りからのプレッシャーや「デキる奴と思われたい」という見栄です。
　「どれくらいでできそう？」と聞かれたとき、断れずに「頑張れば2日です！」と答えてしまう。その瞬間の場の空気は和らぎますが、未来の自分に巨大な借金を背負わせているだけだったりします。

根性論を捨てて、仕組みで殴る

　では、この脳の癖にどう立ち向かえばいいのでしょうか。
　気合で「もっと慎重に見積もろう」と思っても、バイアスは消えてくれません。必要なのは、自分を最初から疑っておく仕組みです。

　まず試してほしいのが、自分が「これくらいでできる」と思った時間の1.5倍を、機械的に提出するルールを作ることです。「3日で終わる」と感じたら、脳内で勝手に「4.5日」に変換して伝える。自分の直感を一切信用しないという、少し寂しいくらいの割り切りが効果を発揮します。

　もう一つは、タスクをとことん細かく切り刻むことです。「問い合わせフォームを作る」という大きな塊のままだと、どうしても大雑把な見積もりになります。これを「画面のレイアウト」「入力チェック」「メール送信処理」「エラーが出たときの表示」と、1時間から数時間単位で終わるレベルまで分解してみる。細かく分解すればするほど、隠れていた「あれ、ここどうやるんだっけ？」という謎の時間が浮かび上がってきます。

　作業に入る前に「もしこの作業が遅れるとしたら、原因は何だろう？」と1分だけ妄想してみるのもおすすめです。「あ、あの外部サービスの仕様書、まだちゃんと読んでなかったな」といった小さな落とし穴に、事前に気づくことができるようになります。

「早く終わる」より「約束通り終わる」ほうがずっといい

　エンジニアにとって大切なのは、「早くできます」と調子のいいことを言うことではなく、「言った通りの日に届ける」ことのはずです。予備の時間（バッファ）を積むことは、ずるでもサボりでもありません。予期せぬトラブルからプロジェクトを守るための、立派な品質管理なのです。

　そして、周りのビジネスマンやマネージャーにも知っておいてほしいことがあります。エンジニアに「これ、どれくらいでできる？」と一発の数字で聞くのは、少し酷かもしれません。「一番うまくいった場合と、何かハマった場合で、それぞれどれくらい？」と、幅を持たせて聞いてあげるだけで、お互いのストレスは一気に減ります。

　予備日をたっぷり含んだ見積もりが出てきたとき、「もっと早くできないの？」と詰め寄らないでください。それは彼らが真剣にリスクと向き合った、誠実さのあらわれなのですから。

　完璧な未来予知なんて、誰にもできません。
　だからこそ、自分の脳の「甘さ」をあらかじめ計算に入れながら、お互いにクスッと笑ってフォローし合えるような現場でありたいものです。

【徒然メモ】「開発者バイアス」と 「その克服方法」

1. 「開発者バイアス」とは何か

　開発者が見積もりを立てる際、無意識に楽観的になったり現実と乖離したりする心理的・環境的要因の分類です。

　(1)心理的・認知バイアス（脳の癖）

　・計画の誤謬（Planning Fallacy）
　　過去に似た作業で遅延した経験があっても、「今回はスムーズにいく」と思い込んでしまう傾向。

　・自己奉仕バイアス／過信効果
　　自分の技術力やトラブル対応能力を過大評価し、エラーや詰まりが発生しない前提でスケジューリングする。

　・楽観主義バイアス
　　ネットワーク障害、APIの仕様変更、急な仕様変更などの「外部要因による障害」を考慮外にしてしまう。

　・トンネル視点（ハッピーパス指向）
　　「正常系（すべてが正しく動く流れ）」のコード量だけを計算し、例外処理やテスト、リファクタリングの時間を計算に入れない。

　(2)技術的・業務構造の理解不足

　・「コードを書く時間」＝「開発時間」という錯覚
　　調査、設計、ビルド、動作確認、コードレビュー、ドキュメント作成、デプロイ準備などの周辺作業時間を失念する。

　・未知の領域（Unkown-Unknowns）の軽視
　　新規技術や外部ライブラリを導入する際、「調べればすぐできるだろう」と調査・検証時間を数時間程度に見積もってしまう。

　・技術的負債の無視
　　既存コードの読み解きや、改修に伴う影響範囲の調査時間を計算に入れない。

　(3)組織・人間関係の圧力（環境的バイアス）

　・「早く見せたい・認められたい」欲求
　　優秀に見られたい、あるいはクライアントや上司を喜ばせたい心理から、希望的観測のスケジュールを提示してしまう。

　・「プレッシャーへの忖度」バイアス
　　営業や PM から「〇日までにできる？」と聞かれた際、断れずに「頑張ればできる」ギリギリの日数を言ってしまう。

2. 開発者バイアスを克服する方法

　バイアスは根性論では解決しないため、「仕組み」「手法」「コミュニケーション」の観点から対策を分類します。

　(1)見積もり手法・計算ルールの仕組み化

　・作業の細分化（WBSの徹底）
　　1つのタスクが半日〜1日（例：4時間〜8時間以内）で終わるレベルまで分解する。小さく分解するほど認知の漏れが減る。

　・バッファの定型ルール化（「3点見積もり」など）
　　　・最良シナリオ・標準シナリオ・最悪シナリオの3パターンを出して加重平均を取る（PERT手法）。
　　　・「算出した見積もり×1.3〜1.5」を標準バッファとして組織的にルール化する。

　・「過去の実績値」との比較（類推見積もり）
　　自分の感覚ではなく、類似タスクの「過去の実際の消化時間」をログ（JiraやTrello等）から引っ張り出して適用する。

　(2)レビューと組織的プロセス（他者目線の導入）

　・ピア・見積もり（相見積もり・ポーカー見積もり）
　　1人の感覚に依存せず、チームの複数人で見積もりを出し合い、乖離がある部分の認識を合わせる。

　・「悪魔の代弁者（Pre-mortem）」セッション
　　見積もり決定前に「このプロジェクトが計画通りに終わらなかったと仮定したら、理由は何か？」をあらかじめ出し合い、リスク時間を事前組み込みする。

　(3)マインドセットとコミュニケーションの改善

　・「開発時間」と「作業時間」の区別
　　1日8時間労働でも、会議やチャット返信、レビュー等で集中できるコード執筆時間は「実質4〜5時間」であることを前提に計算する。

　・バッファ提示の心理的ハードルを下げる
　　上司や顧客に対して「早く出す見積もり」ではなく「確実に守れる見積もり」こそが価値であるという文化を作る。

【関連記事】

☆IT現場の生態系

☆プロマネの生きる道

☆プロジェクトマネジメントの小径

書籍の紹介

・人月の神話
・フレデリック・P・ブルックス，Jr. (著), 滝沢徹 (著), 牧野祐子 (著), 富澤昇 (著)  形式: Kindle版
・丸善出版　2014/4/20
　大規模開発プロジェクトにおけるソフトウェア工学の古典として読み継がれている名著。「遅れているソフトウェアプロジェクトへの要員追加は、さらにプロジェクトを遅らせるだけだ」というブルックスの法則は名高い。開発において「人員×月日」というスケジュール見積もりを適用する問題点を指摘する。
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

・プロジェクトマネジメント知識体系ガイド
　（PMBOKガイド）第7版 Kindle版
　＋プロジェクトマネジメント標準: PMI日本支部 監訳
　プロジェクトマネジメント協会（PMI） (著)
　一般社団法人 PMI日本支部 (2023/1/6)
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

・図解即戦力　PMBOK第7版の知識と手法がこれ1冊でしっかりわかる教科書 Kindle版
　前⽥ 和哉 (著)
　 技術評論社 (2024/9/20)
　プロジェクトマネジメントの世界標準として知られるPMBOK Guide 第7版の解説書です。「プロジェクトの基本」「価値実現システム」「12の原理・原則」などプロジェクトマネジメントの基礎となる知識のほか、PMBOK第7版のメインテーマともいえる「8つのパフォーマンス領域」について、要点をくわしく解説します。プロジェクトマネジメントの勉強のほか、PMP試験対策の第一歩としてもおすすめできる1冊です。
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

・図解入門よくわかる 最新PMBOK第6版の基本 Kindle版
　鈴木安而 (著)
　‎ 秀和システム (2018/3/23)
　PMBOKガイドは、米国プロジェクトマネジメント協会により、日本語を含め世界11ヶ国語に翻訳・出版されています。翻訳されても、専門用語が多い、カタカナ用語が多いなどの理由からなかなか理解が困難です。本書は、『PIMBOKガイド第6版』の翻訳・監訳チーム・リーダーでもある著者が、本来の意味をなるべくかみ砕いて解説します。イメージしやすいよう図版を豊富に使っているので、初心者からベテランまでわかりやすくなっています。
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

・プロジェクトマネジメントの基本がこれ1冊でしっかり身につく本 Kindle版
　前田和哉【著】
　技術評論社（2022/06）
　本書は、プロジェクトマネジメントについて基本から学ぶことのできる入門書です。プロジェクトマネジメントの基礎知識について解説した後、プロジェクトを「立ち上げ」「計画」「実行」「監視・コントロール」「完了」という5つの段階に分け、各段階において実施すべきこと、注意すべきポイントについて丁寧に解説しています。
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-