Hola! マイコです。

プロダクトマネージャーに任命されてから1年以上経過しました。その間、要件定義、関係者間調整、大まかなシステム設計、オペレーション構築、トラブルシューティングなど幅広く挑戦してきましたが、
エンジニアが最高のパフォーマンスを発揮できるような環境づくり
が大事だと考えるようになりました。

この記事では、1年間の経験を通じて、エンジニアとの関係＆環境づくりに役立った（と思う）ことを紹介します。

オンボーディング支援

新しくジョインしたエンジニア向けにオンボーディングセッションを行なっています。
技術面についてはエンジニア同士でフォローしていただいているので、プロダクトマネージャーからは事業全体やユーザ像、優先順位の考え方などプロダクトを取り巻くコンテクストをインプットしています。
また、口頭での説明だけでなく、過去の経緯やエラー経験などを記載したドキュメントも用意しています。過去の過ちは繰り返さないためにも、なるべく考慮不足や不具合や債務を残さず、前向きな開発ができるように心掛けています。

自分が作っているもの（プロダクト・機能）の価値を信じてもらう

エンジニアとの日々のコミュニケーションは「今やること」「解決すべきこと」ばかりで超近視眼的な話題になりがちです。オンボーディングでプロダクトの位置付けや現在地について話していても、目の前の開発に集中していると忘れてしまいそうです。そこで、ランチ会を開催し、中長期ビジョンや大きな課題を一緒に語る機会を作っています。普段とは違う頭の使い方をするので、人柄もわかって楽しいです。
また、ユーザの生の声を届けるということも日常的に行なっています。自分の仕事の価値を認められるのは、とても嬉しいことです。ユーザの声ほど生々しいものはありません。
「ユーザにはこうやって捉えられていいる」「この機能がこんなに喜ばれてるよ！」とお問い合わせチャネルでプロダクトに関する声が届くと、開発チームをメンションしています。

阻害要素を排除し、開発に集中できるようにする

自分のやるべきことに集中できると、パフォーマンスが発揮できるし、何より気持ちよく仕事に取り組めます。残念ながらプロダクト開発や運用では、予期せぬ障害やエラーによって予定を狂わされることが多々あります。
そこで、（ログを追いかけるなどエンジニアでないとできないことがない限り）トラブル調査・対応はプロダクトマネージャーが引き受けるようにしています。
トラブルシューティングは、ユーザの状況とデータの不整合を見比べたり、仕様を調べたりと、ビジネスとエンジニアリング双方の理解が必要です。
プロダクトマネージャーとしてもエラー調査を行うことで、細かい仕様やシステム間連携、さらに技術的課題を解像度高く理解できます。技術的な面でエンジニアと課題認識が揃ってくると、新機能設計や優先順位決めのコミュニケーションもスムーズになるというメリットがあります。
最終的にパターン化できたエラーはサポート窓口に型化・移管までしています。

ちなみに私は「メーデー!:航空機事故の真実と真相」シリーズがファンです。事故調査委員になりきって解明してます。

まとめ

以上、1年間、プロダクトマネージャーとしてエンジニアのパフォーマンスを引き出すためにやってみたことでした。

今後の改善案ですが、オンボーディングセッションに「自社システムのテーブル定義の解説」を追加予定です。システム周りはエンジニアの領域ではあるので僭越ではありますが、おそらく弊社システムのER図を継続的に一番見続けているのが私なので、蓄積した知識を共有しようと思っています（特にいろんな落とし穴）。

プロダクトマネージャーの先輩方やエンジニアの方にも、こうするとパフォーマンス上がるよ！なんてご助言あればコメントいただけますと幸いです。