システム導入を立て直すための要件定義—失敗を繰り返さない4つの観点

納期の回復より、経営判断の回復を優先する

元の計画へ戻ることを唯一の成功とすると、誤った前提まで温存します。最初に、経営が継続・縮小・変更・中止を選べる証拠を成果として定義します。

元の納期へ戻すことだけを成功にしない

市場、制度、業務、利用者ニーズが変わっていれば、当初の全範囲を完成させても価値がありません。範囲縮小、段階提供、解決方式の変更、契約再設計、中止も、価値とリスクを比較した結果なら正しい意思決定です。

GOV.UKのDiscoveryガイダンスは、構築前に問題、利用者、制約、政策意図、改善機会を理解し、価値と費用を比較するよう示します。立て直しでも、完成させる方法を議論する前に、解くべき問題と進む価値を再確認します。

解決策が先行した案件では、「この製品を導入する」「この画面を完成させる」が目的化します。立て直しでは、対象利用者、現状の不利益、望む結果、法令・契約・技術制約、代替手段へ戻します。そのうえで、当初の投資効果の見込みが今も成立するかを再判定します。

• 当初の事業上の前提が現在も成立するか確認する
• 継続、縮小、段階化、方式変更、中止を比較する
• 対象外と停止条件を経営判断として記録する

犯人探しではなく共通の事実を作る

責任追及から始めると、課題や前提が隠れ、診断が政治的になります。契約、要件、設計、コード、テスト、変更、課題、環境、データを保全し、代表的な業務シナリオを実機で確認します。関係者には同じ論点でインタビューし、意見と証拠を分けます。

課題は、目的、範囲、要件、データ、技術、品質、体制、契約へ分類します。発注者と受注者のどちらか一方だけを原因にせず、意思決定、依存作業、前提、成果物の完成条件がどう連鎖したかを問題原因の関係図にします。

継続判断では残作業だけでなく、利用可能な資産、追加投資、移行・運用費、機会費用、停止時の影響を比較します。過去に費やした金額は回収不能であり、将来価値の証拠にはなりません。すでに支払い、回収できない費用を守るために完遂するのではなく、現在から見た最良の選択を行います。

• 現行版と権限を保全し、無秩序な変更を止める
• 重大なサービス・セキュリティリスクは先に被害拡大を止めることする
• 症状と根本原因を別の欄で記録する

初動で変更を止め、資料と事実を保全する

変更を増やす前に、成果物、契約、決定、欠陥、環境、データ、未解決事項を凍結・保全します。責任追及ではなく、再検証可能な事実を作ります。

意見ではなく証拠の目録を作る

成果物の有無だけでなく、誰がどの環境で確認したか、現行版はどれか、再現できるかを記録します。進捗報告と実行可能なソフトウェアが矛盾する場合は、代表シナリオを実際に動かし、完了・未完了・不明を区別します。

課題台帳を責任追及ではなく前提検証へ変える

課題には、観察事実、業務影響、想定原因、必要な証拠、暫定措置、決定者、期限を持たせます。「要件不備」「ベンダー遅延」といったラベルだけでは、行動につながりません。考えられる原因を複数置き、誤りか確認できる情報を集めます。

具体例：進捗率は高いが業務が完了しない場合

以下は特定案件を再現したものではなく、一般的な論点を組み合わせた架空の例です。画面や機能は多数完成していても、権限、データ、例外、外部連携、移行がつながらず、利用者が一連の業務を完了できない場面を扱います。

最も危険な一連の流れを先に通す

取引量、例外、法令影響、連携依存が大きいシナリオを選び、最小構成で動かします。未完成部分は仮の接続先でも構いませんが、データ項目・品質・更新ルール、処理状態の変化、権限、失敗時の戻りを検証します。これにより、詳細開発前に構造的な不整合を発見できます。

結果を範囲と契約へ戻す

検証で判明した追加作業を単なる変更要求にせず、当初前提、責任分界、合格条件との関係で整理します。段階提供の単位、支払、検収、変更手続を更新し、発注者・受注者のどちらかへ一方的に負担を移しません。

