システム開発における「要件定義」の重要性と、要件定義書のサンプルを紹介

TOP
コラム
システム開発における「要件定義」の重

はじめに

自分が利用したいシステムを一人で全て開発するのであれば、目的のシステムの概要や計画、設計といったものは自分の頭の中にあれば、十分進めていくことができます。途中で作業できない期間があったり、気が変わって方向転換したりということがあっても誰にも迷惑はかかりません。そのため、開発前にしっかりスケジューリングして計画通りに進めていくことは少ないでしょう。

しかし、開発するシステムの規模にかかわらず、複数人で作業を進める場合や、クライアント等の第三者から開発の依頼がある場合に口約束だけで開発を進めてしまうと、エンジニア同士、エンジニアとクライアント間で認識に相違が発生する可能性が出てきます。そのため、あらかじめミーティング等の話し合いの場を設けて、ステークホルダーとして関わる人達の間で方針や概要を決めた上、以降もそれらを確認できるようにドキュメントとしてまとめておく必要が出てきます。

今回は、システム開発の開始の段階で行われ、その後のプロジェクトの行方を左右すると言っても過言ではない「要件定義」がどのような工程であるか、また「要件定義」の工程における成果物である「要件定義書」に組み込むべき内容のサンプルについて紹介していきます。これからSE(システムエンジニア)を目指そうと思っている方、すでにSEであるものの、社内に要件定義書のサンプルがなく、毎回クオリティに差が出てしまって困っている方、フリーランスのエンジニアになるため、要件定義ができるようになっておきたいと思っている方はぜひご覧ください。なお、より要件定義を深く理解してもらえるよう、初めに各種開発モデルについて簡単に解説した上でサンプルを紹介します。すでに十分理解できているという方は「要件定義では何をするか」の部分から読み進めてください。

開発モデルをおさらい

ITにおけるシステム開発には、正確かつ効率良くプロジェクトを進めるための「開発モデル」と呼ばれる手法が複数存在しています。開発する内容によって適したモデルは異なるため、PM(プロジェクトマネージャー)・PL(プロジェクトリーダー)やエンジニアは、その時のプロジェクトに最適なモデルを選んで採用します。今回は、多くの企業で標準化されている代表的な4つの開発モデルについて紹介します。なお、以下4つの開発モデルはもちろん、いずれもモデルであっても、基本的に要件定義、もしくはそれに相当する工程が少なからず発生します。

ウォーターフォール

開発モデルの中でも特にシンプルで理解しやすい手法であり、各工程が大きく、上流工程と下流工程の2つに分けることができます。上流工程には、今回取りあげる要件定義と基本設計(外部設計)・詳細設計(内部設計)が含まれており、下流工程には実装、各種テストが含まれます。上流から下流の工程にかけて順にプロジェクトを進めていくことから「ウォーターフォール(滝)」という名称がつけられています。基本的に、要件定義はPM・PLやSEがクライアントと共に進める工程で、基本設計、詳細設計はPLやSE、下流工程はPL、プログラマー、各エンジニアが進めていく傾向にあります。シンプルなので計画通りにプロジェクトが進めやすい反面、仕様変更があった場合の時間・コストが多くかかってしまうというデメリットがあります。そのため仕様変更が発生することの少ない開発に向いているモデルと言えます。

アジャイル

スタートアップや、ベンチャー企業等において、開発にスピードが求められる場合に向いているモデルです。開発の流れ自体はウォーターフォールと同様ですが、システム全体における上流工程・下流工程ではなく、システムを細かく分けた上で、小分けにしたシステムごとに要件定義からテストまでの工程を短いサイクルで行うこととなります。開発が完了した一部分のみを先にリリースすることも可能なため、結果としてリリースまでの期間を短くすることが可能な他、仕様変更や新たな要望があった場合も部分的な対応のみで済むので、ウォーターフォールよりは用意に対応できるというメリットがあります。同時に、プロジェクト全体としてのスケジュール管理がしづらいというデメリットもあります。Webシステムやゲーム等、仕様変更が前提となるようなサービスに適しているモデルと言えます。

プロトタイプ

名称にもあるように「プロトタイプ(試作品)」をユーザーに提供しながら開発を進めていくモデルとなります。アジャイルと同様、スケジュールが管理しづらい、プロトタイプを構築する分のコスト・時間が別途発生するというデメリットがあるものの、システムのプロトタイプがあることで、クライアントが望む機能をイメージしやすく、抱えている課題点もクリアにしやすいというメリットがあります。クライアント側がITの知識を持っていないということは珍しくないので、そういった場合は完成形を伝えることが難しく、要件定義の段階で詳細まで詰められないこともあります。そのため、具体的な完成形のイメージがない状態で、クライアントのヒアリングをスムーズに行いたいといった場合におすすめのモデルと言えます。

