要件定義で定める内容

要件定義で定める内容は以下のとおりです。なお各会社ごとや対象とするシステムの種類ごとに様々な進め方が存在しますので一つの例として捉えてください。

業務フロー

業務フローには、機能が使われる背景となる業務の流れを記述します。システムの機能は主に人が使うわけですから、その背景である業務・人の動きを把握することは非常に重要です。

機能定義

要件定義で定める内容の中核となるのは機能定義です。システムが提供する機能について説明を記述します。企業システムでは、「受注登録」「顧客情報照会」というように、「○○という情報を登録する」「××という情報を照会する」といった情報の出し入れが主な機能となります。

概念モデル

概念モデルには、システムが管理する情報の体系を整理します。企業システムの主な役割は情報を管理することですので、その情報の体系の整理が必要です。これらを記述した上で、整合がとれている事を確認していきます。要は「システムをどう使うか(＝業務の流れ)」「システムは何をしてくれるのか(＝機能)」「システムは何を(どんな情報を)管理するのか(＝情報の体系)」を整理していくのです。

業務フロー、機能定義、概念モデル

非機能要件

上で述べたものは機能要件と呼ばれるものです。もう一方で非機能要件という、システムの性能や信頼性などを定めていく作業があります。

例としては、どのくらいの数のユーザがどの程度アクセスするか(性能要件)、継続して稼動した時にどの程度のシステムダウンが許容されるか(信頼性要件)といった情報を定めて行きます。これらの情報は、ハードウェア等を選定していく際などに用いられます(当然、高い要求に対しては、高価なハードウェアを用意するわけです)。

なぜ要件定義をするのか

ここで「要件定義をせずに、直接プログラムや設計書を作ってしまえば良いのでは?」と疑問に思う人がいるかもしれません(特にこれまでプログラミング経験がある人ですね)。しかしある程度以上の規模のシステムでは、きちんと要件定義書を作成することは非常に重要なのです。

ユーザの要望を文書化する過程で、曖昧な点を明確化することができます。またユーザの本質的な要求と単なる思い付きをふるいにかけることができます。これらのプロセスを軽視して直接開発してしまうと、全体の整合が合わなくなったりシステムが肥大化してしまったりするのです。

要件定義の難しさ

要件定義は非常に難しい作業です。コンピュータ相手ではなく人が相手であるにも関わらず、最終的にプログラムに落ちるよう整合を保つ必要があるからです。

ユーザと長い時間をかけてシステムの実現イメージをすり合わせたにも関わらず、稼動後に「こんな想定じゃなかった」と言われてしまうこともあります。また二人のユーザの矛盾した要求の調整に奔走させられる場合もあります。

要件定義には、システムでの実現可能性を判断する技術スキルとともに、業務とシステムの橋渡しとなる領域でうまく整合性を保ち、ユーザに納得してもらう、という論理的思考力をはじめとする様々なスキルが必要となるのです。

皆さんの多くは、最初は要件定義ではなく、プログラムの開発などに関わることが多いと思います。ただそのシステムは、必ず何らかの企画や要件を元に始まっているはずです。これから関わるシステムごとにその目的や背景の業務を理解し、そして数年後には、是非このように難しく面白い要件定義にたずさわっていただきたいと思います。

執筆者紹介

吉村泰生(YOSHIMURA TAISEI)
- ウルシステムズ コンサルティング第2事業部 シニアコンサルタント


IT系コンサルティング企業を経て、2006年より現職。製造、金融、サービス業等、多岐に渡る業種でビジネスモデリング・開発上流工程に多く携わる、自称 業務モデラー。