コンセプチュアル・マネジメント

◆優先順位のマネジメントはプロジェクトの要

戦略マネジメントとは優先順位付けであるといってもよい。戦略の実行手段であるプロジェクトマネジメントの中では優先順位のマネジメントは特別な意味を持っている。

プロジェクトにおける優先順位はさまざまな要因で決まってくる。一つのプロジェクトの中でいえば、クリティカルパスにある作業は他のタスクに優先される。

プロジェクトのメンバーが専従ではなく、複数のプロジェクトに参画している場合は、プロジェクトの優先順位が問題になるケースがある。例えば、Ａさんが行っている仕事が双方のプロジェクトでクリティカルパスにあり、他人を以って変えがたい仕事である。すると、全体のスケジュールが遅れること、あるいは、それ以降でスケジュールを調整しなくてはならないことを覚悟してその人の仕事の優先順位をつけなくてはならない。その際に問題になるのは、プロジェクト同士の優先順位である。優先順位の高いプロジェクトのＡさんの仕事を優先する。

もう少し経営側に目を向けると、どのプロジェクトを実施するかという問題もある。これも一種の優先順位である。

つまり、あるプロジェクトの中でコンフリクトを解消するためには、いくつかのレベルの優先順位を考えていく必要がある。逆にいえば、いくら一つのプロジェクトの中で最適の意思決定をしたと思っていても、それが結果として、そのプロジェクトの失敗につながるケースは少なくない。

◆優先順位を考えずに失敗しているオフショア開発プロジェクト

最近、このようなパターンをよく耳にするケースはＳＩにおけるオフシェア開発である。人材が確保でいないのでオフショア開発に踏み切る。オフショアという解決策が本当に問題解決になるかどうかという根本的な議論はあると思うが、それはさておいて、オフショア開発を考える際に、まず、他のプロジェクトでとは考えない。決め撃ちである。オフショア開発の意義をどこにおくかにもよるが、リソースマネジメントにおくのであれば、リスクがあまりにも大きいにも関わらず、決め撃ちでオフショア開発をするのは無謀である。事業部なり、部門なりで、抱えているプロジェクトを抱えてプロジェクトを眺めてみて、プロジェクトの優先順位を分析し、リスクをとれるプロジェクトをオフショアとして、原因になったプロジェクトはオフショアのプロジェクトからのリソースをまわすという選択もある。

このような意思決定の根拠になるのは、プロジェクトの優先順位である。

◆「優先順位などつけれない」は本当か

ここで、最近、よく耳にする誤解を指摘しておく。ＳＩ企業の人からよく聞く話だが、

「実施しているプロジェクトはすべて受注したプロジェクトなので、優先順位という考え方はなじまない。すべてのプロジェクトを、納期の早いものから、同じ品質で収めるのが我々の任務である」

一見、正しい。ただし、「リスクがなければ」である。優先順位付けというのはそもそも何のために行うのかをよく理解しておく必要がある。リスクマネジメントである。プロジェクトリスクがある限り、論理的に準備したリソースですべてのプロジェクトに対応できるとしても、現実にできるという保証はない。ましては、３件に１件は納期遅れプロジェクトがあるといわれる業界である。原因はいろいろあるとしても３件に１件のプロジェクトは納期に遅れる。そもそも、上のような理屈など成り立たないのだ。プロジェクトをやめるという選択肢はないとしても、このプロジェクトではお客にないてもらうという選択肢はあるのだ（もちろん、おおっぴらにはいえないので、公式には上のようなコメントになるのだろうが、もし、真剣に言っているとすれば怖いものがある）。

ここで考えておくべきことは、プロジェクトの優先順位をマネジメントすることによって、確実に初期の計画通りに終わらないとならないプロジェクトは確実に終わることができることだ。これが戦略的なプロジェクト実行である。