ITプロジェクトにおける意思決定マネジメントとは

プロジェクトマネジメントの知識体系では、ステークホルダーとかコミュニケーションマネジメントのようなカテゴリとなっていますが、ここでは、重要な意思決定に関するマネジメントを説明していきます。

現場のすべてのエンジニアが関わるとは限りませんが、プロジェクトマネジメントとしては最重要な項目です。

要求の合目的性確認の重要性を説明してきましたが、重要な意思決定においては、合目的性確認に大きく影響します。また意思決定は、ちょっと聞いてみる、といった簡単なものではありません。というのは、発生していることが細かくて個別のことであり、そのままちょっと確認しても通じないことが多いからです。

プロジェクトでの意思決定とは

プロジェクトにおける意思決定者とは

プロジェクトにおいては様々な意思決定がなされますが、それは階層的な意思決定となっていて、最終的にはプロジェクトオーナーの判断となります。

プロジェクトオーナーとは、投資をしている人になり、企業の中では社長や責任部門長となります。

最終意思決定者は大抵1人となるでしょうが、ある程度の企業であれば、より複雑な意思決定となります。

ステークホルダーと呼ばれますが、多くの関係者が出てきます。

ITシステム開発であれば、ユーザ部門長が存在します。IT関連部門長もいますし、ITの役割の中でも、業務アプリとインフラなどに分かれているケースもあります。

さらに業務といっても、各営業部門と経理部門がすべて関わっているケースもあり、それら関係する人たちすべてが意思決定に関わってくる可能性があります。

プロジェクトで意思決定が必要なケースとは

プロジェクトにおいては、様々な意思決定がなされます。

大まかにいうと、以下のポイントで意思決定が必要となります。

非常に大まかな分類であったため、それだけ、という疑問があるかもしれません。

確かに、細かい意思決定は、日常より多くあります。毎週課題を潰しているとしたら、毎週意思決定はされているとも言えます。

しかしここでは、プロジェクトとしての意思決定と考えてください。

また、開始と終了というのは、全体の開始と終了ではありません。プロジェクトは段階的にフェーズごとに進められることが多いため、段階的に意思決定がされるということになります。

プロジェクトにおいて意思決定の段取りがどうなっているかを知る

要件定義の意思決定は、最もと言えるほど重要タイミングのものです。

要件定義の完了は、その後の開発の始まりとなりますので、費用も大きく増えてきますし、なかなか引き戻せない状況となります。

例えば要件定義の意思決定において、意思決定の段取りはどうなるでしょうか。

要件定義を、関係部門を巻き込みながら終え、成果物とし、完了という意思決定とするということですが、実際は段取りがかなり複雑となります。

関係する部門長にそれぞれ説明の上、承認を得ます。5部門なら5部門なりに、9部門なら9部門なりに段取りが多くなります。その段取りを計画するタスクが数週間かかるかもしれません。

事業部門だけではなく、ＩＴ部門も3部門ほど関係しているかもしれません。

それぞれの意思決定はそれぞれ進められるものと、同時に承認を得るべきものとがあるでしょう。

そのような意思決定の段取りをプランニングしなければいけないということです。

そして、最終的な責任部門による承認の意思決定がなされます。

最終的な承認を経て、次フェーズの実行がなされます。

つまり、意思決定プロセスを考えなければ、月末で完成すればよかったものが、実際は月初に終わらせて意思決定プロセスに乗せないといけない、ということになります。

それだけ、思ったより期間はタイトになっているということです。

そして、次フェーズは前フェーズである要件定義が承認されないと、進められないという状況ですのでいったん現場は休憩となることさえあります。

さらに、重要な意思決定だけに、一発で意思決定されるとは限りません。

要件定義時は、ビジネスプロセスに影響する可能性が高いため、その影響も見据えた上での意思決定となります。よって、できると思って検討を進めていたが、現実的にやるとなったときに、本当に費用対効果は出るのか、やろうとしていたプロセスに変革することができるのか、という疑問が出ることも十分あり得ます。

よって、それらを踏まえて、段取りを考えないと、プロジェクト全体が進められないことになります。

プロジェクトでの意思決定マネジメントとは

なぜ意思決定にマネジメントが必要なのか？

意思決定は発注側がするものであり、受注側は受託範囲の仕事を実行すればいいです。しかし、実際には、発注側の意思決定は、受注側のタスクを含む全体のタスクに影響してしまいます。

意思決定がなされないと、次のタスクに進めることができないのが普通だからです。

また、意思決定には段取りが必要です。準備の上、上位者に承認を得ることもあれば、関係者に合意を得ることも必要です。そして、それらの順序は大切です。

