仕様書・設計書の読み方｜未経験エンジニアが実装前に確かめる6つの観点【2026年版】

学習中は、作りたいものを自分で決めて作ります。ところが現場に入ると、誰かが書いた仕様書を渡されて「これで実装をお願いします」と言われる。ここで最初の壁にぶつかる人は多いはずです。

書いてあることは分かる。でも、いざ手を動かすと決められない箇所が次々に出てくる。「この項目が空だったときはどうするのか」「エラーになったら何を表示するのか」「上限は何件までなのか」——仕様書に書かれていないことが山ほどある。

そして多くの人が、書かれていないところを自分で埋めて実装し、レビューで「そこは違う」と言われて作り直します。これは技術力の問題ではなく、読み方の問題です。この記事では、実装に入る前に確かめる観点を型にします。

1. 結論：仕様書は「書かれていないこと」を探すために読む

読む目的をここに置くと、動き方が変わります。

読み方	やること	結果
書かれていることを理解する読み方	上から順に読む	分かった気になって着手する
書かれていないことを探す読み方	6つの観点で穴を探す	着手前に質問が出せる

仕様書に穴があるのは、書いた人の落ち度ではありません。すべての条件を漏れなく書ける人はいませんし、書いた時点では想定していなかった場面が必ず出ます。だから、実装する側が穴を見つけて確認する工程が前提として組まれています。

2. 現場で渡される文書の種類

まず、渡されたものが何なのかを見分けます。名前は会社によって違いますが、役割は概ね3つに分かれます。

種類	書かれていること	読む目的
要件・企画の文書	誰の何を解決するか、実現したいこと	目的を理解する
仕様書	画面や機能の振る舞い、条件	穴を探す
設計書	構造、データの持ち方、処理の流れ	既存との整合を確認する

いちばん見落とされるのが1つ目です。目的を読まずに仕様だけ見ると、判断に迷ったときの拠り所がなくなります。「なぜこの機能が必要なのか」が分かっていれば、書かれていない箇所も推測して質問の形にできます。上流の工程に関わる動き方は要件定義・上流工程へ移る｜第二新卒が実装から移るための材料と順番にまとめています。

3. 確かめる6つの観点

実装に入る前に、この6つで穴を探します。

観点	探すこと	質問例
境界	上限・下限・ゼロ件・最大件数	「0件のときの表示は」
異常系	失敗したとき、通信が切れたとき	「保存に失敗したら何を出すか」
権限	誰が見られるか、誰が操作できるか	「一般ユーザーも編集できるか」
同時実行	複数人が同時に操作した場合	「同時更新は後勝ちでよいか」
既存への影響	すでに動いている機能との関係	「既存データの扱いは」
完了の定義	どうなったら終わりか	「どこまでがこの対応範囲か」

とくに1番目と2番目は、ほぼ毎回どこかが抜けています。正常系は書きやすいので誰でも書きますが、異常系は書き漏れやすい。ここを先に洗い出すだけで、手戻りの大半が消えます。

6番目が最も重要

「完了の定義」は、実装量そのものを左右します。管理画面も作るのか、既存データの移行も含むのか、テストデータの投入は誰がやるのか。ここが曖昧なまま進むと、終わったつもりで報告して「まだ残っている」となります。

4. 読む順番

上から順に読むのは効率が悪い。次の順で読むと、穴が早く見つかります。

Step1：目的と完了条件を先に読む（5分）

何のための機能で、どこまでが範囲か。ここを押さえてから中身に入ると、細部の判断が速くなります。

Step2：画面や項目の一覧をざっと見る（10分）

全体の量を把握します。この時点で「思ったより大きい」と分かれば、その事実自体を早く共有できます。

Step3：6観点で穴を探しながら通読する（30分〜）

疑問が出たらその場で書き留める。読み終わってから思い出そうとすると必ず漏れます。

Step4：質問をまとめて一度に投げる（10分）

1つずつ聞くと、相手の時間を細切れに奪ううえ、自分も待ち時間が増えます。まとめて投げるほうが、双方にとって効率的です。質問の作り方はエンジニアの質問の仕方｜未経験・第二新卒が詰まったときに30分で先へ進む型の3点セットがそのまま使えます。

5. 質問の投げ方

穴を見つけたら、質問の形を整えます。ここで工夫すると、答えが早く返ってきます。

投げ方	相手の負担	返答速度
「ここはどうすればいいですか」	ゼロから考える必要がある	遅い
「Aだと思いますが、合っていますか」	可否の判断だけ	速い
「AかBか迷っています。既存はAです」	選ぶだけ	速い

案を添えるのが要点です。未経験でも、既存の実装を見て「たぶんこう」と推測はできます。その推測が外れていても問題はなく、むしろ考えた形跡があるほうが信頼されます。

誰に聞くかを分ける

疑問の種類	聞く相手
「こう動くべきか」という仕様の決め	企画・ディレクター・仕様の作成者
「既存はどうなっているか」	その部分を書いた人、チームのチャンネル
「どこまでやるか」という範囲	直属の上長・リーダー

仕様の決めを技術者に聞き続けても答えは出ません。ここを取り違えると時間だけが過ぎます。

6. 設計書を読むときの追加観点

設計書は、既存のコードとの整合を見るために読みます。

見るところ	確かめること
データの持ち方	既存のテーブルや項目を使うのか、追加するのか
処理の流れ	どこから呼ばれ、どこへ返すのか
外部との連携	他システムに影響するか
命名の規則	既存の書き方に合わせる
設計の意図	なぜその構造になっているか