遅延や不具合の奥にある原因を確認する

遅延、欠陥、要件増加を原因とみなさず、目的、責任、合格を判断する根拠、学習の欠落まで遡ります。四つの観点を再始動条件へ変換します。

観点1・2：目的と責任を正常化する

目的では、特定製品の導入や画面作成という表現を、誰が何を達成できず、どの影響があるかへ置き換えます。事業成果、対象利用者、制約、対象外を一枚にし、スポンサーが承認します。ハード制約と、現行慣習のように変更可能なソフト制約を分けます。

責任では、情報共有、論点整理、助言、承認、決裁を分け、誰が何をいつ決めるかを明確にします。業務要件を事業者へ丸投げせず、発注側の業務オーナーが選択と優先順位を担います。技術側は実現方式、制約、リスクの選択肢を提示します。

要件追加は、利用者や目的の未理解、例外発見、法令変更、設計制約の顕在化など複数の原因から起きます。件数だけを抑えても原因は残ります。追加要件を目的、発見経路、影響、回避可能性、決定遅延へ分類し、どの学習不足が繰り返されているかを確認します。

• KGI（最終目標を表す指標）、対象利用者、制約、対象外を再承認する
• 要件・設計・予算・変更の決定者を分ける
• 未決事項へ決定者、期限、影響を付ける

観点3・4：検証と学習を計画へ組み込む

検証では、各要件に適用条件と合格を判断する根拠を持たせます。文書レビュー、試作品、機能テスト、性能測定、移行照合、運用リハーサルなど、何をもって満たしたと判断するかを先に決めます。

学習では、理解が増えるたびに前提、範囲、見積、優先順位を更新します。変更を悪とせず、価値、費用、日程、品質、リスクへの影響を同じ形式で判断します。GAO（米国会計検査院）のAgile Assessment Guideが示す増分開発と継続評価を、無計画な仕様変更ではなく統制された学習として用います。

手戻りも「開発者の品質」だけで説明せず、合格条件の曖昧さ、データ例外、性能・安全性などの条件の後付け、レビュー環境不足、意思決定遅延を切り分けます。欠陥が見つかった工程ではなく、混入した判断や条件へ戻ることで再発防止が可能になります。

• 要件とテスト・証拠を対応付ける
• 変更の判断基準と承認経路を統一する
• 重要前提が変わったときの再判断条件を決める

継続・縮小・段階化・方式変更・中止を比べる

埋没費用や対面上の理由ではなく、今後得られる価値、追加費用、重大リスク、代替、撤退費を同じ表で比較します。中止を損失制限として扱います。

継続条件を言語化する

たとえば「代表業務シナリオが実データで成立する」「重大な性能・安全性などの条件リスクに検証方法がある」「運用責任者が受入に参加する」といった条件を置きます。条件を満たさない場合は、期限を延ばすのではなく、範囲・方式・契約を見直します。

中止を失敗ではなく損失制限として扱う

事業環境が変わり期待する業務効果が消えた、法令・技術制約で実現性がない、追加投資が代替案を上回る場合、中止は合理的です。データ・知見・再利用可能な資産を保全し、意思決定理由を記録することで、同じ前提を別案件で繰り返さないようにします。

要件を目的・適用条件・合格基準で書き直す

「〜できる」という機能文を、なぜ必要か、いつ誰に適用するか、何を見て受け入れるかへ分解し、業務シナリオへ束ねます。

業務の受付から完了までの業務シナリオへ束ねる

機能領域やシステム別に分割すると、利用者が仕事を完了できるかを最後まで確認できません。受付、判断、処理、通知、記録までの業務シナリオへ要件を束ね、利用者、データ、例外、性能・安全性などの条件、運用を一つの業務完了単位にします。

各要件には、どの事業成果・利用者ニーズに寄与するかという目的、どの利用者・状況・データ・例外に適用するかという条件、何をもって合格とするかという証拠を記録します。目的に紐づかない要件は、法令や基盤制約など別の根拠がなければ削除候補です。

