 |
でんと机に構えて座り，全く動かないプロジェクト・マネージャ（PM）がいる。そこが開発現場の真っ直中ならまだしも，全く関係ない自分のデスクにかまえている場合すらある。そういうPMに限って，メンバーに対して報告を徹底させることに躍起となり，報告されていないことがあると叱咤する。すべての情報は自分に集まるべきとし，自分はその中心なのだから動かないと決めつけている。
確かに，PMはメンバーに対して安心感を与えるために大きく構えておく必要がある。しかしそれはPMの取るべき姿勢の話であり，実際に動くなという意味ではない。PMは開発の状況を，メンバーからの報告だけではなく，自分の肌で感じるべきなのだ。
動かないPM
Iさんは中堅SIベンダーU社で中堅PMとして認められている技術者である。入社以来，プログラマ～SE～PMと順調にキャリアを積み重ね，数年前からPMとして活躍している。今回，Iさんは得意先であるT社より受注した中規模Web系課金システム開発のPMとして任命された。この開発に当たって，T社から特定のJavaフレームワークの指定がされていた。これは今後T社が自社システムの標準として採用を検討しているものであり，今回はそのファーストケースとしての開発であった。K社としても初のフレームワークということもあり，これまでの実績からIさんを任命したのだ。
Iさんは自社のSE事情が厳しいことを考慮し，基本設計まではU社のSEで行い，詳細設計以降はU社の協力企業S社を使って行うことにした。開発場所としてはU社が準備したプロジェクト・ルームを使って行うこととなった。今回の開発に携わるメンバーは，協力企業も含めてすべてこの部屋に集まることとなったのである。
プロジェクトが開始してすぐに異変は発覚した。PMであるIさんが執務室にある自分の机に座っている機会が非常に多いのだ。詳細設計からの本格参画とはいえ，上流工程にもSEを数人投入しているS社の責任者から，サブリーダーJさんへクレームが上がったが，Iさんは一向に取り合わなかった。Iさんの言い分は次の通りだった。
「PMである自分は，社内調整やユーザーとの調整で社外秘の情報も扱う機会が多い。また社内上層部に対してもタイムリーな情報提供を行う必要があり，自席で仕事をするのが最も効率がよい。プロジェクトの運営方針は説明したし，報告ルールも作成し，コミュニケーション・ツールも導入した。後は運営方針に従って各自自分の仕事を正しく報告してくれれば問題ない。それに自席にいるとはいえ，レビューや定例会議には必ず顔を出すようにするし，協力企業への発注形態は請負なので勤怠管理を行う必要もない。従って，これがプロジェクト運営上の問題点となることはない」。
Iさんの言い分はもっともらしく聞こえたが，実態としてプロジェクトはうまく行かなかった。開発後半の結合テスト・フェーズにさしかかったころから，一部のサブシステムの進捗が計画通り進まなくなったのである。
理由はいくつかあった。
一つには，基本設計書に書かれた内容と詳細設計書に書かれた内容に食い違いがあった。基本設計書には複数の解釈が可能な表現で記載されている個所があり，結合テストで不具合が発生したのだ。
また，仕様を押さえている何人かのSEが欠席しがちになっていた。これによりそのSEしか知らない仕様の確認に手間取り，結合テストを中断するケースも目立ち始めたのだ。
これまで定例会議や進捗報告では「順調」となっていただけに，Iさんは苛立ちを押さえきれなかった。早速担当SEを呼び出して状況の説明をさせた。すると，担当SEからは意外な一言が飛び出してきた。基本設計フェーズの終盤にU社側のSEの1人と，詳細設計以降を担当するS社側の何人かのSEの間に意見の衝突があり，それ以降両者はまともに議論できるような関係にないというものであった。
Iさんは自社のSEとF社の責任者に向かって，「なぜ今まで報告しなかったんだ。そもそも，プロなんだから人間関係云々言う前に結論を出せ！」と言ってはみたものの事態は一向に進展せず，プロジェクト全体のモチベーションは低下する一方だった。
結局，問題の発生したサブシステムは，すべてU社側で再作成し，1カ月の納期遅延で何とか納品した。しかし，S社とは支払い条件についていまだ会社間で協議が続けられている。
Iさんの失敗
Iさんのように，自席に座っているケースは少ないとしても，プロジェクト・ルームの自分の席からなかなか動かないPMは少なくない。一日の中で一度もメンバーの間を歩いて回らないPMすらいる。
PMの仕事の一つとして，Net Enablerという仕事がある。プロジェクトの組織（Net）を能動的に動かすという意味だ。そのためにPMは常にメンバーに気を配らなければならない。具体的には，次のような項目について常にチェックする必要がある。
・メンバーのスキル，得意分野，苦手分野
・メンバーの体調，睡眠状況，持病の有無
・メンバーのモチベーション
・メンバー間のコンフリクト発生有無
腕に自信があるならば，ウォークスルーで各成果物の仕上がり具合を見て回るのもよい。気軽に声を掛け，ちょっとした雑談を交えるくらいでなければ，各担当者は心を開きにくいものである。
プロジェクトが一丸となって動いているという雰囲気を作り上げるのはPMとして必須の仕事である。そして，それがプロジェクト全体のモチベーションとなるのだ。そうすることで，初めてPMはプロジェクト全体の空気を肌で感じることができる。
この空気を感じることができなければ，Iさんのような失敗を起こすことになる。また，この空気を感じることができれば，たとえ報告が無くとも，「何か変だぞ？おかしいな」と感じられるようになるのだ。
PMにとって「ほうれんそう」は基本のき
社会人になって最初に教えられる言葉に「ほうれんそう」がある。報告の「ほう」，連絡の「れん」，相談の「そう」を略した言葉だ。これは新入社員が上司に対して行うべき事柄として教えられる。
しかし，プロジェクトにおいてはPMが積極的に行うべきだと筆者は考える。なぜならば，各メンバーは，自分の担当する部分がうまく行っている間は正しく報告するが，いったんトラブルが発生したり，遅延が発生したりすると，タイムリーに報告/連絡/相談が出来ない場合があるからだ。
また，人間関係の衝突などの場合，報告書に名指しで記載するケースは極めてまれである。これらの情報を収集する手段としては，対面によるインタビューが最適だと考えるからだ。
PMはどのような場合であっても，プロジェクトの状況を正しく把握する必要がある。それは工程表に記した線の状況や，WBSの進捗だけではない。それを支えているメンバーの状況も含めたすべての状況を把握するのだ。
そのためにも「ほうれんそう」は各担当者から行うものとは決めつけず，PMが率先して「何か報告することはないか？」「相談事はないか？」「連絡し忘れていることはないか？」と，常に担当者と会話するべきなのだ。
プロジェクトに参画したすべてのメンバーと気軽に，かつ本音で会話できないようでは，たとえ優秀（と社内で言われている）なPMであっても，プロジェクトを成功に導くのは困難である。
|