関係者が多いとそれだけ工数が増えるのは想定できますが、関係者ごとに意思決定の観点が異なるため、それぞれ準備する必要も場合によってはあります。

意思決定の場を用意するのも一苦労の場合があります。上位の意思決定をする人ほど忙しいからです。

一定以上の金額のものを扱うのであれば、意思決定のマネジメントができていないと、いつの間にか半年ほど経っているようなことさえありますので、注意しないといけません。

意思決定のタスク

意思決定のタスクは、意思決定者の数と種類にもよりますが、いずれもある程度多い前提で考えます。

書き出してみるとかなり多く見えますが、さらに何段階もレビュー実施されることもあります。

そして、重要なことで記載されていないものがあります。

それは、意思決定全体に時間を要することによって起きます。つまり、意思決定に影響しうるプロジェクト状況の変化を反映することです。

最終意思決定を目掛けて進めていくわけですが、プロジェクトの実タスクが完全に完了してから開始することは稀です。実際はプロジェクトが進んでいる状態で、見切りで進めていかないと間に合わないです。

よって、意思決定プロセスの途中で、課題が解決したり、逆に課題が発生したりすることがあるため、その内容を反映します。

意思決定マネジメント

意思決定のタスクが多くあることから、マネジメントすることが必要となってきます。

タスクは前から順々に実施されるとは限りません。むしろ最終意思決定の場の設定が最初で、それに合わせて対応していくことのほうが多いのかもしれません。

意思決定の場の設定と場の実施、資料作成と修正反映といったようにタスクの種類ごとにスケジューリングされ、実施されることになります。

まずは、意思決定が間に合うようにタスク化されていることが重要です。そして、各タスクの実行者と関係者を明らかにし、スケジュールを押さえます。

実行中は、出来高を測りますが、定量的にできることと定性的にしかできないことがあります。

定量的に見えるものは少ないです。プロジェクトの定量的な情報は、意思決定においても定量的なものと言えます。

結論のサマリーは定性的になります。サマリーはただ単にまとまっているのではなく、意思決定者が意思決定する目線でサマリーされていないといけません。

状況が変化すると、サマリー内容は変わってしまいます。よって、都度状況を確認しながら、内容への反映方法を検討するようマネジメントされないといけないということです。

しかも、実プロジェクトと並行していますので、二重にタスクを進めていかねいといけない、ということになります。

課題がなくタスクが完了しているので問題なく完了、というシナリオだったものが、課題が発生し、しかもビジネス影響のありそうな課題であれば、タスクはおおむね完了しているが１点重要課題が出た、というサマリーとなります。しかもシナリオが変更になる可能性があります。

ここへきて重要課題が発生したということに対し、シナリオとしてはいくつかあります。

• 課題はなんとかなりそうなので、そのまま進めます。
• 課題の発生時期が問題のため、他に問題がないかを調査するタスクを加えます。
• 課題が重要なため、いったん中断します。

という結論が全く違うものになっています。

意思決定マネジメントは意思決定者が状況を常によく見ていられれば、意思決定は早いですが、実務的には、準意思決定者やプロジェクトマネージャなどが、意思決定者の目線である程度判断しながら、状況をまとめていくことになります。

全体状況が見られる人が複数いない場合は、遅延に繋がっていくでしょう。

意思決定を外注化？AI化？

意思決定だけでの大変苦労するタスクですので、なんとか効率化したいところですが、人の営みそのものですので、何ともしようがないと思われます。

ところが、人に頼めるような仕事とは思えない意思決定の仕事も、外注化されています。

正確に言うと最終意思決定は、意思決定権者が行います。その支援を外注化するということです。

意思決定のための情報を整理することは、それほど簡単なことではありません。しかし、外注できなくもありません。

安価でできるとは思われませんが。

また、意思決定のような複雑な思考においてもAIの活用が可能となってきています。

意思決定そのものはまだできないかもしれませんが、情報を整理したり、必要な情報を探索したりすることは、できるようになっています。

意思決定に必要な他の切り口はないか、ということも探索可能ですので、意思決定のための経験値不足を補うこととも言えます。

このように、意思決定を手助けする仕組みもありますので、企業は社員にさせることに拘らなくなっていくかもしれません。

人の営みでしかできないようなことは、確実に仕事としては残るでしょう。

意思決定のマネジメントにおけるありがちな問題とは

そもそも意思決定者が曖昧

意思決定のマネジメントには、意思決定ルートが定まっていることが必要です。

これは前提と思いきや、建前上担当役員などが最終意思決定者となっていても、実際は別な人が本当の意思決定と行うということがあります。

