当サイトの記事は編集部が国土交通省・IPA・デジタル庁などの公的機関の情報、規格や業界団体の公開情報を調べて独自に執筆しています。記事内にIT・Webエンジニアの転職サービスへの案内（広告）を含みます。
『仕様書を書く仕事って、具体的に毎日何をしているの？』と気になっている方も多いはずです。SEやPM、社内SEと呼び名もいろいろで、違いが分かりにくいですよね。
結論から言うと、仕様書の仕事は「書く人」「読んで作る人」「発注側でまとめる人」の3つの立場に分かれます。
この記事を読めば、システムエンジニアの仕事内容と、職種ごとの仕様書との関わり方が分かります。
仕様書を書く仕事とは？SEの仕事内容をひとことで言うと
仕様書を書く仕事の中心は、システムエンジニア（SE）です。お客さんや社内の担当者から話を聞き、どんなシステムを作るかを文書に落としていきます。
『SEってプログラムを書く人じゃないの？』と思う方もいますよね。実は、SEの仕事内容の多くは、作る前に決めて、決めたことを書き残す作業なんです。
厚生労働省の職業情報サイト「job tag」の「システムエンジニア（受託開発）」（2025年11月時点の写し）では、仕事の流れがこう紹介されています。
| 工程 | SEがすること | 主に作る文書 |
|---|---|---|
| 要件定義 | お客さんに業務の流れや書類の種類・量を聞き、どんなシステムにするか決める | 要件定義書 |
| 基本設計 | データベースや外部システムとの連携、画面の構成を固める | 基本設計書 |
| 詳細設計 | データ形式や内部の処理、操作画面の細かい所を決め、処理の流れを細かく分ける | 詳細設計書 |
| テスト | テスト計画を作り、単体・結合・総合テスト、受け入れテストを進める | テスト計画書・テスト仕様書 |
| 導入・保守 | システムを導入し、その後の保守や管理も担う | 運用の手順書など |
システムエンジニアの仕事内容は「決める・書く・確かめる」
表を見ると、SEの仕事は大きく3つに分けられます。何を作るか決めること、決めたことを仕様書や設計書に書くこと、書いたとおりにできたかテストで確かめることです。
同じページでは、プログラマーは「SEが作成した詳細設計書に基づいてコーディング」する仕事として紹介されています。つまり、SEが書いた文書が、次の人の仕事の出発点になるんです。
仕様書がなぜ大事なのか
例えば、ネットショップの注文画面を作る場面を考えてみてください。「送料は合計金額によって変わる」とだけ書かれていたら、作る人によって計算の仕方がバラバラになりますよね。
いくら以上で無料になるのか、離島はどうするのか。こうした決めごとを、誰が読んでも同じに伝わる形で書くのが仕様書の役目です。仕様書そのものの意味は仕様書とは？意味と目的で詳しく紹介しています。
job tag には「社内SE」という名前の職業ページは見当たりませんでした。ただ、SEやプロジェクトマネージャの勤め先として「一般企業の情報システム部門」が挙がっていて、そこで働くSEが一般に社内SEと呼ばれています。
仕様書に関わる職種は3つの立場に分かれる
仕様書との関わり方で職種を分けると、「書く（SE・PM）」「読んで作る（プログラマー）」「発注側でまとめる（社内SE）」の3つになります。同じ仕様書でも、立場によって見る所が違います。
『SE、PM、PG、社内SE…結局どう違うの？』という声はよく聞きます。呼び名で覚えるより、仕様書をどう扱うかで並べるとすっきりしますよ。
| 立場 | 主な職種 | 仕様書との関わり | よく使う文書 |
|---|---|---|---|
| 書く | SE・PM | 要望を聞いて、何を作るかを決めて書く | 要件定義書・基本設計書・詳細設計書 |
| 読んで作る | プログラマー | 設計書を読み、そのとおりにプログラムを作る | 詳細設計書・テスト仕様書 |
| 発注側でまとめる | 社内SE・情報システム部門 | 社内の要望を集めて、外部の開発会社に伝える | 要件定義書・RFP・調達仕様書 |
書く立場：SEとPM
SEは、要件定義から設計までの文書を書く中心の人です。PMは、プロジェクト全体の計画や予算、人の割り振り、進み具合を管理する立場になります。
job tag の「プロジェクトマネージャ（IT）」（2026年10月時点の写し）では、終わった後に顧客向けの資料や、運用・管理に必要なドキュメントを作ることも仕事に挙がっています。PMも、書く仕事から離れるわけではないんです。
読んで作る立場：プログラマー
プログラマーは、設計書を読み解いてプログラムに置き換える人です。設計書のあいまいな所に最初に気づくのも、この立場の人であることが多いです。
「この場合はどう動けばいいですか？」と質問を返す力も大事な仕事の一部です。読む経験を積むと、書く側に回った時に「つまずかない書き方」が分かるようになります。
発注側でまとめる立場：社内SE
社内SEは、自分の会社の中でシステムを使う人の声を集め、開発会社に伝える立場です。開発を外に頼む時は、要件定義書や提案依頼書（RFP）を書くこともあります。
IPAの「超上流から攻めるIT化の原理原則17ヶ条」には、「要件定義は発注者の責任である」という一文があります。発注側でまとめる仕事が軽いわけではないことが、この言葉からも分かりますよね。
SE・PM・社内SEの仕事内容はどう違う？
SEは「何を作るか決めて書く」、PMは「プロジェクトを最後まで進める」、社内SEは「自社の困りごとをシステムで解く」のが中心です。どの職種も、仕様書を読む・書く場面は多くあります。
『SEとPMって、上司と部下みたいな関係？』と思う方もいるかもしれません。役割が違うだけで、上下で分けるとかえって分かりにくくなります。
- お客さんの要望を聞いて、作る物を決める
- 設計書を書き、チームで作り上げる
- 納期と品質に責任を持つ
- いろいろな業界のシステムに関われる
- 社内の要望を集めて、優先順位をつける
- 開発会社に仕様を伝え、出来上がりを確かめる
- 導入後の使い方や問い合わせにも対応する
- 自社の業務に深く詳しくなれる
SE：工程ごとに書く物が変わる
SEは、担当する工程によって書く文書が変わります。要件定義なら業務の流れや必要な機能、基本設計なら画面や帳票、詳細設計なら内部の処理です。
job tag の「システムエンジニア（受託開発）」では、一般的に3年目頃には一人で詳細設計を書けるようになり、5年目頃には基本設計を含む開発全体ができるようになると紹介されています。いきなり全部を任されるわけではないので、安心してくださいね。
PM：計画と管理が中心
PMは、プロジェクトの実行計画を作り、予算や要員、進捗を管理します。job tag では、プロジェクトの規模は数人から数十人、場合によっては全体で数百人規模になると紹介されています。
SEとして構築や運用を経験した人がPMになることが多い、とも書かれています。SEの経験が、そのままPMへの道につながっているんです。
プログラマーとSEの境目はどこ？
職場によっては、SEとプログラマーをはっきり分けていないこともあります。設計書を書いた人が、そのままプログラムも作るケースも珍しくありません。
求人票で「SE」と書かれていても、実際に任されるのが製造とテスト中心ということも。名前より「どの工程の文書を書くか」を見ておくと、入ってからのずれが減りますよ。
社内SE：使う人に一番近い
社内SEは、システムを毎日使う社員のすぐそばにいます。「この画面、入力が多すぎて大変なんだけど」という声を聞いて、直すかどうかを決めるところから関わります。
開発会社とのやり取りでは、社内の言葉を開発側の言葉に置き換える役割も担います。社内SEの働き方は社内SEと仕様書でも紹介しています。
| 比べる所 | SE | PM | 社内SE |
|---|---|---|---|
| 主な相手 | お客さん・開発チーム | お客さん・チーム全体 | 社内の利用者・開発会社 |
| 一番多い文書 | 要件定義書・設計書 | 計画書・進捗の報告 | 要件定義書・RFP・社内向けの手順 |
| 喜ばれる場面 | 決めたとおりに動いた時 | 予定どおり完成した時 | 社内の業務が楽になった時 |
| 大変になりやすい所 | 仕様の変更が続く時 | 遅れや予算の調整 | 社内の要望がまとまらない時 |
プロジェクトの流れで見る、仕様書が出てくる場面
SEの1日は、打ち合わせ、文書を書く時間、確認とレビューの組み合わせです。どの工程にいるかで、時間の使い方が大きく変わります。
『毎日パソコンに向かって黙々と書いているの？』と想像する方もいますよね。実際は、人と話す時間もかなり多い仕事です。
- 要望を聞く打ち合わせで、今の業務の流れや困っていることを聞き取る
- 要件定義書に、作る機能と守る条件をまとめて合意する
- 基本設計書・詳細設計書で、画面や処理の中身を決める
- プログラマーが設計書をもとに作り、SEが質問に答える
- テスト仕様書に沿って動きを確かめ、受け入れテストを経て導入する
要件定義の頃：聞く時間が長い
最初の頃は、お客さんや社内の担当者と話す時間が中心です。「今は紙の伝票を何枚書いていますか？」のように、業務の具体的な所まで聞いていきます。
話した内容は、その日のうちに議事録や要件のメモに残しておきます。後で「言った・言わない」にならないようにするためです。
設計の頃：書く時間とレビューが増える
設計に入ると、文書を書く時間が一気に増えます。書いた設計書は、先輩やチームの人に読んでもらうレビューを受けます。
「この項目、入力しなかった時はどうなる？」といった指摘をもらい、直していく流れです。指摘をもらうのは、仕様書の質を上げる大事な場面なんです。
テストの頃：仕様書どおりか確かめる
作り終わったら、仕様書どおりに動くかを確かめます。うまく動かない時は、作り方の問題か、仕様書の書き方の問題かを見分けるのもSEの仕事です。
導入・保守の頃：仕様書が「説明書」に変わる
システムが動き始めた後も、仕様書の出番は続きます。「この画面のこの項目は何のためにあるの？」と聞かれた時、答えの根拠になるのが仕様書です。
改修の相談が来た時も、まず今の仕様書を開いて、どこを変えるとどこに影響が出るかを調べます。数年後に別の人が読んでも分かるように書いておくと、保守の担当者がとても助かるんです。
| 工程 | SEの時間の使い方 | 仕様書の役割 |
|---|---|---|
| 要件定義 | 打ち合わせと聞き取りが中心 | 決めたことの合意の記録 |
| 設計 | 書く時間とレビューが中心 | 作る人への指示書 |
| テスト | 確認と不具合の切り分けが中心 | 正しい動きの基準 |
| 導入・保守 | 問い合わせと改修の検討が中心 | システムの説明書 |
決まったことを口頭だけで済ませてしまい、仕様書に反映し忘れることがあります。テストの段階で「聞いていた話と違う」となりやすいので、決まったことはその都度、文書に書き足しておきましょう。
仕様書を書く仕事に向いている人
仕様書を書く仕事は、人の話を聞いて整理するのが好きな人に向いています。プログラミングの得意・不得意だけで向き不向きは決まりません。
『理系じゃないと無理なのでは？』と心配になる方も多いはずです。job tag の「システムエンジニア（受託開発）」でも、文系の人も多いと紹介されています。
- 人の話を聞いて、要点を短くまとめるのが苦にならない
- 「これってどういう時に起きるの？」と例外を考えるのが好き
- 決まったことを文書に残すのが面倒ではない
- 分からない所を、そのままにせず質問できる
- 新しい業界や業務の話を聞くのが楽しい
つまずきやすい所
一方で、つまずきやすい所もあります。お客さんの言葉があいまいなまま進めてしまい、後で作り直しになるのが典型的な例です。
「たぶんこういう意味だろう」と思った所ほど、「念のため確認させてください」と聞き返すくせをつけておくと安心です。仕様書の書き方のコツは仕様書の書き方にもまとめています。
| つまずく場面 | 起きやすいこと | 先にできる工夫 |
|---|---|---|
| 要望を聞く時 | 言葉の意味を取り違える | 具体例を1つ出して確かめる |
| 文書を書く時 | 書く人によって表現がばらつく | 用語の一覧を先に作る |
| 仕様が変わる時 | どこを直したか分からなくなる | 版と変更の履歴を残す |
| テストの時 | 仕様書に無い動きが見つかる | 例外の場合を設計の時点で書く |
よくある相談：SEの仕事内容がつかめない・つらい
「SEの仕事内容が具体的に分からない」「細かさがつらい」という相談はとても多いです。どちらも、工程と立場で分けて考えると見通しがよくなります。
『調べても要件定義とか設計とか、言葉ばかりでイメージできない』という声、ありますよね。Q&Aサイトでよく見かける相談を、要約してお答えします。
相談1：SEは毎日何をしているのか、簡単に知りたい
業界研究をしていて、SEの仕事内容がイメージできないという相談です。閲覧数の多い質問で、同じ悩みの方がたくさんいることが分かります。
簡単に言うと、「何を作るか聞いて決める」「決めたことを書く」「書いたとおりにできたか確かめる」の繰り返しです。今どの工程にいるかで、話す時間が多いか書く時間が多いかが変わります。
相談2：基盤系SEとは何をする人？
アプリのSEとは別に、基盤系（インフラ）のSEがいると聞いて、違いが分からないという相談です。
job tag の「システムエンジニア（基盤システム）」では、ITインフラを設計・開発する仕事として紹介されています。設計の工程では、機能や構成、性能、信頼性、予算、開発工程を内容とする設計書を作るとあります。扱う対象が違うだけで、要件を決めて設計書を書く流れは同じなんです。
相談3：細かい作業と完璧さを求められて苦しい
新卒2年目で、細かさと高い水準を求められ続けるのがつらいという相談もありました。仕様書の仕事は、確かに細かい所まで決める必要があります。
ただ、一人で完璧に書く必要はありません。レビューで直してもらう前提で、早めに下書きを見せるやり方に変えると、気持ちがぐっと楽になることも。
今の工程が合わないと感じる時は、職種を変えずに担当工程や立場を変える道もあります。開発する側から発注する側へ移る人もいます。
仕様書を書く仕事に就くには
仕様書を書く仕事に就くのに、決まった学歴や資格はいりません。まず読む・作る側の経験を積み、少しずつ書く側に回っていくのが一般的な道です。
『今から目指しても間に合う？』と迷っている方もいますよね。job tag では、特に学歴や資格は必要とされないと紹介されています。
- 設計書や仕様書を読む経験を積む（プログラマーやテストの担当）
- 小さな機能の詳細設計を任せてもらう
- 基本設計や要件定義の打ち合わせに同席する
- 情報処理技術者試験などで知識を形にする
- 要件定義から任される職場へ移る、または社内で担当を広げる
未経験から目指す場合
ITの仕事が初めての方は、まず仕様書を読む側から始めるのが近道です。未経験からの道のりは未経験からITエンジニアへで、段階ごとに紹介しています。
上流の工程に進む道筋は上流工程とは？で詳しくまとめました。どこまで経験を積めば次に進めるのかの目安になります。
今の職場で経験を積むか、職場を移るか
今の職場で上流の工程に関われそうなら、まずはそこで経験を積むのも立派な選択です。資格を取ってから動く方法もあります。
一方で、今の会社ではテストや製造の工程しか担当できないこともあります。その場合は、求人の仕事内容を比べてみると「どの工程を任されるか」がはっきり見えてきます。
要件定義や設計書を書く経験は、上流工程を任される職場で評価されやすいものです。今の担当工程から一歩進みたい方は、求人の仕事内容を比べてみると道が見えてきます。
IT・Webエンジニアの転職（PR）
仕様書を書く経験を活かせる職場を探すなら、求人も比べてみる
要件定義や設計を任されるか、発注側か開発側か、扱うシステムや働き方は会社によって大きく違います。担当したい工程や条件から、IT・Webエンジニアの求人を比べてみてください。
無料ITエンジニアの求人を探す求人の条件・待遇は各求人票と応募先の案内でご確認ください。
職種ごとのお給料の目安はシステムエンジニアの年収で、公的統計をもとに紹介しています。転職を考える時の求人票の見方は要件定義・設計の経験を活かす転職が参考になります。
よくある質問
SEの仕事内容はプログラミングが中心ですか？
プログラミングをするSEもいますが、仕事の中心は何を作るかを決めて文書にすることです。工程によっては、話を聞く時間と書く時間がほとんどになります。
仕様書を書く仕事は文系でもできますか？
できます。job tag でも、システムエンジニアには文系の人も多いと紹介されています。人の話を聞いて整理する力が活きる仕事です。
社内SEも仕様書を書きますか？
書きます。社内の要望をまとめた要件定義書や、開発会社に提案を頼む時の提案依頼書（RFP）を作ることがあります。
一人で設計書を書けるようになるまで、どのくらいかかりますか？
job tag の「システムエンジニア（受託開発）」では、一般的に3年目頃に一人で詳細設計、5年目頃に基本設計を含む開発全体ができるようになると紹介されています。職場や担当によって差はあります。
まとめ
- 仕様書を書く仕事の中心はSEで、要件定義から設計、テストまで文書と付き合う
- 職種は「書く（SE・PM）」「読んで作る（プログラマー）」「発注側でまとめる（社内SE）」に分けると分かりやすい
- SEの1日は、打ち合わせ、文書を書く時間、レビューの組み合わせ
- 学歴や資格は必須ではなく、読む側から書く側へ段階を踏んで進むのが一般的
- 上流の工程に進みたい時は、求人の仕事内容で担当工程を比べてみる
コメント