発注者の方　必見！～プロジェクト成功の鍵を握る要件定義8つのタスク

前回に引き続き、要件定義についてお伝えしていきます。
お伝えしたいポイントを中心に書いていますので、よく目にする情報・当たり前のことなどは、さらっと、書いてしまっていますがご了承ください。
では、早速要件定義の主なタスクを一つ一つ解説していきたいと思います。

前回の記事をご覧になってない方はこちらをご覧ください。

その１）プロジェクトの目的とゴールを明確に定義し、関係者が共通の理解を持つ

最初にプロジェクトの目的を明確にします。あるいはプロジェクト関係者全員で共有します。
なぜ新しいシステムが必要なのか、何を達成したいのかを明確にすることで、後工程において拠りどころを見失わないようにする必要があります。
当然と言えば、当然のことですね。

その２）現行の業務フロー（AS-IS）を整理し、課題を抽出・定義する

現在の業務フローを図として作成します。
新規ビジネスの場合は、すっ飛ばして構いません。現行業務はないですからね。

本来であればお客様自身で作成し、どの業務に課題があるのか整理していただくことが好ましいです。

ただ、多くの場合、我々がお客様にヒアリングしながら作成しています。
我々がこれを作成することで業務の理解度が上がり、お客様との認識のズレが生じ辛いというメリットもあります。
また、業務フローを可視化することで新たな改善ポイントが見えたり、お客様内においても共通認識を持つことができます。
イレギュラーな業務もこのフロー図で表現しておくことで、要件の抜け・漏れを防ぐことができます。

場合によっては、業務のスコープを広げた
ビジネスプロセスフロー図
を作成することもあります。
結局は、状況・規模・複雑度など様々ですので、都度都度何がどこまで必要か考えながら進めていくことが大切かと思っています。

その３）現行業務（課題）に対する要望を明確にし、業務要件（TO－BE）を定義する

業務要件とは一言で言うと「業務をどうしたいか、やりたいこと」です。
お客様は業務のプロなので、お客様主体で決定していくタスクになりますが、我々も一緒に考えていくスタンスで取り組んでおります。

たとえば、「在庫ありきで受注しなければならない」ことが条件の企業において

受注したものの、在庫がなかった・・・

という問題があったとします。
そういったケースでは

欠品した状態で受注しないこと

が業務要件（やりたいこと）となります。
お客様から

在庫状況をリアルタイムで把握できるようにしたい

という要望が発せられた場合、これは業務要件ともシステム要件とも捉えられます。人により考え方が異なるところです。なぜ、リアルタイムで把握したい、のかを考えると

欠品した状態で受注しないこと

だったりします。
でもどちらでもゴールは同じになるので、あまり追及しすぎなくてもよいかと思いますが
目的は、

リアルタイムで在庫を把握すること

ではなく

欠品した状態で受注しないようにする

ということになります。
「なぜ」を繰り返して考えることがポイントになるかと思います。

業務要件は業務のプロの発注側が担当すべき、システム要件はシステムのプロの受注側が担当すべき
なんて線引きをしてしまうとうまくいかないケースがあります。
我々は業務の素人かもしれませんが、お客様の業務を理解することで、業務要件も提案するスタンスで取り組んでおりますので、ご安心ください。
＃業務要件とシステム要件の境目は難しいですね。難しいだけでなくかなり重要なポイントと考えています。
＃機会があれば、別途ブログを書きたいと思います。

また、システムのセキュリティや性能要件などはお客様から業務要件を出してもらうのは難しいケースが多いです。
そんな場合でも、我々システムの専門家からお客様にヒアリングすることで業務要件と言いますか、
「なぜ」をもとに後述する非機能要件に落とし込んでいきますので、ご安心ください。

さて、この後は「こうしたい、こうあるべき」な業務フロー図を作成します。
が、システムに関係ないところで業務プロセスが大きく変わる等の理由がなければ、この業務フロー図は作成しても価値がありません。そういう場合は作成しません。
ただ、最終的にはシステムを利用した新しい業務のフロー図を作成しますが、現時点ではシステム要件が定まっていなため、システム要件を定義したあとに作成することになります。
長くなってきたので、一旦ここままでとします。

さて、この業務要件を定義した後は、この要件を実現するためにシステムに求めることを決めていきます。

その４）どの業務をシステム化するべきかを検討し、システム要件を定義する

その前に、新業務フロー図を作成した場合は、業務のどの部分をシステム化するかを決めます。
システム化による効果が大きく望めそうな業務、あるいは人手での業務でも構わない業務などを検討します。
この作業の前にシステム化する範囲を決めてしまうと、システム化すべきではない業務をシステム化してしまったり、システム化すべき業務がシステム化されないことにもなってしまいます。
システム化するのは効果が明確である業務のみとなるようこの段階で十分に検討しましょう。

