Product Engineering Conference 2026 #PdEConf 師匠と弟子が「現場」で戦う —フルリモート時代のプロダクトエンジニア JEDI育成プログラムの全貌 稲葉 達也 @GotoIdealJack 

マインドや考え抜く力の育成についてお話をします 本や勉強会、 AIでも渡せるもの 技術スキル (言語・設計知識) プロセス (進め方) マネジメント 01 何を育てたかったのか 02 前日譚1つ前の育成企画 （しくじり先生的な） 現場での経験や先輩の背中を見て獲得していくもの  マインド面  考え抜く力 (発想力・網羅力 ) 03 本日のメイン : JEDIプログラム Copyright hacomono Inc. All Rights Reserved. 2 

こんな経験はありませんか？ 01 02 03 意気込んで 数ヶ月後、 期末、 キックオフ 進めてはみたもの の、なかなか成果が でない。 成果ゼロで 終わる Copyright hacomono Inc. All Rights Reserved. 3 

わたしももちろんやりました 期間 対象メンバー アウトプット 6ヶ月 5名 0件 育成は「特別な場」を作るほど、上手く行かないのかも Copyright hacomono Inc. All Rights Reserved. 4 

自己紹介 稲葉 達也 イナバ タツヤ / @GotoIdealJack 株式会社 hacomono Engineering Manager → Product Lead Engineer → Product Lead Engineer / Engineering Manager 経歴 • 株式会社ワークスアプリケーションズ (2009〜2017) ワークフロー製品や人事評価、海外オンボーディング、SCM製品の開発 • 株式会社コドモン (2017〜2022) 幼保施設のBtoBtoC製品の開発 • 家族: 3人の子どもの父 • 趣味: Disney / MCU / hottoys / 本の電子書籍化 • 人生の推し: Johnny Depp • 株式会社 hacomono (2022〜) 2024年7月よりEMからプロダクトリードエンジニアに就任。設計アドバイス、啓蒙、コア開発に従事。2026年 7月からEM兼プロダクトリードエンジニアに。 Copyright hacomono Inc. All Rights Reserved. 5 

No content

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

hacomonoとは 13,000店舗・施設以上での導入実績 8 

No content

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

プロダクトエンジニアに求めるスキル 📖ドメイン知識 🧩設計力・課題解決力 🤝コミュニケーション能力 ステークホルダー・業務フロー エッジケースを理解し、改善ポイン トを把握しているか 課題の背景を捉え、開発の要否、 拡張性・汎用性を考慮した設計、 落とし所を作れるか ステークホルダーとのコミュニケー ション、相手や場に合わせた最適 な伝え方ができるか 🎨UI/UX 💻エンジニアリングスキル ユーザー体験を軸に設計ができ るか、そのための UI デザインが できるか 領域ではなくイシューを一気通貫 で担当し、プロダクト開発に取り組 めるか Copyright hacomono Inc. All Rights Reserved. 11 

hacomono の“プロダクトエンジニア ”の生態 プロダクトエンジニアを構成するマインドと生態 好奇心 Why思考 仮説思考 熱量の 高さ 素直さ 期待値を 超える Copyright hacomono Inc. All Rights Reserved. 12 

何を育てたかったのか 

認知はできた。次は育成 これまで ｜ 認知・浸透 Next ｜ 力の底上げ →育成 定義・マインドは浸透 次なる挑戦は「全体の底上げ」 2023年末に定義を策定してから1年半、様々な施策の実施 を通じて、プロダクトエンジニアとしてのマインドや定義を組 織に浸透させることに成功しました。 浸透の次フェーズとして、組織全体の「底上げ」へ。特に以下 の2つの観点での育成にフォーカスします。 ● プロダクトづくり勉強会の開催 好奇心 / Why思考 / 素直さ / 熱量の高さ / 期待値を超える ● 成果発表会（自慢大会）の実施 2. 考え抜く力の底上げ ● 360°フィードバック 1. マインド面の強化 発想力・網羅力の向上 ● 設計書テンプレートの活用 ● 外部登壇 フルリモート × マルチプロダクト 組織環境：日本全国から参画 / プロダクト開発エンジニア 約30名〜 Copyright hacomono Inc. All Rights Reserved. 14 

