第33回　Webサイトのテストを，上手にマネジメントするには

　Webサイトをテストする方法について，前回に引き続き，もう少し掘り下げてみたいと思います。これまでは，個人的に行える範囲の方法を書いてきましたが，今回は，もう少し規模の大きなプロジェクトでテストする場合のヒントにしてもらえれば幸いです。

テストの目的

　「テストは何のために行うのか？」と問われれば，「問題（バグ）を修正するため」と通常は答えるでしょう。開発者の立場に立てば，「すべて」のバグは直すべきです。そのために全力を尽くすべきですし，これに徹することが開発者の良心の基でもあります。しかし誤解を恐れずに書けば，バグのないアプリケーションは存在しません。ですので，プロジェクト管理者の立場に立てば，開発対象の品質の「出来具合」を知ることが，テストの重要なポイントになります。

　経験をつんだプロジェクト管理者（プロジェクト・マネージャ：PM）やプロジェクト・リーダー（PL）は，どの程度の数のバグが発見され，それがどの程度で収束（修正）されるかを，開発規模から察知することができます。ソースコードの量から概算を計算する方法も，ソフトウエア工学的には研究されています。なのでPMやPLにとっては，バグがなくなること自体が大切なことであるとともに，信頼性のあるテストがきちんと行われ，それが最新情報であり続け，集計や傾向分析，あるいはどこに注力すべきかがわかる「情報」が非常に重要になってきます。

　これまで，画面キャプチャの撮り方（同時に「紙」による問題整理方法）や，HTMLソースコードごと記録する方法に触れましたが，PMやPLにとっては個々の問題の詳細（原因と対処）の深みにとらわれることなく，全体像を把握する一覧表のほうがニーズは高いでしょう。

Excelとメールで対応する

　一番用いられている方法としては，やはり「表形式」だと思います。「問題管理表」や「バグ管理表」という名で，通常はMicrosoft Excel（エクセル）で情報整理された「表」です。ユニークな番号（ID）があり，問題発見者や日時や問題詳細（現象）などが記されていて，対応済みや未対応などの「ステータス」を記録し，その「済み」マークをいかに多くするかに神経をとがらせます。

　情報管理の方法としては，Excelのファイルをメールなどで配布しやすいということからか，一般的には関係者全員が同じファイルを持って定期的な会議などを活用して，ステータスを変更していくスタイルがとられます。

　送ってしまうだけという方法なので，便利であり一般的とも言えますが，問題がないわけではありません。情報の更新や信頼性という意味で，関係者が増えるほど「情報の管理」が大変になってきます。各人が自分の担当領域だけを更新するにしても，流れ作業的に順番を決めて情報追加をして行くというワークフローで対応するにせよ，です。

　最大の問題は，関係者が増えるほどに「情報の整理」に時間（＝コスト）がかかり，肝心の問題解決（バグの修正）にかける時間を圧迫する点にあります。

システムで対応する

　したがって，そうした「情報の整理」をシステムにやらせる，という方法が増えてきています。Excel操作にかける時間が開発末期に大きくなると予想できるなら，多少最初のころに時間をかけても，情報整理をしやすい（あるいは，してくれる）「環境」を作っておいたほうが後が楽になります。

　イメージ的には，Webベースで問題の登録と情報更新（ステータスの変更），集計が可能なシステムです。ブラウザさえあれば，開発者の数に依存しないで情報を集めることができます。さらに，集計結果をCSV形式などで出力できれば理想です。このようなシステムを用意できれば，Excelのファイルを送って「やるべきこと（ToDo）リスト」を確認する方法よりも，Webに慣れていればいるほど快適に感じる人が多いでしょう。

　ただし，すべてをモニター画面で確認するという方法は，万人に受け入れられるものではないのも事実です。つまり，慣れ親しんだ形式への出力ができることが重要になってきます。画面のスナップショットを撮るように，問題一覧のスナップショットをファイルとして出力するのです。クライアントや上司から現状報告を求められたときにも，そのファイルを送るだけにすることもできます。

　さらにセキュリティなどを考慮すれば，もっと広範囲な情報共有も可能です。ブラウザさえあればアクセスができるのですから，URLを教えれば，様々な「役割」の人が「問題管理」に参画できます。

　例えば大きなプロジェクトでは，純粋な問題管理の専門家に参加してもらうことができます。問題の種類別に，日々のステータスの増減を管理する役割です。映画（映像）製作でのタイムキーパーのような仕事です。あえて開発現場の状況を知らなくても良い場合もあります。純粋（単純）にスケジュールの遅れだけを気にして，冷徹に進ちょく分析に徹してくれるほうがフェアなペースメーカーになってくれる場合が多いからです。

　また，多少の勇気が必要ですが，クライアントにそのまま見せるという方法もあるでしょう。クライアントが技術に明るい場合や，最新技術を多用していて常に最新情報にアンテナを張っておかなければならないようなプロジェクトでは有効です。また，協力会社や複数の「組織」での並行開発でも，使い方次第では非常に有効に機能します。

ツールを使うなら

　個人的には，慣れと設定のしやすさから，ファイルメーカーで作ってしまいますが，「mantis」というツールもあります。サーバー設定の部分で多少敷居は高いものの機能的には魅力的です。

結論

　ツールの導入は，そのツールへの「依存」を生み出します。ツールに振り回されて，本質的なことがらに集中する時間を奪われることも少なくありません。バグ管理ツールは，雑多な情報を整理するために存在し，基本的にはすべて（バグ）情報は，「修正完了」というステータスに変更されて，「ToDoリスト」から消えていくべきものです。また，そうならなければならない情報なのです。プロジェクト末期に，集中的に使われるものでもあるので，その管理に時間がかかるようでは本末転倒です。

　だからこそ，慎重にツールを選択する必要がありますし，その選択眼も鍛えておかなければなりません。そして，そうした経験の積み重ねが，データとしても残せることが，より高度な品質管理をするスキルとして定着していくのでしょう。

三井 英樹（みつい ひでき） 1963年大阪生まれ。日本DEC，日本総合研究所，野村総合研究所，などを経て，現在ビジネス・アーキテクツ所属。Webサイト構築の現場に必要な技術的人的問題点の解決と，エンジニアとデザイナの共存補完関係がテーマ。開発者の品格がサイトに現れると信じ精進中。 WebサイトをXMLで視覚化する「Ridual」や，RIAコンソーシアム，日刊デジタルクリエイターズ等で活動中。Webサイトとして，深く大きくかかわったのは，Visaモール（Phase1）とJAL（Flash版：簡単窓口モード/クイックモード）など。