システム開発の流れ。発注者は各工程で何を決めるのか

システム開発の工程表には、要件定義、設計、開発、テストと専門用語が並びます。初めて外注する経営者には、開発会社が順番に作業し、完成時だけ確認すればよい計画にも見えます。

システム開発の流れで発注者が担う仕事は、最後の確認だけではありません。発注前に投資目的を決め、提案時に比較条件をそろえ、要件定義で作る範囲を選び、受入時に合否を判定し、本番移行時に業務を切り替えます。開発会社へ技術作業を任せても、事業上の判断は各工程に残ります。

僕は、発注者が全工程の技術を理解する必要はないと考えています。一方で、誰が何を決めたら次へ進めるのかは、契約前に理解しておくべきです。工程名ではなく、発注者の決定を軸に開発全体を見ていきます。

システム開発の流れは、六つの決定をつなぐ仕事です

発注前には、解決したい業務と投資できる条件を決めます。提案・見積もりでは、候補会社を比べる基準と発注範囲を決めます。要件定義では、作る機能と見送る機能を決めます。設計・開発では、技術案が事業条件に合うかを承認し、変更時に動かす範囲、費用、期限を選びます。

受入・検収では、納品されたシステムが合意した条件を満たすか判定します。本番移行・運用では、利用を始める日、旧業務を止める条件、公開後の担当を決めます。各工程には、開発会社が作る成果物と、発注者が出す判断の両方があります。

大切なのは、工程を会議の日程として扱わないことです。要件定義会議が終わっても、対象外の業務や最終承認者が決まっていなければ、設計へ渡せる条件はそろっていません。設計書を受け取っても、運用方法と受入条件を発注側が承認していなければ、実装後の合否を決められません。

各工程の終点は、資料を受け取った日ではなく、次の工程で使う判断が記録された日です。発注側と開発会社が同じ終点を見ていれば、進捗率だけでは見えない未決事項も早く見つけられます。

発注前と提案・見積もりでは、目的と比較条件を決めます

発注前に経営者が決める内容は、欲しい画面ではありません。どの業務を変えたいのか、誰の行動を変えたいのか、変化を何の資料で確かめるのかを決めます。現行業務の開始と終了、利用者、困っている場面、動かせない期限、予算の上限も社内で確認します。

社内の責任者も発注前に置きます。現場の業務を説明する人、部門間の希望を調整する人、予算変更を承認する人、最終的に受け入れる人が必要です。一人が複数の役割を持っても構いませんが、開発会社から届いた質問が社内で止まらない経路を作ります。

候補会社へ相談する段階では、各社へ同じ背景と条件を渡します。完成仕様を発注側だけで書き切る必要はありません。発注側が固定する条件と、候補会社に提案してほしい範囲を分けます。提案依頼の具体的な作り方は、RFPで発注条件と評価基準をそろえる方法で詳しく説明しています。

提案・見積もりで決めるのは、最も安い会社ではなく、どの前提で誰へ任せるかです。要件定義、画面設計、データ移行、受入支援、本番公開、公開後の保守が見積もりへ含まれるかを確認します。対象外の作業は社内で担うのか、別料金で頼むのかまで決めます。

見積金額に差がある場合は、金額だけをそろえようとしません。対象範囲、未確認事項、成果物、担当者の役割、仕様変更時の扱いを同じ列で比べます。候補会社が置いた仮定を読まずに総額だけで選ぶと、発注後に必要な作業が追加費用として現れます。

発注を決める前に、選んだ提案の理由を社内で説明できるか確認します。予算内だから、という理由だけでは足りません。業務の理解、進め方、リスクの説明、運用後の支援まで含め、会社として受け入れた条件を提案書と契約書へ残します。

要件定義から開発までは、作る範囲と変更の扱いを決めます

要件定義では、各部門の希望を集めるだけでは足りません。発注者は、今回変える業務と残す業務を分け、予算と期限が衝突した際の優先順位を決めます。経営者がボタンの位置やデータ構造まで設計する必要はありませんが、どの利用者のどの業務を完成させるかは開発会社へ預けられません。

要件定義の成果物には、対象範囲だけでなく、対象外、未決事項、受入条件、公開後に発注側へ残る作業も入れます。作らない範囲の決め方や経営者が参加する場面は、経営者向けの要件定義の進め方にまとめています。

設計では、開発会社が画面の流れ、保存するデータ、外部サービスとの接続、権限、障害時の復旧方法を技術案へ落とします。発注側は、顧客への影響、現場の運用、予算、公開日から案を承認します。技術用語が分からない場合は、推奨案だけでなく、見送った案、費用と日程の差、運用上の負担を説明してもらいます。

開発が始まった後も、発注者の判断は続きます。動く画面を見た現場から追加要望が出たら、開発会社に影響を確認してもらい、追加するのか、別の機能を外すのか、公開後へ送るのかを選びます。依頼した瞬間に実装へ入らず、費用、期限、受入条件への差分を記録してから承認します。

