開発フローを改善したいとき、目的や目指したい姿を明確にするのは大前提だが、さらに開発フロー全体の変更しやすい・変更しにくいところを理解してから設計と改善を実施した方がいいと考えている。
開発フローには、事業の特性上もしくは組織の歴史的経緯でその組織特有の変更しにくい部分が存在している。状況によって様々だが、例えば、リリースの曜日、レビューやリリース承認プロセス、ミーティングの頻度などがあり得るだろう。
そして改善を実施するときのよくある失敗は、いきなり理想のフローを設計し、変更しにくい部分も含めてたくさん変えてしまうことだ。変更しにくい部分を同時に一気に変えようとすると、その変更の関係者が増え、反発が起きやすくなる。反発が起きると、良い方向に向かうはずの変更まで含めて「全部失敗だった」となってしまい、何も変えられずに失敗するケースが多い。
そこで次の2つを意識すると良い。
まず、変更しにくいところを無理に変更せず、変更しやすいところだけを調整する。例えばリリース省力化をしたいとき、リリース承認プロセス自体を廃止できないとしても、承認のために確認する項目はある程度簡単に変更して効率化する、などがあるだろう。
次に、本当に大事な変更と考えるなら、変更しにくいところを1つだけ選んで改善する。例えばリリースサイクルを短縮するためにリリース曜日を変える必要があるなら、同時にリリース承認プロセスまで変えようとしない。その代わりに、まずリリース曜日を変える変更をし、それがうまくいったら続いてリリース承認プロセスの変更に進む。変更しにくいところを改善すると必ず何らかの問題が起きるため、このように1つずつ進めることで、変更で起きた問題に1つずつ対処できる。
このように、変更しやすい部分だけを改善する・変更しにくい部分は1つずつ改善するの2つを意識することで、スムーズな変更を実施できると考えている。目的や目指したい姿が明確であることは大前提として、さらに変更をスムーズにするために試してみてほしい。
こういう話について以下の発表資料でも言及しているので、良ければ見てみてください。 speakerdeck.com
