プロセスがリバウンドのように太っていく

おはこんばんはー。りょくちゃです。

複数の開発チームが成果物をメインブランチに統合するときにマージおじさんが現れて一日かけて成果物を統合してくれています。

本当かどうかはさておき、複数の開発がメインブランチから切り出したブランチで開発を行った後、統合するときに（競合箇所のマージなどの）問題が頻繁に起こるのを避けようとするとまとめてせーののタイミングで定期的に統合する気持ちはわかります。

気持ちはわかりつつも、自分は複数の開発を行っていても常にメインブランチに統合して壊れたら直してリリースする開発が好きなのですが、そこからは離れていっていることがわかります。

こんな時、自分が意識することがあります。合言葉は「臭いものに蓋をしない」です。

パッチ対応から遠いところに本当の問題がある

まず、先手と後手の話をしていきます。

開発するときに起きる問題に先手で対応するか後手で対応するかで違いがあります。問題に気付いてから対処しようとすると後手のパッチ対応になってどんどん時間に余裕がなくなります。

例えば、テストが後回しになるのも残業が発生するのも開発アイテムが完了しないのも同じ現象です。

臭いものに蓋をすると余裕がなくなっていく

少しだけスケールの大きな例え話をします。回帰テストのテストケースが膨大になると、組織はテスト専門チームを作ります。

さらに、テストケースが増えてきたら、外部のテスト組織に業務委託を頼みます。打つ手がどんどんなくなってきて、外部に頼り自分の組織で余裕がなくなっていく様子がわかります。

その現象を生むもとのプロセスに改善を入れるのは当たり前の話なんですが、問題を検出した箇所からは遠いところに修正を入れる必要があるので認知的な努力が必要なのが難しいところです。

そこで後手のパッチ対応を行うと「臭いものに蓋」をすることになり、辛いことが増していくという理屈です。

パッチ対応を洞察するには短期的な解決になっていないか問いかける

問題には短期的な解決と長期的な解決があります。どちらも余裕を作り出しますが、パッチ対応は短期的な解決が目立ちます。「ダブルチェックをする」「レビューをする」のようなアクションが立案されると感じ取ることができます。

マージおじさんを生み出しているチームではパッチ対応が常習化しているかもしれません。パッチおじさんで生まれる余裕は一時的なものでマージおじさんはいずれ疲れて、マージ疲れから競合解決に失敗するかもしれません。こうして取りこぼした問題をパッチ対応で解決するともっと重厚なプロセスになっていきます。何ということでしょう！まるでリバウンドをするようにプロセスが太っていきます！

もとの話に戻ると、解決のためには根本的な問題にアプローチすることを検討します。自分はスクラムマスターなので、ふりかえりの練度を高めていけるように支援することを意識します。

この場合、本当の問題は長期的な解決を考えることでわかります。回帰テストの例では、「テストケースが増えているのはどうしてか？」「テストケースはどうなっているのが理想的か」について考えることができます。

アクションとしては、ふりかえりで今パッチ対応していることに目を向けて、本当の問題を見つける方針で議論してみるのはどうでしょうか。では、また次回！