ソフトウェア・シンポジウム2019 in 熊本

要件定義計画を強化するアセスメント項目の提案

越前谷 達朗株式会社日立ソリューションズ・クリエイト
tatsuro.echizenya.rp@hitachi-solutions.com

新田 史弥
株式会社東光高岳
nitta.fumiya@tktk.co.jp

久保 光寛
日本システム技術株式会社
m.kubo@jast.co.jp

吉竹 宏幸
TIS 株式会社
yoshitake.hiroyuki@tis.co.jp

渋谷 公寛
東京海上日動システムズ株式会社
kimihiro.shibuya@grp.tmnf.jp

石川 冬樹
国立情報学研究所
f-ishikawa@nii.ac.jp
栗田 太郎
ソニー株式会社
taro.kurita@sony.com

要旨的な問題であると推察した．
我々は，開発プロジェクトの要件定義計画の改善を促すことを目的とし，現場で実践可能なガイドラインとして利用できる『要件定義計画アセスメント項目』を提案する．
今回作成した要件定義計画アセスメント項目を過去の開発プロジェクト 53 件に適用した調査の結果，要件定義計画の課題・リスクを事前に抽出し，要件定義で発生している主要な問題を予防する可能性があることを確認した．
以下本論文の構成を述べる．2 章で要件定義計画の概要や実態，課題を説明する．3 章で課題への対策となる要件定義計画アセスメントの考え方や内容，利用手順を説明する．4 章でアセスメントによる要件定義計画の不備・リスク抽出調査の内容と結果を説明し，5 章で調査結果を考察する．6 章で要件定義計画の課題に対するアセスメント項目の効果を，7 章でアセスメント項目の活用方法と今後の課題を述べる．

我々は要件定義計画の不備に起因する要件定義の失敗を回避するために，要件定義開始前に具体化するべき計画事項と計画内容に対するアセスメント項目を創出し，過去の開発プロジェクト 53 件に対して調査を行った．結果，要件定義計画の不備を抱えた開発プロジェクトが多く存在すること，それらの要件定義で発生した問題の予防にアセスメント項目が有効であることを確認した．

1. はじめに実現するビジネスや業務，開発するシステムを決定する要件定義工程は，開発プロジェクト毎に進め方や決めるべき事柄，範囲が多様である．よって要件定義の品質や作業の効率・実現性を担保するためには個々の開発プロジェクトの特性や制約等を考慮した最適な要件定義計画が必要であり，成否の鍵を握る．要件定義実践の観点から要求工学知識を体系化した『要求工学知識体系REBOK』[1]においては，共通的な知識領域の一部に「要求の計画と管理」を定義し，「プロジェクトの特性や遂行条件を考慮して，要求開発の方法や手順を検討する必要がある」と解説している．しかし我々は自らの経験から，要件定義計画の未作成，計画の具体性不足，等は普遍

2. 要件定義計画の概要と現状
2.1. 要件定義計画の概要
要件定義計画は下記事項について，開発プロジェクト毎の特性や制約に合った最適かつ実行可能な内容を検

19

SEA

ソフトウェア・シンポジウム2019 in 熊本

討し，ステークホルダと合意，共有するものである．検討事項の多くは他工程の実行計画に同様の項目があり理解しやすいが，「(3) 3)」「(4) 1)」のように，要件定義に依存する特徴的な検討事項が一部に含まれる．

いるが，マイグレーションに限定されている．
2.3. 開発プロジェクトでの要件定義計画立案の実態
要件定義計画立案の実態を把握するため，回答者が担当した直近の開発プロジェクトでの要件定義計画の内容を表１のアンケートで調査した．また，回答内容との依存関係を分析するため，回答者とプロジェクトのプロフィールも収集した．回答者へのアセスメント項目は 33 項目を対象に合否評価を実施した．（3 章 表 10 参照）(1) 要求開発プロセスの基本方針と前提条件
1) 要求開発プロセスの目的
2) プロジェクトに関係するステークホルダとその役割(2) 要求開発プロセスのアプローチ
1) プロジェクトライフサイクルの選択とアクティビティの設定
2) 要求獲得，要求分析，要求仕様化，要求の検証・妥当性確認・評価の各プロセスでのアプローチ(3) 要求開発プロセスのアクティビティ
1) 各アクティビティの実施手順，使用する書式
2) 要求定義文書の標準的な要求記述ガイド
3) 要求の優先順位付けプロセス
4) 要求のレビュー方針と確認方針，受け入れ基準と評価基準(4) 要求開発プロセスのコミュニケーション計画
1) ステークホルダ間のコミュニケーションの内容と方法
2) コミュニケーションスケジュール(5) プロジェクト管理と要求定義，システム構築との関係
1) プロジェクト管理：メトリクス，リスク管理，問題管理2) システム構築：見積りの範囲と精度(6) 要求管理計画
1) 要求管理プロセス
2) 構成管理※要求工学知識体系 REBOK 第 7 章 要求の計画と管理 から引用

表 1．アンケート項目と概要
No

アンケート項目1

プロジェクト

回答対象プロジェクトの開発種別，

プロフィール

開発対象分野，開発形態等

回答者

回答者の要件定義の経験プロジェ

プロフィール

クト数，累計経験期間，役割・担当

2

アンケート概要

領域
3

要件定義計画要件定義計画書の有無，の問題の有無

計画内容に関する問題の有無

4

アセスメント

要件定義計画の内容に対するアセ項目

スメント実施結果(33 項目での合否評価)

53 件のアンケート回答を集計し，以下 2 点について調査した結果を示す．
(調査 1) 要件定義計画の実態(調査 2) 要件定義計画の実態と回答者プロフィールとの相関関係
調査 1 要件定義計画の実態
アンケート結果の分析により，以下 2 点の見解が得られた．
(1) 要件定義計画が未作成または問題があるケースが多い
要件定義計画の有無と計画の品質について，評価を3 択で回答させた．回答結果を図 1 に示す．さらに，計画がある開発プロジェクトの要件定義計画に 33 項目のアセスメントを適用し，各項目の内容が計画書に反映されている項目を合格とし、合否を判定した．合否判定結果から，各プロジェクトのアセスメント合格率を算出し，分布を作成した．これを図 2 に示す．図 1 および図 2 より以下の結果が得られ，多くの開発プロジェクトで要件定義計画に軽視できないレベルの問題があることが確認できた．

2.2. 業界内における取り組み
業界内の要件定義計画強化に関連する取り組みを主要な標準，知識体系で確認したが，いずれも具体的な定義事項やガイドライン，ノウハウは示さず，実効性は限定的であった．共通フレーム 2013[2]では「2.2 要件定義プロセス」に「要件定義プロセス実行計画の作成」が定義されているが，要件定義実施に関する標準，方法論，手順，役割分担を決定することの必要性を説明するに留まっている．要求工学知識体系 REBOK では，共通知識領域「要求の計画と管理」に「要求開発プロセスの計画」が定義されているが，2.1 に挙げた要件定義計画の検討事項を定義するに留まっている．システム再構築を成功に導くユーザガイド[3]では，要件定義計画事項が定義されて20SEA

ソフトウェア・シンポジウム2019 in 熊本①②

回答者 53 名の約 94%が要件定義の「計画無し」または「計画に問題あり」と評価(図 1 参照)
回答者 53 名の内、要件定義計画があると回答された 42 件のプロジェクトの 6 割が，アセスメント合否判定の合格率 40%から 70%に集中(図 2 参照)の排除」や「成果物の記述レベル・方法の明確化」といった，要件定義特有かつ重要な計画事項が入った.一方で「開始条件」「完了条件」といった認知度の高い計画事項の合格率が低いケースが確認できた．これは要件定義で決めるべきこと，やるべきこと，開始時の状態等が開発プロジェクト毎に異なり多様であるため，汎用的な条件を設定し難いためと考える．
表 2．合格率が高いアセスメント項目（抜粋）
合格率

アセスメント内容[%]
88.1

関係者間において，進捗や品質・リスクを定例会などで共有するようになっており、課題の対応方針の確認など，チェックポイントが設定されているか．

85.7

プロジェクトの目的が明確になっているか．あるいは，目的を明確にするためのタスクが計画されているか．

83.3

関係者間において，スケジュール，体制，タス

図 1 要件定義計画の有無と計画の品質ク，分担が明確になっているか．

表 3．合格率が低いアセスメント項目（抜粋）
合格率
[%]
26.2

アセスメント内容
定義した要件に対するステークホルダ間の理解
齟齬を防止するために，要件文書の曖昧さを排除する検証計画を立てているか．

31.0

お客さま担当成果物も含め，各成果物内容，記述事項，記述レベル・方法が，その必要性を含めて明確になっているか．

40.5

要件定義工程の開始条件と，それに対する現状を整理し，要件定義作業の開始可否を評価可能な準備を行っているか．

40.5

図 2 各プロジェクトのアセスメント合格率の分布

お客さまとの間で「現行踏襲」要件の範囲や内容の認識齟齬を最大限防止するための取り組みを計画しているか．

(2) 要件定義特有の観点を考慮した要件定義計画が立案できていない計画がある開発プロジェクト 42 件を対象にアセスメント項目ごとの合格率を求めた．合格率が上位・下位のアセスメント項目の一部を表 2，表 3 に示す．合格率上位には「進捗や品質・リスクの共有」「プロジェクト目的」「スケジュールやタスク・担当の明確化」といったプロジェクト計画でも扱う認知度の高い計画事項が入った．合格率下位には「現行踏襲要件の認識齟齬の防止」や「要件の曖昧さ

42.9

要件定義工程の完了条件および判断ルールを成果や品質の観点から明確にし，途上管理計画や審議計画を行っているか．

21

SEA

ソフトウェア・シンポジウム2019 in 熊本

表 6．要件定義を担当したプロジェクト数によるアセスメント合格率

調査 2 要件定義計画の実態と回答者プロフィールとの相関関係
調査 1 の結果と回答者・対象プロジェクトのプロフィールとの相関関係の分析から，有意な特徴として以下 2 点が確認できた．
(1) 表 4 より新規開発，派生開発に比べて，マイグレーションプロジェクトのアセスメント合格率が低いことが分かる．マイグレーションの場合，基本的に業務要件が現行と同じで，顧客に業務要件を確認するための計画事項が少なく済むためと考える．
(2) 表 5，6，7 より以下のいずれかの条件を満たす人が携わるプロジェクトの要件定義計画書はアセスメント合格率が高いことが分かる．
・要件定義で広い役割を経験（システム要件，アーキテクチャ，インフラ等）
・要件定義の経験プロジェクト数が 7 件以上
・要件定義の累積経験期間が 15 ヶ月以上
このことから要件定義計画の良し悪しは計画担当者の要件定義実践経験と暗黙知に依存していると考えられる．

プロフィール情報のアンケート回答
要件定義を担当した
回答数
プロジェクト数
1～2 件
10

開発形態

55.3%

3～6 件

1648.1%

7 件以上

1658.9%表 7．要件定義を担当した累積期間によるアセスメント合格率
プロフィール情報のアンケート回答
要件定義を担当した
回答数
累積期間
1～2 ヶ月0

アセスメント合格率0.0%

3～6 ヶ月1153.6%

7～14 ヶ月

742.3%

15 ヶ月以上

2457.5%2.4. 要件定義計画の課題

表 4．開発形態によるアセスメント合格率
プロフィール情報のアンケート回答

アセスメント
合格率

2.2，2.3 の調査結果より，要件定義計画に関して表 8の課題があると考える．

アセスメント
合格率
回答数

新規開発

1257.6%

派生開発

1658.4%

マイグレーション

1445.7%

表 8．要件定義計画に関する課題一覧
No

課題内容

課題 1

標準・知識体系に定義されている要件定義計画の検討事項は粒度が粗く，ガイド・ノウハウとして

表 5．要件定義工程における役割によるアセスメント合格率
プロフィール情報のアンケート回答(複数回答)
要件定義工程における役割の実効性に限りがある(2.2，2.3 調査 2 参照)
課題 2

画が立案できていない傾向にある(2.3 調査 1 参

回答数

業務要件定義1650.2%

システム要件定義(機能要件)

33

54.8%

システム要件定義(非機能要件)

2256.5%

ソフトウエアアーキテクチャ

1162.6%

インフラ・NW

461.1%

移行

964.0%

プロジェクトマネジメント

2052.4%

プロジェクトマネジメントオフィス

263.3%

その他

1

9.9%

開発プロジェクトの要件定義計画には問題があり，要件定義特有の観点を考慮した要件定義計

アセスメント合格率照)3. 要件定義計画を確認するアセスメント項目の提案
3.1. アセスメント項目の目的前章で挙げた課題を解決するため，要件定義開始前に要件定義計画の内容を評価し，その改善を促すことを目的とした要件定義計画アセスメント項目を提案する．

22

SEA

ソフトウェア・シンポジウム2019 in 熊本

表 9．アセスメント項目の利用手順

アセスメント項目に準じて各開発プロジェクトの要件定義計画の内容を確認することで，要件定義計画立案者の経験やノウハウの不足を補い，計画の問題やリスクに対する気付きを得ることを期待できる．

No.

手順

1

項目選別

説明
アセスメント項目を選別する．
アセスメントは全項目実施が必須ではない．開発プロジェクトの特性や条件，リス

3.2. アセスメント項目の概要

ク等を考慮し，実施不要/不可の項目を対象から外す．特定の開発プロジェクトアセスメント項目を表 10 に示す．アセスメント項目立案にあたり，アセスメント対象となる計画書の目次構成は表10 の章・節列の内容のとおり具体化した．その計画書目
次を網羅するアセスメント項目を定義した．アセスメント項
目は，計画が書かれていることよりも，計画内容が妥当であることの確認に重点を置いた．具体的なアセスメント項
目の内容は，著者らの経験や知見を整理し，議論の上決定した．

固有の確認項目の必要性も確認する
2

紐づけ

アセスメント項目とアセスメント対象を紐づける．
開発プロジェクト毎に計画を記載する文書やその形式が異なるため，アセスメント対象の計画事項が記載される文書，目次を特定し，アセスメント項目と紐付ける

3

アセスメント

複数担当者でアセスメントする．

実施

顧客を含む全てのステークホルダグルー

3.3. 利用手順

プから選出した担当者が個別にアセスメントを実施する

開発プロジェクトでの利用手順を表 9 に示す．また，その利用イメージを図 3 に示す．ただし，本研究の調査では過去の開発プロジェクトが対象であるため，この手順に沿った利用はしていない．
重要な点は，顧客を含む全ステークホルダグループが表 9 の No.3 と No.4 の手順に参加することである．これにより，要件定義開始後に起こりがちな認識齟齬の発覚による作業停滞や計画外作業を予防できる．

4

結果比較

アセスメント結果を評価する．
担当者全員の評価を確認し，評価が低い項目や担当者間の評価差異が大きい項目について，全担当者で理由や認識をすり合わせる

5

対応検討

要件定義計画の改善内容を確定する．
要件定義計画の再検討箇所，検討方針等をステークホルダ間で確定，合意する

図 3 アセスメント項目の利用イメージ

23SEA

ソフトウェア・シンポジウム2019 in 熊本

表 10．アセスメント項目
章 節 アセスメント項目
１．要件定義方針（１）プロジェクトゴール①プロジェクトの目的が明確になっているか。あるいは、目的を明確にするためのタスクが計画されているか。

（２）要件定義スコープ①要件定義作業や検討領域、業務、ITシステム機能の範囲は、読み手による解釈の違いがないように具体的に定義されているか。

（３）要件定義遂行上の制約、前提①お客さまが示す要件定義実施に関する制約条件が明確か。
②要件定義計画の完遂に必要な前提条件を自社から明示しているか。
③制約内で実行可能な要件定義計画を立てているか。

２．要件定義実施計画（１）実施計画概要①要件定義計画書がお客さまのプロジェクトオーナーをはじめとする関係者、ステークホルダーに説明され、合意・承認を得ているか。

（２）要件定義の進め方①採用予定の技術や製品、パッケージ等と、業務要件・システム要件との適合評価および対策検討の実施を計画しているか。
②お客さまとの間で「現行踏襲」要件の範囲や内容の認識齟齬を最大限防止するための取り組みを計画しているか。
③要件定義の進め方の論理的な流れや方法論を具体化し、プロジェクトが実行可能な要件定義プロセス/成果物を計画しているか。

（３）ご提示頂く情報①システム企画・システム化計画・提案依頼書・業務要件定義等のインプットについて、内容の範囲や網羅性、具体性等を確認し、想定に対する不備・不足があれば対策を計画に織り込んでいるか。
②現行業務、現行システムを可視化した文書の整備状況、品質に問題はないか？問題が明確な場合、現行調査実施の判断や実施計画立案を行っているか。

（４）要件調整の進め方①要件規模が予定リソースを超過した際に、実現要件を調整するルール、手順、基準を定義し、調整実施タイミングを計画しているか。

（５）品質計画①プロジェクトの目的・目標に対する要件の妥当性をお客様が評価・判断する実施計画を立てているか。
②定義した要件を業務またはシステムとして実現できる見通し、裏付けを取る検証計画を立てているか。
③プロジェクトの目的や目標、解決対象の課題等と紐づけて、要件の必要性を確認する検証計画を立てているか。
④定義した要件に対するステークホルダー間の理解齟齬を防止するために、要件文書の曖昧さを排除する検証計画を立てているか。

（６）体制①関係者間において、スケジュール、体制、タスク、分担が明確になっているか。
②お客様業務やシステムに関する知識・経験を保有した、自社体制を構築しているか。
③自社要員は、要件定義計画にまとめた要件定義の進め方や成果物体系、背景にある考え方を理解し、実践する準備ができているか。

（７）スケジュール①難易度、複雑度、現行の可視化度合い等による、業務やシステム機能ごとの重みやリスクの違いを踏まえた、実現性あるスケジュールを計画しているか。

（８）成果物定義①お客さま担当成果物も含め、各成果物内容、記述事項、記述レベル・方法が、その必要性を含めて明確になっているか。
②後続の、方式要件・基盤要件・外部設計や開発工数見積に対する十分なインプット情報を備えた成果物体系、様式、記述ルールになっているか。
③前/後工程を含め、成果物間の前方/後方トレーサビリティが明確であり、要件の存在理由、必要性を確認可能な、成果物体系、様式、記述ルールになっているか。

（９）コミュニケーション計画①お客様との意思決定や、要件合意および承認に関するルールや実施タイミングが明確になっているか。
②ステークホルダー間で要求が纏まらない場合などに、プロジェクトとして判断を下す最終意思決定者が決められ、意思決定ルールとして明確になっているか。
③関係者間において、進捗や品質・リスクを定例会などで共有するようになっており、課題の対応方針の確認など、チェックポイントが設定されているか。
④プロジェクトに必要なお客さまとのコミュニケーション密度を踏まえて、お客さまオフィスでの常駐作業の要否を検討しているか。

（１０）工程開始/終了基準①要件定義工程の開始条件と、それに対する現状を整理し、要件定義作業の開始可否を評価可能な準備を行っているか。
②要件定義工程の完了条件および判断ルールを成果や品質の観点から明確にし、途上管理計画や審議計画を行っているか。

（１１）要件定義の重要成功要因と対策①要件定義の成功のために決定的に重要となるプロジェクト特有の要因を分析し、要件定義計画で「要件定義の重要成功要因と対策」として具体的活動に落とし込んでいるか。

３．お客さまへの依頼事項①要件定義活動におけるお客様の責任、役割に基づく、具体的なタスクや対応依頼事項（依頼先、ボリューム、時期、期待アウトプット等）が明確になっているか。

４．課題、リスク①要件定義計画の各項目に関するリスク・課題は網羅的に整理が行われ、対策および自社/お客さまでの担当範囲は明確か。
②要件定義開始に間に合わなかった計画事項がある場合、課題として管理し、影響を管理できているか。

24SEA

ソフトウェア・シンポジウム2019 in 熊本

表 11．要件定義で発生した重要な問題内容と比率

4. 調査

#
1

アセスメント項目の有効性と網羅性を検証するためアンケートを実施した.

2

4.1. 調査方法
著者らの所属会社で要件定義経験者に下記 3 点を確認するアンケートを実施した． なお、本アンケートは，2.3
要件定義計画立案の実態調査のアンケートと合わせて実施した．

3

・過去の開発プロジェクトの要件定義で発生した重要な問題（Q1）
・上記問題に最も高い予防効果を期待できるアセスメ
ント項目（Q2）
・我々のアセスメント項目に対する追加項目案（Q3）

4

重要な問題

4.2. 調査結果

比率23%

顧客要件の変更/拡大

12

内

顧客要件の変更

5

訳

コスト以上の要求

4

追加要件の発生

3

顧客意思決定の遅れ

10

内顧客間における要件の共有不足

4

訳

顧客側の要件確認遅延3

顧客要件の決定遅延

3

要件の抜け漏れ/認識齟齬16内

要件定義が不十分12

訳

要件の認識齟齬

4

現行システム理解不足

6

内

現行業務の可視化に対する顧客の3

訳

協力が無い
現行システムの調査が不足

5件数19%

30%

11%

3

マネジメント不備

7内資料作成工数増加による工程遅延

2

訳体制を確保できずに要件定義を開1

13%始して有識者の高負荷発生

要件定義で発生した重要な問題を内容で分類した結果を表 11 に示す. 回答者 53 名から得た重要な問題は 5つに分類できた．なお、分類にあたっては，アンケート回答にあった問題事象を１件ずつ確認し、表 11 内訳の粒度で分類した後，それらを要約して 5 点の重要問題として整理した．
また，重要な問題ごとに，予防効果が高いと回答者が評価したアセスメント項目と回答数を整理した結果を表12 に示す．表 11 で分類した主要な問題 5 つを横軸に，アセスメント項目の分類（3 章 表 10 の章・節列）を縦軸に並べ，問題に対してアセスメント項目が有効と回答された件数を各マスに記載した．重要な問題 51 件のうち 49 件に対して，予防効果があるアセスメント項目がアセスメントシート内に存在することが確認できた.

実現方法に議論が集中し工程遅延

1

過去プロジェクトをなぞる計画で進1めたため品質に問題発生
成果物定義を決定せず要件調整を1進め、顧客指摘が多発し工程遅延
リソース調整に時間がかかり工程遅

1

延256

重要な問題なし

24%

7

合計

53100%

SEA

ソフトウェア・シンポジウム2019 in 熊本

表 12．要件定義で発生した問題に対する有効なアセスメント項目(目次別)
重要な問題

#
⽬次

12
39

要件

1

定義

0実施

1

計画件数

⽐率

件数

⽐率

00%

00%

00%

00%

00%

00%

00%

0%

00%

00%

425%

00%

114%

00%

59%

10%

18%

220%

00%

00%

114%

00%

48%

8%

（１）実施計画概要

325%

330%

16%

00%

00%

00%

713%

14%

（２）要件定義の進め⽅

00%

00%

16%

233%

114%

00%

48%

8%

（３）ご提⽰頂く情報

18%

00%

00%

233%

00%

00%

36%

6%

（４）要件調整の進め⽅

18%

110%

00%

00%

114%

00%

3

6%

6%

（５）品質計画

18%

00%

2

13%

00%

00%

00%

36%

6%

（６）体制

18%

00%

00%

117%

114%

00%

3

6%

6%

00%

00%

00%

00%

00%

00%

00%

0%

00%

00%

4

25%

00%

2

29%

00%

6

11%

12%

217%00%

00%

00%

00%

00%

2

4%

4%

00%

00%

2

13%

00%

00%

00%

2

4%

4%

00%

1

10%

00%

00%

00%

00%

1

2%

2%

00%

220%

16%

1

17%

00%

00%

4

8%

8%

00%

110%

1

6%

00%

00%

00%

2

4%

4%

2

17%

00%

00%

00%

00%

00%

2

4%

4%

00%

00%

00%

00%

00%

2

2

4%

-ル

（７）スケジュール（８）成果物定義

1（９）コミュニケーショ

2

ン計画

1

（１０）⼯程開始/終了基

3

準

1

（１１）要件定義の重要4

成功要因と対策

1３．お客さまへの依頼事項

16

４．課題、リスク17

該当するアセスメント項⽬は無い

18
19

QCD に影響する問題は無かった
合計

12100%

10100%

16100%

6100%

7100%

2100%
100%

件数

53⽐率

⽐率

⽐率

15

合計

件数

制約、前提

２．

なし

⽐率

（３）要件定義遂⾏上の

8

重要な問題

ト不備

件数

⽅針

7

マネジメン

ム理解不⾜⽐率（２）要件定義スコープ

6

現⾏システ

れ/認識齟齬

件数

定義

5

要件の抜け漏

定の遅れ

⽐率

要件

4

顧客意思決変更/拡⼤件数（１）プロジェクトゴー
１．

顧客要件の100%

追加アセスメント項目案 36 件を我々のアセスメント項目とマッチングした結果を図 4 に示す．30 件は定義済のアセスメント項目と同義であり，6 件は定義済項目にない新たな観点であった．

26SEA(#18 除く)100%

ソフトウェア・シンポジウム2019 in 熊本

5.2. アセスメント項目の網羅性評価

図 4 追加アセスメント項目案の分類

アセスメント項目で確認すべき対象の網羅性を考察す
る．3 章で述べたとおり，要件定義計画書の目次構成を網羅するアセスメント項目を整備していること，表 12 で大多数のアセスメント項目に主要問題のいずれかに対する予防効果が確認できること，回答者から追加アセスメント項目の要望が少ないこと，から一定の網羅性が認められる．

5. 考察
5.1. アセスメント項目の有効性評価
表 11,12 から要件定義の重要問題全件の 72%を占める
上位 3 問題に対する予防効果が確認でき，アセスメント項目の有効性が認められる．問題毎に考察を纏める．

(1) 大多数のアセスメント項目に有効性が認められる
表 12 で，#1(プロジェクトゴール)，#10(スケジュール)を除く 88%のアセスメント項目に主要 5 問題のいずれかへの予防効果があると評価されたことから、主要５問題を網羅していると認められる．

(1) 顧客要件の変更/拡大
表 12 の#4(実施計画概要)との関係が強い．#4 では要件定義計画書を顧客に説明し合意･承認を得ることをアセスメントする．要件の変更/拡大防止には顧客からの無理難題な要求を抑制する必要があるため，次点の#12(コミュニケーション計画)において要件の合意・承認ルールを決定し，ルールを顧客と合意すること(#4)の有効性が認められる．

(2)

アセスメント項目追加の提案数は少なく，内容も限定的アセスメント項目追加提案 6 件を分類すると｢プロジェク
ト外要因に関する確認事項｣｢コミュニケーションの改善に関する確認事項｣に関するものであった．前者は不足していた視点で，改善点と考える．後者は定義済の同類項目の強化に役立てるべきものであった．

(2) 顧客意思決定の遅れ
表 12 の#4(実施計画概要)との関係が強い．限られた要件定義期間で要件確定するには，全ステークホルダがそれぞれの責務を計画通りに果たす必要がある．次点の#15(お客様への依頼事項)において顧客側キーマンに然るべき時期の意思決定が重要責務であることを理解させ，計画に責務を定義し合意すること(#4)の有効性が認められる．

6. 結論
開発プロジェクトへの事後適用調査により，表 13 に挙げた効果を確認した．
今回提案する『要件定義計画アセスメント項目』では，計画書内に計画内容が記載されていることでは不十分であるため，計画書の目次項目(表 10 の章・節列参照)に合わせた内容に踏み込んだアセスメント項目とした．その結果，主要問題の予防効果が認められ，『要件定義計画アセスメント項目』が実践で利用可能なガイドラインであったことが確認できた．要件定義計画の不備を補完するにあたり必要な項目が定義されていたことが確認できたことから，提案するアセスメント項目を要件定義計画の内容のアセスメントに適用することで，開発プロジェクトごとに最適な計画へと強化するための改善点を得られることが確認できた．

(3) 要件の抜け漏れ/認識齟齬
表 12 の#2(要件定義スコープ)，#11(成果物定義)との関係が強い．#2 のアセスメント項目には要件定義作業や検討領域，業務，IT システム機能の範囲は読み手による解釈の違いがないように具体的に定義されているか，#11 のアセスメント項目にはお客さま担当成果物も含め各成果物内容，記述事項，記述レベル，方法がその必要性を含めて明確になっているかについてアセスメントすることとしており，要件の抜け漏れ/認識齟齬の抑制に対する有効性が認められる．また検証妥当性確認プロセス や 工 程 開 始 終 了 基 準 を 確 認 す る #8( 品 質 計 画 ) ，#13(工程開始/終了基準)が次点に入っており，本問題への根本的対策となる「ステークホルダ間の共通認識/理解の形成」に対する有効性が認められる．

27

SEA

ソフトウェア・シンポジウム2019 in 熊本

7.2. 今後の課題

表 13．要件定義計画に関する課題に対する効果
No1

課題内容

効果

標準・知識体系に定義されアセスメント項目は要件ている要件定義計画の検定義の主要な問題に対討事項は粒度が粗く，ガイして予防効果がある(5.1

ド・ノウハウとしての実効性参照)

アセスメント項目自体も要件定義の多様性に対応する必要があり，特に下記 2 点に対する取り組みが必要と考えている．また，進行中プロジェクトへの適用も含め，研究，実証実験を継続し，実用効果を最大化したい．
・プロジェクト特性やリスク等に合わせたアセスメント項
目の選別方法の整備
・利用者のコンテキストに依存したアセスメント項目内容の解釈差の抑制に限りがある
2

開発プロジェクトの要件定

アセスメント項目は要件義計画には問題があり，要定 義計画が備えるべき件定義特有の観点を考慮

事項を網羅する項目をした要件定義計画が立案備えており，要件定義特できていない傾向にある有の観点を考慮した計謝辞

画立案ができる(5.2 参照)

本論文の執筆に当たり，日本科学技術連盟・第 34 年度(2018 年度)ソフトウェア品質管理研究会・研究コース 5
アドバイザーの熊本高等専門学校の荒木啓二郎校長，研究コース 5 の研究員の皆様，日本科学技術連盟・事務局の皆さまにお世話になりました. 厚く御礼申し上げます.

7. 今後の活用

7.1. 要件定義計画以外への適用の提案

参考文献

以下ユースケースにおいても，アセスメント実施による効果を期待できる．
(1) 提案活動段階での，提案する要件定義業務の妥当性，実現性，リスクの分析(2) 設計工程開始段階での，他社が実施した要件定
義業務の妥当性の確認
顧客から提案依頼書を受領し提案を行う(1)の場合，コストやスケジュール等に大きく影響する重要な計画事項を提案書に記載し，顧客の合意を得る．要件定義で決めることや進め方，顧客を含めた役割分担，実施期間，顧客側の対応事項等である．提案に含めた事項は受注後の変更が難しいため，提案前にアセスメントする価値がある．
設計工程から開発を請負う(2)の場合，何かしらの方法で設計工程開始の可否や妥当性を確認する．その一部として要件定義成果物の品質確認に加え，要件定義計画の事後アセスメントでプロセス品質を確認する．要件定
義に参加したステークホルダや進め方，使用した文書，承認プロセス等の確認により，設計工程開始判断の妥当性向上を期待できる．

[1] 一般社団法人 情報サービス産業協会 REBOK 企
画 WG，要求工学知識体系 REBOK，第 1 版，近代科学社,2011[2] IPA SEC，共通フレーム 2013～経営者、業務部門とともに取組む「使える」システムの実現～，第 1 版，
IPA，2013[3] IPA SEC，システム再構築を成功に導くユーザガイ
ド～ユーザとベンダで共有する再構築のリスクと対策～，第 2 版，IPA，2018

28

SEA