「要件定義ができない」の原因は7つに分かれる——型別の打ち手と、要件が固まらないまま発注する方法【2026年版】

「要件定義ができない」——システム開発の担当になった方から、こうしたご相談をよく受けます。開発会社との打ち合わせは3回、4回と重ねているのに、要件定義書のドラフトが埋まらない。社内に聞けば聞くほど話が増え、決まるどころか論点が増えていく。期限だけが近づいてくる、という状態です。

まず申し上げておきたいのは、これは担当者の能力の問題ではないということです。要件定義は、現状の業務を理解する思考と、それを抽象化する思考と、システムとして実装できる形に落とす思考を、同時に行き来する作業です。しかも発注側の担当者にとっては、一生に1〜2回しか経験しない業務でもあります。難しくて当たり前の仕事だ、というのが実情です。

そのうえで大事なのは、「できない」をひとつの症状として扱わないことです。当社が2018年からホーチミンで日系企業の開発体制を支援してきたなかで見てきた限り、要件定義が止まる原因は7つの型に分かれます。現行業務を誰も説明できない、決裁者が出てこない、関係部署の要望が矛盾する、何を作りたいか自体が決まっていない、ベンダーの質問に答えられない、時間が取れない、そもそも社内にIT担当がいない——この7つです。型が違えば打ち手も違います。

そしてもうひとつ。「要件定義ができないから発注できない」というのは、多くの場合は思い込みです。IPA(独立行政法人情報処理推進機構)が公開している「超上流から攻めるIT化の原理原則17ヶ条」は、要件定義を発注者の責任としながら、同時に「多段階の見積もりは双方のリスクを低減する」として多段階契約の活用を挙げています。全部を決めてから一括で発注する以外の道は、公的なガイドにも書かれています。

この記事では、要件定義が止まる7つの型と型ごとの打ち手、要件定義を外部に手伝ってもらうときの契約と費用の考え方、そして要件が固まりきらないまま進める3つの方法を整理します。筆者は人材業界出身で、2018年からベトナム・ホーチミンに拠点を置き、日系企業約100社の開発体制と採用を支援してきました。要件定義書が整った状態で相談に来られる企業は、実際にはごく一部です。

「要件定義ができない」の正体——止まっているのは文書ではなく決定です

要件定義ができないという相談を受けたとき、当社がまず確認するのは「何が書けていないか」ではなく「どの決定が、誰の手元で止まっているか」です。埋まらないのは文書ですが、止まっているのは決定だからです。ここを取り違えると、テンプレートを探したりAIに草案を書かせたりといった作業に時間を使い、肝心の決定は止まったままになります。

要件定義が難しいのは担当者の能力の問題ではない——3つの思考を往復する業務だから

要件定義では、3種類の思考を同時に行き来することが求められます。ひとつめは現状の業務を正確に理解する思考、ふたつめはそれを個別の事情から切り離して抽象化する思考、みっつめは抽象化したものをシステムとして実装できる形に落とす思考です。この3つは使う言葉も粒度も違い、会議の途中で何度も切り替わります。

しかも、業務を最もよく知っている現場の担当者ほど、この会議についていけなくなります。業務の言語とシステムの言語が混ざった抽象度の高い会話になるからです。加えて、システムの刷新は7年から14年に1度といった頻度でしか起きません。発注側の担当者にとって、要件定義は一生に1〜2回しか経験しない業務です。経験で上達する機会が構造的に与えられていない仕事だ、というのが実情です。

当社は2018年からホーチミンで日系企業約100社の開発体制と採用を支援してきましたが、初回のご相談の時点で要件定義書が整っていた企業は、ごく一部です。多くは「作りたい方向は決まっているが、機能に落とせない」状態から始まります。ですから、要件定義ができないこと自体は珍しい状況ではありません。

止まり方は7つの型に分かれる

「できない」をひとつの症状として扱うと、打ち手が決まりません。当社が見てきた範囲では、止まり方は次の7つの型に分かれます。自社の症状に近いものを1つか2つ選んでください。

型1から型4は社内で決定が止まっている型、型5から型7は決定を外部とやり取りする経路が詰まっている型です。前者は開発会社を変えても解決しません。後者は体制と運用の設計で解けます。以降の章で、それぞれの打ち手を順に見ていきます。

