近年はデジタルトランスフォーメーションが避けて通れないテーマとなっています。モデルベースエンタープライズへの移行から、インダストリー4.0のアプローチ導入に至るまで、トランスフォーメーションという言葉の意味は人によって異なります。しかし、テクノロジの進歩に後れを取ることは許されません。そうしたテクノロジによって、新しい機能や製品をより早く市場に投入することができます。
検証と妥当性確認を担当するV&Vチームは、組織のデジタルトランスフォーメーションにおいて中心的な役割を果たせる、また果たすべき存在です。製品の性能に関する洞察を提供し、品質の保証と意思決定の迅速化の両方を実現する存在です。真の問題は、どうすればV&Vテストチームが予算やリソースを増やすことなく、そうした取り組みを進められるのかということです。デバイスの複雑性が絶えず増大し、より多くのテストをより短時間で実行しなければならない状況の中で、そうした必要不可欠な洞察にたどり着くまでの時間をどのように確保すればよいのでしょうか。
それには、V&Vのワークフローとプロセスを評価し、小さな変化が大きな影響をもたらす可能性のある領域を明らかにします。また、V&Vチームの効率を高めて、V&Vのフェーズで生じるトレードオフを減らし、リスクを軽減します。また、簡単なクイズに答えてテスト戦略のプロファイルを特定し、チームの目標に沿ったプロセス、システム、およびデータ向けにカスタマイズされた提案を受けることも検討してください。
制限について理解するためには、ワークフローの大まかな部分から出発して、全体を細かく分ける必要があります。そうすることで、製品の開発からテスト、製造、顧客への納入までのプロセス全体にわたって、制限がどのように当てはまるのかを理解することができます。
通常のワークフローでは、エンジニアリング検証テスト (EVT) の段階が近づくにつれて、V&Vエンジニアが関与し、仕様や要件について設計エンジニアと話し合いを始めます。大まかな手順を確認しておきましょう。
次のステップは製品の合否に応じて決まり、設計を反復してテストするか、製造部門に引き渡して製造へと進める可能性があります。
図1. V&Vテストエンジニアリングの典型的なワークフロー
こうした典型的なワークフローを客観的に評価してみると、手動での作業を必要とするステップが多くあることに気づきます。これらの意図しない非効率性は、最初はそれほどでもないように思われるかもしれませんが、立ち寄りやデータ転送の手順をすべて足し合わせると、その影響は大きくなります。製品がスケジュールどおりに市場に出せなくなる可能性があるうえ、すべてのテストを再実行する時間が取れないために、最終的に品質よりもリスクを受け入れることになります。
ステップ自体に改善できる領域がある場合も多くありますが、見落としがちなのが、チームによるこれらのステップ間の移行方法です。あるステップから次のステップに進む方法が非効率的であると、変更が生じたときに手動でドキュメント化を行うため、生産性だけでなくトレーサビリティも失われます。最適化や自動化を図ることでワークフローの効率を大幅に増やせる領域について、いくつか注目してみましょう。
デジタルトランスフォーメーションの取り組みで大きな成果を上げている企業は、多くの場合、部門間の孤立化を解消することに成功しています。特にV&Vチームの場合、どの製品をパイプラインに含めるのか、どの機能を組み込む予定なのかについて、チームが関与し認識するプロセスが存在します。V&Vが早い段階から関与するほど、適切に計画を立てることができます。
関与とは、会議に延々と参加するだけでなく、設計チームによって生成されるデータ (i)、特にシミュレーションデータにアクセスできることを意味します。V&Vチームが製品についての理解を深めるほど、テスト計画が向上します。
V&Vテストエンジニアは設計エンジニアリングとより緊密かつ早期に連携して作業したいと考えるかもしれませんが、重要なのは、製造テストチームも早期に関与させる必要があるということです。製造部門では、早期の段階で何をテストするのか、どのようなテスト方法を用いるのかを理解し、最終的にはテスト計画のどの領域で問題が見つかったのかを理解する必要があります。そうすれば、最終製品がV&Vからリリースされた時点で、製造とテストを開始する準備をより適切に整えることができます。
多くの場合、V&Vテストチームでは、さまざまなテクノロジについてテストを実行できるように、多様な装置が必要になります。また、まれに生じる対処の難しいシナリオについてもテストできるようなテストカバレッジをシステムに設けておく必要もあります。当然ながら、V&Vの実行にはさまざまな高価な装置が必要です。
再利用や転用について検討する際、どの装置をテストに転用できるかを調べるにはかなりの時間がかかる可能性があります。たとえば、さまざまなテスタのもとへ出向き、ニーズに合った装置を探し、その装置が現在使用されているかどうかを調べ、誰がそのテストを担当するのか、そして必要な期限までにテストが完了するかどうかを追跡する必要があり、こうしたすべての作業には時間がかかります。
適切な装置を見つけられたとしても、さらに考慮すべき事項が発生します。装置はあとどのくらいでキャリブレーションが必要になるのか、キャリブレーションされていない装置を使用して品質を損なわずにテストを完了することができるか、などです。こうした複雑さがあるにもかかわらず、たいていは新型の装置の調達に踏み切るというケースが多く見られます。新型の装置は高価であるばかりか、調達のプロセスにも貴重な時間が割かれます。
装置が必要になるたびにこうした決まりきった作業を繰り返すのではなく、システム内にあるデバイスの追跡を自動化することが必要です。そうすれば、どの装置がどのテスタにあるか、テストが実行されているかどうか、その特定のテスタで装置がどのくらい利用されているかを、すべてひと目で確認することができます。こうした機能を確保することで、時間のかかる面倒なテスト装置の検索が不要になります。そうした洞察が得られると、チームはデータに基づいて装置に投資し、本当に必要な場合にのみ装置を調達できるようになります。その結果、予算を他のことに振り向けることができます。プロセスにおいて効率改善が必要な部分を特定することから始めた作業が、コスト管理の改善にもつながるというわけです。
テストシステム用のソフトウェアの開発は、V&Vテストエンジニアが実行する必要のある最も時間のかかるタスクの1つですが、最も重要なタスクの1つでもあります。時間には限りがあり、期限を守る必要があります。そのため、それぞれのV&Vテストエンジニアに、ソフトウェア開発に必要な言語を選んでもらうのが良いと考えるかもしれません。その場合、エンジニアは使い慣れている言語を選ぶことが前提になります。しかし、たとえばソフトウェアシステム全体で十数種類の異なるプログラミング言語を使用する状況になったとしたらどうなるでしょうか。共通のフレームワークや一連のコーディングルールがなければ、カスタマイズされたテスタを構築する可能性がありますが、保守ができなくなり、コードの再利用も難しくなります。コードを作成したエンジニアが会社を離れたり、別の役職に異動したりした場合は、さらに困難な状況に陥る可能性があります。同じタイプのテスタを2回か3回構築すれば、こうした非効率性の影響を実感することになるでしょう。
このような状況を改善する方法を検討するには、まず、V&Vラボでさまざまなタイプのテストを実行していることを幅広く理解することから始めます。単純なユーザ入力に基づいて単純な制御を行う場合もあれば、厳密なタイミング要件を順守しながら実行される高度なテストルーチンを必要とする場合もあります。効率の向上を目的としているため、このような幅広さが重要になります。したがって、単純なテストにはノーコード/ローコードの選択肢を利用できるようにし、ソフトウェア開発の時間を本当に必要なテストにのみ集中させる必要があります。
より複雑なテストの場合は、標準化されたオープンなフレームワークを利用して効率を上げることができます。こうしたフレームワークは、さまざまな言語で開発されたコードモジュールを呼び出すことができ、ニーズに合わせてカスタマイズできる柔軟性を備えています。データ収集、合否の評価、他のバックエンドシステムとの統合など、必要となる共通のコンポーネントをひとたび開発して、すべてのテスタでそれらを再利用できるようにすれば、適切な基盤が整備され、効率が向上してリスクが軽減されます。その結果、V&Vテストエンジニアはフレームワーク全体ではなくテストルーチンの構築に専念できるようになり、最終的にはテスタをより迅速に立ち上げることができます。ただし、こうしたメリットを真に発揮するためには、いつ、どのような場合にノーコードを選択するのではなくフレームワークを採用するのかを定めたプロセスを設けておく必要があります。この手順を確立しておけば、全員がテスタの構築方法を理解して一連の同じルールに従うようになり、開発と保守が簡素化されます。
多くの企業はテストシステムのデプロイを手動で行っており、テストソフトウェアを開発マシンからテスタに移し、すべてが想定どおりに機能することを確かめる必要があります。多くの場合、このステップでコードの小規模な調整や変更が生じ、それらは通常はテスタ上で直接実行されます。プロセスが手動であるため、V&Vテストエンジニアはトレーサビリティやコンプライアンスを確保するために、後で忘れずに最終バージョンを開発マシンに戻し、ドキュメントやバージョン履歴などを更新する必要があります。手動のプロセスにはそれぞれ時間がかかり、エラーが生じる可能性が高くなります。
手動プロセスでは接続型システムのメリットは活用されず、システムをデプロイする際はV&Vエンジニアをラボに待機させる必要があります。エンジニアのデスクとラボの距離が離れていると、往復するだけでもかなりの時間が費やされる可能性があります。また、些細なアクシデントが発生するかもしれません。もし、テストプログラムの転送に使用するUSBメモリが破損したらどうなるでしょうか。または、エンジニアがテストプログラムをテスタにデプロイした後で、大幅な変更が必要になることが判明し、デスクにある開発マシンから作業しなければならなくなったとしたら、どうなるでしょうか。こうしたさまざまな状況で、エンジニアがラボとの間を往復する必要が生じ、システムのデプロイに要する時間が増える可能性があります。
このような手動プロセスの効率を高めるためには、会社の離れた場所から接続およびアクセスして表示や管理ができるシステムが必要です。システムを確実に準備できるように、システムにどのようなアセットやソフトウェアがあるのかをチームが確認できるようにする必要があります。それからリモートでデプロイを行えば、誰が何をデプロイしたのかがすべてバージョン履歴に記録され、トレーサビリティが確保されます。システムの自動化とリモート管理を実現すれば、運用効率が高まるだけでなく、それぞれのシステムに対する一貫したトレーサビリティが確保されます。
テストの監視は、効率を向上しようとしているときに見過ごされがちなポイントです。テストをある程度自動化すると、テストの実行を開始した後に、ときどきテスタに立ち寄ってテストの状況を確認し、テストがいつ頃完了するのかを感じ取ることができます。
結果の解析とレポート生成は非常に重要ですが、特に長い時間がかかります。多くの場合、自動化や自動テストシステムについては話題に上りますが、プロセスのこの部分については見落とされがちです。
テストの完了後、テストエンジニアは、製品の性能結果の原因を理解する必要があり、テストシナリオから予想通りの結果が得られたかどうかを検証する必要があります。結果はテスタ自体に保存されることが多いため、エンジニアは手動で結果を取得することになります。その後、データの確認、抽出、変換、解析を行いますが、これらはすべて自動的に実行しなければ冗長なプロセスになります。
お客様の会社では他の領域において効率を推進している可能性が高いため、すべての製品について解析のプロセスを標準化すれば意味のあるものになるでしょう。解析を標準化すると、テストコストが削減され、解析されるデータの量が増え、そこから得られる洞察も増えることが証明されています (ii)。自動化は重要ですが、アドホック解析を迅速に実行できることもまた重要であり、チームが根本原因を解析するのに役立ちます。テストデータを一元的に保存する場所と、発生するテストデータに対して実行できる定義済みのルーチンを用意しておけば、この段階で生じる多くの時間を節約できます。 また、レポートの標準化や自動生成を行い、利害関係者と簡単に共有できるようにすれば、必要な情報を必要なチームに迅速に提供できるようになり、製品設計の反復が迅速化され、市場への投入期間が短縮されます。
ワークフロー全体を客観的に眺めてみることで、プロセスのどの領域に注目する必要があるかを見定められるようになります。状況は会社によってさまざまです。前述した課題のいくつかを抱えているかもしれませんし、すべての課題が当てはまるかもしれません。今日、あらゆる組織がさまざまなイニシアチブを取り入れ、行動の迅速化、効率の向上、競争上の優位性の創出に注力していますが、それでもV&Vチームには組織におけるテストの捉え方や価値を変える機会があります。
たとえば以下のような取り組みが可能です。
プロセスの最適化は会社全体にメリットをもたらします。すぐに取り掛かれるような簡単な作業ではありませんが、取り組む価値は十分にあります。そして、単独で行う必要はありません。NIは複数の企業と協業して、効率向上を推進する標準化のイニシアチブに取り組んでいます。それはワークフローやプロセスにとどまるものではありません。
お客様が求めている成果について今すぐ目を向け、ボトルネックのある領域を調べてベストプラクティスについて話し合うことができます。お客様が最大限の効率の達成や最大限のリスク軽減に集中して取り組むことができるよう、NIがどのように支援できるかについてご紹介いたします。
[1] Laurence Goasduff、「Data Sharing Is a Key Digital Transformation Capability (データ共有はデジタルトランスフォーメーションの主な機能である)」、Gartner、2021年5月20日 (https://www.gartner.com/smarterwithgartner/data-sharing-is-a-business-necessity-to-accelerate-digital-business)
[2] Foster, Simon、「テストデータ管理のインフラストラクチャの構築」、 NI、2021年11月8日にアクセス (https://www.ni.com/en-us/innovations/case-studies/19/creation-of-an-infrastructure-for-test-data-management.html)