QbookジャーナルQBOOK JOURNAL

QCDをガッツリ底上げ!「仕様書インスペクション」で叶えよう!

最終更新日時:2020.05.29 (公開日:2018.06.11)

QCDをガッツリ底上げ!「仕様書インスペクション」で叶えよう!

例えば、素晴らしく高水準なテスト品質を誇るテスト専門会社、あるいは品質保証部門があったとします。彼らは持ち前のナレッジをフルに活用し、精度の高いソフトウェア検証を行ってくれます。そんな彼らに、あるシステムの第三者検証を依頼したとしましょう。
彼らはシステムに潜むバグを余すことなく検出するため、バグ曲線はなかなか収束する気配を見せません。追加テストの検討が行われ、分析の結果、工程の終盤で追加テストの実施が決定します。
その後も弱点となる機能に対して部分的な強化テストを繰り返し、バグ曲線がだんだんと緩やかさを見せた頃、ようやく全ての欠陥が解消され、システムは晴れてローンチを迎えることができました。
おかげで、バグのない高品質なシステムは、ユーザーに高い満足感を与えることができました。めでたし、めでたし。

いやいや、ちょっと待ってください。

その話、もう少し何とかならなかったものでしょうか。

高品質を求めるあまりに、犠牲になったモノ

ソフトウェアが高い品質をもって世に送り出されることは、大変結構なことです。しかし、品質をテスト工程の中で引き上げようとするには、どうしても犠牲にしてしまいがちなモノもあります。

それは、「コスト」と「納期」です。

プロジェクト下流のテスト工程では、バグの検出⇒解消⇒再確認という小さなサイクルが何百、何千と生まれ、この粒の一つ一つがソフトウェアの品質向上に大きく寄与します。
しかし、そこに費やされる工数も当然、粒の数だけ発生します。
この事実からは目を逸らすことはできません。

検出されたバグが製造工程のコーディングミスから生まれたものならば、まだ良かったと言えるでしょう。
しかし、バグの真因がプロジェクトの上流工程にあったとなれば、途端に厄介さを極めます。

要求定義書に、たった一行の記述ミスがあったとしましょう。
その誤った一行から、誤った基本設計が行われ、誤った内容が詳細設計にブレイクダウンされ、ついには誤ったソフトウェアが出来上がります。
仮に、テスト工程で誤りをバグとして検出できたとしても、その修正活動は要求定義から始まり、基本設計、詳細設計、そしてソフトウェアと、これまで辿ってきたすべての工程で行われなくてはなりません。

このような手戻り作業だけでも工数と労力を必要としますが、本当に怖いのは、これら一連の流れが「計画外の作業」であることなのです。
下流工程に入ると、上流工程の担当者はプロジェクトから離れる、あるいは別タスクを割り振られることがあります。基本設計を終えた担当者がシステム移行の計画を進めているところに、手戻りにより「急遽」基本設計の練り直しが入ってきた場合、担当者は進めていた移行計画の手を止め、設計作業に注力しなくてはなりません。このような緊急対応を予め想定しておくのは難しく、意外な形で、本来進めるべきタスクの進捗が阻害されてしまうのです。
設計担当者がプロジェクトを離任し、適切なスキルセットを保有したメンバーが存在しない場合も悲惨です。限られた時間で要員調達に奔走するか、あるいはリスクを無視して、スキルアンマッチなメンバーを割り当てざるを得ない事態に発展します。
当初計画にないのですから、テスト環境面数の不足やツールの不足も起こりえますし、混乱と焦りから、さらなる人的ミスを誘発することも十分に考えられるでしょう。

要求定義を1とした場合、欠陥の除去にかかる相対コストは、コーディング段階で10倍、テスト工程で15~70倍、運用に入ると40~1,000倍にも膨らむ(Tom Gilb 1999)と云われております。
これらが決して大げさな数字ではないことを、まずはご理解いただけたのではないでしょうか。

上流工程の欠陥、どうして誰も気づかない!?

例えば、基本設計の工程で何らかの欠陥(設計漏れ)が混入したとしましょう。
これに対し、何も対策をしないままに工程を進めた場合、次に欠陥を見つけるチャンスはいつ訪れるのでしょうか。
その答えですが、詳細設計、製造、単体テスト、結合テストをすり抜け、システムテスト工程あたりになるのではと予想されます。

「詳細設計や製造の担当者は基本設計書をちゃんと見てないの?」
「単体テスト、結合テストの担当者は仕事をさぼっていたの?」

いえ、そうではありません。
もちろん彼らが欠陥に気づく可能性もありますが、決してそれに期待してはいけません。

突然ですが、例えばこんな経験はないでしょうか。

組み立て式の家具を購入したあなたは、同梱された「組み立て方」の説明書を参考に、家具の組み立てを行います。部品の中には、役目の違うよく似た2種類の金具があり、説明書の記載ではこれらがまるで同じ部品のように扱われていたとします。
そのことに、あなたは多少の違和感を覚えるかもしれません。しかしあなたは、まずは説明書通りに作業を進めてしまうでしょう。
やがて完成後、あなたは家具がガタつくことに気がつきます。
家具を一度分解し、その原因を見つけた時。
あなたは、そこで初めて説明書に対する悪態や不満の言葉を漏らすのです。

詳細設計、製造、単体テスト設計、結合テスト設計の各担当者は、一様に、基本設計書から情報を得ます。基本設計書に対する粗探しや、評価をするためにそれを読んでいるわけではありません。
彼らは基本設計書の「検証者」や「評価者」ではなく、「利用者」なのです。
目的が違えば、視点も異なります。書いてあることが正しい前提のもと、時に「ちょっとした違和感」を覚えたとしても、まず大抵は自分の作業を進めることを優先して、基本設計書を読むのです。
ゆえに、欠陥に初めて気づくことができるのは、利用者でない、かつ要求定義がインプットされた、システムテスト工程の担当者と推測されるわけです。(下図1参照)

