要件定義を成功させる5つの手法と見本になる成果物とは？

こんにちは！

ITエンジニア・webディレクター・webデザイナーなどのIT人材の自立・キャリアを支援するITプロパートナーズのCTOの柳澤（やなぎさわ）です。

弊社は、独立精神旺盛な優秀なエンジニアの方々の独立・起業サポートや、フリーランス支援を行っている会社です。

こちらのジョブウィズでは、企業の新規事業開発担当者の方や、システム開発責任者の方、事業責任者の方達に向けて、事業開発のコツや、自社プロダクトやWebサービスを立ち上げる際にポイントや注意点について、弊社ノウハウを包み隠さずにお伝えしています。

システムやソフトウェアの開発、全てのITを活用したプロジェクトに欠かせない工程が「要件定義」。

プロジェクトを成功させるか失敗させるか、それはほぼ要件定義で決まるといわれています。

要件定義の作成を中途半端にした結果、後々になり問題が発生し解決が難しくプロジェクトが失敗となるのはよくある話しです。

効率的にプロジェクトを進行させるためにも、要件定義はしっかりと慎重に行う必要があります。

しかし、そもそも要件定義の作成自体が難しくここで頭を悩ませている方も多いと思います。

そこで今回は、要件定義を成功させるために必要な5つの準備についてまとめてみましたので参考にしてみてください。

見切り発車の要件定義は失敗する理由

プロジェクトの鍵を握るといっても過言ではない「要件定義」。

何故なら、一般的な開発プロジェクトは最初に「要件定義」の工程が構成されることが多く、要件定義を間違えてしまうとスタートから間違えてしまうということになり、崖に向かって走っているようなものです。

その結果プロジェクト全体へ影響が出てしまいます。見切り発車な要件定義が失敗する最大の要因はどのようなものなのでしょうか？

全体の方向性がバラバラ

見切り発車で要件定義をしてしまうと、関係者間でのコミュニケーションが不十分になってしまい、方向性の共有がしっかりとされないままプロジェクトも進んでしまいますよね。

その他にも、インプット不足やミーティングの準備不足などが生じて、グダグダな要件定義活動になってしまう可能性が大きいです。

そこで、要件定義を成功させる5つの手法をお伝えします。

要件定義を成功させる手法①システムと業務フローの現状を知る

業務改革やコスト削減など、プロジェクトの目的はさまざまです。

しかし、ほとんどの企業では既に何かしらのシステムが稼働しており、そのシステムの課題を解決したいためにプロジェクトはスタートしています。

つまり、要件定義に必要な重要な課題の答えはここにあるともいえます。既存の業務フローと既存の業務システムに目を通すことにより、どの部分の問題を解決しないといけないのかが見えてくるはずです。

もちろん、システムの設計書通りに現場が動いてないケースも少なくはありません。

そのため、要件定義の精度を高めるためには設計書だけではなく保守担当者や関係者からのヒアリングも必要になってきます。

この作業には、多くの時間とコストを必要とする場合がほとんどです。

しかし、要件定義を成功させるためにあくまで重要なのは、現状の「業務フロー」「既存のシステムの問題」を理解すること。

少しでも無駄を無くすために、要件定義をスムーズに進行させるためにも確認できるよう調整しておきましょう。

要件定義を成功させる手法②必要な打ち合わせ回数を熟考する

要件定義では、具体的な課題や要望としているシステムを見極め整理し、整理したものを今度はどういったふうに形にしていくかを検討する必要があります。

それを決めると場として、細かい分野での打ち合わせが必要になってきます。

この時に考えなくてはいけないのが、「打ち合わせの回数を何回にするか」です。

プロジェクトによっては、根拠がないままなんとなく打ち合わせ回数が決まることも多くありますよね。

例えば、クライアントのスケジュールの都合で週に1時間しか都合が付かないなどさまざまです。

しかし、要件定義をするためにも打ち合わせは一番重要ともいえる工程です。

後々になって、打ち合わせ回数内に決まらなかったから追加で回数を増やすというのもよく聞く話しだと思います。

この打ち合わせ回数についてですが、適切な回数を決めるのは難しく一概にはいえません。

何が課題かを見極める

しかし、打ち合わせは課題を知ることが重要です。

そこで、それぞれ業務やシステムの機能で区切って考えていき、打ち合わせで検討する範囲を狭めてみましょう。

範囲を狭めることにより、対象が広すぎてイメージができなかった課題を見つけやすくなります。

このときに、区切ったことにより出てきた疑問点なども解決するための場を設けましょう。

例えば、クライアントの業務で気になる部分など簡略化できる部分がある場合は、こちらからそれを提案してみるのも良いでしょう。

そして打ち合わせは、あくまでSE主導で進行していくようにします。

クライアント主導になってしまうと、収集が付かないことが多いためです。

