はじめてのPM

IT経験2年半ほどにて初めてPMをやってみて、自分としての反省をまとめてみました。
なるべく抽象というよりは具体的なアクションとしての反省としています。

前提

• AWS上でLambda, SQSを用いたサーバレスアプリケーションへの移行
• 5名、4,5ヶ月ほどのウォーターフォール小規模プロジェクト
• 見積もりから参画し、顧客折衝、要件定義とか一通りやった

良かったポイント

手戻り上等で強引に進めたこと

ウォータフォールの開発だったが、設計が終わる前にゴリゴリ作ってみたりしていたのは結果とても良かった。

開発を進めてくれてるメンバーには、手戻りが発生したりすることにはなってしまい申し訳なさはあったが、結果としてはPJはより品質もスピードも高まった感があるのでPMとして割り切る部分な気がする。

「手戻り」+「設計」の時間は、「設計まち」+「構築」の時間より、絶対短かったし、結局「設計待ち」＋「構築」でもどうせ手戻り生じる気がするから、それならそもそも一定の手戻りは織り込み済みの上でゴリゴリ進めていくべき。

結局、手戻りは不確実性に対して分岐をミスった時に起こるわけだが、手戻りを恐れて進めない時間よりどっちもやっちゃう時間が早いならそれはプロジェクトとして正解、進めないとわからんとこも多いわけで。

ここは大きいプロジェクトだと無視しきれない手戻りもあったりするわけだから調整の上な気がするが、基本は強引にでも進める、メンバーに多少は迷惑はかかってしまう前提で進めるのも大事。

対顧客でも完璧を求めすぎなかったこと

お客さんとの定例などで要件やスケジュールについて喋ることも多いが、この時準備不足で自分が納得いかないこともある。

その時に準備不足だからといって、共有を引き延ばさなかったのは良かった点。

もちろん、お客さんからの信頼を失うのはもってのほかなので、程度はあるが、お客さんからの軽い質問や詰めを過度にビビりすぎて完璧に準備するまで先のばすのはNG。

不安ごとの大体は杞憂に終わるな、という印象。

自分は詰めが甘く不安に思っている内容でもお客さんがあまり気にせずに拍子抜けに終わることも多い。
仮に詰められるケースでも致命的じゃなきゃ大して支障になることはない。それより先伸ばして必要な要件や設計が決められない方がよっぽど問題。

どうしても人間は完璧主義になりがちなので、雑でもいいから進めるスタイルでやったのはナイスだった。

せっかちに進めたこと

とにかくせっかちに前半に詰め詰めになるようなスケジュールを切った。

具体的には結合テストや単体テストなどの締め切りを逆算して、それぞれのガチのデッドラインを用意しつつ、そのデッドラインよりさらに前をどんどん締め切りにしていった。

結局締め切りを設定するとそこに向かってメンバーはきっちりやろうとしてくれる。

逆に本当にギリギリのスケジュールを設定したら余裕を持ってこなしてくれるかというそれは可能性としてはそんなにない。（メンバーがそこまで把握するギリもないといえばない）

夏休みの宿題は大半が8/30,31でやるのと同じなので、早めにガンガン切って締め切り効果を出すのは大事だった。

メンバーに申し訳ないと思わず、PMとしてきっちり判断して良かった。

プロジェクトの最初に時間を投資したこと

一番時間を投資すべきタイミングはプロジェクトどこか？

これはプロジェクトの最初だと思ったし、実際そうして良かった。

結局不確実性があると選択肢がとにかく増えるので、時間がどんだけあっても足らない。

選択肢を全部実現していくのも限界がある。

だからPMは不確実性を減らすことに全力を使うべき、理想は前半に残業が嵩み、後半は暇くらいだと思われる。（残業がないのが理想ではあるけど）

もちろん、お客さん都合でいきなり要件がひっくり返ることもあるが、それはこっちが先方の依頼を聞いてるので優位に物事を進められる。

でも、不確実性を減らしていない・要件を確定させていないのはこちらの責任、あとからスケジュールの調整が効かない。

だからとにかく最初に時間を突っ込んで不確実性を減らしていったのは正解だったしこれからも続けたい。

リードといえど、メンバーへの雑な相談をしたこと

自分で判断に迷うことがあればどんどんメンバーに相談した、これはやりやすかった。
リードは必ずしも引っ張らなければいけないわけでもない。

