Product Engineer Night #7 〜LT大会！〜に行ってきました。
ずっと行きたかったイベントで念願の初参加でした。
イベントの概要
Product Engineer Night はプロダクト志向を持つエンジニアたちが集まり、知識と経験を共有し互いに学び、議論を深める場を創ることを目的としています。
「Product Engineer」という新しい職種を定義する企業が国内外で出始めており、技術中心のエンジニアリングから一歩進み、プロダクトの価値を中心に据えたエンジニアリングへと進化する動きが出ています。プロダクト開発はその不確実性が特徴であり、単一の知識や手法だけでは価値を生み出すことは難しい総合戦とされる領域です。多様な知見と視点を持つことがプロダクト価値追求には欠かせません。
プロダクトエンジニアに関する note はこちら
（https://note.com/niwa_takeru/n/n0ae4acf2964d）
過去の参加者アンケートでのNPSは9.4と非常に高く、LTだけのイベントではなく全員が楽しく議論をする熱狂的なイベントを実施しています。現在プロダクトエンジニアとして第一線で活躍されている方だけでなく、プロダクトエンジニアという働き方・姿勢に興味がある方もぜひ奮ってご参加ください！
引用：
イベント参加の背景
- プロダクトエンジニアという概念にここ１年ぐらい魅了され続けている。
- 主催の丹羽さんやLT登壇者北原さんの発信に刺激を受けている。
- これまで気後れして参加できていなかったけど今夜こそ！！
プロダクトエンジニアのLT大会メモ
６つのLTどれも学びが深かったです！！
- 不確実性の高い仮説を迅速に検証するための開発プロセス
価値は状況によって変わる。
バリュープロポジションキャンパスでも、あくまで仮説。
リリースして初めて評価してもらえる。
利用・定着・活用、継続を含めて価値を評価する。
アウトカムはコントロールできないので、IN/OUTの質量をあげる。
プロダクトディスカバリーはタイムボックス区切って高速に回し、デリバリのサイクル回す。
各工程のアウトプットを次のインプットに回す。仮説が外れても次に活かす。
CMMIで各プロセスを評価する。レベル３定義された段階を目指す。
３になると再現性が生まれるので、他プロジェクトでも活かせる。
Minimum Marketable ProductとMVPの違いを意識する。
プロダクトエンジニアだからこそ全体プロセスを意識した改善ができる。 - エンジニアが加速させるプロダクトディスカバリー 〜最速で価値ある機能を見つける方法〜
ディスカバリーは問題と解決策を探索し、何を作るかを見極めるフェーズ。
プロダクト開発は望まれていないことを作って失敗する。
評価のリスクが最後まで持ち越されることが問題。
価値、ユーザビリティ、実現可能性、事業実現性のリスクに対処することが大事。
問題と解決策の探索を行う。
後者は迅速な学習が最適。作らずに済むことが大事。
プロダクトディスカバリーからエンジニアが入ることで、仮説検証を早められる。
リスクの高いところから検証する。 - フリーランスエンジニアがプロダクトエンジニアになるまで
フリーランスとプロダクトエンジニアとで任される単位・任され方は逆。
しくじり。
・顧客や営業のいうことの鵜呑み
顧客の事情とプロダクトの事情の最適解を考えられるのはエンジニア。
HOWではなく、WHYにより課題の再定義が重要。
・オーナーシップが芽生えない
プロダクトレベル、ビジネスレベルの視座が求められる。
プロダクトに対して自分のビジョンが重要。自分なりのプロダクトロードマップを立てる。
・PdM、PjM、エンジニアでの迷子
プロダクトエンジニアには各領域の役割がある。
フェーズによって目的を変える。要件定義ではtoBeを見据える（PdM視点）。
設計工程以降、どこまでどうやって作るかを考える。（PjM、エンジニア視点） - プロダクトエンジニア構想を立ち上げ、プロダクト志向な組織への成長を続けている話
開発を通じてプロダクトの価値を高めたいエンジニアが多い。
EMとして自組織にプロダクトエンジニア文化を育てたい。
ユーザー価値を素早く提供できるプロダクト志向組織へ。
全社の方向性からぶれないように整理し、随時共有を行う。
現場ではドッグフーディング、他プロダクトへの興味、顧客理解のためにCS情報を整理。
プロジェクトごとにリードエンジニアを設けた。（立候補制）
プロダクト改善のチケット起票、定性指標でモチベーション確認、定量ではデプロイ頻度など向上。
これからは、広範なアイデアの引き出し、ビジネスサイドとの連携を強化したい。 - ラクスの開発組織が目指す圧倒的な『顧客志向』の文化の創り方～楽楽精算編～
年４回リリースのウォーターフォール開発。
ステークホルダが多く、意見を聞かないといけない。ＷＦの方が合理性がある。
アウトプット量が限られるので、アウトカムを意識しないといけない。
プロダクト志向のために、認知、興味関心、意思決定、行動の強化。
認知のための顧客志向ワーク。ディスカッションによる言語化。
興味関心のための製品貢献実感醸成のための勉強会。PdMによる製品解像度の向上。
意思決定のための製品ロードマップの勉強会。ロードマップをどう活かすかのディスカッション。
行動のための要求に至った顧客課題共有会。なんでそれを選んだのかの共有会。 - プロダクトエンジニア360°フィードバックを実施した話
プロダクトの定義。
どうゆう人で、どうゆうスキルが必要で、どういったマインド・生態か。
コンテキストを揃えるためにフィードバックを行う。
被評価者は評価者を指名。評価者はGoogleFormで投稿。その後FB。
FB結果をもとに次のアクションの検討。FB自体も継続的に続けることで認識をアップデートする。
Unconference! (交流会)
激烈なヒトミシラーとして、毎回オフライン参加を躊躇ってしまう理由のひとつである懇親会。
皆さま気さくに話しかけて下さりとても嬉しかったです。
EM、PdMといった自分とは違う視座で見たエンジニア組織の課題であったり、事業フェーズやプロダクトへの関わり方でのエンジニアの視座であったり、自分とは違う領域の方とのコミュニケーションにより、学びや発見に繋がるところが多くありました。
直前までオフラインかオンラインかで悩んでいましたが、オフライン参加して良かったです。
普段の業務では発生しないコミュニケーションの重要性。計画的偶発性理論。
感想とまとめ
エンジニアが事業領域を意識することの重要性を１日１回は聞く時代になった気がしています。
プロダクトエンジニアという考え方に魅了されたのと並走し、及川卓也さん『ソフトウェアファースト』がずっと頭に引っかかっています。
ソフトウェアは事業と密接に関わるようになり、その開発にオーナーシップを持たないとVUCAの時代では置いてきぼりにされる。
増田亨さんの最近のドメイン駆動を中心とした発信にも共通した背景があると思っています。
自分は受託開発という領域で、発注企業様のプロダクト開発を支援するサービスというプロダクトを携わるエンジニアリングを行っています。
もしかしたら『共創』という考え方に落ち着くのかもしれないけれど、受託開発を受けるだけではなくオーナーシップを持って取り組みたい。
多くの刺激を頂いたイベントでした。
今後もプロダクトエンジニアリングを志向していたいです。
丹羽さん北原さんが私のことを覚えていて下さったこと嬉しかったー。
