- ホーム>
- ITコンサルティング>
- システム開発 PMO>
- ベンダーサイドPMOの業務内容とは?プロジェクトでの役割や1日の過ごし方
公開日:2024.02.28(水) 更新日:
ITなどソリューションを担当する「ベンダーサイドのPMO」を紹介
PMOはその名前の通りプロジェクト管理が主な役割となります。
プロジェクトによって求められる役割は異なるため、現場が変わるごとに新しい知識やスキルを身に付けていく必要がある非常に難しいポジションです。
しかし、プロジェクトの中核を担うことになるため、年収も高くやりがいのある仕事になります。
近年はDX活用が社会的に重視されており、企業でも特にIT関連のプロジェクトが増えてきました。
その影響でPMOも2種類に分かれることがあります。
発注側の企業で組織される「ユーザーサイドのPMO」と、受注側の企業で組織される「ベンダーサイドのPMO」です。
ここではベンダーサイドのPMOについて詳細に取り上げます。
業務内容は具体的にどのようなものか、ベンダーサイドのPMOになるにはどのようなスキルが必要なのか、向いている人はどのような特長があるのか、などの点について理解を深めることができます。
ぜひ参考にしてください。
ベンダーサイドのPMOの業務内容
たとえば、SIerなどではクライアント企業へシステムを導入するためプロジェクトを立ち上げます。
そのようなITソリューションを提供する側の企業のプロジェクト管理を行うチームがベンダーサイドのPMOです。
システム開発や導入のプロジェクトでIT領域のタスクや課題を管理します。
また、開発やテストなど一部の業務を外部に委託している場合などはパートナー企業の管理も必要です。
プロジェクトにおける役割
システム開発のプロジェクトは通常、要件定義、設計、実装、テスト、運用・保守、などのフェーズに分かれています。
それぞれで特有のタスクや課題が発生します。
そのマネジメントおよび責任者の意思決定補佐が、ベンダーサイドのPMOの主な役割です。
たとえば要件定義フェーズでは、主にクライアント企業の経営層と会社の目的やビジョンを確認し、業務担当者とその実現のための対応手段を検討します。
ITがそのソリューションの一つとして採用された場合、後続のフェーズではシステムエンジニアやプログラマーと協力して、設計やプログラミングなどシステム実装を具体的に進めていくことになります。
このようにITプロジェクトはフェーズによってマネジメント対象が異なる難しい仕事になりますが、ベンダーサイドのPMOはその時々で正確に役割を把握し行動する必要があります。
特にシステム開発管理の役割が求められることが多いです。
必要とされるスキル
PMOであるためマネジメントスキルは言うまでもなく必須です。
それに加え、特にコミュニケーションスキルとIT関連の知識およびスキルが重要になります。
ベンダーサイドのPMOは主にITプロジェクトに配置される組織で、フェーズごとに様々な関係者と協力して仕事を進めることになります。
クライアント企業の業務担当者、自社のシステムエンジニア、業務委託先企業のプログラマーなど、一緒に仕事をする相手は様々です。
それぞれの担当者の業務領域、関心ごと、重視するポイント、などを正確に理解することは円滑なプロジェクト推進に繋がります。
またベンダーサイドのPMOであるため、特にITの知識が必要なプロジェクトが多いです。
特にシステム開発や導入の際に、プログラミング、テスト、不具合対応、などの細かいタスクを管理します。
システム開発や導入における専門用語を難なく理解し、適切なアクションを取れる人材は活躍しやすい職種です。
PMOはアドミニストレータ、エキスパート、マネージャーといった役職に分かれ、それぞれ業務内容が異なることはあります。
しかし、マネジメントスキル、コミュニケーションスキル、ITスキルの3点はどのポジションでもベンダーサイドPMOとして必要なスキルになります。
なぜPMOはベンダーサイドとユーザーサイドに分かれるのか?
ベンダーサイドのPMOはシステムベンダー側のタスクや課題管理が主な役割です。
それに対して、ユーザーサイドのPMOはシステムのユーザー企業側の立場でマネジメントを行います。
ではなぜPMOという組織はベンダーサイドとユーザーサイドで分かれるのでしょうか?
この理由は特に企業のITプロジェクトを例に考えるとわかりやすいでしょう。
企業が業務改善などを目的としてITソリューションを導入する場合、外部のITコンサルティングファームやSIerなどと契約してプロジェクトを進めることが一般的です。
エンタープライズシステムを構築する場合、外部の力を全く借りずに自社だけでプロジェクトを推進できるノウハウやリソースが揃っている企業はほとんどありません。
そのため業務システムの開発・導入などの大規模なプロジェクトでは基本的に発注側と受注側が存在します。
必然的にどちらの立場でもタスクや課題の管理が必要になるため、PMOがそれぞれで存在することになります。
求人サイトで掲載されている案件の特徴
プロジェクトの種類は様々です。ITプロジェクト案件は常に数多く求人サイトに掲載されています。
ベンダーサイドのPMOに求められる役割を担える人材は仕事に困ることはありません。
具体的な例を挙げると以下のようなプロジェクトが多くの業界で企画・運営されています。
- 店舗向けPOSシステムの開発支援
- 新規事業立ち上げに伴うECサイトの構築
- 社内向けの業務Webサービス開発
- カスタマー用のiOS、Androidアプリ開発の支援
- Salesforce、SAPなどエンタープライズシステムの導入
【働き方】ベンダーサイドのPMOの1日の過ごし方
ベンダーサイドのPMOは具体的にどのようなスケジュールで仕事をしているのでしょうか?
結論から言うと、フェーズによって異なります。
システム開発のプロジェクトはいくつかの工程に分かれており、工程ごとに対応する役割や参画メンバーも異なるため、それに合わせてベンダーサイドのPMOの業務内容も異なります。
ここでは業務内容をより具体的に理解できるよう工程別に例を3つ取りあげました。
具体例①実装工程
ベンダーサイドのPMOは特に実装やテスト工程においてプロジェクトの主軸となる役割が求められます。
以下は、実装工程のスケジュール例と主な業務内容になります。
スケジュール例
09:00~10:00 | 朝会(WBSを投影しプログラマーとその日の作業を確認) |
---|---|
10:00~12:00 | 課題・不具合のチェック(課題管理ツール)とその対応 |
12:00~13:00 | お昼休憩 |
13:00~15:00 | テスト工程に向けたプロジェクト管理指針の資料作成 |
15:00~16:00 | プロジェクト管理指針に関する打ち合わせ |
16:00~17:00 | 明日の準備 |
17:00~18:00 | 夕会(その日の進捗をWBSをベースに確認、クライアント側への進捗報告) |
18:00~19:00 | 夕食 |
19:00~22:00 | 残業時間(その日に終わっていないタスクがあれば対応) |
主な仕事内容
システムの実装工程では、プログラミング作業や単体テストの進捗、発生した課題の確認とその対応、次フェーズに向けた準備、などが主なタスクとなります。
本工程では作業が非常に細かいものになるため、作業や課題管理のため専用のツールの導入が一般的です。
よく利用されるツールはJiraなどになります。
Jiraはカスタマイズできる領域が広く各プロジェクトの個別要件に合わせやすいことや、ソースコードの管理ができるGithubと連携できる仕組みが実装されています。
細かい作業分担や不具合を管理する上で非常に便利です。
本工程では、メインとなるシステム実装のタスクと合わせて、後続のテスト工程の準備も実施します。
具体例のに記載のようなテスト工程でのプロジェクト管理ルールの検討会議やその資料作成などの作業が発生します。
各テストの定義、スケジュール、テストで発見された不具合の管理方法などを検討します。
プロジェクトメンバーへ説明できるよう資料作成や説明会の調整も必要です。
本フェーズに限ったことではありませんが、PMOには各フェーズのメイン業務を推進しつつ、後続フェーズを見据えて自発的に行動していくことが求められます。
具体例②導入工程
システム開発・導入関連のプロジェクトは最後にリリースを行い完了となります。
リリース時は想定外の問題が発生することも多いため、プロジェクトを成功させる上で重要かつ難易度の高いフェーズになります。
スケジュール例
22:00~23:00 | メールチェック、リリースの最終準備状況の確認 |
---|---|
23:00~24:00 | リリース開始会議(段取り確認) |
24:00~01:00 | リリース作業 |
01:00~02:00 | 休憩 |
02:00~04:00 | 作業のチェック、および切り戻し判定 |
04:00~06:00 | リリース作業完了後のシステム検証 |
06:00~07:00 | 完了報告など |
主な仕事内容
会社の業務システムリリースは土日や夜間に実施されることが多くなります。
システムリリース中は当然システムが使えません。
平日日中に実施すると業務を止めてしまうことになり、会社にとっては大きな損害になります。
そのため、時間がかかる場合やリスクが高いと判断されたリリースは、業務時間外で調整して行われます。
リリース作業だけでなく業務観点での検証作業なども必要です。
あらかじめリリース時にどんな作業が必要になるのか正確に把握し、必要な担当者のスケジュールを調整しておくこともベンダーサイドPMOの役割となります。
リリース当日はまずリリースの準備が万全となっていることを確認します。準備に不備がある場合は延期を検討しなければなりません。
準備に問題がない場合、次はリリース作業の段取りを確認します。
関係者間で事前に作成済みのリリース手順の読み合わせを行う形が一般的です。その上でリリース作業に入ります。
ヒューマンエラーのリスクを極力下げられるようリリース作業は基本的に自動化しておきます。
チェック作業など人手が必要なもののみを手順書に従って実施していくイメージです。
また、リリース作業の中盤には「切り戻し判定」のタイミングを設けます。
リリース作業は特に想定外の問題が発生しやすく、予定通りリリースができないこともあります。
たとえば、当日までに業務システムに想定以上のデータができてしまい、予定された時間内に旧システムから新システムへのデータ移行が完了できない、というような問題はよく発生します。
このような場合、翌日の業務に影響が出ないようシステムの切り戻しが必要です。
具体例③運用・保守工程
システムのリリース後は運用・保守工程に入ります。
システムは一度リリースすれば終わりではなく、その後も継続して機能改修していくことが一般的です。
スケジュール例
09:00~10:00 | メールチェック |
---|---|
10:00~11:00 | 課題、案件の確認、打合せ資料の作成 |
11:00~12:00 | 業務担当者との次回追加案件の優先順位付けの打ち合わせ |
12:00~13:00 | お昼休憩 |
13:00~14:00 | 次回案件の設計 |
14:00~15:00 | 本番環境での障害調査 |
15:00~16:00 | 開発案件、障害対応、テストなどの作業割り振り |
16:00~17:00 | 明日の準備 |
17:00~18:00 | 内部定例(一日の進捗確認) |
18:00~19:00 | 夕食 |
19:00~22:00 | 残業時間(その日に終わっていないタスクがあれば対応) |
主な仕事内容
運用保守のフェーズでは、細かい案件を扱うことが多いです。
新規システム開発のプロジェクトでは、目的を達成する上で必須となる機能を実装し運用を開始します。
その後、以下のような対応を運用・保守フェーズでシステムを稼働させながら対応することになります。
- 本番環境で発生した不具合の修正
- 優先度が低いと判断した機能の実装
- 稼働後にユーザーから新たに要望を受けた機能の実装
運用フェーズでのPMOの役割は多岐に渡ります。
追加機能の設計、開発、テストに加え、本番機障害調査や対応も随時発生します。
PMOはシステムのユーザーである業務担当者と適宜コミュニケーションを取り仕事を進めます。
特に本番環境での業務を止めないことを重視するプロジェクトが多いです。
タスクに優先順位を付けて効率的に障害対応や追加開発を推進していく役割を担います。
記事まとめ
本記事ではベンダーサイドという種類のPMOについて解説しました。
ベンダーサイドのPMOは受注側であるベンダーのプロジェクトをマネジメントします。
様々な役割を持つ大変なポジションですが、ITプロジェクトは多くの業界で企画されているため需要の高い職種であることは間違いありません。
高年収も期待できるため、興味があればおすすめの職種です。