なぜ、マインド面？考え抜く力？ 答1 よりスピーディーに、より正確にプロダクトを送り出す力に直結する マインド面の強化 期待される成長と変化 課題解決力 / 越境力 / 推進力がパワーアップする メンバー： 自分で考えたものを形にする楽しみ・責任感・オーナーシッ プの向上（= どの企業でも最前線で活躍できる力） ↓ チーム： プロダクトをより良くするためにみんなで考える雰囲気の醸成 と開発スピードの向上 考え抜く力の底上げ 期待値を超える発想力・あらゆるパターンを想定した 網羅力が身につく ↓ プロダクト： 期待を超える機能が継続的にリリース ↓ 部：自ら発案した機能が出る文化 答2 AI時代、実装が速くなるほど、これらのスキルの（まだ）価値は上がる Copyright hacomono Inc. All Rights Reserved. 15 

前日譚:1つ前の育成企画 （しくじり先生的な） 

プロダクトリードエンジニア成長支援プログラム （通称: BootCamp, 2025） テーマ: とことん自分の頭で考え抜く プログラム概要 運用ルール 要望リストから自ら機能を選び、PRD作成からリリースまで単身で 推進する成長プログラム（他タスクと並行） ● 期間・体制: 1期（6ヶ月）/ 基本は1人で設計・実装 ● 他タスク並行: スキマ時間を活用し他業務を言い訳にしない 対象者 ● レビュー基準: 妥協のないレビュー（なぁなぁにしない） ● 進め方: セルフマネジメント。負荷が高すぎればSTOP ● 評価: 完遂できたら加点。完遂できなくても、評価に影響なし ・リーダー 5名 他メンバーへPdEを啓蒙・育成できる方 ・レビュワー 4名 行動指針 安易に答えを求めず、自ら考え抜いた仮説を提示して議論に臨む。あら ゆる可能性を考慮して主体的に動く。 Copyright hacomono Inc. All Rights Reserved. 17 

プロダクトリードエンジニア成長支援プログラム （通称: BootCamp, 2025） 成長を遂げる5つのステップ 01 STEP 1 選定 要望リストから自ら開発したい機能を選定。 PdM事前承認の上共有。 02 03 育成する「側」のポリシー 教え方のスタンス ① レビュワーは「何を教えて / 何を教えないか」 を意識して臨む STEP 2 企画・設計 PRD（要件定義書）作成。期待を超える「Wow要素」を盛り込み、ビジネス側ヒアリング、 PdMレビュー等を経る。 プロフェッショナル意識 ② レビューは対お客様想定 。社内向けになぁなぁでやらない STEP 3 開発 通常タスクと並行しながら単身で実装。必要に応じた中間レビューを挟み、リリース判定 レビューへ。 自立支援 04 STEP 4 テスト 05 STEP 5 リリース・効果測定 テストケースを自ら作成しQAにレビューを依頼。単体テストを含む検証を自分で実施し 結果をドキュメント化。 リリースノートを作成（ライター確認必須）、本番リリース。適用後は利用実態の調査まで レポートとして完了。 ③ 進捗にはほぼ関与しない 。自分で考えて着地させる力を身につけてほ しいため セーフティネット ④ 負荷が高すぎればSTOP。リリースできなくても減点はしない Copyright hacomono Inc. All Rights Reserved. 18 

結果は... リリース 0 未着手 3名 案件設定 1名 PRD作成に着手 1名 STEP1完了 0名 設計レビュー通過 0名 実装以降 0名 件 Copyright hacomono Inc. All Rights Reserved. 19 

何が起きていたのか、 誰も途中で「無理です」とは言わなかった キックオフ時の期待 しかし、 みんな企画を前のめりに受け取ってくれ た。 「今の案件が終わったら着手します」 やる気も十分に出してくれていた。 期中の内心： 信じる 半分 / そうだよね忙しいよね 半分 Copyright hacomono Inc. All Rights Reserved. 20 

振り返り 企画 実際に起きたこと（現実・課題） 「6ヶ月間で進める、レビューは 5回」  フィードバックまで遠すぎて熱量が続かない 「他タスクと併用」「スキマ時間で行う」  スキマ時間を捻出する熱量まで用意はできなかった。 「設計・実装は 1人で行う」  詰まったときの前進が本人の可処分時間だけに依存 「PRDからリリースまで全工程」  直列設計。 1つ詰まると全部止まる／中間の達成がない 「レビューは対お客様想定でなぁなぁでやらない」  準備コストが高く、レビューを設定する行為自体が重い 「リリースできなくても減点はしない」  安全設計だが、やらないコストも 0になった 対象＝各グループのリーダー 5名  一番忙しい層を選んでいた ※基準は正しかった。 “重い関門 ”にしたことが問題 Copyright hacomono Inc. All Rights Reserved. 21 

