SalesDock ロゴSalesDock
業務改善

要件定義の進め方|工程の前に決定者を決める、発注側の順番と未決項目の扱い

止まるのは工程ではなく、決める人が決まっていない項目

11分で読める

要件定義の進め方の結論|工程を進める前に、項目ごとの決定者を決める

要件定義が止まる場所は、たいてい書き方ではありません。その項目を決める人が社内で決まっていないことが原因です。決定者が決まっていない項目は、ヒアリングを何回重ねても意見が集まるだけで結論になりません。工程の順番を整える前に、どの項目を誰が決めるかを先に埋める。この記事は、その順番と、決められない項目の扱い方を扱います。

  • ヒアリング・整理・文書化・承認という工程を回しても、決定者が決まっていない項目は決まらない。工程より先に決定者の欄を埋める
  • 業務構造の棚卸しは要件を書く前に置く。いまの手順を書き出さないまま要件を書くと、現行の例外処理が要件から落ちて、あとで追加費用の相談になる
  • 決められない項目は空欄のまま出さない。未決と明記して出す/期限を切って保留する/今回の範囲から外す、の3つから扱いを選んで記録に残す

この記事は、システムを入れることは決まっていて、要件定義をこれから始める、あるいは始めたものの前に進まなくなった発注側を想定しています。扱うのは手順と決定体制です。要件定義書のどの欄に何を書くかという書式は、要件定義書のテンプレート(発注側が埋める欄と、埋まらない欄が意味すること)に分けて書いています。書式を先に手に入れても、決める人が決まっていなければ欄は埋まりません。逆に、決める人と順番が決まっていれば、欄は後から選べます。

一般的な要件定義の進め方と、実務で止まる場所

解説記事で紹介される流れは、おおむね共通しています。準備をして、現状を聞き取り、出てきた要求を整理し、要件の形にして、文書にまとめ、関係者の承認を取る。この並び自体に問題はありません。ただ、この並びは「聞けば決まる」ことを前提にしています。実務で止まるのは、聞いても決まらない場所です。

止まり方には型があります。1つ目は、現行業務の例外を誰も説明できない状態です。通常の流れは全員が説明できるのに、条件が変わったときの扱いは担当者の頭の中にしかありません。2つ目は、部署をまたぐ要求が食い違い、どちらを採るかを決める人がいない状態。3つ目は、いったん決めた内容が次の打ち合わせで戻る状態です。

3つとも、工程の順番を入れ替えれば直るものではありません。決定の体制と、決める前の材料の問題です。ここから先は、その2つを工程の前に置く順番で書きます。

手順1:項目ごとの決定者を、工程に入る前に決める

最初に作るのは要件の一覧ではなく、決定者の一覧です。表は5列で足ります。項目を増やすほど埋まらなくなるので、まずここだけにします。

  • 決める項目

    「顧客の名寄せの単位」「承認を何段にするか」のように、決着すれば設計が動く粒度で書く。工程名では書かない

  • 決める人

    1人だけ書く。複数人が並んでいる項目は、その時点でまだ決定者が決まっていない

  • 関係する人

    決定の前に意見を聞く人。決める人と役割を分けて書く

  • 決める期限

    打ち合わせの回数ではなく日付で書く。期限の無い項目は、最後まで残る

  • 決め方

    1人で決める/関係者の合意を取る/上位者へ上げる、のどれかを先に選んでおく

決める人の欄には1人だけ書く

2人以上が並んでいる項目は、まだ決定者が決まっていません。関係者が2人いること自体は普通なので、片方を「決める人」、もう片方を「関係する人」に振り分けます。ここを曖昧にしたまま会議を開くと、両者が意見を言い、どちらの意見も採用されないまま終わります。

「社長が全部決める」で埋めない

中小企業の案件では、決める人の欄をすべて経営者の名前で埋められることがあります。最終的な決裁がそうであっても、項目によっては現場の運用を知っている人しか判断材料を持っていません。全部を1人に寄せると、その人の予定が空くまで全項目が止まります。決裁が要る項目と、担当者が決めてよい項目を分けておくと、並行して進みます。

決める人が空欄の項目は、その時点で未決リストに入れる

空欄のまま工程を進めないことだけを決めておきます。決める人が書けない項目は、内容が難しいのではなく、社内で誰の担当か決まっていないという別の問題です。これは要件の議論では解けないので、要件の会議とは別に片付けます。

手順2:業務構造の棚卸しを、要件を書く前に置く

決定者が決まったら、次は要件ではなく現行業務の書き出しです。順番を逆にすると、要件が「いまの困りごと」の断片から組み上がります。断片から書いた要件は、通常の流れは押さえられていても、例外の扱いが抜けます。

AIを使った開発では、書き出した現在の流れをそのままシステムへ移しません。通常の自動処理、AIが解釈する部分、人が承認する部分へ分け直してから要件にします。全体の進め方はAI駆動開発とは何かで整理しています。

