トレーサビリティ・マトリクス
アドベントカレンダー２３日目
最近社内イベントにて、トレーサビリティ・マトリクスについてのテストプロセス改善事例を発表。
上位ドキュメントの管理内容が下位ドキュメントに確実にトレースされているか、それを可視化する仕組みで、多くの作業ミスを検出し後工程への悪影響を防止したというお話。
まぁ作業ミスは多くの環境で発生するし、トレーサビリティ・マトリクスはそれを検出する有効な手段の１つであるから、確実な作業を推進したいのなら現場で積極的に使って欲しいところ。
そうした事からふとSQuBOK を確認してみると、「トレーサビリティ・マトリクス 」は思ったよりも内容として取り上げられておらず、なぜだろう？ と感じた。
１０１ページ 2.2.3.7 派生開発（XDDP) のトレーサビリティマトリクス（TM)
→これはマトリクスには違いないが、XDDPの１要素として触れているのでちょっと違うもの。
１４７ページ 2.11.4 トレーサビリティ管理
→トレーサビリティをざっくり説明しているが、トレーサビリティ・マトリクスまでは触れていない。
かなり大事な技術だと思うのだけど、論文が無かったのか載っていないのは残念。
なおトレーサビリティ・マトリクスは、JaSSTの下記資料がわかりやすいと思う。
http://jasst.jp/archives/jasst10e/pdf/C6.pdf
SQuBOK社内活用について考えてみたこと
アドベントカレンダー１５日目
恐らく私の身の回りの人の大多数は、そもそもSQuBOK自体の存在を知らないことだろう。。
だから読破会に参加して色々と得た事も、個人活用に閉じず、社内にも何らかアウトプットしたいと思う。
しかし社内へのアウトプット方法は、闇雲やたらにやっても効果が無いというのが最近の悩みだ。
今週、「テストプロセス改善」をテーマとして、発表を企画した。
発表後に関心を持った質問が多く、終了後の飲み会でも好評だったので、"発表" としては成功したのだろう。
ただ参加者からはもっと色々と聞きたかった、発表を踏まえてディスカッションや現場の改善策を考えたいという声もあったのだが、
定時後の勉強会・発表会という枠では知識や成果の伝達以外は中々難しいのだろうと思う。
で結局のところ、参加者には何が成果として残ったとか、何かの技術知識の習得に繋がったとかの明確なものは無い。
だからアウトプットの結果として、明確な成果・効果が見えないものは、意味があるのか？ という悩みに繋がる。
JaSST形式の流れるような発表と短い質疑応答のスタイルは、
参加者に強い学ぶ意思や課題解決という目的が無いと、効果はほとんど得られないはず。
参加者にとってのアウトプット、内容の腹落ち を最優先に考えないと、全ては失敗に繋がるため、
普通の "発表会"はもう終わりにしようと考えている。
で、SQuBOKを読んで改めて感じたことは、そもそもの "ソフトウェア品質" に関する知識・理解・実践の全てが不足しているということ。
だから、SQuBOK第２版 第１章 ソフトウェア品質の基本概念 をスコープとして、その内容の紹介、自組織における状況を説明、ディスカッション、具体的なすぐに始められる小さな対策案の検討 までを社内イベントとして一連の流れで実施したい。
自身も含めて、"ソフトウェア品質の基本概念" をあまり理解していない場合、SQuBOKの第１章はかなり体系的にまとまっていて活用の価値が高いのではないかと思う。
追伸
SQuBOK第２版 の目次ページに "索引" が340ページ目とあるが、実際は400ページ目の誤記であった。
SQuBOKの利用方法
SQuBOKアドベントカレンダー７日目
■はじめに ３．本書の利用方法（４）品質保証に携わる技術者やその管理者 に対しては、利用方法として次の一文が示されている。
”まず本ガイドを一度、隅から隅まで読破していただきたい。”
”全体に目を通すことにより、品質保証のための技術の全貌を理解できるはずである”
”実務で問題が発生したとき、樹形図を参照しながら解決策となりそうな技術のあたりを付ける。”
”あたりを付けた技術の参考文献をたどることにより、その技術を適用できるだけの知識を習得できる。”
最近、この参考文献をたどり詳細を学習するという利用方法を実践したので、その時の経験を時系列にまとめてみることにした。
１．社外の勉強会や懇親会の場で、知らない用語「レジリエンス」を耳にする
２．任意のテーマで社外発表できる機会があり、「レジリエンス」をテーマとしてはと意見をもらう
３．SQuBOKで用語を調べてみる
４．掲載されていた参考文献を確認する
５．参考文献を購入する
６．参考文献を読み込む
７．社外発表のため用語について調べて、自身の経験と見解を述べたまとめ資料を作成する
８．まとめ資料を発表する
９．発表内容について、聴講者からフィードバックをもらう。
１０．現場の業務カテゴリー（準正常系と運用要件定義など）と、学んだ知識が紐づくようになった。
後で調べてわかったことだけれど、手持ちの本ではSQuBOKにしか該当の用語が掲載されていなかった様子。
この経験を通じ、用語の辞書や参考文献への橋渡しとして、SQuBOKの紹介通りの利用方法が機能したことを実感した。
これは他の技術書と比較して対応範囲がかなり広いことも意味しており、今後の活用においても、「何か困ったら、まずはSQuBOKを引いてみる！」というアプローチに多大な信頼を寄せることになるだろう。
次の目標としては、利用方法の最初に紹介されている以下の文言を実感できるようになりたい。
”まず本ガイドを一度、隅から隅まで読破していただきたい。”
”全体に目を通すことにより、品質保証のための技術の全貌を理解できるはずである”
という訳で簡単な内容でしたが、まずはSQuBOKに対して感じたことを綴ってみました ^^
＃アドベントカレンダー上、エントリに漏れたため上手く繋がっておらず申し訳ないです。
次回は、anahiappiさん。
引き続きよろしくお願いします！
【勉強会用】１．デシジョンテーブル（決定表）とは？
＜JSTQBの定義＞
入力データや入力条件の組み合わせに対する処理や出力結果を
表（テーブル）にまとめたもの。
●補足
入力データ間に相互作用があると論理関係が複雑になるが、デシジョンテーブルで視覚化する事により、入力と出力を簡潔に整理できる。
開発者・テスト設計者が早期に仕様書へ記載してレビューする事で、複雑なビジネスロジックに対する認識齟齬が起きにくくなる。
（文章や単純な表による表現では、書き方・読み方の不統一が問題。）
フローチャートの代わりとして用いる事が可能で、システム関係者以外でも容易に読み取れる図式表現である。デシジョンテーブルは決定表とも呼ばれ、"意思決定"を文書化する用途で使用される。例えばマネージャの意思決定をメンバへ事務的に遂行させ、例外事項はマネージャにエスカレーションするといった整理でまとめる事もできる。
●歴史
１９５０年代にはフローチャートや文章の弱点である、書き方によって単純にも複雑にもなってしまう点を解決するため、米国で使用されていた。
１９７０年には、日本にもデシジョンテーブルの翻訳本が出版され、システム開発に応用され、テーブルからプログラムを自動生成する用途にも使われている。
今日では、ソフトウェアテストにおけるホワイトボックステスト技法として位置づけられ、独立した１つのテーマとして扱われる事は少ない。
●参考書籍
・JIS規格 JIS X 0125 決定表 1986年
（ジュンク堂など書店で購入可能）
・デシジョン・テーブル入門
ハーマン・マクダニエル 著,岸田 孝一 訳 日本経営出版会 1970年
（国立国会図書館、東京都立図書館で参照可能）
・デシジョンテ-ブルによるプログラムフロ-チャ-ト
清田進 著 日刊工業新聞社 1971年
（国立国会図書館、東京都立図書館で参照可能）
・JaSST'09東京 E4 初心者向けテスト技法演習 -テスト技法の基本のキ-
（www.jasst.jp/archives/jasst09e/pdf/E4-1.pdf ）
・はじめて学ぶソフトウェアのテスト
リー・コープランド (著), 宗 雅彦 (翻訳) 2005年
・ソフトウェアテスト実践ワークブック
レックス・ブラック (著), 成田 光彰 (翻訳) 2007年
デシジョンテーブルの勉強会
意思決定をテーブル化してみる
不明確な意思決定をテーブル化してみよう。
価値のあるノウハウや思考パターンをテーブル化することは、
デシジョンテーブルの得意な分野だと思う。
そこで「不明点の解消」についてざっと考えてみた。
ざっと作ったので、テーブルが規則を完備しているか確認してみよう。
２値の条件が５つだから、完全なテーブルなら
２×２×２×２×２＝３２規則となるはず。
#1＝２（-が１つ）
#2＝１
#3＝１
#4＝２（-が１つ）
#5＝２（-が１つ）
#6＝４（-が２つ）
#7＝８（-が３つ）
#8＝８（-が３つ）
合計＝２８ ...４つ足りない。
Y,Y,N のパターンが漏れていたようだ。
規則を追加。
もう一回、規則数を計算すると
#1＝２（-が１つ）
#2＝１
#3＝１
#9＝２（-が１つ）
#10＝２（-が１つ）
#4＝２（-が１つ）
#5＝２（-が１つ）
#6＝４（-が２つ）
#7＝８（-が３つ）
#8＝８（-が３つ）
合計＝３２
となりテーブルが完備したことを保証できた。
既に存在する有形の事象ではなく、形になっていなかった無形の思考を整理すると新たな発見に出会えたり、色んな価値を共有できるかもしれない。
ある書籍にはデシジョンテーブルの説明に、
『価値のあるものをテーブル化する。』
という一文があった。
少し意味がわかった気がする。
条件と動作が実行される順番
条件指定部、動作指定部の記述ルールを整理。
条件指定部は、各々の条件の間に順序関係が無い。
どの条件から評価してもよいし、同時に評価してもよい。
動作指定部は、記述した順番に動作が実行される逐次実行方式。
同じ動作であっても、前提となる動作が異なるなら動作は重複する。
「お風呂に入る」という動作が２つあるが、
前提動作に「ご飯を食べる」があるか無いかということ。
入力の組み合わせがシンプルなケースでも、
実行する動作が多いなら規則間の動作を比較整理する目的で、
デシジョンテーブルを使えるかもしれないと思った。
