要件定義とは何か
『要件定義』とは、システムを使う側が何をしたいのか、要求を具体的にまとめる作業です。実際に設計する側とコミュニケーションを取り、何ができて何ができないのか、分かりやすく明確にします。
具体的には、システムを使うユーザー側の要求をまとめる作業を『要求定義』、実際にシステム開発するにあたって具体的に機能をまとめる作業を『要件定義』と分けるケースもあります。
システムサイドが要件をまとめる
システム側が利用者に対して、「このシステムで何をしたいのか」を聞き出す作業が『要件定義』です。開発前に、どんな機能を実装しなければいけないのか、文書にまとめていきます。
利用者側は設計の都合や、何ができるのかを分かっていません。必要な機能や性能をまとめるには、『ユーザー側がしたいこと』と『希望する内容』を実現する機能を一致させる必要があります。
後から利用者側と開発側が考えていたことが違うなど、トラブルにならないためにも大切な作業です。
実現できないことも明確にする
要件定義では、実装できないことも利用者側に分かるようまとめていきます。たとえば、現在何らかのシステムを使って作業をしている利用者は、今できていることは説明しなくてもできると考えているためです。
もし、今使っているシステムと変わる場合は、機能ごとに実装できないことを伝えましょう。システムを使う側にとっては、ほかの機能が使いやすくなっても、一つのできないことがあるだけで台無しになる可能性があります。
実装できない機能がネックになって、システム自体不要との結論に達するケースさえ考えられます。開発を始めてからでは間に合いません。早い段階での提示が大切です。
要件定義のゴール
要件定義のゴールは、利用者が希望している内容が、機能や性能としてまとめられ、文書化されている状態です。
何をしたいのか十分に聞き取りを行い、実装できること・できないことを明確にすれば、作業は完了します。
実際にシステムができあがってから考えの相違に気付くと、取り戻すのは簡単ではありません。何度か打ち合わせを取り入れながら、実際にどんなシステムを作りたいのか明確にしていきましょう。
要件定義の進め方のポイント
要件定義のポイントは、『利用者側が分かるように、細かくコミュニケーションを取ること』です。できれば、実際に画面を見ながら、どんなシステムになるのか伝えられると、なおよいでしょう。
要件定義がいったん終わっても、設計と要件定義は繰り返し行います。すべてが完了してから見てもらうだけでは、失敗も起きやすいためです。
要件定義、基本設計を繰り返す
ユーザー側に要求を聞き、文書化する『要件定義』と『基本設計』は繰り返し行います。たとえば、一つの機能を実装したとき、システム上の動きではどうなるのか、実際に見てもらえば間違いありません。
基本設計まで進んだ後、ユーザーに見てもらい、さらに要件定義を行います。この繰り返しによって、よりユーザーの求めていることがはっきり分かってくるでしょう。
途中経過で追加したい機能や、不要な機能も出てきます。細かくコミュニケーションを取ることで、利用者側の要求に応えていくことが大切です。
コミュニケーション、情報共有を大切に
要件定義と設計には、コミュニケーションと情報共有が欠かせません。コミュニケーション不足では、利用者が本当に何をしたいのかが聞き出せないためです。
実際に設計に携わっている側と、何も知らない側では、当然考えることも違います。設計担当は不可能なことがある程度推測できても、依頼者には推測できません。
開発側はできないのは当然と実装不可能な機能を伝えず、依頼者はできるものと思い込んでいれば、実際にシステム完成後ほとんどやり直しになります。
また、途中で実装できなくなった機能や、内容の変化などもお互い共有しましょう。どちらかが把握していない場合、トラブルにつながります。
こんな要件定義は失敗のリスクが大きい
要件定義が失敗に終わることはよくありますが、特に多い原因は『依頼者側とのイメージのズレ』です。
要件定義の段階では問題ないと考えていても、実際に簡易でできあがったシステムを見てもらうと、テストの段階で希望していた機能がないなど、抜けが判明します。
多くの場合、依頼者が求めているシステムが作れていないことが要因です。しかしこれは、きちんと時間をかけてコミュニケーションをとっていれば防げる事態です。
一方で、依頼者の希望を重視しすぎて、いつまでも要件定義や設計が終わらないパターンもあります。
システム設計上、本当に必要なことと、そうでないことの振り分けも大切です。依頼者が期待する内容と、実際にシステムでできることのすり合わせがうまくいかないと失敗も増えてしまうでしょう。
まずは経緯を明確にする
要件定義の基本は、『目的を明確にして文書化すること』です。なぜシステムを必要としているのか、何をしたいのか経緯をはっきりさせましょう。
利用者にはシステムの概要は分からないため、システムを使って何を実現したいのかを聞き取ります。この作業で、設計の方向性が決まる大切な作業です。
目的のヒアリング
目的のヒアリングでは、新しく実装するシステムで何がしたいのかを聞き出します。たとえば、システムを利用している社員の負担軽減が目的なら、現在何に時間がかかっていて、どのような機能を実装すれば負担軽減につながるのかを考えていきましょう。
また、通販サイトで購入された商品をコンビニやロッカー受取に指定したいなど、目的が具体的なパターンもあるでしょう。ヒアリングによって、依頼者が何を求めているのか、掴むことが大切です。
質問を繰り返して認識のズレを解消
ただ依頼者の要望を聞いているだけでは、要件定義は終わりません。システムサイドからも質問をして、ユーザーと設計側のズレをなくしていく必要があります。
依頼者側はイメージで話をしているため、すべてを聞き入れていると大変です。場合によっては、不要な機能が作成されるケースもあります。
詳しく質問していくうちに、求めているもののズレが発見されれば、早めに修正が可能です。たとえば『利用者の負担を減らす』といっても、さまざまな方法があります。
どの項目が優先されるかで、システムの概要も変化するでしょう。実際に利用するユーザーのニーズを把握すれば、設計に生かせますね。
本当に必要なものを想像することが重要
単にいわれていることを鵜呑みにするだけでは、お互いに納得いくシステムはできあがりません。ユーザーは設計に関してほとんど分からないため、話で聞いている物と、実際に必要としているシステムが違う可能性もあります。
また、最終目的が時間短縮なら、過程はそれほど重要視されません。ユーザー側の認識だけでなく、開発側から見て本当に必要なものを提案すれば、さらによい物ができあがります。
要件定義書の準備をする
要件定義書は、ルールに従って作成します。内容や書式など、決まっている部分も多いため、適当には作成できません。
まずは、文書のルールを具体的に決めてから作成しましょう。ユーザーがなぜ、その機能を必要としているのかをまとめた『ユーザーストーリー』の作成も必要です。
文書のルールを作成
たとえば、文中に出てくる用語の統一や、独自の言葉で説明する際の定義などルールを設定します。文書のフォントや体裁もルール化しておくと分かりやすいでしょう。
さまざまな人が関わる定義書では、ルール化されていないと内容ごとにバラバラの文書ができあがってしまいます。
簡潔に分かりやすく書くのは当然としても、接続詞の使い方や、用語についてはルールとして設定した方がスムーズでしょう。
ユーザーストーリーは分かりやすく簡潔に
ユーザーストーリーは、それほど細かい決まりがなく、自由に作成できます。ユーザーが何をしたいのか、なぜその機能を求めているのか簡潔に説明しましょう。
たとえば、「発行ボタンを押すと、納品書がPDFファイルで作成されるようにしたい」などが当てはまります。あくまでもユーザー側の視点に立った内容のため、分かりやすくまとめましょう。
要件定義の成果物の書き方
実際に『要件定義書』として成果物を作る場合、記載内容や構成はある程度決まっています。ユーザーが求めている内容を形にするだけでなく、システム開発の上で役立つドキュメントに仕上げましょう。
必ずこの項目を入れなければならないなどの厳しいルールはありませんが、テンプレートやサンプルを参考に作り上げるのも有効です。
要件定義書に記載する内容
要件定義書に記載する内容は『システムの概要』や『入力、出力要求と内容』などです。それ以外にも、実際にシステムができあがった後の説明書にもなり得る『システムを利用したときの業務フロー』や『性能に関する要求』なども記載されます。
ユーザー側の要求と、システム化したときの挙動を記載し、認識のズレをなくすことが重要です。セキュリティ面の要求や、なぜシステムを導入したいのか目的も記載しておきましょう。
ほかにも、ユーザー側が希望する内容があれば記載します。
機能要件、非機能要件とは
『機能要件』と『非機能要件』の分類は簡単です。機能要件は、ユーザーが最低限必須としている機能に当たります。
たとえば、毎日の売上を集計する目的でシステムを作るなら、売上集計機能は機能要件です。もし、達成できなければ、プロジェクトが失敗となるような重要な要件が機能要件に当たります。
対して、非機能要件は絶対に必要な機能ではないものの、実装できれば顧客満足度が上がる要件です。たとえば売上集計ソフトなら、集計までの時間が早ければ早いほど、顧客満足度は高まります。
さらに、セキュリティやその他のオプションなど、あれば役立つ機能なども非機能要件として分類しましょう。
分かりやすい構成を心掛け、図も活用する
要件定義書は、依頼者側とのコミュニケーションに使われます。定義書の内容は、専門用語に解説を加えるなど、ユーザーが読んでも分かるようにまとめましょう。
必要に応じて図を使うと、さらに分かりやすくなります。簡単にシステムの概要や機能の説明ができれば、ユーザー側との認識もかみ合うでしょう。
表やグラフ、実行画面のサンプルを用意するなど、視覚的に分かりやすい定義書が役立ちます。
ネット上のテンプレートも参考になる
要件定義書の作成方法が具体的にイメージできないときは、ネット上のテンプレートを参考にしましょう。ある程度必要な情報が盛り込まれているため、プロジェクトに合わせて内容を追加、削除するだけで使えます。
最初から定義書のルールやフォーマットを作るより時間短縮に繋がり、スムーズな要件定義が可能です。特殊な案件の場合は使いにくいこともありますが、一般的なプロジェクトなら活用してみましょう。
ミーティングを開催する
開発側とユーザー側がそろった、ミーティングの開催も重要です。文書のやり取りだけでは分からない不具合が見つかります。
一度ではなく何度か開催し、そのたびに修正を加えていきましょう。最初と最後だけなど、回数が少なすぎると問題が発生したときに修正が難しくなります。
業務ごとに話し合いを設けるとスムーズ
基本的には、業務ごとに話し合いの時間を設けるとスムーズです。たとえば、特定の機能に対して1回のミーティングを行います。
もちろん、複数の機能をまとめて1回でミーティングしても問題はありません。まったく触れずに開発を進めるのではなく、それぞれユーザーとのすり合わせができていれば不都合なく進められます。
もし、ユーザー側での確認後、さらに打ち合わせが必要なものは2回に分けてチェックしましょう。
全体のすり合わせも忘れずに
ピンポイントでの確認だけでなく、全体的なすり合わせもミーティング中に行いましょう。機能は利用者が求めるものができあがったとしても、納期やオプション、運用後のフローがうまく行かなければ不都合が起こります。
ミーティングの間に、全般的に話を進めておけば、トラブルを未然に解消できるでしょう。
運用後の計画
システムは、作るだけで完了するわけではありません。ユーザー側にとっては、利用開始からが重要です。
運用後に修正を行う場合のルールや、期限なども設定しておきましょう。もちろん、作った後は有料で対応するなどのケースもありますが、どちらにしても計画を決めておかなければスムーズに進みません。
作って終わりではない
システムは作った段階で開発側の仕事が終わるものではありません。運用している段階で、メンテナンスや機能の修正、バグの対策が必要になれば手直しが必要です。
どこまで対応するのか、運用スケジュールを決めておき、スケジュールに従って進めて行きましょう。
実際に利用が始まると、テスト段階では現れなかった問題も出てきます。作成後の問い合わせや対応のことも、早めに話しあっておくとよいでしょう。
要件定義と並行して運用設計を進めておく
要件定義を進める際に、合わせて『運用設計』も組んでおくと後々の作業がやりやすくなります。運用設計は、システムを実際に運用したときに、どのように使うのかをまとめる作業です。
定期的な運用や、不定期に発生する業務なども盛り込みます。設計側に問い合わせる場合はいつ対応してもらえるのかなど、具体的な内容も設定しましょう。
運用設計は開発側が行う業務と決まってはいません。しかし、ユーザー側が運用設計の大切さを知っているとは限らないため、必ず誰が運用設計を進めるのか把握した上で設計や要件定義を進めましょう。
要件定義を終え、設計に進んでしまうと、後から導入後の問題が見つかっても対処が大変です。なるべく早めに運用設計に取りかりましょう。
まとめ
要件定義は、システム開発に欠かせない工程です。依頼者側が何を求めているのか、明確に文書化すると、システム開発後のトラブル軽減に役立ちます。
要件定義でシステムの概要を依頼者に伝え、明確にしておけば、その時点で認識のズレもなくせるでしょう。
求められている機能を実装するだけでなく、できないことや運用後の業務フローも要件定義をしているうちの話し合いが大切です。
