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

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章 ツールを現場で有効利用するためのヒントより引用】

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

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

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

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

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

【引用終わり】

ツールの導入とは自分自身が変化するということ

Embedded Technology 2008 が終わった。5月のESECと11月のETは組込み系の首都圏で開催される2大イベントで、これらの展示会に行くことでツール類の情報や、開発方法論の情報などをチェックする。

日頃、ソフトウェア開発に関するツールについて、「ツール至上主義はいけない」とか「ツールベンダーの口車に乗ってはいけない」などと言っているが、ツールについて最新情報をチェックしていない訳ではない。何が本当に役に立つのか、立たないのかの判断基準を自分の中にしっかり持ってツールを見定めているし、ツールベンダーの話も聞くようにしている。

そういう目で展示会の会場を回っていると、ツールを通してエンジニアを助けてあげたいと思っているツールメーカー、ツールベンダーと、時流にのって売り上げを伸ばすことだけを考えているツールメーカー、ツールベンダーが見分けられるようになる。

ツールメーカーは純粋にソリューションを提供したいと考え、ツールベンダーは売り上げしか考えていないとか、ツールベンダーの営業員によっても目先の売り上げだけを考えている者と、ユーザーと長く付き合うために何とか要望を聞いてあげたいと考える者がいるので、一概にあの会社はいいとか悪いとか言えないが、好ましくないベンダーは好ましくないユーザーがいるからこそ生き残ってしまうのではないかと思うことがある。

ET2008の展示会場で 富士設備工業（株）電子機器事業部 の浅野さんと話しをしていたときのことだ。（富士設備工業なんて、およそソフトウェアと関係ありそうもないが、実は海外の開発ツールを積極的に導入しサポートまで提供している）

富士設備工業（株）電子機器事業部 では、ソフトウェアプロダクトラインの支援ツール pure::variants を取り扱っている。今でこそ、ソフトウェアプロダクトラインはメジャーなキーワードになりつつあるが、たぶん日本で初めて話題になったのは2003年くらいからだと思う。当時、自分はEEBOFでソフトウェアプロダクトラインのことを知り、CQ出版の Interface誌 2003年12月号で『具体例で学ぶ組み込みソフトの再利用技術』というタイトルで自分がモデレータとなってソフトウェアプロダクトラインにも関係する記事を書いた。浅野さんはこの記事をことを覚えていてくれて、当時ソフトウェアプロダクトラインの情報源のひとつとして役に立ったと言ってくれた。

浅野さんとソフトウェアプロダクトラインを日本で成功させるのは簡単ではないという話をしていたら、お客さんの中にはツールを導入しても結果的にうまくいかず、ツールやそのソリューション自体に対して役に立たないという烙印を押してしまい、その経験がトラウマになってしまう人たちもいるということを聞いた。

自分はツールを導入するきっかけは、技術者個人がある状態から別の状態に変化すること、あるいは変化したいと思うことにあると考えている。

現在の状態では問題がある、効率が悪い、品質が上がらないので、それらの問題を解決し、開発効率がよい状態、ソフトウェア品質が高い状態に移行したいと考え、ツールが状態変化に必要だから導入するという考え方だ。

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

一番成功する確率が高いのは、技術者が自分自身で状態の変化を手作業で実現し、その手作業の工程を自動でやってもらうといケースだ。手作業で業務なりプロセスなり、活動なりを改善し、その一部をツールに任さるためにツールを導入するケースだ。すでにやったことがあって効率化を図るという方法ならほとんどの場合成功する。

それとは逆に自分自身が変わる気がなく、ツールを魔法の箱にように見たてて期待していても何も起こらない。高い金払ったのだから何か出せと言っても何もでてこない。

ただ、ツールを購入したことをきっかけにして、ツールを使いこなせるようになることで自分自身の変化のきっかけにする人はいると思う。でも、自分自身の変化の必要性の認識とそのたいへんさが十分に理解できていないと結局は途中でくじけてツールはお蔵入りとなる。

世の中には操作者が何も考えなくてもインプットを与えて期待するアウトプットを出力するタイプのツールもたくさんある。でもソフトウェア開発に使うツールはソフトウェア開発自体がひとつの方法論には集約できないのでそんな単機能のツールなど存在しないし、そのような単機能なツールはあったとしても一般化されているのでESECやETで物色することもないのだ。

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

ツールを使うユーザーが自分自身の変化について心の準備ができており、変化しなければならない目的が明確になっており、その目的のためには多少の犠牲も必要というそれなりの根性があればツールは活きてくる。そのようなユーザーに手厚く援助してくれるツールメーカーやツールベンダーを見つけないといけない。

その自信がないユーザーはまずは、ツールを買うのでなくソリューション自体を学習したり、手持ちの道具を使って問題を解決してみることを考えるとよい。解決できる見通しが立ってからツールを導入すれば失敗はしない。

実は、Excel や Word やフリーのツールなどをくふうすることで解決できてしまう問題はたくさんある。そういう努力を日々やっていると、「なんで、わざわざこんなツールを作るの？」とクビをかしげたくなるようなツールも見えるようになってくる。