こんにちは。アセンド株式会社でプロダクトエンジニアをしているまっつんです。
Product Engineer Night(以下PdENight)第一回から1ヶ月、今度は応募多数に付き増枠し、結局それ以上の60名も応募していただきました！今回はそのレポートを公開します。
第一回のレポートはこちら👇
NPS(イベントの評価)
恒例のイベントの評価ですが、今回もNPSが高く、平均値9.4でした！
当日の熱気もすごく、Xの投稿をまとめさせていただいたので、そちらもご覧ください。
今回のテーマはDomainへのDeep Dive
3社のスタートアップのプロダクトエンジニアに登壇していただき、プロダクトエンジニアはどうやってドメインの知識を獲得したり、ドメインに入り込んでいくのか？ということについて話していただきました。
- プロダクトエンジニアナイト開催に寄せて
- 薬局組織の内部を探る BIツールを通じたドメイン理解
- エンジニアはどのようにドメインにダイブできるか
- 最初のファンを作り、最初のファンに価値を届けるまで
-
Unconference!(交流会)
- 手作り大量キーマカレーとお酒とともにディスカッション
プロダクトエンジニアナイト開催に寄せて
- プロダクトエンジニアが自信を持って開発できるコミュニティを作りたい
- 参加者や登壇社の方も、今までやってきたことが肯定されたような気持ちになったという意見もちらほら
- 公共性のあるコミュニティにしたいというメッセージ
プロダクトエンジニアについてのnoteも共有
①薬局組織の内部を探る BIツールを通じたドメイン理解
- 薬局向けのSaaS開発や患者さん向けのお薬手帳の開発など
ソフトウェア開発のプロセス毎のドメイン知識
- ソフトウェア開発のプロセスごとにドメイン知識を得る目的が変わる
- 要件定義フェーズ
- 機能・非機能要件を明確にするためにドメインの理解が必要
- 例：目標達成度の通知機能が欲しいという要望に対して、ドメイン知識がないとメールで送ればいい、となるが、ドメイン知識があると、FAX文化があるためFAXが効果的！となる
- 開発フェーズ
- 使いやす機能の開発にもドメイン知識が必要
- 例：文字の大きさ => ユーザーの年齢層が高ければ大きめにしようなど
- 運用フェーズ
- フィードバックの解釈や運用体制の改善のためにドメイン知識が必要
- 例：MySQLのアップデート対応 → ドメイン知識がないと来週やるか、となるが月末にアクセスが増えるというドメイン知識があれば翌月の半ばにしようとなる
どうやって学ぶか
- フェーズ別に手段がある
- おすすめ
- 現場に出てみる
- PdMに定期的に顧客接点を作っておいてもらう
- 失敗を早く検知できる。モック段階や開発途中などにフィードバックをもらえる
- フィードバックを受けて振り返り
- SLOなどのメトリクスについてチーム全員で振り返る
- 簡単に実施できるし、チームビルディングにもなる
- キャッチアップの心得
- すべてのドメイン知識を理解するのは難しい
- 開発の全工程に関わる、周辺の知識を取りに行く
QA
- 現場を見る頻度は？
- そんなに多く出来てないが、US(ユーザーサクセス)留学制度があり、仲の良いお客さんの所に足を運び、新しく入った人には行ってもらう
- デザイナーとエンジニアが対立したという話をもう少し聞きたい(スライド16)
- PDMに対しても意見を数る
- エンジニアがドメインへの理解をしているからそのようなマインドセットになっている
- 最終的な意思決定はUXデザイナーだが、全員が意見していい
②エンジニアはどのようにドメインにダイブできるか
- 入社してから約３ヶ月毎に１機能・１プロダクトを立ち上げてきた
- 三領域の立ち上げ経験をもとに整理
- ドメイン知識の分類
- 開発プロセスでどう知識を使うか
ドメイン知識の分類
座学・現場・ビジョンの3つに分かれる
- 座学知識
- 体系的・形式的な知識
- 法律、法令、運行管理者試験などの資格試験の参考書も読んだ
- 専門家へのヒアリング
- 現場知識
- 顧客の現状, AsIs
- 自プロダクトの利用状況や顧客要望
- セールスやCSに聞いたり競合調査
- ビジョン知識
- 顧客のToBe像
- 経営層、事業責任者と認識を合わせる
プロダクト開発でどうドメイン知識を活かすか
- ダブルダイヤモンド
- 課題特定フェーズ
- 座学知識の重要度が高い
- 相手が何を言っているかを正確に理解するための基礎素養
- ここの解像度が低いとBizを巻き込んで炎上
- 座学知識の重要度が高い
- 仕様策定フェーズ
- 座学知識・ビジョン知識の重要度が高い
- 実現すべきプロダクト像の再構築
- プロダクトの伸び代が決まる
- 座学知識・ビジョン知識の重要度が高い
- 設計開発フェーズ
- 座学知識・ビジョン知識の重要度が高い
- どういう進化をしうるかの仮説があれば最適なアーキテクチャ設計ができる
- 座学知識・ビジョン知識の重要度が高い
- 価値提供フェーズ
- 座学知識・現場知識の重要度が高い
- 新機能により現行の業務がどう変わるのかを知っておくと、移行する際のサポートが変わる
- 座学知識・現場知識の重要度が高い
③最初のファンを作り、最初のファンに価値を届けるまで
- 創業期、CTO(実のお兄さん！)から誘われてJoin
0→1フェーズで大切にしていること
創業期、600人規模の会社になってもある新規事業時も共通
-
ファン化へのこだわり
-
ゴールデンケースにおいて積極的に利用するユーザーをファンユーザーと称す
- 業務で使う、機能が不足しても、機能が増えたら即試してくれる
-
ゴールデンケースにおいて積極的に利用するユーザーをファンユーザーと称す
-
ゴールデンケースはANDPADの社内用語
- 一定の頻度と手間がかかるmustな業務をプロダクトに置き換えて高い費用対効果を感じられる利用ケース
- NOT ファンユーザー
- 一度試しただけで翌日使ってもらえない
- あとで試してみるねで止まってしまう
- ゴールデンケース例：ANDPADでの例
- 施工の写真撮影や写真整理、台帳作成など
ゴールデンケースの解像度を高める
- 開発者であっても「明日派遣されて、該当業務が実行できる」を目指す
- n=1のユーザーを定め、適切な情報取得・質問をしながら足りない解像度を補完し続ける
- エンジニアとしてはゴールデンケースを理解した上で、技術で出来る出来ないなどを考えて優先順位を定める
- 失敗するケース
- ファンユーザーが増えない中開発が進みMVP機能が膨らみ続ける
- 創業期や新規事業でも１・２年ファンユーザーを作ることができず試行錯誤した
- ファンユーザーが増えない中開発が進みMVP機能が膨らみ続ける
- 成功するチームの大事な要素
- ユーザーをゴールデンケースに導くファン化にこだわるコミュニケーションが必要
- このコミュニケーションが起きていない状態ではファン化が出来ず、0->1フェーズを突破できない
Q&A
- 1,2年ファンができないという状況だと「この仮説が間違っているから、この機能を足せばいいのでは？」という誘惑が出ると思うが、どう向き合い乗り越えたか
- よくあった。一例だと、あるタイミングでこれ以上機能増やすのはやめようという意思決定をした
- 機能開発の言い訳をやめて、この期間でファン化にこだわろうというコミュニケーションを行った- ファン化についてのKPIはあるか？
- 0→1は定量より定性面が強いような気がしている
- お客さんが熱狂してる、のような定性面で見ていた
- ファン化についてのKPIはあるか？
交流会
今回の交流会は各卓ファシリテーターになる方をランダムに設定してて、かつ話が出るようにテーマを設定していました。サイコロの目によって共有・話すテーマを一人ずつ変えれました。
１卓しかいれなかったですが、DDDをどう活用しているかや、新しく入ったメンバーにどうやってキャッチアップさせているのかなど白熱した議論ができました！各テーブルも盛り上がっていたように思います。
キーマカレーも最高に美味しかったです。
次回予告
次回は2月に第③回を行う予定です。レポートを書いてくださる方も募集しています！ぜひXなどでご連絡ください！
connpassのグループのフォローをぜひお願いします！
Discussion