チームを不安定な状況に置くことで改善する

ネットを見ていても、アジャイル開発系の書籍を読んでいても、もう、改善することがあたかも当然のような風潮です。

でもですね、じゃあ、月曜日に向かう職場、チームの中で改善って存在するのでしょうか。

どうでしょう。アジャイルの書籍に書いていあるように改善するチームですか。

改善とは何か

まずは辞書を引きましょう。

「悪いところを改めてよくすること」をする行為、でしょうか。この行為をするためには、「悪いところ」を認識する必要があります。

「悪いところ」を認識することは誰かといえば、チームであればメンバ全員になります。

「改める」のは誰か。もちろん、チームのメンバ全員です。

「チームのメンバが悪いところを認識して、改めて今より良くする活動をする」ということが改善の目的になります。

なぜあなたのチームで改善できないか

どうして書籍や他社のチームでは改善活動ができているのに自分のチームでは改善しようとしないのでしょうか。

それは、現状が安定しているからです。

ここでいう安定とは最適化されている、洗練されている、という意味はこれっぽっちも、１ミリも含めていません。どちらかと言えばゼロ％です。

歪でも、無駄が多くても、何度も手戻りしても、そのプロセスがチームのお作法として、暗黙に期待される振る舞いとしてのプロトコルであり、それを習い、それに慣れてしまっていたら、そうした所作をすることでチームの運営が回りますから、そうした状態に属することに違和感を持たないのです。

それが続くことでメンバは「安定」してる状態を得られるわけです。

この安定した状態には「悪いところ」を識別、認知する方法が存在しないのです。ですから、「改めなくては」と誰も思わないのです。

改善活動を始めるにあたって

改善は、安定した状態を変化させる影響力を持っています。ですから、改善はチームに対し変化を要求するということです。

安定している状態のチームに突然、

「改善しよう！」

と言っても受け入れられないのは、歪や無駄が多くてもチームが安定しているからです。

そうした状態を動かすためにはwhyがないとそう易々とは付き合ってくれません。

つまり、「悪いところ」を示し、それを変化、変えることでチームにメリットが得られることを理解してもらわなければなりません。だからwhyが必要なのです。

改善は苦痛である

安定した状態のチームを改善するということは、安定した状態を揺り動かすということです。それは

チームを一時的に且つ、適度に不安定にする

ということをこれから行うということに腹を括らなければなりません。だって、安定を壊すことで不安定という苦痛を体験させることになるのですから。

不安定にするわけですから、今までなかったコミュニケーションが生まれて当然です。それは、意見の言い合いであったり、衝突であったりするのです。そうしたことを改善をする前に予測し、それが生じた際にどのようにファシリテートしていくか、その方向性、決断する際の判断基準は用意しておく方が良いでしょう。

例えば、現状より作業量が減るなら続ける、など定量的に計測でき、比較できる指標を判断基準にするのがチームの中で共通理解を得やすいです。

それでもなお、改善は必要です。

なぜなら、改善は変化することであり、変化だけが新しい体験の機会であり、学習と成長に繋がるからです。

月曜からチームを少しだけ、不安定な状態にしてみましょう。