システム開発・要件定義の心得:合意形成について#1

システム開発・要件定義の心得:合意形成について#1

本項ではシステム開発の最終確認、「システム要件」として整理された要件について、開発者とユーザーの間で合意するための方法を説明します。併せて、「ビジネス要件(社外の要件)」「業務要件(社内の要件)」について実現性を含め確認を行います。

合意形成

本来、システム開発プロジェクトにおいては、「システム要件」についてのみ、合意を得られれば目的は達成されるのかもしれません。ただ、前述のとおり、情報システムはビジネスや業務のストーリーを通して、ユーザーにとっての価値を提供するものです。単なる項目の羅列では、開発予定のシステムの妥当性を判断し、合意に至ることはできません。

ビジネスと業務のストーリーを意識しつつ、「システム要件」とともに「ビジネス要件」「業務要件」に関しても、対象となるステークホルダーに確認し、合意を得ます。対応関係は以下の通りです。

「ビジネス要件」→経営層ビジネス責任者

経営トップ及び該当ビジネスの責任者との間では、ビジネスの方向性を明確化する目的で、「ビジネス要件」として整理された要件、かつ「業務要件」「システム要件」にブレイクダウンしない(できない)要件について確認し、合意形成を行います。併せて、「ビジネス要求」として整理されたものの「ビジネス要件」とならなかった事項に関しても、最終的に確認します。

「業務要件」→ビジネス責任者・担当者

該当ビジネスの責任者及び担当者との間では、業務の方向性を明確化する目的で、「業務要件」として整理された要件、かつ「システム要件」にブレイクダウンしない(できない)要件について確認し、合意形成を行います。業務フロー(生産→配送→販売のようなプロセスの流れ・塊)と業務プロセス(生産、配送、販売、などの業務のプロセスそのもの)は、ITシステムの有無にかかわらず存在しますから、これらの定義に関する合意はここで行います。併せて、「業務要求」として整理されたものの「業務要件」とならなかった事項に関しても、最終的に確認します。

「システム要件」→業務担当者

当該業務の担当者との間で、システムの方向性を明確化する目的で、「システム要件」として整理された要件について確認し、合意形成を行います。併せて、「システム要求」として整理されたものの「システム要件」とならなかった事項に関しても、最終的に確認します。

せっかく苦労して迅速に要件定義を終えても、合意形成に時間がかかるようでは本末転倒です。時間的制約がプロジェクト全体を圧迫することについて、開発者とユーザーの間で共通認識を持ちましょう。それでも合意に時間がかかりそうなときは、プロジェクト全体の工程の中にきちんとバッファを持たせておく必要があります。

つまり「 WBS (Work BreakdownStructure):作業を分解して構造化し、分業する方法」上に定義して、スケジュールを再調整しなければなりません。もちろん、そうならないに越したことはありませんが、ステークホルダーの数が多く、開発対象のシステムが大規模になるほど、合意対象が増えて困難になります。早期に合意形成を終了させるためには、繰り返しになりますが、「わかりやすいもの」を用いることが一番です。

次の項「システム開発・要件定義の心得:合意形成について#2」で続きを紹介しております。是非そろってお読みください。

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