おもに情報システム部のPMO(Project Management Officer)担当者向けに、パッケージシステムの導入やスクラッチシステム開発プロジェクトにおけるPMOのタスクについて一覧化しました。
PMOには、事務局などの役割も含めています。
プロジェクトの想定としては、外部パートナー会社にシステム導入・開発を依頼し、情報システム部門にPMO(プロジェクト事務局)を設置するケース。
プロジェクトの全体工程において、PMOが果たす重要な役割とタスクについて本記事を参照してください。また、PMOを設置する際の作業見積もりや人員を検討する際の参考情報として活用頂ければと思います。
はじめにプロジェクトの工程全般におけるPMOの役割をみてみましょう。
- マスタスケジュールの管理
- マスタスケジュールを設定する
- 進捗を管理する
- 納期を調整する
- 詳細スケジュールの管理
- 翌1か月分程度の詳細スケジュールを設定する
- 会議の管理
- 会議日時を調整する
- 会議場所を確保する
- 参加者に開催通知を送る
- 議題を募集する
- 会議資料を作成する
- 司会進行する
- 議事録を作成する
- 議事録を承認する
- 課題の管理
- 課題を起票する
- 課題担当者をアサインする
- 課題の進捗を確認する
- 課題を更新する
- 成果物の管理
- 成果物の納品を確認する
- 成果物の内容確認を依頼する
- 成果物を検収する
プロジェクト全工程を通じて、マスタスケジュール、会議体を含めた詳細スケジュール、課題や成果物を管理することが主要なタスクになります。外部パートナー会社に開発を委託する場合には、社内のスケジュールを主に管理し、会議体や課題は役割分担、成果物は主に外部パートナー会社が担う場合が多いです。
つぎにプロジェクト開始前の準備フェーズにおけるタスクをみてみましょう。
- マスタスケジュールの管理方法を決める
- ツールの選定 プロジェクト管理ツール、Excel ほか
- 更新ルールを決める(新規、変更、進捗登録…)
- 課題の管理方法を決める
- ツールの選定 backlog、Redmine、Jira・・・
- 課題の管理フローを決める(登録からクローズまで)
- コミュニケーション方法を決める
- ツールの選定 Slack、Teams、Chatwork ほか
- チャネルの分け方を決める(全体、チーム別、PMOのみ…)
- コミュニケーションルールを決める(メンション、投稿時間帯…)
- ファイルの管理方法を決める
- クラウドストレージ、社内ファイルサーバー ほか
- 成果物を決める
- フォルダ構成を決める
- バージョン管理方法を決める
- 会議ルールを決める
- 会議種類を決める(ステコミ、PMO、プロジェクト全体、チーム別…)
- 会議頻度、参加者を決める
- 議事録起票者を決める
- 議事録の承認から格納までの管理方法を決める
プロジェクト準備フェーズでは主にプロジェクト管理ルールを作成し、プロジェクトメンバーと合意します。
従来はExcelを多用した管理が多かったですが、今はクラウドサービスを適宜使いながらルールを決めていけるとよいです。社内のセキュリティポリシーやプロジェクトメンバーのリテラシーなどを考慮して、最適なサービスを選定しましょう。
プロジェクトルールは地味ではありますが、プロジェクト期間中に当たり前のように運用される(=ルールであることを意識しなくなる)ことに大きな意味があります。PMOとして重要なタスクであることを認識したいと思います。
つぎは要件定義フェーズ、設計フェーズ、開発フェーズをみてみましょう。
- 開発スコープを管理する
- 開発要件を集約する
- 開発要件に優先順位をつける
- 開発の工数と費用見積もりを評価する
- 開発納期を確定する
- 開発スコープを確定する
- 開発要件の変更管理
- 設計ドキュメント(成果物)を管理する
- 成果物の完成イメージ(記載粒度)をすり合わせる
- 成果物の完成スケジュールを決める
- 成果物のレビュールールを決める
- 成果物のレビュー進捗を管理する
- 次工程への移行判定をおこなう
- 移行基準を決める
- 移行基準の判断材料を集める
- 移行判定会を実施する
- プロジェクト全般のタスクを実行する
プロジェクト全般のタスクに加えて、開発スコープの管理が重要になります。機能実装の可否はもちろんですが、RFP等で定義した課題の解決度合いやプロジェクト目標との整合性を保ちながら開発スコープを管理します。
なお、開発スコープのオーナーシップは情報システム部ではなく現場部門、例えば生産管理部門や営業部門が担うことになります。現場部門の要求と開発予算、納期のバランスをみつつ、確定させていくことが重要であり、利害調整が難しい局面でもあります。
設計フェーズのはじめには、画面やデータベース、インフラの設計書も管理します。画面でいえば例えば検索条件が部分一致か完全一致か記載されているか、など設計書の記載粒度を決めておきましょう。記載粒度がずれていることが後で判明すると、プロジェクトの遅延や関係性悪化などひどいことになる恐れがあります。詳細レベルにまで踏み込んでドキュメントを管理しましょう。
このフェーズで議論されたスコープは後続の受入テストにおいて重要なインプットになります。
それではつぎに受入テストフェーズをみてみましょう。
- 受入テストを実施する
- テスト計画を作成する
- テストケースを作成する
- テストデータを準備する
- テスト進捗状況を管理する
- 障害チケットを管理する
- 本稼働を判定する
受入テストはプロジェクトの大詰めになります。PMOは受入テストの実行者というよりは管理者であり、テスト計画からテスト進捗管理、本番稼働判定までの一連のプロセスがよどみなく進むように現場部門を支援しつつタスクを遂行します。
主たる役割はテスト計画と進捗管理でしょう。テストケースの作成は現場部門が主で、テストデータは外部パートナー会社が主として実行するケースが多いです。PMOは一覧の作業がスケジュールどおり実行されているかを確認しましょう。
テストプロセスとクラウドサービスを組み合わせ、効率よくテストが進められるよう工夫します。
つぎに運用教育フェーズをみてみましょう。
- 教育を管理する
- 教育計画を作成する
- 教育資料を作成する
- 教育を実施する
PMOはシステム導入会社に教育を依頼し、プロジェクトメンバのみならず現場業務に携わり新システムを利用するユーザーを漏れなく招集しましょう。
PMOは教育の対象者や教育内容、方法、場所、日時などを決め、本番稼働がスムーズに進むよう現場部門を支援しつつタスクを遂行します。
つぎは移行フェーズです。
- 移行を管理する
- 移行計画を作成する
- 移行手順書を作成する
- 移行タスクの進捗を管理する
- 移行リハーサルを企画・実施する
- 本番移行を企画・実施する
- 本番稼働判定をおこなう
移行フェーズでは旧システムから新システムへの切り替えをPMOが主導して進めます。外部パートナー会社が素案を作成してくれることもあります。ただし移行フェーズのオーナーシップは情報システム部で持ったほうが良いでしょう。
システムの切り替え、データの切り替え、業務の切り替えなど各種視点を移行計画にまとめます。移行リハーサルは可能な限り本番切り替えに近い状況を再現し、本番でのエラーを事前につぶしておきましょう。
最後に本稼働後フェーズをみてみましょう。
- 運用課題を管理する
- 運用課題を起票する
- 運用課題に優先順位をつける
- 追加開発を企画・実行する
本稼働後にユーザーからあげられた課題を集約し、二次開発、三次開発の計画をたてましょう。使ってみてはじめて明らかになる課題はかなりの確率で発生します。そこで次期開発の計画が必要になります。
以上がシステム導入・開発におけるPMOの役割およびタスクの一覧です。