【未経験PM必見】リアルなプロジェクトマネージャー業務と“泥臭”現場術

TL;DR(この記事でわかること)

• PM の本質は“曖昧を具体に変換し続けること”
• 手順化済みタスクを抱えた瞬間に残業が確定するワケ
• “いつ・何を・どうやるか” を自分で決められないとプロジェクトは即炎上
• 明日から使えるリスク処理バッファ／朝会ファシリのコツ

対象読者

• IT業界未経験でPM、PMOへのジョブチェンジを検討している方
• IT 3年目未満でマネジメント経験がない方
• 情シス経験のみで請負・SES業界に興味のある方

前提

• 座組み は下図を想定（4 名のエンジニア + PM）
  

• 請負元との定例 MTG は 毎週 1 時間

• アジャイル／ウォーターフォール混在 & 要件定義不足のため 想定外イベント多発

— 成果責任は全部 PM に乗っかる ー

こちらの記事でも解説しましたが、PMは成果を求められる職務です。

よって、「いつ、何を、どうやるか」 は自身で考えて自身で決めます。
PMは受動的では絶対に務まりません。

能動的に以下のことを考えれば、
プロジェクトを成功させるために必要なタスクは常に大量に発生します。

• 具体的に受けた指示が本当に正しいのか考えること
• 夢見たいな要望を具体的なタスクに落とし込むこと
• 検知した問題を具体的なタスクに落とし込むこと

経験が浅い方であれば常にアップアップしてるくらいでないと高確率で炎上します。

🔳 「IT業界あるある」
何も言われないから、何をやっていいかわからずに具体的に言われたことだけやって炎上していくマネージャーが一定数います。

1 日のタイムスケジュール例

ー 突発タスクに備えよう ー
フリータイムは “リスク処理バッファ”の時間です。
突発タスクに即応できるよう、固定枠を極力減らしています。

🔳 日時定期

時間帯	内容
9:00 - 9:30	朝会準備 — Backlog 確認 & アジェンダ作成
9:30 - 10:00	朝会(エンジニア4名と) — 10 分雑談 & 進捗確認
10:00 - 12:00	フリータイム
12:00 - 13:00	昼休み
13:00 - 18:00	フリータイム

🔳 週次定期

曜日	時間帯	内容
月曜日	-	-
火曜日	-	-
水曜日	15:00 - 16:00	請負元との定期MTG
木曜日	-	-
金曜日	-	-

時間ごとの具体的な過ごし方

朝会準備(9:00 - 9:30)

「朝会で確認すること、周知すること」を明確にする時間です。

具体的には、backlog のようなPJ管理ツールを眺めながら、計画通りタスクが進捗しているか、不穏なコメントはないか等をザッと見て違和感を感じた箇所を言語化し「誰に何を確認するか」を整理します。

また、全体に共有した方が良い情報を、どのように伝えたら良いかエンジニア向けに言語化する時間にも使います。

例えば、このようなアジェンダができます。

# 全体周知
- ソース中のコメントアウトについて
改修前の実装をコメントアウトした状態のPRが散見されます。
あとで見返したときに読みにくくなるだけなので消した状態でPRしてください。
また、消しても大丈夫と自信を持てるくらいの単体テストは必ず実施してください。

# 進捗確認
- Aさん
  順調
- Bさん
　昨日相談もらった通り、設計時の考慮漏れで2日遅延するのはOKです。
  他にも影響ないか整理したいので詳細を13:00から会話させてください
- Cさん
  昨日完了予定のタスクが終わってない?
- Dさん
  1日前倒しで進んでるようなのでBさん予定だったタスクもらって欲しい

朝会(9:30-10:00)

ー 朝会は大切 ー
私個人のベストエフォートは毎朝始業近くに朝会を実施することです。
自分を含むメンバー全員が朝から気が引き締まるので、作業効率を高く維持するための一番の工夫になります。

私の場合は、
遊び心なきところに良いものは作れないという信念があるので、
最初の10分くらいは雑談に使います。

