EAフレームワークに基づく要件定義の実践

はじめに

こんにちは、オプスイン開発部の乾です。私は現在システム開発プロジェクトの要件定義を担当しています。

早速ですが本記事の結論から申しますと、要件定義で成果物を体系的に作成することで、EAを実践しつつ顧客から信頼いただけるシステム開発を実現していきたい、と考えています。

要件定義とは

システム開発における要件定義とは、何を作るかを決める工程です。要件定義が終了すれば、（理想的には）あとは要件定義書にしたがってシステムを作るだけです。よって、要件定義で重要なのは、どんなシステムを作るかについて、顧客と合意することです。

具体的には何をもとに合意すれば良いのでしょうか？IPAの資料室には、機能要件の合意形成ガイドとして下記が上がっています。

1. システム振る舞い設計
2. 画面設計
3. データモデル設計
4. 外部インタフェース設計
5. バッチ設計
6. 帳票設計

オプスインではこれらの要件定義フェーズの成果物として特に下記の項目を重要視し、テンプレート化しています。

1. 業務フロー図
2. 機能リスト
3. 画面リスト
4. 外部インタフェースリスト
5. バッチリスト
6. インフラ構成図
7. 非機能要件リスト

EA

一方、EA（エンタープライズアーキテクチャ）という言葉をご存知でしょうか？

サイト https://www.cloudtimes.jp/dynamics365/blog/enterprise-architecture.html から引用すると、

EAとは経営戦略とITを絡めた全体最適化によって、顧客ニーズをはじめとする社会環境や情報技術自体の変化に素早く対応するための構造です。EAを実践することで企業は組織全体で統一された情報、効率良く整備された業務プロセスを手に入れることができ、利益率をアップしたり、新たなビジネス価値を創出することができます。

となります。参考までにEAは４つのアーキテクチャからなります。

1. BA（ビジネスアーキテクチャ ）
2. AA（アプリケーションアーキテクチャ ）
3. DA（データアーキテクチャ ）
4. TA（テクノロジーアーキテクチャ ）

概念的にはわかったような分からないような、実現できたら良いとは思いますが、実際にどうしたら良いかが分からないですよね。再びIPAの資料室に戻りますが、EAフレームワークがあります。ここではEAの各アーキテクチャをEAプロセスと主要成果物として下記のように定義されています。

1. BA
   1. BA-1 （ファンクション/プロセス分析）
      1. DFD
   2. BA-2（情報分析）
      1. 情報リスト
   3. BA-3（業務フロー作成）
      1. 業務フロー
2. AA
   1. AA-1（システム機能定義）
      1. システム機能階層図
      2. システム機能定義書
   2. AA-2（システム関連定義）
      1. システム関連図
      2. システム間インタフェース定義書
3. DA
   1. DA-1（概念データモデル作成）
      1. 概念ERD
   2. DA-2（論理データモデル作成）
      1. 論理ERD
      2. データ量一覧表
4. TA
   1. TA-1（ネットワーク構成定義）
      1. ネットワーク構成図
   2. TA-2（ソフトウェア構成定義）
      1. ソフトウェア構成図
   3. TA-3（ハードウェア構成定義）
      1. ハードウェア構成図

ポイントはこれらのプロセスは階層化され順序があるため、先のプロセスの成果物が決まらないと後のプロセスの成果物は決まらないということになります。また、先に挙げた要件定義工程の成果物とほぼ一致しています。明示的にドキュメントには残していなくても、暗黙の内にこれらの設計を行っていることを実感しています。

まとめ

最後にまとめとして、要件定義では上記の成果物を顧客の合意を得ながら作ることで、顧客に信頼いただけるシステム開発を目指します。