「要件定義って言葉はよく聞くけど、結局なにするの？」
独学である程度コードが書けるようになって、就職して開発現場に入って少ししたぐらいでちょっと気になり出すやつ。僕も最初の頃「設計の前のなんか偉い人がやるやつ」くらいの理解でした。笑
この記事では、8年目のエンジニア兼PMとして上流から下流まで一通り経験してきた立場で、「要件定義とはなにか」と「現場で実際にどう進めるか」を5分でざっくり掴めるようにまとめました。あとは炎上案件がなんでできちゃうかとかも書きました。
※現場の全て話せるわけじゃないので所々ぼかします...ご了承ください。
はじめに
はじめまして。現在8年目になるエンジニア兼PMやってるやむぅ。です！普段はフリーランスエンジニアとして、8人の開発チームのPM（プロジェクトマネージャー）をしたり、AIゲームコーチングサービスなどの「個人サービス運営」「個人的なエンジニアサポート」この三つを主軸に活動しています。
- エンジニア歴: 8年目（上流の設計から下流の実装・テストまで全部経験あります）
- 得意な技術: Java, TypeScript, Next.js, Python, Go, Cursor, Claude code など
- 個人運営スクール: 個人開発や転職にコミットするプログラミングスクール「Programing Factory - ProFact」運営
- 個人開発したサービス運営
そもそも要件定義って？
要件定義とは、システムで解決したい課題を整理して、「何を作るか」と、それと同じぐらいに「何を作らないか」を関係者全員で合意する工程です。機能の足し算をする場ではなく、認識を揃えるための工程、くらいの理解でOKです。
ここけっこう誤解されがちなんですが、要件定義＝「ほしい機能を全部リストに書き出すこと」だと思ってると、だいたい開発後半で詰みます。予算もスケジュールも有限なので、'やらないこと'を決めて線を引くのが重要です。
僕の体感ですが、炎上案件のほとんどは、コードがどうこうより「ここで線が引けてなかった」が原因です。あとは「それもできますねぇ」みたいにいっぱい抱えちゃうとか。作る前の認識合わせをサボると、作った後に「思ってたのと違う」が爆誕します。
要件定義の全体像（誰の・何の課題を・どう解くか）
要件定義は「業務 → 課題 → 要求 → 要件」の順で、抽象から具体へ降りていく地図づくりなイメージです。いきなり機能の話(どんな機能作るかとか)から始めず、まず「誰の・何の困りごとを・どう解くか」を上から順に降ろすのが重要だと僕は思います。
順番で言うとこんなイメージです(業務システム作りたい時を例としてます)。
- 業務：今この人たちは普段なにをしているか（例：紙の予約台帳を電話で埋めてる）
- 課題：そこで何に困っているか（例：ダブルブッキングが月に何件か起きる）
- 要求：だからどうしたいか（例：予約をリアルタイムで一元管理したい）
- 要件：それをシステムでどう実現するか（例：予約登録時に重複チェックして弾く機能）
ここで大事なのは、いきなり要件（機能）から考えないことです。「予約管理機能を作ります」から入ると、それ別に必要じゃないやつ、な開発になる可能性に繋がります。上3つ（業務・課題・要求）が握れてないまま機能だけ決めると、作っても使われないやつが生まれます。
要件定義の進め方
要件定義の進め方は「①現状を知る → ②要る/要らないを仕分ける → ③仮で合わせる → ④文書で合意する」の4ステップです。順番が大事で、特に①を飛ばすと全部ズレます。
それぞれ、どんな感じでやってくかを書いていきます。
ステップ1：ヒアリング（今どうなってるか＝As-Isを把握する）
まず現状の業務を聞きます。ポイントは、決裁者だけじゃなく実際に使う現場の人から聞くと相手のためにもなるし巻き戻りも少なくできます。
- 誰が・いつ・どの作業にどのぐらい時間がかかってるか
- Excelとか紙の手作業が残ってるのはどこか
- 他のシステムとデータのやり取りが必要か
ここで偉い人の「こうあるべき」だけ聞いて作ると、現場で「いや実際はこうやってんだけど…」とかが後出しで出てきて崩壊します。僕は必ず使用場面の運用フロー（As-Is）を図にして、課題リストに落としたりします。
ここで罠があります。相手の曖昧な言葉を「まぁこういうことっしょ」でふんわり受け取らないこと。意図を正確に汲み取る責任は、基本こっち（聞く側）にあると思っておくのが安全です。じゃないとゴミみたいに責任押し付けて出戻りが発生します。
ステップ2：要求を仕分けて優先度をつける
集めた課題から「あるべき業務（To-Be）」を描いて、システム化すべき所と、既存運用のままで十分な所を切り分けます。ここが「何を作らないか」を決める場面です。
理論値で言えば「依頼のもの全部作る」がベストですが、それが決められた人数、時間で達成できるかというとほとんどのケースでそんなん無理です。
そのうえで優先度をつけます。よく使うのが MoSCoW っていう仕分けで、ざっくりこんな感じです。
- MUST：これが無いと成立しない（例：予約の登録・検索）
- SHOULD：できれば欲しい（例：見積の自動作成）
- WANT：あると嬉しい（例：KPIのグラフ表示）
全部MUSTにしたくなる気持ちはわかるんですが、それやると予算もスケジュールも溶けます。「なんでもやります！」は後々自分たちの首を絞めます。限られたリソースで段階的にリリースするために、ここで現実的に削るのが大事です。技術的に無理めなやつは、ちゃんと代替案を出すのが大事です。
ステップ3：プロトタイプで完成イメージを合わせる
文字だけだと人によって想像してるものが全然違うので、画面のイメージを早めに見せて合わせます(これは必須じゃないです)。目的は「完成イメージの共有」なので、この段階では動かなくていいし作り込まなくていいです。あくまで自分たちと相手のイメージの齟齬をなせればOKです。
粒度に応じて道具を変えます。
- ざっくり構想：手書き・ホワイトボード
- 画面構成の初期共有：PowerPoint / Excelでも十分
- 見た目・操作感まで見たい：Figmaとか
初期の「あ、ここ違う」を潰すコストは、本開発後に直すコストの何分の一かで済みます。先に絵で揉めておくほうが、結果的に超ラクです。
※デザインとかはもっと後の工程でデザイン担当に依頼するため、UIのイメージじゃなくてあくまでやりたいことのイメージ合わせレベルの話です。
ステップ4：要件定義書にして合意する
最後に、決まったことを文書にして発注・受注で合意します。要件定義書は実質「ここまでやります、という合意の記録」なので、後でモメたときに効いてきます。
※エンジニア界隈ではよく「言った・言ってない」問題が勃発します。この要件定義にとどまらず、決め事は些細でも文書・テキスト(slackのトーク履歴とか)に残すようにしましょう。口約束だけでやるのは愚策です。
最低限これは絶対書く、というのがこのへん。
- 目的・背景（できればKPIまで。「商談を月◯件にしたい」とか）
- 機能要件と非機能要件を分けて書く（後述）
- 用語集（言葉の定義ズレ対策。後述）
- 変更履歴・承認フロー（誰がいつ何を変えたか）
- コスト/納期/品質のどれを優先するか（MVPで出すのか等）
最近はクラウドの他にもAI前提の案件が増えてきているで、SLAやバックアップ、AIに食わせるデータの範囲・プライバシー、認証や権限まわりも、ここで握っておくとのちのち平和で進められます。
「言った/言わない」を消す具体テク
認識ズレを消す一番の近道は、要件を「主語・条件・受入基準」の3点セットで書くことです。これだけで「言った言わない」のほとんどは消えます。
ダメな書き方とマシな書き方を並べるとこんな感じ。
NG：予約をキャンセルできるようにする
→ 誰が？ いつまで？ できたらどうなったら「OK」なの？ が全部曖昧
OK：
主語：ログイン済みの一般ユーザーが
条件：予約日の前日23:59まで
動作：自分の予約をキャンセルできる
受入基準：キャンセル後、その枠が他ユーザーの予約可能枠に戻ること
特に 受入基準（どうなってたら完成と言えるか） を書いておくのが効きます。これが無いと「動いてはいるけど、それ求めてたやつと違うわ」が起きます。受入基準はそのままテストの観点にもなるので、書いといて損なしです。
要件定義でやりがちな事故
要件定義で事故る原因は、だいたい「①機能から考える ②全部網羅しようとする ③非機能を忘れる」の3つがありがちなんじゃないかと思います。
順番に。
- いきなり機能から考える：さっきの「業務→課題→要求→要件」を飛ばして機能リストから入るやつ。誰の何を解決するんだっけが抜けて、使われない機能が生まれちゃう
- 全部を網羅しようとする：あれもこれも詰め込むと、優先度がぼやけて全部中途半端になります。MUSTを絞らないとプロジェクト進行が詰みます
- 非機能要件を忘れる：「機能はできた、でもクソ遅い」「アクセス集中で落ちる」「データ飛んだ」系
このへんを最初に潰しておくだけで、後工程のやり直しがかなり減ります。
機能要件と非機能要件のざっくり仕分け
機能要件は「何ができるか（What）」、非機能要件は「どれだけ・どう動くか（How）」です。両方そろって初めて"使えるシステム"の要件になってきます。
ざっくりこんな分け方をします。
- 機能要件（What）：ユーザーがやれる操作。例＝会員登録、検索、予約、帳票出力 など。「この画面でこのボタンを押すとこうなる」系
-
非機能要件（How）：機能以外の品質まわり。例:
- 性能（レスポンス1秒以内、同時100人までさばける）
- 可用性・信頼性（稼働率、障害時の復旧、バックアップ）
- セキュリティ（認証・権限・暗号化）
- 法令・コンプライアンス
非機能はつい後回しにされがちなんですが、運用フェーズでややっこくなるのがここです。機能要件と同じぐらい大事なとりきめになってきます。
ついでに、要件定義で押さえるべき項目をチェックリスト的に並べておきます。
- システム要件：そもそも何を実現したいか（目的・対象ユーザー・提供価値）
- 機能要件：何ができるか
- 非機能要件：どれだけ・どう動くか
- 技術要件：言語・フレームワーク・インフラ構成（学習コストも地味に大事）
- 運用要件・制約：運用体制・サポート・教育、納期・予算・使えるリソース
次フェーズ（設計）への渡し方
要件定義の成果物は「設計する人が迷わない粒度」で渡すのがゴールです。細かすぎず、でも判断に必要な情報は欠けてない、くらいの粒度を狙います。
具体的には、要件定義書・As-Is/To-Beの業務フロー・優先度つきの要件一覧・画面イメージ・用語集あたりがそろってると、設計フェーズがだいぶスムーズです。逆にここがフワッとしてると、設計者が「で、これ結局どうしたいの？」となって手戻りします。
要件定義→設計→実装→テスト、と工程はつながっていくので、各工程は「前の工程の成果物を受けて」進みます。
最後に
僕がやっているProFactでは、こういう「上流（要件定義・設計）から下流まで、現役と一緒に手を動かして学ぶ」をやってます。'コードが書ける'だけじゃなく、エンジニアとして立ち回れる力が身につくところが推しポイントです。気になった方はのぞいてみてください。
※副業、Web制作を目指している方はお力になれません…ご了承ください。