SEとして働くのであれば将来的には意識しておきたいステップアップとしてプロジェクトマネージャーがあります。
マネージャーと名のつく通り、要は作業員ではなく人やシステムを管理する側に回るということですね。そんなプロジェクトマネージャーの仕事内容について説明します。
目次
やりがい
SEのプロジェクトマネージャーのやりがいは何といっても、プロジェクトを完遂した時の達成感に他なりません。大体のプロジェクトマネージャーは要件定義もしくはその前段階のシステム化企画から、その責務を負い各フェーズで作成する成果物の納期と品質確保のプレッシャーと戦いながらプロジェクトのチームメンバーを束ねてシステムのカットオーバー（リリースとも言います）を迎える訳です。
プログラマーや実作業に特化したSEも納期に間に合わせるために相当なプレッシャーもありますが、プロジェクトマネージャーだけは全体を俯瞰できる役割にいる為、その分責任が重大です。プロジェクトの規模は大小様々ですが完遂した時の達成感は相当なものになります。
スポーツで例えれば、プログラマーや実作業に特化したSEは「選手（プレーヤー）」、プロジェクトマネージャーは選手を束ねる「監督」にあたります。
実際の仕事内容（仕事の進め方）
仕事の進め方はプロジェクトの特性によっても様々ですが、今回は一般的なウォーターフォール型開発のプロジェクトのお話をします。
大前提としてですが、プロジェクトは同じものが一つとしてなく生き物のようなものですので、過去に通用したやり方が通用するとは限りません。
（ウォーターフォールモデルについてはこちらを参照ください → ウォーターフォール型開発とは？）
フェーズ毎に決められたが成果物が作成され、クライアント内で承認されることで
次のフェーズへ移行する開発手法です。一般的に広く復旧した手法で通常は5～6フェーズになることが多いようです。
システム化企画
まずはシステムの概要を決定します。ここでのプロジェクトマネージャーの役割はクライアントから大雑把な「こんなシステムが作りたい」という構想に対して、要件定義からカットオーバーまでの大雑把な月単位のスケジュールと、どのようなアクションプランが必要かのアウトラインを想像しながら費用・工数の概算を見積もります。ここでは主に、現実的なスケジュールを引く力とアクションプランを想像する力が必要となります。
見積もりなどの決済権やプロジェクトチームのメンバーの選定、スケジュールの引き方など、プロジェクトマネージャーが決めることが多いです。
プロジェクト全体の成功有無を握っているといっても過言ではない責任がプロジェクトマネージャーにはあります。
要件定義
プロジェクトマネージャーとしての勝負は要件定義フェーズで8割決まります。
まずはシステム化企画をもとにクライアントからシステムの要件を聞き出します。
このフェーズ中のプロジェクトマネージャーの仕事で最重要ポイントは、要件定義でいかに現実味のあるスケジュール・体制を確立できるかということと、品質を確保する点です。各項目のポイントは次の通りです。
体制構築
ポイントは業務の担当者と決定権を持つプロジェクトオーナーもしくは権限移譲された責任者を決めてもらうことです。そうでなければ、誰も決定者がいなくなり、せっかく決めたスケジュールも守られることはまずありません。
品質確保
ポイントはシステム化する業務に精通している担当者が必ずしもシステムに詳しくない場合が多々ありますので、そういった方々へ分かりやすく説明できるスキルと要件の中にトレードオフの内容や矛盾が含まれていないかのチェックができるスキルです。
スケジュール確保
ポイントは担当者とプロジェクトオーナーであるクライアントの責任者の思いは一致してもらうことです。概ね過去の失敗プロジェクトの半数は、クライアント内の意思統一が行われず、要件定義のヒアリングの場で意見のすり合わせが行われ議論が行われスケジュール遅延することが原因でした。中規模から大規模のプロジェクトでは機能要件、非機能要件、性能要件の他にも多岐にわたる要件を定義しければなりませんから、各項目で毎回すり合わせ不足が露呈すると、スケジュールの遅延に直結する為、致命傷となる場合がほとんどです。
外部設計～総合テスト
要件定義までで重要事項の決定や体制構築・スケジュール定義まで終えていますので、外部設計から総合テストまではスケジュールの予定・実績管理と、課題管理・リスク管理が主な業務になります。
課題・リスクが顕在化しそうか常にチェックしつつ、進捗と品質が設計通りに確保されているかを確認します。要件定義で確保した品質より外部設計以降のフェーズで品質があがることはありえませんので、品質を落とさないように担当者からどんな小さな懸念事項も聞きもらさないように、コミュニケーションを多くとります。
カットオーバー（リリースとも言います）
ここまでくれば一安心ですが、最後はデータの移行と、利用者の利用開始が待ち構えています。ここでは、移行リハーサルや並行稼働などシステムや業界の特性により対応内容を検討して、システム移行の影響を最小限に留める努力をします。
ここで成功してこそ終わりよければすべてよしとなります。
プロジェクトリーダーとの違い
大き目な開発ではプロジェクトリーダーが表に立ち開発を進める場合があります。
この場合はプロジェクトマネージャーの裁量をある程度プロジェクトリーダーに預けた状態です。
しかし、結局のところ最終的な決定権はプロジェクトマネージャーにあります。予算やスケジュール、メンバー構成、システム開発の方向性など、ご意見番的な立場でプロジェクトリーダーがまとめて来たものをジャッジするのです。
プロジェクトマネージャーは自らが表舞台に立つこともあれば、プロジェクトリーダーに任せて管理する場合もあります。
いずれにしても、プロジェクトマネージャーには、そのプロジェクト自体の最終的な責任があります。失敗も成功もプロジェクトマネージャーが基本的には責任を負います。
ですので、プロジェクトリーダーを立てる際も、任せられる人選しなければなりませんし、任せているから自分は何もしなくていいわけではなく、しっかりと自分の経験と知恵を絞り出し、間違った方向にプロジェクトが進まないか目を光らせて監視していることが大切です。
プロジェクトリーダーとプロジェクトマネージャーの違いについて、詳しくは以下でまとめています。
→ プロジェクトマネージャーとプロジェクトリーダーの違い
必要な勉強
資格の勉強が知識を得るためには近道です。プロジェクトマネージャーの概要を知る程度なら国家資格でもある情報処理推進機構（通称：IPA）の基本情報処理技術者試験の勉強がお勧めです。
さらに高度なプロジェクトマネージャーの知識・スキルを得たい場合にはプロジェクトマネージャー試験（PM）がよいと思います。さらに上位は米国PMI本部主催のPMP資格がありますが、これはお金も時間もかかりますので本当にプロジェクトマネージャーを極めたい人はどうぞという資格です。
ただし、資格もいいですが、やはり現場のプロジェクトマネージャーを見て学ぶことが現実的なスキルが身につきます。
- プロジェクトが傾きそうになった時にどういった指揮をとったか。
- コミュニケーションのトラブルが起きた時にどう対処したか。
- 〇〇さんがプロジェクトマネージャーのときは上手くいったのに、△△さんのときは上手くいかなかった。なぜだろう。
など。
理想的には、プロジェクトマネージャーになる前にプロジェクトリーダーを経験するはずです。
そこでプロジェクトマネージャーにべったり張り付き、しつこいくらいに質問して知識を盗むことをおすすめします。
給料・年収
３０歳～３４歳の平均で５８０万円前後です。（https://doda.jp/guide/heikin/2010/002_02.html）
将来性
過去から言われ続けていますが、システム業界のプロジェクトマネージャーは人手不足ですので今後も売り手市場です。将来性は大いにあります。
SEはプレイヤーばかりが多く管理できる人がとても少ないです。
キャリアを積んでステップアップしていかないといけない職種ではあるため、時間はかかりますが、目指す価値は大いにあります。
マネージャー職であればハイクラス系の求人からも選べることができるようになるのです。
また、管理する立場になると人間的にも大きく成長できます。給料としてもプレイヤーのころと比べると大きく底上げされるため、安定した生活を送れるようになるでしょう。。