ソフトウェアのテスト展開を成功させるための CAD マネージャー向けガイド

ロバート・グリーン 氏

この記事は、CAD ユーザーに向けた、ソフトウェア/ハードウェアに関する情報、アドバイスやヒントの提供を専門とする米国の雑誌・ Web サイト『Cadalyst』の編集者によるものです。発行者の許可を得て発行しています。
Cadalyst

8 段階の手順を踏むことが、CAD ワークフロー用の新しいツールを確実に評価する上で役立ちます。

新しい CAD ツールの展開を検討している場合は、社内に実際に導入する前にそのソフトウェアの綿密なテストを実行することが 不可欠です。 そうしたテストはどのように実施したらよいのでしょうか。

 

IMAGE-29P9

このホワイトペーパーでは、私が経験を通じて得たソフトウェア テストのベスト プラクティスを共有するために、綿密で制御されたテスト プロセスを確実に実行する方法について、手順を追って説明します。 実際にソフトウェアを実装する前のリハーサルとして、テスト展開を実施します。このテスト展開によって、驚くほど多くのことを学べます。 それでは、始めましょう。

 

Step 1: 手順 1: テスト インフラを構築する

手間をかけてソフトウェアをテストするのですから、ソフトウェア自体をテストするだけでなく、そのソフトウェアの実行に関連するすべての事項をテストします。 テストでも本番環境と同じネットワーク システム、フォルダー、および標準を使用してください。ソフトウェアのデバッグだけでなく、実際の作業環境を模倣してテストします。

テスト インフラストラクチャを構築するには、少なくとも次の作業が必要になります。

  • ソフトウェアの試用版または評価ライセンスを取得します。
  • 必要なネットワーク フォルダーを作成し、適切な権限を設定します。
  • テンプレート、ファミリ、コンテンツ ライブラリなど、標準化関連のファイルを整理します。
  • ファイリング フォルダーやプロジェクト フォルダーの概要をまとめます。
  • 自分とユーザーの両方をサポートするための、トレーニング用資料をまとめます。

ソフトウェアは試用モードであるため、すべてを最初から完璧に設定するのは不可能であり、テスト中に必ず不具合や問題が発生します。しかし、すぐに本番環境の標準と適合させることができます。

 Step 2: 性能試験場(テスト環境)を確立する

航空機を設計する企業は、性能試験場で実際の条件下で設計をテストしてから、航空機を顧客に引き渡します。 性能試験場を使用すると、制御された環境でさまざまなテストを迅速に実施できます。エンジニアは、早期にエラーを把握できるだけでなく、テスト パイロットからフィードバックを受けて設計を容易に修正できます。

CAD の場合、この性能試験場に相当するのは、私がテスト パイロットと呼んでいるテスト ユーザー グループです。これらのユーザーは、制御された環境で新しいソフトウェアのテストを行い、導入を検討する主な機能、役に立つ機能と役に立たない機能を見分けます。私はこれらのテストを、故意にソフトウェアをクラッシュさせてデバッグするだけではなく、インストールを検証し、標準の作業プロセスを変更し、標準を更新し、トレーニング戦略を策定し、ユーザーが最大限に理解できるようにする手段と捉えています。 新しいソフトウェアを厳格にテストし、実装の準備を整えることが目的です。  試したソフトウェアでは会社のニーズが満たされないこともありますが、多くのユーザーを巻き込むのではなく、テスト ユーザーのグループでそれを検証することができます。

Step 3: テスト パイロットを選定する

採用するテスト パイロットの資質によって、テスト環境の質が左右されます。 テスト パイロットは、次の資質を備えている必要があります。

  • 新しいソフトウェアを習得する意欲が強い
  • プレッシャーがかかっても冷静さを失わない
  • 問題を明確に伝えることができる
  • 粘り強く、最後までやり通す

ソフトウェアのテスト パイロットは、新しいツールで課題が発生したりクラッシュしたりする可能性があることを認識しつつ、本番環境に展開できるように準備するプロセスに携わる意欲のある人々です。

こうした資質を備えた何人かのテスト パイロットがいれば、新しい CAD を評価して活用することができます。 テスト パイロットがいない場合は新しいソフトウェアを一般ユーザーに試してもらうことになりますが、そのソフトウェアに問題が発生したときに混乱が生じる可能性が高くなります。 そのような経験をお持ちではありませんか。

