システム開発には欠かせない！「要件定義」とは？
システム開発の現場でたびたび耳にする「要件定義」という言葉について、次のような疑問を持ったことはありませんか？
・要件定義って具体的に何をするの？
・要件定義はどうして重要だと言われているの？
・要件定義で失敗しないためには、どんなことに気を付けたら良い？
そこで今回は、「要件定義って何ぞや？」という方に向けて、要件定義の基本や進め方のポイントなどについて詳しく解説していきたいと思います。
この機会に「要件定義」に関して理解を深めたい方は、ぜひ参考にしてみてください！
※今回の内容は、以下記事の抜粋になっています。完全版はこちらから↓
１．システム開発の全体像
要件定義の詳しい説明に入る前に、まずはシステム開発の全体像について確認しておきましょう。
一般的に、システム開発のプロジェクトは「ウォーターフォールモデル」に沿って進められることが多いです。
「ウォーターフォールモデル」とは、上流から下流へと「水が流れ落ちる」ように、前の工程には戻らないことを前提に、要件定義、設計、開発、テストと1つ1つの工程を確実に完了させながら進めていく開発手法です。
要件定義は、図の通りウォーターフォールモデルの最上流に位置します。
２．要件定義とは？
要件定義とは、ユーザー（システム発注者）の要望をヒアリングした上で、その要望を実現するために具体的にどのような手順でシステムを構築していくべきか、誰が見ても理解できるように文書化する作業のことです。
いわば、「システム開発の土台作り」の工程ですね。
要件定義の重要性
要件定義はシステム開発の初期段階で行われる工程であり、プロジェクトの成否やシステムの品質を左右する非常に重要な役割を担っています。
要件定義が不十分なままプロジェクトが進んでしまうと、次のようなトラブルに見舞われる可能性があります。
・想定していたものと全く違うシステムが出来上がった
・せっかく作ったのにシステムが全然役に立たなかった
・予算が大幅にオーバーしてしまった
・開発スケジュールが大幅に遅延してしまった
・最終的な納期に間に合わなかった
また、後から「実はこんな機能が欲しかった」とユーザーの隠れた要望が明らかになり、開発がやり直しになってコストや時間が無駄になってしまうこともあります。
このようなリスクを避け、ユーザーが求める成果物を決められた期間内に完成させるためには、要件定義の段階で発注側のユーザーと受注側のベンダーが綿密な打ち合わせを重ね、お互いに納得するまでニーズや方向性のすり合わせを行う必要があるのです。
「要求定義」と「要件定義」の違い
要件定義とよく似た言葉に「要求定義」がありますが、この2つは別物であることに注意しましょう。
「要求定義」でシステム導入により実現したいことを明らかにし、「要件定義」でその内容を実現するための方法や手順を定めていくという流れです。
・要求定義：
┗解決したい課題、システム導入の目的、欲しい機能など、システム化によって実現したい要求事項を整理する工程
┗作業者：ユーザー
・要件定義：
┗ユーザー側の要求定義の内容を受けて、それらの要求をどのような方法で実現すべきか定める工程
┗作業者：ベンダー（※責任を負うのはユーザー）
「要件定義」と「基本設計」の違い
もう1つ、要件定義と「基本設計」も混同しやすいので注意が必要です。
「要件定義」が「言葉」でシステムに必要な機能を明確化するプロセスなら、「基本設計」は開発すべき内容を「図」で視覚的にユーザー側へ共有し、システムの完成イメージをすり合わせていくプロセスです。
・要件定義：
┗ユーザーからの要求をもとに、システムに実装すべき機能・性能を定める
┗作業者：ベンダー（※責任を負うのはユーザー）
・基本設計：
┗要件定義の内容を受けて、それぞれの機能の役割をさらに具体化する
例：何をする機能なのか？機能同士はどのようにつながるのか？
┗作業者：ベンダー
３．要件定義の責任はユーザー側にある
ユーザーの要求を実現するための具体的な方法を検討していくのが要件定義ですが、要件定義の最終的な責任はユーザー（発注者）側にあります。
つまり、自社の要望をベンダー側に伝えきれていなかったり、システム化の目的があやふやだったりしたせいでシステム導入が失敗したとなれば、その責任の所在はユーザー側にある、ということです。
ベンダー側も、IT専門知識を活かして要件定義がスムーズに進むよう積極的に支援を行う必要がありますが、元々は
・何のためにシステムを導入するのか？
・システムを使って何を実現したいのか？
といった、ユーザー側の要求が要件定義の出発点となっていることから、システム開発を依頼したユーザーこそが、要件定義の責任を負うべきといえるのです。
４．要件定義の進め方
要件定義は、基本的に以下3ステップに沿って進めていきます。
①ユーザーから要求をヒアリングする
②要求内容を整理する
③要件定義書を作成する
ユーザーから要求をヒアリングする
要件定義は、ユーザーの要求をヒアリングするところからスタートします。
ヒアリングでは、
・現状どのようなプロセスで業務をこなしており、どのような課題を抱えているのか？
・システム化でどのような課題を解決し、何を実現したいのか？
などを聞き出し、ユーザーが抱える現状の課題やシステム開発の目的を明確にしていきます。
すでにユーザーの方で要求定義が行われていた場合でも、まだ言語化しきれていない潜在的なニーズが存在するかもしれないので、要求事項が漏れなく出そろっているか、ベンダー側の視点からしっかりと確認することが重要になります。
要求内容を整理する
ユーザーの要求をヒアリングによって明確にできたら、次はその要求がシステムで実現可能な内容かどうか、1つずつ吟味していきます。
プロジェクトの予算やスケジュールの都合上、ユーザーの要求をすべて実現できるとは限らないので、必ず実現したい内容なのか、できれば実現したい内容なのか、ユーザーとよく話し合って優先順位をつけながら、本当に必要な要求内容だけに絞り込んでいきます。
要件定義書を作成する
要求内容の整理を行い、システムに必要な機能が明確になったら、いよいよ要件定義書としてドキュメント化していきます。
要件定義書には、ユーザーからヒアリングした「解決すべき課題」や「システム化の目的」だけではなく、要望を実現するために必要なシステムの「全体像」や「実装すべき機能」など、これまでに整理したすべての内容を盛り込みます。
これから開発していくシステムの完成イメージについて、ユーザーや開発メンバー全員でズレなく認識を共有できるよう、ITに関する専門知識が無い人でも理解しやすい内容にまとめることがポイントです。
５．要件定義をスムーズに進めるポイント
最後に、要件定義をスムーズに進めるために意識したいポイント6つをご紹介します。
・5W2Hでユーザーの要求を正確に引き出す
・ユーザーの現行システムや業務フローを把握する
・ミーティングの必要回数を予測する
・ユーザーの要求と要件定義書が一致しているか確認する
・プロジェクト内で役割分担を明確にする
・誰が見ても理解しやすい要件定義書を作る
5W2Hでユーザーの要求を正確に引き出す
ユーザーから要求を正しく引き出すためにはヒアリングが重要ですが、「5W2H」を意識すると抜け漏れや曖昧さが生じにくくなり、ヒアリングの精度が格段に向上します。
・Why：なぜシステム化が必要なのか？背景・目的は？
・What：現状の課題や改善したいポイントは何か？何を実現したいのか？
・Where：どの部分にシステムを導入するのか？開発範囲は？
・Who：システムの利用者・運用者は誰か？
・When：いつまでにシステムを開発する必要があるのか？
・How：どのように要求を実現するのか？
・How much：予算はどのくらいか？
ユーザーの現行システムや業務フローを把握する
ユーザーがシステム化によって叶えたい要望は実に様々なものがありますが、多くは現行のシステムや業務フローに問題があり、その問題を解決したいがためにプロジェクトを立ち上げています。
つまり、要件定義段階で必要になるのは、すでに社内で使われているシステムや現在用いられている業務フローについて正しく理解し、その中でどの部分に問題があってどのように解決すべきかを明らかにすることになります。
中には、現行システムの設計書通りに業務を行っていないケースもあるので、要件定義の精度をさらに高めるなら、システム利用者や保守担当者からのヒアリング調査も必要になります。
ミーティングの必要回数を予測する
要件定義において何かと悩みの種となるのが、ミーティングの回数です。
週に何度もミーティングの時間を設けることは業務都合を考えても現実的ではありませんし、逆に回数が少なすぎても「要件を決めきれない」「関係者が出席できず確認が進まない」といった事態になりかねません。
何回ミーティングを開催すれば要件が固まるのか、適切な回数は一概には言えませんが、システムの機能や業務フローごとに打ち合わせ内容を区切り、一度のミーティングで検討すべき範囲をなるべく狭めることで、大まかながらも打ち合わせに必要な回数が見えてくるようになります。
ユーザーの要求内容と要件定義書が一致しているか確認する
要件定義書が完成したら、抜け漏れや認識のズレがないか、ユーザーとベンダーの双方で十分なすり合わせを行うことが大切です。
万が一両者の間で認識の相違があったまま開発が本格的にスタートしてしまうと、後の工程で手戻りが発生し、納期の遅れや予算オーバーにつながってしまいます。
ユーザーの要求内容がまんべんなく反映されているかどうか、要件定義書の内容をじっくりと読み込み、慎重に確認するようにしましょう。
プロジェクト内で役割分担を明確にする
ユーザー側とベンダー側の役割分担を明確に決めておくことも、要件定義をスムーズに進めていくためには欠かせません。
役割分担を曖昧なままにしておくと、やらなくてもよい仕事が増えて本来の業務に支障をきたす可能性があります。
例えば、現行業務の洗い出しや将来的なビジョンの策定など、元々はユーザー側が行わなくてはならない業務をベンダー側が引き取って作業するといったケースです。
そのため、WBSなどを活用してすべてのタスクに担当者と期限を割り振り、誰が・いつまでに・何をすべきかはっきりしていない業務は一切無くすようにしましょう。
誰が見ても理解しやすい要件定義書を作る
要件定義書は、誰か1人だけが見るものではありません。
エンジニアといったシステム開発に携わるメンバーはもちろんのこと、ITの専門知識があまり豊富ではないユーザーなど、関係者となる何人もの人が目を通すものです。
そして、各関係者の間で専門知識レベルに差があるということは、認識のズレが発生しやすいということに他なりません。
認識のズレを放置したままプロジェクトを進めてしまうと、後々想定外のシステムが出来上がって、「思っていたものと違う！」「こんなはずじゃなかった！」とクレームにつながる恐れがあります。
そのため、要件定義書を作成する際は、ユーザーが最終的な成果物を具体的にイメージできるよう、ITの専門知識が無くてもすんなり理解できるぐらいに説明を分かりやすく工夫することが重要です。
まとめ －良い要件定義書には要求の「叶え方」が書かれている
ここまで、要件定義の基本や進め方のポイントについてご紹介してきましたが、いかがでしたでしょうか？
要件定義は、ヒアリングを通してユーザーから掘り起こした要求内容を整理するだけではなく、「その要求をどのようにして実現するか」という問いに対する具体的な "答え" をドキュメントに落とし込み、ユーザーに理解してもらって初めて完了するものです。
このことから、要件定義が失敗しないための第一歩は、「ユーザーとベンダーの間で、十分すぎるぐらいにコミュニケーションを取る」ことだと言えるでしょう。
※今回の内容は、以下記事の抜粋になっています。完全版はこちらから↓