AI Slopを生まないPlatform Service設計

by skijima404

Embed

Start on current slide

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 ﬁx 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