本日のメイン : JEDIプログラム 

失敗から得た 3つの改定 改定 01 改定 03 改定 02 業務外に場を作る 6ヶ月の長期 ▼ ▼ 通常業務を教材にする 短期集中 JEDI / 師匠 ある種の領域を極めた人を目指す 1対1で集中伝承 関与しない（自走） ▼ 伴走する 答えは渡さないが、関与する PADAWAN / 弟子 実務を材料に師匠と共に考え、成長を目指す Copyright hacomono Inc. All Rights Reserved. 23 

プロダクトエンジニア JEDI プログラム （2026） テーマ: 一緒に考え抜く プログラム概要 運用ルール 師匠と弟子がペアを組み、弟子が普段関わっている実際の 開発タスクをそのまま材料に、約2ヶ月・週1回30分の1on1 で壁打ちする。 ● 期間・体制 : 2ヶ月 ● 材料: プロダクト設計 / コード設計・書き方 ● 進め方: 基本1週間に1回の1on1形式30分） 対象者 ● 評価: 特に加味しない ● 弟子: 挙手制（現時点で9名、15回参加） ● 師匠 4名 Copyright hacomono Inc. All Rights Reserved. 24 

前年度との対比 比較項目 成長支援プログラム 2025 JEDI プログラム 2026 期間 6ヶ月 約2ヶ月 （短期集中） 材料 要望リストから選ぶ新規案件 普段の実際の開発タスクそのまま 位置づけ 業務外・スキマ時間 業務内・地続き 体制 単身 ＋ 要所レビュー 師匠と 1 対 1 接点 都度設定のレビュー（全 5回） 週1回・30分の 1on1 （平均8回） ゴール 機能のリリース 考え方の伝承 対象 選出された 5名（リーダー） 手を挙げた 9名 Copyright hacomono Inc. All Rights Reserved. 25 

伝承する内容によって 2つのコースを設置 ① テクニカル・マスター ② プロダクト・マスター コード設計・実装 機能設計・プロダクト思考 ● 中長期で運用保守しやすいコード設計 ● 機能の考え方・設計の仕方 ● ドメインを意識したクラス設計 ● 業務を点ではなく、線で見る考え方 ● パフォーマンスを意識した実装 ● 想定外を、想定内にしておく考え方 ● 障害・データ欠損を前提にした堅牢な設計（冪等性・復 旧経路） ● PRDからどう自分なりの機能を広げるか 期が短いので、弟子は期ごとに師匠を変えられる （リピート4名は全員2回目の参加で別の師匠へ） Copyright hacomono Inc. All Rights Reserved. 26 

具体的な進め方 ① 弟子から説明・方針 ● 「何が課題か把握できているか」 ● 「どう解決しているか」 ● 「我が事化（オーナーシップ）して、取り組んでいるか」 ② 問いかけ、 一緒に考えながら考え抜くマインド・実践的な発想方法の伝承 1. 誰のために作るか 2. 網羅性を高める 3. 広げる ● 解決対象の焦点を絞りすぎていないか ● ビジネス観点が入っているか ● 準備 / 運用 / 確認 フェーズの業務内容 が把握・想像できているか ● この機能をリリースしたときに次に起こる面倒く さいポイントは何か？それを解決するには？ ● 我々（運用保守面）もハッピーな状態に なっているか？ ● イレギュラーパターンを出し尽くし、復旧・ 予防策は考えられているか？ ● この業務の前後の工程がより楽になるために 連携部分でできることはないか？ ● 徹底的に面倒くさがってみる Copyright hacomono Inc. All Rights Reserved. 27 

今のところ順調！ 第1期 2026年23月)  完走 第2期 2026年45月)  完走 第3期 2026年67月)  完走 第4期 2026年89月)  実施中 累計の参加実績 9 15 名が 回 参加完走 Copyright hacomono Inc. All Rights Reserved. 28 

