「GenAIはScrumイベントを速くしない」を読んだ感想

記事の主張：速いイベントは共通理解を作らず飛ばしてしまう。だからAIは「速さ」でなく「見落としを拾う・深掘り・協働」に使う

突き合わせてみたら、うちのAI/プロセスの使い方は3か所でAvoid側に寄っていた

1. 共通理解を飛ばす — PBIのAI生成（偽の合意）

PBIをAIに生成させるテンプレを作ったが、記事ではこれはAvoid（NG）だった

理由は品質ではなく偽の合意：完成済みに見えると皆が頷くだけで、各自が違うものを想像したまま合意したつもりになる

実際うちも全体では合意していたが、全員が腹落ちしていたかは怪しい

→ 次にPBIを扱うとき「できてる」で素通りさせず、who/why/何を解決するかをチームで会話する

2. フィードバックを飛ばす — show & play（Sprint Review）

今のレビューは「見せて語る」型で、その場は問題なく見えてしまう

だがユーザーの詰まり・認識ズレは、STGや本番に出てから問い合わせとして遅れて表面化している

→ 次のレビューで、デモの後に1つだけユーザー（or近い人）に具体的タスクを操作してもらう枠を試し、STG/本番の問い合わせと突き合わせる

3. 本音を飛ばす — 文字起こしと心理的安全性

うちは全イベントで一律に文字起こしを使っているが、記事はレトロスペクティブだけは録音・文字起こしを避けよと例外扱い

理由はレトロスペクティブが本音で問題を出し合う場だから。記録があると「残したくない」で口が重くなる

実際、自分自身もレトロスペクティブで本音を言えなかったことが何度もあった

→ 次のレトロスペクティブで文字起こし・録音を一度止め、発言の率直さが変わるか試す

感想

スクラムイベントに生成AIを使う「条件」が明確だったのが良かった（Consider/Avoidの線引き）

ただ結局はチーム力がキーだと思う。雑にAIを入れるのではなく、目的を全メンバーが言語化できるまで腹落ちしてから入れないと意味がない

これはSDDのような開発でも同じ。手段の前に目的の共通理解

「AIはスピードを出すが理解が取り残される」件は実感がある

例：ツールを自作したとき、アーキテクチャを特に考慮しないまま進めてしまった。速いが設計の理解は後回しになっていた

最近スピード重視の記事が多い傾向を感じる。スピードと同じくらい理解と価値を大事にしたい