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

基調講演
「実験的アプローチを可能とするチーム作り」
細谷 泰夫（三菱電機）

JaSST'13 Kansaiにて「実験的アプローチによる現場改善」というタイトルで基調講演が行われている。本講演はその続編とも取れる内容で非常に興味深かった。
改善を行うというのは何かしらの変化を起こすことである。変化を起こすというのは良い結果を得られることもあるが、その逆もある。それを恐れて躊躇しまうことも多い。
「実験的アプローチ」とは、変化の対象となる初期のスコープを極小にすることによって、変化の結果を評価しながら、スコープを広げるべきか、軌道修正すべきか、元に戻すべきかを判断する漸進的な改善のアプローチである。このアプローチにより、変化のリスクを抑制しながら効果的な改善を実施し、その成果を早期に享受することが可能となる。
実験的アプローチには3つの原則がある。

1. 改善のスコープを極めて小さくする
2. 実践の結果を素早く得る
3. 結果を評価して軌道修正する

これらを意識し、（手段の）情報収集・調査、 課題の発見、 課題と手段のマッチング、 手段の試行、手段の実践、結果の評価の6つの活動を行う。
手段の情報収集、調査はSNSやコミュニティ、書籍などから軽く継続的に情報を集めてそれほど時間をかけずに調査を行う。
課題の発見は反復的な活動を行い、週単位での振り返りを利用して行う。
課題と手段のマッチングでは発見した課題に対し、手段を適用できるかを検討する。課題と手段は必ずしも1対1ではない。また、通常のプロジェクトでは課題の発見と手段の収集をシーケンシャルに行うことが多いが、実験的アプローチでは課題の収集と手段の収集を並列的に行う。
手段の試行は、それほど時間をかけない。並行して複数の手段を実践するということもある。試行は実践のスタートラインに立つこと。手段によっては試行を行わず、すぐに実践するケースもある。
手段の実践はスコープを絞り、いかに早く実践するか、ということが大切。あらかじめ火傷が少ないような仕組みややり方で実践を早くする。本番で実践することにより、試行よりもより大きな結果を得ることができる。
結果の評価は手段を継続するか、改善するか、やめるか、をチームで議論して決める。当初意識していなかった課題を実践により感じることもある。振り返りをうまく使うことが効果的。試行錯誤を次につなげる。こういう行動様式が根付いてくると、新しい手法を考えられるようになる。
続いて3年間でいろいろ試行実践された中から、原因結果グラフを単体テストに活用、DSL (Domain-Specific Language：ドメイン固有言語)を用いたコード生成、実験的にやめてみる（TDD(test-driven development：テスト駆動開発)での事例）という3つの事例を挙げて紹介された。
前の2つは選択した手段を試行錯誤しながら実践すること、それによって理論の理解をメンバが進めることができ、さらにツールを自作するようになったということであった。最後の事例は実際に実施している手段をやめてみることによって効果も得られたが、メンバは不安も感じたのでそれらを取り込んで改善を進めていったということであった。手段をやめてみる、ということは大きな決断もいるが、それを（短期間で）行うことで得られる効果という知見は、筆者にとっても大きな刺激であった。
最後にまとめとして、

• 改善のスコープを小さくとらえてジレンマを乗り越える
• 変化を楽しんで、自分たちがより良い開発ができるようなチームになる
• 実践を通して自分たちで効果を体験してコンテキストと摺合せ、自分たちのコンテキストに対して必然性のある改善を進めていく

ということが述べられ、

• 「実験的アプローチは1人でも実践できる。自分自身が変わることはまわりが変わること、世界が変わることにつながる」
• 「みなさんが原動力になって周りを変えていきましょう」

という、強いメッセージで講演は締めくくられた。

「ペトリネットを利用した状態遷移テスト」
和田 浩一（東京エレクトロン）

