東芝情報システム株式会社

PlatformDoctor®を用いたリファクタリングサービスの紹介

ソフトウェアの外部的振る舞いを保ちつつ、内部構造を改善するリファクタリングのニーズが高まっています。ソースコードの改善のためには、ソースの複雑性、モジュールの影響度や重要度など、課題を明確にする指標を踏まえ、その可視化が求められます。当社では、診断ツールであるPlatformDoctor®を活用し、お客様の課題に応じたサービス提供を展開しています。
エンベデッドシステム事業部
鈴木 さゆり

エンベデッドシステム事業部
鈴木 さゆり

ソフトウェア開発で、なぜリファクタリングが必要なのでしょうか

 ソフトウェアのプログラミングでは、初期段階からハードや実行環境の変更、機能の追加など、ベースとなっているソースコードに改良などが繰り返されることが多いのが現状です。特に組込みでは、このようなリサイクルしながらの開発が多くなっています。
 ハードが少しでも変わるとソフトの微妙な変更が頻繁に行われ、これが度重なると最初の設計思想が崩れて読みにくいソースコードが増えてしまいます。つまり、元のところから線を辿っていくとグチャグチャに絡まった状態であることから、私たちはこれを「スパゲッティ状態」と呼んでいます。この状態を放置しておくとさまざまな支障をきたすため、ソースの現状を複数の指標によって定量的に可視化し、改善が必要とされる部分を把握することが求められるようになりました。
 リファクタリングとは、プログラムの動作や振る舞いを変えることなく、内部の設計や構造を見直してソースコードをクリーンに保つことです。大規模なプログラムでの仕様変更や機能追加では、リファクタリングを行う機会を製品開発のスパイラルに取り込み、製品の寿命を考慮して改善を繰り返すことが不可欠です。(図-1) そのため当社では、ソフトウェア構造を診断するPlatformDoctor®を開発しました。
画像1-1

PlatformDoctor®の概要と「可視化」について教えてください

 PlatformDoctor®は、ソフトウェア構造を数値で定量的に評価できるツールです。某自動車メーカーのシステム開発に複数の開発会社が関わっていた時、ソフトウェア構造の品質を見極め、問題を解決するためのツールとして開発しました。一般的な指標に加え、組込み技術の開発を行ってきた経験値を活かして独自の組込みに特化した指標を取り入れています。
 普段、プログラム開発に従事している人は、ソースコードを見ると「このソースは読みにくい」とすぐにわかりますが、プロジェクトでは、開発部門だけでなく品質部門など普段はソースコードにあまり触れない方もたくさんいます。そのような方々に、「ソースが読みにくい」「不具合が起きる可能性がある」ことを客観的に理解してもらうため、数値化・可視化できるようにしました。このように、PlatformDoctor®の優位性は数値によってソースコードの良し悪しを共有できる点にあります。
画像2-1

お客様の困りごとに寄り添った時、どのようなアプローチを行いましたか

 PlatformDoctor®では、Excelファイルを使って評価指標を表示します。良い部分は緑、概ね基準値に近い部分は白、悪い部分は赤の表示になります。(図-2)
 しかし、それから先、どのような改善を行うかをお客様に提示してこそリファクタリングサービスです。PlatformDoctor®を導入し、お客様がこのツールを使いこなせばツールとしての優位性を理解できますが、実際には数値として確認した後の改善策を把握できずにいる場合が多く、それ自体、私がこのツールに初めて出合ったときの戸惑いと同じものでした。
画像1-1
 そこで、お客様の困りごとを解消できるリファクタリングサービスを検討し、数値化して状態を提示した後は「診断」のステップに進み、改善箇所を示して説明するようにしました。提示した数値を見て実際にリファクタリングするかはお客様の判断ですが、PlatformDoctor®を使い、診断まで行うことで自分が味わった戸惑いが解消され、リファクタリングサービスの価値につながると思いました。
 PlatformDoctor®は、文字通りお客様がリファクタリングを行うにあたっての健診ドクターです。初期段階の分析は、人間に置き換えるといわば年に1度の定期健康診断で、指標ごとに基準値との比較が明示されます。人間も要検査の診断が出れば専門の精密検査を行うように、リファクタリングサービスでも悪かった指標や検討が必要な指標についてさらに踏み込んだ判断を導くのが精密分析です。その結果、何らかの治療が必要なソースコードかを見極めて改善を提案します。

