システム設計の登竜門!要件定義入門#1

システム設計の登竜門!要件定義入門#1

システム開発において意図せずに誤った方法、施策を取ることは絶対注意しなければならいと思います。この記事はその基本的、概念的な回避方法を記載しました。是非一読ください。

システム開発における「要件定義」とは?

システム開発における要件定義とは、「要求分析結果を基に、システムで実装すべき制約を明確にし、『要件』として確定すること」を指します。

(ここで「要求」と「要件」の違いを整理します。

「要求」= 本当に欲しいもの

「要件」= 本当に要るもの

要求と要件の違いを簡潔に言い表すとしたら、このようになります。)

確定された要件については、ステークホルダー間(その要件や要求において関係のあるまたは関係するであろうすべての人)で合意を得る必要があります。つまり、関係者の特定の人に理解がされるのではなく、関係者全員の合意を至ることが可能な表現を用いる必要があります。さらに、次工程である「設計工程」のインプットとして有用つまり「設計が可能な状態にすること」が求められます。そのためには、後工程の技術者がわかる表現でなければなりません。この二点を満たしてこそ、要件定義は初めて意味を持ちます。

本来の要件定義の位置づけ

要件定義で行う作業は、要求を基に制約を考慮し、現状分析を経て要件として明確化することです。そのためには、要求を見直し、修正を加えることによって、要件定義が可能となるくらいにまで、要求が明確にならなくてはいけません。この場合の「要求」とは、要求事項の羅列を指すのではありません。「ToBeプロセスモデル」すなわち「プロセスのあるべき姿」と、「ToBe概念データモデル」すなわち「データのあるべき姿」が、既に作られている状態を指します。ここで述べた「プロセスモデル」とは、「企業組織の仕事の仕方を図解したもの」と表現する人もいます。要求分析と要件定義の作業を列挙してみます。

1.じっくりと時間をかけて要求を明確化し、ToBe ビジネスモデルを検討する。

2.明確化された要求を基に、ToBe (あるべき)プロセスモデルと ToBe概念データモデルを作成する。

3.AsIs(実際に今ある)モデルを検証。(…ここまでが要求分析で行うべき作業です。)AsIsモデルを参考にして、人、モノ、金等のプロジェクトとして意識

4.絶対制約を考慮しつつ ToBeの実現可能性を検討する。

5.もし、実現可能性が低いと判断されたら、ToBeを修正し、新しいToBeのプロセスモデルとデータモデルを作成する。

6.AsIsから新ToBeモデルへ至るプランを考える。

4.以降が要件定義で行うべき作業です。また、5.の内容を一言で表せば、「理想を現実に近づける作業」だと言えます。実際には、元のToBeモデルを修正して作成します。上記のように、ToBeに充分な時間をかけて、業務フローレベルまで落とし込んでいれば、そこから実現可能な ToBeを策定することは比較的容易です。

上の図のように、①理想の ToBe を考え抜き、「要求」をモデルの形にまとめ、そこへ②ASIS分析を通じて現状を加味することで③「要件」としてまとめ上げ、実現を目指すための新しい ToBeモデルを作成する、この手順を踏むのが理想です。①理想のToBeと③実現を目指す ToBeの差は、② AsIs と制約を実現可否の判断材料として反映させたものになります。とはいえ実際には、要件定義の前段階において、要求をToBeモデルにまで落とし込むことをしない、もしくはできなかった開発プロジェクトが数多くあるでしょう。

要件定義を行う上での前提条件が異なる下記の2パターンについて、要件定義のやり方を説明していきます。

A)要求がToBeモデルに落とし込まれている(本来目指すべき形。要求分析がきちんと行われている場合)。

B) 要求がやや暖味であり、ToBeモデルは存在しない(要求分析がきちんと行われなかった場合)。

機能の使用を確定すること

要件定義は「要求」を「要件」に落とし込む工程です。要求段階において要求は、ビジネス(経営レベル)、業務(現場レベペル)、システム(エンドユーザーが操作する機能レベル)という、それぞれのユーザーの立ち位置から現出してきます。要求はあくまでユーザーから出てくるものですから、それを分析する過程において、要求を何らかのフォーマットに落とし込んで整理する際には、ビジネス表現、つまりユーザーが理解できる表現でなければなりません。

では、要件定義ではどうでしょうか。要件に関しても同様です。何が要件として整理されたかを、ユーザーが理解できなければなりません。さもないと、合意を得ることもできません。要求と要件で異なる点をひとつだけ挙げるとすれば、要件を定義した結果は、設計工程におけるインプットとして、有益でなくてはならないことでしょうか。

そのため、要件定義のアウトプットは、「ユーザーが理解できるビジネス表現、かつ、設計工程においても使用可能なもの」である必要があります。設計工程で役立つためには、これから作るシステムの具体像がなければなりません。そのため、様々な立場の誰が見ても「わかりやすい」ということに尽きます。そして、そんな「わかりやすい」表現を使って、「方向性が適切か」見極め、そしてその方向性を実現するための「枠組みを明確にして具体化」していくことになります。

要件定義の範囲

どこまでの作業を要件定義の工程とみなすかは、実はプロジェクトによって異なります。「要件定義プロセスとタスク(成果物)の関係についてはプロジェクトによる」という考えが一般的でもあるようです。本書で説明する要件定義は、「実装(HOW)を意識せずに、まずは何システム開発における「要件定義」とは?(WHAT)をきちんと定義すべき」という考えに悲づいています。実装を意識せずに定義するのはデータ、プロセス、機能等に関する事項に及びます。

a)機能/非機能要件の確定まで:開発対象のシステムで必要とされる機能/非機能要件を、全て確定させるところまでを、要件定義にて行います。b)機能/非機能の目的·方向性の明確化まで:想定したアーキテクチャを基盤とし、データとプロセス、そして必要となる機能、UIについて確定させるところまでを要件定義にて行います。b)はa)の途中までを実施する形になります。本書ではb)を基本としつつ、a)と b) 2パターンのどちらの場合にも当てはまるよう説明していきます。システム設計の登竜門!要件定義入門#2は今回の記事内容の補助とより深い理解を意図した記事になります、続けてご覧ください。

【広告】Librus Tech Communityのお知らせ

Librus株式会社が運営する、システムエンジニアやプロジェクトマネージャーの方向けに展開するコミュニティにぜひご参加ください。「互いに助け合い、学び合う空間」をコンセプトに、システム開発に関するセミナーや勉強会をはじめ、案件や転職先のご紹介、相談対応も行います。エンジニア初心者の方や起業、現在フリーランスをされている方、フリーランスを目指している方も大歓迎です。

▼Slackコミュニティ入会フォーム
https://forms.gle/1D5duKwVJhm1vFb18

テックカテゴリの最新記事