講演は、ペトリネットの概要と製品への適用事例という構成で行われた。実際のツールを用いたデモも行われ、理解の助けとなった。
ペトリネットはToken、Place、Transition、Arcの4つの部品を使って表記する。これらの部品を用いることで、視認性の高いモデルを作成でき、同時刻に成り立つ事象を一つのモデルで表せる。システムを少ない部品で表現できるので図が描きやすい。
また、ツールを用い、シミュレーションできるので、状態をモデル上で動かして動的に捉えられる。シミュレーションにより、最適化されたテストパスが出てくるので、テストケースとして遷移条件をそのまま出せる。
製品への適用事例では、単体・結合・機能テストで検出すべき欠陥がシステムテストまで残ってしまうという問題に対し、状態遷移表では表せない問題（依存関係、非同期等）を解決する手段としてペトリネットを適用した例を紹介された。
効果として、システムテストに流れ込む前に欠陥を検出でき、テストケースの漏れを埋めることができた。また、その他の効果として次の設計への参考資料になり、設計時のあいまいさの排除につなげることができることもわかった。
テスト工程では変更点に着目、ペトリネットでのシミュレーションにより、テストの方針を明確に定められるようになった。レビューの場面では、従来はスキル差が新人とベテランとで指摘数に現れていたが、システムの動きが視覚的に捉えられるので新人による指摘件数が上がってきたという効果があった。

「機能ブロックと擬似コードを用いたS/W開発事例
- 機能ブロックと擬似コードをテストに用いる -」
鳥本 明男（メルコ・パワー・システムズ）

昨年のJaSST'12 Hokkaidoでの事例発表の続きである。今年はその実践も含めての報告ということで、施策の効果が示された。
仕様書と設計書の齟齬、設計書とコードの齟齬、これらを繰り返して取り除くことが必要であり、そのため機能ブロックと疑似コードを用いる。今回はレビュー中心に施策を行った。
スコープを明確にし、設計書は機能ブロックを用いてレビューする、疑似コードのレベルでコードレビューをする。こうすることで、規模が実際のコードよりは少ないのでレビュー可能となる。
効果として、機能ブロックと擬似コードを用いることで設計書とコードが整理されたものになり、レビューしながら設計することにより、問題の先送りがなくなった、レビューが楽しく行えるようになった、などが挙げられた。また、コード全体がわかりやすくなり、新人にも本質が見抜けるようになった、ということである。

ビブリオバトル
【司会進行・運営】
小野寺 瑠依 （ビブリオバトル室蘭）
土田 健斗 （ビブリオバトル室蘭）

ビブリオバトルは、バトラーと呼ばれる発表者が、自身のお気に入りの本を5分で紹介するプレゼンバトルで、今回は5名のバトラーによるプレゼンテーションが行われた。
プレゼンテーションというとスライドを用意してスライドとトークにより聴衆に伝えるケースが多いが、ビブリオバトルではスライドが無く、バトラー自身の表情や仕草、本だけでなく小道具による効果、そしてトークの内容で勝負することになる。スライドが無いために5分をどのように使ってストーリー立てて話せるか、そして聴衆の傾向を把握していかに共感を得られるかが重要ということを実感させられた。
バトラーの方々は各人の本に寄せる思いを存分に語り、どなたも魅力的であった。そして室蘭工業大学の学生による進行もまた素晴らしいものがあった。聴衆がなかなか質問の手を挙げないときにもバトラーのトークを補うような質問を代わりにしてくださった。全体的にあたたかいセッションであった。

チュートリアル
「テスト自動化分析 - 頼れる大人のテストエンジニアリングと金勘定 -」
講師：松木 晋祐 （ACCESS）
アシスタント：後藤 香織 （ベリサーブ）

