この記事は enechain Advent Calendar 2023 の9日目の記事です。
こんにちは、先月11月にenechainに入社した尾崎（@ozsaya）です。 前職はクックパッドで、クックパッドマートという生鮮ECサービスの開発に携わっていました。 これまでのキャリアではソフトウェアエンジニアとして自社サービスの開発に携わってきましたが、プロジェクトマネジメントやプロダクトマネジメントを始めとして、営業や分析、マーケティングなど色々な役割を兼ねる機会も多く、転職を機にプロダクトマネージャーというロールに軸足を置いてみることにしました。 2023 enechainアドベントカレンダーにも投稿している弊社Product Management Desk統括の大橋の姿勢に共感したことは入社の決め手の一つです。
Product Managerは「会社の事業上の課題を、あらゆる手段を駆使して（主にプロダクトやテクノロジーの力を用いて）解決に導く人」だと思っています。
なんやかんやで入社して一ヶ月経ったので、最初の一ヶ月で考えていたこと、実践したこと、これからやろうとしていることを言語化してみます。
プロダクトマネージャーの役割
私の考えでは、プロダクトマネージャーとは原初一人でプロダクトを開発していたところから専門的な職能を持った人に役割を移譲していった成れの果てです。 プロダクトマネージャーはプロダクトの成功のために必要なことを一番フラットな目線で判断して実行できて、そうしなくてはいけない役割だと考えています。 判断には根拠になる情報が必要で、必然的に一番多くの情報を持っている必要があることになります。 そういうわけで、私が入社後一ヶ月で重視したのはメンバーとプロダクト・事業・業界について知ることでした。
入社する
入社して担当することになったプロダクトは、新規に立ち上げる環境価値の取引所『日本気候取引所 - Japan Climate Exchange』（JCEX）でした。 JCEXの開発着手は9月で、プロダクトのリリースが11月末に決まっていました。 私は実際には10月の半ばから業務委託として参画していたため、リリースまでの3ヶ月の開発の後半1.5ヶ月を伴走した形になります。 入社初日時点では、環境価値のドメインの知識は愚か、事業戦略も関わるメンバーの全体像も把握できていませんでした。 ただ、エンジニアチームの開発に対する焦燥感は伝わってきました。 偶然にも私はコードを書くことができたので、まずはコードを書いてみることにしました。 結果的には環境構築のドキュメントをちょっと更新して、UIコンポーネントを一つ実装する程度の関わりだったのですが、これをきっかけにエンジニアメンバーの方々と結構打ち解けられたなと感じていてとても良かったです。
仕様書
少しずつエンジニアメンバーとのコミュニケーションを取れるようになってくると別の課題が見えてきました。 JCEXには既にリリースに向けた仕様書が用意されており、さしあたり仕様整理は必要ないと考えていたのですが、そんなことはありませんでした。 言われてみると当たり前のことですが、開発を進める中で仕様に対する確認事項が生まれている状態でした。 エンジニアメンバーが気づいた仕様に関する確認事項を一元的に引き受けて事業メンバーとすり合わせにいくことにしました。 また、仕様書の差分を参照しづらく、仕様追加や変更に至った経緯もあとからわからなくなっているという課題感も見えてきました。 特効薬的な改善はないのですが、仕様の確認が生じた際の議論のドキュメント化を徹底し、仕様書の該当箇所へリンクしていくことにしました。
判断できること
プロダクトの仕様に関して逐一事業メンバーの時間を取ってすり合わせることは、最適な状態とは言えません。 プロダクトマネージャーが業界・事業・プロダクトについてより知っていればプロダクトマネージャーだけで判断できることは少なくないはずだからです。 仕様書が策定されたあとの追加の確認事項は、基本的にはプロダクトマネージャーが判断した上で事業メンバーに共有する程度のフローで運用できるのが望ましいと考えています。 入社2週目までに関連書籍や制度のインプットをしてみたものの、なかなか知識が追いつかないと感じることが多かったので、思い切って事業の責任者に勉強会を開いてもらうことにしました。 事業責任者に勉強会を開いてもらうことは時間の使わせ方の観点で憂慮していましたが、結果的には非常に有意義だったと認識しています。 事業責任者の視点での業界と事業に対する考えをインプットできたことはとても効果的でした。 実際に、この勉強会を境に私自身が判断できる領域は格段に増えました。
一ヶ月の振り返り
そんなこんなでJCEXのリリースまでこぎつけ、リリース後の開発トピックの優先度と仕様策定を進めているのがここ数日です。 振り返るとかなり後手後手で、必要に迫られたことに対応しているような状況が多かったなと感じています。 同時に、この一ヶ月で業界・事業・プロダクトにまつわる最低限度の理解を獲得できたと感じています。 ここからの開発はトピック策定から参画できるので、事業・プロダクトの成功に繋げられるようより先手を取った動きを心がけていきたいです。
大事だと思ったこと
ストック情報の重要性を改めて認識しました。 一ヶ月という短い期間でも、ちょっと前に意思決定した内容を参照できる状態のありがたみを感じる機会は何度もありました。 仕様変更の議論にしても、事業責任者からの勉強会の内容にしても、これからもできる限りの情報をドキュメント化していこうと考えています。 理想的には、このプロダクトに新しいメンバーが参画したときに、ドキュメントを読みこめば私と同じ判断ができる状態を目指したいです。
エンジニアを経験していることの有効性
エンジニアを経験していると実際に開発するエンジニアと共通の言語を持てるため、より効率的な仕様策定が実現できると感じています。 主に開発プロセスで負担をかけていると気づけたポイントと改善のアイデアもあり、このあたりの見通しの良さもエンジニアを経験していてこそなのではないかと考えています。 （例えば、Protocol Buffersを私がレビューしてみるなど、うまくいくものがあれば改めてブログで共有しようと思います。） また、JCEXの他に基盤寄りのプロダクトも担当し始めています。 基盤寄りのプロダクトになると技術的な要素の比重が高くなるので要件理解のためにエンジニアの経験が活きています。 弊社のプロダクトマネージャーは各々異なる特徴的な経験を持っているので、得意な領域を補完しあえたら良いなと考えています。
おわりに
ここまで実践したことを綴ってきましたが、プロダクトマネージャーとして立ち上がる上で何より大事なのはチームメンバーのホスピタリティだと感じています。 特に、わからないことをすぐに聞ける環境であったこと、入社早々からプロダクト開発チームがプロダクトマネージャーに積極的に情報を集約してくださったことがとても助かりました。 感謝しています。 冒頭に掲げていた事業やプロダクトの成功に集中したい、という意志を叶えられる環境にあると感じています。 これはとてもありがたいことで、日々プロダクトに向き合えることを楽しんでいこうと思います。
明日はJCEXで一緒にリリースまで駆け抜けたエンジニアの@tomohiko-tanihataからGoのマイグレーション環境構築について紹介するので是非チェックしてみてください。
enechainでは、一緒に事業を拡大していける仲間を絶賛募集中です。
