技術系管理職のためのプロジェクトマネージメント論

　技術系管理職の仕事の一つに「プロジェクトマネージメント」があります。業種に関わらず、技術系の部署では、何らかのプロジェクトに関わっているものであり、技術系管理職が、プロジェクトマネージメント業務を担っているケースが多くみられます。また、自身がプロジェクトマネージャーをしていなくても、プロジェクトマネージメントの知識やスキルが必要とされる場面に数多く遭遇します。

　プロジェクトマネージメントの世界標準とみなされているのが、米国のPMI（Project Management Institute）がまとめた、PMBOK(Project Management Body of Knowledge)です。これを基にしたプロジェクトマネージメントに関する参考書や教科書も多く出ており、近年ではPMP(Project Management Professional)の資格を持っている人もかなりいます。しかし、実際にやってみるとプロジェクトマネージメントは非常に難しく、特に大規模なプロジェクトでは、PMPの資格を持った人をプロジェクトマネージャーやプロジェクトリーダに配置していても失敗するケースが多くみられます。

　参考書や教科書の知識だけではうまくいかないのかもしれません。実際にマネージメントをしていく上で、何が問題になり何が必要なのかを考えてみます。

プロジェクトマネージメントの方法論

　これまで多く使われてきたプロジェクトマネージメントの手法は、第二次世界大戦後のアメリカの国防・宇宙のプロジェクトから始まり、当初エネルギー産業やプラント建設関連で使われてきたものです。1990年台以降にソフトウェア産業で、大規模プロジェクトが行われるようになり、そのマネージメント手法として広く世界的に普及しました。いわゆる「ウォーターフォール型」の開発モデルが前提となっており、PMBOKの第七版で「予測型アプローチ」と呼ばれています。予測型アプローチには以下の特徴があります。

• プロジェクトは「独自のプロダクト、サービス、所産を創造するために実施される有期性の業務」と定義される。
• プロジェクトのゴールに至るまでの「プロセス」が定義されておりこれが中心的な考え方になっている。プロセスが終了したことを確認して次のプロセスに移行することが重視される
• 特に最初の、「立上げ」「計画」のプロセスは重要で、スコープやスケジュール、コストなど計画の大部分をプロジェクトの初期段階で立案することが求められる。

プロジェクトマネージメント実践時の問題

　予測型アプローチでは、初期段階で計画を立案しますので、計画の確からしさに影響する、要件やシステム仕様の「不明確さ」は早い段階で解消することが重要になりますし、仕様を実現するための技術的裏付けの有無も計画に影響します。しかし実際には、計画時に予見できなかったり、見落としてしまったりすることはどうしても出てきてしまい、これによりプロジェクトの途中で当初想定していなかった問題が発生してしまいます。

　問題がプロジェクトの後ろの段階で発覚した場合には、大きな後戻りが発生し、大幅に工数がかかってしまいます。問題は極力早い段階で発見し、迅速に「計画変更」を行う必要があります。

　しかし、多くのプロジェクトで、これがうまくできていません。以下のようなことが起きます。

計画を変更すべき時期を逸してしまう　大きな問題が起きていることに気づかず、計画を変更すべき時期を逸してしまうケースです。プロジェクトのメンバーの中には問題に気づいている人もいるのですが、プロジェクトマネージャを含むリーダー層には伝わらず（あるいは理解されず）後手にまわってしまうということがよく起きます。

大きな変更ができない　問題に気づいていても、その大きさを過小評価し大きな変更を避け、対処療法でやり過ごしてしまうパターンです。結局、対処療法では問題が解決せず、更なる変更が必要になり、傷口を広げてしまうことがよく起こります。

計画の変更が周知されない　リーダー層を中心に、計画が立案されてもそれがプロジェクトの各チームのメンバーにうまく伝わらず、うまく方向転換ができないと言う問題もよく起こります。混乱が起き、無駄な時間と作業が発生します。

　こうなってしまう背景には、「一度立てた計画は安易に変更してはいけない」という思い込みがあるように思います。また、予測型アプローチでは、初期の段階でしっかりと計画を立てることが要求されています。せっかく時間をかけて作った計画を変更するのは、余計に抵抗を感じるのかもしれません。「計画の変更＝プロジェクトの失敗」と思ってしまう人もいるようです。しかし、本当にプロジェクトを成功させるためには、計画は死守するものではなく柔軟に変更すべきものなのです。

　プロジェクト内の状況をリーダー層が把握できていなかったり、プロジェクトメンバーとの意思の疎通ができていないことも、計画変更がうまくできない要因です。このような問題に対し「頻繁にミーティングを行い、コミュニケーションを取る機会を増やす」ことを解決策とするプロジェクトが割と多いのですが、これで事態が好転するかはかなり疑問です。コミュニケーションは手段であり、本来必要なのは、プロジェクトのゴール、方針、対処すべき問題や解決策などを、プロジェクトメンバーが共通的に理解することです。伝わらないミーティングはいくらやっても意味がありません。

問題を防ぐための知恵

　実際に、計画変更がうまくできない失敗は多く見てきましたし、私自身も何度も失敗してきました。数々の失敗をすると、さすがにそれなりの教訓を学び、知恵やノウハウがついてきます。その中でお勧めできそうなものを３つほど挙げてみます。

計画変更を織り込んで計画する

　これを防ぐ方法として、あらかじめ「計画変更をすることを計画しておく」というやり方があります。計画時点で、ホールドポイントをいくつか設定し、その時点で計画の変更が必要かどうかを評価する計画にしておきます。また、このために必要な費用や工数も計画に織り込んでおきます。

