要件定義のコンサルとは｜頼める範囲と、依頼前に自社で決めておくこと

システムを作る話が出たとき、「要件定義はどこまで自分たちでやるのか」「コンサルに頼むと何が変わるのか」で止まる会社は少なくありません。社内に開発の担当者がいない中小企業では、特に判断しにくい部分です。

この記事では、要件定義のコンサルが担当する範囲、開発会社の要件定義との違い、依頼前に自社で決めておくこと、AIにアプリを作らせる場合の考え方を説明します。

要件定義のコンサルと、開発会社の要件定義の違い

開発会社の要件定義は、作るものを仕様として確定する作業で、コンサルは、そもそも何を作るべきかを業務の側から決める作業です。開発会社は「作る」ことが商売なので、頼まれた範囲を仕様に落とすのは得意です。一方で、頼む側の業務が整理されていないと、聞いたとおりに作って、使われないものができることがあります。コンサルは、この「頼む前の整理」を発注側に立って担当します。

要件定義は、頼む側の業務を一番知っている発注側が決める部分を持つ工程です。書く欄と考え方は要件定義書のテンプレートで、進める順番は要件定義の進め方で整理しています。

要件定義のコンサルに頼める範囲と、頼めない範囲

頼める範囲は、業務の棚卸し、目的と範囲の線引き、使う人とデータの整理、開発会社の見積もりの読み解きです。最終判断と、プログラムの実装・保守は含まれないことが多いため、契約の前に確かめます。契約の前に、どこまでが成果物かを確かめます。

見積もりを受け取っている段階なら、要件の漏れや前提の食い違いを第三者の目で確かめる使い方もあります。見方はシステム開発の見積もりのセカンドオピニオンにまとめています。

最初に確かめるのは「何を、誰に見せるために作るか」

要件が絞れない原因の多くは、機能の数ではなく、目的が確認されていないことです。たとえば買取再販の会社で、賃料査定の自動化を検討したときは、査定の精度をどこまで上げるかの話が長引きました。「この査定、お客様に見せますか」と聞くと、見せない（社内の判断にだけ使う）という答えで、顧客向けの精度までは要らないと分かり、要件が絞れました。

このように、要件定義の最初の仕事は、機能を並べることでなく、成果物の使い道を確かめることです。コンサルに頼む価値は、こうした確認を、業務を知らない第三者として遠慮なく聞ける点にあります。

依頼する前に、自社で決めておくこと

依頼前に自社で書いておくとよいのは、目的・使う人・決める人・予算と期限の上限の4つです。この4つが書けているだけで、コンサルや開発会社との最初の打ち合わせが、説明から相談に変わります。書けない項目は、そのまま「未決」として、決める人と期限を残して出して構いません。

いまの業務を書き出す作業が重いときは、業務の棚卸しのやり方から始めると、目的と使う人を書きやすくなります。

AIにアプリを作らせる場合も、先に決めることは同じ

AIにコードを書かせるなら要件定義は要らない、と考える人もいます。実際には逆で、AIはコードを書く速度が上がる分、決めないまま進んだときに、間違った方向へ速く進みます。動くものはできても、直すほど別の所が壊れる「修正の沼」にはまる原因は、コードの質より、決めていないことにあります。

AIに書かせる前に決めておくのは、次の3点です。

• 誰が使うか：入力する人、確認する人、承認する人を分けます。
• 何を使うか：パソコンかスマホか、いつ入力するか、Excelなど既存の道具をどうするかを決めます。
• どのデータとつながるか：顧客・物件・案件のような箱と、箱どうしの関係（ER図）を決めます。

AIを使った進め方の具体的な手順とプロンプトは要件定義をAIで進める方法に、箱と線の図の作り方はER図をAIで作成する方法に書いています。決めずに始めたときの失敗はバイブコーディングのデメリットと失敗例にまとめています。

コンサルを選ぶときに確認すること

要件定義のコンサルを選ぶときは、次の4点を契約前に確かめます。どれも、見積もりや打ち合わせで質問すれば答えが返ってくる項目です。

• 成果物は何か：業務フロー図、要件メモ、要件定義書のうち、何が納品されるかを確かめます。
• 実装を含むかどうか：含まれる場合は、要件定義を担当した会社が作る会社でもあるため、要件が自社の作りやすい形に寄っていないかを見ます。
• 決める人を誰にするか：コンサルが判断材料を出し、決めるのは自社だと明記されているか確かめます。
• 画面や絵を見せる時期：要件を文章だけで詰める進め方か、動かない画面の絵を早めに見せる進め方かで、認識のずれが見つかる時期が変わります。

要件定義のコンサルの費用は、見積もりの4項目で比べる

要件定義のコンサルの費用は、契約の形（月額・期間・成果物の数）と整理する範囲で変わります。公的な統計や公式の料金表で根拠を示せる金額幅が見つからなかったため、この記事では金額の目安を載せていません。複数社の見積もりは、成果物の種類、打ち合わせの回数、修正に対応する範囲、実装を含むかどうかの4項目をそろえて比べます。コンサル全般の費用の見方はDXコンサルの費用相場が参考になります。

進め方の例｜要件を詰める前に、動かない絵を出す

SalesDockでは、要件の確認を文章だけで重ねず、早い段階で絵を見せて確かめる進め方を取っています。実際の場面を3つ挙げます。

• 不動産会社の案件管理で、カンバン型の画面のデモを見せたところ、画面への要望が先に出そうになりました。そこで先に社内の登場人物と業務フローを整理し、そのうえで優先順位を決めることで合意しました（進行中の案件です）。
• 仕入れ業務のシステム化の相談では、その場で見積もりを出しませんでした。代わりに、作りきらない「動かない構想の絵」を2週間で出すと約束しました。
• 中小企業向けの支援では、ヒアリングを1回に絞り、2回目の打ち合わせの代わりにデモを見せています。

要件定義では、画面や絵を先に見せてから要望を聞くと、言葉だけでは出てこない食い違いが早く見つかります。上の3つはその考え方に沿った例です。実際のSalesDockの支援の様子は事例001もご覧ください。

効果は、手戻りの回数と未決項目の数で測る

要件定義のコンサルを使った効果は、次の2つを記録すると数字で分かります。

• 作り始めたあとに、要件の変更で直した回数と、その理由：「使う人が増えた」「データが足りなかった」のように理由別に数えます。
• 未決項目の数：要件メモの「未決」の件数を、作り始める前と、最初の画面ができたあとで比べます。

最初の画面ができたあとも未決項目が減らないときは、作る前に決めきれていない合図です。作り進めず、決める人と期限を確かめ直します。

まとめ｜頼む前に4つを書き、決める人は自社に置く

要件定義のコンサルは、作る前に「何を作るか」を発注側の立場で決める支援で、最終判断は自社が持ちます。SalesDockは、コードの前に業務の構造を文章にする進め方で、中小企業の経営管理基盤の実装と定着を月額で支援しており、実装まで含めて受ける形が中心です。実装を含む場合は、上で挙げた「要件が作りやすい形に寄っていないか」という注意を自社にも当てはめ、決める人は自社に置いて、判断材料と選択肢を文章で渡します。要件定義だけの依頼は、相談の場で範囲を確かめます。まずは、作りたいものを1つ選び、目的・使う人・決める人・予算の上限を数行で書いてみてください。

要件定義のコンサルに関するよくある質問