こんにちは、Enterprise Cloud部 ソリューションアーキテクト1課 の 宮形 です。
私の在籍する部では「エンタープライズ」と名がある通り、主に大型の民間企業や公的組織向けの顧客を対応します。私は、その中でも大型・長期の クラウドインテグレーションプロジェクトのプロジェクトマネージャー(PM)を担当させて頂く機会が多いです。
おかげさまで大型・長期のプロジェクトをご用命いただくことも増えてきまして、新任のPMメンバーから「普段プロジェクトで何やってるの?」「PMのやり方教えて」と相談いただくことがあります。
本BLOGでは、その時に皆様にお話ししている、私が普段プロジェクトのPM業務でやっていることのご紹介をさせていただきます。
プロジェクトの体制・性質によってはPMは上席責任者という立ち位置になっていて、実質的にプロジェクト管理業務をプロジェクトリーダー(PL)が担うケースもあると思いますので、その場合はPL業務と読み替えてください。
ここで書く普段やっていることの範囲
大型・長期プロジェクトのクラウドインテグレーションの場合、複数ベンダーやステークホルダーが参画することもあり、今のところウォーターフォール型で進行するプロジェクトが多いです。
その為フェーズも下記のように順に進行します。本BLOGでは全てフェーズで共通で行っていることを中心に記載したいと思います。各フェーズ固有で行っている事がありますが、そこまで書くと文章が膨大になりますので今回は除外します。
- 要件定義
- 基本設計
- 詳細設計
- 運用設計
- 構築・リリース
- テスト
- 本番稼働・本番切替
これらフェーズのより前には「商談フェーズ(RFI、RFP対応)」、「PoC」等があり、後には「運用」があり参画する場合もありますが、仕事のサイクルが大きく異なりますので私の言うPM業務からは除外とします。
PMとしての1週間サイクルでみた各日にやること
イメージしやすいよう、とあるプロジェクトの例として1週間の活動サイクルで各日に何の活動をしているをご紹介します。
曜日 | 活動 |
---|---|
月曜日 | ・プロジェクト管理資料のメンテナンス |
火曜日 | ・顧客打ち合わせ(全体進捗・課題報告、技術討論) |
水曜日 | ・次週の顧客打合せのアジェンダ作成 ・よろず相談会 |
木曜日 | ・議事録の作成とレビュー |
金曜日 | ・社内定例会議(進捗・タスク・課題管理) ・技術討論資料のレビューとリリース |
なお、サーバーワークスではこれらの活動はすべてオンラインツールを活用した非対面でのフルリモートで完結できるようになっています。
【月曜日】プロジェクト管理資料のメンテナンス
このプロジェクト例では火曜日に顧客との打合せで全体進捗・課題の報告がありますので、その前日の月曜日にプロジェクト管理資料のメンテナンスを行います。前週の金曜日に社内定例会議でメンバーからそれぞれ進捗・タスク・課題の状況を聞いていますので、その内容を取りまとめることになります。
WBSの更新
WBSには各タスクと開始日・終了日・進捗%が一覧で記載されていますので、その時の最新状況を記載します。またタスクの増減や担当者変更があった場合なども一覧を修正します。
QA管理表・課題管理表・不具合管理表などの更新
プロジェクト毎に利用する管理表はそれぞれですが、QA管理表・課題管理表・不具合管理表を利用することが多いです。それが1つになっている場合もあります。各QA課題不具合の状態(対応中、回答済、完了)を最新状況に更新します。私の場合は、この手の管理表はメンバーに直接記載してもらうようしていますので、更新が滞っている、停滞している、ちょっと危なそう、になってる情報をみつけて各メンバーにリマインドしたりフォローしたりします。
プロジェクト報告サマリの作成
WBSとQA管理表・課題管理表・不具合管理表を最新状況に更新しましたので、そのサマリを1枚ものにした資料を作成し、顧客へ提出します。プロジェクトによって報告サマリ不要の場合もありますが、大型・長期プロジェクトの場合は求められることが多いです。
【火曜日】顧客打ち合わせ(全体進捗・課題管理、技術討論)
火曜日は顧客打合せがあり、この例では前半は「全体進捗・課題管理」後半は「技術討論」の2部構成となります。プロジェクトによっては別日で開催の場合もありますが、この2部構成というパターンが多いです。
全体進捗・課題管理
顧客や各ベンダーのコアメンバーが参加します。サーバーワークス側はPM、PLが必ず参加します。月曜日に作成提出した「プロジェクト報告サマリ」をもとに5-10分程度で当社の進捗とインパクトの大きいQAや課題の状況を報告します。
技術的なトピックとして全体広報した方がよい事項があれば時間を頂いて説明します。その説明要員としてプロジェクトメンバーにも参加してもらう場合もあります。
技術討論
サーバーワークスの担当する領域のディスカッションに行うための会議体となります。サーバーワークス側はPM、PL、説明パートのあるメンバーが参加します。前週に提出した「次週の顧客打合せのアジェンダ」で議題を告知していますので、その内容にそって進みます。
内容はプロジェクトやフェーズによって様々ですが、ヒアリング事項の説明、「設計書」「構成図」「パラメーターシート」のレビューや直近で予定する構築作業の説明を行うことが多いです。私の場合はPMとしては会議のファシリに徹して、技術討論はメンバーにバトンタッチして直接説明してもらっていますが、顧客の特性や内容・メンバー力量に応じて適宜フォローします。
クロージングでは、次週開催予定の技術討論会での議題を告知します。内容に応じて顧客や各ベンダーの誰に参加して欲しいのかを伝える参集打診も行います。
打ち合わせ終了後に時間がある場合は、メンバーで残ってアフター会議をします。PMとして次のタスクや、会議の宿題整理、各メンバーへの割り当て、目安期限を認識合わせします。
【水曜日】よろず相談会
これはプロジェクトの内容やメンバーの力量に応じて開催になりますが、社内で「よろず相談会」を毎週設定している場合があります。 サーバーワークスはリモートワークでの Slack でのテキストコミュニケーションが中心になりますので、相談や質問はチャットで行います。しかし、サーバーワークスにジョインして間もない、経験が浅いメンバーは質問の言語化に苦労し時間がかかりますので、リアルタイムの会話で相談した方よいケースも多いです。この時間枠で Meet や Slack huddle 等のツールで集まって雑談っぽくメンバーからの質問や相談に気軽に答えるようします。
PMとしてもメンバーが理解や腹落ちが不十分でタスクを遂行してしまうことは手戻りや品質低下リスクにつながりますので、この会の開催はとても重要だと感じています。
【水曜日~木曜日】次週の顧客打合せのアジェンダ作成
次週の技術討論の打合せアジェンダを作成します。私の場合は、前の会議が火曜日でしたら水曜日~木曜日と早めに作成して、顧客やメンバーへ周知するようしています。顧客とのディスカッションの記憶が残っているうちに。。。というのもありますが、アジェンダはイコール(=)次のメンバーの到達点の指標になりますので、PM自身としての認識整理と、メンバーが目標設定しやすくなる狙いもあります。
【木曜日】議事録の作成とレビュー
顧客打ち合わせの議事録を作成とリリースは、私の場合打合せの2営業日までに実施するようにしています。このプロジェクト例だと顧客打ち合わせは火曜日なので木曜日を議事録の提出期限とします。
議事録の作成はPM本人が行う時もありますが、できるだけメンバーに行ってもらい、私はレビューに徹するようしています。「議事録の作成に時間をかけることは無駄」という考え方も最近はありAIや文字おこしを活用する方も増えてきました。これは私も否定はしませんが、議事録を作成することはプロジェクト全貌を把握して、要点・結論のみをまとめる訓練になりますので、次期PM、PL候補となりうるメンバーにお願いするようしています。
議事録のレビュー観点は人やプロジェクト特性に応じてだと思うので、ここでは割愛します。
【金曜日】社内定例会議(進捗・タスク・課題管理)
このプロジェクトの例では社内定例会議を毎週金曜日に開催しています。ここでは主に下記のような話題を話し合います。
- PMから全体への共有事項(例:プロジェクトの運用ルールやツールの変更、原価状況、上司や営業から連携された事項)
- 各メンバーから各タスクの進捗報告
- PMからQAや課題の対応状況確認
翌週の月曜日にプロジェクト管理資料のメンテナンスを行いますので、PMはその元となる各メンバーの進捗把握や遅延、重大課題のアクションプラン等設定の把握が重要となります。
また、顧客打ち合わせに参加して欲しいメンバーの選定もこの時に行うようにしています。私の場合ですが、説明要員のメンバーには会議参加してもらいたいですが、逆に説明が無いメンバーは欠席でよいとしています。メンバーご自身が担当する領域は本人から顧客説明してもらった方が内容精度も高いですし、ご本人のオーナーシップも高まると思います。対して議題に説明や担当パートが無い場合は、会議参加する時間がもったいないですし、最近ではWeb会議録画の倍速再生や文字おこし、議事録といった優れた非同期の確認方法がありますので、それらを活用すればよいと思います。
【金曜日】技術討論資料の社内レビューと顧客リリース
「技術討論資料」が何かというと、いわゆる「設計書」「構成図」「パラメーターシート」等のプロジェクトフェーズ毎の成果物になります。 このプロジェクト例では毎週火曜日の顧客打合せ・技術討論の場で各メンバーがそれら資料を説明することが多いので、金曜日を社内レビューと顧客リリースの期限としています。
打ち合わせの場で初めてお披露目するよりは、事前に目を通してもらった方が理解が深まりますし、質疑応答も有益になります。なので会議の2営業日前までに各メンバーからはアウトプットを出してもらうようにお願いしています。
またPMとして事前レビューをするなかで、顧客から質問や加筆修正依頼が来そうなポイントを気付けた場合は、メンバーへ先回りしてインプットしておくようにしています。
まとめ
普段はAWSを中心とした技術的な内容をBLOGに書いていますが、今回は趣向を変えた内容としました。ご参考になりましたでしょうか。
当社へジョインしてくれた新卒採用、中途採用の皆さんと会話すると「普段の仕事をイメージするために入社前にサーバーワークスエンジニアブログを読んでいた」という方が沢山おられましたので、日々やっていることを書くだけでも参考になるのかなという思いで執筆しました。
PMのお仕事は「何が正解」が無い領域だと思います。過去IT業界で先輩方が考え出した王道パターンを踏襲しつつも、最新のITツールを活用した効率的でかつ顧客・メンバー皆のメリットが大きく、サーバーワークスのカルチャーや行動指針にそったやり方を常に追求したいと常日頃思うのでした。
www.serverworks.co.jp www.serverworks.co.jp
本記事が少しでも皆様のお役に立てれば幸いです。