大企業では実施が難しいと思われるソフトウエアのリファクタリング。富士ゼロックスでは、どのように取り組んでいるのか。リファクタリングの実施を決断した理由、課題とその対応方針、成果、今後の展望などについて聞いた。
1962年設立の富士ゼロックスは、主に複合機やオフィスプリンターなどに内蔵されるコントローラーソフトウエアの開発を行っている。コントローラーソフトウエアは、スキャナーで撮り込んだ画像の加工や印刷、ネットワーク経由の通信、セキュリティなどの各種機能を、操作パネルのユーザーインターフェースを介して制御しており、昨今の多機能なオフィス機器の要といえる。
一方で、多機能になったことでコードは大規模かつ複雑化の一途をたどっている。
「2000年頃は200万行程度だったが、2010年には1000万行を超える勢い。しかも、関数複雑度という指標で評価したら、ものによってはリスクが伴うほどに複雑で、テストすらできないレベルといった判定になるものもあった」
そう話す富士ゼロックス コントローラ開発本部 マネジャーの土樋祐希氏は、「特に若い開発者にとっては、すでに存在しているソフトウエアを触ることになるわけだが、ドキュメントもない上にコードの可読性も低い。そのような中でコードに手を加えなくてはならない。その結果、不具合が発生してしまうケースもあった」と明かした。
原因は、ソフトウエアの品質の捉え方にあった。これまで同社では、「バグがないことが高品質である」という考えに基づき、スナップショット的な品質評価を行ってきた。実際、バグの有無は指標として分かりやすい。
しかし、コードの複雑度や可読性といった中身をきちんと整理しないと、怖くて誰も触れないままソフトウエアは巨大化する。それにびくびくしながら運用するのは、リスクを高めるばかり。しかも、維持費や開発費にも響いてくる。今後はバグだけではなく、将来的な保守を見据えた品質管理もしていくべきだ。そう同社は考えた。
といっても、ゼロからソフトウエアを作り直して再スタートを切るのは厳しい。そこで、コードの複雑度を整理し、保守性の高い状態へ持っていく「リファクタリング」を採用することにした。コードがすっきりして分かりやすくなれば、修正や機能追加が円滑になると踏んだからだ。
だが、進める上でいくつかの課題があった。一つは、1000万行もあるコードをどこまで修正するのかという、大規模であるがゆえの課題だ。「巨大なソフトウエアを全てを直すことは非現実的。効率良く効果的な改善につなげるために、どこから優先的に手を付けるべきか悩んだ」(土樋氏)。
また、現在はコードに継ぎ足すだけで仕事として成り立ってしまっているが、リファクタリングするとなると設計面の技術力などが問われてくる。そうした再教育も必要になる場面も出てくる可能性がある。
さらに、風土に関する課題も懸念された。「今動いているものに手を加えるべきではないという意識が働き、変化に抵抗する人も出てくることが予測された」(土樋氏)。
検討の末、まずは全体をざっくり整理し、リファクタリング対象を絞り込み、そこから手を付けていく方向で少しずつ解消していくという結論にたどり着いた。
リファクタリング対象を絞り込む基準として、同社は複雑な関数の数を縦軸、一定期間内のコミット数(コードの修正回数)を横軸とした二元表を作成した。そして、両軸共にしきい値が高い、よく修正が発生して複雑度も高い「NGエリア」の部分から優先的に取り組むことにした。この指標を示したことで、リファクタリングしようというコンセンサスも得やすかったと土樋氏は言う。
リファクタリングを進める上では、「Lattix」と「Understand」などのツールを活用した。
Lattixは、Java、.NET、C/C++などで開発されたソフトウエアの構成要素の依存関係を可視化し、デグレードやエラーの原因となるような構造上の問題を確認しやすくするコード解析ツールだ。依存関係はメトリクス表示され、コンポーネントやパッケージといった抽象的な粒度から、クラスやソースファイルなどの詳細な粒度まで、階層を折りたたみながら俯瞰できるのが特徴だ。
Understandは、コードを高速解析し、プログラムの制御フローや構造、関数や変数の呼び出し関係など、要素間の関係をフロー図やツリーで可視化するコード解析ツールだ。コードの複雑度やカウントメトリクス(ファイル数や実行可能コード行数など)、オブジェクト指向メトリクス(クラスメソッド数、クラス結合度など)を含む約100種類のソフトウエアメトリクスを計測、リポートするなど、より粒度の細かい部分で問題の洗い出しができるのが特徴だ。
Copyright © ITmedia, Inc. All Rights Reserved.