連載
» 2006年10月27日 12時00分 UPDATE

ソフトウェア品質を高めるには(1):Quality Architectによる戦略的なテスト

ソフトウェア開発において、最も戦略的でない工程は何でしょうか。多くのエンジニアは、テストを挙げるでしょう。残念ながら、頑張ってはいるものの、いまも多くの現場ではテストを行き当たりばったりに進めているのが現状です。そこで本稿では、テストを行き当たりばったりではなく戦略的に進めるために必要な考え方を、いくつか紹介します。

[西康晴,電気通信大学 電気通信学部 システム工学科 講師]

戦略的な品質向上を担うQuality Architect

 戦略的に進めるとは、一体どういう意味なのでしょう。例えば局地的な戦闘のような、個々の局面における目標達成を指しているわけではありません。事業全体における大きな目的を達成するために、すべての局面を俯瞰(ふかん)し、長期的な視野で進めていくことを意味しています。個別最適ではなく全体最適を狙うのだ、といい換えてもよいでしょう。すなわち、行き当たりばったりなソフトウェア開発というのは、個別最適のわなに陥っているのです。

 日本のソフトウェア開発の現場には、すっかりプロジェクトマネジメント(PM)という概念が定着しました。これによってマネジメント力が向上したのは事実です。しかしPMの概念を誤解している現場では、個々のプロジェクトのQCDを達成することだけがPMだと勘違いして個別最適に陥るあまり、組織全体として開発力が疲弊しています。お手軽にコストダウンを進めようと、発注品質を向上せず安易にオフショア開発に手を出し手戻りが多発する、というのも、個別最適による誤謬でしょう。プロセス改善という概念を誤解している推進組織は、標準プロセスへの準拠の強制とCMMIのレベル取りという誤った個別最適に陥ってしまっています。

 品質を向上しようと品質保証(QA)とソフトウェアプロセス改善(SPI)とPMOの組織を設置したにもかかわらず、現場はそれぞれの組織に報告義務を負ってしまい、かえって大変になってしまった組織もあります。能力の高いエンジニアを多く抱えているはずの日本のソフトウェア産業がこれほど赤字やトラブルに苦しんでいるのは、個別最適を狙うあまり全体最適を見失うというわなにはまっているためであると筆者は考えています。

 従って重要なのは、個々の技術力やマネジメント力を向上するだけでなく、戦略的にソフトウェア開発を進め全体最適を達成し、組織全体の開発力を向上することで長期的にコストを低減し品質を向上していくことです。とはいえ全体最適を狙う組織をまた新たに設置したのでは、元の木阿弥です。すべての個別最適はもともと、全体最適を狙う手段として始められたわけですから。必要なのは、組織の構成員すべてが全体最適を狙って行動することであり、そのきっかけとなる役割を開発現場の内部に配置することです。これは各プロジェクトの戦術的成功を支援しつつ、組織全体の全体最適を推進するという高度な作業にほかなりません。この役割を担う人財を“Quality Architect”と呼びましょう。

 Quality Architectは、プロジェクトの品質マネジメント、レビューやテストなどのV&V、プロジェクト内のプロセス改善など品質にかかわる活動を俯瞰的にデザイン・推進し、品質に関する責任を負います。同時に、プロジェクト内の品質達成が組織的な全体最適を推進するような施策を取らなくてはなりませんし、個々の開発技術者が全員参加で全体最適に寄与している感覚を持つよう泥臭い活動をすることも必要です。プロジェクト内の戦略的な品質向上と、組織全体の戦略的な品質向上の2つの活動をバランスよく達成するというミッションを持つわけです。そのためQuality Architectは高い開発力やマネジメント力を備えるだけでなく、有機的に結合させたさまざまな品質技術を俯瞰的な施策と泥臭い活動によって実現するという高い能力を備えていなくてはなりません。品質にかかわる技術者のキャリアの最高峰といえるでしょう。