inspe-z1

※)V字で表現される各工程はプロジェクトごとに特色がありますが、ここでは上図の工程をモデルとします。

上流工程で生まれる欠陥は後続の工程を静かに汚染していくため、検知が遅れて取り返しのつかない惨事に発展してしまうことも珍しくありません。
何としても回避したいところです。

そこで、そんな上流工程の欠陥をスマートに、かつ効果的に潰すことができる、とっておきの手法に触れていきたいと思います。

キーワードは、「インスペクション」です。

インスペクションとは

インスペクションは、成果物に対するレビュー形式のひとつです。本来は(第三者による厳密な)検査、視察といった意味を持ちます。
レビューには、即席で行うアドホックレビュー、作成者が主体となって指摘を求めるウォークスルーなど、様々な形式がありますが、インスペクションはその中で最も公式的で、品質向上効果の高いレビューであると云われています。
ここからは、上流工程の成果物(要求定義書、基本設計書、詳細設計書)を総じて「仕様書」と呼称し、これらにスコープを当てた「仕様書インスペクション」としてご紹介いたしましょう。

仕様書をしっかり「作り込む」。それが仕様書インスペクション

上流工程の担当者は、仕様書を作成したのち、自身で行える限りの見直しはするかもしれません。もちろんそれは推奨されるべき行為です。ただし、仕様書は自分以外の第三者が読む前提のもと、作成されるべきものです。作成した本人にとって100点満点でも、次の工程の担当者が内容を理解できなかったり、得るべき情報が得られなかったり、曲解させてしまったりする可能性が多分に含まれます。
これらの問題は、作成者本人のスキルレベルや経験値でなんとかするものではありません。

仕様書インスペクションは、仕様書に含まれる欠陥を、早い段階で的確に潰すことを目的としています。作成された仕様書に対し、最適な評価者が、最良の環境で、適切な指摘を行えることが特徴です。

チェッカと呼ばれる評価者は、インスペクション対象となる仕様書に合わせて選抜されます。
例えば基本設計書を例とした場合、「要求定義書の作成者」「詳細設計書の作成者」「製造担当者」は、可能な限りチェッカとして参加してもらいたいものです。そこに「新人や未経験者」「インスペクションの専門家」「テスト技術者」が加われば、より指摘の幅が広がるでしょう。
特に「テスト技術者」は、テスト経験則に基づいたノウハウに期待が持てますし、上流工程から携わることで多くのインプットを得てもらえれば、下流工程で行われるテスト品質の向上にも繋げることができます。
各チェッカがそれぞれの立ち位置から役割を理解し、ユニークな観点で発する指摘や質問は、仕様書の品質改善における重要なファクターとなります。(下表1参照)

inspe-h1

インスペクションを遂行するにあたり、活動プロセスの確立、インスペクタ(チェッカを含む、活動への参加者)の召集、ルールの策定、スケジュールの設定やツールの調達など、緻密な計画と準備が行われます。これらはモデレータ(あるいはインスペクションリーダ)と呼ばれる「調整者」が担当します。
モデレータはプロセスごとのファシリテート、会議調整などの事務局、活動中のメトリクス収集、チェッカやオーサ(仕様書の作成者)の負荷軽減やモチベーションコントロールといった、活動の推進も担います。
こうした最良の環境をモデレータが提供することで、チェッカは仕様書に対する指摘出しに専念することができ、オーサは編集作業に注力することができるのです。(下図2参照)

inspe-h1

仕様書インスペクションを経て磨き上げられた成果物の品質は、想像以上に高い水準まで引き上げられているはずです。
欠陥を「その場で」細かい網にかけることで、次工程における作業品質も高まります。テスト工程で検出されるバグの数も自然と抑えられるので、修正活動にかかる工数も節約できることでしょう。
手戻り作業によるリスク軽減に著しい効果があることは、もはや言うまでもありませんね。

仕様書をしっかり作り込み、QCDのすべてを獲る。
仕様書インスペクションは、これらを叶えるための、少し豪華なプロジェクト活動です。

最後に

インスペクションは仕様書に限らず、テスト計画書やソースコードなど、あらゆる成果物について適用が可能です。また、参加者のスキルアップにも貢献するほか、記録票などのアウトプットは、上手に利用すればインスペクション活動のさらなる改善にもつながりますし、プロジェクトを縦横断する貴重な資産にもなります。
一方で、活動自体には、やはりそれなりの初期投資(時間やコスト)がかかります。モデレータの力量が十分でない場合、活動そのものに失敗し、リソースをただ費消して終わるケースもあります。
上手く回すことができれば、初期投資を補って余りある恩恵が期待できますが、下地もないままに適用するのは慎重になった方が良いでしょう。

肝要なのは、取り入れるプロジェクトの特色に合わせ、最適な形でカスタマイズすることでしょう。まずは簡単な成果物からパイロットで適用し、徐々に慣らしていくことで、皆様だけの「仕様書インスペクション」活動を創り上げてみてはいかがでしょうか。

参考書籍
Tom Gilb, Dorothy Graham =著/伊土誠一、富野壽 =監訳『ソフトウェアインスペクション』構造計画研究所、1999/8.

資料ダウンロード

執筆者:豊島 淳之介

バルテス株式会社 エンタープライズ品質サービス事業部 部長

金融系を中心としたシステム開発業務に約10年間、SE兼プロジェクトリーダーとして携わる。 バルテス入社後はソフトウェア品質コンサルタントとして、PMO支援やテストマネジメント推進業務に従事。 プロジェ...