それでも要件を決める責任は発注者側にある——IPAの一次情報で確認する

ここで押さえておきたいのが、要件を決める責任の所在です。IPA(独立行政法人情報処理推進機構)が2019年9月12日に公開した「ユーザのための要件定義ガイド 第2版——要件定義を成功に導く128の勘どころ」は、「システムの要件を定義する責任は、構築されたシステムを利用してビジネスに貢献する役目を負うユーザにある」としています。同じ資料は、ITベンダやシステム部門が中心になって要件定義を進めるスタイルから、業務部門のユーザが主体的に関与するスタイルへ変える必要性が増していると述べています(2026年9月16日に公開ページを確認)。

IPA-SECの「超上流から攻めるIT化の原理原則17ヶ条」も、第9条で「要件定義は発注者の責任である」と明記しています。ただし同じ第9条の行動規範には、受注者側の項目として「発注者側に立った支援を提供する」が並んでいます。責任は発注者にあるが、支援を受けること自体は否定されていない——これがこの記事の前提です。

要件定義そのものの手順・文書の書き方は既存記事に譲る

要件定義という工程の位置づけや、要件定義書に何を書くかは、本記事では扱いません。工程の地図と成果物は「要件定義とは」の記事、手順と役割分担は「要件定義の進め方」の記事、文書の章立てと記載例は「要件定義書の書き方」の記事、公開されている実物は「要件定義書 サンプル」の記事、生成AIの使いどころは「要件定義 AI」の記事で整理しています。本記事は、それらを読んでもなお止まっている状態を動かすことに絞ります。

まず、自社がどの型かを決めてください。型が決まれば、次にやることは1つか2つに絞れます。

社内で止まっている4つの型と打ち手——現行業務・決裁者・部署間の矛盾・作りたいものが未定

型1から型4は、決定が社内で止まっている型です。この4つは、開発会社を変えても、要件定義書のテンプレートを変えても解決しません。IPAの原理原則17ヶ条は第4条「ステークホルダ(利害関係者)間の合意を得ないまま、次工程に入らない」の行動規範として、受注者側に「合意確認の作業支援はできるが請負(責任)はできないことを明示する」を挙げています。社内合意は、外部に移せない仕事だということです。以下、型ごとに最初にやることを書きます。

型1: 現行業務を誰も説明できない——例外を全部そろえない。主要な1本だけ確定させる

最も多いのがこの型です。現行の業務フローを書こうとすると、「担当ごとにやり方が違う」「あの取引先だけは特別」という話が次々に出てきて、まとまらない。現行システムを作った担当者はすでに退職していて、仕様書も残っていない。私自身、ベトナムの大手IT企業でERPのプライム案件を上流から担当していたときに、この状態から始まる案件を何度も見ました。

ここでやりがちな失敗は、例外を全部そろえようとすることです。例外は集めれば集めるほど増えます。やるべきことは逆で、最も件数の多い1本の流れ(メインフロー)だけを、先に確定させることです。手順は次のとおりです。

1. 直近3か月の取引データを件数順に並べ、上位2割の取引がどう流れているかだけを追う
2. その1本を、担当者1名に実際の画面と帳票を見せてもらいながら、開始から終了まで通しで書く
3. 書いたものを別の担当者1名に見せ、「この通りか」ではなく「どこが違うか」を聞く
4. 出てきた違いは、フローに描き込まず、別表に「例外候補」として番号付きで積む
5. 例外候補は、件数と、システム化しなかったときの手作業の量を書いて、後で判断する材料にする

この進め方なら、1週間から2週間で「主要な1本」は形になります。例外の扱いは要件定義の後半、あるいは運用でカバーする判断に回せます。

もうひとつ注意したいのが、「今と同じものを作ってください」で済ませることです。17ヶ条は第14条で「『今と同じ』という要件定義はありえない」とし、行動規範に「既存機能だけを見て要件とするのではなく、使われ方まで十分調査し、要件とする」を挙げています。現行システムの画面を並べただけの資料は、要件定義書にはなりません。使われ方まで踏み込むから、上の手順2で「実際の画面と帳票を見せてもらう」ことが効きます。

型2: 決裁者が出てこない——「決める人」を1名決める稟議を先に通す

