曖昧な用語を定義することの重要性
IT業界では常に新しいワード*1が生み出され、略され、定義の曖昧な用語が飛び交っている。 例えばソフトウェアにおけるテスト工程名称は単体試験、Unit test(UT)、Program test(PT) など、企業によって異なるケースも多い。 Systemt test(ST)を Product test(PT)と呼ぶこともあったり、略称によっては重複することもあり統一された呼称がない*2、または浸透していないのが現状である。
テスト工程だけでなく、要求分析なのか要件定義なのか、基本設計なのか概要設計なのか、似たようで異なる用語が多すぎる。 統一された用語が定義されているのが無論、ベストではあるのだが工程自体が企業独自のものであり、様々な用語を用いてる以上、統一用語を定義するのは難しい。
そのような状況においては用語の定義と状況の定義が肝要となる。
具体的には以下のようなものだ。
| 用語 | 状況 | 完了時の状態 |
|---|---|---|
| ユニットテスト(UT) | ソースコードのメソッド単位試験 | メソッドの機能要件が満たせている |
| 結合テスト(IT) | データのインプットからアウトプットに対する試験 | クラス、モジュール間でデータIOに対する機能要件が満たせている |
| システムテスト(ST) | 画面上からデータの登録など要求に対する機能要件の試験 | 要求に対する機能要件が満たせている |
| 受け入れテスト(AT) | パフォーマンスや負荷など、非機能要件に対する試験 | 想定ユーザの運用要件が満たせている |
日常から様々な略称や用語を用いることが多い業界だが、用語の定義が曖昧であるとコミュニケーションロスにも繋がってしまう。
テスト工程を例としたが、会議の場などで顧客の話、先輩・上司の話が理解できない若手の多くは用語の定義を求めていないことが多いように思う。 企業の風土といえば聞こえは良いが暗黙の了解で決められた用語も多く、同じ職種でも企業が変われば意味が異なる。 コミュニケーションロスを起こさずスムーズに業務を遂行するためにも用語の定義は忘れないようにするべきであると考える。
