【要約】PMの哲学 本紹介

今回は、読了してからは随分と経ってしまったのですが、私が最初に読んだPM本を紹介したいと思います。

室脇慶彦さん著「PMの哲学」です。

プロジェクトマネジメントに深く関わる方であれば、本書を読んだことがある方も多いかと思います。また、同じく、室脇さんが書かれた前著である「失敗しないITマネジャーが語るプロフェッショナルPMの神髄」についても読まれたことがある方が多いかと思います。

今回は、より中規模システム開発を想定した本書について私の実体験と共に特に心に残っている内容紹介したいと思います。

重要ポイント
制約条件のバランスを考える
三種の神器を装備する
プロジェクトマネジメントの技術力「工程定義力」
重要なのは「想定との差」
まとめ

重要ポイント

本書は、第１章プロジェクトマネジメントの優先順位から始まり、第２章では品質曲線についての説明がされています。

その後は、PMが考慮すべき事項、PMBOKのポイント解説、各工程におけるプロジェクトマネジメント要諦、そしてPMとしての心得などが室脇さんのお言葉で紹介されています。

その中で、私の実体験ととも重なり、特に新米PMの方にぜひ覚えておいてほしい内容をピックアップして紹介します。

〇制約条件のバランスを考える

〇三種の神器を装備する

〇プロジェクトマネジメントの技術力「工程定義力」

〇重要なのは「想定との差」

他にもたくさん紹介したいこと、特に各工程で求められるマネジメントのポイントについて解説をしたいですが、それらはぜひ本書を購入いただき読んでいただければと思います！

制約条件のバランスを考える

本書では、PMBOKにおけるプロジェクトの定義について触れながら、プロジェクトとは「独自性」と「有期性」を持つと説明しています。そして、独自性＝特異性だとして以下のように述べられています。

プロジェクトはプロジェクトである故に「特異性」が存在するので、プロジェクトを成功させるには「特異性」に応じた対応が必要です。

（中略）

よくあるケースですが、過去のプロジェクトで経験し成功したやり方をそのまま適応すると失敗します。
PMの哲学　室脇慶彦 (著)

新米PMは勿論、メンバーとして参画している若手や新人もこのことは意識すべきです。同じプロジェクトは二度と存在しない。だからこそ、その場その場で適切な判断をしなければいけないのです。あの時うまくいったから今回もうまくいくという考え方は、通用しません。ましてや、これだけ世の中の変化が激しい時代です。通用する訳がないのです。

そして、「特異性」が生まれる理由は、プロジェクトには制約事項があるためです。具体的には、品質、コスト、スケジュール、そしてスコープが制約事項となります。これらの要素がすべて同じというプロジェクトはまずもって存在しません。どれか１つでも違えば、それは過去のプロジェクトとは特異な部分となり、その点を考慮しなければいけません。

この制約条件を考慮した、今回のプロジェクトのための計画を立てることが、すなわち、”テーラリング”です。しかし、これらの条件はバランスを取る必要があります。

そして、私自身数多くのプロジェクトを経験する中で、１つを大切にするあまり、何かを大きく逸脱してはいけないと痛感してきました。しかし一方で、品質を高めようとすると時間がかかりますし、スコープを広げようとするとコストがかかります。

この４つのバランスを”いい感じ”に保ちながら、ステークホルダーを満足させることがPMの最大の仕事だと言ってよいでしょう。

三種の神器を装備する

室脇さんが所属する野村総合研究所では、「三種の神器」と呼ばれるプロジェクトマネジメントの重要なツールとして以下の３つを挙げています。

サブシステム構成図、スケジュール、体制図

これら３つのドキュメントについて、本書では以下のように述べられていますので紹介します。

プロジェクトとしての計画の妥当性を証明するドキュメントとして使われます。つまり、これらの３つのドキュメントが常に整合性をもって、プロジェクトとして維持されていると、該当プロジェクトは正常化されている確率が高い、と経験的にNRIでは証明されているのです。
PMの哲学　室脇慶彦 (著)

サブシステム構成図は、システム全体図と読み替えても良いでしょう。

そして、これらの３つのドキュメントがどのような関係性であるべきか、どのように整合性が保たれているべきか説明されています。

過去に私が経験したプロジェクトでは、サブシステム構成図と体制図の間にギャップがあり、それが原因が炎上した苦い経験があります。

