要件定義書なしで進めた受発注システム刷新を、中間レビューから立て直した事例
システムを作り終える前の中間レビューで、業務部門が初めて画面を触った。出てきた指摘は87件。うち14件はデータ構造から作り直しが必要だった。原因は、要件定義書を作らず、口頭ヒアリングだけで設計に進んだことだった。この事例では、そこから品質を優先して立て直した過程を、数字とあわせて追う。
■ 会社と案件の前提
項目 | 内容 |
|---|---|
委託元（架空） | みなと食品流通株式会社（食品卸売、従業員約800名、拠点12か所） |
委託先（架空） | 中規模SIベンダー B社 |
案件 | 20年使った受発注・在庫システムの刷新 |
期間 | 2025年4月〜2026年3月の12か月（要件定義2か月、設計3か月、開発4か月、テスト3か月） |
予算 | 1億8,000万円 |
委託元体制 | 情報システム部2名＋業務部門の兼任担当4名 |
委託先体制 | PM1名、SE5名、PG12名 |
業務フローを書ける人 | 両社とも0名 |
■ 要件定義フェーズ：何が省かれたか
情報システム部は2名だけ。業務部門の担当者は通常業務との兼任だった。B社の要員も開発経験者ばかりで、業務分析の経験者はいなかった。
両社は「現行システムと同じ業務なので、ヒアリングで足りる」と判断した。システム要件定義書は作らず、ヒアリング10回分の議事録（箇条書き）だけで設計に進んだ。
本来つくるもの | この案件での状態 |
|---|---|
業務フロー図 | なし |
業務ルール一覧 | なし（議事録に散在） |
例外処理一覧 | なし |
拠点ごとの差異一覧 | なし |
システム要件定義書 | なし |
要件の完了条件（誰が何に合意すれば確定か） | なし |
ヒアリング議事録 | 10回分、箇条書き |
■ 設計・開発フェーズ：推測で埋めた設計
B社SEは議事録と現行画面のスクリーンショットから、足りない業務を推測で補って設計した。
設計書は画面項目とテーブル定義が中心で、業務部門には読み解けなかった。回付に対する回答は「特に意見なし」。形だけの承認になった。
例外処理や拠点ごとのローカルルールは、ヒアリングで一度も話題に出なかった。
■ 2025年10月（7か月目）：中間レビューで何が起きたか
開発済みの画面を、業務部門に初めて操作してもらった。代表的な指摘は次のとおり。
No | 指摘 | なぜ漏れたか | 影響 |
|---|---|---|---|
1 | 冷凍品の「分納出荷」ができない | 分納の話が出ず、1受注＝1出荷で設計した | データ構造 |
2 | 大口顧客の期間限定「特別単価」を登録できない | 価格マスタを顧客×商品で1価格として設計した | データ構造 |
3 | 北海道・九州の拠点は締め日が違う | 全社共通の締め日と思い込んだ | ロジック |
4 | 返品時に在庫の戻し先（良品／廃棄）を選べない | 現行では担当者がExcelで管理しており、誰も説明しなかった | データ構造 |
5 | 承認ルートが金額で変わる | 「課長承認」とだけ聞いていた | ロジック |
影響の区分 | 件数 |
|---|---|
データ構造に影響（テーブル設計からやり直し） | 14件 |
ロジック変更 | 31件 |
画面修正 | 42件 |
合計 | 87件 |
手戻りは約40人月と見積もられ、2026年3月の本番稼働は3か月遅れる見通しになった。経営層から「なぜ今まで分からなかったのか」と追及があり、両社の間で責任の押し付け合いが始まりかけた。
■ 原因を調べた：87件を1件ずつ仕分けた
原因 | 件数 | 割合 |
|---|---|---|
ヒアリングで出なかった例外処理 | 29件 | 33% |
現行システムの外にある業務（Excel・紙） | 18件 | 21% |
拠点ごとの差異 | 16件 | 18% |
設計側の推測誤り | 15件 | 17% |
用語の解釈違い（「出荷日」「締め」など） | 9件 | 10% |
上の3つ、合計63件（72%）は、業務フローと例外処理を文書にしていれば設計前に見つかったものだった。問題は開発力ではなく、「伝えたつもり」「分かったつもり」を確かめる仕組みがどこにもなかったことにある。
■ 立て直し：5つのステップ
ステップ | 時期 | やったこと |
|---|---|---|
1. 危機対応 | 10月中旬〜下旬（2週間） | 両社役員を入れたステアリングコミッティを臨時開催し、責任追及は後回しにして「稼働品質を最優先する」と合意した。データ構造に影響する領域の開発は止め、マスタ保守など影響の小さい機能だけ継続した |
2. 業務の再可視化 | 11月（4週間） | 外部の業務アナリスト2名を短期契約で投入（費用は両社折半）。ヒアリングではなく、3拠点で現場に入って業務を観察した。現場のExcel・紙帳票・手書きメモも全部集めた |
3. 要件定義書の遡及作成 | 12月上旬 | 業務フロー・業務ルール・例外処理・拠点差異を要件定義書にまとめ、業務部門の責任者が署名で承認した |
4. 検証の仕組み | 12月〜3月 | 動く画面での確認、業務シナリオでの机上検証、2週間ごとのデモ、変更管理委員会を導入した |
5. 再ベースライン | 12月 | 稼働を段階展開に変更。第1期（本社＋3拠点）2026年6月、第2期（残り9拠点）8月 |
■ 見える化で出てきたもの
成果物 | 件数 |
|---|---|
業務フロー（スイムレーン形式）：主要業務 | 23本 |
業務フロー：例外フロー | 41本 |
業務ルール | 212件 |
拠点ごとの差異 | 38件 |
要件ID（要件→設計→テストケースで追跡） | 486件 |
例外フローが主要業務の約2倍あった。口頭ヒアリングで出てくるのは主に「いつもの流れ」で、例外は現場を見ないと出てこない。
■ 確認の仕方を変えた
以前 | 変更後 |
|---|---|
テーブル定義・画面項目一覧の設計書を回付 | 動く画面や紙芝居で業務部門が操作して確認 |
中間レビューで初めて見せる | 2週間ごとに開発中の機能をデモ |
「特に意見なし」で承認 | 「月末に分納＋返品が発生したら」など業務シナリオで机上検証 |
追加要望はその場で受ける | 変更管理委員会が影響度を評価してから承認 |
初回のデモでは23件のズレが出たが、7回目には1件まで減った。ズレを「設計の終わった後」ではなく「作っている最中」に見つけられるようになった。
■ 結果（QCD）
観点 | 合格ライン | 実績 | 判定 |
|---|---|---|---|
Q（品質） | 受入テストの重大障害 25件以下（当初想定） | 10件（想定比60%減） | 達成 |
Q（品質） | 稼働後3か月の業務停止 0件 | 0件 | 達成 |
C（コスト） | 追加費用 3,500万円以内（承認枠） | 3,200万円（予算比＋17.8%） | 達成 |
D（納期） | 再計画の第1期 2026年6月、第2期 8月 | 計画どおり稼働 | 達成 |
追加費用の内訳 | 金額 |
|---|---|
業務アナリスト2名×3か月 | 600万円 |
手戻り開発（約40人月） | 2,400万円 |
テスト期間の延長 | 200万円 |
合計 | 3,200万円 |
費用は契約条件にもとづき、要件定義の責任分担に応じて両社で負担した。作成した業務フローと要件定義書は、稼働後もみなと食品流通の業務マニュアル兼、次期改善の基礎資料として使われている。
■ 振り返りと、自分の現場で使うなら
要件定義書は「省略できる書類」ではなく「合意の証拠」。口頭ヒアリングだけでは、双方の理解が一致しているか確かめる手段がない。
業務フローを書ける人は、最初に確保すべきクリティカルリソース。社内にいなければ外部から調達する。今回600万円で済んだ費用は、手戻り2,400万円より小さい。
「現行と同じ」は最も危険な要件。漏れの2割は現行システムの外（Excel・紙・担当者の頭の中）にあった。
業務部門が読める形でレビューする。テーブル定義ではなく、画面・シナリオ・フロー図で確認してもらう。
早く、小さく、何度も見せる。中間レビューで初めて見せるのでは遅い。
問題が見つかったら、責任追及より品質回復の合意を先に取る。押し付け合いが始まると、事実の共有が止まる。
■ 研修・ディスカッション用の設問
Q1. 要件定義フェーズのどの時点・どの判断を変えていれば、今回の事態を防げたか。
Q2. 業務フローを書ける人がいない状況で、PMとして取れる選択肢を3つ挙げよ。
Q3. 中間レビュー直後の1週間で、PMが最優先でやるべきことは何か。
Q4. 追加費用の負担について、委託元・委託先それぞれの立場から論点を整理せよ。
※掲載している会社名・業界設定・数値などは、説明のために設定した架空のものです。実在の企業・団体・個人とは関係ありません。