「これ、誰が決めるんでしたっけ」という言葉が会議で出るようになったら、この型です。社長は「現場で決めていい」と言い、部門長は「経理が決めるべき」と言い、経理は「営業のやり方に合わせる」と言う。全員が「決めるのは自分ではない」と考えていて、要件定義書の承認だけが何か月も動かない。当社にご相談いただいたケースでも、この状態で3か月動かなかった例があります(具体的な社名・内容は公開可否を確認のうえで扱っています)。

打ち手は、要件定義を進めることではなく、決める人を1名決める稟議を先に通すことです。要件定義の議論を止めてでも、これを先にやったほうが早く終わります。稟議に書く内容は3行で足ります。

• このプロジェクトの意思決定者は誰か(1名。合議体にしない)
• その人が決める範囲はどこまでか(予算・スコープ・納期のどれを動かせるか)
• その人が決められない事項は誰に上げるか(上位者を1名だけ指定する)

17ヶ条の第2条は「取り決めは合意と承認によって成り立つ」とし、行動規範に「合意プロセスと承認ルールを明確にし、それに基づいて行動する」を置いています。承認ルールが決まっていないプロジェクトは、要件定義の手前で止まります。

型3: 関係部署の要望が矛盾する——機能の数ではなく「誰の工数を減らすか」に論点を戻す

営業は入力項目を減らしたい、経理は増やしたい。現場は自由入力にしたい、管理部門は選択式にしたい。この型では、機能の仕様そのものを議論すると決着しません。両方の言い分が、それぞれの部署の中では正しいからです。

当社が実際に決着させた方法は、論点を戻すことでした。議論するのは機能の数ではなく、「このシステムで誰の工数を何時間減らすのか」です。入力項目を1つ増やすと営業1人あたり月に何分増えるのか、その項目がないと経理は月に何時間の照合作業が発生するのか。両方を分単位で出すと、議論は感情から数字に移ります。多くの場合、片方の負担が桁違いに大きく、そこで決着します。

それでも決まらない場合は、型2に戻ってください。部署間で決着しない論点は、その上位の決裁者が決めるべき論点です。関係者全員が納得する案を探し続けるのは、失敗のもとです。17ヶ条の第4条にあるとおり、ステークホルダの合意確認を自らの仕事と心得るのは発注者側の行動規範です。

型4: 何を作りたいか自体が決まっていない——要求を出す段階と要件に絞る段階を分ける

「やりたいことは色々あるが、機能に落ちない」型です。この型の特徴は、会議のたびに新しいアイデアが出て、前回決めたことが上書きされることです。

原因は、要求を出す作業と、要件に絞る作業を同じ会議でやっていることにあります。17ヶ条は第16条で「機能要求は膨張する。コスト、納期が抑制する」とし、行動規範に「要求を抽出する段階と、要件として絞り込む段階を分ける」「必要最低限のシステム構築からスタートする」「要件の優先順位付けをする」を挙げています。会議を2種類に分けてください。

絞り込み会議では、要求を「必須」「あとで」「やらない」の3つに分けます。2段階(必須/それ以外)では、判断を先送りした項目が全部「それ以外」に溜まって機能しません。「あとで」に入れた項目は、いつ判断するかの時期まで書いてください。

なお、要求と要件という言葉の使い分けそのものは、「要求定義と要件定義の違い」の記事で整理しています。

この4つの型に共通するのは、決める人と決める範囲を狭めたことです。全員で全部を決めようとしている限り、要件定義は終わりません。

開発会社との間で止まっている3つの型と打ち手——質問に答えられない・時間が取れない・IT担当がいない

型5から型7は、社内の決定そのものではなく、決定を外部とやり取りする経路が詰まっている型です。この3つは体制と運用の設計で解けます。逆に言えば、放置しても自然には解けません。打ち合わせの回数を増やしても、同じ質問が繰り返されるだけです。

型5: ベンダーの質問に答えられない——質問を「事実」と「決定」に仕分ける

開発会社から100項目の質問票が送られてきて、手が止まる。このパターンは非常に多く見られます。原因は質問票の中身ではなく、性質の違う質問が同じリストに混ざっていることにあります。

