各個撃破 - TrickDiary

いまさらながら反応してみるお。自分が考えてるようなことも含め概ね案は既に出尽くしてるように思うのですが、自分が効率化の為にやってることのひとつである各個撃破がでてないようなんで、ちょっと言及してみる。

ソフトウェア開発においての各個撃破は、大小様々なタスクに対しそれらのタスクを処理するのにとにかくすぐに片付けることができる小さなタスクから優先して片付け、大きなタスクも小さなタスクに分解してサクサクとタスクの数を減らしていくことです。もちろん他の要件も加味してタスクを処理する順番を決める必要はありますが、基本的には小さなタスクから。

こうするとなにがいいかと言うと...

小さなタスクであれば簡単に数をこなせるのでフロー状態への移行が容易くなる。
一般的にすぐにやれば５分で済むタスクでも１時間ほっとけば１０分かかるようになり１日ほっとけば１時間かかるようになり１週間ほっとけば１日かかるようになる・・・という時間の経過とともにそのタスクを処理する時間が肥大化する現象もソフトウェア開発においては別段珍しいことではなく、タスクが肥大化する前に処理してしまうことで時間と労力の節約になる。
不確定要素の数を常により少ない状態にすることができ、スケジュール管理上好ましい。特にバグに関しては丸一にかかると思っていたバグ修正が５分で済んでもスケジュール的には困りませんが、５分で済むと思っていたバグ修正が実は丸一日かかると判明するのは影響が大きく、それを早期に発見できるのはとても重要です。
残バグ数を少ない状態に保てる。割れ窓理論じゃないですが、細々したバグが沢山残っている状態ですとテスト時になんらかのバグを発見してもそれが新規のバグなのか既存のバグなのかの判別もしづらく、例え本当は重大な問題であっても一見些細なバグに見える場合にせっかく再現し且つテスターに目撃されているにも関わらずなんの記録も残されないという事態も招きます。
小さなバグを処理してるうちに、大きなバグの原因や対策方法などを考える期間的な余裕が生まれ、効率よく対処できる。

...などといった利点があります。もちろん、このやり方は正しく適用しないと些末なタスクばかりこなしていつまでたっても重要なタスクがなにひとつ処理されないという事態も招きかねないので、そのあたりは注意が必要です。