設計書と実際のコードがずれていることは珍しくありません。古い環境ではとくに起きます。ずれを見つけたら、直すのではなくまず報告する。勝手に合わせると、他の箇所に影響が出ることがあります。古い環境の見分け方はレガシーな開発環境を求人票から見抜く｜第二新卒が入社前に確認する7項目にまとめています。

7. 仕様書がない現場での動き方

小規模な開発では、口頭の依頼だけで進むこともあります。この場合は、自分で書くのが安全です。

受け取った内容を書き起こして返す

「こう理解しました」と箇条書きで返し、相違がないか確認してもらう。5分の作業ですが、認識のずれをここで潰せます。この確認は、後から「言った・言わない」になるのも防ぎます。

決めたことを残す

チャットで決まったことは流れます。決定事項だけを別の場所にまとめておくと、実装中に見返せますし、次の担当者にも渡せます。記録の残し方は議事録と資料作成｜第二新卒が最初に評価される仕事を参考にしてください。

反復型の開発では特に確認が要る

短い周期で作りながら決めていく進め方では、仕様が固まりきらないまま着手することがあります。この場合こそ「今回の範囲はどこまでか」を毎回確認する必要があります。進め方の実態はアジャイル開発の現場｜第二新卒が求人票から実態を読むで扱っています。

8. 読む力が選考でも効く

仕様を読んで穴を出せることは、面接や課題でも評価される部分です。

場面	見られていること	示し方
コーディング課題	曖昧な要件をどう扱うか	前提と判断を提出時に書き添える
技術面接	手戻りを防ぐ意識があるか	着手前に確認した経験を話す
職務経歴書	チームで開発できるか	仕様確認の役割を担った経験を書く

課題を出すときに「この点は仕様に書かれていなかったのでAと解釈しました」と添えるだけで、印象が変わります。正解を当てることより、決めた根拠を示せることが評価されます。課題の出し方はコーディング課題への向き合い方｜提出前にやる5つの確認、技術面接で見られる点はエンジニアの技術面接｜未経験・第二新卒が答えより見られている3つにまとめています。

9. よくある質問

仕様書を読んでも全体像がつかめません

先に目的と完了条件だけを読む順番に変えてみてください。細部から入ると全体が見えなくなります。それでも掴めない場合は、実際の画面や既存の似た機能を触ってみると、文章だけで読むより早く理解できます。

質問が多すぎると迷惑になりませんか

着手前にまとめて聞くのであれば、迷惑にはなりません。むしろ実装後に手戻りが発生するほうが、全体の時間を大きく消費します。1つずつ小出しに聞くのを避け、まとめて出すことだけ意識すれば十分です。

書かれていない箇所を自分で決めてはいけませんか

決めてよい範囲と、決めてはいけない範囲があります。表示の細かな体裁など影響の小さい部分は判断して進め、その旨を報告すれば足ります。金額の扱い、権限、データの削除に関わる部分は必ず確認してください。

設計書とコードが違っていました

まず報告してください。設計書が古いのか、コードが仕様どおりでないのか、どちらなのかによって対応が変わります。自分で判断して片方に合わせると、他の機能に影響が出る可能性があります。

仕様の作成者と連絡が取りづらいです

チームのリーダーや上長に、確認の経路を相談してください。着手できない状態が続くこと自体が報告すべき事実です。返答を待つ間に進められる部分があれば、そこから着手するのが現実的な進め方です。

未経験でも仕様に意見を言っていいですか

言って構いません。実装する立場から見た矛盾や抜けの指摘は、経験年数に関係なく価値があります。ただし「おかしい」ではなく「この条件のときにどうなるか分からない」という形で出すと、受け取られ方が良くなります。

読むのに時間がかかりすぎている気がします

慣れるまでは時間がかかって当然です。ただし、読むだけで半日以上使っている場合は、規模が大きすぎるか粒度が細かすぎる可能性があります。その状態をリーダーに共有すると、分割してもらえることがあります。

仕様書の書き方も覚えたほうがいいですか

読めるようになると、自然に書けるようになります。無理に先回りする必要はありませんが、口頭の依頼を自分で書き起こす練習を続けていれば、上流の工程に移るときの材料になります。

10. まとめ：今週やる3つのこと

仕様書は理解するために読むのではなく、書かれていないことを見つけるために読む。この一点を変えるだけで、手戻りは大きく減ります。

今週やる3つのこと

① 手元の仕様書を、目的と完了条件から読み直す

② 境界・異常系・権限・同時実行・既存への影響・完了の定義の6観点で穴を書き出す

③ 出た疑問に自分の案を添えて、まとめて一度に質問する

読み方の型を持っている人は、経験年数に関係なく信頼されます。ここは早い段階で身につく価値のある部分です。

この先、読むべき記事

• エンジニアの質問の仕方｜未経験・第二新卒が詰まったときに30分で先へ進む型（疑問の投げ方）
• 要件定義・上流工程へ移る｜第二新卒が実装から移るための材料と順番（仕様を書く側へ）
• コードレビューの受け方｜第二新卒が指摘から伸びるための3つの姿勢（指摘から学ぶ）
• アジャイル開発の現場｜第二新卒が求人票から実態を読む（進め方の違い）
• エンジニアの1日の流れ｜入社前に知っておくこと（現場の時間の使われ方）

この記事を書いた人

木戸 悠介（きど ゆうすけ）／なぜキャリア？運営者。1996年生まれ、神戸市出身。

23歳で上場企業子会社に新卒入社し、メディア広告営業を担当。25歳で第二新卒として障がい福祉領域のSaaS企業へ転職し、営業から営業企画へ職種を変えた。2ヶ月で10社に応募し2社から内定。その後スタートアップに3人目の社員として参画し、現在は自分の会社を経営している。