これまでに診断した事例をいくつか教えてください

・1つめは、某メーカーの品質部門からの依頼です。
 開発・製造するメカニカル製品について、お客様が機種ごとにソフトウェアを改良して開発環境を変更したところ、以前に比べて不具合が多くなったとの報告がありました。開発部門と品質部門の両方が同席する場で、PlatformDoctor®で数値化した内容を提示し、該当する指標が規定をはみ出している旨を説明すると、心当たりがあるとのことで両部門から納得の回答がありました。この事例の場合、当社ではリファクタリングを行いませんでしたが、精密分析を行ってソースコードの特定関数について指摘しました。後に自社でリファクタリングを実施し、その後はPlatformDoctor®を活用して数値改善に取り組んでいるそうです。また、このケースではPlatformDoctor®のワークショップを開催してほしいとの要望がありましたので、取扱説明書に記載されている内容の一部を掘り下げ、改善の仕組みを4回の勉強会で説明し、共感をいただきました。

・2つめは、人事異動にともない、開発部門のキーマンが不在になった事例です。
 長期間の開発では人事異動や退職による人の入れ替えが付きものです。引き継ぎ用のドキュメントがあれば検証もスムーズに進められますが、多忙な状況ではドキュメント作成がつい後回しになってしまうこともあります。このお客様の場合は、その先も長期でシステムを使う予定だったため、このタイミングでトラブル回避のためにリファクタリングを行いました。しかし、リファクタリングで本当に改善されたか疑問が残るのと同時に、さらに改善の余地はないか数値化してみたいとのことでした。
 このケースでは、「重複コード」がキーワードになりました。同じ処理をする機能がソースコードとして2つある場合、その部分で不具合が発覚すれば両方の改善が必要です。片方だけを直し、もう一方の存在がわからなければ放置されてしまい、違うタイミングで同じ不具合が出てしまいます。そのため当社では、重複コードの診断を含めた解析を行いました。

・3つめは、実際にリファクタリングを実施した事例です。
 某メーカーのメカニカル製品で、ティーチング用ソフトウェアの機能追加を繰り返し行っていたところ、あるタイミングで条件付けが複雑になり、さらなる機能追加ができなくなったケースです。
このケースでは「条件分岐」がキーワードになりました。ソースコードでは、ある条件ごとに分岐点がたくさんあり、複雑に絡んでいます。製品の初期段階では、できることが少ないために分岐も少なかったのですが、機能が追加されるたびに条件分岐だらけのソースコードになっていました。(図-3)
 そこでリファクタリングを実施し、すべてを書き換える対処を行いました。そもそもリファクタリングは外身を変えずに中身を変えるものなので、リファクタリングのメリットが活かされた事例です。
画像4-1

今後の展望について教えてください

 これまではツールの販売が中心でした。しかし、お客様の要望を汲み取っていくうちに、PlatformDoctor®の販売を含めた総合的なリファクタリングサービスの必要性を感じています。大切なソースコードを「メールで送る」「メディアにコピーして郵送する」のは紛失のリスクをともなうことから、クラウド化は有効な手段です。また、事例でご紹介したワークショップ形式の勉強会では好感触を得たので、資料提供も含めた活動が不可欠になるでしょう。さらに、オンラインによるリモート診断や、リモート診断とワークショップを合体させたサービスも実施していきたいと思います。
 開発を重ねるとソースが複雑化して劣化するのは避けられません。そのため、改善が必要な部分を数値で認識できるPlatformDoctor®を取り入れたサービス提供でお客様に貢献したいと思っています。

※記事内における内容、組織名、役職などは2022年7月公開時のものです。
※本文中の会社名および製品名は各社が商標または登録商標として使用している場合があります。

お気軽にお問い合わせください。当社の製品・サービスは企業・団体・法人様向けに販売しております。