ここからは、数々のプロジェクトをこなした“すご腕”PMへの取材を基に、「PMがやってはいけないこと」を紹介する。まずは、「計画策定」と「リスク分析」という2つの場面における、6種類の禁じ手を解説する。
計画策定：積み上げで計画してはいけない
システム開発プロジェクトを担当するPMが最初にやることであり、プロジェクトの成否を分ける重要な仕事が、計画の策定だ。
サブシステムごとに複数チームで進めるプロジェクトでは、PM1人でスケジュールを立てるのは効率的ではない。チームのリーダーにも手伝ってもらって、スケジュールを練っていくことになる。
このとき、PMが陥りがちなのは、リーダーが作成したスケジュール表を単にまとめただけで、全体スケジュールにしてしまうことだ。集まった計画の積み上げで、全体計画を立ててはいけない。
確かに、各リーダーのスケジュールを積み上げれば簡単に全体スケジュールは作れる。忙しいときは特に楽をしたくなるものだ。
だがそれでは「プロジェクトが始まって問題が発生したとき、PMは適切にスケジュールを調整できない」と、住商情報システムの森 雅昭氏（戦略ビジネス事業部門 メディアソリューション事業部 ブロードネット第2部長）は話す。
例えば、あるチームの仕様策定の作業に遅れが出そうになったとする。そのとき、積み上げた計画を見ただけでは、「その作業の期間を延ばしてもよいのか、それともほかのチームから要員を回してでも終わらせなければならないのか」と、判断に迷ってしまうのだ（図1）。
もし「この作業で確定させる仕様は複雑そうなので、期間を長く取りたい。しかしその後の設計作業が迫っていてそれほどは取れない」といったリーダーの意図をPMがつかんでいれば、「その作業はなんとしても終わらせなければならない」とすぐに判断できる。
そのために森氏は、リーダーにスケジュールを立ててもらった後、「何を重視してスケジュールを立てたのか」「スケジュールを作成する上で、どんなリスクを見込んだのか」といった、計画時のリーダーの意図を確認している。
ただし意図の確認だけでは不十分だ。森氏は「リーダーはチームをまとめる立場として、作業の優先順位やリスクを決めている。これらがプロジェクト全体と同じとは限らない。そこはPMが判断すべきだ」と話す。例えばリーダーは、担当するサブシステムのテストを、既存システムとの連携テストより優先しようとするだろう。しかし、既存システムは長年使っていて、インタフェースの仕様が複雑になっているとすると、プロジェクト全体としては、連携テストを優先したほうがよい。
なおプロジェクト計画は、スケジュールだけにとどまらない。要員計画やコスト計画など、あらゆる計画について、積み上げの計画をしてはいけないのは同じである。
計画策定：開発標準を重視してはいけない
プロジェクト計画は、あらかじめ決められた開発標準に沿って進められることが多い。開発工程ごとの作業内容が決められていたり、プロジェクトで利用する要件定義書や設計書のひな型もあったりする。そのままの形で使えるものが数多くそろっているので、プロジェクトを立ち上げるのに、開発標準は便利だ。
その開発標準の中に、工程や作業ごとの標準工数が含まれていることがある。プロジェクトの計画策定時に開発規模を見積もるときには、とても役立つ数値である。
しかし、開発標準に示されたこの数値をそのまま、プロジェクト計画に当てはめるのはやめよう。「標準工数は、過去のプロジェクトにおける実績の平均値であることが多い。当然ながら、PMが実際に担当するプロジェクトが必ずしもその工数通りに進むとは限らない」と、キヤノンITソリューションズの高槻洋史氏（製造事業本部 開発センター センター長）は説明する。
標準工数でプロジェクトを計画するのは、言い換えれば、すべてのメンバーが平均的なスキルを持つことを前提にするようなもの。
「精度の高いプロジェクト計画を作るためには、開発対象のシステムの難易度はどれくらいなのか、メンバーとしてどのような人がアサインされそうなのかといったことをしっかり把握した上で、工数を出していくべきだ」と、高槻氏は指摘する。開発標準ばかりを重視してはいけないのである。
開発標準の重視しすぎは、テスト工程における品質管理でも問題になるので気を付けたい。
NTTデータCCSの梅澤浩二氏（ビジネスシステム2部 マネージャ）があるプロジェクトに途中から参加したところ、「品質に関する標準に、プログラムのステップ数当たりのテスト回数が書いてある。その通りにこなさなければならない」と、PMがこだわっていた。「示された回数はあくまで目安ととらえた方がよい。それだけを重視するよりも、テストの内容に不足がないかどうかといったことにも配慮するほうが、品質向上には効果がある」と話す。
