PR

 プロジェクトマネジャー(PM)やリーダーを任されている皆さんはぜひ、胸に手を当てて自分に問い掛けてほしい。あなたは、プロジェクトの状況をきちんと把握できる“仕掛け”を積極的に作っているだろうか?

 ここでいう仕掛けとは、プロジェクトの進捗や課題、コスト、欠陥といった情報を、的確に収集できる手段を指す。日次や週次などの「いつ」、どのメンバーからという「誰が」、どんなフォーマットの報告書という「どのようにして」を決めたものだ。

 「社内で管理の仕掛けは決まっているのでそれを使っている」という方が多いかもしれない。筆者も楽がしたいので、できるだけ社内で規定された仕掛けでプロジェクトを進めたいと思う。

 ところが、ここに大きな落とし穴がある。今回は「管理の仕掛け作りを怠るな」というルールを紹介しよう。

情報収集の仕掛けは画一的ではダメ

 管理の仕掛けは画一的なものではダメだ。同じ仕掛けですべてのプロジェクトがうまくいくほど現実は甘くない。これが、今回のルールの本質だ。

 問題が発生すれば、最終的に責任を負うのはリーダーである。それだけに、リーダーはプロジェクトの生命線といえる管理の仕掛けを、プロジェクトの特性に応じて作る必要がある。

 例えば、難航が予想されるプロジェクトなら、報告間隔を短くしたり、報告内容を細かくしたりする。一方で、管理の負担を軽減するために、重要ではない情報の報告を割愛したりする。こうした工夫こそが、プロジェクトにおける問題の早期発見につながる。

 ただし難しいのは、プロジェクトの組織が「マトリクス型」になっているケースである。大きなプロジェクトでは、サーバーや基盤、ミドルウエアなど、チームが分かれており、各チームにそれぞれリーダーがいる。加えて、各チームが参加する設計工程や実装工程にはフェーズ別のリーダーがいる。そのため情報の伝達系統が2重となり、本来作るべき管理の仕掛けを導入しづらくする原因になる場合が多い。

 筆者もかつて、マトリクス型組織のプロジェクトを任されたとき、ユーザーの非難を浴びた経験がある。

 筆者がPMとして参加したそのプロジェクトは、サーバーや基盤、ミドルウエアなど各チームが分かれ、それぞれリーダーがいた。筆者は全体のPMとして、規定の管理資料や定例会など管理の仕掛けを用意。各チームのリーダーも、それぞれの仕掛けを用意した。

 いろいろな問題が個別には出ながらも何とかテストフェーズの半ばに差し掛かった。ところが、あるチームの様子が変だった。筆者は状況を確認するために、チームリーダーを問い詰めた。するとリーダーは「少々遅れているが、週末にはリカバリーできる」と回答した。現場を見渡すと、数十人のメンバーがボロボロになっている。一方、筆者の所属していたサーバーチームもやや遅れ気味。このため「自分たちのことは自分たちで何とかしてくれ」と思い、祈る気持ちで進捗の回復を待った。

日々の作業が多忙で状況を報告してくれず

 2週間後、根拠のない祈りもむなしく、そのチームの作業が「1週間の遅延」という形で顕在化した。ユーザーから「なぜ遅れたのか。どうするつもりか」と責められた。状況把握ができていないので対策を説明できない。そのチームのリーダーには「やるべきことが多すぎる。必死で作業しているので待ってほしい」と、状況の報告を拒否された。これでは遅延の原因が分からないばかりか、進捗状況の正確な把握もできない。筆者は途方に暮れた。

 やむなく上司に相談した。すると上司は、次のような行動を取った。まず報告頻度を週次から日次に変更。次にユーザーとの検討会を2日に1回設定した。報告書を書く暇がないメンバーには、個別に状況を聞いて回った。報告の余裕がないというリーダーには義務だとして作業よりも優先させた。その結果、進捗遅れの状況や原因をつぶさに把握し、人員を追加投入する対策を打った。そして、テストフェーズの終了後には進捗遅れを解消してみせた。

 規定の管理の仕掛けを取り入れただけではうまくいかないことを痛感した瞬間だった。現場の特性に応じて、しっかりと状況をリアルタイムに把握できる仕掛け作りを怠ったのが原因だ。勇気を持って現場に切り込み、その場に合った仕掛けを作るべきだった。

大森 久永(おおもり ひさなが)
1998年に日立製作所入社。以来、銀行システムのSEとして従事。2003年から2年間、旧UFJ銀行に出向。2005年に三菱東京UFJ銀行のDay1統合プロジェクトに参加。インターネットバンキングの構築プロジェクトで、PMとして約600人のメンバーを率いた。