本セッションの流れ
（1）IV&V技術継承問題【30分】 （2）IV&Vトレーニングの開発～技術者を育てるのは難しい～ （大久保梨思子/JAXA）【20分】 （3）宇宙飛行士訓練開発手法を適用したIV&Vトレーニング （奈良和春氏/有人宇宙システム株式会社) 【40分】①課題
②方策
（教育）
③設計
（教育）
教育による解決 ・IV&Vとは？ ・IV&Vは何が難しい？ ・技術継承でどんな問題？ ・どんなモデルで解決？ （教育の前提） ・教育以外の解決方策IV&Vとは？
3
“Independent Verification and Validation (IV&V) is the activity of verifying and
validating software as conducted by an organization that is technically,
managerially, and financially independent from the development organization.”
Lewis, Robert O. ”Independent verification and validation: A life cycle engineering process for quality software.” Vol. 11. JohnWiley & Sons,1992.
プロダクトに確信を得るためのセカンドオピニオン
プロダクト発注者 （IV&V発注者） V&V提供者 (プロダクト開発者) V&V結果 品質保証活動 IV&V提供者 IV&V結果 (セカンドオピニオン) プロダクトの品質に対する 確信度の向上 プロダクトの品質に対する 確信度の向上なぜIV&Vが必要？
E.W. Dijkstra, The Humble Programmer, 1972
But: program testing can be a very effective way to show the presence of bugs, but it hopelessly inadequate for showing their absence.
なぜIV&Vが必要？
なぜIV&Vが必要？
より異なる評価軸から
多角的に品質観測量を増やし
品質推定精度を上げるしかない
確信度 （確率密度） 品質（信頼度確率） 客観評価により 観測量を増やす 許容品質下限IV&Vは何が難しい？
7異なる評価軸を探し続けないといけない
・開発組織に対して限られた人的リソース（JAXAの場合数%程度）
・その前提で、日々そのプロダクトを見ている人達が見れていない/
上回る大事な評価軸を短時間で発想しなければいけない
JAXAにおけるIV&V
プロジェクトチーム (IV&V発注者) S&MA （品質保証部門） 研究開発部門 (IV&V提供者) システムサプライヤ (SW開発者/V&V提供者) IV&V支援企業 (IV&V提供者) IV&Vを含めたソフトウェア開発プロセス規定 IV&V要請 部分アウトソース（従来） システム調達JAXAにおけるIV&V
9 萌芽期 1990s～2007 発展期 2008～2014 成熟期 2015～2017 対象数：少（3装置/年程度） IV&V技術者：少数精鋭 対象数：中（5装置/年程度） IV&V技術者：若年層へ世代交代 対象システム数：多（8装置/年～） IV&V技術者：技術者数不足 ひとみ異常事象→IV&V義務化 [1] Okubo et al., Transition of Independent Verification and Validation Activity and Refined Concept at the Mature Age, ISTS2017JAXAにおけるIV&V技術継承問題
萌芽期 1990s～2007 発展期 2008～2014 成熟期 2015～2017 メーカ検証後の残留不具合要因 単純～複雑 単純～複雑 複雑 （例：過渡的挙動で発生する問題） JAXA IV&V 対象プロジェクト数 少 （3つ/年程度） 中 （5つ/年程度） 多 （8つ/年程度） 実施者 少数の 経験豊富な技術者 経験の浅い技術者 への世代交代や増加 左記＋人的リソース不足多発 検証の質 個人能力依存 で「高」 個人能力依存で「低」： 経験浅く、対象数も増え、 文書間整合性確認が主 同左 検証 効果 効果発揮 （例：システム影響大 問題） 効果維持 ※単純要因は整合性確認でも検 知可能な場合が多いため（例：要 求に対する設計漏れ） 効果低下 → プロジェクト期待との乖離 「経験の浅い」技術者 設計情報 一般論 教科書等 （例：文書間整合性、 分岐網羅、抽象的すぎ るチェックリスト/Lessons Learned等） ？ 一般論 検証 （例：文書 間整合性 チェック） 単純な誤り 複雑な誤り 網作成 道具 狙いが定まってい ないため単純な誤 りしか防げないJAXAにおけるIV&V技術継承問題
11 プロセス 品質 プロダクト 品質 （内部/外 部品質） 利用時 品質 影響 依存 依存 利用文脈 プロセス定義、 中間プロダクト JAXA プロジェクトチーム （IV&V発注者） 主関心事項 発展期 IV&V 影響 トレサビリティエラー 誤記、抜け等 （プロセスリスク） 利用しても問題ないことの 確信を得たい ソフトウェアプロダクトの設 計が〇となっていることから このシステムは〇のような 際に〇の状態となるリスク がある（プロダクトリスク） 期待されるIV&V JAXA プロセスアセッサJAXAにおけるIV&V技術継承問題
如何に開発者と異なる検証観点を発想できるか → 視野が仕様範囲内では開発者とのダブルチェックにすぎない （=品質推定精度は向上しない or 開発者リソースを足しているのみ） → 視野の入口は仕様ではないところに置く必要性 例）失敗経験、システムの製品特徴を踏まえ導出されるリスク 検証結果は、如何に強い懸念と紐づいているか → 誤記、処理・状態の定義漏れなど表面事象のみ見つけたところで 実質的に製品品質に寄与しないかもしれない（保守性除く）。 よって具体的問題発生時影響と問題発生可能性を語れなければ コスト投入価値はない（IV&V文化醸成の阻害要因にもなる）。 逆にそれが語れなければ問題がなかった場合に 何が大丈夫であることが確認されたのか誰にも分からない。 （=品質観測量が追加されない）IV&V技術継承問題を踏まえてのIV&Vで大事なこと
→ 経験の浅い技術者には上記は容易ではないため プロダクトリスクではなくプロセスリスクへ流れる 独立評価リソースはとても高コス ト（オーバーヘッド率が高） なのに独立性を活かせていない 高コストなのに 投資効果を感じられない。IV&V技術継承問題
13 IV&Vの難しさ（＝価値）である 異なる評価軸の探索のすべてが個人能力依存 IV&Vはエンジニアリング活動なのに 自身の活動にエンジニアリングが入っていない IV&Vへのエンジニアリングの導入問題の解決方策
(a)経験知のモデル化 GSN（ゴール構造表記法）を 拡張し、検証戦略を 可視化・再利用可能化 （b）プロセス化 IV&V作業を 約300工程に分解定義し 平準化・フィードバック容易化 （c）教育プログラム化 教育工学+SW工学で 持続的に見直しできるよう設計し た「教材」、「能力試験」 JAXA出版 IV&Vガイドブック 第4版 2017年3月 導入編55頁 実践編550頁 対象システム 実施計画書 指摘表 IV&Vプロセス （ガイドブックで規定） 運⽤シナリオ 故障解析書 設計仕様書 SW開発成果物 SW上位仕様 分析エビデンス 同種システム 同種ソフトウェアの 不具合情報 システム分析結果 主な中間成果物 システム設計書 要求仕様書 評価報告書 リスク導出経緯 ⾻⼦ 検証 戦略 リスク 試験仕様書 リスク導出経緯 検証 結果 ソースコード ・・ ・ ・・・ 評価準備（PR) 実施検討（PL) リスク抽出（RK) 要求評価（RV) 設計評価（DV) コード評価（CV) 試験評価（TV) 評価報告（RP) 蓄積改善（CA) 計画合意形成資料 検証戦略⾻⼦ リスク導出 検証戦略 IV&V活動⽬的 SWリスク 観点設定 根拠 システム 仕様 リスク導出 観点 検証結果 検証⽬的 検証観点 検証項⽬ システム仕様 観点設定 根拠 ① 組織力を活かす 若年層へ世代交代で、質が低下す る状況において、経験知をモデル化 し、個人技から組織・チームでアイデ アを出しあえるようにし、熟練者の経 験知を活かせるようにする。 ②：サイクル数を活かす 対象システム数の増加を、上記仕 組みで逆にフィードバック機会が多数 存在する場として活かし、現場で実際 に使える技術へ精錬させる。 今秋ライセンス提供開始 詳しくはこの後の講演にて 今秋ライセンス提供開始 詳しくはこの後の講演にてIV&Vにおける「プロセス化」
15 実施計画の検討 評価作業 （何をどのように 確認するかは主に 評価者能力依存） 問題点の提示 例：上位文書と下位文書の 「整合性」を確認します プロジェクト▲ 合意 旧IV&V（発展期） 後段の試験で問題が起こっても 何がまずかったのか分析不能 （技術前進不能状態） プロセス リスクの合意 旧IV&V 付随問題 プロジェクト▲ 報告 新IV&V ①入口は仕様ではないところに置く （システム特徴/失敗経験踏まえたプロダクトリスク） ②評価軸がIV&Vの価値を支配するため なぜ何を検証するかを重視・繰り返す（フロントロード） 検証戦略立案 リスク分析 検証結果 （問題点の提示、 未検証がどこか） 事後不具合 発生時分析 評価作業 何を どうやって プロセス見直し 内部 イタレーション なぜ 検証戦略対比 プロダクト リスクの合意 プロジェクト▲ 報告 プロジェクト▲ 合意 例：○が発生する リスクを低減します。IV&Vにおける「経験知のモデル化」
組織・チームでアイデアを出しあえるよう 熟練者の経験知を活かせるよう 頭の中を吐き出す ②手段導出「視点」 ・目的をどういう切り口で捉え 達成しようとしているのか ①目的/手段「論理構造」 ・何のために何をやるのか ・どの範囲が検証されるのか ③「根拠」 ・なぜその視点や手段が妥当で あるといえるのか ・どういう前提をおいているのか 思考過程の構造化IV&Vにおける「経験知のモデル化」
17 G0： 確認内容 C1：確認項 目が有効で ある前提 S0：確認内容に対 し確認項目が網羅 的である視点 G1： 確認項目 G2： 確認項目 C0：確認内容の根拠 確認内容が対応してい る懸念事項を記述する。 E：確認 結果 ①視点を明記して 網羅性を確保 ②前提が有効であるか確 認できるため、有効な確認 項目のみ選定できる。 ③確認項目の背景や 意図を各階層で記述 ④抽象から具象まで確認 項目をツリー形式で積み上 げることが可能。 ⑤利用者が確認できたのかどう か、記録することができる。 GSN（ゴール構造表記法）を応用しモデル化IV&Vにおける「経験知のモデル化」
リスク分析 検証戦略 IV&V保証事項 （SWリスク低減） SWリスク （SW不具合要因） 観点選択の 根拠 システム 仕様情報 評価結果 評価⽬的 観点選択の 根拠 SW仕様情報 システムリスク：電力枯渇（衛星喪失） バッテリ残量が少ない状態での運用中に、万一何らかの 異常が発生し、電力枯渇に至るリスクがないか 軌道制御系サブシステムに異常が生じても軌道高度を引 き上げることをリトライするソフトウェア設計となっていた。 軌道高度を引き上げる動作はその姿勢からさらにバッテ リ残量を低下させてしまう。 電力枯渇回避のため、即座に電力確保を最優先する制 御へ切り替える必要性を発見し対策を打った。 衛星の事例 軌道高度を引き上げる制御を行う際は問題がないか リスク導出 観点 評価観点 評価項⽬ （判定基準）IV&Vにおける「経験知のモデル化」
19本モデル化の直接効果
【効果①】よりよい検証戦略が検討可能
（全員が同じ森が見える、議論文脈局所化等）
【効果②】具体的な検証観点が蓄積可能
【効果③】実行レベルで容易にPDCA
（見逃し不具合発生時に従来分析難）
IV&Vへのエンジニアリング導入前後の比較
システムB 姿勢軌道系 システムC 姿勢軌道制御系 開発企業Ａ エンジニアリングを 入れていないIV&V (= 旧IV&V（発展期）) エンジニアリングを 入れたIV&V (= 新IV&V) 欠陥 欠陥 比較 設計・製造IV&Vへのエンジニアリング導入前後の比較
21 質
工数
検出欠陥数（個） 旧IV&V（発展期） 新IV&V プロダクト品質上の欠陥4
16
プロセス品質上の欠陥41
1
旧IV&V 新IV&V 工数 (人時)744.5
386.25
[2] Kakimoto et al., IV&V Case: Empirical Study of Software Independent Verification and Validation based on Safety Case, ISSRE2017IV&Vへのエンジニアリング導入前後の比較
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%（参考）開発企業ＡによるIV&Vの質の評価
（開発企業側のIV&V対応コストの視点）
旧IV&V 新IV&V 旧IV&V 新IV&V 実際に是正措置が必要となった 指摘の割合（指摘ヒット率） IV&Vから設計者への確認のうち 単なる質問の割合の変化 IV&V検証者側の狙いが 定まっていないため 開発企業にも負担のかかる 無駄の多い検証
IV&Vへのエンジニアリング導入による検証の質と量の推移
23 0 50 100 150 200 250 300 350 400 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 0 10 20 30 40 50 60 70 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 質の推移 （「検証戦略モデル」内の特徴・懸念表現語彙数） 検証の質 2014（エンジニアリング導入前） 量の推移 （「検証戦略モデル」内のノード数） 検証の量 ※上図の各検証に投じている人的リソースは概ね同等であるが 各検証対象ソフトウェアの新規規模、複雑性、環境条件などにばらつきがあるため上図は「長期傾向」としての参考。 量に対して質がバランスしない 不安定な検証 量と質がバランスした 安定的な検証 時期 量と質がバランスした状態で 質が上昇した検証 （SW単位） 高 低 多 少 2015（エンジニアリング導入後1） 2016（エンジニアリング導入後2）24
IV&Vへのエンジニアリング導入による検証の質と量の推移
0.0 50.0 100.0 150.0 200.0 250.0 300.0 350.0 400.0 450.0 500.0 0.0 100.0 200.0 300.0 400.0 500.0 検証 戦 略 メ ト リ ク ス 経験量 相関値：0.937 【質と量の推移の計測方法】 ①「検証の質」=「検証戦略」内の「特徴」表現語彙数＋「懸念」表現語彙数 ・「特徴」=対象プロダクト（設計）における差分情報（他プロダクトや他部位との比較）等 →欠陥(fault)の存在可能性が高いと仮定 ・「懸念」=起こってほしくないこと →保持できれていれば欠陥(fault)が故障(failure)につながる可能性が高いと仮定 ②「検証の量」= 「検証戦略」内のノード数（GSN記法上のゴール数） ・試験でいうと試験ケース数相当 G0: 共有変数に対する競合 に問題がない。 S0: 同期か非同期か に分ける G1: 同期処理（逐次処理） に問題がない。 G2: 非同期処理（割り込み処理） に問題がない。 S2: 優先度高タスクにおける 変数の書きの有無 に分ける G2.1: 割り込むタスクが変数を 書く場合、問題がない。 S2.1: 優先度低タスクの 読み書きパターンに分ける G2.1.1: 共有変数に対し、 ・優先度高タスクが、書き ・優先度低タスクが、読み書き の場合、問題がない。 G2.1.2: 共有変数に対し、 ・優先度高タスクが、書き ・優先度低タスクが、読みのみ の場合、問題がない。 G2.1.3: 共有変数に対し、 ・優先度高タスクが、書き ・優先度低タスクが、書きのみ の場合、問題がない。 G2.2: 割り込むタスクが変数を 書かない 場合、問題がない。 C1: 割り込み禁止（マスク）処 理等で順番が固定含む C2: 【前提確認】 割り込みが発生するタスクは、優先 度低のタスクが実行中に、優先度 高のタスクが起動する場合のみ 例：タスク優先度が同一の場合、SW リスクはない。 F2.2: 優先度が低いタスクが、共有変 数に「書き」を行っている、且つ 優先度が高いタスクが読み込 みしている場合、意図した値に なっているか、確認する必要が ある。 F1: 変数の競合（意図しない上書き 等）は、発生しない。 C0: 【懸念情報】 割り込み関係にあるタスク間 で扱っている共有変数に、競 合（意図しない上書き）が発生 するリスクがある。 C2.1S: 変数に対する競合分析表 （割り込み関係のあるタスクが 扱うグローバル変数を記入） E1: 変数に対する競合分析表 E2: 変数に対する競合分析表 E3: 変数に対する競合分析表 ※「検証戦略」に基づく上記メトリクスと「経験量」（熟練度合）の相関は極めて高い[3] 「検証戦略」 メトリクス値化ここまでの取り組みと最新の取り組み
25 ここまでの取り組み 現在取り組み中 ・データ量が増えると再利用しきれない ・定石再利用ではIV&Vの価値も出し続けられない ・役に立たない情報も混ざっている最新の取り組み – 連結化と内面化
26 異常値を検知した場 合の対処が適切 今サイクル/ 次サイクルに 分解 今サイクルの演算 に使用するデータが 適切 異常値検知は前回値と 比較して行う設計である 次サイクルで比較に使 用する値（前回値）の設 定が適切である。 ： 分析表 ： 分析表業務上のGSN
ｚ 要素 データベース検索サービス
GSN作成者
表による抽出
構造図による分析
分析フレーム ワークマスターGSN分析者
※ツリー型チェックリスト分析＆再利用手法（TARM）（特願2017‐206127）価値ある情報のみデータ化
（プロダクト特徴・懸念）
最新の取り組み – 連結化と内面化
27 異常値を検知した場 合の対処が適切 今サイクル/ 次サイクルに 分解 今サイクルの演算 に使用するデータが 適切 異常値検知は前回値と 比較して行う設計である 次サイクルで比較に使 用する値（前回値）の設 定が適切である。 ： 分析表 ： 分析表業務上のGSN
ｚ 要素 データベース検索サービス
GSN作成者
表による抽出
構造図による分析
分析フレーム ワークマスターGSN分析者
③：暗黙知を形式知へ変換 → GSNを暗に習得 ③：暗黙知を形式知へ変換 → GSNを暗に習得 ①：形式知から暗黙知の生成 → データの再利用 ①：形式知から暗黙知の生成 → データの再利用 ②：新たな形式知の生成 → 能力の計測 ②：新たな形式知の生成 → 能力の計測 ④：暗黙知の習得 → 業務の学習 ④：暗黙知の習得 → 業務の学習 [4]梅田、GSNを応用したナレッジマネジメントシステムの提案, 第11回 D‐Case研究会 ツール・解説書等とセットで ライセンス提供開始予定（2017年12月） ツール・解説書等とセットで ライセンス提供開始予定（2017年12月） ※ツリー型チェックリスト分析＆再利用手法（TARM）（特願2017‐206127）①共同化 （Socialization） ②表出化 （Extermalization） ④内面化 （Intermalization） ③連結化 （Combination）
