きっかけ：初めてPMっぽいことをやってみた

以前、PMをやる前の不安を書いた記事の続になります。

実際にやってみて感じたのは、「想定していた前提がかなりズレていた」ということでした。

タスクの進み方、コミュニケーション、工数の考え方など、どれも思っていたより難しく、逆にシンプルな部分もありました。

今回はその中でも特に印象に残った3つについて振り返ります。

想定より早すぎる実装と「やることがなくなるPM」

まず一番驚いたのが、「実装が早すぎる」ということでした。

今の実装者はAIを使って開発を進めているため、こちらが想定していたスピードよりもかなり早くタスクが終わります。

その結果どうなるかというと、「PM側の準備が追いつかない」という状態になります。

・次のタスクの整理が終わっていない
・仕様の細かい詰めができていない
・先方への確認が終わっていない

つまり、「実装が止まる原因がPM側にある」という状況が発生しました。

正直、最初は「早いのは良いこと」と思っていましたが、実際には「早すぎるとボトルネックになる場所が変わる」だけでした。

この時に初めて、「PMは常に一歩先にいないといけない」という意味を実感しました。

次に難しかったのが、「先方から必要な情報をどう引き出すか」です。

特に意識していたのは、「やりとりの回数を減らす」ということでした。

ただ実際には、

・聞きたいことをまとめきれない
・相手の前提を読み違える
・返ってきた回答が想定とズレる

ということが多く、「一発で必要な情報を取る」ことがほぼできませんでした。

ここで感じたのは、「質問は情報を取る行為ではなく、認識を揃える行為」ということです。

単純に聞けばいいわけではなく、

・相手の前提を想定する
・回答の粒度を指定する
・選択肢を提示する

など、「回答の形まで設計する必要がある」と気づきました。

最後に意外だったのが工数の考え方です。

正直、最初は「契約した工数は使い切るもの」だと思っていました。

ただ実際に進めていく中で、「少なく終わることは悪ではない」という感覚になりました。

むしろ、

・無駄な作業をしていない
・効率よく進められている
・見積もりとの差分を説明できる

のであれば、「予定より少ない」は問題にならないことがわかりました。

ここはかなり認識が変わったポイントで、「工数＝消化するもの」という考えは危ないなと思いました。

今回PMをやってみて感じたのは、

「思っているより全部コントロールできない」ということでした。

・実装は想定より早い
・情報は思った通りに取れない
・工数の考え方も違う

その中で必要なのは、「常に前提を疑って調整し続けること」だと思いました。

まだまだうまくできていない部分も多いですが、少なくとも

「PMは指示する人ではなく、流れを設計する人」

という認識には変わりました。

次はもう少し、「詰まる前に動けるPM」になりたいと思います。