スパイラル

アジャイルに非常に良く似たモデルで、システム全てが完成していない状態でリリースを行うので、開発のスピードアップが計れます。ただし、大きく違うのは、アジャイルはあくまで完成して品質が保証されている部分のみをリリースするのに対し、スパイラルでは、品質の保証されていない、言わば未完成の状態でクライアントに利用してもらうことになります。そう聞くと無責任な開発手法のように思えますが、実際はスパイラルモデルを採用することで、クライアントの要望や問題点をリアルタイムに確認し、素早くシステムに反映することが可能となります。プロトタイプの完成時点では、クライアント側からどの程度の要望や修正点が出てくるかは未知であるため、その後、どれだけのフェーズやコスト・時間がかかるかが予測しづらいというデメリットがありますが、プロジェクトにある程度余裕があり、よりクライアントの要望に応えられるシステムを開発したいという場合には、適したモデルと言えます。

以上が代表的な開発モデルとなります。それぞれにメリット・デメリットがあるため、開発するシステムや、状況、目的に見合ったモデルを選択することで、プロジェクトを効率的に進められるようになります。また、これらのどのモデルを採用する場合であっても欠かせないのが、要件定義です。

要件定義では何をするか

要件定義における「要件」を出すのはクライアント、まとめるのがエンジニア側となります。PM・PL、SE等が繰り返しクライアントにヒアリングを行った結果として出てきた要望を具体化していきます。必要な機能や機器等を、自社のナレッジを用いながら決めていき、実現できるもの・できないものについてはクライアントと認識合わせを行っておきます。同時に、プロジェクトの方針や進め方、全体のスケジュール、予算等についても決める必要があります。

クライアントの要望を漏れなく聞き取り、それぞれの要望に対する詳細事項を決め、最終的に「要件定義書」として記録・作成し、この工程の成果物とするという流れが、一般的な要件定義の方法です。なお、要件定義書は、現場のエンジニアや管理者だけではなく、クライアントや経営層が確認することもある重要なドキュメントの一つとなるため、5W1Hを用いて、誰が見てもシステムの全体像を把握できるようにわかりやすく完成させる必要があります。また、要件定義書の更新・修正・追記を行った場合は、誰がいつ何のために、何に対して実施したかを記録し、ドキュメントのバージョン管理を適切に行うことも大切です。バージョン管理が行われていないと、文書が改竄されたとしても誰も気づくことができず、信憑性のない文書となったり、プロジェクトに混乱を招いたり、クライアントの信用を失ったりという状況になりかねないためです。

要件定義書に組み込むべき内容のサンプル

要件定義書に決まったフォーマットはないので、企業やプロジェクトごとに独自のドキュメントが作成されていることでしょう。しかし、記載されている内容は大きく分けると「概要」「業務要件」「機能要件」「非機能要件」に該当するものであり、これらは共通して記載があります。今回は、要件定義書の内容のサンプルとして、組み込むべき内容について紹介していきます。

概要

どういった背景があって、何を目的とし、どのようなシステムの開発を目標としているかという点の明記、プロジェクト内で使われる専門用語を定義、システム構成の文章での説明や図示等を行う部分です。なお、概要で作成する図は「システム構成図」と呼ばれ、パソコンやサーバーといったハードウェアを中心として、データの流れ等を表した図のことです。ネットワーク構成図やサーバー構成図は、また別に作成されることとなります。

業務要件

クライアントへのヒアリングでわかったことや、RFP（Request for Proposal）と呼ばれる書類がある場合は、その内容を含めて記載することとなります。なお、RFPとは、システムの必要要件や、解決したい内容、希望する機能等をクライアント側が取りまとめた書類のことです。具体的には、プロジェクト内で行う業務詳細や、開発規模、開発に要する工数、開発場所、システム化を実現する機能、ステークホルダーや権限といった内容についてまとめます。他にも、システム導入前後の業務全体の流れを把握するためのプロセス図やフローチャート、業務内容の一覧や、各業務内容の定義や詳細を一つずつ説明したページを含めることも多いです。

機能要件

業務要件よりさらに細かい内容を記載する必要があり、ハードウェア、ソフトウェア、ネットワーク、アプリケーションといった各分野ごとの構成図や、実際にユーザーが利用するインターフェース(画面)の一覧や遷移図、レイアウト、また帳票が必要な場合は、帳票の概要、一覧、レイアウトについてもまとめます。システム内で必要となるバッチ処理や、データベースのテーブル関連図(ER図)、外部システムとの連携が発生する場合は、外部システムの関連図、外部インターフェースの一覧、定義についても機能要件で記載が必要です。

