Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
aiagentandpo.pdf
Search
Yasunobu Kawaguchi
PRO
June 16, 2026
Storyboards
3
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
aiagentandpo.pdf
Yasunobu Kawaguchi
PRO
June 16, 2026
More Decks by Yasunobu Kawaguchi
See All by Yasunobu Kawaguchi
Claude Code x Accounting
kawaguti
PRO
1
360
Every Conversation Counts
kawaguti
PRO
0
380
Why we keep our community?
kawaguti
PRO
1
880
Scrum Fest Morioka 2026
kawaguti
PRO
3
1k
Claude Code for NOT Programming
kawaguti
PRO
2
450
Why Organizations Fail: ノーベル経済学賞「国家はなぜ衰退するのか」から考えるアジャイル組織論
kawaguti
PRO
3
460
Git in Team
kawaguti
PRO
4
690
from Sakichi Toyoda to Agile
kawaguti
PRO
2
260
Agile PBL at New Grads Trainings
kawaguti
PRO
1
1.6k
Other Decks in Storyboards
See All in Storyboards
Panty Vigilante
marcylin0225
0
210
ICE CREAM!!
erikaj543
0
220
Debt To Tadashi
ray2970
0
300
Space Cadet - Storyboard
cassidyhenstock
0
200
Hallway Confrontation
ray2970
0
110
a Fight sequence
nicola404
0
280
Action Scene - Part I
mingyiding
0
330
SOMETHING FORGOTTEN
erikaj543
0
210
The Unfortunates: Ruth & Hamlin's Moment of Peace
takins_2022
0
100
Tsekouri - Opening Montage Storybeats
cooperbucci
0
530
Haruk SC:02
_waste_of_ink_
0
180
借運
gueiji0622
0
110
Featured
See All Featured
Music & Morning Musume
bryan
47
7.2k
Darren the Foodie - Storyboard
khoart
PRO
3
3.4k
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
65
55k
The AI Revolution Will Not Be Monopolized: How open-source beats economies of scale, even for LLMs
inesmontani
PRO
3
3.5k
Dominate Local Search Results - an insider guide to GBP, reviews, and Local SEO
greggifford
PRO
0
190
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
A brief & incomplete history of UX Design for the World Wide Web: 1989–2019
jct
2
390
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
Scaling GitHub
holman
464
140k
Large-scale JavaScript Application Architecture
addyosmani
515
110k
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9.1k
Information Architects: The Missing Link in Design Systems
soysaucechin
0
960
Transcript
AIエージェントが 教えてくれた プロダクトオーナー シップの本質 エンジニアの役割の変化に向き合う Conference 2026 | 2026.6.18 川口
恭伸(YesNoBut株式会社)
川口 恭伸 かわぐち やすのぶ YesNoBut株式会社 代表取締役社長 一般社団法人スクラムギャザリング 東京実行委員会 代表理事 金沢大学経済学部
卒 北陸先端科学技術大学院大学 情報処理研究科 修了 日本証券アナリスト協会 検定会員
新しいプロダクトを、新しい需要を、 作りたい──という人がいます。 この会場にも、きっといらっしゃるでしょう。
https://youtu.be/B34jOZ3r130?si=ju7xb1mHMB3kOf0n Jeff Patton 基調講演(Regional Scrum Gathering Tokyo 2025)より
Jeff Patton による言葉の整理 アウトプット = 利用者が使えるもの アウトカム = 人々がそれを使ってすること 使ってくれる。対価を払ってくれる。
インパクト = その結果、業績が動く ※書籍では「成果」と訳してます Jeff Patton 基調講演(Regional Scrum Gathering Tokyo 2025)より
「アウトカムは、構築したものや品質では 測定されない。それを使って、人々が 何をするかで測定される」 だから、スプリントの終わりには測定できない。 「ビジネスアウトカム」はない。ユーザーアウトカムが、 ビジネスインパクトを駆動する。 成功の先行指標は、アウトカム。 ユーザーが使い続けてくれるか? Jeff Patton
基調講演(Regional Scrum Gathering Tokyo 2025)より
https://youtu.be/B34jOZ3r130?si=ju7xb1mHMB3kOf0n Jeff Patton 基調講演(Regional Scrum Gathering Tokyo 2025)より お金を稼ぎたい ミッション
ビジョン 戦略 ステークホルダ 課題 ニーズ 見つける 使ってみる 使い続ける 価値! 収益↑ コスト↓ 市場価値 機能 性能 要求 アイデア モノ 時間 コスト スコープ 多くの企業が、企画して作って売ることばかり考えがち とユーザー とユーザー アウトカム インパクト 不満 ビジネス ニーズ
Jeff Patton 基調講演(Regional Scrum Gathering Tokyo 2025)より 開発が扱うのはここ スクラムもここ プロダクトは
全体を考える
ゴールは、なかなか満たされない。 満ちるまで、努力を投入し続けることになる。 だから、途中で、 「本当にゴールに向かっているのか」が 分かるようになっていないと、続かない。 Jeff Patton 基調講演(Regional Scrum Gathering
Tokyo 2025)より 利用者にとっての価値 アウトカム 企業にとっての価値 インパクト
データがなくても「進んでいる」と 言い張ることは、できる。 でも、嘘は、自分が苦しくなるだけ。 ヘルシーに、前に進んでいる実感を持って進めたい。 Jeff Patton 基調講演(Regional Scrum Gathering Tokyo
2025)より
だから、最初に言います。 作らない方がいい。 出さないほうがいい。 Jeff Patton 基調講演(Regional Scrum Gathering Tokyo 2025)より
ヒポクラテスの誓い 患者の利益を第一に
よくいただくご依頼: 「ユーザーストーリーマッピングの話を してください」 ユーザーストーリーマッピングはシンプルな仕組みです。 説明するのは、大歓迎ですが…。
でも、ご依頼の背景は、たいてい── 「新規のものを作りたい。うまく整理できない。 どう進めたらいいでしょうか」 それ、ユーザーストーリーマッピングを入れても、 あまり変わりません。 たぶん、圧倒的に、調べが足りない。
「調べが足りない」には、2つの方向があります。 ① ユーザー・対象領域の調査・理解 ② 作り方の調査・理解 ① ユーザー・対象領域 の調査・理解 ② 作り方の調査・理解
ふつうは、作れる状態になってから、 作れそうなものを企画する。 (作れる見込みがないと約束できない) しかし、多くの場合は逆──作りたいものを考えてから、 作り方を考える。 絵の描き方を知らないまま「宮崎駿を超えるヒットを」 というのに、ちょっと似ているでおじゃる。 それに、あなたの人生の時間を投資しますか? ① ユーザー・対象領域
の調査・理解 ② 作り方の調査・理解
「絵が描けないから、描ける人に頼もう」は、 もっとひどい。 うまくいくか分からないものを、 お金を払って、作ってもらう。 売れないものを「とにかく作ってください」 と受託開発を回す。 みんなが、不幸になる。 やらない人のノブレスオブリージュ(予算配賦)
「そんなこと言ったら、 何も作れなくなるじゃないか」 ──そう思う人は、たぶん、作らない方がいい。 まだ、作るのは早いかもしれない。 焦らないで! 順を追って話していきます。
2026年2月 2024年12月 まず作り方の方の話 ① ユーザー・対象領域 の調査・理解 ② 作り方の調査・理解
Replit Agent を使ってみた。 AIがWebアプリを 作ってくれるぞ! (うそくさい)
全国のスクフェス を地図表示する アプリを作ってみた
None
2026年2月のあらまし 2025年2月にリリースされた Claude Code を使ってみた。 ソフトウェア開発だけでなく、 フォルダにあるファイルと Webアクセスを使って 事務作業をこなしてくれる。
最近やっていること • 協賛金の入金突合: Pretix 請求書 + マネーフォワード請求書 + 銀行 CSV
を毎 月突合する作業。カタカナ振込名義のずれ、まとめ振込、 PayPal の資金移動、時系列ルールなど、地味だが落とせない 処理を Claude に下書きさせています • 経費精算のルールチェック: 毎月100〜200件の経費明細を、税区分・科目・出張日当・イ ンボイス番号など 10 種類以上の観点で点検する作業。「要修 正/要確認/参考」の 3 階層に自動分類して返ってきます
LLMのありがちな課題 すぐ忘れる さっきまで 優秀だったのに…
でも人間も同じだよね なので… メモを取る ドキュメントを起こす grepする、ググる コードに起こす テストする
Claude Code がやってるのもそれ すぐ忘れる なので… メモを取る ドキュメントを起こす grepする、ググる コードに起こす テストする
その結果のSaaSの死 LLMの能力向上で、 人間がやっているような ライフハックを 実行可能になってきた。 それを実装してる。 …のかも。
使ってみた感じ 優しく原状復帰を繰り返して、 Baby Steps で指示するとよさげ。 手は早いが慎重さに欠ける 新人さんに仕事をお願いしている 感じ。(仕組みの理解は必要)
これはまさにPOの動き プロダクトオーナー(PO)の 練習にもってこいかもしれない。 開発者が理解できる粒度で バックログを提示して、 質問に答えながら、 有限時間内に実装してもらう。
PO スクラム マスター 開発者たち プロダクト オーナー
顧客 PO スクラム マスター 開発者たち プロダクト オーナー
顧客 PO スクラム マスター 開発者たち アウトプット プロダクト オーナー
顧客 PO スクラム マスター 開発者たち アウトプット アウトカム プロダクト オーナー
顧客 PO スクラム マスター 開発者たち アウトプット アウトカム プロダクトオーナー は、各種の要望を 「実現可能な仕様」
に落として、 バックログに積み、 優先順位付けして ROIを高く保つ。 プロダクト オーナー
顧客 PO スクラム マスター 開発者たち アウトプット アウトカム 開発したものは アウトプット、 それを利用して
エンドユーザーが 得られる成果が アウトカム。
顧客 PO スクラム マスター 開発者たち アウトプット アウトカム なるべく少ないアウトプットで、 アウトカムを得たい Jeff
Patton 『ユーザーストーリーマッピング』
顧客 PO スクラム マスター 開発者たち アウトプット アウトカム プロダクト オーナー
AIはツールであり、 人の能力の増幅器です。 増幅される元となる、その人の興味・関心、 情熱や執着、スキル、科学や業務の基礎知識が問われます。
道具が能力を増幅するのは、 初めてではない。
産業革命の進展は紡糸・織機とともに 1733年 飛び杼(ジョン・ケイ) 1764年 ジェニー紡績機(ハーグリーヴス) 1768年 水力紡績機(アークライト) 1779年 ミュール紡績機(クロンプトン) 1785年
力織機(カートライト) 蒸気機関による機械化 1811-16年 ラッダイト運動 1868年 明治維新 https://ja.wikipedia.org/wiki/ラッダイト運動
産業革命の第一の矢「飛び杼」 1733年、ジョン・ケイが発明。 織物生産を飛躍的に向上させ、 産業革命の引き金となった。 https://ja.wikipedia.org/wiki/ジョン・ケイ_(飛び杼)
ラッダイト運動(1811-1816年) 使える人たちに とっての増幅器 は、そうでない ひとにとっての 脅威となった https://ja.wikipedia.org/wiki/ラッダイト運動
豊田佐吉 1867年生まれ。 遠江国・山口村の大工の息子。 (三河吉田藩領、現・静岡県湖西市) 豊田佐吉記念館(静岡県湖西市)
「毎晩、夜なべをして お母さんが機織り仕事を していた…、その仕事を 楽にできないのか」 (豊田章男) https://toyotatimes.jp/spotlights/091.html / 豊田佐吉記念館
山口夜学会で『西国立志編』を輪読していた 佐吉の夜間勉強会。 豊田佐吉記念館の となり、山口観音堂。 山口観音堂(豊田佐吉記念館となり)
『西国立志編』= スマイルズ『自助論』(1859) 産業革命を動かした発明家たちの伝記集。 「天は自ら助くる者を助く」。 明治4年出版、明治の大ベストセラー。 増幅器を生んだ人々の物語を読んだ 青年が、次の増幅器を作った。 https://jinjibuchou.com/自助論
豊田式木製人力織機 (1890) まず、母の仕事を楽にする。 能率を5割高め、 布のむらをなくした。 豊田佐吉記念館
「自働化」── 糸が切れたら、自ら止まる 無停止杼換式自動織機 G型 (1924) へ。 「何が異常か」を 定義できるのは、 領域を知る者だけ。 トヨタ産業技術記念館(名古屋市)
豊田佐吉の開発の信念 「発明は 製作を完全にし、 十分な営業的試験 をしなければ 世に出しては いけない」 トヨタ産業技術記念館
140年後。増幅器はAIになった。 同じ銀行CSVでも── 9イベントの金の流れを知る人にだけ、異常が見える。 問われるものは、変わっていない。
増幅される元は、人によって違う。 認知の特性。興味・関心。執着。 AIは、差を均さない。 差を増幅する。 増幅器だから、何なのか。
ルックバック展(押山清高監督)で気づいたこと アニメ制作者が捉えている世界の解像度は、全然違う。 自分には見えていない線が、監督の脳内には存在する。 培ってきた知識・経験・ふるまいが、 情報が入ってきたときの補助線の引き方 を変える。 だから、徹底的に情報を仕入れる。 劇場アニメ ルックバック展 ―押山清高
線の感情 より
世の中の企画のほとんどは、たぶん、 作られるべきではない。 調べも、経験も、練り込みも足りないまま生まれてくる。 でも、どれがそうかは、作って世に出すまで── 出してすら──分からない。 Jeff Patton 基調講演(Regional Scrum Gathering
Tokyo 2025)より
トライは、必要なもの。 社会という広大な選別の中で、残るものが残る。 でも、「いいトライでしたね」と 葬られるために作る人は、いない。 どうやって生き残るか。 それが、作る人の切実な願い。 劇場アニメ ルックバック展 ―押山清高 線の感情
より
調べるのは、コスパが悪い? 逆です。 作り、リリースした瞬間に生じる 「義務」こそ、最大のコスト。 人生の重要な部分が、そこに取られる。 だから、アイデアのデリバリーには慎重になる。
自律的なチームには どのような情報が 必要なのだろうか? ? 調べるの方の話 ① ユーザー・対象領域 の調査・理解 ② 作り方の調査・理解
ジェフ・パットン Jeff Patton 協調ワークショップを 通じて共通理解を作る。
2011年。初来日が 第一回スクラムギャザリング東京
最も驚いたのは、 付箋を書き出す際の 「スピード」と「量」
60 世界最初のユーザーストー リーマッピングが生まれた時
61
62 ゲーリーから聞き取って 書いたカードで床が埋まった。 そして、それを整理した。
63 利用現場を知らない人には、 この緻密さと情報量を 出すことは難しい。
64 前書き リアルタイムに 議論し、記録し、 付け加えていく
65 前書き
https://www.1101.com/iwata/2007-09-04.html
「オレは、これをいいと思う」って すべてのお客さんを代表するかのように、 思い込みで語るつくり手が多いんですよ。 https://www.1101.com/iwata/2007-09-04.html
本当は「お客さんがこう反応する」 っていう事実があって、 「それはなぜだろう?」 という仮説があって、そこではじめて 「じゃあ、どうすれば、 根っこの問題が解決できるだろう?」 って考えなきゃいけないのに、 「オレはこう思う!」という、 事実と仮説をぐちゃぐちゃに混ぜた意見を 押し通してしまうことが多いんですね。
https://www.1101.com/iwata/2007-09-04.html
つまり、宮本さんというのは 視点を動かすことに長けているんですね。 そのとおりですね。 いままで近くで見てたのを、 突然ものすごく遠くから見てやり直すというか 虫メガネで見ていたかと思うと 地上一万メートルからもう一回見直してみたり https://www.1101.com/iwata/2007-09-04.html
それでも、自分の仮説は 間違っているかもしれない。 残酷ですが、それが現実。 その現実に対応できる自分を、育てる。 I could be wrong.
本田宗一郎 「地面に耳をつける」 https://bikefun.jp/2025/03/05/soichirohonda_nonakajiro/
ハイキュー!! 24巻
ハイキュー!! 24巻 今までずっと ボールだけを追ってた
ハイキュー!! 24巻 今までずっと ボールだけを追ってた でも コートの中には 情報がいっぱいだ
「障子を開けてみよ、 外は広いぞ」 豊田佐吉 豊田佐吉記念館(静岡県湖西市)
スクラムチームは、山を登る登山隊のようなもの。 一番前に、方向を決める人──前が見えている人。 一番後ろに、チーム全体が見える人。 隊列を組めば、必然的にそうなる。
よりうまく登るには、 前に立つにふさわしい人が、前に立つ。 経験がある。情報を持っている。現地を知っている。 そして、「この山を登るんだ」という意思。
全員が前に出る必要は、まったくない。 「お前やれ」と立たせる話でもない。 立つべくして前に立つタイミングが、 人にはある。 煮詰まらないアイデアで 焦って作っても、 うまく前には立てない。 今じゃないほうがいいのかも。
ありがちなのが── 前に立たせて、梯子を外す。 私はこれを「文化祭運営」と呼んでいます。 「次の代に渡すんだ」という意識が強すぎて、 適した人がいなくても、育っていなくても、 とにかく渡して、任せてしまう。
学校なら、毎年卒業するから仕方ない。 でも会社には、十年、二十年いる人もいる。 本当にそれ、やる必要ありますか? ちゃんとサポートして育てる。一緒にやる。 本当は、できるはず。 そんなに簡単に、新しいものは作れないのだから。
https://www.youtube.com/watch?v=ipuwbFanqMY ソシアルの原点は ペアなんです。 俺と君は違うよねと。 (36:45)
おれときみはちがうよね、と。 知的コンバット
83 圧倒的な情報量から 絞り込んだ仮説
VS 圧倒的な情報量から 絞り込んだ仮説 説得のために作る わかりやすい資料 全く異なるスキルセットが必要
圧倒的な情報量につきあえるチーム = 包括的な制度 インクルーシブ
圧倒的な情報量につきあえるチーム = 包括的な制度 インクルーシブ
87 誰かの責任にするのではなく、 ハイキュー!! 8巻
88 利用者の情報を集める。
プロダクトオーナーは、おそらく 「誰にでもできる仕事」ではない。 ここまで徹底的に調べられるの は、一つの特性。 不得意な人がやってはいけない、 のではなく。 得意・不得意を生かしながら、 みんなで作る。
「足りない」と思ったとき、どうするか。 無理に進めない。アイデアは、温存する。 別の人のアイデアから生み出す側に回る ──良いチームメンバーという選択。 チャンスは、何度も巡ってくる。
プロダクトは、一人では作れない。 良い協力者が、まだ得られていないなら── それは、アイデアを温めるタイミング。 調べる。手の中で試す。 人を説得できるところまで、補強する。 巻き込む前の、試行錯誤のタイミング。
「はまる」タイミングは、いずれ来る。 状況とアイデアが、ぱたっとはまる瞬間は、突然訪れる。 それまでは、今あるものの組み合わせ── 小規模なイノベーション、適応開発。 たいてい、その方がユーザーにとってもコスパがいい。
ただし、ここまでで届くのは、 PSF(Problem-Solution Fit)まで。 その先に、PMF(Product-Market Fit) ──市場で顧客をつかみ、レベニューが回るフェーズを目指す。 フィードバックで感触をつかむ。 いきなり爆売れするものを作ろうとすると博打になる。 アウトプットして、アウトカムを確認して、 改善を繰り返す。
その先にインパクトが生まれる…かもしれない。 問題を解決できなければ、顧客はつかめない。
https://youtu.be/B34jOZ3r130?si=ju7xb1mHMB3kOf0n Jeff Patton 基調講演(Regional Scrum Gathering Tokyo 2025)より お金を稼ぎたい ミッション
ビジョン 戦略 ステークホルダ 課題 ニーズ 見つける 使ってみる 使い続ける 価値! 収益↑ コスト↓ 市場価値 機能 性能 要求 アイデア モノ 時間 コスト スコープ 多くの企業が、企画して作って売ることばかり考えがち とユーザー とユーザー アウトカム インパクト 不満 ビジネス ニーズ
それで、どうしたらいいの? ① AIエージェントに、小さな業務を任せてみる 作り方の調べを、繰り返す。作る練習。頭と手の筋トレ。 相手(利用者)よりうまくなる(FDEの必須タスク) ② 作りたくなったら、まず調べる。 作るなら「調べるために作る」 最小のサンプル。常に中途の結果。完成版にこだわらない ③
はまらなければ、作り直す。AI時代はこれが簡単に 機能を足せばいつか使えるものになる、という幻想は捨てる 「いま欲しいものは何か」を、考え直し続ける
「調べが足りない」には、2つの方向があります。 ① ユーザー・対象領域の調査・理解 ② 作り方の調査・理解 ① ユーザー・対象領域 の調査・理解 ② 作り方の調査・理解
97 利用者の情報を集める。
AIで増幅される時代 増幅される元を、育てる。 それは独りではできない。 おれときみはちがうよね、と 知的コンバットを重ねるチームで。
おまけ アジャイルの本質
エクストリームプログラミングの原動力のひとつ は、ビジネスとテクノロジーの間の溝を癒すこと でした。私は、一般的に言われている2つのグ ループが激しく対立し、協力する方法を見つけて も必要なものが得られないという状況を目の当た りにしてきました。つまり、自分には納期を決定 する力があると思っている人が、その力の幻想を 手放そうとしなかったのです。そこにエクスト リーム・プログラミングが登場し、一連の人間関 係とそれを支える儀式、そしてそれらの儀式や人
間関係を支える技術的な慣習を提示しました。そ して、その代償として、締め切りを指示すること ができなくなりました。 (Kent Beck 2021年7月のAgile 2021でのトークより) https://ja.wikipedia.org/wiki/ ケント・ベック
それを良しとする人もいました。そして、そのよ うなチームはとてもうまくいきました。しかし、 一般的には、力関係は変わっていません。つまり、 インセンティブが変わっていないのです。だから、 行動は変わらない。だから結果も変わっていない。 私は、これはペアプログラムをするかしないかと いう問題ではなく、意思決定をスキル・情報・結 果に向けて動かす意思があるかどうかという問題 だと思っています。 (Kent
Beck 2021年7月のAgile 2021でのトークより) https://ja.wikipedia.org/wiki/ ケント・ベック
それを良しとする人もいました。そして、そのよ うなチームはとてもうまくいきました。しかし、 一般的には、力関係は変わっていません。つまり、 インセンティブが変わっていないのです。だから、 行動は変わらない。だから結果も変わっていない。 私は、これはペアプログラムをするかしないかと いう問題ではなく、意思決定をスキル・情報・結 果に向けて動かす意思があるかどうかという問題 だと思っています。 (Kent
Beck 2021年7月のAgile 2021でのトークより) https://ja.wikipedia.org/wiki/ ケント・ベック 自分には納期を決定する力 があると思っている人が、 その力の幻想を手放そうと しなかったのです。
それを良しとする人もいました。そして、そのよ うなチームはとてもうまくいきました。しかし、 一般的には、力関係は変わっていません。つまり、 インセンティブが変わっていないのです。だから、 行動は変わらない。だから結果も変わっていない。 私は、これはペアプログラムをするかしないかと いう問題ではなく、意思決定をスキル・情報・結 果に向けて動かす意思があるかどうかという問題 だと思っています。 (Kent
Beck 2021年7月のAgile 2021でのトークより) https://ja.wikipedia.org/wiki/ ケント・ベック 一般的には、力関係は 変わっていません。 自分には納期を決定する力 があると思っている人が、 その力の幻想を手放そうと しなかったのです。