NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'13 Tokai

基調講演
DevJTestでQCDの同時達成を目指せ！～時代の変化の中でテストプロセスも変えよう～
システムクリエイツ　清水 吉男氏

DevJTestとは「Dev Join to Test」の略で、開発担当（Dev）とテスト担当（Test）が連携・協力し合う開発により、時代の要求であるQCD＋αの同時達成を実現させよう、というのが趣旨である。なおこの略称はDevOpsを参考にしたとのことであった。

この業界では、当初要求された「品質」の達成が求められ、その後「納期」、「コスト」が積みあがり、そして現在ではさらに「＋α」が求められている。
このような時代の変化とは裏腹に、ソフトウェアの大規模化や役割の分化に伴い、「作る人」と「テストする人」が分離した構図になっていることが多い。テストのことを考慮せずに作られたソフトウェアをテストするには、その範囲を拡げ、量を増やすしかなく、結果としてコスト増・長期化を招いてしまう。
このように開発・設計担当とテスト担当の連携も工夫もなく闇雲にテストするアプローチでは＋αどころか、QCDの同時達成すら実現できない。

この状況を打破するには、「テストでバグを見つける」だけではなく「設計でバグを減らす」への発想の転換が必要であり、開発・設計担当とテスト担当の連携や相互の情報共有が不可欠である。

市場や顧客の要求を反映しながら製品やシステムをリリースし続けるために、開発・設計担当はいかにしてバグを埋め込まないかを、テスト担当はいかにしてバグを効率よく検出するかを考えて対応する。そのためには相互の情報共有が不可欠であり、作り込んでしまったバグの情報から、バグのパターン、バグを作り込まない方法、テストの情報を公開・共有して、バグの作り込みが減ることを評価する組織に変えていく。
そしてさらに「＋α」を実現させる、つまり、いかにして他者・他社と差別化して価値を付与し、高く買ってもらうかを考える必要がある。
そのためにハードウェアではなくソフトウェアで価値を作る。価値を高める。
これからのビジネスの勝敗はソフトウェアで決まる。
機能を動かすだけのソフトウェアに最早「価値」はない。
ソフトウェアによりハードウェアだけでは実現できない「それ以上の価値：QCD＋α」を付与し、競争に勝つことを目指す。
それを実現できる組織、エンジニアが競争に勝ち抜いていく。

以上の実現にはプロセスを改善することが不可欠であるが、新しく取り入れた手法の本質を認識していないと簡単に先祖帰りしてしまう。そして形骸化には十分注意が必要である。
その対策として清水氏は３つの防止策を提示した。

1. 新しい方法の導入時に解決する問題は何かを明確にしておく。
2. うまくいかない時は原典に戻ってみる。
   なぜそうする必要があるのか。どういう結果が欲しくてそうするのか。
3. 取り組みの前後の違いをデータで示す。

そして最後に、テストエンジニア、ソフトウェアエンジニアとして胸を張れる人生を生きるための大事なポイントを共有した。

• 自分よりよいとわかればすぐに取り込む「肯定眼」を身につけよ
  　人の粗さがしでは、チームプレーどころか誰にも負けない自分を作ることはできない。
• 最後に幸せな人生だったと言えるように「時代を読む」
  　ソフトウェアなしでは成立しない社会である。活躍する場はたくさんある。
• マキアヴェリの言葉
  人の運の善し悪しは、時代に合わせて行動できるか否かにかかっている。
  まず準備せよ。目の前のチャンスが見えなくなる。

この講演で最も印象に残ったのは、「状況に対する捉え方一つで結果が正反対になる」ということであった。
困難な状況に対して、自分を信じることができない人は手を出せずに逃げてしまう。
結果として現状を変えられない。
一方、自分の可能性を信じることができる人は「やりがいがある」と捉えてチャレンジしていく。
結果はやってみないとわからないのだから信じる以外にない。
やらない限り現状を打開するチャンスは得られない。
そのためにどのように準備し、どのように工夫するかは自分次第である。
根拠もなく自分を安く見積もらず、やりもせずに否定して手を付けないことがないように注意したいと感じた。

特別講演
論理の設計とテストを考える　～CFD++、その目指すところ～
デバッグ工学研究所　堀田 文明氏

数か月前にWebで突然目に触れた「CFD＋＋」という名称。
「これはいったいどういうものなのか？／CFD技法と何が違うのか？」と思っていたが、意外と早くその解説を聞くことができた。

