要件定義工程の進め方




要件定義の進め方

若手エンジニアの中には、要件定義の進め方がよく分からない人も多いだろう。

そこで、今回は要件定義の進め方を説明する。

はじめに

システム開発の最上流工程は「要件定義」だと感じるかもしれないが、実際は、要件定義よりも上に「企画」がある。

企画では、ユーザ企業にて、経営戦略や事業戦略にもとづいて業務分析を行い、システム化の全体像/範囲/予算/スケジュールなどを検討する。

予算を検討するためには見積りが必要なので、企画の段階からベンダ企業が支援する場合も多い。

企画にて、システム化の大枠が決められ、その後の要件定義工程にて、具体的な要件を詰めていく流れだ。

要件定義工程の進め方【全体概要】

要件定義工程の進め方は下記のとおり。

要件定義の流れ

1.要件定義の計画作成
2.業務要件の整理
 2-1.現行業務の整理
 2-2.ヒアリング実施と課題分析
 2-3.新しい業務の検討
 2-4.システム化範囲の検討
3.システム要件の整理
 3-2.プラットフォームの検討
 3-3.機能要件と非機能要件の整理
4.まとめ/見積り
 4-1.要件定義書の作成
 4-2.基本設計以降の計画作成
 4-3.見積りの算出

ざっくり説明すると、
 1.どう進めるのか計画を立てて
 2.どんな業務にしたいのか整理し、
 3.どんなシステムが必要なのか整理し、
 4.要件定義書にまとめ、見積りをする
という流れだ。

要件定義の計画作成

成果物

・要件定義計画書

要件定義をはじめるにあたって、システム化の方針を明確にし、要件定義のスケジュールや体制図を作成する。

前述の「システム化構想」がしっかりとできていれば、その内容を引き継ぐだけでいいのだが、システム化構想が十分にできていない場合も多い。

そのため、現状調査やヒアリングをする前に、5W2Hを再確認することが重要となる。

5W2H
システム開発における5W2H
出典:IPA『高品質のための超上流工程における企業の課題・取組み事例集』,p.11

要件定義は、システム化構想の結果を受けて、「どんな業務にしたいのか検討し、その業務を実現するために必要なシステムを整理する」工程だ。

これらの情報を整理したのち、「業務要件の整理/システム化要件の整理/まとめ・見積り」といった要件定義のスケジュールを立てよう。

業務要件の整理

要件定義では、まず業務要件の整理を行う。

よくある間違いが、「どんなシステム機能が欲しいですか?」というシステム要件のヒアリングをしてしまうこと。

多くの場合、ユーザ企業側でも現状の課題分析が不足しているため、本当に必要なシステム機能が何なのかがイメージできていない。

このような状態で、システム要件を詰めても、後々の工程でシステム機能が追加されたり、作ったものの”使えないシステム”となってしまう可能性が高くなってしまう。

ゆえに、要件定義では「システム要件の整理」の前に「業務要件の整理」が必要なのだ。

では、下記4つの作業内容を説明していこう。

 ・現行業務の整理
 ・ヒアリング実施と課題分析
 ・新しい業務の検討
 ・システム化範囲の検討

現行業務の整理

成果物

・現行業務フロー
・業務処理定義書

業務の「あるべき姿(To-be)」と「現状(As-is)」とのギャップが「業務課題」となる。

課題を抜けなく洗い出すためにも、現行業務(As-is)の整理は重要なのだ。

現行業務を整理する手法はいろいろあるが、「業務フロー」を作成するのが一般的で、フロー上に書ききれない詳細な内容は、「業務処理定義書」に記載する。

プロジェクトの特性に応じて、「データフロー」や「ユースケース」を用いて整理することもある。

 

また、現在は、部分的にシステム化をしている場合がほとんどなので、現行システムの調査も行い、業務フローにシステム機能を追記しておこう。

もし、現行システムの資料が無い場合は、要件の抜け漏れを防ぐためにも、下記のような資料を整理をしておいた方がいいだろう。

現行システムの資料

・システム機能階層図
・画面一覧
・画面遷移図
・帳票一覧
・ER図
・エンティティ一覧
・エンティティ定義書
・外部システム関連図
・外部インターフェース一覧
・外部インターフェース定義書

 

ヒアリング・問題分析・解決策検討

成果物

・ヒアリング結果一覧
・問題/影響/原因/対策一覧

業務部門にヒアリングをしながら課題を分析し、対策を検討するタスク。

対策には、システム化による対策だけでなく、業務プロセスだったり体制の変更なども含める。

それでは下記3つの観点で説明していこう

 1)ヒアリングの実施
 2)問題の分析
 3)解決策の検討

1)ヒアリングの実施

今回のプロジェクトのテーマ(つまり、事業課題)に沿った業務上の問題について、業務部門にヒアリングを行う。

ヒアリングの方法にもいろいろあるが、例えば、日立製作所では、RAカードと呼ばれるアンケートカードを用いて、「問題」「影響」「原因」「願望」という4項目に分けて記入してもらうそうだ。