質問は2種類あります。ひとつは「事実を答えるもの」で、現在の取引先数、月間の伝票枚数、使っている会計ソフトの名前などです。これは調べれば答えが出るので、担当者が1人で片づけられます。もうひとつは「決定を求めるもの」で、承認は何段階にするか、過去データを何年分移行するか、スマートフォン対応を含めるかなどです。これは会議にかけないと答えが出ません。

当社では、質問票が届いたら次の運用に変えていただくことをお勧めしています。

1. 質問票に「事実」「決定」の列を1つ足し、全項目を仕分ける(担当者1人で30分から1時間)
2. 「事実」は担当者が調べて先に返す。ここだけで半分以上が埋まることが多い
3. 「決定」だけを抜き出し、決裁者が出る会議に一括でかける。1問ずつメールで往復しない
4. 「決定」のうち、いま決めなくても開発を始められるものは、開発会社に「いつまでに決めればよいか」を聞いて期限を書き込む

手順4が効きます。質問票の項目には、要件定義の段階で決めないと設計が進まないものと、設計の後半まで待てるものが混ざっています。開発会社に期限を聞けば、いま決めるべき項目は3割程度まで減ることがあります。

答えられない質問が残った場合は、「わからない」と正直に返してください。空欄のまま返さず、「現時点で決められない。判断材料として何が必要か教えてほしい」と書き添えると、開発会社側は提案の形で選択肢を出せます。17ヶ条の第2条には、受注者側の行動規範として「良否判断を仰ぎやすい提案を心がける」が挙げられています。判断を仰ぐ形にしてもらうのは、発注側から要求してよいことです。

型6: 時間が取れない——要件定義に必要な時間を稼働として見積もっていない

「本業が忙しくて、打ち合わせが月に1回しか取れない」という型です。この型は、本人の努力不足ではなく、要件定義に必要な時間が誰の工数にも計上されていないことが原因です。

要件定義の期間中、発注側の担当者に必要な時間は、打ち合わせそのものよりも、その前後の作業に多くかかります。社内ヒアリング、資料の準備、質問票への回答、議事録の確認、社内への説明。当社が見てきた中規模の案件では、発注側の主担当で週に8時間から16時間程度、繁忙期はそれ以上になることもあります。月1回の打ち合わせだけで進めようとすれば、要件定義に半年かかる計算になります。

打ち手は3つです。

• 工数として申請する。 「要件定義期間の3か月間、週2日はプロジェクト業務に充てる」と書いて上長の承認を取る。承認が取れないなら、そのプロジェクトは社内で優先されていないということで、それ自体が重要な情報です
• 打ち合わせの頻度を上げて1回を短くする。 月1回2時間より、週1回45分のほうが進みます。決められない論点が1週間以内に見つかるためです
• 主担当を2名にする。 1名が休んだり異動したりすると止まる体制は、要件定義の期間中はとくに危険です

期限だけが先に決まっていて稼働が確保できない場合は、その時点で開発会社に伝えてください。工程の前提が変わるため、後から伝えると手戻りになります。17ヶ条の第3条は「プロジェクトの正否を左右する要件確定の先送りは厳禁である」とし、「未確定要件の先送りは厳禁であり、現工程を延ばしてでも確定させる」を行動規範に置いています。スケジュールを守るために要件を曖昧なまま次工程へ送ると、後工程でより大きく遅れます。

型7: 社内にIT担当がいない——非IT部門でも決められることと、決められないこと

情報システム部門がなく、総務や経理の担当者が兼任でシステム導入を進めている。あるいは専任担当が1名いるが、社内PCとネットワークの保守で手一杯。中小企業では珍しくない状況です。

この型で大事なのは、決められないことと、決められることを分けることです。次の表のとおり、要件定義で決めるべきことの多くは、IT知識ではなく業務知識で決まります。

IT知識が必要な行は、開発会社に「選択肢を2つか3つ出して、それぞれの費用と制約を書いてください」と依頼すれば、発注側は選ぶだけで済みます。逆に、IT知識が不要な行を開発会社に決めさせると、あとで「想定と違う」となります。これが丸投げの実態です。渡してよい作業と社内に残す判断の線引きは、「システム開発 外注 丸投げ」の記事で詳しく整理しています。

