XDDPにおけるデグレード防止効果を高めるための手法 - IPA2015 Azbil Corporation All Rights Reserved. XDDPにおけるデグレード防止効果を高めるための手法

2015 Azbil Corporation All Rights Reserved.

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

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

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

アズビル株式会社関野浩之

2015 Azbil Corporation All Rights Reserved. 2

メンバーの紹介

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

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

リーダー関野浩之アズビル株式会社（★発表者）

大坪智治株式会社インテック

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

・開発案件のほとんどが派生開発（組み込み系：1社、エンタープライズ系：2社）・当時、XDDPの導入を検討中（1社は試行中）

メンバーの特徴


目次

[解説]XDDPとは

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

2. 適用した手法

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

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


[解説]XDDPとは

XDDP（eXtreme Derivative Development Process）とは清水吉男氏が提唱した派生開発に特化したプロセスモデル

変更を表現する視点の異なる成果物（3点セット）

変更要求仕様書、トレーサビリティ・マトリクス、変更設計書

↓トレーサビリティマトリクス

↓変更要求仕様書 D1 D2 A B C D E F G

要求 XX5

理由

要求 5.1 計測レンジを○○から□□に変更する。

理由・・・・・

要求 5.2 計測周期をA(ms)からB(ms)に変更する。

理由・・・・・

要求 5.3 計測値のデータ範囲を○○から□□に変更する。

理由・・・・・

文章ソース／タスク

センサーの計測範囲を○○から□□に変更する。

△△の計測用途に利用できるようにするため。

変更設計書変更設計書

変更設計書「何を」「どのように」変更するのかを記述

「どこを」変更するのかを記述

「どうやって」変更するのかを記述

担当者の思い込みや勘違いを低減するレビューの効果を引き出し、

不具合の作り込みを防ぐ手法


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

背景

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

熟練技術者が不在となることで影響箇所の見極めを誤り、変更箇所の故障や既存箇所の故障（デグレード）が繰り返し発生

XDDPを導入すれば、大幅な改善が期待

変更箇所の故障：効果あり

既存箇所の故障（デグレード）：熟練技術者と非熟練技術者で効果が異なる

知識・スキルを埋めるもの⇒チェックリストチェック内容：具体的過ぎ抽象的過ぎ、チェック項目数：膨大

非熟練技術者が容易かつ効果的に使えるものにはなっていない

知識・スキルの差



目的と狙い

目的

狙い

非熟練技術者がチェックリストから「知識・スキル不足を埋める過去の教訓」を容易かつ効果的に探し出し利用するしくみを考案

「XDDPによる不具合防止効果」と「チェックリストによる不具合防止効果」の融合

知識・スキル不足を埋める過去の教訓

レビューの効果を引き出す成果物

XDDP チェックリスト両者を

容易かつ効果的に紐づける手法

を研究


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

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

変更箇所の故障(20件)

48%

既存箇所の故障(22件)

52%

「変更箇所の故障」と「既存箇所の故障（デグレード）」が半々を占める


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

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

シミュレーションの目的 XDDPを適用することで不具合防止できるのかを把握

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

シミュレーションのパラメータ（熟練技術者／非熟練技術者）知識・スキルの有無が不具合防止にどのように影響するのかを把握

不具合要因思い込みや勘違いを低減するしくみ

要求や仕様の勘違い「変更要求仕様書」のレビュー

仕様レベルでの変更場所の特定の勘違い「トレーサビリティ・マトリックス」のレビュー

ソースレベルでの変更場所特定や変更方法の勘違い「変更設計書」のレビュー

熟練技術者と非熟練技術者の知識・スキル熟技術練者非熟練技術者

ITSS/ETSSのレベル 4 4～3

ソースコード読解力（アーキテクチャ読解力）十分十分

当該製品の開発経験十分不十分

ソースコードレベルの製品知識十分不十分

当該製品を利用する顧客側の業務・運用の知識十分不十分

当該製品のハードウェア・ソフトウェアの知識十分不十分



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

89%

42%

80%

15%

11%

58%

20%

85%

0%

20%

40%

60%

80%

100%

熟練技術者非熟練技術者熟練技術者非熟練技術者

変更箇所の故障既存箇所の故障

