要件定義との違い、要求定義の進め方

要求定義と要件定義の違い、ご存じですか。要求定義はシステムを導入する組織がどの様なシステムにしたいか、要望・要求をまとめることです。要求定義に間違いがあると、ソフトウェアが設計通りに動いても、そもそも設計仕様が間違いで使えないという事も起きます。仕様に基づいて多くのヒト、モノ、カネ、時間をかけて作ったシステムがあるべき姿ではなかったということで多大な費用も無駄になってしまいます。

ソフトウェア開発に限らず、プロジェクトで何をしたいかが明確でないと、本来の目的と違ったものができます。何を何のためにする、どの様にしたいかを整理し、文書化するのが要求定義です。要求定義が起点となり、その後の設計仕様が決まります。

今回は要求定義の進め方について、初めての方でも分かる様に段階的に解説していきます。

要求定義と要件定義の違い

システム開発プロセス

製造業で業務効率化、新規顧客サービスを展開するサービス業、IT化で生産性を上げようと考えられている組織が多くなっています。ペーパーレス等のデジタル化や自動化も考慮したDXを考えられている方々もいます。

システムを導入されようと思われている組織が、システム化をシステム会社に丸投げすると、想定と異なるものができてしまいます。そのため、システムを導入される組織がやらなくてはならないのが「要求定義」です。

典型的な開発プロセスは、「要求定義」⇒「要件定義」⇒「基本設計」⇒「詳細設計」⇒「実装」⇒「単体テスト」⇒「結合テスト」⇒「総合テスト」⇒「受入れテスト」と進みます。

そんな中、リリース後のシステム不具合の原因の８割は「考慮漏れ」と言われています。そのため、「要求定義」、「要件定義」、「基本設計」など、上流工程でどれだけ品質を作りこむかが重要となります。

要求定義と要件定義の違い

製造業で業務効率化、新規顧客サービスを展開するサービス業など、システムで生産性と顧客満足の向上を目指す組織が、どのような機能をシステムに求めるかを文書化するのが要求定義となります。システムベンダーにRFP（Request For Proposal、提案依頼書）を出して、見積等をもらう際に、要求定義書が添付されているとシステム化に関する認識の齟齬が回避されます。

システムを自社開発している企業以外は、システムを外注します。SaaS等のパッケージシステムを使うケースや、独自のシステムを委託開発してもらうこともあるでしょう。その際にパッケージソフトウェア会社、受託開発会社が要件定義を行います。要件定義をまとめるためにはシステムの知識が必要だからです。

要求定義と要件定義の違いは下記の通りです。

• 要求定義：システム利用組織が組織内もしくは組織外向けのシステムで、システムで実行すると決定した項目に対して、必要な条件や能力を明確化して文書化し経営責任者の合意を得たもの
• 要件定義：要求定義で明確になったものに対して、技術的達成が可能な方法や解決策を文書化し、システム仕様の基盤となるもの

システム依頼主が作成した要求定義をシステム会社やシステム開発会社が精査し、技術的要件書としてまとめたものが要件定義書です。要件定義書はシステム依頼主とシステム開発者が合意し、依頼主の承認を得たものでなくてはなりません。一旦要求定義書の合意がされたら、その後のシステム化では要求定義書がシステム化プロジェクトでの共通認識となっていきます。

要求定義工程の考え方

プロジェクトの目的を明確化

要求定義工程に進む前にシステム化を目指すに至った課題と、どうするためにシステムを入れるのか、システム化プロジェクトの目的を明確にします。システム化のほとんどは何かの改善や効率化であり、まず現状(As-Is)がどの様な状態で、その様な形が理想の形（目的が達成できる：To-Be）なのかを明確にします。

現状(As-Is) から 理想の形（目的が達成できる：To-Be)

