スクラムの捉え方メモ
RSGT2020直後時点、私自身のスクラムに対する捉え方を整理するためのメモ。
スクラムは、適応系のひとつの形。
究極的には、適応のためのフィードバックループの形成。
それができれば、PDCAでも、透明性・検査・適応でも、ふりかえりでも、モブワークでもなんでもいい。
究極的には、私たち人間が「適応を継続」できるか？
個人、チーム、組織それぞれ。
習慣にして継続できるかがすべて。
できないものはできなし、合わないものは合わない。
人間は、怠惰・脆弱であるため、うまく補強する。
・人間のプラスの部分であるの強化：マインドセット、エンゲージメント、モチベーション、など
・人間のマイナスの部分であるの強化：（人によらない）仕組み化、ロールの帽子
チーム、組織になると、いろいろなバイアスが絡んで複雑になる。
「適応を継続」ため、何かをできるかが？すべて、できなければ意味がない。
適応を継続するプロセスをどう構築するか？
たぶん、それだけ。
おそらく、適応系の基本は、
・現状の確認
・方向性の確認
・その差をどう埋めるか？材料に経験を使う。
スクラムフレームワーク
その中で、（ここではあえて）ソフトウェア開発（チーム）における適応フレームワークとして、スクラムがある。
ただの薄っぺらい枠組みなので、あとはいい感じに実装してください。
- 価値基準
- 人間のプラスの部分であるの強化に使っていると思うけど、正直まだよくわからない
- ロール
- スクラムイベント、成果物
- これらは、絶妙なバランスで、計算された、複雑に絡み合って、成り立っている芸術作品のようなもの。
- 三次元のだまし絵のように、一見訳がわからないが、
- それぞれのピースが、ソフトウェア開発（チーム）における
- すべての透明性・検査・適応を成り立たせるために、あらゆる角度で絡み合って、補強しあっている。
- 異常なまでに美しい。
- イベント、成果物を行うだけで、透明性が確立され、検査のタイミングが与えられる。
- そこまでできれば、最高のチームなんだから、「適応」はできるでしょ（知らんけど）
- 価値基準が違ったり、最高でなかったりするチームがイベントを行えば、ただの地獄
最高のチームが使えば、シャトルランを繰り返し、ソフトウェア開発の適応を早くできる！
めっちゃ強いチームがめっちゃ強くなれる
スクラムは、最高のチームが最高のパフォーマンスを出すために設計されているため、
そうじゃないのに、飛びついて使おうとするから、何かおかしくなる
ただのたプロセスフレームワーク、それ以外のいろいろは当然必要。
スクラムの欠点
スクラムは、ソフトウェア開発（チーム）に閉じているが、これが実際のビジネスとミスマッチを生んでいる。
より具体的には、PBIの作り方、順番の決め方。
市場からの適応フィードバックループは、枠組みの外。「価値」の適応を対象にしていない。
そのため、それを解決するために、
プロダクトマネジメント、リーンスタートアップ、デザイン思考、ディスカバリーループ、正しいものを正しく作るなどが模索されている。
そもそも、欧米文化（？）で生まれたものなので、日本文化で合わない
そう考えた上で（追記）
みんなが、スクラムフレームワークを使って、それぞれに実装している、だけ。
フレームワークの本質が見えてきて、フレームワークを無視しても、ぶっ壊しても、自分で作ってもいい、そのまま使ってもいい
最初からフレームワークを型通りに使わなくても、その中でうまく使っていけばいい。
（うまくいかないかもしれないけど）それはそれでいいじゃん
そもそも、合わないかもしれないし。
そう理解した上で、私は「好き」をどうするか？
「アジャイルやりたい」「スクラムやりたい」人にどう接する？
私自身の「好き」をあきらめたくないし、
「好きなものを嫌われない」をあきらめたくないなあ
今の私は『私は好きを諦めない』
