本ブログは移転しました。こちらをご覧ください
◆2つの要求
スコープにプロダクトスコープとプロジェクトスコープがあるように、要求にもプロダクト要求とプロジェクト要求がある。要求=顧客(ユーザ)要求だと考えていると、ちょっと違和感があるかもしれないので、少し、ITの受注プロジェクトを例にとって商流の整理をしておこう。
ITのプロジェクトではRFPによって、顧客が調達をする際の要求が提示される。RFPではもっぱらプロダクト要求(技術要件)が注目されるが、技術要件以外にも、マネジメント要件が示されるのが一般的である。これらの顧客要求に対して、ベンダーは企業として提案をする。
◆顧客要求と自組織からの要求
その提案を作るにあたって、案件が受注できた暁には、経営としてプロジェクトに対して要求したいことが出てくる。経営からのプロジェクトに対する要求には2種類あり、戦略上の業務の位置づけ(あるいは、それを定義することを要求する)、および、顧客要求への対応の2つである。
たとえば、今年度の戦略目標の一つにしている技術Aの確立という項目があったとすると、このプロジェクトにAという技術を適用し、知見を得るといった要求が出てくる。そして、この要求を踏まえて、受注後には予算を決めることになる。
後者であるが、基本的に顧客要求を受けいれるのは受注責任者(一般には事業部長)である。具体的なとりまとめはプロジェクトイニシエータが行うことが多い。その責任において、プロジェクトに対して要求の形でその実現方法についての指示を行うという意味である。
経営のプロジェクト要求には、顧客のプロダクト要求への影響を与えるものもある。たとえば、顧客の要求が不十分で、要求追加が想定される場合、プロジェクト要求として顧客の要求追加に当たっては、トータルの工数が変わらないようにするというような要求をすることも考えられる。
◆要求マネジメント
このようにプロジェクト要求には、顧客からの要求と、経営(自組織)からの要求が含まれる。プロジェクトを立ち上げるにあたっては、このバランスが取れる要求マネジメントが必要である。
プロジェクトとプロダクトへの要求は、プロジェクトリクエストとしてプロジェクトイニシエータが取り纏める。そして、受注(事業)責任者が、プロジェクトリクエストにより、プロジェクトスポンサーを指名する。そして、プロジェクトスポンサーは、プロジェクトリクエストに基づき、プロジェクト憲章を発行し、プロジェクトの体制を整え、プロジェクトを遂行していくという流れになる。あとは、PMBOKなどでプロセス化されているとおりである。
もう一つ重要なことは、プロジェクト要求はプロジェクト憲章で、制約条件や前提条件に落とされ、さらにプロジェクトマネジメント計画書でマネジメント要件に落とされ、実現されていく。プロダクト要求は、RFPの書き方にもよるが、基本的はプロジェクトの実行中に製品要件に落とされ、実現されていく。
この具体化をしていくことが要求マネジメントそのものである。
最近のコメント