As-Isの業務フロー図を描き、To-Beの業務フロー図を作成すると業務の可視化ができます。As-Isの業務フロー図と、現在の業務の課題を照らし合わせて解決策を議論し絞り込みます。そして業務改善できるところ、システム化によって効果が得られるところを見つけ出し、To-Beのフローを作っていきます。

QCD（Quality:品質、Cost:費用、Delivery:納期）

QCD^*を考えて、プロジェクトでやること、やらないことをはっきりさせ、ステークホルダーの合意を取ります。プロジェクトによる効果目標は導入後に効果測定できる様に「具体性」、「計量性」、「達成可能性」のあるものにするのが良いです。

*QCDとは

・Q (Quality) – 品質

・C (Cost) – 費用

・D (Delivery) – 納期

要求定義の進め方

プロジェクト憲章

要求定義の最初にプロジェクト憲章を作るのがお勧めです。

プロジェクト憲章の記述内容は下記の通りです。

• プロジェクトの目的
• プロジェクトの目標と成功基準
• ハイレベルな要求事項
• ハイレベルなプロジェクト記述、アウトライン、および主要成果物
• 全体のリスク
• 要約マイルストーン・スケジュール
• 事前承認された財源
• ステークホルダーの一覧
• 承認要求事項
• 終了基準
• プロジェクト・マネジャーとその責任と権限
• プロジェクト憲章を許可するスポンサーあるいは他の人物の名前と地位

（出典：PMBOKガイド 第6版）

目的

プロジェクトの目的では、これから作るシステムで「誰が何をしたいのか」、「なぜ必要なのか」を記載します。この目的はプロジェクトに関わるメンバー間での共通認識として徹底させなくてはなりません。

業務要件から非機能要件への流れ

業務要件工程では、これから作るシステムが業務やサービスを通して「誰にどのように使われるか」、「なぜ使われるのか」を利用者要求に対し、理解を示すとともに、「システムの対象となる業務を洗い出し業務フロー図などで記載」します。

機能要件では、業務要件をインプットとして、システム化に必要な機能や性能を洗い出し、「どの部分をどのようにシステム化するかの具体的な手段を決めて」いきます。

システム化を考慮して要求は機能要求（Functional Requirement）と非機能要求（Non-Functional Requirements）に分けることができます。

別の見方で、要求にはビジネス要求（経営戦略や事業方針に基づく要求）、事業部門要求（当事者部門の要求）、ソリューション要求（ビジネス要求と事業部門要求に適合した課題の解決策）があります。

業務要件

業務可視化

機能要求をまとめる上で、対象業務をしっかりと可視化することが必要です。可視化とは形のないものを目で見てわかる様にすることです。業務プロセスは形として見えるものではなく、主観で理解が変わってしまい、見落としてしまうこともあります。このように通常では目に見えないものを見える状態にし、共通認識を得ることを可視化と言います。

業務可視化には下記のメリットがあります。

• 各人様々な業務の仕方ある中で、誰もが提携の業務を遂行できるようになる
• 属人化の原因から、制度やルール、運用を見直すことができる
• 業務プロセスに潜む非効率化を把握できるので、優先的に改善策を検討できる
• 全ての業務内容を挙げることで、システム導入時の要件が明確になる
• 集中度が高い業務や課題を抱えている業務は顕在化し、業務を最適化できる
• 業務のムリ・ムダ・ムラが把握でき、コスト削減や業務の効率化に繋がる
• 市場ニーズとマッチする業務に注力でき、顧客満足度の向上が図れる

可視化のためには、業務を行う担当にヒアリングや、担当の近くに張り付いて業務を見ながら文書化シャドーイングという手法があります。ヒアリングやシャドーイングを通して理解した業務の流れを「業務フロー」として図式化し、業務一覧を作ります。

「業務フローの書き方ガイド」で、業務フローに階層レベルがあること、最初は粒度が粗い会社レベルから始めて、部署レベル、業務レベルと段階的に詳細化することを説明しています。

「業務フロー書き方ガイド」は下記ボタンからダウンロードできます。

