去る2015年8月12日，長崎ブリックホール（長崎市茂里町）にて「長崎 SW Quality & Development Gathering 2015」が開催されました。
私は主催者としての参加でしたが，少しだけお話ししてきました。
■「長崎SWQuality&DevelopmentGathering2015」
V字モデルのテスト工程のインプットがUSDM形式だったときに慌てないために from Ikedon
XDDPにおけるテストについて，現実的によくある話をとりあげ，理想と現実の差を認識してもらい，ディスカッションするというセッションでした。
本来XDDPは実装までに品質を作り込むことを重視する（というか作り込まれる）ため，清水さんの本にはあまりテストについては言及されていません。これ自体はそりゃそうだよねと納得するわけですが，現実としては今まであるＶモデルベースの社内規格の左側である開発工程にXDDPを当てはめるということが多くあります。
こういったゆがんだ導入の場合，本にはテスト工程についての記述が少ないので，テスト工程の運用について混乱してしまうことがほとんどです。加えて，これまでWORDベースでの設計ドキュメントしか読んだことがないテスト担当者にExcel＆USDMで書かれたドキュメントが渡ったときに，テスト担当者が混乱を起こしてしまいます。
こういった現実について，もちろん最初からXDDPを綺麗に入れ直すということが理想なのですが，すでに進んでしまっている今回のプロジェクトでは当座をしのぐために，いびつとわかりつつも対処対応することが必要です。
それから，大きな組織になればなるほど設計規格をかえることはとても大変で，1年を越えることもほとんどです。そのあいだはいびつな対応とわかりつつも，それでうまくやらざるを得ません。
こういった状況における，最初に装具する「慌てポイント」を４つ取り上げています。
- 慌てポイント１：そもそも慌てない
- 慌てポイント２：どこのインプット？
- 慌てポイント３：どこのテストレベル？
- 慌てポイント４：情報が足りません
どれも当たり前だよなという話なのですが，実際，現実として初めて遭遇したときに例外なく慌てます。なにぜならば，テスト担当者全員がXDDPやUSDMを知っているわけではないし，実戦経験があるわけでもないからです。
これら４つの慌てポイントについて，簡単にアドバイスを紹介しています。もし同じような状況で慌てポイントに遭遇した際の参考にしていただければと思います。
当日のセッションでは，これらを紹介した後に，では本来どうあるべきなのかを議論したかったのですが，他のセッションが押したこともあって，10分しか時間がなく，深い議論することができませんでした。なので，別途再演するなり何なりしたいなぁと考えています。その際はもう少し時間も増やして慌てポイントを少し追加したいなぁとも考えています。