非機能要件

「非機能要件」とは、システムを稼働するために直接必要とはならないものの、システムの品質や満足度を高めるために必要な機能のことを表しています。処理速度の向上や、セキュリティ関連のシステム、教育といった内容が該当します。なお、基本情報技術者試験等を運用するIPA(独立行政法人情報処理推進機構)では、非機能要件について細かく定義しています。システムの稼働時間、停止予定といった「可用性」、システム化された機能の状態や業務量、今後の見積もりといった「性能・拡張性」、トラブル発生時の対応レベルに関する「運用・保守」、移行に関する「移行性」、不正アクセス防止や利用制限といった「セキュリティ」、耐震・免震、騒音、消費エネルギー等の「システム環境・エコロジー」といったものが該当するとしています。

要件定義書のサンプルフォーマットを入手したい場合

この記事では、要件定義書に含めるべき内容を文章で紹介してきましたが、実際にフォーマットを入手したいという方もいることでしょう。調べてみたところ、要件定義書のサンプルを提供しているサイトはいくつかありました。一つは、前述したIPAの公式ページ内「超上流から攻めるIT化の事例集：要件定義」の中で、機能要件（プロセス）、機能要件（データ）、機能要件（インターフェイス）、非機能要件のカテゴリに分け、それぞれ数種類のサンプルが用意されています。「超上流から攻めるIT化の事例集：要件定義」で検索してみましょう。ものによってはサンプルをPDFで、実際に書き込めるフォームはExcel形式(拡張子は.xlsx)で提供されているので、必要な方をダウンロードしてみましょう。

また、分野が異なりますが、環境省では「自然環境局総務課動物愛護管理室」に関する要件定義書のサンプルがPDFで提供されており、「自然環境局総務課動物愛護管理室要件定義書」で検索すると出てきます。フォーマットは用意されていないものの、基本を忠実に再現して作成されているドキュメントとなるので、初めて作成する際の手本とするのにおすすめです。

さらに、様々なビジネス関連の書類のテンプレートを無料で提供している「［文書］テンプレートの無料ダウンロード」というサイトの中にも要件定義書のサンプルがありました。「要件定義書［文書］テンプレートの無料ダウンロード」で検索すると出てきます。Word(拡張子は.doc)形式のデータで、中身は目次のように要件定義書に含める項目が羅列しています。各項目のフォーマットはないので、今回紹介してきたように、要件定義書に組み込む必要のある項目だけを把握したい場合はおすすめです。

要件定義書の作成に役立つサービス

最後に、要件定義書の作成に役立つその他サービスについて紹介します。一つは作図に役立つアイコン素材提供サイトです。「icooon-mono」で検索すると、IT関連にかかわらず多くのアイコン素材が無料で提供されているページが確認できます。業務フロー等の作成に役立つ可能性があるでしょう。また、ネットワーク機器・インフラを提供するCisco社の公式ページ(cisco.com)内でも、無料アイコンが提供されています。Microsoft Visio用、PowerPoint用というようにツールごとに、ネットワーク構成図を作成する際に役立つアイコンが提供されていて親切です。

さらに、IPAの公式ページ内には、「ユーザのための要件定義ガイド第2版　要件定義を成功に導く128の勘どころ」というPDFドキュメントが無料で公開されています。一つ一つの項目が細かく解説されており、全部で500ページ弱と非常にボリュームのある資料なので、詳細を確認したい部分のみを読み込んで作成に生かしてみてはいかがでしょうか。同じく、要件定義書についてより深く学びたい方は、オンライン学習サイトを利用することも可能です。オンライン学習サイトはたくさんあり、プログラミング講座を中心としているものの、中には要件定義書等のドキュメント作成について学べるものもあります。ぜひ自分に合ったサービスを見つけて、学習を進めてみてはいかがでしょうか。

まとめ

要件定義書には一律で決まったフォーマットや記載内容がないので、初めて作成する際は何から手をつけて良いのか迷ってしまうことでしょう。しかし、要件定義はプロジェクトを成功に導くために必要不可欠な工程であり、その成果物となる要件定義書も同様となります。

今回見てきたように、要件定義書には非常に多くのことを組み込む必要があるため、大規模なシステムであればページ数も多くなることでしょう。しかし、実際に記載する内容が企業やプロジェクトによって大幅に異なることはないので、一度作成してしまえば、別のプロジェクトでも汎用的に利用できるようになる可能性があります。これからフリーランスのエンジニアになるに当たって、上流工程である要件定義もできるようにしておきたいという場合や、社内に要件定義書のサンプルがないので、率先してサンプルを作成していきたいという場合は、ぜひ今回の記事を参考に作成してみてはいかがでしょうか。