本記事ではシステム開発における要件定義の全体を書いてみます。
要件定義とは何か、要件定義で決めること、要件定義のスキルとその学習方法など全部で14個の視点をカバーしました。おもに、情報システム部の担当者あるいはIT企業で要件定義を担うエンジニアのかた向けです。
要件定義とは何？
はじめに要件定義とは何でしょうか。
簡単にいうと「どんなシステムを作るかを決めること」です。
システムが対象とするユーザーやユーザが成し遂げたいこと、そしてシステムの機能や画面イメージなどを含みます。
もう少し難しい言葉で定義すると「開発システムに実装する特性の決定」です。解説は下記の記事にありますので、要件定義そのものを詳しく知りたいかたは合わせてご覧ください。
要件定義の目的
要件定義は何のためにおこなうのでしょうか。
それは「ユーザーにとって価値のあるシステムを開発するため」です。
ユーザーの何らかのニーズを満たし、ユーザーが成し遂げたいことがシステムで実現できるようにすること。それがシステムの価値であり、要件定義をおこなう目的です。
逆に言えば無駄なシステムを作らないためとも言えます。ユーザーの要求が汲まれていない、ユーザーの要求が汲まれていても複雑すぎて使えない、などといったことが起きないようにシステムで実装したい特性を定義します。
ユーザーは無駄なシステムにお金と時間をかけたくありませんし、エンジニアも無駄なものを作りたくありません。エンジニアもユーザーに喜ばれるシステムを開発したい。そのために要件定義を行います。
要件定義の目的を達成するために、要件定義で決めること、要件定義で製作するもの、要件定義の流れといった方法論を活用し、ユーザーにとって価値のあるシステムを開発します。
要件定義の効果（メリット）
要件定義をおこなうとどのような効果があるのでしょうか。
- ユーザーの価値そのものを明らかにできる
- 無駄な開発を最小化できる（コスト・時間）
- 手戻りを最小化できる（コスト・時間）
- 開発の規模が分かる（コストと工期の見積もり）
- 開発ロードマップが描ける
- 次工程の設計ができる
- 受入テスト仕様書を書ける
要件定義でのセッション（ディスカッション）を通じて、ユーザーとエンジニアの双方がシステムの価値を明確にできるという効果があります。実はユーザー自身が価値について曖昧だったり、うまく表現できなかったりします。そこでユーザーとエンジニアの対話によって価値を明確にし、システムでの実現方法を可視化し明確にします。
また、ユーザーがシステムを通じて成し遂げたいことに対して、機能などの不足や超過は双方のコストと時間の無駄になります。要件定義による開発範囲を決めることで、不足や超過といった無駄な開発を防ぎます。
さらに、要件定義を経てシステムの全体像が見えてきます。システムの全体像が分かると、システムの開発規模が判明し、稼働開始時期やそれまでにかかる費用を概算で見積もることができます。要件をもとに工数とコストを見積もる手法は別途書籍などでも紹介されていますので参照してみてください。
要件定義のリスク
要件定義では何を注意すればよいでしょうか。要件定義には下記のようなリスクがあります。
- 要件が漏れる
- 要件を誤る
- 属人的になる
- 要件が決まらない（終わらない）
- 揉める（関係の悪化）
要件が漏れたり誤ったり、または決まらないことによってユーザーとエンジニアが揉める、というのはシステム開発において頻度高く出現するリスクです。漏れや誤りに気付くのは要件定義よりも後のフェーズ、たとえばユーザー受入テストになることが多く、そこからの手戻りは難しいです。そのため、開発プロジェクトの第二期（フェーズ2）として次期開発のテーマに設定するか、もしくはプロジェクト期間を延長してでも実装するということになります。いずれもコストと費用が増えるリスクです。
主要な要件が漏れたり誤ったりすると、ユーザー受け入れフェーズで揉め事になり、関係性が悪化し、最悪の場合はプロジェクトの中止や訴訟といった事態を招きます。
これらリスクをいかに低減させられるかが、私たち情報発信者の責任と価値であり、また企業側の努力でもあります。
なお、要件定義はツールやサービスによって効率化したり高度化したりできますが、基本的には人間同士でおこなわれます。ユーザーの成し遂げたいことが最大限実現できるよう、ユーザーにとって価値のあるシステムを開発できるよう、要件定義のリスクを知り、要件定義の手法を活用します。
プロジェクト全体における要件定義の位置づけ
ウォーターフォール型の開発プロジェクトにおける要件定義フェーズの位置づけは下記のとおりです。
- システム企画
- 要件定義
- 基本設計
- 詳細設計
- 開発
- 単体テスト
- 結合テスト
- システムテスト
- ユーザー受入テスト
- 教育
- 移行
- 運用開始
プロジェクト全体では序盤にあり、一般的には上流工程として位置づけられます。ユーザーにとっての価値の実現方法が要件定義フェーズで明らかになり、要件定義以降の工程ではその成し遂げたいことを詳細化し、プログラムに書くことでシステムが開発されます。
なお、要件定義で決めたことをユーザーが実際の体験（操作）として確認できるのはユーザー受入テストのタイミングになります。ユーザーにとっては確認できるまでに長い空白があることはウォーターフォール型開発のデメリットです。そのためにも要件定義の段階で画面イメージを確認して、実際のシステムの動きを想定した要件定義をしておくことが重要です。
要件定義で決めること
ユーザーにとって価値のあるシステムを開発するために要件定義では何を決めればよいのでしょうか。要件定義で決めることは下記のとおりです。
- 仕事の流れ（業務フロー・ユーザーストーリー・UXなど）
- 画面（UI）
- 機能
- 非機能
- 実現アーキテクチャ（インフラ・言語・ライブラリ・フレームワーク・データベースなど）
- データ（マスタ・トランザクション）
価値あるシステムを作るために最も重要なこと。それはユーザーがシステムでどのような体験をするかです。ユーザーの体験を明らかにするためには仕事の流れを定義し、ユーザーがシステムを使う局面と流れ、そして具体的に得られる便益（ベネフィット）を洗い出します。
また、要件定義の段階から画面のイメージを用いて話すこと、ユーザーがシステムのイメージを湧きやすくなり、より具体的な要求を話す（引き出す）ことができます。漏れや誤りをなくすためにも画面は重要です。
一方で、開発する側は実現するための方法であるアーキテクチャを考えます。実装の限界がありますので、「なんでも作れる」ではなく、「これなら作れる」を見出します。
要件定義のインプット
要件定義をおこなうために活用できるインプット、すなわち入力情報は下記のとおりです。
- システム企画書（前フェーズのアウトプット）
- 事業目標や経営からの期待など
- 制約条件（いつまでに・いくらまでなど）
- 既存の業務マニュアル
- 既存の業務レポート（紙・FAX・PDF、Excel、PowerPointなど）
- 現行システムそのもの（ある場合のみ）
要件定義では、インプットとなる既存の情報を参照し、システムの要件仮説を立ててからヒアリングにのぞむと良いです。ゼロから要件を聞くよりも、仮説である要件を投げかけたほうが具体的な議論ができます。そのため、既存の資料やこれまでのプロジェクトフェーズで製作された文書を読み込み、ユーザーの価値や画面のイメージ、そして必要な機能の仮説などを立てます。
現行システムが存在する場合には、現行の画面やマニュアル、課題、これまでの改善の取り組み、ソースコードなどを確認します。
なお、新規事業などで既存の業務が存在しない場合には、類似の業務を調べておくと良いでしょう。
要件定義のアウトプット（成果物）
要件定義フェーズで製作する成果物（アウトプット）は下記の通りです。
- 要件定義書
- 添付 業務フロー図
- 添付 機能要件一覧表
- 添付 非機能要件一覧表
- 議事録
- ヒアリングメモ
基本的には要件定義書というひとつの文書にまとめて記載します。要件定義フェーズでは前述の「要件定義で決めること」で決めた内容を明文化し、ステークホルダーで合意されていることを目指します。なお、業務フロー図など図解が必要な文書は別添とします。
また、議事録やヒアリング時のメモやホワイトボードの写真も併せて成果物として残しておきます。
要件定義の進め方
要件定義フェーズはどのように進めるのがよいでしょうか。要件定義の進め方の例を挙げると下記の通りになります。
- 開始判断
- 計画
- 準備
- 要件定義インプットの分析
- 文書化（仮説）
- ヒアリング・観察
- 振り返り
- 文書化（実績）
- レビュー
- まとめ
- 終了判断
前フェーズであるシステム企画が完了していることを開始条件として判断します。
そして要件定義フェーズのスケジュールや体制、実施内容などを計画します。
計画を終えたら、準備、そしてインプット資料を読み込み、仮説ベースで要件を書き起こします。仮説をもって、ユーザーへのヒアリングあるいは現場見学をおこない、実績ベースで要件を書き直します。
その後、文書のレビュー、アウトプットの最終まとめをおこない、要件定義の終了を判断します。
要件定義の参加者と役割
要件定義に参加すべき人は誰でしょうか。要件定義フェーズ全体の参加者と、ヒアリングといった要件定義セッションの参加者を分けて考えてみましょう。
要件定義フェーズ全体
- 要件定義の経験者
- 開発対象の業務が分かる人（依頼側・作る側の双方）
- 実装アーキテクチャを選定できる人
要件定義フェーズ全体では要件定義の経験者が必要です。要件定義の計画立案、工程の管理、文書の粒度や書き方などを計画および管理することが目的です。また、システムの対象が既存の業務であれば、その業務に携わる現場の方とその業務領域におけるシステム開発の経験があるエンジニアをアサインします。
また、開発アーキテクチャを選定できるエンジニアをアサインし、開発上の制約事項などを確認します。
要件定義セッション（会議体）
- セッションの進行（業務が分かる人）
- ユーザー予定者
- 議事記録者
要件定義セッションでは、会議の進行できる人をアサインします。会議を進行する人は対象業務に理解があるか、要件定義の経験がある方が望ましいです。会議進行者はユーザー（大半の場合は該当業務が分かる現場部門である）に対して、システムに対する要求を聞き取り、掘り下げ、ユーザーの壁打ち相手になります。
聞き取った内容を議事録に記載する人は進行する人と分けたほうがよいです。書きながら話すことは難しく、書き取りミスや進行の妨げになります。また、音声記録をして後日議事を書き起こすことは、再度会議と同じ時間を消費してしまうため非効率になりがちです。
そのため、人工知能を搭載した議事録作成ツール・サービスを導入するか、議事記録者を別途アサインします。また、各セッションを終える際に、セッションで決まったToDoを読み上げて双方で確認できると良いです。
要件定義の契約
要件定義の契約形態には二種類あります。
- 準委任契約
- 請負契約
準委任契約では要件定義の作業に対して対価が発生し、請負契約では要件定義の成果物に対して対価が発生します。請負契約では成果物の瑕疵担保責任があり、成果物の誤りがあった場合は無償で修正する義務が生じます。
なお、要件定義開始時点にシステム開発規模が判明していない場合は要件定義のみを準委任契約で締結し、以降の基本設計からシステムテストまでを請負契約で締結することが多く見受けられます。一方で、システム開発規模が判明している場合はプロジェクト全体を請負で一括契約するケースもあります。
要件定義の終了基準
要件定義を終えたといえるのはどのようなときでしょうか。
- 成果物が承認された
- 要件定義の作業報告書が承認された
- 次工程以降の工数と費用が見積もれた
要件定義の終了基準は基本的には契約書に記載しておきます。契約書に記載された基準が満たされたときに作業完了とします。
たとえば、要件定義の成果物が双方で合意された、あるいは作業報告書が承認されたときです。要件定義以降の契約が連続するときには、次工程以降の見積もりができていることを終了基準とする場合もあります。
契約上の終了基準は上記のとおりですが、大切なことはユーザーにとって価値のあるシステムとなる要件定義ができたか否かです。そのために要件定義で決めるべきことが決め決めれたかどうかは別途振り返りが必要です。
要件定義に必要なスキル
要件定義を行うにはどのようなスキルが必要になるでしょうか。ビジネススキルとテクニカルスキルに分けてみてみましょう。
ビジネススキル
- 対象業務の知識
- セッションをリードするスキル（一般的にはファシリテーションスキルと呼ばれます）
- 質問力
要件定義をおこなうためにはユーザー（＆業務）の理解が欠かせません。システムの対象となるユーザーの業務知識を習得できていることが大切です。特に既存業務がある場合は、ユーザーの話を理解して要件に変換していくため、業務知識もしくは業務経験が必要です。一方で、新規業務あるいは新規事業の場合は、類似の業務知識を取得しておくとよいでしょう。
加えて要件定義セッションを進行できるスキル、そしてセッション内で要求を聞き出す質問力が求められます。いかにユーザーから要求を量と質ともに引き出せるかはファシリテーションスキルと質問力によるところが大きいです。
テクニカルスキル
- UI・UXデザインの手法
- 実装アーキテクチャーの知識
- データベース設計の知識
テクニカルスキルでは、画面やユーザー体験を中心に要件を整理していきますので、UIおよびUXの設計手法を習得します。
また、要求を実現するためのアーキテクチャーの選択肢を引き出しとして習得します。インフラ（サーバー、ネットワーク、セキュリティほか）やアプリケーション（フロント、バックエンド）、データベースなどの実装知識です。
また、システムが扱うデータ設計のためには、ER図が書けるといったデータベース論理設計のスキルが必要になります。
要件定義の学習方法
要件定義のスキルを習得するためにはどのような学習方法があるでしょうか。例えば下記のような学習方法があります。
- 本
- 動画
- 研修
- 聞く
- 過去の成果物を見る
- OJT
習得のハードルが低いのは本を読むことです。ちなみに要件定義を学べる本については以下にまとめてあります。
次に動画サイトです。Udemyといった技術系の動画サイトで要件定義の動画を視聴できます。また、研修会社が提供する研修を受講する方法もあります。
その他、社内の経験者に聞く、もしくは社内にある過去プロジェクトの成果物を参照する、またはOJTといった方法もあります。
おわりに
以上、要件定義を14個の論点に分類してみてきました。
要件定義の目的である「ユーザーにとって価値のあるシステムを開発するため」を実現するための一助になれたら幸いです。
