折角地元でイベントを開催したのですから，筆者自身も何か技術を紹介したいという想いがありました。自身が主催するイベントとで自身がしゃべるというのはマッチポンプも過ぎるのではという考えも一瞬よぎったのですが，なかなかない機会でもありましたし，時間の調整セッションも必要だと自分を納得させしゃべることにしました。自身のスライドを簡単に解説します。（過去のBlog記事を改編して作成しています）
■V字モデルのテスト工程のインプットがUSDM形式だったときに慌てないために from Ikedon
イベントのテーマである「派生開発」それと，清水さんが「USDM」について講義下さっている，「テストの立場に立ったセッションも入れたい」といういうことで，こういったタイトルに落ちつきました。
USDMについてはすでに清水さんの講義で理解をしているはずです。また，XDDPについては藤沢さんの発表にて概要が紹介されています。これらを前知識として利用させていただくことにしました。どちらもあるべき姿に立って語られていますので，このセッションでは「そうはいっても現実いびつな状況ってあるよね」という（生臭い）現実側に立ってみました。
もしあながたテストチームのテスト担当者だったときに，なんの前触れもなく「今回の開発はXDDPなので，仕様書はUSDMです」と言われ，面食らったときにどうなるか？ということですね。ただし面食らったとしても，テストはしなければなりません。納期は迫っているのです。
こうした理想と現実の差を認識してもらい，ディスカッションにより，どのように差を埋めるか，この状況からどう抜け出すかを具体的にイメージしてもらうことがこのセッションの目的として設定しました。こうして，前半10分でスライドをお話しし，残りをディスカッションという構成とすることにしました。
前知識と書きましたが，「XDDPにおけるテスト」についてはこれまでのセッションでは語られていません。ですので，おさらいとしてXDDPにおけるテスト，を簡単に整理します。
まず，清水さんのXDDPの本の索引を見てほしいのですが，「テスト」についてはほとんどキーワードがありません。また本文を参照してみてもキーワードが出てくるくらいで，テストについては具体的に書かれていません。そう，XDDPの本にはテストについてはほとんど書かれていないのです。
これには理由があります。本来，XDDPは実装までに品質を作り込むことを重視する（というか作り込まれる）ためだだからです。テスト工程ではバグはほとんど出ません。故にテストについての記述は少なくなります。考えてみれば実に当たり前であるわけですが，Ｖモデルの呪縛（！）にとらわれていると，Ｖモデルの左側である開発工程にXDDPを当て，Ｖの右側はそのままという導入の仕方をしてしまいがちです。特にＱＡ部門によるプロセス監査などが厳格であればあるほどその傾向があるように思います。また，テストチームが自身でテストプロセスを設計できない場合，そうなりがちです。
本来はテスト工程もまたプロセス開発しておく必要があるのですが，それをしないまま，テストに取り組もうとしているのが現実として多いというわけです。
こういった現実について，もちろん最初からXDDPを綺麗に入れ直すということが理想なのですが，すでに進んでしまっている今回のプロジェクトでは当座をしのぐために，いびつとわかりつつも対処対応することが求められます。
もう少しシンプルに考えてみましょう。派生開発におけるテストへの要請は主に３つです。
- 変更箇所をテストする
- 影響箇所をテストする
- 全体としてデグレや非機能劣化がないかテストする
このとき，XDDPやUSDMに慣れていないと，最初のステップである「1.変更箇所をテストする」でいきなり躓くことになります。
新規開発と異なり，変更に注目してテストを実施します。XDDP（派生開発）の場合は，すでに動いているソフトやシステムが存在しています。新規の機能の集合体である新規開発と異なり，変更に注目してテストを実施するというスタイルになりますし，その要求や仕様がUSDM形式の変更要求仕様書で送付されてきますが，それにも慣れていません。
慣れていないことが重なるわけです。
こうして本を参照するわけですが，そこに求める解は書いてありません。
こういったいびつな事態に直面した場合，どうすれば良いのでしょうか？
理想的にはプロセス設計し，すでに定義済みのXDDPのプロセスと接続するのがよいでしょう。ただし，多くの場合，そういった時間はテストチームには残されていませんし，プロセス設計できるメンバが存在するかもわかりません。なので，いびつとわかりつつＶモデルの右側そのままにテストを乗り切るこという対応を取らざるをえません。そうしてなんとか当該プロジェクトを乗り切ることになります。そして次のプロジェクトではその失敗を生かせば良いです。ただ，大きな組織になればなるほど厳格な設計規格が存在し，それを変えることが難しいです。変えるまでに1年を越えることもほとんどでしょう。その間はいびつな対応とわかりつつも，それでうまくやらざるを得ません。
こういった状況における，最初に装具する「慌てポイント」を４つ取り上げています。
- 慌てポイント１：そもそも慌てない
- 慌てポイント２：どこのインプット？
- 慌てポイント３：どこのテストレベル？
- 慌てポイント４：情報が足りません
どれも当たり前だよなという話なのですが，実際，現実として初めて遭遇したときに例外なく慌てます。なにぜならば，テスト担当者全員がXDDPやUSDMを知っているわけではないし，実戦経験があるわけでもないからです。
では，慌てポイントの１つ目です。
「そもそも慌てない」ということですが，要するに「心の準備ができていない」ということです。
ある日送られてきた設計仕様書の形式がこれまでと大幅に異なっていたら，誰もが一瞬の時間を要します。それがWordによるリストタイプの物が，Excelによる階層表記の物になっていたらなおさらです。
USDMでの階層表記は当たり前として，要求が階層になるとか，範囲があるとか，Before／Afterで書くとか，理由があるとか，TMがついているとか，･･･etcとなると，初見でサラリと読めというのは高い要求です。しかもテスト担当者はこれをつくったこともないわけですから。
そうすると，やはり最低限「見たことはある」という状況にまずは持って行く必要があります。
何ができるでしょうか。それは，書店に行ってUSDMの書籍を買ってくることです。半日もあれば，（USDM自体の深い理解は難しいとしても）中身を読むこと位はできるようになります。そうすれば，少しは落ちついて対応することができるようになるでしょう。
慌てポイントの２つ目です。
変更要求仕様書を受け取ったときに，それがどのテストレベルへのインプットなのかがわからずに慌てる場合があります。
新規開発におけるＶモデルの場合は開発工程のアウトプットがどのテスト工程のインプットになるかが明確です。ところがXDDPを無理矢理Ｖモデルに統合してしまうと，左側と右側の対応関係がわかりづらくなってしまい，いったいこの変更要求仕様書がどのテスト工程に対応しているのかわからなくなってしまいます。
そこで，至極当たり前ではあるのですが，インプット先がどの工程になるのかを定義する必要があります。その際に忘れてはならないのはXDDPの三点セットの他の2つのドキュメントがどの工程に対応しているのか，合わせて定義することです。
変更要求仕様書は変更要求と仕様がが書かれています。従って，受け入れテスト・システムテスト・統合テストへのインプットが考えられます。TMはトレーサビリティを確保する物なので，システムテスト以下が妥当かもしれません。変更仕様書は構造が書かれるのでコンポーネントテストだけかもしれません。
ひとまずはこのように定義しておき，テストチーム内に周知しておくことが必要です。ただし，それが当座をしのぐために暫定的に決めた事であることは合わせて伝えておきましょう。
慌てポイントの３つ目です。
変更要求仕様書をシステムテスト・統合テストのインプットとして決めた場合，ではその中に記述されているものがどちらに対応しているのかがわからないということも起きやすいことです。
これは要求と仕様の関係や範囲をどの程度しっかりと理解できるかに影響を受けますが，まずは割り切って対応するのが混乱を沈めやすいでしょう。
そういったわけで，まずは「要求はシステムテスト」「仕様は統合テスト」とわけることが一案としてあります。それぞれに別けられたものをそれぞれのテストの目線で「そのテスト工程でのテストで良いのか」「他のテスト工程でもテストする必要は無いか」といった目線でチェックします。そこで違和感が生じたものについては，検討を実施します。
これにより，ひとまず，変更要求仕様書に書かれている内容の振り分けはできるようになります。ただし，この方法は変更要求仕様書の記述内容に大きな影響を受けます。本来ならば要求や仕様を定義する際にどのようなテストが必要であるか，変更要求仕様の定義者にテスト担当者が気がつきやすいように記述してもらうなどの手立てが必要です。（変更要求仕様書の記述内容の云々についてはここでは議論を割愛）
慌てポイントの４つ目です。
インプット工程も決まり，変更要求仕様書の内容の振り分けもざっくりできるようになってきたところで直面する問題が「これだけじゃテストできないんじゃない？」ということです。
変更要求仕様書は「変更」が書かれているもので，それ以外は書かれていません。ですがテストを行う上では「それ以外」の情報も必要となります。このため，変更要求仕様書をテストするための唯一の情報としてしまうとテスト設計の難易度が極めて高くなります。
ここで思い出してほしいのですが，派生開発ではすでに動いているシステムやソフトが存在します。即ち全体が書かれたドキュメントが存在しているはずです。これらも合わせて入手しておく必要があります。また，変更要求仕様の中身を定義するに当たっての関連ドキュメントも入手しておく必要があります。つまり，スペックアウト資料も入手しておく必要があります。これら2つのドキュメントを入手することを徹底しましょう。
それから，忘れられがちですが，派生元のテストベースやテストウェアも入手しておく必要があります。なぜならば「テストベースやテストウェアも派生開発の対象」だからです。当然ながら，これらのドキュメントや資産がどのテスト工程のインプットとなるかも定義する必要があります。
以上，これら４つの慌てポイントについて，簡単にアドバイスを紹介しました。もし同じような状況で慌てポイントに遭遇した際の参考にしていただければと思います。
当日のセッションでは，これらを紹介した後に，では本来どうあるべきなのかを議論したかったのですが，他のセッションが押したこともあって，10分しか時間がなく，深い議論することができませんでした。なので，別途再演するなり何なりしたいなぁと考えています。その際はもう少し時間も増やして慌てポイントを 少し追加したいなぁとも考えています。