【開発依頼者向け】システム開発における『要件定義』とは？

2022-08-22 2023-08-14

この記事は、開発会社への開発依頼を検討している方、すでに依頼しており対応に困っている方へ向けたものです。

「開発なんて全くわからない世界だ」と思われている方とも、ぜひひとつのチームとして一丸となりプロジェクトに向き合いたいと弊社は考えています。
そのために開発サイドがどんなことをしているか簡単にご紹介します。

今回は「要件定義」と呼ばれる工程を説明していきます。

今回の記事を読めばこれがわかる！

☑️　「要件定義」とは？
☑️　「要件定義」の進め方
☑️　要件定義とユーザーストーリーの違い

今回記事を執筆している私は、エンジニア経験がない状態でディレクターとして開発会社に入社しました。
開発経験が乏しい人間でも知識をつけることでチームの一員として動くことができます。
皆様の不安を解消できるように執筆しましたので、一緒に要件定義について学びましょう！

要件定義とは？

要件定義の概要

要件定義は、開発後に出来上がったプロダクトに必要な機能や要求をまとめ、ドキュメント化する作業のことです。開発に着手する前に行います。

ここで制作したドキュメントは「要件定義書」と呼ばれます。
開発を進める中で脱線がないよう何度も立ち返られる、開発の軸となるものにするため、抜け漏れは原則許されません。

要件定義の意義

要件定義書は目的地までの地図のようなものです。しっかりと作ることで、プロジェクトメンバーが一つの目的に沿って開発を進めることができます。

逆に要件定義を曖昧に終わらせてしまうと、開発途中で仕様が変わり無駄な工数が発生したり、顧客やユーザーの求めていたものとは異なるものを完成させたりしてしまいます。

要件定義の失敗例は【開発ディレクター向け】オフショア開発で要件定義を成功させるコツで詳しく紹介しているので、気になる方はご一読ください。

要件定義の進め方

要求のヒアリング

まず、プロジェクトマネージャーやディレクターから制作物について、要求のヒアリングがあります。ここでの要求とは、どんなことを実現させたいかです。ユーザーにどんな体験を提供したいのか、どのような課題を解決したいのかなどを伺います。開発会社はここで得た情報をもとにまずは要求の定義を行い、それらを要件に落とし込んでいきます。

このヒアリング時には、課題を「どうやって」解決するかまで決めておく必要は必ずしもありません。要件定義をしていく過程で、ユーザーにとってベストな実現方法を検討していきます。

ところで、この後のステップで制作する要件は2種類あります。「機能要件」と「非機能要件」です。「機能要件」はシステムの機能そのものの要件です。「非機能要件」は、セキュリティやユーザビリティなど、機能以外で実現させたい要件です。要求のヒアリング時にはシステムそれ自体の話だけではなく、全体として実現させたいことを共有いただけると開発会社は後の工程を進めやすくなります。

要求仕様書の作成

前のステップでヒアリングした要求を文面にまとめます。

基本方針、開発スケジュールや予算、開発環境といったプロジェクト全体に関わる事項や、機能のアウトラインを確認するための書類になります。

要求仕様書をクライアント・開発会社でずれがないか確認した後、要件定義書の作成に移ります。

要件定義書の作成

まとめた要求を要件の形まで落とし込み、文書にします。

要件定義書には以下のような項目があります。

• システムの概要

要求をどうやってシステムで実現するかをまとめます。「レシピを表示したい」という要求があった場合、表示方法ひとつをとっても文章、画像、動画と様々な実現方法があります。最適なものを検討した上で概要にしていきます。

• 開発の目的・目標

システムをどんな課題やユーザー層に対して作るのか、何が達成されれば良いのかなどをまとめます。機能などを後から検討する場合はこの目的・目標に即したものを選んでいきます。

• 機能要件

要求を実現するために必須な機能のことを機能要件といいます。例えば「現行システムを引き継いで同じ分析機能を入れたい」「要望が多いため画像登録機能は必ず加えたい」など、クライアントが望んでいるものをまとめます。これらは最低限必要な機能になるため、どれかが抜け落ちている状態ではリリースができません。

• 品質・性能要件

パフォーマンスや可用性といった、品質の要件をまとめます。例えばサービスが年中無休で24時間利用可能であることが必要とされる場合はそれを明記したり、良いパフォーマンスを「ログイン時の応答時間が3秒以内である」などと明文化したりします。

• セキュリティ要件

システムを安全に運用するためのセキュリティ対策を定義します。運用を見据えたものですが、「条件に合わないアクセスを許可しない」などと機能として開発する必要があるので、開発開始前にまとめておきます。

ご依頼企業の方は、実現したいものとズレがないかご確認をお願いします。

要件定義書が完成した後

要件定義書を作成した後は、基本/詳細設計など具体的なシステムの設計を開始します。開発知識のない方にとっては、設計段階に入ると全てを理解することが難しくなる場合もでてきます。そこで要件定義書で定めた指針が役に立ってきます。指針に沿って設計は進むので、逐一依頼者が確認をしなくてもシステムはやりたいことの実現に向かって作られます。

要件定義書の指針に沿って開発するとはいえ、フィードバックは必要です。最も事業を理解されているクライアント企業の方の意見は、プロダクトを良いものにするため不可欠です。特に弊社ではクライアントと「ワンチーム」となり、プロジェクトを進めることを重視しているため、できあがっていくシステムに対して率直にフィードバックをいただけるとありがたいです。

要件定義とユーザーストーリーの違い

現在主流な開発方法は2つあり、それぞれ「ウォーターフォール開発」「アジャイル開発」と呼ばれています。ウォーターフォール開発は全ての機能ができてからリリースしますが、アジャイル開発は1~2週間で開発期間を細かく区切り、できた機能からリリースしていきます。弊社Enlytはほとんどのプロジェクトでアジャイル開発を導入しています。

要件定義を「要件定義書」を使って行うのはウォーターフォール開発の場合です。

アジャイル開発の場合は、要件定義書ではなく「ユーザーストーリー」を用いて要件を定義していきます。

要件定義書とユーザーストーリーの大きな違いは、「途中で変化するか」です。

要件定義書はシステムが完成するまで、基本的には変更しません。

対してユーザーストーリーは、小さなリリースを繰り返す中で気づきを得て、少しずつ変わっていきます。

またユーザーストーリーは「どう実現させるか（HOW）」を書きません。下記の3つを書いていきます。

• 誰のための機能なのか？
• システム的に期待することは何なのか？
• なぜその機能が大切なのか？

ユーザーストーリーについての詳細は【保存版】ユーザーストーリーの基本｜アジャイル開発に携わるメンバーが抑えるべきポイントをご覧ください。

この記事のまとめ

• 要件定義は、プロダクトに必要な機能や要求をまとめ、ドキュメント化する作業のこと
• 実現したいものからずれた開発を行わないため、軸となる指針を定める目的がある
• アジャイル開発の場合は、要件定義の代わりに「ユーザーストーリー」を作る。

要件定義にはクライアント企業の皆様のご協力が不可欠です。実現したいことを詳細にお話いただければと思っています。開発側も実現に向けて全力でサポートさせていただきます！

Enlytについて

株式会社Enlytはベトナムに開発拠点SupremeTechを持ち、これまで50以上の開発プロジェクトを行ってきました。ベトナムと日本のグローバルなチームで、数多くのプロジェクトを成功に導いてきました。

お客様の納得のいくまで、共に開発させていただき、アイデアを最高のかたちにサービス化いたします。

オフショア開発についてのお悩みやご相談がございましたら、下記ボタンより気軽にお問合せください！