業務フローから業務一覧作成

業務フローや業務一覧を作成するためには、業務を実際に実施している人にヒアリングする事が重要です。ヒアリングをしている過程で解決策のヒントを得ることもできます。

対象とする業務範囲を構造的に捉え、上位レベルからから段階的に整理します。一般的に組織体系を基にして作成していきます。この成果物を「業務体系表」と呼びます。

To-Beの業務フローを元に業務要件を記述していくには5W2H (What, Who, When, Where, Why, How, How much)を確認ポイントにして記載すると漏れがありません。

業務フローの粒度の粗いものから順に、業務一覧表も大分類、中分類、小分類と詳細化していきます。

多くの方がなじみ深いハンバーガー店舗の業務例で、業務フロー図と業務一覧の関係を業務フロー図と業務一覧の関係は下記のイメージになります。

機能要求

機能要求とは業務を果たすためにシステムに入れこむ必要のある機能的効果、つまり働きです。

システムとしては「何か（What）」として捉えられることが主軸となります。 例えば、次の様に機能要求があります。

例えば、次の様に機能要求があります。

1. 注文を受けて、入力する。
2. 指定の時間が経ったら、スイッチをオフする。
3. 指定日に給与を支払う。

機能要求は一つのまとまりとして捉えられます。最小の機能のまとまりを組み合わせて、より大きな単位の機能として扱うことができます。

非機能要求

非機能要求はシステムが機能要求を満たす上での特性となります。非機能要求は業務に直結しない内容になるため、イメージし難いという特徴があります。要求定義工程において非機能の要求項目が漏れやすいため、システム開発者との共通認識を持つことが難しいと言われています。そのため、情報処理推進機構(IPA)では課題解決のために「非機能要求グレード」を規定しています。

可用性

システムサービスを継続的に利用可能をするための要求

性能・拡張性

システムの性能、および将来のシステム拡張に関する要求

運用・保守性

システムの運用と保守のサービスに関する要求

移行性

現行システム資産の移行に関する要求

セキュリティ

情報システムの安全性の確保に関する要求

システム環境・エコロジー

システムの設置環境やエコロジーに関する要求

さらには具体的に非機能要求として挙げるべき項目が細分化されています。

大項目	中項目
利用性	・継続性　・耐障害性　・災害対策　・回復性
性能・拡張性	・業務処理量　・性能目標値　・リリース拡張性　・性能品質保証
運用・保守性	・通常運用　・保守運用　・障害時運用　・運用環境　・サポート体制　・その他運用管理方針
移行性	・移行時期　・移行方式　・移行対象（機器）　・移行対象（データ）・移行計画
セキュリティ	・前提条件・制約条件　・セキュリティリスク分析　・セキュリティ診断　・セキュリティリスク管理　・アクセス・利用制限　・データの秘匿　・不正追跡・監視　・ネットワーク対策　・マルウェア対策　・Web対策
システム環境・ エコロジー	・システム制約/前提条件 ・システム特性　・適合規格　・機材設定/環境条件　・環境マネジメント

ソフトウェア品質とは|上流工程が重要|品質を学ぶ でご紹介した下記二つの不具合起因の障害例は非機能要件に関しての考慮漏れが原因となっている可能性が高いです。

この様に、リリース後にシステム不具合が起きることがあります。製品やサービスが市場に出てからの不具合は、修正が大変などころか、ブランドにも傷がついてしまい、信用も失いかねません。

＜不具合起因の障害例＞

• みずほ銀行、システム障害
• NTTドコモ通信障害

「非機能要求」とは解決策が機能するための環境条件、性能、品質などで、地味な割には見落とした場合に大きなリスクとなるものです。上記の非機能要求グレードに従ってもれなく記述できる様にしましょう。

要求定義の進め方ガイド ダウンロード

具体的な要求定義書に記載する内容については、下記ボタンから「要求定義の進め方ガイド」をダウンロードして下さい。