メンバーの紹介 日本科学技術連盟ソフトウェア品質管理研究会 2010 年度第 6 分科会 B グループ リーダー関野浩之 アズビル株式会社 ( 発表者 ) 大坪智治 株式会社インテック 外谷地茂 キヤノンITソリューションズ株式会社 メンバーの特徴 開発案件のほとんどが派生開発 ( 組み込み系 :1

XDDPにおける

デグレード防止効果を高めるための手法

～『気づきナビ』の考案～

2015/11/18(水) @ET2015横浜

アズビル株式会社

関野 浩之

メンバーの紹介

日本科学技術連盟 ソフトウェア品質管理研究会

2010年度 第6分科会 Bグループ

リーダー 関野 浩之

アズビル株式会社（★発表者）

大坪 智治

株式会社インテック

外谷地 茂

キヤノンＩＴソリューションズ株式会社

・開発案件のほとんどが派生開発

（組み込み系：1社、エンタープライズ系：2社）

・当時、XDDPの導入を検討中

（1社は試行中）

メンバーの特徴

目次

[解説]

XDDPとは

1.

手法の導入に踏み切った動機や経緯

2.

適用した手法

3.

効果測定の方法とその結果

4.

取り組み結果と今後の課題

[解説]XDDPとは



XDDP（e

X

treme

D

erivative

D

evelopment

P

rocess）とは

 清水吉男氏が提唱した派生開発に特化したプロセスモデル  変更を表現する視点の異なる成果物（3点セット）  変更要求仕様書、トレーサビリティ・マトリクス、変更設計書 ↓ト レー サビリテ ィマト リク ス ↓変更要求仕様書 D1 D2 A B C D E F G 要求 XX5 理由 要求 5.1 計測レンジを○○から□□に変更する。 理由 ・・・・・ 要求 5.2 計測周期をA(ms)からB(ms)に変更する。 理由 ・・・・・ 要求 5.3 計測値のデータ範囲を○○から□□に変更する。 理由 ・・・・・ 文章 ソース／タスク センサーの計測範囲を○○から□□に変更する。 △△の計測用途に利用できるようにするため。 変更設計書 変更設計書 変更設計書 「何を」「どのように」変更するのかを記述 「どこを」変更するのかを記述 「どうやって」 変更するのかを記述 担当者の思い込みや勘違いを低減するレビューの効果を引き出し、 不具合の作り込みを防ぐ手法

1.手法の導入に踏み切った理由や経緯

背景



派生開発における現場の悩み

熟練技術者が不在となることで影響箇所の見極めを誤り、 変更箇所の故障や既存箇所の故障（デグレード）が繰り返し発生 XDDPを導入すれば、大幅な改善が期待 変更箇所の故障：効果あり 既存箇所の故障（デグレード）：熟練技術者と非熟練技術者で効果が異なる 知識・スキルを埋めるもの⇒チェックリスト チェック内容：具体的過ぎ抽象的過ぎ、チェック項目数：膨大 非熟練技術者が容易かつ効果的に使えるものにはなっていない 知識・スキルの差

1.手法の導入に踏み切った理由や経緯

目的と狙い



目的



狙い

非熟練技術者がチェックリストから「知識・スキル不足を埋める 過去の教訓」を容易かつ効果的に探し出し利用するしくみを考案 「XDDPによる不具合防止効果」と 「チェックリストによる不具合防止効果」の融合 知識・スキル不足を 埋める過去の教訓 レビューの効果を 引き出す成果物 XDDP チェックリスト 両者を 容易かつ効果的 に紐づける手法 を研究

1.手法の導入に踏み切った理由や経緯【現状分析①】

派生開発で発生する不具合

変更箇所の 故障 (20件) 48% 既存箇所の 故障 (22件) 52% 「変更箇所の故障」と「既存箇所の故障（デグレード）」が 半々を占める

1.手法の導入に踏み切った理由や経緯【現状分析②】

ＸＤＤＰによる不具合防止シミュレーション



シミュレーションの目的

 XDDPを適用することで不具合防止できるのかを把握



シミュレーションの判定基準



シミュレーションのパラメータ

（熟練技術者／非熟練技術者）  知識・スキルの有無が不具合防止にどのように影響するのかを把握 不具合要因 思い込みや勘違いを低減するしくみ 要求や仕様の勘違い 「変更要求仕様書」のレビュー 仕様レベルでの変更場所の特定の勘違い 「トレーサビリティ・マトリックス」のレビュー ソースレベルでの変更場所特定や変更方法の勘違い 「変更設計書」のレビュー 熟練技術者と非熟練技術者の知識・スキル 熟技術練者 非熟練技術者 ITSS/ETSSのレベル 4 4～3 ソースコード読解力（アーキテクチャ読解力） 十分 十分 当該製品の開発経験 十分 不十分 ソースコードレベルの製品知識 十分 不十分 当該製品を利用する顧客側の業務・運用の知識 十分 不十分 当該製品のハードウェア・ソフトウェアの知識 十分 不十分

1.手法の導入に踏み切った理由や経緯【現状分析②】

ＸＤＤＰによる不具合防止シミュレーション結果

89% 42% 80% 15% 11% 58% 20% 85% 0% 20% 40% 60% 80% 100% 熟練技術者 非熟練技術者 熟練技術者 非熟練技術者 変更箇所の故障 既存箇所の故障 （デグレード） XDDPで 防止不可 XDDPで 防止可 変更箇所の故障⇒十分な効果を得られる 既存箇所の故障（デグレード）⇒十分な効果を得られない

1.手法の導入に踏み切った理由や経緯【現状分析②】

既存箇所の故障（デグレード）事例と

熟練技術者の持つ知識・スキルの関係

1.手法の導入に踏み切った理由や経緯【現状分析②】

熟練技術者の持つ知識・スキルとは

 熟練技術者が持つ、デグレード防止に必要な知識・スキルを デグレード事例の作り込み要因から抽出 デグレード防止に必要だった 知識・スキル 技術者熟練 非熟練技術者 ①業務・運用に関する知識 （画面操作など） （暗黙知）十分 不十分 ②スペックアウト方法の知識 （調査場所，調査方法など） （暗黙知）十分 不十分 ③データに関する知識 （データ構造，データ範囲など） （暗黙知）十分 不十分 ④制御に関する知識 （関数呼び出し，イベント/タスクの流れ， データの排他制御など） 十分 （暗黙知） 不十分 ⑤非機能要求の知識 （リソース，パフォーマンスなど） （暗黙知）十分 不十分 ⑥動作環境に関する知識 （OS，ミドルウェアなど） （暗黙知）十分 不十分 いずれもソースコードを

1.手法の導入に踏み切った理由や経緯

熟練技術者の持つ知識・スキルを

どこから獲得するのか

各組織が過去の教訓を蓄積したチェックリストは、 熟練技術者の持つ知識・スキル（暗黙知）を形式知化したもの チェックリストを活用するには課題あり ①莫大なチェック項目の中から必要なチェック項目を効率的に探し出す ②チェック項目の抽象度が高すぎると、 非熟練者は変更内容に関わるチェック項目を自分で探し出せない XDDPと組み合わせて既存チェックリストの課題を解決するしくみ 『気づきナビ』 の考案 非熟練技術者が既存チェックリストからチェック項目（過去の教訓）を 容易かつ効果的に探し出し利用するしくみが必要

2.適用した手法

変更仕様とチェック項目を結びつける「変更特性」

既存チェックリストの課題 （莫大なチェック項目の中から必要なチェック項目を効率的に探し出す） を解決するためには何が必要か？ 派生開発の中で発生する変更仕様とそれに関係したチェック項目を 結びつけるためのキーワードがあれば課題を解決できる 「変更仕様の中から“変更する”という行為を一般化したキーワード （変更特性）」で変更仕様とチェック項目を結びつける 「○○タスクに××データを読み出し、△△を計算し、□□データを書き出しする．」 変更特性の抽出 「××データの読み出し処理追加」、「△△計算処理追加」、「□□データの書き出し処理追加」 変更特性例

2.適用した手法

気づきナビのしくみ

変更特性Ａ 不具合防止の教訓 変更仕様Ａ 変更仕様 変更要求仕様書から 変更特性を抽出 （変更特性マトリックス） 変更仕様と不具合防止の教訓（チェック項目）を変更特性で「紐づけ」すること によって既存チェックリストの課題を解決する ⇒非熟練技術者でも既存チェックリストからチェック項目（過去の教訓）を 容易かつ効果的に引き出し利用できる 既存チェックリストに 変更特性を追加、変更特性で整理 （変更特性チェックリスト） 変更特性Ｂ 変更仕様Ｂ ・・・・・ ・・・・・ 変更特性Ａ 変更特性Ｂ 変更特性Ｃ “変更する”という行為を簡潔なキー ワード（「何を」「どのように」変更した のか）で一般化 不具合防止の教訓 不具合防止の教訓 不具合防止の教訓 紐づけ 紐づけ

2.適用した手法

変更特性マトリクス

変更要求仕様書 ・変更仕様について「何を」「どのように」 変更するのかを記述する． 変更特性マトリクス ・変更特性チェックリストから抽出した変更特性 を記述する． ・変更特性（「何を」「どのように」変更したのか）の 「何を」が同じものは同じカテゴリにする．

2.適用した手法

変更特性チェックリスト

項目 内容 不具合事例 Bタスクの計測処理が規定時間内に完了しないことがあり，計測値がエラーになる． 作りこみ要因 Aタスクに同期待ち（ループによるフラグ確認）のある関数f( )の呼び出しを追加したところ，Aタ スク実行中にBタスクが動作できなくなったため． チェック項目 タスクに同期待ち（ループによるフラグ確認）処理がある場合，タスクの処理時間が長くなる． タスク処理時間が規定時間を超えていないことを確認する． 抽象度 分類 変更特性 目的 チェック項目 低い ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ 高い 製 品 固 有 （製品○○に） 関数f( )の 呼び出し追加 ⇒変更特性追加 タスク処理の同期待 ちが長くなることで， システム動作のパ フォーマンスが劣化 することを防止する ため． 関数f( )はループによるフラグ確認があるため， 関数f( )の呼び出しを追加するとタスクの処理 時間は長くなる．タスク処理時間が規定時間を 超えていないことを確認する． （同期待ち のある） 関数 呼び出し追加 タスクに同期待ち処理（ループによるフラグ確 認）がある場合，タスクの処理時間が長くなる． タスク処理時間が規定時間を超えていないこと を確認する． 製品 間で データの読み出し処理追加 データの読み出しの影響で，タスクの処理時間が長くなる．タスク処理時間が規定時間を超え 不具合報告書 変更特性 チェックリスト ①「変更特性」は不具合報告書から抜き出し， “変更する”行為の抽象度に応じて「製品固有」と「製品間で共通」を準備する． ② 不具合防止の目的が同じものは「チェック項目」を同じにする．

3.効果測定の方法とその結果

効果測定の方法とその結果

1. 気づきナビにより、たどり着いたチェック項目から、デグレード防止に有効な情報を 得られることを検証（シミュレーション） ⇒22事例中、13事例においてデグレード防止に効果的であった 1. 気づきナビにより、確認が必要なチェック項目の数が少なくできることを検証 ⇒確認するチェック項目数が気づきナビ導入前に比べて約17％少なくなった 2. 気づきナビにより、非熟練技術者が熟練技術者と同じチェック項目を抽出できること を検証 ⇒熟練技術者と非熟練技術者でほぼ同じチェック項目を抽出できた 3. 気づきナビにより、非熟練技術者が新たな欠陥に気づくことを検証 ⇒非熟練技術者が見落としがちな異常処理の抜け（のべ5件）に気づくことができた チェックリストの課題を解決していることと、非熟練技術者でもＸＤＤＰのデグ

測定①：デグレード事例に対するシミュレーション

測定②：XDDPを導入したプロジェクトでの試行

3.効果測定の方法とその結果

効果測定の結果に対する考察

既存箇所の故障（デグレード）の問題に限らず、変更箇所の故障といった他の 問題に関しても、多くの気づきがあることがわかった 気づきナビの本質は、変更仕様とチェック項目（過去の教訓）の紐付けにある ため、変更特性と過去の教訓次第で、既存箇所の故障（デグレード）以外の 問題にも効果を発揮することが期待される 変更仕様 チェック項目 （過去の教訓） 既存箇所の故障 （デグレード） 変更箇所の故障 本質

効果測定からの気づき

3.効果測定の方法とその結果

効果測定の結果に対する考察



ナレッジマネージメントとしての『気づきナビ』

技術者同士が同じ不具合を経験することで、 不具合防止の暗黙知を共有する 熟練者の持つ不具合防止の暗黙知を気づき ナビに形式知として蓄積する 非熟練者は気づきナビの知識を利用するこ とで、熟練者の持つ不具合防止の暗黙知や 組織の持つ形式知を体得する 組織の持つ形式知（不具合報告書、チェック リストなど）と組み合わせ、新たな形式知とし て蓄積する →気づいていない知識が新たに出てくる

表出化

連結化

共同化

内面化

形式知 『気づきナビ』 暗黙知 形式知 『気づきナビ』 暗黙知

4.取り組み結果と今後の課題



取り組みと結果

 XDDPを気づきナビで補強することで、導入負荷を抑えつつ、非熟練 技術者によるデグレード防止効果を向上できた。  「変更特性マトリックス」と「変更特性チェックリスト」の作成方法とメ ンテナンス方法を示した。これらにより、「変更特性マトリックス」と 「変更特性チェックリスト」の双方の整合性を保ちながらの運用が可 能になった。  『気づきナビ』に蓄積されている知識を組織的に利用し、共有化→形 式化→連結化→内面化のサイクルを繰り返せば、熟練技術者が気 づいていない知識が新たに出てきたり、技術者同士の共通の体験 が生まれるため、さらに効果的なものになると考えられる。



今後の課題

 気づきナビの不具合防止効果の実証実験  気づきナビの不具合防止効果向上に向けた研究  変更特性の効果的な定義（整理）方法  不具合報告書、チェックリストの効果的な記述方法