（デグレード）

XDDPで防止不可

XDDPで防止可

非熟練技術者の既存箇所の故障（デグレード）防止には、ＸＤＤＰを適用するだけでなく、何らかの工夫が必要

変更箇所の故障⇒十分な効果を得られる既存箇所の故障（デグレード）⇒十分な効果を得られない



既存箇所の故障（デグレード）事例と熟練技術者の持つ知識・スキルの関係

依存する依存しない



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

熟練技術者が持つ、デグレード防止に必要な知識・スキルをデグレード事例の作り込み要因から抽出

デグレード防止に必要だった知識・スキル

熟練技術者

非熟練技術者

①業務・運用に関する知識（画面操作など）

十分（暗黙知）

不十分

②スペックアウト方法の知識（調査場所，調査方法など）


不十分

③データに関する知識（データ構造，データ範囲など）


不十分

④制御に関する知識（関数呼び出し，イベント/タスクの流れ，データの排他制御など）


不十分

⑤非機能要求の知識（リソース，パフォーマンスなど）


不十分

⑥動作環境に関する知識（OS，ミドルウェアなど）


不十分

いずれもソースコードを読み込むだけでは得られない知識



熟練技術者の持つ知識・スキルをどこから獲得するのか

各組織が過去の教訓を蓄積したチェックリストは、熟練技術者の持つ知識・スキル（暗黙知）を形式知化したもの

チェックリストを活用するには課題あり①莫大なチェック項目の中から必要なチェック項目を効率的に探し出す②チェック項目の抽象度が高すぎると、非熟練者は変更内容に関わるチェック項目を自分で探し出せない

XDDPと組み合わせて既存チェックリストの課題を解決するしくみ『気づきナビ』の考案

非熟練技術者が既存チェックリストからチェック項目（過去の教訓）を容易かつ効果的に探し出し利用するしくみが必要


2.適用した手法

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

既存チェックリストの課題（莫大なチェック項目の中から必要なチェック項目を効率的に探し出す）

を解決するためには何が必要か？

派生開発の中で発生する変更仕様とそれに関係したチェック項目を結びつけるためのキーワードがあれば課題を解決できる

「変更仕様の中から“変更する”という行為を一般化したキーワード（変更特性）」で変更仕様とチェック項目を結びつける

「○○タスクに××データを読み出し、△△を計算し、□□データを書き出しする．」変更特性の抽出

「××データの読み出し処理追加」、「△△計算処理追加」、「□□データの書き出し処理追加」

変更特性例



気づきナビのしくみ

変更特性Ａ

不具合防止の教訓

変更仕様Ａ

変更仕様

変更要求仕様書から変更特性を抽出

（変更特性マトリックス）

変更仕様と不具合防止の教訓（チェック項目）を変更特性で「紐づけ」することによって既存チェックリストの課題を解決する⇒非熟練技術者でも既存チェックリストからチェック項目（過去の教訓）を

容易かつ効果的に引き出し利用できる

既存チェックリストに変更特性を追加、変更特性で整理

（変更特性チェックリスト）

変更特性Ｂ変更仕様Ｂ

・・・・・

・・・・・

変更特性Ａ

変更特性Ｂ

変更特性Ｃ

“変更する”という行為を簡潔なキーワード（「何を」「どのように」変更したのか）で一般化




紐づけ

紐づけ



変更特性マトリクス

変更要求仕様書・変更仕様について「何を」「どのように」変更するのかを記述する．

変更特性マトリクス・変更特性チェックリストから抽出した変更特性を記述する．

・変更特性（「何を」「どのように」変更したのか）の「何を」が同じものは同じカテゴリにする．



変更特性チェックリスト

項目内容

不具合事例 Bタスクの計測処理が規定時間内に完了しないことがあり，計測値がエラーになる．

作りこみ要因 Aタスクに同期待ち（ループによるフラグ確認）のある関数f( )の呼び出しを追加したところ，Aタスク実行中にBタスクが動作できなくなったため．

チェック項目タスクに同期待ち（ループによるフラグ確認）処理がある場合，タスクの処理時間が長くなる．タスク処理時間が規定時間を超えていないことを確認する．

抽象度分類変更特性目的チェック項目

