Slide 1

Slide 1 text

AI Slopを生まない Platform Service設計 価値仮説と効果測定ってどうやるの? Red Hat Sachiko Kijima 1 Version number here V00000

Slide 2

Slide 2 text

木嶋 幸子 (Sachiko KIJIMA) @Red Hat ▸ エンタープライズアーキテクチャ ▸ アーキテクチャモダナイゼーション ▸ プラットフォームエンジニアリング 2020/5から現職 (Red Hatコンサルティング部門) 2 Version number here V00000

Slide 3

Slide 3 text

仮説検証中 Q: 今日のKeynoteを みましたか? 3 Version number here V00000

Slide 4

Slide 4 text

AI Slopとは何か 4 Version number here V00000

Slide 5

Slide 5 text

AI Slopを生まないPlatform Service設計 私のAI Slop被害体験 (スライド作成) 4h 12h 5 Version number here V00000

Slide 6

Slide 6 text

AI Slopを生まないPlatform Service設計 AI “Work” Slop 40% 42% 直近1ヶ月にAI Workslopを 受け取ったと認識している 人の割合 渡す側を以前より信頼でき ないと感じる人の割合 AI Slopかどうかは、受け取り側の主観的な判定 に依存する。 それらが本当に品質が悪かったかは調査の中では評価していない 。 6 Source: The hidden cost of AI “workslop” - and how leaders can fix it BetterUp Labs - Workslop Version number here V00000

Slide 7

Slide 7 text

AI Slopを生まないPlatform Service設計 仕事を渡す側の責任範囲は変わっていない AIの有無に関わらず、仕事を後続タスクに渡す側の責任範囲は、本来 1ミリも変わっていません。 ● ● ● 受け手がそれを使える状態かどうかを確かめる 自分のアウトプットで受け取り側が困ることがないかを確認しフォローす る より良い渡し方を考える 7 Version number here V00000

Slide 8

Slide 8 text

AI Slopを生まないPlatform Service設計 良い仕事の渡し方はリレー競技のバトンパス バトンを受け取ったあと、すぐ にトップスピードに 乗れたか 想定された区間の 中で渡せたか 全体のタイム (Outcome) は出たか 8 Throughput! Version number here V00000

Slide 9

Slide 9 text

AI Slopを生まないPlatform Service設計 期待値がズレるとタイム (成果) は出ない スピードが合わない 受け取り側の想定する 場所にバトンがない 受け取り側の準備がで きていない 一方的にどっちが悪いという話ではない 受け取れなかった理由は、実際の受け渡しを調べてみないとわからない 9 Version number here V00000

Slide 10

Slide 10 text

AI Slopを生まないPlatform Service設計 目的への貢献度と、受け手の負荷で、対処すべきかを判断する 受け手の負荷(認知・実行コスト) 高い 要改善・支援 目 的 へ の 貢 献 度 高い 理想の状態 残す ちょうど良い (受け取り側がパンクしないよう、改善・サポート ) (価値が高く、認知負荷が低いサービス ) 即対応 低い 低い 不要 作らない or リタイアする 作らない or リタイアする ※ リリース済みなら即対応!!! (成果に貢献しないため作成不要 ) 10 Version number here V00000

Slide 11

Slide 11 text

Value Stream Management 11 Version number here V00000

Slide 12

Slide 12 text

AI Slopを生まないPlatform Service設計 Value Stream 価値 (Value) の流れのこと。 その価値が必要になった時点から、実際に価値が必要な人に届けられた時 点までをひとつのValue Streamと呼びます。 12 Version number here V00000

Slide 13

Slide 13 text

AI Slopを生まないPlatform Service設計 Value Stream Management Value Streamの効率 (Throughput) がどのように良いかを可視化し、計測 し、改善する取り組みのこと。 速かった? 後で問題起こらなかった? 使えるものになった? 13 Version number here V00000

Slide 14

Slide 14 text

AI Slopを生まないPlatform Service設計 あるあるパターンを見てみましょう! (その後に解説編をやります。) 14 Version number here V00000

Slide 15

Slide 15 text