以降の作業は、システム化する業務に対して行っていきます。

話を戻しまして、「システム要件」とは一言で言うと「業務でやりたいことをシステムでどう実現するか」です。

先ほどの在庫の件で考えてみます。
入庫（出庫）された現場から入庫（出庫）票を別の部署に持っていき、オペレータが現行システムに手入力しているような状況だったとします。

　【業務要件】
　　　欠品した状態で受注しないこと

に対し、システム要件は

　【システム要件】
　　　在庫がない状態で受注登録できないこと
　　　　→（そのためには）入庫したその場所で入庫情報を登録できること
　　　　→（そのためには）出庫したその場所で出庫情報を登録できること
　　　リアルタイムで在庫を把握できること（これは本当に必要な要件なのかは、今回は触れないでおきます）
　　　・・・・・

などとなりますでしょうか。
お客様のご要望、実現性などを踏まえながら定義していきます。

また、外部（別）システムとのデータ連携があるようなら、この時点で外部インターフェースの仕様を明確にする必要があります。

その５）システムの利用を想定した新しい業務フローを作成し、新業務フロー図を作成する

次に、システム要件を踏まえ、システムを利用した新しい業務のフロー図を作成します。
これでシステムをどのタイミングで利用しつつ、どのような業務フローとなるのかが明確になります。
新しい業務もイメージしやすくなりますね。

作成する資料は、上記の「業務フロー」と同様の図となります。

その６）システムに必要な機能を洗い出し、機能要件を定義する

次は、システム要件と新業務フロー図をもとに、新しいシステムがどのような機能を持つべきかを洗い出します。
たとえば、以下のシステム要件に対しては

　【システム要件】
　　　入庫したその場所で入庫情報を登録できること

以下の機能が必要になります。

　【機能要件（必要な機能）】
　　　入庫情報をバーコードで登録する機能
　　　入庫情報を編集する機能
　　　入庫情報を削除する機能
　　　・・・・・

これで、開発すべき機能がすべて洗い出せました。
システムのボリューム感や超概算見積もりも可能となります。

これまでを整理すると、下図のように業務→システム→機能と要件を落とし込んでいくことでシステムにどんな機能が必要かが洗い出せます。つまり、何をどのくらい開発するかが見えてきます。
なお、細かい説明は省きますが、複数のシステム要件を１つの機能に落とし込むこともあります。
「システム要件：機能要件」が「１対多」になるとは限りません。

その７）システムアーキテクチャを決定し、システムの構成を定義する

次に、システムのアーキテクチャを決定します。
クラウドを利用するのか、オンプレミス構成にするのか。
Webアプリケーションにするのか、ローコード開発するのか、外部サービスを利用するのか、など。
外部システムとの連携（関係性）もここで表現しておきます。
これらも費用にも大きく影響してきますので、お客様のご意向・ご予算等を踏まえながら決めていきます。

その８）ソフトウェア（システム）の品質要件を明確にし、非機能要件を定義する

最後に、システムに求める品質特性を明確にします。
セキュリティ、信頼性、性能などソフトウェアの品質に関わる件については、「機能」ではないため「非機能」と呼ばれています。
この非機能要件も定義する必要があるのですが、多くのお客様から要求は出てきません。
当たり前だと思います。プロでないとあまり意識しないところでもあります。
この要件については、我々のほうからヒアリングすることで網羅していきます。
たとえば
　・データベースのバックアップは必要ですか？
　・なぜ必要ですか？復旧までにどのくらいの時間が許容できますか？
のように、システムを安全に運用していくにあたり、必要な事項をヒアリングします。
ですので、ご安心ください。
非機能については、機会があれば別途ブログを書きたいと思います。

さいごに

ここまでお付き合いいただきありがとうございました。
だいぶ端折ったつもりですが、かなり長くなってしまいました。
要件定義でなにやるのか、超ざっくりお伝えすることができたでしょうか。
分からない、不安、知りたいことなどがあれば、お問い合わせいただければと思います。

やはり特に重要なポイントとなる「業務要件」「システム要件」あたりのボリュームが多かったですね。
もっと書きたいことや例外ケース、補足など多々あるのですが、今回はここまでにしようと思います。

これにて要件定義は終了！・・・・・・

ではありません。最後の仕上げが待っています。待っていないこともありますが（笑
次回は最後の仕上げについてお伝えしていきたいと思います。