【イベント参加レポート】Product Engineer Night #5 〜プロダクト志向の組織・カルチャー形成〜
今回はこちらのイベントに参加しましたのでレポートです！
詳細は以下。
「Product Engineer」という新しい職種を定義する企業が国内外で出始めており、技術中心のエンジニアリングから一歩進み、プロダクトの価値を中心に据えたエンジニアリングへと進化する動きが出ています。プロダクト開発はその不確実性が特徴であり、単一の知識や手法だけでは価値を生み出すことは難しい総合戦とされる領域です。多様な知見と視点を持つことがプロダクト価値追求には欠かせません。
今回のテーマ: プロダクト志向の組織・カルチャー形成
過去のイベントでは、組織としてプロダクト志向を持つ方法について多くの相談が寄せられています。エンジニアがドメインに関心を持って主体的にキャッチアップする方法や、プロダクトの先にある事業を見据え、数値を含めてエンジニアが動ける状態にする方法などが挙げられます。エンジニアがプロダクトと事業に対してオーナーシップを持って開発できる組織作りを目指し、今回のテーマを選定しました。
なぜ参加したか
エンジニアがドメインに関心を持って主体的にキャッチアップする方法を知りたい
オーナーシップを持って開発できる組織づくりに興味がある
他社ではどんなプロダクト志向の開発組織をつくっている、作ろうとしているかを知りたい
※恐らくプロダクトエンジニアという言葉が生まれたのも、エンジニアが「この作業をすると誰がどう嬉しくなるのか」が曖昧になったり、「言われたから開発する」「作業としてやる」「これを提供したその先に顧客など使ってくれる人がいる」などといった「なぜやるのか」の視点をなかなか持てない場合があるからだと思っており、プロダクトに対する「主体性」や「オーナーシップ」というのは前から深く考えていた課題なので、このテーマにはとても興味がありました！
新たな考え方が取り入れらればと思い参加しました。
ゴール
他社での組織、カルチャーづくりの事例を知ってアウトプットできる状態になること
なにか取り入れられそうなアイデアがあれば自分の組織にも共有や提案をできる状態になること
LT① プロダクトエンジニアをつくる組織設計
by 丹羽 健 / アセンド株式会社 取締役CTO
物流のSaaSのアセンドがプロダクトエンジニアを必要とする理由
マルチプロダクトを作らなきゃいけなかったので、プロダクトづくりの生産性を上げることが大きなテーマだった
組織拡大中でプロダクトごとにチームを分けている
コンパクトさを保って機動的に開発をしている
3つのプロダクトエンジニアの役割
Product Maneger
・事業マーケット全体を俯瞰整理して優先スべき顧客課題を策定
Lead PdE
・仕様品質の担保、メンバー育成
・メンバーがつくる仕様の水準を引き上げプロダクトとして満たすべき品質を確保
・メンバーを育成し、組織のプロダクト開発力を向上
Member PdE
・開発機能に対してオーナーシップを持ち、関係者を巻き込み頼りながら顧客へ価値を提供する
価値あるプロダクトをつくる3要素
①課題へのオーナーシップ
顧客期待を超える機能には個人の熱量が最重要
オーナーシップを高めるために入社オンボーディングで各地域の運送会社様の現場を訪問して課題の重要性を全身で感じて熱量を上げる！
言われた仕様ではなく自身で策定した仕様を実現する
プロダクト開発プロセスの全体にオーナーシップを持つフルサイクル開発
自分が作った機能を顧客に自分が提供し顧客への価値提供の実感が醸成される
②顧客理解、ドメイン理解
SaaSとして顧客業界理解の解像度を重視
課題整理とソリューションの質の土台
顧客ごとにSlackチャンネルで背景情報を収集可能なようにしている
商談課題ヒアリングの動画をデータとして蓄積し誰でも参照可能
③検証スピード
仮説検証のスピードが事業成長の源泉
スピードが早いということはフィードバックが早い
顧客要望を受けて20分で改善した事例もある
感想
特に運送会社さんのところへオンボーディングのときに実際に課題を全身で見る！っていうところに共感しました。これはどんなサービスでもできることで、例えばCSの顧客MTGに参加するなどっていうのは本当にオーナーシップを持つために重要なんだと思いました！
LT② バクラクの爆速開発を支える プロダクト組織の開発文化
by 小峯 祥平 / 株式会社LayerX プロダクト開発部 部長
LayerXの文化
羅針盤をつくって行動指針や大切にしている価値観を言語化している
プロダクト志向のエンジニアが活躍するために必要な３つの要素
①爆速開発力
お客様に価値を届ける速さが早いこと
②エンジニアリング力
お客様の要望を実現し、想像を超えるためには技術力が大事
③リーダーシップ（オーナーシップ）
自分の仕事 チームの仕事 組織全体やプロダクトの提供価値
リーダーシップ、オーナーシップの範囲が広いほど事業、組織への貢献度は大きい
チームに各プロダクトの意思決定を移譲する
【自分の考えた工夫、施策でお客様が喜ぶ、会社が成長する】
以下を３〜５人の小規模なチームに任せておりチームでの意思決定の幅は広い
・プロダクトやチームの目標設定
・日頃の開発サイクル
・メンバーのマネジメント
※開発タスクのオーナーシップを持たせるためにWhy What Howを極力メンバーに委譲して意思決定している
爆速開発の特徴
・Factから事業をつくる
データだけではなく、お客様の名前の声もFactのひとつ。技術力でより良い解決策が生まれる
・デモ駆動開発
デモを見せて素早くFBをもらい、改善することが重要
・オーナーシップを持ち、背中を預け合う開発スタイル
エンジニアが仕様策定から参加し、フロントエンドもサーバーサイドも関係なく、一気通貫で開発する。お客様の声から始まる開発とあるべき姿から逆算した開発の２面で開発している
感想
やはりオーナーシップを持つためには、自分で仕様を考えて自分でつくったりすることが大事なんだなと思いました。そのために羅針盤で具体化・言語化して開発を進めていて素晴らしい組織だと思いました。やはり、上から言われたりビジネス側から言われたからみたいな仕様だとエンジニアとしてのオーナーシップは持ちづらかったりするのでプロダクト開発の一部だけに関わるのではなく全体に関わっていくことの重要性を改めて感じました。
LT③プロダクトディスカバリーから見る、アウトカムに向き合う価値観と習慣
by 株式会社dinii Software Engineer Yutaro kido
diniiはテクノロジーで飲食ビジネスを楽しくやりがいのあるものに、飲食文化を面白くエンターテイメントなものにしていくプロダクト。
プロダクトで問題を解決するために重要な２つの課題
①ディスカバリー
問題の解決策の発見・把握
diniiのディスカバリーチームでは自社にとって新しい領域に対して、問題の解決策を発見するために必要な学習を迅速に行う（Product Manager,Designer,Engineer）の３名でディスカバリーチームを構成している。
②デリバリー
堅牢でスケーラブルな実装の提供
ディスカバリーのためには迅速な学習が必要で、デリバリーのためには自信のある実装が必要
新規プロダクトの立ち上げで重要視した価値観と習慣
価値観：顧客の成功がプロダクトの成功
新規プロダクト開発では最重要
プロセスの遵守でも計画の達成でもKPIの改善でもなく、顧客の成功を目的にする
顧客の段階的な成功（最初から完全な成功は難しいので段階的に考えている）
プロダクトや機能を
①使ってみたいと思う
②実際に使う
③習慣的に使う
④お金を払ってでも使いたいと思う
習慣①：顧客と話す
顧客が成功するプロダクトを創るために顧客と継続して話すことは必要不可欠
顧客の成功の段階ごとに顧客と話したくなることが変わる
習慣②：早く出す
早く出すためにできること
作らないものを早く決める
小さく出し続ける
など・・・
感想
ダイニーさんのプロダクトは無意識に飲食店などで使っていたので、あのプロダクトだ！と想像できました。
プロダクトで重要なのは顧客の成功を先に考えていくこと！っていうのは共感できましたし、同じく大切にしたい価値観でした。
LT③ 方向性・仕組み・文化で実現するプロダクト志向の開発組織
by 古澤 智裕 / 株式会社メルカリ Discovery & Search Team Director
プロダクト志向：顧客への価値最大化を重視する価値観
組織のプロダクト志向を支える土台の３要素
方向性：ビジョンと達成への道のり
ゴールと戦略を言語化すること。どこに向かいどのように向かうべきか。
OKRをメルカリは採用している
ゴール：チームが向かうべき場所と測り方を明文化したこと
戦略：ビジョンを達成するための道筋を言語化したもので、全体像、難所、その解決方法を含む
仕組み：活動の枠組みとそのアップデート方法
優先順位付け：優先順位付けの基準をできるだけ透明化し、そのためのコンテクストをアップデートする仕組みを作る
フィードバックサイクル：ユーザーテスト、A/Bテストなどを活用し、アイデアの確からしさを確認する
優先順位付けの基準の例
テーマの優先度
ビジョンとの関連性；ビジョンに一致するプロジェクトを優先し、ビジネス成長にプラスの影響があってもビジョンから遠ざかるなら優先度は下がる
投資対効果
文化；日々の仕事の積み重ね
重要とする価値観を明文化する。日々のコミュニケーションで意思決定の過程をオープンにすることで、自然と発生する考え方に影響を与える
重要とする価値観の明文化
意思決定のプロセスをオープン化
【実例】行動指針
顧客のために行動する
誰のために行動しているのかを常に考える
シンプルさを保つ
システム設計、UI/UX、コミュニケーションなどすべてをシンプルに保つ
個の変革が成長を牽引する
メンバーの成長が会社の成長になる
感想
「誰のためになぜやるのか」この考え方は、エンジニア視点でときに忘れてしまう場合もあるのでこれを行動指針に落とし込んで実践されていて、素晴らしいなと思いました。前職でプロダクトオーナーをやっていた
最後に
今回のLTで共通していたのはオーナーシップの重要性、顧客との対話、顧客の成功というキーワードが出てきていたことです。
エンジニアがプロダクトを自分の裁量と知見で改善して、直接顧客に喜んでもらったり、改善のFBをもらったりする体験は、これからのプロダクトエンジニアリングを考えていくときに重要だと改めて思いました。
顧客視点で考えて顧客視点で仕事をしていく。この価値観は以下の記事でも書いたのでとても共感できる内容が多かったです。
特に気になったのは以下。
プロダクトエンジニアという新しい職種の定義とその重要性。
羅針盤で自分たちの価値観やWhy What Howを言語化すること
エンジニアがオーナーシップを持って開発できる組織づくり。
誰のためになぜやるのか、を明確にすること。
顧客との対話とその重要性。
顧客の成功を目的としたプロダクト開発の価値観。
これからの業務でも、こういった価値観を言語化したり振り返ったりっていうのを意識していきたいなと思いました！
余談
イベントでは手作りと思われるカレーが提供され、これの豚肉が角煮のようにゴロゴロと大きく、おいしかったです。もしかしてこれもプロダクト志向か…
