ソフトウェアの構造分析ツール「Lattix」のユーザ事例　～RICOHの例～

組み込みソフトウェアの依存関係を可視化し
デジタルカメラの品質向上と開発期間短縮を実現

　リコーは，デジタルカメラ製品のさまざまな機能を担う組み込みソフトウェアの品質を向上させ，複数の機種を効率的に開発することを目的として，ソフトウェアの構造を整理するという活動に取り組んでいる．そのツールとして同社が採用したのが，コードの構造を可視化し，改修の影響範囲を把握できる「Lattix」だった．

●品質向上のための取り組みに着手

　リコーは，デジタルコピー，ファクシミリ，プリンタなどのOA機器の分野において世界的に著名なメーカーだ．複写機や小型複合機では，国内でトップクラスのシェアを誇る．　そうしたOA機器とともに現在のリコー製品の柱となっているのが，デジタルカメラである．実はリコーは昭和初期からカメラを製造する老舗であり，1990年代まで35ミリフィルムのコンパクトカメラを中心に，高品質なマスマーケット向け製品を提供するメーカーして広く認知されてきた．1995年に発売したデジタルカメラ「DC-1」以降は，有力なデジタルカメラメーカーとしての地位を確立．以降，フィルムカメラに引き続き，コンパクトカメラ市場向けを中心に製品を展開する．2009年12月には，レンズ，撮像素子，画像処理エンジンを交換可能なユニットに一体化した「GXR」を発売し，デジタルカメラの新しいスタイルとして注目されている（図1）．

図1 Lattix を活用して開発された組み込みソフトウェアを搭載するリコーの最新デジタルカメラ「GXR」

　そうしたリコーの高機能なデジタルカメラを支えているのが，組み込みソフトウェアだ．自動車，携帯電話，デジタル家電など電子制御で動くあらゆる機械・機器には，その心臓部にコンピュータシステムが組み込まれている．そのシステムにさまざまな機能を付加し，稼働させる役目を果たすのが組み込みソフトウェアだ．製品内部にあって容易に書き換えることができず，その出来が製品の品質を左右するため，どのメーカーも組み込みソフトウェアの品質管理には細心の注意を払っている．もちろん，リコーのデジタルカメラも例外ではない．
　しかし，複数の機種を同時に効率的に開発するためには，より厳しい品質管理体制が求められる．そこでリコーが取り組んだのが，組み込みソフトウェアの構造を整理するという活動だった．
　「当社では，全般的な組み込みソフトウェアの品質向上を実現するために，コードの構造を整理していくという活動に取り組んでいます．たとえば，変更個所を特定しやすくするには，依存関係を整理しておかないといけません．そういう活動の積み重ねによって整理されたものがあったことで，たとえばGXRのようなユニット交換式カメラの開発も可能となりました」（リコー パーソナルマルチメディアカンパニー ICS設計室 牧 隆史氏）

 ●依存関係の可視化を実現 

　リコーのデジタルカメラ開発部門が，組み込みソフトの品質の観点で依存関係に着目しはじめたのは，2006年前後のことだという．
　「それ以前から，静的解析などいくつかの品質向上のための取り組みは行っていましたが，依存関係の確認を組織的に行うことはあまりされてきませんでした．特に以前は，デジタルカメラに求められる機能が現在ほどは多くなかったため，開発者の人数も限られていたので，ある意味開発者に任されている部分があったともいえます」
　しかし，こうした属人的な品質管理では，さらなる開発効率の向上，開発期間の短縮という課題を解決することは難しい．それを改革する手段として，牧氏が中心となって取り組んだのが，組み込みソフトウェアのソースコードの依存関係を可視化するということだった．
　「これまでもソースコードを静的解析したり，アーキテクチャを図式化したりしてモジュール構造の依存関係を把握しようとしてきましたが，それを基に実際にコーディングする際に，ルールが守られているかどうか確認する手段はなく，開発者に委ねられていたわけです．そこで，コードの依存関係を把握したり，呼び出し関係を解析したりできるツールを探したところ，ちょうどよいタイミングで私たちが探していた機能を持つLattixに出合ったわけです」

●開発効率と開発スピードが向上

　依存関係を把握したいという問題意識を持っていたリコーにとって，Lattixが提供する機能そのものが成果物と言えるものだった．牧氏はさっそく，Lattixの国内販売元であるテクマトリックスにコンタクトをとり，デモライセンスを入手して製品の評価を実施．有用性を確認した後に導入したという．
　「組み込みソフトウェアのソースコードをLattixにすべて読み込ませ，アーキテクチャを検証するために利用しています．たとえば，新製品には新機能を実現するための新しいモジュールが入っています．新しいモジュールは，既存のモジュールから呼ばれたり，既存のモジュールを呼んだりという依存関係が必ず出てくるので，Lattixを使って依存関係が正しく実装されているかどうかを確認しています」
　こうしたコーディング成果物の品質チェックは，プロジェクトごとに行われてい
るという．
　「かつてはソースコードを目で見て確かめていましたが，開発規模が大きくなるにつれ，すべてを見ることはできなくなってきました．明示的な依存関係は検出できても，そうでないところの検出は困難です．そのためにもツールの力は必要です」
　牧氏は，Lattixを導入した効果も実感しているという．
　「ルール違反になっている部分が可視化できる点（図2）が一番大きなメリットです．上級のプロジェクトマネージャにも，どのドメインに問題があるか一目で理解してもらえるので，対策が取り易くなりました．もちろん，このツールを使うことで製品開発における問題の全てが解決するわけではありませんが，開発効率が向上したことで，結果的に品質が向上したと考えています」

図2 Lattixによるアーキテクチャルール違反の可視化イメージ

　開発スピードも早くなったと評価する．
　「開発スピードの向上にも寄与していると思います．正確に計測したわけではありませんが，ソースコードを目で見て確認しなければならない場合は，開発に着手する前に依存関係などを調べなければならず，それが時間のロスにつながっています．そういう部分がかなり短縮できました」

 ●他のツールとの連携に期待 

　今後は，Lattixの進化に期待しているという．
　「マトリックスで表示されるLattixの画面は，定量的で分かりやすいです（図3）．アーキテクチャ分析機能のベースとなるDSM（Dependency Structure Matrix）が完成された手法なので，それを見るツールという観点では完成されていると思います．

図3 Lattix のDSM（イメージ）

　ただし，スペックの低いマシンで利用する場合，大量のソースコードを読み込んでセルの数が増えると，やや速度が低下することがありました．構造上，仕方のないことだとは思いますが，次のバージョンでパフォーマンスが向上したと聞いていますので，最新バージョンを使用するのを楽しみにしています．また，現バージョンでは，Understand（ソースコード解析ツール）の結果をLattixに読み込んだり，LattixからUnderstandを起動したりすることができますが，このようなツール連携を他のツールとも実現してもらえると助かります」

以上