「普通のアジャイル」のなにがダメのか？
Large-Scale Scrum(LeSS:大規模なアジャイル開発のフレームワーク)の勉強会「Less Study」、次回は明日開催の予定です。少人数で地道にちょっとずつ翻訳と解釈を進めてますので、良かったらご参加下さい。明日は前回からの続きで「待ち行列理論」と、滝川が「顧客価値による組織化」を担当する予定です。ちなみに滝川担当分は、翻訳はGoogle先生がほぼほぼカンペキにやってくださったので(最近のGoogle翻訳スゴイな！)、あとは発表の資料準備だけです、まぁ明日までになんとなかるでしょう。(たぶん)
さて、本題。
前回のLess Studyは珍しく初参加の方が何名かがいらっしゃいました。本編も割と初心者向けというか、スクラムは分かるけどLeSSは分からないという人のために、比較的噛み砕いた説明が多かったんですが、その傾向は懇親会でも続きました。そんな折、初参加の方からこんな質問を受けました。
「LeSSは他と比べるとどっちが大変なんですか？」
それに対し、オレが「普通のアジャイルで開発した場合と比べると……」とうっかり返してしまったところ、その場に居た既存メンバーのほぼ全員からコンマ2秒で
「「「普通の！？」」」
と総ツッコミを受けた次第です。言われてすぐアチャーッと自分の失敗に気付き、即座に訂正しました。
さて、オレはなにをやらかしたでしょうか？
以前、上記の記事でも書きましたが、「アジャイル」は開発・ビジネス・組織を少しでも良くするためのTIPSの集まりを指す言葉で、とても範囲が広く、またそれぞれのTIPSによって目的も用途も適用範囲も様々です。
ところが、「普通のアジャイル」なんて言い方をしてしまうと、アジャイルのどのプラクティス・どのフレームワークを指し示しているのか、主語が大きすぎて分からないんです。同じ開発現場は2つとありません。同じ「アジャイルな開発をやっている現場」でも当然その度合いや導入しているプラクティスは異なるのです。なので、「普通のアジャイル」などと言おうものなら「『普通』ってなんだよ！？」「俺の『普通』とお前の『普通』が同じだとでも思ってんのか！？」って指摘を受けるのは必然でしょう。今回もオレが指摘されたのはこの点でした。指し示す主語が曖昧すぎる、と。
要は「曖昧さを取り除いて、共通認識を得やすい言葉に置き換える」ことが必要です。じゃあどうすんのか、なんですけど、オレ個人が普段確認するのには、思考プロセスのフレームワークである「TOC(Theory of Constraints - 制約理論)」の中にあるチェックツール「CLR(Categories of Legitimate Reservation - 論理性の検証)」を用いています。使い方が難しい(特に他人に不用意に用いると他者を傷つけたり追い込んだりしてしまうことがある)んですが、自分で使う分には便利だと思っています。
- 意味の明瞭性
- 実体(事実)が存在するか
- 因果関係の存在
- 原因の不十分
- 追加の原因
- 原因と結果の逆転
- 予想される結果の存在
- 同語反復／循環論理
上記記事にもあるとおり、CLRのチェック項目は全部で8つあります。が、これは問題が発生した際の原因究明に使うものなので、そうではないケースでは上の2項目だけで十分だと思います。つまり「①言葉の意味が理解できて、②その言葉が指し示すものの存在の有無や大きさが確認できる」状態であれば問題ないと思います。
今回、オレはLeSSとの比較対象を列挙する際、「普通のアジャイルで開発した場合」と表現したものを「8人1チーム程度の一般的なお手本どおりのスクラムで開発した場合」と訂正しました。これでもまだ曖昧な内容ではあるんですが、あまり細かく定義しすぎると汎用性が失われますし、とりあえずこの内容で「まぁそれならいいんじゃない」とメンバーにもお許しいただけたので、本記事上でもよしとして頂けると嬉しく思います。
何事においても、言葉の意味は明確にし、誤解や拡大解釈を防ぐよう心がけることが必要です。CLRはシステム開発でも要件定義やテストの際に活用すると便利だと思っています。興味がある方はTOCやその教育(子供)向けのTOCfEに関する書籍が何冊か出ているほか、セミナー等も定期的に開催されていますので、良かったら調べて学んでみて下さい。……あ、でもCLRを普段の会話で使い過ぎると、「お前と話すのはめんどくさい」と周囲から煙たがられるのでご注意あれ。特に男性が女性に対して使い過ぎると喧嘩の原因になりかねません。使用はあくまで自己責任でお願いします。
