「要求定義」と「要件定義」の違いは？｜要求定義の進め方
「要求定義」についてこんな悩みをお持ちの方は多いのではないでしょうか？
- 要求定義と要件定義の違いがわからない
- 要求定義の目的がわからない
- 要求定義で何を行うかわからない
上記のような疑問や不安にお応えしていきます。
今回の記事を読めばこれがわかる！
☑️「要求定義」と「要件定義」の違い
☑️「要求定義」の目的
☑️「要求定義」の工程
この記事を書いている私は新卒でこの春にEnlytに入社したディレクターの野田です。
新卒ですが今まで何件かの要求定義のミーティングに参加してきたので、今回は参加した要求定義のミーティングから学んだことを紹介したいと思います！
目次
「要求定義」と「要件定義」の違いは？
「要求定義」とは
要求定義の目的はクライアントと共にシステムの概要を具体化することです。
実際にクライアントと話をするとクライアント側でやりたいことがふわっとしていることがよくあります。そういった場合は抽象的な言葉から具体化する必要があります。
具体化することにより、クライアントとプロジェクトのゴールのイメージを共有し、認識齟齬をなくすことが可能になります。
明確に要求定義をできていないと実際に開発した成果物がクライアントから求められていたものと違うということが起こる可能性があります。
「要件定義」とは
要求定義はクライアント目線なのに対し、要件定義の目的は開発者の視点から必要な機能や要求をわかりやすくまとめることです。
しっかりまとめることによりプロジェクトを計画通りに進め、目的の脱線を防止することが可能になります。
要件定義をしっかりせずに開発を開始してしまうと開発開始後に想定外の作業が多発し、計画通りにプロジェクトが進行できない可能性があります。
「要求定義」と「要件定義」の違い
上記の通りクライアント視点で・目的・ニーズ・要求を定義するのが要求定義。
開発者視点からシステム概要・機能要件・非機能要件などを定義するのが要件定義です。
違いとしては誰視点なのかという点で異なりますが、どちらか片方でも十分にできていなければプロジェクトの進行に遅れや問題が多発することになります。
「要求定義」の進め方
「要求仕様書」に書くべき項目
要求仕様書とは、クライアントがシステム開発側に対して開発を依頼する際のシステム要件を文章化したもので、要望や要求事項・予算・リリース目標などが主で、具体的な実現方法は書かれていません。
クライアント側にシステム開発に強い担当者がいれば、要求仕様書はクライアント側で作成すべきですが、そうでない場合は、開発担当側の関与が必要になる場合もあります。
- システム化の目的
まずシステムを開発する目的を記載します。
ここでは開発することによる効果を可能な限り明確にすることが重要です。
ここで明確化して置くと、後に開発が進んで要件やスケジュール変更を余儀なくされた場合の指針になります。
【具体例】
- 開発を依頼された背景
- 現在の状況
- 開発後の理想像
- 理想像のために必要なこと
- 基本方針
開発の基本方針を記載します。
内容としては複数の設計者で実施するために必要となる重要な設計方針、誰がどういった項目のテストを行うのかというテスト方針を明確化します。
明確化することでスムーズに開発をスタートさせることが可能になります。
【具体例】
- クライアントに開発体制はあるのか
- こちら側で対応する開発範囲はどこまでか？
- テストはどの範囲までこちらで行うか
- 脆弱性テストなどの必要性はあるか
- 機能一覧
「何を開発するのか」のおおまかな内容を記載します。
詳細な機能は要件定義などで決定していくのでここではあくまでおおまかな内容で問題ないです。
クライアントに説明しやすいように、文章だけでなく表にしたり図を用いて作成するなどの工夫が必要になります。
開発側は周知の内容でも開発の知見がないクライアントには理解できない内容もあるため、一目みただけで内容を理解できるように作成することが重要です。
【具体例】
要求定義で議論すべきこと
要求定義の段階ではクライアント側でやりたいことがふわっとしていることがよくあります。
そういった場合は抽象的な言葉から具体化→具体化…を繰り返していきます。
そのため以下の5W2Hを明らかにしていく必要があります。
| いつ（When） | 期日やタイミング、開発の速度感はどういう状況か |
| どこから（Where） | 社内から利用なのか社外からか。別のシステムとの連携か |
| 誰が（Who） | 利用者は誰か。または、ある利用者には制限させるのか |
| 何の情報を（What） | どのような情報を扱うのか |
| どういう理由で（Why） | そもそも、なぜそれが必要なのか |
| どれぐらいで（How Much／Many） | 毎日なのか、一年に一回なのか。どれぐらいの量か |
| どうするのか（How） | 何をしたいのか。それを行うと、どうなるのか |
この5W2Hを明らかにしていくことにより、クライアントがやりたいことを明確化していき、クライアントとの認識齟齬を防ぐことが可能になります。
また、引き出した要求の優先度を確認しておくことも大事です。
様々なステークホルダーの要望や予算、リソースなど多角的な観点から整理・議論し、今何を優先すべきかを決めていきます。
要求定義で注意すべきこと
- 発注元の要求を聞き入れ過ぎない
要求定義に沿ったシステムにすれば、発注元の満足度を得ることができます。
しかし、要求・要望を聞き入れ過ぎたことで、中途半端になってしまったり肝心な機能が不足した不完全なシステムになることもあり得ます。
作成する段階から、本当に必要なのかエンドユーザー視点になって考えて、発注元からの要求があった部分でも不要な部分は除外することが重要なポイントといえるでしょう。
例）ECサイトを構築する場合、クライアントから「運用しやすくするため、購入者が商品を購入する前に在庫があるか確認依頼をするようにして欲しい」という要望があったとします。
確かに運用上でこの確認があると便利な点はありますが、エンドユーザーである購入者からすると、購入前のフローとして手間に感じるでしょう。なのでこういった要求があってもプロジェクトを成功させるために聞き入れすぎないことが重要です。
- 要求漏れ
要求漏れとはクライアントが要求する機能を実装するには、他の機能も実装しないといけないのに、そのことを要求定義の段階で定義できていないことです。
例えばクライアントから「顧客データをCSVで出力して管理したい。」という要求があったとします。この機能を実装するにはCSVを出力する機能はもちろんですが、顧客にCSVに記載する情報を入力してもらう画面やその情報をデータベースにあげるバックエンドの機能の実装が必要になります。この様に1つの要求でも複数の機能が必要になり、その機能のうち一つでも定義が漏れていたら「要求漏れ」になります。
要求漏れをしやすい理由は、要求定義自体に仕様が実装・搭載されないこともあるためです。
要求漏れを防ぐため、上記で記載した5W2Hをしっかり議論する必要があります。 - セキュリティに関連する部分
セキュリティー部分に要求定義忘れがある場合、外部からの不正アクセスに繋がる危険性があります。
セキュリティの管理は外注の専門企業に依頼する、本番環境に開発会社はログインできない様にするなど、詳細な内容は要件定義で決めることになりますが、要求定義の段階で決めておくと開発をスムーズに進めることが可能になるでしょう。 - 要求定義書の管理
これまで要求定義書に記載する内容を紹介してきましたが、記載途中または記載後にクライアントからの要求が変わることはよくあります。
その時どの情報が最新の要求のものかわからなくなってしまうことがあります。
なので、要求定義書を記載する人を決めたり、更新した際は更新箇所をまとめて確認できるものを用意しておくと混乱を避けられます。
要求定義のまとめ
今回は要求定義について解説しました。
要求定義をしっかり行うことでクライアントとの認識齟齬を防ぎ、開発したものがクライアントが要求しているものと違うということを防ぐことが可能になります。
Enlytについて
株式会社Enlytはベトナムに開発拠点SupremeTechを持ち、これまで50以上の開発プロジェクトを行ってきました。ベトナムと日本のグローバルなチームで、数多くのプロジェクトを成功に導いてきました。
お客様の納得のいくまで、共に開発させていただき、アイデアを最高のかたちにサービス化いたします。
オフショア開発についてのお悩みやご相談がございましたら、下記ボタンより気軽にお問合せください！
