【入門】ソフトウェア開発の要件定義
はじめに
ソフトウェア開発をする上で『要件定義』は非常に重要な工程のひとつであり、「要件定義が曖昧であったこと」が理由で問題が発生することも多い難しい工程のひとつでもあります。
この記事では、要件定義とはどんなものなのか？ という基本的な観点で解説します。要件定義について初めて知る人や曖昧に考えていた人はぜひ読んでいただければと幸いです。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
要件定義とは
要件定義とは『システムを使うユーザーがそのシステムにおいて出来ることを定義すること』です。
例えば「本の購入ができるECサイト」のようなシステムの場合は、
・本を購入する
・本を予約する
・おすすめの本をユーザーに表示する
といった内容(機能)が要件になります。
要件定義は、ソフトウェア開発を行なうためには必ず必要です。ソフトウェアを設計、開発するためには、具体的にどんな機能が必要かを明確にしておく必要があるからです。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
この記事における要件定義の位置づけ
日本における「要件定義工程」は
・システム開発会社が発注元企業に対して行なう要件定義
・自社開発システムの開発時に行なう要件定義
で微妙にニュアンスが異なると考えています。
大きく異なるのは『顧客が誰か？』という点で、システムの請負開発において顧客は「システムの発注元企業」ですが、自社開発では「システムを使うユーザー」です。本質的には同じ事なのですが、業務としての合意形成のプロセスが異なるため内容も違っているという理解です。
明確な定義はしにくいですが、この記事では主に「自社開発システムの開発時に行なう要件定義」をベースに話を進めます。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
機能要件と非機能要件
要件定義は『機能要件』と『非機能要件』に分かれます。
機能要件とは、ユーザーが直接できること(機能)を指します。また非機能要件とは機能要件以外のシステムになければいけない要件を指します。例えば、処理速度やセキュリティ、システムの稼働率などがこれにあたります。
■ 機能要件
・本を購入できる
・本を購入すると確認メールが送られる
など
■非機能要件
・購入ページは、3秒以内に表示されること
・顧客情報は暗号化して保存されること
など
非機能要件は、ソフトウェアを開発したことがない人(エンジニア以外の人)には言語化しにくい内容ですが、知識として理解しておく必要があります。
例えば、プロダクトの責任者が本当に提供したいプロダクトの価値の中には非機能要件も含まれており、正しくソフトウェアを開発するためには、開発前に非機能要件をエンジニアを含めたチームに共有することが重要になってくるからです。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
要件定義をなぜ曖昧にしてはいけないか
前提として『要件が明確に決まっていないとシステムが作れない』ということがありますが、チームの開発プロセスとしてなぜ必要かを説明します。
要件定義が必要な理由には次のようなものがあります
・エンジニアとのコミュニケーションを円滑に進めるため
・システムのあり方をチーム全員が理解しておくため
・システムの規模を大まかに見積もるため
まず、要件定義が曖昧の状態で開発に入るとエンジニアとのコミュニケーションで問題が生じることがあります。
小さなベンチャー企業でありがちなのは、パワーポイントのような簡単な資料で見た目と機能説明を行い要件定義を完了してしまうケースです。
このような進め方をしてしまうと、エンジニアは開発の段階で不明点が多く発生するため、そのたびにコミュニケーションを取らなくてはならなくなります。これは設計工程においてお互いに大きなストレスになり得ます。
また、リリース直前になってプロダクト責任者が認識していた機能が実装されていなかったり、イメージしたものとは違うなど、後々の開発工程で考慮漏れや機能漏れが発生する危険性もあります。
小さなチームで良くある悪い例:
プロダクト責任者(やwebディレクター)がパワーポイントなどの資料で大枠のアプリケーションの概要を説明して、そのまますぐに開発。
↓
開発中にエンジニアから「XXXXの機能は必要ですか？」「XXXXについては考慮する必要がありますか？」などの質問が多く発生する。
↓
リリース直前に実装漏れやUXの齟齬が発生する。
また、要件を正しく定義できていないと、スケジュールの見積もりも上手く行きません。そのためリリースが当初の期待よりも大幅に遅れてしまうなど大きな影響があります。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
要件定義のポイント
要件定義を正しく行なうためのポイントとしては、「システム完成時にその要件が正しく実現できているかをYES/NOで答えられる」形で表現されているかで判断できます。
■ 良い例
・ユーザーは購入ページで販売中の書籍を購入できる
・ユーザーが本を購入したら明細をメールで送信する
・本が売り切れている場合は、ユーザーは本を購入できない
・本が売り切れていることをユーザーにわかりやすく通知する
■ 悪い例
・購入ページで本を購入できる
完成したシステムを想像し、その要件がYES/NOで答えられないような曖昧なものであったり、表現が不足していたらもう一度見直すことが必要です。将来的に開発に悪影響が出てしまう可能性があります。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
エンジニア以外の人が非機能要件を考える時
プロダクトの一番はじめの要件をプロダクト責任者やディレクターなどエンジニア以外の人が書く場合、非機能要件を全て洗い出すことは難しいと思います。
ですが、そのプロダクトのコアな体験となる非機能要件については、エンジニア以外の人でも洗い出せるように意識しましょう。『スムーズな画面遷移を売りにしたい』『強固で安全なセキュリティを売りにしたい』などの重要な要件は初めからチームに共有しておく必要があるからです。
内製のチームであれば、その他のシステム非機能要件はエンジニア側でフォローすることが可能である場合が多いです。
最終的にはエンジニアを含めたチームで要件定義をレビューし、合意をとることが重要です。何度も議論し、詳細を話し合うことで漏れのない要件を定義することができます。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
アジャイル開発における要件定義(ユーザーストーリー)
アジャイル開発では要件定義の方法として『ユーザーストーリー』という手法が使われることがあります。
ユーザーストーリーとは「私が [ペルソナ] なら、[希望] を実行することで [目標] を達成したい」といったテンプレートを使い、誰が、なんのために、どんなことを実現するのか？をシンプルな1文で表現します。
例:
私が[本の管理者]なら、[本の販売記録画面を閲覧することで][本の販売上京を把握したい]
アジャイル開発では、プロジェクト初期に全ての要件や仕様を詳細に洗い出さず、最も優先度が高い機能から開発していきます。そのためシンプルな要件をユーザーストーリーとして洗い出しておき、定期的に優先度の並び替えや要件の再定義を行なうといった方法をとります。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
まとめ
要件定義は、開発をはじめるために必要な最も重要な工程です。また要件定義は、そのシステムが計画した通りに開発できたかを図るためのテスト項目書にもなります。
要件定義の精度が上がることで開発プロジェクトの失敗を減らすことができます。いままで曖昧なイメージで開発を行なっていた人は、この記事をきっかけに要件定義の方法や内容を見直してみると良いかもしれません。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
アンケートのお願い
このチャンネルでは、これから提供していくコンテンツやサポートの内容を改善していくために、アンケートをお願いしています。
ぜひアンケートにご協力ください。
この記事が気に入ったらサポートをしてみませんか？