例外が抜けたことは、要件定義の時点では表に出ません。開発が進んだあと、実際の業務を通したときに「この場合が通らない」という形で出てきます。その時点では設計が固まっているので、直すには追加の作業が要り、費用と期日の相談になります。順番を守ることで避けられるのは、この後戻りです。

書き出すのは、業務ごとに次の5つです。

  • その業務が始まるきっかけ(誰からの、どんな連絡や動きで始まるか)
  • 通る人と順番。承認や確認が入る場所
  • 使っている道具。紙、Excel、メール、既存システムのどれで持っているか
  • 完了の判定。何をもって「終わった」と扱っているか
  • 例外のとき、誰が何をしているか。金額が大きい、期日が短い、相手が特殊、といった条件ごとに書く

5つ目が要件定義でいちばん効きます。例外の条件と、そのときの手順を書き出しておくと、「今回のシステムで扱う例外」と「今回は人が対応し続ける例外」を、要件を書く前に線引きできます。書き出し方そのものは業務棚卸しのやり方(AI化・自動化の前にやるべき整理)にまとめています。

既存の会計ソフトや勤怠、取引先から届くファイルとの受け渡しがある場合は、棚卸しの段階で、同じ情報をどこが正として持つかまで決めておくほうが安全です。連携の方式を選ぶ前に決める4項目(正本・共通ID・更新責任・止まったときの手順)は、システム連携とは(つなぐ前に決める4つ)で扱っています。ここが決まっていないまま連携要件を書くと、後から「どちらの数字が正しいのか」という論点が設計をやり直させます。

手順3:聞く場と決める場を分ける

ヒアリングは広く、決定は狭く開きます。同じ会議でこの2つをやると、その場にいる人の声の大きさで結論が決まり、あとで戻ります。戻った論点は、次の会議でもう一度同じ議論になります。

ヒアリングの出力は「要求の一覧」です。ここでは採否を決めません。決定会議の出力は「決定した項目」と「決まらなかった項目」の2つです。決定会議に持ち込むのは、要求そのものではなく、2〜3個の選択肢と、それぞれを選んだときに業務がどう変わるかです。選択肢の形にしないと、会議は要望の言い合いに戻ります。

決定会議に出るのは、その項目の決める人と関係する人だけにします。全員を呼ぶと、自分の担当外の項目で発言が増え、決まる項目の数が減ります。

手順4:決められない項目は、3つのどれかに割り当てる

期限までに決まらない項目は必ず残ります。残ること自体は問題ではなく、扱いを決めずに空欄のまま次へ渡すことが問題です。空欄で渡すと、受け取った側は自分の想定で埋めて見積や設計を作ります。その想定が違っていたとき、差は後から費用や日程の形で出てきます。

  • 未決と明記して出す

    決着していないことと、ベンダー側に前提を置いてもらう範囲を書いて渡す。見積の前提が「仮置き」ではなく「明示された未決」になる

  • 期限を切って保留する

    決める人と日付を入れて、いったん先へ進める。期限が来たら決める会議を開く。期限の無い保留は保留ではなく放置になる

  • 今回の範囲から外す

    今回は作らない、または今回は人が運用で回す、と決めて書き残す。外したこと自体を記録しないと、後から「入っているはずだった」になる

どれを選んでも、記録には同じ4つを残します。項目名、選んだ扱い、そう決めた日、そう決めた人です。この4つが残っていれば、後から「言った・言わない」にならず、期限が来たときに何を再開すればよいかも分かります。記録の置き場所は専用のツールでなくてよく、決定者の一覧に列を足すだけでも足ります。

なお、未決の項目をどの欄にどう書くかという書式の話は、要件定義書のテンプレートの記事の担当です。この記事は、その欄に入れる中身を誰がいつ決めるかまでを扱っています。

進め方が崩れているときの3つの兆候

工程表の上では進んでいるのに、実際には止まっていることがあります。次のどれかが出たら、先へ進めずに決定者の一覧へ戻ります。

  • 同じ論点が3回以上の会議に出てくる。決める人が決まっていないか、選択肢の形になっていない
  • 議事録に「持ち帰り」だけが増える。持ち帰った先で誰が決めるかが書かれていない
  • ベンダーからの質問リストに、答えられない項目が増えていく。棚卸しが足りていない可能性が高い

契約や体制の形は、進め方が決まってから選ぶ

契約の形(請負か準委任か)や、社内にプロジェクト担当を置くかどうかは、早い段階で話題になります。ただ、契約の形が決めるのは責任の分担であって、決められない項目が決まるわけではありません。決める項目と決定者が見えてから選ぶほうが、条件を具体的に書けます。

契約の種類ごとの法的な効果や、どちらが自社に合うかの判断は、案件の条件によって変わります。この記事では扱いません。契約書の文面と、弁護士など専門家への確認で判断してください。

費用の内訳や見積の読み方で迷う場合はシステム見積もりのセカンドオピニオン(見積書で確認する観点)、作り方をゼロから作るか既存製品に寄せるかで迷う場合はスクラッチ開発の判断基準が使えます。どちらも、要件が固まりきる前でも読める内容です。