問題:現在の業務で起こっている問題
影響:問題の結果として発生している好ましくない状況
原因:問題を引き起こしている最も重要な原因
願望:問題の解決策や改善案

ヒアリングした内容は、一覧表にまとめて後々確認できるようにしておこう。

2)問題の分析

ヒアリングの結果をもとに、問題・影響・原因を構造的に整理する。

整理するときは、「問題」から整理していく良いだろう。

参考:問題分析

影響 :問題に対して、「だから何?」
(問題)出荷伝票の書き間違いがある。
↓ だから何?
(影響)誤出荷に繋がっている。

原因 :問題に対して、「なぜ?」
(問題)出荷伝票の書き間違いがある。
↓ なぜ?
(影響)出荷依頼をメールや電話、FAXなどで受けて、伝票を書き起こしているため。

 

影響に対しては、「だから何?」を繰り返して、「売上/コスト/顧客満足度/コンプライアンス」といった経営レベルの観点につなげよう。

原因に対しても、「なぜ?」を繰り返して、「業務プロセス/システム/制度・ルール/組織・担当者/設備・機器」といった観点に落とし込んでおくと対策が検討しやすい。

さらに、それぞれの問題に対して優先順位を仮決めしておくと、解決策の検討対象を絞ったり、システム化の対象範囲を決めたりする際に役立つだろう。

3)解決策の検討

掘り下げた原因に対しての対策を検討する。

前述した5つの観点で考えると対策が出やすい。(システム化だけが対策ではない)

・業務プロセス
・システム
・制度・ルール
・組織・担当者
・設備・機器

ここでの”システム”に当たる部分がシステム要件へとつながっていく。

新しい業務の検討

成果物

・新業務フロー

現行業務の資料に検討した解決策を反映させる。

現行のデータフローやユースケースを整理していた場合は、改善後の資料も整理しておこう。

システム化範囲の検討

成果物

・システム化の対象範囲

新しい業務の姿が描けた後は、システム要件の整理へと入っていくが、その前に、今回のプロジェクトでのシステム化範囲を検討する。

要件定義開始時の範囲から外れていなければ問題ないが、問題分析・解決策の検討を行った結果、システム化範囲が変わってきている可能性があるからだ。

具体的な作業としては、要件定義開始時の5W2HのWhere(対象範囲)やHow(実現手段)をチェックする。

当初と比べてシステム化範囲が拡大している場合、範囲を絞ったり、プロジェクト予算を増やしたりする必要があるだろう。(要件定義のスケジュールが延長となることもある)

システム要件の整理

業務要件の整理が終わったら、システム要件の整理を行う。

システム化の範囲やプラットフォームに変更がないかを再検討し、システムの機能要件と非機能要件を具体的にしていくという作業だ。

では、下記2つの作業内容を説明していこう。

 ・プラットフォームの検討
 ・機能要件と非機能要件の整理

プラットフォームの検討

成果物

・ハードウェア構成
・ソフトウェア構成
・ネットワーク構成

プラットフォームとは、システム機能を提供するためのネットワーク、ハードウェア、OS、ミドルウェア(DBなど)のこと。

システム化構想の段階で仮決めしたプラットフォームに対して、前作業「システム化範囲の検討」の結果を受けて、プラットフォームに変更がないかを再検討する。

プラットフォームの変更は、プロジェクト費用に大きく影響するため、しっかりと検討しておきたい。

機能要件と非機能要件の整理

新しい業務を実現するうえでのシステム要件を整理する。

システム要件は「機能要件」と「非機能要件」に分類できる。

機能要件 :業務を代行、または支援する機能

非機能要件:性能・信頼性・操作性など、機能以外の要件

 

機能要件の成果物

・システム機能要件
 システム機能階層図

・画面要件
 画面一覧
 画面遷移図
 画面レイアウト

・帳票要件
 帳票一覧
 帳票レイアウト

・データ要件
 ER図
 エンティティ一覧
 エンティティ定義書

・外部インターフェース要件
 外部システム関連図
 外部インターフェース一覧
 外部インターフェース定義書

 

非機能要件の成果物

・ユーザビリティ及びアクセシビリティ要件
・システム方式要件
・規模要件
・性能要件
・信頼性要件
・拡張性要件
・上位互換性要件
・継続性要件
・情報セキュリティ要件
・情報システム稼働環境要件
・テスト要件
・移行要件
・引継ぎ要件
・教育要件
・運用要件
・保守要件

 

機能要件は、画面や帳票といった入出力機能から整理していくと良いだろう。

非機能要件は、IPAの『非機能要求グレード』を参考にすると整理をしやすい。

機能要件と非機能要件は下記の記事でも説明しているので、参考にしてほしい。

機能要件と非機能要件の書き方〜サンプル付き

機能要件・非機能要件の書き方【サンプル有り】

2018年8月17日

