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

S1) 基調講演
「がんばるだけの品質向上活動からの脱却」
森崎 修司氏 (静岡大学 情報学部)

事前質問への回答から基調講演が始まったが、途中から質問も回答もどんどん笑える物となっていき少々驚いた。これは森崎氏とJaSST実行委員会が例年極度の緊張状態になる会場の雰囲気をなんとか和ませたいという気遣いで、周到に用意されたものであった。
この「笑い」は会場を和ませるのに大いに成功したと思う。

講演では森崎氏自身の経験に基づき品質向上活動を「4レベル+１」に分解し、それぞれのレベルの詳細と改善に向けた施策について事例を挟みながら説明が行われた。
品質向上活動のレベルは次のように分けられる。

• レベル0：品質向上とは関係ない活動をしている
• レベル1：各々が思い思いの品質向上活動をしている
• レベル2：関係者間で求められる品質が合意できている状態で活動をしている
• レベル3：他にまね出来ない品質向上活動が特徴づけられている
• レベル4：品質活動が競争力の源泉となり、顧客が価値を認めて対価を払ってくれる

各レベル改善に向けた施策と注意点

• レベル0：ルール増加・強調は、「ルールさえ守っていれば大丈夫」「ルール以外は気にしなくてもよい」という人が増える、そうならない為にあるべき姿を示す。
• レベル1：レベル0脱却のポイントに加えて、結果や表層的な情報だけではなく背景や状況を含めて合意する。 その為に日々品質活動を見えるようにし、活動への抵抗を減らす。
• レベル2：上手くいっている理由を深掘りし成功要因の検討をする。上手くいっている理由をもとに自組織の特徴と関連づける。その為に他の事例を知るのは大事。コミュニケーションも大事であり、コミュニケーションが取りづらい所ではバグが混入しやすくバグが出来る背景がわかっていても解決させる取り組みが出来る組織は少ない。
• レベル3：競争力を分析する。　「あれ？」と思うところからはじまる。

品質向上活動は常に抵抗に合うのは仕方が無いとし、活動を定期的に見直し本当に品質向上に繋がっているか振り返ることが重要とまとめられた。
講演内容からは、「顧客が価値を認めて対価を払ってくれる=ビジネス」として品質向上活動もビジネスと直結させて意識していく必要があることが伝わってきた。
現場ではついつい忘れてしまいがちであるが、今自分(達)の品質向上活動を測る上での指標として大変参考になる内容であった。

S2-1) 事例発表
「ランダムテストにおける問題改善手法の報告」
清水 有樹 （DTS） 田処 将司 （DTS）

Mobile FeliCa ICチップのファームウェア開発で、入力の組合せによる想定テストケース数を計算すると8585216通りとなり全ケースのテストが不可能。そこで2因子間の組合せをAll-Pair法で実施し、多因子間網羅のテストにランダムテストを導入した。ランダムテストではコマンド選択比率の制御と要素ごとの同値分割を導入し、重複や偏りを無くし複雑な条件で評価を行った。形式仕様記述言語VDM++で開発した期待値エンジンを作成しテスト結果と比較して確認した。
発表後の質疑応答で、Ruby言語で約70000ステップのテスト専用のツールを別途開発していると話されていた。テストは4883094通り行われており、ランダムテストのテストケースよりも期待値エンジンによるテスト結果比較が大きく貢献しているように思えた。テスト専用ツールの効果の大きさを実感できる内容であった。

S2-2) 事例発表
「機能ブロックと擬似コードを用いたS/W開発事例
- 上流工程で後工程の作業に直結したアウトラインを描く -」
鳥本 明男 （メルコ・パワー・システムズ）

開発時の品質向上と納期短縮の為に、上流工程の時点で後工程の問題を取り除き、要求のトレーサビリティの確保を行う。要件定義・外部設計・内部設計・コーディングと続く開発の流れで、要件定義書と外部設計書に機能ブロックが入り、内部設計書に擬似コードとテストデータが入る。テストはxUnitを用いたユニットテストを定着させた。
要求仕様書で要求を仕様化する際に具体的な変更方法を記述する話に似ていると感じたが、上流工程(要求側)の視点なので、擬似コードでプログラマと認識を一致させる点など工夫を感じられる内容であった。

S2-3) 事例発表
「テスト駆動開発の導入
- ペアプログラミングによる学習効果 -」
渡辺 修司 （札幌Javaコミュニティ）

