Product Engineer Night #6 稲葉 達也 @GotoIdealJack プロダクトエンジニアを育む hacomonoでの取り組み

2 Copyright hacomono Inc. All Rights Reserved. 稲葉 達也 イナバ タツヤ / @GotoIdealJack 株式会社 hacomono Engineering Manager → Product Lead Engineer 株式会社ワークスアプリケーションズにて、ワークフロー製品や人事評価、オンボー ディング、SCM製品の開発 　↓ 株式会社コドモンにて、幼保施設の BtoBtoC製品の開発 　↓ 2022年に hacomonoジョイン、2024年7月から事業拡大に向けて EMからプロダクト リードエンジニアとして役割を変え、プロダクト全体の設計アドバイスおよびプロダクトエ ンジニア活動の啓蒙、そして自身もコア機能のプロダクト開発に従事 自己紹介

No content

Confidential About 4 会員管理・予約・振替・キャンセル・決済・請求管理・売上管理・債権管理 入退館・EC・POS・本人認証カメラ・QRリーダー ・総合フィットネスクラブ ・ヨガ・ピラティス ・パーソナルジム ・24時間ジム フィットネスクラブ ・屋外運動場 ・屋内運動場 ・体育館 ・水泳プール ・学校 ・レジャー施設 公共運動施設 ・Jリーグ（サッカー） ・Bリーグ（バスケットボール） ・野球チーム・サッカーチーム etc スポーツチーム ・スイミングスクール ・ダンス・バレエスクール ・ゴルフスクール ・テニススクール ・カルチャースクール ・空手・体操スクール ・サッカースクール 運動スクール ウェルネス施設の手続きをすべてデジタル化

5 Copyright hacomono Inc. All Rights Reserved. “プロダクトエンジニア ” とは？ プロダクトの成長を軸に、 オーナーシップを持って追求・越境していくエンジニア と、定義しました 🚀 https://speakerdeck.com/hacomono/urutoraziyanpu-nacheng-chang-wozhi-erupurodakutoenziniatoiukiyaria

プロダクトエンジニアを育む施策

7 Copyright hacomono Inc. All Rights Reserved. プロダクトエンジニアを育む社内の仕組み 設計書テンプレート・ レビュー プロダクトづくり勉強会 成果発表会（自慢大会） OJT 不定期開催

8 Copyright hacomono Inc. All Rights Reserved. プロダクトエンジニアを育む社内の仕組み 設計書テンプレート・ レビュー プロダクトづくり勉強会 成果発表会（自慢大会） OJT 不定期開催

9 Copyright hacomono Inc. All Rights Reserved. なぜ設計書テンプレート？ 💡 ここで言う設計書とは、開発する要件に対してどのように既存の画面に手を加え、また新規にどの ような仕様をプロダクトに注入していくかをまとめたドキュメントになります。 💡 内容だけ聞くと詳細設計書/機能一覧表/開発計画書とも捉えられますが、ここにプロダクトエンジニ アとしての育成観点、ひいてはお客様にしっかりと価値を届けることができるプロダクトを考えるた めの手助けとなる要素を盛り込んでいますので本日はその点を中心に紹介させていただこうと思い ます。 💡 個人的に新卒時代からこのドキュメントを書き続けている＆ブラッシュアップし続けてきたこともあ り、hacomonoジョイン時に即座に導入させていただいた施策でもあります。

10 Copyright hacomono Inc. All Rights Reserved. 設計テンプレートとレビュー運用を紹介 ● Notionで作成しています ● 構成は4つ ○ タイトル ○ 解決したい課題・概要 ○ ユーザーストーリー /機能一覧 ○ 参考資料 / メモ ● プロダクトマネージャーからPRD（要件一覧）を受け取った あとこの設計書を作成し、その後レビューをします ● 書くのはもちろんプロダクトエンジニア。技術専門用語は 大部分で利用せず、誰でもわかる記載を心がけます

11 Copyright hacomono Inc. All Rights Reserved. 聞いていただく上での留意事項 ● 全ての開発案件で導入していません [重要] ○ 不具合修正・小さな改善系は省いたりしています。 ○ チームの状況（担当機能の成長フェーズやメンバー構成）に よって書く書かないの選択をしてもらっています。 ● 各チーム・メンバーでアレンジしてもらっている場合もあ ります ○ この後お話していただく POINTを押さえておいていただけれ ば問題なし👍としています

