自分のコアな職能を説明する際、プロジェクトマネジメントの領域を語ることが多いものの、それを正しく説明することについてはあまり自信がない。

いちおう教科書的に答えるのであれば、PMBOKの定義に従い、有期かつユニークな目的を持った仕事であるところのプロジェクトを対象に、その完了までの計画を立て遂行すること、とかになると思う。説明としては概ね間違っていないと思うけれど、知らない人には結局なんだかよく分からないと思うので、もう少しかみ砕いて説明しようと思う。プロジェクトマネジメントを既に囓っている人は、PMBOKなり、類する書物などでもっと体系的に勉強してもらえればと思う。

「マネジメントとは経営すること」でも書いた通り、プロジェクトの進行管理や進捗管理だと捉えると高い確率で失敗するので、「プロジェクト経営」だと捉えて取り掛かるのがよい。

プロジェクトはユニークな存在であり、全く同一のプロジェクトは存在しない。依って都度都度、プロジェクト固有の進め方が求められる訳で、だからこそ、その経営は難しいのだけれど、敢えて言ってしまおう。概ね以下に沿って進めれば何とかなる。逆に言えば、上手く行かないプロジェクトは下記のどこかに問題があると言える。なお、トラブルのないプロジェクトはほぼない。上手く行くプロジェクトとは、トラブルとの付き合い方が上手いプロジェクトのことである。

現在地を理解する

プロジェクトをはじめる際、未来のことは考えるのに、意外と今現在どういう状態なのかを誰もよく分かっていないことが多い。ビジネス的な背景や課題、現在の業務、機能、前提条件や制約条件などを洗い出す。例えば、特定の技術を使わなくてはならない、期間や予算に制限がある、などのことである。ここをまず明確にすることからはじめる。

ゴールを決める

目指すべきゴール地点を決める。この際、明確な座標を決めること。ボンヤリとした未来ではなく、目的と時期と内容をできる限り具体的に定義する。特に成果物は明確にしておく必要がある。誰が読んでも誤読がないように、プロジェクトメンバー全員で納得するまで話し合おう。

現在地からゴールに至る道順を決める

現在地とゴールが決まったら、そこに至るまでの進め方を考える。アプローチ方法はおそらく無数にあるので、前提や制約条件などから、最も妥当な方法を検討する。この際、技術的な問題に直面することが多いので、検討メンバーには必ず専門家を入れること。専門家不在で決めたルートを進むのは死への行軍と同義である。決めるべきことの基本はヒト・モノ・カネ。

これらを取りまとめた計画書を書く

ここまで決めた内容を必ずドキュメントにする。これは絶対である。いくら正しい計画を立てたとしても明文化されていない計画は無いも同然であり、この先、容易に変容して道を踏み外していくことになる。プロジェクトは人間が行う仕事の集合体であり、人間は誤解する生き物である。

メンバー全員で読み合わせて合意する

とりまとめた計画書は、プロジェクトメンバー全員で読み合わせを行い、問題点を洗い出し、修正の上で合意するところまで持って行く。この「持って行く」作業がプロジェクトマネジャーの腕の見せどころではないかと思う。ここをサボる人はプロジェクトマネジャー失格なので、手を抜かず、丁寧に行おう。ただし、話を積み重ねていけば、必ず問題点にたどり着くし、着地点も見出せるはずなので、特殊な知見や技能が必要なわけではない。

実行する

プロジェクトメンバー全員で計画を合意できたら、あとは計画に沿って進めて行く。ここから先は進行管理の世界なので、計画から逸脱していないかどうかを確認し、逸脱している場合は原因が何かを調査する。

想定外のことが起きたら立ち止まって話し合う

計画にはない想定外のことが起きたら、計画を変更するか、変更せず続行するかをプロジェクトメンバー内で相談して決める。計画を変更すると決めたのなら、計画書を必ず変更する。計画とは基準であり、プロジェクトが正しく進んでいるかどうかを判断するための道しるべなので、計画を変更したなら基準も必ず更新する。ひとつの計画を変えれば別の計画にも影響するので、それを見極めるためにも、プロジェクトマネジャーひとりで判断せず、メンバー内で話し合うことが重要である。プロジェクトが上手く行かないのは、計画変更をルーズに行うからである。逆に言えば、ちゃんと管理さえずれば計画変更を嫌う必要はない。

なお、本稿は受託のウォーターフォール型開発を基本的には念頭においているが、アジャイル型の開発についてもベースは変わらないと思っている。ただ、受託におけるアジャイル型は別の課題があるのでそれはまた別の機会に。