第６分科会 B グループ

派生開発における変更工数の見積精度向上策-「変更依頼仕分けガイド」の提案 Estimate precision improvement plan of change cost in the Derivation Development- Suggestion of the 'Change Request Classification Guide ' 主査
副主査
副主査
リーダー
研究員

：清水 吉男 (株式会社システムクリエイツ)：飯泉 紀子 (株式会社日立ハイテクノロジーズ )：足立 久美 (株式会社デンソー )：蓑島 秀明 (テクニカルジャパン株式会社 )：瀧野 宏一 (TIS 株式会社 )中津留 稔 (アンリツエンジニアリング株式会社 )研究概要
近年,開発工数の実績が見積を超過する派生開発プロジェクトが散見され,経営リスクの一つになっている．工数を超過したプロジェクトの不具合事例を調査したところ,テスト工程で発見された不具合は,設計工程まで手戻りが発生しているケースが多く見られた.これ
らの原因として,顧客からの変更依頼によっては,見積時に考慮されていない 「隠れた要求／仕様」が存在することが分かった．派生開発において,「要求」と「仕様」が混在する変更依頼から「隠れた要求／仕様」を見つけるには,変更依頼から「要求」と「仕様」を適切に見極めることにある.しかしながら,その見極めが担当者の見積経験や当該システムの習熟度に依存する部分が大きいことより,適切に判別できていないのが現状である.
本研究において,この「隠れた要求／仕様」に気付くためのアプローチとして,変更依頼を「要求」と「仕様」に判別するための「変更依頼仕分けガイド（CRCG:Change RequestClassification Guide）」を作成した．このガイドによって,「隠れた要求／仕様」に気付くことができるようになり,見積精度を高めることができる.

Abstract
In recent years, There are a lot of derivation development projects that a development
cost exceeded an estimate cost, and that become one of business risk. We investigated somedeficient cases that had cost beyond the estimate and found out there were many cases thatmalfunction had occurred in test process and to take measures we had had to go back to design
process. The cause of that is existence of 'informal Requirements or Specification' due to lackof consideration in estimate process. It is important to classify whether a change request fromclients in the derivative development is 'Requirements' or 'Specification', and in the latter case,
it is also important in estimate process to consider whether 'informal Requirements orSpecification' exist, but we could say that these classification have been depended on persons
in charge of estimate and it is difficult. In this study, We devised 'CRCG(Change RequestClassification Guide)' for a change request to distinguish 'Requirements' or 'Specification' as
approach to notice 'informal Requirements or Specification'. We get possible to notice'informal Requirements or Specification' by using this guide and can improve with estimate
precision.

11. 研究動機
今日のソフトウェア開発は低コスト,短納期が当たり前となっているのが現状である.その要因として,小規模な派生開発が多いことが理由の一つに挙げられる.小規模な開発だけに,高精度の見積を短期間に行う必要があるのだが,必ずしも当該システムを熟知している経験者（以下,熟練者と称する）が見積を行うとは限らず,熟知していない開発担当者が見積ることも少なくない.この場合,熟練者とは違って見積りに時間が掛かるため,変更依頼に対する変更箇所および影響箇所の見極めが十分に出来ないまま,開発を進めざるを得ない状況があるのが実情である.また,我々研究メンバーの所属するプロジェクトを対象に開発工数の予実を分析したところ,結合テストまたは総合テスト工程において予実の工数乖離が大きいことが分かった.その原因が何処にあるのかを見つけるため,結合テストまたは総合テスト工程で発生した不具合事例に着目して分析した結果,これらの不具合は要求分析や設計工程において,変更箇所や影響範囲の調査・検討不足および仕様漏れが起因するものであり,その対策に多くの手戻りコストが発生していることが分かった.
分析した不具合事例の中には,変更依頼に示された内容を基にプログラムを変更したが,後の結合テストまたは総合テストにおいて,変更した箇所に起因した不具合が他モジュールおよび他システムで発見されたケースがあった.このケースにおける問題点は,顧客からの変更依頼が具体的な内容で示されていたことより,変更箇所が容易に特定できたために,担当者は他にも「変更すべき箇所がある」ことを疑わなかったことで「隠れた仕様」に気付けなかったことにある.
この「隠れた仕様」を見つけ出す手掛かりを得るために先行技術である XDDP[1]を参照した.XDDP によると顧客からのシステムに対する変更依頼には,要求と仕様が混在[2] しているという.変更依頼が「要求」で来た場合,USDM[3]を用いて要求から仕様を導き出すことは可能であるが,「仕様」で来た場合は,その変更依頼に対する背景や理由が書かれていないため,顧客へ変更内容に関する背景や理由を確認した上で,新たに要求を立てる必要がある（図 1.1）.

