SIerのPM(プロジェクトマネージャー)の「仕事内容」と「役割」

SIerがお客様のシステムを導入したり運用したりする際はプロジェクト単位で仕事をしますが、そのプロジェクトそのものを管理するのがPM（プロジェクトマネージャー）の役割です。

一言で管理と言ってもその仕事内容は多岐に渡るため全てを網羅することはできませんが、今回の記事では、その基本的な仕事内容について、実際の現場の仕事の流れを想定してフェーズ毎に説明していきます。

【目次】

1. SIerにおけるPM（プロジェクトマネージャー）の役割
2. 「要件定義〜設計フェーズ」におけるPMの仕事内容
3. 「構築〜テストフェーズ」におけるPMの仕事内容
4. 「移行フェーズ」におけるPMの仕事内容
5. 「運用フェーズ」におけるPMの仕事内容

SIerにおけるPM（プロジェクトマネージャー）の役割

プロジェクトの管理者

PMはプロジェクトが完了するまでの間、全体の計画と実行をリードするのが仕事です。規模の大小はあっても、どのプロジェクトでも必ずPMがアサインされ、着任後はまずPMが中心となりプロジェクト計画を作成します。

プロジェクト内のどのタスクを誰が行っても良いのですが、通常はシステム作業やテクニカルなタスクは特定のスキルを持ったメンバーに任せ、PM自身は全体の管理を行います。

お客様から見ればPMはプロジェクト責任者でもあり、メンバーが行ったことはPMの責任として見なされますが、管理者であるからと言って必ずしも人事的な権限がある訳でもなく、あくまでプロジェクト管理という役割を担っているに過ぎません。それでも時にはメンバーの人的な管理も担うこともありますが、基本的にはプロジェクト全体のスコープ、スケジュール、コスト、品質を始終適切に管理することが仕事内容です。

PMBOKに沿った管理が基本

SIerのプロジェクト管理と言えば、PMBOKをベースにした管理が主流です。実務上は例えばWBSのようなツールに目が行きがちですが、プロジェクト管理の様々な場面で必要となる分野に対し、何をインプットに何をアウトプットするか、といったことが一通り網羅されているため、PMとして仕事をするのであればその知識体系を理解することは必須と言えます。

PMBOKに仕事内容が記載されている訳ではないため、それを参照すれば仕事ができる訳ではありませんが、漠然と読んでいるだけで内容を理解し仕事に活かすことは簡単ではないため、まずはPMの補佐をしてPMP取得を目指した勉強をしながら内容を覚えていくことが多いです。

PMPを取得しなければPMを名乗ってはいけないということは全くありませんが、PMとしてのキャリアを歩む場合は、まずPMBOKを勉強しながらPMP取得を目指す人が多いのが事実です。

「要件定義〜設計フェーズ」におけるPMの仕事内容

①プロジェクトの立ち上げ

正確には要件定義フェーズより前ですが、PMはまずプロジェクトの立ち上げから参画することが多いです。

立ち上げと言っても、お客様との契約前にある程度内容を詰めておく必要があるため、実際はPMが参画する時点でスケジュール、スコープ、要員、コストなどが概ね決まっているケースが殆どで、それらの前提のもとマスタースケジュールやWBSなどを詳細化していく作業を行います。

PMBOKではプロジェクト立ち上げの段階でまずプロジェクト憲章を作成することになっていますが、実態としてはお客様への提案資料をベースにした資料で表現されることが多く、上記のマスタースケジュールやWBSに加え、体制図、メンバー間やお客様とのコミュニケーション計画などを追加で作成します。
大抵はこの資料を使用してまずは自社メンバー内のキックオフ会議を開催し、内容を共有します。その後はプロジェクト全体のキックオフと初回の要件定義セッションを行い、プロジェクトが本格的に始まります。

②文書フォーマットを決めて分担する

このフェーズの主な成果物は要件定義書や設計書といった文書です。また、移行の全フェーズで共通して使用する課題管理票などもまずここで作成することが殆どです。

しかし各自が思いのまま作成しては整合性が取れなくなるため、PMは全体としてどんなフォーマットや章立てで作成するか明文化します。
過去に類似のプロジェクトを経験していれば自身でドラフトできてしまいますが、例えばお客様固有のフォーマットを要求されることもあるため、まず関係者の意見を確認することが重要です。

