プロジェクトマネジャーやPMOは、一人ひとりのメンバーの状況とプロジェクトの大局的な状況を見ること、つまり、「木を見て森も見る」視点が重要だ--。私は数多くのプロジェクトをこなしていくなかで、いつもこう考えてきました。しかし、どれだけ注意しても、うまくいかない事象に何度も直面しています。その時に思い知ったのは、木を見て森も見るだけでは、まだ何かが足りないということです。
大局的にプロジェクトを俯瞰し、細かい点までプロジェクト運営に注意を払っても、同じような問題が何度も出てくることがあります。そういう時、原因を追究していくと、大体は人の問題に行き着きます。さらに「なぜ、その人がそのような失敗をしたのか」と追究していくと、最終的には環境の問題に行き当たることが少なくありません。
実例を挙げましょう。あるプロジェクトで、プログラミングのミスが多発しました。その原因が担当者の不注意やコーディングレビュー不足であることは容易に想像できましたが、なぜそうした不注意や不十分なレビューが起こったのかを追究してみました。
たどり着いた結果は「担当者が他のプロジェクトと掛け持ちをしていて残業が続き、注意を欠いていた」ということでした。また、レビューで適切な指摘ができなくてもレビューワーは何の責任も取らなくてよいので、「真剣に集中してレビューしていなかった」という事実が判明しました。つまり、プログラミングミスが起きやすい環境ができていたのです。「木を見て森も見る。さらにはその環境まで考える」。これが経験から学んだ教訓です。
木や森は環境に合わせて育つと言えます。「開発期間は短いが、納期は絶対順守」という環境であれば、その環境に合わせたマスタースケジュールや全体計画（森）、各メンバーの作業計画やWBSが作られます。ここでどんなにプロジェクト全体をマネジメントしようと努力し、各個人の細かい作業にまで目配せしても、そもそもの環境が厳しければ、その環境に沿った問題が発生するということなのです。
同じような問題が何度も発生する場合、「環境を変えること」が根本的な解決につながることがあります。変更可能な環境要素を探り、改善していくしかありません。プロジェクト内で一般的に利用できる手段としては、悪い環境を矯正したり、悪い環境からの影響を緩和したりするための「仕組み化・ルール化」を考えてみるとよいでしょう。
プログラミングミスが多発した例で考えてみます。まず、プロジェクトを掛け持ちする場合なら、一定期間は1つのプロジェクトに集中できるように取り決め、その期間は「他のプロジェクトからの問い合わせは禁止」というルールを設定してみてはどうでしょうか。また、同じミスを繰り返さないために、一度起こったミスはチェックリスト化して、必ずセルフチェックするような仕組み作りが考えられるでしょう。
レビューの精度を上げる問題については、プログラミングミスが判明した場合の責任をレビューワーが取り、同じようなミスの再発防止策を必ず立てさせ、発表させるというルールを作ったり、各レビューワーのレビュー状況を調べて、適切な指摘ができているかを見える化する仕組みを作ったりすることが考えられます。いずれも、レビューワーが真剣に取り組まざるを得なくなる心理的なプレッシャーとして作用するはずです。
このようにプロジェクトをマネジメントする際の視点として、今までよりもう一段高いところから見渡し、プロジェクトが置かれた環境にも目を向けることが大切です。これまで手を焼いていたような問題に対して、違ったアプローチを導き出せるかもしれません。