品質改善に役立つ注目のツール

2009年8月末に発売される 組込みプレス Vol.16 で『品質改善に役立つ注目のツール』 という特集記事をコーディネイトした。

この記事では ソフトウェア品質診断ツール eXquto と アーキテクチャ分析ツール Lattix の2つのツールを比較している。

記事をコーディネイトするにあたって一番気をつけたのは、ツールを使うユーザーの利益が最大になるように情報を提供するということだ。

ともすればツールの紹介記事は売り手側の都合のよい情報だけが一方的に伝えられツールの弱点や有効に使うためにユーザーサイドが負うべき責務は隠されてしまうことがある。

そこで、今回の記事では、何十万円もするツールの購入は組織に対する投資と位置づけ、なぜ、そのような投資が必要なのかという前提条件について、まず、解説し、次に2つのツールのベンダー及びパートナーに、ツールの特長を紹介してもらい、最終章でツールを現場で有効利用するためのヒントを書いた。

【記事をコーディネイトしようと思ったきっかけ】

eXquto はソフトウェア品質診断ツール、Lattix はアーキテクチャ分析ツールで、どちらも現在あるソフトウェアシステムをよりよくするための道具である。1980年台、1990年台、ソフトウェア工学はどのようにシステムを分析設計するのかに注力を注いできた。リファクタリングという取り組みはあったものの、リファクタリングはどちらかと言えば、プログラマが個人の範疇でソフトウェアを再構築することを指していたと思う。

しかし、組込みソフトウェア開発の現場では、試行錯誤を繰り返しすでに30万行を超え、100万行を超えるようなソフトウェアを作り込んでしまっていた。

経済産業省 2008年度版 組込みソフトウェア産業実態調査報告書によると、平均的な組込みソフト開発のモデルは次のようになる。

• 組込みソフト開発費：1200万円～3000万円
• 使用開発言語：C言語
• システム規模：20～50万行
• 新規開発行数規模：2～5万行

実際のソフトウェア開発では、新しい製品開発であっても20～50万行のソフトウェアをゼロから作ったりはしない。すでにある既存製品の大部分を使い、それらの10%程度のソフトウェアを新規に作成する。

それはかなり泥臭い世界であり、すでに作り込んでしまったぐちゃぐちゃのプログラムも嫌々ながら使い続けなければいけないのだ。形式手法を使って仕様とプログラムの関係の完全性を証明できるような取り組みができるのはほんのひとにぎりの開発に過ぎない。

情報工学の研究者達はこのようなすでに作り込んでしまった相当な規模のソフトウェアをきれいにするというエンジニアリングについて有効な方法論を考えるのが苦手だ。苦手かどうかのバロメータは彼らの研究が現場にどれだけ近いか、現場とともに問題の解決に取り組んでいるかどうかで分かる。

我々は、ソフトウェア開発の現場と研究者の距離が縮まることを待っているほど余裕はない。だから、2000年台は、ツールを使ってすでにあるシステムを分析し、捨てるのか、再構築するのかを判断する基準を作っていく必要がある。

【記事のメイキング】

今回はまず最初に組込みプレス編集部に企画案を提示し、了解を得て、eXquto の開発元である(株)エクスモーションさん販売もとの(株)東陽テクニカと、Lattix の販売元のテクマトリックス株と Lattix を使ったコンサルテーションを実施している イーソル/RCS の双方に記事の企画を打診した。幸い、双方からOKの返事をもらったので、イントロは酒井、eXquto の紹介記事はエクスモーションに、Lattix の紹介記事は テクマトリックスとイーソル/RCS に、まとめを酒井が書くようにした。

イントロでは経済産業省 2008年度版 組込みソフトウェア産業実態調査報告書のデータをもとに、どのような開発で今、何が求められているのか、ソフトウェア開発の効率化、品質向上にはどれくらいの投資がふさわしいのかを書いた。

ツールの紹介はそれぞれに同量のページ数ぶん書いてもらい、比較表は酒井が原案を作って双方に提示し、それぞれ修正を繰り返すことにした。比較表はツール屋さんに取ってはもっともシビアな部分であり結果的に延べ20回の修正を行った。

そしてまとめの部分は、酒井がユーザーの目線でツールを宝の持ち腐れにせず、有効利用するためにはどのような覚悟が必要か、どれくらいツールメーカー、ツールベンダーと真剣に対峙する必要があるのかを書いた。ツールに対する注文も書いたためツールベンダー、ツールメーカーとぎりぎりの調整も行った。

この特集記事の最後に「ツールを宝の持ち腐れにしないためには」について書いたので是非読んでいただきたい。

【品質改善に役立つ注目のツール 第4章 ツールを現場で有効利用するためのヒントより引用】

■ ツールを宝の持ち腐れにしないためには

　この特集記事を読んでいただいているソフトウェアエンジニアのみなさんによく考えて欲しいのはソフトウェア開発は基本的にはソフトウェアエンジニアの日々の活動の成果の積み重ねであり、ソフトウェアエンジニアの頭の中で考えたことが最終成果物になるということです。ソフトウェア開発で何か状態を変化させるということは、すなわちソフトウェアエンジニア自身（正確に言えばエンジニアの頭の中）がある状態から別の状態に変わるということなのです。したがって、自分自身が変わる気はさらさらなく、ツールが問題解決のソリューションを提供し、ツールを導入するだけで成果物がよい方向に変化してくれるはずだと考えているとたいてい失敗します。

　ソフトウェア開発を支援するツールには何らかのソリューションが隠蔽されているのは確かです。しかし、利用者はそのソリューションがどんな問題を解決するのに有効であるのか、どのようなケースの問題解決に向いていて、どのようなケースの問題解決は苦手であるのかを理解する必要があるし、場合によっては自組織や開発製品に合わせてツールの使い方をくふうしたり、ツール自体をツールメーカーやツールベンダーにカスタマイズしてもらったり、改善してもらわないといけないこともあります。

　品質改善に役立てる目的で販売されているツールは、そのツールを使うことで実システムの品質改善やアーキテクチャ改善ができなければ、導入してもまったく意味がありません。今回紹介したツールベンダー、ツールメーカー、コンサルテーション会社は筆者がみな個人的にも付き合いがある会社です。ユーザーサイドが自分のプロジェクトやソフトウェアシステムの改善を本気で取り組もうとしているのならば、彼らも途中で投げ出さずに付き合ってくれることは分かっています。ツールベンダー、ツールメーカーはすべての組込み開発の現場を知っているわけではありません。彼らのセールストークを信じてツールを購入し改善が進まないのなら、何が問題なのかを彼らに伝える義務がユーザーにはあると思います。そのようなユーザーの意見をフィードバックするからこそツールメーカー、ツールベンダー、ツール自体がよりよく進化していくのです。

　ツールを宝の持ち腐れにしないためには、ツールが持っている効果、効能を正確に判断し、長くつきあえる正直なツールメーカー、ツールベンダーを探し、壁にぶち当たっても簡単にあきらめずに、ツールとともに彼らと長くつきあう覚悟で改善を進めることです。それができないプロジェクトや組織はせっかく購入した高価なツールをいずれは放置し腐らせることになります。ツールを選ぶ確かな目を育てるには、失敗の経験を積むことも必要ですが、失敗の経験はできるだけ影響の小さい範囲で積み重ねて、百万円クラスのツール選択では失敗のないようにすることが大事です。

【引用終わり】