弥生の開発再生プロジェクト（その2）

リファクタリング　最大の成果は「自信」を勝ち得たこと

2010年03月16日 09時00分更新

岡本浩一郎／弥生

リファクタリングには当初懐疑的だった岡本社長。しかしその成果は絶大だった！　リファクタリングをするにあたって、弥生がとった行動とは何か？　エンジニア企業弥生の再生は続く。

　弥生株式会社の岡本です。前回は弥生の開発の「再生」について、まずはプロジェクト管理の徹底といった定石から始め、そしてリファクタリングに取り掛かったというところまでお話しさせて頂きました。

　リファクタリングの定義は、前回もWikipediaからの引用で、「プログラムの外部から見た動作を変えずにソースコードの内部構造を整理すること」とご紹介しました。連載第2回（関連記事）でお話しさせて頂いたように、私はコーディングの現場から引退してだいぶ時間が経っていますので、実際にどのようにリファクタリングするかという技術論ではなく、そのメリットを中心にお話ししたいと思います。技術論に関しては、Wikipediaでも主な手法について簡単に紹介されていますし、より詳しい手法については、「リファクタリング」（マーチン・ファウラー著）などを参照されると良いかと思います。

社内勉強会も頻繁に開催
～コードを“あるべき姿”に戻すために～

　リファクタリングのメリット。それは、コードが整理され、見通しが良くなること。保守開発では、時間的制約から（悪く言えば）その場しのぎの修正がなされることが多々あります。たとえば、全体の流れを無視して、条件分岐を無理やり突っ込み、最低限必要な処理を追加する。類似のコードを探してそれをコピーし、必要な部分のみ書きかえる（いわゆるクローンコード）、など。しかし、これらの修正は、コードの複雑性を増すことになり、その後の保守をますます難しくします。

　リファクタリングでは、機能の追加は行ないません。その代わり、この種のコードの複雑性を排除し、いかに「あるべき姿」に戻すかに注力します。この結果として、やっつけ保守では得られない、見通しが良く、クリーンなコードを実現することができます。

弥生のリファクタリングビフォーアフター。左がリファクタリング前。右がリファクタリング後。リファクタリング前は、コメントがない、変数名が分かりにくい、直接文字列バッファを操作している、文字列リソースが直接埋め込まれている、whileのループが格好悪い、など突っ込みどころ満載。リファクタリングは後整理され、見通しが良くなった

　コードが整理され見通しが良くなれば、保守性が飛躍的に向上します。コードがスパゲッティ状態であっても、元々そのコードに詳しい人（いわゆるそのシステムの主ですね）が手を入れる場合、まだ何とか取り繕うことはできます。しかし、そうでない場合は、度胸を試されることになります。当然、関連のドキュメントには目を通し、コードも精査するわけですが、それでも、修正すべき個所を見落とすことも決して珍しいことではありません。

　しかし、リファクタリング後であれば、構造が整理されており、どこに手を入れれば何が起こるのか、あるいは、何をするためにはどこに手を入れるべきなのかが明確になっています。すなわち、自信を持って手を入れることができますし、試行錯誤のための工数も減り、さらに下流工程での品質保証工数も結果として減らすことができます。

　さらに副次的なメリットを挙げると、正しいオブジェクト指向のコードになるということ。これは副次的メリットとは言え、実際問題として大きなメリットだと考えています。一般的に、マイクロソフトプラットフォーム上のPCソフトの開発言語は、アセンブラ、BASIC、C、C++という順で発展を遂げ、最近ではC#を使うケースも増えてきています。しかし、残念ながら、言語はC++でも、実質的にCとしてしか使っていないというケースが多く見受けられます。要は、昔ながらの書き方を引きずり、C++、あるいはオブジェクト指向プログラミングのメリットを実現できていないケースです。

　リファクタリングは、オブジェクト指向プログラミングの特徴であるコードの再利用性を最大限に発揮することを主眼に行なわれますので、当然のことながら、クラスの見直し、メソッドの見直しなどを通じ、オブジェクト指向が徹底されます。

　最後に、これも副次的メリットと言えますが、エンジニアのスキルの向上も期待できます。リファクタリングは、機能を変えずに構造を整理するわけですから、リファクタリングにあたってはコードの基本的構造を徹底的に理解する必要があります。やっつけ保守ならではの、最小限理解して、最小限手を入れる、の繰り返しではなかなか得られない経験です。人の書いたコードをじっくりと分析すること自体が、自分のコーディングの癖を見直す良い機会ともなります。

　さらに、リファクタリングを通じ、あるべきコーディングを身を持って学ぶことができます。弥生でリファクタリングを実施するにあたっては、社内勉強会を頻繁に開催しました。実在のコードをお題に、現状のどこが問題なのか、そしてそれをどのようにリファクタリングすべきかについて、喧々諤々の議論を行ない、これによって皆のスキルアップを図りました。リファクタリングを通じ、スキルアップを図ることで、その後の保守開発においては、より最適なコードを書くことができるようになります。

リファクタリング　最大の成果は
弥生の開発として自信を持てるようになったこと

　メリットの多いリファクタリングですが、実際に行なうためには、ひとつやらなければならないことがあります。それは、開発環境の見直し。リファクタリングはコードに手を入れる作業である以上、デグレードが発生する可能性があります。逆にデグレードが発生していないことを確認するためには、徹底的なテストが必要になります。

　Visual Studio 2008のような最新の開発環境では、リファクタリング作業を円滑に進めるためのテストツールが非常に充実しています。弥生では、リファクタリングの実施とあわせ、開発環境をそれまでのVisual Studio 2003（一部Visual C++ 6.0）から、Visual Studio 2008 SP1への移行を行ないました。また、Parasoft社のC++ Testのようなテストツールも併用することによって、リファクタリング作業の円滑化と品質の確保を図っています。

　前回もお話ししたように、当初、私はリファクタリングには懐疑的でした。しかし、実際に行なってみると、そのメリットは想像をはるかに上回るものでした。色々と書きましたが、最大の成果は、弥生の開発として「自信」を持てるようになったということだと思います。品質への自信、技術への自信、そしてスキルへの自信。

　一方で、決して楽な道のりだったわけではありません。特に当初は試行錯誤の連続でしたし、通常のサイクルで新製品を発売しなければなりませんから、残業時間も決して少なくはありませんでした。しかし、ここまで辿りつけたのは、弥生の開発者全員の努力の賜物だと思っています。本当に皆には感謝していますし、誇りに思っています。

さて、前回と今回で弥生の開発の再生についてお話をさせて頂きました。次回は、再生した弥生が今後どういった方向に進もうとしているのかを、お話しさせて頂きたいと考えています。