フレームワーク導入の意識（Framework Adoption Mindset）

フレームワークの「良し悪し」より先に問われるのは、導入する側・される側の意識の状態である。これはスクラムに限らず、あらゆるフレームワーク・手法・ツールの導入に共通する問題。

アジャイルソフトウェア開発、テスト駆動開発、リファクタリング、さまざまなアジャイルの手法は、誤解されて利用され、うまくいかず、「うまくいかないのは方法が悪いからだ」「うまくいかないのは利用側が正しく扱ってないからだ」という対立する主張を繰り返してきている。

どんなフレームワークを使っていても、使っている人の意識の状態が問題の本質。

具体例：ScrumButとスクラムウォーターフォール

ScrumButとは「スクラムを採用しているが、〇〇はやっていない」という部分適用の実態を指す言葉。

スプリントという形式だけを取り入れながら、実態は計画駆動・承認フローのままという歪んだ適用。スクラムの意図とはかけ離れているが、現場では頻繁に起きる。

これらに対して、

スクラム側の説明：「スクラムを正しく理解していない」採用側の説明：「スクラムはそのままは、うちの現場ではできない」批判的な見方：

スクラムの防御的姿勢の文脈： このような意図しない適用が繰り返されてきた歴史が、スクラム側の防衛的な姿勢をもたらした側面があるように推測する。

何をどう使おうが、その状況に当事者が満足していれば問題ない。意見がわかれるのは、うまくいっていない時に限られる。

→ 詳細は scrum-framework-discourse を参照。

方法論・フレームワークの問題を指摘するだけでは不十分。採用する側の意識を問い直すことがセットで必要：

「やってみないとわからない」はそのとおり。しかし「やってみてどうだったか」についてのシングルループ学習だけでなく、ダブルループ学習が必要

これらの点については、今更Takeshiが言うまでもなく、ある程度熟達している人なら常に問うべき内容である。

david-hawkins のパワーvsフォースで言えば：

フォース（強制・義務・恐怖・「やらされ感」）で導入されたフレームワークは、どれだけ正しく実施されても本質的な変化をもたらしにくい。
- うまくいかなかった場合、現実に向き合えずに他責になるか、反転して強い自責となり現実に応答するよりも自分を責める方向に向かう。
パワー（内発的動機・「やりたい」・現場の切実な問い）から始まったとき、フレームワークは道具として機能する。
- うまくいかなかった時は、他責にも強い自責にもならず、現実に向き合い応答する内省がはじまる。

すべてはきかっけに過ぎないので、意識状態は変りうる。ただ当事者が自覚し認知する必要があるだけ。

すべてにおいて問われること：

「誰のどの意識からの行動か？」「不快に留まっているのかどうか」「今何を感じているのか」

now-here の状態観察・negative-capability の「不快に留まる」能力——これらはフレームワーク導入の場においても同様に問われる。