現代社会はシステム、ソフトウェアに大きく依存しています。利用者が不自由無く、快適に使えるシステムを動かしているのがソフトウェアです。利用者目線で使い勝手の良いソフトウェアの品質は要求定義、要件定義工程で決まります。

ソフトウェア市場不具合の原因の８割は要件定義での「考慮漏れ」によるものです。そのため上流工程でどれだけ品質を作りこめるかが重要となります。その要件定義作成の元になるのが要求定義書です。

今回は要求定義の位置づけ、QCD、品質との関連について、初めての方でも分かる様に段階的に解説していきます。

要求定義がシステム品質を決める

システム開発は要求定義に始まる

ATMなどの金融システム、自動改札機、スマホアプリ、検索エンジンなど。。。世の中は大きくシステム、ソフトウェアに依存しています。システムは利用者のしたい事を先回りして、期待通りどころか、期待を上回る満足を得られる様に、作られています。

システム開発の初期段階で、利用者がそのシステムに何を期待しているのか、何を求めているのかを可視化し、文書化することを「要求定義」と言います。

製造業では生産管理システムなどの基幹システムを導入して省人化と共に生産性向上、短納期、低コストなど、顧客満足度を上げようとIT化を進めます。サービス業でも顧客が必要な情報を得て、サービスフローに従ってスムースにサービスを受けられる様にシステムを導入します。

システムの企画を通して、開発プロジェクトが立ち上がった後は、下図の様な工程に沿って開発を進めます。これはV字も出ると呼び、プロセスモデルであるウォーターフォールモデルをもとに、各開発工程とテスト工程の関係を表わしたモデルです。

ウォーターフォールモデルにおける、要求定義、要件定義、基本設計、詳細設計は、実装後の各工程に対応するテストレベルと密接に関係します。要求定義の要求記述をテストするのが受入れテスト、要件定義によるシステムの仕様をテストするのが総合テスト（システムテストとも呼びます）。基本設計のシステム設計をテストするのが結合テストです。

ユーザの要求分析・抽出をする要求定義が最初の工程で、要求定義をシステム仕様に落とし込むためにシステム開発者が記述するのが要件定義です。

英語のRequirementは要求、要件の両方の意味があり、特に使い分けしませんが、日本では「要求」と「要件」を使い分けることが多いです。

• 要求定義：プロジェクト当事者が、プロジェクトで実行すると決定した項目に対して、必要な条件や能力を明確化して文書化し経営責任者の合意を得たもの
• 要件定義：要求定義に明確になったものに対して、技術的達成が可能な方法や解決策を文書化したもの

要求定義が重要な理由

リリース後にソフトウェアを利用し始めると不具合が起きることがあります。製品やサービスが市場に出てからの不具合は、修正が大変などころか、ブランドにも傷がついてしまい、信用も失いかねません。

＜不具合起因の障害例＞

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

市場不具合の原因の８割は要件定義での「考慮漏れ」によるものです。そのため上流工程でどれだけ品質を作りこめるかが重要となります。その要件定義作成の元になるのが要求定義書です。

要求定義書はソフトウェア受託開発会社や自社開発会社だけに必要な書類ではありません。基幹システムを刷新しようとしている製造業、業務改善をしようとしているサービス業等でも重要なドキュメントとなります。システムで何をしようとしているのか、どんな機能を入れたいのか文書化して、クラウドサービス、パッケージソフト、開発会社の選定をする前に整理しておく必要があります。

システムを利用する企業でしっかりと要求を整理し、要求定義書を記述することで、システム開発会社との誤解を避ける事ができます。要求定義書で、システム化できなかったり、コストや納期を無視した内容が入っていたりしても、その後の要件定義工程で開発会社が指摘してくれます。まずはしたい事、期待する事をちゃんと文書化することが重要となります。

要求定義書に間違いがあると、ソフトウェアが設計通りに動いても、そもそも設計仕様が間違いだったという事も起きます。設計仕様に基づいて多くのヒト、モノ、カネ、時間をかけて作ったシステムがあるべき姿ではなかったということでは、多大な費用も無駄になってしまいます。ソフトウェア開発に限らず、プロジェクトで何をしたいかが明確でないと、本来の目的と違ったものができてしまいます。何を何のためにする、何をしたいかを整理し、文書化するのが要求定義です。

