昨今、ソフトウェアの巨大化が大きな課題と認識されている。特に航空自衛隊が42機導入を検討しているF35戦闘機の著しい開発遅延は、ソフトウェア開発の著しい遅れが原因とされている。F35のソースコードは現状で2000万行を軽く越える規模となっており、そもそも人間の管理能力の限界を超えているとも言われている。このような巨大化し複雑化するソフトウェアは、宇宙・航空、医療、鉄道、自動車などミッションクリティカルな社会システムを動かす大きな基盤中の基盤となっており、今後もその重要性は益々増大することはあれ、絶対に減る事はない。
このような状況において、今ソフトウェア業界では、IV&V（Independent Verification and Validation）が注目されている。
IV&Vは、開発組織から独立した組織が高度なソフトウェアの信頼性を確保するため、正しい仕様のソフトウェア（Validation）が正しく動作すること（Verification）を、客観的に評価する活動または組織を意味する。IV&Vは、航空宇宙システム、鉄道等の社会インフラシステム等のクリティカルシステムを中心に適用が進んでいる。クリティカルシステム以外でもソフトウェアの品質説明力を向上させる為に必要とされる活動である。
以下、IV&Vについて徒然なるままに。
高い信頼性が求められるソフトウェアでは、誤動作が許されない。宇宙ステーションや人工衛星、ロケットなどの宇宙機は、ひとたび宇宙空間に出ると、物理的な修理を容易に行うことができない。宇宙機に搭載されるソフトウェアについても同様であり、打ち上げ後の修正や変更は容易でない。ソフトウェアの誤動作は、致命的な故障につながり、人命にかかわる事故となる場合もある。宇宙機のゴールは宇宙機のミッション成功。ゴール達成のためには、バグのないソフトウェアを実装することが極めて重要である。但し、完璧と思える開発プロセスや検査プロセスが確立していてもソフトウェア上の問題が残ってしまうことが多々ある。これは人間系の問題であり、ソフトウェアの問題とは異なる次元にあり、人間のうっかりミスや想定抜けをゼロにすることは難しいのが現状。
IV&Vはこの人間系の問題を開発プロジェクト組織とは別の第三者の冷静な観点で、ソフトウェアを点検することで、高い信頼性を実現することを目的とするもの。これは、IV&Vの「技術的独立」のメリットと言われる。
IV&Vのポイントは、開発組織とは別の組織によって厳密に行うこと。開発組織の方針やスケジュールに左右されず、IV&V組織の中で、どのソフトウェアをIV&Vの対象にするか、IV&Vにどの技法を使うか、IV&Vのスケジュールをどうするかを決定し実施する。これを「組織的独立」と言う。更に、IV&Vは独自の予算によって実施される。開発に携わっている組織において、資金面の問題によってIV&Vができなくなることを防止する。これは、IV&Vの「資金的独立」と言う。
ミッションクリティカルなシステムソフトウェアの場合、開発組織の中で品質が作り込まれていくプロセスとは別に、IV&Vを実施することで品質と安全性の確度を高めることとなる。IV&Vでは、受注者で行われている品質向上策とは異なる手法、観点、技術で、成果物をチェックする。これにより開発組織で発見できなかった欠陥を見つけることが可能。
IV&Vの嚆矢はNASAである。NASAはV&V体制、つまり開発組織でVerification＆Validation実施体制を確立し、それなりの効果もあげていたと推測される。しかし、1987年のチャレンジャー号の空中爆発事故が発生し、 原因究明が強力な体制で実施された。原因は、固体ロケットブースター(SRB)のオーリングの不具合であった事が判明する。但し、 事故原因の究明過程でソフトウェアについても専門家による再チェックが実施され、 膨大な不具合が発見された。それら不具合の中にはシャトルの運用に甚大なる被害をもたらすものも多く含まれNASAの事故究明を任とするロジャー委員会のソフトウェア部会報告書には、ソフトウェア不具合の中には第三者がチェックすることに事前に取り除ける不具合が多数存在する事が指摘された。この報告を受けNASAでは新たにIV&Vという検証プロセスの確立に向けた作業が進められる事になった。具体的にはNASAで開発されるソフトウェアを独立に評価する機関IV&V Facilityを設立した 。
NASAでは150人のIV&V専門家とケネディ宇宙センターなどに常駐するIV&Vフィールド技術者が数100名規模でソフトウェア対策に従事していう。IV&V Facilityの活動詳細は http://www.nasa.gov/centers/ivv/home/index.html を参照。
スペース・シャトルのシステムは、1秒間に約3、500万命令の処理が可能な性能だったが、NASAで事故後に約100のプロジェクトリスク評価データを検討し、70プロジェクトをIV＆Vの導入候補とし、リスクの高いものから適用するガイドラインを設けIV＆Vを導入した。 その効果については、NASAのプロジェクトへのIV＆Vの適用は肯定的な結果となり、手戻りなどコスト高と致命的な障害の未然防止もできたとしている。NASA IV&V Facility MDP が公開しているデータセットがあり、複数のプロジェクトで開発されたモジュールに関するメトリクスを記した内容である。
公開データにはプロジェクト毎のモジュールの不具合数不具合率が含まれておりモジュールのコード行数合計、不具合数合計をそれぞれ集計し、1000行毎の不具合率を計算している。
1000行毎の不具合率は中央値が6.95、平均が7.86で、天下のNASAにおけるソフトウェア開発でも多数の不具合が混入している現状が覗える。つまりIV＆Vという検査プロセスを経ることで、不具合の存在が明らかとなり、結果的に欠陥の流出を抑制できる可能性がある。
ソフトウェアやハードウェアの不具合以外にも、下記のような大きなプロジェクトにありがちな問題も指摘されていたと言う。（他人事でない・・・）
「人の死に至ったあの飛行の安全性を損なう潜在的な危険を指摘していたエンジニアが何人もいたにもかかわらず、 スケジュール通りに打ち上げを行うというプレッシャーのかかった管理者は 彼らの訴えを却下していた（怒）」
JAXAにおけるIV&Vは、 1996年NASAとの宇宙ステーション共同開発に取り組んだ事を契機としている。つまりIV&VをNASA から義務付けられたと言うこと。それ以降1998年からはロケット、人工衛星の開発への横展開が始まり、H-ⅡAの1998年の事故で、 IV&V活動が強化され現在の体制確立に繋がった。また欧州宇宙開発機構で利用されているSPICE for SpaceにはIV&V関係のプラクティスが含まれており、JAXAとしてもプロセス改善とIV&Vを融合させて推進する姿勢である。
IV&Vから少々外れるがJAXAにおけるモデルベースのプロセス改善への取組みは2002年からで、STD‐24／NDC1-9-1やCMM（ソフトウェア成熟度評価）によるGAP分析結果と国際標準ISO12207（SLCP）、SPICE for Space、SA-CMM等を参考にした統合プロセスの検討・実装を行っている。
IV＆Vの特徴は以下の通り。
①リスクの特定（リスク対応技法を含む）
②検証 と妥当性確認 に対して独立した評価・査定を提供する（検証組織が開発組織とは独自に検証技術を開発・獲得する）
③開発組織に対して、リスク特定・対応策、品質・安全性の向上、適時性・信頼性の改良、手戻りの低減という事項に対する支援を実現する。
IEEEは、IV&Vの独立性（IV&VのI）に対し技術的独立、管理的独立、財政的独立の3つ視点で規定している。
①技術的独立：
開発プロセスや製品の査定をするIV&V担当者の専門技術は、 開発者のそれとは独立である。
②管理的独立：
IV&V実施工数はシステム実装に責任をもつ組織から分離されていることが要求される。IV&Vは 解析・テストするソフトウェアおよびシステムのセグメント（部分）を独立して選択し、IV&V手法を選定し、IV&V実施スケジュールを立案し、 取り組むべき特定の技術課題・問題を選択する。
③財政的独立：
IV&Vは開発組織より別で上位（通常は本社組織等）の組織から資金提供（予算立案）されるべきものである。 通常の開発プロジェクトはIV&Vサービスを受けたことに対して費用を払う。
IV&Vのコストが気に掛かるが、JAXAは公表を控えているようだが、NASAはガイドラインを公表しており、IV&Vのコストは、ソフトウェア開発費の10％が標準的としているとの事。IV＆Vの定量的な効果は、JAXA内部でも公表していない。NASAは、2007年から2009年の積算で28億円の効果があったとしている。
これはIV&Vで発見された不具合が放置された場合の被害想定額。定性的な効果としては、以下。
①技術的欠陥の抽出
・通常の試験技術では発見が困難な上流工程の欠陥 （開発担当者の思い違いなどにより混入したシステム挙動の矛盾や重要機能の欠落など）を発見できる可能性がある。特にシステム欠陥、異常・故障時の動作不成立などが発見される。
・主開発プロセスにおいて未導入の新規検証技術 （モデル検査、 フォールトインジェクションによる網羅試験など） により、複雑な欠陥を点検できる。
・コードレベルでは、故障耐性不足（エラー処理など）、タイミング競合などの問題が解析により発見される。
②開発作業品質の向上
・ピアレビューと一緒で他人、つまりプロジェクトに関係の無い他者が成果物を見る・検証するということで、開発担当者が「キチンと作ろう」という気持ちになる。意外とこれは重要な最初の一歩である。
・IV&Vにより発見された問題が引き金となり、 開発担当者による自己点検の観点に取り込まれ、 他の重要課題の抽出に繋がる。
・開発組織、 対象製品の特性に合わせて、 重要な工程、 観点に焦点を当てた検証を行うことができ、 信頼性向上のための効率的コスト配分を実現できる。
・新規技術をIV&V技術として実証（シャドウプロセス）を進め、開発プロセスの飛躍的ステップアップに貢献できる。（基礎体力としての信頼性向上、 品質向上）
③マネージメントへの品質の可視化
マネージメントに対して、客観的な立場での製品の評価報告を実施することにより、重要な経営判断へのインプットとなる。
IV&Vで用いるツール＆技法には・・・
・各種シミュレータ（Matlabや業界や特定分野に特化したシミュレータ）
・テストケース生成、
・静的コード解析（MISRA-C）
・モデル作成／モデル検証ツール
・モード遷移解析 － 完全性解析
・ノミナルシミュレーション － FDIR(1故障時)網羅性解析
・ソフトウェアデビエーション解析 －単一故障シミュレーション
・FDIR階層分析 －複数FDIR並列実行解析
・安全モード遷移解析 －二重故障シミュレーション
・HAZOP解析 － 一貫性解析
・共有変数解析 －コードクローン解析
・階層モデルによる事項事例解析
・自然言語仕様によるモデル自動生成－トレーサビリティ解析、リーチャビリティ解析
・運用制約識別 －インターフェイス解析
・タイミング解析 － 二重故障安全網羅テストケース解析、姿勢制御系搭載ソフトウェアチェックリスト
IV&Vを組み込んだ開発プロセス基準書には、以下のようなものがある。
・搭載ソフトウェア品質保証プログラム標準（JMR-009A）
・プロセス定義文書目次 （NDC-1-9-1）
・ソフトウェア設計基準（JERG-0-026） 平成16年4月1日 （NDC-1-9-1）
・標準プロセス
NASAは、IV&Vのテスト・検証プロセスにおいてソフトウェアシミュレーションを多用している。2010年にNASA IV&Vのndependent Test Capability（ITC）チームは、NASAゴダード宇宙飛行センターと協力して、全球降水観測計画（GPM）Operational Simulator（GO-SIM）プロジェクト向けに、ソフトウェアのみのシミュレータを開発している。GPMのミッションは、国際的な人工衛星網により、地球全体の雨や雪について次世代の観測を行うこと。GO-SIMには、GPMの地上システムとデータベース、フライトソフトウェアの実行ファイル、人工衛星のシミュレータなどが搭載されるが、Wind River Simicsと言う製品を使用することで、シミュレーションモデルの80～90％を他のミッションで再利用可能となり、莫大なコスト削減を実現。因みにGO-SIMのコンポネント（ITC Synchronous Bus：ITCSB）は、ジェイムズ・ウェッブ宇宙望遠鏡のIV&Vシミュレーション・テスト（JIST）プロジェクトで再利用された。このほかNASAでは、NASAのフライトシステム用途以外にGO-SIMソリューションを商用化する可能性を検討しているとの情報あり。
ソフトウェアに起因する事故は、1990年代以降、 衛星の大型化とミッションの複雑化に伴って衛星の故障や事故が増えた。NASAは、ミッション中断となった太陽観測衛星(SOlar Heliospheric Observatory：SOHO)について、事故調査を行い階層構造で事故モデルを詳細に明らかにしている。その結果衛星で重要な制御を担当するソフトウェアに多くの故障や事故が起因していることが指摘された。システム安全で、衛星開発の初期段階からソフトウェアの影響やヒューマンファクタに起因する事故の可能性まで幅を拡げて検討することが重要である事が認識された。また同時期にNASA Design for Safety programとNASA IV&V Facilityからの経費でマサチューセッツ工科大学大学院生25名による航空宇宙事故レポートの詳細かつ体系的な分析研究がある(N.G.Leveson、2001)。この論文では、アリアン５型ロケット１号機、スペースシャトル・チャレンジャー号、NASAの火星探査衛星および火星着陸衛星、タイタンロケット、名古屋空港での中華航空 A320事故などの３つの航空機事故を対象に分析した結果、ソフトウェアが重要な役割を果たしているシステムの事故は、従来のイベントを時間軸でつなげるモデルでは分析が不可能であると指摘。また宇宙の事故の要因として、安全文化が普及を越して氾濫して機能していないこと、 安全について組織間のコミュニケーションが形骸化していること、不十分な安全解析があることを識別している。更にスペースシャトル事故の詳細分析結果では、打上げ成功が続いてスタッフが自信過剰になっていたこと、ソフトウェアの役割を過少評価していたこと、冗長系に頼りすぎていたこと、安全マージンを少なくする設計変更を繰り返したこと、ヒヤリハット情報を無視したこと、総じてシステム安全が十分に機能していないことが要因になっていると指摘。今後は事故の未然防止に向けて、科学的にソフトウェアがからむ複雑システムの事故メカニズムを表現できるモデルを構築しシステム安全とソフトウェア安全を発展させる必要があると結論付けている。
複雑化するシステムの事故メカニズムを解析する手法として事故をモデル化しそのプロセスまで論理的に解析する手法（Systems–Theoretic Accident Modeling and Process：STAMP）がある。STAMPは、米国の航空機衝突防止システム（TCAS II）に適用され、極めてうまく適合した検証結果がある。STAMPは、カナダの水道汚事故にも適用され従来からの故障の木解析（Fault Tree Analysis: FTA）よりも幅広く解析ができることを示している。STAMPの課題としては情報をわかりやすく記録できるフォーマットや、システム設計の中のシミュレーション、解析結果ともリンクしてやり取りができるツール化が期待される。
宇宙におけるすべての事故には組織要因が関係するため、事故防止には組織要因の果たす役割の理解が必須である。それについて従来の研究で主流となっている、通常事故理論（Normal Accident Theory:NAT）と高信頼性組織理論(High Reliability Organization Theory:HRO）の長所・短所を分析しシステム安全の改善を提案されている。高信頼性理論では信頼性文化を論じる視点でオペレータが高い信頼性で運用していれば事故はないと主張する。実証として、複雑なシステムでは、すべての部品が無故障で完璧に作動していても部品相互の影響から事故に至ることがあり、NASA の火星着陸衛星の搭載ソフトウェアに起因した事故がその例。システム安全では、 事故防止の安全要求設定が重要であるが、 その安全要求を入れてシステムを設計する際には、不適切なコンポーネントの動きをどの様に防御して安全を確保するかが必要。更に開発過程では組織内外からの要求で安全技術要求を変更することが多いが、その変更回数と安全リスク増減の関連について考察を加えない点が、今後のシステム安全の課題と認識されている。
2003年のスペースシャトル・コロンビア号事故について事故究明委員会の勧告にあるNASA組織の再構成に必要な要因について研究されており、組織構造、組織のサブシステム、意志疎通、リーダーシップ、情報システム、能力開発、 動機付けの維持等に焦点があてられている。その結果 チャレンジャー事故からコロンビア事故の間にシステム安全は発展せず、むしろ形骸化が進んでいると結論付けられた。その実例として重要な技術会議にシステム安全のエンジニアは出席していないなど、あげて組織の問題であると断じている。能力開発面でもNASAのリーダー達は全員、システム安全の思想について講師になれるまで研鑽することが必須であり、更にはシステム安全の情報・データを組織知として活用すべきであると指摘。更に2012年までに主要メーカの20～30％の熟練エンジニアが定年を迎える事から人材育成も欠かせない重要な視点である。
最近の衛星、ロケットの事故に共通の要因として安全文化、マネージメント、組織、技術力不足を識別できる。それらの要因を更に細分化すると、ソフトウェアリスクについての独断や軽視、責任分担の混同、コミュニケーション不足、ソフトウェア技術不足、システマティックな考え方の欠如、不十分な設計審査と安全審査、形骸化しているシステム安全が列記される。具体的にアリアン５型１号機、NASAの火星探査衛星及び火星着陸衛星、タイタン・セントールロケット、NASAの太陽観測衛星の事故を題材として、安全文化、マネージメントと組織及びソフトウェア技術についても分析した結果、システム安全には、過去の事故から学んで修正すべきことがあり、同時にソフトウェア開発も変わるべき要因があるとの指摘は傾聴に値する。
安全文化は、物理現象の様にモデル化して解析できるという仮説を立てられる。それを NASAに当てはめモデルを構築している。そのモデル構築に前述のSTAMPベースのハザード解析を使った結果、 国の政策が変わるとNASA の安全文化が持っているリスクはどう変化するかも表すことができ、更にそのリスクが許容できないほど大きくなった時にその根本原因まで識別が可能になったと言う。その実例としてスペースシャトル打上げ確率に及ぼす要因をシステム安全のリソース、システム安全の現状、失敗事例からの教訓、技術的リスク、システム安全の努力と効果、シャトル機体の老朽化と保全、要員のシステム安全に関する知識と技量、 高度なマネージメントに分類し因果関係までモデルで詳細に説明した研究が存在し、この研究の結論は、宇宙開発のリスクを減らすには、高い地位で高度な技量を持ち安全について決定できる人材、安全部門の権力と権威、問題を的確に分析してレポートできる能力などの要因を改善する必要があり、 更にそれらの諸方策を偏りなく評価できる能力も必要としている。スペースシャトル打上げについて組織要因、システム安全まで含めた総合的に因果関係をモデルで説明できるSTAMPベースのハザード解析は有効である。
