はじめに
こんにちは、hacomono でプロダクトエンジニアとして日々開発に励んでいる renren です。
「プロダクトエンジニアとは？」と思われた方は、こちらのスライドや過去の記事にまとまっていますので、ぜひご覧ください。
"ウルトラジャンプ" な成長を支えるプロダクトエンジニアというキャリア - Speaker Deck
「プロダクトエンジニア」という役割を定義しましたというお話 - hacomono TECH BLOG
プロダクトエンジニアとしての観点を詰め込んだ開発設計書のテンプレートを公開します - hacomono TECH BLOG
本記事で紹介する取り組みは、「"ウルトラジャンプ" な成長を支えるプロダクトエンジニアというキャリア」で示された理念と強く関連しています：
- ドメイン知識の強化（ビジネス日報の活用）：「ドメイン知識すなわちユーザーの業務理解」を深め、「ユーザーが日常的に行う業務の流れを理解」するという原則に沿っています。
- 課題解決能力の向上（ワークショップの実施）：「ゼロベースの思考で考え、周りから得られている情報（課題）が本当に正しい課題かどうか見極める」というプロダクトエンジニアの基本姿勢を実践しています。
- コミュニケーション能力の発揮（CSとの連携）：「プロダクトを一緒につくるメンバーだけではなく、その先にいる社内のメンバー/ユーザーに対して」関係構築を行い、「迅速に物事を進めていけるよう」リードしています。
特に「熱量の高さ」と「Why思考・仮説思考」のマインドが、本記事の取り組み全体を通じて実践しており、「期待値を超える」プロダクト開発につながっています。
さて、プロダクトエンジニアとして働く中で、「ただ機能を実装する」だけでは物足りなさを感じていませんか？仕様書通りにコードを書いても、ユーザーの課題から遠い場所にいるような感覚。タスクの背景が見えず、現場で何が起きているのか把握できない状況。
私もそんな課題感を抱えていました。そこで、3つの簡単な取り組みを始めてみたところ、プロダクトエンジニアとしての解像度とモチベーションが大きく向上しました。今回は、その具体的な取り組みと効果を紹介します。
1：ビジネスメンバーの日報でリアルな現場を知る
なぜ始めたのか
最大の課題は「開発案件の解像度の低さ」でした。現場が何を求めているのかわからない状況では、機能開発の優先度や意味を理解するのが困難でした。
具体的な取り組み
hacomono には社内全員の日報が見える環境があります。この環境を活用し、営業、マーケティング、CS など全ビジネスメンバーの日報を定期的にチェックするようにしました。
例えば、ダブルブッキング防止機能の実装中、営業メンバーの日報で「お客様から『スタジオの予約が重複して困っている』という相談を複数件受けた」という記載を見つけました。この情報から、私たちが開発している機能が「顧客の課題解決にマッチする」ことが明確になり、単なる機能開発ではなく、実際の顧客課題解決につながることを実感できたのです。
得られた効果
モチベーションが向上しました。「誰のために、なぜこの機能を開発するのか」という本質が明確になることで、開発への熱量と責任感が大きく高まりました。特に、日報で店頭スタッフがダブルブッキングが起きないように常々チェックしていた苦労を知り、私たちの開発が現場の負担軽減に直結することを実感できました。PRDにその情報が記載されていたり、PdMから説明を受けますが、自分自身の足で得た情報には特別な説得力があり、心から納得して課題に向き合うことができました。この体験を通じて、プロダクト開発においては技術的な「どうやって」よりも、目的を示す「なぜ」の部分が圧倒的に重要だと実感しました。
2：ワークショップで多角的な価値を探求する
2つのワークショップを実施
- 価値マップワークショップ
課題の把握と整理のため、社内の複数メンバーにインタビューを実施し、その情報を価値マップとしてまとめました。エンジニア、QA、デザイナー、PdMが参加する多様な視点を持つチームで取り組みました。
- ユーザーストーリーマッピング
「理想の予約体験」を具体的に描き出すために、予約チームでユーザーストーリーマッピングを実施しました。「予約」という概念が広範で曖昧なため、チーム内でも理想像を明確に表現できない状況を改善するためです。
最大の発見：メンバーの多様な視点
ワークショップで最も印象的だったのは、メンバーからの柔軟な視点でした。私は既存システムや運用を前提に考えがちでしたが、「そもそもなぜこの流れなのか」「別のやり方もあるのでは」といった根本的な問いを投げかけてもらいました。自分では思いつかないような多様なアイデアが出てきて、私の思考のクセを変える貴重な刺激となりました。
この多角的な視点により、チーム内で当たり前と思っていた前提を見直すきっかけが生まれ、より良いソリューションの発見につながりました。
具体的な成果
ワークショップの結果、PBI（プロダクトバックログアイテム）の見直しを行いました。優先度の再評価や新たな課題の発見により、より価値の高い機能開発にフォーカスできるようになりました。
3：CSとの関係構築で鮮度の高い情報を収集
きっかけは新年会
CS（カスタマーサクセス）との連携は、福岡で開催された新年会への参加がきっかけでした。それまではあまり接点がありませんでした。
月1回の1on1で情報交換
新年会をきっかけに、月1回の1on1を設定して情報交換を行っています。特に印象的だったのは、実際の環境を見せてもらいながら「この要件を満たすためにこういった複雑な設定をしている」といった現場の工夫を教えてもらったことです。
チームへの情報展開
得られた情報は以下の方法でチームに展開しています：
- 直接聞いてもらう：温度感が重要な情報は、MTGを設定してCSから直接チームに話してもらう
- 口頭での共有：日常的な情報は自分から口頭で伝える
大きな変化と効果
この取り組みにより、チーム全体に以下の変化が生まれました：
- 具体的な機能のターゲットイメージが明確化され、モチベーションと生産性の向上につながった
- 作った機能のフィードバックが届くようになり、開発者として大きな喜びを感じられるようになった
- 現場を踏まえ「機能をこうした方がいい」「こうしたい」といった改善提案がチーム内で活発になった
具体的な成果：ダブルブッキング防止機能
CS連携の成果として最も顕著だったのが、ダブルブッキング防止機能の開発です。現場の切実なニーズを直接聞くことで、チーム内での優先度が一気に高まり、スピーディーにリリースまで進めることができました。さらに嬉しかったのは、リリース後にCSの方からDMをいただき、「開発への感謝」と「現場の反応も良い」という生の声を聞けたことです。自分たちの開発した機能が実際に価値を届けられたという実感が、次の開発へのモチベーションにつながりました。
まとめ
3つの取り組みを通じて、私自身とチーム全体に大きな変化が生まれました：
- 解像度の向上：ビジネス日報により、タスクの背景や顧客課題が明確になった
- 視野の拡大：ワークショップにより、多角的な価値探求ができるようになった
- 現場との連携：CS連携により、リアルなユーザーの声を開発に活かせるようになった
最も重要だったのは、これらの取り組みがモチベーションと生産性の向上に直結したことです。「誰のために、なぜ作るのか」が明確になることで、プロダクトエンジニアとしての充実感と責任感が大幅に向上しました。
プロダクトエンジニアとして、技術力だけでなく「プロダクトの価値創出」により深く関わりたい方は、ぜひこれらを試してみてください。小さな一歩から始めても、大きな変化につながるはずです。
💁 関連記事
