ベストプラクティスは全員にとってベストなのか？

全国1000人のエンタープライズベストプラクティスマニアのみなさんこんにちは。

Esther Derbyさんといえば、アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引きの作者で有名ですが、最近のブログ記事、Seven Agile Best Practicesが良い内容だったので、紹介します。

アジャイル開発でもクラウド導入でもDevOps推進でもいきなりベストプラクティス教えてほしい、とかどうやったら一番うまくいきますかとか聞かれることがありますが、全部に適用できるようなものはありません。売っているプラクティスを買ってきてうまくいくのであれば、もっと高い金額で売るでしょうし、次から次に新しいものが出てくるはずがありません。またたとえうまくいったとしても自分たちで変化に対応できなければいずれ陳腐化していきます。

本当に大事なのは自分たちの問題だと認識して当事者として考えて行動し続けることです。

アジャイルの7つのベストプラクティス

最近、見知らぬ人が自分にアジャイルのベストプラクティスを教えようと言ってきた。

自分は、広く適用可能な「一般的に良いプラクティス」はあると考えている。自分の経験では、ベストプラクティスを探すことは多くの場合銀の弾丸を探すことであり、複雑な問題を簡単に解決するソリューションへの欲求の裏返しに他ならない。これは、システムを見てそれを進化させ能力を身に着けていく、という難しい作業をショートカットしようとしているものであり、成功するのをほとんど見たことがない。

とはいえ、自分のプラクティスの1つは思い込みに挑むというものなので、ベストプラクティスはないという自分の思い込みに挑んでみた。そこで、たぶん自分に教えようとしてくれる人の考えにはないいくつかのことを思いついたので以下に紹介しよう。

#1 解決しようとしている問題について深く考える

まず最初に、どんな問題を解決しようとしているのか、それは誰のためなのか、どんな利点を産むのかについて理解する。これが理解できないなら、うまくいくかどうかは選んだソリューション次第になってしまう。

#2 問題の根本原因に関する思い込みに疑問をなげかける

どのように作業が進むのか、どのように人が作業するのかに関する思い込みが、探求すべきソリューションの領域を決めてしまう。たとえば、スプリントの最後までにストーリーが完了しないのは十分な責任感がないからだ、と思い込んでしまっていたら、チーム内の作業フローやチーム間の依存関係を検討してみようとは思わないだろう。

根本原因は1つとは限らない点には注意が必要だ。複雑なシステムにおいては、複数の絡まりあった原因があることが多い。全てが繋がっており、1つを変えれば多くが変わることもある。全部の根本原因を予想することはできないが、いくつかを予想することはできるはずで、それによって取るべきアクションが変わる。

#3 現在のシステムと、それがどのように問題に繋がっているかを理解する。さらにそれが問題解決にどのように役立つかを理解する

システムはふるまいを決める。あなたが良くみるパターンは、持っているシステムから生まれてくる。システムについて知っていることを、CDE・DOE・影響マップ・リワードマップ・バリューストリームマップなどを使ってスケッチしてみよう。どんな図でもシステムについてよく知る手助けとなるはずだ。どの要素を変更できるか、どんな影響があらわれそうかを検討するために、これらの図を使う。

#4 状況を改善するための候補となるアクションを最低3つ調査する。ソリューションを売っている人の口車に乗らないこと

もし3つの異なるアプローチが思いつかないのであれば、それはまだ十分に考えきれていない。たくさんの解決候補策を考えることは、状況の理解を深めてくれる。

どうやって問題のパターンに役立ちそうな要素に働きかけるかを考えること。似たような3つのアプローチ(たとえばツールAかBかCを使うべき？みたいなものだ)の比較に限定しないこと。

役にたっているものから学ぶこと。ただしただそれを真似して取り入れるだけではいけない。どこを変えられて、どこは厳密に従うべきなのかを理解する必要がある。この手の学びは理論の探求と実践から得られる。

銀の弾丸などないのだ。

#5 より効果的に作用しより良い結果を得るために実験する

大きな変更は存続の危機のような気持ちになる。小さな変更は学習をサポートする。

#6 複数の実験をおこない結果を検証する。実際に得られた結果をもとに調整する

自分が高校と大学で化学の授業を受けていた時は「実験」は期待した正しい結果が得られた。だが、本当の実験は「学び」についてのものである。特定の技術的プラクティスを適用するために、なんらかのスキルを向上させたり異なるレベルでの理解を促進する必要がある、ということを学ぶかもしれない。アーキテクチャーが自治的なチームの利点を妨げていることを学ぶかもしれない。いずれにせよ、学びがアプローチの見直しの手助けになる。

裏付けとなるデータ、そうではないデータを見てみること。良い方向に向かっているとしたら効果をより大きくするために何ができるかを考えること。もしそれが機能性をそぐような効果がでた場合にどうやってそれを緩和するかを考えること。

#7 問題を解決するためにインクリメンタルかつイテレーティブに進めること

1つのビッグバンなソリューションを選んでそれを展開していくのは真のアジャイルなやり方ではない。試してみて、そこから学び、どのようにシステムが変わったのかを見るようにしよう。問題についてより多く学べて、副作用を観察する機会も得られる。他の可能性や途中で現れた機会に対してオープンであるようにしよう。

これらのベストプラクティスは、自分のコンテキストや組織、その中の人にあったアプローチへとあなたを導いてくれるだろう。それこそがあなたにとってのベストプラクティスであり、他の組織で異なるコンテキストのもとで発生する問題に対してうまくいく何かがあなたにとってのベストプラクティスなわけではない。あなたやあなたの周りの人がそこでのアプローチへの改善に取り組むことで、みんながそれをサポートするようになる。

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料）