最小単位は画面や機能ではなく、利用者が業務結果を得るシナリオです。各要件を、なぜ必要か、誰・いつ・どの条件に適用するか、何を観察できれば満たしたと判断するかで記述します。根拠がない要件、重複、矛盾、実装方式へ過度に固定された要件を見直します。

• 要件を画面・機能名だけで分類しない
• 通常処理と例外処理を同じシナリオで確認する
• 目的が重複する要件を統合する

性能・安全性などの条件、データ、移行、運用を同時に扱う

画面機能を先に固め、性能、権限、監視、データ移行を終盤へ送ると、成立条件の問題が遅れて判明します。重要シナリオごとに、可用性、応答、セキュリティ、ログ、データ品質、バックアップ、サポート、教育、切戻しを確認します。

デジタル庁の解説書は、テストの種類、目的、内容、実施者、合否、環境を要件として明らかにすること、既存サービスの継続方針によって移行作業が大きく変わることを示しています。旧新並行、未完了データ、切替時点、復旧目標を要件定義へ戻します。

合格を判断する根拠には、デモ、実データによる処理結果、性能測定、障害復旧演習、権限レビュー、移行照合、利用者テストなどがあります。文章レビューだけで完了とせず、要件の性質に合う証拠を選びます。

• 移行照合の件数・値・関係・履歴を定義する
• 運用担当者を受入テストへ参加させる
• 切替と切戻しを本番前にリハーサルする

データ・非機能・移行・運用を同時に確認する

後工程へ追いやられた制約を、機能と同時に検証します。最も危険で不確かな前提から高リスク項目の先行検証を設計します。

高リスク項目の先行検証の対象を選ぶ

主要な外部連携、データ移行、複雑な権限、ピーク性能、現場受容、法令解釈など、影響と不確実性の双方が高い前提を優先します。見た目の分かりやすい画面を先に作るのではなく、成立しなければ方式変更が必要になる部分から試します。

GOV.UKのAlphaガイダンスは、最もリスクの高い前提を、判断に必要な最小限の試作品で試す考え方を示します。検証用コードを本番品質と誤認せず、検証した問い、データ、結果、限界、次の判断を記録します。

代表シナリオには正常操作だけでなく、欠損・重複データ、権限不足、外部連携遅延、ピーク負荷、障害、再処理、取消を含めます。性能・安全性などの条件を別紙の抽象要件にせず、業務がどの条件で継続・停止・復旧するかへ結びます。

• 価値と不確実性のマトリクスで順番を決める
• 検証前に成功・失敗・追加調査の条件を書く
• 結果が悪い場合の代替案と停止判断を準備する

利用者が業務を完了できる最小範囲でロードマップを再構成する

検証結果を踏まえ、利用者が一連の仕事を完了できる単位でリリースを作ります。各単位には機能、データ、性能・安全性などの条件、移行、運用、教育、切戻しを含め、完了の定義を共有します。文書やコードの作成量を進捗率にしません。

次の段階へ進む判断条件は、重要シナリオの受入、重大欠陥、移行照合、運用準備、未解消リスクで判断します。全体の納期を先に約束するのではなく、危険な前提が解消されるにつれ予測幅を狭めます。

移行はデータ投入で終わりません。件数・値・関係・履歴・権限の照合、業務開始前の差分処理、切替後の訂正、旧システム参照、問い合わせ窓口、切戻しを含めます。運用チームが試験と受入に参加していない場合、本番準備は完了していません。

• 業務完了単位ごとに予算・日程・受入を持つ
• 依存関係と決定待ちを可視化する
• 提供後の利用データで次の優先順位を更新する

高リスク項目から試し、再開を段階判断する

判断理由の記録、業務完了単位、合格を判断する根拠を使い、再開、追加投資、契約変更を段階化します。作業消化ではなく不確実性の減少を確認します。

判断理由の記録で前提と見直し条件を残す

主要な決定ごとに、論点、選択肢、判断基準、決定、理由、前提、影響、承認者、見直し条件を記録します。単なる議事録ではなく、後から前提の変化と判断理由を追跡できる形式にします。

会議は、情報共有、論点整理、助言、決定に分けます。決定会議には、選択肢、価値・費用・リスクへの影響、推奨案を事前に準備します。決定できない場合は、不足情報、取得方法、担当、期限を決めます。

