エンジニアと要件定義の役割分担｜SE・社内SE・発注側は何をする？

当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。

要件定義は誰がやる？結論は「発注側とエンジニアの共同作業」

要件定義（RD：Requirements Definition）は、システムで何を実現するかを関係者で決める工程です。

『要件定義はSEの仕事でしょ』と思っている方も多いはずです。

たしかに、要件定義書を書く作業はエンジニアが担うことが多いです。

ただ、「どの業務をどう変えたいか」は、その業務をしている人にしか決められません。

IPAが2019年に公開した「ユーザのための要件定義ガイド 第2版」も、システムを使って業務に責任を持つユーザ、つまり発注側に向けて書かれています。

発注側が主体的に要件定義に関わる必要が増している、という問題意識からなんです。

「決める人」と「まとめる人」を分けて考える

要件定義の役割は、大きく二つに分けると見通しがよくなります。

エンジニアは、決める人の代わりに決めてしまわないことが大事です。

一方で、聞いたことをそのまま書くだけでは、実現できない要件や矛盾した要件が残ってしまいます。

要件定義そのものの意味をおさらいしたい方は、要件定義とはもあわせてどうぞ。

SEにとって要件定義とは？エンジニアが担う仕事

SEは、システムの設計や開発の全体を見るエンジニアのことです。

システムエンジニアが要件定義で担う仕事を、順番に見てみましょう。

要望をそのまま書かず、「なぜ」を聞く

例えば、店舗スタッフのシフトをシステムで作る案件を考えてみます。

「シフト表を自動で作ってほしい」と言われた時、そのまま要件にすると、何をもって完成かが分かりません。

「自動で作ってほしいのは、作る時間を減らしたいからですか、それとも不公平をなくしたいからですか」
「どちらかというと、毎月の調整の手間を減らしたいんです」

こう聞き返すと、本当に必要なのは「希望の集め方と調整の手間を減らすこと」だと見えてきます。

エンジニアの腕の見せどころは、こういう問いかけなんですね。

実現できるかを、早めに伝える

発注側の要望の中には、予算や期間に合わないものもあります。

その時は、「できません」で終わらせず、代わりの案を出すのがエンジニアの役目です。

例えば、シフト作成の案件で「希望を出した全員の希望を、全部かなえる表を自動で作りたい」という要望が出たとします。

人数が足りない日がある限り、全員の希望をかなえるのは難しいですよね。

そこでエンジニアは、こんな代わりの案を出します。

「全員の希望をそのまま反映するのは難しいので、人数が足りない日を一覧で出して、店長が調整しやすくする形ではどうでしょう」
「それなら今の調整の手間はかなり減りそうです。その形で進めてください」

このように、実現できる形に言い換えて合意を取るところまでが、エンジニアの役割なんです。

エンジニアが作る主な成果物

要件定義の中で、エンジニアが手を動かして作ることの多い資料も押さえておきましょう。

それぞれの中身は、要件定義の成果物一覧で詳しく紹介しています。

立場で変わる役割：受託開発・社内SE・発注側の分担表

ここが、この記事でいちばん伝えたいところです。

『求人には要件定義と書いてあったけど、実際に何をするの？』と感じたことはありませんか。

実は、どの立場が要件定義を担うかは、契約の形や会社によって変わります。

立ち位置別の役割分担表（例）

架空の「店舗スタッフのシフト作成をシステム化する場合」で、立場ごとの分担を並べると次のようになります。

この表はあくまで例です。

社内SEがいない会社では、業務部門の担当者がSIerと直接やり取りすることもあります。

SIerのSEが要件定義をする場合

SIer（システムインテグレーター）は、企業からシステム開発を請け負う会社です。

SIerで要件定義をするSEは、発注側の業務を聞き取り、要件定義書という形にまとめる役を担います。

受託開発では、要件定義を準委任契約、設計以降を請負契約に分けて契約する例もあります。

その場合、要件定義の段階は「一緒に決める」作業で、成果物の完成責任は設計以降とは扱いが変わることがあります。

社内SEが要件定義をする場合

社内SEは、自社の情報システムを担当するエンジニアです。

社内SEの要件定義は、発注側の立場に立って、開発会社に「何を作ってほしいか」を伝える仕事が中心になります。

業務部門の言葉を、開発会社に伝わる言葉へ通訳する役、とイメージすると分かりやすいですよ。