具体的には、当番を決めて5分間でなんでも良いので自分の好きな話してもらって、残りの5分で雑談します。

その後、残りの20分で先ほどのアジェンダをベースに朝会を進めていきます。

全体共有事項は良いのですが、進捗確認を上手にファシリテートしないと時間がいくらあっても足りなくなります。

そのため、事前に調べればわかる範囲の最新進捗情報を確認しておき、認識ズレがないかを確認する場に止めます。

もし、詳細を知りたかったり悩んでいる様子であったりする場合は、朝会以外の時間で必要最低限の人数(大抵1on1)でのMTGを企図します。

ー よくあるダメなMTG ー
ファシリテートが機能していないと進捗確認が目的であるMTGのはずが、進捗確認・課題整理・課題解決立案をフルセットで検討する場に化けます。

4人の進捗確認するだけであれば15分で十分ですが、フルセットだと1時間あっても足りなくなります(人が増えると話が発散しやすくなって指数関数的に時間が増したりもします)

ー でも、皆んなで考えるべきケースもある ー
皆んなで考えるべきクリティカルな問題や、多数で話した方が問題解決効率が上がるケースあります。
進捗確認以上の話になったから一様に方向修正するのも違うなというのが個人的な見解です。
そのため、この話題は皆んなで話した方が良い話題なのかを考えて、違うなと判断した場合に方向修正をするように私は心掛けております。

フリータイム(10:00 - 18:00)

前提に書きましたが、このPJは不測の事態が多いと予見されるので固定時間は極力少なくしてます。
つまり、自身が担当すべき作業を実施する時間ではなく、PJ内の曖昧な部分を具象化して定義し続けるための時間になります。

具体的に、どんな内容をやるかを解説していきます。

ー 手順が決まっている作業を担当しないこと ー
手順が決まっている作業はPMが担当すべきではないです。(そんな役割ではない)
ですので手順の承認は自身の役割ですが、手順設計や検討・実施運用は配下のメンバーに振れるべきです。
私の経験上、これを持った瞬間に、その時間分は残業時間で消化することになりました。。。

ー でも、現実的に自分がやらないといけないときも沢山ある ー
実際問題、手順設計できるレベルのエンジニアが配下にいないとか、エースエンジニアはクリティカルタスクに専念させたいから、そんなタスク振る余力がどこにもないとかは良くある話です。
社内に相談したからといって、それすぐにやらなくてもいいから置いとけば？とかで濁されるのも良くある話で、放置するとお客さんに怒られるのも良くある話です。
私は、この矛盾を解決するために、グッと堪えて自身が作業することでバランスをとるタイプでしたが、何を選択するかはPMによって千差万別です。

朝会で検知したリスク要因の回収

朝会のアジェンダに記載しましたが、リスクがありそうな箇所を検知したらMTGを企図して状況をヒアリングしたり、タスクの入れ替え等で認識齟齬が出そうな箇所を伝える時間です。

一例として、アジェンダに従って朝会で会話したら、やはりBさん、Cさん、Dさんと具体的に会話が必要と判断したとします。

• Bさん(設計考慮もれの詳細を把握)

設計時点の考慮もれを概要レベルで報告してもらいましたが中身の理解が追いついていないので詳細を教えてもらう目的でMTGを企図しました。
なぜ理解が必要かというと、Bさんが気づいてくれた原因を水平展開してシステム全体視野で俯瞰した時に他にも同様の事象が眠っていそうな箇所がないかを検討するために必要だったり、お客さんに報告した時に詳細質問されたら答えられるように把握する必要があったりします。
よって、Bさんの知識を借りて詳細を理解できるまで会話して、もし時間が余ったら2人でシステム全体を俯瞰して他に眠ってないか検討します。

• Cさん(タスクの期限守れずに未報告で帰宅していた)

Cさんに伝わる言葉で未報告のまま期限超過が続くと皆んな不幸になるよねと叱る時間です。
併せて、本人は遅れている分をどうやってリカバリーするつもりなのか見解を確認します。

