要件定義とは：開発会社に頼む前に、社内でまとめておくこと

社内の業務をシステムにしたいと考えて開発会社に相談すると、早い段階で「まず要件定義をしましょう」と言われます。けれども、初めてシステム開発を頼む会社にとって、要件定義で何を決めるのか、自分たちは何を用意すればよいのかは、分かりにくいものです。

「要件定義書を書いて渡さないと相談できないのでは」と身構える人もいれば、「専門的なことだから開発会社が全部やってくれる」と考える人もいます。実際は、そのどちらでもありません。

この記事では、次のことを順に書きます。

• 要件定義とは何か
• 要件定義は、誰の仕事とされているか
• なぜ最初の工程が大事なのか（公的な調査の数字）
• 要件定義で決める3つのこと
• 開発会社に頼む前に、社内でまとめておく7つのこと
• 開発会社と一緒に決めればよいこと
• 相談から要件の確定までの進め方と、よくあるつまずき

要件定義とは：要望を、合意した「決めごと」にする工程

IPA（独立行政法人 情報処理推進機構）が公開している「ユーザのための要件定義ガイド 第2版」（2019年）は、要件定義を次のような工程として説明しています。企画の段階で立てたシステム化の計画をもとに、関係者のニーズや要望、課題を分析してシステムへの要求を定義し、関係者と合意して「要件」とする工程です。

ここで大事なのは、「要求」と「要件」は違うという点です。同じガイドでは、要求を文書にして関係者と合意したものを「要件」と呼んでいます。そして要件は、業務部門から情報システム部門、さらに開発会社へと、第三者に伝わる形になっている必要があるとしています。

たとえば、「受注の入力を楽にしたい」は要求です。これを「営業担当が外出先のスマートフォンから受注を登録でき、登録した内容は当日中に出荷担当が確認できる」のように、誰が読んでも同じものを思い浮かべられる形にし、関係者が「これで行く」と合意したものが要件です。

工程の順番でいうと、要件定義は「企画」と「設計」のあいだにあります。

要件定義は、「なぜ」を「何を」に変える工程だと考えると分かりやすいでしょう。

要件定義は、発注する側の仕事とされている

要件定義を誰がするのかについて、公的な指針ははっきりしています。

IPA が公開している「超上流から攻めるIT化の原理原則17ヶ条」の第9条は、「要件定義は発注者の責任である」です。開発会社の支援を受けた場合でも、要件定義の成果物に対する責任は発注者にある、と説明されています。

契約の面でも、同じ考え方が取られています。IPA の「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）〈第二版〉」（2020年公開）は、要件定義を契約上の独立した段階とし、その契約の形を準委任としています。準委任とは、完成品を約束する契約（請負）ではなく、決められた作業を行うこと自体を約束する契約です。

準委任とされている理由は、要件定義の段階では発注する側の業務の要件がまだ決まっておらず、出来上がるものを前もって特定できないからです。このモデル契約書の解説では、要件定義の作業をするのは発注する側で、開発会社はそれを支援するという役割分担になっています。要件定義の検討会も、発注する側が主催する形です。

ここで誤解してほしくないのは、「開発会社に頼ってはいけない」という意味ではないということです。業務の課題を聞き取って整理する、画面の案を作る、技術的にできることとできないことを伝える、といった作業は、開発会社が大きく手伝えます。分けられているのは、「決める責任」と「決めるための作業を手伝うこと」です。

自社の業務で何を良くしたいのか、どこまでお金と時間をかけるのかは、発注する側にしか決められません。そこを開発会社に任せきりにすると、出来上がったものが「頼んだつもりのもの」とずれてしまいます。

なぜ最初の工程が大事なのか：公的な調査の数字

要件定義が大事だと言われるのには、理由があります。いくつかの調査の数字を見てみます。

成否の多くは、要件定義までで決まる

先ほどの「17ヶ条」の第3条は、「プロジェクトの成否を左右する要件確定の先送りは厳禁である」です。その説明では、要件定義は開発全体の工数でみれば1〜2割の作業だが、開発の成否という意味では7〜8割がここまでの工程に左右される、と書かれています。

IPA の要件定義ガイドも、一般社団法人 日本情報システム・ユーザー協会（JUAS）の「ソフトウェアメトリックス調査2016」を紹介しています。この調査の479件のプロジェクトでは、工期が遅れた理由の50％以上が要件定義の問題だったとされています（ガイドの23ページ）。

同じガイドは、修正にかかる手間は要件定義の段階なら小さく、設計、開発、テスト、稼働後と進むほど大きくなる、とも説明しています。決めるべきことを後回しにすると、後の工程で手戻りとして返ってくるということです。

