必ず知っておきたい要件定義でやるべきこと#1.2

必ず知っておきたい要件定義でやるべきこと#1.2

必ず知っておきたい要件定義でやるべきこと#1.1での内容、要件定義でやるべきことをより深く理解、習得するためページです。もし#1をご覧になっていない場合には要件定義でやるべきこと#1.1を先にご参照ください。

要求が愛味?

要求を基に ToBe モデルを作成し、AsIsモデルと制約を踏まえて新ToBe モデルを作城することにより、要件定義を確定する方法を説明しています。では、実際の全てのプロジェクトで、そのとおりに実施できるでしょうか。要件定義段階になって、「そもそものシステムの目的は何?」、「新しい業務のイメージが湧いていない」、「そもそも何がしたいのかわからない。漢然としている」などといった事態は生じないでしょうか。これはシステム化企画や業務分析がきちんとなされていない、つまり「要件定義への橋掛け~失敗しないシステム開発の準備#1~」の内容が実施されていない状態です。

要求が明確でない状況です。当然、本来あるべき ToBe モデルは存在しません。存在したとしても要件定義には役にたたない代物です。現実は残酷です。「本来そうあるべき」という議論を蒸し返しても、間題は解決しません。前工程で実施すべき作業がきちんと消化されていなかったら、この「要件定義」の工程できちんと消化し、次工程の設計工程以降への悪影響を断ち切るしかありません。要件定義を含む上流工程の不備は、システム開発に大ダメージを残します。ゆえに、どうような事態であれ、要件定義を完逐し、問題を後工程へ先送りしないためには、前工程の不備もすべて要件定義で吸収しなくてはならないのです。考えられるパターンは以下の2つです。

  • ToBeモデルが存在する場合には、AsIs モデルと制約を踏まえて、ToBeモデルから新ToBeモデルを作成することにより要件定義を行う。→「要件定義への橋掛け~失敗しないシステム開発の準備#1~」の内容がきちんと実施された状態です。
  • 要求が暖味でToBeモデルが存在しない場合には、要求を明確化しつつ、ToBeモデルを作成することにより要件定義を行う。→「要件定義への橋掛け~失敗しないシステム開発の準備#1~」の内容が実施されていない状態です。

上記の①②いずれの場合でも、「要件定義」の工程では最低でも以下の2点をまとめ上げなくてはなりません。

・要件としての合意を可能とするもの

・設計工程のインプットとして有用なもの

言うのは簡単ですが、実際に行うとなると大変なことです。システム開発プロジェクトの失敗はほとんど、ここがうまくできなかったことに起因しているといえます。もし要件定義からアサインされて、前工程の成果物が曖昧だったり使い物にならないようなら、要件定義工程の期間延長を堂々と主張し、WBSに反映させましょう。

「要求→要件」を明確にする手順

要件を定義しつつ、「要求→要件」のトレーザビリティを明確にする具体的な手順は以下のとおりです。

Step1 要求階層の確認

再度、各「ビジネス要求」「業務要求」「システム要求」の分類が正当かを確認します。さらに「ビジネス要求」から「業務要求」、「業務要求」から「システム要求」、「ビジネス要求」から「システム要求」へのブレイクダウンが正当かを確認します。ToBe モデルが存在する場合には、モデルが各要求を反映したものになっているかを確認します。ToBeモデルが存在しない場合には、「要件定義への橋掛け~失敗しないシステム開発の準備#1~」で示した方法で、要求の明確化と階層化を行います。この場合、ToBeモデルの作成は、時間的に難しいので、あくまで要求の明確化に専念します。

Step 2 要求から要件へ

「ビジネス要求」のうち「ビジネス要件」へ、「業務要求」のうち「業務要件」へ、「システム要求」のうち「システム要件」になりうる事項を確認し、対象になった事項に限り、各々の要件として整理します。ToBeモデルが存在する場合には、ToBeモデルからAslsモデルを踏まえて新ToBeモデル作成の準備を行います。ToBeモデルがない場合には、要件化に注力し、要件から新ToBeモデルを作成する準備を行います。

Step3 要件の整理

整理された各要件について「ビジネス要件」から「業務要件」へ、「業務要件」から「システム要件」へとブレイクダウンしうる事項を抽出し、整理していきます。ここでは要求分析にて「ビジネス要求→業務要求→システム要求」へとブレイクダウンできなった要求が、スライドした要件が対象です。システム要件へのブレイクダウンは、注意を払って行う必要があります。

Step 4 システム要件の確定

「システム要求」から要件化した、もしくは「業務要件」からブレイクダウンして要件としてまとめられた項目について、システムで実現すべき「システム要件」として定め、実現へ向けた対応方針を、要件定義書にまとめていきます。この際に、単に要求をそのまま要件化するのではなく、「一見、実現性が薄い」、「ビジネス上のインパクトが弱い」といった要求には、よりビジネス価値を高める代替え案を想定し、それを要件化していきます。ここが要件定義工程の「胆」になります。

Step 5 要件範囲の明確化

整理されたシステム要件を基に、対象となる機能/非機能を一覧化することにより明確にします。この段階では、その時点でわかっている範囲内で構いません。どのようにシステム要件として落とし込むか未定の場合は「未決」とし、データモデル、プロセスモデル作成の時まで放っておいても構いません。新規開発案件の場合は、システム全体のイメージと想定しうる機能、修正(保守)の場合は、対象機能とシステム全体への影響を明らかにします。この時点で、ビジネス要件を基にした新 ToBeビジネスモデルを確定させます。

実施作業の場合分け

これらの作業項目を、下記のような場合分けに応じて、適宣、実施していきます。

エンタープライズ系システム→新規❶→修正③

コンシューマー向けシステム→新規❷→修正④

上の❶と❷の場合、エンタープライズ系かコンシューマー向けシステムを問わず、要求から要件へとトレースできる環境作りを行う必要があります。コンシューマー向けシステムの場合、システム要件までの落とし込みを、時間をかけずに行い、「未決」事項になりそうな要件はとりあえず後まわしにして、要件を確定させます。③と④の場合もビジネス要件、業務要件、システム要件各々の修正レベルに応じて対応します。コンシューマー向けシステムにおける修正の④は、ビジネスに大きな影響を与える場合を除き、業務要求、システム要求からシステム要件までの移行、ブレイクダウンを迅速に行い、ビジネス要求との整合性を後回しにしてでも、速やかに設計実装を行うべき場合があります。与えられた状況の中で、どこまで正確な整合性を求めるか迅速性を求めるか、決めていく必要があるのです。

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

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

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

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