4月に社会人デビューし、5月にエンジニアデビューして半年ほど経ちました。
その間に、社内ツールを1つ作り、今は会社の一事業の基幹システムの開発に携わらせて頂いています。
半年経った今だからこそ、改めて開発プロセスを調べて学んでまとめてみようと思った次第です。
読み物的な感じで読んで頂ければと思います。
目次
第1章 要件定義 ←今回はココ！
第2章 設計
第3章 開発（実装）
第4章 テスト・検証
第5章 リリース
第6章 運用
開発プロセスを6つに分けて一つ一つピックアップしていきます。
色々調べてみてコアとなる考え方を抽出して抑えるべきポイントと僕が経験した半年での出来事を振り返ろうと思います。
要件定義ってなんだ？？
上記の質問に一言で自信を持って答えられた方はこのページをそっとじしてもらって構いません。
もしくは新人未経験エンジニアの体験談だけ読んで笑ってやってください。
要件定義について調べていると大抵のサイトにはこう書かれていました。
「開発の出発点でもあり、その後の開発の良し悪しを左右するもっとも大事な工程である」
ふむふむ、なるほど。
現実世界に置き換えてみましょう。
例えば、旅行。
どこかへ旅行する時に
・どこへ行くのか？
・誰と行くのか？
・何泊泊まるのか、もしくは日帰りなのか？
・その旅行でどのくらいお金使うのか？
・レンタカーで行くのか、電車か、はたまた飛行機か？
など全く決めずに思いつきでフラッと旅に出てしまうようなスナフキンのような人は中々いないと思います。
せっかくの旅行を精一杯楽しむために、出来る限り自分の欲望を最大限満たすような計画を立てるはずです。
旅行計画（要件定義）は「旅行（開発）の出発点であり、その後の旅行（開発）の良し悪しを左右するもっとも大事な工程である」
要件定義の重要性がよく分かったと思います。
要件定義を行う目的って？？
上でも少し触れましたが、要件定義はその後の開発を左右する大事な工程です。
何となく要件定義を行う目的は分かりそうなものですが、後輩や新人エンジニアに聞かれた時のために一言でまとめておきます。
要件定義を行う目的、それは...
依頼者（発注者）にとって本当に価値のある成果物を提供すること
だと思います。
少し話が飛躍したように思えるかもしれないですね。
例えば、こんな状況を思い浮かべてください。
あなたにとっての一番の親友があなたにこんな相談をしてきました。
「そろそろ彼女（彼氏）が欲しくて。。。誰かいい人いたら紹介してくれない？」
きっとあなたはこう聞くはずです。
「君はどんな異性がタイプなの？」
続いて
「年下がいいの？年上がいいの？」
「背は高い方がいいの？低い方がいいの？」
…etc
これってまさに要件定義してますよね！
この目的はもうお分かりでしょう。
親友に恋人を作ってもらい、幸せになってもらうことです。
つまり、要件定義を行う目的は依頼者（発注者）にとって本当に価値のある成果物を提供することなのです。
要件定義のゴールはどこ？？
要件定義を調べていると、こういう失敗談をよく目にしました。
・いつまでたっても要件定義の作業が終わらない
・予定通りに要件定義フェイズを終えたものの、その内容が荒すぎて後工程で要件の抜けや漏れが見つかる
・何でもかんでも要件に盛り込んでしまい、いつまでたっても開発が終わらない
もしかしたらエンジニア歴の長い方なら経験があるかもしれません。
こういったことが起きてしまう原因としては、やはり要件定義に大きな原因があるのだと思います。
先ほどの例えの話に戻ります。
あなたが親友に好みのタイプを聞くと、親友はこう答えました。
「やっぱり付き合うなら、可愛い（かっこいい）人がいいなぁ。あとはある程度お金を持ってて、優しい人がいいね。」
いかにも若者らしい答えが返ってきましたね。
あなたはこんな風に返すのではないでしょうか。
「芸能人で言うと誰がタイプ？」
「年収いくらくらいがいいの？」
自然な流れですが、あなたはどうしてこんな質問をしたのでしょうか？
それは
あなたの感じる可愛い（かっこいい）の基準・お金持ちの基準・優しいの基準と、親友が感じるそれらの基準が違うから
に他ないでしょう。
いくら親友といえども他人は他人です。
イメージの違いは必ずあるはずで、そのイメージがすり合わない限り親友への異性の紹介は終わらないでしょう。
逆に言えば、イメージがしっかり擦り合っていれば何人か紹介するうちに運命の人と思えるような人を紹介出来ると思います。
つまり、要件定義のゴールは
依頼者（発注者）と開発者の成果物イメージが擦り合うこと
だと言えます。
抽象的な依頼、課題に対してしっかりゴールイメージを擦り合わせてあげることが大事です。
要件定義で抑えるべきポイントって何？？
さぁ、ここまできて何を当たり前なことを言っているんだとお思いかもしれません。
こうやって身近なことに置き換えて考えてみると当たり前のことでも、同じことが要件定義だとうまくいかなくなってしまうのはそれが同じことだと気づいていないことが原因かもしれませんよ。
さて、
要件定義の目的：依頼者（発注者）にとって本当に価値のある成果物を提供すること
要件定義の目標：依頼者（発注者）と開発者の成果物イメージが擦り合うこと
だと述べました。
ではこの目的、目標を達成するために要件定義ではどんなことに気をつければ良いのでしょうか。
今回、色々調べていく中で以下の3点が要件定義において外してはいけないポイントだということが見えてきました。
1. 事前準備
2. ゴール設定
3. 役割分担
一つずつ見ていきます。
1. 事前準備
何かの開発に着手する時にいきなり要件定義から入り、相手の要求をきちんと理解しないまま開発が始まってしまい、結果失敗するというパターンが往々にしてあるようです。
「敵を知り、己を知れば百戦危うからず」ということわざあるようにまずは相手のこともきちんと知る必要があります。
現状の業務フローがどういうもので、その結果どんな課題があり、それをどのような形でシステムで解決したいと思っているのか、しっかり把握するということです。
親友は結婚を考えていて結婚相手を探しているのか、ただ単に付き合いたいだけなのかによってあなたが紹介する人も変わるはずです。
また、親友はスポーツをやっていて休日に一緒にスポーツ出来るような相手を探しているのか、それとも休日は家にこもって一緒に映画を一日中見ていられるような相手を探しているのかによっても紹介する人は変わります。
大事なことは
・現状の業務フローの把握
・既存システムの仕様把握（既存システムを使っている場合）
をしているかしていないかで、最終成果物に大きな影響を及ぼします。
まずは現状把握から始めるようにしましょう。
2. ゴール設定
ここは少し目標と被るのですが、もう少し具体的に言うと
新システムを使った時の業務フローを擦り合わせる
ということです。
事前準備で既存業務のフローと既存システムの仕様を把握していたとして、それが新しいシステムになった時にどのように変化するのかを明確にしておきます。
既存のシステムと明確な変化がないor課題が解決されていない場合、それはゴール設定が間違っているかシステム化しなくて良いという結論に至ります。
恋人が出来た後の二人の生活がどのようになるかを擦り合わせておくのです。
平日はお互い仕事があるけど、二人ともお酒が好きだから夜は飲みに行ったり家で飲んだりして、休日は一緒にジムに行って運動する。
このフローを共有しておけば、あなたが紹介する人は相手の求める理想像にかなり近いはずです。
3. 役割分担
こういった失敗談もあるそうです。
既存業務の突っ込んだ整理や、業務のあるべき将来像の策定、どのレベルで機能を実現するかの判断など、依頼者側でなければこなせないタスクを開発者側に任せてしまい、開発が遅れた結果、納品も遅れてしまう。
エンジニアは頼まれるとノーと言えない人が多く、結果たくさんの仕事を抱えてしまいがちです。
（かく言う僕もそのうちの一人です。。）
ですが、本当に価値のある成果物を提供するためにはお互いがやるべきことをきちんとやることが理想の状態です。
依頼を受けてから開発、リリースまで全て一人で出来れば何も問題ないですが、そんなスーパーマンのような人はほとんどいません。
時には断る勇気も必要です。
自分がきちんと価値を発揮できるようにお互いが協力しあってより良いものを開発していけるように歩み寄る姿勢が必要ですね。
もし、合コンのセッティング、連絡先の交換まで促してあげてるのに、その後ことごとく失敗した親友が
「失敗するのは君のせいだ。ちゃんと付き合えるまできちんとフォローしろ。」
そういってきたらその親友とはそれっきりにしましょう笑
まとめ
以上、目的・目標・ポイントという流れで要件定義を分解して説明させて頂きました。
要件定義の目的：依頼者（発注者）にとって本当に価値のある成果物を提供すること
要件定義の目標：依頼者（発注者）と開発者の成果物イメージが擦り合うこと
要件定義のポイント：1. 事前準備、 2. ゴール設定、 3. 役割分担
理屈では分かっていても実際にやると難しいのは重々承知しています。
きちんと要望を持っている依頼者だけではないこともあるかと思います。
中には本当の課題に気づいていない可能性もあります。
そういう時に大切なのは、小手先のテクニックではなく目的や目標、抑えるべきポイントを理解していることだと思い、その視点でまとめました。
新人未経験エンジニアの「要件定義」経験談
社内ツールを開発した時に、初めて要件定義を体験しました。
たまたまPOの方がパワポでイメージを作ってきてくださる熱心な方だったので、そんなに苦労しなかった覚えがあります。
そんなイージーモードでさえビビリの僕はしっかりヒアリングすることが出来ず、ふんわりした要件定義で終えてしまい、その後何度か追加で質問しに行かせていただいた覚えがあります。
その後のフィードバックで案の定「ビビリすぎ」と言われました。
要件定義を苦手とする人が多い理由を感覚的に感じ取った経験でもあります。