そのうえで、社内に窓口役が1名もいないと、どの体制を組んでも回りません。兼任で構わないので、開発会社からの連絡を受けて社内に振る役を1名決めてください。当社の場合は、この負担を軽くするために日本人PMをフロントに置く体制を推奨しています。仕様のヒアリングと文書化を開発側で巻き取れるためです。

ここまでの7つの型を自社で動かせないときは、手を借りる段階です。次の章で、外部に何をどこまで頼めるかを整理します。

要件定義を外部に手伝ってもらう——要件定義支援・上流だけの準委任と費用の考え方

要件定義の支援は、普通に買えるサービスです。開発を発注する前に、要件定義だけを別契約で依頼することもできます。にもかかわらず、この選択肢を知らずに何か月も止まっている企業は少なくありません。ここでは、誰に頼めるのか、契約はどうなるのか、費用はどう見るのかを順に整理します。

誰に頼めるのか——開発会社・ITコンサル・PMO人材・公的支援の4つ

依頼先は大きく4つに分かれます。得意な領域が違うため、自社が止まっている型に合わせて選んでください。

どこに頼む場合でも、確認すべきことは同じです。誰が担当するのか(会社ではなく人の経歴)、成果物は何か(要件定義書なのか、議事録と論点整理なのか)、期間はどのくらいか、そして社内のどの会議に出てもらえるのか。会社の選び方そのものは「システム開発会社 選び方」の記事で整理しています。

契約は準委任になる——IPAのモデル契約が示す上流工程の考え方

上流工程を外部に頼むとき、契約は準委任になるのが一般的です。理由は単純で、要件定義は「決まった成果物を完成させる」ことを約束できない工程だからです。何が要件になるかは、やってみないと決まりません。

IPAが2020年12月22日に公開した「情報システム・モデル取引・契約書(第二版)」は、システム開発を工程ごとに区切って契約する考え方を示し、準委任契約における報酬請求権を論点として扱っています。同じくIPAが2020年3月31日に公開した「情報システム・モデル取引・契約書(アジャイル開発版)」は、「あらかじめ特定した成果物の完成に対して対価を支払う請負契約ではなく、ベンダ企業が専門家として業務を遂行すること自体に対価を支払う」と明記しています(いずれも2026年9月16日に公開ページを確認)。

準委任と請負の違いそのものは「準委任 請負 違い」の記事で整理していますが、発注側として押さえておくべきは一点です。準委任では、成果物の完成責任は受託側にありません。要件定義書という形の成果物を求めたい場合は、契約書に成果物の定義と検収の条件を書き込む必要があります。なお、本記事の契約に関する記述は一般的な整理であり、法的助言ではありません。個別の契約内容については、弁護士など専門家にご確認ください。

費用の考え方——金額表ではなく「人月×期間」と上限の置き方で見る

要件定義支援の費用相場を金額表で覚えようとすると、かえって判断を誤ります。同じ「要件定義支援」でも、議事録の整理だけを週2日で受ける契約と、業務改革の設計まで含む契約では、桁が変わるためです。

見るべきは次の3点です。

• 誰が何人月入るか。 上流を担える人材は、実装を担当するエンジニアより単価が高くなります。要件定義は業務理解と抽象化を同時にこなす作業で、担える人が限られるためです。当社が人材紹介の事業から見てきた限りでも、上流工程を任せられる人材の市場は慢性的に薄く、それが単価に反映されています
• 期間の見込みは何で決まるか。 システムの規模よりも、関係者の数と合意形成のスピードで決まります。部署が3つ以上またがる案件は、それだけで期間が伸びます
• 上限をどう置くか。 準委任は稼働に対して払う契約なので、期間を区切らないと総額が読めません。「まず1か月」「まず20人日」と区切り、そこで中間成果物を見て継続を判断する形にしてください

IPAの原理原則17ヶ条は、第5条で「多段階の見積もりは双方のリスクを低減する」とし、行動規範に「事業リスクを低減するためにも、多段階見積もりを活用する」「見積もりリスク回避のため多段階契約を活用する」を挙げています。上限を置いて区切るのは、発注側が値切るための工夫ではなく、公的なガイドが勧める進め方です。

支援と丸投げの線引き——外に出せる作業と、自社が持つべき決定

外部に出せるのは作業です。現行業務の聞き取り、業務フローの作図、論点の整理、要件定義書の執筆、非機能要件の選択肢づくり。これらはすべて外に出せます。