進捗会議では、作業の完了数だけを聞きません。発注側の回答を待っている質問、前提が変わった設計、次に確認できる画面を見ます。判断が必要な議題には、選択肢、推奨理由、影響、回答期限を付けてもらいます。経営者は開発会議へ常時参加しなくても、経営判断が必要な場面で材料を受け取れます。

受入・検収では合否、本番移行では開始条件を決めます

受入確認は、開発が終わってから初めて考える作業ではありません。要件定義の段階で、誰が、どの画面で、どのデータを使い、どの結果なら合格かを書きます。確認に使う社員の時間、サンプルデータ、外部サービスの接続環境も工程表へ入れます。

開発会社のテストと発注側の受入確認は役割が異なります。開発会社は設計どおりに動くかを確かめ、発注側は合意した業務を実行できるかを確かめます。正常な操作だけでなく、入力間違い、権限の違い、外部連携の失敗時に業務へ戻れるかも確認します。

不一致が見つかった場合は、感想ではなく、確認した版、操作、入力値、期待した結果、実際の結果、仕様書の箇所を記録します。合意した仕様との不一致なのか、文書へ書かれていない認識差なのか、新しい改善要望なのかを分けます。検収の詳しい進め方は、システム開発の検収で合否を記録する方法を参照してください。

本番移行で経営者が決めるのは、公開ボタンを押す時刻だけではありません。移すデータの範囲、旧システムへの入力を止める時点、利用者への案内、操作教育、問い合わせ窓口を確定します。移行に失敗した場合に旧業務へ戻す条件と、戻す判断を出す人も必要です。

開発完了と業務開始は分けて判定します。システムが完成していても、利用者のアカウント、データ移行、操作手順、障害時の連絡先がそろっていなければ、事業として利用を始める準備は終わっていません。本番移行の責任者が、各準備の結果を見て開始か延期かを判断します。

運用が始まったら、問い合わせ、不具合、改善要望を同じ窓口へ集めます。障害対応の連絡先、保守契約に含む作業、追加開発として見積もる作業、社内で更新するデータを分けます。開発会社へ任せる範囲と社内に残る仕事を曖昧にすると、公開直後から小さな依頼が止まらなくなります。

工程をまたぐ未決事項には、責任者と期限を置きます

システム開発では、最初から全項目へ答えを出せるとは限りません。現行データを調べなければ移行方法を決められない場合や、試作画面を利用者へ見せなければ操作方法を選べない場合があります。未決事項が存在する事実より、誰がいつ調べ、結果によって何が変わるか分からない状態が危険です。

僕なら、工程表と別に判断記録を一枚持ちます。議題、選択肢、決定した内容、決めた人、決定日、見送った案、再検討する条件を文章で残します。未決の議題には、調査する人、回答期限、費用や公開日への影響を付けます。

判断記録は、開発会社を管理するためだけの資料ではありません。発注側の担当者が替わった際に、過去の前提を復元する資料になります。提案時の約束が要件定義へ入り、要件定義の受入条件が検収表へ入り、検収結果が運用課題へ渡ったかを同じ記録から追えます。

技術案を評価できる人が社内にいない場合は、開発会社とは別の技術責任者へ判断材料を読んでもらう方法もあります。外部の責任者は経営判断を代わりに決める人ではありません。技術案を費用、期限、運用上の影響へ翻訳し、経営と技術をつなぐ役を担います。

発注者が技術用語を覚えるより、決裁に必要な説明形式を決めるほうが先です。開発会社へ「推奨案と理由」「費用への影響」「公開日への影響」「運用開始後の仕事」「回答期限」を同じ形式で出してもらえば、経営者は選択へ集中できます。

最初の発注会議までに、一枚へ六つの決定欄を作ります

明日は一枚の文書を開き、発注前、提案・見積もり、要件定義、設計・開発、受入・検収、本番移行・運用という六つの見出しを書いてください。各見出しの下へ、発注側が決める内容、決める人、判断に使う資料、決定期限を文章で入れます。

空欄が見つかったら、開発会社の名前で埋めないでください。業務範囲を決める人がいなければ事業責任者を置き、技術案を評価できなければ評価役を探し、受入担当者が決まっていなければ現場の時間を確保します。発注前の空欄は、契約後には承認待ちとして現れます。

候補会社との初回会議では、一枚を画面に出し、各工程で何を提出してもらい、発注側が何を承認したら次へ進むのかを聞きます。回答は提案書と工程表へ反映してもらいます。工程名が並んでいても、成果物、承認者、完了条件が書かれていなければ、流れはまだ合意できていません。

システム開発の流れを理解する目的は、経営者が開発会社の仕事まで引き取ることではありません。経営者は投資目的、優先順位、受入基準、業務開始を決めます。開発会社は決まった条件を技術案と動くシステムへ変えます。両者の判断が工程ごとにつながった時、外注でも発注者が主導して開発を進められます。