見積もりやリカバリーの「失敗」は必ず起こる
このような事態が発生するのはなぜだろうか。石垣氏は以下の2点を挙げる。
- 「失敗は見積りの失敗」であるという認識の欠如
- 隠された失敗が明るみになり、「詰んでいる」状態であること
1．について石垣氏は、マーティン・ファウラー氏による言葉を引用しつつ、「プロジェクトが失敗するのは、そもそもの見積もりが失敗しているためだ」と話す。さらには「見積もり時点での計画工数が大きくなるほど、実績との乖離が大きくなる傾向がある」というIPAのデータも示した。
そのうえで石垣氏は、「見積もりが失敗するのは、プロジェクト初期の段階で多くの約束事を決めてしまうためだ」と指摘する。有名な図である「不確実性のコーン」が示すように、プロジェクトの初期は不確実性が非常に高いため、焦ってリカバリー策を講じたところで見積もりのズレは取り戻せないのだ。
「プロジェクト初期に『だいたいこのくらいです』と伝えた概算がいつのまにか"約束"となり、首を絞めることはよくある。技術負債が溜まっていればなおさら見積もりは難しい。エンジニアはこのことをよく認識し、"DD（詳細設計）の後であれば、リリース日を約束できる"といった形で伝えるべきだ」。石垣氏は、予測と約束を区別することの必要性をこう強調した。
2．の「隠された失敗」は、予定日の直前になされる「リリース日が2週間ずれます」という報告などだ。事業責任者からすれば「どうして今言うんだ」と頭を抱えたくなるだろう。
石垣氏によれば、このような状況に陥る原因には、エンジニアの「リカバリーできる」という過信や、開発への不安から必要以上のバッファを取ってしまうケースがあるという。「技術負債の解決と内部品質の改善は、遅くなればなるほどリカバリープランが限られる」と、早めに報告することの重要性を強調した。
計画のディレイや予算超過といった課題を抱えた事業責任者は、内部品質の改善よりもスピードを重視し、短期的な選択に走りがちだ。しかし、こうした状況が続くとエンジニア側からは「いつリファクタリングのような内部改善ができるのか」という疑問が生じてしまう。
「事業を営む以上、毎年の売上成長を目標に掲げることは避けられない。だからこそ、それを言い訳に問題を先送りすることなく、内部品質の改善や技術負債の解消をスケジュールに織り込んでいくことが重要だ」。
エンジニアの「言語化能力」はリファクタリングにも効果アリ
技術負債を解消するためには、エンジニアの言語化能力も鍵となる。内部品質の改善効果は非エンジニアにとっては分かりにくいうえに、リファクタリングの具体的な効果や意義を説明できるエンジニアも少ないため、事業責任者の納得を得づらいのだ。
「昨今では事業責任者も、リファクタリングを『やったほうがいい（やらなければ）』と考えていることが多い。ただしその範囲や方法に知悉しているとは限らず、そうなると予算やスケジュールも立てられないので、及び腰になるわけだ」
DMM.comには20年以上変わらないシステムも多く存在しており、これらのリファクタリングには数十億円規模の費用がかかる可能性がある。
石垣氏はこうしたレガシーの解消に「いつ踏み込もうかと悩む」としつつ、具体的な手立てとして「開発の優先順位を明確化すること」を挙げる。これは新規開発やエンハンス開発はもちろん、ミドルウェアのバージョンアップやセキュリティ対応、設計改善なども含めた幅広い要素に優先順位をつけるものだ。
エンジニアリングは不確実性が高いため、これらの事項を適切に言語化しオープンにすることで、「新規開発やエンハンス開発ばかりを割り振られ、内部品質改善の機会が失われる」という状況を回避できる。石垣氏は「リファクタリングという言葉を使わずに、何をするのかをしっかり言語化して伝えることが重要」と、非エンジニアにもわかるような説明を行うエンジニア側の責任について強調し、ミノ駆動氏の講演につなげた。
