開発の再生「常識も進化すべきではないでしょうか？」

2010年02月25日 06時00分更新

岡本浩一郎

開発の再生
リファクタリングのメリットは明らか

　ここまで、弥生がとった打ち手をお話ししてきましたが、これは経営としては難しい判断でした。なぜならば、これらの打ち手は中長期的には絶対に必要なものですが、短期的に見れば、コストを増大させ、また実現できる機能（スコープ）を減らすことにつながりかねないからです。冒頭でお話しした通り、純粋に経営的観点で、かつ短期的視野で考えれば、こういった打ち手は「また今度」にしたいものです。その方が低いコストで、とりあえず今期をしのぐことができます。

　ただ、それは問題の単なる先送りに過ぎません。そして、その先送りをいつまでも続けるわけにはいきません。「もぐら叩き」によるバグ取りで、結果的にはお客様に提供できる品質は確保されていましたが、それは当然というよりも幸運によるもの。このまま単調な保守を続けてもどこにも行かないというエンジニアの疲弊も臨界点に達しつつありました。

　経営としてどちらを取るか。「とりあえず今年は」で問題を（また）先送りするか、「開発の再生」を図り将来に備えるのか。もうお分かりの通り、弥生は後者を選びました。この判断ができたのは開発の現場出身者ならではだと感じています。もっとも、前任者もどこかのタイミングで、開発の在り方を見直すことの必要性は感じていたのです。だからこそ、外部からエンジニア出身者を招聘するという大胆な判断があったのでしょう。

　さて、ここまでの打ち手はいわゆる定石ですが、次の一手は耳慣れない方もいらっしゃるかもしれません。それはリファクタリングです。Wikipediaによれば、リファクタリングとは、「プログラムの外部から見た動作を変えずにソースコードの内部構造を整理すること」。

　少し前までの開発は「動いているものには触るな」が常識でした。動いているコードに下手に手を加えると想定しない不具合（いわゆるデグレード）を生みがちという先達の知恵です。一方で、この常識によって、必ずしも最適でないコードが温存されるというコード疲労を生んでいることも事実。

　実は、このリファクタリングを提案したのは私ではありません。提案者であり、推進者は私が外部から招聘した開発のヘッド。今だから告白しますが、私は当初リファクタリングには懐疑的でした。私も前述の常識を疑っていませんでしたから。しかし、実際にリファクタリングを始めてみると、そのメリットは明らかでした。

　今では私も「動いているものには触るな」の常識は必ずしも正解ではないと考えています。従前の常識が変わってきた背景には、開発環境／開発ツールの発展があります。今では各種のツールを利用し、コードに手を加えた前と後とでの挙動の違いをシステマティックにテストすることが可能になりました。開発の進め方が進化した以上、常識も進化すべきではないでしょうか。

　今回、リファクタリングについて簡単にお話させて頂きましたが、このリファクタリングは私が想像した以上に、非常に大きい効果をもたらすことになります。次回は、リファクタリングの意味を中心にお話させて頂きたいと思います。