図 1.1 変更依頼 からの要求 ・仕様分析 イメージ
しかしながら,顧客からの変更依頼が「仕様」で来たものであると,担当者が見極められなければ,“新たに要求を立てる作業”が出来ず,隠れた「要求」もしくは「仕様」に気付く事は困難である.
そこで我々は,顧客からの変更依頼が「要求」または「仕様」であることを見極めるための術を示すことを研究の目標とした.

2

2.

現状分析
工数予実に乖離が発生する原因を分析するため,研究メンバーの所属するプロジェクトを対象に,プロジェクトの工数予実調査を実施した.その結果,収集したプロジェクト 15 事例のうち,工数予実の乖離が 5 件のプロジェクトに見られ,さらに,結合テストもしくは総合テストに顕著に表れていることが分かった（付表 A-1）.
また,上記の調査対象プロジェクトにて発生した 91 件の不具合事例を分析したところ,変更内容に対する処理の検討不足・考慮漏れが 35 件と不具合の約 40％を占めていること（付図 B-1 参照）,また,不具合の約 40%が詳細設計まで手戻りが発生していること(付図 B-2 参照）が分かった.
上記の調査結果より,設計段階で変更内容に対する処理の検討不足・考慮漏れが発生したことに起因した「工程の手戻り」が,工数予実の乖離に大きく影響していることが分かった.何故,設計段階で変更内容に対する処理の検討不足・考慮漏れが発生したのか？その手掛かりを得るために先行技術である XDDP を参照した.
XDDP では,機能変更の開発プロセスにおいて使用する 3 点セット（変更要求仕様書,トレーザビリティ・マトリクス（以下,「TM」と記述する）,変更設計書）の一部である変更要求仕様書は,顧客からのシステムに対する変更依頼を「USDM」の表記法に則り,要求と仕様を階層構造で表現したものである.しかしながら,USDM は「要求」と「何故その変更が必要なのか？」の理由や背景を基に「変更すべき箇所」を捉えるものであるが,「仕様」で来る変更依頼には,その理由や背景が示されていない事が多く,要求の本質を捉えにくい.このため,顧客へ変更内容に関する背景や理由を確認した上で,“新たに要求を立てる作業”が必要となるが,担当者が「仕様」で来る変更依頼を見極められなければ「変更すべき箇所」に気付く事は困難である.
ま た ,見 積 の 経 験不 足 や シ ス テ ム の 習 熟 度 が 低 い 担 当 者 が 見 積 を 行 っ た 際 ,変 更 依 頼が具体的な内容で示されているが故に,変更箇所を容易に特定できたことで,他への影響等について何ら疑いを持たなかった結果,他の「変更すべき箇所」の存在に気付けなかった.この点については,派生開発特有の問題であると考えられる.派生開発では,既存ソフトウェアに対して新たな機能を追加する「新規機能追加」と,既存機能に対して変更を行う「既存機能変更」の異なる 2 つの開発アプローチが存在する（図 2.1）.

図 2.1 ソフトウェア開発 形態「新規機能追加」に関しては新規開発同様,システム全体や追加機能に関して追加する
背景や理由が変更依頼に伴って示される場合が殆どであるが,「 既存機能変更」に限っては,変更依頼が具体的な内容で示されるケースが少なくない.それ故に,変更依頼から容易に変更箇所が特定できたことで「他に変更箇所は無いだろう」という,担当者の「思い込み」が「隠れた仕様」を気付きにくくしている.
上記の問題を解決すべき課題として下記の点にフォーカスした.
・如何にして変更依頼から「要求」で来たものか「仕様」で来たものかを見極めるか.
変更依頼が「仕様」で来たものと見極められることで,“新たに要求を立てる作業”が必要であることに気付くようになり,他にも「変更すべき箇所」があるかも知れないと担当者が気付きやすくなる.その結果,工程の手戻りが低減され,見積精度も向上すると考える.
3

3.

先行研究
仕様から新たな要求を立てる方法については,先行研究として木下ら[4]が考案した「システムプロファイル」がある.これは,変更要求仕様書を利用して仕様から新たな要求を立てる際に,他システムへの変更要求を引き出すために用いるシートであるが,そもそも変更依頼の「仕様」（先行研究では「仕様レベル」と称する）について,「変更箇所がイメージできるほど具合的に示されたもの」としており,「仕様レベル」に関する具体的な定義付けがされていない（論じられていない）.特に見積の経験不足やシステムの習熟度が低い担当者が見積を行う場合,変更依頼が「仕様」であると判断できなければ,「システムプロファイル」を用いても,他への影響箇所が適切に抽出できない可能性がある.
4 . 解決策4 .1 見積を見誤る理由
派生開発の見積において工数を見誤る原因の一つに,変更依頼について,「要求」か「仕様」の見極めができず,「隠れた要求／仕様」に気付かないことにあった．その理由は,見積担当者の経験不足やシステムの習熟度が低く,変更依頼が具体的な内容で示されているが故に変更内容を鵜呑みにしてしまった結果,「隠れた要求／仕様」の存在に気付くことができなかったからである．
4.2
4.2 解決策のポイント
上述の理由から,「隠れた要求／仕様」を見つけるためには,見積担当者の経験不足や当該システムの習熟度に極力依存させないことが必要である．そのため,変更依頼には「要求」として来るものと「仕様」として来るものの 2 種類が混在することを認識させた上で,変更依頼が「要求」または「仕様」のいずれかで来たものであるかを的確に判断させることがポイントとなる．なぜなら「仕様」と判断された変更依頼が,変更内容に関する背景や理由を考慮した上で“新たに要求を立てる作業”（以下,昇華と称する）の前提条件になるからである（図 4.1）．

図 4.1

変更依頼 から仕様作成までの 流れ

4.3 解決策
見積における顧客からの変更依頼の捉え方について習熟者にヒアリングし,我々研究メンバーで上述の解決策のポイントを基に,変更依頼から「要求レベル」または「仕様レベル」を判定する「変更依頼仕分けガイド（Change Request Classification Guide）」（以下, CRCGと称する）を考案した．この CRCG を使い,変更依頼の内容を分析することにより,「仕様」で来た変更依頼に気付き,「隠れた要求／仕様」の発見につながるものと考えた．
4表 4.1

変更依頼 仕分けガイド（仕分け ガイド（ CRCG）
CRCG ）

4.3.1
4.3 .1 判定結果 による定義付 け
図 4.2 に示す要求／仕様レベル判定フローに従い,CRCG（表 4.1）を用いた変更依頼の要求／仕様レベル判定結果を以下に示す.
【昇華を伴わない仕様レベル】
チェック項目 1 又は項目 2 に該当かつ,項目 3 および項目 4 に該当する場合.
【昇華を伴う仕様レベル】
チェック項目 1 又は項目 2 に該当かつ,項目 3 または項目 4 に非該当の場合．
【要求レベル】
チェック項目 1 および項目 2 に非該当の場合．

図 4.2

CRCG を用いた要求／仕様レベル判定フローを用いた要求／仕様レベル 判定フロー

5

5.

解決策の検証
既存のプロジェクト事例を基に,以下の観点から表 4.1 に示す CRCG の正当性を検証する.
① 変更依頼から「仕様レベル」または「要求レベル」を判定できるか.
② 「昇華を伴う仕様レベル」と判定できた変更依頼から昇華を行い, 隠れた変更仕様を見つけることができるか.

5 . 1 「 仕様レベル仕様レベル」」 判定の検証(1) シミュレーションの実施
研究メンバーから収集した不具合事例 70 件（単純ミスによる不具合 21 件については,本研究に直接関係しないため対象外とした）を基に特定できた,変更依頼 59 件を用いてCRCG の正当性を検証した.
(2)シミュレーションの結果
シミュレーションを実施した結果を表 5.1 に示す.検証の対象となった変更依頼 59 件のうち,17 件について「昇華を伴わない仕様レベル」,3 件について「昇華を伴う仕様レベル」と判定できた.
表 5 .1CRCG 判定結果（一部抜粋）

5 . 2 判別結果の有効性検証(1) シミュレーションの実施
CRCG による判別結果の有効性を検証するため,「昇華を伴う仕様レベル」と判定できた 3 件について昇華を行い,隠れた変更仕様を見つけることができるかを検証した.
(2)シミュレーションの結果
シミュレーションを実施した結果,「隠れた要求／仕様」を見つけることができた.
ここでは表 5.1 項番 7 の変更依頼を用いて,表 5.2 に判定前の変更要求仕様書例を,表5.3 に判定後の変更要求仕様書例を示す.

6

表 5 .2

判定 前 の 変更要求仕様書例

表 5.3「DELIVERY」は,昇華によって新たに立てた「変更要求」であり,その変更要求から USDM によって見つけた「隠れた仕様」が「DELIVERY02.01」である.
表 5 .3

判定 後の変更要求仕様書例

7

6 . 結論
6 . 1 取組みと成果
今回の研究を通し,派生開発における「既存機能変更」においては,変更依頼が「仕様レベル」で来ることが多くあることを再認識することができた.また,シミュレーションによる検証結果から,研究メンバーが携わっているシステム形態に限定ではあるが,CRCG を用いることで以下に示す効果があることがわかった.
① CRCG を用いることで,熟練者か否かに関わらず,変更依頼が「仕様レベル」として提示され,隠れた要求や仕様があることに気が付くことができる.
② CRCG により「昇華を伴う仕様レベル」と判定された項目については,昇華を行うことで新たな要求を定義することができる.
③ 読み手にとって誤解を与えるような曖昧な表現に気付きやすくなり,変更依頼の提示元へ確認を促す機会になる.
6 . 2 今後の課題
CRCG を用いることで,変更依頼より「要求レベル」または「仕様レベル」が判定可能であることは確認できたが,この結果,見積精度がどの程度改善されるかについては,時間的な制約から検証するに至らなかった.この点に関しては今後の課題である.
また今回の研究では,「隠れた要求／仕様」に気付けなかったことにより発生した不具合事例に着目したが,他の不具合事例について,早期発見に有効であると思われる検出手段を検討した（表 6.1）.
表 6 .1 不具合事例 における 検出 手段 一覧（一覧 （ 付表 C - 2 より抜粋）より 抜粋）
不具合の検出手段
No.
不具合事例
レビュー
構成管理昇華再確認
1
不具合事例 1○☓☓☓
2
不具合事例 2☓○☓☓3
不具合事例 3☓☓○☓4
不具合事例 4☓☓☓
○
…
…
…
…
…
…
20
不具合事例 20○☓☓☓
その結果,昇華の他にもレビュー(設計,コード含む)や構成管理,質問票等による仕様の再確認で不具合を事前に発見できると判断した.これらの検出手段（昇華を除く）における解決策の検討についても今後の課題である.
7 . 参考文献[1] 清水 吉男,「派生開発」を成功させるプロセス改善の技術と極意,技術評論社,2007[2] 清水吉男,SQiP 第 6 部会[派生開発]特別講演資料 5 版 派生開発プロセス[XDDP]のポイント,2013[3] 清水 吉男,【改定第２版】 [入門+実践] 要求を仕様化する技術・表現する技術,2010[4] 木下 良介,中澤 康郎,大杉 仁司,変更依頼の対応箇所を検討する前に他システムへの影響を検知する方法,日本科学技術連盟第27年度ソフトウェア品質管理研究会成果報告集,2011

8

付録 A
付表 A - 1 ：プロジェクト事例

9

付録 B
付表 B - 1 ：不具合事例（抜粋）10

付図 B - 1 ：バグ原因
11

付図 B - 2 ：抽出すべき工程12

付録C付録 C
付表 C - 1 ： 変更依頼仕分けガイド（ CRCG）
CRCG ）

13

付表 C - 2 ： 不具合事例における検出 手段一覧

14