低い↓↓↓↓↓↓↓↓↓↓高い

製品固有

（製品○○に）関数f( )の呼び出し追加⇒変更特性追加

タスク処理の同期待ちが長くなることで，システム動作のパフォーマンスが劣化することを防止するため．

関数f( )はループによるフラグ確認があるため，関数f( )の呼び出しを追加するとタスクの処理時間は長くなる．タスク処理時間が規定時間を超えていないことを確認する．

（同期待ちのある）

関数呼び出し追加

タスクに同期待ち処理（ループによるフラグ確認）がある場合，タスクの処理時間が長くなる．タスク処理時間が規定時間を超えていないことを確認する．

製品間で共通

データの読み出し処理追加⇒変更特性追加

データの読み出しの影響で，タスクの処理時間が長くなる．タスク処理時間が規定時間を超えていないことを確認する．

不具合報告書

変更特性チェックリスト

①「変更特性」は不具合報告書から抜き出し，“変更する”行為の抽象度に応じて「製品固有」と「製品間で共通」を準備する．

② 不具合防止の目的が同じものは「チェック項目」を同じにする．


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

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

1. 気づきナビにより、たどり着いたチェック項目から、デグレード防止に有効な情報を得られることを検証（シミュレーション）

⇒22事例中、13事例においてデグレード防止に効果的であった

1. 気づきナビにより、確認が必要なチェック項目の数が少なくできることを検証⇒確認するチェック項目数が気づきナビ導入前に比べて約17％少なくなった

2. 気づきナビにより、非熟練技術者が熟練技術者と同じチェック項目を抽出できることを検証⇒熟練技術者と非熟練技術者でほぼ同じチェック項目を抽出できた

3. 気づきナビにより、非熟練技術者が新たな欠陥に気づくことを検証⇒非熟練技術者が見落としがちな異常処理の抜け（のべ5件）に気づくことができた

チェックリストの課題を解決していることと、非熟練技術者でもＸＤＤＰのデグレード防止効果を高められることが確認できた

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

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



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

既存箇所の故障（デグレード）の問題に限らず、変更箇所の故障といった他の問題に関しても、多くの気づきがあることがわかった

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

変更仕様チェック項目（過去の教訓）

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

変更箇所の故障

本質

効果測定からの気づき



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

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

技術者同士が同じ不具合を経験することで、不具合防止の暗黙知を共有する

熟練者の持つ不具合防止の暗黙知を気づきナビに形式知として蓄積する

非熟練者は気づきナビの知識を利用することで、熟練者の持つ不具合防止の暗黙知や組織の持つ形式知を体得する

組織の持つ形式知（不具合報告書、チェックリストなど）と組み合わせ、新たな形式知として蓄積する→気づいていない知識が新たに出てくる

表出化

連結化

共同化

内面化

形式知『気づきナビ』

暗黙知

形式知『気づきナビ』

暗黙知


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

取り組みと結果 XDDPを気づきナビで補強することで、導入負荷を抑えつつ、非熟練

技術者によるデグレード防止効果を向上できた。

「変更特性マトリックス」と「変更特性チェックリスト」の作成方法とメンテナンス方法を示した。これらにより、「変更特性マトリックス」と「変更特性チェックリスト」の双方の整合性を保ちながらの運用が可能になった。

『気づきナビ』に蓄積されている知識を組織的に利用し、共有化→形式化→連結化→内面化のサイクルを繰り返せば、熟練技術者が気づいていない知識が新たに出てきたり、技術者同士の共通の体験が生まれるため、さらに効果的なものになると考えられる。

今後の課題気づきナビの不具合防止効果の実証実験

気づきナビの不具合防止効果向上に向けた研究

変更特性の効果的な定義（整理）方法

不具合報告書、チェックリストの効果的な記述方法


ご清聴ありがとうございました

Documents

XDDPにおける デグレード防止効果を高めるための手法 - IPA2015 Azbil Corporation All Rights Reserved. XDDPにおける デグレード防止効果を高めるための手法

XDDPにおけるデグレード防止効果を高めるための手法 - IPA2015 Azbil Corporation All Rights Reserved. XDDPにおけるデグレード防止効果を高めるための手法