要件定義を成功させる手法③イメージしている成果物を共有

要件定義の成果物といえば「要件定義書」です。

しかし、この要件定義書には定義がなく人によってイメージするものは違います。

何故なら、この要件定義書は企業やプロジェクトによって構成が大きく違うためです。

例えば、要件定義で作成する資料にも同様のことがいえます。資料は、設計図だけで充分と考えるところもありますし、モックアップも必要と考えるところもあります。つまり、それだけ「要件定義書」は人によって多くのイメージがあるのです。

そこで、SEとクライアント双方が共通できるイメージがないならば自らが成果物を定義する必要が出てきます。要件定義で決めるのは、設計工程で必要となってくる機能を項目にまとめることです。

つまり、システム化にするにあたっての仕様のことを指します。システムの仕様の中で、機能の複雑性も伝わるようにしておくことも必要です。

これには、設計工程以降の必要となる作業を見積もるためです。

他にも、仕様が決定するまでの経緯、実装されている機能の必要性についても理由をまとめておくことでクライアントからの信頼を得ることができます。

成果物を提出する際は、どのタイミングで何を作るのか一目で分かるように明確にし、WBS（Work Breakdown Structure）を作成することにより納期の遅延のリスクを減らしましょう。

また、最終的な成果物標準を定義しておきサンプルを作成しおきましょう。

事前にサンプルを共有することにより、最終成果物のある程度のイメージを双方に持たせることができるためです。

関係者間で成果物の合意を取ること

この時に、関係者間で合意を取っておく必要があります。

合意がない場合、後から「思っていたものと違う」「内容の記述が足りない」といったクレームが発生しかねないからです。

要件定義を成功させる手法④役割分担の明確化

よくあるのが、プロジェクトの役割分担を明確にしないまま後々になり面倒な業務まで頼まれてしまうといったことがあります。

その結果、やらなくていい仕事が増えていってしまい本来の業務に支障をきたすことになります。

例えば、担当者が決まっていない作業を開発側が引き取ることがよくあります。

プロジェクトによっては、本来ならば発注者側がやるべき業務まで受注者側に任せているといったこともあります。

既存業務の整理や業務の将来的ヴィジョンなど、本来ならばこれらは発注者側が行うべき仕事です。

こういった環境になってしまうのは、役割分担が明確化されていないためです。そのせいで、本来ならば担当しなくてもいい仕事が増えていき非効率的な環境になってしまいます。

業務内容のリスト化とタスク振り分けをする

このような状況にならないためにも、自分が本来やるべき仕事をやれるようにするためにもプロジェクトを開始する前に作業の概要を一覧化することが望ましいといえます。

一覧化し、そこから発生する細かい作業は誰が担当するのか、もしくは支援止まりでいいのかといったように具体的な役割分担をRACIチャートでまとめておき、関係者全員が合意をしておく必要があります。

また、役割分担を決める際は本来担当すべき人物に遠慮せず割り振るようにしましょう。

その際に、開発者側で引き取る必要が出てきた場合はスケジュールへの影響も考慮し、難しい場合はスケジュールを改めて調整してもらうよう申し出るようにしましょう。

あれもこれもと請け負っていては、本来やるべきことができなくなってしまいます。

誰が何をすべきなのか、本来は誰の仕事なのかを真剣に考えることが重要です。

そして、必ず決定事項は文章にしてそれぞれの責任を明確にしましょう。

システムの受託開発が失敗するほとんどの原因は、要件定義にあるといわれています。

その原因に、発注者側が受注者側への過度に仕事を頼みすぎていること、それぞれの役割があやふやになり責任が誰にあるかの所在が検討付かないなど、情報が整理されていないことが原因にあることが多いと感じます。

[最重要！]要件定義を成功させる手法⑤要求定義と要件定義の関連性

そして何より、要件定義で重要なのは要求定義と要件定義が対になっていることです。

要件定義は要求定義を元に作成されます。

そして、日々ビジネス環境は変化して行く中で、ずっとそのシステムを使っていくということは、まずありません。

そんな中で、もしも要求定義と要件定義がついになっていなかった場合、後ほど大変なことになります。

具体的には、改善をするたびにプログラムのソースリストを辿ることになるといった事態に陥ります。

結果、改善の工数が多くなり、成功の可能性も低くなってしまうのです。 

さて、ここまで要件定義を成功させる手法について見てきましたが、その成果物である要件定義書についても触れて見たいと思います。

 要件定義書を作成する目的って？

システム開発を行う上で、重要になってくるのが「要件定義」を行うことだということは、すでにご存知だと思います。

その要望をまとめた成果物（プログラム、設計書など）が「要件定義書」です。

この工程は設計や実装工程の前工程として行われ、複数回の打ち合わせによりまとめられた成果物を作成していきます。

要件定義には決まった手法はなく、システム開発会社やそのときのシステムによりさまざまです。

