この記事はLITALICO Engineers Advent Calendar 2025 シリーズ4の20日目の記事です。
カレンダーは4枚あるので、ぜひこちらもご覧ください 
- シリーズ1: 「Figma Makeで社内ボドゲをオンライン化したら組織活性化につながった話」 by @yoshika_nakajima さん
- シリーズ2: 「『分析者が本当に必要なデータマート』を作るためにデータエンジニアが毎日マーケターと話してわかったこと」 by @KakkiiiiKyg さん
- シリーズ3: 「支援現場に触れたエンジニアに起きた「解像度」の変化」 by @ancient_city さん
はじめに
LITALICOの@tomoki-okeです。障害福祉領域の転職サイトLITALICOキャリアの開発を行っています。
早いもので入社して7年目になりました。ここ2年前くらいから、要件定義を担当する機会が増えてきました。今回はそんな要件定義について書きます。
正直、自分は実装がパズルに近い感覚で好きです。その点、実装に比べると要件定義はゴールが見えづらく、ソースコードや動く画面のような分かりやすい最終成果物はないです。実装とは頭の使い方が違っていて、2年前は要件定義が「難しくて、大変で、少し退屈なタスク」だと感じていました。
ここ2年「要件定義とはなにか？」に悩みながら取り組んできた結果、自分なりの答えが見えてきました。
要件定義の目的・やりがいが見いだせてなかった3年前の自分に「要件定義は案外面白い」とメッセージを送るつもりで、今自分が考える「要件定義とはなにか？」を書き残してみようと思います。
要件定義とはなにか？
「要件定義とは何？」とAIに聞いてみると、「なにを、どのように作るかを定義すること」 という答えが返ってきます。
言葉としては理解できますが、実務に落とし込もうとすると、「どこまで細かく定義すればいいの？」 という疑問にぶつかりました。
終わらない「どこまで書くか」問題
要件定義と一口に言っても、外部パートナーに依頼するなら正確なドキュメントが必要でしょうし、大規模な新規施策なら膨大な情報量になります。
一方で、私が普段向き合っているのは、気心の知れた自チームのメンバーと、10人日程度で進める開発です。「あまり書きすぎてもムダになりそう」と思う反面、いざ筆を動かそうとすると、以下のようなモヤモヤが次々と湧いてきました。
- 「なにを」の壁： PdMが書いたIssueに概要はある。これ以上、何を深掘りすればいいのか？
- 「どのように」の壁： 「極論、作れば決まること」を、事前にどこまで決めきるといいのか？
- 「渡す相手」への不安： 別のエンジニアにタスクを振る際、どこまで書けば情報不足にならないか？
「書かなさすぎて情報不足になる不安」と「書きすぎて時間を溶かしてしまう罪悪感」の板挟みになり、要件定義のたびに手が止まってしまっていました。
先輩の何気ない一言からの気づき
そんな時、要件定義をテンポよくサクッと済ませる先輩に相談してみました。
「渡す相手（人）に合わせて、どこまで詰めるかを変えているよ」
この言葉を聞いて、なるほどと思いました。情報の過不足がない「要件定義書」という成果物を作るのがゴールではありません。記載がなくても伝わる部分は割愛してもいいですし、逆にフォローしたい部分は書いた方が良いです。
要件定義する自分と開発担当者、前段の要求や要件定義をともに行うPdM・デザイナーのチーム全体で、いいアウトプットが出せればいいです。
要件定義とはバトンを渡しながら進めるシステム開発というプロセスの中で、「不確実性を減らすこと」そのものが目的だったのだと、その時ようやく気づくことができました。
システム開発全体の流れから要件定義を捉え直す
「ユーザーが抱える問題を、正しく解決しているシステム」 は良いシステムだと思いますが、そのためには、以下のステップを一段ずつ踏んでいく必要があります。
- ユーザーの問題を正しく捉え、解決すべき課題を設定する（要求分析）
- 課題を解決するためのシステムの振る舞いを決める（要件定義）
- 定義された振る舞いを、実際に動く形にする（設計・実装）
各職種の担当パートを色分けしていますが、各職種が専門性を発揮しながら、企画からリリースまで 「バトン」を繋いでいくイメージです。このバトンとは、言い換えれば「論理的な意思決定の積み上げ」 です。
要件定義はまさにその中間地点にあたり、「前段の要求」を深く理解し、「後続の実装」が可能な状態へと翻訳する、架け橋のような役割を担っています。
なぜ、わざわざ「開発前」に情報をまとめるのか？
あえて開発前に情報をまとめることの意味は何でしょうか？自分は3年前以前、要件定義を意識せずに開発してきましたが、その時遭遇した問題を思い出すと
- 開発後半で機能不足に気づいて、途中で機能追加が発生する。結果的に工数が追加で必要になり、リリース日が遅れる
- リリース後に、本来一緒に改修したかった箇所が発覚し、後追いでぱらぱらとリリースが必要になる
- 実装しながら芋づる式に実装箇所が増えていき、想定よりも影響範囲が広がり、リリース日が後ろ倒しになる
こうした問題はすべて、「開発の後半（V字の右側）」で発覚したからこそ、問題が大きくなったと言えます。V字モデルをベースに考えてみると 「開発後に気づくと手戻りが大きくなるリスク」を、より早い段階（V字の左側）で先回りして気づけるとよいです。
「この要件なら、ここの影響範囲が広がりそうだ」「このパターンは考慮漏れではないか」と事前に気づくことができれば、その場で「やらない」という判断をしたり、よりシンプルな構成に舵を切ったりすることができます。
エンジニアが要件定義することの付加価値・やりがい
エンジニアにしかない観点で、開発上の石ころを取り除く貢献ができる
開発フロー図を見ると分かりますが、施策の後半はエンジニアのターンです。この後半のエンジニアがフルスイングできる状態を作るために、事前にリスク対処するのが要件定義の役割です。
ただし、先程書いたような開発途中で遭遇する問題はエンジニアでなければ気付くのが難しいです。スムーズに開発を進める準備は、エンジニアだからこそできる仕事だと思います。
普段の実装がユーザー価値につながる実感が持てる
要件定義はまさにその中間地点にあたり、「前段の要求」を深く理解し、「後続の実装」が可能な状態へと翻訳する、架け橋のような役割を担っています。
と書きましたが「要求を満たす要件を定義して、実装可能な状態に落とし込む」という過程を実践することで、実装によりユーザー体験を変え（ようとし）ているという実感を強く持てるようになりました。
チームで働いてる実感が持てる
バトンの例を出したように、要件定義はPdM・デザイナー・エンジニアの3者と連携するタスクになるので関わり合う人・タイミングが増えました。
PdMが少しふわっとした要求を渡してくれると「信頼されてる」と感じて「頑張るぞ！」と思えますし、エンジニアに開発を依頼するときは「ここからは頼んだ！」という気持ちで渡すので、開発がスムーズに進んで機能がリリースされると嬉しいです。
まとめ
2年ほど経過して、実装が好きだけど要件定義も割と好きかもと思えるようになってきました。実装をユーザー価値に繋げられる実感が持てるようになったことは、最近の仕事の楽しさや自信に繋がっていると感じます。
要件定義を担当することになったけど楽しさが分からない...と思っている数年前の自分みたいな方に届くと良いなと思います。
LITALICO Engineers Advent Calendar 2025は明日も新しい記事が公開予定です！
ぜひそちらもご覧ください
- シリーズ1: 「GitHub Actions 入門 〜RSpec自動化事例〜」 by @eggc さん
- シリーズ3: 「レビュー環境はじめました」 by @EXcEption2zero さん
- シリーズ4: 「MBOを"自己統制ツール"として使い倒すための7つの視点」 by @makitoc さん