あなたの会社に長年稼働し続けているシステムはありませんか？
もし答えがイエスであれば、そのシステムは稼働を開始してから、数多くの改修を繰り返して複雑化してしまっているかもしれません。複雑化したシステムは機能の追加・変更による改修が発生したときに、改修の影響範囲がだんだんと読みにくくなっているものです。
影響が読みにくいということは、改修することでトラブルにつながるリスクも高まっています。
このようなシステムを持つ企業では、システム担当者が保守費用の増大とトラブルのリスクに悩まされながら、モンスターと化したシステムと悪戦苦闘されているのではないでしょうか。
この記事では、そんな悩みを抱えるシステム担当のみなさまに向けて、複雑化したシステムをいかにわかりやすくシンプルにしていくかについて、効果的な方法をお伝えしたいと思いますので、参考にしていただければと思います。
開発が終わり、本番稼働を開始したシステムはバスタブ曲線という曲線をたどってシステムの安定性が変化していくと言われます。
横軸が本番稼働開始からの稼働期間、縦軸がトラブル率で表されるグラフは、初期故障期間にあたる本稼働開始直後にはトラブルが多く、さまざまなメンテナンスが必要になります。しばらくすると偶発故障期間に入りグラフの傾斜が右肩下がりになり、安定してシステムを稼働させることができます。
偶発故障期間を過ぎたシステムはやがて老朽化が進み、摩耗故障期間に入ります。
この期間では再びトラブルの増加傾向が見られるようになってきます。
このようなグラフの形状からバスタブ曲線と呼ばれています。
摩耗故障期間のトラブル増加傾向はハードウェアやネットワークの老朽化やユーザーデータの品質低下に起因しているものもありますが、もうひとつ大きな原因として、長年にわたって改修に改修を重ねたソースコードが複雑化・肥大化してしまったことが挙げられます。
複雑化・肥大化したソースコードは、様々な不都合を生むようになります。
複雑化・肥大化したソースコードには、不要なソースコードがたくさんあったり、同じ処理をしているコードが複数箇所に書かれていたり、変数やメソッドの名称が機能の実態を表していない難解なコードが書かれていたりします。
このような状態になってしまったソースコードは、機能の追加・変更のための改修を実施するときに改修箇所や、改修による影響範囲を調査することがとても大変になります。
調査をするためには難解なコードを読まなくてはなりませんし、使われていないと判断できない限りは不要なコードも読んで調べなくてはなりません。
同じ処理が複数箇所に書かれていれば、改修箇所やテストケースが増えることにもなります。
システムを改修し続ける限り、毎度このような調査が必要になり、しかもそれは稼働年数が増えれば増えるほど重くのしかかってくるのです。
人の体で例えるなら、複雑化・肥大化したシステムの体質はさしずめ「メタボ」のような状態と言えます。
メタボになってしまった体は、生活習慣病などのリスクが高まります。
そのため、体質を改善してリスクを下げる努力が必要となってきます。
システムの場合は体質を改善するのにどんな努力ができるでしょうか？
複雑化したソースコードをわかりやすくシンプルにするための技術として、リファクタリングというものがあります。リファクタリングはシステムに機能を追加したり、性能を改善したりするものではありません。 外部から見たシステムの振る舞いは変えずに、ソースコードの内部構造を理解しやすくするための技術です。
システムの体質を改善するためには不要なソースコードは削除し、同じ処理をしているコードは共通化し、変数やメソッドの名称は機能の実態を表すわかりやすいものに変更します。
これがリファクタリングというものです。
まさにシステムの体質を改善する取り組みだと思いませんか？
複雑化・肥大化したソースコードにとってリファクタリングが効果的だとはよく聞くけれど、実際にコストをかけただけの効果が得られるのか？あるいは、稼働しているシステムのソースコードに変更を加えることはリスクが高いのではないか？
そんな疑問が払拭できず、なかなか実行に踏み切れないという方もいらっしゃるのではないでしょうか。
ここでは、リファクタリングのメリットについて説明してみたいと思います。
リファクタリングを実施し、システムの体質が改善されることによって得られるメリットはいくつかあります。
リファクタリングを実施することでソースコードが読みやすくなると、改修が発生したときの調査で改修箇所や影響箇所が見えやすくなり、改修にかかる工数がより精緻に見積もれるようになります。
リファクタリングでソースコードが読みやすくなり、改修による影響が見えやすくなると、影響箇所の調査漏れも起こりにくくなります。
改修による影響箇所の調査が漏れてしまい、本番リリースしてから思わぬトラブルを招くことがしばしばありますが、リファクタリングを実施したソースコードでは影響箇所の調査漏れが起こりにくくなるため、システムを改修することでトラブルが起こるリスクを低減することが可能です。
複雑化・肥大化したソースコードは、システムを再構築する際に調査・分析で膨大な工数を要することになります。
しかも、難解なソースコードによる調査は仕様の読み誤りも発生しやすく、テスト工程やユーザの受け入れ段階で多くの不具合指摘が発生するリスクも高まります。
事前にリファクタリングを実施しておくことでシステム再構築にかかる調査工数、および再構築の対象とすべき範囲を削減することができ、さらに再構築システムをリリースするときのトラブルリスクを低減することにもなります。
それ以外にも、システムの複雑化・肥大化により技術者の属人化を招くリスクの低減、ソースコードの静的解析による潜在バグの除去といった効果が出ることも考えられます。
このように、リファクタリングを実施することによるメリットは多いのですが、そうは言っても一度に進めるにはリスクも高いし、メリットが目に見えにくいものに対して費用をかけるという決断しづらいなど、懸念が拭いきれない方も多いと思います。
でも、何も全てのことを一度に実施することはないのです。
むしろ、一度に実施する範囲を限定して少しずつ進めていく方が、バグを埋め込むリスクを減らせるので適していると言えるくらいです。
リファクタリングを少しずつ進めていくのであれば、まずは不要なコードの削除から始めるのがいいでしょう。
長年改修を重ねているシステムは、不要なコードも多くなっているものです。保守を担当している技術者は改修によるリスクをなるべく避けたいため、改修箇所を最小限に抑えようとするからです。
たとえば、改修によって不要になった関数やサブルーチンがあった場合、呼び出し箇所をコメントアウトするだけで、関数やサブルーチンそのものを削除するということはあまりしないと思います。
このようなことが積み重なるため、改修のたびに不要なコードがゴミのようにどんどん溜まっていくのです。
不要コードを検出するツールなどを利用して、削除対象コードを効率良く特定して進めていきましょう。
コメントアウトの削除もおすすめです。
改修を何度も重ねてきたソースは大抵、コメントアウトされて動いていないコードが羅列されていることが多いものです。コメントアウトされた行はそのまま残し、修正後のコードは別の行に書かれています。
修正後のコードもコメントアウトされて、さらに新しい修正後のコードが別の行に書かれていることもあるでしょう。ひどいソースコードでは、このような形でコメントが幾重にも重ねて書き換えられていたりします。
この記事をお読みになっているみなさんも、このようなカオスと化したコードと日夜格闘なさっているかもしれませんね。
私も長年保守を担当していたシステムで、このようなコメントだらけのソースコードを改修するのに随分、苦戦していたことがありました。
このカオス状態を、クリアにしてすっきりさせるわけです。
幾重にも重ねてコメントアウトされたコードを一掃するだけでも、ソースコードはかなり読みやすくなると思いませんか？
修正したコードのテストはもちろん必要ですが、コメントを削除するだけの修正であればそれほどリスクもありません。これらを、他の改修案件を実施するたびについでに少し混ぜて、地道にやっていくのです。
修正したときの経緯を記録しておくべきだとして、頑なにコメントで修正履歴を残し続けているということもあると思いますが、実際には改修して何年も経ったコメントが必要になることはそうありません。もし必要になったとしても、バージョン管理システムを導入していれば、元のバージョンを確認することは容易です。
不要コード、コメントの削除まで実施してソースコードがある程度すっきり読みやすくなったら、重複したコードの共通化や、変数名・メソッド名の変更などにも着手していくといいでしょう。
リファクタリングを実施するときにあわせて関数一覧や変数一覧などのドキュメント最新化も進めておくとより効果的です。
こんな話を聞いたことがあります。
既存システムの再構築を実施するとき、事前にソースコードを見直して不要なコードを削除するという簡単なリファクタリングを実施しただけで、全体の２割以上もソースコードが削減できたというものです。
２割の不要なソースコードがなくなったらどうですか？その後の再構築プロジェクトでは現状調査や要件定義に大きな工数をかけることになるはずです。
調査の工数が２割減り、要件定義の対象となる機能も２割減り、といった具合にプロジェクト全体の工数も、ソースコードを見直さずに実施するのに比べれば大きく削減されることでしょうね。
普段から改修の機会を利用して小さくリファクタリングを積み重ねていくことで、結果的にはこの例と同じだけの効果を生むと言えるでしょう。
複雑化・肥大化したシステムを効率良く体質改善する手法としてリファクタリングが効果的であることをご説明してきました。
リファクタリングは、必ずしも一度に大きなリスクと費用をかけて実施するものではなく、普段から実施している保守案件の中に少しずつ取り込んでいくやり方でも充分に効果を見込める手法であることがお分かりいただけたでしょうか。
システムの複雑化・肥大化はすべての企業の情シスにとって悩ましい問題ではありますが、悩んでいても解決されることはありません。こうしている間にもシステム資産の複雑化・肥大化は進んでいくのです。
大きなリスクを負わず、小さな取り組みとしてスタートしていけるのがリファクタリングですから、まずは身近なところから小さくスタートしてみてはいかがでしょうか。
複雑化・肥大化したシステム資産と日々格闘なさっているシステム担当のみなさまに、この記事の内容が少しでもお役に立てましたら幸いです。