　例えば、要件定義フェーズの後にホールドポイントを設定しておき、基本設計に入る前に、決まった要件から、その後の作業量を見積り計画の変更が必要かを検討します。あるいは、技術的な実現可能性やプログラム規模を正しく把握するために一部を試作する工程を入れておき、その後に計画変更の検討を行うなどもできます。

　変更に対する心理的なハードルを下げると言う意味もありますし、計画を早期に確からしくするという意味でも有効です。計画の変更が必要かを評価するホールドポイントの前に、不確かさを解消するためのアクションを計画しておけば、プロジェクト遂行する上でのリスクを解消することができます。

やり取りする情報を減らす

　コミュニケーションは手段であり、本来の目的はプロジェクトメンバーの共通理解です。コミュニケーションの仕方を改善することで、格段に理解が進むことがあります。

　口頭でのコミュニケーションは手っ取り早く伝えられるメリットはありますが、これに頼りすぎるのは危険です。人間が短期に記憶できる量には限りがありますので、たくさんの情報を聞いても覚えているのは一部だけです。言った言わないの問題や、伝言ゲームの問題が必ず起きます。また、口頭のみのミーティングでの決定は、その場のムードに影響されがちです。根拠がなくても声の大きい人の意見が通ってしまうのはよくある話です。

　一方、ドキュメントによるコミュニケーションは、大人数に効率良く確実に伝えるにの適した方法であり共通理解のためにはとても重要です。しかし、ドキュメントを作るのに時間がかかったり、せっかく作っても読まれないことも多いなどの理由により、特にエンジニアは人これを敬遠しがちです。

　多くの場合、文章を「書きすぎ」ていることが原因になっています。やたらと長い文章は、書くのに時間がかかりますし、読む側も読む気を無くします。簡潔、明快に最小限の文章で書くことができれば問題はかなり軽減されます。そのためには、書き手にライティングに対する知識とスキルが必要なのですが、これをちゃんと学んでいる人は意外と少ないようです。

　いずれにせよ、プロジェクトの状況を理解するためにミーティングなどでたくさんの情報を報告させようとすると、かえって状況がわからなくなります。むしろ、報告する量を抑えた方が、効率的に情報の伝達ができ良い方向に行くように思います。例えば、ミーティングでの状況の説明と伝達事項は何分以内とかにに制限するとか、報告書は報告のための文書は最初に様式を決め、最小限しか書けないようにしておくなども有効です。また、個々のプロジェクトメンバーのコミュニケーション力はプロジェクトの成否に大きく影響しますので、エンジニア向のテクニカルライティングなどの教育は必ずやっておくべきです。

定番の客観データ活用手法を使う

　誰でもそうなのですが、プロジェクトの当事者になってしまうと、周囲のムードに影響され、プロジェクトの状態を客観的に見るのが難しくなってしまします。このため、客観的なデータを使うことが推奨されていますが、どんなテータをどう使うのかは結構難しい話です。多くのデータを使って複雑なことをやろうとすると混乱します。まずは、シンプルで効果の高い、「定番の」やり方をやってみることをお勧めします。

EVA (Earned Value Analysis)

　スケジュール、コストの実績と計画の乖離を監視し、最終的な終了日とコストを予測する手法です。3つの計測値を使って計画との乖離を計測しますが、計測値は全てコストに換算して表します。

PV (Planed Value)　プロジェクトの計画時に作成されたコスト計画値でです。これを基準値として、乖離を計算しますので、ベースラインとも呼ばれています。

 AC  (Actual Cost)　実際に発生したコストです。経理データなどを使うこともできます。

EV   (Earned Value)　出来高を表しており、ある時点において完了している作業量をコストに換算したものです。コスト計画時に、その作業に対して計画していたコストの積み上げになります。

ある時点で、ACがPVを大幅に超過している場合には、問題があります。この場合は大抵計画時の見積もりが正しくないことが原因ですので、コスト計画の見直しが必要になります。一方、ACがPVよりも低ければコストは予算内に推移していて一見問題ないように見えますが、この際にEVがPVよりも低ければ、計画通りに成果が出ておらず、これからコストが計画よりも余分にかかるであろうことが予測できます。現在のペースでいった場合の完了時のコスト（Estimate at Completion : EAC)など予測し、許容範囲を超える場合には計画変更が必要になります。

収束曲線の活用

      ソフトウェアの品質管理などではお馴染みの手法で、横軸に時間の経過、縦軸に発生した障害をとったグラフを作ると、ゴンペルツ曲線と呼ばれるS字の曲線になります。この曲線の傾きなどを基に残存障害数や、障害の収束時期の予測を行ったりします。

　この考え方は、テストフェーズだけでなく他のフェーズでも応用できます。例えば、要件定義フェーズでは、検討すべき要件の数と確定できた要件の数、設計フェーズでは解決が必要な課題の数と、解決できた課題の数などを計測していくことにより、各フェーズがいつ終了できそうか予測することができます。

その他、アドバイスなど

　今回は、計画の変更について書いていますが、本当に難しいのは「変更しよう」と思い切って決断することだったりします。計画を変更してプロジェクトのメンバーを動かすためには相当なパワーが必要ですし、コストもかかります。また、上層部や関係部門に説明もしなければいけませんし、色々と文句を言われることも覚悟しないといけません。誰にとっても気が進まない話です。できればやりたくありません。

　一方、私の感覚では、最初に計画した通りに実行できるプロジェクトというのは、ほぼありません。仮にあったとしたら、それは元々プロジェクトとしてやる程のものではなかったものだと思っています。どっちみち計画は必ず変更になるものなのだと開き直ってしまったほうが楽になりますし、そう思った方がプロジェクトを客観的に見て決断できるような気がします。

　「計画を変更することをあまり深刻に考えすぎないように」ということを、最後にアドバイスしておきます。