SIにおけるソースコードのライフサイクル
小野 ソースコードの美しさを考える上で大事なのが、どれくらいの期間メンテナンスしていくソースコードなのか、というライフサイクルなんですよ。パッケージとかWebのサービスっていうのは、基本的にそのソフトウェアがなくなるまでの間、維持・改修し続けるもの。SIは個別のお客さん向けに作ってカットオーバーして…と、ひとつの区切りがあるわけだけれど、それは作り切りみたいな形なのか、メンテナンスされ続けるものなのか？SIにおける１つのソースコードの旅路、どこまで、何年くらい生きてくのか？どうやって変化していくのか？どういうふうに流れていくのか？そういう、SIにおけるソースコードのライフサイクルの話を有馬さんからしてもらおうかと。
有馬 SIerのコードも１度出したら使い捨てというわけでは当然ないです。たくさんの人が関わって、すごくコストをかけて開発しているので当然ながら使い捨てません。実際には5年、10年と使い続けます。じゃあそのソースコード、必ずしも美しいとは言えないかもしれないソースコードは、どうやって10年間、改修・保持されていくのか。やっぱりだんだんと苦行になってきます。１度作られたソースコードが次に人の目に触れるのは、そのシステムを使っているユーザーから「新しい機能を作りたい、今の機能を変えたい」というような要求が発生した時です。そこで初めて過去のソースコードが、ソースコードとして陽の目を見ます。まず機能を変えたいという要望をもとに、改修を担当するベンダーが見積もり作業を行いますが、ソースコードが美しいか美しくないかの違いによって、見積もりの額が大きく変わってきます。
小野 美しいコードは見積もりが違うという話でしたよね。ケースによるだろうけど、何倍くらい変わる感じ？
有馬 規模によりますが、5倍以上になることもあります。プログラムは修正したら終わりじゃなくて、大量のテストをしなければいけないからです。美しくないコードは、テストの量が非常に大きくなる傾向にあります。たとえば、ユーザーはたった1つ、A機能の修正しか要望してないのに「いやいや今回のコードを直すと、僕らが見たところ、A、B、C、D、Eの 5機能を直さなければいけません」となる。ですので、「ここの部分のテストの費用を頂かないと改修はできません」という形になってしまう。その後、ユーザーにその見積もりが許容され、開発工程に進んでいくんですけど、その開発でも多くの苦労が待っています。正しいデザインパターンやオブジェクト指向に基づいた美しいコードであれば、追加機能を簡単に差し込むことができる。しかし美しくないコードは、if文などの処理分岐がたくさんはいっているので、どうしてもそこに対して新たな分岐を追加していくことになってしまう。そうすると分岐の入れ間違いとか、その分岐をいろんなところに入れなければいけないっていうような状況が生まれます。その結果、フラストレーションが溜まって、プログラマーの口から思わず「このクソコードが！」と汚い言葉等が飛び交ってしまいます。ただし、そこで全体を改善する時間はとることができないので、同じように分岐追加で対応することになります。分岐を加えられたクソコードは、更なるクソコードになり……これは記事にはできない（笑）。
小野 こんな丁寧な口調でクソコードって（笑）。
有馬 クソコードがクソコードを生む。それの繰り返しが10年間溜まると、やっぱり大量のif文がまたそこに生まれて「もう、もう無理だね…」というところで、更改が始まる。
小野 最初カットオーバーまでまず作るよね。作って、次のシステム更改までの間に機能追加の要望とかがなければそのままだけども、機能追加とか変更の要望があれば、その時、該当箇所およびその影響範囲の箇所については手が入っていくと。…という意味においては、メンテナンスが入っていく。ただ何もなければ手が入らないと。システム更改になりました、要するにシステムバージョン2で、大型のリニューアルがありますってなった時に、その時代のフレームワークだとか新しい技術っていろいろ変わってるから、基本もう１回作るんだけども、その新しいシステムの中でもバージョン1のコードは部分的には生きていく。完全に捨てるケースってある？
有馬 完全に捨てるケースはほとんど見たことはないですね。移行対象外機能として認められれば捨てますけど。よく言われる「設計書がない問題」っていうのがやっぱり出てきます。設計書自体はあるのですが、新規開発時から年月が経ち、設計書と実際のコードに乖離があって役に立たないという問題です。そういった時は既存のソースコードをそのまま持ってくる、もしくはそこで表現されている分岐をそのまま持ってくるのはやっぱり多いですね。
小野 形を変えて生きてくわけだよね。だからやっぱりSIも、一見、システム更改が終わったら変わるよねとか、変更がなければそのままだよねっていうふうに、メンテナンスされ続ける期間、実はパッケージとあんまり変わらないくらい生きてくわけですよね。パッケージのほうは常に手が入り続けるから、入る頻度とかっていうのは、確率は違うかもしれないけども、基本的に生き続けてメンテナンスされ続けるわけだよね。そしたら変わらないよね。同じくらい大事ですよね。メンテナンスのしやすさ、メンテナビリティが。
有馬 メンテナビリティは、SIにおいてもとっても大事です。