予定どおりにいかない理由の上位

JUAS の「企業IT動向調査報告書2026」（2026年4月）は、システム開発が品質・予算・工期の面で予定どおりにいかなかった理由を尋ねています。2025年度の調査で、工期について多かった回答は次のとおりです（複数回答）。

この調査は、理由として「要件定義」という言葉を直接挙げているわけではありません。ただ、「計画のときに考えが足りなかった」「今の業務が思っていたより複雑だった」「途中で仕様がたびたび変わった」は、どれも要件定義で何をどこまで決めたかと深く関係しています。

小さく始めると、予定どおりに進みやすい

同じ調査では、開発の規模による違いも示されています。規模が小さいほど、品質・予算・工期のどれも予定どおりに進んだ割合が高くなっています。

この調査の回答企業は東証上場企業などの大きな会社が中心なので、中小企業にそのまま当てはまるとは限りません。それでも、一度に大きく作るより、範囲を絞って始めたほうが予定どおりに進みやすいという傾向は、要件定義で「最初にどこまで作るか」を決めるときの参考になります。小さく作って確かめる進め方は、MVP とは：小さく作って確かめる開発の進め方で詳しく書いています。

なお、日経コンピュータが2018年に行った調査（日経クロステック）では、1745件のシステム導入・刷新プロジェクトのうち、スケジュール・コスト・満足度の3つの条件をすべて満たした「成功」の割合は52.8％でした。システム開発の約半分は、どこかで予定どおりにいかないということです。

要件定義で決める3つのこと

要件定義で決めることは、大きく3つに分けられます。

モデル契約書の解説では、業務部門が業務要件を、情報システム部門が機能要件と非機能要件を定義し、経営層が承認するという分担が示されています。情報システム部門がない中小企業では、機能要件や非機能要件は開発会社の手を借りて決めることになるでしょう。ただし、承認するのは発注する側です。

見落とされやすい「非機能要件」

機能要件は話題にしやすい一方で、非機能要件は話に出ないまま進みがちです。IPA は、非機能要件についての認識の行き違いを防ぐために「非機能要求グレード」を公開しています。そこでは非機能要件を、次の6つの大きな項目に分けています。

• 可用性（止まらずに使えるか、止まったときにどう戻すか）
• 性能・拡張性（速さ、利用者やデータが増えたときの対応）
• 運用・保守性（日々の運用や、直すときのしやすさ）
• 移行性（今のシステムやデータからの移し替え）
• セキュリティ（誰が何を見られるか、情報をどう守るか）
• システム環境・エコロジー（設置場所や使う環境など）

全部を細かく決める必要はありません。ただ、「止まったら業務がどれくらい困るか」「社外の人も使うか」「個人情報を扱うか」は、早めに開発会社と話しておくと、あとで大きな手戻りになりにくくなります。

「すぐに」「今と同じ」は要件にならない

「17ヶ条」の第13条は「数値化されない要件は人によって基準が異なる」、第14条は「「今と同じ」という要件定義はありえない」です。

「画面がすぐに表示されること」と書いても、「すぐ」が1秒なのか10秒なのかは人によって違います。「今の Excel と同じことができればよい」も、今の Excel で誰がどんな作業をしているかを書き出さなければ、開発会社には伝わりません。数えられるものは数で書き、「今と同じ」は今の作業を具体的に書き出す。これだけでも、要件の質はかなり上がります。

要件定義で作る資料

要件定義が終わると、決めたことは資料の形で残ります。IPA の要件定義ガイドは、設計や開発、テストにつなぐ主な資料として、次のようなものを挙げています（表3.2）。

小さなシステムなら、これらを1冊にまとめたり、画面のたたき台で代わりにしたりすることもあります。大事なのは資料の数ではなく、発注する側が中身を読んで「これで行く」と言える状態になっていることです。資料を受け取ったら、自分たちの業務の言葉で説明できるかどうかを確かめてください。説明できない所は、遠慮なく開発会社に聞き直しましょう。「17ヶ条」の第17条も「要件定義は説明責任を伴う」としています。

開発会社に頼む前に、社内でまとめておく7つのこと

ここからが、この記事でいちばん伝えたいことです。要件定義書を社内だけで書き上げる必要はありません。けれども、発注する側にしか決められないことがあります。それを相談の前にまとめておくと、開発会社との話が早く、深くなります。

1. 目的と、うまくいったと言える数字

「なぜシステムを作るのか」を一文で書きます。そのうえで、うまくいったかどうかを判断できる数字を決めます。「受注の入力にかかる時間を、1件あたり10分から3分にする」「月末の集計作業を、2日から半日にする」のような形です。