要件定義のまとめ/見積り

要件定義のまとめとして、下記の作業を行う。

 ・要件定義書の作成
 ・基本設計以降の計画作成
 ・見積りの算出

要件定義書の作成

成果物

・要件定義書

要件定義フェーズのまとめとして、要件定義書を作成する。

これまで作成してきた資料をもとに、下記のような流れで形を整えていく作業だ。

要件定義書の内容

1.業務要件の定義
1-1.業務概要
1-2.規模
1-3.時期・時間
1-4.場所
1-5.管理すべき指標
1-6.システム化範囲

2.機能要件の定義
2-1.システム機能要件
2-2.画面要件
2-3.帳票要件
2-4.情報・データ要件
2-5.外部インタフェース要件

3.非機能要件の定義
3-1.ユーザビリティ及びアクセシビリティ要件
3-2.システム方式要件
3-3.規模要件
3-4.性能要件
3-5.信頼性要件
3-6.拡張性要件
3-7.上位互換性要件
3-8.継続性要件
3-9.情報セキュリティ要件
3-10.情報システム稼働環境要件
3-11.テスト要件
3-12.移行要件
3-13.引継ぎ要件
3-14.教育要件
3-15.運用要件
3-16.保守要件

 

要件定義書の書き方は、下記を参考にしてほしい。

>> 「要件定義書の書き方」を見る

作成した要件定義書は、ユーザ企業側のレビューを行い、承認をもらおう。

基本設計以降の計画作成

成果物

・WBS

要件定義書の作成後は、基本設計以降の作業を洗い出し、スケジュールを立てよう。

ここで作成した資料は、見積りや、後続工程でのスケジュール・コスト管理にも使用する。

基本設計以降の流れ

・基本設計(外部設計)
・詳細設計(内部設計)
・プログラム設計
・プログラミング
・単体テスト
・統合テスト(結合テスト)
・総合テスト
・運用テスト

システム開発のV字モデル

見積りの算出

成果物

・見積書

要件定義書が完成した後には、システム開発の見積りを算出する。

システム化構想の予算をオーバーしていないかのチェックとしての意味合いのほか、基本設計以降を請負契約とする場合には、契約金額そのものになる。

 

参考までに、下記に代表的な見積り手法を3つ紹介しておこう。
 1)類推見積り
 2)パラメトリック見積り
 3)ボトムアップ見積り

1)類推見積り

過去の類似プロジェクトから、見積りを類推する方法。

予算獲得時など、上流工程の初期見積りで使われることが多いが、精度が粗いため、要件定義以降ではほとんど使われない。

2)パラメトリック見積り

機能数や画面数などに係数をかけて見積りを算出する。

係数の設定次第で見積り精度が変わってくるが、利用実績の多い企業では係数の信頼度も高く、ユーザー企業の理解も得やすいため、最も利用される手法だ。

3)ボトムアップ見積り

プロジェクトの作業を洗い出し、工数を算出する方法。

作業ベースで見積るので最も精度が高く、プロジェクト開始後のスケジュール・コスト管理にも流用できる。

IPA『ソフトウェア開発見積りガイドブック』,pp.48-59 を参考に記載

さいごに

要件定義の進め方を説明してきた。

要件定義の流れ

1.要件定義の計画作成
2.業務要件の整理
 2-1.現行業務の整理
 2-2.ヒアリング実施と課題分析
 2-3.新しい業務の検討
 2-4.システム化範囲の検討
3.システム要件の整理
 3-2.プラットフォームの検討
 3-3.機能要件と非機能要件の整理
4.まとめ/見積り
 4-1.要件定義書の作成
 4-2.基本設計以降の計画作成
 4-3.見積りの算出

システム開発のプロジェクトのおよそ半数は失敗するという調査結果があり、その失敗原因のトップは「要件定義」にあるとされる。

この記事が参考になれば幸いだ。

 

要件定義工程の関連記事はこちら。

要件定義工程の成果物

要件定義工程の成果物一覧

2019年6月4日
要件定義の進め方

要件定義工程の進め方

2019年6月2日
要件定義の目的

【結論】要件定義の目的は「プロジェクトの失敗を減らすこと」

2019年6月2日
要件定義書の書き方

要件定義書サンプル・書き方

2019年6月2日
機能要件と非機能要件の書き方〜サンプル付き

機能要件・非機能要件の書き方【サンプル有り】

2018年8月17日

参考文献

IPA『共通フレーム2013』

IPA『経営者が参画する要求品質の確保』

IPA『ユーザのための要件定義ガイド』

IPA『非機能要求グレード』

IPA『ソフトウェア開発見積りガイドブック』

日経BP『要求定義の方法論を知る』

日経BP『手戻りなしの要件定義[業務の分析・設計]』

経済産業省『情報システム・モデル取引・契約書(受託開発(一部企画を含む)、保守運用)<第一版>』






コメントを残す

メールアドレスが公開されることはありません。

CAPTCHA