以前、一年分の仕事が確保できたと一人よろこんで居たわけですが、そのあと契約が進まず。。。いよいよ、新しい案件探しに走らないといけないか？と心配しはじめたところで、ようやく契約成立しました。ホッ。

さて、最近「ツール屋さんの仕事って何なんだろう？」と考えさせられる出来事があり、ここで自分の考えを整理してみたいと思います。

使われないツールたち

モデルベースといえば、ラピッドプロトタイピングから始まり、MILS、SILS、HILS、自動コード生成、テストパターン生成など、ツール作りのネタになりそうなトピックが盛りだくさんです。

これまで、長い時間をかけて沢山のツールを作成させていただきましたが、ほとんど使われていないツールがたくさんあります。

そういったツールの作成は、だいたい次のようなストーリーで進んでいきます。

お客様 「モデルベースは、こうあるべきだ。だから、こういうツールを作りたい。やれるな？」

私 「ははー。おおせのままに。」

・・・３か月後・・・

私 「おっしゃる通りのツールが出来ましてございまする」

お客様 「よし、よくやった。では現場に配るとしよう」

・・・さらに１か月後・・・

私 「現場では、だれも使ってない。ガーン。」

うーん、実に残念。ツール屋さんの最終目的は、お客様の業務改善にあると思っています。ツールを作って、それが開発効率を少しでも押し上げられたとき、はじめて費用をかけた意味が出てきます。

ツールを誰も使っていない ＝ 業務改善効果は０

という残念な状況に、ガッカリすることひとしおでした。

お客様の方針転換と、あらたな発見

ここで、お客様の方針が変わります。これまではお客様がツールの要望を出し、それを私が作成するという形でした。それが、次のようになりました。

お客様 「吉武さん、車両で実際に起こった不具合の解析業務を出してあげるから、実際にやってみて？」

私 「ははー。おおせのままに。」

そうして必要な資料を見せていただきつつ、自分の作ったシミュレーション環境を使おうとしたらアラ不思議。

言われるがままに大量の機能をぶちこんで作ったシミュレーション環境、用意するだけで数時間かかるし、シミュレーション開始ボタンを押してから動き始めるまでに１分かかったりします。

私 「ふざけんな。こんなもん使えるか（自分で作ったことを棚にあげつつ）」

まず、こんなツールを作っちゃった事を大反省です。そりゃー、誰も使わないわけだ。そこで、業務を実施するのに、本当に必要最低限な機能だけを持ったツールを作り直すことにしました。

ツールを作り始めること、約４時間。バカでかい制御モデルから、本当に見たい部分だけをサクっと切り出して動かすツールの完成です。厳密さなんか、どうでも良し。使えることが最優先ですよ。

こうして作ったツールを元に、不具合解析すること約４時間。原因判明！

私 「原因がわかりました。微妙なタイミングで起きる、すっごいレアな不具合ですねー」

お客様 「え？もう分かったの？」

このあと、何パターンかレアな不具合の解析をまかされましたが、このツールを使ってさくっと解析、さくっと原因究明です。

こりゃイケるぞっていう事で、ツールにちょろっとマニュアル付けてみましたらば、制御開発責任者の方にバカ受け。あっという間に現場に広めていただき、バリバリ使われるようになりました。その結果、部署内の説明会で、マネージャー層に紹介されるまでになりました。（これ、ちょっとすごい事なんです）

３か月かけて作ったツールは見向きもされないのに、半日で作ったツールがこんなにウケるとは・・・ちょっとショックでしたね。

傾向と対策

何がいけなかったのだろう？と反省しますに、たとえ必要な機能を持っていたとしても、以下の条件を１つでも満たしているツールは使われにくいように思います。

・実行するのに時間がかかる （現場の人は、とっても忙しい！）
・習得するのが大変 （現場の人は、自分の業務で頭がいっぱい！）
・ちょっとでも問題があると動かなくなる （現場の人は、バッドノウハウに興味なし！）

理想のモデルベース開発を実現しよう！だとか、色んなパターンで使えるように汎用性を持たせよう！だとか考えはじめると、たいがいどれか１つ２つに引っかかります。

ツールを誰も使っていない ＝ 業務改善効果は０

ですから、そういうのは非常にマズいんですね。これに対抗するには、大きく３つの方法があります。

パターン１：現場に特化して、極限までシンプル化

たとえば、上記の不具合解析ツールですが、今のお客様の現場でしか使えません。汎用品ではないのです。

お客様が使われている開発ツール、お客様が採用されているモデル構成、そういったものに極限まであわせています。

その結果、５分で準備完了、超高速でシミュレーション実行、という事が実現できています。覚えないといけないことや、必要な操作も最小化しているため、ちょっと使ってみようかな、という気になり易いようです。

パターン２：難しい事は、肩代わり

たとえば、お客様の部署ではHILSがよく使われています。HILSは、

・用意するのは大変（I/O回りからプラント整備まで、沢山のノウハウが必要）
・使うのは簡単（ベンチや車両と同じようにECUを用意するだけ）

という両面性があります。そこで、HILSの大変な部分はすべて私が受け持っています。「難しい部分はやっておきましたから、一通り動くようになってます。あとは、やりたい評価にあわせてプラントモデルいじるだけでいいですよー」という状態を常に保っているため、みなさん適当にイジってはECUの動作確認をされています。

その他にも、夜中にモデルをごにょごにょするシステムを作っているのですが、このシステムの管理はノウハウが要るので私の仕事です。一方、ごにょごにょした結果は誰でも見られる形式で公開しており、それを見るのにノウハウ等は一切いりません。これも皆さんに使っていただけているようです。

パターン３：使え！と強制する

まったくもってオススメできない手段です。少なくとも私の関与するところではありません。

パターン１、パターン２、いずれかをトコトンつきつめて、納得しながら使って頂けるのがベストです。

ツール屋さんの仕事って？

ツール屋さんの目標は、ツールを通じて、お客様の業務を改善する事です。

業務の改善効果 ＝ ツール利用率 × ツールの持つ効用

といったところでしょうか。ちょっと複雑なツールを作ると、あっという間にツール利用率は０に落ちますから、とにかく工夫が必要です。

ですから、ツール屋さんの仕事とは、「シンプルさと機能のバランスが取れたツールを作ることで、業務の改善効果を最大化すること」と言える気がします。

（「シンプルさ」とは、あくまでユーザーから見たものなので、難しい部分を誰かがやってくれる仕組みにしておけば、それはそれでアリと言えます。）