IPA の要件定義ガイドも、経営層には数値で確かめられる目標を立てることが求められる、としています。数字があると、あとで機能を足すか削るかを迷ったときに、「その機能はこの数字に効くか」で判断できます。効果の考え方は、DXと投資対効果（ROI）の考え方もあわせて読んでみてください。

2. 今の業務の流れと、困っている所

今、誰が、いつ、何を使って、どんな作業をしているかを書き出します。きれいな図でなくてかまいません。付箋やホワイトボードに書いて写真を撮ったものでも、開発会社にとっては大きな手がかりになります。

あわせて、困っている所に印を付けます。「二重に入力している」「この人しか分からない」「月末に残業が集中する」などです。可能なら、「週に何回」「1回に何分」と、頻度と時間も添えてください。

3. 使う人と、使う場面

システムを使う人は誰で、どんな場面で使うのかを書きます。事務所のパソコンで使うのか、現場でスマートフォンやタブレットで使うのか。パソコンに慣れた人か、そうでない人か。社外の取引先も使うのか。

同じ機能でも、使う場面によって画面の作り方は大きく変わります。ここは発注する側にしか分からない情報です。

4. 最初にやること・やらないこと

やりたいことを全部書き出したうえで、優先順位を付けます。そして、「最初の版ではやらないこと」も書いておきます。

「17ヶ条」の第16条は「機能要求は膨張する。コスト、納期が抑制する」です。要望は話し合うほど増えていきます。要望を出す段階と絞り込む段階を分け、最低限の構成から始めることが勧められています。やらないことを先に決めておくと、話し合いの中で要望が膨らんだときに立ち返る基準になります。

5. 予算の枠と、使いたい時期

「いくらまでなら出せるか」「いつから使いたいか」を、おおよそでよいので社内で決めておきます。予算を開発会社に伝えるのはためらわれるかもしれません。けれども、枠が分かれば、開発会社はその中でできる最も効果の高い範囲を提案できます。

使いたい時期も、「繁忙期の前に」「来年度の始まりに」のように理由と一緒に伝えると、どこまでを最初に作るかを決めやすくなります。

6. 決める人と、社内の体制

誰が最終的に決めるのか、誰が開発会社とのやり取りの窓口になるのか、現場の意見を誰が取りまとめるのかを決めます。

IPA の要件定義ガイドは、経営層が要件定義に積極的に参画することが成功の鍵だとしています。モデル契約書の解説で紹介されている裁判例（東京地方裁判所 平成16年3月10日判決）でも、発注する側には、社内の意見を調整して統一し、要望をはっきり伝え、最終的に決める役割があるとされています。同じ判決は、開発会社の側にも、進み具合を管理し、発注する側の関わり方にも働きかける義務があるとしています。役割を分け合って進めるものだということです。決める人が会議に出られないまま進むと、終盤で「思っていたのと違う」とひっくり返ることがあります。

7. 今あるシステム・データ・紙

今使っているシステムや Excel、紙の帳票、取引先とのやり取りの方法を一覧にします。新しいシステムに移すデータはどれか、今のシステムとつなぐ必要があるかも書いておきます。

JUAS の調査で「想定以上の現行業務・システムの複雑さ」が上位に入っていたように、今あるものの把握が足りないと、あとで想定外の作業が増えます。

まとめておくための型紙

上の7つは、次のような1枚にまとめると開発会社に渡しやすくなります。空欄があってもかまいません。空欄は「開発会社と一緒に考えたいこと」として伝えれば十分です。

開発会社と一緒に決めればよいこと

7つのことをまとめたら、残りは開発会社と一緒に決めていけば大丈夫です。たとえば、次のようなことです。

• 画面の構成や、入力する項目
• 機能の細かい動き（例外のときにどうするか、など）
• データの持ち方や、今のシステムとのつなぎ方
• 非機能要件の具体的な水準（どれくらいの速さ、どれくらいの守り）
• どの技術やサービスを使うか

これらは、技術の知識や、ほかの会社での経験が役に立つ部分です。発注する側が考えた案に、開発会社が「この場合はどうしますか」「この方法なら手間が半分になります」と返しながら詰めていくのが、うまく進むやり方です。

クリーヴァの事例から

クリーヴァの事例でも、お客様と分担しながら要件を決めています。

株式会社プラゴ様では、おおまかな要件はプラゴ様のほうで作っていて、詳しい要件定義や画面の構成を考えるところから、クリーヴァが入りました。

