作り直すといっておきながら「仕様は前のシステムと同じで」とは何事だ

はじめに

年末ですね。街を歩いていると、そこかしこで工事が行われています。まちづくり、ビジネス的な要請、さまざまな理由に並んで老朽化に伴う改築があります。

ソフトウェア開発でも、日々工事は行われています。建造物と同じように、ビジネス的な要請だったり老朽化対策だったり理由は様々です。

昔より作り直しに取り組みやすくなった

技術的負債という言葉が（提唱者の意図した意味から逸脱したりしながらも）ある程度普及したこと、そしてソフトウェア自体が長寿化したことから老朽化対策としての工事が行われる機会はひところより増えたように思います。

ふるまいは変えずに内部構造を改善するリファクタリング。
アーキテクチャレベルでの改善を行うリアーキテクチャ。
そもそもゼロベースで作り直す、リプレイス。

作り直しといってもそのレベル感はまちまちです。まちまちですが、「作り直そう」という動機に共通するのは「開発スピードが低下している/もっと向上させたい」という思いでしょう。（OSやライブラリのバージョンアップに伴う作り直しもありますがここではスコープ外とします）

さて、いま自分たちがとろうとしている作り直し戦略は、「開発スピードを向上させる」という目的にマッチしているでしょうか。

「作り直して。既存の機能は全部サポートして。」

前述のように、OSやライブラリのアップデートが作り直しのきっかけであれば、既存の機能を保つというのは真っ当な判断です。

ですが、「機能が多すぎる」「設計が複雑すぎる」といった状況であれば、「既存の機能は全部サポートして」というビジネス要件が適切であるか丁寧に検査する必要があります。

大量に実装された機能をメンテナンスすることが開発スピード低下につながっているとしたら。相反する要件にどうにか対応しようという努力が複雑さを招いているとしたら。これはそのソフトウェアを作り上げるシステム（ステークホルダーとチームの利害、技術的制約事項など）が技術的負債の発生源であることを示します。

そして、そういう状況であれば仮に作り直したとしても、早晩技術的負債は積み上がっていきます。なんせ発生源であるシステムには何ら変更が加わっていないのですから。

リプレイスのリプレイス

対処しきれないほどの大量の機能、理解が困難なほどの複雑な設計。それを作り直すという作業自体が相当に負荷のかかる行為です。複雑であるがゆえに作り直しながら課題にぶつかり、その課題を応急処置で解決していくことで新しい負債が生まれていきます。

どうにかこうにか完成したリプレイス版システム。どうにも開発スピードが上がらない。新しい技術的負債が盛り込まれている。すべてが新しいシステムへ移行しているわけではないため古いシステムのメンテナンスも必要となる。もちろん開発スピードは上がらない。

「リプレイスしようか。」

これは、繰り返す物語。　　

リプレイスはやめておこう、という単純な話でもない

ああ、なんて悲しい結末でしょう。もちろんフィクションですよ。

ここ数年は「完全に作り直すリプレイスより、まずはリファクタリング/リアーキテクチャで課題の解決を試みよう」という流れが主流になっている肌感があります。もしかしたら、リプレイスによるつらい体験がエンジニアたちの集合知として形成され、そういった風潮ができているのかもしれません。

ところが、リファクタリングにしろリアーキテクチャにしろ、複雑化し開発スピードが低下する要因がビジネスーエンジニアリングの関係のシステムにあるとすれば、そこと向き合わずに根本解決することはありません。

システムと向き合う

じゃあ、開発スピードが低下したソフトウェアを前に、私達は何をするべきか。それは、その負債を作り上げる「システム」と向き合うことです。　　

異なるスコープの要件をすべて飲み込むモノリスが開発対象
顧客要望は必ず要望された通りに作る
機能追加の意思決定はビジネスサイドのみでおこなう

たとえばこういったシステムであれば「機能が多すぎる」「設計が複雑」という状況を呼び込みやすい、というのは想像に難くないでしょう。

つくりなおしはビジネスサイドも一緒にね

顧客からの要望に応えたい、というのはまっとうな動きです。問題は、その「顧客の要望をそのまま受け取って実現する」ということが技術的負債につなかまる、ということをビジネスサイドが知らないということにあります。エンジニアリングは専門分野じゃないので、ここは仕方ないところです。
ここは「ビジネス側はこっちの苦労も知らないで」と嘆くのではなく、きちんと対話してみるとよいでしょう。

「○○の要望なんですが、そのまま実現すると特別な対応が必要になります。将来的な開発スピード低下につながるおそれがあります。要望を読み込んでみたのですが、たとえばXXという制約を設けてもいいのであれば改修範囲は軽微なものにおさまります。どうでしょう」

こういったやりとりを通して真の要件が浮き彫りになっていくため、顧客満足度、そしてビジネスサイドの希望を損ねることなく良いアーキテクチャを保つことができます。対話というシステムは強力なのです。

と、いうわけで。もし「作り直し」の機運が高まったら、この話を思い出してください。「全部の機能を保ってね」は、ビジネスサイドとして要求してくることはある意味当然です。
それだと何が困るか、将来にわたってビジネス価値をスピーディに提供し続けるためにはどうしたいか、対話する素地を作りましょう。ビジネス的にもエンジニアリング的にも満足のいくものが、その先にはあるはずです。