前の章では、「組込み制御ソフトウェア」の開発に利用するツールが、話題に出てきました。ちょうど良いタイミングなので、この章では、開発ツールを選ぶ際に、気をつけることについて、取り上げて見たいと思います。
まず、開発ツールは、カタログの記載内容だけで導入を決めるのではなく、実際に評価するべきです。多くのツールでは、その評価利用期間が限られているので、十分な時間が取れるタイミングで、評価を開始できるよう、計画を建てることも重要です。
評価の効率や精度を上げるには、ツールの体験セミナーを活用して、使い方を学んでから、評価を開始しても良いでしょう。さらに評価の効率や精度を上げようとするなら、あえて有償のセミナーを受講してから評価する方法もあるでしょう。時間をかけて評価できる利点の他に、ツールベンダーの技術担当者の技術力や、誠意ある対応ができるかどうかも、把握できるでしょう。私自身も、かつて、シミュレーションツールの選定で、当時良く耳にしていた、２種類のツールの中から、１種類を選定するミッションを任されたことがありました。当時、機能が優れていると言われていたツールについて、セミナーを受講しに行ったのですが、技術担当者にシミュレーションツールのオプションである、自動コード生成機能の活用について相談してみたところ、「そういうのはやめた方がいい」と、全く取りあってもらえませんでした。その後、もう一方のツールも評価し、担当者へ相談したところ、「できるはずです。」という前向きな回答で、親身にサポートしてもらえたことから、そのツールを採用して、実際の開発への適用しました。当時は自動コード生成ツールは、まだ最適化機能が不十分だったため、自動で生成したコードは、一部のみの利用に留まりました。それでも、シミュレーションを活用して、要求仕様設定とソフト設計の精度を上げることができたので、組込みソフト開発期間の短縮につながり、ツール導入の成果をしっかり得ることができました。
一度導入したツールを、その後のプロジェクトでも利用する可能性がある場合、ツールベンダーの継続的な対応能力も、ツールの導入条件として考える必要があります。これは、人伝てに聞いた話ですが、あるメーカの方は、当時２種類のツールの中から、１種類を選定する際に、知人のアドバイスから、それぞれのツールベンダーの製品開発者に会いに行ったそうです。その際、機能が優れていた方の製品の開発者の対応があまり芳しくなく、良く調べると企業買収があって、重要な部分の開発チームがいなくなっていたことがわかったそうです。もう一方のツールベンダーは、しっかりとした開発チームが存在し、親身に話を聞いてくれたことから、そちらの製品の導入を決めたそうです。その数年後には、開発チーム不在のツールの更新が止まってしまい、そのツールを組織導入していたユーザは、大変困ったことになったと聞きました。数年間経過すると、OSに大きな変更が発生したり、ソフト開発に利用するコンパイラーなどの主要ツールも変わったりします。それらの変化に合わせて、ツールも更新する必要があり、開発チーム不在では、その対応が難しい状況だったのかもしれません。
補足ですが、上記の通り、OSやコンパイラーなどが更新される影響で、定期的に、開発ツールをバージョンアップすることも、ツールの運用として、想定しておく必要があります。私たちは、2000年から2020年の間に、32bitPCから64bitPCへの切り替え、セキュリティ対策や、サポート期間終了に伴うOSの複数バージョンアップ、PCの主要プログラミングツールの仕様変更などを経験しました。ツールベンダーは、ユーザからの要望や、製品の付加価値を高める目的で、ツールの更新を行いますが、その中で、上記の変化に対応しています。私自身、内製シミュレーションプログラムを開発・メンテナンスしていた経験から、自分たちで、このような変化への対応をすることは、厳しいと感じます。ツールベンダー側で対応した製品を導入することを検討したくなるのは、私だけではないでしょう。
この章では、開発ツールを選ぶ際に、カタログの記載だけで決めるのではなく、しっかり評価して決めるべきということ。そして、製品の機能だけでなく、ツールベンダーの製品サポート力を確認することも、重要であること。特に長く開発ツールを利用する場合や、組織導入する場合は、ツールベンダーの開発チームの対応力（定期的な更新があることなど）に、気をつけることについても、説明しました。
