要件定義のやり方。経営者は「作らない機能」を決める

要件定義の初回会議で、開発会社から機能の希望を聞かれます。営業部門は顧客管理を求め、管理部門は請求処理を加え、経営者は「専門家に任せます」と答えます。会議は進んでいるように見えますが、事業上の優先順位は決まっていません。

要件定義のやり方で最初に決めるのは、画面の数ではありません。経営者が決めるべき内容は、解決する業務、使える予算、守る期限、見送る範囲です。開発会社へ任せるのは、経営上の条件を画面、データ、運用へ翻訳する仕事です。

経営者が全会議へ出席し、ボタンの位置まで指示する必要はありません。一方で、何を作らないかまで開発会社へ預けると、売上計画や顧客との約束を知らない人が事業の優先順位を選ぶ形になります。

要件定義のやり方は、作らない範囲から決めます

要件定義を機能の希望集めから始めると、要望は増え続けます。各部門には必要な理由があり、開発会社も受け取った希望を勝手には削れません。最後に予算か公開日が合わなくなり、重要な機能まで急いで削る事態になります。

僕は、最初に「今回変える業務」と「今回変えない業務」を対にして書きます。たとえば、問い合わせの受付から担当者の割り当てまでは対象にしますが、請求書の発行は既存サービスへ残す、と線を引きます。対象外にした理由も、将来対応、既存手段で継続、効果が未確認という言葉で残します。

作らない範囲は、開発費を抑えるためだけに決める項目ではありません。利用者が覚える操作、社内で更新するデータ、障害時に戻す業務も減らせます。機能を一つ加えるたびに、公開後の担当者と運用方法まで必要になります。

経営者は、機能名より先に事業上の到達点を示します。「顧客管理を便利にする」では判断できません。「問い合わせを受けた担当者が、過去の対応記録を同じ画面で確認してから返答できる」のように、誰の行動がどこまで変わるかを書きます。

到達点を測る資料も指定します。実際の問い合わせ記録、手作業で転記している表、処理待ちを確認する画面など、社内に存在する資料を要件定義の場へ出します。測定できる数字がまだない場合は、開発前に記録を始める担当者と確認日を決めます。

予算と期限が衝突した際の優先順位も経営判断です。公開日を守って範囲を狭めるのか、必要な業務を守って日程を動かすのかを、開発会社は代わりに選べません。経営者が判断基準を先に渡せば、開発会社は実行可能な案へ分けられます。

最初の成果物は、分厚い仕様書でなくても構いません。対象の利用者、変える業務の開始と終了、対象外、予算の上限、動かせない日付、最終承認者を一枚に置きます。経営者は一枚の内容を承認し、個々の画面設計は次の作業へ渡します。

発注側が決め、開発会社へ任せる範囲

要件定義で発注側が持つ仕事は、現場の事実と事業の制約を渡すことです。現行業務を知る担当者を会議へ出し、実際の帳票、入力データ、例外対応、顧客との取り決めを見せます。経営者は部門間で希望が割れた際に、採用する案を決めます。

開発会社には、業務を実現する技術案を作ってもらいます。画面の流れ、保存するデータ、外部サービスとの接続、利用者ごとのアクセス範囲、障害時の復旧方法を設計し、複数案の費用と日程への影響を説明してもらいます。

技術案を任せる行為と、承認まで預ける行為は別です。開発会社が提案した案に対し、発注側は顧客への影響、社内の運用負荷、予算、公開日を見て採否を決めます。技術的な危険を評価できる人が社内にいない場合は、開発会社とは別の技術責任者に設計案を読んでもらいます。

役割分担が曖昧になる原因は、担当者の能力だけではありません。要件定義が見積もりに含まれているか、社内資料を誰が開示できるか、追加費用を誰が承認するか、質問へ何日で答えるかが決まっていない案件は、優秀な担当者を集めても止まります。

開発会社を選ぶ前なら、RFPで発注側の条件と提案範囲を分ける方法を使えます。すでに発注先が決まっている場合も、RFPと提案書を要件定義の机へ戻し、提案時の前提が仕様書と見積書のどこへ入ったかを照合します。

要件が固まっていない段階で実装一式の固定見積もりを求めると、候補会社は多くの仮定を置きます。現行業務の調査、利用者への聞き取り、試作画面の確認までを先に契約し、調査結果から実装範囲を見積もる方法もあります。調査の成果物と実装契約を分ければ、分からない範囲を無理に確定した扱いにせずに済みます。

忙しい経営者向けの要件定義のやり方

経営者がすべての業務聞き取りへ参加すると、日程が合わず、現場も経営者の答えを待つようになります。経営者の参加場面を、開始時、重要な選択肢が出た時、最終範囲を確定する時に絞ります。作業会議は事業責任者と現場担当者へ任せます。

