ホワイト・ボックス法で合理的にテスト
ソフトウエアの中身を考慮してテストを行うのが，ホワイト・ボックス法である。ソフトウエアには，機能的にあり得ない組み合わせが存在する。ソフトウエアを開発した担当者には，その組み合わせが分かる。このあり得ない組み合わせを間引くのがホワイト・ボックス・テストである。例えばビルを作ったとする。ビルには，水道管や電気配線，ガス管などが走っているが，水道管からガスが出るかどうかのテストなどはしない。作った技術者なら，そんなことはあり得ないことが分かっているのでテストはしない。ブラック・ボックス・テストなら，ひょっとしたら水道管からガスが出るかもしれないと，テストを行わざるを得ない。
この記事は，「日経エレクトロニクス」と「日経バイト」が刊行した別冊『組み込みソフトウエア2006---品質管理と開発技法の実践的改革A to Z』の掲載記事を抜粋したものです。詳細はこちら。
ホワイト・ボックス・テストで合理的な手法は「原因結果グラフ」である。ただし，難しすぎてほとんど使われていない。筆者が勧めるのは「原因流れ図（CFD：case flow diagram）」である。テスト項目が少なく，理解しやすい点に特徴がある。
原因流れ図の基本的な考え方はこうである。ソフトウエアには，制御の流れや，トランザクションの流れなど，何らかの流れが存在する。この流れを把握すれば，ブラック・ボックス・テストのような総当たりの探索は必要ない。ソフトウエアの中身を見ながらディシジョン・テーブル（変換表）を作れば，大幅にテスト項目は減るという考え方である。原因流れ図は，原因結果グラフを流れ図で置き換えて理解（適用）を容易にしているという特徴も備える（図4）。筆者は10数年前から，原因流れ図を使っているが，最近になって少しずつ利用する企業が増えている。
図4 原因流れ図（Case Flow Diagram）
プログラムの中身を考慮し，不必要なテスト項目を削るとともに，処理（制御）の流れを素直にグラフに表現する。理解しやすいという特徴がある。
チームなくしてテストなし
テスト技法を現場に展開する際に問題となるのが人である。そもそも，ソフトウエアは技術ではない。ほとんどは「技法」の世界である。技法とは，使う人によって決まるもの，言い換えれば技能である。使う人によってパフォーマンスが決まる。だから技法を高めようと思えば，人を訓練して技能として高めていかなければならない。
しかしテスト工程は，個人の能力向上だけでは改善できない。組み込みソフトウエア開発に携わる人たちの仕事は専門性が高い。つまり，それぞれが自分で考えなければならない仕事である。一方で，この人たちは周囲と心を1つにして仕事に取り組んだり，人に頼るといったことが少ない。つまり，専門性は高いが協調性が低い人たちが，テスト技法の展開で障壁となることが少なくない。
では，どうすれば専門性の高いエンジニアをまとめることができるのか。筆者が勧めるのは，Bruce W. Tuckman氏が確立したチーム・ビルディングの理論を活用することである。
人が集まったときに，最初はバラバラの状態にある。けれども，旅行に一緒に行こう，バーベキューを一緒にしよう，ソフトウエアを一緒に作ろうといって集まると，お互いに探り合いが始まる。これを「形成期」と呼ぶ。このチームでは，どう行動すればいいのだろうと皆が周囲を見回す時期である。この状態でも，チームはそこそこ回るが，それほど本気になってメンバーは動かない。その後，個性がぶつかる騒乱期に入る。目標に向かってテストを行う場合に，「私はこういうやり方でやる」「いや，おれはこうだ」などと，専門性が違うことによってぶつかり合いが起こる。そしてチームはバラバラになる。この騒乱期は必ず起きる。騒乱期を乗り越えると，一定の秩序ができる規範期に入る。
チームの発展過程を横軸に，仕事のパフォーマンスを縦軸に取ったものが図5である。チームがバラバラなときには全くパフォーマンスが出ない。組み込みソフトウエアの開発は，まずこの段階から始まる。それが形成期に移ると，皆が周囲をうかがいながらもパフォーマンスが徐々に上がってくる。ところが騒乱期に入ると，隣り同士がメールでケンカをしている，口も利かないといった状況が起こる。当然，チームのパフォーマンスはがくんと落ちる。テスト技法などを持っていても，聞く耳を持ってもらえない。ここでチームは解体しかねない。思い当たることがある読者も多いのではないか。
図5 チームの形成過程とパフォーマンスの関係
騒乱期をいかに脱するかが，仕事のパフォーマンスを上げるポイントである。2005年のプロジェクトマネジメント学会誌掲載されたに松尾谷と榎田の論文を基に作成。
しかし，この時期にさまざまな方法論や予防策を講じれば，騒乱期を抜け出すことができる。こうなればしめたものである。その後，パフォーマンスがぐんと高まっていく。つまり，技法や人の作業でパフォーマンスを上げようと思えば，チームの状態が非常に重要な意味を持ってくる。チーム作りが，プロジェクト成功への早道となる。
騒乱期から脱出せよ
厳しい仕事を一緒にすればチームワークができるだろうと読者は思われるかもしれない。いわゆる「同じ釜の飯を食った」というやつだ。しかし，それは間違っている。チームができていない状況で難題を与えられても，皆がバラバラになるだけである。プロジェクトで仕事を進めようとする場合に，まず手掛けなければならないのがチーム作りである。チームを作ってから仕事を与えるという手順を踏むべきである。しかも，プロジェクトの期間が短くなってきている現状では，仕事を進めるなかでチームを立ち上げる時間的余裕はない。ではどうするか。
これまでチーム・ビルディングは大きく2つの方法で行われてきた。オンジョブ法とオフジョブ法である。
前者は，プロジェクトの仕事のなかでチームを作っていく。キックオフのミーティングや朝礼といった手段を採りながらチームを形成する。成功するかどうかはリーダーいかんにかかっている。リーダーの人間性をうまく使って，プロジェクトを成功に導く例もあるが，筆者の見るところ，うまくいっていない事例も多い。時間がかかることも問題である。プロジェクトの期間が短くなっている現在，この手法は取りづらくなっている。
後者のオフジョブ法は，プロジェクトの仕事から離れてチームを作る方法である。飲み会や歓迎会も1つの方法だが，これだけでは限界がある。そこで大きく2つの方法でチーム・ビルディングを行う。1つは自己開示型，もう1つは体験型である。
自己開示型では，リーダー自身に能力をつけてもらう。組織行動学や心理学の知見を生かし，ロールプレイヤ事例演習を中心にトレーニングを行う。体験型は，危機に遭うと助け合うという，人間の本能を利用する。例えばアドベンチャー型のチーム・ビルディングがある。フィールド・アスレチックのような所に連れていき，コントロールされた危険のなかでチームにゲームなどをやらせる。すると各自が危機を感じて，互いに助け合うようになる。こうしてチームを形成していくのである。（連載終わり）