テスト駆動開発とは、テストコードをプロダクトのコードより先に記述するテストファーストを実践しインクリメンタルに開発する開発手法。ペアプログラミングとは、ペアで1つの作業を行うプラクティスで、コードとを書くドライバーとサポートするナビゲータの役割を定期的に交代するやり方。5、6人で3ヶ月程度の規模の開発に、テスト駆動開発とペアプログラミングを行った。

開発の流れ

1. ナビゲータに実装することを説明する
2. ナビゲータからの質問に答える
3. 合意したならば、実装を進める
4. 適宜ツッコミを受ける
5. 一区切りついたならば役割をチェンジする

作業時間

1. 実装完了時間はほぼ２倍
2. デバッグ時間は半減
3. システムテスト後の修正時間は半減
4. トータルで２-３割増えた程度　※慣れてくれば同程度の時間になる可能性

品質は不具合の質が変化しシステムテスト時の不注意的な欠陥が激減し、プロジェクト中盤でも安定して動作した。テスト駆動開発とペアプログラミングの効果として、効果的なユニットテストを強制、考えたことを相手に伝えるプロセスがある、プロジェクトナレッジの共有、プログラマのスキルアップがある。テスト駆動開発におけるテストは主にデバッグ／単体テストレベルの物であって、品質保証的なテストは該当しない。欠陥を見つけることよるりソースコードの品質向上が目的であることを改めて実感できる内容であった。

S5-1) ビブリオバトル

ビブリオバトルは、長年全国で開催されているJaSSTの中で初の試みで、今まで行っていたライトニングトークスに替わり新機軸として取り込まれた。
紹介された本は以下の通り。

• 「リーンソフトウェア開発　～アジャイル開発を実践する22の方法～」
  　鶴谷 俊之（日本アイビーエム・ソリューション・サービス）
• 「インタフェースデザインの心理学　- ウェブやアプリに新たな視点をもたらす100の指針 -」
  　阿部 智紀（トラスティア）
• 「ソフトウェアテスト293の鉄則」
  　都築 将夫（TEF東海）
• 「カエルを食べてしまえ！」
  　雨池 真一（日本ナレッジ）
• 「ラピッドデベロップメント」
  　島根 義和

「知的書評合戦」とも言われるビブリオバトルは読んで面白いと思った本を順番に一人五分間で本を紹介するという物で、ソフトウェア関連の書籍は高価であり、普段なかなか本の中身を知ることが出来ないが、ビブリオバトルを通じて未知の書籍を知るのにとても参考になる場だったと感じた。特に島根氏の紹介した「ラピッドデベロップメント」は価格だけ見ると高価であり敬遠しがちな本ではあるが、氏の紹介では「内容が非常に豊富であり大変お買い得である」と紹介され、大いに購入意欲が湧いた。

S6-1) チュートリアル
「超高速コードインスペクションの実践」
原 佑貴子 （日本IBM）

講演者 原 佑貴子氏は、前年のJaSST北海道で「品質エンジニアの思考回路 －コードインスペクション編－」と題して日本IBMで開発されたインスペクション法「Quality Inspection」の実演を行っている。今回はその内容の一部を実体験できるものであった。前年は5000ファイルものソースコードが使われていたが、今年も数十ページに及ぶ生のソースコードが印刷物として用意される驚愕の内容であった。やはりレビューはコーディング熟練者の方が素早く且つ正確に指摘することが出来ていたが、「Todoが残っている(仕様が決まっていない)」、「例外無視(作り込み不足)」といった、欠陥予測をポイントに見ることで比較的効率良くレビューができることを体感した。

S7) クロージング

クロージングにて、シンポジウム7回目で初めて参加者が100名を超えたと発表された。
ビブリオバトルのような新しいことへ挑戦する姿勢や、前年反響の大きかった原 佑貴子氏の発表をフォローし、さらに一歩踏み込んだ発表として手配する等、参加者が楽しめる工夫が随所に見られ、シンポジウム全体の姿勢と工夫が参加者増加に繋がっていると感じた。

最後に

クロージングでJaSST北海道は終わりであるが、情報交換会に特色があるのでここで紹介したい。 情報交換会は参加者がより多くの情報を持ち帰って貰うことに焦点が当てられ、食事は軽食、参加費は無料で、参加者が講演者に直接疑問や意見を話せて更にその情報を共有できる場になるよう工夫されている。 全員参加可能なパネルディスカッションに似ているが、堅苦しさは無く、より深いコミュニケーションが行える場となっている。
最後まで多くの情報を持ち帰ることのできる、大変有意義なシンポジウムであった。