【24】変更を恐れない

　ソフトウェア業界で働いたことのある人なら、ひどいプロジェクトに関わった経験か一度はあるはずです。たとえば、どう見てもコードベースの品質が低すぎるようなプロジェクトです。システムの構造自体に問題があり、どこかに変更を加えると必ず、関連のないはずの別の箇所が壊れてしまう。そんなプロジェクトにおいて新たにモジュールを追加する必要が生じた時、担当者が考えるのは、できる限りどこにも変更を加えないことです。リリースの時は、毎回固唾を飲む思いをします。それはまさにソフトウェアで「ジェンガ」をやっているようなものです。直方体のパーツを積んで作った高い塔が倒れないよう、慎重にそっと手を加えていくのですが、いつかは必ず崩れる運命なのです。

　変更を加える度になぜそう神経質になるかというと、それはシステムがいわば「病気にかかっている」からです。医者に診てもらう必要があります。そうしなければ容態は悪くなる一方でしょう。システムのどこが悪いのか、自分ではよくわかっているのだけれど、怖くて触れないのかもしれません。しかし、何かを改善するのに痛みはつきものです。外科手術をするには、必ずどこかを切る必要がありますが、痛みはあくまで一時的なことであり、その傷は癒えるのです。そして、患者の容態は手術の前より良くなるはずです。

　プログラムのコードでも同じことが言えます。改良を加える間、一時的にどこかが壊れていても誰か気にする人がいるでしょうか。そもそも、そういうむやみに変更を怖がるような態度のせいでプロジェクトがひどい状況に陥っている可能性が高いのではないでしょうか。リファクタリングをすれば時間と労力はかかりますが、プロジェクトが進む中でその投資は十分回収できるでしょうし、何倍もの利益となって返ってくるでしょう。さらに良いことは、「病気の」システムを治すことがプロジェクトのメンバーにとって経験になるということです。その経験によって、システムは本来どうあるべきかを全員が理解するようになり、システムについてのエキスパートになるのです。システムがひどいとただ怒るのではなく、改良できる知識を身につけるのです。作っている人間自身がシステムを嫌っているようでは、そんなものを使わされる側はたまらないでしょう。

　システムの改良にあたってすべきこととしては、たとえば、内部インターフェースの再定義、モジュールの再構築、コピー＆ペーストしたコードのリファクタリングなどが挙げられます。また、依存関係を減らして設計をシンプルにすることなども重要です。コードをシンプルにするため、機能の組み合わせ方が不適切なときによく生じるコーナーケースを減らすというのも有効でしょう。改良はゆっくり少しずつ加えていき、改良の都度テストをします。一度に大幅な変更を加えるのは危険です。それが元で大変な問題が起きてしまい、結局、せっかく途中まで進めた改良を全部やめてしまおうということになりやすいからです。

　大切なのは、外科医が身体を切ることを恐れずに病気を治すように、コードに変更を加えることを恐れず、積極的にシステムを改良していく姿勢です。そういう姿勢は人から人へと伝播しやすいものです。同じような人が増えれば、延び延びになっていた改良プロジェクトが実施に移される、ということがあるかもしれません。チームのメンバーの意識が高まれば、日々、気づいたことをリストアップして皆と共有する、ということもできるでしょう。これもシステムの質向上につながります。改良プロジェクトを実施するには、会社の上層部を説得することが必要になるかもしれません。「改良してもすぐに目に見える利益が生まれるわけではないが、将来のコスト削減につながり、リリースに要する時間の短縮もできる」ということを説明して納得してもらうのです。こうして、システムの「健康」への留意は常に怠らないようにしましょう。