【依頼者も開発者も大事な工程】要件定義は何をすればいいの？

ごきげんよう、Zei(ゼイ)です。
個人開発をするにあたって、「個人開発ではありながらも、しっかりとシステム開発のプロセスを踏んで形にしていこう」と決意してプロジェクトを一人で進めております。
今回は、システム開発9つの工程の2番目【要件定義】を詳しく学んでいこうと思います。

以前の決意した記事↓
【超個人的なWEBアプリを作りたい】

システム開発の工程全体を説明している記事↓
【システム開発の流れと開発手法を知ろう】

システム開発2番目の工程【要件定義】

要件定義とは、システム開発者が依頼者と打ち合わせをして、要求(定義)をもとに実装するシステムが具体的にどのような機能・性能を持ち、どのように動作すべきかを詳細に要件定義に定め、具体的にどのように進めていくかを決める重要な工程。

成果物は基本設計のインプットになるので「情報が足りない、システム設計ができない。」とならないようにしっかり詰めていくことが必要。

要件定義の目的と重要性

要求定義で提示された依頼者の「システム化する目的(Why)」や「何がしたいのか(What)」の『夢』を、システムとして実現可能な『理想』に具体的に落とし込む作業。
システムに必要な機能、パフォーマンス、インターフェース、セキュリティ要件などを具体的に決める。

要件定義をしっかりと行うことで依頼者と開発者の間に誤解がなくなり、システムが”求める仕様通り”に開発される確率が格段に高くなる。
逆に要件定義がしっかりと行われていないと、開発が進むにつれて依頼者と開発者の認識にズレが生じ、プロジェクトの成功が怪しくなる。
「お互いの認識がズレてない、このまま進めて大丈夫だよね」と、お互いの同意をとるために実施する。

要件定義の進め方

依頼者と開発者の協議

依頼者と開発者が協力して要求を具体的にまとめる。
要求内容に対する疑問点や確認すべき事項をクリアにしていく。

要件定義を開発者が固めていくには、依頼者側から現行業務の洗い出しをしてもらう必要があるので、依頼者側にも動いてもらう必要がある(開発者へ丸投げしてもいいシステムは作れない)。

依頼者側と開発者とでそれぞれの役割が違うため、まずは依頼者側とシステム開発者のそれぞれの役割分担をはっきりさせることが大切。
タスクを細分化してプロジェクトごとに担当者を設け、役割分担を明確にする。

依頼者側の現行システムの課題を洗い出すためにも、依頼者側の現行システムの中身を把握することが大事。
現行システムの状況を把握できるかが完成するシステムの質の高さに関わってくるので、しっかり時間をかけて把握する必要がある。
ダメなシステムを作らないように、システムの骨組みとなる要件定義を念入りに行っていく。

依頼者側が要求する内容が必ずしも現実的でない場合がある。
開発者は技術的に実現可能かどうかを検討し、必要な調整を提案することが重要。
依頼者との対話を重ね、最適な解決策を見つけ出す必要もある。

要件が明確かつ具体的であることが最も重要。
「欲しい機能」をざっくりとした言葉のままではなく「どのように機能するのか、どのように動作するのか」と明確に定義する。
曖昧な要件は後々のトラブルの元となり、開発が進むにつれて問題が大きくなる。

機能要件の整理

システムが実現すべき機能を具体的に定義。
どのようなデータを入力し、どのような結果を出力するのか、依頼者側がどのようにシステムとやり取りするのかなど、システムの基本的な動作に関する要件を明確にする。

非機能要件の整理

システムのパフォーマンス、セキュリティ、可用性、拡張性など、技術的な要素に関する要件の整理。
システムが1秒以内にレスポンスを返すなどを記載。

優先順位の設定

すべての要件が等しく重要というわけではないので、どの機能が最も重要か、どの機能が後回しにできるかを依頼者と開発者で決める。
プロジェクトのスコープが明確になり、リソースをどこに集中させるべきかが分かる。

確認と合意

依頼者側が抱えている問題や求める解決策について、開発者が技術的に実現可能な形に変換し提示。
依頼者と開発者がそれを共有し、合意する。
この合意に基づいて、実際の開発作業が開始される。

ここで依頼者と開発者の認識にズレがある場合プロジェクトは失敗してしまうので、
念入りに、念入りに確認・解決・明確にする。

要件定義書で作成するもの

プロジェクトによって変わってくるが、主に下記が必要になってくる。

要件定義書は関係者となる何人もの人が見るもの。
関係者の中でもそれぞれ専門分野などが異なるので、認識のズレが生じかねない。
誰が見ても理解がしやすい要件定義書の作成を意識する必要がある。

作成後も管理を怠らない

要件定義書は、システム開発が進んだ後でも非常に重要な役割を持つ。
テストの基準を決めるためにも使用され、総合テスト・受入テストにおける「合格基準」も要件定義に基づくことになる。
変更に対応していなければ、そのテストの根拠が不明瞭となり評価ができなくり、さらに状況によってはトラブルに発展する。
プロジェクトが進行する中で変更があれば、要件定義書の更新を都度都度行い、最新の情報を関係者全員に伝えることが大切。

参考サイト

システム開発の「要件定義」とは？進め方やコツを解説 - システム開発のプロが発注成功を手助けする【発注ラウンジ】

ITを活用したプロジェクトや開発の現場に欠かせない工程が「要件定義」です。システム開発は、この「要件定義」をしっかりと固めることで、企業の課題の解決に繋げることができます。本記事では、要件定義の基礎情報や要件定義の流れと進め方のコツを解説し...

hnavi.co.jp

おわりに

ここを失敗したら大炎上間違え無しの要件定義をまとめていきました。

絶対にいいシステムを作るぞという、依頼者・開発者どちらの執念も必要な工程だと感じました。
誰もゴミを作りたいとは思わないと思うので、お互いに協力して進めていきたい工程ですね。
決めごとが多くて、人(依頼者)によってはめんどくさいと感じるかもしれませんが、ここでサボ…開発者に丸投げしてしまうと双方が痛い目に合うので、どちらの立場の時でも真剣に要件定義の工程に参加したいなと思いました。