コーディングもテストも慣れてきた！ちょっとずつ業務の範囲を広げていきたいなぁ
エンジニアとして実務デビューしてから数年経つと、開発の上流工程と呼ばれる部分を任せられるようになるはずです。
求人広告を9年以上書いてますが、エンジニア求人でよく書きますよ〜！上流工程任せてもらえるって
よくあるウォーターフォール開発でいうと、設計や要件定義が上流工程にあたります。
どの業務が上流工程にあたるかはわかるけど、実態をそこまで知らない若手エンジニアのあなた！そんなあなた向けに、身近なあることに例えつつ、要件定義について徹底解説します。ゆくゆくは上流工程を目指しているなら、しっかり覚えておきましょう！
＼エンジニアが大企業並みの給与と自由をGet／
そもそも要件定義とは？
早速、要件定義について説明していきましょう。その前に、開発工程の流れを振り返ります。
経験3年以下の若手エンジニアが任される工程は開発（コーディング）やテスト部分です
エンジニアのステップアップでよくある流れは以下の通り。
- 開発とテストが難なくできるようになったら、仕様を決定する詳細設計を任せる
- 詳細設計もできるようになったら基本設計や要件定義を任せる
要件定義は、長期にわたりエンジニア経験を積んだ中堅〜ベテラン層が担う場合がほとんどです。
開発における要件定義の立ち位置
要件定義をざっくりいうなら、本格的な開発をする前に進め方の指針を立てることを指します。
ユーザー側の意見をヒアリングしてまとめ、開発者視点で何をどう進めればいいかシナリオを作っていきます。
企画とごっちゃになる人もいるかもしれませんが、企画はビジネス上の方針で、開発プロセスとは別。
企画でできあがった方針を、どう開発していくかを考えるのが要件定義なのです
じゃあ上流工程として、まとめられがちな基本設計との違いは？
基本設計は要件定義で決めた内容を、より具体化したもの。
要件定義の段階でスケジュールが出ているので、そのスケジュールに合わせて何をどう開発するか示しています
要件定義がないとどうなるのか？
仮に要件定義がないまま、開発を進めてしまうとどうなるでしょうか？オープン系SEとして10年以上勤務する私の夫に起きたトラブルを事例としてご紹介しましょう。
前提条件を伝えると、夫は某メーカーの客先常駐エンジニア。生産システムを中心に開発業務に従事しています。今回はあるシステムの改修に関するお話です
客先のある方から改修の依頼を受けた夫。ただ、要件定義が定まっておらず見切り発車のような状況でした。
いろいろ不安だなぁ〜…。ただ納期も近いから、都度確認しながら進めるか
夫は基本設計以降できる人なので、一旦もらった内容をもとに基本設計書・詳細設計書を作って後輩と一緒に開発を進めていました。
そろそろ大枠ができたし、単体テストでもやるか
あ、夫さん！そのシステム、○○の動き方変えるので基礎設計書のここだけ変えてもらっていいですか？
エッ
その翌日。
夫さんごめんなさい、それ想定と違うところいろいろあったので全部やり直します
エッッッッッ！？
という感じで、要件定義がしっかり固まっていないと、開発中に大幅修正が入って開発遅延が起こります。となると、残業が増えて案件炎上の温床ともなりえます。
実際にこの後しばらく、普段ノー残業で帰ってくる夫が1日2時間くらい残業する事態に陥りました
開発をスムーズに進めるためには、最初の方針決めがとても大事なのです。
これが悪化すると炎上プロジェクトが爆誕します。炎上についてはこちらの記事も見てください！
要件定義ができるまでの流れ
要件定義が決まるまでには、大きく分けて3つのプロセスが存在しています。
- ユーザーからの要求、要望確認
- システム要件を決める
- 要件定義書の作成
まずユーザーの要求や要望をできるだけ具体的に確認します。
ユーザーからの要求を全部飲むと、工数が膨らむ、開発環境を考えると実現できないなど炎上する可能性があります。なので、ユーザーの要求と開発上の制約との両立が肝。
続いてシステム要件の検討、決定です。ヒアリング内容をもとに、必要な機能を洗い出していきます。
「この機能は今の環境じゃ厳しい」「今の環境で代替可能なこんな機能は？」など、必要に応じてユーザーと話し合って実現可能な機能のみ要件定義書に盛り込みます。
最後に要件定義書の作成です。以下のような内容についてどのように定義するのか、書面に残します。
- 機能要件…実装する機能に関すること
- 非機能要件…保守性など、実装する機能以外に関すること
- サイト要件…Webサイト構築の際に定義。ターゲット層やブラウザ、OSなど
- インフラ要件…サーバやDB、ネットワークに関すること
- セキュリティ要件…セキュリティ面の目標
ここまで説明を聞いたけれど、イマイチぴんと来ない？それなら身近なものに例えてみましょう
要件定義を旅行に行くときの流れで言い換えよう
ということで、ウォーターフォール開発そのものを旅行に行って帰ってくるまでの工程で言い換えましょう。
旅行に行って帰るまでの工程の確認
旅行に行くとき、最初にやることは何ですか？そうですね、行き先の決定です。
複数人で行く場合はどの宿で泊まるか、どの観光スポットに行くかワイワイ話し合うはずでしょう。
行き先が決まったら日程調整と各種手配です。全員の予定が合う場所を見つけて、交通手段や宿を予約します。急に予定が変わることもありつつ、いざ当日！
予定通り旅行に行けることもあれば、珍道中と化すこともあるでしょう。それも楽しみつつ、決めた日程をこなして家に着く。これが旅行ですね。
要件定義は…ここだ！
この流れを踏まえると、「旅行の計画を立てる部分」と「要件定義」はかなり近いです。
複数人の際に行き先をヒアリングする行動は、ユーザー要求の確認そのもの。行き先での目的を決めるところがシステム要件決定に近いです。
要件定義書はいわば「旅行のしおり」ですね。
ちなみに基本設計は旅行の行程決め、開発実務は各種準備みたいなもの。前日の荷造りがテストで、当日がシステム稼働と想定しています
楽しい旅行にするには最初の計画が必須！
行き当たりばったりの旅行もそれはそれで楽しいです。ただ行き当たりばったり過ぎると「行きたかったスポットが休館日で行けない！」ということも発生します。
本当に全員が楽しい旅行にするには、最初の計画が欠かせません。
これ、開発もそうなんですよね
最初にしっかり計画を組んで、下調べもしておけば100％楽しめる旅行になります。
100%良い開発をするために、要件定義が欠かせないのとほぼ同じではないでしょうか？
要件定義を作るために必要なスキル
そんな例え話を挟みまして、最後に要件定義をする上で欠かせないスキルについて説明しますね
要件定義を作る際に必要なスキルは主に3つです。
ちなみに開発の技術面の知識は言わずもがなすですよ
- 要求を引き出せるコミュニケーション能力
- 実現できるか考えられる想像力
- 第三者にも伝わりやすく文章化する能力
1つ目が相手の要求を引き出せるだけのコミュニケーション能力。
ユーザー側も課題や要求を言語化しにくいことがあります。その際に、「もしかして、ここも困ってませんか？」と補完するのもエンジニアの役割。無理難題が来た時に上手に断れるかどうかも重要です。
2つ目が実現可能か把握するための想像力。
ヒアリングした内容を具体的にイメージできるかどうかがスムーズな開発には欠かせません。要件定義の担当者はできると思っても、実は開発者側には無茶ぶりだったというケースも多いはず。このようなすれ違いをなくすためにも必要なスキルです。
3つ目は伝わりやすい言語化能力。
ユーザーも開発者も全員同じ認識で開発に入れるよう、誰でもわかる言葉で要件定義をする必要があります。要件を正確に把握し、具体的な文章に落とし込んで初めて要件定義として機能します。
さいごに
開発の方針となり、炎上を避けるためにも欠かせない要件定義。開発工程においてどのくらい重要かわかったはずです。
必要なスキルで紹介したものを実現するには、知識と経験が欠かせないので、経験を積んだ状態で初めて要件定義を任されます。
でも、やってみないとわからない部分も多いですよね～
「要件定義を任せてほしい」
「そこそこ経験があるはずなのに、ずっと同じ工程ばかり任される」
そんなお悩みがある若手エンジニアの方！
リベロエンジニアでは自分のやりたいことに近い案件が多数あります。「本当にあるの？」と疑問に思うなら、一度無料面談でお話ししてみましょう。転職の意向の有無は関係ありませんよ！
＼エンジニアが大企業並みの給与と自由をGet／
