システム開発とは – 要件定義書 –
要件定義とその目的
まず、「要件定義」とは何なのでしょうか。
それはすなわち、「顧客が必要とするものと、それをどのようにシステム化するかをまとめたもの」です。
要件定義はシステムを使った業務改革・改善が成功するかが決まる工程と言われるほどです。
ウォーターフォール型開発でプロジェクト進行するのであれば、この工程は特に重要で、この工程を疎かにすると、完成したシステムが業務とうまく噛み合わないなんてことも起こり得ます。
なぜ、このようなことが起こるのかと言うと、クライアントとベンダがお互いの共通認識が一致できているのかをしっかりと確認していないことにあります。クライアント側の「このくらい分かっているだろう」や、ベンダ側の「ここの作業はこんな感じだろう」という予想が悪い方向に進んで、システム開発の失敗を招いてしまいます。
それが起こらないように大切なことが、ヒアリングです。この段階でクライアント側は自社には何が必要で、どんな課題を解決したいのかを、言語化する必要があります。
そして、ベンダ側はクライアントの要求項目をシステムに当てはめて、どんなシステムを作るのかをイメージできる必要があります。また、ベンダ側はクライアントが言語化する以外にも必要なものが存在する可能性が高いことも意識しておきましょう。
しっかりとしたヒアリングによって得たクライアントの要求をシステムに落とし込み、ドキュメント化したものを「要件定義書」と言います。この要件定義書は共通認識が言語化された証拠となり、プロジェクト成功へと導く道標となります。
要件定義書に記載するべき内容
それでは、要件定義書には何が記述されているべきなのでしょうか。要件定義書に書かれている項目は企業ごとに異なります。
基本的には、要件定義書は業務要件、機能要件、非機能要件に決定され、その順に書かれます。
今回はそれぞれの要件で代表的なものを紹介していきます。
業務要件
業務要件は主にシステム化と業務について書かれます。
・システムの目的
なぜそのシステムを作るのか、そのシステムで何を達成するのか、そのシステムで何を解決するのか、を明記します。
・システムを使用するユーザ
誰のためのソフトウェアなのか、エンドユーザーはどのような人なのか、システム自体が社内で使うものなのか、それとも社外のユーザが使用するのか、と言った項目を明記します。
・システム化する範囲
既存の業務フローのどこからどこまでをシステム化するのかを記載します。
・現在の業務フロー
現在の業務の流れを見える化するために明記します。
・システム導入後の業務フロー
システム導入後に業務フローがどう変わるのかを見える化するために明記します。クライアントはどのような手順で業務が進んで行くのかを確認することができます。
機能要件
機能要件はシステムについてを明記します。
ここでは主にベンダ目線でのシステムについての記述がメインとなります。
・構成図要件
ハードウェア構成図、ソフトウェア構成図、ネットワーク構成図、アプリケーション機能構成図、などを明記します。クラウド上に構築するのであれば、ハードウェア構成図やネットワーク構成図の代わりにインフラストラクチャ構成図などが使われることが多いでしょう。
・画面要件
システムの画面一覧、画面レイアウト図、画面遷移図など記述します。
・帳票要件
帳票一覧、帳票概要など帳票に関する記述します。
非機能要件
非機能要件では可用性やセキュリティなどの非機能要件についての記述をします。
・可用性
稼働率や目標復旧時間などを記述します。
・運用・保守性
バックアップや運用監視、マニュアルの作成についての記述をします。
・性能
スループットやレスポンスの速さなどの性能目標についてに記述をします。
・セキュリティ
セキュリティをどのように確保するかやシステムの公開範囲などについて記述します。
要件定義書を書き始める前に
要件定義書を書き始める前にいくつかの下準備が必要です。
情報整理をする
ヒアリングで書き出した情報は、ざっくばらんとしているはずです。この情報をまず整理するところから始めます。特にこの段階で業務要件・機能要件・非機能要件と必要な情報に分けておけば、後で楽になるでしょう。
問題分析をする
次に整理した情報から現在の業務の問題を分析します。何が問題で、何が必要なのかを明確にしましょう。そうしなければ、必要機能を正しく導き出すことも出来ないはずです。
クライアントに優しい表現
クライアントのほとんどはベンダ企業で働く人達ほどIT用語に詳しいわけではありません。要件定義書をIT用語で埋め尽くしてしまうとクライアントが読んでも訳が分からず、要件定義書が意味をなさないなんてことが起こってしまいます。
5W2Hを考える
誰のためのシステムか、何を必要とするのか、なぜそのシステムが必要なのか、いつ必要なのか、どこで必要なのか、どのように提供するのか、といった5W2Hをなくしては要件定義はしっかりとしたものになりません。
課題解決を明確にする
上記の項目を引っ括めた上で課題すべき解決とその解決方法を明確にして書き出しましょう。課題解決がはっきりしていない要件定義書では、システム開発が自体のゴールが明確になっていない状態になってしまい、プログラマーも完成イメージが思い描けないまま、システムに取り掛かることになります。
まとめ
今回は前回の提案依頼書に続いて、要件定義書についての紹介をしました。アジャイル型の開発ではそこまで重要視されませんが、ウォーターフォール型開発を進める上では、要件定義書はなくてはならないものです。
今回紹介した要件定義は日本のデファクトスタンダードを元に紹介しましたが、欧米のようなスピード感が求められる環境では、少し違った要件定義書になります。例えば、画面レイアウトや構成図のようなものは一切なく、デザインの資料は全くの別で用意する、または、なしで進めるなんてこともザラにあります。
兎にも角にも要件定義の工程で重要なことはヒアリングです。ヒアリングをする際はただ聞くだけのヒアリングではなく、要件定義書に落とし込むためのヒアリングをすることが重要です。
要件定義書は地図に例えられることがあります。要件定義なしでは目的地がわからない状態となり、プロジェクトの進行が迷子に
なってしまいます。しっかりとしたシステム開発の際は、要件をしっかりと固めることで成功への道が切り開けます。
中小企業をがっつりサポート！
当社では
など、企業のIT化のサポート・DX事業のサポートを行っています。
まずはお気軽にお問い合わせしてください。