テスト パイロットとして適任なユーザーを既にご存知ではありませんか。

注: 小規模企業の場合は特に、CAD マネージャーが自分 1 人でソフトウェアをテストしようと考えるかもしれません。 それ以外の方法がない場合を除き、自分 1 人でテストすることはお勧めしません。 ソフトウェアを本番環境に展開する前にそのソフトウェアの問題を発見するには、他のユーザーを少なくとも 1 人テストに参加させて、その人の観点からも評価することが非常に重要です。

Step 4:本番環境とテスト環境を分離する

テスト パイロットには、プロジェクトで必要になった場合にいつでも標準の CAD ツールに戻せるように構成されたソフトウェアやカスタム設定を提供する必要があります。 これは、プロジェクトに重大な問題が発生しそうになったときに新しい CAD ツールからすばやく切り替えるための方法です。

また、テスト環境を分離して、試験対象のソフトウェアを使用中の限られたプロジェクトのみをその環境に置くようにします。 目的は、新しいソフトウェアを実際のプロジェクトに使用しながら、データの破損、バージョンの競合、予期しない問題などが発生した場合のリスクを低減することです。

最後に、本番環境とまったく同じように新しいソフトウェアを運用できるように、テスト環境を設定します。そうすることによって、ソフトウェアのデバッグと同時に、インストール ファイルやネットワークのデバッグを行うことができます。

Step 5: テスト パイロットへのインタビューを実施する

新しいソフトウェアを評価するテスト パイロットにインタビューして、彼らの経験から学びましょう。 次の点について確認します。

  • どのような問題があったか。
  • エラーが発生したときにどのような現象に気付いたか。
  • 分かりにくかったことは何か。うまく行ったことは何か。
  • ソフトウェアの操作を容易にするものは何か。
  • 自分の経験を他のユーザーにどのように伝えるか。

旅客機の性能試験場で「ディブリーフィング」と呼ばれるこのインタビューを行うことが、適切なフィードバックを得るための一番の近道です。 収集した情報は、ソフトウェアのデバッグだけでなく、他のユーザーに対して実施するトレーニングの教材を作成するのにも役立ちます。 インタビュー時には詳細なメモを取り、後で参照できるように、得られた情報をドキュメント化します。

Step 6: 改善し、テストを繰り返す

テスト パイロットのフィードバックを得たら、それに従ってソフトウェアを調整し、後日実施するトレーニング用に変更内容をドキュメント化します。さらに、必要に応じてテスト環境を微調整し、テスト プロセスを繰り返します。 テスト展開を改良しながらプロセスを繰り返すたびに、処理がよりスムーズになり、そのソフトウェアの本格的導入にテスト パイロットたちが同意できる状態に到達します。

追加テストを省略して展開を迅速に進める誘惑に駆られるかもしれませんが、テストを繰り返すたびに、ユーザーにとって習得しやすく使うのも容易なソフトウェアに改善できます。 テスト パイロットがより多くの作業を行うことによって、後で実施するトレーニングの時間を短縮できます。

Step 7: テスト パイロットの貢献を伝える

テスト展開が進むにつれ、そのうわさがオフィス内に広まって行きます。 それに合わせて、テスト パイロットの貢献を高く評価していることを皆に伝えます。 努力を惜しまず、明敏で、能力の高いテスト パイロットが、新しいテクノロジーの導入に大きく貢献していると伝えることによって、他のユーザーも彼らのように評価されようと努力するようになります。 すべての CAD ユーザーがテスト パイロットと同じように努力したら、素晴らしい成果がもたらされます。 すべてのユーザーがテスト パイロットと同じように取り組めば、新しい CAD ツールのトレーニングと実装が非常に容易になります。

単独でソフトウェア テストが行われないように管理する

