業務仕様や開発仕様を確定するために利用者側と開発者側の連携のとり方

2020年2月23日

プロジェクトに必須の業務仕様

ITプロジェクトは業務仕様を策定してから開始したいが……

ITプロジェクトに関わらず、プロジェクトとして何らかの請負業務を発注する場合は仕様書を策定することが求められます。
官公庁、国公立大学などの公共機関であれば、こうした業務仕様・開発仕様を定めた後に発注を行います。しかし、民間企業間では、この業務仕様を定めずにプロジェクトをスタートさせることも少なくなく、トラブルの原因となってしまっています。

なぜ業務仕様がプロジェクトの失敗に影響を与えるのか

なぜ業務仕様がプロジェクトの成否に影響してしまうのでしょうか？
その理由としては、業務仕様が定まっていないと、「こうした使い方は想定していなかった」、「こんなシステムだと私たちは使えない」など、ある程度システムが形になってから要求事項がでてきてしまい、開発の手戻りが発生してしまいます。その結果、予算超過やスケジュール遅延が発生し、プロジェクトの失敗に至ってしまいます。

業務仕様が定まらない利用者側の原因

業務仕様は基本的にプロジェクトを発注する側（以下、利用者）の責任の下で作成されます。業務仕様が定まらない原因は様々ありますが、利用者側に起因するものとしては以下のようなものが挙げられます[1]平成9年春期PM試験午後Ⅱ問３の問題文を参考に作成 。

  • 要求事項の未整理
  • システムに対する過度な期待
  • 利用部門間の意見の調整不足
  • 業務仕様の検討および決定プロセスにおける利用者側の検討不足

これらの状況がどのようなものか、簡単に解説していきます。

要求事項の未整理

利用者側に起因する、業務仕様が確定できない理由としては要求事項の未整理が挙げられます。
つまり、「どんなシステムが必要なのか」、「どんな機能が必要なのか」ということがまとめられておらず、業務仕様が定められないというものです。

システムに対する過度な期待

先ほどは要求事項の未整理により業務仕様が確定できませんでしたが、これと真逆の位置にいるのがシステムに対する過度な期待により業務仕様が固められないというものです。
例えば「この機能でお客さんから情報を収集するのであれば、AIを使い自動で返信してほしい」というように、システムへの過度な期待により、仕様が定まらないという状況が挙げられます。

利用部門間の意見の調整不足

別部署で１つのシステムを共同で使用する場合は、利用部門間の意見が調整できず、業務仕様が固められないことがあります。
例えば、予約数を１つでも多く取りたい営業部門と、顧客の分析を深く行いたいマーケティング部門があったとします。Webサイトに予約フォームを作成しようとした際に、営業部門は入力項目をできるだけ少なくし、顧客の負担を減らして予約数を増加させようと考える一方、マーケティング部門は入力項目を増やして、顧客のことを知りたいと考えるかもしれません。
上記の例は極端ですが、システムを利用する部門間で要求事項や利害が一致しないこともあります。こうした調整ができないことも、業務仕様が定まらない原因となってしまいます。

業務仕様の検討および決定プロセスにおける利用者側の検討不足

たとえ要求事項が整理され、利用者の期待のコントロールや利用部門間で意見を調整できたとしても、業務仕様にそれらの内容を落としこまなければ意味がありません。
最終的には利用者間で収集した情報をもとに、十分に業務仕様を検討していく必要があるでしょう。

業務仕様を固める上で利用者側で明らかにしておきたい事項

業務仕様を固める上で、明らかにしたい事項は何でしょうか。
ここからは、業務仕様の策定で明確にしたいポイントを解説していきます。

何をして何をしないか？

業務仕様を固める上で大切なのは、「何をして何をしないか？」を明らかにすることです。とくに「何をしないか」を検討することが、利用者側の協議で重要な議題になります。
「何をするのか」という要求事項は、利用者の意見をくみ取ることができれば、いくらでも声があがってきます。しかし、それらの要求事項をそのまま業務仕様にぶつけてしまうと収集がつかず、いくら予算があっても足らないシステムになってしまいます。
そのため、一度意見をくみ取り、その中で「何をしないか」ということを検討していく必要があります。

利用者の人物像（ペルソナ）を明確にする

業務仕様を策定する上で、利用者側で開発しようとしているシステムを「誰が使うのか？」を明確にしておくことも大切です。
例えば、新卒社員のように業務経験や専門知識のあまりない人物が使うシステムなのか、専門家が使うシステムなのかで、開発されるシステムの様相は大きく変わっていきます。
専門知識があまりない人物像をイメージするのであれば、機能はシンプルなほうがよいですし、専門家が使うのであれば凝ったつくりのシステムになっていきます。

利用者側と開発者側が連携をとるための手法

ここからは利用者間、あるいは利用者と開発者の間で連携をとるために、どのような手法をとればよいのかを考えていきます。

ブレインストーミングによる要求事項の洗い出し

システム導入は、利用者間でどのようなシステム・機能が必要なのかを洗い出していくことから始まります。
よく使われるのがブレインストーミングの手法で、まずはざっくばらんに意見を言い合い、要求事項を洗い出していきます。
機会があれば開発者もこのブレインストーミングの会議に加わり、他の類似するシステムはどのような機能をもっているのかを話していくとよいでしょう。

ユースケースの作成

Webサービスを展開するときなど、カスタマージャーニーを考えることがあります。
カスタマージャーニーとは、顧客となるユーザーがどのようなプロセスを経てWebサービスにたどり着き、サービスを利用するかという一連の行動を考えるものです。
システム導入を検討する場合も、同様に各部門の利用者がどのような業務プロセスを経ながら使っていくのかというユースケースを作っていくとよいでしょう。
ブレインストーミングで洗い出された要求事項とユースケースを照らし合わせ、「何をして何をしないのか」を明確にしていきます。

利用者のペルソナ分析

ペルソナ分析もマーケティングでよく使われる手法で、象徴となる顧客像を作成し、その行動・思考様式を考えていきます。

同様に、導入しようとしているITシステムであっても、「誰がこのシステムを使うのか」を明らかにしていく必要があります。
この利用者のペルソナを作成した後に、ブレインストーミングの中で挙げられた要求事項を見直し、必要な機能を整理していきます。

ペルソナ分析については、下記の記事もご参照ください。

業務仕様・開発仕様を固められなかったらコンサルタントに相談する

今回は業務仕様や開発仕様を策定する上で、明確にしておきたいポイントと、利用者・開発者が連携するための手法を見ていきました。
今回紹介した手法をとりながら、必要なシステム・機能を整理していきますが、こうした情報をいくらあつめてもそれらを業務仕様にまとめるのは簡単なことではありません。
そんな時は、業務仕様の策定部分だけコンサルタントに任せてもよいかもしれません。

注

注
↑1平成9年春期PM試験午後Ⅱ問３の問題文を参考に作成

手法・技法業務仕様,要求事項,開発仕様

Posted by promapedia