人によっては、サブシステム構成とは呼ばないかもしれませんが、あるプロジェクトでは大きな主要テーマが３つありました。そこで、体制図上、プロジェクトマネジメントを行うPMと、テーマ横断でアプリケーションのリードを行うPLを配置しつつ、各テーマに対してTL（チームリーダ）を敷く計画を立てていました。しかし、ある１つのテーマを担当したTLのスキル不足により、PLが全体リードもしつつ、あるテーマのリードも担当することとなり、結果PLの負荷が高まり、遅延を招いたということがありました。

プロジェクトに矛盾が起きていないかを確認するために、３つのドキュメントを常に照らし合わせながら状況を注視し、もし矛盾を見つけたら是正をします。この確認作業をプロジェクト期間中はずっと継続することをぜひ忘れないでいただければ、きっとプロジェクトはうまくいくと思います。

プロジェクトマネジメントの技術力「工程定義力」

工程定義力、これが私が一番重要だと思う、PMの技術であり、むしろ、PMの仕事が工程定義そのものだと私は確信しています。

ぜひ、工程定義については、以下の記事もご覧ください。

工程定義、これはプログラマーにとってのコーディングスキルと同じくくらい、立派な”技術力”です。工程定義が下手なPMの下で仕事をすると、それはもう目も当てられません。

PMは工程定義をすることが仕事。自戒の念も込めて、そう肝に銘じたいと思います。

プロジェクトには特異性があるので、毎回同じやり方では通用しません。ですから工程定義力は重要です。中規模プロジェクトでは、比較的これまでの経験がそのまま活かせる場合が多いことは事実です。しかし、結果的に同じ工程を踏んだとしても、過去の工程を参考にするにしても、なぜこのような工程を定義して進めたかを検証し、不足部分や不要部分はないかを確認し、PM自身が納得することが重要です。
PMの哲学　室脇慶彦 (著)

特に、SAPやOracle EBSを代表するようなパッケージシステムの導入を行っているPMは、ついつい同じような工程定義をやりがちです。前回担当したあの会社さんと、同業種で、同規模の会社、同じモジュールの導入を検討しているから、今回も同じで良いだろう。

参考にできる部分はたくさんあると思いますが、ここはぐっとこらえて、本当に良いのか？、今回の顧客特有の事象はないだろうか？、そもそも予算はあるのか？、スケジュール的な余裕はあるのか？など、前述した制約条件を頭に入れながら、工程定義をしなければいけません。

重要なのは「想定との差」

本書では、要件定義フェーズでのプロジェクトマネジメントの要諦にて、概要設計工程の終了基準の策定として謳われています。

この想定との差は、QCDのすべてに対して言えます。

想定より、品質が良いのか悪いのか、コストがかかったのかかかっていないのか、遅延しているのか進んでいるのか、常に想定に対してどうかを確認するのがPMに求められる観察力です。

室脇さんは想定との違いについてこう述べています。

とにかく自分の想定との違いの原因分析を必ず実施します。プロジェクト全体を完璧に回すことは基本的に無理です。優先順の高い部分を手厚くし、低い部分は、制御可能な状況を作ればいいのです。

とにかくプロジェクトの状況を体感していれば、想定外のことは通常起こりません。従って、想定外と思ったことを本当かと確認することは、極めて重要です。
PMの哲学　室脇慶彦 (著)

ここで新米PMや若手の方にぜひ気づいていただきたいことがあります。

それは、「想定との差」を分析するには、そもそも想定がなければいけないということです。当たり前のことかもしれませんが、とにかく重要です。つまり、計画がないところに差は生まれません。

計画がなければ、どうなっていれば良いのか悪いのかそれすら判断ができません。なんか順調そうと思えても、そのままで本当に最終的なゴールまでたどり着けるのでしょうか？なんか良くないと思っていても実はそこまで悪い状況ではないかもしれません。

必ず、計画を立てること、これを肝に銘じていただければと思います。

PMだけでなく、新人や若手のうちから、自分に与えられた作業に対する計画を意識し、計画を立てることです。５日以内にこのプログラムを完成させておいてとPMから言われたら、自分の中で１日ごとにどこまで完成させておく必要があるのか、イメージし計画を立てます。

そうした自分の中の計画の積み重ねが、いずれ自分がPMとなり、プロジェクトの計画を立てるときに必ず活きてきます。