株式会社リソース・シェアリング スポンサードサーチ
AIがコードを書く時代だからこそ、「何を作るか」が経営者の仕事になる、では要求定義の「何を作るか」「なぜそれが必要か」「解決した先にどんな状態を目指すか」を言語化する、ということは経営者の仕事であり、AIがどれだけ進化してもそれは変わらない、という話をしました。
本記事では、要求定義の次のステップである「要件定義」の本質と、IT導入を誰に依頼すべきか、SIer・ITコンサル・システム会社の選び方について解説します。
ここでも核心的な主張は同じです。
AIが「実装」を担う時代になったからこそ、要件定義における人間の判断は以前よりも重要になっている。
なぜそう言えるのか。順を追って説明していきます。
「要件定義」とは何か、改めて経営者向けに整理する
前編で紹介した通り、要求定義と要件定義には明確な順番があります。
- 要求定義：「何を・なぜ・どんな状態に」を言語化する（経営者が主役）
- 要件定義：それを実現するために「システムが何をすべきか」を仕様として整理する（エンジニア・専門家が主役）
要件定義のフェーズでは、要求定義で定めたゴールを、実際に開発・導入できる仕様に落とし込んでいきます。
たとえば、要求定義で「受注処理の工数を月40時間から月10時間に削減したい」というゴールを設定したとします。
要件定義では、これを達成するためには以下の項目を具体的に決めていきます。
- どんな画面が必要か
- どのデータを自動連携するか
- どんな通知機能が必要か
- 既存のシステムとどうつなぐか
この段階で必要なのは、技術的な専門知識です。経営者が細部の仕様を決める必要はありません。
しかし、「技術的に可能か」の判断を専門家に任せながら、「これはやる・これはやらない」という優先度の意思決定は、経営者が担い続ける必要があります。
ここを外部任せにした瞬間、プロジェクトは迷走します。
AIが要件定義を変えた、でも「選ぶ責任」は変わらない
AIの登場によって、要件定義の「作業」は大きく変わりました。
以前であれば、要件定義書を作成するだけで数週間を要していました。仕様を言語化し、ドキュメントにまとめ、関係者に確認し、修正する、この繰り返しに膨大な時間がかかっていました。
AIを使う事で、この作業は劇的に効率化できます。
AIが得意な要件定義の作業
- 要件の抜け漏れの検出：「このパターンが考慮されていない」という指摘
- 影響分析：「AをBに変えると、Cに影響が出る」という分析
- ドキュメント生成：ヒアリング内容をもとにした仕様書の自動生成
- 選択肢の列挙：「この要件を満たす実装方法は3パターンある」という提示
これらの作業をAIが担うことで、要件定義の速度と精度は大幅に上がります。
しかし、AIにはできないことがあります。
AIにできない要件定義の判断
- 「Aパターン、Bパターン、Cパターンのうち、御社にはどれが合うか」の決定
- 「この機能は今回やらない」という意思決定とその責任の引き受け
- 対立する意見を持つステークホルダー間の調整と合意形成
- 「技術的には可能だが、現場に定着するかどうか」という現実的な判断
これらは、AIが「計算」できるものではありません。不確実性を引き受け、腹を括って決める——それは人間の仕事です。
そして、AIが要件定義の「作業」を速くするほど、この「判断」の質がプロジェクトの結果を左右するようになります。
速くなった分だけ、方向が正しければ早く成果が出る。方向が間違っていれば、早く失敗する。
AIが進化するほど、要件定義における人間の判断の価値は上がります。
要件定義の本質は「合意形成」である
要件定義でよくある誤解があります。
「要件定義は、機能の一覧を作ることだ」
確かに、機能一覧は要件定義の成果物のひとつです。しかし、それは要件定義の「手段」であって、「本質」ではありません。
要件定義の本質は、合意形成です。
「このシステムを使って、誰が・何を・どう実現するか」について、関わるすべての人が同じ絵を描いている状態を作ること、それが要件定義の最大の目的です。
この合意形成には、3つのレベルがあります。
レベル1：表面的合意
「ステークホルダーの皆さんに説明して、OKが出ました」
会議に参加して、資料を見て、「わかりました」と言った。しかし、本当に内容を理解しているかどうかはわかりません。特に反対意見は出なかった。
このレベルの合意は、後で必ず問題になります。「こんなはずじゃなかった」「聞いていない」という声は、多くの場合ここから生まれます。
レベル2：理解の合意
「ステークホルダーの皆さんが内容を理解した事を確認した上で、OKが出ました」
資料の内容を理解し、自分に関係することを把握した上での合意はしました。しかし、「変化を受け入れる」ところまで至っていない場合があります。
レベル3：コミットメントの合意
「ステークホルダーの皆さんが今後どう変化するのかを受け入れた上で、OKが出ました」
コミットメントの合意が取れた状態とは、このシステムが入ることで、自分の仕事のやり方が変わることを理解し、その変化に前向きに取り組む意思がある状態です。
IT導入で現場の定着がうまくいくケースは、多くの場合、レベル3まで合意が取れています。逆に、稼働後に現場が旧来のやり方に戻ってしまうケースは、レベル1の表面的合意しか取れていなかったことがほとんどです。
要件定義の段階でレベル3の合意を取ることは、容易ではありません。しかし、そこを目指す意識があるかどうかが、IT投資の成否を大きく左右します。
「全部やる」という罠
要件定義の現場で最もよく見られる失敗のひとつが、「全部やる」という選択です。
IT導入プロジェクトが進むと、様々な立場から要望が積み上がります。
経営者は「あれもできるとよい」と言い、現場担当者は「この業務も自動化したい」と言い、営業部門は「顧客データも一元管理したい」と言います。
すべての要望は、それぞれの立場から見れば正当です。しかし、すべてを要件に盛り込もうとすると、プロジェクトは破綻します。
- スコープが広がりすぎて、開発費用が予算を超過する
- 開発期間が延び、リリースが遅れる
- 機能が多すぎて、現場が使いこなせない
- 優先度が曖昧なまま進み、何のためのシステムかわからなくなる
この「全部やる病」が生まれる背景は、前編でも触れたとおりです。責任回避、思考停止、合意回避のいずれかが根本にあります。
解決策は、「優先順位を決める」ことです。
要件定義でよく使われるフレームワークに、MoSCoW分析があります。
| 分類 | 意味 | 考え方 |
|---|---|---|
| Must（必須） | なければシステムが成立しない要件 | 「これがないと導入しない」 |
| Should（重要） | できれば入れたい重要な要件 | 「できれば今回入れたい」 |
| Could（あれば良い） | 余裕があれば対応する要件 | 「次のフェーズでも良い」 |
| Won’t（今回は見送り） | 今回は対象外にする要件 | 「明示的にやらないと決める」 |
この分類で重要なのは、最後の「Won’t（今回は見送り）」です。
やらないことを明示的に決めるのは、単なる削減ではありません。このプロジェクトで何を達成するかのフォーカスを守るための、積極的な意思決定です。
経営者が、「今回はこれだけに集中する」、と宣言し、「Won’t」のリストに明確に合意できたプロジェクトは、成功する確率が高くなります。
SIer・ITコンサル・システム会社：あなたはどこに頼むべきか
要求定義と要件定義について理解できたところで、次の問いが生まれます。
「では、誰に依頼すればいいのか」
SIerとはそもそも何をする会社なのか、なぜAIが普及してもSIerが不要にならないのか、その背景については「なぜITに詳しくない人ほど「AIでSIerは不要になった」と思ってしまうのか？」で詳しく解説しました。
ここでは、発注者の立場から、今の自分の状況でどこに依頼すべきかという判断軸を整理します。
IT導入の依頼先には、大きく3種類あります。
SIer（システムインテグレーター）
大規模・複雑なシステムの設計から開発・運用まで一貫して対応できます。
要件がある程度固まった状態からの参画が多く、自社にIT部門がある企業の大規模プロジェクトに向いています。提案がシステム導入前提になりやすい点や、自社の得意技術に誘導されるケースには注意が必要です。
ITコンサルティング会社
特定のシステムやベンダーに縛られない独立した立場から、要求定義の整理、ベンダー選定、プロジェクト全体の管理を支援します。
何を作るかがまだ決まっていない段階から関われるのが強みです。コンサルティングだけを行って開発実装は行わない会社や、弊社のように、開発・運用まで一気通貫で行うITコンサルティング会社もあります。
システム会社（受託開発会社）
要件定義が固まった状態を受け取り、設計・開発・実装を担う専門集団。SIerより小回りが利き、要件が明確であれば効率的に動きます。
言われたものを作るスタイルの会社では、要求定義が曖昧なまま依頼すると業務に合わないシステムができやすい点は注意が必要です。
この3社それぞれは、全ての会社にとって万能のものはなく、自社のIT導入がどの段階にあるかによって、最適な依頼先は変わります。
| 段階 | 状況 | 最適な依頼先 |
|---|---|---|
| 課題整理段階 | 「何をしたいか」が曖昧。IT投資の方向性が決まっていない | ITコンサル |
| 要求定義段階 | 課題はわかっている。「どう解決するか」の整理が必要 | ITコンサル |
| 要件定義段階 | ゴールが決まっている。システムの仕様を固めたい | ITコンサル + システム会社 or SIer |
| 開発・実装段階 | 要件が固まっている。システムを作りたい | システム会社 or SIer |
| 運用・改善段階 | 稼働済み。定着支援と継続改善が必要 | ITコンサル + システム会社 |
特に注意していただきたいのは、「開発が得意な会社」に「何を作るか」の整理まで任せてしまうことです。
開発会社は、作ることの専門家です。
「何を作るべきか」の整理は本来、別のスキルセットを要します。
依頼する際には、この会社は要求定義の段階から支援してくれるのか、それとも要件が決まってから動く会社なのか、を事前に確認することが重要です。
依頼先を選ぶ際の5つのチェックポイント
ITコンサルティング会社であれ、SIer・システム会社であれ、依頼先を選ぶ際に確認しておきたいポイントをまとめます。
1. 「なぜ」から考えてくれるか
提案の冒頭から、「このシステムを導入しましょう」と言う会社は注意が必要です。
まず、「今の課題は何か」「ゴールは何か」から入ってくれる会社を選びましょう。課題の整理より先にシステムの提案が来る場合、自社の都合でシステムを売ろうとしている可能性があります。
2. 「やらないこと」を一緒に考えてくれるか
良いパートナーは、「全部やりましょう」とは言いません。
「今回はここに集中しましょう」「これは次のフェーズでいいでしょう」という判断を一緒にしてくれる会社が信頼できます。要件を増やすことで売上が上がるビジネスモデルの会社は、スコープを広げる方向に動きやすい傾向があります。
3. 費用・リスク・選択肢を透明に開示してくれるか
「この方法しかありません」ではなく「A・B・Cという選択肢があり、それぞれのメリット・デメリットはこうです」と複数の選択肢を提示してくれる。
費用についても、なぜその金額になるかを説明してくれる、そういった透明性のある会社は、長期的なパートナーになれます。
4. 導入後の支援まで考えてくれるか
システムは導入してからが本番です。
稼働後の現場定着支援、運用上の課題への対応、継続的な改善、これらを視野に入れた提案をしてくれるかどうかが重要です。「納品したら終わり」のスタンスの会社とは、長期的な関係を築くのは難しいです。
5. 自社の文化・規模・リテラシーを理解しようとしているか
大企業向けの提案をそのまま持ってくる会社は合いません。
「今の御社のIT体制で、どこから始めるか」という、現実的な視点を持ってくれているかどうかを確認してください。
要件定義で経営者が担うべき具体的な役割
「要件定義はエンジニアに任せればいい」という発想は、前編の要求定義と同様に危険です。
もちろん、詳細な技術仕様を経営者が決める必要はありません。しかし、以下の場面では経営者が積極的に関与すべきです。
優先度の最終決定
「Must / Should / Could / Won’t」の分類について、最終的な判断は経営者が行うべきです。
担当者レベルでは「全部Mustにしたい」という圧力が働きやすく、経営判断として「今回はここまで」という線を引くことが必要です。
ステークホルダー間の調整
部門をまたいだ要件の調整が必要になるとき、現場担当者レベルでは解決できないことがあります。
営業部門の要望と製造部門の要望が対立する場合、どちらを優先するかは経営的な判断が必要です。
スコープ変更の承認
プロジェクトが進む中で「やっぱりあの機能も欲しい」という追加要望が出てきたとき、それを許可するか・しないかの判断は経営者が行わなければなりません。
安易に追加を認めると、スコープが膨らみプロジェクトが迷走します。
ゴールとのズレの確認
要件定義が進むにつれ、当初のゴールから少しずつズレていくことがあります。
定期的に「この要件は、最初に設定したゴールに本当に貢献するか」を確認する役割を経営者が担ってください。
AI時代における人間の仕事
ここまで、要求定義と要件定義の2つの記事にわたって、IT導入における経営者の役割について考えてきました。
最後に、改めてお伝えしたいことがあります。
AIがコードを書き、AIが設計を支援し、AIが仕様書を生成する時代になっても、変わらないことがあります。
「これでいく」と明確に判断をし、その判断に責任を持つこと
不確実な状況の中で、完全な情報が揃わない中で、それでも方向を決め、変化を受け入れ、うまくいかなければ別の手を打つ、これは計算ではなく、決断です。
AIは計算できますが、決断はできません。
要求定義で、何を解決したいかを言語化する、要件定義で、どこまでやるか・何をやらないかを決める、現場と「変化を受け入れる」レベルの合意を取る、そして、導入後も「成果が出ているか」を測り続ける。
これらすべてに、人間の判断と責任が伴います。
AI時代のIT投資で求められる経営者の役割は、「ITのプロジェクトを人に任せる」ことではなく、「ITを使って何を実現するかを、自分の言葉で決め続けること」です。
弊社はその「決め続ける」プロセスに、伴走します。
まとめ
後編で整理した内容をまとめます。
- 要件定義の本質は合意形成：機能一覧を作ることではなく、関わる全員が同じ絵を描いている状態を作ること
- AIは要件定義の「作業」を助けるが、「判断」はできない：腹を括ることは人間の仕事
- 「全部やる」は失敗のパターン：MoSCoW分析で優先順位を明確にし、「やらないこと」を決める勇気が必要
- SIer・ITコンサル・システム会社はそれぞれ異なる：自社の段階と目的で依頼先を選ぶ
- 経営者は要件定義の「決断」に関わり続ける：技術仕様は任せてよいが、優先度・スコープ・合意形成は経営の仕事
2つの記事を通じてお伝えしたかったのは、要求定義も要件定義も、「経営者が主役でなければならないプロセスである」ということです。
専門家をパートナーとして活用しながら、「何を・なぜ・どこまで」という判断を手放さないこと。それがAI時代のIT投資で成果を出すための、最も重要な姿勢です。
弊社では、要求定義から要件定義の支援、そして適切な依頼先の選定まで、伴走型のITコンサルティングサービスを提供しています。
「IT導入を検討し始めた」「どこに頼めばいいかわからない」という段階からでも、お気軽にご相談ください。
御社のゴールへの到達を、誠実にバックアップします。
よくあるご質問
依頼する事は可能ですが、注意が必要です。
SIerやシステム会社は「作ること」の専門家であり、「何を作るか」の整理は得意でないケースが多いです。要求定義や要件定義を曖昧なまま開発に進めた場合の手戻りコストは、ITコンサルの費用をはるかに上回ることがほとんどです。
また、弊社では初期段階のご相談は無料で対応していますので、まずはお気軽にご相談ください。
プロジェクトの規模によりますが、1〜3ヶ月程度が目安です。
「早く開発に入りたい」という気持ちから要件定義を急ぐと、後で大きな手戻りが発生します。要件定義に時間をかけることは、トータルの期間を短くすることにつながります。
省略はできません。
AIは要件定義の「作業」を効率化しますが、「判断」は人間が行う必要があります。むしろAIによって開発速度が上がるほど、要件定義の精度がプロジェクトの成否を左右します。AIを活用した要件定義の効率化は大いに推奨しますが、省略は本末転倒です。
要件定義の成果物（要件定義書）をもとに、複数のシステム会社から見積もりを取ることをお勧めします。
弊社では、RFP（提案依頼書）の作成支援やシステム会社の選定支援も行っています。「どこに依頼するか」の判断まで、一緒に考えます。
はい、プロジェクト途中からのご支援も対応しています。
現在の要件定義の状況を確認し、ゴールとのズレや抜け漏れを整理するところから始めます。開発が始まる前に問題を発見できれば、後の手戻りを大幅に防ぐことができます。
ITを使った経営課題の解決でお困りではありませんか？
DXを始めとするITを使った経営課題の解決が上手くいっていない企業は数多くあります。
それは、単なるソリューションの導入や、社内人材への丸投げとなっており、課題解決がゴールになっていないからです。
そのためには、経営とITを理解した人材が、経営者層と共に取り組み、経営者の頭の中を可視化することが必須要件です。
現在、1時間の無料オンライン・コンサルティングを実施しております。
是非この機会にご相談ください。
構築予算が10分の1に
経営課題を解決するECサイト、越境ECサイト、BtoB ECサイト、マーケットプレイスを構築するならCS-Cartをご検討ください。
スポンサードサーチ