アプリケーションの開発や拡張に着手する前は、ビジネスルールの確認が必要だったり、連携先のドキュメントがなかったり、データ品質に懸念があったりと、詳細が不足していることがよくあります。それでも、プロダクト、ビジネス、技術の各担当者は、進めるかどうか、どのチームで取り組むか、どの順序で進めるかを決める必要があります。この状況で不確実性がある中でPHPプロジェクトを見積もるとは、正確な数字を当てることではありません。根拠のある予測とその限界、予測の精度を高めるために必要な情報を示すことです。
見積もりは、意思決定を導き、作業を調整するために役立ちます。スコープ、納期、コストが変わらないという約束になるわけではありません。これらの概念を区別すれば、リスクを隠さずに計画を立て、具体的な情報に基づいて変更を話し合えます。
単一の数字では不確実性が見えなくなる理由
「12週間」のような数字は単純に見えますが、何が含まれるのか、何が第三者に依存するのか、どのような前提を置いたのかは分かりません。2つのチームが同じ期間を提示していても、見積もっている作業は異なる場合があります。一方はテスト、移行、デプロイまで含め、もう一方は機能開発だけを対象にしているかもしれません。明確な根拠がなければ、その数字では提案を比較できず、差異の原因も特定できません。
工数と期間も分けて考える必要があります。工数はチームが行う作業量を表し、カレンダー上の期間には作業の順序、人員の稼働状況、レビュー、待ち時間、依存関係が影響します。人員を増やしても、必ず期間が短くなるとは限りません。調整コストが増えたり、外部システムへのアクセス待ちが解消されなかったりすることがあります。
そのため、情報だけではより高い精度を正当化できない場合は、予測を幅のある範囲で示します。その範囲には説明が必要です。どのシナリオを表すのか、どの不確実性が幅を広げているのか、どのような条件が整えば範囲の端に近づけるのかを明らかにしましょう。根拠のない範囲は、恣意的な数字を2つ並べただけにすぎません。
既知のスコープ、不明点、依存関係を分ける
見積もりの前に、理解済みの作業と調査が必要な作業の違いが分かるよう、見積もりの根拠を整理します。各項目を次のように分類できます。
- 既知：合意済みで検証可能な動作。たとえば、既存フォームにバリデーション付きのフィールドを追加する作業。
- 要確認：未決定の機能上の判断。たとえば、誰がどの条件で申請を承認できるか。
- 依存関係：別のチーム、ベンダー、システムが管理するアクセス、回答、納品。
- 技術リスク：実現可能性やコストが不明な事項。たとえば、形式が統一されていないデータの移行。
PHPアプリケーションでは、既存環境についても確認します。コードの構成、テストの網羅性と有用性、環境のバージョンと依存関係、データモデル、連携、認証、権限、デプロイプロセスなどです。すべてが不健全だと決めつける必要はありませんが、確認済みのことと仮定にすぎないことは見極めましょう。
前提は、その影響とともに記録します。たとえば、「外部サービスにはテスト環境と最新のドキュメントがあるものとする。そうでなければ、連携の見積もり前に仕様の調査が必要」と記します。こうすれば、前提が隠れた条件になるのを防げます。誰がいつ確認できるかも記録しましょう。
フェーズごとに範囲を設定し、含まれる作業を説明する
意思決定に役立つ単位に作業を分けます。最初の構成として、調査、実装、検証、本番環境への反映が考えられます。すべての取り組みに同じフェーズが必要なわけではなく、各フェーズを独立したブロックとして実行すべきとも限りません。作業の種類を分け、各段階の成果を明確にすることが目的です。
各作業について、期待する成果、見積もり工数、主な不明点、依存関係を記します。たとえば、連携には、仕様の分析、実装、実際または模擬の応答を使ったテスト、エラー処理、可観測性の確保が含まれる場合があります。見積もりが通信コードだけを対象にするなら、その旨を明記し、連携全体の見積もりとして提示しないでください。
入手できる根拠に見合った範囲を算出します。スコープが定義され、チームがシステムを理解している場合は、幅を狭められます。要件が不足していたり、未知の技術が含まれたりする場合は、幅を広げ、その理由を説明します。特定したリスクと結び付けずに一律の予備率を足すのは避けましょう。カバーできているという誤った印象を与えるうえ、不確実性をどう減らすかも明確になりません。
合意がなければ対象外になりがちな作業も示します。データの準備、セキュリティレビュー、アクセシビリティ、監視、ドキュメント、トレーニング、他チームとの調整などです。すべてを必ず含める必要はありませんが、含めるかどうかは明確に決めましょう。期間を伝える際は、作業の順序と、スケジュールに影響し得る外部の待ち時間も示します。
調査やパイロットリリースで根拠を得る
不確実性によってコストや実現可能性が大きく変わる場合は、詳細な計画を確約する前に調査したほうがよいことがあります。範囲を限定した調査フェーズでは、コードやアーキテクチャの確認、ユーザーフローの明確化、連携の検証、技術的な仮説のテストを行えます。調査の質問、活動内容、予定期間、成果物を定めましょう。成果物の例として、未決事項、更新されたリスク、改訂後の見積もりがあります。
実際のユーザーやシステムを使って代表的なフローの一部を試せる場合は、パイロットリリースから根拠を得られます。ただし、パイロットはデモではなく、それだけで製品の運用準備が整ったと証明するものでもありません。評価対象と成果の測定方法を定め、スコープを拡大する前に必要となる品質、セキュリティ、サポート上の管理策を明らかにします。仮説が確認できなかった場合にどのような判断をするかも、あらかじめ合意しておきましょう。
調査にもパイロットにもコストがかかり、問題が明らかになることもあります。不確実性がなくなる保証はありません。問いに応じて選択しましょう。要件の明確化ならレビューで十分な場合がありますが、技術的に未知の連携には、範囲を限定したテストが必要かもしれません。現時点で調査する価値がなければ、リスクを記録し、根拠が得られたときや影響が変わったときに見直す計画を立てます。
変更のたびに危機にせず、計画を見直す
見積もりの見直しは、以前の見積もりが役に立たなかったという意味ではありません。得られている情報が変わったということです。たとえば、調査の完了時や依存関係の検証後など、見直しの時点を定め、分かったことを当初の前提と比較します。
変更が生じたら、何が変わったのかを説明します。スコープ、前提、依存関係、品質要件、システムの条件などです。そのうえで、作業とスケジュールへの影響を説明し、選択肢を提示します。スコープを縮小または延期する、納期の延長を受け入れる、調査に投資する、または緩和策を用意してリスクを受け入れるといった方法があります。そうすれば、古い数字を守るのではなく、意思決定とその結果について話し合えます。
予定した節目より前に見直すべき兆候として、要件の矛盾、環境へのアクセスの遅れ、想定と異なるデータ、構造上の問題が明らかになるテスト、外部依存先からの回答の欠如などがあります。作業にかかる工数が継続的に見積もりを上回る場合は、同じ調整を残りすべての作業に機械的に適用するのではなく、見落としていた複雑さや中断など、原因を調べます。
見積もりを伝えるための簡易テンプレート
実用的な要約は1ページ程度で、次の項目を含められます。
- 目標とスコープ：目指す成果と対象外の事項。
- 工数と期間の範囲：使用する単位、含まれるフェーズ、作業量とカレンダー上の期間の違い。
- 前提：見積もりの根拠となる条件と、その確認方法。
- 不確実性と依存関係：影響、担当者、次に確認する兆候。
- 確度：制約する要因を含む、根拠のある評価。統計的な精度を装った数字ではない。
- 次のステップ：計画の見直しにつながる意思決定、調査、またはリリースと、見直しの日付や条件。
たとえば、いくつかの前提に基づく初期実装フェーズを範囲に含め、外部連携はまだ検証されておらず、テスト環境へのアクセス後に計画を見直す、と伝えられます。この例は一律の期間を定めるものではありません。観察可能な条件と予測をどう結び付けるかを示しています。
初期見積もりの質は、範囲がどれほど狭いかではなく、次の一手を選ぶのにどれだけ役立つかで測られます。PHPプロジェクトでは、既知の作業と不明点を分け、依存関係を説明し、計画の更新方法に合意することで、要件がすべて確定する前でも、誠実な判断ができるようになります。
