インテルチック・タックというものをご存じでしょうか？
インテルプロセッサのロードマップモデルだったものです。アーキテクチャはそのままでプロセスルールの縮小を行う「チック」と、プロセスルールそのままでアーキテクチャの改善を行う「タック」これを交互に行い、継続的に新製品を投入するというものです。現在はプロセスルールの微細化が困難になり破綻していますが、長く続いたモデルです。
ちょっと強引ですが、これをソフトウェアに当てはめ、機能はそのままでリファクタリングを行う「チック」と、機能改善・新機能の開発を行う「タック」と考えると、チック・タックでリファクタリングを行いつつ、改善を続けるという継続的な開発ステップになるのではないでしょうか？
インテルの戦略は、プロセスルールの微細化が物理限界に近づいたことで破綻していますが、「リファクタリングが物理限界に到達する」なんてことはありませんから、同じ理由で破綻することはないでしょう。
ってことで、私のおすすめの開発ステップがチックタックモデルなわけです。こういう考え方はもともとあるものでしょうが、この話をすると、チックタックって何？と知っている人があまりいなかったので、啓蒙の意味を込めて書いています。
リファクタリングは行わなければならない
どのように作られたソフトウェアも時間の流れとともにその設計が陳腐化し、時には技術的負債と言われるようになってしまいます。そのため、継続的にリファクタリングは行わなければなりません。技術的負債を放置したままでは、新機能の開発も計画通りに進めることはできず、不具合の温床になってしまいますので、技術的負債を先送りして良いことはないでしょう。
とはいえ、リファクタリングが十分に行われないまま、技術的負債をため込んでしまっているソフトウェアは多いことでしょう。
そのようなプロジェクトを担当することになった時、どのように開発を進めていけばいいでしょうか？
本音を言えば、新機能の開発は当面とめて、ひたすらリファクタリングに取り組みたいところではありますが、ビジネス的な観点から新機能の開発をすべて止めるという判断はなかなかできるものではありません。提案しても受け入れられる可能性はかなり小さいでしょう。
新機能を開発する場合に、修正する周辺をリファクタリングしていくということは通常行われると思いますが、これでは新機能の入る場所以外のリファクタリングが進みませんし、全体に影響のあるリファクタリングを実施するのは難しく、新機能の開発も妥協の上に行わざるを得ない場合も出てきてしまいます。
そのため、開発ステップを「チック」「タック」に分け、「チック」ではリファクタリングに集中し、「タック」で新機能の開発に取り組みます。これを繰り返すことで、継続的に新機能を実装しつつも、ソフトウェアの品質を高めていくことができます。
負債が多い状態では、チックに長い時間をかけたり、ステップを分けてチック・チック・タックとしてもいいでしょう。リファクタリングが進み、負債が少なくなったらチック・タック・タックとしても良いでしょう。当初考えていた負債を返済し終える頃には、当初リファクタリングした箇所が負債になり始めていたりするので終わりはありません。いつまでもこのステップを続けましょう。
リファクタリングを行うことを開発ステップにルールを決めて組み込んでしまえば、次々に開発タスクが積まれてリファクタリングに取り組めない、みたいな状況でも、今はリファクタリングのステップだから開発は次のステップで、と説明しやすいですし、非エンジニアから見ても、スケジュールやエンジニアリソースの見通しがわかりやすくなりメリットがあります。計画に取り込むに当たっても説得しやすいのではないでしょうか？
「チック」を挟むことで開発速度が落ちる懸念もされますが、実際はほとんど落ちません。初期は多少落ちるかもしれませんが、回を追うごとに開発効率が上がっていき、開発速度はどんどん上がっていきます。何より、エンジニアのモチベーションが上がりますしね。
呼び方は何でもいいですが、チック・タックでモダンな環境を維持しつつ、継続的に成長するソフトウェア開発を行いましょう。というお話でした。