はてなブックマーク新着レポート

AIで実装は速くなった。なのにプロダクトは速くならない。職能の壁を越えて価値のフローを設計する

Speaker Deck（nwiizo氏・Product Engineering Conference 2026 発表、2026/09/05・30分）

この発表は何を解決するのか

「AIでPull Requestは増え、手を動かす速さも上がった。それなのに、価値が届くまでの時間や成果は変わっていない」 — この「速くなった実感」と「届いた価値」が噛み合わない問題を、数値・フレームワーク・具体的手法で解きほぐす発表です。

• なぜ実装が速くなってもプロダクト全体は速くならないのかを価値が届くまでの流れ（バリューストリーム）の測定で説明
• 全体の速さを決める「詰まり（制約）」の見つけ方を習得できる
• ユーザーの目的・失敗の見つけやすさ・利用状況から「作る・任せる・やめる」を決める基準が持ち帰れる

登壇者の nwiizo 氏は株式会社スリーシェイクのソフトウェアエンジニア。単著『おい、とりあえず終わらせろ』、翻訳書『アーキテクチャモダナイゼーション』『セキュアAPI』『実践 プラットフォームエンジニアリング』などでも知られる人物です。

1. 増えた生産量はどこに消えたのか

AIで速くなった「実感」と「結果」は分けて確かめる

DORAの2025年調査では、世界の技術職約5,000人のうち90%が仕事でAIを使い、80%以上が生産性向上を実感。同時に、AIをよく使う組織ほど一定期間にユーザーへ届けた変更件数が多く成果も高い傾向がある一方で、変更による障害や手戻りも増えていました。DORAの2026年レポートも「コーディングが速くなるだけではROIにつながらない」と指摘しています。

価値の基準は「ユーザーのジョブ」に置く

ジョブ理論（Jobs to Be Done）でいう「ジョブ」とは、ユーザーがある状況で片付けたいこと。ジョブは機能名ではありません。価値が届くのは実装が終わったときではなく、ユーザーのジョブが片付いたときです。

アウトプット	検索条件を実装し、本番で利用できる状態にしたこと（作って出したもの）
利用	対象のユーザーが商品を探すときに実際に使ったこと
アウトカム	必要な情報へ早くたどり着き、購入を判断できたこと（利用後に生じた変化）

利用回数はアウトプットとアウトカムをつなぐ手がかりですが、それだけでは判断できません。プロダクトの速さは、機能を出すまでではなく「結果を確かめるまで」で見る必要があります。

実作業30%・待ち70%の例え話

チケット着手から本番反映までを「実作業30%・待ち70%」と置くと、AIで実作業を半分（30→15）にしても、全体の短縮はわずか15%。待ちの70（判断待ち・レビュー待ち・他チーム待ち）が残るからです。

• 内側のループ：設計→コード→手元テストの繰り返し。AIで短くしやすい。
• 外側のループ：優先順位→レビュー→統合→リリース。役割をまたぐ判断・調整があり、待ちが生まれやすい。AIで内側が速くなっても、外側が一日に受け入れられる件数は自動では増えない。

2. バリューストリームマッピングで「詰まり」を見つける

測り方

1. 直近10件程度の案件（未完了含む）を時系列に並べる
2. ジョブ確認→着手→PR→承認→本番反映→利用開始→結果確認の区間に分ける
3. 記録から「実際に進めた時間」と「止まっていた時間（誰の・どんな判断待ちか）」を分けて拾う。不明な時間は不明として残す

例：着手から本番反映まで20時間のうち、実作業6時間（実装5時間＋レビュー確認1時間）、待ち14時間（レビュー開始待ち10時間＋本番反映判断待ち4時間）。この場合の実作業率は30%です。

待ちが生まれる3つの依存

仕組みへの依存	別システムや接続先の変更を待つ → 接点を安定させ、別々に変更できるようにする
人の知識への依存	特定の人に聞くまで判断できない → 判断の根拠と手順を共有する
順番への依存	先の確認・承認が終わるまで進めない → 同時に進めるか、確認条件を明示する

制約理論：全体の速さを決める工程から直す

各工程には1日に処理できる量があります。AI支援で1日10件のPRを作っても、レビューが1日5件しか進まなければ、未確認のPRが毎日5件ずつ積み上がり、着手から利用可能までの時間はむしろ長くなります。この「全体の速さを決めている工程」が制約です。

レビュー待ちの解消は、詰まる理由に合わせて変えます：

• 確認する時間がない → 新規着手を絞ってレビュー時間を確保。担当者への依頼集中も確認
• 差分の意図が読めない → 変更を目的ごとに分け、判断理由とテスト結果を添える
• 何を正解とするか未決定 → コードを読む前に期待する動作と決める人を確定。判断待ちをレビュアーの遅さにしない

なお、制約が実装側にある現場では、AIで実装を速めると全体も速くなります。「どこが制約か」をまず測ることが、AIの使い所を決めるということです。

3. 独立したバリューストリームの4条件

制約が判断や引き継ぎにあるなら、チームが発見から結果確認まで大きな待ちなしで進められるかを見直します（出典：Nick Tune, Jean-Georges Perrin『Architecture Modernization』）。

① 事業の仕事に合わせて担当範囲を決める	どのジョブを扱うかが明確な範囲へ集中する
② チームが判断できる	合意した予算・品質・権限の範囲で何をいつ届けるか決められる
③ 利用後の変化から作るものを決める	届けた結果（アウトカム）まで同じチームが確かめる
④ ソフトウェアを分ける	他システムを同時に変えなくても開発・テスト・リリースできる

①③が「何を担うか」、②④が「どう進めるか」を決めます。分割の単位はファイル数やサービス数ではなく、一緒に変更しなくて済む範囲で考えます。分割や全面刷新そのものを目的にしないこと。

4. 作る・任せる・やめる

まとめ

• 実装を速めても待ちは残る：30/70の例では実作業を半分にしても全体は15%しか縮まない。アウトプットの増加だけではアウトカムの変化は分からない。
• 見る範囲を「実装」から「ユーザーの結果」まで広げると、次に何を速くすべきかが見えてくる。
• 役割ごとの前提を図と対話で確かめ、チームで「作る・任せる・やめる」を決める。