実現が難しい、失敗時の影響が大きい、前提の確からしさが低い前提を優先します。見栄えのよい画面や簡単な機能から進めると、重大な制約が後半まで残ります。検証は成功を示すためでなく、早く誤りを見つけるために行います。

• 口頭決定を正式なログへ反映する
• 古い前提で作られた決定を定期確認する
• 決定リードタイムを遅れの主因として測る

検収・支払・変更を業務完了単位へ結び付ける

契約上の成果物と、利用者が受け入れられる業務完了単位を対応させます。共同作業が必要なデータ提供、業務判断、環境準備には、発注者・受注者双方の担当と期限を記載します。変更時には範囲、費用、日程、品質、リスクを同じ様式で評価します。

固定価格か準委任かという形式だけでは解決しません。不確実性の高い検証と、条件が明確な実装を分け、段階ごとの判断で次の契約範囲を判断できる構造にします。未達時の是正、知識移転、終了時の成果物・データ引継ぎも定めます。

段階1は継続価値と対象範囲、段階2は構造的リスクと代表シナリオ、段階3は運用準備と段階提供です。各段階で、次の投資額、未解消リスク、決定者、停止条件を示し、単一の完了日だけで全体を管理しません。

• 文書納品だけで検収を完了しない
• 発注者の依存タスクも進捗管理する
• 重大前提が崩れた場合の再協議・終了条件を持つ

資料が整っても立て直っていない兆候を確認する

代表業務が通らない、判断者が不明、失敗が学習へ戻らない、進捗率だけが上がる、責任追及が強まる場合は、管理体制を再設計します。

立て直しを想定と違うことを示す五つの兆候

意思決定リードタイムが短くならない、合格を判断する根拠のない要件が減らない、重大欠陥が後工程へ流出する、リスク検証より機能開発が優先される、契約と段階提供が不整合という状態です。これらを週次で確認し、再計画の精度ではなく学習速度を見ます。

責任追及が強まったら、管理体制を見直す

発注者・受注者が証拠を共有せず、課題を防御材料に使い始めると、悪い情報が遅れて報告されます。判断者は問題の早期発見を評価し、事実・前提・決定を分け、契約上の責任と改善活動を混同しない運営を作ります。

計画より先に、前提を決め直せる状態を作る

立て直しの成果は、予定表の見栄えではありません。価値、証拠、選択肢、停止条件を持ち、経営が損失を制御できることです。

作業量ではなく価値と予測の質を測る

利用者が完了できるシナリオの提供率、目的へ紐づく要件の割合、明確な合格条件を持つ要件の割合、意思決定リードタイム、工程別欠陥流出率、移行照合、運用準備を見ます。重要前提を解消するにつれ、範囲・費用・日程の予測幅が縮むかも確認します。

課題件数を減らすために報告を抑えたり、期限を守るために品質を暗黙に調整したりしてはいけません。課題が早く見つかり、判断までの時間が短くなり、後工程への欠陥流出が減ることを健全化の兆候と捉えます。

DXwheelは、被害拡大の防止と判断資料の保全、短期診断、価値・範囲の再合意、要件再構成、高リスク項目の先行検証、段階計画、管理体制・契約整合、運用準備をつなぎます。

• 業務完了単位の提供と利用結果を追う
• 欠陥を発見工程と混入工程で分類する
• 予測値には前提と確度を添える

DXwheelが支援できる領域

DXwheelは、中立な立場で成果物・課題・実機を確認し、短期間で現状を診断します。関係部門への聞き取りと問題原因の整理を行い、目的、守るべき条件、要件と検証結果の対応関係を明確にします。その上で、短期試作、段階計画、意思決定と契約上の論点を整理します。

支援の目的は元の計画を形式的に守ることではなく、経営が継続・変更・中止を判断できる透明性と、チームが小さな業務完了単位で安全に再始動できる条件を作ることです。

• 証拠ベースの短期診断
• 目的・責任・検証・学習の再設計
• 段階提供に合わせた意思決定と契約の整合