出せないのは決定です。何のために作るのか、どの業務をやめるのか、何を優先するのか、いくらまで出すのか。ここを外に出した瞬間に、支援は丸投げになります。17ヶ条の第9条は、発注者側の行動規範として「『我々が要件を決め、責任を持つ』という意識を社内に浸透させる」を挙げています。外に出せるのは作業で、決定は出せない——この線引きだけは、支援を受けても変わりません。

要件が固まりきらないまま進める3つの方法と、そのときの契約

ここまでの打ち手を試しても、要件が固まりきらないことはあります。とくに新規サービスのように「ユーザーが使ってみないとわからない」領域では、机上で詰めきるほうが不自然です。その場合に取れる方法は3つあります。いずれも、要件定義を飛ばすのではなく、要件を決めるタイミングを後ろにずらして、決めながら作る形にするものです。

3つの方法の比較表——段階的発注・アジャイル・ラボ型

3つは排他ではありません。実務では「まず段階的発注で要件整理だけを準委任で切り、方向が見えたらラボ型に移す」という組み合わせが多くなります。アジャイル開発の外注実務は「アジャイル開発 外注」の記事、ラボ型の費用と向き不向きは「ラボ型開発」の記事で整理しています。

段階的発注が最も始めやすい——IPAが多段階契約を勧める理由

3つの中で最も始めやすいのは段階的発注です。社内の稟議が通しやすく、途中でやめる判断もできるためです。

前の章でも触れたとおり、IPAの原理原則17ヶ条は第5条で「多段階の見積もりは双方のリスクを低減する」とし、「見積もりリスク回避のため多段階契約を活用する」を受注者側の行動規範に挙げています。同じ条には、受注者側の行動規範として「要件定義段階では非機能要件に保証できないものがあることを説明する」も並んでいます。つまり、要件定義の段階で総額を確定できないのは、発注側の準備不足ではなく、工程の性質として織り込まれていることです。

実務での切り方は、たとえば次のようになります。

1. 第1段階(1〜2か月・準委任): 現行業務の整理、要求の洗い出しと優先順位付け、実現方式の選択肢の提示。成果物は論点整理と概算レンジ
2. 判断会議: ここで「作る/作らない/範囲を変える」を決める。やめる判断がしやすいのが段階的発注の利点です
3. 第2段階(2〜3か月・準委任): 要件定義書と基本設計。成果物が定義できるなら請負でも可
4. 第3段階(実装): 要件が固まっていれば請負、変わり続けるならラボ型やアジャイル

RFPを出す場合も、第1段階の前に全部を書き切る必要はありません。RFPに書くことと書かないことは「RFP 書き方」の記事で整理しています。

走りながら決めるときの歯止め——上限・優先順位・動くものを先に見る

要件を決めながら作る進め方には、費用が読みにくいという弱点があります。歯止めを3つ置いてください。

• 金額の上限を先に置く。 「この予算までで、できるところまで」と決めてから始めます。準委任は稼働に払う契約なので、期間と体制を固定すれば月額は読めます
• 優先順位を毎回つけ直す。 17ヶ条の第16条にあるとおり、機能要求は放っておけば膨張します。当社が支援した介護記録SaaSのCareViewer様では、構想と優先順位だけが決まった状態で開発を始め、週次で優先順位を判断し直す運用にしました。日本語対応のブリッジSE1名とフルスタックエンジニア2名の体制で、結果としてコストは従来の半分以下に収まっています
• 動くものを先に見る。 17ヶ条の第12条は「表現されない要件はシステムとして実現されない」とし、「文書・モックアップなどの手段を講じて、要件を表現しつくす努力をする」を発注者側の行動規範に挙げています。文書で詰めきれない論点は、画面のモックアップやプロトタイプを先に作ったほうが早く決まります。議論が具体的になるためです

アジャイル開発版のモデル契約は、発注者がプロダクトオーナーを選任し、「プロダクトの方向性及び内容を決めるための主体的かつ積極的な関与」を求めるとしています。相応の負担を伴うとも明記されています。走りながら決める進め方は、発注側の関与が減る方法ではなく、むしろ増える方法だという点は要注意です。

それでも請負で一括発注したほうがよい場合

