プロジェクトマネージャの仕事

プロジェクト管理については、プロジェクト管理とは何かで述べた通りである。プロジェクト・マネージャ（以下、PM）は、プロジェクトを管理することが仕事である。プロジェクト管理の大半はリスク管理である。PMが意思決定する場合の発想は全て、リスクの排除にある。 PMの仕事の中でもここでは特に、スケジュール管理、コスト管理、品質管理に分けて解説する。

プロジェクトには必ず納期が存在する。プロジェクトメンバーは、この納期にシステムを完成させ、納品することを目標に仕事を進める。PMは、この納期に間に合わせるためのスケジュールの決定を行う必要がある。 スケジュールは開発するシステムの規模、作業メンバーの人数、その他のリスクを踏まえて決めることになる。システムの規模が小さくても、作業メンバーが少なければ長期的なスケジュールを引く必要がある。短納期での開発を強いられるのであれば、人員を大量に投入することも考えなければならない。大企業であれば、人員を比較的簡単に確保することができるが、ほとんどの中小企業においては、ある程度の人員しか確保できないのが現状である。 PMは、納期やシステム規模が決定していない曖昧な条件（＝リスク）を徹底的に排除することも必要である。これらのリスクを早めに排除することができれば、より戦略的な意思決定を行うことができる。早急な事態を乗り越えるための手腕は確かに重宝されるが、緊急事態に至らせないためのリスク管理は極めて重要なのである。 スケジュール管理では、各開発フェーズの始まりと終わりの時期を決定する。さらに、それらの納期に間に合わなかった場合の対応策も用意する。プログラムの実装や、各機能の設計に対する作業納期まで細かく管理するPMはあまりいない。なぜなら、そこまで開発現場に深く関わってしまうと、PMが成すべき役割が疎かになってしまう恐れがあるからで、作業の細かいスケジュール管理は現場のリーダーに任せる場合がほとんどである。現場の細かい進捗に PMが口を出すようなときを、プロジェクト危機の始まりと考える場合もある。すなわち、現場のメンバーをPMが信用できなくなった状態である。

コストとは、プロジェクト遂行に必要な全ての費用を指す。開発を遂行するためには、PMやプログラマなどの作業者、開発するためのパソコン、ソフトウェアなどが必要であり、いずれも費用が発生する。パソコンやソフトウェアなどはある程度固定的なコストであるが、人件費に限っては、非常に流動的なコストと言える。PMは特に、人件費についての管理が重要になる。 プロジェクトで必要な費用は、プロジェクトの開始時に見積もるが、それはあくまで予測でしかない。もちろんそこには根拠が存在するが、未来のことを高い精度で予測しているだけで、予測が完璧に当たる場合はあまりない。例えば、開発するシステムの仕様変更によって、作業時間が増える場合がよくある。これは当初の想定していた仕様とは異なるため、当初の作業時間よりも多くの時間が必要となるためである。なお、仕様変更などのリスクに対しては、契約の時点で仕様変更に関する対応規則が定められる場合が一般的である。 こういった、リスクが排除されていない場合でのコストについて、対応が必要である。例えば、結合テストフェーズでバグが大量に発生し、単体テストをやり直す事態が起きたとしよう。これに対応するためには、スケジュールに遅延を起こさないように大量の人員や時間を使う。つまり、多くのコストを費やして、スケジュールを取り戻そうとする方法である。このような状況も想定してコストは設定されているのであるが、想定を大幅に上回ることもある。いわゆる、赤字である。赤字の状態を乗り越えるための方法はそう多く存在するものではなく、顧客に対する信用（納期確保）を最優先にし、コストの投入を継続していく場合が多い。他に、ムダな作業を排除するなどの効率化を推進する場合もあるが、作業の効率化ほど難しい課題もないであろう。

品質管理は、開発においてシステムの品質を向上させることである。システム開発を行う場合、単体テストや結合テストなどでのバグ検出目標を設定する。バグの検出はシステムの品質向上に直結し、目標とするバグ検出数を達成することが品質向上につながる。 結合テストなどはほとんどの場合、開発環境で実施されるが、システムテストに至ると顧客の本番稼働環境を利用する場合が多い。システムテストで結合テストレベルのバグが大量に発生すれば、結合テストまでの品質管理が十分になされていない、という評価をされる場合があり、各テストフェーズにおけるバグの摘出と修正は非常に重要なのである。 PMは、各テストフェーズにおけるバグの検出率を把握し、バグ曲線などを使って客観的に品質を分析する。バグ曲線は最終的に収束に向かうように遷移するが、現場で収束に向かう傾向にない場合、テストの実施方法を見直すなどの対策を考えなければならない。また、開発フェーズであればともかく、本番運用を開始したあとにもシステムに障害が発生することがよくある。その障害がシステムのバグなのか、顧客要件の問題なのかを分析し、顧客に説明する責任がPMにはある。

PMは、プログラム言語などの技術的な知識が必ずしも必要、というわけではない。もちろん実装経験があることは貴重であるが、プログラムの実装とシステム開発の管理業務では、内容が非常に異なる。一方、システムの設計やテストなどは、システムの規模やコストを見積もるために役に立つ知識である。 PMになるためには、まずはプロジェクトの各サブシステムの開発リーダー（プロジェクトリーダー）などを経験し、キャリアアップを行う。新卒で入社して、すぐにPMが務まるかというと、それは無理な話である。PMに必要なシステム開発の管理能力を身に付け、さらに、大規模なチームをまとめあげるためのチームマネジメント能力を習得する必要がある。

PMはシステム開発の責任者であり、開発チーム全体をまとめあげる役割を果たす。PMなしでは開発全体が進まず、代替の利かないポジションである。それゆえ、PMの報酬もシステムエンジニアやプログラマと比較すると、非常に多い。システムの規模にもよるが、1000万円を超える年収もザラである。しかしながら、その重責によるプレッシャーも相当であり、精神的なタフさなどのストレス耐性も必要である。また、開発が破綻した状態になると、ほぼ24時間耐性での状況判断が必要になるため、体力、精神力ともに欠かすことができない能力と言える。