目次
最終更新日：2026年7月27日
システム開発には様々なフェーズがあります。プログラムを組むだけではなく、どんなシステムを作るのか設計する設計フェーズや、作ったシステムが正しく動作することを確認するテストフェーズがあります。その一番最初のフェーズにあるのが「要件定義」というフェーズです。
この要件定義はプロジェクトによって中々進行しないことがあります。要件定義フェーズが遅れに遅れたけど、システムそのものをオープンさせる日程は変更されず、後に続くフェーズを担当する人達が地獄を見るという話はよく聞く話です。
この要件定義というフェーズは誰に責任があり、要件定義フェーズの遅延は誰が悪いのかについて考えてみます。そのうえで、「決めなければいけないのは分かっているが、決められない」という時に現実的にどうすればいいのかまでを扱います。要件定義そのものの進め方や成果物については「要件定義とは？進め方と成果物」で解説していますので、そちらをご覧ください。
要件定義とは
システム開発における要件定義とは、システムに備わる機能をどんなものにするのかを具体的に検討する前に、そもそも何のためにシステムを必要としているのか、満たさなければならない利用者の要求は何なのかを明確に定義するフェーズです。
注文住宅で言えば、具体的に屋根や壁をどういったものにするのかを検討する前に、
- マンションにするのか戸建てにするのか
- その家には何人で住むのか
- 駅からの距離はどれくらいの土地を用意するのか
- 駐車場は何台分必要なのか
このような「満たさなければならない要求」を明確にしていくのが要件定義です。当然のことながら業者側で一方的に要件定義の内容を決定することなどできませんので、必ず利用者側も要件定義フェーズでは深く関わることになります。
要件定義が進まない時
では要件定義が進まない時というのは、そのプロジェクトではどのようなことが起きているのでしょうか。その内容を端的に表現したツイートがありますのでこちらをご覧ください。
ラーメンの注文で例えていますが、要件定義が進まない時というのは正にこのツイートと同じような状況が実際のプロジェクトでも発生しています。
これをご覧になった皆さんは、お客さんとラーメン屋さんのどちらに問題があると感じましたか？この記事の先に進む前に、ぜひ一度ご自分でも考えてみていただけたら面白いと思います。
どちらが悪いと感じるかは人それぞれ
上記のツイートへの反応の非常に面白いところは、「お客さんが悪い」「ラーメン屋さんが悪い」という意見が、人によって全く異なるところです。同じ現象を見ているのに人によって受け取り方が全く違うのです。
お客さんが悪いのか、ラーメン屋さんが悪いのか、どちらが正解ということはありません。どちらにも一定の理があるから意見も様々に分かれるのだと思います。
このツイートはラーメンの注文の場面で例えていますが、これと同じことは実際のプロジェクトでも起きてるんですよね。プロジェクトの要件定義が進まない時に、顧客側の立場に近い人だと「開発会社が悪い。もっと顧客に寄り添った提案をしろ」と言うことが多いですし、開発側の立場に近い人だと「顧客が悪い。さっさと決めるべきことを決めてもらわないと先に進めない」と言います。
どちらにも自分の正義があるので、自分の正義だけを相手にぶつければここで衝突することになります。そしてコミュニケーションがうまくいかずに、要件定義が全く進まずに頓挫してしまうのです。
要件定義が進まない典型パターン
立場によって解釈が分かれるとはいえ、要件定義が止まっているプロジェクトを実際に覗いてみると、詰まっている箇所はだいたい似ています。よくあるのは次の4つです。
- 決められる人が打ち合わせに出ていない……出席者は真面目に検討しているが、最終的にゴーサインを出せる立場の人がその場にいないため、毎回「持ち帰って確認します」で終わる。
- 「何を作るか」から始めてしまっている……本来は「何を解決したいのか」が先。目的が定まらないまま機能の議論を始めると、判断の基準がないので何も決まらない。
- 部門ごとに要求が食い違っている……開発会社に持ち込まれる前に社内で調整がついておらず、要件定義の場が社内調整の場になってしまう。これは開発会社には解けない。
- 期日だけが先に決まっている……検討に必要な時間が確保されていないので、決めるより先に「間に合うのか」の話になる。冒頭のラーメンの例がまさにこれです。
自分たちのプロジェクトがどれに当てはまるかが分かると、打ち手も変わってきます。1つ目と3つ目は開発会社ではなく発注者側でしか解けない問題ですし、2つ目は開発会社が主導して整理できる問題です。「要件定義が進まない」とひとまとめにせず、どこで詰まっているのかを切り分けてみてください。
顧客は真剣に要件定義に取り組むべき
要件定義は顧客（利用者）も深く関わる必要があります。どんなに開発サイドの人間が手取り足取り色々と提案をしたとしても、最終的に意思決定をするためには顧客にも真剣に考えてもらう必要があります。
上記のツイートだと、ラーメン屋さんから「何ラーメンにします？」と聞かれていることに対して、何一つ正面から答えていませんよね。何ラーメンを作るのか決めなければならないのに、これだと先に進むことができません。実際のプロジェクトでも同じことは度々発生します。
顧客側からすると、選択肢としてどんなラーメンがあるのかわからずに意思決定ができないのかもしれません。何を作るか決められないけど、迫りくる時間へのプレッシャーから、いつまでに作るのかばかりを気にしているのかもしれません。
色々と言い分はあるにせよ、わからないことがあるのであればラーメン屋（開発会社）に聞くべきですし、真剣に考えているのであればわからないままスルーして意思決定しないということはやらないはずです。
要件定義をうまく進めるためには、顧客側も要件定義に正面から取り組んでいただく必要があります。
とはいえ、社内にITに詳しい人がいないために「そもそも何を決めればいいのかすら分からない」という企業様も少なくありません。そうした場合に現実的にどうするかは、この記事の後半「それでも決められない時、現実的にどうするか」で扱います。
業者は顧客の立場にたってコミュニケーションするべき
要件定義は最終的に顧客に意思決定してもらう必要があることは間違いありません。その意味から、私は要件定義の最終的な責任は顧客側にあると考えています。
しかしだからといって一方的に「顧客が決めてくれない」とぼやいているだけでは、専門家としてその仕事を請け負っている意味を考え直さなければならないかもしれません。
お客さんが何ラーメンにするのか決めてくれないのであれば、いつまでに決めてもらわないと希望する時間までに間に合いませんよということを伝える必要があるかもしれません。お客さんが決めやすいように、こんなラーメンがありますよと選択肢を提示したり、おすすめを提案したりする必要があるかもしれません。
この記事を最初に書いた2020年当時と比べて変わったのは、その「選択肢を並べて見せる」こと自体のコストが下がったことです。案を複数出す、比較表にする、画面のイメージを試しに作ってみる——かつては相応の工数がかかったこれらの作業が、AIを使えば短時間で出せるようになりました。「選択肢が分からないから決められない」は、業者側から潰しにいける問題になりつつあります。もちろん出てきた案が妥当かどうかを判断するのは人間の仕事ですが、顧客に何も見せないまま「決めてください」と待つ理由は、以前より少なくなっています。
それでもあらゆる手を尽くしても顧客が真剣に取り組んでくれないということであれば、そのまま進めてもそのプロジェクトが成功することは絶対にありませんから、「うちのラーメンはお客さんには売らないよ」と、そのプロジェクトから撤退するという選択も、プロとしての最終的な責任です。
それでも決められない時、現実的にどうするか
ここまで「最終的な責任は顧客側にある」と書いてきましたが、責任の所在が分かったところで、決められないものは決められません。ラーメン屋の例で言えば、「メニューを見せられても、そもそも自分が何を食べたいのか分からない」という状態です。この場合に現実的に取れる手は、だいたい次の4つです。
1. 決めることを分解する
「システムの要件を決める」は大きすぎて手がつきません。まずは「何を作るか」ではなく「今の業務の何が困っていて、何が解決されれば成功と言えるのか」から言葉にしてみてください。目的が決まれば、機能の要不要は判断できるようになります。逆に、目的が決まっていない状態で機能の議論をしても、判断の基準がないので永遠に決まりません。
2. 社内に「決める人」を1人立てる
関係部署の意見を集めることと、最終的に決めることは別の仕事です。全員が納得するまで待つ進め方だと、要件定義はまず終わりません。意見が割れた時に決める人を1人決めて、その人が打ち合わせに出る。これだけで進み方が変わるケースは多いです。
3. 要件定義だけ先に外部へ発注する
意外と知られていませんが、要件定義だけを切り出して先に発注するという進め方があります。開発を丸ごと任せる契約とは別に、要件を整理するところだけを専門の会社に手伝ってもらう形です。アクシアでも、週1回の要件定義ミーティングにこちらのメンバーが参画して、各部門から出てくる要望に実現コストを示しながら優先順位をつけていく、という形でご支援したことがあります。ただし要件定義を外部に丸投げすることはできません。あくまで発注者のプロジェクトメンバーの一員として加わる形です。具体的な進め方は「要件定義だけ先に発注するという進め方」に、実際のお客様の事例とあわせて書いています。
この形の良いところは、「作らない」という結論も出せることです。要件を整理した結果、今のタイミングでシステムを作るべきではないという判断になったお客様も実際にいらっしゃいます。開発ありきで話が進まない分、発注者にとっては安全な入口です。
また、社内にITに詳しい人がいないために「そもそも何を決めればいいのかすら分からない」という場合は、発注先とは別に月額制でITの相談相手を持てるIT顧問サービスのような選択肢もあります。
4. すでに進行中なら、第三者に診てもらう
すでにプロジェクトが動いていて要件定義で止まっている場合は、当事者だけで話し合っても堂々巡りになりがちです。止まっている原因が発注者側にあるのか、開発会社側の進め方にあるのかを外から切り分けるだけでも、次の一手が見えます。アクシアでは第三者の視点で進行や提案内容を診断する「システム開発のセカンドオピニオン」をご用意しています。要件定義が停滞して不安を感じている場合はご相談ください。
まとめ
何かの物事がうまく進まない時に、悪いのは「顧客or業者」の二者択一で考えてしまうことも多いですが、一方的にどちらかだけが悪いケースばかりではないようです。上記のツイートの反応を見ればそのことをご理解いただけるのではないでしょうか。
私自身、今回の自分のツイートへの反応を見て色々と学ぶものがありました。要件定義（その他のことでも）がうまく進まずに「相手のせいだ」と考えている人がいたら、ぜひ一度今回ご紹介したツイートを思い出していただけたら幸いです。
そのうえで、責任の所在を確定させることがゴールではありません。決められないなら、決められる状態に持っていく。そのための手は上に挙げたとおりいくつもあります。アクシアでは要件定義からのシステム開発も、要件定義のみのご支援も行っておりますので、お困りの企業様はお気軽にお問い合わせください。
なお、要件定義そのものの進め方・成果物・機能要件と非機能要件の違いについては「要件定義とは？進め方と成果物」で、要件定義を含むプロジェクト全体が失敗する原因については「システム開発が失敗する原因と対策」で解説しています。