この要件定義書は、システム全体を決める重要なスタートラインです。これにより、プロジェクトが成功するか失敗するかが決まると言っても過言ではありません。

それでは良い要件定義書の基本はどのようなところにあるのか次に見ていきます。

良い要件定義書の基本って？

まず第一に、良い要件定義書は基本がしっかりしています。

要件定義書は階層構造で作成する

これはなにも要件定義書に限ったことではありませんが、相手に文章を読んでもらう必要がある際はできるだけ読みやすい文章構造にする必要があります。

アウトラインが綺麗な文章は、それだけ相手が読む気にもなり全体像の把握をしてもらえます。

誰にでも何を求めているかが分かる文章

良い要件定義書の基本中の基本、それは実際に利用するユーザーが理解できる文章になっているかです。要件定義書というのは、IT分野に長けている人だけを対象としたものではありません。

そのため、SEやプログラマに向けた専門家向けの表現をした文章の場合理解してもらえないことがあります。確かに、文章の情報の質も大変重要なことですがそれを理解してもらえる表現でないと信用を得ることは難しく、全く無意味なものとなってしまいます。

良い要件定義書には要求の解決策が書かれている

そもそも要件定義の最終目的とはなにか？

エンドユーザーからの要求を明確にまとめたもの？そうではありません。

何を求めているかを明確化するのは当然、重要なのはその要求に対する「答えが文章」になっているかです。

ここまで書かれて、初めて要件定義は完了します。

そして最後に、要件定義成果物に記載すべき項目について見てみましょう。

最終成果物に必要な項目は？

成果物には大きく分けて三種類あり、今回ご説明する「最終成果物」はプロジェクトで最終的に目指し完成した成果物のことをいいます。

これは、作成された成果物により変わってきますがおおまかに以下の通りに分けることができます。

最終成果物に必要な項目一覧

・システム概要や背景

システムを導入する背景や理由を明確にすることにより、どういった目的で求められているかというプロジェクトの方向性をプロジェクトメンバー全員で共有することができます。

全員で共有することにより、メンバー同士の見解の相違が発生するのを防ぐことができます。

スムーズにプロジェクトを進行していくためにも、ある程度の背景やシステム概要を含めましょう。

・システム導入による目標

要件定義でヒアリングした内容を元に、システムを導入することにより達成できる目標や、導入により生まれるメリットを表記しましょう。

それにより、目指すべき最終成果物のイメージをより具体的にすることができます。

・システムの具体的な機能

システムの具体的な機能を詳細に表記することにより、エンドユーザーから求められている機能を実現できているかといった疑問点を解決できます。

また、詳細にシステムの機能を表記するために画像などを使い説明するようにしましょう。

・既存のシステムとの変更点など導入後のフロー

新しいシステムを導入することにより、既存のシステムとの変更点を可視化する必要があります。

そのため、導入後のフローを表記しておくようにしましょう。

その際に、細かすぎないよう書き方に注意が必要。

・システム要求

ハードウェアなどの構成、対応しているOSなどのシステム面についても表記しておきましょう。

これらを表記する理由に、システムの保守管理や引き継ぎを行う際に役に立つためです。

・性能または品質要求

もちろん、重要なのはシステムの機能だけではありません。それに対する処理速度が、エンドユーザーからの要求を満たしている必要があります。処理能力について、具体的な数字を表記ししっかりと品質要求を満たしていることを明確にしましょう。

・セキュリティ要求

未だに、ウィルスによる情報漏えいは跡を絶ちません。

こういった脅威にシステムが対応できるように、ウィルスなどの攻撃パターンを把握しそれに対応できるシステムにする必要があります。

またその際に、「何が」「何に対して」セキュアなのか表記しましょう。

また、OWSP Japanから「セキュリティ要件定義書」が配布されています。

基本的に、こちらの要件定義所をベースにセキュリティ要件を取り決めるのが、漏れがなく安全な方法といえます。

できる人がやっている要件定義の進め方とは？

ここまで要件定義の手法と最終成果物について触れてきましたが、要件定義全体を進めていく上で必要なことや、具体的な進め方について知りたい方もいらっしゃるかと思います。

以下の記事で詳しく解説しているので、合わせてご覧ください。

できる人はやっている要件定義の進め方とは？

まとめ

いかがでしたでしょうか？

要件定義を成功させる手法と作成目的、良い要件定義書の作成方法、そして最終成果物に必要な項目についてご説明しました。

要件定義はプロジェクトを成功させるのに最も重要なことであり、それだけ多くの方が頭を悩ませるものでもあります。

最終成果物の項目についても、今回記したのはあくまで基本でありこれが全てではありません。

さらに良いものへ仕上げるために、要件定義書は「誰でも分かりやすく、共有できるもの」になるよう心掛けていきましょう。