【第1-1回】要件を読み解く力：何を作るのかを正しく理解する
はじめに
皆さん、こんにちは！
連載 「新人エンジニアが独り立ちするためのプロジェクト開発入門」、記念すべき第1回へようこそ。
プロジェクトに配属され、初めてのタスクを任された時、多くの新人がこう思います。
「よし、早くコードを書いて認められたい！」
その気持ち、非常によく分かります。ですが、少しだけ立ち止まってください。凄腕のシェフが、お客様の注文を聞かずにいきなり料理を始めないのと同じように、私たちエンジニアも、「何を作るべきか」を正確に理解することから仕事が始まります。
この最初のステップを疎かにすると、
「作ったはいいけど、思ってたのと違う…」
「ユーザーが本当に欲しかった機能はこれじゃなかった…」
といった悲しい手戻りが発生し、自分だけでなくチーム全体の時間も奪ってしまいます。
そこで今回は、開発の羅針盤とも言える**「要件」**を正しく読み解き、自信を持って開発のスタートラインに立つための技術について、深掘りしていきます。
1. 開発の地図と設計図：「要件定義書」「仕様書」ってなんだ？
タスクを任されると、「詳細は仕様書見ておいて」と言われることがよくあります。そもそも「要件定義書」や「仕様書」とは何者で、どこに注目すれば良いのでしょうか。
プロジェクトの憲法：要件定義書
要件定義書とは、一言でいうと**「このプロジェクトで、何を・なぜ作るのか」**を定めた、最も大元になるドキュメントです。お客様（クライアント）やサービス企画者が「こんな課題を解決したい」「こんな世界を実現したい」という想いを、機能として具体化する一歩手前の段階でまとめられたものです。
ここには、プロジェクトの根本的な目的が書かれています。
機能の設計図：仕様書
仕様書は、要件定義書で決まった「作ってほしいもの」を、**「じゃあ、具体的にどう作るのか」**に落とし込んだ、開発者向けのより詳細な設計図です。
仕様書には、以下のような種類があります。（プロジェクトによって呼び方や粒度は様々です）
- 機能仕様書： ログイン機能、投稿機能など、機能単位での振る舞いを定義します。「このボタンを押したら、この画面に遷移する」といったレベルで書かれています。
- 画面仕様書： 画面のレイアウトや、どこにどの項目を表示するかなどを定義します。ワイヤーフレームやデザインカンプがこれにあたることもあります。
- 外部設計書/内部設計書： ユーザーから見える部分の設計（外部設計）と、データベースのテーブル構造や処理の内部ロジックなどの設計（内部設計）を定義します。
新人がまず見るべきポイントはここだ！
膨大なドキュメントを前に圧倒されてしまうかもしれませんが、大丈夫です。まずは以下のポイントに絞って、全体像を掴むことから始めましょう。
-
✅ プロジェクトの目的・背景
- なぜ？：このシステムは、誰の、どんな課題を解決するために作られるのか？これを理解すると、自分の作業がどう社会やユーザーの役に立つのかが見え、モチベーションが格段に上がります。
-
✅ 機能一覧
- 何を？：どんな機能があるのか、全体像をざっと眺めましょう。自分が担当する機能が、システム全体の中でどのような役割を担っているのかが分かります。
-
✅ 登場人物（アクター/ユーザーロール）
- 誰が？：このシステムを使うのは誰か？「管理者」「一般ユーザー」「ゲストユーザー」など、役割によって使える機能が違うことがほとんどです。自分が作る機能の利用者像をイメージしましょう。
-
✅ 用語集
- 言葉の定義：プロジェクトには、その現場でしか通じない固有の単語や略語が必ず存在します。「〇〇マスタ」「△△フラグ」など、分からない言葉があれば、まず用語集を探してみましょう。
これらを最初に押さえておくだけで、自分がこれから作ろうとしているものの解像度がぐっと上がり、先輩との会話もスムーズになります。
2.「分からない！」を乗り越える調査と質問の技術
仕様書を読んでも、必ず「これってどういう意味だろう？」「この場合の考慮が抜けているのでは？」といった疑問が出てきます。これは、あなたが未熟だからではありません。疑問を持てること自体が、あなたが真剣にタスクに向き合っている証拠です。
大切なのは、その「分からない」をどう解消していくか、その方法論です。
ステップ1：探偵になれ！まずは自分で調べる
いきなり先輩に「分かりません！」と駆け込む前に、まずは自分で調査する癖をつけましょう。これは、自走力を高めるための重要なトレーニングです。
＜調査対象リスト＞
-
プロジェクト内のドキュメント (Wiki, Confluence, Notionなど)
- まずは公式情報を探します。キーワード検索を駆使して、関連ページがないか探しましょう。
-
過去のチケット (Jira, Backlog, Redmineなど)
- 今回作る機能と似たような機能のチケットが過去になかったか探します。過去のやり取りの中に、仕様決定の経緯や実装のヒントが眠っていることは非常に多いです。
-
チームのチャットログ (Slack, Teamsなど)
- 過去に同じような疑問を誰かが議論していなかったか、チャットの検索機能で探してみましょう。
自分で調べるプロセスは、たとえ答えが見つからなくても無駄にはなりません。「ここまで調べた」という事実が、次の質問フェーズで絶大な効果を発揮します。
ステップ2：質問の質を高める魔法のフレームワーク
自分で調べても解決しなかった場合、いよいよ質問の出番です。しかし、ここでも作法があります。相手の時間を尊重し、的確な回答をもらうためには「質問の質」が重要になります。
❌ 悪い質問の例
「すいません、〇〇の仕様が分かりません。教えてください。」
これでは、相手は何が、どの程度分からないのか分からず、「仕様書のどこを読んだの？」という確認から始めなければなりません。
⭕️ 良い質問のフレームワーク
以下の5つの要素を意識して質問を組み立ててみましょう。
- 【前提】 自分が今どのタスク（チケット番号など）をやっているか
- 【目的】 そのタスクで何を実現しようとしているか
- 【現状・試したこと】 自分で調べたこと、分かったこと、分からなかったこと
- 【仮説・自分の考え】 自分はこうではないかと考えている、という意見
- 【質問】 具体的に何を知りたいのか、ピンポイントで聞く
＜質問テンプレート＞
お忙しいところ失礼します。チケット
#123「ユーザープロフィール編集機能の実装」について質問です。(前提・目的)
プロフィール項目に「ニックネーム」を追加する実装を進めています。(現状・試したこと)
仕様書を読むと「ニックネームはいつでも変更可能」とありますが、文字数制限についての記載が見当たりませんでした。
類似機能である「ユーザー名」の仕様をチケット#88で確認したところ、こちらは20文字という制限がありました。(仮説・自分の考え)
おそらくニックネームにも同様の文字数制限（20文字）を設けるべきだと考えているのですが、この認識で合っていますでしょうか？(質問)
ニックネームの文字数制限について、仕様がもし決まっていれば教えていただけますでしょうか。また、決まっていなければ、何文字にするのが良さそうかご意見を伺えますでしょうか。
この聞き方をすれば、質問された側は「ああ、ちゃんと自分で調べた上で、的を射た質問をしてくれているな」と感じ、すぐに具体的な回答ができます。あなたの評価も上がり、一石二鳥です。
3.「なぜ？」を問うことの絶大な効果
最後に、新人から一歩抜け出し、「デキるエンジニア」になるための最も重要なマインドセットをお伝えします。それは、仕様の「なぜ？」を常に考える癖をつけることです。
言われた通りに作る「作業者」で終わるか、ビジネスに貢献する「開発者」になれるかは、この「なぜ？」を考えられるかどうかにかかっています。
なぜ「なぜ？」が重要なのか
-
① 最適な実装を選択できる
- 例えば、「このデータはCSVでダウンロードできるようにして」という要件があったとします。
- なぜ？ → 「営業チームが毎月の実績集計で使うため」
- この背景を知れば、「それならCSVより、リアルタイムで集計が見られるダッシュボード画面を作った方が、営業さんはもっとハッピーになるのでは？」という代替案や改善案を提案できます。
-
② 予期せぬ不具合を防げる
- 例えば、「投稿したメッセージは削除できること」という要件があったとします。
- なぜ？ → 「間違って投稿した時に修正したいから」
- この背景を知れば、「誰かの投稿に返信が付いている場合、元の投稿が消えると文脈が分からなくなるな。削除ではなく『削除済みです』という表示に変えるべきでは？」と、仕様の考慮漏れに気づくことができます。
-
③ 仕事が圧倒的に面白くなる
- 自分が書いているコードが、誰のどんな課題を解決し、どう喜ばれるのか。その繋がりが見えると、目の前の単調に見える作業も、大きな価値を生むための重要なピースであることが分かり、やりがいを感じられます。
「なぜ？」を考えることは、仕様書に書かれていることの裏側にある「本当の目的」を探る旅です。この視点を持つことで、あなたの作るものの価値は飛躍的に高まります。
まとめ
今回は、プロジェクト開発の第一歩である「要件を読み解く力」について解説しました。
- 要件定義書や仕様書は、開発の地図であり設計図。まずは目的や全体像を掴もう。
- 分からないことは、まず自分で調べ、整理してから質問する「質問の技術」を身につけよう。
- 仕様の背景にある「なぜ？」を考えることで、単なる作業者から価値を創造する開発者へ進化しよう。
コードを書くスキルはもちろん重要ですが、この「要件を正しく理解する力」は、エンジニアとしてキャリアを築いていく上で、同じくらい、あるいはそれ以上に重要な土台となるスキルです。
ぜひ、明日からの業務で、一つでも意識してみてください。
次回は、**【第1-2回】技術選定の裏側：なぜこの技術が使われているのか？**をお届けします。お楽しみに！