センスメイキング(Sense-making)は、最初に思い浮かんだソリューションにチームが飛び付くことを防いでくれる。Cynefin(クネビン)フレームワークは、情報に基づいたセンスメイキング後のレトロスペクティブで、チームが何をなすべきかを決める上での指針となる。Cynefinを使うことで、データ収集から洞察の獲得へというレトロスペクティブの転換を、さらに進めることが可能になるのだ。
アジャイルコーチのEnrico Teotti氏はAginext 2021で、アジャイルレトロスペクティブにおけるCynefinの適用について講演した。
Cynefinは、Teotti氏によれば、レトロスペクティブをリードする上での指針となり、レトロスペクティブで現れた問題の解決をナビゲートする、意思決定支援フレームワークである。問題の性質によっては、次の適切なステップを選択する上でも有効である。
ファシリテータは、そのイテレーションにおけるデータ収集を支援し、レトロスペクティブをペースダウンすることによって、最初に思いついたソリューションへの偏重を回避し、センスメイキングの実施をサポートすることができる。
クラシックな影響の輪(>circles of influences)の考え方によれば、チームがコントロールできるものがあり、影響を与えられるものがあり、チームにとって対応することしかできない企業ポリシやその他の要因からなるスープ(Soup)がある。Teotti氏は、意思決定者を生データに触れさせる手段として、仲介者の解釈を削減することによって、仲介者によるセンスメイキングを排除するように提案している。それにより、チームレトロスペクティブで出されたストーリないしデータポイントを、その情報を必要とする(チーム外の)人の手に届けることが可能になるのだ。
Teotti氏はこのCynefinを、自分たちの周りに何があるかを見て、それを理解し、次のアクションの情報とするためのレンズセットとして使うことを提案する。いつもレトロスペクティブで行っているように、振り返って調整(reflect and adjust)するのだ — そのアプローチが自分たちに向いていなければ、別の方法を試そう。
Cynefinをアジャイルレトロスペクティブで使用する方法について、Enrico Teotti氏に聞いた。
InfoQ: レトロスペクティブにおいて、データ収集とクラスタリングという従来型のアプローチを使った場合、どのような限界があるのでしょう？
Enrico Teotti: イテレーションレトロスペクティブでデータを収集する時に、すでにソリューションを検討しているチームが多いのです。例えば、stopの列に"ペアプログラミングを止める"というカードがあって、2分程度の議論が行われると、もうそれでペアプログラミングは行われなくなる、といったような事があります。"何か"を確認して検討する前に、"どうするのか"に飛躍してしまっているのです。チームがアジャイルプラクティスやレトロスペクティブに不慣れで、問題が明確なものであるならば、これもありかも知れません。
データを取得して、クラスタリングして、アクションを決めていれば、いつもの考え方でビジネスを続けることになります。アイデアの多様化や多様な思考のチャンスは、そこには存在しません。
さらにそこには、すべての問題には等しく解決策がある、という仮定が底辺にあります。しかし現実には、その中の一部は、影響を受けることしかできないような"邪悪な問題(wicked issues)"なのです。
InfoQ: 複雑な問題に対処する上で、Cynefinはどのように役立つのでしょうか？
Teotti: "複雑"ということばは乱雑に使われ過ぎているので、読者のために明確化したいと思います。複雑というのは、"非常に難しい"という意味ではありません。原因と結果が遡及的一貫性(retrospective coherence)によってのみ明確化するような扱いにくい領域、特定の行動を指向する領域、影響を与えることしかできない領域、という意味なのです。
ソースコード内の"バグ#1234を修正する"ことを考えてみましょう。最高か、それに準ずるプラクティスを実践していて、すでに十分な期間を経ているのならば、ソースコード内にその問題を見つけて、おそらくは修正することでしょう。
ここでCynefinが行うのは、分類・検知・応答(明確な問題の場合)であり、分析・検知・応答(複雑な問題の場合)です。
次に、組織レベルでバグ率を低減することを考えてみましょう。今あなたの眼前にあるのは、人々とシステムが入り混じっている社会技術(socio-technical)システムです。複雑な問題を処理するためにCynefinが提案するのは、精査(probe)・感知(sense)・反応(respond)という、実験的(あえて言えば、アジャイルな)アプローチです。システムに影響を与えるためには、いくつかの証拠(レトロスペクティブで得たデータ)に裏付けられた、一貫性のある仮説を立てた上で、安全な失敗の可能な実験を作成し、成功または失敗の指標を明確化しておきます。
ここで"Design Unbound"という、APJの素晴らしい書籍からの引用を紹介したいと思います。
"問題の本質を科学的あるいは技術的なものと限定して認識し、関連するコンテキストを排除するならば、たとえ問題が複雑なものであったとしても、一般的に単純な科学モデルないしエンジニアリングモデルで解決することが可能です。
一方でこれらの問題が、社会的、政治的、経済的、文化的な信念体系の変化を通じて体系化された、人間環境の中に根付いたものであると理解するならば、私たちは複雑性の領域の中にいるのです。"
”Design Unbound Designing for emergence in a white water world”より
InfoQ: レトロスペクティブにおけるデータ収集から洞察獲得への転換を進めるには、どうすればよいのでしょうか？
Teotti: チームを取り巻く環境によって違います。データから洞察へというこの転換が、平均的なレトロスペクティブと強力なレトロスペクティブとの違いを生み出すのです。
ファシリテータとしては、多様性のある思考の発展を促すために、さらなる促進策を試行し、推奨することができます。非常に強く反対するグループも一部にはあります。その中から、一部のグループに対しては、レトロの終わりにROTI(Return On Time Invested、時間投資対効果)を実行することが最善のアプローチであることが分かりました -- 今回のレトロがどの程度有意義な時間であったか、気に入ったことは何か、1ポイント高くなったと認められる改善点は何か、といったことを、0から4の間で答えてもらいます(詳細は"Measure the return of time invested"を参照)。それによって、振り返りの不足している点を明らかにするのです。
もうひとつの重要なポイントは、イテレーションのレトロスペクティブを行う目的を明確に示すことです。これには原則の12項を使用するとよいでしょう。すなわち、
チームは定期的に、効率性を向上する方法を振り返り、それに従って行動を変更し調整する。
この"振り返り"が大切なのです。これを行うことで、何がどの分野に属しているのかを認識し、多様性のある思考を促進することが可能になります。
このアプローチの"トレードオフ"は、問題への対応方法ではなく、問題を理解するための時間が必要である、という点です。
InfoQ: 時間のバランスを取るには、どうすればよいのでしょう？問題を理解する時間を十分に確保するには、何をすればよいのでしょうか？
Teotti: 場合によりますね。グループにとって何が重要か、が問題です。グループの管理下にあるもの、影響下にあるもの、それらの対象外であるもの、Diana Larsen氏の言う"スープ(Soup)"を視覚化することも必要です。まずは、管理下にあるものに注目しましょう。その上で、それらの問題を解決するために必要なエネルギを視覚化するのです。そうすることで、すべての項目に対処するのではなく、振り返りにおいて重視すべき項目を選択することが可能になります。
InfoQ: レトロスペクティブを促進する上で、何か秘訣(Tip)はありますか？
Teotti: Tip #1: すべてのレトロスペクティブで、グループからのフィードバックを集めること。これはグループとあなたのためです。パターンと異常値を見つけ出して、次のレトロスペクティブに活かしてください。
このフィードバック収集に長時間の議論は必要ありません。終了前の5分か10分で十分です(そして、必ず時間通りに終了してください)。フィードバックを十分に反映する時間がないかも知れませんが、そのような場合はデータのパターンから明らかになるでしょう。私が口頭でフィードバックを求める場合は、30秒間を与えるか、サイレントアクティビティを使用します。最後の5分か10分を、フィードバックを獲得するための既定の時間にしておくことが大切です。
Tip #2: レトロスペクティブの目的を極めて明確なものにしておくこと。ここではマニフェストの原則12項に加えて、行動に先んじる振り返りの重要性を強調しておきたいと思います。
Tip #3: ファシリテータにとって、Cynefinの背景にあるセオリには大きなメリットがあります。私たちを取り巻くドメインに一度気付けば、それらを無視することはできなくなるでしょう。レトロスペクティブは参加者にとってメリットのある場合も、そうでない場合もあります。ですから私は通常、グループにはCynefin理論を導入しません。