PMやPLとして大切だと考えていること

本記事は  【PM/ディレクターウィーク】  1日目の記事です。
🍦  告知記事  â–¶â–¶ æœ¬è¨˜äº‹ â–¶â–¶  2日目  ðŸ’»

自己紹介

こんにちは。金融ITソリューション事業部の佐藤です。
私はこれまでシステムエンジニアとして小売業のECサイト、証券会社のオンライントレードサイトなどの構築、運営に携わり、数人月(MM)～数十MM程度の小～中規模な案件のプロジェクトマネージャー(PM)や数百MMにもなる大規模プロジェクトのプロジェクトリーダー(PL)やアプリメンバーとして業務をしてきました。
自分で手が動く方ではなく技術的なことは疎いためこのBlogとは縁遠いと思っていましたが、今回「プロジェクトを推進する上で大事だと考えていること」というお題目で声をかけていただきました。
それならできるかも・・ということで書かせていただくことにしました。
PMやPLとして過去に経験してきた業務の中で大事だと考えていることについて述べたいと思います。

マネジメント業務の目的

ひとことでいうと
「プロジェクトの目的を達成すること。」
ですが、PMやPLの仕事は下記のようなものがあります。

・プロジェクト計画の立案
・その他各工程の計画書作成(テスト計画、リリース計画)、報告書作成
・社内上層部や顧客に対してのプロジェクト状況報告
・スケジュール管理、課題管理、要員管理、コスト管理

「設計書を作る」とか「コードを描く」とか「テストを実施する」みたいなものはないです。
直接的な仕事をしないけど、プロジェクトをまとめて推進するためには必要な役割です。
上記のようなマネジメント業務をする上で大切だと考えていることを3点お話しします。

管理系タスクは仕組み化する

状況報告はマネジメントする立場の重要な仕事です。規模が大きいプロジェクトになるほどPMは各所への報告書作りで忙殺されます。
進捗状況は細部まですべてを自分で把握することができないため、担当者の報告を信じます。
「大丈夫？」→　「大丈夫です！」ではどう大丈夫なのかわからないため、進捗管理資料や課題管理資料などはフォーマットや記載ルールを定義する必要があります。
担当者が決められたルール通りに管理資料を更新してくれたら、プロジェクトの状況が把握できる状態にします。それをプロジェクト完了まで維持しなければなりません。
プロジェクトメンバーにとって進捗管理資料や課題管理資料の更新はOUTPUTに直接関係しない作業なので優先度は低くなりがちです。更新してくれません。
こちらは「更新してください」とお願いするしかないのですが、受け入れてもらうために作業の自動化、簡素化など、できることはプロジェクト途中で改善を実施することもあります。
（うまくいっていないプロジェクトの応援で途中から参画すると、だいたいWBSの更新がとまっていたり、課題管理票に数週間前の課題が放置されていたりします。）

課題の交通整理をする

プロジェクトを進めるうえで様々な課題は発生します。
お客様から追加要望があった場合や設計において仕様を決めるときに顧客確認事項が発生した場合は、介入して交通整理したほうが良いと思います。
顧客担当者や外部に関連システムがある場合はその外部システム担当者に対するメイン窓口は自分の役割です。
やり取りする対象とプロジェクトメンバーとの間で円滑に課題解消するために動きます。
結論次第で機能要件に変更が入ったり追加の要件をねじ込まれたりすることがあるため、慎重に対応したほうが良いと思います。
また、プロジェクトメンバーの回答内容が顧客に理解できない場合があるため、顧客にも理解できる文章に翻訳してあげたりすることもありました。
複数のサブシステムが関係するプロジェクトの場合に発生するサブシステム間の課題は双方の主張が相反することもあるため、その場合はプロジェクト全体の視点から着地点を提案することも必要です。

価値観を共有する

複数のメンバーとともに一つの目標に向かって活動していくため、いろいろな価値観をできるだけ共有したほうが良いと思います。

・「やること」と「やらないこと」の共有
・「目標とすることは何か」の共有 ・前述した「仕組み化」の内容共有
・「OUTPUTイメージ」の共有
・「レビュー観点」の共有

など、他にもたくさんありそうですがどこまでメンバー内で共有できるかが重要です。
ではどのように共有すればよいでしょうか。
プロジェクト計画書、テスト計画書、リリース計画書　など各工程の事前に計画を定義するものは複数あります。
各工程の計画書にどこまで具体的に共有したいことを記載できるか。それをどこまで熱量込めて伝えられるか。だと思います。

直近のプロジェクトでは振り返り時に

「レビュー計画も実施すればよかった。担当システムの成果物のレビューに対して インプット、プロセス、レビュー観点を定義するレビュー計画を各システム担当者に実施してもらい、 それをPM側でレビューすれば、品質分析がしやすくなる」

という提案が該当プロジェクトのPMからありました。※私はPLとして参画
次回のプロジェクトでは実施してみようと思います。

おわりに

以上PMやPLとして大切だと考えていること3点を挙げました。
同じような業務をしている人にとっては当たり前のことを言っているだけになってしまいました。
ですがこれまでの経験上、現時点で私としてはここに書いていたことが重要だと考えています。
まだまだ自分も徹底できておらず道半ばのため、これからもどのようにすれば良いか考えUpdateしていくつもりです。

本音を言うとPMやPLとしていちばん大切だと考えていることは
キックオフと打上げの飲み会は必ずやる！
と言いたいところです（笑）。
コロナ禍以降は難しかったですがもうそろそろ解禁でもよいですね。

最後まで読んでいただきありがとうございました。

執筆者 : 佐藤 健　システムエンジニア