逆に、次のような案件は、要件を固めてから請負で一括発注したほうが総額も管理コストも下がります。

• 作るものが明確で、途中で変わる見込みがない(法改正対応、既存システムの単純な置き換えなど)
• 社内にプロジェクトへ継続的に関与できる人を置けない
• 予算を年度内に確定させる必要があり、総額が動くと稟議が通らない
• 開発期間が3か月未満で、反復する回数がそもそも取れない

要件が固まらないまま進める方法は、要件を固める努力を省くためのものではありません。固めきれない領域が残るときに、その領域だけを後ろにずらすための道具です。

「要件定義ができないから発注できない」は本当か——当社の進め方と、自社で進めたほうがよいケース

最後に、この記事の出発点に戻ります。要件定義ができていないと発注してはいけない、というルールは存在しません。要件定義書は相談の入場券ではなく、相談を経て作られる成果物です。

相談の時点で必要なのは要件定義書ではなく、目的・予算上限・決める人の3つ

当社が初回のご相談でうかがうのは、次の3点です。これが揃っていれば、要件定義書がなくても話は進みます。

1. 何を解決したいのか。 機能ではなく、困っている状態で構いません。「受発注の入力を二重にやっていて、月に80時間かかっている」で十分です
2. 予算の上限と時期。 金額が決まっていなければ「年間でこのくらいまで」というレンジでも構いません
3. 決める人が誰か。 これが最も重要です。型2で書いたとおり、ここが空欄のままだと、どの進め方を選んでも止まります

逆に、この3つが揃っていない状態でいきなり要件定義書を作ろうとすると、型4の「会議のたびに前回が上書きされる」状態に入ります。順番が逆だ、というのが実情です。

当社の場合——日本人PMフロントのラボ型で、最小構成2〜3人月から

当社は、要件が固まりきらない状態から始まる案件を前提に体制を組んでいます。推奨しているのは、日本人のPM(またはブリッジSE)をフロントに置き、その後ろにベトナム側のエンジニアを付けるパターンです。仕様のヒアリングと文書化をPM側で巻き取れるため、発注側は「決める」ことに集中できます。日本人PMを置く判断基準は「オフショア開発 日本人PM」の記事で整理しています。

契約はラボ型(準委任)で、最小構成は日本人PMフロント+2〜3人月、月額約80万円からです。公開している単価は実務3年目安で1,500USD(約22.5万円)、5年で2,000USD、10年目安・ブリッジSEで3,000USD(1USD=150円換算の目安)。グループが持つ2,000名以上のIT人財データベースから直接アサインするため、協力会社を経由する仲介マージンが発生しません。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。1名から始められ、最短2週間で開始、増員は約1週間、縮小と交代は1か月単位で対応しています。

前の章で触れたCareViewer様も、構想と優先順位だけが決まった状態から始まった案件です。要件定義書が完成してから声をかけていただいたわけではありません。

自社で進めたほうがよいケース、当社が向かないケース

とはいえ、当社に頼まないほうがよいケースもあります。率直に書きます。

• 要件が確定していて、期間が3か月未満の単発案件。 立ち上がりの時間が相対的に大きくなるため、国内の受託会社に請負で出したほうが総額で安くなることが多くなります
• 月100万円未満の少額・不定期の開発。 専属チームを確保する形の費用構造と噛み合いません
• 社内に窓口役を1名も置けない案件。 これは当社に限らず、どの開発会社でも同じです。ラボ型はとくに、依頼する作業を用意し続ける責任が発注側に残ります
• 業務改革そのものが目的の案件。 複数部署の業務そのものを設計し直すフェーズは、業務コンサルティングの領域です。当社はシステムを作る側であって、社内の合意形成を代行する立場ではありません
• 要件定義の整理だけを社内で完結できる体制がある場合。 情報システム部門があり、上流を担える人がいるなら、外に出す必要はありません。その場合は実装以降の体制だけをご相談ください

そして最初に戻りますが、型1から型4は社内の決定の問題です。ここが止まっている限り、開発会社を探す前に、決める人と決める範囲を狭めることが先になります。当社にご相談いただいた場合も、まずその確認から始めます。

要件定義ができないときによくある質問