また、プロジェクトにおいて各種文書はベースラインとして重要な意味を持つため、フォーマットだけではなくどんな項目を記すかということも慎重に検討する必要があります。
記載が曖昧になると後で揉めてしまう原因となるため、正しい情報が明確に文書化されているかという観点の確認も責任を持って行うことになります。

③お客様やメンバー間のコミュニケーションをリードする

特にプロジェクトが始まったばかりの要件定義フェーズでは、お客様とのリレーション構築や密なコミュニケーションを心がけて行わなければなりません。単に会議を主催するだけではなく、関係者間の意思疎通がうまくいっているか常に気を配り、必要に応じてフォローするのもPMの仕事です。

結果的には関係者を集めた打ち合わせの形式となることが多いですが、課題があれば議論するだけではなく課題管理票や議事録などに記録するよう指示し、次のアクションが決まるまでリードすることも必要です。

「構築〜テストフェーズ」におけるPMの仕事内容

①忙しいメンバーから情報を引き出しコントロールする

このフェーズではメンバーがシステム作業に注力することが多いため、メンバー間の情報連携が疎かになりがちです。その中でも情報を集め、状況を記録してコントロールしなければなりません。
例えば構築期間中に定例会議を開催して各メンバーから状況を報告させるということを行うにせよ、ただ報告させて終わるのではなく、そこで問題が見つかれば問題管理票などに記録し、原因究明を指示する必要があります。また進捗が思わしくなければ要因を探り対処することも必要です。

小規模なプロジェクトではPMがシステム作業者を兼任していることもありますが、多くのプロジェクトではPMが手を動かしてシステムを構築することは稀ですので、その分、どう工夫して情報収集しコントロールするかが腕の見せ所となります。

②変更を正しく管理する

ウォーターフォール・モデルに沿ってシステム導入を進めても、全てが以前決めた決定事項や計画通りに話が進む訳ではなく、何らかの理由で修正が必要になることもあれば、時には大きく覆ったりします。
結果的には予算的にあるいは技術的に可能であれば対応することが多いのですが、そこに至るまでの道筋を変更管理というプロセスで管理するのがPMの仕事の一つです。

変更は構築やテスト時にだけ発生するものではありませんが、例えば要件や設計どおりに構築できないことが発覚することもあれば、設計通りに構築してテストをした結果、要件を満たさないことが発覚した、ということもあります。
その場合はただ設計を変えて取り繕うのではなく、まず変更をするべきか、その変更はスケジュールやコストなど他の要素に影響がないか、影響がある場合はどう対処するか、といったことを変更管理として検討して記録し、最終的に関係者が受け入れるか受け入れないか判断できるところまで調整することが必要です。

また、変更後は然るべき文書に変更を反映する必要もあります。このプロセスの詳細はPMBOKにもう少し詳しく書かれていますが、独断ではなく予め計画したプロセス通りに物事を進め記録を残すことが必要です。

③文書の最新化

構築やテストが始まり忙しくなると、各メンバーの文書に対する意識が薄れがちになります。上述のとおり変更管理を正しく行っていればよいのですが、少しでもメンバー任せにしておくと逸脱してしまうのが現実で、例えば設計書やWBSが更新されていない、問題管理票に最新の状況が記載されていない、といったことはしばしばあります。

メンバーからするとシステム作業は特に手を取られるタスクであるためそこだけに注力しがちですが、PMは常に全体を俯瞰して整合性を保たなければなりません。
時には全てをタイムリーに最新化できないこともありますが、放置せずに具体的にどれが残っていていつまでに仕上げなければならないか、ということを一つ一つ確認し、メンバーに的確に指示することが必要となります。

「移行フェーズ」におけるPMの仕事内容

①移行作業に向けた調整を行う

システム導入プロジェクトにおける最も重要な局面が移行です。システム移行を行う際は、システムの規模に応じて事前に移行判定やサービスイン判定を行うお客様もいらっしゃるため、PMは判定基準として何が必要か、基準を全て満たしているかを確認します。
判定は移行フェーズのイベントですが、予め要件定義フェーズ等の早い段階で判定項目を確認しておきます。本来は今まで行ってきたことを記載するだけですが、実は判定基準を満たしていないということにならないよう、日頃の管理が必要になります。
要領の良いPMはプロジェクトが始まると真っ先に判定基準項目を確認し、それに合わせた管理を確立しています。

また、移行作業内容の事前の検証もここでの大きな仕事です。自身で技術的なアセスは難しいかもしれませんが、担当者任せにせず、作業の前提や前後関係、体制などを一つずつ丁寧に確認し、移行時のリスクを極力ゼロにすることを行います。

