要件定義の進め方とポイント（1）

はじめに

　多くの企業にとってITは必要不可欠であり、年々その重要性を増しています。一方、多くのシステム導入がQCDの観点で失敗しています。その比率は7割程度あり、原因の多くは要件定義工程にあると言われています。（参考：企業IT動向調査報告書2017、ソフトウェアメトリクス2016）
本コラムではシステム導入を成功させるために、要件定義の進め方とポイントを順次紹介します。

要件定義工程の位置づけ

　要件定義はシステム導入の初期工程であり、企画工程と基本設計工程の間にある上流工程です。企画工程は、企業のニーズや課題を解決するための新業務の全体像とシステム構想を検討する工程であり、成果物としてはシステム化計画書等があります。後続の要件定義工程では企画工程の成果物を基に、ステークホルダーの課題やニーズを分析し、ビジネス要件を定義します。また、システムで実現する要件について関係者と合意をとり、システム要件とします。

要件定義工程の進め方

　要件定義工程は、ビジネス要件定義、システム要件定義、およびマネジメント＆コントロールに分類されます。

A. ビジネス要件定義

A-1.現状把握

　要件定義の最初の段階として、ステークホルダー間で現行業務に対して共通認識を持つ必要があります。また、システム再構築の際には既存システムで実施している業務の理解も重要になります。現行システムおよび業務について可視化し、把握できる状態にします。

A-2.課題やニーズの抽出

　次に対象業務に関する課題やニーズを抽出します。基本的にはステークホルダーにヒアリングの形で収集することが多いですが、ニーズの抜け漏れがある、ステークホルダーによって課題が異なる、大量にニーズが集まって収集がつかなくなる等、多くの問題が内在しているフェーズです。

A-3.課題やニーズの分析

　抽出した課題やニーズは粒度も抽象度も異なるものが混ざっているため、分析を行い整理します。重複しているニーズを排除したり、代替手段を検討したり、深掘りして真のニーズを探したりします。また、大抵のシステム導入プロジェクトでは当初想定していた規模よりも多くの課題やニーズが抽出されます。すべて対応するのが現実的ではない場合は極力当初目的に沿う形で優先順位付けを行います。そのため、企画工程で検討した経営レベルの目的・目標をブレイクダウンし業務レベルの目的・目標を明確にしておく必要があります。

A-4.要件の合意・文書化

　整理した課題やニーズ（=解決すべき要件）についてステークホルダーに説明の上、合意をとります。特に課題やニーズを棄却する場合はステークホルダーへの十分な説明が必要です。そのためにはA-3.にて検討した業務レベルの目的・目標、および優先順位について明確にしておく必要があります。どうしても合意形成が難しい場合は棄却ではなく先送り（別タイミングでシステム化）等の代替案提示、ステアリングコミッティへのエスカレーション等を行う場合もあります。最後に、合意した要件に対して文書化し、エビデンスとします。

ビジネス要件定義にて作成するドキュメントとしては、
・課題・ニーズ一覧、課題原因分析図、要件一覧
・ステークホルダー一覧
・ビジネスプロセス関連図、新旧業務フロー、業務機能構成表
等があります。

B. システム要件定義

B-1.要件の仕様化

　導入する情報システムや製品が技術面・運用面・利用面等で問題ないか確認できる文書を作成します。システム開発系のプロジェクトの場合、作成するドキュメントとしては以下のようなものがあります。
・機能系・・・システム機能階層図
・インターフェイス系・・・画面一覧、帳票一覧、画面遷移図、画面レイアウト
・データ構造系・・・テーブル一覧、テーブル定義書
・その他・・・非機能要件書、移行計画書

なお、要件定義までは社内リソースで、後工程以降を外部ベンダーに発注するケースも多いため、ここで作成する文書についてはなるべく抜け漏れやあいまいさのない文章で表現し、業務を把握していない外部ベンダーでも理解できる表現を心がける必要があります。

B-2.確認・評価

　作成された文書が要件を満たしているか確認します。要件定義書に漏れがあった場合、後工程になればなるほど手戻りに必要なリソースは肥大化していきますので、しっかりレビューを行う必要があります。レビュー手法としてはインスペクションやウォークスルーがあげられます。
また、要件の妥当性確認の際には業務部門の方にも確認・評価してもらう必要がありますが、ITに慣れていない担当者の場合はレビューすることが難しいケースがあります。実業務と照らし合わせた別ドキュメント等を用意し補助資料として利用する等、工夫して進める必要があります。

C. マネジメント＆コントロール

マネジメントは上記A,Bに共通する管理業務となります。

C-1.計画（立ち上げ）

　企画前工程で検討した構想の確認、およびオーナーやステークホルダーの特定、チームビルディング等を行い、要件定義工程のスケジュールを作成します。また、進捗/課題/品質等のプロジェクト管理方法を検討し、計画書として文書化します。

C-2.コントロール

　ビジネス要件定義、システム要件定義中は進捗や課題、品質のモニタリングを行い、必要に応じてキャッチアップ等の施策を適宜実施します。

C-3.終結

　計画通り要件定義工程が完了したことを確認の上、工程の完了についてオーナーと合意をとります。

次回コラムから、要件定義工程の各プロセスについて成功のためのポイントを紹介していきます。