戦略的なテストによる全体最適の実現

 次に、Quality Architectの視点からテストを眺めてみましょう。多くのテストの現場では、品質を向上するために大量のテスト項目を挙げ、人海戦術で実施しています。そうした現場では、品質を向上することは(テストの)コストを増大させることと同義です。

 しかしこれは個別最適にほかなりません。水際での膨大なテストというのは戦術的に仕方がないのかもしれませんが、長期的には組織が疲弊していきます。

 逆に、テストの上手な現場ではどのように進めているのでしょうか。そうした組織では、バグが出やすいところを上手に狙ってテスト設計を行い、バグがなさそうなテスト項目を適切に間引いています。別に魔法を使っているわけでも何でもありません。注目すべきは、テスト技術者と開発技術者とが密接にコミュニケーションを取っている点です。一体全体、何を話しているのでしょう。

 腕の良いテスト技術者は、テスト対象に検出されたバグをさまざまな観点から頭の中で分析し、同じようなバグがほかにも作り込まれていそうかどうかを推測しています。そして開発者に、似たようなバグが作り込まれている可能性と推測される機能を伝えるのです。それによって開発者はデバッグの際に水平展開をして効率的にコードや設計、仕様を修正していきます。

 また腕の良いテスト技術者には、頭の中で分析したバグのパターンが蓄積されています。

 そこで分析や設計といった開発のレビューにも参加し、開発者がバグを作り込んでしまいそうな「におい」のする部分を指摘することで、未然に不具合を防いでいます。気の利いた開発者であれば、そうしたにおいをレビューのチェックリストや開発のガイドラインに反映させることでしょう。腕の良いテスト技術者は開発経験が少ない場合もありますが、豊富なバグのパターンを持っていることで開発者に深く信頼されますし、気軽に相談を受けるのです。特に信頼の深い場合は、仕上がりに心配な設計やレビューし切れなかった部分を開発者がテスト技術者に伝えることでカバーしてもらうこともあります。

 一方、彼らは別の相談もしています。特に組み合わせのテストは膨大になるため、適切な間引きが必要です。とはいえ何も考えずに間引いてしまうと、バグの検出漏れにつながってしまいます。そこで組み合わせのバグが発生してしまうような設計上の依存関係があるかどうかを開発者に検討してもらい、よりバグが漏れにくいテストの間引きを実現しているのです。開発の上流からテスト技術者が参画し並列に作業している場合は、組み合わせのテスト項目数が爆発し過ぎないよう、依存関係が集中し核になっている部分をスッキリと設計してもらうように依頼することもあります。

 もちろんユーザーの要求の重要度をヒアリングしてテスト項目の優先度に反映させたり、テストし切れずに出荷せざるを得ない部分の品質リスクが許容範囲内なのかどうかを相談する場合もあります。それにより開発者自身も要求の不備に気付き、改善につながります。

 こうした腕の良いテスト技術者が自然に実施している施策は、人海戦術によって大量のテストを消化し品質を確保する個別最適のわなにはまったテストとは異なります。テストの質を向上することで開発全体の質が上がるという、個別最適と全体最適とを同時に実現できる施策なのです。技術的にはそれぞれ不具合モードやWモデル、リスクベースドテストと呼ばれていますが、重要なのはこのような技術をただ導入することではなく、戦略的な位置付け、すなわちQuality Architectの視点を十分反映させるように導入することです。

 そして個別最適のための活動や努力が、全体最適にきちんとつながっていることを把握し確認し続けることです。それこそが全体最適を実現する戦略的なテストといえるでしょう。

 Quality Architectは、現場が思い込んでいる「品質を上げようとするとコストが掛かる」という誤謬を払拭し、「品質を上げようとするとコストが下がり、納期が短縮する」という正しい認識に改めることが使命です。テストをきっかけに自組織の品質改善活動を棚卸しし、個別最適のために全体最適を阻害する施策になっていないかどうかを確認することを通じて、多くの組織でQuality Architectが育成されることを願っています。


◎ 本記事は日本科学技術連盟(日科技連)発行の「クオリティワン」で掲載した内容を日科技連了承の下、再編集の上再掲載しています(編集部)。


筆者プロフィール

西 康晴(にし やすはる)

 某社でソフトウェアテストに関するコンサルティング部門を立ち上げた後、東京・調布の電気通信大学にて研究や教育、コンサルティングを行う傍ら、ソフトウェアテストのエバンジェリストとして「現場に笑顔を」をキーワードに飛び回っている。



Copyright© 2016 ITmedia, Inc. All Rights Reserved.

Loading

ピックアップコンテンツ

- PR -

注目のテーマ

マーケット解説

- PR -