AI Slopを生まないPlatform Service設計 とあるPlatform Engineeringチームのコンテキスト 組織の目的 組織の作戦 チームの目的 労働人口減少対策として、 人的資源を集約する コンテナオーケストレーションを使い 運用を自動化・高度化することで 価値創出に人を集約する コンテナオーケストレーションの 利用促進 15 Version number here V00000

Slide 16

Slide 16 text

AI Slopを生まないPlatform Service設計 現状調査 & 課題発見: Value Stream Mapping 16 Version number here V00000

Slide 17

Slide 17 text

AI Slopを生まないPlatform Service設計 解決すべき課題の仮説定義 17 Version number here V00000

Slide 18

Slide 18 text

AI Slopを生まないPlatform Service設計 深掘り分析: Metric-Based Process Mapping LT 1週間の内訳 : プラットフォームチームはプロジェクト状況を把握して回答 したいので、ミーティングが必要になる。 手戻り: プラットフォームについて問い合わせてはみたものの、回 答のうちの一部を再検討したりなど、追加の質問が出てく るケースがある (50%) 18 Version number here V00000

Slide 19

Slide 19 text

AI Slopを生まないPlatform Service設計 目指す価値とKGI (Key Goal Indicator) 目指す価値 KGI (Key Goal Indicator) プラットフォーム選定の負荷を軽減し、短時間で安 全な選択を可能にする ミーティングゼロ! 19 Version number here V00000

Slide 20

Slide 20 text

AI Slopを生まないPlatform Service設計 価値仮説 ここまでで、最終的に組織の目的に至るまでに、次のようなロジックのつなが り (価値仮説) が生まれました。 情報収集・ 選定の負荷が減る コンテナ基盤の 採用が進む 運用の自動化が進む 人の手が空く 必要な仕事へ 人的資源を 再配置できる この辺がこのPlatform Engineeringチームのスコープ 20 Version number here V00000

Slide 21

Slide 21 text

AI Slopを生まないPlatform Service設計 ソリューション仮説定義 ソリューション: チャットボット、Platform Advisor ● ● ● 開発者はAIチャットボットに、社内のプラットフォームの選び方や、メリッ トデメリット、技術の解説などを説明してもらえる。 ミーティングの調整などが不要なため時間短縮にもなる 開発者の理解度に応じた説明をAIがしてくれるので、キャッチアップが 簡単にできる 21 Version number here V00000

Slide 22

Slide 22 text

効果測定を設計しよう 22 Version number here V00000

Slide 23

Slide 23 text

AI Slopを生まないPlatform Service設計 ミーティングゼロだけではなぜいけないのか ● 欲しい成果が出るかわからない ● 選定が進んだ上でゼロなのか、そもそも候補に上ってないのかがわから ない ● 副作用的な悪化がないかわからない 23 Version number here V00000

Slide 24

Slide 24 text

AI Slopを生まないPlatform Service設計 効果測定を通じてどのカテゴリにいるかを検証する 好転するかどうか 受け手の負荷(認知・実行コスト) 高い 要改善・支援 成 果 へ の 貢 献 度 高い 理想の状態 残す ちょうど良い (受け取り側がパンクしないよう、改善・サポート ) (価値が高く、認知負荷が低いサービス ) 即対応 低い 低い 副作用的に 悪化するか 不要 作らない or リタイアする 作らない or リタイアする ※ リリース済みなら即対応!!! (成果に貢献しないため作成不要 ) 24 Version number here V00000

Slide 25

Slide 25 text

AI Slopを生まないPlatform Service設計 効果測定 = 活動目的に対するビジネス的なテストケース ● 「正常系」: 狙った効果が出ているか ● 「異常系」: 悪い副作用を抑えられているか 25 Version number here V00000

Slide 26

Slide 26 text

AI Slopを生まないPlatform Service設計 正常系: 狙った効果が出ているか 情報収集・ 選定の負荷が減る コンテナ基盤の 採用が進む 情報収集が簡単になったら、本当 に基盤の採用が増えるか? チャットボットが情報収集の時間を 短縮できているか? 26 情報収集の時間短縮が、 Value Stream全体のThroughput向上を 実現しているか? 運用の自動化が進む 人の手が空く 必要な仕事へ 人的資源を 再配置できる コンテナオーケストレーションが使 われたら、本当に作業工数が減る か? コンテナオーケストレーションを 使って、自動化に進むような活用 方法がされているか? Version number here V00000

