現役Webディレクターが「要件定義の進め方」を徹底解説！【注意すべきポイントは三つです】
こんにちは、カズキです。
本記事は「要件定義の進め方」について、現役Webディレクターでもあるボクが、初心者でもカンタンに理解できるよう、過去の経験をもとにまとめたものです。
要件定義はシステム開発の中でも重要なパートかつ、一番はじめにおこなう工程であることから、つまづく人も多いでしょう。
本記事では、できるだけ難しい言葉を使わないように書きました。
そのため、最後まで読んでいただければ「要件定義に大切なポイント」を理解することができ、明日からサクサク業務に取り入れることができるでしょう。
それでは、さっそく参ります。
現役Webディレクターが「要件定義の進め方」を徹底解説！【注意すべきポイントは三つです】
まず、基本的なトコロを押さえましょう。
そもそも要件定義とはなんぞや？
要件定義について、説明できますか？
結論から、
要件定義
↓
クライアント（発注者）の要望と、その要望をどのように叶えるか、を文章でまとめたもの。
基本的には、上記にかかる工程を指す場合がほとんど。
システム開発だと、クライアントの要望をどのような機能で実装するか、「機能要件を一覧にした資料」などを指すこともあり、システム要件定義書などと呼ばれます。
要件定義の目的としては、「クライアントの要望」と「実際におこなう作業」との段差（ズレ）を無くすことにあるんですね。
要件定義が終わってから「詳細スケジュール」を出したり「見積もり書」を作るのが、正しいシステム開発の流れです。
※要件定義を後まわしにしてしまうと、後々追加注文されてしまうなど、スケジュールが破綻しがち。
要件定義はどんな手順で進むの？？
ステップは至ってシンプルです。
step1：「業務上の課題」をヒアリングする
↓
step2：「要求」をリストアップする
↓
step3：「要件」をまとめたドキュメントを作成する
順を追って説明します♪( ´θ｀)ノ
step1：「業務上の課題」をヒアリングする
まずはヒアリングをおこなって、クライアントが抱えている課題を引きだしましょう。
NGなのは「どんなシステムが作りたいですか？」などと聞いてしまって、ヒアリングをすっ飛ばして要件定義を進めてしまうこと。
これは、イケません。
理由として、クライアント側も「課題分析がしっかり出来ていない」ことも多いからですね。
ヒアリングもロクにしないで言われたまま開発を進めてしまうと、後になってから追加機能が必要になったり、そもそも不要なシステムを作ってしまったなど、クレームに繋がることも少なくありません。
そうならないためにもシステムへ落とし込む前に「現状どのような業務課題があるのか」をヒアリングしつつ、それはシステムで解決できることなのか、また優先度として高いのものなのか、コミュニケーションを重ねてお互いの理解を深めることが大切なんですね。
最低でも、
・業務効率を上げる為にやりたいのか（※システムリニューアルが必要かも）
・売上を狙った一時的な施策なのか（※既存システムへの追加で充分かも）
・もしくは、その両方を見据えているのか
このあたりを整理するだけでも、システム開発にかかる規模感や目的のズレをなくせます。
step2：「要求」をリストアップする
さて、ヒアリングから「要求（業務上課題）」が明らかになったら、スプレットシートなどにまとめましょう。
こちらの作業は「要求定義」とも呼ばれます。
第三者がみても分かるような言葉で書ければベストですね。
（箇条書きだと分かりやすいのでオススメですよ♪( ´θ｀)ノ）
リストアップが済んだら、「追加要求はないかどうか」クライアントに確認を取りましょう。
要求をリストアップする際には、下記項目を追加しましょう。
→事前に記入しておけば、優先順位が決めやすくなるのでオススメ。
①なぜ行う必要があるのか
②「必須」なのか、それとも「希望」なのか
③「恒久対応」なのか、それとも「暫定対応」なのか
※恒久対応：長期的な解決策
※暫定対応：一時的な対応策
step3：要件をまとめたドキュメントを作成する
クライアントから頂いた「要求」に対して「システム上どのように再現すべきか」、システム担当者と相談します。
この時点で「システム仕様書」まで作る必要はナシです。
ここですべきなのは、「要求をシステムで再現することができるのか明文化すること」、また行う場合は「どの程度のリソースや予算が掛かるのか、想定される工数を算出すること」にあるんですね。
それを元にクライアント側と相談しつつ、実際に開発を進めるかどうか決めます。
予算やスケジュールに合わない場合は、代替え案を提案するなど柔軟な対応も必要になってくるでしょう。
また、システム仕様書は作らなくてもいいですが、実際に開発がスタートしてから、「やっぱり、システム上できません…。」では困ってしまうので、対応範囲と再現性の担保は慎重におこないましょう。（※このあたりは、システムエンジニアと二人三脚でやると安心です）
システムによってはサーバーサイドとも連携する必要もあるので、状況に応じてプロジェクトの共有などしましょう。
注意すべき「三つのポイント」をシェア
過去、さまざまな要件定義をしてきた経験から、以下の注意点を共有したいと思います♪( ´θ｀)ノ
その１：3Wを浸透させることはメッチャ大事、エビデンスに残すのがオススメ
3Wとは、以下のこと。
・Why（なぜ）：背景・経緯・目的
・What（何を）：内容定義・要件
・Who（誰が）：体制：役割
プロジェクトが進むと、ついつい目的をを忘れてしまうこともあるでしょう。
-ディレクション側-
よしよし、スケジュール通りで順調に進んでいるようだ…。
-開発側-
なんで、こんな訳わからないシステム作るんだろう…。
まぁ、要望通りやってるし、問題ないだろう…。
こんな感じで伝わっているようで、発注者側と開発側では捉え方が異なることはよくあること。
それを理解していないと、「伝えたつもりだった」とか、「それは聞いていない」など、言った言わないの話になることもあるんですよね。
出来上がったあと、イメージと違うものが出来上がってからではもう手遅れです。
こんな最悪の事態を防ぐためにも、最低でも3Wは明確にしておくべきでして、要件定義書にも記載しつつ、口頭でも説明するぐらい丁寧に共有するぐらいでいいのです。
技術者が情報を取りに行くことも大事ですが、プロジェクト担当者としてしっかり情報を伝えることができれば大きい事故は防げるはずです。
抜け漏れがないよう、しっかりやりましょう♪( ´θ｀)ノ
その2：システム要件には優先順位をつけよう
システム開発の工程において、マスト（必須）で作るべき機能なのか、それともウォント（希望）レベルなのか、それが振り分けられているだけで開発のしやすさもかなり変わるものです。
結論、システム開発は希望を突きつめたり、予算やリソースをかければ、いくらでもいいものが作れてます。
いい意味でも悪い意味でも、終わりがないんですね。
そのため達成すべき目標を決めることがゴールになるため、すべてのシステム要件に対して、優先順位をふっておく、と判断軸が生まれて、意思決定もスムーズにできるためオススメです。
–担当者-
ひとまず第一フェーズではここまでにして、ここからは効果を見つつ、第二フェーズで対応するか考えましょう。
みたいな感じで、落とし所を決められれば、お互いハッピーに仕事ができますね。
その3：予期せぬ事態は起きるものだと、お互いが理解しよう
入念に要件定義を行なっても、多少のズレは起こるもの。
理由は人によって言語の捉え方は異なって然りですし、ITに対する理解も人それぞれだからですね。
それは仕方のないことですし、とくにはじめて仕事をする人だと少なからず出てしまうはず。
大切なのは、そのことをお互い理解した上で要件定義をおこなうことなんですね。
こう言えば伝わるだろう…。ではなくて、これで、伝わってますかね？
のように、常にシツコイぐらい確認しつつ進めることが大切だと経験から学びました。
巻き込む力があれば、なんとかなる
個人的には、
「要件定義＝巻き込む力」
だと思ってます。
結論から、認識ズレやコミュニケーションエラーを起こさないように、しっかりと目的を定めてゴールが設定できれば、やり方はどうであれ正解です。
究極な話、技術的に不安なことがあれば技術者（エンジニア）に確認すればいいですし、場合によっては同席してもらえば解決するからですね。
必要ならサーバーサイドの人間も巻き込みミーティングをセッティングすればオッケイ。
すべて一人でやらないといけないルールなんて、無いんですよね。
確かにいつまでも誰かに頼っていたら迷惑かもですが、慣れるまでは関係者各位に情報共有をおこないつつ、バックアップしてもらう形でOK。
要件定義はプロジェクトの方向性に関わる重要なパートなので、全メンバーも把握しているぐらいでちょうど良いんですよ。
そのためにも日頃からメンバーと良好な関係を築くなど、いざとなったら相談しやすい体制を作れると良いですね。
ぜひ、今後の業務に役立ててもらえると嬉しいです。
▼Web開発のアウトライン設計を学びたい方は以下の記事をどうぞ
https://jpn-lifestyle.com/2020/08/15/wire-flame-how-to-make/