生き生きとした庭

スクラムを巡る言説——フレームワーク推進言説へのモヤモヤ

9 min read

スクラムを巡る言説——フレームワーク推進言説へのモヤモヤ

スクラム自体への批判ではなく、「フレームワークとしてやれ」という言説がもたらす構造的な問題への問い。同様の問題はあらゆるフレームワーク推進言説に当てはまる。

→ スクラムの概要・評価・関連リンクは scrum を参照

「フレームワークとしてやれ」言説の問題

XP白本初版が「すべてやれ」と言いすぎたのと対称的に、スクラムは「フレームワークとしてやれ」という方向に行きすぎた、という感覚がある。ただし、これはスクラム公式定義そのものへの批判というより、スクラムを正解として推進する言説への批判として捉えた方が正確かもしれない。

→ ga-shu-ha-ri で論じる「守から入る弊害」と同じ構造。自分で苦しまずに最初からフレームワークを先に与えると智慧が刻まれない可能性がある。

失敗解釈が偏りやすい構造

スクラムは「問題を明るみにするフレームワーク」という立ち位置を取る。この立ち位置と「中核の部分適用を認めない」の組み合わせで、適用失敗の解釈が「Scrumが不適合だった」ではなく「Scrumを十分に実施していなかった」に偏りやすい構造が生まれる。

「問題を見える化する」という主張は Scrum適用中に発生する問題 への対応論理であって、「Scrumを適用したこと自体がコンテキストアンマッチだった」というメタレベルの問いは、Scrumのフレームワークの内側では扱われにくい。

ポパーの反証可能性とまったく同じではないが（Scrumは科学理論ではなく実務フレームワーク）、失敗時の説明責任が外部化されやすい言説構造を持つという意味では似た問題がある。

「スクラムがうまくいかない」は「スクラムが合わなかった」とはならず「理解が不足していた」「うまくできなかった」に着地しやすい。本来は「そのコンテキストではスクラムが合わなかった」という評価も選択肢にあるのが自然であり、「合わないなら前に戻す」は正当な判断である。しかし、その状況を「スクラムを正しく理解し実践できていないから」という理由で批判するのは防衛的な正当化にも感じる。

間違ってはいない。しかし、そのとおりとも言えない。——Takeshi

「正しい処方箋」が「処方箋を受け入れられない組織の現実」を十分に見ていない。negative-capability的に言えば、「うまくいかない不快」にともに留まる姿勢が、推進言説の中に少ないように思える。

一方で、スクラムを誤解したまま採用する例も枚挙にいとまがないように思える。これは方法論に真摯に向き合う人物にとっては納得できないことも理解できる。（ScrumButやスクラムウォーターフォールなどの詳しい考察は → framework-adoption-mindset ）

フレームワークとしての成功事例とコンテキスト重視の姿勢

  • 初期の事例で有名なのは、SalesForceの全社一斉スクラム化。（Mike Cohn氏が関わる）
    • 他にも数多くある。
  • 選択肢としては「あり」であるが「万能」ではないし「それだけ」でもない
    • 段階的変容が「正解」でもない
  • 大事なのは「うまくいかなかった」ことを直視すること「コンテキスト」をよく観察すること
    • 現場が好奇心に溢れている、あるいは、過去に痛い失敗をしている場合、フレームワークは効果を発揮しやすい傾向がある
  • 全てはコンテキストからはじまる（＝つまりパタン）
  • participatory-knowing-complementarity

「スクラムが合わない」を示せるか：誠意の指標

フレームワーク提供者・推進者の誠意は、「自分のフレームワークが合わない状況を具体的に示せるか」で測れる。2011年に参加した James CoplienのCSM研修では「スクラムに向かない状況」を明示していたので誠意を感じた。現在の主流CSM/PSM研修でこの観点がどの程度扱われているかは未確認。明示的に扱われているなら訂正が必要である。

対照：ScrumPatternsのアプローチ

CoplienらのA Scrum Book（ScrumPatterns）は、パタン・ランゲージ的な漸進的適用を示唆している。パタンは「このコンテキストでこのフォースが働くなら、この解決策が有効」という形式——適用の是非がコンテキストに委ねられる。Scrum.orgにあるScrumPatternsの紹介でも「1つずつ採用し、うまくいかなければ別を試す」と書いている（Scrum Patterns—Putting Scrum into Practice | Scrum.org）。長年パタン・ランゲージを追求してきたCoplienならでは、の誠実さがあるように感じる。

Takeshiも以下の記事のように「段階的漸進的導入」を勧めている。 → 「アジャイル導入」や「プラクティス導入」うまくいかないと嘆くあなたに送るたったひとつのアドバイス

なお、この「コンテキストに合うパタンを順次適用する」アプローチの原典として、Amr Elssamadisyの Agile Adoption Patterns: A Roadmap to Organizational Success（2008）がある。アジャイルのプラクティスをパタンに分解し、それぞれのコンテキストに合うものを順次適用することを推奨する書籍で、一読を勧める。AAPを読むと、TDDですらも複数のパタンのセットであり、スクラム自体もコンパクトになってはいるが、複数のパタンの組みわせであることが用意に理解できる。

アジャイルソフトウェア開発でシップするプロダクトが、小さなユーザーストーリーの漸進的な開発で作られていくように、アジャイルチームも、小さくスライスされたチームのためのユーザーストーリー（＝パタン、プラクティス）を少しづつ積み上げていった結果、いつしか立派なアジャイルチームになっていた、というのが理想像。

関連ページ

グラフビュー

バックリンク