頑張ってまとめたにもかかわらず、一度作ったきりで状況に応じた更新ができず、結局、テストチームの誰も見なかったり、支持を受けられない結果、誰にも守られない「テスト計画書」……。そんな不幸なドキュメントを作っていませんか?
システム開発をプロフェッショナルとして組織的に行っているなら、「最初から計画を立てない」というプロジェクトは存在しません。しかし、テストフェイズとなると無計画に突っ走る……、そんなプロジェクトが珍しくありません。どうしてでしょう。議論パートでも話題となりましたが、
こういった状態に陥ってしまうメカニズムを簡単に考察します。
「計画が守られないのはテスト計画が見直されないから」という意見をよく聞きます。この意見の理由として、以下を挙げられる方はきっと多いでしょう。
仕様変更が多発し、システム開発が当初のスケジュールやリソース内で対応できなくなり、その多くのしわ寄せがテストフェイズに来るため、結果として赤字プロジェクトに転落してしまう。こういった厳しい現実を嘆く方もいるでしょう。
とはいえ「テスト計画が見直されないのは仕方がない話で、結果としての損失もやむを得ない」。このように簡単に割り切れるものではないはずです。計画不在のテスト実施に陥らないために、どういった工夫ができるのかを考えてみましょう。
ビジネスモデルが変化すると、作成対象機能の変更とともに開発計画やテスト計画も当然変更する必要が出てきます。変更が発生したなら、その状況をフィードバックして素早く計画に反映させる必要があります。「以下のフィードバックループを回すのは理想論で、簡単にできることではない」という感想が聞こえてきそうです。
このような「機敏にフィードバックすること」を意味する興味深い言葉をソフトウェア開発の現場以外で耳にしました。それはボウリングの世界で使われる言葉です。今回は角度を変えて、メタファ(比喩)的な話とします。ソフトウェアテストにかかわる技術者には「抽象」から「具象」の世界を導き出す力が必須ですので、以下の話から何らかのヒントをつかんでほしいと思います。
ボウリングはさまざまなコンディションに左右されるスポーツです。レーンコンディションは、オイルの塗り方、湿度、レーン表面の汚れなどにより刻々と変化し、こういった条件で投げたボールの曲がり具合が変わってきます。
プロボウラーは投球ごとにボールの動きからフィードバックを受け取り、次の投球に生かします。もしこれが、ゲーム終了後にしかフィードバックせず次のゲームに挑むのでは、最初のゲームは低い点数しか得ることができなくなります。変化に機敏に対応できないようだと、ゲームの前半と後半でレーンコンディションが変化するような過酷な状況が起こった途端に対応することができなくなることは、容易に理解できるでしょう。
ボウリングの世界では、この「フィードバックして次の投球に生かす」という行為を「Versatility」と呼んでいます。英和辞典を引くと「多芸」と出ているでしょうが、このメタファをソフトウェア開発の現場に適用するときには「知恵と工夫」とでも意訳するのが適切でしょう。
システム開発においても、このVersatility=知恵と工夫 を活用することで状況が変化するゲームで勝利をつかむように、変化するプロジェクトの状態を常に感じ取るようにしたいものです。テスト計画を機敏かつ徹底的に改善しなければ、多くの場合、うれしくはない結末を迎えることになります。「速過ぎて/忙し過ぎて対応できない」のではなく、そうだからこそ機敏に対応(変更)するよう、意識を変えていくことが必要なのです。
[JaSST 実行委員会]
共同実行委員長 古川善吾(香川大学)
共同実行委員長 西康晴(電気通信大学)
[実行委員]
秋山浩一 (富士ゼロックス)
大月美佳 (佐賀大学)
大西建児 (豆蔵):本記事取りまとめ担当
大野晋 (SKサポートサービス)
片山徹郎 (宮崎大学)
榊原彰 (日本IBM)
鈴木太平 (プラネット)
鈴木三紀夫 (TIS)
高橋寿一 (ソニー)
野村絵里 (JaSST)
古長由里子 (日本IBM)
松岡正人 (日本IBM)
湯本剛 (サイクス)
和田憲明 (富士通)
敬称略(50音順)
Copyright © ITmedia, Inc. All Rights Reserved.