効果は、未決項目の数と決定までの日数で測る

効果を開発の成否で測ると、判定が出るのは数ヶ月先になります。手元の一覧から数えられる項目で見ます。開始した週に1回数えて、以降は2週間ごとに同じ数え方をします。

  • 決める人の欄が埋まっている項目の割合
  • 未決として残っている項目の数
  • 未決が決定に変わるまでにかかった日数
  • 期限を過ぎたまま残っている未決の数

未決の数がゼロになる必要はありません。見るのは、減っているか、期限内に決まっているかの2点です。期限切れの未決だけが増えている場合は、決める人の割り当てか、選択肢の作り方のどちらかに原因があります。

来週の一歩:決定者の欄を1枚作る

要件の一覧には手を付けません。いま止まっているところから逆にたどって、決める人の欄だけを作ります。

  1. いま進んでいる案件で、ベンダーから聞かれて答えられていない質問を全部書き出す
  2. 書き出した質問を、決着すれば設計が動く単位の「決める項目」に言い換える
  3. 項目ごとに、決める人を1人だけ書く。書けない項目には印を付ける
  4. 印の付いた項目について、誰なら決められるかを社内で先に決める
  5. 決める人が入った項目に、日付の期限と決め方を足す

1枚できると、止まっている原因が「情報が足りない」なのか「決める人が決まっていない」なのかが分かれます。分かれた時点で、次に開く会議の相手が変わります。

決める項目をどの粒度で立てればよいか迷う場合は、架空の条件で入力・確認・人の判断を組み立てる設計演習の資料が練習に使えます。導入の実績を集めたものではなく、決める項目を自分で洗い出す手順をなぞるための教材です。読めば成果が出るという性質のものではありませんが、欄に何を並べるかの見当は付きます。進め方そのものを相談したい場合は、オンライン相談で作りかけの1枚を持ち寄る形も取れます。製品の選定を代行するものではなく、決める順番を一緒に決める場です。

よくある質問

要件定義は発注側とベンダーのどちらが進めるものですか?

進行役と決定者を分けて考えると整理できます。会議を設計して議事と決定事項を残す進行役は、ベンダーや外部の支援者に頼めます。一方で、業務をどう変えるか、どの要望を今回は見送るかを決めるのは発注側です。ここを外に預けると、決まっていない項目が誰にも決められないまま工程だけが進みます。文書の書式そのものについては別記事で扱っています。

要件定義にはどれくらいの期間をかけるべきですか?

一律の目安は出せません。期間を左右するのは工程の数ではなく、決める項目の数と、決定者が社内で決まっているかどうかだからです。決定者の欄が全部埋まっていて、部署をまたぐ論点が少なければ短く終わります。逆に、決定者が空欄の項目が残っていると、打ち合わせを何回積んでも同じ論点が戻ってきます。期間を見積もる前に、決める項目を数えるほうが早く見当がつきます。

決められない項目は、どう扱えばよいですか?

空欄のまま渡さないことだけを守り、扱いを3つから選びます。未決と明記して出す、期限を切って保留する、今回の範囲から外す、の3つです。どれを選んだか、誰がいつそう決めたかを記録に残します。空欄と「決めないと決めた」は、書類の上では似て見えますが、後から確認したときの意味がまったく違います。

要件定義書のテンプレートはどこで手に入りますか?

書式については、この記事とは別に、公的な無料テンプレートを起点に機能要件と非機能要件の欄を解説した記事があります。この記事が扱うのは、その欄を埋める前の段階、つまり誰とどの順で決めるかという手順と体制です。書式を先に手に入れても、決定者が決まっていなければ欄は埋まりません。

現場からの要望が多すぎて絞れません。

要望を「今の業務が回っていない」「回ってはいるが手間がかかる」「あると良い」の3つに分けてから決定会議へ出します。決定会議で扱うのは1つ目だけにして、2つ目と3つ目は一覧に残したまま今回の範囲から外すかどうかを判断します。全部を同じ会議で比べようとすると、声の大きさで順番が決まり、後から覆ります。

泉 款太(いずみ かんた)

株式会社SalesDock 代表取締役

慶應義塾大学法学部卒。スタートアップ、ラクスル、リクルート(SUUMO)を経て2025年に独立。 中小企業の経営・営業・業務・データをつなぐ事業基盤の設計と実装を支援。 不動産・製造業・クリニックを中心に、累計40社以上の支援に携わる。

運営は株式会社SalesDock(大阪市中央区本町)。中小企業向けに、AI内製化(初期構築15万円+月額10万円・90日)と、 そのあとのAI顧問(月額5万円・6ヶ月契約から)を提供しています。価格は税別です。 大阪・関西を中心に、オンラインで全国からのご相談に対応しています。

代表者情報を読む →

この記事の数値について

本文中に一次資料へのリンクがある数値は、リンク先を出典としています。 リンクのない業務設計、判断基準、実務上の目安は、SalesDockが累計40社以上の支援と自社運用で得た知見を一般化したものです。 個別企業での成果を保証する数値ではなく、条件によって変わります。