エンジニアはどのようにドメインにダイブできるか

2024/01/17 Product Engineer Night #2 〜DomainへのDeep Dive！〜 に登壇した際の資料です。
https://product-engineer.connpass.com/event/305777/

X: https://twitter.com/moeka__c

Transcript

1. 【Product Engineer Night #2】 エンジニアはどのように ドメインにダイブできるか プロダクトエンジニア 松本萌花
2. 2 自己紹介 2 1995年生まれ 山口県出身 2017年4月 新卒でSIer NSSOLに入社 BEエンジニア 美容向けBtoBtoCサービス 2022年5月~ アセンド株式会社 プロダクトエンジニア 物流向け運送管理SaaSを開発 松本 萌花 Matsumoto Moeka プロダクトエンジニア
3. 3 アセンド株式会社の紹介 3 物流業界の価値最大化 Our Mission アセンドが挑む物流の社会課題 中小企業中心で投資余力がなく デジタル化に取り残された運送業界 2030年に物流の供給力は35%不足 日本の経済損失は10兆円 一方で運送事業の市場規模は20兆円 SaaSを起点として事業が成り立ち 十分にユニコーンが狙える業界 TAM 20兆円 SAM 2兆円 2024年問題対策として、 政策パッケージが発表 解く意義の大きい社会課題を持ち エンジニアとして最大限の挑戦と 社会的インパクトを起こすこと ができる 日本で最もデジタル化の 遅れた産業で 最高の業務体験を作る
4. 4 4 運送業特化 All-in-One SaaS を開発 性質の異なるドメインのプロダクトを ３ヶ月に１度のペースでリリース
5. 5 プロダクト開発経歴 5 2022/5 2024/1 現在 2022/8 2023/7 2023/４ 入社 請求管理機能 立ち上げ 3ヶ月 労務管理機能 立ち上げ 4ヶ月 3ヶ月 車両点検管理機能 立ち上げ 新機能 立ち上げ中！ ロール • 新規機能 プロダクトの立ち上げ • 特にドメイン・業務が複雑な領域を 担当させられることが多い 開発体制 • PdM ◦ CPO 森居さん • エンジニア ◦ moeka（プロダクト開発の中心人物） ◦ サポートで CTO
6. 3領域の立ち上げ経験を元に、以下を改めて整理する • ドメイン知識の分類 • プロダクト開発プロセスでドメイン知識をどう活用するか 6 今日お話しすること 6 『ドメインへのディープダイブ』
7. 7 ドメイン知識の分類 7 ビジョン 座学 現場 体系的 形式的な知識 顧客のAsIs プロダクトのToBe 企業ミッション 開発ロードマップ 業界動向 競合情報 顧客要望 現場業務 法律 資格 ドメイン エキスパート Web CS/Sales プロダクト開発に必要な ドメイン知識をマッピングしてみる
8. 座学知識 8 8 フレームワークの公式ドキュメントを読む 顧客の業務ドメインにおける 体系的・形式的な知識 知識の種類 Web開発で例えると • 労基法(厚労省) 改善基準告示(国交省) 双方の労働時間算出ロジックの違い • 法律を直接読んだり、 運送業専門の社労士にヒアリング • 資格試験の参考書 • 法律、法令 • Web上の解説記事 • 専門家にヒアリング 獲得方法 私の事例（どんな知識・獲得方法）
9. 現場知識 9 9 開発フローを把握する Four Keysを見てみる 顧客のAsIs像。 現行業務フロー、商習慣など Web開発で例えると • トラックの車検、法定点検の 実施記録、費用はどの粒度で取得可能か • 車検後に顧客がディーラーから受領する 書類一式をCS経由で入手 • 自プロダクトの利用状況や顧客要望か ら深堀り • セールスやCS(顧客に近い人)に聞く • 競合調査 • 現場ヒアリング (N=1なので注意) 私の事例（どんな知識・獲得方法） 知識の種類 獲得方法
10. ビジョン知識 10 10 最新技術を追う チームの目標や改善について話す 顧客のToBe像。 経営層、事業責任者と認識を合わせる Web開発で例えると • 顧客の顧客（荷主企業）が どのように物流網を構築しようと しているか • 社長から本を紹介 してもらう • 企業ミッション • プロダクト バリュープロポジション • 開発ロードマップ • 業界動向・トレンド 業界紙や論文、ニュース 私の事例（どんな知識・獲得方法） 知識の種類 獲得方法
11. 11 開発フローでのドメイン知識の活用 11 プロダクト開発フロー上で ドメイン知識をどう活用するか
12. 12 ダブルダイヤモンドでプロダクト開発のプロセスを考える 12 課題 特定 仕様 策定 設計 開発 価値 提供 時間の経過 選 択 肢 発 散 収 束 発 散 収 束 Discover Define Develop Deliver 正しい課題を見つける 正しい解決策を見つける
13. 13 課題特定フェーズ 13 座学知識 現場知識 ビジョン知識 • 相手が何を言っているかを正確に理解するために必須。 • 正しい論点や疑問点を出すための基礎素養となる。 • このフェーズで今までの現実への認知を調整する。 • 困難ポイントや論点をどこまで出し切れるかが勝負。 • 課題をフラットに捉えるため、むしろ今までの思想や 「あるべき」を学びなおす姿勢で臨む。 重要度：高 ▪フェーズ定義 顧客がやりたいことや プロダクトが提供したい価値と、 今のプロダクトのギャップと ブロッカー、論点を認知。 目指すアウトカム、ゴールの 認識を合わせる。 ▪思うところ ここの解像度が低かったり、 P Jの途中で忘れ去られると 高確率でBizを巻き込んで炎上す ることになる。
14. 14 仕様策定フェーズ 14 座学知識 現場知識 ビジョン知識 • 前提となる制約条件が頭に入っていることで仮説の精度が 上がり、上手く着地させる武器になる。 • 現場の解像度が高すぎ・要望をそのまま受け取りすぎると 要件が歪んだり局所解になるので注意。一歩引く。 • ここで実現すべきプロダクト像を再構築することになる。 • 「こうしていきたい」の解像度が高ければ高いほど、 大きく描く勇気が出てくる。 ▪フェーズ定義 ソリューションの考案。 課題を解決しつつも、プロダク トの世界観やUXがツギハギにな らないようにToBeを描く。 実現可能性やコストも考慮しつ つスコープや登り方を決定。 ▪思うところ 各々の思惑が錯綜して無限に時間 がかかりがち。 引き出しの多さと同時に、 ここを上手く着地させる手腕が問 われる。 が、このフェーズでプロダクトの 伸びしろが決まるので、 決断のプレッシャーがすごい。 重要度：高 重要度：高
15. 15 設計開発フェーズ 15 座学知識 現場知識 ビジョン知識 ▪フェーズ定義 構想をプロダクトとして実現 させていく段階。 完全にエンジニアに主導権が 渡る。 ▪思うところ 機能を仕上げることに意識が向 きがちだが、やることがHowに 落ちたこの段階でチームが変に 躓く事態に陥らないようにプロ ダクトを守っていくのもエンジ ニアにしかできない大事な仕 事。 中長期的な生産性を保つ内部品 質向上のために、使える知識は 全て使う。 • 「正しい語彙と概念」をもとにしたモデリングの強さ • 「正確な構造でデータを貯める」部分と、「誰がどう使う か」を司る部分を実装上切り分けることで、高い柔軟性を 持ちつつバグが少ない状態を保てる • 気になる気持ちをぐっとこらえて、今の現場ではなく「目 指すアウトカム」と「目指したい世界観」を道しるべに。 • どこがどういう進化をしうるかや現時点での仮説の確度の 高低がわかっていれば、最適なアーキテクチャ設計や 将来に向けた投資判断がしやすい。 重要度：高 重要度：高
16. 16 価値提供フェーズ 16 座学知識 現場知識 ビジョン知識 ▪フェーズ定義 顧客の業務に作った機能を装着 する。 課題が解決できたか、想定して いた価値を出せているかをト ラッキングし、サポートと調整 を行う。 ▪思うところ 顧客への提供価値最大化を成し 遂げるための最後のひと押し。 プロダクトが提案する世界観に 顧客を連れて行くという難関ポ イントで、実力の見せ所。 CSとタッグを組んでやり切る。 • 顧客や社内から想定外の質問や要望が次々出てくる。適切 に重要度や優先度を把握し捌いていくにはやはり必要。 • システムがいまどう使われていて、新機能により現行の業 務フローがどう変わり、違和感なく移行するためにどのよ うなサポートが必要か。 • 「あるべき」しか頭にないとびっくりするほど現場に フィットしないし、心が折れる。 重要度：高 重要度：高
17. 17 フェーズごと 17 課題特定 仕様策定 設発開発 価値提供 座学 ここがないと相手が何 言ってるがまず理解で きない 前提となる制約条件へ の理解。仮説の精度や スピード 正しい概念理解をもと にしたモデリング 要望の重要度や優先 度の判断精度向上 現場 現実の認知、理想まで のブロッカー、困難ポイ ントや論点の把握 現場の解像度が高す ぎると歪むので注意 現場の解像度が高す ぎると歪むので注意 現場がどう違和感なく新機 能に乗っかれるか。システ ムがいまどう使われてい て、現行業務フローにどう 組み込むか ビジョン 今までの思想や「ある べき」を学びなおす姿 勢が大事 実現すべきプロダクト 像の再構築。大きく描 いてポテンシャルを引 き上げる。 将来どこが重要になる か、まだ仮説段階で柔 らかさが必要なとこは どこかを考慮したアー キテクチャ判断 「あるべき」しか頭にな いと驚くほど現場に フィットしない
18. • ドメイン知識は、その性質により「座学」「現場」「ビジョン」に分 類できる • プロダクトの各フェーズごとに重要なドメイン知識は変わる。 • ドメイン知識を戦略的に獲得し、プロダクト開発で正しく利用できる ようになることで、顧客に価値を提供し続けられるプロダクト開発が 実現できるはず。 18 まとめ 18
19. アセンドで共に開発をするプロダクトエンジニアを募集しています！ プロダクト開発ナレッジを発信するイベントを 定期的に開催しています！ メンバー募集！ 19 松本 萌花の 𝕏 (@moeka__c) お気軽にフォローください。 ASCEND ProductFM Product Engineer Night