②移行作業の旗振り役

移行作業が始まると、手を動かすのは特定のスキルを持った配下のメンバーであることが殆どです。そのため、PMは移行作業中はコントロール役に徹することになります。

また、途中の進捗状況をお客様へ報告する役目もあります。
万が一トラブルが発生した場合はお客様への報告をしながらメンバーへの指示もしなければならず、そうならないためにも、やはり移行作業前の準備が重要となります。

③プロジェクトのクローズ

移行作業が終わり、プロジェクトの目標を達成すればPMとしての仕事は終わりですが、事務処理を終えたらそのまま流れ解散という訳ではなく、何らかの形でお客様やメンバーへ感謝を伝えることを忘れてはいけません。

また、プロジェクト期間中に経験した有用な情報をLessons Learnedとして纏め、別のPMがその知識を活用できるようにしておくことも最後の仕事として必要です。プロジェクト管理自体はPMBOK等でフレームワーク化されていますが、この時はこうするということまで網羅されている訳ではないため、必ず誰かに役に立つのです。

「運用フェーズ」におけるPMの仕事内容

①安定稼働を目指しメンバーを管理する

SIerがシステムの運用を行う場合、システム導入と切り離して運用フェーズのみからなるプロジェクト単位で仕事をしますが、大抵は数年単位の契約となるため、一つのプロジェクトとしては長丁場となります。

更に、システム導入プロジェクトとは違い、特定の目的に向かって進むというよりも日々の業務をこなすという性質が高いため、PMとしての仕事はシステム導入時と大きく異なります。
プロジェクト全体の方針としてITILベースのプロセスを導入することが多いですが、例えばそれらのプロセスを日々メンバーに遵守させるといったことは、最も基本的な仕事内容です。
ただプロセスを制定すればよいという訳ではなく、やはりルールを逸脱するメンバーもいるため、その場合は何故逸脱したのか、どう再発防止するか、ということも考える必要があります。
運用フェーズではプロジェクト内で様々なルールを制定することが多いですが、どう守らせるかという点を忘れずに管理することが必要です。

②障害対応時のマネージ

システムを運用していると、どんなに気をつけていてもしばしば障害が発生してしまうこともありますが、この時PMとして必要なのは、お客様とメンバー両方のマネージです。
お客様からするとどんな影響があり、いつ回復するかが大きな関心事ですが、正確な報告ができるよう、障害回復作業にあたるメンバーに指示を出して情報を集めます。

また、回復方針をどうするかはメンバーだけで判断できないことがあるため、お客様とメンバーの間に立ち、双方の状況を一つずつ落ち着いて整理して対応を進めることも行います。
インパクトの大きなシステムほど素早く正しい判断が必要となりますが、障害の状況によっては、なかなか解決の筋道が見つからないこともあります。困難な状況でも諦めずに解決の糸口を見つける努力を続けることが大切です。

③メンバーの作業管理

期間が長い運用プロジェクトでは、メンバーの作業管理が重要です。運用プロジェクトでは事前に成果物が決まっているわけではないため、各メンバーのタスク全てをWBSで管理することは難しく、日々の管理方法を工夫しないとワークロードの把握が困難になります。

また、障害が発生するとそちらに手を取られてしまうため、いつも予定通りという訳にもいきません。
しかし事前に計画を立てることは基本で、誰にどのタスクをアサインしているか、また期日はいつか、という管理をしながら、全員のワークロードが溢れないようコントロールすることが必要となります。
どう管理するかはPMそれぞれのスタイルによりますが、例えば毎日短時間の定例会議を開催し全員の報告を元に調整することもあれば、プロジェクト管理ためのプロダクトを活用してオンラインで管理することもあります。

=================

＜エンジニアのキャリアに関する記事＞

【保存版】エンジニア(SE)からコンサルタントに転職・活躍するまでのAtoZ
https://www.axc.ne.jp/column/axis-column/2018/0227/se_cous.html

「2次受けSIer」からコンサルファームへ年収アップでの転職成功事例
https://www.axc.ne.jp/column-career-change-case/2015/0914/571.html

SIerにおけるSEの仕事内容＜各フェーズ毎＞【保存版】
https://www.axc.ne.jp/media/careertips/sierseworks

=================

今回の記事では、SIerにおけるPMの役割や仕事内容についてご紹介しました。

キャリアでお悩みの方は、ぜひアクシスコンサルティングにご相談ください。