勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

ソフトウェア独立検証および妥当性確認(SW IV&V)についての私的まとめ

日本技術士会の情報工学部会の2012年6月部会で紹介されていたJAXAのソフトウェア独立検証および妥当性確認(SW IV&V)活動が興味深かった。調べてみるといろいろと資料も公開されているようなので紹介する。なお、本エントリの内容は公開資料に基づく筆者の私見であり、JAXAさんとはなんの関係も無いことをおことわりしておく。

SW IV&V とは

SowtWare Independent Verification and Validation のこと。独立した組織の指導と管理に基づいて検証(ベリフィケーション)と妥当性確認(バリデーション)を行うこと。

SW IV&Vの特徴としては、以下の1,2,3が挙げられます。

  1. リスク特定・リスク対応技法を含む
  2. 検証と妥当性確認に対して、独立した評価・査定を提供する。(検証組織が開発組織とは独自に検証技術を開発・獲得する)
    • 検証 = 正しく製品を構築しているか? 検証はソフトウェアの開発サイクルでの各フェーズで確立されている(フェーズに対する)要求を満たしているか否かを決定するプロセスです。
    • 妥当性確認 = 正しい製品を構築しているか? 妥当性確認はソフトウェアの開発サイクル全体を通じて、ソフトウェア製品がミッションと顧客ニーズを満たしているかを評価することです。
  3. 開発組織に対して、・リスク特定・対応策、・品質・安全性の』向上、・適時性・信頼性の改良、手戻りの低減という事項に対する支援を実現する

ベストプラクティス調査報告~究極の高品質ソフトウェア開発プロセスをめざして~(PDF)P9

JAXAによるIV&Vの取り組み

JAXAの資料(前述のベストプラクティス調査報告)を見ると、だいたいこのような取り組みになっているようだ。

  • 開発プロセスに則り成果物が作成されたかの確認(プロセス保証)はIV&V組織とは別のSQAが担当している。
  • IV&Vは開発部門から独立して、成果物の品質(記述内容の論理性、一貫性、妥当性等)を検証する。
    • 各工程などで達成度(どこまでやるか)に応じて、ヒアリングやチェックリストによる検証から、シミュレーションを用いた検証までを実施

なお、ベストプラクティス調査報告に加えて、神戸大学でのリサーチも公開されておりこちらではJAXAの現場のコメントなどが紹介されていて興味深い。

IV&Vで品質が確保されているわけではなくて、ものづくりは現場の人が作り込む、特に品質は作り込むものなので、IV&Vをやったからといって、品質を確保できているっていう位置づけでは、私たちはIV&Vはやっていないですね。
(中略)
NASAプロジェクトの、IV&Vやっていないプロジェクトもいっぱいありますよね。じゃあ、それを上げられないかというとそんなことはなくて、なんでやるのかっていう時に、品質を確保するんじゃなくて、先ほど申し上げた通り、ある特別の目的で、再度チェックをすると、いうことですかね。より、確度を高くするために。

IV&Vの発想からすると、IV&V組織が品質向上の施策のように考えがちだがそうではないようだ。

  • 品質そのものは既存の開発現場で作り上げていく
  • さらに(ある特別の目的で)より高い品質を保証するためにIV&Vを活用する

ふつうのソフトウェア開発におけるIV&V

じゃあ翻って、ふつうのソフトウェア開発(この定義も難しいけれど)においてIV&Vは有効なのだろうか

  • 品質の底上げを図るような効果はIV&Vにはない。一定以上の品質を独力で確保できる素地が必要(組織、人員やプロセス等)
  • すでに一定の品質が達成されていて、より高い品質を保証する要件が有る場合にのみIV&Vが効く
    • ベストプラクティス調査報告では「製品がユーザにリスクを与える」分野(医療機器、運輸、社会情報インフラ)等が適用領域としてコメントされている
  • IV&Vが必要とされる分野のユーザ企業でIV&V組織を立ち上げるというのはそれなりに意義がありそう
    • SQAやPMOと目的が被りがちなので、きちんとした役割分担は必ず必要
  • ベンダー側でのIV&Vはうまくいかないような気がする
    • プロジェクトの個別性が高いので、IV&Vがうまく機能しない
    • IV&Vが狙う高い品質よりも、まず基礎的な品質向上に力を入れたほうが費用対効果が高いだろう
    • IV&Vよりも、SQAによるプロセス保証的なアプローチや、PMO組織によるマネジメント強化が先だと思う