12 Copyright hacomono Inc. All Rights Reserved. POINT 1: 解決したい課題は何かを明確にすること 💡 ユーザーが解決したい課題を必ず明確にします ● プロダクトエンジニアが解決すべき課題を改めて再認識し、 なぜこの機能が必要なのかをまず理解します。 ● 場合によってはユーザーヒアリングなどで得られた感情など ものそのまま書いたりもします。 ● この後行われるレビューでも、課題に対して議論を集約でき ます。 ● ここで複数の課題が並列され、かつそれぞれの解決策（ =実 装機能）が分かれる場合は、設計資料を分割します。

13 Copyright hacomono Inc. All Rights Reserved. POINT 2: 機能単位ではなくユーザーストーリー単位で書く 💡 業務の流れに沿って、ユーザーストーリーを書き、そこ に実装機能がどう絡んでくるかを書く。 ● 仕様や制限についても明記します。 ● 必要に応じて画面のイメージ図なども追加します。 ● とにかく誰が読んでもわかりやすく。 💡 このタイミングで自分のアイディアを盛り込む。 ● PdMが用意してくれたPRDを「種」として、それを大きく花開 かさせるための要素を考える。そのためにも機能ではなく ユーザーストーリーにフォーカスさせる。 ● 大きな機能ではなく、小さな機能でも OK。工数都合で実装で きなさそうな案であっても、「将来機能」として書く。

14 Copyright hacomono Inc. All Rights Reserved. POINT 3: 準備・運用・確認分析でシーンを分けて考えてもらう 💡 機能を点で考えるのではなく線で考える仕組み ● どのような業務においても「準備」・「運用」・「確認」・「分析」 のフェーズがあると考え項目に落とし込んでいます。 ● これにより業務シーンを「点」で考えるのではなく周辺業務も 鑑みた「線」で考えられるようにしています。 ● システムに置き換えることで新たな面倒くさい箇所が増えて いないかを確認します。 💡 さらに各フェーズでのイレギュラーシーンを考慮 ● 何かあったときのリカバリできるのか。 ● ミスオペレーションしやすい仕様・ UXではないか。 ● 調査をしやすさも考慮したデータ構造やログ出力。

15 Copyright hacomono Inc. All Rights Reserved. POINT 4: レビューは全員で 💡 みんなで様々な視点からブラッシュアップ ● 参加メンバーはプロダクトエンジニア、 PdM、デザイナー、 QA、場合によってはビジネスメンバーも加えて、ユースケー ス毎に議論します。 ● ドキュメントには議事録、 TODO、テスト観点もまとめます。 ● エンジニア視点の実装方針についてもこの段階で相談でき るものはしていきます（ DB構造など） ● 開発に入る前に合意形成をしておくことで、作った後のちゃ ぶ台返しが起こる確率を極力減らします。

16 Copyright hacomono Inc. All Rights Reserved. レビューの場こそ育成・観点共有の場 登場人物は洗い出 せているか 各ユーザーストー リーはつながって いるか ユーザーストー リーに漏れはない か イレギュラーケース にも対応できている か 適度に汎用化はで きているか 本当に課題を解決 できているか 他の機能への影 響がないか 他の機能とのコラボ レーション要素はない か UXは適切か ユーザーの期待値を 超える要素がふくまれ ているか SLCのバランス は適切か ここのパフォーマンスの 影響に気をつけて 受け入れられるか （売れるか） こんな機能があっ ても良さそう！

17 Copyright hacomono Inc. All Rights Reserved. プロダクトづくり力の底上げは別途勉強会を開催

18 Copyright hacomono Inc. All Rights Reserved. POINT 5: 開発しながらドキュメントもアップデート 💡 開発を進めながらも内容を更新 ● 開発中更新された仕様の反映したり ● テスト観点を充足させたり ● 最終的にできた画面や実際に動作が確認できる動画も掲載 します。 💡 最終的に仕様書として社内ナレッジとして継続活用 ● この資料を見てサポートサイトに反映したり ● 営業やCSのみなさんの新規機能のキャッチアップ材料とし たり ● チームにジョインしたメンバーのキャッチアップ材料としても 利用

19 Copyright hacomono Inc. All Rights Reserved. 活用する上で得られた効果・まとめ 💡 テンプレートからスタートすることで設計レベルを一定水準引き上げ、 よりよい機能開発を考える時 間を増やすことができます。 💡 プロダクトエンジニアに考え書いてもらうことで 「オーナーシップ」を持ってもらう ことができます。 💡 レビューに関係者全員を巻き込むことで開発開始前から 越境しやすい関係性を持ってもらう ことが でき、さらにレビューの経験を積み重ねていくことで 解決策案（プロダクト開発案）の発想の幅を広 げていくことができます。 💡 QA視点として、設計段階から入ることで品質保証の意見も早期に取り入れることができ QAのシフ トレフトにも寄与できます。

We're hiring! 他のポジションも 募集しております 🙏