人数の少ない会社では、要件定義から導入まで一人で担当することもあります。

Webエンジニアが要件定義をする場合

自社サービスを作るWebエンジニアは、発注側と開発側が同じ社内にいることが多いです。

そのため、要件定義書を一冊作るより、企画担当と話しながら機能を小さく決めて、作っては確かめる進め方になりやすいです。

アジャイル開発では、要件をプロダクトバックログに並べ、ユーザーストーリーで書くことがよくあります。

「店長として、人数が足りない日をすぐに見つけるために、日ごとの不足人数を一覧で見たい」のような書き方です。

発注側の担当者が知っておきたいこと

ここまで読んで、『じゃあ発注側は何を準備すればいいの？』と思った方もいるかもしれませんね。

発注側の担当者がエンジニアに任せきりにしないために、準備しておきたいことを並べてみます。

この四つがそろっていると、エンジニアは「何を決めてもらえばいいか」が分かり、打ち合わせがぐっと短くなりますよ。

何年目から任される？要件定義に入るまでの道のり

『何年目になったら要件定義ができるんだろう』と気になる方も多いですよね。

ただ、これは会社の規模や体制で本当にばらばらです。

1年目から打ち合わせに同席する会社もあれば、プログラムやテストの経験を積んでから上流の工程に入る会社もあります。

任される前にできる準備

要件定義は、ある日いきなり全部を任されるものではありません。

先輩の打ち合わせに同席して、少しずつ担当を広げていくのが一般的です。

未経験から少しずつ身につける練習の順番は、要件定義のスキルを未経験から身につける方法で詳しく紹介しています。

下流工程の経験は、要件定義に生きる

プログラムやテストの経験は、要件定義で「実現できるか」を判断する時の土台になります。

例えば、テストを経験した人は、「この要件だと合否を判断できない」と気づきやすいんです。

一方で、下流工程の経験がなくても、業務をよく知っていれば聞く力や書く力で十分に活躍できます。

エンジニアが要件定義でつまずきやすい場面

要件定義を任されたばかりの頃は、いろいろな場面で迷いますよね。

よくある場面と、その時の動き方を並べてみます。

「お任せ」と言われた時こそ、確認を増やす

発注側から「詳しくないので、お任せします」と言われることもあります。

『任されたなら自分で決めていいのかな』と思いがちですが、ここは注意が必要です。

案を作って見せるところまではエンジニアの仕事で、それを採用するかを決めるのは発注側です。

「この二つの案のうち、どちらが店舗の運用に合いそうですか」と、選んでもらう形にすると進めやすくなりますよ。

打ち合わせで使える聞き方の例

聞き方を少し変えるだけで、決める人に判断してもらいやすくなります。

どれも、相手が答えやすく、決めたことが残る聞き方なんです。

要件定義がなぜ難しいと言われるのかは、要件定義が難しい理由とつまずきポイントでまとめています。

よくある相談に答えます

エンジニアと要件定義について、よく寄せられる相談を要約してお答えします。

現場によっては、要件定義と基本設計の境目があいまいなまま進むことがあります。

ただ、細かい設計まで要件定義の段階で決めると、後で変えにくくなる面もあるんです。

まずは「要件定義で決めること」と「設計で決めること」を一覧にして、チームで合意を取ってみてください。

境目の考え方は、要件定義と基本設計の違いが参考になります。

小さな会社では、よくある体制です。

一人で担当する時ほど、「決める人」を業務部門の責任者にしておくことが大事になります。

要件を自分だけで決めず、要件の一覧を見せて承認をもらう流れにしておくと、後で困りにくくなりますよ。

結論から言うと、そういう分担になる案件は多いです。

ただ、下請けの会社でも、要件定義の打ち合わせに同席したり、一部の要件の検討を任されたりすることはあります。

要件定義に関わりたい場合は、まず要件定義書を読み込んで、気になる点を質問するところから始めてみましょう。

よくある質問

まとめ

要件定義を実際にどう進めるかは、要件定義の進め方・手順で順番に紹介しています。

あわせて読みたい

要件定義とは？意味をわかりやすく解説｜家づくりで見る全体像

要件定義を未経験から身につける方法｜小さな成果物で慣れる3か月

要件定義の進め方とやり方｜6つの手順と週ごとのスケジュール例