要件定義が止まっている段階で、当社が実際にいただくことの多い質問を5つ挙げます。契約や費用に関する回答は一般的な整理であり、個別の案件では前提によって変わります。法的な判断が必要な場合は専門家にご確認ください。

Q1. 要件定義は開発会社にやってもらえますか

作業は依頼できますが、決定は依頼できません。現行業務の聞き取り、業務フローの作図、論点の整理、要件定義書の執筆は外部に出せます。一方で「何のために作るか」「どの業務をやめるか」「何を優先するか」は発注側が決めるものです。IPAの「超上流から攻めるIT化の原理原則17ヶ条」も第9条で要件定義を発注者の責任と位置づけたうえで、受注者側の行動規範として「発注者側に立った支援を提供する」を挙げています。支援を受けること自体は問題ありません。

Q2. 要件定義だけを別の会社に頼んで、開発は別の会社に出してもよいですか

可能です。ただし2点だけ確認してください。ひとつは、要件定義書の著作権と利用範囲が契約でどう定められているか。もうひとつは、実装の実現性を誰が担保するかです。実装を担当しない会社が書いた要件定義書は、実現方式やコストの見通しが甘くなることがあります。開発会社の見積もり段階で、要件定義書の内容に対する意見を出してもらうと、その差が見えます。

Q3. 要件定義にはどのくらいの期間がかかりますか

規模よりも、関係者の数と合意形成のスピードで決まります。部署が1つに収まる小規模なシステムなら1か月前後、3部署以上にまたがる基幹システムの刷新なら3か月から半年かかることも珍しくありません。期間を縮める最も効果的な方法は、決裁者を1名に決めて、その人が出る会議を週次で固定することです。打ち合わせの回数を増やすより効きます。

Q4. 要件が途中で変わったら、追加費用になりますか

契約形態で変わります。請負契約では、合意した仕様との差分が追加費用の対象になるのが原則です。準委任契約(ラボ型・アジャイル)では、稼働に対して支払うため、優先順位の入れ替えであれば追加費用は発生せず、代わりに何かが後ろにずれます。どちらが有利かは、変更の起きやすさで決まります。線引きの実務は「仕様変更 追加費用」の記事で整理しています。

Q5. 要件定義書がなくても見積もりは出ますか

出ます。ただし精度は下がり、幅のあるレンジになります。当社の場合、解決したい状態・予算の上限と時期・決める人の3点をうかがえれば、体制を仮組みして概算をお出しできます。体制の最小構成は日本人PMフロント+2〜3人月で月額約80万円から、開始までは最短2週間が目安です。要件定義書は、その概算をもとに進めるかどうかを決めたあとに作る成果物。

まとめ: 止まっているのは文書ではなく決定——型を特定し、決められない部分は契約で分ける

要件定義ができないという状態は、7つの型に分かれます。現行業務を誰も説明できない、決裁者が出てこない、関係部署の要望が矛盾する、何を作りたいか自体が決まっていない、ベンダーの質問に答えられない、時間が取れない、社内にIT担当がいない。型1から型4は社内の決定が止まっている型で、開発会社を変えても解決しません。型5から型7は決定を外部とやり取りする経路の問題で、質問の仕分けや体制の設計で解けます。まず自社がどの型かを1つか2つに絞ってください。

そのうえで、自社だけで動かせない部分は外部の支援を買えます。上流工程の契約は準委任になり、費用は金額表ではなく「誰が何人月、いつまで入るか」と上限の置き方で見ます。IPAの「超上流から攻めるIT化の原理原則17ヶ条」も、多段階の見積もりと多段階契約の活用を勧めています。要件定義の手順そのものは要件定義の進め方で整理しています。

それでも要件が固まりきらないときは、段階的発注・アジャイル・ラボ型という3つの進め方があります。最も始めやすいのは段階的発注です。ただし、走りながら決める進め方は発注側の関与が減る方法ではなく、むしろ増える方法だという点は要注意です。専属チームを月額で確保する形の詳細はラボ型開発とはをご覧ください。要件定義ができないことは、発注できない理由にはなりません。相談の時点で必要なのは、要件定義書ではなく、解決したい状態・予算の上限と時期・決める人の3つです。

現在の体制と要件をお聞かせいただければ、どの型で止まっているかの切り分けと、体制を仮組みした概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。