プロジェクトマネージャは少ない情報から危機を推し量り対策を打たねば自らの首を絞める

プロジェクトマネージャがプロジェクトチームの現地作業に同行できないことはよくある話で、どちらかと言うとプレイングマネージャのプロジェクトマネージャでなければ帯同しない方が多いのかもしれない。

ワタシの志向は一度は現地に入りたい、と思うし、それは一番最初が良いと思っているんです。それは、一度でも自分の眼で見ておかないと後々に現地で何かあったときでも、何もなくても現地作業の段取りでも、ワタシの頭の中で現地の地図が広げられて色々なケースを想定できないとストレスになって、結局どこかのタイミングで行くことになるからです。

あとね、最初に入って、現地のお作法とかを知っておきたいんですよ。どれだけセキュリティが高いのか、とか、事務手続きが煩雑なのか、とか。そうした一見直接の現地作業と関わらないようなことも現地での構築作業が佳境になってきたときとか、トラブルで急に入館しないといけないとか、そうしたダッシュ力が必要なときに一つひとつの作業を情報を持っている人を探しながらなんてやっていられないのはそうなる前からわかっているので、あらかじめ知っておきたいんです。

プロジェクトマネージャの自分の眼で見ておくことは、それ以降の現地の情報が更新されたときにベースラインを持っておけるのでとっても精神的にも、ものごとの判断をするにもいいんです。

現地作業をするとき、必ずチームを組んでもらいます。メンバの中からリーダになるエンジニアを決めておく。現地で調整できるものはそのリーダにデレゲートしておく。調整が付かないことはそのリーダからエスカレーションしてもらう。そうしてコミュニケーションのフォーカルポイントを決めておくんです。それは現地に出したチームと開発拠点との接点でもあるし、現地の管理者とチームとの接点を決めておくことでもあります。それを決めておくことで、情報が発散したり、誰が最新の情報を持っているか、など自然と集約れるので防止することが出来るのです。

現地のチームの中の役割も明示的に決めておいた方が良いと思います。これは最近改めて実感したんですね。現地でトラブルのようなことがあったので。最終的にはトラブルではなく、現地チームの勘違いが根本的な原因だったんですけど。

ワタシたちのチームは割としっかり準備をして現地に臨みます。いや、そうさせるようにしたんですね。チームメンバのスキルレベル、経験、アウトプットや作業の品質に関する考え方がバラバラだったので。総合的な観点で言えば、ヘビーな方ではないかと思うんですが、それはそうしないと例えば現地の作業品質の担保にならないから、なんです。阿吽でこちらの思っている望んでいる作業品質とエビデンスを確保してきてくれるんならもっとワタシもメンバも楽にできるんですが。

でもそうはいかない。そうなるためには、プロジェクトマネージャとメンバの双方でめざし最低限の確保する作業品質レベルに対する期待を共有し続けなければならないんです。それが続けられるような関係でなければ、期待する作業品質のレベルを暗黙な阿吽の高いコンテキストの中に埋めておけないんです。だから明示的なコンテキストにするためにヘビーな準備をするんです。

ヘビーな準備は、手順書とか、現地作業の時間割とかその作業を遣り遂げてくるためのふるまいを記載するところに表れてくるんですが、それが続くとどうも表面的なその時間割を作ることが目的にすり替わって、現地で“間違えないための”時間割になっていないという危険を孕んでしまうんです。

これがとっても危険なんです。何が危険かと言うと、時間割を作ることが目的になっているので、そこに記載さえすれば、こちら側のチームが勝手に想定したりする事項を恰も“必ずそうなっていると思い込んでしまう”ということです。それダメなんですよ。こっちがそう思っていても、現地での準備とか、事前に調整したことが“ホント”にそうなっているかなんて現地に行かないと誰もわからないんです。

え？「事前に調整したんだろう？」って？それで全ての事前調整してきたことがそのとおりになっているなんて信用できますか。現物を見て初めて安心できるんじゃないんですか。

時間割には、事前に調整したとおりになっているかというアクティビティが必要なんです。他者の作業を信用するしない、ということではないんです。信用何て現物を観てからしたらいいんです。

それでも現地でチームはトラブルに合うものですけどね。それが時間割から抜けていたものかもしれないし、途中で他者の操作でトラブルを起こされることもあるし、ハタマタ自爆することだって。

そうしたトラブルの対応は、リモートにいるプロジェクトマネージャには直接知ることが出来ません。現地のチームメンバは頑張ってトラブルを特定しようとか、トラブル解決をしようとするんですが、その作業を後ろからでも横からでも観ていられないから連絡を貰うしなかないんですがここでやっぱりチームのリーダが頑張っちゃうことが多いんです。そうするとどうなっちゃうか。

連絡がタイムリーに要旨だけでも上がってこなくなっちゃう。これは困ったことです。こうなってしまうのはどこに原因があるでしょうか。そう、現地のチームの役割分担を明示的にしてあげないからなんですね。なんでも現地のリーダが頑張らないといけないわけじゃないんです。一緒に行ったら、全員で分担しないと結果的に仕事をトラブルをしている一握りの人と傍観者になってしまう。これが一番いけない。傍観者には払う給料はないんですよ。

そうした現地のチームの役割は、通常の運営から決めてあげるんですよ。トラブルのとき、って限定しちゃうとトラブルが起きたときに自然と行動を移せないんですから。通常の運営から相互にカバーできるように役割分担を決めておく。プロジェクトマネージャがそれで決めるのはロールだけでいいです。誰がどの役割をするなんて、そんな裁量はチームに譲りましょう。そしてチームでやりたい人がやりたいロールをやるのが一番安全で効率がいいんです。自分で望むということはそれだけ関心と集中力を持っていますからね。

今回チームのロールを明示的に組み、チームの役割分担を変えたのは、トラブルではないのですが、でもちょっと危険な予兆を感じたからです。それは直接現地のリーダの言動がテンパっているというか、パニくる直前のような言葉の勢いとか状況の理解度とかの匂いが感じられたからです。逆に言えば、その匂いを感じなければ気が付かなかったんですが。

それを見過ごしていれば、その作業のその後の対応も、その次からの作業も何も対策をせずに望むわけで、そうすればいつか大きなトラブルを自ら抱き込むことになったのではないか、と思うんです。おお、コワイ。

ちょっとした電話口での会話の中から危険を予知することの力も必要です。