用語における認識の違いから思うこと

用語における認識の違い

　開発業務で同僚や関連会社メンバーとの議論や社外技術コミュニティの方々との議論」を通じて感じていることですが、コンテキストが共有されていない状況で用語を使って議論すると、話がかみ合わないことが多々あります。 例えば、「テスト条件」です。

　各々のシチュエーションを以下書き出してみます。

私が社外技術コミュニティに参加する前

　テスト条件という言葉は知らない状態でしたが、当時のイメージは「テストの目的」「テストの環境(構成)」「テストの手順」「テスト結果の判断基準」の4要素でした。

JSTQB用語集を見たとき

　JSTQBのサイトにあるソフトウェアテスト標準用語集 日本語版では、下記のように記載されていました。

「コンポーネントやシステムのアイテムやイベントで、 テストケースにより検証できるもの。たとえば、機能、トランザクション、フィーチャ、品質の属性、構造要素など。」

　初めて上記の記載を見たとき、イメージができなかったです。原因は、自組織で聞いたことがない用語で、社内用語で該当しそうな用語が存在するか探してみたのですが、ありませんでした。

TwitterのTLで見たとき

　Togetterにまとめがありましたので、下記引用します。
　http://togetter.com/li/384359

　@akiyama924さん曰く、
「テスト（要求）分析フェーズのアウトプットで、テストすべき何か」「整理すると、テスト対象（テストオブジェクト）を分解してテストアイテムを見つけるんだけど、それだけではなく、テスト対象から離れて評価したいこともあるわけで、それらを総称してテスト条件と呼ぶのではないかと思います。それで、テスト条件≒テスト観点なのかなと。」

　「テストすべき何か」から、私は「テストを通じて確認したいこと」や「開発者が心配していること」をイメージしました。

Test.SSFのスキル基準

　ASTERのサイトにあるSSFに基づくテスト技術スキルフレームワーク スキル基準[Ver1.0]の8/15ページによると、
「第2階層:テスト詳細設計→第3階層：分析-7.テスト条件（確認項目）の設計」とあり、(粒度の大小はまちまちですが)確認項目から機能を確認する内容(例：データの送受信、ユーザ認証)のことと認識しました。

各々のシチュエーションからの認識

　「テスト条件」という用語だけでも、認識しているものは多種多様でお互いに思い描いているものは違うので、(自組織でも組織間でも)思い描いているものを共有しているかお互いに確認し合うことは大切だなと痛感しています。
　例えば、開発vsテストの対立構造は、小さな認識の違いが徐々に拡大して、お互いに理解し合うことが困難になった結果、心理的に壁を作り関係修復不能に陥ることも1つの要因と思います。

認識の違いを埋めるもの

　開発業務では、開発者と議論するときに「ポンチ絵」や「UMLに近いもの」を描いて、「私は○○と捉えているけど、□□さんはどんな捉え方ですか？」と質問して、認識の違いは何かを把握するようにしています。
　2015年夏に京都でTOCfEの認定プログラムに参加したときに「クラウド」を描きましたが、対立事項が何かを整理して、何が妨げになっているかを把握すると、認識の違いをどのように埋めるか考えるきっかけになりました。

さいごに

　相手が理解しやすいように表現するためには、様々なジャンルに興味を持って触れることだと思いました。最近の私は、殺伐とした生活になりがちなので、ある程度の気持ちの余裕が必要かもしれません...