」そうして必要な資料を見せていただきつつ、自分の作ったシミュレーション環境を使おうとしたらアラ不思議。言われるがままに大量の機能をぶちこんで作ったシミュレーション環境、用意するだけで数時間かかるし、シミュレーション開始ボタンを押してから動き始めるまでに1分かかったりします。こんなもん使えるか(自分で作ったことを棚にあげつつ)」まず、こんなツールを作っちゃった事を大反省です。そりゃー、誰も使わないわけだ。そこで、業務を実施するのに、本当に必要最低限な機能だけを持ったツールを作り直すことにしました。ツールを作り始めること、約4時間。バカでかい制御モデルから、本当に見たい部分だけをサクっと切り出して動かすツールの完成です。厳密さなんか、どうでも良し。使えることが最優先ですよ。して作ったツールを元に、不具合解析すること約4時間。「原因がわかりました。「え?もう分かったの?」このあと、何パターンかレアな不具合の解析をまかされましたが、このツールを使ってさくっと解析、さくっと原因究明です。こりゃイケるぞっていう事で、ツールにちょろっとマニュアル付けてみましたらば、制御開発責任者の方にバカ受け。あっという間に現場に広めていただき、バリバリ使われるようになりました。その結果、部署内の説明会で、マネージャー層に紹介されるまでになりました。(これ、ちょっとすごい事なんです)3か月かけて作ったツールは見向きもされないのに、半日で作ったツールがこんなにウケるとは・・・ちょっとショックでしたね。何がいけなかったのだろう?と反省しますに、たとえ必要な機能を持っていたとしても、以下の条件を1つでも満たしているツールは使われにくいように思います。(現場の人は、バッドノウハウに興味なし!)理想のモデルベース開発を実現しよう!だとか、色んなパターンで使えるように汎用性を持たせよう!だとか考えはじめると、たいがいどれか1つ2つに引っかかります。業務改善効果は0ですから、そういうのは非常にマズいんですね。これに対抗するには、大きく3つの方法があります。パターン1:現場に特化して、極限までシンプル化たとえば、上記の不具合解析ツールですが、今のお客様の現場でしか使えません。汎用品ではないのです。お客様が使われている開発ツール、お客様が採用されているモデル構成、そういったものに極限まであわせています。その結果、5分で準備完了、超高速でシミュレーション実行、という事が実現できています。覚えないといけないことや、必要な操作も最小化しているため、ちょっと使ってみようかな、という気になり易いようです。パターン2:難しい事は、肩代わりたとえば、お客様の部署ではHILSがよく使われています。・用意するのは大変(I/O回りからプラント整備まで、沢山のノウハウが必要)・使うのは簡単(ベンチや車両と同じようにECUを用意するだけ)という両面性があります。そこで、HILSの大変な部分はすべて私が受け持っています。「難しい部分はやっておきましたから、一通り動くようになってます。あとは、やりたい評価にあわせてプラントモデルいじるだけでいいですよー」という状態を常に保っているため、みなさん適当にイジってはECUの動作確認をされています。その他にも、夜中にモデルをごにょごにょするシステムを作っているのですが、このシステムの管理はノウハウが要るので私の仕事です。した結果は誰でも見られる形式で公開しており、それを見るのにノウハウ等は一切いりません。これも皆さんに使っていただけているようです。パターン3:使え!と強制するまったくもってオススメできない手段です。少なくとも私の関与するところではありません。パターン1、パターン2、いずれかをトコトンつきつめて、納得しながら使って頂けるのがベストです。ツール屋さんの仕事って?ツール屋さんの目標は、ツールを通じて、お客様の業務を改善する事です。ツールの持つ効用といったところでしょうか。複雑なツールを作ると、あっという間にツール利用率は0に落ちますから、とにかく工夫が必要です。ツール屋さんの仕事とは、「シンプルさと機能のバランスが取れたツールを作ることで、業務の改善効果を最大化すること」と言える気がします。(「シンプルさ」とは、あくまでユーザーから見たものなので、難しい部分を誰かがやってくれる仕組みにしておけば、それはそれでアリと言えます。コメントを投稿して頂くには、JavascriptとCookieを有効にしていただく必要がございます。