木下斉さんと電通ホワイト化を成し遂げた鬼時短の著者である小柳はじめさんの対談でオプトイン・オプトアウトという承認プロセスについて紹介されています。

今回はそこに「disagree&commit」というオプトアウトを実現するための手法を加えて、スピード感のあるシステム開発のレビューフローという具体的な活用について紹介します。

〇オプトイン・オプトアウト

鬼時短では、それぞれの承認プロセスについて、下記のように説明されています。

また、スピード感のある承認フローの実現のために「3営業日オプトアウト型」が推奨されています。

〇Disagree&Commit

オプトイン型の承認フローは承認者が承認・不承認を即断即決できるだけの教育と訓練を受けていることを前提とした仕組みです。
しかし、承認者がそのような能力を備えていない場合に、オプトアウト型を取り入れることに成功しても、承認後に「待った」が入ることがよくあります。

そのような「待った」を抑制するための方法の一つが「Disagree & Commit」です。
承認後の待ったは、承認時は「よさそう」という消極的な抵抗が後になって大きくなることで発生します。（それって、オプトアウトの意味ないじゃん。と思いますが、オプトアウトの運用直後ではよくあることなのです。。。）

Disagree & Commitはミーティングの参加者全員の「進めてよい」と積極的なコミットメントを必要とする合意形成で、このように語りかけます。

この方法は後から「待った」が入る影響が大きすぎるケースで活用する手段として懐に入れておくのが良いかと思います。
また、「プロダクトマネージャーのしごと」という書籍で詳細な運用方法が紹介されています。

〇高速なレビューフローの紹介

私の開発チームでのオプトイン・オプトアウト・Disagree & Commitの活用事例をご紹介します。

プログラムの修正内容のレビュー・承認について下記のルールを定めています。

基本的には二人からの承認を得られれば良しとしますが、レビューが難しい修正に関してはレビューが進まないという課題が発生するため、その場合はメンバーを集めて一気に承認を済ませます。
正直、未レビューの修正が溜まっていくということは起きてしまいますが、このようなハイブリッドなレビューフローをチームに落とし込むことで、確実にレビューのスピード感は上がっています。

チーム運営の参考になれば幸いです。
最後までお読みいただきありがとうございました。