開始時には、事業上の到達点、対象外、予算、期限、優先順位を承認します。議題は機能一覧ではなく、どの業務を変え、どの状態になれば投資を続けるかです。営業資料や取締役会資料に書かれた約束と食い違う場合も、最初の場で直します。

重要な選択肢が出た時は、文章だけでなく動く試作画面と実際に近いサンプルデータを見ます。開発会社には、推奨案、見送る案、費用と日程への影響を一枚で示してもらいます。経営者は設計を自分で作らず、事業上受け入れられる案を選びます。

最終範囲を確定する時は、対象機能だけを読みません。対象外、見積もりの前提、未決事項、受入条件、公開後に社内へ残る作業まで確認します。空欄が残る項目には、調査する人と回答期限を置きます。

経営者へ上げる依頼は、「どうしましょう」だけでは足りません。選択肢、推奨理由、顧客への影響、追加費用、公開日への影響、回答期限を同じページへ載せます。経営者が必要な材料を一度で読めれば、会議への常時参加を減らせます。

採用した案は、日付、承認者、理由と一緒に判断記録へ残します。見送った案と再検討する条件も書きます。担当者が交代した後も、過去の案を同じ理由で議論し直さずに済みます。

事業責任者が作業会議を進めても、技術案を評価する人がいない場合があります。外部の技術責任者やCTO代行は、経営者の代わりに事業目標を決める役ではありません。開発会社の説明を費用、日程、運用上の危険へ翻訳し、経営者が選べる案に整える役です。

進捗管理を外へ出すだけでは技術案の評価まで埋まりません。技術顧問とCTO代行の役割分担も確認し、会議を進める人、設計案を評価する人、技術判断を実行する人、予算を承認する人を分けてください。肩書きが一人に集まる場合も、依頼書には各作業を書き分けます。

要件定義の完了条件を決め、判断記録を始めます

仕様書のページ数では、要件定義の完了を判定できません。各要件について、利用者、操作する場面、必要なデータ、期待する結果、確認する人が書かれているかを見ます。開発会社と発注側が同じ手順で完成を確かめられれば、実装へ進めます。

「検索できる」「安全に使える」「速く表示される」という表現だけでは受入条件になりません。誰がどの画面を開き、どのデータを入力し、何が表示されたら合格かを文章にします。応答時間や保存期間が重要なら、自社の利用人数、業務上待てる時間、必要な保管期間から条件を決めます。

正常な操作だけでなく、入力間違い、外部サービスの停止、権限のない利用者による操作も確認します。エラーが出るかだけではなく、誰へ通知し、どの業務手順へ戻るかまで決めます。公開後の問い合わせ先と修正を依頼する窓口も要件へ含めます。

未決事項が残っていても、要件定義を終えられる場合はあります。未決の理由、確認方法、担当者、期限、費用や公開日へ影響する条件が見えていれば、調査項目として管理できます。「開発会社へ一任」という記載は、選択基準と承認者がないため未決事項のままです。

開発手法によって、要件を決める時期は変わります。アジャイルとウォーターフォールを発注者の責任で選ぶ方法で説明したように、アジャイルでは開発中も優先順位を選び続けます。ウォーターフォールでは着手前の要件と受入条件へ多くの時間を使います。

どちらの進め方でも、変更の受付場所と承認方法は必要です。変更依頼を課題管理ツールへ残し、費用、日程、既存機能への影響を確認してから承認します。口頭の依頼を仕様書へ戻さない運用では、最終確認の時点で見積書との対応が切れます。

実装契約へ進む前に、要件一覧、対象外一覧、判断記録、受入条件、見積書を横に並べます。各文書の範囲が一致し、未決事項の扱いまで説明できたら、要件定義を終える判断ができます。

明日は、直近の業務手順、実際に使う帳票や画面、顧客から届いた問い合わせ、開発会社の見積書を開いてください。業務の開始地点と終了地点を一行で書き、今回変える範囲と残す範囲を分けます。

次に、未決の論点を一つ選びます。選択肢、推奨案、採用しなかった案、費用と公開日への影響、承認者、回答期限を一枚へ記録します。開発会社へは、次回会議から同じ形式で選択肢を出してもらいます。

経営者が見るべき場所は、仕様書の全ページではありません。事業の到達点、見送る機能、予算と期限が動く条件、完成を認める基準です。四つの内容を経営者が選び、技術案への翻訳を担当者へ任せれば、忙しくても要件定義を丸投げせずに進められます。

対象外を決められない、最終承認者が空欄、受入条件を実際の画面で説明できない場合は、実装契約を急がないでください。現行業務の調査と試作を先に発注し、一枚の判断記録を埋めてから開発範囲を確定します。