DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

＜　前回　｜　目次　｜　次回　＞

今回は、プロジェクトにおける意思決定を「何に基づいて」行うのかがテーマです。

意思決定とは、何を優先するのかということであり、突き詰めれば「何を取り、何を捨てるか」を判断することです。
しかしながら、プロジェクトには多くのステークホルダー（利害関係者）が様々な要望を突き付けてくるため、PMにとって難しい決断を迫られるケースが往々にしてあります。

この時、プロジェクトとして「コレを捨てる！」という明確な決定を下すことができなければ、限られたリソース（要員や時間、予算など）の中でやがてジリ貧となり、メンバーに相当な負担を強いた挙句に、結局中途半端な成果しか得られないといった結果に陥ることになります。
そして、そのような状況にハマっているプロジェクトは世の中に非常に多いと感じています。

何が判断を妨げているのか？

このような問題を議論すると、良く「誰が判断に責任を持つのか、明確になっていないからだ！」という意見が出てきます。
もちろん、これは重要なことです。プロジェクト活動においては、プロジェクトの母体となっている組織との関係性が複雑になりがちです。例えば、A部とB部という2つの部門からメンバーを集めたプロジェクトでは、両部の部長がPMの決定に口を挟み、判断を下せなくなるようなケースがあります。対応策としては、あらかじめPM、A部長、B部長それぞれが判断すべき事項を切り分けてルール化しておくことが考えられます。

しかし、それだけでは十分ではないのです。いくら権限や責任の切り分けを行ったとしても、合議の上で決定しなければならない事項はどうしても出てきます。プロジェクトの根幹に関わる重要事項であればある程、誰かが1人で意思決定することは難しくなります。強引に独裁的な意思決定することは不可能ではないでしょうが、引き換えに一部のステークホルダーの満足度を損ねてしまうことになり、それではプロジェクトへの協力が得られなくなってしまいます。

従って、例え合議であっても、全員が納得できる答えを導き出せる「共通の基準」があることが非常に重要になってくるのです。

あなたがPMだとして、プロジェクトのスコープ拡大の是非をA部長、B部長と打合せ、意見を出してもらったとしましょう。A部長はYes、B部長はNo、どちらの主張もそれぞれに理解できるものがありますが、議論は平行線を辿ったとします。
「A部長は頑固だし社内に影響力をもっているから、B部長には泣いてもらって後でフォローしておこう」とか、
「今回はB部長の意見を採用しておき、そのかわり次の機会にはA部長の意見を尊重しよう」とか、

そのような考え方で重要な決断を下すなんてナンセンスの極みですが、「共通の基準」がなければこのような状況にもなりかねないのです。

「共通の基準」は何か？

共通の基準とは、つまり「プロジェクトの目的や目標」のことです。
よく、物事は「Why→What→How」の関係性で考えよ、と言われます。プロジェクトに置き換えて言えばこのようになります。

・Why：何のためにプロジェクトを行うのか
・What：プロジェクトで何を実現するのか
・How：プロジェクトをどのように進めるのか

そもそも出発点である「Why」がステークホルダー全員で具体的・明確に合意できていれば、プロジェクト開始後に論理的な議論と意思決定が非常にやりやすくなるのです。

“Why”を具体化する一つの方法は、ステークホルダーの要求事項を分析して体系的に整理しておくことです。例えば図1のようなイメージです。

図1 おでん屋台制作プロジェクトの要求体系例

このような要求の体系を共有できていれば、プロジェクト開始後にこの体系に無関係、または不必要な要望が上がってきたとしても、それらを却下することが論理的に判断可能になるのです。もしくは、仮に却下しないのであれば、この要求体系から見直す必要があり、WhatやHowも含めて変更する（つまり、追加のリソースを投入する）ことの説明がしやすくなります。

要求分析を行う際のポイントは、要求を要求間の因果関係（下位の要求が実現されれば上位の要求が実現されるという関係）に矛盾のない体系を作り上げておくことです。つまり、上位の要求に無関係や要望をこの段階で切り離し、あらかじめステークホルダーの様々な要望の中から真に必要なものだけを取捨選択しておくのです。
（ここで様々な要望を矛盾した状態で無理やり体系の中に詰め込んでしまうと、結局論理的に判断できなくなりますので・・）

また、要求は「手段」ではなく、「達成すべき条件（Condition）や持つべき能力（Capability）」として定義しておくこともポイントです。そうしておけば、仮に手段を変更する場合（例えば、プロジェクトで利用する製品を変更するとか、品質目標を変えるとか）、変更後の手段によっても要求が満たせるのであれば受け入れが可能ですし、逆に要求の実現に影響を及ぼすのであれば、やはり却下しなければならないことになります。

このような要求分析は、「BA（Business Analysis）」という業務領域にあたり、プロジェクトマネジメントにも活かせる様々な考え方や専門的手法が含まれていますので、興味がある方は是非書籍などご参考にされてみてはいかがでしょうか。

それでは次回もお楽しみに！！

＜　前回　｜　目次　｜　次回　＞