プロジェクトの企画段階や設計段階で、必ず耳にするであろう機能要件。
機能要件は、プロジェクトのゴール設定と言っても過言ではなく、これが定まらないとゴールを決めずにマラソンするようなものだ。
その機能要件と並んで重要なのが、非機能要件である。
非機能要件もプロジェクトのゴール設定なのだが、目に見えづらい要件であるため、裏のゴールと覚えてもらいたい。
例えるなら、ゴールをしたと喜んでいたら、裏のゴールを達成できておらずに、失格になるようなものだ。
今回は、プロジェクトの成功を左右する機能要件と非機能要件について説明していく。
これらを身につけることができれば、プロジェクト成功確率はぐっと高まるはずだ。
目次
機能要件とは
機能要件とは、顧客が構築するシステムに求める機能のこと。
プロジェクトで構築するシステムの目標となるため、プロジェクトのゴール設定と言えるだろう。
機能要件は、画面・帳票・バッチに大きく分類される。
例えば。
販売製品や販売履歴が見れる画面が欲しい。
帳票
製品納品の納品書を自動作成して欲しい。
バッチ
月末の支払業務を自動化して欲しい。
機能要件の書き方
機能要件は、システム開発の要件定義の初期段階で洗い出すことになる。
顧客が完成形のイメージを持っていれば楽なのだが、実際にはイメージを持っていないことが多い。
なぜなら顧客は業務のプロであって、システムのプロではないからだ。
そのため、顧客にヒアリングを重ねながら要件を洗い出していくことになるだろう。
具体的な手順を紹介しよう。
①背景や目的を明確にする
顧客は何らかの目的があってシステムが欲しいと思っている。
まずは背景と目的を明確にしよう。
背景と目的をキチンと理解できていないと、議論がまとまりにくくなり、要件を絞り込むときの判断材料も不足することになる。
②必要な機能を洗い出す
最初は顧客が求める機能をヒアリングすることから始める。
その後、ヒアリングした内容を図や表にまとめたり、具体的な画面や帳票のサンプルを作ったりしながら、具体的にイメージができるようにする。
業務改善のシステムならば、業務フローから必要な機能を洗い出すことが多いだろう。
③機能要件の選定
全ての機能を開発するだけの予算が顧客にあれば良いのだが、現実的には予算の都合で機能を絞り込むことになる。
機能毎の概算工数（費用）を提示しつつ、機能削減した際の代替案を検討していく。
・利用頻度の低い画面や帳票は、Excelやメールで作業する
・画面の一部の便利機能（例えばグラフ表示機能）を外す
・開発費用の少ない簡易機能を提供する
ちなみに、費用を提示する場面では、
「もっと安くできないか？」
と、顧客と値引き交渉になる場合も多い。
このような交渉に備えて、値引きを前提で費用を提示するという策も必要だろう。
機能要件のサンプル
機能要件のサンプルをExcelにまとめたので活用して欲しい。
あえて最終局面ではなく、検討途中のサンプルとしているが、機能要件の雰囲気は伝わるはずだ。
非機能要件とは
非機能要件とは、顧客が機能面以外にシステムに求める要件のこと。
稼働率やシステム性能、セキュリティ、保守サービスなどの要件だ。
機能要件と並んで、システムの目標となるため、プロジェクトのゴール設定と言えるだろう。
非機能要件を検討する際には、情報処理推進機構（IPA）がまとめた非機能要件グレードがとても参考になる。
（ちなみに、IPAは情報処理技術者試験を行なっている有名な機関だ）
IPA（情報処理推進機構）では、以下の非機能要件を6大項目として定義している。
| 分類 | 概要 | 要件項目の例 |
|---|---|---|
| ①可用性 | システムの継続利用 | ・障害や災害時における稼働目標 |
| ②性能・拡張性 | システム性能、将来の拡張 | ・画面レスポンス ・データ増加 |
| ③運用・保守性 | 運用と保守のサービス |
・稼働時間 ・データバックアップ ・システム監視 ・計画停止 ・サポート体制 |
| ④移行性 | 現行システムからの移行 | ・移行スケジュール ・移行方法 ・移行データ |
| ⑤セキュリティ | セキュリティの確保 | ・認証機能（ログインなど） ・機能制限 ・データの暗号化 |
| ⑥環境・エコロジー | 設置環境や規格 | 耐震や温度、湿度、騒音など |
(IPA 非機能要求グレード より抜粋）
非機能要件の書き方
非機能要件は、機能要件と同じく、システム開発の要件定義の初期段階で洗い出すことになる。
しかし、機能要件と比べて、非機能要件の検討は難易度が高い。
というのも、非機能要件は顧客が意識していない場合が多く、私たちシステム屋から要求を定めていく必要があるからだ。
具体的な手順を紹介しよう。
0.機能要件の検討が完了していること
当たり前かもしれないが、非機能要件を検討するのは、機能要件の検討が完了した後になる。
機能が変わってしまえば、裏側の要件である非機能要件も大きく変更されて無駄になってしまう可能性があるからだ。
1.自分たちで非機能要件の仮設定
まず最初に非機能要件の洗い出しを行うわけだが、前述したように顧客側は非機能要件を意識していない場合が多いため、
「非機能要件は何かありますか？」
と聞いたところで何も得られないだろう。
そこでまず、私たちシステム屋から非機能要件の一覧表を仮作成する。
作成する際は、可用性や性能・拡張性などに分類しつつ、構築するシステムの特性に応じて要件を仮決めしていこう。
検討の際は、IPAの非機能要件グレードが参考になるだろう。
非機能要件グレードでは、モデルシステムと、非機能要件のレベルが記載されている。
・社会的影響がほどんと無いシステム
・社会的影響が限定されるシステム
・社会的影響が極めて大きいシステム
＜可用性の継続性レベル＞
レベル１：定時内（9時〜17時）
レベル２：夜間のみ停止（9時〜21時）
レベル３：1時間程度の停止（9時〜翌8時）
レベル４：若干の停止あり（9時〜翌8:55）
レベル５：24時間無停止
IPAの非機能要件を参考にすれば、検討すべき項目の漏れを減らすことができるはずだ。
2.非機能要件を顧客と設定
私たちシステム屋で、非機能要件一覧の仮作成ができた後は、顧客に適切な要件を確認する。
例えば。
「システムの稼働時間は9時〜21時ではなく、6時〜22時として欲しい」
このような具体的な要件が出てくるはずだ。
注意しなければならないのは、要件の理由をしっかりと聞き、メモをしておくこと。
・始発で出勤して作業をする人がいるため
・残業終了時間が22時のため
要件の理由をメモしておかないと、顧客が言った要件を採用するしかなく、代替案が提示できない。
また、思いつきで回答する顧客もいるため、理由はしっかり聞いた方がいいだろう。
3.非機能要件の選定
非機能要件も要件に応じて必要なコストが変わってくる。
例えば。
②24時間フル稼働のシステム
→当然、②の方がコストが高い。
・データバックアップ
・ツール開発の必要性
・運用保守の負担増加
「品質は良ければ良いほどいい」と考えるのは当然だ。
だが、非機能要件を充実させればさせるほど、コストが高くなることを顧客にも認識してもらい、要件を選定していこう。
非機能要件のサンプル
非機能要件に悩んでいる方のために、サンプルを用意した。
無料でダウンロードできるので、ぜひ参考にしてほしい。
色々と書いているが、IPAの非機能要件グレードを参考にすれば、時間をかけずに作成できるはずだ。
さいごに
機能要件と非機能要件について説明してきた。
機能要件
顧客がシステムに求める機能のこと。
画面・帳票・バッチに大きく分類される。
非機能要件
顧客が機能面以外でシステムに求めること。
稼働時間や復旧時間目標、レスポンス、セキュリティなどの検討項目がある。
近年、システムは社会インフラとなっており、システム障害が社会に与える影響が日に日に増している。
このため、今後もシステムの品質への注目は増すばかりだろう。
日経コンピュータの調査結果で、システム障害の原因は主に要件定義にあることが分かっている。
要件定義の中でも最重要と言えるのが、機能要件と非機能要件によるゴール設定だ。
プロジェクトの成功を左右するのは言うまでもなく、プロジェクト完了後の運用保守でも大きな影響を与える。
しっかりと作り方を学んで欲しい。
参考になれば幸いだ。
要件定義工程の関連記事はこちら。
コメントを残す