なぜ刷新の見積もりは膨らむのか：不確実性を減らす調査と計画
レガシーシステム刷新の検討で、最初に知りたいことの一つは費用と期間です。しかし、プログラム本数や画面数を数えた段階の見積もりと、業務やデータの調査を終えた後の見積もりでは、前提が大きく違うことがあります。
見積もりの精度を高めるには、数字を細かくする前に、その数字を変え得る条件を明らかにする必要があります。何が分かっていて、何が未確認で、どの調査を行えば次の判断ができるのか。これを説明できる計画が、予算と進捗の管理を支えます。
図：調査で得た根拠に合わせて、実施範囲と見通しを具体化する。
プログラム本数だけでは、必要な仕事が見えない
同じ本数のプログラムでも、独立した照会処理が中心のシステムと、締め処理や外部連携が複雑なシステムでは、必要な調査と試験が異なります。コード量に表れないデータ補正や運用担当者による手作業が、移行範囲に入ることもあります。
また、変換されたコードが動くまでの工数だけでは、刷新全体の費用は説明できません。データの移行、性能確認、権限設計、利用者教育、切り替え準備、運用引き継ぎ、旧環境の終了までを対象に含める必要があります。
見積もりの対象 | 調査で明らかにすること |
業務・アプリケーション | 継承、変更、廃止する機能と例外処理 |
データ | 移行量、変換、補正、照合、履歴の参照方法 |
連携 | 相手先、仕様、変更可能な時期、結合試験の条件 |
基盤・運用 | 環境、監視、バックアップ、権限、障害対応 |
検証・切り替え | 受け入れ条件、リハーサル、停止可能時間 |
利用・定着 | 教育、問い合わせ対応、業務手順の更新 |
終了・維持 | 旧環境の廃止条件と、新環境の継続費用 |
AWSのアプリケーション評価ガイドでも、評価は資産の発見、分析、計画からなる活動とされ、移行全体に継続して情報を提供する役割が示されています。クラウド移行向けの資料ですが、調査結果を計画へ反映し続ける考え方は、刷新計画を検討するうえでも参考になります。
見積もりを、前提条件とセットで提示する
初期段階では、すべてを確定できるとは限りません。そこで、確定している作業、前提を置いた作業、追加調査が必要な作業を分けます。「調査後に決める」とだけ記載せず、何を確認し、どの結果なら見積もりが変わるかまで示します。
仮の例として、月次バッチの処理時間が分からないケースを考えます。予備工数を上乗せするだけでは、性能問題をどこまで見込んだのかが分かりません。現行の処理時間とデータ量を測り、移行先で代表処理を試し、許容時間を超える場合は設計を見直す、という確認手順を設けると、追加作業が発生する条件を説明できます。
未確定部分を含む見積もりは、単一の金額だけでなく、条件別の幅や内訳で示す方法があります。ただし、その幅を根拠なく狭めたり、統計的な裏付けがないのに確率を付けたりすることは避けます。基本ケース、追加作業が発生する条件、次に見直す時点を明確にします。
予備費や余裕期間を設ける場合も、二重計上にならないよう、各作業に含めた余裕との関係を整理します。何に備えるのか、誰が使用を判断するのかを決めておくことで、使い道の分からない上乗せを減らせます。
調査は、次の判断に必要な成果物を決めて行う
調査の終了条件が曖昧だと、資料は増えても、発注や実施の判断に進めません。初期調査で得たい成果物を、意思決定に結び付く形で定義します。
たとえば、資産一覧には、名前だけでなく、利用状況、担当、重要度、依存先を含めます。業務一覧には、継承する範囲、変更する範囲、まだ判断していない項目を示します。データ調査では、移行量に加えて、品質上の問題と補正の責任者を整理します。
調査結果が「対象資産の一覧」「依存関係」「移行方式の候補」「未解決事項」「見積もりの前提」にまとまれば、次の段階でどこまで確約できるかを判断しやすくなります。調査自体にも範囲と期限を設け、重要な不確実性から優先して解消します。
代表機能の検証では、難しさを代表させる
試しに小さな機能を移してみることは、方式を確かめるうえで有効です。ただし、最も簡単な画面だけを対象にすると、そこで測った生産性を全体に当てはめられないことがあります。
検証対象は、全体の負担を左右する条件を含むように選びます。大量データ、複雑な計算、外部連携、例外処理、長時間バッチなど、主な難しさを一つの対象に含められない場合は、複数の小さな対象で確認します。
検証の完了条件も、コード変換や画面表示までとせず、必要なデータ変換、テスト、修正、運用手順まで含めて決めます。測定した工数は、環境構築などの初回だけの作業と、対象ごとに繰り返す作業に分けます。試作で省略した作業があれば、全体見積もりに戻す必要があります。
AIや変換ツールを使う場合も、生成速度に加えて、レビュー、誤りの修正、試験まで含めて評価します。検証済みで受け入れ可能な成果物を作るのに、どれだけの作業が必要かを把握することが目的です。
工数とカレンダー上の期間を分ける
必要な作業量が分かっても、人数で割れば完了日が出るとは限りません。業務判断を行う担当者、既存システムに詳しい担当者、外部連携先など、同時に対応できる量には制約があります。
月末や繁忙期には試験や切り替えを行えないこともあります。機材・環境の準備や外部との調整に待ち時間がある場合、開発要員だけを増やしても全体の日程は短くなりません。誰の判断がいつ必要になるかを、工程に組み込みます。
AWSの移行ウェーブ計画では、技術的な依存関係に加え、担当者の確保や業務上の重要日程も考慮しています。対象を段階に分ける場合も、こうした制約と依存関係を基に実施単位を決めることが大切です。
複数社の提案を比較するときは、総額の前に、対象範囲、移行回数、試験の責任分担、利用部門に求める作業、切り替え後の支援期間をそろえます。含まれる仕事が違う見積もりを並べても、価格差の理由を判断できません。
計画を更新する条件を、最初に合意する
調査や先行移行で分かったことは、後続の計画へ反映します。その際、当初の見積もりを消してしまうと、何が変わったのか分からなくなります。基準となる計画を残したうえで、差分が範囲の追加、前提の誤り、作業の難しさ、判断待ちのどれによるものかを説明します。
節目では、対象範囲が明確か、重要な方式を検証できたか、未解決事項を引き受ける責任者がいるかを確認します。その結果に応じて、次段階へ進む、追加調査を行う、範囲や方式を見直す、という判断を行います。予算や期限を守るための選択肢を、問題が大きくなる前に持てるようにします。
株式会社Managetechは、見積もりは関係者が前提を共有するための道具だと考えます。何をどこまで行い、何が分かれば精度が上がるのかを示します。その積み重ねによって、経営の判断と現場の実行をつなぐ刷新計画を組み立てます。
コメント