「AI駆動PO」を考えてみる - 作る速さから価値のスループットへ：検査・適応で未来を開発 / AI-driven product owner. scrummat2025

Transcript

1. "AI駆動PO"で考えてみる 作る速さから価値のスループットへ AI時代の業務バランスと検査・適応で未来を開発 2025/10/04 CCIグループ 北國銀行・デジタルバリュー 長井 洋介
2. １. セッション内容 2
3. このセッションについて • ある程度スクラムの知識がある方向けにはなりますが、最低 限の要点は説明します。 • 制作を進めるうちに想定以上の観点が出てきました。発散的 で歯切れの悪さや曖昧さが伴いますが、聴いてくださった方 の翻訳力や主体性に頼る構成にしています。 • 多様なシステムの世界を想像し、出来るだけ原理原則を大切 にします。 • 思考実験ですので気づきや違和感はどんどんディスコードに 投稿してください。それが他の方の次の気づきにも繋がりま す。 3
4. 皆さんお聴きになられましたか？ fukabori.fm #131. 「AIコーディングの現在地 w/ twada」 4 引用元：「fukabori.fm #131. AIコーディングの現在地 w/ twada」 https://fukabori.fm/episode/131
5. fukabori.fmとt-wadaさん fukabori.fmは、ホストの岩瀬義昌さん（@iwashi）が、技術・組織・マネジメ ントを深掘りするPodcast。ゲストはEM・PM・実務家が多く様々なITに関連の ある議題を扱う。代表回は #100「A Philosophy of Software Design」、 #130「MCP回」など。先日のスクラムフェス大阪2025のキーノートスピー カーでもありました。 #131でゲストの通称t-wadaさんこと和田卓人さんは、テスト駆動開発（TDD） の第一人者として実践と普及に尽力されいる日本の著名なプログラマー。 fukabori.fmでもt-wadaさんゲスト回は界隈で話題になること多い。 5 引用元：「fukabori.fm #131. AIコーディングの現在地 w/ twada」 https://fukabori.fm/episode/131
6. 「シニア有理論」付近の抜粋引用 (1:03:02～) 例えば、だからプログラミングスキルそのもの、コーディ ングスキルそのものが、今後の世界でもしエージェントがさらに進化し てコーディング自体はそんなに競争力にならないとしたら、コーディン グが自分のアイデンティティの大部分でありかつ競争力の大部分であっ たエンジニアは、シニアエンジニアであってもやっぱり危機に晒される わけですが、 そこに対して自分のスキルセットを棚卸して洗い替えていくアンラーニ ングっていうのはものすごく痛みを伴うプロセスで、それは色々知って いるとかこれまで色々やってきて　積み上げてきたことがむしろ重荷に なってしまいますよね。だからそんなに簡単ではない。 引用元：「fukabori.fm #131. AIコーディングの現在地 w/ twada」 https://fukabori.fm/episode/131 6
7. 「シニア有理論」付近の抜粋引用 やっぱりその、自分のそれまでのアイデンティティと、状況によっては どう向き合うかって話になるから、めちゃくちゃ辛いです。これ、プロ グラミングってこれからなくなるかもしれないなって思うと、私もとて も辛いです。なぜならプログラミングは好きで好きで仕方がないからで すね。 なので、そういったところっていうのはやはりアンラーニングとかアイ デンティティ喪失の痛みがある。だからシニアもそんなに簡単ではな い。で、ジュニアエンジニアは有利な点もあります。1つはだからアン ラーニングの必要がない。これから必要なスキル、考え方をこれからど んどん吸収していけばいいというところがまず有利な点。 引用元：「fukabori.fm #131. AIコーディングの現在地 w/ twada」 https://fukabori.fm/episode/131 7
8. 一部の要約 • ソフトウェア開発は自律的AIによる「エージェンティック コーディング」へと急激に移行。 • シニアはデザインパターンなど無数の語彙（コンテクスト圧 縮技術）を持ちAI時代の競争力に。 • コードディングシーンが急速に失われようとしていること へ、t-wadaさんの強い悲しみ。 • シニアは知識や経験則が重荷となり、アイデンティティを揺 るがし痛みを伴うアンラーニングに直面。限られた時間でAI に触れ本質掴むよう頑張るしかない。 • 一方、ジュニアは豊富な時間を武器に。多くのツールや体験 を積めて新時代の本質を捉えやすい。 8 引用元：「fukabori.fm #131. AIコーディングの現在地 w/ twada」 https://fukabori.fm/episode/131
9. t-wadaさんの使命感からくる多くの試行と所感について話 されていて、リアリティがあり論理的で多面的な見立てに強 い納得感があったこと。またAIがもたらそうとしている未来 への好奇心と、そこに混ざり合った悲しみの言葉から、多く の視聴者は"事の重大さ"を感じ取ったこと。 「うちの会社ではエンジニア全員に視聴を指示」なんて話も 目にしたりで、多くのIT関係者の心を鷲掴みでインパクトが 大きかった印象。「AIコーディングの現在地」というタイト ルが正にの神回であったと捉えています。 なぜ "神回" だったか 9 引用元：「fukabori.fm #131. AIコーディングの現在地 w/ twada」 https://fukabori.fm/episode/131
10. 多分、世界が変わり始めてる GPT4の公開から早2年以上。当たり前となった生成 AI。"Vibe Coding"だけでなく"仕様駆動開発"なる手法も登 場。 それらの開発体験は衝撃的で「生産性10倍!!」との声もチラ ホラ。本格的な"AI駆動開発時代"が目の前。 10
11. 多分、世界が変わり始めてる GPT4の公開から早2年以上。当たり前となった生成 AI。"Vibe Coding"だけでなく"仕様駆動開発"なる手法も登 場。 それらの開発体験は衝撃的で「生産性10倍!!」との声もチラ ホラ。本格的な"AI駆動開発時代"が目の前。 もうジュニアは不要? そもそもエンジニア不要?? xxx社でエンジニア何千人解雇???? 現在私はエンジニアの採用も担当していますが、「採用方針 を見直したほうが良いのでは?」など複数の社員から相談を 受けている。 11
12. たしかにVibe Codingはすごい 自宅で初めてCursorを触っときに作ったのがこちら。 「アクアリウムをブラウザで再現して魚の世話ができるよう なパラメータを持ったゲームを作って」と注文。 自律的にコード生成するAI。今までなら軽く1ヶ月以上掛か りそうなものが僅か10分足らずで。indexファイルを開くと そこには画面の中で動く魚。超高速の衝撃的体験。 12
13. 世の中の声、会社での声、自身の体感 確かにどれも一致している 13
14. 開発組織としてのAI活用の現在 自社では利用方法がモデル化されていないため、上手く使え ているとは言い辛い。ただし個人レベルでは5倍～10倍速度 が上がったケースを複数確認。 金融系システムが中心の自社では、システムの大きさや関連 サービスなどとの依存関係も複雑なため、全体適応の観点だ と定着までの道のりは長そう。 一方、デザインやフロントエンド寄りの工程が先に定着しそ うな気も。仮にコンポーネント別で活用が進むならば、チー ムの機能横断性は低下するかも知れない。 14
15. 組織としてどのように捉えるか これは開発組織だけでなく会社全体に対する視点だが、 「このAIの変革に対し開発組織がどこまで能動性を持つべき か」という漠然とした問題意識がある。これはこのセッショ ンのテーマとも言える。 なぜなら目の前ですごい事が起こっていて、AIコーディング に触れた "開発従事者" だけが気づいたものなのであれば、 早めにアラートを上げたほうが良いかもしれないから。 15
16. 局所的には速くなっている 繰り返しだが個人依存なりに一部かなり速くなっている。 当然だが局所的にでも開発が高速化したら周辺での影響はあ るはず。 例えばチケット駆動な開発の場合、要件整理やチケット（具 体的な仕事）の整理はボトルネックになりそう。 スクラムチームであれば、 チケットとなるプロダクトバックログの管理者であるプロダ クト―オーナー（PO）がボトルネックになり得るというこ と。 16
17. プロダクト―オーナー に着目する 全体を見ようとすると問題が複雑で捉えきれないため、一つ テーマを絞り込り、問題を紐解くことで、そこから得る気付 きが結果的に輪郭を捉えることに繋がることを目指す。 ということでプロダクトオーナー＝POを少し解説。 スクラムチームは3つのロールで構成される。 1. PO：価値最大化を担いプロダクトバックログを管理。 2. スクラムマスター：理解と実践を支援し障害除去。 3. 開発者：自律的に設計/実装しスプリント毎に成果を。 17
18. スクラムのすべてがここにある 「スクラムガイド」 “Scrum is immutable. While implementing only parts of Scrum is possible, the result is not Scrum.” スクラムは、スクラムガイドに定義されているスクラムのアカウンタビ リティ、イベント、成果物およびそれらを結びつけるルールから構成さ れる。これらの要素を除いたり変更したりすると、それはスクラムでは ない。 18
19. 「スクラムガイド」より抜粋 プロダクトバックログ プロダクトバックログ プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの⼀覧で ある。これは、スクラムチームが⾏う作業の唯⼀の情報源である。 1 スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプラ ンニングのときには選択の準備ができている。スクラムチームは通常、リファインメントの活動を 通じて、選択に必要な透明性を獲得する。プロダクトバックログアイテムがより⼩さく詳細になる ように、分割および定義をする活動である。これは、説明・並び順・サイズなどの詳細を追加する ための継続的な活動である。多くの場合、属性は作業領域によって異なる。 作業を⾏う開発者は、その作業規模の評価に責任を持つ。開発者がトレードオフを理解して選択で きるように、プロダクトオーナーが開発者を⽀援することもできる。 19 引用元：「スクラムガイド 2020」 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
20. 「スクラムガイド」より抜粋 プロダクトバックログ プロダクトバックログ プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの⼀覧で ある。これは、スクラムチームが⾏う作業の唯⼀の情報源である。 1 スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときに は選択の準備ができている。スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得 する。プロダクトバックログアイテムがより⼩さく詳細になるように、分割および定義をする活動である。これは、 説明・並び順・サイズなどの詳細を追加するための継続的な活動である。多くの場合、属性は作業領域によって異な る。 作業を⾏う開発者は、その作業規模の評価に責任を持つ。開発者がトレードオフを理解して選択できるように、プロ ダクトオーナーが開発者を⽀援することもできる。 20 引用元：「スクラムガイド 2020」 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
21. 「スクラムガイド」より抜粋 プロダクトオーナー プロダクトオーナー プロダクトオーナーは、スクラムチームから⽣み出されるプロダクトの価値を最⼤化することの結 果に責任を持つ。組織・スクラムチーム・個⼈によって、その⽅法はさまざまである。 プロダクトオーナーは、効果的な プロダクトバックログ管理にも責任を持つ。たとえば、 • プロダクトゴールを策定し、明⽰的に伝える。 • プロダクトバックログアイテムを作成し、明確に伝える。 • プロダクトバックログアイテムを並び替える。 • プロダクトバックログに透明性があり、⾒える化され、理解されるようにする。 上記の作業は、プロダクトオーナーが⾏うこともできるが、他の⼈に委任することもできる。いず れの場合も、最終的な責任はプロダクトオーナーが持つ。 21 引用元：「スクラムガイド 2020」 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
22. 「スクラムガイド」より抜粋 プロダクトオーナー プロダクトオーナー プロダクトオーナーは、スクラムチームから⽣み出されるプロダクトの価値を最⼤化 することの結果に責任を持つ。組織・スクラムチーム・個⼈によって、その⽅法はさまざまで ある。 プロダクトオーナーは、効果的な プロダクトバックログ管理にも責任を持つ。たとえば、 • プロダクトゴールを策定し、明⽰的に伝える。 • プロダクトバックログアイテムを作成し、明確に伝える。 • プロダクトバックログアイテムを並び替える。 • プロダクトバックログに透明性があり、⾒える化され、理解されるようにする。 上記の作業は、プロダクトオーナーが⾏うこともできるが、他の⼈に委任することもできる。いずれの場合も、最終 的な責任はプロダクトオーナーが持つ。 22 引用元：「スクラムガイド 2020」 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
23. 「スクラムガイド」より抜粋 プロダクトオーナー プロダクトオーナー プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなけ ればならない。これらの決定は、プロダクトバックログの内容や並び順、およびスプリントレ ビューでの検査可能なインクリメントによって⾒える化される。 プロダクトオーナーは 1 ⼈の⼈間であり、委員会ではない。プロダクトオーナーは、多くのステー クホルダーのニーズをプロダクトバックログで表している場合がある。ステークホルダーがプロダ クトバックログを変更したいときは、プロダクトオーナーを説得する。 23 引用元：「スクラムガイド 2020」 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
24. 「スクラムガイド」より抜粋 プロダクトオーナー プロダクトオーナー プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなけ ればならない。これらの決定は、プロダクトバックログの内容や並び順、およびスプリントレ ビューでの検査可能なインクリメントによって⾒える化される。 プロダクトオーナーは 1 ⼈の⼈間であり、委員会ではない。プロダクトオーナーは、 多くのステークホルダーのニーズをプロダクトバックログで表し ている場合がある。ステークホルダーがプロダクトバックログを変更したいときは、プロ ダクトオーナーを説得する。 24 引用元：「スクラムガイド 2020」 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
25. プロダクトオーナーとは • プロダクトの価値を最⼤化することの結果に責任を持つ人。 • 効果的なプロダクトバックログ管理にも責任を持つ人。 • 多くのステークホルダーのニーズを、プロダクトバックログ で表している場合がある。 • そのプロダクトバックログは、スクラムチームが⾏う作業の 唯⼀の情報源。 25
26. プロダクトの価値を最大化する プロダクトオーナー（PO）の責務は「プロダクトの価値の 最大化」。"最大化"という言葉から読み取れる通り、最小か らのスタート（漸進性や変容性）が前提。 これは「単一指標の最大化」ゲームではないということ。 プロダクトの価値はプロダクトの中だけにあらずその外にあ る何かへの貢献であっても良い。 流れの中で経営戦略と整合させて“総合的価値”を最適化して いく営みであり、時に停滞や撤退判断も立派な価値の最大化 にもなるものだと理解しています。 26
27. そんなPOの特性を踏まえて 生成AIに話を戻します。 POは動きを変える必要があるでしょうか。 必要があるなら何をどのように変えればよいでしょうか。 27
28. 生成AI時代のPOの動きかた 場所やケースに大きく左右されると思う。ただ、生成AIを使 うのはエンジニアだけではない。業務部門や関係部門、何よ りPO自身も。 PO自身の所属が開発組織か業務組織かでも大きく変わる が、POはプロダクトの要であり、特に開発部門所属の場合 は生成AIの動向を近くで観察できる絶妙なポジション。なの で、POの意識がこれまで通りで良いとは到底思えない。 であればいっそ「AI駆動PO」なんて思い付きで思考実験す るのも面白いかもしれない。というのが本セッションの動機 となります。 28
29. ということで 長くなりましたが 今日話す事 POの視点を持ちながら、アレやコレやと生成AIによる変革 を仮説的に調査・整理し「AI駆動PO」がどのように立ち回 るか答えを探ろうとした結果、そこには想像以上に複雑な世 界が広がっていました。 結局、全体を通して「POが」とうより俯瞰的な内容に寄っ てしまいましたが、どの粒度にも通じる基本的な話が多めに なっていますので、その中で得た気づきやこう考えると良い のでは？というアイデアを、脈絡は気にせず提示し、みなさ んと共に思考実験してみたいと思っています。 29
30. 自己紹介 長井 洋介（Nagai Yosuke） CCIG 北國銀行 システム部 開発G グループ長 CCIG デジタルバリュー テクノロジー部 部長 1978年 生まれ 神戸市出身 2005年～ 複数の都内企業でIT事業に従事 　経験スタックはフロント～インフラまで広浅 　エンタープライズ系からキャリアを開始し 　WEBを中心に toB, toC, SNS, ゲームなど 　様々なソリューション, サービスサイズ, ライフサイクルを経験 2021年8月～ 北國銀行入行 デジタルバリュー出向兼務 金沢に転居！ 現在はCCIグループのIT文脈全体に関与を広げている カード系事業開発も監修 スクラムフェス金沢運営 アジャイルにどっぷり！ 30 ＼北國フィナンシャルホールディングスはCCIグループとなりました／（2025/10～）
31. [宣伝]＼新デビットカードアプリ ／ 31
32. 目次 1. セッションの内容 2. 起きていること 3. 高速化で起きること 4. 生産性を調査 5. 全体の回転数は上がり続ける 6. 可能性と方向性 7. AI駆動PO（拡張PO） 8. ギャップと分担 32
33. ２. 起きていること 33
34. 用語説明：AI駆動開発 AI駆動開発は、生成AI（ChatGPT、GitHub Copilot、 Cursorなど）を活用してソフトウェア開発を行う広義の概 念です。コード生成やテスト自動化にAIを使うだけでなく、 要件定義や設計支援なども含まれます。 AI駆動開発自体は広義で「会話を軸に試作を回すVibe Coding」や「仕様を土台に自動生成するSDD」など、複数 のスタイルが位置づけられます。つまりAI駆動開発は総称的 な言葉であり、実際の取り組み方はチームの文化やプロダク ト特性に応じて多様に分かれていきます。 34
35. 用語説明：Vibe Coding Vibe Codingは、AIと開発者が「対話」しながらコードを共 創するスタイルで、AI駆動開発の一形態です。 CursorやWindsurfなどのAIエージェント系IDEを開き、 「もっと見やすく」「デザインを変更して」と自然に話しか けるだけでAIがコード修正版を返します。仕様書を綿密に作 る前にまず動くものを形にし、その場で改善を繰り返すのが 特徴。直感やアイデアを素早く形にするのに適しておりプロ トタイピングと相性が良い。 35
36. 用語説明：仕様駆動開発（SDD） SDDは Spec-Driven Development（仕様駆動開発）の略称 で、「仕様を出発点にコードやテストを生成・整合させる開 発手法」を指します。 最初に「仕様」を整理し、それを基にコードやテストを生成 するAI駆動開発の一形態。最近ではAWS産の「Kiro」など のツールが話題に。流れとしては「仕様を書く → ツールで 形式化 → コードやテストを生成 → 実装と突き合わせて調 整」といった手順。まだ実用事例は限られていますが、複雑 さや信頼性が求められる領域で活用が期待、模索されていま す。 36
37. 開発組織としてのAI活用の現在 自社での生成AI活用は積極的で、複数のモデルやエージェン トを検証中。活用方法のモデル化には至っていない為、会社 として使えているとは言い辛い。 ただし個人レベルでは、5倍～10倍速度が上がったケースを いくつか確認している。 金融系の自社ではシステムの大きさや接続サービスとの依存 関係も複雑なため、全体適応や定着までの道のりは長そう。 デザインやフロントエンド寄りの工程が先に定着しそうな気 も。 37
38. 実務でどこまで使えているか エージェンティックコーディングを実務利用できている現場 はどのくらいあるだろうか。プロダクトの種別やタイプ、 フェーズ、業種、など様々な条件があると思うが、システム のサイズや複雑性は大きなポイントになりそう。 いずれにしてもコンポーネント個々に対するきめ細やかな設 計とそれらを統制するためのアーキテクチャが必要そう。 あともう半年～1年でもしたらその辺りを自律的に言語化、 全体を統制してくれるオーケストレーター的エージェントが 登場してくる気もする。 38
39. 「複雑性」とAIの相性 39 Vibe CodingやSDDなどの評価や実例なども踏まえて、AI開 発とサービスサイズなどの相性度を生成AIで100点評価。 相性度 種別 代表例 複雑性 90 LP（1ページ訴求） キャンペーンLP、単発申込フォーム 小（1～5p） 85 静的コンテンツ 会社概要、製品説明、採用ページ 小（5〜30p） 78 マーケサイト（軽動的） ブログ、ナレッジサイト、CMS更新 中（CMS/検索/多言語） 72 フォーム＋簡易ワークフロー 問合せ→CRM登録、自動返信 中（外部API少なめ） 68 プロモ特化EC（軽量） 固定カタログ＋Shopifyテーマ改変 中（在庫/決済依存） 62 ダッシュボード/BI KPI可視化、レポート表示 中（DWH/SQL連携） 58 CRUD内製ツール マスタ管理、チケット管理、承認フロー 中（認証/権限/監査） 50 複合業務ロジック 料金計算、与信、在庫引当 大（複数システム連携） 45 本格EC 在庫・価格変動、販促連動、多通貨決済 大（基幹/配送/税制依存） 38 協調・リアルタイムアプリ コラボ編集、WebSocket同期 大（低遅延/同時編集） 30 マルチテナントSaaS 権限管理、拡張、課金、SLAs 超大（マルチ環境/監査必須） 20 規制/安全クリティカル 金融システム、医療基盤、決済基盤 極大（規制・安全要求極高）
40. ３. 高速化で起きること 40
41. どの粒度でも安易な高速化は怖い 速く作れる→気軽に作れる→安易に作れる 誰しも日々の業務の中で、仕事の速度向上をしたくなるのは 至極当然のこと。しないといけない。 ただ、価値が未定義だとゴミの量産になり易いし、部分的な 高速化と全体の高速化が一致するとは限らない。安易な高速 化は意図しないボトルネックのスライドなど、周囲負担や副 作用が多いので注意したい。 仮に全てが上手くかみ合い全体が高速化したとして、その世 界はどんな世界なのか。それは全体で合意していた戦略なの か。そもそも持続性はあるのか。 41
42. ボトルネックについて ボトルネックとは、全体の流れや成果を最も遅らせている弱 点部分のこと。制約条件となり全体の限界を決める。 制約理論（TOC）で有名な「ザ・ゴール」や、本イベント のキーノートスピーカーである森 雄哉さんの以下のスライ ドがかなりおススメです。 42 ブルシットプロダクトからチームを守れ! ｢顧客が本当に必要だったもの｣を追求する プロダクトマネジメントを実現するぞ/bullshit product rsgt2022 https://speakerdeck.com/moriyuya/bullshit-product-rsgt2022
43. 闇雲に回転数 だけを上げると 43 • ボトルネック（周囲が） ◦ 待機時間が生まれプレッシャーを生む ◦ 部位に偏り周りが速度向上に追われる • コミュニケーションコスト増 ◦ 頻度が上がりペース崩れ質も低下 • 個別最適 ◦ 待ちの間は中の仕事を…となる ◦ それはそれで業務の管理コストもあがる ◦ 効率化しても仕事が増えない ◦ 人を減らそうとする
44. 44 層 主な役割 領域 –4層 経営, 営業,マーケ 事業戦略, 市場分析 –3層 事業部門, PM 企画, ガバナンス –2層 開発T、デザイナー 概要設計, レビュー –1層 PO, SM チケット管理 0層 DEV (開発者) 開発 (設計・実装) +1層 シニアエンジニア, QA 技術的検証 +2層 QA, 事業部門, CS 総合検証・受入検証 +3層 法務, セキュリティ,監査, 統括 リリース承認 +4層 SRE/インフラ, PM, 営業店 リリース, ユーザー展開 +5層 SRE, CS, データアナリスト 運用保守・効果測定 影響の距離と頻度のイメージ 影響の距離のイメージ図。V字モデル的な対称性もあり頻度も見 えてくる。例えばセキュリティのシフトレフトが非自動化だと開 発高速化の分だけ関与頻度増の可能性。
45. 45 層 主な役割 領域 主な活動内容 –4層 経営, 営業,マーケ 事業戦略, 市場分析 事業戦略策定, 市場分析, 投資判断, 予算承認 –3層 事業部門, PM 企画, ガバナンス 業務要件提示, PJT計画, 法務・セキュリティ評価 –2層 開発T, デザイナー, データアナリスト 概要設計, レビュー UI/UX作成, データ分析, 仕様の合意形成 –1層 PO, SM チケット管理 バックログ優先順位付け, プロセス円滑化, タスク具体化 0層 DEV (開発者) 開発 (設計・実装) コーディング, デバッグ, 単体テスト, ビルド +1層 シニアエンジニア, QA 技術的検証 コードレビュー, 品質テスト(QA), 連携検証 +2層 QA, 事業部門, CS 総合検証・受入検証 総合的な動作検証(QA), 業務シナリオ受入テスト(UAT) +3層 法務, セキュリティ, 監査, 統括 リリース承認 法務レビュー, 脆弱性診断, 監査対応, リリース可否判断 +4層 SRE/インフラ, PM, 営業店 リリース, ユーザー展開 本番環境へのデプロイ, 営業店対応, 研修, マニュアル作成 +5層 SRE, CS, データアナリスト 運用保守・効果測定 安定稼働監視, 障害対応, KPI測定, フィードバック収集
46. ここまでのまとめ 生成AIはすごい。少なくとも個人レベルのコーディングにつ いてはゲームチェンジが起き始めている。 でも闇雲に回転数だけ挙げると、チケット担当のPOはボト ルネックになり、いずれ関係部門にも影響してくる。 高速化のため闇雲に生成AIを使っても、全体の生産性として は上がるどころか下がる可能性すらあるということ。 46
47. ４. 生産性を調査 47
48. 生産性とはそもそも何か 48 次に闇雲に回転数だけを上げない方法を考えてみる。 回転数は量的生産性に分類されると思うが、量的生産性以外 にどんなものがあるか。 アバウトに調べると、生産性は量か質かで語られる傾向が あったので、生産性にはどんな種別・観点があるか DeepResearch。中央値に注意しつつ学術性やビジネス支持 度を重視しつつ調査。
49. 分類パターン 主要な次元 主要な適用領域 支持度 学術性 ソース例 全要素生産性 効率性、技術 マクロ経済、 長期成長戦略 中 最高 BLS, NBER, 学術論文 部分生産性 量 (労働生産性) マクロ経済、 製造業、財務分析 高 高 BLS, OECD, Investopedia Q, C, D 質、コスト、 納期 オペレーション、製造 業、サプライチェーン 最高 中高 Lean Management, Wikipedia, HBR/McKinsey Q, Q, V 質、量、価値 サービス業、知識労働、 プロダクトマネジメント 高 中 HBR, TIAA Institute, ResearchGate Eco-efficiency 効率性、持続性 ESG経営、戦略、 イノベーション 中高 高 WBCSD, UN Sustainable Dev. 創造性, 革新性 質、価値、新規 R&D、競争戦略 中 中高 Schumpeter, ResearchGate 生産性とはそもそも何か 49 視点やスコープ調整が難しく適当なところで手を止めたが、 結局どの側面や観点で見るかは文脈による。
50. 開発における"生産性"を分類 50 観点 プロダクト価値 開発における実現手段の例 🚀 量的 （D,スピード） 市場投入と学習の サイクルを高速化 企画・仕様・コードの自動生成 実践: CI/CD, WIP制限, 小バッチ開発 ✅ 質的 （Q,価値,信頼） 顧客価値とシステムの 信頼性を両立 テスト設計, 合成データ生成, 原因分析 自動テスト, SLO/SLI, オブザーバビリティ 💰 効率性 （C,経済性） コストを最適化し 経済合理性を高める コスト分析, 手順書生成, 重複検出 FinOps, IaC, コンポーネント共通化 🌱 持続性 （保守性） 技術的負債を管理し 長期的な保守性を保つ ドキュメント・ADR・依存更新の自動化 技術的負債管理, 静的解析 🔄 適応性 （変化対応） ビジネスや技術の変化へ 迅速かつ安全に対応 影響分析, ロールバック手順の生成 疎結合アーキテクチャ, フィーチャーフラグ 改めて、開発工程をマッピングしながらチューニング。 QCDに"持続", "適応"が加わった形。プロダクトにおける生 成AIの生産性分類には程よい抽象度だと感じた。ちなみに このセッションのテーマは🌱持続性と🔄適応性ですかね。
51. 社会は生成AIをどう見ているか？ 51 そもそも • 社会全体が生成AIに何を見ているのか • 社会全体が生成AIに何を期待しているのか が気になり調べてみました。
52. AIへの「期待と関心」日本と海外 52 観点 日本 海外 背景 人口減少による人手不足という社会課題。 既存ビジネスの安定的継続志向。 絶え間ないイノベーションと成長を追求する企業文化。 リスクを厭わない投資家文化。 AI導入目的 人手不足の解消と業務効率化が主。 既存業務の課題解決を重視。 競争優位性の獲得と新たな市場創造が主。 イノベーションへの投資を重視。 注目テーマ ★★★★★: 業務効率化/生産性向上 ★★★★☆: 顧客体験(CX)向上 ★☆☆☆☆: 新規事業・サービス創出 ★★★★★: 労働市場・雇用 ★★★☆☆: 倫理・ガバナンス ★★★★★: 業務効率化/生産性向上 ★★★★☆: 顧客体験(CX)向上 ★★★★★: 新規事業・サービス創出 ★★★★☆: 労働市場・雇用 ★★★★★: 倫理・ガバナンス 労働市場への 影響 雇用代替への懸念が根強く、 「AIに仕事を奪われる」という議論が中心。 AIと人間の共存・協業が前提。 「専門性を向上パートナー」として新職種の創出に関心。 具体例 - 三菱UFJ銀行: 生成AIで月22万時間削減。 - 江崎グリコ: AIチャットボットで問い合わせ 対応を効率化し、人手不足を補う。 - コカ・コーラ: 生成AIで顧客嗜好を分析、新フレーバーを 開発。 - Gucci: AIで顧客に合わせた提案を実現しブランド向上。 DeepResearchで「生成AIによる変革」を日本と海外で分けて調 査。さらにその結果を比較し傾向を分析。 結果、日本は人手不足や効率化志向でAIへの不安感も強い。 一方、海外は成長志向や探索的志向でAIへの期待感が強い。
53. AIは人の仕事を本当に奪うのか Q. 産業革命の度に人の仕事は上流にシフトしましたか？ A. はい、産業革命のたびに人の仕事は全体的に見れば上流 にシフトしてきました。 ただし「みんなが上流へ行けたわけではなく、上流と下流の 格差はむしろ拡大する傾向」が常に伴いました。 👉 言い換えると、産業革命は「人を上流へ押し上げる力」 と「一部を下流に固定化する力」の両方を持っており、その ダイナミクスが社会を形作ってきたと言えます。 by GPT5 53
54. ５. 全体の回転数は上がり続ける 54
55. 外に目を向けてみる さて、生産性の定義なんかは広く調べつつも、 ここまでは開発視点。一人称の話でした。 周囲では何か変化が起こってないでしょうか。 55
56. 空気を読まず、Vibe Codingでつくりあげた試作品を持ち出した結果、エンジ ニアさんとのコミュニケーションがギクシャクした。リアルな体験を爆速で 試すためだったはずが、「これをつくる」みたいな取り扱いになり、エンジ ニアさんの立場を悪くさせてしまった（気がしている）。 Vibe Codingによって、ユーザー体験を独りよがりで考えてしまい、開発チー ム全員で考える"創造性の余白"を消してしまったのだ。 引用元：Big AI Shift（byユーザベース）hiranotomoki 「第7話 デザイナーのAIシフト -パンドラの箱が開いた日-」 https://note.com/hiranotomoki/n/na15288ce334a デザインの現場での生成AI活用 56
57. プロトタイプの事例を読んだ時は私の中でとても苦い味がして 「これは社内でも起こりそう」という事で引用させていただきま したが、記事全体や中で紹介されている動画含めてかなり面白 かったです。是非読んでみてほしいです。 デザインの世界で起きている戸惑いも、エンジニアの葛藤とかな り似ていて大きな共感を覚えました。特にデザインの部門が分離 している開発組織の場合はおススメです。 デザインの現場での生成AI活用 57 引用元：Big AI Shift（byユーザベース）hiranotomoki 「第7話 デザイナーのAIシフト -パンドラの箱が開いた日-」 https://note.com/hiranotomoki/n/na15288ce334a
58. コラム：Design-Driven Design？ システム思想やシステム戦略をどう担保するか。 SDD（仕様駆動開発）はアーキテクティングなエージェント の片鱗が見えた印象で、今後SDDがより高度化したデファク トスタンダードが登場したら、Vibe Codingで生まれたプレ ゼンテーション駆動なものとコンフリクトしそう。 長寿命想定のシステムであればDomain-Driven Design（ド メイン駆動設計）で丁寧に業務とシステムが整合したモデル の構築が必要になるケースもあるので、その場合プロトタイ プを早めにシステム部隊に連携したもらうなど、受け手とし てのシフトレフトが必要かも知れない。 58
59. Domain-Driven Design ドメイン駆動設計（DDD）は、エリック・エヴァンスが提 唱した設計アプローチで、業務知識を中心にモデル化しソフ トウェアへ反映することを重視。業務専門家と開発者がユビ キタス言語で協働し、複雑な処理をコンテキストで整理し業 務との整合性を確保。 依存の方向を業務モデル側に集約し、技術的要素が業務に従 う構造をとることで、業務変化への追従性や変更容易性を高 め、長期的に適応可能なシステムを育成。 59
60. 隣ではなく外の世界も変化する • 経営判断：意思決定高速化でロードマップ修正が増加 • セキュリティ：攻撃巧妙化で修正頻度と運用負荷増大 • 規制/監査：更新短期化で要件変動と適合確認頻発 • 競合：模倣スピード加速で差別化の寿命短縮 • プラットフォーム：頻繁更新で再学習や互換性崩れ常態化 • データ/モデル：更新短周期化でMLOps負荷増大 • エコシステム依存：外部速度が契約や法務律速点になる • 流通/チャネル：UIやアルゴ揺れでABテスト頻度増加 • 人材市場：スキル半減期短縮で育成・再配置速度が競争力直結 • 顧客期待：即応・パーソナライズ要求で体験改善サイクル加速 60
61. 全体の回転数は上がり続ける 今回の問題が非常に難しいと感じたのはこの点。 システム開発における生成AIの恩恵が大きすぎて、周辺状況 に目が向きづらくなっているが、実際には社会全体でゲーム チェンジが始まり出しているということ。 至極当然のことだが、統制や指針がないと現場は現場で今出 来ることでベストを尽くすので周囲の高速化は止めづらい。 この複雑性をどのようにとらまえて、自分たちがどのように 立ち回っていくかを考えていく事が重要だと考えます。 日本人が効率に目を向けがちという点も覚えておきたい。 61
62. ６. 可能性と方向性 62
63. 「時間をかけること」の再評価 「新しいエネルギーによって生まれる新しい価値」と聞く と、未知のものを想像しますが、既知のものを大幅に向上、 発展させるものもあると思います。 今日までの開発の常識だと、制作に20年掛かるようなもの は当然企画外。ところが生成AIの登場で、そういった企画外 ・規格外のものを、数年など少し時間を掛けて作るという選 択肢が生まれてくるだろうなと。 63
64. 「時間をかけること」の再評価 どの会社やどの組織でも探索的な開発に取り組める訳ではな いですが、生成AIの登場はソフトウェアの「新しい可能性」 を沢山開くものだと期待しています。技術負債は怖いもの の、かつてない発想のサービスがバンバン出てくると良いで すね。 64
65. 「方向性」のフレームワーク 生成AIでずっと効率化を続けるのは疲れそう。でも新しい未 来を想像するのは楽しいしモチベーションが上がる。 そういった生成AIの持つ可能性や「方向性」の話を生成AIに 壁打ちしていたら、方向性整理のフレームワークを提示して くれたので納得感が出るまでチューニングしてみた。 65
66. 「方向性」のフレームワーク 66 Safer（守り） Bolder（攻め） More （量） 効率化・安全な量産 　- 既存UIの自動テスト生成 　- ログ出力パターンの自動生成 　- 既知要件のドキュメント自動作成 　- コスト削減目的のルーチン自動化 大胆なスケール拡張 　- 多言語化（自動翻訳／ローカライズ） 　- 類似機能の高速クローンと同時市場展開 　- 高頻度A/Bで小改善を一気に回転 　- 顧客対応チャットボットの大規模展開 Better （質） 品質保証・リスク低減 　- 脆弱性チェックの自動化・強化 　- 自動コードレビューでムダを削減 　- テストカバレッジの強化 　- リリース前軽量セーフティケース整備 新価値創出・未知への挑戦 　- 新UXデザイン案のAIプロトタイピング 　- 顧客インサイト分析→新規サービス仮説 　- 異分野を組み合わせた新ビジネス探索 　- 「いままで無理」だった根本的再構築 事業やプロダクトに対しAI活用の方向性や重みを整理するもの。 四象限的に方向性をマップするも良し、ステージやフェーズに応じ て70-20-10学習モデルのように割合配分するなどトレードオフ スライダー的にも使うも良し。正しい方向や配分を固定化…ではなく POが組織に投げかける“問いの枠組み”として生成。 Time Dividend Framework
67. 「方向性」のフレームワーク 67 Safer（守り） Bolder（攻め） More （量） 効率化・安全な量産 　- 既存UIの自動テスト生成 　- ログ出力パターンの自動生成 　- 既知要件のドキュメント自動作成 　- コスト削減目的のルーチン自動化 大胆なスケール拡張 　- 多言語化（自動翻訳／ローカライズ） 　- 類似機能の高速クローンと同時市場展開 　- 高頻度A/Bで小改善を一気に回転 　- 顧客対応チャットボットの大規模展開 Better （質） 品質保証・リスク低減 　- 脆弱性チェックの自動化・強化 　- 自動コードレビューでムダを削減 　- テストカバレッジの強化 　- リリース前軽量セーフティケース整備 新価値創出・未知への挑戦 　- 新UXデザイン案のAIプロトタイピング 　- 顧客インサイト分析→新規サービス仮説 　- 異分野を組み合わせた新ビジネス探索 　- 「いままで無理」だった根本的再構築 補足：生成AIの思考→構築プロセス ・問いを「生産性自体」から「獲得時間の配当（dividend）先」に転換 ・思考プロセスは「時間の使い方」に軸を換えて指標偏重を避ける事 ・ 下敷き理論：70-20-10, Three Horizons Model, DORAやSRE ・ 既存フレームで語られていた要素を再解釈してAI活用文脈に合わせ Time Dividend Framework
68. 割合配分の例 68 Safer（守り） Bolder（攻め） More （量） 効率化・安全な量産 大胆なスケール拡張 Better （質） 品質保証・リスク低減 新価値創出・未知への挑戦 ※方向性配分（トレードオフ）のざっくり例※ 👉 品質立て直し：More 10% / Better 60% / Bolder 10% / Safer 20% 　不具合分析、根本原因調査、リファクタ、テスト補強、レビュープロセス改善 👉 新事業探索期：More 10% / Better 15% / Bolder 65% / Safer 10% 　PoCやMVP作成、顧客インタビュー、競合リサーチ、UXプロトタイピング、仮説検証スプリント 👉 大規模リリース前：More 10% / Better 25% / Bolder 5% / Safer 60% 　リグレッションテスト、性能検証、デプロイ手順リハーサル、セキュリティレビュー、ドキュメント整備 👉 インシデント発生後：More 5% / Better 20% / Bolder 5% / Safer 70% 　障害原因の振り返り（ポストモーテム）、監視改善、アラート閾値調整、運用手順標準化、再発防止策導入 Time Dividend Framework
69. ７. 役割の拡張 69
70. ここまでのまとめ 個人レベルでは生成AIでゲームチェンジ始まる。ただ闇雲な 高速化は周囲影響やPOはじめ隣接からボトルネックに。意 図を持たない高速化は生産性を下げることも。注意が必要。 生産性には複数の観点があること。そして領域や方向性もい ろいろ。国内全体としては効率性などに潮が強そうで、 他分野、外の世界でも回転数は日増しに上がっていくはず。 それらを踏まえて、自分たちは生成AIを使いなんの生産性を 上げるのか、どの方向に生産性を使うかを明確にしたい。 そしてどれだけ生産的であっても価値の高さが全てである。 70
71. 生成AI活用における勘所 • 何があろうと価値・効果が重要 • 浮いたパワーの投資先（方向）を決めておこう ◦ それにより部分最適と意図なき高速化を予防する • 与える影響を知る ◦ ボトルネックを捉えていくこと • 受ける影響を知る ◦ 周囲がどんどん速くなってくるぞ • その上で、どこに生成AIを用いるか意図を持つ • 本当の「生産性」を得るため観測・計測 • 効率化に振る場合は代替え感情に配慮 ◦ 活用できれば仕事が自然と増えるはず 71
72. AI駆動なPOをシミュレーション ということでやっとタイトル回収し始めます。POにとって どれが一番課題でしょうか。 方向性や課題などは、条件（ケースや環境）によりそう、な のでここまでの視点をもって、それぞれで考える他ないのか なとも感じています。 では、条件によらないものとは？ 72
73. Re: 生成AI活用における勘所 • 何があろうと価値・効果が重要 • 浮いたパワーの投資先（方向）を決めておこう ◦ それにより部分最適と意図なき高速化を予防する • 与える影響を知る ◦ ボトルネックを捉えていくこと • 受ける影響を知る ◦ 周囲がどんどん速くなってくるぞ • その上で、どこに生成AIを用いるか意図を持つ • 本当の「生産性」を得るため観測・計測する • 効率化に振る場合は代替え感情に配慮 ◦ 活用できれば仕事が自然と増えるはず 73
74. Re: 生成AI活用における勘所 • 何があろうと価値・効果が重要 • 浮いたパワーの投資先（方向）を決めておこう ◦ それにより部分最適と意図なき高速化を予防する • 与える影響を知る ◦ ボトルネックを捉えていくこと • 受ける影響を知る ◦ 周囲がどんどん速くなってくるぞ • その上で、どこに生成AIを用いるか意図を持つ • 本当の「生産性」を得るため観測・計測する • 効率化に振る場合は代替え感情に配慮 ◦ 活用できれば仕事が自然と増えるはず 74
75. Re: 隣ではなく外の世界も変化する 75 • 経営判断：意思決定高速化でロードマップ修正が増加 • セキュリティ：攻撃巧妙化で修正頻度と運用負荷増大 • 規制/監査：更新短期化で要件変動と適合確認頻発 • 競合：模倣スピード加速で差別化の寿命短縮 • プラットフォーム：頻繁更新で再学習や互換性崩れ常態化 • データ/モデル：更新短周期化でMLOps負荷増大 • エコシステム依存：外部速度が契約や法務律速点になる • 流通/チャネル：UIやアルゴ揺れでABテスト頻度増加 • 人材市場：スキル半減期短縮で育成・再配置速度が競争力直結 • 顧客期待：即応・パーソナライズ要求で体験改善サイクル加速
76. Re: 隣ではなく外の世界も変化する 76 • 経営判断：意思決定高速化でロードマップ修正が増加 • セキュリティ：攻撃巧妙化で修正頻度と運用負荷増大 • 規制/監査：更新短期化で要件変動と適合確認頻発 • 競合：模倣スピード加速で差別化の寿命短縮 • プラットフォーム：頻繁更新で再学習や互換性崩れ常態化 • データ/モデル：更新短周期化でMLOps負荷増大 • エコシステム依存：外部速度が契約や法務律速点になる • 流通/チャネル：UIやアルゴ揺れでABテスト頻度増加 • 人材市場：スキル半減期短縮で育成・再配置速度が競争力直結 • 顧客期待：即応・パーソナライズ要求で体験改善サイクル加速
77. Re: プロダクトの価値を最大化する プロダクトオーナー（以後：PO）の責務は「プロダクトの 価値の最大化」。"最大化"という言葉から読み取れる通り、 最小からのスタート（漸進性や変容性）が前提。 これは「単一指標の最大化」ゲームではないということ。 コーディング速度や技術力の最大化は手段の側面が強く、ま た、プロダクトの価値はプロダクトの中だけにあらずその外 にある何かへの貢献であっても良い。 流れの中で経営戦略と整合させて“総合的価値”を最適化して いく営みであり、時に停滞や撤退判断も立派な価値の最大化 にもなるものだと理解しています。 77
78. Re: プロダクトの価値を最大化する プロダクトオーナー（以後：PO）の責務は「プロダクトの 価値の最大化」。"最大化"という言葉から読み取れる通り、 最小からのスタート（漸進性や変容性）が前提。 これは「単一指標の最大化」ゲームではないということ。 コーディング速度や技術力の最大化は手段の側面が強く、ま た、プロダクトの価値はプロダクトの中だけにあらずその外 にある何かへの貢献であっても良い。 流れの中で経営戦略と整合させて“総合的価値”を最適化して いく営みであり、時に停滞や撤退判断も立派な価値の最大化 にもなるものだと理解しています。 78
79. 79 AI時代、 経営層の意思決定は速くなる？ ロードマップ修正も多くなる？ 戦略にプロダクトを整合する？
80. 80 ドメイン駆動設計（DDD） に似た考え方を転用できそう
81. Re: Domain-Driven Design ドメイン駆動設計（DDD）は、エリック・エヴァンスが提 唱した設計アプローチで、業務知識を中心にモデル化しソフ トウェアへ反映することを重視。業務専門家と開発者がユビ キタス言語で協働し、複雑な処理をコンテキストで整理し業 務との整合性を確保。 依存の方向を業務モデル側に集約し、技術的要素が業務に従 う構造をとることで、業務変化への追従性や変更容易性を高 め、長期的に適応可能なシステムを育成。 81
82. Re: Domain-Driven Design ドメイン駆動設計（DDD）は、エリック・エヴァンスが提 唱した設計アプローチで、業務知識を中心にモデル化しソフ トウェアへ反映することを重視。業務専門家と開発者がユビ キタス言語で協働し、複雑な処理をコンテキストで整理し業 務との整合性を確保。 依存の方向を業務モデル側に集約し、技術的要素が業務に従 う構造をとることで、業務変化への追従性や変更容易性を高 め、長期的に適応可能なシステムを育成。 82
83. Re: Domain-Driven Design 依存の方向を業務モデル側に集約し、技術的要素が業務に従 う構造をとることで、業務変化への追従性や変更容易性を高 め、長期的に適応可能なシステムを育成します。 83
84. Strategy-Driven Product Owner 依存の方向を戦略側に集約し、プロダクト的要素が戦略に従 う構造をとることで、戦略変化への追従性や変更容易性を高 め、長期的に適応可能なプロダクトを育成します。 84
85. 85 Strategy-Driven Product Owner 実際、POの責務に、経営戦略そのものの最適化まで含むと 境界が曖昧になるのと、従属性を助長させ自律性も下げかね ないので、これは少し極端な例かも知れない。
86. 86 Strategy-Driven Product Owner ただ、生成AIがもたらす変化の加速度を想像すると、生成AI の本質に触れやすいのはやはり現場側なので、プロダクトに 可搬性や柔軟性を注入し組織に対し能動的なトスアップや キャッチボールができるリーダーは、開発の現場に自律性と 活力を与える気がする。
87. 87 Strategy-Driven Product Owner 近い将来、開発者が今やっていることの大部分をAIに委ね て、開発者の動きは体半分くらいは外側に飛び出すに違いな いと思っている。 なので、ここでいう「拡張PO」は、責務も薄く広く外側に 拡大ではなく、体半分外へスライドする拡張をイメージして います。
88. "既存PO業務での"生成AI活用 少し発散気味でしたが、戻ります。 元々「拡張PO」をキーワードに幾つか検討事項を用意し、 生成AIの強みを活かしやすいところの整理や、生成AIによる 直接的な補助要件などを整理する予定でした。 • AIが得意：情報収集／分析・可視化／仮説生成・代替案／文書ドラフト／説明資料の雛形 • 人が必要：価値判断／合意形成・調整／最終優先順位／文脈理解／責任の引き受け • メトリクス整備：差戻し率、承認リードタイム、レビュー待ち在庫、ガードレール逸脱数 • ボトルネック調整ロードマップ：チーム内→部門間→ガバナンス→外部説明へ段階展開 • オートマージの運用プロトコル：対象範囲・権限・ロールバック・監査証跡 • コミュニケーション負債の抑制：定型同期の縮小、非同期テンプレ、意思決定ログ化 • 実験のガードレール：セキュリティ・法務の最小チェックリスト、段階リリース • ナレッジ化と育成：AIリテラシーギャップへのアプローチ、ジュニア×シニアへの割り当て • パイロット設計：小さく始めて、効果→拡張→制度化の順に 88
89. "既存PO業務での"生成AI活用 ところがここまでの説明の通りで、PO業務であれ何であ れ、局所の生産性向上に生成AIをどう使うか、の前に、手段 はやはり目的があってのものであり、結局同じ話になってし まうわけですね。AIが得意な調査タスクをAIで賄う運用を始 めたとて、それ単体では成果に繋がるとは言い辛い。 89
90. "既存PO業務での"生成AI活用 ですので、各社、各組織、各サービス、各開発現場のコンテ キストに併せつつ、生成AIを用いる方向性、生成AIをどの生 産性向上に用いるか、などを検討いただくことがファースト ステップだと感じます。 90
91. ８. ギャップと分担 91
92. "既存PO業務での"生成AI活用 もう一点だけ。 92
93. "既存PO業務での"生成AI活用 • AIが得意：情報収集／分析・可視化／仮説生成・代替案／文書ドラフト／説明資料の雛形 • 人が必要：価値判断／合意形成・調整／最終優先順位／文脈理解／責任の引き受け • メトリクス整備：差戻し率、承認リードタイム、レビュー待ち在庫、ガードレール逸脱数 • ボトルネック調整ロードマップ：チーム内→部門間→ガバナンス→外部説明へ段階展開 • オートマージの運用プロトコル：対象範囲・権限・ロールバック・監査証跡 • コミュニケーション負債の抑制：定型同期の縮小、非同期テンプレ、意思決定ログ化 • 実験のガードレール：セキュリティ・法務の最小チェックリスト、段階リリース • ナレッジ化と育成：AIリテラシーギャップへのアプローチ、ジュニア×シニアへの割り当て • パイロット設計：小さく始めて、効果→拡張→制度化の順に 93
94. "既存PO業務での"生成AI活用 • AIが得意：情報収集／分析・可視化／仮説生成・代替案／文書ドラフト／説明資料の雛形 • 人が必要：価値判断／合意形成・調整／最終優先順位／文脈理解／責任の引き受け • メトリクス整備：差戻し率、承認リードタイム、レビュー待ち在庫、ガードレール逸脱数 • ボトルネック調整ロードマップ：チーム内→部門間→ガバナンス→外部説明へ段階展開 • オートマージの運用プロトコル：対象範囲・権限・ロールバック・監査証跡 • コミュニケーション負債の抑制：定型同期の縮小、非同期テンプレ、意思決定ログ化 • 実験のガードレール：セキュリティ・法務の最小チェックリスト、段階リリース • ナレッジ化と育成：AIリテラシーギャップへのアプローチ、 ジュニア×シニアへの割り当て • パイロット設計：小さく始めて、効果→拡張→制度化の順に ここまでの観点を踏まえ これってどう思いますか？ 94
95. AIに対する理解度の差 開発チーム内でもこの差が顕著に開き始めている。 組織やチームレベルでこの差を埋める努力をしないと、 その人の感度の高さがボトルネック（律速点）になる。 95 生成AIがぺらぺらぺらで ぺらぺらぺらだから ぺらぺらぺらしてください ?! …? はいはい！ なるほど～！
96. ジュニア×シニアへの割り当て 96 冒頭でもあったジュニアによる「AIコーディングの本質の掴 みやすさ」は活かしたいところ。複雑なものを渡しづらいと しても、軽量な案件は積極的に割り振ってAIコーディングの 機会を増やすことも重要。 また別の側面を見ると「頻度の低さ」なども軽量さのうち一 つと捉えることができないか。 • 作業量の小ささ（小規模／コンパクト／限定的） • 複雑性の低さ（シンプル／ローコンプレックス／単純／ベーシック） • 負荷の少なさ（低負担／ライト／浅め／ソフト／容易） • リスクや影響範囲の小ささ（安全圏／ローリスク／限定影響／局所的） • 期間・継続性の短さ（短期／スポット／単発／一過性） • 頻度の低さ（低頻度／散発的／希少）
97. 97 層 主な役割 領域 主な活動内容 –4層 経営, 営業,マーケ 事業戦略, 市場分析 事業戦略策定, 市場分析, 投資判断, 予算承認 –3層 事業部門, PM 企画, ガバナンス 業務要件提示, PJT計画, 法務・セキュリティ評価 –2層 開発T, デザイナー, データアナリスト 概要設計, レビュー UI/UX作成, データ分析, 仕様の合意形成 –1層 PO, SM チケット管理 バックログ優先順位付け, プロセス円滑化, タスク具体化 0層 DEV (開発者) 開発 (設計・実装) コーディング, デバッグ, 単体テスト, ビルド +1層 シニアエンジニア, QA 技術的検証 コードレビュー, 品質テスト(QA), 連携検証 +2層 QA, 事業部門, CS 総合検証・受入検証 総合的な動作検証(QA), 業務シナリオ受入テスト(UAT) +3層 法務, セキュリティ, 監査, 統括 リリース承認 法務レビュー, 脆弱性診断, 監査対応, リリース可否判断 +4層 SRE/インフラ, PM, 営業店 リリース, ユーザー展開 本番環境へのデプロイ, 営業店対応, 研修, マニュアル作成 +5層 SRE, CS, データアナリスト 運用保守・効果測定 安定稼働監視, 障害対応, KPI測定, フィードバック収集
98. 98 層 主な役割 領域 –4層 経営, 営業,マーケ 事業戦略, 市場分析 –3層 事業部門, PM 企画, ガバナンス –2層 開発T、デザイナー 概要設計, レビュー –1層 PO, SM チケット管理 0層 DEV (開発者) 開発 (設計・実装) +1層 シニアエンジニア, QA 技術的検証 +2層 QA, 事業部門, CS 総合検証・受入検証 +3層 法務, セキュリティ,監査, 統括 リリース承認 +4層 SRE/インフラ, PM, 営業店 リリース, ユーザー展開 +5層 SRE, CS, データアナリスト 運用保守・効果測定 Re: 影響の距離と頻度のイメージ シニアでも中心から外になればなるほど経験していないことがグ ンと増える。であればスパンが短い中心領域はシニア、スパンが 長い領域をジュニアに任せて、レビュー負荷を調整できないか。
99. 99 新しいチームの役割分担 このセッションはあくまで思考実験なので粗いことを遠慮なく書 きますが、以下のような配分イメージを作ってみました。 再現性ある生成AI活用としてローコンテクストを体系化する上で も、役割の細分化は考えるポイントになりそう。 業務・関係部門 PO・SM DEV 業務・全体系 軽量・個別要件系 SM AI シニア ジュニア PO
100. 複雑な問題こそ多様な力で 100 今回の調査で採用含め教育を中心とした人事戦略の整備が重 要性が一気に増した一方で、今後の役割に対する曖昧さはそ の足枷にもなる、「厄介な問題（Wicked Problem）」と言 えそう。線形因果モデル（原因→結果）で捉えるのではな く、複雑適応系（Complex Adaptive System）としての全 体性を理解することが重要。 複雑な問題こそ多様な力で説く必要性も感じますし、人では なくプロセスをマネジメントする事が重要と言えると思いま す。皆で問題の全体を捉えて仕組みを調整すること。
101. 「AI駆動PO」（拡張PO） 101 AI時代において、プロダクトオーナーはAIを戦略的に活用 し、情報収集と分析の効率化を図ることで、本質的な価値判 断、経営戦略との整合性、そして複雑な合意形成へと注力す る。複雑さと様々なギャップが増幅する協働課題は、個々の 人材管理ではなく体系的なプロセス管理を通じて解決を図 り、多様な才能の最大限の活用を推進する。さらに、生成AI リテラシー向上のための社内研修や学習プログラムを導入を 提案するなど、組織全体でAIを効果的に活用できる企業文化 醸成に貢献する。これによりプロダクトと経営戦略、および 人材との整合性を高め、市場環境の変化に迅速に適応し、真 の価値最大化を牽引する役割を果たす。
102. まとめ 102
103. 組織での生成AI活用について 103 • 現場では生成AI活用進んでいますか • 何の生産性に活用していますか • そのものの生産性は本当にあがっていますか • それは価値の向上にちゃんと繋がっていますか • シニアもジュニアも皆不安になってませんか • 話が高速化してきていてみんな疲れてませんか • 生成AIについて会社で話し合ってますか • 生成AIを使ってない人は周りにいますか • チームでの会話は生産的になっていまか
104. 個人での生成AI活用について 104 • みなさんは普段生成AIつかってますよね • みなさんは何の生産性を上げていますか • それに連動する形でどんな変化がありましたか • 意欲的な心だけが先行してませんか • 楽しみすぎて家族との会話減ってませんか
105. 今回の整理でわかったこと 105 沢山ありすぎますが、何れにせよ諸刃の剣的な破壊力がある ので上手く使いたいですよね。乱暴な整理でしたが、それな りに沢山の観点を提示できたのではないかと思います。 皆さんともっと生成AIの未来や可能性について意見交換し、 もっともっと仕事を楽しんで、いきいきとした価値ある職場 づくりを目指したいなと思います。
106. "AI駆動PO"で考えてみる 作る速さから価値のスループットへ AI時代の業務バランスと検査・適応で未来を開発 2025/10/04 CCIグループ 北國銀行・デジタルバリュー 長井 洋介