PRODUCT HISTORY CONFERENCE 2024メモ
iwamasa概要
日程：2024/11/30
PRODUCT HISTORY CONFERENCE
iwamasaスタートアップのドメイン課題に立ち向かうアプローチ
IVRy 成田さん プリンシパルエンジニア
MOSH 村井さん CTO
[MOSH]
ヨガのお店を題材とした場合
HPの立ち上げ、予約、顧客管理、決済などそれそれ別のプラットフォームを使う必要があった
→それを1つのプラットフォームで対応できるようにする
ヨガの先生は場所を予約してレッスンする感じだった
→最近はZoomなどでも行うようになり、アーカイブ配信もある
シュガーアートドール？
→砂糖で作ったサンタクロースとか
[IVRy]
電話応答の難しさとは？
→電話自体が「落ちる」ことを想像されない
繋がることが「当たり前」として捉えられる
SaaSのサービスで裏側でAIを使ったり、毎日デプロイも行っているので落ちることはある
安定性と開発生産性の両立はドメイン固有の難しさ
LLMはOpen AIやGoogle Geminiを組み合わせて使っている
→外部のものを使うと常に賢くなっていくのが良い
単純な内容であれば自分たちのモデルでも良い＆安定性が増す
AIを賢くすることでできる限りオペレータに繋がなくて済むようにしたい
既に事業があって、そこにあるデータを使ってどうAIを組み合わせるか？はよく聞く
→IVRyはAIがビジネスに直結する形だからそこに面白さがある
iwamasaプロダクトと組織の成長〜10人規模から300人超〜
ウェルスナビCTO 保科さん
創業期(10人程度)
CEOをトプとして他のメンバーがフラットにいる体制
サービスをゼロから作り上げる
それぞれの分野のプロフェッショナルを集めた少数精鋭
CEOに全ての情報を集めて即断、即決する
スピード感が早い
→逆に人が増えるとCEOに集まりすぎてボトルネックになる
プロダクトマーケットフィット期 25人程度
経理、人事などはスケールさせずにそのまま
マーケ、エンジニア、CSなどをスケールさせる
この辺りからマネージャーを設定してその下に人を集めていく
横にチームが増えると全体の把握をするためのコストが発生する
プロダクトグロース期(100人程度)
プロダクトをグロースするためにフォー活しやすい組織構成に変更
CEO
CFO(管理部)
COO&CTO(プロダクト部門)
技術ベースで組織を分けていた
→採用するときにどのような人が欲しいのか？を募集しやすくなる
チームごとに採用を動かしやすい
マルチプロダクト期(現在) 300人程度
CEO
CFO(管理部)
COO(事業部門)
→さらに事業ごとにグループ構成
CTO(システム部門)
→さらに事業ごとにグループ構成
継続して既存プロダクトのグロースを行う
複数の新規プロダクトを立ち上げ、グロースを行える組織体制を構築
事業部門、システム部門がそれぞれの領域に集中し、事業貢献できるような構成
ここまで来るまでに「あなたはどこにフォーカスすべきなのか？」が明確になっていなかった
横断組織が強すぎるとイノベーションを阻害してしまう
組織構成はいわゆる縦割りであり、部門間の衝突のリスクを抱える
- 良いプロダクトはエンジニアリングだけでは成立しない
- 会社内の全てのチーム、メンバーが噛み合う必要がある
- 組織体制に絶対的な正解がない
- 会社の状況によって理想的な組織体制は異なる
- 形だけ整えてもワークしない
- 組織体制の強みと弱みを理解する
- 戦略に合わせて組織体制を選択する必要がある
- 弱みを理解してこそ、強みを活かせる
- 最後はやっぱり人が大事
- 私1人が頑張ったところで何も生み出せない
- 理想を共有し、目的に向かって進むチームの一人一人こそが主役
iwamasa事業成長を爆速で進めてきたプロダクトエンジニアたちの成功談・失敗談
LayerX VPoE 高橋さん
ニーリーCTO 三宅さん
[LayerX]
ALTERMA - オルタナ
資産運用サービス
16人のチーム
PdM: 1
[Nealle]
Mobility SaaS
月極駐車場のオンライン契約を可能にする
開発組織30名程度
PdM: 3
[LayerX]
管理画面のフロントエンドにSaaSを活用
APIを書くだけの状態にした
→管理画面に割くリソース削減、管理コストの削減
Angularを使っていたことがあったが、フロントの移り変わりが早くて廃れるのも早い。
そうするとその技術を触ってくれる人も少なくなる
オルタナではオフショア、外注の話は上がって来なかった
→QAの領域は依頼しているらしい
「だろう設計」によりデータモデリングが理想から乖離
「一般的な証券システムはこうだろう」という想定でテーブルを初期設計
→実際には「このテーブルのこのカラムは別のテーブルにあるべき」といったことが発生
必要になったタイミングで必要になった設計をすべき
レビューは対象の理解度が高い状態ですべき
エンジニアが要件定義をやることで取扱高アップ！
PdMが1人しかいない体制
PdMは役割と割り切り、エンジニアがドメイン知識をキャッチアップして企画もする方向性に切り替えた
企画リソースが増えたことで1,2日でリリースできる改善施策から成果が出た
企画までエンジニアが行う場合、PdMとの違いは？
→PdMはより専門的な企画を行う
エンジニアが片手間で行えないような大きな企画を行う
法律周りのレビュープロセスが俗人化していて品質が悪化
専門家のレビューが必要な複雑な処理においてレビュープロセスが属人化して品質問題に発展
専門性が低い部分において開発しながら仕様を理解しようとしてしまった
→「どのような開発物」ならレビューを受ける必要があるかを明確にしておく
ウォーターフォール的に仕様が決まっているものは明確にしてから開発すべきだった
[Nealle]
オフショア開発の活用
初期開発はインフラ〜アプリまで全てオフショアで開発
ローンチご、内製とのハイブリット→その後完全内製
CTOはレビューよりもQAみたいな動きを最初に行っていた
コアとなる設計が甘く、今も苦労中
去年1年かけて40%作り直した
後から変更することが大変なことはやる、やらないの判断が重要
エンジニアが周囲を巻き込みながら複雑な要件定義、プロジェクトマネジメント全般を進行した
事業成長が優先であるから機能開発スピード優先は変えない
エンジニアが事業サイドに染み出すカルチャー、プロセスにこだわった
何を作るかはエンジニアが決める
業務をやりながらプロダクトへの高速にフィードバック
必要なものを自ら考え開発するのが一番いいものを早くデリバリーできると信じている
営業の勢いを止めない
やってみて気がつくことも多いので、無駄なものを作らないで済む
企画までエンジニアが行う場合、PdMとの違いは？
エンジニアが事業に染み出すなら、PdMはもっと事業に染み出せ！
→より数値にこだわる、マーケと連携する、ユーザーインタビュ＋営業も一緒にとか
繰り返すことへの投資が遅かった
CI/CDを作るのが遅く、手動対応や深夜メンテを長く続けてしまった
組織が拡大し、エンジニアに対する問い合わせが爆増
→トイルを撲滅する開発を定期的に行う
開発する時間を奪われる＋事業が伸びて組織が拡大→指数関数的に苦しくなっていく
エンジニアリングに費やせている時間を可視化すべき
時間を生み出す施策に投資すべき
Q&A
管理画面はこれ使ったらしい(Nealleさんも同じく) →権限制御、ログ管理なども行ってくれるらしい
プロダクト志向の文化をどう作るか？
- まずは背中を見せる、そのような文化で採用を行う
- Step by Stepで物事を大きくしていく
どのような人材を採用をしているのか？
- LayerXは新卒採用もしている
- 金融経験者が少なく、Webエンジニアのキャリアが多い
- 分からないことがあった時に「まずやってみよう」ができる人
- Nealleはこれから新卒採用していくフェーズ
- 技術は楽しい、進化させることは凄いがその技術を駆使して問題解決する人
- 専門家よりもゼネラリスト、幅広くアプローチできる人