Slide 1

Slide 1 text

© SmartHR, Inc. 速く作れるかではなく、 速く学べるか ― 学習ループを回すパイロットの途中報告 ⻑⽥ 翔 SmartHR 技術統括本部 アジャイルコーチ 2026/4/28 Product Management Summit

Slide 2

Slide 2 text

⻑⽥ 翔(SmartHR アジャイルコーチ) スピーカー紹介 AI時代の開発⽣産性向上をテーマに、 意思決定と学習のプロセス設計に取り組み中。 開発プロセスや組織‧チーム設計を通じて、 プロダクト開発の現場が意図して "価値" に 向き合い続けられる状態をつくることに関⼼がある。

Slide 3

Slide 3 text

リリースしたけど 「それは効いたのか?」が 分からないまま次に進む 3 「価値を出せたと感じるのが難しい。成功体験が積み上がらない」 ー 社内ヒアリングより

Slide 4

Slide 4 text

AIで「作る速さ」は上がった しかし「学ぶ速さ」は⾃動的には上がらない 4  → 判断と学習の速度がボトルネックになる

Slide 5

Slide 5 text

2チーム並⾏ | 8週間 | 既存プロセスの変更なし 5  軽量な「型」を⼊れることで  観測→判断更新のサイクルが  チームで回るようになるか? パイロットの問い

Slide 6

Slide 6 text

追加した型は2つのみ 6 ① Learningレビュー―場 週1回 / PM + エンジニア 今週得た証拠  ↓ 意思決定の更新  ↓ 次に取りに⾏く証拠 ② Decision Log―記録の型 4項⽬で記録 Decision / Context / Hypothesis / Next Observation 核⼼: 「次に何を観測するか」を リリース前に決める

Slide 7

Slide 7 text

7 Decision Log(テンプレートの⼀部抜粋)

Slide 8

Slide 8 text

型が最初に効いたのは 狙っていた「リリース後」ではなく 「企画からリリースまでの過程」だった 8 リリース後の検証はこれから

Slide 9

Slide 9 text

9  チームA PM  「意思決定⾃体は変わらなかったと思う。   でも、この規模の案件で観測条件を明⽂化することは   なかったかもしれない」 「この型がなかったとしたら何か違っていたか?」  チームB エンジニア  「認識のズレを揃える場がなかったら困っていた。   Slackでの都度確認が発⽣していたはず。」

Slide 10

Slide 10 text

10  ① 情報の⾮対称性の解消    PM ↔ エンジニア間で判断の前提が揃う 型の付加価値は3つに整理できる  ③ 事前の判断設計    分岐条件や評価基準をリリース前に設計する機会が⽣まれる  ② 事前の⾔語化    暗黙の判断が記録として残る

Slide 11

Slide 11 text

11  ① リリース後の観測→判断更新で型が機能するか    当初のボトルネック仮説の検証⾃体がこれから まだ分かっていないこと  ② 型の価値と外部視点の価値をまだ切り分けられていない    チーム外の視点があること⾃体の効果が⽰唆されている

Slide 12

Slide 12 text

「リリース後に何を観測するかを リリース前に決める」 12 たったこれだけで、学習ループの起点が⽣まれる 1つだけ持ち帰っていただくなら