ー 当事者の言い分を鵜呑みにしないこと ー
未報告で遅れている時点で適切な判断ができない人です。
そのような人が、残業して取り戻します、とか土日でますとかが本人のリカバリープランであることが多いです。

しかし、一定のライン超えると生産性落ちるのは目に見えているので間に受けてはいけません。

なぜ、今のタスクが遅延しているのかをヒアリングして原因を判断してあげて、こちらから次のタスク以降は同じ事象が発生しないようにサポートしてあげる案が建設的です。

ー 原因を考えると良いことが沢山ある ー
例えば、設計書に書いている仕様を見落としていたので1日遅延してしまったのが原因とします。
その再発防止策は、設計書を正しく理解してから正しい順序で作業することで防止可能です。
擬態的には、まず設計書を確認しつつ、何をどの順でやるのかメモ書きレベルでいいので書いてから作業するように徹底させます。メモ書きが完了したら、作業は進めて良いので、私にメモ書きを共有するようにします。(隙間時間でレビューします)
もし、違和感がある箇所があれば、再度会話して認識を合わせます。

ー 人の成長を待つことが、そのPJ中ではマイナスになることが多い ー
本人にできる限り原因と対策を考えさせた方が人間的成長は見込めるというのは事実です。
しかし、プロジェクトは期間が有限である特性上、人の成長をゆっくり待っても、今のプロジェクトにはマイナスになるケースが多いです。
よって、私は3分考えさせて答えを言ってしまします。

• Dさん(Aさんのタスクを拾ってもらう)

タスクの入れ替えはリスクが伴うので、事前に把握しておいた方がいい情報を共有しておきます。
この場合、Aさんも同席させた方がいいので、私が概要を説明して、Aさんがどういう方針で考えていたかをDさんに共有します。
それが済んだら、Dさんから質問をもらって認識を合わせていきます。

ー この引き継ぎチャットでよくない?? ー
この引き継ぎをチャットで済ますと、気軽に質問できない空気が生まれやすいと私は考えております。
逆に10分でも良いので、この時間を取ることで質問しやすくなると考えております。

曖昧なタスクの具体化

来週から実施予定のタスクがタイトルしか設定してない状態であることがよくあります。
読んで何をやるかわかるように設計書のどこを参照して、何を実現したいのかを記載します。

追加要件の整理

お客さんから追加で要望を頂いた場合、まず以下を検討して見積もりをお客さんに共有する必要があります。

• どのくらい時間がかかるのか
• 具体的に何をする必要があるのか

自身で答えを出し切るのか、誰かに検討してもらうのかは判断次第ですが、どのような道筋で進めて、いつ報告するのかという計画を立案します。

週次MTGの準備

主にお客さん向けのMTGになりますが、お客さんが理解できるように噛み砕いた報告資料を作成する必要があるので資料を作成します。
この時間で、お客さんが気にされることや受け答えのシミュレーション等もしつつ資料に整理していきます。

ー 事前準備は非常に大切 ー
週次MTGの準備を丁寧に実施すると4時間くらいかかってしまいますが、
私は不測の事態で瞬時に判断するのが苦手なので可能な限り予見して週次MTGに臨むようにしておりました。
その結果、「あー、それ考えたんですけど ~なのでPJ的に推奨されませんけど、やりますか???」的な返答をすることが多くなり、よく考えているなとお客さんに信頼いただけた要因でもあります。

まとめ

• PM の主戦場はコードではなく コミュニケーションと構造化
• “手順済みタスクを手に取った瞬間に残業” を合言葉に、曖昧 → 具体 の作業に集中する
• 口が渇くまで話して、糖分が切れるほど考え抜く――それがプロジェクトを炎上させない最短ルート

終わりに

未経験から約2年の地獄のようなPM経験を記事にすることで、私自身の供養をしております。
続編に興味を持って頂けた方は こちらのxアカウント をフォロー頂けると幸いです。

なお、"いいね" により私の供養が進みます。