弟子たちの声（プロダクト編） 渡したこと 返ってきた言葉 お客さまの前で説明して納得してもらえるか ・「顧客に自分の言葉で説明できるくらいまで 理解していないといけない。その機能は何のために存在していて、何の業務を どう良くするためのものなのかを考えぬく」 ・「顧客の前でなんでこの仕様にしたのかを説明できるレベルまで 自分の中で整理できる状態にする」 徹底的に面倒くさがる ・「徹底的に面倒臭がる。自分だったらこれが面倒くさいとかを考え抜く 」 ・「特に印象深いのは不便さの追求 。どんなに小さな機能改修でも立ち返って、何が不便かな、何が面倒かなというのを考え るようにします」 担当領域の外に好奇心を持つ ・「好奇心を持って、 自分の担当外の設計やフローのキャッチアップの必要性を強く感じた」 ・「担当領域に限らず、その前後で顧客が感じているペイン を考えて、自分の担当領域で何ができるかを考える」 開発者目線から離れる ・「実装が面倒・大変だからこちらの方がいいのでは、という開発者目線から、ユーザーの体験としてどうあるべきかという 視点にする 」 一般的なシーンに重ねて考える ・「比較対象として、世間一般に広く周知されているアプリケーションを参考にする 。ユーザーは、一般的に実装されている 機能は当然できるはずだという視点で評価する」 風呂敷の広げ方（と、仕舞い方） 将来の機能実装案も考えておく ・「広げるだけだと本筋の設計が終わらなくなる。広げる→仕舞う→広げる→仕舞うを繰り返す ことで、色々な可能性に対応 できる」 イレギュラー時のリカバリー ・「想定しておけば、起きたときも『そのケースは想定済なので、こうすれば解消できます』と案内できる」 ・「実装案は複数案用意して、だめだったときのリカバリー案も考えておく 」 中長期の運用で苦痛が出ないか ・「不要な設定はできるだけ設けない。 開発負債のことも考える」 ・「実装しないことになっても、設計段階で考えを広げておく ことは大切。後々の拡張にも対応しやすくなる」 Copyright hacomono Inc. All Rights Reserved. 29 

弟子たちの声（テクニカル編） 渡したこと 返ってきた言葉 「動く」と「運用できる」は別物 ・「レビューでは『いまの仕様で動くか』だけでなく、境界（権限・スコープ）が正しく切れているか 『スケールしたときに壊れな いか』を見る視点がついた」 似て見えるコードの裏側を疑う ・「発行されるSQLが遅延評価か即時評価か を意識しないと差に気づけない。本番でデータが増えてから遅さが顕在化す る」 守りたい制約は DBに寄せる ・「二重請求・請求漏れを防ぐのに、GENERATED COLUMN でユニーク制約 を張るという知見が得られた」 必ず落ちる・欠損する前提で設計する ・「冪等性が求められるシステムでは Hot&Warm の二段構え にする。単一の経路に依存せずデータの完全性を追求する」 命名は妥協しない ・「コンテキストと操作を意識し、適切な名前をつける。そのために語彙を増やす 」 ・「命名も含め、自身が100%納得するまで考え抜く 」 まず理想形を描き、そこから逆引きする ・「技術的な制約や自社プロダクトの都合は一旦完全に無視して 理想形を作り上げる。その理想から必要な技術や仕様を逆 引きしていく」 ★ 手を動かして仕組みを理解する ・「Net::HTTP を使って HTTP クライアントを作ってみると良いと話をいただき、プライベートで fincode の Ruby SDK を 作ってみて学習中 」 Copyright hacomono Inc. All Rights Reserved. 30 

次なる一手 【現在】 挙手制 （弟子9名 / 延べ15回 / 第4期実施中） A案：全員へ広げる B案：挙手制のまま深める PdE全員が受ける標準プログラムにする 手を挙げた人の 2周目・3周目に時間を割く 💡 社内議論： 「熱量がある人にもっと時間を割くべきでは？」という議論が起きている 引き続き、ブラッシュアップしていきます Copyright hacomono Inc. All Rights Reserved. 31 

まとめ: 4つのお持ち帰り 01 成長機会の「後回し」を防ぐアンチパターン 「業務外」「長期」「不介入」の 3点セット 02 負荷を上げずに継続できる仕組み 通常業務を教材に、週 130分2ヶ月、少人数制 03 顧客価値へ視点を向けさせる手法 答えを教えず、問いを渡して、一緒に考える 04 AI時代だからこそ、考え抜くマインド・実践的な発想方法の伝承の緊急度が上がっている 実装が速くなるほど差がつくのは顧客価値を考え抜いた深さ。そしてそれは（まだ）現場でしか渡せない Copyright hacomono Inc. All Rights Reserved. 32 

May the Force be with you！ We're hiring! Appendix! 「プロダクトエンジニア」という役割を定義しましたという お話 プロダクトエンジニアとしての観点を詰め込んだ開発設 計書のテンプレートを公開します プロダクトエンジニア 360° フィードバックを実施しまし た エンジニアの育成プログラム「プロダクトエンジニア JEDIプログラム」を紹介します 他のポジションも 募集しております 🙏