🐻

Product Engineer Night #3 に行ってきました

2024/03/14に公開

こんにちは、もこし(@mok_oshi)です。
普段は techners株式会社で美容サロン向けの SaaS KaruteKun を開発してます。

最近個人的にウォッチしているプロダクトエンジニアに関するイベント
Product Engineer Night #3 にいってきました。
いい刺激になったので、つらつらと感想を書いていきます!

発表まとめ

プロダクト開発ゼロイチの分類とロジックス事業がイチに至るまで (アセンド株式会社 丹羽さん)

https://x.com/niwa_takeru/status/1767900739173851535?s=20
「ゼロイチ」の言葉の定義から丁寧にはじまった。なるほどたしかにゼロイチと言っても、 事業 > プロダクト > 機能 と粒度がある。「ゼロイチ」と言われたら事業のことなのかなとは思っていたけど、敢えて定義に立ち返るのはいいですね。(PMFの参考指標で調達が上がっているのは「むむ?」となった。PMFしているから調達ができるのかな?と思った。)

運送のドメイン知識がなさすぎるけど、荷物・トラック・ドライバーの3つを最適化する、と聞くとたしかに紙では非効率そうだしITでめっちゃよくできそう!となった。

業者ごとにオペレーションに差異がありそうだし、共通項とって標準化するの大変なのだろうな〜。個社と仲良くしすぎると全体感を見失いがちになる、みたいなポイントも大いにありそう。

創業時からプロダクト戦略は変わっておらず、ただ技術的には結構何度か大きく変更があったみたい。ゼロから作り直したり、DB変えたり、すごく機動的に動いているように見えた、すごい。ドメインまで踏み込んで試行錯誤するエンジニアの動きがとても重要そう。技術選定だけでなく各所での意思決定まで、やっぱり強いエンジニア組織が事業の成功のファクターになるよなぁという気持ち。

コンパウンドスタートアップにおける新規プロダクトの0→1開発 (株式会社LayerX 高江さん)

https://x.com/shnjtk/status/1767907558097076692?s=20
クレジットカードの取り扱い、決済ドメインの複雑な知識が必要だし、高いサービス品質も求められそうで、とても難易度が高そう。(様々な例外パターンをどう取り扱うか、想像しただけでツラそう!)

コンパウンドでプロダクト展開することによるデータ設計の重要性についてのお話もあった。チームが異なるプロダクトでデータ定義の秩序をもたせるために、すごく綿密に考えたみたい。メンテナンスに簡単に入れられないから、ほいほいデータ構造も変えられないということで、ドメインエキスパートと議論をつくしたというのもすごく見習いたい話でした。

ドメインが複雑だから、知識をどうチームで引き継いでいくのかも難しいというのはなるほど〜〜〜となった。「ここの仕様なんでこうなってるんだ!?」に答えられる人がいないことほど悲しいことはないよね…。

新規プロダクトの仮説検証ループをすばやく回し続けるためのプロダクトエンジニアリング (株式会社カケハシ 椎葉さん)

https://x.com/bufferings/status/1767896346684776698?s=20
新プロダクトを立ち上げるため、仮説検証を繰り返しているお話!

PdMが薬局訪問して翌日に仮説をチケット化、さらにそれを当日〜数日以内にリリース、くらいのスピード感を持ってやっておられる。すごく楽しそう!

高いスピードを実現するための技術的な取り組みは目からウロコでした。フルTypeScriptのモノレポ、FeatureFlagを活用したトランクベース開発、モブプロやペアプロの実践、ロギングやメトリクスの収集などなど。。

仮説検証フェーズで不確定要素が多いので戦術的DDDは不採用というのも納得感あった。(DDD詳しくはないんですが。。)こういう仮説検証を最速で回すための技術的な取り組みって、強い目的意識を持ったエンジニアリングって感じがして良い。お話を直接聞けなかったんですが、モブプロやペアプロはどうやってうまく回しているのかな。。。XP復習しないと、となった。

雑感

プロダクトエンジニアというワーディングが結構すきなんですが、別に今に始まったロールじゃないよねというツッコミもたしかにありますよね。事業の話が前段にあったうえで技術的なアレヤコレヤが議論されているのがすごく良いなと思ってしまうのですが、確かにフェーズやチーム規模、会社の環境によって、別に普通にエンジニアに求められる動きだよねと言ってしまえばそれまでかもしれない。
でも バックエンドエンジニア フロントエンドエンジニア iOS/Androidエンジニア フルスタックエンジニア など技術領域で区切った呼称がしっくりこない環境があるんだよな〜〜という気持ちで、プロダクト開発(事業)全般を技術を強みにリードする人 を一発で呼称できる プロダクトエンジニア という言葉が便利って感じなのかな。(最近は フルサイクルエンジニア みたいな単語もあるみたいで、意味合いは近そう)
あと、もちろん技術領域に得意不得意があるのは当然で、「全部できないとプロダクトエンジニアじゃありません!」って話でもないと思っています。プロダクト・ユーザー志向を持ちながら、開発では自分の強みを活かせれば良きですよね。(だから例えば技術的にはジュニアだからまだプロダクトエンジニアじゃないよね、という話でも無いと思っています)

あとは、開発生産性を高める、というキーワードが結構多く出るな〜と思った。フルTypeScriptの技術選定もやっぱり最近結構増えている気がする!?
自社でも、フルTypeScript & モノレポ & (なんちゃって)トランクベース で開発を進めているけど、今のところとても納得感のある構成なんだよな。メンバーが増えたりチームが増えたりプロダクトが増えたりしたときにどういう影響が出てくるのかはまだ見えていないので、このあたり知見が貯まると良いな〜。

Discussion