要求定義とITCプロセス

私は、ITコーディネータ制度が出来て、第1号のグループで資格取得しました。
受験した動機は、ITCプロセスガイドラインで提示された経営戦略からITの構築・運用を一貫して統治するITガバナンスの考え方に感激したからです。
ただ、最近になって要求定義の勉強を始めました。その勉強を通して感じますことは、ITCプロセスガイドラインだけでは“経営とITの橋渡しは無理ではないか?”と思い始めました。

“業務プロセス構築”の分野に対するガイドラインが弱い気がします。
ITを活用して経営戦略のための業務プロセス作りが出来て始めて“経営とITの橋渡しではないか?”と思っています。
従来、アプリケーションシステムの構築に係る要件定義、基本設計、詳細設計、開発・テスト、移行と進む各フェーズの中で、特に“要件定義”、“基本設計”のフェーズは属人的な要素が色濃く残っていました。
結局、“ユーザー任せ、またはベンダー任せ”になっていました。

ITCプロセスもその時代を反映してその部分と経営とITのつなぎに関する標準化されたアプローチガイドが抜けているのです。

要求定義の観点から、保管が必要と思われる部分を列挙してみましょう。
経営戦略フェーズにおいて、一般的にはBSCの内部業務プロセスの視点で導き出される戦略目標としてのIT領域戦略課題から要求定義はスタートします。

1.戦略目標としてのIT領域戦略課題はCOBITでいう「ビジネス達成目標」になります。要求定義としてのIT領域戦略課題の記述です。

2.COBITの情報要請規準に基づいて、ビジネス要求をIT化目標に変換する記述でCOBITでは「IT達成目標」として定義しています。
構築するシステムは何を目的に構築するのかを定義しますので、DFDでいうコンテキストダイアグラムに相当した定義が必要です。

3.IT達成目標が決まって、エンタープライズを構成する要素の関係を定義する記述です。
ジェネリックモデルのビジネスプロセスモデルのレベル0の記述です。
この分野は事業間や企業間のデータフローと業務ルールを定義が必要です。

4.この後は、ビジネスプロセスモデルのレベル1,2の要件定義でよく活用している記述分野です。
ただ、DFDには業務ルールの記述がありません。このルール記述の追加が必要と思われます。
理由は、業務処理を分割していきますと「受付処理」、「更新処理」、「出力処理」等の各業務処理で似たような処理が出てきます。
これらの処理は業務ルールを外出しで設計することでより簡易なモジュール構造になるからです。
その例は、電子政府のエンタープライズアーキテクチャのEEM(Entity Event Matrix)にその例を見ることが出来ます。
この分野の定義も必要です。
ITCプロセスガイドラインもこの分野の記述を加えたほうが良いような気がしています。

今回はここで終わります。
次回は、IT戦略のテーマとして「サプライチェーンとDFD」を捉えてみます。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする