ＳＥノウハウ 要件定義編: Ver1.5
価格： ￥0
カテゴリ： Kindle版
本書は、システム開発における要件定義のノウハウを纏めた書籍です。
システム化構想・システム化方針・計画は本書の対象外とし、個別システムの要件定義を対象としています。
特に、エンタープライズレベルの企業の要件定義において、本書が参考になるかと思います。
＜特徴＞
・システム構築の実際のノウハウであること
・実際の業務で使えることを目的としており、工程・業務・タスク単位の章立てであること
・各要件におけるゴール（どこまでやればいいかの基準）を明確にしていること
＜冒頭＞
1.要件定義
要件定義とは、システムを利用して業務を行う時に、どのようなシステム化対象・機能、性能等が必要か決める業務である。
社内の経営戦略・業務戦略、情報戦略や、既存の情報システムの基盤・各種管理体を踏まえ、ステークホルダーの様々な要求や意見を纏め、調査、分析、知識や経験等により『相対効果の大きい対策』を導き出し、各種要件（機能要件、セキュリティ要件、性能要件等）として纏めることを目的としている。
『相対効果の大きい対策』には特に留意が必要で、ステークホルダーの要望を単に全て取り入れることなく、目的を実現できるよう代替え案の提示を行うことや、予算に収まるよう、システムに求める要件が過度に増加することの無いように制御し、費用対効果等の観点（※１）から合理的な内容とし、ステークホルダーの合意形成を図る必要があることに要件定義の難しさがある。
システム開発というビジネスは、他のビジネスと比べ、曖昧なビジネスである。例えば、他のビジネスでは、展示品があったり、試供品があったり、模型があったりと、成果物が明確であるが、システム開発は、発注者と受注者のイメージでのやり取りが行われ、イメージに大きな隔たりがあることもしばしばある。このシステム開発における要件定義の曖昧性を認識しつつ、イメージの提示・提案等により、隔たりのギャップを埋めるとともに、曖昧性をいかに減らせるかが、要件定義工程の重要なポイントである。
また、システム開発業務は、開始時点において、全体が見えていないことが多く、作業の進捗と共に新たな問題が発覚したり、仕様変更やスコープの変更が多く発生したりする業務特性がある。そのため、まずは、発注者・受注者が共同で仕様を確定させ、それからシステム開発の請負契約を行えば、不透明な見積りとなることもないし、曖昧要件の受注リスクを抱えることもなく、お互いにWin-Winの関係になれる。（仕様確定のためのＳＥ派遣、仕様確定した後、システム開発の請負契約の２段階契約）
※１ 考慮すべき観点
・費用対効果
・全体最適化
‐開発標準（ハードウェア、ミドルウェア、ソフトウェア）への準拠
‐必要最低限の機能水準（セキュリティ機能、耐障害性機能等）
・システム化に伴う影響
・システムの資産価値
＜成果物＞要件定義書／要求定義書（RFP）
＜成果物の構成 例＞
各要求における決定事項を整理し、構造化された形でドキュメントに纏める。ドキュメントは、決定事項を最後に書くのではなく、ヒアリングや議論の叩き台として作成し、関係者の意見を反映し（何度も書き直しながら）、品質・精度を高めてゆくものである。
要件定義書の構成例は、以下のとおりである。
●要件定義書サマリー
忙しく見る時間のない者もいるため、以降のページをサマリーした１枚程度で作成する。
例えば、機能一覧を機能数でサマリーすることで規模感を表現することが出来る。ユーザー企業の上層部は（１つ１つの機能に興味はなく、）知りたいのは規模感である。
●システム別の対応概要
開発対象のシステムについては、主要機能（サマリー）を記し、開発に伴う影響を受けるシステムにおいては、システム別の対応概要を記す。これにより、対応の全体感を表現することが出来る。
●制約と前提条件
●システムフロー図
●システム構成図
●機能一覧
⇒1.5機能一覧の作成 参照
〇画面一覧、画面レイアウト（イメージ）
⇒1.7画面機能 要件 参照
〇帳票一覧、帳票レイアウト（イメージ）
⇒1.8帳票機能 要件 参照
〇バッチ一覧、データフロー図（DFD）
⇒1.9バッチ機能 要件 参照
〇例外処理機能
⇒1.11例外処理機能 要件 参照
●データ一覧、概念データモデル（ER図）
⇒1.6データ一覧等の作成 参照
●外部I/F一覧
⇒1.10外部I/F 要件 参照
●セキュリティ要件
⇒1.12セキュリティ要件の定義
●完全性要件
⇒1.13完全性要件の定義
●耐障害性要件
⇒1.14耐障害性要件（可用性要件）の定義 参照
●性能要件
⇒1.15性能要件の定義 参照
●拡張性要件
⇒1.16拡張性要件の定義 参照
●運用要件
⇒1.17運用要件の定義 参照
●保守性要件
⇒1.18保守性要件の定義 参照
●課題と解決策
ユーザー企業が解決を求めている課題に対する解決策を記す。
ユーザー企業にとって最も関心があることは、現状の業務の課題がどのように解決されるかと言うことである。
もし、未解決のものがあれば、未解決の理由と対応方針を記載するが、以降の工程に持ち越しても問題ないか判断する必要がある。
●特記事項
特記事項があれば記す。
例：費用にかかわる要求事項（予算）
1.1.準備
1.1.2.本書の前提
本書（個別システムの要件定義にかかわるノウハウ）を記載するにあたり、以下の前提である。
●要件定義をＳＥが支援
要件定義は、基本的にユーザー企業が行うものだが、実際に、ユーザー企業の約８割がＳＥ等の支援を受けて要件定義を実施している。そのため、ＳＥが要件定義の仕様確定のための支援を行う前提で記載している。
●全体のシステム化の方針・計画（スケジュール）
本書は個別システムの要件定義を記載したものであり、下記については、前工程にて定まっている前提である。
⇒詳細は、『ＳＥノウハウ システム化方針・計画編』に記載予定
・開発するシステム（群）の全体方針、全体計画（マスタースケジュール）
・システム間の大よその役割分担
●現行システムの分析・調査
現行システムをもとに新システムを開発する場合、現行システムの分析・調査が行われている前提である。⇒詳細は、『ＳＥノウハウ 現行システム分析編』 参照
【補足】
業務の実態においては、完全な現行システムの分析・調査を完了後に、要件定義に着手することは殆どなく、必要に応じて要件定義工程の中で並行し分析・調査作業を行っている。
現行システムの仕様理解の時間を発注者が認めてくれることは少ない。（発注者から見れば即戦力がいて然るべきと考え、そのような項目があれば、即削られる。）しかし、実際にはかかり、必要な時間である。そこで、「現行調査」という泥臭い作業を入れ、工数を計上することにより、仕様を徐々に覚える時間を確保することが出来る。
●システム重要度評価
システム化構想・システム化方針・計画は本書の対象外とし、個別システムの要件定義を対象としています。
特に、エンタープライズレベルの企業の要件定義において、本書が参考になるかと思います。
＜特徴＞
・システム構築の実際のノウハウであること
・実際の業務で使えることを目的としており、工程・業務・タスク単位の章立てであること
・各要件におけるゴール（どこまでやればいいかの基準）を明確にしていること
＜冒頭＞
1.要件定義
要件定義とは、システムを利用して業務を行う時に、どのようなシステム化対象・機能、性能等が必要か決める業務である。
社内の経営戦略・業務戦略、情報戦略や、既存の情報システムの基盤・各種管理体を踏まえ、ステークホルダーの様々な要求や意見を纏め、調査、分析、知識や経験等により『相対効果の大きい対策』を導き出し、各種要件（機能要件、セキュリティ要件、性能要件等）として纏めることを目的としている。
『相対効果の大きい対策』には特に留意が必要で、ステークホルダーの要望を単に全て取り入れることなく、目的を実現できるよう代替え案の提示を行うことや、予算に収まるよう、システムに求める要件が過度に増加することの無いように制御し、費用対効果等の観点（※１）から合理的な内容とし、ステークホルダーの合意形成を図る必要があることに要件定義の難しさがある。
システム開発というビジネスは、他のビジネスと比べ、曖昧なビジネスである。例えば、他のビジネスでは、展示品があったり、試供品があったり、模型があったりと、成果物が明確であるが、システム開発は、発注者と受注者のイメージでのやり取りが行われ、イメージに大きな隔たりがあることもしばしばある。このシステム開発における要件定義の曖昧性を認識しつつ、イメージの提示・提案等により、隔たりのギャップを埋めるとともに、曖昧性をいかに減らせるかが、要件定義工程の重要なポイントである。
また、システム開発業務は、開始時点において、全体が見えていないことが多く、作業の進捗と共に新たな問題が発覚したり、仕様変更やスコープの変更が多く発生したりする業務特性がある。そのため、まずは、発注者・受注者が共同で仕様を確定させ、それからシステム開発の請負契約を行えば、不透明な見積りとなることもないし、曖昧要件の受注リスクを抱えることもなく、お互いにWin-Winの関係になれる。（仕様確定のためのＳＥ派遣、仕様確定した後、システム開発の請負契約の２段階契約）
※１ 考慮すべき観点
・費用対効果
・全体最適化
‐開発標準（ハードウェア、ミドルウェア、ソフトウェア）への準拠
‐必要最低限の機能水準（セキュリティ機能、耐障害性機能等）
・システム化に伴う影響
・システムの資産価値
＜成果物＞要件定義書／要求定義書（RFP）
＜成果物の構成 例＞
各要求における決定事項を整理し、構造化された形でドキュメントに纏める。ドキュメントは、決定事項を最後に書くのではなく、ヒアリングや議論の叩き台として作成し、関係者の意見を反映し（何度も書き直しながら）、品質・精度を高めてゆくものである。
要件定義書の構成例は、以下のとおりである。
●要件定義書サマリー
忙しく見る時間のない者もいるため、以降のページをサマリーした１枚程度で作成する。
例えば、機能一覧を機能数でサマリーすることで規模感を表現することが出来る。ユーザー企業の上層部は（１つ１つの機能に興味はなく、）知りたいのは規模感である。
●システム別の対応概要
開発対象のシステムについては、主要機能（サマリー）を記し、開発に伴う影響を受けるシステムにおいては、システム別の対応概要を記す。これにより、対応の全体感を表現することが出来る。
●制約と前提条件
●システムフロー図
●システム構成図
●機能一覧
⇒1.5機能一覧の作成 参照
〇画面一覧、画面レイアウト（イメージ）
⇒1.7画面機能 要件 参照
〇帳票一覧、帳票レイアウト（イメージ）
⇒1.8帳票機能 要件 参照
〇バッチ一覧、データフロー図（DFD）
⇒1.9バッチ機能 要件 参照
〇例外処理機能
⇒1.11例外処理機能 要件 参照
●データ一覧、概念データモデル（ER図）
⇒1.6データ一覧等の作成 参照
●外部I/F一覧
⇒1.10外部I/F 要件 参照
●セキュリティ要件
⇒1.12セキュリティ要件の定義
●完全性要件
⇒1.13完全性要件の定義
●耐障害性要件
⇒1.14耐障害性要件（可用性要件）の定義 参照
●性能要件
⇒1.15性能要件の定義 参照
●拡張性要件
⇒1.16拡張性要件の定義 参照
●運用要件
⇒1.17運用要件の定義 参照
●保守性要件
⇒1.18保守性要件の定義 参照
●課題と解決策
ユーザー企業が解決を求めている課題に対する解決策を記す。
ユーザー企業にとって最も関心があることは、現状の業務の課題がどのように解決されるかと言うことである。
もし、未解決のものがあれば、未解決の理由と対応方針を記載するが、以降の工程に持ち越しても問題ないか判断する必要がある。
●特記事項
特記事項があれば記す。
例：費用にかかわる要求事項（予算）
1.1.準備
1.1.2.本書の前提
本書（個別システムの要件定義にかかわるノウハウ）を記載するにあたり、以下の前提である。
●要件定義をＳＥが支援
要件定義は、基本的にユーザー企業が行うものだが、実際に、ユーザー企業の約８割がＳＥ等の支援を受けて要件定義を実施している。そのため、ＳＥが要件定義の仕様確定のための支援を行う前提で記載している。
●全体のシステム化の方針・計画（スケジュール）
本書は個別システムの要件定義を記載したものであり、下記については、前工程にて定まっている前提である。
⇒詳細は、『ＳＥノウハウ システム化方針・計画編』に記載予定
・開発するシステム（群）の全体方針、全体計画（マスタースケジュール）
・システム間の大よその役割分担
●現行システムの分析・調査
現行システムをもとに新システムを開発する場合、現行システムの分析・調査が行われている前提である。⇒詳細は、『ＳＥノウハウ 現行システム分析編』 参照
【補足】
業務の実態においては、完全な現行システムの分析・調査を完了後に、要件定義に着手することは殆どなく、必要に応じて要件定義工程の中で並行し分析・調査作業を行っている。
現行システムの仕様理解の時間を発注者が認めてくれることは少ない。（発注者から見れば即戦力がいて然るべきと考え、そのような項目があれば、即削られる。）しかし、実際にはかかり、必要な時間である。そこで、「現行調査」という泥臭い作業を入れ、工数を計上することにより、仕様を徐々に覚える時間を確保することが出来る。
●システム重要度評価