【要件定義って難しい】初心者SEでも要件定義から開発作業までスムーズに進めるステップ【例題あり】
番外編は250円ですが、本編は無料です。
ご安心を！
「要件定義って、何から始めればいいんだろう」
「初心者SEだから、上流工程をどう進めたらいいのか分からないよ」
未経験でローコードエンジニアとして入社してから2,3か月くらいの私です。
超困惑してました。
SEとしての実務経験がない頃/浅い頃って、
・最初はテストから
・少し経験を積んだら
「じゃあこの機能のこの部分のコードを、こんな風に書き換えてみて」
みたいに細かな指示付きでコードを修正する
みたいな感じで段階的に経験を積んでいくのが通例だと思ってました。
初心者の方にいきなり重めの業務を任せるなんてことも、そうそう無いはず…
しかし、アサインされたプロジェクトの状況によっては、初心者さんに適したレベルの業務がなかったり、教える人や時間がなかったりすることもありますよね。
そうなると、ほとんど実務経験のない状態で、「こういう要望が来たから要件からまとめといて」なんて無茶ぶりを受けることも。
私の場合もまさにそうで。
立ち上げから間もないチームに入ったので、レベルに合わせた業務の割り振り体制がまだできてなかったんです。
なので、開発未経験でそのシステムの仕様も全然分かってないところからいきなり、
「ここにこんな機能を追加したいから、要件定義からやって。それができたら実際に開発とテストもしてね」
という、盛りだくさんな指示を遂行することになりました。
今思えばいい修業経験だったのですが、
当時は「え、まず何をすれば？どこを見れば？」と
パニック状態になっていました。
今、SEになりたてで頑張っている方の中にも、
「はい要件整理して。開発もよろしく」といった無茶ぶりを受けた/受けそうな環境でひぃひぃ言っている方もいるんじゃないでしょうか。
今回の記事は、そんな方のための記事です。
同じ状況にあった当時の私に、パニックを和らげるための指針を示してあげるとしたら…という観点で、「要件整理から開発作業に落とし込むコツ」をまとめました。
難しい言葉や特殊な関数などは極力使わないように書いたので、気軽に読み進めてみてくださいね。
同じような状況に遭遇した/遭遇しそうで不安になっている、初心者SEさんの助けになれば幸いです。
ステップ①：日本語の状態で要望を整理する
例えば、こんな要望が来たとします。
社内の申請システムに、承認フローを追加したい。
部長と課長、両方の承認が必要。
結果は申請者にメールで自動通知してほしい。
こういう時、いきなりコードを書き始めると、初心者のうちは思考がこんがらがってよく分からなくなります。
なので、まずは日本語の状態で読み込み、曖昧な部分を確認していきします。
要望①：部長と課長、両方の承認が必要。
質問①-1：「両方の承認がある」以外にどんなパターンがある？
要望②：結果は申請者にメールで自動通知してほしい。
質問②-1：メールを送るのはどんな状況になった時？
質問②-2：宛先はその申請者のメアドのみ？
質問②-3：タイトルや本文には何を書く？
とにかく疑問を書きまくった後は、想定できる範囲で回答の予測を書いていきます。
要望①：部長と課長、両方の承認が必要。
質問①-1：「両方の承認がある」以外にどんなパターンがある？
→恐らく、部長と課長それぞれに、「承認」・「却下」・「何もしていない」の3パターンがあるため、3×3=9パターンになりそう。
要望②：結果は申請者にメールで自動通知してほしい。
質問②-1：メールを送るのはどんな状況になった時？
→質問①-1の9パターンのうち、部長と課長それぞれが、「承認」もしくは「却下」した時だけに限られそう。
質問②-2：宛先はその申請者のメアドのみ？
→他に考えられるのは、ccに承認者とか、何か共通のメーリングリストとかが必要だったりする？
質問②-3：タイトルや本文には何を書く？
→承認パターンごとに内容が違うかも？対象申請のURLは入れる？
この内容をQA表にまとめて、ユーザーに回答してもらいます。
QA表の画像が小さいので、文字起こししたバージョンも記載しておきます。
1. 部長・課長の承認状況パターンの組み合わせは、別表の通りのパターンが考えられますが、認識相違ないでしょうか。
2. メールを送るのは、別表のパターンのうち、パターンNo.1,2,4,5の時でしょうか。
3. メールの宛先はその申請者のメールアドレスのみでしょうか。
例えば「ccには承認者のアドレスや、何か共通のメーリングリストを入れる」といったご要望はありますでしょうか。
4. タイトルや本文の内容は決まっていますでしょうか。
「承認パターンごとにテンプレートが存在するかどうか」、「本文に対象申請のURLが必要かどうか」等想定しておりますが、現時点で決まっていることがありましたらお知らせいただけますと幸いです。
回答の予測を書いておくことをおすすめしている理由は、ユーザーがYes/Noで答えやすくなるためです。
また、初めからある程度回答の道筋を立ててあげた方が、質問の意図が伝わりやすいものです。
ただ、予測がどうにも思いつかない場合は、まずは回答を完全に委ねてみて、その回答次第で再質問…という感じで徐々に要望を整理していきましょう。
ステップ②：処理の流れを日本語からプログラムに翻訳する
ある程度ヒアリングができたら、次は翻訳作業です！
（だから、文系とか語学系の人、実はかなり向いてる）
もっと言うと、「プログラムに落とし込みやすくする」作業ですね。
私は普段、日本語からプログラムに翻訳する感じで実施しているので、それに沿った形で説明していきたいと思います。
（フローチャートを書いた方が分かりやすければそれでもOK！）
まず、ヒアリングした情報を基に、大まかな処理の流れを書いていきます。
ここでは、ヒアリング結果として下記内容が返ってきたと仮定します。
1. 部長・課長の承認状況パターンの組み合わせは、別表の通りのパターンが考えられますが、認識相違ないでしょうか。
→合っています。
2. メールを送るのは、別表のパターンのうち、パターンNo.1,2,4,5の時でしょうか。
→合っています。
3. メールの宛先はその申請者のメールアドレスのみでしょうか。
例えば「ccには承認者のアドレスや、何か共通のメーリングリストを入れる」といったご要望はありますでしょうか。
→ccには承認者のアドレスを入れていただけますでしょうか。
4. タイトルや本文の内容は決まっていますでしょうか。
「承認パターンごとにテンプレートが存在するかどうか」、「本文に対象申請のURLが必要かどうか」等想定しておりますが、現時点で決まっていることがありましたらお知らせいただけますと幸いです。
→テンプレートは特に決まっていませんが、承認者情報と、承認/却下の結果が分かるようにしていただければと思います。
対象申請のURLも入れていただきたいです。
これらの情報を基に、大まかな処理の流れを整理してみます。
申請者が申請する
→部長・課長のもとに承認依頼が届く
→どちらかが承認もしくは却下する
→どちらも承認もしくは却下していた時に、メール送信処理を実施
次に、未記入のヒアリング情報を書き足していきます。
申請者が申請する
→部長・課長のもとに承認依頼が届く
→どちらかが承認もしくは却下する
→どちらも承認もしくは却下していた時に、メール送信処理を実施
つまり、どちらも承認もしくは却下したときに初めて、承認処理を抜けるということ。
どちらかが承認も却下もしていない状態では、承認処理を抜けられないということ。
また、メール送信処理を実施する時には、下記情報が必要。
・toのメールアドレス（申請者）
・ccのメールアドレス（承認者）
・タイトル
・本文
・承認者
・承認結果
・対象申請のURL
ここから、プログラムに翻訳していきます。
少し長いですが、根気よく思考の流れを追ってみてください。
なお、細かい部分の書き方はプログラミング言語によって大分異なるので、日本語を混ぜたり、文法をちょっと変えたりしています。
申請者が申請する
→部長・課長のもとに承認依頼が届く
→どちらかが承認もしくは却下する
→どちらも承認もしくは却下していた時に、メール送信処理を実施
【思考①】
つまり、どちらも承認もしくは却下したときに初めて、承認処理を抜けてメール送信処理を実施するということ。
どちらかが承認も却下もしていない状態では、承認処理を抜けられないということ。
→状況によってループが発生するということは、while文でループさせればいいのでは。
「どちらかの承認結果がまだ無いうちはループ処理を続ける」ということにすれば良さそうだな。
【思考②】
そもそもループ処理に入る前に、「どちらかが承認したタイミングでその承認結果を受け取る」ということをやっておかねば始まらないのでは。
「承認者（従業員ID）」と「承認結果」を格納する変数を設定しよう。
（ここでは、「承認者（従業員ID）」には部長の従業員ID：123、もしくは課長の従業員ID：456が入ってくるということにします。）
（また、「承認結果」には、承認時に1、却下時に2が入ってくることとします）
【思考③】
ループ処理の中で実施する承認処理を具体的に考えよう。
ループ処理を抜けられるかどうかは、承認結果の有無によって左右されるから、「承認結果がある」、「承認結果がnullや空」の判別がつけばいいのかな？
いやいや、メールを送るときには、「最終的に承認か却下か」という情報も必要になるから、最終承認結果の判別ができないといけないな。
別途「2人の承認結果を格納する変数」を用意して、ループ処理の中で値を格納していこう。
（以降、この変数を「最終承認結果」と呼ぶ）
【思考④】
「最終承認結果」は、要素数が2の配列型にして、もし部長が承認/却下したら1つ目の要素に、課長が承認/却下したら2つ目の要素に承認結果が入るようにしよう。
これは分岐だから、if文で表現できそうだな。
「もし「承認者」が「123」だったら、「承認結果」の値を「最終承認結果の1つ目の要素」として格納し、
もし「承認者」が「456」だったら、「承認結果」の値を「最終承認結果の2つ目の要素」として格納する」
という感じかな。
（例：部長が承認、課長が却下の場合は、{1,2}という配列になる）
【思考⑤】
ということは、【思考①】の「どちらかの承認結果がまだ無いうちはループ処理を続ける」は、
「最終承認結果の2つの要素のうち、どちらか1要素でも空のうちはループ処理を続ける」と言い換えられそうだな。
【思考⑥】
また、メール送信処理を実施する時には、下記情報が必要。
・toのメールアドレス（申請者）
・ccのメールアドレス（承認者）
・タイトル
・本文
・承認者
・承認結果
・対象申請のURL
メールのタイトルは、「【申請ID：〇〇】□□のお知らせ」という文言にすれば分かりやすいかも。
本文は「あなたの申請（ID：〇〇）は、△△によって□□されました。」という感じにして、最後にURLを付けたらいいかな。
【思考⑦】
「□□」には、「承認」、「却下」のどちらかを入れよう。
（以降、「□□」を「最終承認結果（メール）」と呼ぶ）
2人とも承認した時だけ「承認」で、それ以外の時は「却下」だね。
これは分岐で表せられるから、if文を使えば良さそう。
さっき決めた「最終承認結果」の変数も使うと、
「もし「最終承認結果」が{1,1}だったら、「最終承認結果（メール）」は「承認」、
それ以外は「却下」となる」
ってことになるか。
【思考⑧】
それから、「△△」には承認者の名前（役職）が入るね。
（以降、「△△」を「承認者（メール）」と呼ぶ）
2人とも承認した時は2人の情報で、それ以外の時は「却下した人の情報」でいい気がする。
これも分岐で表せられるから、if文を使えば良さそう。
「もし最終承認結果が{1,1}か{2,2}だったら、△△は「部長・課長」、
もし最終承認結果が{1,2}だったら、△△は「課長」、
もし最終承認結果が{2,1}だったら、△△は「部長」」
って感じかな。
こんな感じで、プログラムに落とし込むことができました。
（特定の言語ではなく、疑似言語のような感じで書いているので、ルールや文法の細かいところには目をつぶってください）
あとは、実際のプログラミング言語のルールや文法に沿って、変数の設定、while文やif文の記載を進めていけばOKです。
他にも、
「部長や課長の従業員IDの受け取り方法」、
「メールアドレスの指定方法」、
「対象申請情報やURLの取得方法」
など、決めることはたくさんあるのですが、外部システムとの連携や、データベースの扱い方が関わってくることもあるため、今回は割愛します。
そして、今回は仮でメールタイトルや本文を作っただけなので、この後どこかのタイミングで、ユーザーへ内容確認をしていただく必要があります。
また、今回はどんなプログラミング言語でも共通しているであろう、while文やif文のみに留めました。
ですが、プログラミング言語によってはもっと便利な標準関数やメソッドが用意されているので、そちらを使えるならその方がいいです。
ちなみに、承認結果とメール内容のパターンはこんな感じで整理されます。
補足①：要件整理・開発中に不明点が増えたら
要件整理や開発を進める中で、
「これ、こういう仕様で合ってるのかな？」
「ここって、このパターンの時はどうするんだろう？」
といった不明点があとから出てくることも少なくありません。
そんな時は、ステップ①で作成したQA表にまとめて、早めに質問しておきましょう。
この時気を付ける点としては、概ね以下の通りです。
実現できるか不安な部分は、仮コードを書いて検証する
→ユーザーに「じゃあそれでお願い」と言われて、「やっぱ実現できませんでした★」と返すわけにもね…実現できないと分かった場合、代替案も添える
→「この仕様だと実現できないんですけど、どうしましょう？」と聞かれるよりは、「こういう仕様ならできるんですが…」と相談される方が、ユーザーも判断しやすいですよね。実現できるにしても工数がかかりそうなら、その情報も伝える
→「この方法でやっていきましょう」と決まったはいいものの、当初想定されていた工数よりもかかってしまったら、ユーザーも困惑しますよね。
補足②：日頃からインプットを増やして、ひらめき力を育てよう
要望を見た時に、すぐプログラムのイメージが浮かぶかどうかは、日頃のインプット量にかなり左右されます。
例えば…
標準関数やメソッドをたくさん知っている
よくある実現例（サンプルコード）を見たことがある
こういう経験が増えるほど、
「この要望、あの関数でできそう！」
「前に見たあのコードが使えそう！」
とひらめきやすくなります。
例えば極端な話、if文を知らない人がいたとします。
その人が「もし○○なら●●、△△なら▲▲、どちらにも当てはまらないなら■■を出力」という要望を見ても訳が分からないですよね。
if文というものを知っているからこそ、「この要望を叶えるにはif文を使えばいいんだな」とピンと来るんです。
なので、空き時間にドキュメントを読んだり、サンプルを触ったりして、脳内の引き出しを増やしておきましょう！
まとめ
ここまででご説明したステップと補足内容をまとめると、こんな感じです。
日頃からインプットを増やして「ひらめき力」強化しておく
いざ要望を受けたら、まず日本語で整理し、QA表を作成
一通りヒアリングできたら、日本語で流れを書いてプログラムに翻訳
不明点は早めにQA表で確認、実現可否によっては代替案も提示
要望を見て「こんなの無理！」と思う気持ち、すごくよく分かります。
でも、ひとつずつ日本語に分解して、流れを描いて、そしてできるだけ丁寧にヒアリングしていけば、ちゃんと形にできるようになります。
焦らず、諦めず、一歩ずつ進んでいきましょう。
上流工程業務ができるようになると、カバーできる業務の幅が一気に広がって、社内評価や転職等にも有利になりますよ！
最後までお読みくださり、ありがとうございました！
番外編（有料部分）
本編で挙げた承認フローの例だと、一般企業の申請システムに触れた経験のある方なら、仕様確認をしなくても何となくイメージができてしまうんじゃないかなと思いました。
もちろん、実務であれば事前にイメージがついているに越したことはないのですが、訓練においてはなるべく事前にイメージがしにくいものの方が効果があるのではと考えました。
（＝きちんとヒアリングして内容を整理する練習になりそう）
というわけで、
「承認フロー」よりもなじみのある人が少なそう
私がある程度語れる分野
で、もう1つ具体例を出しながら説明してみようと思います。
テーマ（要望）は、
「根音と和音の種類を指定すると、使うべき音を根音から順に教えてくれる」機能
はい、音楽の話です。
要件整理～開発作業準備の訓練をしたくて、かつ音楽のことをあまり知らなかったり、上記要望を見てもよく分からない…という方には、これからの説明は効果的だと思います。
普段触れない話題について向き合って、要件整理を進めていくわけですから、いい訓練になるはずです。
また、要件整理～開発作業準備の訓練をしたくて、かつ上記要望の意味が分かるという方にとっては、「普段何となく脳内でやってることって、ガチガチにルール化するとこうなるんだ」という発見があって面白いと思います。
ちなみに、たったこれだけの要望でも「日本語からプログラムに翻訳する」説明部分で2,600文字近くになりました。
（【思考⑧】まであります）
プログラミング知識も音楽知識もある人はどうしたらいい？
多分プログラミング知識がある人はこの記事見に来なさそうだけど、もし来てくれてたんだとしたら、申し訳ないけどつまんないだろうから帰ってもらった方がいいかも….。
それではスタートです。
↓
ステップ①：日本語の状態で要望を整理する
「根音と和音の種類を指定すると、使うべき音を根音から順に教えてくれる」という要望から、不明点を抜き出して疑問点を書いてみましょう。