Slide 27

Slide 27 text

AI Slopを生まないPlatform Service設計 みんなが使ってくれているか (Adoption) も測定する みんなが使っていて役にたっているからミーティングゼロなのか? 基盤自体が無視されているからミーティングゼロなのか? 測定項目例 : ● 認知度 ● 利用数 ● 利用ユーザーの感想 27 Version number here V00000

Slide 28

Slide 28 text

AI Slopを生まないPlatform Service設計 異常系: 副作用がないか 情報収集・ 選定の負荷が減る コンテナ基盤の 採用が進む 運用の自動化が進む 人の手が空く 必要な仕事へ 人的資源を 再配置できる 質の悪い回答が問題を 起こしていないか? プラットフォーム情報収集や選定ス ピードが急激に変わったことで、困る 人がいないか? 28 Version number here V00000

Slide 29

Slide 29 text

AI Slopを生まないPlatform Service設計 副作用的な悪化をどう検知するか 人と人との仕事の受け渡し (ハンドオーバー) に着目し て見つけると見つけやすい。 プロセス全体を通じて洗い出し、必要箇所を全て計測す る。 承認が降りにくくなってないか? 29 Version number here V00000

Slide 30

Slide 30 text

AI Slopを生まないPlatform Service設計 Value Streamの認識が短いとリリース後を計測できない デプロイ段階で想定外の トラブルが起きていないか? インシデント傾向、 SLA実績、運 用工数はどうか? 30 Version number here V00000

Slide 31

Slide 31 text

AI Slopを生まないPlatform Service設計 効果測定はあくまで「どこに該当するか」を判定するまで 受け手の負荷(認知・実行コスト) 高い 要改善・支援 成 果 へ の 貢 献 度 高い 理想の状態 残す ちょうど良い (受け取り側がパンクしないよう、改善・サポート ) (価値が高く、認知負荷が低いサービス ) 即対応 低い 低い 不要 作らない or リタイアする 作らない or リタイアする ※ リリース済みなら即対応!!! (成果に貢献しないため作成不要 ) 31 Version number here V00000

Slide 32

Slide 32 text

AI Slopを生まないPlatform Service設計 対処するには原因の深掘りが必要 実際に何が起こっているか、なぜそれが起こったかは深掘りして特定、 起こっている事象に対して適切な対処をする 32 Version number here V00000

Slide 33

Slide 33 text

AI Slopを生まないPlatform Service設計 成果への貢献度が低い場合 ● 価値仮説レベルで間違った! ○ 捨てざるを得ない 可能性が高い ● ソリューションの企画段階で間違った! ○ 捨てざるを得ない 可能性が高い ● 実装レベルで間違った! ○ 修正できるか確認 。できなければ捨てざるを得ない 作る前に検証!! → 仮説検証の重要性 33 Version number here V00000

Slide 34

Slide 34 text

まとめ 34 Version number here V00000

Slide 35

Slide 35 text

AI Slopを生まないPlatform Service設計 まとめ ● AI Slopは検知して修正できるよう、警戒は怠らない ○ そのために価値仮説と効果測定を利用する ● 価値仮説を作成しないと効果が測定できない ○ 目的の実現に至る因果の繋がり (仮説) ○ これをやらないと局所最適になっていないかがわからない ● 効果測定は、狙った効果と、悪い副作用の両方を計測する 35 Version number here V00000

Slide 36

Slide 36 text

AI Slopを生まないPlatform Service設計 おまけ: このプレゼンに本当にAI Slopが紛れてない? どこでAIを使ったか、どう見直したかなど、過程をたどれる ようにRepoに検討記録をおいて公開しています。 調査資料、今回話さなかったネタ、採用しなかった案など もありますので、ご興味がありましたらご覧ください。 36 Version number here V00000

Slide 37

Slide 37 text

Thank you Red Hat is the world’s leading provider of enterprise open source software solutions. Award-winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. linkedin.com/company/red-hat facebook.com/redhat youtube.com/@redhat x.com/RedHat 37 Version number here V00000