最終的にチームの方針を決められればいい。
だったらぐだぐだ迷って決められないよりチームメンバーに相談してさっさと決めた方がよい。
ガンガン壁打ちとしてメンバーは使わせてもらって助かった。

だめポイント

リスクに対するアクションのデッドラインを決めておくべきだった

PMの大きな仕事のひとつは、不確定な要件を確定させることがある。
結局、必要な情報が出揃ってしまえば設計を進めることはそれほど難しくはない。

お客さんから要件が出てこない場合、いつまでに要件が出なければスケジュールに間に合う約束はできない、という握りをしておくべきだった。
要は「要件が決まらない」というリスクの管理である。

今回リスク管理自体はしていて、要件が決まらない場合用のセカンドオプションを用意していた。
けれど「ファーストオプションがいつまでに決まらなければセカンドオプションでいきます」という具体的なデッドラインをお客さんと握れておらず、上司からの指摘で初めて問題に気づいた。

セカンドオプションを持つだけでなく、いつセカンドオプションに切り替えるか。
リスクのヘッジ策だけでなく、ヘッジ策をトリガーするデッドラインまで決めておくべきだった。

内部のコミュニケーションを増やすための時間の投資をすべきだった

エンジニアとして働いていれば、心理的安全性だなんだ言われることは多い。
頭ではその重要性を理解しても、心理的安全性を醸成するために行動するのは難しい。

そうしたコミュニケーションの時間のために、プロジェクトの時間を取ったりするのはなんだか気恥ずかしさがあって敬遠してしまいがちだ。効果も不透明でわかりづらい。

それでも、コミュニケーションが簡単にとれる関係性ができているかどうかはプロジェクトの進めやすさや成否に大きく関わってくる。

「ちょっと同期的に相談してもいいですか？」「めんどくさいんですけど、このタスクちょっとお願いしていいですか？」みたいな、声かけができる関係性があるかどうかがとても大事。

この関係性ができてないと、どうしても依頼や相談をすることが億劫になってしまって、タスクを抱え込んだり、メンバー間での情報共有ができなくなってしまう。

プロジェクトの立ち上げ段階で早いうちに飲みにいってしまった方がいいなと思ったし（時代的にちょっとあれならランチとかでも全然いい）、定例会の場などで軽いコミュニケーションの場をとるなど、コミュニケーションのための時間を用意すべきだった。

自分の見積もりは常に甘いと認識しておくべきだった

人間は見積もり甘くしがちである。
自分も例外ではなく、甘い見積もりをしてしまっていた。
それを理解してきっちりバッファを積んでおくべき、自分がこのくらいのバッファでいいかなと思ってもそれより気持ち1.3-1.5倍取るように動く。

単体テストや結合テストも絶対手戻りが起きるわけだし、バッファは積むに越した事はない。
PMははプロジェクトが炎上したら怒られるけど、後半暇になってリソースを余らせてもそこまで問題とはならない。

とにかくプロジェクトをスケジュール通り問題なく終わらせるのが最優先なので、それに対して多め多めにバッファを積むべきだった。
自分の見積もりは常に甘いと思ってバッファを積むようにしたい。

タスクを雑に任せること

オンボーディングが不十分なメンバーなどに対して、「情報の共有もできてないから、簡単なタスクを渡しおこう」となってしまいがちだった。

これは「情報の共有されてないじゃん」というメンバーからの指摘にビビってる訳でもある。
実際には、大半のメンバーは情報の共有がされてなくても、自律的に情報をプルしに来て課題を解決してくれる。

情報共有されていないから、と文句を言うメンバーは少ない。
仮にそういう文句を言われるのだとしても、PMとしてはプロジェクを前に進めることのほうが大事なので、ちょっと文句を言われるようなことを気にしていてはいけない。

タスクをアバウトに大きく任せる方がPM側はよっぽど楽だし、メンバーが自律的にプルしてくれた方がメンバーのプロジェクト固有の知識の理解が圧倒的に早い。（もちろん、PM側に時間が潤沢にあるのであればきっちり情報共有をすべきだが、時間が余ってるPMは少ないと思う）

正直今回は少しビビってしまうところがあったので、今後はいい意味で雑にタスクをふる、と言う意識を持っておきたい。