当サイトの記事は編集部が国土交通省・IPA・デジタル庁などの公的機関の情報、規格や業界団体の公開情報を調べて独自に執筆しています。記事内にIT・Webエンジニアの転職サービスへの案内（広告）を含みます。
社内SEの求人や配属の話で『要件定義をお願いしたい』と言われ、『開発会社のSEとどう違うの？』と首をかしげた方も多いはずです。同じSEでも、立っている場所がまるで違うんですよね。
結論から言うと、社内SEの要件定義は「社内の困りごとを聞き、要件にまとめ、外注先と詰めて、受け入れて運用する」発注側の仕事です。作る人ではなく、何を作ってもらうかを決める人だと考えるとわかりやすくなります。
この記事を読めば、社内SEが要件定義で何をするのか、どんな仕様書を書くのか、受託側のSEとどう違うのかが分かります。
社内SEとは？要件定義で何をする人か
社内SEは、自分の会社の情報システムを担当するエンジニアです。要件定義では、社内の利用者と開発会社の間に立って「何を作ってもらうか」を決め、文書にまとめます。
社内SEという言葉は求人でよく見かけますが、公的な職業の名前ではありません。
厚生労働省の職業情報サイト job tag には「社内SE」という名前の職業ページは見当たりませんでした。ただ、job tag の「システムエンジニア（受託開発）」や「プロジェクトマネージャ（IT）」の説明には、勤務先として一般企業の情報システム部門が挙がっています。
『じゃあ、社内SEって何をしている人なの？』と思いますよね。この記事では、自社のシステムを担当し、発注側として開発や運用に関わるエンジニアを社内SEと呼ぶことにします。
要件定義は発注側の責任
IPAの「超上流から攻めるIT化の原理原則17ヶ条」には「要件定義は発注者の責任である」という一文があります。社内SEは、この「発注者」の側に立つ人なんです。
開発会社が聞き取りや文書作りを手伝ってくれることはあります。それでも、何のためにシステムを作り、何ができればいいかを決めるのは、会社の側の仕事です。
デジタル庁の標準ガイドライン群用語集では、要件定義を「必要な要件を明確に定める行為又はその定めた内容」と説明しています。要件定義書の中身は要件定義書とは？目的・書く内容・作る流れで紹介しています。
社内SEの仕事を4つの流れで見る
社内SEの仕事は「社内の声を聞く」「要件にまとめる」「外注先と詰める」「受け入れて運用する」の4つの流れで見ると、全体がつかめます。どの段階でどんな文書を書くかも、この流れに沿って決まります。
社内SEの仕事は幅が広く、『結局、何が本業なの？』と迷いやすいですよね。編集部で、システムを一つ入れ替える時の流れを4つに分けてみました。
| 流れ | やること | 書く・使う文書 | 話す相手 |
|---|---|---|---|
| 社内の声を聞く | 困りごとや要望を集め、今の業務の流れを確かめる | 聞き取りメモ、業務の流れ図 | 現場の担当者、管理職 |
| 要件にまとめる | 要望を要件に直し、優先順位をつけて合意する | 要件定義書 | 現場、経営層、情報システム部門 |
| 外注先と詰める | 提案を集めて外注先を選び、作る範囲と条件を決める | RFP、調達仕様書、契約書 | 開発会社、購買・法務 |
| 受け入れて運用する | できあがった物を確かめ、使い始め、問い合わせに応える | 受入れテストの計画書、運用の手順書 | 開発会社、現場の利用者 |
社内の声を聞く
最初の仕事は、現場の困りごとを聞くことです。ここで大事なのは、「どんな機能がほしいか」より先に「何に困っているか」を聞くことなんです。
例えば、経費精算のシステムを入れ替える時なら、こんなふうに聞いてみます。
「今、精算でいちばん手間がかかっているのはどこですか？」
「差し戻しになるのは、どんな時が多いですか？」
要件にまとめる
集めた声を、要件定義書にまとめます。要望はたくさん出てくるので、全部をそのまま入れるのではなく、目的に合うかで優先順位をつけるのが社内SEの腕の見せどころです。
原理原則17ヶ条には「機能要求は膨張する。コスト，納期が抑制する」という一文もあります。
予算と期限を見ながら「今回やること」「次に回すこと」を分けておきましょう。
外注先と詰める
要件がまとまったら、開発会社に提案を頼み、選んで契約します。ここで使うのがRFPや調達仕様書です。
外注先との打合せでは、要件定義書の言葉の意味がずれていないかを一つずつ確かめます。例えば「月末の締め処理を速くしたい」という要件なら、こんなふうに詰めていきます。
「速く、とは今よりどのくらい短くなればよいですか？」
「締めの日に同時に使う人は、何人くらいになりそうですか？」
- 作る範囲と、今回は作らない範囲
- 納めてもらう成果物（どの文書まで含むか）
- 要件が変わった時の進め方と費用の扱い
- 受入れで何を確かめたら合格とするか
受け入れて運用する
できあがったシステムが要件どおりかを確かめ、使い始めてからの問い合わせや改善にも対応します。作って終わりではなく、使われ続けるところまでが社内SEの仕事です。
使い始めてからは、現場からの「ここを変えてほしい」が次の要件の種になります。問い合わせの中身を記録しておくと、次の改修で要件定義をする時にぐっと楽になりますよ。
社内SEが書く仕様書：要件定義書・RFP・調達仕様書
社内SEが書く主な文書は、要件定義書、RFP（提案依頼書）、調達仕様書、受入れテストの計画書です。それぞれ「何を作るか」「何を提案してほしいか」「どんな条件で頼むか」「何で合格とするか」を書きます。
民間企業に決まった書式はありませんが、デジタル庁の手引きは、発注側の文書を考える時の良いお手本になります。
要件定義書
デジタル庁のDS-100（デジタル・ガバメント推進標準ガイドライン）では、要件定義書の記載内容を「業務要件の定義」「機能要件の定義」「非機能要件の定義」「システム方式の決定」としています。
非機能要件は、速さや止まりにくさ、セキュリティなど、機能以外の水準のことです。
IPAの「非機能要求グレード2018」では大項目を6つに分けているので、決め漏れを防ぐ目次として使えます。くわしくは非機能要件とは？要件定義書に書く項目と決め方で紹介しています。
RFP（提案依頼書）
RFPは、デジタル庁の用語集で「提案依頼又は提案依頼書のこと。Request For Proposal の略字」とされています。
複数の開発会社から提案を集める時に、「こういう目的で、こういう条件で、こんな提案をしてほしい」と伝える文書です。書き方はRFP（提案依頼書）とは？要件定義書・仕様書との関係で紹介しています。
調達仕様書
DS-100では、調達を行う時に調達仕様書を作り、要件定義書や参考資料を添付する流れになっています。調達仕様書の記載事項には、次のような項目が挙がっています。
- 調達案件の概要
- 情報システムに求める要件（要件定義書を満たすべき旨）
- 作業の実施内容と実施体制・方法
- 成果物の取扱い（知的財産権の帰属、契約不適合責任、検収など）
- 再委託やその他の特記事項
民間の発注でも、作業の範囲や成果物の扱いを書いておくと、後で「そこまでは頼まれていない」というすれ違いを防げます。
受入れテストの計画書
IPAの共通フレーム2013のガイダンスには、「受入れテストの内容，体制，スケジュール等を明確にした受入れテスト計画書を文書化することが望ましい」という記述があります。
DS-100でも、発注側（PJMO）が受入テストを行い、そこに情報システムの利用者が参加する流れになっています。何を確かめたら合格とするかを、作る前に決めておくのがコツです。
受入れの基準を決めないまま開発に入り、納品された時に「思っていたのと違う」となることがあります。要件定義書の各項目に「どう確かめるか」を一言ずつ添えておくと、受入れがぐっと楽になります。
請負か準委任かも決めておく
共通フレーム2013のガイダンスでは、企画や要件定義の一部を外に頼む場合、「請負」か「準委任」かの区別をしておくのがよい、としています。
完成した物に責任をもってもらうのか、作業を手伝ってもらうのかで、契約の考え方が変わります。迷う時は社内の法務担当にも相談してみてください。
社内SEと受託側SEの違い
社内SEは「何を作ってもらうか」を決める側、受託側のSEは「どう作るか」を決めて作る側です。同じ要件定義でも、立場が違うと大事にすることが変わります。
job tag の「システムエンジニア（受託開発）」では、顧客にヒアリングして業務のプロセスを理解し、どのようなシステムにするか決めることを要件定義として説明しています。受託側は「顧客の要件を聞いて形にする」立場なんです。
| 比べる所 | 社内SE（発注側） | 受託側のSE（開発側） |
|---|---|---|
| 立場 | 自社のシステムの持ち主 | お客さんのシステムを作る |
| 要件定義での役割 | 社内の要望を集めて決める | 顧客から聞き取って文書にする |
| 主に書く文書 | 要件定義書、RFP、調達仕様書、受入れの計画 | 要件定義書の案、設計書、テスト仕様書 |
| 話す相手 | 社内の現場・経営層・外注先 | 顧客の担当者・自社の開発チーム |
| プログラミング | 職場によるが、自分で書かないことも多い | 設計からコーディングまで関わることが多い |
| 仕事の終わり | 使われ続ける限り続く | 納品と保守契約の範囲まで |
- 自社の業務に深く入り込める
- 作った後の使われ方まで見届けられる
- 経営や現場に近い所で決められる
- 社内の意見の食い違いをまとめる必要がある
- 頼まれ事が幅広く、何でも屋になりやすい
- 外注先との調整に時間がかかる
どちらが良い悪いではなく、向き不向きの話です。『作るのが好き』なら受託側、『決めて使ってもらうのが好き』なら社内SEが合いやすいかもしれません。
仕様書を書く仕事の違いは仕様書を書く仕事とは？SE・PM・社内SEの仕事内容と違いで、要件定義書の役割分担は要件定義書は誰が作る？発注側と開発側の役割分担でくわしく紹介しています。
社内SEに向く人と、求人票で確かめること
社内SEに向くのは、人の話を聞いて言葉にまとめるのが得意な人です。求人票では「どこまで自分で作るか」「外注先とどう分担するか」「担当するシステムの範囲」を確かめておきましょう。
『プログラミングが苦手だけど、社内SEならできる？』という声もよく聞きますよね。
社内SEは、職場によって自分で作る量が大きく違います。外注中心の職場なら、聞き取りと文書作り、外注先との調整が仕事の中心になります。
- 現場の人の話を最後まで聞ける
- 聞いたことを表や文章にまとめるのが苦にならない
- 予算や期限を見ながら優先順位をつけられる
- 技術の細かい話を、ITに詳しくない人に言い換えられる
求人票で確かめたいこと
社内SEの求人は、同じ名前でも中身がかなり違います。気になる求人は、次の表に書き出して比べてみてください。
| 確かめること | 見る所・聞くこと |
|---|---|
| 自分で作る量 | 開発は内製か外注か、使う言語や道具 |
| 担当する範囲 | 業務システム、社内ネットワーク、パソコンの管理など、どこまでか |
| 要件定義の進め方 | 要件定義書は誰が書くか、外注先とどう分けているか |
| 部署の人数 | 一人で全部を見るのか、チームで分けるのか |
| 社内の相手 | どの部署の依頼を受けるか、経営層と話す機会があるか |
年収の目安は公的統計で見る
『社内SEの年収ってどのくらい？』と気になる方も多いはずです。ただ、社内SEだけを取り出した公的な統計は見当たりません。
経済産業省のIT人材需給の試算（2019年）でも、IT企業とユーザー企業の情報システム部門などで働く人をまとめて数えています。職業分類では「システムコンサルタント・設計者」「ソフトウェア作成者」などの区分です。区分ごとの数字は仕様書を書くエンジニアの年収｜公的統計で見る職種別の目安で紹介しています。
社内SEの要件定義でよくある相談
知恵袋でよく読まれているのは「SESから社内SEへ移れる？」「SIerで要件定義をしてきたけど社内SEで活かせる？」「プログラミングが苦手でも社内SEはできる？」といった相談です。
ここからは、知恵袋でよく読まれている相談を要約して答えてみますね。
相談1：SESで要件定義まで経験。社内SEへ移れる？
『SESで経験を積み、基本情報と応用情報を持っていて、要件定義の経験もある。社内SEに移れる？』という相談です。
要件定義の経験は、社内SEの仕事とつながりやすい経験です。応募書類では、どんな業務の要件を、誰から聞き取って、どんな文書にまとめたかまで書くと、発注側の仕事に近いことが伝わります。
一方で、社内SEは発注側として社内の意見をまとめる立場です。面接では「開発会社の立場で見ていた要件定義」と「発注側で決める要件定義」の違いをどう考えるか、自分の言葉で話せると強みになります。
相談2：SIerで要件定義から保守まで担当。社内SEで活かせる？
『今はSIerで、要件定義から開発、リリース、保守まで担当している。社内SEに移って活かせる？』という相談です。
活かせる場面は多いです。開発の流れを一通り知っていると、外注先の見積もりや設計書を読んで「ここは手間がかかりそう」と見当がつけられます。
ただ、社内SEになると自分で作る機会が減る職場もあります。作ることを続けたいのか、決める側に回りたいのか、自分の希望を先に決めておきましょう。
相談3：プログラミングが苦手。社内SEはできる？
『社内SEに就職しようと思っているけど、プログラミングがとても苦手。大丈夫？』という相談です。
外注中心の職場なら、聞き取りや文書作り、調整が仕事の中心になります。ただ、外注先の説明を理解したり、設計書を読んだりするには、基本の知識は欠かせません。
『苦手だから避けたい』と思うより、「読めるようになる」ことを目標にしてみてください。
ITパスポートや基本情報で基礎の言葉をそろえるのも一つの方法です。資格の選び方は要件定義に役立つ資格｜情報処理技術者試験の選び方で紹介しています。
相談4：希望しない部署に配属された社内SE2年目。転職すべき？
『製造業の社内SEに、希望していないのに配属された。2年目だけど転職したくてたまらない』という相談です。
まずは、今の職場で要件定義や外注先との調整に関われるか、上司に相談してみるのも手です。発注側として要件をまとめた経験は、どの業界でも通じる強みになります。
それでも気持ちが変わらない時は、今の経験を棚卸しして、次の職場で何をしたいかを言葉にしてから動くと後悔が少なくなりますよ。
発注側として要件をまとめた経験は、社内SEの求人でも開発会社の上流工程でも評価されやすいものです。
今の職場の外も見てみたい方は、求人の仕事内容を比べてみると道が見えてきます。今の職場で担当を広げる道も、もちろん正当な選択です。
IT・Webエンジニアの転職（PR）
仕様書を書く経験を活かせる職場を探すなら、求人も比べてみる
要件定義や設計を任されるか、発注側か開発側か、扱うシステムや働き方は会社によって大きく違います。担当したい工程や条件から、IT・Webエンジニアの求人を比べてみてください。
無料ITエンジニアの求人を探す求人の条件・待遇は各求人票と応募先の案内でご確認ください。
求人票の見方や準備は要件定義・設計の経験を活かす転職｜求人票の見方と準備で紹介しています。
よくある質問
社内SEも要件定義をするのですか？
します。社内SEは発注側として、社内の要望を集めて要件定義書にまとめます。IPAの原理原則17ヶ条にも「要件定義は発注者の責任である」とあります。
社内SEの要件定義と、開発会社のSEの要件定義は何が違いますか？
社内SEは「何を作ってもらうか」を決める側、開発会社のSEは顧客から聞き取って形にする側です。同じ要件定義書でも、社内SEは社内の合意を取ることに多くの時間を使います。
社内SEが書く仕様書にはどんなものがありますか？
要件定義書、RFP（提案依頼書）、調達仕様書、受入れテストの計画書などです。デジタル庁のDS-100は発注側の文書のお手本として参考になります。
社内SEにプログラミングは必要ですか？
職場によります。内製の職場では自分で作ることもあり、外注中心の職場では聞き取りや調整が中心です。どちらの場合も、設計書を読める程度の基礎知識はあった方が仕事を進めやすくなります。
社内SEとして要件定義を学ぶなら、何から読めばいいですか？
IPAの「ユーザのための要件定義ガイド 第2版」は、要件定義を成功に導く128の勘どころを、発注側の目線でまとめた手引きです。デジタル庁のDS-100とあわせて読むと、発注側で決めることの全体像がつかめます。
まとめ
- 社内SEの要件定義は、発注側として「何を作ってもらうか」を決める仕事
- 仕事は社内の声を聞く・要件にまとめる・外注先と詰める・受け入れて運用するの4つの流れ
- 主に書く文書は要件定義書、RFP、調達仕様書、受入れテストの計画書
- 受託側のSEとは、決める側か作る側かの違いがある
- 求人票では自分で作る量と担当する範囲を確かめる
コメント