チュートリアルでは、テスト自動化技術およびテスト自動化の戦略を考えるときにネックとなるROI(投資収益率)について、解説と演習により学んだ。
主にシステムテストを対象として自動化技術の特徴、自動化の課題、自動化における誤解、自動化の世代について解説があった。
その後、テスト自動化のROI(投資収益率)についての解説があった。ROIを考えるときの観点として、費用・時間・リスクの3つがあり、リスクについては「自動化しないことで負うリスク」であり、例えば繰り返しのテストで人が変わりリズムが崩れる、繰り返しテストすることを止めることでデグレードが起こる、といったものが考えられる。また、テスト自動化のROIはどの観点を使ったとしても一長一短あり、期間を区切ったうえで選択的、戦略的に便益を狙っていくとよい。ということを学んだ。
演習では、手動でテストを行った場合の見積もりをもとに、自動化をしたらどのようにコストが変わってくるか見積もり直し、その計算結果をもとに参加者同士で意見交換を行った。
演習を通じて、同じテストを一定回数以上繰り返さないとコストアップになってしまうこと、プロジェクトの背景により自動化を部分的に導入するという判断も必要となること、単に導入コストだけに囚われず結果の正確さなど広い視点でコストを考えること、プロジェクトの今後も鑑みて長い目で捉えることなどを学んだ。
テスト自動化における導入コスト、保守コストを踏まえたうえで、それを上回る効果とはなにか？を考える良い機会となった。

ワークショップ
「テストとメトリクスの素敵なマリアージュ」
TEF道 (TEF北海道ソフトウェア勉強会)
森崎 修司（静岡大学）

TEF道 (TEF北海道ソフトウェア勉強会)によるワークショップである。
模擬プロジェクトでのメトリクス結果をベースに、参加者が6～7名のチームに分かれ、話し合いによりメトリクス結果の是非について検討していき、その結果を報告しあい、さらにTEF道メンバおよび森崎先生からコメントをいただいた。
最初に、メトリクスに関する講義が行われ、次にワークショップとなった。ワークショップでは模擬プロジェクトのデータとして欠陥率、テスト密度、作業状況、バグ分析結果など、豊富なメトリクス結果が用意されていた。それに対して極めて楽天的なプロジェクトリーダから、品質分析報告が述べられた。この見解およびその後のテスト設計方針に対してさまざまな観点からデータの検討を行った。データが膨大であり、時間は限られていることから、どこに着目し、どこを指摘していくかなどがポイントとなったと思う。
グループ発表では、一つのメトリクスを追うだけでなく、他のメトリクスと合わせて検証するなど、各グループのメンバの経験による知見も披露され、非常に有意義な知見を得ることができた。

クロージングスピーチ
「コンテキストの理解による技法、事例の分析
- 苦手の対策にむけて-」
森崎 修司 (静岡大学)

新しい手法を取り入れる際に、背景、状況、制約＝コンテキストを意識することが重要である。コンテストを意識できることにより、単純な苦手意識であれば、克服できるよう手を施すことができ、よりつきつめて効果が本当に得られるのかを考えることができる。
本講演では2つの手法が紹介され、それらがコンテキストを意識した上で効果があるのかどうかについて会場とともに検証した。

手法1：Fault-proneモジュール予測

不具合のありそうなソースコードモジュールを予測する手法。プロダクトメトリクスとプロセスメトリクスを取る。その一つにFixCacheがある。これは、同じモジュールで不具合が再発しやすいという経験則を使って予測する。全体のソースコードファイルの1割で73～95%の精度で不具合を予測できた例が紹介された。また、Googleでのソースコード更新履歴に基づく不具合予測に応用されている、という事実がある。
これに対し、会場からは、

• 経験的には効果が出そう

という意見が挙がった。経験的には、というところでコンテキストを共有できていると判断できる。逆に上手く行かないと思う例としては

• 更新ルールができていないと更新履歴は取り出せない
• システムテストしかしていないので、対応しているモジュールが分からない

など、コンテキストが異なることが考えられる。

手法2：リファクタリング

プログラムの振る舞いを変えずにソースコードの可読性を上げる。更新が多いとソースが複雑になる。それをリファクタリングで解消する。
これに対し、会場からは

• そのソフトウェアの寿命が分からない。10年使うのならいいかもしれないけど、一瞬で終わるならいらない。

という意見が挙がった。これもその通りで、リファクタリングはコンテキストによっては単なる無駄、ということはある。コードをきれいにしておくことが大事かどうかについては、リファクタリングの実施へのコスト、コードの寿命など議論の対象になる。このようにコンテキストを知っておくことが大事である。

以上のような検証でコンテキストの重要性を実感することができた。