やりたいことができない場合は小さく分解すればいい

2017.01.31

ポイント

皆さんの現場では「ふりかえり」であがったTryはどれほど実行されているでしょうか？

「一見良さそうなTryが出て、チームもそのTryに合意しているが、次のふりかえりで聞いてみると実行されていない」という現象を見聞きします。特に手強いProblemに対するTryや、(壮大な遠い目標を掲げた)新しいチャレンジとしてのTryなどはその傾向は強くなります。
このようなパターンの場合、ふりかえりの会話で「◯◯のTryをやろうと思ったのですが、”いろいろ”あってできませんでした…」という会話が出てきます。

このパターンが続くと「結局Tryを出しても何も変わらない」と雰囲気が沈みがちになりチームのパフォーマンスが落ちたり、Problemが解決されず大きな問題が発生するといった悪影響が出てきます。このようなパターンが発生する原因はなんでしょうか？

これは【Tryが大きすぎる】【Tryが具体的でない】ことが多くの原因です。
日々のタスクもある中で、大きすぎたり、具体的な一歩が見えていないと「やるの大変だなぁ…」と気持ちになり、他のことに目移りしてしまい、なかなかそのTryに取り掛かれない状況になります。

Tryが大きすぎる

例えば「リリースサイクルが長い」というProblemがあり、原因の1つに「デプロイが手動」というのがあったとします。そして「CIを導入して完全に自動化されたデプロイメントパイプラインを構築する」というTryがあがったとします。

この「CIを導入して完全に自動化されたデプロイメントパイプラインを構築する」は、多くのチームにとって大きすぎるものとなります。
どれくらいが大きいか…というのはチームの練度やスキルセットによって変わりますが、これを見極めるのもポイントです。

これまで手動でデプロイをやってきたチームだと、「CIってなに？」「デプロイの自動化ってどうやってするの？」「一気にできるんだろうか？」という分からないこと、不安が多く出てきます。こうなるとなかなかその一歩が踏み出せなくなります。

そこで「CIを導入して完全に自動化されたデプロイメントパイプラインを構築する」を小さいActionに分解します。例えば「(何らかの)CIツールを導入する」「シンプルなデプロイの仕組みを1つ作る」「デプロイの結果をブラウザから見えるようにする」などです。

このように大きなTryを小さなActionに分解することで、最初の一歩を踏み出しやすくなります。また小さなActionにすることで作業をペアで進めたり、平行して進めることができるようになり、チームとしてとりかかることができます。それは改善の早さを上げ、学ぶことが増えることにもつながります。

Tryが具体的でない

「(何らかの)CIツールを導入する」「デプロイの結果をブラウザから見えるようにする」は小さなActionになり、とりかかりやすくなっていますが、もう一段具体化することでよりActionが明確になります。

「(何らかの)CIツールを導入する」は「CIツールにはJenkinsを使い、◯◯サーバーで稼働する」などと具体化します。こうすることで、いざやろうとした際に「何から手をつければ良いんだろう？」という状況を防ぐことができます。また事前にやらないといけないこと(この例だと◯◯サーバーを操作する権限など)も見えてきます。

Tryを具体的なActionに落とし込めないということは、チームでもイメージがすり合っていない可能性が高く、そのままTryしようとしてもムダが多くなり、冒頭の「◯◯のTryをやろうと思ったのですが、”いろいろ”あってできませんでした…」という状態になりがちです。

大きく具体的でないTryを小さな具体的なActionにすることで、ふりかえり自体も引き締まり、改善の早さも目に見えて変わってきます。

1つ別の視点でポイントがあるとすれば、マネージャーがあれこれ指示をするのでなく【チーム自身で考えてActionを出してもらうように促す】ことです。これをすることで「自律的に考え、自己改善ができるチーム」に近づいていきます。
＃促すためのポイントはいくつかありますが、またそれは別のエントリで書きます。