さらに、要求定義はすべてのステークホルダの合意を得たものである必要があります。ステークホルダーとは要求、あるいは、要求が定めるビジネスや情報システムに関与する人、あるいは、組織のことです。ステークホルダで特に重要なのは経営層です。要求定義書は経営層の承認を得たものでなくてはなりません。

要求工学知識体系（REBOK）について

要求工学知識体系(Requirements Engineering Body Of Knowledge：REBOK アールイーボック) は，要求工学を理解し，活用するための手引きとなる要求工学の知識を実践の視点から整理し，体系化したものです。一般社団法人、情報サービス産業協会（JISA）が刊行しています。（参考資料：要求工学知識体系)

「要求」という言葉は日常でも使われますが、システム開発上ではいくつかの定義があります。IEEE Std 610.12によると、要求は「ステークホルダが問題解決や目標達成に必要な条件、あるいは、能力」と定義されています。

「要求工学」とはシステム開発やソフトウェア開発における、ユーザ要求を組織的、かつ、合理的（工学的）に定義する技術です。ユーザ（利用者）にとって必要なコトをしっかりと理解して最適な解決法を見つけ出すための技術と言っても良いと思います。最終的にシステムのユーザ価値を高め、組織、社会への情報システムの価値を高めるためのものです。 REBOKでは８つの知識カテゴリーがあります。

知識領域	内容
1. 要求工学の基礎	要求とそのスコープや性質などの基礎的事項、機能要求、非機能要求も含む
2. 要求工学プロセス	要求開発、管理のプロセスと主要なアクティビティなどに関する知識
3. 要求獲得	顧客を含むステークホルダを明らかにし、会議、インタビューなどによる要求の引出しに関する知識
4. 要求分析	要求項目を整理し、その間の関係付け、優先順位付けなどを行い、実現すべき要求を明らかにして絞りこむ技術に関する知識
5. 要求仕様化	分析された要求を規定の書式や表現法で記述する技術に関する知識
6. 要求の検証・妥当性確認・評価	要求仕様書に矛盾がないことなどの正当性の確認や、要求仕様書が顧客の要求を満たしていることの妥当性の確認、あるいは、その達成の度合いを評価する過程と技術などに関する知識
7. 要求の計画と管理	要求管理を計画し、その遂行や成果物を管理する技術に関する知識
8. 実践の考慮点	要求工学を実勢する上で有用な知識

QCD（Quality:品質、Cost:費用、Delivery:納期）について

要求定義ではQCDを記述します。

・Q (Quality) – 品質

・C (Cost) – 費用

・D (Delivery) – 納期

何より大切なのは品質です。品質の定義はいろいろありますが、下記が代表的なものです。

・クロスビーの定義：「品質は、『要求に対する適合』である」

・ワイバーグの定義：「品質は、誰かにとっての価値である」

・ジェームズ・マーチンの定義：「システムが本稼働をするとき、どこまで真のビジネス（ユーザ）ニーズに合っているのか」

クロスビーの定義によると、要求に合っていれば品質は良いということになりますが、要求が間違っていてユーザが不満足だということもあります。そのため、ユーザのニーズをしっかりと把握して要求定義をする必要があります。その意味で、要求定義書はとても重要なスタートポイントです。初めが間違うとプロジェクト全体が間違った方向に動いてしまいます。

ソフトウェア開発では費用（Cost）と納期（Delivery）も大切です。要求定義書にはしっかりと費用・納期の記述が必要です。せっかく品質が完璧なソフトウェアが出来上がっても費用が想定を超えて、開発期間が想定以上にかかってしまっては意味がありません。しっかりとステークホルダと合意された費用と納期を記述して関係者の合意と情報共有をしましょう。

要求定義のために業務フロー把握が必須

要求定義を完成させるには現状の業務フローを把握することが必要不可欠です。まずは業務フロー図を作成し、その上で業務プロセスにおける課題をピックアップしていきます。例えば、業務として無駄なものあるのか、またシステムを導入した場合に省力化できることはないかなどを細かく検討していきます。

業務フローを作成する過程では、業務を遂行する実務担当者へのヒアリングも行いながら進めるのがお勧めです。既存のマニュアルなども業務フローを把握する上で、参考になります。

業務フローの書き方がわからない方は下記ボタンより、『業務フローの書き方ガイド』を無料ダウンロードして下さい。