はじめに
不動産業界向けの新規プロダクトを開発している篠島です。新卒で入社してから9ヶ月が経ちました。Speeeに入社するまでは、個人でアプリやサイトをリリースしながら技術を学んできましたが、実際に開発現場に入ってみると、開発チームだけでは解決できない、あるいは気づくことすら難しい問題が多く存在することを痛感しました。
そうした中で、プロダクトの課題解決に向き合うプロダクトマネージャー（以下、PdM）の行動を間近で見る機会を得たことは、私にとって非常に大きな学びとなりました。特に、課題やステークホルダーが複雑で、「こうあるべき」という理想の姿がまだ明確になっていない状況下での対応力に感銘を受けたので、そこから得た知見をぜひ共有したいと思います。将来エンジニアを目指しているものの、開発の仕事についてまだイメージが湧いていない方に、働く上で重要なポイントが少しでもお伝えできれば幸いです (ちなみにPdMが書いた記事はこちらです)。
「あるべき姿」が見えないとき、どう前に進むのか？
Speeeの開発現場では、単に求められたものを開発するだけでは不十分な場合があります。特に新規プロダクトのオペレーションにおいては、Biz側（営業やマーケティング、オペレーション推進などのチーム）も模索しながら進めており、チーム間であるべき姿の認識が一致していなかったり、情報共有が十分でないままプロジェクトが進行してしまうことがあります。
このような曖昧な状況で、とにかく開発視点で偏った計画を立ててしまったり、受け身の姿勢で開発を進めてしまうと、期待されている水準を満たせない的外れな開発物を生み出す恐れがあります。 この恐れを回避するためには、他のチームの業務背景を深く理解し、そのチームの視点に立ちながらあるべき姿をともに考えることが重要であると学びました。
請求に関するプロジェクトの序盤、開発チームとPdMで具体的な方向性を詰めていました。しかし、プロジェクトに関連する業務を知らないまま進めていたため、方向性自体は間違ってはいないが、請求業務に携わる人が求める水準を満たせない状態になりかけていました。
日頃から境界にとらわれないインプットの姿勢を持つ
あるべき姿が見えないという問題に直面した際、普段から他職種が何を考え、どのようにオペレーションを動かしているのか深く理解する姿勢が欠かせないと感じました。 また、日常的に他のチームに関する知識をインプットすることができれば、課題の背景や全体像を早く正確に捉えやすくなり、本質的な解決策を短い時間で導き出せる可能性が高まります。
実際、PdMの行動を観察する中で、この姿勢の重要性を強く感じました。例えばPdMは、エンジニア経験がないにもかかわらず、簡単なコードであれば読み書きできるレベルまで学び、自らプルリクエストを作成してレビューを依頼するなど、技術的な側面にも積極的に理解する姿勢が印象的でした。
このようなPdMの姿勢は、プロジェクトを円滑に進める上で非常に重要です。異なる職種の人たちが協力し合う際、それぞれの業務背景が反映された共通言語がないと議論が噛み合わず、意思決定が滞ります。完全に共通言語を持つことは、現実的には難しいものの、PdMのように相手の視点に立ち、必要な知識をインプットする習慣を身につけることで、言語の使い分けや調整が可能になります。このような工夫を通じて、職種間のギャップを埋め、プロジェクトをスムーズに進めることができます。
このような姿勢はPdMに限らず、エンジニアにも求められる重要なスキルだと実感しています。自分の専門性を深めるだけでなく、他職種とのギャップを理解し、それぞれの考えを適切に捉えて擦り合わせることが、プロジェクトの成功に直結するのだと思います。
それでも「あるべき姿」が見えないときは？
とはいえ、実際に課題にぶつかった時、現場の状況や業務内容を深く掘り下げないと、全体像を把握するのが難しいことも少なくないと思いました。そのような時にPdMは、チームに対して以下のような取り組みを行いました。
1. 日次で他チームの業務を理解する場を作る
「あるべき姿」が曖昧な状況でまずやるべきことは、開発チームが背景知識を徹底的に理解することでした。プロジェクトの課題となっているオペレーションを毎日理解する場を設定し、この場によって開発チームが関与していない領域の知識を学ぶことで、その領域に関わっている人がどこに課題感を感じていて、どういう解決をしたいのか、を把握することができました。
2. 解決策の提案は慎重に行う
オペレーションの理解を進めている段階では、具体的な解決案を急いで提案することを避けるべきとも学びました。
まだチームごとの課題感や抽象度が揃っていない段階で、具体的な解決策を一方的に提示すると、議論がかみ合わなくなる問題が発生しました。これはそれぞれのチームが、それぞれの立場から異なる視点や抽象度で解決策を考えていたためです。
実際に起きたことではないですが、開発チームが工数の見積もりや計画を立てたいがために技術的な解決策を急いで提示してしまうと、業務全体の背景を考慮していないために、他のチームから理解されなかったり、場合によっては不信感を生む恐れがあるので気をつけようと思います。解決策を提案するタイミングは、関係者間の認識が完全に擦り合った後であるべきだと考えています。
3. 職種間の擦り合わせを一旦誰かが担う
2に関連しますが、解決へ向かうための職種間による「実現方法(How)の擦り合わせ」というプロセスの初動では、一旦両方の領域に詳しい方を介して非同期的に進めた方が良いと思いました。理由は前項とだいたい同じで、各チームから見えているものがあまりにも異なるため、議論が収拾しづらくなるためです。
これも基本的にはPdMが担当する役割だと思いますが、エンジニアの自分がそれを部分的にもできるようになれば、プロジェクトをより円滑に進めることができたのではないかと感じています。
おわりに
9ヶ月の経験を通じて学んだことは、エンジニアとして技術力を磨くだけでなく、プロジェクト全体を見渡し、他のチームを理解することの重要性です。入社以前は、組織での開発について具体的なイメージがまだ薄く、技術を深く身につけることが最優先だと考えていました。しかし、実際に仕事をしてみると、プロジェクトを前に進めるためには、それぞれのチームの目標や課題感を踏まえながら、あるべき姿を明確にし、共通認識を持つことが不可欠だと感じました。
これらの解決策は、どれも一朝一夕で身につくものではありませんが、意識して取り組み続けることで、養っていけるんだろうなと思います。
今後は、これらの学びを活かし、プロジェクトの中で積極的に役割を果たし、目標に沿った成果を出せるよう頑張ります！
Speeeではサービス開発をともに推進していく仲間を募集しています。
新卒の方は、こちらから本選考に申し込みが可能です キャリア採用の方は、こちらのFormからカジュアル面談をお申し込みいただけます Speeeではさまざまなポジションを募集中しています。募集中のポジションは、こちらから確認できます。もちろん、募集中のポジションに限らず、気になる方はカジュアル面談を気軽にお申し込みください。
※この記事は、2024 Speee Advent Calendar 17日目の記事です。 昨日の記事はこちら