独自にソフトウェア テストを行ってしまうユーザーはいないでしょうか。 自分が見つけたツールを手当たり次第にダウンロードしてテストするユーザーや、会社で評価中のツールの噂を聞き、管理されたテスト環境の外で独自にテストしてしまうユーザーがいるかもしれません。 ユーザーが、新しい、仕事に役立つツールを探そうとするのは良いことですが、ユーザーが独自にテストを行うことによって多くの問題が生じる場合があります。

  • 標準からの逸脱。独自にテストを行ったユーザーが会社の既存の標準とは一致しない作業方法を提案し、その結果生じた問題の解決を CAD マネージャーが迫られる可能性があります。
  • CAD マネージャーへの負荷の増大。ユーザーが正式に許可されていないテストを行った結果、多くの質問を受けたり、問題が発生したりして、CAD マネージャーが正式なテストやその他の優先事項に対応する時間が削られてしまいます。
  • エラーの増加。管理されていない環境で作業すると、誤ってプロジェクト ファイルを上書きしたり、バージョンの問題が発生したり、企業データが破損したりする可能性があります。 このようなエラーは悪意に基づくものではありませんが、余計なコストがかかります。
  • 経費の増加。 新しいソフトウェアの管理されたテストを実施するのには経費がかかりますが、独自にテストするユーザーが割り込むと、さらに経費がかかり、生産性にも悪影響が出ます。  テストのコストを最小限に抑えるには、テスト パイロットの数とテストにかける時間を厳密に管理する必要があります。

新しいテクノロジーを学ぼうとする意欲を削がずに、勝手にソフトウェアのテストが行われるのを回避するには、厳密なルールを設定する必要があります。

テストしたいツールをユーザーが見つけた場合は、まずそれを CAD マネージャーに伝えて、管理された環境下でテストを実施するかどうかを検討してもらう必要があります。

何らかの理由で正式なテストを実施できない場合は、次の条件を満たす場合にのみ、独自にツールをテストするように勧めます。

  • テストはユーザーが自分の時間に実施する。
  • IT スタッフや CAD 管理者のサポートを求めない。
  • 会社のネットワークから分離された環境で実施する。
  • 本番環境でのツールの使用を目的とする場合は、会社の標準に準拠する。

これらの方針を明確にすることによって、正式な許可を受けずにテストすることに伴う問題を回避しながら、ユーザーが自発的に新しいツールを実験できるようにします。

Step 8: トレーニング プランを作成する

テスト パイロットがテスト環境内で新しい CAD ツールを使用すると、後で本格的に実装する際に役立つ、多くの情報が得られます。 テスト期間中、注意を怠らずにメモをしっかり取ることで、次のことを確認できます。

  • 強調する必要がある概念
  • 難解な概念を説明する最善の方法
  • 予期すべきユーザー問題
  • 最も適切に機能する作業方法および標準

これらの内容に留意して、他のユーザーをトレーニングする方法、ソフトウェアを管理する方法、新しいソフトウェアを最高の状態で運用するのに必要な標準とベスト プラクティスを決定できます。

まとめ

このホワイトペーパーで概要を示したテスト展開のベスト プラクティスに従うことによって、安定して使いやすく、トレーニングも容易なソフトウェアを実装できます。 テスト パイロットと性能試験場は航空機産業で使われる概念ですが、さまざまな CAD ツールの評価においても同じように役立つと思います。 また、性能試験場(テスト環境)はソフトウェアをテスト運用するだけの場ではなく、すべてのユーザーにとって使い勝手の良いソフトウェアにするための実験室でもあります。

 

 

Robert Green 氏は、米国およびカナダにおいて、CAD のプログラミングおよびコンサルティングを行っています。 また、長年にわたって Cadalyst 誌の編集者として活躍し、『Expert CAD Management: The Complete Guide』の著者でもあります。Green 氏の Web サイトをご参照ください。

ロバート・グリーン 氏は、1991 年から、米国、カナダ、およびヨーロッパで、CAD 管理に関するコンサルティング、プログラミング、トレーニング、およびテクニカル ライティングのサービスを提供してきました。 熟練したメカニカル エンジニアでもある ロバート氏は、1985 年以降、広く普及しているさまざまな CAD ツールをさまざまなエンジニアリング環境で使用してきました。 作業環境を問わず常に優秀な CAD ユーザーであった ロバート氏ですが、CAD 管理の知識は実際の現場で身に付けたものです。 経験を積んで行くうちに、CAD 管理に伴う技術的な課題やトレーニングに関する課題に興味を持つようになり、現在では、講演を通じて CAD 管理者の指導にあたっています。 Robert 氏は、Cadalyst 誌で執筆している記事と、著書『Expert CAD Management: The Complete Guide』(出版社: Sybex)で広く知られています。 執筆活動をしていないときは、自身が経営する Robert Green Consulting (ジョージア州アトランタ)にてコンサルティング業務を行っています。