その人の意思決定結果をもって、最終意思決定者が決定します。

あるいは、部門長が何人かいるとして、よく知っている部門長の一人が実際の意思決定者であり、他は飾りにすぎないということもあります。

しかし、それらの本当の意思決定ルートは部外者に明かされることはありません。

さらに、本当の意思決定者と思われる人がわかったとして、その人にアプローチしたとしても、最終意思決定者が覆すこともあります。

つまり、意思決定ルートがわかりづらく、何かを押さえればいいという状態ではありません。

意思決定者は意思がない

同じような話ですが、最終意思決定者になっている人が、実は意思がないということがあります。

本来は非常に危ないことですが、意外とありえます。

他の人で意思決定できていれば、何とかその場は進められていると思います。

一旦進んでしまえば、そのような場面でもなんとか進めていくしかありません。

もちろん、その際は意思決定のマネジメントは難しいです。

また、別なケースとして、準意思決定者や途中の意思決定者に意思がないこともあります。

意思決定者の意思を見極めることも、意思決定のマネジメントと言えるのでしょう。

意思決定者が覗きに来ることを期待して、情報を出さない

意思決定のマネジメントはここまで説明してきた通り、苦労を要する面があります。

よって、できれば、現場を何とかするほうを優先したいという、現場の意見もあるでしょう。

意思決定者が現場を覗いていて、いつでも意思決定できるというのは、確かに理想的かもしれません。

しかし、大抵の場合は、何か仕掛けがないと、常に覗くのは困難です。

よって、何もしないというのは無理で、仕掛けを組むことを考えたいです。

わかりにくくて予定より大幅に時間がかかってしまう

意思決定はやってみたら実は意思決定者ではない、というようなことに出くわすと手戻りが大きくなりがちです。

単なる意思決定にすぎないものに、数か月要してしまうことすらあり得なくありません。

意思決定遅れを盾に取る

発注側の意思決定の遅れは、プロジェクトとしての遅延をもたらします。

受注側は、発注側の意思決定の遅れに従い、ただ遅らせればいいのでしょうか。受注側の都合もあるため、困ることもあると思います。

受注側ベンダーより、意思決定が遅れたのでその分は追加費用を請求します、という場面があるかもしれません。

しかし、それこそその通りうまく呑んでくれるとは限りません。

意思決定はプロジェクト全体の意思決定となるため、意思決定されるべきことは、プロジェクトとしてできていないといけません。

意思決定が遅れているということは、すんなり意思決定できない状況であり、プロジェクトにうまくいっていない部分があると想定されます。

うまくいっていない部分は、発注側と受注側の双方に責任があることが多いです。

受注側は、自分たちの役務はうまくいっていると思っていても、発注側意思決定をうまくいかせることができていない要素があるということを認識しないといけません。

どのくらい工数をかけて対応するかは別として、意思決定タスクへのリスクは、発注側と受注側いずれも考えておくべきことです。

発注者と受注者の意思決定、どちらに問題があるか見定めたい

意思決定はオーナーである発注側の意思決定を指す場合が多いですが、受注側も意思決定を行っています。

受注側責務において実行すべきタスクの責任は当然受注側にあり、そのタスクに関する意思決定は受注側ということになります。

受注側の意思決定を経て、受注側タスクが完成している前提で、オーナー側意思決定がなされます。

オーナー側が意思決定できないという状況となったときに、判断材料が出ていないことがあります。その判断材料は、実は受注側の意思決定不備による成果物不備があるのかもしれません。

意思決定者は、やはり先にある目的に合致しているかを判断します。

先にある目的と今進めているプロジェクトに差異が出てくることもあります。例え要件定義ではっきり決まったものであっても、別な事業上の理由で、目的に合わなくなっていることもあります。

意思決定は、そこで立ち止まる勇気も持ち合わせたものでもあります。よって、そのようなこともあることを常に関係者は考えていないといけないということになります。それは、受注者であっても同じです。

意思決定のマネジメントとして本当にやるべきこととは

プロジェクトにおける意思決定は、とても順調で楽な場合もあるでしょうが、難しいことも多いのではないでしょうか。

先に説明したようなありがちな場面は、かなり複雑なケースかもしれませんが、予め起きうることを考えておくに越したことはありません。

意思決定すべきことやすべき人がわかりにくくなっていて、意思決定に問題が生じている場合であっても、プロジェクトはあるべき目的に向かっているかどうかを見極めて、対応していきたいです。

ただし、目的だからといって、決めた範囲をころころ変えていいということでもありません。また、発注と受注の関係よる実行範囲もあります。変更は変更として、正しく処理されないといけませんし、変更も意思決定の重要事項です。