「CFD＋＋」のもととなるCFD（Cause Flow Diagram：原因流れ図）は、原因結果グラフ（CEG）を技術者が理解しにくい状況を見て考え出されたとのこと。主に結合テストの合理化を目指し、テスト用のデシジョンテーブルにまとめるなどの手続きと連携する方法をデバッグ工学研究所代表－松尾谷氏が考案した。その流れは、以下の通りである。

1. 機能仕様書や構造仕様などをインプット情報としてその論理を原因流れ図で表す。
2. 原因流れ図を入力してデシジョンテーブルを作成する。
3. デシジョンテーブルによりテストを行う。

これを効率的に実施し、適正なコスト削減手段となるためには、プログラムの適切な論理設計・論理構造の明示が前提条件となる。
もし不適切で複雑な論理設計・論理構造である場合はテスト量も膨大になり、これを人海戦術で対応するとコストパフォーマンスが著しく低下してしまう。

そしてCFDの進化形である「CFD＋＋」は、論理構造の表現手段として、これまでのモジュール構造表現ではなく、「単適合決定表」・「多重適合決定表」などの「決定表」を使用する。そして決定表の分割・結合やテストの決定表などにより、論理設計段階で「テストのしやすさ」を確保するとのことである。
実際の単適合、多重適合の決定表、論理のフロー表現、仕様の連結決定表や決定表の統合などについては時間の関係でかなり足早な解説となったのは残念であった。
さらに、今後CFD++が目指すこと、取り組みが始まったばかりの話題として、静的テスト（静的解析）の進歩からツールを活用するConcolicTestingとの融合にも話が及んだ。
ConcolicTestingは、動的テストでは発見が困難なバグの検出をも目指して、CUTE（C++ Unit Testing Easier）などのツールを介してコードから必要なテストデータを生成し、その実行結果を導くものである。
現時点では「仕様との一致性が不明」などの問題点はあるものの、システムの実稼働環境が整わない状況でも、条件分析なしで必要なテストケースを生成、実行でき、結果を確認できることはテストの効果、効率の両面で非常に有効である。
問題点の解消などを含めて現在も研究中とのことなので、CFD++の今後に期待していきたい。ただし、いずれの場合も適切な論理設計が欠かせないことは忘れてはならない。
適切な論理設計の重要性はCFD＋＋に限らず不可欠な事項としてしっかり認識しておく必要性を感じた。
なお、特別講演での解説にとどまらず、直後のSIG1にてCFD++の実習が行われていた。
聞いただけで終わらせない、実務での実践を促すプログラム構成が非常に有効であることを付記しておく。

SIG

各SIGのテーマを記載する。
どのSIGにもほぼ同数の受講者が参画し、演習による技術習得の促進、相互の議論や情報交換が行われた。

• SIG1：CFD++の実践～演習で考える論理設計とテスト～
• SIG2：探索的テストを探索してみよう！
• SIG3：マインドマップをぐるぐるするワークショップ
• SIG4：機能ブロックと擬似コードをテストに用いる
  　　　　～仕様どおりから，より良いモノづくりへ～
• SIG5：今一度考えてみるテスト駆動開発とユニットテスト
• SIG6：テストに対する不安・不満・負担を共有しよう！解決のヒントを探ろう！

その他のセッションを含めた受講の感想とまとめ

基調講演での食い入るような姿勢、質疑応答では会場のあちこちから手が挙がり、終了時間になってもまだ手が挙がっている・・・。そしてポスターセッションではまるで朝夕の通勤電車内のような混雑の中、テスト設計コンテスト参加チームの成果物や地域コミュニティの活動内容など、掲示された題材を前に発信者のアピールと受講者との質疑応答で大いに盛り上がっている・・・など、さまざまな場面で日本のモノづくりの中心である東海のパワーを直に感じることができた。

さらに、6テーマに分かれて「聞く」＆「手と頭を使って実践する」場となったSIG、参加者同士が活発に議論したワールドカフェなど相互対話と実践を促すさまざまな運営上の工夫が随所に見られ、JaSST東海実行委員会の周到な事前検討と的確な当日運営が見事に結実したものであると感じた。
今回初参加であったが、東海地域の技術力、そしてポテンシャルの高さを垣間見ることができた1日であった。