IV&V技術継承問題

2017/11/30

植田泰士

JAXA 研究開発部門 第三研究ユニット

ueda.yasushi@jaxa.jp

第15回 WOCSIV&Vセッション

本セッションの流れ

2

（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結果(セカンドオピニオン)

プロダクトの品質に対する確信度の向上

プロダクトの品質に対する確信度の向上

Independent Verification & Validation 独立検証及び妥当性確認

なぜIV&Vが必要？

4

E.W. Dijkstra, The Humble Programmer, 1972But: program testing can be a very effective way to show the presence of bugs, but it hopelessly inadequate for showing their absence.

システムに欠陥が無いことをテストによって完全に保証することは出来ないから

なぜIV&Vが必要？

5

なぜIV&Vが必要？

6

より異なる評価軸から多角的に品質観測量を増やし品質推定精度を上げるしかない

確信度（確率密度）

品質（信頼度確率）

客観評価により観測量を増やす

許容品質下限

IV&Vは何が難しい？

7

異なる評価軸を探し続けないといけない

・開発組織に対して限られた人的リソース（JAXAの場合数%程度）・その前提で、日々そのプロダクトを見ている人達が見れていない/

上回る大事な評価軸を短時間で発想しなければいけない

JAXAにおけるIV&V

8

プロジェクトチーム(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, ISTS2017

JAXAにおけるIV&V技術継承問題

10

萌芽期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技術継承問題

12

如何に開発者と異なる検証観点を発想できるか

→ 視野が仕様範囲内では開発者とのダブルチェックにすぎない

（=品質推定精度は向上しない or 開発者リソースを足しているのみ）

→ 視野の入口は仕様ではないところに置く必要性

例）失敗経験、システムの製品特徴を踏まえ導出されるリスク

検証結果は、如何に強い懸念と紐づいているか

→ 誤記、処理・状態の定義漏れなど表面事象のみ見つけたところで

実質的に製品品質に寄与しないかもしれない（保守性除く）。

よって具体的問題発生時影響と問題発生可能性を語れなければ

コスト投入価値はない（IV&V文化醸成の阻害要因にもなる）。

逆にそれが語れなければ問題がなかった場合に

何が大丈夫であることが確認されたのか誰にも分からない。

（=品質観測量が追加されない）

IV&V技術継承問題を踏まえてのIV&Vで大事なこと

→ 経験の浅い技術者には上記は容易ではないためプロダクトリスクではなくプロセスリスクへ流れる

独立評価リソースはとても高コスト（オーバーヘッド率が高）なのに独立性を活かせていない

高コストなのに投資効果を感じられない。

IV&V技術継承問題

13

IV&Vの難しさ（＝価値）である異なる評価軸の探索のすべてが個人能力依存

IV&Vはエンジニアリング活動なのに自身の活動にエンジニアリングが入っていない

IV&Vへのエンジニアリングの導入

14

問題の解決方策

(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における「経験知のモデル化」

16

組織・チームでアイデアを出しあえるよう熟練者の経験知を活かせるよう

頭の中を吐き出す

②手段導出「視点」・目的をどういう切り口で捉え

達成しようとしているのか

①目的/手段「論理構造」・何のために何をやるのか・どの範囲が検証されるのか

③「根拠」・なぜその視点や手段が妥当で

あるといえるのか・どういう前提をおいているのか

思考過程の構造化

IV&Vにおける「経験知のモデル化」

17

G0：確認内容

C1：確認項

目が有効である前提

S0：確認内容に対

し確認項目が網羅的である視点

G1：確認項目

G2：確認項目

C0：確認内容の根拠

確認内容が対応している懸念事項を記述する。

E：確認結果

①視点を明記して網羅性を確保

②前提が有効であるか確認できるため、有効な確認

項目のみ選定できる。

③確認項目の背景や意図を各階層で記述

④抽象から具象まで確認項目をツリー形式で積み上

げることが可能。

⑤利用者が確認できたのかどうか、記録することができる。

GSN（ゴール構造表記法）を応用しモデル化

IV&Vにおける「経験知のモデル化」

リスク分析

検証戦略

IV&V保証事項（SWリスク低減）

SWリスク（SW不具合要因）

観点選択の根拠

システム仕様情報

評価結果

評価⽬的

観点選択の根拠

SW仕様情報

システムリスク：電力枯渇（衛星喪失）

バッテリ残量が少ない状態での運用中に、万一何らかの異常が発生し、電力枯渇に至るリスクがないか

軌道制御系サブシステムに異常が生じても軌道高度を引き上げることをリトライするソフトウェア設計となっていた。軌道高度を引き上げる動作はその姿勢からさらにバッテリ残量を低下させてしまう。電力枯渇回避のため、即座に電力確保を 優先する制御へ切り替える必要性を発見し対策を打った。

衛星の事例

軌道高度を引き上げる制御を行う際は問題がないか

リスク導出観点

評価観点

評価項⽬（判定基準）

18

IV&Vにおける「経験知のモデル化」

19

本モデル化の直接効果

【効果①】よりよい検証戦略が検討可能（全員が同じ森が見える、議論文脈局所化等）

【効果②】具体的な検証観点が蓄積可能

【効果③】実行レベルで容易にPDCA（見逃し不具合発生時に従来分析難）

IV&Vへのエンジニアリング導入前後の比較

20

システム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, ISSRE2017

IV&Vへのエンジニアリング導入前後の比較

22

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.050.0100.0150.0200.0250.0300.0350.0400.0450.0500.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]梅田他、GSNを活用した技術者能力計測手法の提案, ソフトウェア品質シンポジウム2016

※「検証戦略」に基づく上記メトリクスと「経験量」（熟練度合）の相関は極めて高い[3]

「検証戦略」

メトリクス値化

ここまでの取り組みと最新の取り組み

25

ここまでの取り組み

現在取り組み中

・データ量が増えると再利用しきれない・定石再利用ではIV&Vの価値も出し続けられない・役に立たない情報も混ざっている

新の取り組み – 連結化と内面化

26

異常値を検知した場合の対処が適切

今サイクル/次サイクルに

分解

今サイクルの演算に使用するデータが

適切

異常値検知は前回値と比較して行う設計である

次サイクルで比較に使用する値（前回値）の設

定が適切である。

：

分析表

：

分析表

業務上のGSN

ｚ要素データベース

検索サービス

GSN作成者

表による抽出

構造図による分析

分析フレームワークマスター

GSN分析者

※ツリー型チェックリスト分析＆再利用手法（TARM）（特願2017‐206127）

[4]梅田、GSNを応用したナレッジマネジメントシステムの提案, 第11回 D‐Case研究会

価値ある情報のみデータ化（プロダクト特徴・懸念）

新の取り組み – 連結化と内面化

27

異常値を検知した場合の対処が適切

今サイクル/次サイクルに

分解

今サイクルの演算に使用するデータが

適切

異常値検知は前回値と比較して行う設計である

次サイクルで比較に使用する値（前回値）の設

定が適切である。

：

分析表

：

分析表

業務上のGSN

ｚ要素データベース

検索サービス

GSN作成者

表による抽出

構造図による分析

分析フレームワークマスター

GSN分析者③：暗黙知を形式知へ変換

→ GSNを暗に習得

③：暗黙知を形式知へ変換

→ GSNを暗に習得

①：形式知から暗黙知の生成

→ データの再利用

①：形式知から暗黙知の生成

→ データの再利用

②：新たな形式知の生成

→ 能力の計測

②：新たな形式知の生成

→ 能力の計測

④：暗黙知の習得

→ 業務の学習

④：暗黙知の習得

→ 業務の学習

[4]梅田、GSNを応用したナレッジマネジメントシステムの提案, 第11回 D‐Case研究会

ツール・解説書等とセットでライセンス提供開始予定（2017年12月）ツール・解説書等とセットでライセンス提供開始予定（2017年12月）

※ツリー型チェックリスト分析＆再利用手法（TARM）（特願2017‐206127）

①共同化（Socialization）

②表出化（Extermalization）

④内面化（Intermalization）

③連結化（Combination）

新の取り組み – 連結化と内面化

28

検索サービス

異常値を検知した場合の対処が適切

今サイクル/次サイクルに

分解

今サイクルの演算に使用するデータが

適切

異常値検知は前回値と比較して行う設計である

次サイクルで比較に使用する値（前回値）の設

定が適切である。

：

分析表

：

分析表

業務上のGSN（業務品質の確保、レビューの十分性）

フレームワークを用いた表による抽出

構造図によるフィルタリング

熟練者非熟練者データ生成時に議論

業務時に生成

データ引き出し

新の取り組み – 他領域への応用

29

研究論文作成業務

要求定義業務（設計知見）

テスト設計業務

FMEA適用業務

（FMEA知見）

運用非定常対応業務

（運用知見）

不具合処置業務

（対処知見）

申請書審査業務

IV&V

自組織内活動

他組織活動

業務品質影響力

暗黙知ベースのレビュー業務（知見継承課題）が存在する様々な領域へ応用試行中

まとめ

30

（1）IV&V技術継承問題

（2）IV&Vトレーニングの開発～技術者を育てるのは難しい～（大久保梨思子/JAXA）【20分】

（3）宇宙飛行士訓練開発手法を適用したIV&Vトレーニング（奈良和春氏/有人宇宙システム株式会社) 【40分】

①課題

②方策（教育）

③設計（教育）

教育による解決

・ IV&Vとは？→ プロダクト品質推定精度を高めるための活動・ IV&Vは何が難しい？→ 異なる評価軸を探索し続けること・ 技術継承でどんな問題？→ 上記が個人依存で継承不能・ どんなモデルで解決？→ 検証者の思考過程をモデル化

それを土台としたプロセス化と教育プログラム化・ 教育以外の解決方策→ ナレッジマネージメント（連結化と内面化）