株式会社日本能率協会マネジメントセンター様の「Knotter」では、プロダクトの方向性を決め、「どのようなものを作りたいか」「どのように実現したいか」という要件を整理するところまでを、お客様が担当しています。

株式会社R65様では、事業を引き継ぐにあたって複数の会社を検討する中で、要件がある程度見えてきた段階で、今のシステムを引き継がずにゼロから作り直すのは現実的ではない、と判断されました。要件が見えてくると、「何を作るか」だけでなく「何を作らないか」「今あるものをどう生かすか」も判断できるようになります。

どの事例でも、発注する側が目的や方向性を持ったうえで、細かい部分を開発会社と一緒に詰めています。

画面のたたき台で確かめる

文章だけの要件は、読む人によって受け取り方が変わります。そこで役に立つのが、画面のたたき台です。画面の絵や、簡単に触れる試作品があると、「この項目は要らない」「この順番のほうが現場に合う」と、文章では出てこなかった意見が出てきます。

クリーヴァのサービスでも、最初のステップで今の業務と改善後の業務を Before / After や簡易なプロトタイプで見えるようにし、何を変えるのか、最初にどこまで作るのか、やらないことは何かをはっきりさせています。すでに他社で要件定義まで終わっている場合は、その内容を引き継いで開発から進めることもできます。

相談から要件の確定までの進め方

ここまでの内容を、手順としてまとめます。

1. 社内で7つのことをまとめる：完璧でなくてよいので、1枚にまとめる。
2. 開発会社に相談する：1枚を渡し、空欄は一緒に考えたいことと伝える。複数の会社に相談する場合も、同じ1枚を渡すと比べやすくなる。
3. 要件定義の進め方と契約を決める：要件定義は準委任で、発注する側が主体となって進めるのが基本（モデル契約書）。期間、打ち合わせの頻度、何を成果物とするかを決める。
4. 打ち合わせを重ねて要件を詰める：業務の流れ、画面のたたき台、非機能要件を、決める人も入って確かめる。
5. 要件を確定する：要件定義書の内容に双方が合意する。モデル契約書では、双方の責任者が記名押印して確定する形が示されている。
6. 開発の見積もりと契約に進む：決まった要件をもとに、開発の範囲と費用を決める。

要件定義の期間について、IPA の要件定義ガイドは JUAS の調査をもとに、規模にかかわらず全体の工期の20％強を要件定義に使っていると紹介しています。急ぐあまり決めるべきことを残したまま進むと、後の工程が膨らんで予算を超える例が後を絶たない、とも書かれています。

よくあるつまずきと、防ぎ方

IPA の要件定義ガイドは、発注する側と開発会社の両方から集めた、要件定義でよく起きる問題を挙げています。その中から、初めて発注する会社が特につまずきやすいものと、防ぎ方を整理します。

決めた後に要望を出し続けることにも、注意が必要です。モデル契約書の解説では、仕様を固めると合意した後に大量の追加要望を出した発注者に、協力する義務に反したとして損害賠償の責任が認められた裁判例（札幌高等裁判所 平成29年8月31日判決）が紹介されています。決めた後に変えたくなったら、変更の手続きとして開発会社と話し合い、費用や期間への影響を確かめてから進めるのが安全です。

相談の前に確かめたいチェックリスト

最後に、開発会社に相談する前に確かめたいことをチェックリストにします。

• なぜシステムを作るのかを、一文で言える
• うまくいったと判断できる数字がある
• 今の業務の流れを、ざっくりでも書き出した
• 困っている所に、頻度や時間を添えた
• 使う人と、使う場面（場所・機器）を書いた
• 最初にやることと、やらないことを分けた
• 予算の枠と、使いたい時期の目安がある
• 最終的に決める人と、窓口が決まっている
• 今あるシステム、Excel、紙の帳票を一覧にした
• 分からないことを「一緒に考えたいこと」として書き出した

全部に印が付かなくても、相談はできます。印が付かなかった所が、開発会社と最初に話すべきことです。

おわりに

要件定義は、発注する側の責任とされています。けれども、それは「全部を自分たちで書き上げなければならない」という意味ではありません。目的と数字、今の業務、使う人、優先順位、予算と時期、決める人、今あるもの。この7つは社内でしか決められないので、相談の前にまとめておく。そのうえで、画面や機能の細かい部分は、開発会社と一緒に、たたき台を見ながら詰めていく。これが、要件定義をうまく進めるための現実的な分担です。

「何を作るか、まだ決まっていない」という段階でも、7つのうちいくつかが書ければ、相談を始めるには十分です。

※「17ヶ条」の条文の出典：IPA−SEC「超上流から攻めるIT化の原理原則17ヶ条」