こんにちは。エンジニアの鈴木（@yamotuki）です。
今回は、弊社の内部資料として使っている「プロジェクトマネージャーの型」を紹介します。

この資料は、今までの1~3ヶ月程度のプロジェクトを進める過程で得た知見を、個人の暗黙知ではなくチームとしてPMの役割を担える人を増やそうという目的で作りました。
PMができる状態のエンジニアであればメンバーとしても効率よく仕事を回せるのではないかという仮説のもと、PMの役割をやってもらう人以外にも展開しています。

以下はほぼ原文ままです。

これは何

プロジェクトマネージャ（PM）・リーダ業務の型をできるだけ明文化して、新しいPMやリーダ業務の助けになることを期待した資料。

PMがやること

目的を把握する

プロジェクトの目的を把握する
目的に対してやりたいことが一致しているか確認し、一致していなかったらPdMやデザイナとすり合わせる

プロジェクトを小さくする

多くの目的を一度に達成する巨大プロジェクトになるのを防ぐ。プロジェクトが大きくなると、以下の問題が発生する

不確実性コーンは指数的に大きくなり、リリース日が読めなくなる
長いプロジェクトになると開発者の脳内から初期の情報が揮発し、コードを読み直したり、リリースの手順を整えるのに苦労したりして生産性が低下する

検証したい目的に対して可能な限りリーンなプロジェクトとして小さくできないか検討する。目安としては1~2スプリント以内（※弊社の場合は1スプリント2週間）に収めたい。

ref: 不安とストレスから解放される見積りとスケジュール方法 - Qiita

成果物をイメージする

PdMとデザイナが作ってくれたデザイン（またはそのカンプ）と暫定仕様書を元に、成果物のイメージをする
上記の目的と、仕様・デザインが一致しているか確認し、問題提起する
やりたいことが技術的に無理があるところがないか、目的に対して不当に工数がかかることがないか確認する
デザインに無いけど既存で存在する or 重要なパーツが書かれていないみたいなことはあるので、あるべき情報は何か？をベースに考えるのが良い

成果物のイメージをするためのステップ

デザインや仕様書（項目整理やER図など含む）を見て、脳内で動かしてみる
- これは慣れが必要なようだ。普段の業務から以下のステップで意識することでスキルとして鍛えられるかもしれない
  1. 小さなタスクで自分で模索しながら動くコードを書けるようにする
  2. 大きなタスクを分割してもらったり、指導をもらいながら完走できる
  3. 大きなタスクも自分でタスクをやる前に分割したり、全体設計をしたり、実装イメージをつけることができる
  4. コードと動作の関係を掴む
    1. PR や dev 環境などで、動作からコードがどう動いているかイメージする。「こういう動きをするなら、こういうケースだとバグりそうだな」が指摘できる
    2. コードから動作をイメージする。PRで、「このコードだとこんな変な動きになりません？」の指摘ができる
  5. デザインや仕様書とコードの関係を掴む
    1. まだ動作がない環境でも PR や dev 環境と同様にイメージする
      1. 「このデザインだとこの情報が足りない」
      2. 「この動きをするには情報がこのレイヤまで来ていないといけない」
      3. 「現在のコード設計だと実現が困難」「このような設計にすると楽に実現できる」

タスクを洗う

上記の "デザインや仕様書とコードの関係を掴む" で掴んだ既存のコードとイメージしたコードのずれを探してリスト化する
- 既存のコードにないものは全てタスクになる
- 既存の設計で実現困難なものもリファクタのタスクになる

タスクを分解する

最初の分解

洗ってリスト化したタスクを、可能な限り分担可能な形かつ小さなバッチに分解する
プロジェクトスケジュールを考えて、何人体制で対応しなければいけないか検討し、それに合わせて並列作業できるようにする
- ある程度小さなバッチに分解した後に、クリティカルパスを特定する
- クリティカルパスが大きすぎる場合には、そこをさらに分解してクリティカルじゃなくするためにはどうしたらいいか考える
- 分解できない or スケジュールがきつい場合には、どうしたらクリティカルパスが最速で終わるか考える & チームを巻き込む

情報が増えたら再分解する

デザインがより詳細に固まったり、作業が途中まで進むとタスクに対しての詳細度が上がる。その情報をもとに大きなタスクを細かく分解したり、足りないタスクを作成する。

順序を決める

優先度で組み替える

（間接的にでも）ユーザに価値を届けられる機能が優先。やってもユーザに価値が増えない機能は後回し。

不確実性の高いものから終わらせる

プロジェクト後半に不確実性の高いタスクが存在すると、いつ終わるか判断できず社内外のユーザに迷惑をかけてしまう。できるだけ不確実性が高いタスクは早めに終わらせる。例えば以下のようなもの。

使ったことのないミドルウェアの使用
うまくいくかわからないアルゴリズムの使用
外部との連携
詳細仕様が未決定

ref: 不安とストレスから解放される見積りとスケジュール方法 - Qiita（再掲）

機能ごと完成させる

原則として、1つの機能がユーザに届けられる状態まで一気にやった方が良い
- 例えばプロジェクト全部のAPI -> プロジェクト全部のマークアップ -> プロジェクト全部の組み込みとやるより、一つの機能のAPI -> 一つの機能のマークアップ -> 一つの機能の組み込みをして都度完成させていく方が良い
- 完成系に対してより早いフィードバックを得られ、その知見を次の機能を作るのに活かせるため

テストデータを整備する

local でテストデータが偏っていると確認が甘くなり、プロジェクト後半で問題が起こりやすくなる。 local の seeder に起こり得るパターンをあらかじめ作っておく、もしくはそれを作るタスクを作る。

割り振る

可能であればメンバーの得意不得意・やりたいことを考えて割り振る
途中で一人程度抜けてもプロジェクトが長く停滞しないように、情報を誰がどれくらい持っているべきか考えて進める

リリースまでにやらなくていいものを特定する

リリース後のインクリメンタルな改善で良いもの
ユーザ影響のないもの
コアの価値を提供するのに支障がないもの
- できれば、コアの機能を提供するために「あれもこれも」とならないように仕様作成の段階から分離可能にするのをサポートするのが望ましい（理想）

ボールが落ちていないかチェックする

落ちそうなボールは、積極的に拾う
- 落ちていて後から出現したボールで問題になりそうなものは、軽微なものは自分で巻き取ってさっさと終わらせる or 大きそうなものであればメンバを巻き込んで分担を改めて考える
- 後で忘れずに拾えるところに明記する
メンバーが落ちていたボールに気が付いてくれたり、拾ってくれたら感謝し、そういった行動を推奨する。PMにとって落ちていたボールはプロジェクト終盤の痛手になるため、拾ってくれる人は多ければ多いほど良い。

小さいイテレーションでやること

小さい目標を作る

目標は分かりやすければ分かりやすい方が良い。

特定の見える成果物を作る
何ポイント消化するか決める

その目標を達成するためにそれぞれのメンバーが何を頑張ればいいかブレークダウンして、担当を割り振る。いつ、どれくらい頑張れば達成できるのか可能な限り明確化する。

成果物確認会を開催する

PdM, デザイナ, エンジニアと必要に応じてさらに上長を呼んで成果物の確認会を開催する。
開催タイミングは、機能が大体できたという状態で開催する。完全に完成してから開催するのではなく、ある程度機能ができた段階などにも開催し、プロジェクトの大きさに合わせて複数回開催しても良い。
議事録テンプレートには以下の要素を含める。