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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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