システムやアプリの開発では、開発フェーズの最初に要件定義という工程を実施します。この工程で開発するシステムの要件を決めることになります。
この要件定義をきちんと実施できているかどうかで、その後のシステム開発が成功するかどうかを左右するほど重要な工程になります。
そこで、要件定義の目的とこの工程で決めることについて解説していきます。
要件定義とは実現したい業務の共通認識を作ること
要件定義の目的は「システム開発によってどのような業務を実現したいか」ということを発注者と開発者との間で共有することです。
要件定義で決めることは以下の通りです。
- 新たに構築したい、もしくは効率化したい業務はどのようなものか
- 対象業務のうち、どの範囲までをシステム化するか
- システムを安定稼働させるために必要な条件や制約は何か
これらのことを明確にして、その内容で開発を進めるように発注者と開発者との間で合意をとります。要件定義書という形でアウトプットし、その内容について互いの認識に齟齬が出ないかを確認することが求められます。
要件定義の進め方
要件定義は現状の業務内容を整理して、その中のどの範囲をシステムの機能として開発していくか決めるという手順で進めます。最終的に作りたいシステムの要件を決めることになります。
いきなりシステムに必要な要件を挙げることはできないので、いくつかの工程を踏んでいきます。それぞれの工程で発注者と開発者が協力していく必要があります。
また、各工程において発注者は知り得る業務の情報や要求を開発者に説明する必要があります。開発者は発注者から情報を漏れなく引き出していくようにヒアリングをしていきます。
具体的にどのような流れで何を決めていくのかを以下で説明していきます。
業務要件は現状の業務と理想の業務を明確にする
システムやアプリ開発では効率化したい対象業務があります。要件定義ではまずその業務の現状の分析から行います。
このとき業務に関わる担当者や組織、入出力情報、手順などを明確にしていきます。
上記の図のような購買申請業務を例にしてみます。業務の関係者は申請者、申請を承認する上司、発注する購買部門がいます。
また入出力情報で、申請者が作成した申請書、購買部門が発注する注文書などがあります。そこで購買申請が作成・受理されるまでの決まった流れを、以下のように明確な手順にします。
- 申請者が申請書を作成して上司へ提出
- 上司は受け取った申請書に不備がないか内容を確認する
- 不備があったら却下し、申請者は差戻対応をして再提出する。
- 申請書に問題なければ承認して購買部門へ提出する
- 購買部門は申請書の内容に従って注文書作成して発注する
上記のように現状の業務内容について図や業務フローなどを作成して明確にしていきます。
対象業務の現状を把握できたら、それに対する理想の業務を明確にしていきます。現状の業務内容を整理することで、不要な工程や同じような業務が複数存在していて管理が煩雑になっている部分など改善点が見えてきます。
不要な工程を廃止したり、似た工程は一つにまとめたりすることでより効率化した業務フローを明確にしていきます。
これらの作業は開発者だけではできません。業務内容を知っている発注者の協力が必要になります。発注者からヒアリングした内容を元に開発者が関連図や業務フローを作成しますが、その作成に必要な業務の情報は発注者側が漏れなく伝える必要があります。
機能要件は明確にした業務の範囲から開発する機能を決める
機能要件では業務要件で明確にした対象業務のうち、どの範囲をシステム化するか決めます。そして、決めた範囲の業務をシステムにしたさいに必要な機能を以下の図のように整理します。
業務要件で理想の業務を整理するとき、解消したい不満点が出たり、追加で必要な業務内容が発覚したりします。業務要件の段階では漏れなく要件を出していくため機能はどんどん増えていきます。
理想をいえば、業務要件で明確にした理想の業務に必要な機能を全て実現したいでしょう。しかし、コストや期間の問題から、システム化できる機能の数は限られます。
対応としては開発の予算や期間を増やすか、費用や必要性を考慮して機能に優先順位をつけて作成する機能をしぼりこみます。
非機能要件は安定稼働するシステムに必要な条件を決める
機能要件でシステムとして実装する機能の要件を整理しました。しかし、システムが安定して稼働するためには、機能要件で定義した機能を作成するだけでは不十分です。
非機能要件では、システムが安定稼働するために満たさなければいけない機能以外の条件を決めます。
非機能要件の項目は様々あります。例えばシステムを継続的に利用するために以下の要件を決めておく必要があります。
- 障害発生時にサービスを維持するために、予備の機器をどのくらい用意しておくのか
- 障害発生時にデータを保護するために、バックアップをどのくらいの頻度でとるのか
このような要件を決めていない場合、障害が発生したら全てのデータが消えてシステムが稼働しなくなるような脆弱なシステムになってしまいます。
上記の例は可用性に関する非機能要件です。非機能要件には他にも以下のような定番の項目があります。
- 可用性
- システムを継続的に利用可能とするために機器の予備をどの程度用意するかやバックアップ方法について。
- 性能・拡張性
- システムの処理速度を維持するためにシステムで扱う最大のデータ量を想定したり将来的に業務量が増えたりした場合に備えて機器の性能にどれだけ余裕を持たせるか。
- 運用・保守性
- システムを維持するための点検やバックアップの頻度や時間帯、方法を決めたり、障害時の復旧作業の手順を決めたりする。
- 移行性
- 現状のシステムから開発した新システムへの移行方法を決めたり、移行時のシステム停止時間や移行日程の計画を決めたりする。
- セキュリティ
- 情報セキュリティに関して守るべき社内規定や法律、ガイドラインが存在するか確認し、それらに合わせた利用ルールや対策を決める。
これらの非機能要件の項目は、全てを厳しくすればいいというわけではありません。例えばセキュリティ強度を挙げると性能や操作性等が下がるなど、両立しづらい関係もあります。
開発したいシステムにとって優先度の高い項目を選ぶことが重要です。このとき条件をただ厳しく設定するのではなく、実際に達成可能なレベルに調整していくことが必要です。
要件定義が重要な理由
要件定義というのは、システム開発が上手くいくかどうかを左右するほど重要です。
要件定義フェーズで作成する要件定義書や業務フローなどは後の設計・開発フェーズのインプットになります。要件定義書の内容が不十分だとその後のフェーズで様々な問題が発生していきます。
要件定義フェーズで十分な成果物を作成するには発注者の協力が必要不可欠になります。システム開発は開発者の役割と考えて任せきりにしていると要件定義書は不十分なものになります。
通常の業務がある発注者にとって要件定義フェーズに参加するのは面倒に感じるかもしれません。要件定義の重要性を理解してモチベーションを高めておく必要があります。
要件定義の重要性を理解するために、要件定義がシステム開発において影響をあたえるポイントを説明していきます。
発注者と開発者との間で認識の齟齬をなくす
要件定義のあとは設計フェーズへと進みます。設計フェーズでは要件定義書に記載された要件を満たすシステムの設計が行われます。
設計は開発者が要件定義書から読み取ったシステム像を実現するように作成されます。要件定義書に記載されている要件に漏れがあった場合、その要件に該当する機能は設計されないことになります。
また、要件に十分な情報がない場合、発注者が想定した通りのシステムが設計されない可能性があります。例えば、入力機能に「英数字の入力も可能」という要件があったとします。発注者は半角でも全角でも入力できることを期待していたとしても、開発者は半角のみで設計してしまう可能性があります。
このように発注者の想定したシステム像と異なるものが開発されるのは、発注者と開発者との間で認識の違いが発生しているためです。認識の違いを発生させないためには、要件定義の段階で十分にお互いの認識を合わせて合意しておく必要があります。
発注者が一方的に業務内容を伝えるだけでは、開発者と認識を合わせることはできません。発注者が伝えた内容を元に開発者が作成した要件定義書をお互いが一緒に確認することが必要です。
要件定義書に機能についての記述で抜けている部分やあいまいな部分があったら、開発者がどういう認識をしているか確認することが必要です。
「要件定義書に記載されていない要件を開発者が察して設計に盛り込んでくれるだろう」と判断してはいけません。また、口頭で要件を伝えて終わりにしてはいけません。
要件定義書に文章や図として明記されて初めて発注者と開発者との間で合意したことになります。欠かせない要件について「常識だから」「言ったから」と済ますのではなく、要件定義書に明記するようにしましょう。
開発にかかる費用や期間が増えるのを防ぐ
要件定義が不十分で要件に漏れがあった場合、設計や開発でその要件に該当する機能がないまま進みます。機能が足りないことに気づくのは、開発が進んで動作テストを行うときになる可能性があります。
発注者は設計書の見方について詳しくないので、設計書の段階で漏れがあっても気づきません。開発者は要件定義書に記載されていない機能は開発しなくて良いと判断するため、漏れがあることに気づきません。
こうして、実際に動作テストで動くものを見る段階で機能が足りていないことに気づくことになります。その場合、機能を追加するためには該当する部分の設計・開発フェーズに戻って修正する必要があります。
後半のフェーズで開発作業の手戻りが発生するほど修正にかかる費用や期間は増大します。
設計や開発で漏れがないか確認するさいに最終的に立ち返るのは要件定義書になります。要件定義書に機能の漏れやあいまいさがあった場合、設計・開発の段階でそれに気づかずに後ろの工程で発覚する可能性が高くなります。
システム開発にかかる費用や期間を余分に増やさないためには、要件定義フェーズで十分に時間をとって漏れや認識違いのない要件定義書を作成する必要があります。
開発したシステムの品質低下を防ぐ
機能要件に漏れがあった場合はテスト段階で気づく可能性があります。しかし、非機能要件が不十分だった場合、問題が表面化するのはシステム開発完了後にシステムが稼働してからになります。
例えば、性能についての非機能要件が不十分だった場合、繁忙期に業務で扱うデータ量が増えるとシステムの反応速度が遅くなります。
また、可用性についての非機能要件を決めていない場合、システムの一部で障害が発生したさいに、システム全体が停止してしまうことがあります。
機能要件が問題なければシステムに必要な機能は開発されます。しかし、非機能要件を決めきれていないと処理速度が遅くなったり、障害発生時に全てのシステムが停止してしまったりとシステムの品質が下がってしまします。
安定稼働する満足度の高いシステムを開発するためには、非機能要件の重要性を認識して十分に検討する必要があります。開発するシステムで優先するものが性能なのか、障害時の被害を最小限にすることなのかを明確にして対応する非機能要件を定義しましょう。
まとめ
システム・アプリ開発における要件定義の目的と重要性について説明してきました。
要件定義の目的は開発したいシステム像につていの共通認識を発注者と開発者との間で持つことです。これが達成できたかどうかがシステム開発の成否を左右するほど重要です。
要件定義が不十分だと、システム開発で手戻りが発生しやすくなり、開発にかかる費用や期間が増えます。特に非機能要件は十分に検討して定義しておかないと、システム稼働後に深刻な問題を引き起こします。
要件定義を成功させるためには、業務について詳しい発注者の協力が不可欠になります。また、システムで業務をどのように実現するか考えるのが開発者の役割です。そして、業務に必要なものや満たすべき条件を伝えるのは発注者の役割になります。
システム・アプリ開発の要件定義は、発注者と開発者が協力して進める工程であることを認識するようにしてください。
コメント