受け入れやすい変化とそうでないもの
最近の悩みの一つは、「変化の許容量が違うチームメンバー同士で、どうやってチームを改善し続けるか」だ。悩みの内訳については先日書いた。
この件について、頼れる同僚がディスカッションに付き合ってくれたので、そこで出たアイデアをまとめておく。
* * *
変化に耐え得る総量があるのではないか
変化を受け入れられる総量が各々にあって、そのリソースを他の部分に割いているときはチームの改善をしにくいと感じる可能性があるかもしれない。例えば「新しい技術の導入にチャレンジしている途中だから、プロセスについてはしばらくこのままでいたい」と言った具合だ。
これは何となく分かる。
と言っても僕の場合は「実践する具体的内容」と「実践の方法」とはセットで替えていきたい派なので、「新しい技術を採用する」場面であれば、それに相応な開発プロセスに同時に替えたいけれど。例えば新しい技術採用が失敗し従来の技術に戻す可能性に備えて、いつもよりマメにリプランニングしスケジュールを丁寧にすり合わせるなどだ。
変化しやすい(しにくい)ジャンルがあるのではないか
「新しいライブラリならどんどん触って試してみたいけど、開発プロセスをこまめに変えるのは面倒くさい」といったように、ジャンルによって変化を受け入れやすいかどうかが変わる可能性もありそうだ。もちろんどのジャンルが受け入れやすいかは人によって違うだろう。
これはめちゃくちゃ分かる。
スポーツをしていてうまくいかないとき戦術より道具を変えるほうが簡単だし、格闘ゲームがうまくいかないとき練習メニューを変えるよりキャラクターを変えるほうが心理的に手を出しやすい。これは言い換えると、手っ取り早く責任を押し付けやすいものは何かという話になるのかもしれない。自分の行動に原因があると考えるより、道具やキャラクターに原因があると考えるほうが気楽だ。だからそちらの変化のほうが受け入れやすい。
変化させやすい「型」があるのではないか
人毎に固有の変化のキャパシティにフォーカスして変化量を決める(=改善内容を決める)のではなく、変化させやすい単位や型に合わせて変化量を決めるほうが効果的なのではないか、という話も出た(これは今までの「変化しやすいか否か」の軸ではなく「変化が効果的か否か」の軸での話なので、並列で扱うのはいびつだが目を瞑って欲しい)。
例えばスクラムがその例で、スクラム導入時に「まずはデイリースクラムだけを取り入れよう」と断片的に変化させるよりスクラムの型を丸ごと試したほうが効果を得やすい。
このように型に従うことで変化の効果を得やすい場面は多くあるだろう。"守破離" という言葉があるくらいだ。一方で「変化は小さく」という方針にも賛同できる。僕は何でも小さく始めようとしがちだ。これらは相反するとは限らないが、相反したときに自分がどういう行動を取りがちなのかを知っておきたいと思った。
改善活動のファシリテーションでは、「変化の受け入れやすさ」と「変化の効果の出やすさ」のバランスを取ることも考える必要があるのかもしれない。
* * *
今回はアイデアを出しただけなので結論などは特にない。チームの改善をファシリテーションするときは、こういったパラメータが複雑に絡み合っていることを理解しておくといいかもなあと思った程度だ。体系的な知識としてまとまっているのであればいつか学びたい。
そして、これだけ厄介なパラメータがある中で、専門家でも何でもないチームメンバーが自らの手で自律的な改善を実践しようとすることは、大変なことに違いない。少しでもその手引きができるようになりたいと改めて思う。
ここまで読んでくれてどうもありがとう。 記事を読んでくれて、応援してくれるあなたのおかげで、これからも書き続けることができます😌