IT コーディネータのための階層化アプローチによる業務システム設計～PGL の経営戦略・ＩＴ戦略策定フェーズ実践の勘どころ～

Ver.1.02013 年 11 月 1 日
特定非営利活動法人 IT コーディネータ協会目 次
はじめに...................................................................................................................................................1
第Ⅰ章 本書の作成目的............................................................................................................................3
Ⅰ-1 本書の狙い ......................................................................................................................................... 4
Ⅰ-2 三位一体の位置づけと本書の記述構造.............................................................................................. 5
Ⅰ-2-1 企業経営における三位一体の位置づけ ......................................................................................... 5
Ⅰ-2-2 本書の記述構造............................................................................................................................. 5
第Ⅱ章 三位一体から見た IT 経営実現プロセス全体像 ...............................................................................7
Ⅱ-1 IT 経営実現プロセス全体像 ............................................................................................................... 8
Ⅱ-2 業務プロセス階層レベルの考え方...................................................................................................... 8
Ⅱ-3 IT 経営実現プロセス全体図の概説..................................................................................................... 9
第Ⅲ章 ＩＴ経営実現プロセスの階層化アプローチ .................................................................................. 13
Ⅲ-1 業務プロセスの視点......................................................................................................................... 15
Ⅲ-1-1 目的............................................................................................................................................. 15
Ⅲ-1-2 目的の達成のための実践ポイント .............................................................................................. 15
Ⅲ-1-3

階層的なビジネスモデルと業務プロセスの定義のアクティビティ........................................... 17

Ⅲ-2

IT システムの視点 .......................................................................................................................... 24

Ⅲ-2-1 目的............................................................................................................................................. 24
Ⅲ-2-2 目的の達成のための実践ポイント .............................................................................................. 24
Ⅲ-2-3 階層的な IT への要求定義のアクティビティ............................................................................... 26
Ⅲ-3 人・組織の視点 ................................................................................................................................ 32
Ⅲ-3-1 目的............................................................................................................................................. 32
Ⅲ-3-2 目的の達成のための実践ポイント .............................................................................................. 32
Ⅲ-3-3 階層的な人・組織の定義のアクティビティ ................................................................................ 33
第Ⅳ章 IT 経営実現プロセスの階層化アプローチの事例........................................................................... 39
Ⅳ-1 経営戦略フェーズの事例................................................................................................................. 42
Ⅳ-1-1

事例企業とプロジェクト概要.................................................................................................... 42

Ⅳ-1-2 経営機能別戦略策定・更新 ......................................................................................................... 44
Ⅳ-1-3 業務システム構想策定 ................................................................................................................ 48
Ⅳ-2 IT 戦略フェーズの事例.................................................................................................................... 53
Ⅳ-2-1

業務プロセスグランドデザイン ................................................................................................ 53

Ⅳ-2-2

人・組織グランドデザイン ....................................................................................................... 59

Ⅳ-2-3

IT システム戦略企画(IT サービス) ............................................................................................. 63

Ⅳ-2-4

IT システム戦略企画(IT 環境) .................................................................................................. 68

Ⅳ-2-5

業務プロセス概要設計 .............................................................................................................. 72

Ⅳ-2-6

IT システム計画・調達 .............................................................................................................. 79i

Ⅳ-2-7 IT 要求の優先順位付け ................................................................................................................87
Ⅳ-2-8 人・組織概要設計........................................................................................................................90
Ⅳ-2-9 業務システムの移行計画.............................................................................................................94◆キーワード解説.................................................................................................................................... 99
参考資料 A:階層的４モデリング方法論 ................................................................................................... 101
参考資料Ｂ:業務プロセス参照モデル ...................................................................................................... 104◆執筆者紹介 (いずれも IT コーディネータ) ......................................................................................... 109◆索引 .................................................................................................................................................. 111

ii

はじめに
2001 年 2 月に IT コーディネータ（以下、ITC）制度が発足してから 10 年が経った。この間、ITC および関係者の方々のご努力により、ITC の知名度は向上し、ITC 活動への期待も高まっている。一方で、日本が米国に比べて、企業における IT の利活用が遅れているという報告があるが、残念ながらこの状況はなかなか改善していないというのが実状である。ITC の現場からは、“ＩＴコーディネータ プロセスガイドライン（PGL）の活用の具体的なアプローチ方法がほしい”といった声が出ていた。
本書は、このようなニーズに応え、IT 経営の確立を支援するための具体的な実践ガイドブックを目的として作成した。IT 経営には経営活動全体を捉えた経営システムとしてのアプローチが必要になる。経営システムは経営目標を達成する経営を行う仕組みの全体と捉えることができるが、この中核にあるのが業務システムである。本書
ではこの業務システムの焦点を当てた。業務システムとは、「業務プロセス」を中心として、「人・組織」、「IT システム」の三要素がお互いに有機的で密接な関係を持つ仕組みである。本書ではこのことを、「人・組織」、「業務プロ
セス」、「IT システム」の三位一体の仕組みと捉えている。
世の中には、業務プロセス設計のアプローチとして、BPM（Business Process Management）等の手法が数多く出されているが、業務プロセスに最適化が確立しているわけではない。本書では、業務プロセスをどのように設計するかという点に力点を置き、「人・組織」の動機付けも含め、「人・組織」が「IT システム」をどのように利活用すべきかという観点も関係づけた。本書はＩＴコーディネータの理念である経営に資するＩＴの利活用という立場に立って、PGL にある IT 経営実現プロセスに焦点を当てた業務プロセスの設計アプローチとして、業務システムの段
階的、階層的モデリング手法を提供する。経営戦略から IT サービス活用に至る IT 経営実現プロセスの 5 つのフェーズを業務プロセスの階層と関連づけ、業務システムの設計・構築を体系図化した。そうすることで、IT 経営実
現プロセスと業務プロセス、IT システム、人・組織の設計をより容易にすることができるからである。
本書では、この体系の中で IT 経営へのアプローチで最重要となる経営戦略フェーズ、IT 戦略策定フェーズに焦点を当てて具体的に解説した。この両フェーズをカバーすることで、より確実な業務システムが構築できるようになるのではないかと考えている。更には、本書で紹介する方法を手掛かりとして、ITC が遭遇するさまざまな状
況に応じて、創意工夫を施し、改良を加え、活用を図ることによって IT 経営を実現するプロフェッショナルとして更にレベルアップしていくことを期待している。

1

第Ⅰ章

本書の作成目的第Ⅰ章 本書の作成目的

3

第Ⅰ章

本書の作成目的Ⅰ-1 本書の狙い
本書は、PGL を活用した ITC 活動のレベルアップを図り、企業のＩＴ経営を実現する業務システムを構築することを目的としている。IT 経営実現に向けた活動をより的確なものとするため、PGL の活用をより実践的にした勘どこ
ろを示すことにある。
その背景には、ＩＴシステム導入には力を入れるが、経営環境の変化に適応しにくいＩＴシステムを導入してしまっているケースが見受けられることにある。本書では、このような問題が生じている原因を解決するために、経営環
境の変化に対応する戦略との整合性をはかりつつ、企業経営の成熟度に合わせ、より柔軟に対応できる業務シ
ステム構築の解決策を提案する。
本書は、その内容を下記の３つの基本概念もとに整理し、その概要を解説する。
①

三位一体を考慮した IT 経営の仕組み作り

IT 経営の実現には、「人・組織」、「業務プロセス」、「ＩＴシステム」の３つの要素が密接に関係した業務システムの構築が求められる。IT システムは業務プロセスを支援し、人・組織は業務プロセスを実施する主体という相互関係がある。したがって、従来の IT システムを中心としたアプローチとは異なり、業務システム全体が対象となる。業務
システムの設計・構築にあたっては、「業務プロセス」を主軸に「人・組織」と「ＩＴシステム」を同期・並行することを重視する。
②

業務システムを構造的に実現する方法論の提示

本書では、最上位で決定した経営理念・経営ビジョン・ミッションを起点として、ビジネスモデルに合った業務シス
テムの機能を上位から下位へと階層的・段階的に分析し設計して構築する方法論を示す。方法論では各階層において、上位の目的から達成手段へと PGL の IT 経営実現プロセスの 5 つのフェーズに沿って「人・組織」、「業務プロセス」、「ＩＴシステム」の３つの要素の相互作用を考慮し、段階的に構築することになる。
業務システムを構造化して実現する方法論として、包括的なフレームワークを提示するだけでなく、属人性によるマイナス要因を極力排除して実行するための方法論を例示した。この方法論を活用することによって、経営戦略
から業務システム構築までの検討の各段階の成果物を、目的からその手段へと階層的に関連付けて整合させることができる。これによって、経営環境が変化した場合でも業務システムの是正・変更箇所を容易に特定して対応できる。
③

参照モデルの活用

方法論の記述に加えて、階層化設計のモデルリファレンスを活用することで効率的な業務システム構築が可能と
なる。

4

第Ⅰ章

本書の作成目的Ⅰ-2 三位一体の位置づけと本書の記述構造
Ⅰ-2-1 企業経営における三位一体の位置づけ
経営システムは、企業外環境と密接な関係を持つ経営目標を達成する経営を行う仕組みの全体をいう。業務シス
テムは、経営システムの中核に位置づけられ、「人・組織」、「業務プロセス」、「IT システム」が有機的で密接な関係をもつ三位一体の仕組みと捉えた。
本書では、「業務プロセス」を中核とし、「人・組織」、「IT システム」を関連づけて業務システムを設計・構築することで、経営システムに寄与し、経営目的を達成できる構造で捉えている。
図表Ⅰ-2-１-1 三位一体の位置づけ
企業外環境（国、社会、 技術、自然環境、市場・顧客、サプライヤー・パートナーなど）
経営システム（経営目標を達成する経営を行う仕組みの全体）

経営目的・
目標

業務システム（三位一体の関係をもつ
業務の仕組み）人・組織

業務プロセスＩＴシステムⅠ-2-2 本書の記述構造
IT 経営実現プロセスは 5 つのフェーズの整合性をもって経営戦略を業務プロセス改革へつなげることである。つまり、この 5 つのフェーズ間の整合性がなくなると、経営戦略と整合しない業務プロセスが出来上がる。フェーズ間の整合を保つためには、フェーズ内の課題の解決策を次フェーズへ的確に受け渡す必要がある。本著では、これらのフェーズ内およびフェーズ間に跨る解決すべき主要テーマを整理した。本書の各章の記述概要は以下の通りである。
１） 第Ⅱ章「三位一体から見た IT 経営実現プロセス全体像」
三位一体のアプローチで IT 経営実現プロセスするための全体像を提示した。IT 経営実現プロセスに構築する業
務システムを三位一体の仕組みの各アクティビティとして関連付け、全体像として図式化した。
各アクティビティの機能概説と実施手順、さらに「業務プロセス」、「IT システム」、「人・組織」の 3 つの仕組みのア
クティビティ間の関係を概説した。
２） 第Ⅲ章「IT 経営実現プロセスの階層化アプローチ」「業務プロセスの視点」、「IT システムの視点」、「人・組織の視点」の三位一体の仕組み毎に IT 経営実現プロセス
5

第Ⅰ章

本書の作成目的に跨るテーマを取り上げ、実践のポイント、実施アクティビティ、実施手順を整理した。
（１） 業務プロセスの視点
当該視点では、ビジネスモデルと業務プロセスの階層的定義に関わる実践ポイント、実施アクティビティ、実施ス
テップを整理する。
（２） IT システムの視点
業務プロセス階層から要求されるIT 要求とユーザーからの IT 要求を定義するための実践ポイント、アクティビティ、実施手順を整理する。
（３） 人・組織の視点
人・組織を業務プロセスや IT システムに整合させるための実践ポイント、実施アクティビティ、実施ステップを整理する。
３） 第Ⅳ章「IT 経営実現プロセスの階層化アプローチの事例」「業務プロセスの視点」、「IT システムの視点」、「人・組織の視点」の三位一体の仕組み毎アクティビティの中で重要なテーマを事例として取り上げ整理した。本書は、読者のレベルによって参考とすべき箇所を選択することにな
るが、以下に基本的な読み方を紹介する。
第Ⅰ章において、本書記述の狙いとその狙いの中心になる業務システム設計の前提である三位一体アプローチの必要性をまず理解する。
第Ⅱ章では、「業務プロセス階層レベル」の定義から階層レベルの概念をつかみ、「IT 経営実現プロセス全体像」の解説から本書で使用される各プロセスの全体理解を図る。
第Ⅲ章では、三位一体の各要素毎に階層化されたアクティビティと成果物を理解する。
最後に、第Ⅳ章では、第Ⅲ章で記述したアクティビティの事例のもとに活用法の理解を深める。

6

第Ⅱ章

三位一体から見た IT 経営実現プロセス全体像

第Ⅱ章 三位一体から見た IT 経営実現プロセス全体像

7

第Ⅱ章

Ⅱ-1

三位一体から見た IT 経営実現プロセス全体像

IT 経営実現プロセス全体像

本節の目的は、三位一体アプローチに基づいた IT 経営実現プロセスの改革プロセスとそのプロセス間の関係を全体構造として理解し、さらに後続の節の理解を容易にすることにある。
IT 経営実現プロセスの三位一体アプローチでは、「人・組織の視点」、「業務プロセスの視点」、「IT システムの視点」の 3 つをバランスさせることで業務システムを実効性のあるものにできる。
本節は、以下の２構成からなる。
◆業務プロセス階層レベルの考え方
本書全体に流れる業務プロセス階層の基本概念を把握することに焦点を当てる。
◆IT 経営実現の全体プロセスの概説
三位一体の 3 つの視点の改革プロセスの機能を PGL の 5 つのフェーズに沿って要約する。

Ⅱ-2

業務プロセス階層レベルの考え方

業務改革の実現には業務プロセスの視点が重要である。しかし、従来はこの業務プロセス設計の手法が確立していないため、業務プロセス設計者の経験や考えに基づいて業務プロセス定義が行われてきた。特に、業務プ
ロセスの大きさを記述する（以下、業務粒度という）についての標準が無いために、本来は全体像を検討すべきところで無駄に詳細な定義が行われたり、詳細な定義が必要なところで必要な検討が行われなかったりすることがあった。
PGL では IT 経営実現プロセスを「経営戦略フェーズ」、「IT 戦略策定フェーズ」、「IT 資源調達フェーズ」、「IT 導入フェーズ」、「IT サービス活用フェーズ」の５つのフェーズで説明しているが、各フェーズで検討すべき業務プロ
セスの塊としての業務粒度は同じではない。経営者が戦略を判断する業務粒度と業務担当者が語る業務粒度で違いは自明と思われる。
業務粒度は業務プロセスを階層化することによって確定していくことが可能になる。そのために、業務プロセス階
層レベル（以下、「階層レベル」という）の定義を例示し、その考え方を解説する。
図表Ⅱ-2-1 業務プロセス階層レベルの概要
階層レベル
レベル 1

レベル 2

レベル 3
レベル 4
レベル 5

①

プロセス階層レベルの意味

業務プロセスの粒度の例

事業を推進するための事業機能または支援機能（経営機能とも言う）
事業機能・支援機能の実施方式を定義したもの（業務機能とも言う）
事業機能実施方式に含まれる
複数の業務プロセスの中の一つ
業務プロセスに含まれる複数の業務サブプロセスの中の一つ
業務サブプロセスに含まれる複数の業務処理の一つ事業から見て最上位の業務機能粒度をいう。
・事業機能：販売、生産、調達、物流など・支援機能：人事、経理、技術など
見込生産、受注設計生産等の実施方式によって規定された事業機能、支援機能
事業機能の「販売」を例にとれば、受注、在庫、仕入、出荷、請求などの業務プロセス機能
業務プロセス機能の「受注」を例にとれば、受注受付、在庫照会、在庫引当などの業務処理機能
業務処理の「受注受付」を例にとれば、注文、受領、取引条件チェック、注文データ登録等の業務処理の下位機能

階層レベル１：事業を構成する最上位の業務粒度である。

バリューチェーンでいう販売、生産、物流などの事業業務や人事、経理、技術等の本社機能ともいわれる支援機8第Ⅱ章

三位一体から見た IT 経営実現プロセス全体像能をいう。事業部内の製造本部、企画本部や営業本部といった組織はこの括りになっているところが多い。
②

階層レベル２：事業機能の実施方式を定義した業務粒度である。

受注設計生産や見込み商品といった商品特性によって業務機能は異なってくる。事業機能と実施方式の違いによる業務粒度であり、その業務機能が異なってくるためこの業務プロセス階層を設ける。
事業部内の組織で言えば、見込み生産型商品等の標準品を扱う営業1 部や受注設計生産型の商品を扱う営業2部等として区分された組織を形作っている。
③

階層レベル３：階層レベル２を構成する下位層の業務粒度である。

事業機能の「販売」を例にとれば、受注、在庫、発注、出荷、請求などの業務機能が該当する。事業内の組織に置き換えると、受注課、在庫管理課といった課のレベルの組織の括りはこの階層レベルになっていることが多い。
④

階層レベル４：階層レベル３を構成する下位層の業務粒度である。

レベル３における「受注」を例にとれば、受注受付、在庫照会、在庫引当などの機能が該当する。RFP における業
務プロセスの記述は、当階層レベルで提示する場合が多い。事業内の組織に置き換えると、係のレベルで取り扱う業務粒度で定義するのはこの階層レベルに設定する場合が多い。
⑤

階層レベル５：階層レベル４を構成する下位層の業務粒度である。

レベル４における「受注受付」を例にとれば、注文受領、取引条件チェックの業務処理の下位機能に該当し、実務担当者に必要な業務仕様となる。IT システムを設計するのに必要な業務プロセスの階層レベルでもある。
本書の IT 経営実現プロセスに対する三位一体のアプローチでは、業務プロセスの視点でこの業務プロセス階層
レベル1を PGL の 5 つのフェーズのプロセスを関係づけた。したがって、IT システムの視点、人・組織の視点のプロセス設計はこの業務プロセス階層レベルに連動した設計が必要になる。

Ⅱ-3 IT 経営実現プロセス全体図の概説
本項では、図表Ⅱ-3-1 での三位一体の改革プロセスに焦点を当てて各プロセスの概要と 3 つの視点の関係、
PGL を踏まえた全体観を概説する。 三位一体のアプローチの概説内容は、図表Ⅱ-3-1 の①～④に対応した以下の 4 点に分類して解説する。
①

経営戦略フェーズのアクティビティ群②

業務プロセスの視点に関するアクティビティ群③

IT システムの視点に関するアクティビティ群④

人・組織の視点に関するアクティビティ群

各プロセスの機能詳細はⅢ章以降の節で三位一体の 3 つの視点から詳述することになる。
図表Ⅱ-3-1 IT 経営実現プロセス全体像

1

階層レベル：各々の階層レベルについて、「レベル３」とか数字ではなく、もっと適切な呼称があるのではと感じるのは無理ないことである。この参考となる階層型の業務プロセス参照モデル（巻末の参考資料 B を参照）はグローバルには３種類がある。しかしながら、それらの階層レベルの呼称はバラバラである。そこで、本書では敢えて数字で呼ぶことにした。

9

三位一体から見た IT 経営実現プロセス全体像

第Ⅱ章

IT戦略策定フェーズ

経営戦略フェーズ

IT戦略策定フェーズ 2/
IT資源調達フェーズ

ITサービス
活用フェーズ

IT導入フェーズ

経営戦略
事業戦略
策定・更新

経
営
の
視
点

経営機能別戦略
策定・更新

経営戦略
評価
プロセス階層 レベル1
（事業機能）

事業戦略
評価

④
人
・
組
織
の
視
点

三
位
一
体
の
改
革
プ
ロ
セ
ス

業
務
プ
ロ
セ
ス
の
視
点
Ｉ
Ｔ
シ
ス
テ
ム
の
視
点

評価

人・組織の
グランドデザイン

①

人・組織
概要設計

人・組織の
パフォーマンス
評価

要員教育・
訓練実施

要員能力
開発計画策定②

プロセス階層
レベル3

業務システム構想策定

業務プロセス
グランドデザイン

プロセス階層 レベル2
（事業機能の実施方式）

プロセス階層レベル4

業務プロセス
概要設計③
ITシステム戦略企画

ITシステム計画・調達プロセス階層レベル5

業務プロセス
詳細設計

業
務
シ
ス
テ
ム
移
行

業務システム運用

業務プロセス評価

ITシステム
戦略評価

プロセス階層
レベル5以下ITシステム開発・導入

ITシステム運用・保守

ITシステム評価

１） 経営戦略フェーズのアクティビティ群
このアクティビティ群はビジネスモデルを具体化するものである。KGI/KPI と CSF (Critical Success Factor)の明確化も行う。
これらは、「経営戦略/事業戦略策定・更新」、「経営機能別戦略策定・更新」、「業務システム構想策定」の 3 つのアクティビティからなり、階層レベルが進むほど詳細に定義されていくことになる。
これらは三位一体として分化する前の業務プロセス改革に向けた構想策定のステップになる。
（１） 「経営戦略/事業戦略策定・更新」アクティビティ
外部環境要因に対して、競争優位に立つビジネスモデル（案）を策定していく活動である。
競争優位となる CSF（重要成功要因）を策定し事業分野を明確にする。
（２） 「経営機能別戦略策定・更新」アクティビティ
ビジネスモデル（案）に対する企業内の事業機能（プロセス階層レベル１）の CSF を品質、価格、納期、サービス等の事業機能の改革の視点から策定する。
（３） 「業務システム構想策定」アクティビティ
業務階層レベル２で定義した事業機能は、製造業を例にとれば、見込み生産や受注計画生産等のモノの流れの違いによる実施方式による区分である。
具体的には、「経営機能別戦略策定・更新」アクティビティでの事業機能の CSF に実施方式に関わる要件として組織、業務ルール、人、プロセス機能、IT システム等の「業務プロセス改革区分」を追加することになる。この構造を記述することで事業機能として実現可能な業務プロセス階層が出来上がる。この業務プロセスのレベルを階層
レベル２とした。この記述成果物が、新業務システムに向けた「業務プロセス改革構想書」ということになる。
以上のように、このフェーズ改革プロセスは三位一体の要素をすべて含んだ構想となる。PGL の観点でいえば、
経営戦略企画書の業務システム策定の部分を担うことになる。

10

第Ⅱ章

三位一体から見た IT 経営実現プロセス全体像

２） 業務プロセス2の視点に関するアクティビティ群
このアクティビティ群は、ビジネスモデルの KGI/KPI に対して機能要件を段階的に具体化していくことになる。「業務プロセスグランドデザイン」、「業務プロセス概要設計」、「業務プロセス詳細設計」の 3 段階の活動からなる。
このアクティビティ群は事業機能の構成する「販売」や「生産」プロセスといった業務プロセスの階層レベル２の事
業機能から、課レベルの業務機能（階層レベル３）、係レベルの業務機能（階層レベル４）、担当者レベルの業務機能（階層レベル５）へと業務機能の詳細化のアクティビティである。
(1) 「業務プロセスグランドデザイン」アクティビティ
経営フェーズの業務システム構想策定で策定された「業務システム構想書」をもとに、受注、在庫、調達等といったプロセス階層レベル３の業務機能へ展開し、業務システム全体のギャップ分析のもとに整合性のある「業務改革企画書」を策定することになる。
このアクティビティで追加されるのは、業務機能要件に加え、組織定義、入力/出力情報、業務ルール、管理指標等がある。
業務機能のプロセス階層レベル３は業務機能の中核になることから、この階層レベルの業務プロセス整合性をとっておくことで下位階層への展開が漏れのない精度の高い設計が可能となる。
PGL の観点でいえば、IT 戦略策定フェーズでの「3-4 目標ビジネスモデル策定」から、「3-5 IT 戦略策定」のベース資料となる。
(2) 「業務プロセス概要設計」アクティビティ
事業プロセスグランドデザインを受けて、業務処理機能レベルに定義したプロセス階層レベル４の業務機能へ展開する。ここでの定義は、業務プロセスレベルの定義にあるように、係レベルでの業務粒度となる。
この階層レベルの定義要件は、管理指標は除いて階層レベル３の定義と同様であるが、細分化された定義となる。
この階層レベルの定義によって初めてプロジェクト計画やプロジェクト予算の見積を精度良く算定することが可能となる。そのことから、より実現性のある「業務プロセス改革計画書」とした成果物に作り上げることができる。
PGL の観点でいえば、IT 資源調達フェーズの「2-2 IT 資源調達計画」の調達要件定義書に組み込むベース資料となる。
(3) 「業務プロセス詳細設計」アクティビティ
業務プロセス概要設計を受けて、担当者レベルの業務粒度であり、業務プロセスの階層レベル５と言われる。定義すべき要件はレベル4の定義項目と同様であり、業務処理の下位階層レベルの定義となる。一般的に、ユーザ
ーの業務プロセス定義としては最下位層の定義になる。IT システム構築においては、このレベルでの記述をベンダーとしては要求する。このアクティビティ後、「業務システム移行」アクティビティに統合される。
PGL の観点でいえば、IT 導入フェーズの「3-3 業務プロセスの詳細化と業務移行準備」の業務プロセス定義書のベース資料となる。
３） IT システムの視点のアクティビティ群
このアクティビティ群は、業務プロセスの視点の要求を受けて的確に反映することに尽きる。当プロセスの構成は「IT システム戦略企画」、「IT システム計画・調達」、「IT システム開発・導入」からなる。
(1)「IT システム戦略企画」アクティビティ

このアクティビティは、IT 戦略と IT 戦略展開方針を策定することにある。IT システムの戦略企画は業務プロセス機能に対する業務プロセスグランドデザイン（プロセス階層レベル３）のもとで業務機能の IT 化に向けた要求である
2

業務プロセスとは、業務プロセスは階層化している。各々の階層レベル業務プロセスの処理の順序を表した業務プロセスフローだ
けでなく、それに含まれる個々の業務プロセスの機能を以下のプロセス構成要素（後述）によって明確に定義する(もちろん、他の定義の方法もある)。プロセス機能、IT システム機能、インプットやアウトプット、業務ルール、担当責任組織等を定義する。

11

第Ⅱ章

三位一体から見た IT 経営実現プロセス全体像

IT ビジネス要求をトップダウン要求として受け取る。一方で、現状の IT 改革要求をボトムアップから IT への要求をユーザー要求として整理し、目標業務プロセスと目標 IT 環境のギャップ対策として IT 戦略を策定する。
その後、IT 戦略展開において後続のプロセスに対する業務プロセス改革方針を策定することになる。
PGL の観点でみると、IT 戦略策定フェーズの「3-4 目標ビジネスプロセスモデル設定」、「3-5 IT 戦略策定」、「3-6 IT 戦略展開」に該当する。
(2) 「IT システム計画・調達」アクティビティ
RFP として的確な要求をするための IT への要求事項を整理するのがこのステップである。業務プロセスレベル４で定義された業務処理プロセス階層から IT 化に向けた IT 要求を作る。IT 化に向けた業務機能要求に加え、処理性能、信頼性、セキュリティ等と言った非機能要求も対象となる。
PGL の観点でみると IT 資源調達フェーズの「3-2 IT 資源調達計画」の調達要件定義書作成のベース資料となる。
(3) 「IT システム開発・導入」アクティビティ
PGL の観点でいえば、IT 導入に向けて業務プロセスの詳細化を行う活動であり、業務プロセス階層レベル５である業務処理の下位層の要求を詳細レベルの IT 要求として、IT ベンダーとともに作成・定義していくことになる。この後、「業務システム移行」アクティビティに統合され、IT システム運用・保守の実践となる。
４） 人・組織の視点のアクティビティ群
このアクティビティ群は、業務プロセスの改革に沿って、人・組織改革を同期させることになる。アクティビティ群の構成は「人・組織グランドデザイン」、｢人・組織概要設計」、「要員教育、業務システム移行」の各アクティビティからなる。
(1) 「人・組織グランドデザイン」アクティビティ
人・組織に対する全体整合をもったデザインは、レベル 1 のビジネスモデルに向けた CSF、事業機能の実施方式の決定がグランドデザインの基礎情報となる。業務プロセスグランドデザインでの業務機能の改革を受けて組織機能の全体像を策定していくことになる。
(2) ｢人・組織概要設計」アクティビティ
人・組織グランドデザインを受けて、業務プロセス概要設計で定義したプロセス階層レベル 4 は組織のミッションと人への要求能力の規模とスキルレベルの開発計画を与えることになる。
(3) 「要員教育・訓練実施」アクティビティ
要員能力の開発計画を受けて、業務プロセスの詳細設計によりプロセス階層のレベル５の業務プロセス定義が策定されると、担当者別の作業機能が明確となり要員教育の的確な実施が可能になる。教育・訓練実施後、「業務システム移行」アクティビティに統合される。
以上の 4 つのアクティビティ群はその達成を評価するために達成すべき目標が KGI、KPI として設定されることになる。
構築した業務システムの評価は、、最終的には経営戦略、事業戦略、そして IT 戦略で設定した目標に対する三位一体アプローチの観点での評価になる。経営戦略フェーズ、IT 戦略フェーズに位置する三位一体の各視点のアクティビティにおける KGI 、KPI を IT サービス活用においてモニタリング＆コントロールの対象とすることにな
る。

12

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチ

第Ⅲ章 ＩＴ経営実現プロセスの階層化アプローチ

13

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチ

Ⅲ章を読むにあたって
１） 「業務プロセス」とは業務プロセスはインプットに価値を付加してアウトプットに変換する機能を果たす。業務プロセスは階層化している。各々の階層レベル業務プロセスの処理の順序を表した業務プロセスフローだけでなく、それに含まれる個々の業務プロセスの機能について、本書では以下のプロセス構成要素（詳細は後述）によって明確に定義する（Ⅲ-1 で詳述）。
①プロセス機能、IT システム機能②インプットやアウトプット③業務ルール④担当責任組織：組織自身は三位一体の考え方からすると、人・組織に含まれる。
２） 「IT システム」とはPGL にしたがって、本書では IT システムを以下のように定義する。
①IT 環境・IT 資源：ハードウェア、ソフトウェア、ネットワーク、設備、ソリューション（アプリケーション）
・データ
・IT サービスの開発体制や運用・提供体制(社内、社外)②IT サービス：IT 環境がその要素を組み合わせて、ユーザーが業務プロセスを実行する際に提供するサービス。
上記の内、開発体制や運用・提供体制は、三位一体の考え方からすると、人・組織に含まれる。
３） 「人・組織」とは人・組織について、以下の要素によって明確に定義する。これについてはⅢ-3 で説明する。
① 組織
大企業の伝統的な組織構造では、本部、部、課、係のように階層化しているが、最終的には組織を構成する個々の担当者にたどり着く。本書では、組織は以下のような構成要素によって定義する。
・ミッション・目的・権限と責任・組織機能（遂行すべき業務プロセス）
・業績評価指標 など② 人
組織が遂行する業務プロセスへその能力を提供してこれを実行するという存在。

14

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチ

Ⅲ-1 業務プロセスの視点
Ⅲ-1-1 目的1)

テーマ記述の要旨「業務プロセスの視点」においては、IT 経営実現プロセスの 5 つのフェーズにわたって、ビジネスモデルと業務プ
ロセスを階層的に定義する「階層化アプローチ」が必要になる。この理由は、ビジネスモデルの KGI/CSF/KPI が展開されて業務プロセスへの改革要求として明確になること、そしてこれを実現するための業務プロセスを段階的に階層的にもれなく定義できることである。本節では、IT 経営実現プロセスの複数のフェーズ間にまたがるこれ
らの実践ポイントおよびアクティビティを概説する。
2)

該当 PGL のフェーズ名とアクティビティ名

PGL には、ビジネスモデルと業務プロセスを定義するするためのアクティビティやタスクが、４つのフェーズにわたって存在している。
(1) ビジネスモデルの定義
経営戦略フェーズには、ビジネスモデルを定義するアクティビティが複数箇所に存在している。
①「経営環境分析とあるべき姿の構築」アクティビティ(PGLⅠ3-4)では、「ビジネスモデル(案)を策定」②「経営戦略策定」アクティビティ(PGLⅠ3-6)では、「ビジネスモデルの決定」③「経営戦略展開」アクティビティ(PGLⅠ3-7)では、「ビジネスモデルを各組織の部門戦略として展開」④「プロセス改革課題の明確化」タスク(PGLⅠ3-8-1)では、「部門におけるプロセス改革課題の明確化」(2) 業務プロセスの定義
IT 戦略策定フェーズ以降、業務プロセスを定義するアクティビティが複数箇所に存在している。
①IT 戦略策定フェーズの「現行業務プロセス分析」タスク(PGLⅡ3-2-1)では、「現行業務プロセスの可視化と分析」②IT 戦略策定フェーズの「目標業務プロセス策定」タスク(PGLⅡ3-4-1)では、「目標ビジネスプロセスモデルを策定」③同フェーズの「ギャップ分析」タスク(PGLⅡ3-5-1)では、「目標と現行業務プロセスとのギャップ分析」④同フェーズの「業務プロセス改革方針策定」タスク(PGLⅡ3-6-1)では、「業務プロセスのあり方を分析・計画」⑤IT 導入フェーズの「新業務プロセスの決定」タスク(PGLⅣ3-3-1)では、「新業務プロセスを詳細に設計」

Ⅲ-1-2 目的の達成のための実践ポイント
IT 経営実現プロセスの複数のフェーズ間にまたがって、階層的にビジネスモデルと業務プロセスを定義するためには、下記の実践ポイントに留意してアクティビティを実行しなければならない。
1) ビジネスモデルを階層的に定義するための実践ポイント
ビジネスモデルを階層的に定義するのは、その過程でビジネスモデルを検証しながら、最後は業務プロセスに反映させるためである。
(1) ビジネスモデルを正確に展開（構造化）する
15

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチ

経営戦略フェーズにおいてはビジネスモデルを定義、展開（構造化）し、部門の業務プロセス改革課題とする。この最終は、業務プロセスの定義へのインプットにならなければならない。このビジネスモデルの構造化を正確に行うためには、各アクティビティにおける階層レベルが明確に規定されている必要がある。さらに、この構造化（後述）が MECE (Mutually Exclusive and Colletively Exhaustive) (もれず重複せず)でなければ、ビジネスモデルが業
務プロセスと整合しないことになってしまう。
(2) ビジネスモデルを検証する
階層レベル１や階層レベル２の問題・課題ほど複雑であり、CSF や根本原因の特定がむずかしい。ビジネスモデ
ルの分析においては、問題と原因が隣接していない場合、あるいは全く別の第３因子が存在している場合がある。
また、ビジネスモデルの設計においては、それによる悪影響の発生を見逃しがちとなる。実際に、ある製造メーカにおいて、営業部門の問題解決策が製造部門へ悪影響し、製造部門の問題解決策が資材購買部門へ悪影響し、それが回りまわって営業部門の新たな問題となった「混乱のループ」の事例があった。
ピーター･M･センゲは、人間がこうした誤りを犯すのは、「解くべき問題の定義を惜しんで解答に飛びつく」や「急ぎたいという気持ちに負ける」によるスナップショット思考に陥るからであり、問題は複雑に関連し合っているので、システム思考をすべきだと言う3。
2) 業務プロセスを階層的に定義するための実践ポイント
業務プロセスは機能ベースで、階層レベル２で数十、階層レベル３で数百、階層レベル４で数千、階層レベル５では数万と膨大な数となる。業務プロセスを階層的に定義するのは、ビジネスモデルを反映させながら、重要な問題・課題に集中して、必要な業務プロセスだけを選別しながら定義するためである。
(1) プロセスオーナーを明確にする
プロセスオーナーとは、業務プロセスに対して改善への最終的責任を持つ人物を指す4。担当する範囲としては、
ビジネスユニットとしての複数の業務機能をまたぐ業務プロセス、または業務機能としての複数のビジネスユニット間で共通的な業務プロセスとがある。いずれにしても業務プロセスの設計のためには、プロセスオーナーを明確にして、各組織の責任者との調整のためのリーダシップが不可欠となる。
(2) ビジネスモデルと整合した業務プロセス改革を設計する
ビジネスモデルを展開したプロセス改革課題は、業務プロセスへの業務プロセス改革要求として設計されなければならない。これには、業務プロセス機能や業務ルールだけでなく、組織や人に対する改革要求や IT へのビジネス要求も含む。
(3) 人間系プロセスも対象とするIT を利用する IT 系プロセスに対して、IT を全くあるいは殆ど利用していない人間系プロセスは、業務プロセスの数の約 3/4 以上を占めるといわれている。業務プロセスにはこの両者が混在している。人間系プロセスには、企業に大きな影響を与える意思決定プロセスが含まれるので、その業務プロセス改革要求には非常に重要なものが存在している。
(4)

業務プロセスの階層レベルを規定する。

業務プロセスの階層レベルは地図でいうと縮尺のようなものである。したがって、業務プロセスを階層的に定義する際に各々の階層レベルを誤ると、上位の業務プロセス設計の結果を下位に正確に構造化できない、あるいは同一階層レベルと思ってもお互いにつながらないことになってしまう。団塊世代の大量退職という 2007 年問題に対応するため、そのノウハウを企業内に残そうとして、階層レベルやプロセス構成要素を規定せずに業務プロセ

3
4Ｐｅｔｅｒ M. Senge 「最強組織の法則」守部信之訳、徳間書店、1995
日本 BPM 協会 http://www.bpm-j.org/

16

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチ

スを大勢で記述分担した作業は全くの徒労に終わった。
(5) 業務プロセスを定義するプロセス構成要素を規定する。
業務プロセスフローは業務プロセスの順序関係を表現しただけで、業務プロセスの定義ではない。J-SOX 対応に必要な「３点セット」といわれるドキュメント化においてさえ、業務フロー以外に業務規程を含む業務記述書を必須としている。
業務プロセスを完全に定義するためには、個々の業務プロセスについてのプロセス機能、インプット、アウトプット、
業務ルール、担当組織などのプロセス構成要素を規定して記述する必要がある。IT システムに対しては、インプットやアウトプットはデータモデル定義につながり、プロセス機能や業務ルールはそのプログラムロジック仕様となる。
(6) 上位の業務プロセス設計の結果を MECE に構造化する。
現状の業務プロセスを適切な階層レベルで記述した後は、上位の業務プロセス設計の結果を展開すなわち構造化しなければならない。構造化は要素分解と詳細化という２つのステップを経る。この構造化を MECE に行えないと、どこかで上位の業務プロセス設計の結果の反映が途切れてしまう。すなわち、ビジネスモデルの業務プロセスへの反映は不完全なものとなってしまう。フラットな社会構造で生きている日本人にとって、構造化は割りと苦手な思考である。これが階層化アプローチを導入しにくくしている原因ともなっている。
(7) トップダウンアプローチとボトムアップアプローチを融合させる。
上位の業務プロセス設計の結果の構造化についての実現への CSF や障害となる課題だけでなく、現状の業務
プロセス自身に内在する課題も存在している。トップダウンアプローチにおいては、前者の課題がより重要となる。
また、ボトムアップアプローチにおいては、後者の課題だけを取り扱う。両者を融合させて両者の長所を引き出すために、各階層レベルにおいて両方の課題を解決することが重要である。トップダウンによるスピード指示とボトムアップによる提案を融合させるということは、特に日本企業にとって重要なポイントとなる。
(8) 業務プロセス参照モデルを利用して階層化アプローチを実現する。
階層的な業務プロセス参照モデル（参考資料 B）を利用すると、以下のことが実際に可能となる。
・業務プロセスについて、調達、生産、受注・出荷、これらへの共通支援など業務実行のヨコの機能だけでなく、
計画管理、戦略計画、戦略立案などタテの機能まで、業務の全般をカバーしている・IT に携わってきた多くの人にとって未知の人間系プロセスが定義されている
・業務プロセスの階層レベルやプロセス構成要素が具体的に提示されている・階層レベルに沿った階層化アプローチによって、ビジネスモデルや業務プロセスを定義できる・ビジネスモデル定義や業務プロセス定義の品質と生産性の両方を向上できる

Ⅲ-1-3

階層的なビジネスモデルと業務プロセスの定義のアクティビティ

本項では、前述した実践ポイントに基づいた階層的なビジネスモデル定義と業務プロセス定義のためのアクティ
ビティについて、ある階層的方法論（以下、方法論と省略、巻末の参考資料 A を参照）を例にして具体的に説明する。この方法論における「IT 経営実現プロセス全体像」のビジネスモデル定義と業務プロセス定義のアウトプッ
トを図表Ⅱ-3-1 に追記して、図表Ⅲ-1-3-１に示した。
図表Ⅲ-1-3-1 ビジネスモデルと業務プロセスの実現プロセス (図表Ⅱ-3-1 に加筆・修正)

17

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチ

経営戦略フェーズにおける縦の階層レベル２までの３つのアクティビティが、階層的な３つのサブモデルを定義する「ビジネスモデル定義」である。業務プロセスの視点の横の階層レベル２から５までの４つのアクティビティが、階層的な４つのサブモデルを定義する「業務プロセス定義」である。
1) ビジネスモデルと業務プロセスの各サブモデルの位置付け
図表Ⅲ-1-3-１のビジネスモデルの階層的定義には、「ビジネスモデル」、「業務システム改革モデル」、「業務プロセス改革モデル」という３つのサブモデルがある。業務プロセスの階層的定義では、「業務プロセス改革モデル（レベル２業務プロセス）」、「レベル３業務プロセス」、「レベル４業務プロセス｣、「レベル５業務プロセス」という４つのサブモデルがある。階層レベル２の業務プロセス改革モデルは、レベル２業務プロセスと同一のものである。したがって、ビジネスモデルと業務プロセスとが整合できる。
ビジネスモデルであっても業務プロセスであっても、階層レベルが下位のサブモデルは、上位のモデルの目的を実現するための手段となる。たとえば、在庫引当は、受注処理のための手段の一つである。したがって、業務
プロセス定義においては、上位の階層レベルのサブモデルの定義が終わった後、これを実現するための下位の階層レベルのサブモデルの定義を行うという階層的な順序関係がある。
さて、図表Ⅱ-2-1 において階層レベルを例示した。階層的なビジネスモデル定義や業務プロセス定義を実践するのには、対象となる広範な事業機能や支援機能について、レベル２以下を具体的に設定しなければならない。
これは、実務経験が豊富な者にとっても、大変にむずかしい。なぜならば、業務プロセスが同一の階層レベルというのは、インプットやアウトプットが相互につながっていることであり、業務プロセスの大きさが同程度に見えればよいのではないからである。そのために、方法論では階層型の業務プロセス参照モデル（巻末の参考資料Bを参照、第Ⅳ章に例示）を利用して、階層レベル２、階層レベル３、階層レベル４の業務プロセスを具体的に設定し
18

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチている。あるものは使うべきである。もちろん、業務プロセス参照モデルがカバーしていない経営機能や業務機
能は、自分で設定しなければならない。
2) 階層的なビジネスモデル定義のアクティビティ
ビジネスモデルとは、事業目標を達成するため、顧客に価値を与える製品・サービスを開発・提供する仕組みを表現したものである。ビジネスモデルには、ビジネスモデル、業務システム改革モデル、業務プロセス改革モデ
ルといった、階層レベルが異なる３階層のサブモデルがある。
ビジネスモデルを定義するためには、次の３つのアクティビティを実施する必要がある。
①経営戦略/事業戦略策定・更新：ビジネスモデルを策定・更新する②経営機能別戦略策定・更新：業務システム改革モデルを定義する③業務システム構想策定：業務プロセス改革モデルを定義する(1) 経営戦略/事業戦略策定・更新
この目的は、ビジネスモデルとしての経営戦略や事業戦略を策定あるいは更新することである。ビジネスモデル
は、顧客にどのような価値を提供して競争相手に勝つかの対外的なモデルであるので、事業分野ごとに異なることになる。ビジネスモデルにはマーケティング戦略のように複合的な戦略も含まれる。
(2) 経営機能別戦略策定・更新(Ⅳ-1-2 で詳述)
この目的は、ビジネスモデルを組織が持つ経営機能としてどのように実現するか、対内部のサブモデルである業
務システム改革モデルを定義することである。業務システム改革モデルは階層レベル１の経営機能（事業機能や支援機能）に位置し、業務システムを構成する各々の経営機能に対する改革要求、すなわち業務システム改革
要求から構成される。
(3) 業務システム構想策定(Ⅳ-1-3 で詳述)
この目的は、業務システム改革モデルを業務機能としてどう実現するか、対内部のさらに詳細なサブモデルである業務プロセス改革モデルを定義することである。業務プロセス改革モデルは階層レベル２の業務機能(事業機
能や支援機能の実施方式)に位置し、現状の各々の業務機能に対する改革要求すなわち業務プロセス改革要求から構成される。
「経営機能や業務機能への構造化」や「現在は存在していない経営機能や業務機能の設計」において、人々のナレッジである業務プロセス参照モデルを利用せず、ITC 個人のスキルや経験だけに依存してしまえば、アクテ
ィビティ実施の品質は危うくなる。
3) 階層的な業務プロセス定義のアクティビティ
業務プロセスには、レベル２業務プロセス(業務プロセス改革モデル)、レベル３業務プロセス、レベル４業務プロ
セス、レベル５業務プロセスといった、階層レベルが異なる４階層のサブモデルがある。業務プロセスを定義する
ためには、次の４つのアクティビティを実施する必要がある。この各々の詳細は後述する。
① 業務システム構想策定：レベル２業務プロセス（業務プロセス改革モデル）を定義する② 業務プロセスグランドデザイン：レベル３業務プロセスを定義する③ 業務プロセス概要設計：レベル４業務プロセスを定義する④ 業務プロセス詳細設計：レベル５業務プロセスを定義する

19

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチ

図表Ⅲ-1-3-2 に業務プロセスの各サブモデルの定義（モデリングともいう）の方法を示した。図表Ⅲ-1-3-2 の右端には図表Ⅲ-1-3-1 におけるアクティビティ名、および対応する PGL フェーズを記載した。このように、業務プロ
セスの４階層のサブモデルは、階層レベルにかかわらず以下の共通的な５つの手順によって定義する。
(1) 現状プロセスの調査・記述
この目的は、現状プロセスを正確に記述することであり、業務プロセスフローや個別の業務プロセス機能がアウトプットとなる。現状プロセスの調査・記述は、製造における前段取り作業のようなもので、これ自身は付加価値がある作業ではない。したがって、できるだけ効率的にかつ正確に調査・記述する必要がある。通常は、設計された
上位プロセスの下位の階層レベルに属する業務プロセスだけを調査・記述すればよい。また、調査・記述の抜け・もれは防止しなければならない。さらに、階層レベルが統一された業務プロセスを記述しなければならない。特に、複数人で調査・記述を分担すると、階層レベルがバラバラになりやすい。
この際に、業務プロセス参照モデルを利用すれば、返品やリベート計算など抜けやすい業務プロセスを含めて網羅的に業務プロセスを調査・記述できる。そして、階層レベルは自然に統一される。また、業務プロセス参照モデルに存在し、現状では欠落している業務プロセスも明確にしておく。なぜならば、｢欠落している｣ことが問題・課題の原因となっている場合があるからである。「見える化」といっても、現状に存在するものだけを記述しただけでは「欠落している｣ことは明らかにはならない。
さらに、業務プロセスのプロセス構成要素に関しても、正確かつ効率的に調査・記述できる(Ⅳ章で後述)。業務プ
ロセス参照モデルに記述されたプロセス機能、IT システム機能、インプット、アウトプットや業務ルールについて、こういうものがある筈だと仮説・質問して調査するのである。また、現状に関する不完全なドキュメントがあった場合には、これを業務プロセス参照モデルにマッピングして、不明な箇所だけを前述のように調査・記述すれば、これをさらに効率的に行える。

20

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチ

図表Ⅲ-1-3-2 業務プロセスの各サブモデルの定義の方法(2) 上位プロセス設計からの構造化
この目的は、上位の階層レベルの業務プロセス設計の結果を下位へと構造化することである。この思考にはかな
りの経験・スキルが必要となり、かつ間違えやすい。この際に、業務プロセス参照モデルを利用すれば、構造化における上位から下位への要素分解を MECE にできるだけでなく、詳細化も正確にできる(Ⅳ章で後述)。
(3) 現状プロセスの課題抽出
この目的は、調査・記述した現状プロセスから課題を抽出することである。まず、現状プロセスの調査・記述の際にすぐ、いくつかの現状プロセスの課題を抽出できる。そして、さらに課題を抽出するためには、検討のためのワ
ークショップを開催したり、階層レベルに対応した業務インタビューシートを利用したり、さまざまな技法を利用する。この際に、抽出した課題についてこれが位置する階層レベルを判別する。もし、より下位の階層レベルの業務プロセスに位置する、すなわち小さな課題である場合は、一旦、除外しておき、後で下位の階層レベルの業務プ
ロセスの課題として利用する。
(4) プロセス分析
この目的は、上記(2)の実現のための CSF (主要成功要因)、そして(3)の課題の根本原因、この２つを正確に完全に特定することである。これができなければ、次に行う設計が見当はずれとなってしまう。この際に、各種の技法を組み合わせて適用すれば、さらにプロセス分析の品質を向上できる。たとえば、レベル２業務プロセスのプロセス
分析の際に、抽出した課題の因果関係を図示すれば、根本原因を発見しやすい。

21

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチ(5) プロセス設計
この目的は、上記(3)で特定した CSF (主要成功要因)と課題の根本原因への解決策を設計することであり、アウト
プットは新しい業務プロセスフローや個別の業務プロセス機能となる。プロセス分析が正確に行われていれば、このプロセス設計はそれほどむずかしくはない。継続すべき現状プロセス機能を維持しつつ、プロセス分析の結果を受けた新しい業務プロセスを設計して検証すればよい。たとえば、レベル２業務プロセスのプロセス設計した結果の影響関係を図示すれば、悪影響の有無など検証がしやすくなる。
また、現状で欠落している業務プロセスについては、業務プロセス参照モデルの業務プロセスフローやプロセス構成要素を参考にすれば、新たな業務プロセスを設計できる。ここで、プロジェクト参加メンバーだけの知識・経験で設計しては、その品質は危うくなってしまう。
上記の共通的な手順において、(2)、(3)、(4)がいわゆる「分析」といわれるものである。また、(2)がトップダウンアプ
ローチ、(3)がボトムアップアプローチである。業務プロセスの分析において、この両方のアプローチを組み合わせて適用、すなわち融合させている。これによって、「分析」に内在する人の誤謬リスクへ対処するだけでなく、業務プロセス改革や業務プロセス定義への合意形成をはかることができる。
4) 業務プロセスの各サブモデルの定義のアクティビティ詳細
ここでは、業務プロセスの４階層のサブモデルの定義について、図表Ⅲ-1-3-2 に示した共通的な５つの手順に沿ってその概略を説明する。
(1) 業務システム構想策定 (Ⅳ-1-3 で詳述)
この目的は、階層レベル２に位置するレベル２業務プロセス（業務プロセス改革モデル）を定義することである。まず、階層レベル２で現状プロセスの調査・記述を行う。つぎに、上位プロセス設計の結果としての業務システム改
革要求を階層レベル２に構造化する。そして、業務プロセス診断チェックリストなどさまざまな技法を利用して、レベル２に位置する現状プロセスの課題を抽出する。最後に、業務システム改革要求からの構造化の実現のための CSF、および現状のレベル２業務プロセスの課題の根本原因を特定する。そして、この解決策を業務プロセス
改革要求(概要)として設計する。
業務プロセス改革要求(概要)を集約したものが業務プロセス改革モデルとなる。
(2) 業務プロセスグランドデザイン(Ⅳ-2-1 で詳述)
この目的は、階層レベル３に位置するレベル３業務プロセスを定義することである。まず、業務プロセス改革要求(概要)の範囲に限定して、階層レベル３で現状プロセスの調査・記述を行う。つぎに、上位プロセス設計の結果としての業務プロセス改革要求(概要)を階層レベル３に構造化する。そして、さまざまな技法を利用して階層レベル３に位置する現状プロセスの課題を抽出する。最後に、業務プロセス改革要求(概要)の実現のための CSF、および現状のレベル３業務プロセスの課題の根本原因を特定し、そして、この解決策を業務プロセス改革要求(詳細)として設計する。これには、業務プロセス機能だけでなく、組織、業務ルール、人、情報と IT システムに対する改革要求を含んでいる。
現状プロセスに業務プロセス改革要求(詳細)を反映したものが新たなレベル３業務プロセスとなる。レベル３業務
プロセスとしては、業務プロセスフローと業務プロセス改革要求(詳細)の一覧だけを作成する場合もある。
(3) 業務プロセス概要設計(Ⅳ-2-5 で詳述)
この目的は、階層レベル４に位置するレベル４業務プロセスを定義することである。まず、レベル３プロセス設計された範囲に限定して、階層レベル４で現状プロセスの調査・記述を行う。つぎに、上位設計の結果としての業務プ
22

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチ

ロセス改革要求(詳細)を階層レベル４に構造化する。そして、階層レベル４に位置する現状プロセスの課題を抽出する。最後に、業務プロセス改革要求(詳細)の実現のための CSF、および現状のレベル４業務プロセスの課題の根本原因を特定し、この解決のためのレベル４業務プロセスを設計する。
レベル４業務プロセスとしては、業務プロセスフロー、個別の業務プロセス詳細記述書、インプット・アウトプット説
明書、業務ルール説明書などを作成する。
(4) 業務プロセス詳細設計
この目的は、階層レベル５に位置するレベル５業務プロセスを定義することである。レベル５業務プロセスには、通常だけでなく代替や例外ケースも含むので、レベル４とは１桁多いくらいの数になる（通常、数万はある）。したがって、問題の大きいレベル４業務プロセスを選定して、この範囲のレベル５業務プロセスだけを新たに定義することが多い。
まず、この範囲に限定して、階層レベル５で現状プロセスの調査・記述を行う。そして、レベル４業務プロセスの場
合と同じように、新たなレベル５業務プロセスを設計する。レベル５業務プロセスとしては、レベル４業務プロセスのそれと同様なアウトプットを作成する。
5) 「業務プロセス定義の階層化アプローチ」まとめ
人々のナレッジである業務プロセス参照モデルを利用するだけでなく、人の能力に依存しないようにした技法を持つ方法論によって、階層化アプローチを具現化できる。
・階層レベルに沿った階層化アプローチを具体的に実施できる- ビジネスモデルを階層的に定義し、最後は業務プロセスに設計できる。
- 業務プロセスを階層レベルにしたがって構造化して設計できる。
- 階層レベルごとにトップダウンアプローチに対してボトムアップアプローチを融合できる。
・ビジネスモデル定義や業務プロセス定義の品質と生産性の両方を向上できる- 階層化アプローチでは問題・課題が存在する経営機能や業務機能の下位の業務プロセスだけを調査する。
問題・課題の存在しない業務プロセスは調査しないで済む。
- 業務プロセス参照モデルについて、調査・記述の際には事実の仮説、分析の際には原因の仮説として利用することで MECE な品質を担保できる。特に、業務実行だけでなく、業務ルール管理や業務パフォーマンス管理な
どの共通支援のための業務プロセスは見落とされがちである。
- 現状で欠落している業務プロセスの設計の際には、業務プロセス参照モデルを参考にすれば、新たな業務プ
ロセスフローや個別の業務プロセス機能（すなわちプロセス構成要素）を設計できる。

23

第Ⅲ章

Ⅲ-2

ＩＴ経営実現プロセスの階層化アプローチ

IT システムの視点

Ⅲ-2-1 目的1)

テーマ記述の要旨「IT システムの視点」においては、IT 経営実現プロセスの各フェーズにわたって、IT へのビジネス要求と IT へのユーザー要求を階層的に定義する「階層化アプローチ」が必要になる。この理由は、ビジネスモデルの KGI/CSF/KPI が展開されて IT へのビジネス要求として定義できること、そしてこの実現のための IT へのユーザー要
求を階層的にもれなく定義できることである。本節では、IT 経営実現プロセスの複数のフェーズ間にまたがるこれ
らの実践ポイントおよびアクティビティを概説する。
2)

該当 PGL のフェーズ名とアクティビティ名

PGL には、IT への要求を定義し、IT 導入を計画・実施するアクティビティやタスクが、４つのフェーズにわたって存在している。
(1) IT へのビジネス要求の定義
IT 戦略策定フェーズの「目標業務プロセス策定」タスク(PGL Ⅱ3-4-1)と「目標IT 環境策定」タスク(PGL Ⅱ3-4-2)
では、「IT 戦略として必要な IT サービスと IT 資源を決定する」、そして「IT 戦略策定」タスク(PGL Ⅱ3-5-2)では、「IT サービスと IT 環境の戦略を策定する」。これは、IT へのビジネス要求(後述)を定義して、IT 戦略企画を策定することに該当する。
(2) IT へのユーザー要求の定義
IT 戦略策定フェーズの「IT サービス方針策定」タスク(PGLⅡ3-6-2)では、「IT サービスの主要機能、および操作性や応答時間などを決定する」。そして、IT 資源調達フェーズの「調達要件の明確化」タスク(PGL Ⅲ3-3-2)では、「調達できる単位に整理し、調達要件を明確にする」。これは、IT へのユーザー要求(後述)を定義して、IT 導入計
画を立案することに該当する。
(3) IT ソリューションの選定
IT 資源調達フェーズの目的は、RFP を発行して、IT ソリューションと IT ベンダーを選定することである。これは、ITシステムを調達し IT システム導入計画を具体化することに該当する。
(4) IT へのユーザー要求の詳細化と IT ソリューションの導入
IT 導入フェーズの「外部仕様の決定」タスク(PGL Ⅳ3-3-2)では、「入出力画面や帳票、コード類など外部仕様を決定する」。これは、IT へのユーザー要求を詳細化して、IT システム導入実行計画を立案、そして IT システムを開発・導入することに該当する。

Ⅲ-2-2 目的の達成のための実践ポイント
IT 経営実現プロセスの複数のフェーズにまたがって、階層的に IT へのビジネス要求と IT へのユーザー要求を定義して、IT システムを構築・導入するためには、下記の実践上のポイントに留意してアクティビティを実行しなけ
ればならない。
(1) 業務プロセス改革を重視して IT へのビジネス要求を定義する
ITC が取り組むべきは、IT システムよりも先に業務プロセス改革である。ビジネスモデルを実現するための業務プ
ロセス改革要求には、業務プロセスに関係する人・組織に対する改革要求も含まれる。IT へのビジネス要求はこ
24

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチの一環に過ぎない。この IT へのビジネス要求を集約・反映したものが IT システム戦略である。
米国のCIOは、ITだけでなく業務プロセスに対して責任と権限を持つように変わってきている。業務プロセス改革を重視することで、戦略と IT 投資の整合性を確保し、IT 投資対効果を最大化できるからである。九州大学の篠崎彰彦教授は経済産業省 3,141 社の調査データから、「IT 投資効果が最大限に発揮されるのは、組織(含む業務プロセス)改革と人的対応(教育)の両方にしっかり取り組んだ場合」と分析している5。
(2) 人間系を含めた業務プロセスから IT へのユーザー要求を定義する
業務プロセスには、IT をほとんど利用しない人間系プロセス、および IT を利用する IT 系プロセスという 2 つの種類がある。人間系プロセスは全体の４分の３以上のプロセス数を占めて、IT 系プロセスへ大きな影響を与えている。たとえば、人間系プロセスが標準化されていないと IT 系プロセスに多くの属人的・例外的要求が寄せられる。
したがって、IT 系プロセスだけを取り上げて、IT への要求を定義しようというのは、業務プロセスを一連の連続した「流れ」としてではなく、飛び飛びの不連続の「点」ととらえることになってしまう。
したがって、業務プロセスの定義としては業務フローだけでは全く不十分である。業務フローだけを描いてユー
ザーに業務要件をヒアリングし、それから IT への機能要件を取りまとめようとしたが、6 カ月かかってもユーザー要求を定義できなかったというトラブル事例がある。業務プロセスのプロセス構成要素が IT への要求につながることに気付いていない。
(3) 自動化だけでなく情報化を実現する
IT への要求のうち、「自動化」は IT によって省力化して効率化しようという目的である。対象は、処理手順とアウト
プットが標準化された定型的な業務プロセスとなる。今まで、ITシステムは効率化のツールとして見なされることが多かった。一方、「情報化」はデータや情報の共有によって、業務プロセスの品質とスピードを向上させようという目的である。対象は、処理手順やアウトプットが標準化されていない非定型的な業務プロセスとなる。企業のボト
ルネックになっている、たとえば、販売活動や商品開発など重要かつ非定型的な業務プロセスは多いが、これに対する情報化への要求はあまり取り上げられてこなかった。そして、今まで自動化を追及してきた定型的な業務プロセスは海外へ移転する潮流がある。
(4) 要求工学 (Requirements Engineering)を利用する
BABOK®6（Business Analysis Body Of Knowlege）は IT へのビジネス要求を定義するための知識体系であるがプロセスや方法論ではない。IT へのユーザー要求を定義するプロセスとしては、要求工学の要求定義プラクティスがある。要求工学では、IT へのユーザー要求はヒアリングするものではなく、ユーザーに質問して、「要求を引き出す、要求を獲得する」というアプローチを取る。正確で完全な業務プロセスとプロセス構成要素の定義があれば、ヒアリングに頼らずユーザーに質問して、もれなく正確に完全にユーザー要求を定義できる（Ⅳ-2-6 で詳述）。
(5) IT への要求すべてに優先順位を付けて、要求スコープをコントロールする
経営面からの効果からみれば、すべての IT へのビジネス要求やユーザー要求が同じ重要性、すなわち優先順位である筈はない。たとえば、IT へのユーザー要求が、IT へのビジネス要求を実現するために貢献するのであ
れば、経営面からは優先順位が高くなる。逆に、こんなことができればという単なる願望や要望、現在ある機能だからという保険的要求、そして業務上それほど重要でない金メッキ要求、これらのユーザー要求の実現に IT 投資
しても無駄でしかない。ヒアリングに頼るとこうしたユーザー要求を拾い上げてしまう。
IT への要求に優先順位がついていれば、これを利用して要求スコープすなわち IT システムの開発スコープを適
切にコントロールできる。BABOK® が優先順位付けられていない要求は要求とみなしていないのは、極めて当然である。
5

篠崎彰彦『「経営改革」と「情報化の効果」に関する企業規模別実証分析』経営情報学会誌 Vol.16 No.3(2007)
IIBA「BABOK2.0」 http://www.theiiba.org/am/ ビジネスアナリシスのための知識体系。ここでいうビジネスアナリシスは、IT システ
ムだけでなく本書と同様に人・組織や業務プロセスを含む。
6

25

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチ(6) 階層化アプローチによって IT への要求を定義、実現するⅢ-1 で前述したように、業務プロセスは階層化アプローチで定義する。この業務プロセスから IT への要求を定義
すれば、IT への要求定義も階層化アプローチを実現できる。

Ⅲ-2-3 階層的な IT への要求定義のアクティビティ
本項では、実践ポイントに基づいた階層的な IT への要求の定義と IT システム導入のアクティビティについて、ある階層的方法論を例にして具体的に説明する（Ⅲ-1 と同様、巻末の参考資料 A を参照）。この方法論における「IT 経営実現プロセス全体像」の IT への要求と IT システムに関するアウトプットを図表Ⅱ-3-1 に追記して、図表
Ⅲ-2-3-１に示した。
1) 階層的な IT 要求の定義のアクティビティ
方法論では、以下の４つのアクティビティによって、業務プロセスの階層的定義に沿って、階層的に IT への要求を定義する。
(1) 業務システム構想策定 (Ⅳ-1-3 で詳述)
「業務システム構想策定」の目的は、IT システム戦略構想を策定することである。このため、業務プロセス改革モデルに含まれる業務プロセス改革要求(概要)をインプットにして、IT へのビジネス要求(概要)を定義する。そして、IT へのビジネス要求(概要)の実現について、構想、ロードマップ、費用・効果などを IT システム戦略構想書として取りまとめる。
(2) IT システム戦略企画「IT システム戦略企画」の目的は、IT システム戦略企画を策定することである。このため、「業務プロセスグランド
デザイン」からのレベル３業務プロセスに含まれる業務プロセス改革要求(詳細)をインプットにして、より具体的なIT へのビジネス要求(詳細)を定義し、戦略やビジネス全体への影響度から、IT へのビジネス要求の優先順位付
けを行う（Ⅳ-2-7 で詳述）。
この IT へのビジネス要求(詳細)の実現について、IT サービス戦略(Ⅳ-2-3 で詳述)および IT 環境戦略(Ⅳ-2-4
で詳述)を策定する。そして、プログラム計画、プロジェクト計画、費用・効果などを IT システム戦略企画書として取りまとめる。

26

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチ

図表Ⅲ-2-3-1 IT システムの実現プロセス (図表Ⅱ-3-1 に加筆・修正)(3) IT システム計画・調達「IT システム計画・調達」の目的は、IT ソリューションと IT ベンダーを選定して、IT 導入計画を策定することである。
このため、「業務プロセス概要設計」からのレベル４業務プロセスをインプットにして、概要レベルの IT へのユーザ
ー要求を定義する(Ⅳ-2-6 で詳述）。IT 調達のためには、階層レベル４の「粗すぎず、細かすぎず」という概要レベルの詳細度がふさわしい。
ここで、レベル４業務プロセスには、IT へのビジネス要求は既に反映済みである。したがって、IT へのビジネス要
求が構造化された IT へのユーザー要求、および IT へのビジネス要求と無関係な IT へのユーザー要求の２種類がある。この両者を合わせて IT 要求と呼ぶ。全ての概要レベルの IT 要求を優先順位付けする。この優先順位を利用して IT システムの開発スコープについて、IT ソリューション選定時や IT システム開発・導入時に適切にコン
トロールできる(Ⅳ-2-7 で詳述）。
概要レベルの IT 要求の実現を計画したものが、IT ソリューション選定前の IT システム導入計画書である。この IT
要求を RFP に記述して、適切な IT ソリューションと IT ベンダーを選定する。その後、IT ベンダーの提案と契約をもとに、より具体的な IT システム導入計画書に更新する。
(4) IT システム開発・導入「IT システム開発・導入」の目的は、IT システムを開発・導入することである。このため、「業務プロセス詳細設計」
からのレベル５業務プロセスをインプットにして、詳細レベルのユーザー要求を定義する。または、別の方法で概要レベルの IT 要求を詳細化する。いずれにしても、IT システム開発・導入のためには、｢ある程度、詳細な｣という詳細レベルでなければならない。この詳細レベルの IT 要求の実現を計画したものが、IT システム導入実行計画
27

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチ書である。そして、これに沿って IT システムを開発・導入する。
2) 階層的な IT 要求の定義における共通手順
図表Ⅲ-2-3-2にIT 要求の４階層のサブモデルの定義の方法を示した。階層レベル６は IT 要求モデルではなく、IT 要求をどう実現するかというソフトウェア要求仕様である。図表の右端には IT 要求モデルに対応する PGL フェーズを示してある。このように、IT 要求の各サブモデルは、階層レベルにかかわらず以下の共通的な４つの手順によって定義する。
図表Ⅲ-2-3-2 IT 要求の各サブモデルの定義の方法(1) 現状 IT システムの調査・記述
この目的は、情報システム部門や IT ベンダーにおいて遂行されている IT 環境や IT サービス提供に関連する業
務プロセスについて、IT 環境(IT 資源、データ、開発・運用体制)や IT サービスの現状を調査・記述することである。
この方法は、通常の業務プロセスの場合と同じである。
(2) 業務プロセスから IT 要求の抽出
階層レベルに対応して定義された業務プロセスから、以下のように IT 要求を抽出する。
①

IT へのビジネス要求の抽出(Ⅳ-1-3 とⅣ-2-3 で詳述)

IT へのビジネス要求(概要)の場合はレベル２業務プロセス(業務プロセス改革モデル)上の業務プロセス改革要求(概要）から、IT へのビジネス要求(詳細)の場合はレベル３業務プロセス上の業務プロセス改革要求(詳細）から、それぞれ「情報と IT システム」という業務プロセス改革区分の改革要求を IT へのビジネス要求として抽出する。
28

第Ⅲ章

②

ＩＴ経営実現プロセスの階層化アプローチ

IT へのユーザー要求の抽出(Ⅳ-2-6 で詳述)

階層レベル４または階層レベル５の業務プロセスのプロセス構成要素から IT へのユーザー要求を引き出す。ITへのビジネス要求(詳細)はプロセス構成要素の「プロセス機能(IT システム機能)」へと既に構造化済みである。したがって、IT へのビジネス要求はこれに対する「IT へのユーザー要求の抽出」によって詳細化できる。決して、ユーザー自身の利便性だけから IT へのユーザー要求だけを抽出する訳ではない。この際に、要求工学の要求定
義プラクティスに沿って、以下のように IT へのユーザー要求を抽出する。
a. IT へのユーザー要求の引き出し (Elicitation)
業務プロセスの各プロセス構成要素について、ユーザーに質問することによって「ユーザー要求の引き出し」を行う。概要レベルの場合はレベル４業務プロセスから、詳細レベルの場合はレベル５業務プロセスから、経験豊
富な要求アナリストでなくともユーザー要求を引き出せる。なお、業務プロセスのプロセス構成要素と IT へのユー
ザー要求との強い関係、IT へのユーザー要求の引き出し方法についてはⅣ-2-6 で後述する。
b. IT へのユーザー要求の分析引き出した IT へのユーザー要求を整理しながら、IT 要求定義書に転記する。
c. IT へのユーザー要求の仕様化
IT へのユーザー要求の発生源や発生理由を確認し、関連する業務ルールを特定して、IT 要求定義書へ追記する。特に、業務ルールはプログラムロジック仕様として IT へのユーザー要求の重要な発生源となるが、これは業務プロセスのプロセス構成要素として既に明確に定義されている。
d. IT へのユーザー要求の妥当性確認 (または要求検証)
ユーザーから IT へのユーザー要求に関する受入適合基準を確認して追記する。これはユーザーによる受入テ
ストにおける受入検収の基準となる重要なものである。
(3) 現状 IT システム課題の抽出
IT 資源としてのハードウェア・基盤系、アプリケーションソフトウェア、そしてデータおよび IT サービスの開発・運用体制、また IT サービスに関する課題が IT システム課題である。利用部門における業務プロセスから IT 資源に関する非機能要求を抽出できる。
しかし、調査・記述した IT 環境や IT サービス提供に関連する業務プロセス上で、IT システム課題を把握し記録している筈である。たとえば、性能とキャパシティ管理(DS3)プロセスからは IT 資源(ハードウェア)の処理性能、データ管理 (DS11)プロセスからは IT 資源(データ)のマスタの一貫性、サービスレベルの定義と管理(DS1)プロセスからは IT サービスレベル、などの現状 IT システム課題を抽出できる。もし、そうでなければ、それらの業務プロセスに問題があるので、利用部門における業務プロセスと同様に改善する必要がある。
(4) IT 要求の定義① IT へのビジネス要求の定義(2)で抽出されたITへのビジネス要求に、(3)のうち階層レベル２または階層レベル３に位置するITシステム課題を合算したものが IT へのビジネス要求となる。これには、業務プロセスの業務機能を支援する機能要求だけでなく、処理性能、信頼性、拡張性、セキュリティ、操作性などの非機能要求も含まれる。
② 概要レベルの IT 要求の定義(2)で抽出された IT へのユーザー要求に、(3)のうち階層レベル４に位置する IT システム課題を合算したものが概要レベルの IT 要求となる。

29

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチ

このように人間系を含めた業務プロセスのプロセス構成要素から IT へのユーザー要求を質問すれば、IT へのユーザー要求をもれなく引き出せる上、業務上それほど重要でない IT へのユーザー要求は出てこない。ある事例
では、開発期間と費用が約４割 縮小したことが報告されている。また、また他の事例でも IT 導入フェーズにおいて IT 要求の手戻りはほとんど発生していない。これは、開発されたシステム機能の 64%は、実は、全くあるいはまれにしか利用されていないという調査結果7があるので、しごく当然のことであろう。
3) 詳細レベルの IT 要求の定義の方法(1) 詳細レベルの IT 要求の定義「IT システム開発・導入」における、詳細レベルの IT 要求の定義に関しては、２つの方法がある。第一は、詳細設計されたレベル５業務プロセスのうちの IT 系プロセスから詳細レベルの IT へのユーザー要求を定義する方法である。この方法は、概要レベルの IT へのユーザー要求の場合と全く同じである。第二は、概要レベルのIT 要求を
詳細レベルの IT 要求へと構造化する方法である。
いずれにしても、詳細レベルの IT 要求では通常ケースだけでなく、代替ケースや例外ケースも検討しなければならない。その上で、V(View、画面)、M(Model、データ)、C(Control、ロジック)の観点から概要レベルの IT 要求を構造化する。
(2) ソフトウェア要求仕様の定義
詳細レベルの IT 要求は、選定した IT ソリューションによる IT システム分析へのインプットとなる。IT ベンダーが一番最初に行う IT システム分析は、その前半は IT 要求を確認するという「要求分析」、後半はその IT 要求から IT
ソリューションへの「ソフトウェア要求仕様 (よくシステム要件と呼ばれる)の定義」である。ユーザー企業の概要レ
ベルの IT 要求が不完全や不正確な場合、要求分析は IT 要求の定義に近い作業となる。したがって、IT ベンダ
ーにも IT 要求の定義のスキルや方法論は必要となる。これは IT ベンダーの自衛手段ともいえる。
4) 「IT システム構築の階層化アプローチ」のまとめ
図表Ⅲ-2-3-3 に IT へのビジネス要求がどのように定義されて、IT へのユーザー要求に反映するかを整理した。
図表Ⅲ-2-3-3 の右上のように、レベル２業務プロセスにおける情報と IT システムに関するプロセス改革要求(概要)が IT へのビジネス要求(概要)となる。レベル３業務プロセスを定義した際に、情報と IT システムに関するプロ
セス改革要求(詳細)が IT へのビジネス要求(詳細)となる。
この IT へのビジネス要求(詳細)について、図表Ⅲ-2-3-3 の右下のようにレベル４業務プロセスの「IT システム機
能」へと構造化する。次に、ユーザーに各々のについて質問して IT へのユーザー要求を引き出すので、IT へのビジネス要求(詳細)は、必ずユーザーによって詳細化される。そして、この概要レベルの IT 要求は次に階層レベル５の詳細レベルの IT 要求に構造化され、ソフトウェ
ア要求仕様に反映する。こうして、IT へのビジネス要求(詳細)は確実に IT システムに実装されることになる。
図表Ⅲ-2-3-3 IT へのビジネス要求の定義、構造化と実装

7

CHAOS Report (Standish Group International ,Inc)、2000

30

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチ

業務プロセス参照モデルを利用した階層化アプローチによってもれなく IT 要求を定義し、その優先順位付けを行うことは、IT システム構築の計画を段階的に詳細化し、費用の見積もりを超概算、概算、詳細、ベースラインと確定させていきながら、開発スコープを適切にコントロールすることを可能とする。

31

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチ

Ⅲ-3 人・組織の視点
Ⅲ-3-1 目的1)

テーマ記述の要旨「人・組織の視点」においては、IT 経営実現プロセスの 5 つのフェーズにわたって、人・組織を階層的に定義する「階層化アプローチ」が必要になる。この理由は、ビジネスモデルの KGI /CSF/KPI が展開されて人・組織への改革要求として明確になること、そしてこれを実現するための組織の機能や人の能力を段階的に階層的に定義して準備できることである。本節では、IT 経営実現プロセスの複数のフェーズ間にまたがるこれらの実践ポイントおよびアクティビティを概説する。
2) 該当 PGL のフェーズ名とアクティビティ名
PGL には、４つのフェーズにわたって、人・組織の定義を行うべきアクティビティやタスクが数カ所に存在している。
その各々と目的を下記にあげる。
(1) 経営戦略フェーズ「経営戦略展開」アクティビティ(PGL Ⅰ3-7)では、「ビジネスモデルを各組織の部門戦略として展開」、そして「プロセス改革課題の明確化」タスク(PGL Ⅰ3-8-1)では、「部門におけるプロセス改革課題の明確化」。これは、ビジネスモデルを人・組織に対する改革要求へ展開する「業務システム改革構想策定」に該当する。
(2) IT 戦略策定フェーズ（その１）「目標業務プロセス策定」タスク(PGL Ⅱ3-4-1)では、「目標ビジネスプロセスモデルを策定」。これは、「業務プロセスグランドデザイン」と同時に「人・組織グランドデザイン」することに該当する。
(3) IT 戦略策定フェーズ（その２）「業務プロセス改革方針策定」タスク(PGL Ⅱ3-6-1)では、「目標業務プロセスのあり方を分析・計画」。これは、「業務プロセス概要設計」と同時に、「人・組織概要設計」に該当する。
(4) IT 導入フェーズ「教育・訓練の実施」タスク(PGL Ⅳ3-6-3)では、「教育・訓練計画に基づき、教育・訓練を実施」。これは、「要員教育・訓練実施」によって人・組織を準備することに該当する。

Ⅲ-3-2 目的の達成のための実践ポイント
IT 経営実現プロセスの複数のフェーズ間にまたがって、階層的に人・組織を定義するためには、下記の実践ポイントに留意してアクティビティを実行しなければならない。
1)

人は企業の競争力として最重要なものと認識すること

企業の競争力として、人は極めて重要である。米国 NRC（全米科学アカデミー）が行なった 2020 年の製造業のあり方に関する調査報告書『Visionary Manufacturing Challenges for 2020』では、「画期的な製品といえども 4-5 年もあれば他社に模倣される。優れた生産手法や開発プロセスも、競合企業が本気になれば 7-8 年で追いつかれる。
最もキャッチアップがむずかしいのは『人的能力』である」とのべている。
2)
32

人・組織を業務プロセスや IT システムと整合させる

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチ

業務プロセスのプロセス構成要素として担当責任(組織・人)がある。いくら新しい業務プロセスを定義したとしても、それを遂行する組織の権限・責任と業績評価指標を決定し、人の能力をそれに対応できるようにしなければ、定義した意図どおりには運用できない。
たとえば、需給計画プロセスにおいて、需要に対して供給能力を超えて計画しないという業務ルールがあったとする。しかし、これを担当する組織の業績評価指標が出荷高であれば、この業務ルールは遵守されないであろう。
人や組織は自らが良く業績評価されるように、供給能力を超えた需要へもぎりぎりに対応しようとするからである。
この場合は、業務ルールと組織の定義が不整合となっている。
業務プロセス改革を含めた組織改革、そして人的対応(教育)にしっかり取り組んだ場合に、IT 投資効果が最大化することは、既にⅢ-2 において述べた。

Ⅲ-3-3 階層的な人・組織の定義のアクティビティ
本項では、実践ポイントに基づいた階層的な人・組織の定義のアクティビティについて、ある階層的方法論を例にして具体的に説明する（Ⅲ-1 と同様、巻末の参考資料 A を参照）。この方法論における「IT 経営実現プロセス
全体像」の人・組織の定義に関するアウトプットを図表Ⅱ-3-1 に追記して、図表Ⅲ-3-3-１に示した。
1)

組織(1) 組織とはそもそも組織とは、一定の目的をはたすために編成された、人と他の経営リソースの特定の集合体のことである。
組織は大きく２つの部分に分けられる。一つはハードな構造としての組織であり、組織図などによって公式的に示すことができる。他方はソフトな構造としての組織であり、目に見えないため公式的に示せないが、人の行動を大きく増幅または抑制する。組織文化や組織風土といわれるものである。
(2) 組織は階層構造を持つ
H. A. Simonは、業務プロセスや組織などの「人工物は複雑であるがゆえ階層構造を持つ」とのべている8。図表Ⅱ-2-1 の階層レベルについて、以下に、改めて大企業の伝統的な組織の階層構造の例を示す。
①レベル１ 営業機能本部のように複数の部をたばねたもの。
②レベル２ 営業１部や営業管理部のように機能本部を構成する部。
③レベル３ 営業１課のように部を構成する課。
④レベル４ 営業１課受注係のように課を構成する係。
⑤レベル５ 営業１課受注係を構成する個々の担当者。
通常、事業部は営業や生産など複数の事業機能を持つため、レベル１の上位に位置すると考えられる。ハードな
組織は、こうした階層構造に沿って段階的に階層的に定義していくことになる。
図表Ⅲ-3-3-1 人・組織の実現プロセス (図表Ⅱ-3-1 に加筆・修正)

8

H. A. Simon 「システムの科学 第３版」パーソナルメディア、1999

33

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチ(3) 組織のメタモデル
ハードな構造としての組織を構成する要素の例を以下に示す。組織をこれらの構成要素すなわちメタモデルによって抽象化して記述したものを組織モデルという。
① 組織のミッション・目的
組織が達成すべき独自のミッションや目的を定義したもの。
② 権限・責任組織が組織機能として果たすべき責任、およびそのための権限を定義したもの。
③ 組織機能組織機能として組織が遂行すべき業務機能、すなわち業務プロセスの体系を定義したもの。
さらに、これを遂行するためのかたまりとしての職務（後述）を定義して、要員を割り当てる。
④ 業績評価指標
組織の予算管理や業績評価などのための指標を定義したもの。これには、組織のミッション・目的と要員の目標とを整合させるための個人の評価制度(目標管理制度など)も含んでいる。前述の需給計画プロセスの例では、組織の業績評価指標と個人の評価制度が不整合となっている。
⑤ 組織形態と構造
階層的な組織図で示される組織形態と構造を定義したもの。組織形態には以下のような代表的ものがある。
・ライン型/スタッフ型組織：特定の組織機能、すなわち業務プロセスを遂行するための組織。スタッフ型組織はその専門性からライン型組織を支援する。
・プロジェクト型組織：特定の目的を持つ期限を区切られた組織。
・マトリクス型組織：よくグローバル企業に見られる組織形態であり、ライン型/スタッフ型の組織機能に対して、製品・販売地域・顧客など特定の組織横断的な目的からのコントロールも行えるようにした多元的な組織。市場環境
34

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチの変化へ迅速な適応を行うことが目的。
⑥ 組織マネジメント
組織のマネジメント方針、構成員をミッションや目的へ動機付けるためのリーダシップスタイルを定義したもの。
ジェイ R.ガルブレイスは組織設計のための枠組みとして、スター型モデルとして、戦略、組織構造、業務プロセ
ス、リウォード(褒賞)、人材の５つを提唱している9。上記の組織のメタモデルのうち、①②⑤⑥は組織構造に、③は業務プロセスと必要な人材の確保に、④はリォードにそれぞれ該当する。
2) 人
人とは業務プロセスへ能力を提供してこれを実行するという、組織を構成する最も重要な要素である。組織と同様に、人も大きく２つの部分に分けられる。一つは能力やスキルをはじめとするハードな要素として公式的に定義できる人である。他方はソフトな要素としての人である。人が他の経営リソースと異なるのはそれが自らの意思を持つことである。たとえば、人が自らの能力を積極的に発揮しようというためには、「動機付け」によってこの意欲を向上させる必要がある。リウォードはこのための手段の一つである。
3) 人・組織の階層的定義のアクティビティ
人・組織は、図表Ⅲ-3-3-1 のように、業務システム構想策定、人・組織グランドデザイン、人・組織概要設計、要員
教育・訓練実施というアクティビティをへて、階層的に改革、設計、準備していく。
(1) 「人・組織」改革構想策定「業務システム構想策定」の目的は、本部や部といった構想レベルの組織モデルを定義することである。このため、事業部や機能本部など組織の改廃や新設などの業務システム改革要求や業務プロセス改革要求(概要)から、人・組織の改革への構想を策定し、この実現のための組織改革構想書を作成する（Ⅳ-1-3 で後述）。
①組織改革
ハードな組織の改革では、アウトソーシングや機能分社化によって、現在の組織の機能を外に出すことがある。また、逆に、M&A やインソーシングによって、現在の組織の内に取り込むことがある。いずれにしても、組織改革の構想を策定しなければならない。また、ソフトな組織の改革としては、風土改革や意識改革は重要ではあるが、業務システム改革を中心においた本書では省略する。
②人の改革
また、ソフトな人の改革としては、長期的人材育成や人事制度改革も重要ではあるが、やはり業務システム改革を中心においた本書では省略する。
(2) 「人・組織」グランドデザイン（Ⅳ-2-2 で詳述）
「人・組織グランドデザイン」の目的は、組織改革構想書に基づいて、部の詳細や課といった概要レベルの組織モデルを定義することである。そして、これを実現するための組織改革企画書を作成する(Ⅳ-2-2 で詳述)。これにはチェンジマネジメント(後述)も含まれる。
① 「人・組織グランドデザイン」へのインプット・業務システム改革モデルや業務プロセス改革モデルから部や課などの組織の改廃や新設という組織への改革要求がある。
・レベル３業務プロセスの業務プロセス改革要求(詳細)から
業務プロセスのグランドデザインにおいては、組織や人という業務プロセス改革区分における業務プロセス改革
9

Jay R. Galbraith 「組織設計のマネジメント」生産性出版、2002

35

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチ

要求(詳細)が定義されている。これには、たとえば、現在、「調達センター」が存在しているが、購買発注した資材への納期管理に責任を負っていないという組織への改革要求がある。
③

組織のグランドデザイン「組織」に関する改革要求をもとにして、概要レベルの組織モデルに反映する。このため、組織のミッション・目的、
権限・責任、組織機能、業績評価指標などを検討して組織をグランドデザインする。ここで重要なのは、権限と責任、組織機能としての業務プロセスと業績評価指標との整合である。業績評価指標は、組織機能に含まれるレベル３業務プロセスに対応する業務プロセス参照モデルから、そのパフォーマンス評価指標を参考にして設定できる。
④ 人のグランドデザイン「人」の能力に関する要求を組織モデルごとにグランドデザインする。たとえば、機能分社化する場合には、旧組織の人が持っていた他の組織機能との調整能力が低下しないように設計しなければならない。
④ 組織改革企画書におけるリスクマネジメント計画
組織改革企画書では、「人は企業の競争力として最重要なものと認識すること」を実践するための「人」のリスクマ
ネジメント計画を立案しなければならない。米国の 9.11 テロ事件では、コンピュータやデータのバックアップをしていたが、人を失ったため廃業に追い込まれた企業がいくつもあった。それ以来、同じ仕事をする人を二つのビルに分散させるとか、より一層、在宅勤務が進展したという。
(3) 「人・組織」概要設計（Ⅳ-2-8 で詳述）
「人・組織概要設計」の目的は、部や課における係といった詳細レベルの組織モデルを定義し、それに必要な人の能力の開発を計画することである。このため、概要設計されたレベル４業務プロセスをもとに、グランドデザインされた組織モデルを詳細レベルへと概要設計する。そして、対象範囲について組織改革企画書からより詳細な
組織改革計画書を作成する。
① 組織モデルの組織機能
レベル４業務プロセスのプロセス構成要素に担当責任(組織・人)がある。レベル４業務プロセスへと業務プロセス
概要設計することによって、グランドデザインされた組織モデルの組織機能を概要設計できる。
② 職務記述書
職務分析では、組織機能としての業務機能について、図表Ⅲ-3-3-2 のように、部門、職務、仕事、作業と分類する。
この中で、職務とは業務機能を同一の種類でくくった区分であり、組織でいうと課の中の係がこれに相当する。職務は階層レベルでいうと、ほぼレベル４に位置する。そして仕事や作業は、各々、レベル５やレベル６に位置付けられる。
図表Ⅲ-3-3-2 職務分析における職務他の定義

36

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチ

職務の内容、条件、能力要件から職務記述書(ジョブディスク
リプション）を作成する。米国では職務記述書は雇用契約において使用する。日本においても、個人の職務が不明確ならば成果主義の導入はできない。
個人が担当するレベル４業務
プロセスが明確に定義されていれば、これから職務記述書を作成できる。
③人の概要設計
職務記述書は組織が業務プロセスを遂行するのに必要な能力を明確にしたものである。そして、職務と現在の要員が保有している能力とのギャップを埋めるために、要員能力開発計画を立案する。
a. 人の能力とはハードな要素としての「人の能力」は、以下のような項目によって定義できる。
・対象ドメイン
遂行する業務プロセスだけではなく、取り扱う原材料や商品そして設備や資金などの担当する経営リソース、これとの組み合わせが対象ドメインとなる。
・能力人が対象ドメインへ提供して、定められた結果を出すための能力であり、経験、適性、訓練の３つから構成される。
経験とは実務に従事した経験によって得られた知識や技能、適性とは性格や性質の対象ドメインへの適性、訓練とは、対象ドメインについて教育し、継続的練習させ、習得させることである。
・能力レベル
対象ドメインについてどの位の高い能力が必要かを複数のレベルで評価したもの。
b. 要員能力開発計画の立案
まず、現在の要員の各々が保有している能力を評価する。そして、職務記述書で明確にされた職務に必要な能力とのギャップを明確にする。このギャップが小さければ、その能力の向上のための要員能力開発計画を立案する。ギャップが大きい場合は、他部門からの配転、または新規採用によって補充、またはアウトソースすることにな
る。最後に、これらを組織改革計画書に追記し、人の能力を開発できるように、その教育・訓練を計画する(Ⅳ-2-8
で詳述)。
(4)「人・組織」移行
組織改革計画書を組織改革実行計画書に具体化する。これに基づいて、まず詳細レベルの組織モデルと職務記述書を完成させる。そして、要員能力開発計画で定めた職務能力や技術・技能を具体化した要員教育・訓練実行計画を立案してこれを実施する。
4) チェンジマネジメント
改革には抵抗がつきものである。そのために、チェンジマネジメントを計画して実行しなければならない。以下、

37

第Ⅲ章

ＩＴ経営実現プロセスの階層化アプローチ

チェンジマネジメントを成功させるため 15 の原則を紹介する10。
①現実を直視せよ②戦略的重点分野に絞れ③確固たる指令を出せ④変革の範囲はよく考えて設定せよ⑤変革のための論拠を強固に打ち立てよ⑥顧客を変革にまきこめ⑦関係者を知ること⑧絶えず意思疎通をはかれ⑨評価指標をみなおせ⑩「変革のテコ」となるものはすべて使え⑪大きく発想せよ⑫多様性をバネにせよ⑬スキルを育てよ⑭計画を立てよ⑮変革のためのイニシアチブを一つにまとめよ
特に、⑦、⑧は、適切なタイミングで、適切なステイクホルダーにメッセージを伝えるコミュニケーションの重要性を示している。
5) 「人・組織の構築の階層化アプローチ」のまとめ
業務プロセス参照モデルを利用した階層化アプローチによって、ビジネスモデルや業務プロセスを定義することによって、人・組織への要求を明確にしてこれを階層的に定義できる。
・「人・組織」改革構想策定では、本部や部といった構想レベルの組織モデルを定義し、組織改革構想書を立案する。
・「人・組織」グランドデザインでは、部の詳細や課といった概要レベルの組織モデルを定義し、必要な人の能力への要求を明確にして、組織改革企画書を立案する。
・「人・組織」概要設計では、係といった詳細レベルの組織モデルを定義し、それが担当するレベル４業務プロセスの業務機能から職務記述書を作成し、要員能力開発計画を立案する。
・「人・組織」移行では、詳細レベルの組織モデルと職務記述書を完成させ、要員能力開発計画を具体化して実
施する。

10

IT コーディネータテキスト「中堅・中小の経営改革」日本経済新聞社、2002

38

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

第Ⅳ章 IT 経営実現プロセスの階層化アプローチの事例

39

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

第Ⅲ章では、IT 経営実現プロセスの全体として、業務システム、すなわち業務プロセス、人・組織、そして IT シス
テム、各々の視点について、段階的に定義・実現していく階層化アプローチの考え方、そして階層レベルに関わらない共通的な手順について説明した。この第Ⅳ章では、IT 経営実現プロセスの各々のアクティビテｨについて、事例を中心にその成果物作成の実施手順を詳細に説明する。第Ⅳ章は、まず必要とする節（すなわち事例）だ
けを読んで頂くことを想定しており、階層的アプローチの考え方の重要な部分は繰り返し説明を加えている。

経営戦略フェーズでは、
IT 経営実現プロセスの２つのアクティビティについて、事例を中心にその実
施手順を説明する。
なお、経営戦略/事業戦
略策定・更新アクティビテ
ィは、守秘義務の関係から事例として記述することはできなかった。

40

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

IT 戦略策定フェーズ
では、IT 経営実現プ
ロセスの９つのアクテ
ィビティについて、事例を中心にその実施手順を説明する。

なお、本章の階層化アプローチの事例においては、プロセス
階層レベルの規定だ
けでなく、現状の業務プロセスの調査・記述、上位プロセス設計からの構造化、現状プロセスの課題抽出、そしてプロセス分析とプロセス設計において、業務プロセス参照モデル (参考資料 B)を利用して、これらの作業の生産性と品質の両方を向上させている。もちろん、業務プロセス参照モデルが存在しない事業機能や業務機能においては、自らこれを考え出さなければならない。

41

第Ⅳ章

Ⅳ-1
Ⅳ-1-1

IT 経営実現プロセスの階層化アプローチの事例

経営戦略フェーズの事例
事例企業とプロジェクト概要

１） 事例企業の概要
本章において紹介する、事例 A は単一の中小企業であり、事例Ｂは複数の大企業である。A 社からは、本書で紹介した内容については公表の承認を得ている。事例Ｂは、守秘義務の関係から抽象化した一部の資料だけを紹介した。
事例 A の企業概要：同社ホームページからの会社紹介
当社は 1962 年に創業以来、ステンレス板金加工、特殊油圧機器製造を事業の柱として、お客様から必要とされる製品を作り、ご提供することに専心してまいりました。
イーグル印油圧爪つきジャッキは、重量機械の据付に便利な道具が作れないかというお客様の要望に基づき、1975 年、当社がはじめて実用化に成功し、以来、専門メーカとして全国のさまざまな重量 物運搬のユーザー様にご支持を頂いております。
現場で必要とされるものには、大量生産されることのない、ひとつ一つ異なるニーズがございます。当社ではこうした個別のご要望に応えるべく、多品種小ロット生産体制を整えるとともに、豊富な経験を活かしたご提案ができるプロフェッショナル集団を目指します。
同社は「爪つき油圧ジャッキ」のトップメーカ。精密機械の運搬据え付け、プラントメンテナンス、鉄道保線、防災機材など幅広い分野で使われている。
２）プロジェクトの概要(1)プロジェクトの目的
A 社の主力製品には、標準品および特別仕様や他の機器と組み合わせた特注品、すなわち ETO 品（Engineer toOrder、受注設計生産）とがある。今回のプロジェクトの目的は、サプライチェーンにおける ETO 品に関する販売
活動、商品開発、製品設計、生産準備から出荷までの業務プロセスを確立・改善することである。
(2)プロジェクト体制と期間
A 社側は、社長、および販売、設計、生産、管理を担当する４人のマネジャーである。コンサル側は、方法論(参考資料 A)の適用経験を希望した 13 人である（半数は ITC、期間中オーシャンズ 13 と自称していた）。２週間に一度の打ち合わせ日を設定して、約半年間、合計 13 回の訪問によって、PGL でいう「経営戦略」と「IT 戦略策定」フ
ェーズを完了した。各打ち合わせ日の進め方は、AM は当日に実施するアクティビティに関して、方法論の開発者からコンサルへ説明し、PM は予め決められたコンサルが交代で事例 A 社との打ち合わせをリードし、ファシリ
テーションした。
(3)プロジェクトスケジュールと進捗
図表Ⅳ-1-1-1 に、合計 13 回の訪問日において実施した IT 経営実現プロセスのアクティビティ、および作成した成果物名を示した。第３日目は、抽出した業務課題について A 社内での共有にすべて費やした。一部の成果物は担当コンサルタントが持ち帰って作成したが、毎回 AM はコンサルへの説明なので、13 回の訪問日での作業で完了したと言ってよいであろう。
42

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

図表Ⅳ-1-1-1 プロジェクトスケジュールと進捗

なお、その後、A 社は IT 導入フェーズとして、販売活動、商品開発、製品設計という非定型的な業務プロセスにおいて、ETO 品の案件単位の顧客要求の把握と社内伝達、受注前と受注後の製品設計を含めた進捗管理と情報共有、必要な業務ルールの物理設計・実装、これらを導入済みの安価な汎用的な情報共有ツールを利用して
構築した。

43

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

Ⅳ-1-2 経営機能別戦略策定・更新
1） アクティビティの目的「経営機能別戦略策定・更新」においては、策定した新ビジネスモデル(案)から、業務システムの階層レベル１上でこれを実現するための経営機能別戦略、すなわち業務システム改革要求に構造化し、これに現状を含めた業
務システム改革モデルを定義する。
2） アクティビティの実践ポイント(1)目的達成のための実践ポイント
当該アクティビティの目的を達成するためには、Ⅲ-1 で前述したように、下記の実践ポイントを具体的に実現しなければならない。
①業務システム改革モデルの記述における階層レベルを適切に規定する②業務システム改革モデルの記述の際の要素、すなわちメタモデルを適切に規定する③ビジネスモデル(案)から業務システム改革要求を MECE に構造化する
インプットとなるビジネスモデル(案)は、自然言語で書かざるを得ないとしても、最低、以下のことを満たしていな
ければならない。
・競争業者、顧客、サプライヤなど競争環境上で重要なステイクホルダーを含めて検討したもの
・強み・弱みは、重要な競争業者を特定してそれと比較したもの
・５Ｗ２Ｈ位の形式検証が終わったもの(2)「経営機能別戦略策定・更新」の実施手順
実施手順１：ビジネスモデル(案)の階層的整理
実施手順２：経営機能別戦略への構造化
実施手順３：業務システム改革要求の定義
3） 「経営機能別戦略策定・更新」の実施手順の詳細と事例「経営機能別戦略策定・更新」の実施手順について、事例を交えてその詳細を説明する。
(1)実施手順１：ビジネスモデル(案)の階層的整理
Ⅲ-1 で前述したように、戦略自体は複合的な戦略もあり、必ずしも同列ではない。図表Ⅳ-1-2-1 に戦略の種類と記述技法の例を示した。もちろん、これは全ての戦略を網羅することを目的としたものではない。
①全社戦略(経営戦略)
事業分野ごとのポートフォリオ配分、事業分野ごとに共通の戦略などを定めたものが全社戦略(経営戦略)である。
たとえば、PPM[BCG]のような事業ポートフォリオ戦略がある。
②事業戦略
ビジネスモデル、すなわち事業戦略は、事業分野ごとの競争戦略として、顧客にどのような価値を提供して他社との競争に勝つかを策定する。事業戦略は複合的な戦略となる。たとえば、図表Ⅳ-1-2-1 の中のマーケティン
グ戦略は、マーケティングの 4P として、同じく図表Ⅳ-1-2-1 の中の製品戦略、そして価格戦略、流通チャネル・物流戦略（SCM (Supply Chain Management) 戦略）、プロモーション(コミュニケーション)戦略を含むものである。
図表Ⅳ-1-2-1 戦略の種類と記述技法例
44

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例(2)実施手順２：経営機能別戦略への構造化
経営機能は調達、製造、受注・出荷など、業務システムの階層レベル１に位置する事業機能やそれへの支援機能に該当する。事業戦略をどう実現するか、これを複数の経営機能に構造化したものが経営機能別戦略である。

45

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

図表Ⅳ-1-2-2 事業戦略と経営機能別戦略

このためには、図表Ⅳ-1-2-2 のように、事業戦略から経営機能ごとに CSF(Critcal Success Factor;主要成功要因)を抽出する必要がある。事業戦略からの CSF(戦略課題ともいう)を経営機能ごとに集約したものが経営機能別戦略となる。
各々の企業は、それぞれ異なる経営機能を持っており、これが自らの業務システムを構成する。たとえば、工場を持たないファブレス企業の業務システムでは、製造という経営機能を持っておらず、EMS などの外部企業へと生産委託する。経営機能としては、階層的な業務プロセス参照モデルを利用して、その階層レベル１の事業機能や支援機能を参照すればよい。そうすれば、ビジネスモデル(案)を MECE に経営機能に構造化できる。
【事例 A】「受注設計生産(ETO)品の拡販」という事業戦略は、経営機能（事業機能や支援機能）に以下のように構造化できる（一部だけ表示）。
①販売
・ETO 品の販売業務プロセスの確立によるベテランの経験の形式知化②商品開発と製品設計
・ETO 品の開発業務プロセスの確立による開発・設計リードタイムの短縮
・製品以外の付帯サービスの強化③製造
・標準品（見込生産品）と ETO 品の混在生産によるコスト削減
・ETO 品の生産業務プロセスの見直しによる製造コスト管理(3)実施手順３：業務システム改革要求の定義
経営機能ごとに適切な CSF を抽出するためには、下記の観点がある。あくまで経営機能として、既存の組織にとらわれずに機能中心で検討することが重要である。
・機能・品質面からの CSF
・コスト面からの CSF
46

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

・時間・量面からの CSF
・サービス面からの CSF【事例 A】
前述の販売、商品開発、製造というの３つの経営機能において、機能・品質面、コスト面、時間・量の面、サービス面という 4 つの観点から検討して、以下の CSF（主要成功要因）を抽出した。
①販売活動という経営機能において、時間・量面から「ＥＴＯ品の販売業務プロセスの確立」②商品開発と製品設計という経営機能において、時間・量面から「開発プロセスの見直しによる開発・設計リードタ
イムの短縮」、サービス面から「製品以外の付帯サービスの強化」③製造という経営機能において、コスト面から「標準品とＥＴＯ品の混在生産によるコストの削減」
経営機能別にＣＳＦを集約したものが経営機能別戦略であり。これは業務システムへの改革要求、すなわち業務
システム改革要求となる。これを現状に反映したものが業務システム改革モデルとなり、ビジネスモデルの階層レ
ベル１に位置するサブモデルである。ただし、現状の経営機能に対する変更点だけを記述することが多い。
[補足]用語集の作成
これから業務システム設計において、種々の要素成果物を作成していくことになる。次第に、プロジェクト参加メンバーも増加していく。用語が正確に規定されていなければ、ビジネスモデルや業務プロセスの定義はメンバーに正確に伝わらない。
したがって、顧客との、顧客の間で、そしてプロジェクトチーム内のコミュニケーションを正確にするため、そして新規加入メンバーの早期立ち上げのために、用語集が必要不可欠となる。下記に、用語集に掲載する用語区分の例を示す。
①組織(外部ステイクホルダー､内部ステイクホルダー、情報システム名など)②業務プロセス③業務ルール④リソース（製品、部材、設備など）⑤情報とデータ
この用語集は、プロジェクトのフェーズやアクティビティの進捗に伴って、追加・改定され最終的にデータ辞書までつながっていくものである。

47

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

Ⅳ-1-3 業務システム構想策定
1） アクティビティの目的「業務システム構想策定」においては、業務システム改革要求を含んだ業務システム改革モデルから、階層レベ
ル２上でこれを実現するための業務プロセス改革要求(概要)、構想レベルの組織改革要求、IT へのビジネス要求(概要)に構造化する。そして、業務システム改革構想として、業務プロセス改革構想、組織改革構想、IT システム
戦略構想を策定する。
2） アクティビティの実践ポイント(1)目的達成のための実践ポイント
当該アクティビティの目的を達成するためには、Ⅲ-1 で前述したように、下記の実践ポイントを具体的に実現しなければならない。
①業務システムの三位一体の要素を対象とする②業務システム改革モデルを構造化する。この際に、階層レベルおよび記述要素すなわちメタモデルを適切に規定して、MECE にこれを行う③業務プロセス改革要求(概要)を定義し、業務プロセス改革構想を策定する⑤ IT へのビジネス要求(概要)を定義し、IT システム戦略構想を策定する⑤構想レベルの組織モデルを定義し、組織改革構想を策定する(2)「業務システム構想策定」の実施手順
実施手順１：業務システム改革要求の構造化
実施手順２：業務プロセス改革要求(概要)の定義
実施手順３：三位一体の改革構想の策定
3）「業務システム構想策定」の事例「業務システム構想策定」の実施手順について、事例を交えてその詳細を説明する。
(1)実施手順１：業務システム改革要求の構造化
階層レベル１の業務システム改革モデルについて、トップダウンアプローチによって階層レベル２の業務機能へと構造化することによって、業務プロセス改革要求(概要)を抽出する。
この業務機能への構造化の際に、階層的な業務プロセス参照モデルを利用できる。まず、業務システム改革モ
デルの階層レベル１の経営機能に属する階層レベル２の業務機能をもれなく特定する。つぎに、業務システム改
革モデルに含まれる業務システム改革要求について、これらの業務機能に対する業務プロセス改革要求(概要)
へと MECE に構造化する。
【事例 A】
前述したⅣ-1-2 では、「受注設計生産(ETO)品の拡販」という事業戦略から、販売という階層レベル１の経営機能において「ETO 品の販売業務プロセスの確立」という業務システム改革要求を定義した。
販売業務には、潜在顧客のリサーチ活動、見込顧客とのコンタクト活動、提案・受注活動などの階層レベル２の業
務機能がある。この業務システム改革要求は、階層レベル２の提案・受注業務に対しては、図表Ⅳ-1-3-1 のように、「ETO 品の受注業務(仕様決定、原価見積、納期設定)の標準化」という業務プロセス改革要求(概要)に構造化した。図表Ⅳ-1-3-1 では、他の業務機能への構造化は省略した。

48

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

図表Ⅳ-1-3-1 事例 A：業務プロセス改革要求(2)実施手順２：業務プロセス改革要求（概要）の定義
実施手順１のトップダウンアプローチによる構造化だけでは、業務プロセス改革要求(概要)を適切に MECE に定義できない可能性がある。したがって、図表Ⅲ-1-3-2 に前掲した業務プロセス定義の共通的な５つの手順を踏
むことによって、より精緻に業務プロセス改革要求（概要）を定義していく。
①現状レベル２業務プロセスの調査・記述
階層レベル２の業務機能の現状を調査・記述する。レベル２業務プロセスだと、プロセス数は 20-40 個位となる。
通常、この段階ですぐにいくつかの現状プロセスの課題が明らかになることが多い。
【事例 A】
図表Ⅳ-1-3-2 は、業務プロセス参照モデルの階層レベル２の業務機能を参照して作成した現状レベル２業務プ
ロセス図である。ここでは、自社だけでなく、主要なサプライヤや顧客の業務プロセスの一部を記述してある。
②上位設計(業務システム改革要求)からの構造化
トップダウンアプローチによって、業務システム改革要求から業務プロセス改革要求(概要)へと構造化する。ここは、(1)実施手順１において既に実施した。
③現状レベル２業務プロセスの課題抽出
現状プロセスを記述する過程で抽出できた課題だけでは必ずしも十分ではない場合には、必要に応じて、階層
レベル２用の業務インタビューシートの利用、クロスファンクショナルチームによる課題出しワークショップの開催、階層レベル２のプロセス評価チェックリストなどの技法を利用して、階層レベル２の業務プロセスの課題を抽出する。ここはボトムアップアプローチとなる。
事例 A では、図表Ⅳ-1-3-1 のように、受注業務において「ETO 品の顧客要求の確認」というプロセス課題を抽出して追記した。
図表Ⅳ-1-3-2 事例 A：現状レベル２業務プロセス図

49

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例④レベル２業務プロセス分析
プロセス分析では、構造化された業務システム改革要求の実現、そして現状プロセス課題の解決、この両方の根本原因を特定する。しかし、根本原因として、今まで出てきていない第３因子が存在する可能性もある。したがって、システム思考を行うための技法として、TOC 思考プロセス11の「現状分析ツリー」などを利用して、別の第３因子が存在しないことを確認する。現状分析ツリーは合意形成の技法としても有効である。
⑤レベル２業務プロセス設計特定された根本原因の解決策として業務プロセス改革要求(概要)を設計する。また、この解決策による新たな悪影響がないこと、そして解決策に必要な前提条件が揃っていることなどの確認のためのシステム思考の技法として、TOC 思考プロセスの「未来実現ツリー」などを利用して、設計された解決策をレビューする。
このようにして、より精緻に業務プロセス改革要求(概要)を定義できる。事例 A では、受注業務において「顧客要求の確認シートの整備、見積チェックシートの整備、売価設定基準の整備」を設計した。
ここで、業務プロセス改革要求(概要)は業務機能と業務プロセス改革区分(後述)の組み合わせとして記述する。
業務機能別に業務プロセス改革要求(概要)を集約して、現状に反映したものが業務プロセス改革モデルとなり、ビジネスモデルの階層レベル２に位置するサブモデルである。また、これは同時にレベル２業務プロセスでもある。
業務プロセス改革区分とは、階層レベル２の業務機能やレベル３業務プロセスに対する改革要求において、有形・無形資産のリソースとの関係を設定したものである。業務プロセス改革要求(概要)は複数の業務プロセス改革
区分間において整合性を考慮したものでなければならない。情報と IT システムに関する業務プロセス改革要求(概要)が IT へのビジネス要求(概要)となる。

11

内山春彦・中井洋子：「会社が変われない本当の理由」，東洋経済新報社，2003

50

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例【事例 B】
図表Ⅳ-1-3-3 に業務プロセス改革区分の意味、および SCM 改革における業務プロセス改革要求の例を示した。
図表Ⅳ-1-3-3 事例 B：業務プロセス改革区分ごとの業務プロセス改革要求の例

事例Ｂでは業務プロセス改革区分として、設備、組織、業務ルール、業務プロセス機能、人、情報と IT システム、
この６つを取り上げている。この６つの区分は、多くの SCM 改革事例を分析した結果から得たものである。成功事
例においては、業務プロセス改革区分間で整合性を取ったバランスのよい業務プロセス改革を実施していた。そして、IT システムだけに依存した事例の多くは失敗に終わった。
(3)実施手順３：三位一体の改革構想の策定
業務プロセス改革要求(概要)は図表Ⅳ-1-3-3 のように三位一体の要素を含んでいる。業務プロセス改革区分のうち、組織や人に関するものは「人・組織の視点」へ、設備、業務ルールそして業務プロセス機能に関するものは｢業務プロセスの視点｣へ、情報と IT システムに関するもの、すなわち IT へのビジネス要求(概要)は「IT システム」
へと、それぞれ対応する。
これら業務プロセス改革要求(概要)を実現するため、以下の改革構想を策定する。この中で、組織改革構想の実
現が一番、難易度が高く、相応の期間を要する。
①業務プロセス改革構想
業務プロセス改革要求(概要)の実現について、目的、業務プロセス改革モデル（レベル２業務プロセス）、ロード
マップ、超概算見積レベル（精度±20～30%）の効果と費用を示したものが、業務プロセス改革構想書となる。この
業務プロセス改革構想書から、業務プロセス改革企画書、業務プロセス改革計画書、業務プロセス改革実行計
画書とプロジェクト計画を段階的に詳細化して実行していく。
②組織改革構想
組織改革構想としては、業務プロセス改革要求(概要)から構想レベルの組織モデルを定義する。これについて、
51

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

構想、ロードマップ、超概算見積レベル（精度±20～30%）の効果と費用を示したものが、組織改革構想書となる。
この組織改革構想書から、組織改革企画書、組織改革計画書、組織改革実行計画書とプロジェクト計画を段階的に詳細化して実行していく。
③IT システム戦略構想
IT システム戦略構想としては、IT へのビジネス要求(概要)の実現の構想を策定する。これについて、構想、ロード
マップ、超概算見積レベル（精度±20～30%）の効果と費用を取りまとめたものが IT システム戦略構想書である。
この IT システム戦略構想書から、IT システム戦略企画書、IT システム導入計画書、IT システム導入実行計画書とプロジェクト計画を段階的に詳細化して実行していく。
三位一体の要素の改革構想の実現ロードマップは、改革要求の難易度、相関関係や組織の成熟度によって、当然に変ってくる。したがって、改革構想は、何年間かにわたるプログラム計画として複数の改革プロジェクト計画を含んだ形で構想することが多い。BABOK® ではこれをビジネスケースと呼び、IT への、そして IT 以外へのビジネス要求の定義のためのインプットとしている。
プログラム計画、および詳細化が異なる各プロジェクト計画は、その都度、ステイクホルダーの合意と承認を取り付けておく。

52

第Ⅳ章

Ⅳ-2

IT 経営実現プロセスの階層化アプローチの事例

IT 戦略フェーズの事例

Ⅳ-2-1

業務プロセスグランドデザイン

1） 目的「業務プロセスグランドデザイン」においては、業務プロセス改革要求(概要)を含んだ業務プロセス改革モデルから、業務プロセス改革要求(詳細)、およびこれを含んだレベル３業務プロセスを定義する。
2） アクティビティの実践ポイント(1)目的達成のための実践ポイント
当該アクティビティの目的を達成するためには、Ⅲ-1 で前述したように、下記の実践ポイントを具体的に実現しなければならない。
①業務プロセス改革モデルを階層レベル３に構造化して、レベル３業務プロセスを設計する②階層レベルとプロセス構成要素を適切に規定する
この際に、階層レベルおよびプロセス構成要素すなわちメタモデルを適切に規定して、レベル３業務プロセスを
MECE に定義する。
(2)「業務プロセスグランドデザイン」の実施手順
業務プロセスグランドデザインは、図表Ⅲ-1-3-2 に示した業務プロセス定義の共通的な手順に沿って行う。
実施手順１：現状レベル３業務プロセスの調査・記述
実施手順２：レベル２業務プロセス設計(業務プロセス改革要求(概要))からの構造化
実施手順３：現状レベル３業務プロセスの課題抽出
実施手順４：レベル３業務プロセス分析
実施手順５：レベル３業務プロセス設計(業務プロセス改革要求(詳細)の定義)
実施手順６：業務プロセス改革企画書の取りまとめ
3） 「業務プロセスグランドデザイン」の事例「業務プロセスグランドデザイン」の実施手順について、事例を交えてその詳細を説明する。
(1)実施手順１：現状レベル３業務プロセスの調査・記述
業務プロセス改革モデル（レベル２業務プロセス）に含まれる業務プロセス改革要求(概要)について、その下位に属するレベル３業務プロセスを特定する。そして、その現状を調査し、業務プロセスフロー、業務プロセス機能、担当責任組織などを正確に記述する。この調査・記述の際に、業務プロセス参照モデルを利用すれば、現状では欠落しているレベル３業務プロセスも明確にできる。
【事例 A】
現状プロセスの調査・記述の前に、関連するメンバーに業務プロセス参照モデル（レベル３）を簡単に説明した。
まず、階層レベル２の業務プロセス改革要求(概要)の下位に属するレベル３業務プロセスを特定した。そして、業
務プロセス参照モデルの業務プロセスフロー(形式は図表Ⅳ-2-1-3 と同じ)をスクリーンに映して、ユーザー企業のマネジャーに説明し、現状について業務プロセスの有無などを質問しながら記述した。製品設計プロセスに関しては、設計部門のマネジャーが自ら現状プロセスを記述した。
この際に、現状では欠落しているレベル３業務プロセスも明確にした。現状の業務プロセスフローは、現行の組織
を水泳のレーンのように区切った形式(SWIM チャートという)で書かなかった。現状の組織を忘れて機能中心に考
53

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例える方が、現状プロセスの課題が自由に出やすいからである。
(2)実施手順２：レベル２業務プロセス設計(業務プロセス改革要求(概要))からの構造化
トップダウンアプローチによって、業務プロセス改革要求(概要)から、レベル３業務プロセス上の業務プロセス改
革要求(詳細)へと MECE に構造化する。この際に、業務プロセス参照モデルを利用すれば、正確に効率的に構造化できる。
【事例 A】
事例 A では、業務システム構想策定において、レベル 1 の業務システム改革要求をレベル２の業務プロセス改革要求(概要)に構造化して設計した。業務プロセスグランドデザインにおいては、このレベル２業務プロセス設計の結果としての業務プロセス改革要求(概要)から、レベル３業務プロセス上の業務プロセス改革要求(詳細)へと構造化した。この一部を図表Ⅳ-2-1-1 に示した。
図表Ⅳ-2-1-1 事例 A：レベル２業務プロセス設計からの構造化（一部だけ記述）
図表Ⅳ-2-1-1 では、ETO 品に関する業務プロセス改革要求(概要)から、階層レベル
３の「RFP・RFQ の入手と回答プロセス」への構造化を下記のとおり行った。図表Ⅳ-2-1-1 では、他のレベル３
業務プロセスは省略してある。
①業務ルールとプロセス機
能に関して・顧客要求確認ルールと処理の確立
・原価見積基準と原価見積処理の確立
・売価設定ルールと決裁処理の確立②人に関して営業員は自社製品や技術への知識を保有③情報と IT システムに関して顧客要求を共有・閲覧できる仕組みの構築(3)実施手順３：現状レベル３業務プロセスの課題抽出
ここはボトムアップアプローチで行う。現状プロセスの記述の際に抽出できた課題だけでは必ずしも十分ではな
い場合には、階層レベル３用の業務インタビューシートの利用、課題出しワークショップの開催などの技法を利用して、階層レベル３の業務プロセスの課題を抽出する。階層レベル４以下の課題が出てきた場合は、これを一時的に取り除いておく。
【事例 A】
54

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

現状プロセスの調査・記述の際に、すぐにレベル３業務プロセスの課題として、「デモ機の整備」や「顧客口座開設のルールの整備と処理の確立」を抽出した。
(4)実施手順４：レベル３業務プロセス分析
レベル３業務プロセス分析においては、(2)実施手順２のレベル２業務プロセス設計からの構造化の実現、そして(3)実施手順３の現状レベル３業務プロセスの課題の解決、この両方のための CSF と根本原因を正確に特定する。
この際に、CSF や根本原因が現状において欠落しているレベル３業務プロセスに位置づけられる場合がある。これが、現状プロセスの調査・記述の際に、欠落している業務プロセスを明確にしておく理由である。
(5)実施手順５：レベル３業務プロセス設計(業務プロセス改革要求(詳細)の定義)
継続すべき現状プロセス機能を維持しつつ、プロセス分析の結果を解決できる解決策を業務プロセス改革要求(詳細)として定義する。そして、これを含んだレベル３業務プロセスの設計の結果として、新しい業務プロセスフロ
ーや業務プロセス機能などを記述する。業務プロセス改革要求(詳細)には、業務プロセス改革区分（Ⅳ-1-3 にて前述）ごとに三位一体の要素への改革要求を含んでいる。
①「業務プロセスの視点」への改革要求
この改革要求は、レベル３業務プロセスの設計に反映させる。
②「組織・人の視点」への改革要求「組織」や「人のスキルや意欲」から発生した改革要求は、「人・組織グランドデザイン」へのインプットとして反映させる（Ⅳ-2-2 で後述）。
③「IT システムの視点」への改革要求「情報と IT システム」から発生した IT へのビジネス要求（詳細）は、「IT システム戦略企画」へのインプットとして反映させる（Ⅳ-2-3 で後述）。
【事例 A】
特定された根本原因についての解決策を業務プロセス改革要求(詳細)として設計した。この際に、業務プロセス
改革区分ごとの整合性が取れた解決策について、図表Ⅳ-2-1-2 のように検討した。
図表Ⅳ-2-1-2 では、レベル２業務プロセス設計からの構造化だけでなく、レベル３業務プロセスの課題の解決策について、業務プロセス改革区分（設備、組織、業務ルール、プロセス機能、人、情報と IT システム）の観点から検討した。「デモ機の整備」や「顧客口座開設のルールの整備と処理の確立」は、レベル３業務プロセスの課題から、これ以外はレベル２業務プロセス設計からの構造化から設計した。

図表Ⅳ-2-1-2 事例 A：業務プロセス改革要求（詳細）

55

第Ⅳ章

56

IT 経営実現プロセスの階層化アプローチの事例

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

また、作成した ETO 品に関する新しいレベル３業務プロセスフローを図表Ⅳ-2-1-3 に示した。
図表Ⅳ-2-1-3 事例 A：新レベル３業務プロセスフロー （一部だけ記述）

図表Ⅳ-2-1-3 には、販売活動プロセス、提案・受注プロセス、商品開発プロセス、製品設計プロセスを表示してある（調達・製造・出荷プロセスは省略）。前述した「RFP・RFQ の入手と回答プロセス」は、提案・受注プロセスの中の一つである。事例 A では、商品開発プロセスと製品設計プロセスの双方とも業務プロセスが確立していなかった。特に、商品開発プロセスは現在は全く存在しておらず、業務プロセス参照モデルを参考にして新たに設計した。結果として商品開発・製品設計に多くの課題がフォーカスされたが、コンサルタントであるITCは特にこの業務に詳しい訳ではなかった。業務プロセス参照モデルがなければ、とても新しいレベル３業務プロセスを設計することはできなかったであろう。
【事例 B】
図表Ⅳ-2-1-4 に、グローバル企業の日本、アジア工場、米国販売会社にわたるサプライチェーン、すなわち計画、調達、生産、出荷に関する階層レベル３の業務プロセスフローの事例を示した。これには、各業務プロセスについて、そのインプット・アウトプットデータを表示してある。このように、階層レベル３ならば、約７０個の業務プロ
セスを A3 の１枚に描けるので、サプライチェーン全体を鳥瞰できる。

57

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

図表Ⅳ-2-1-4 事例 B：新レベル３業務プロセスフロー（グローバル）(6) 実施手順６：業務プロセス改革企画書の取りまとめ
業務プロセス改革要求（詳細)の実現に関して、業務プロセス改革企画書として取りまとめる。下記にその内容の例を示す。
①業務プロセス改革の概要
目的、業務プロセス改革要求(詳細)、改革ロードマップとプロジェクト分割、現状と改革後のレベル３業務プロセス
一覧、概算見積レベル(精度±10～20%)の効果と費用②改革後のレベル３業務プロセスの詳細
業務プロセスフロー、そして個々の業務プロセス機能（プロセス機能、インプットやアウトプット、業務ルール、担当
責任組織など）③プログラム計画
プログラムの体制、スケジュール、リスク、前提条件・制約条件など④プログラム計画を構成する個別プロジェクト計画
プロジェクトの目的、対象となるレベル３業務プロセスと組織、作成すべき要素成果物、プロジェクト体制、スケジ
ュール、費用など⑤リスクマネジメント計画

58

第Ⅳ章

Ⅳ-2-2

IT 経営実現プロセスの階層化アプローチの事例

人・組織グランドデザイン

1) アクティビティの目的「人・組織グランドデザイン」においては、構想レベルの組織モデルに対して、業務プロセス改革要求(詳細)からの人・組織への要求を反映して、概要レベルの組織モデルや必要な人の能力を定義する。
2） アクティビティの実践ポイント(1)目的達成のための実践ポイント
当該アクティビティの目的を達成するためには、Ⅲ-3 で前述したように、下記の３つのインプットの要求に対応しなければならない。
①業務システム改革要求から
これは、業務システム改革要求から、直接に人・組織の改革に反映する場合である。たとえば、経営リソースとしての長期的人材育成や人事制度改革などがある。そして、ソフトな構造の組織の改革としての風土改革や意識改
革、ハードな構造の組織の改革としてのアウトソーシング、機能分社化、インソーシングなどの場合もある。
②業務プロセス改革要求(概要)から
これは、業務プロセス改革モデルの業務プロセス改革要求(概要)からの人・組織の改革要求である。たとえば、業
務プロセス改革要求(概要）から、組織の新設や廃止が必要になる場合である。
③レベル３業務プロセスから
業務プロセス改革要求(詳細）によって、既存の組織の機能や人のスキルの変更、および新設する組織の機能や人の能力への要求がより具体的になった場合である。
(2)「人・組織グランドデザイン」の実施手順
人・組織グランドデザインは、Ⅲ-3-3 で説明したように、以下の手順で行う。
実施手順１：組織のグランドデザイン
実施手順２：人のグランドデザイン
実施手順３：組織改革企画書の取りまとめ
3） 「人・組織グランドデザイン」の事例「人・組織グランドデザイン」の実施手順について、事例を交えてその詳細を説明する。
(1)実施手順１：組織のグランドデザイン
組織のグランドデザインでは、部や課といった概要レベルでの組織モデルとして、ミッションや目的、権限・責任、
組織機能、業績評価指標、組織形態と構造などを定義する。以下、組織のグランドデザインにおける留意点についてのべる。
①組織のミッションや目的
この定義の際に、専門化が行き過ぎると、縦割りの組織の弊害が出てしまうことに留意する。
②権限・責任この定義の際に、権限と責任の一致、他組織との職務分担の安定した関係に留意する。
③組織機能
グランドデザインされたレベル３業務プロセスによって、組織機能をより具体的に定義できる。
④業績評価指標59

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

業績評価のための指標は、以下の要素を必要とする。
・Specific（明確性）
・Measurable（測定可能性）
・Agreed（合意された）・Result-oriented or Relevant（結果指向または関連性）
・Time-bound（期限）⑤組織形態と構造
この定義の際に、組織階層が深くなると情報伝達が不正確になりがちになり、伝達の時間もかかってしまう。可能な限り階層を少なくするようフラットな組織構造にすることに留意する。
⑥組織マネジメント
組織運営のためのリーダシップスタイルを決定する。
【事例 A】
図表Ⅳ-2-1-2 に示したものを含めた業務プロセス改革要求(詳細）全体からの組織への要求を図表Ⅳ-2-2-1 に示した。
図表Ⅳ-2-2-1 事例 A：業務プロセスグランドデザインからの人・組織への要求

図表Ⅳ-2-2-1 には、「商品開発部を新設して、営業からの顧客要求に基づいて構想設計を行い、提案活動を支援する、そして製品設計から生産準備までを統合的に管理する」という組織への要求がある。そして、この要求に基づいて概要レベルの組織モデルを定義した。
(2)実施手順２：人のグランドデザイン
ハードな要素としての人のグランドデザインには、以下の２つのケースがある。
60

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例①グランドデザインされた組織モデルから
グランドデザインされた組織モデルを構成する人への要求を検討して、人をグランドデザインする。
②業務プロセス改革要求(詳細)から
業務プロセス改革要求(詳細)には、「人」という業務プロセス改革区分における改革への要求がある。これを組織モデルごとに集約することが、ハードな要素としての人のグランドデザインとなる。
【事例 A】
図表Ⅳ-2-2-1 には、業務プロセス改革要求(詳細）からの人への要求も記述されている。たとえば、営業部の若手営業員には、「原価・価格への知識、機械への基礎知識、自社製品への知識、要求インタビュースキル、交渉
スキル」などの要求がある。これは、次フェーズにおいて、営業の職務記述書に定義して、要員能力開発計画を策定する。
【事例 B】
SCM 事例において、統合したサプライチェーン計画を立案する組織として、SCM センターを新設する場合には、次のことが必要になる。
①組織の権限・責任
営業部門は需要予測に必要な因果要素パラメータ情報を収集する責任を負う。SCM センターはそれを使って需要予測を行い、需要と供給能力を調整する権限と供給する責任を負う。そして、関係する部門では、この需給計
画に沿って生産計画、調達計画、出荷計画を立案する責任を負う。
②組織の業務プロセス
新設される SCM センターには、需要予測、需要計画、供給計画、需給調整、需給計画を立案、あるいはこれらの計画をローリングするための業務プロセスが新たに必要になる。そして、関係する部門の業務プロセスも、当然にSCM センターの業務プロセスとの連携のために変更や新設が必要となる。
③組織の業務ルール
業務プロセスの新設や変更に伴って、因果要素パラメータ設定、需給調整、基準在庫設定などの業務ルールの改廃や新設が必要になる。
④人的資源としての要員の能力
SCM センターの要員に必要な人の能力を設計する。たとえば、需要予測や需給調整に関する能力が不可欠となる。
⑤情報と IT システム(省略)(3) 実施手順３：組織改革企画書の取りまとめ
組織と人のグランドザデインの実現に関して、組織改革企画書として取りまとめる。下記にその内容の目次例を示す。
①組織改革の概要
目的、組織改革への要求、改革ロードマップとプロジェクト分割、現状と改革後の組織モデル図、概算見積レベ
ル（精度±10～20%）の効果と費用②改革後の組織モデル
概要レベルの組織モデルとして、目的、責任、権限、組織機能、業績評価指標、組織を構成する人の能力など③プログラム計画
プログラムの体制、スケジュール、リスク、前提条件・制約条件、チェンジマネジメント計画(Ⅲ-3 で前述) など
61

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例④プログラム計画を構成する個別プロジェクト計画
プロジェクトの目的、対象となるレベル３業務プロセスと組織モデル、作成すべき要素成果物、プロジェクト体制、
スケジュール、費用など⑤リスクマネジメント計画
この必要性の例は既にⅢ-3 において述べた。

62

第Ⅳ章

Ⅳ-2-3

IT 経営実現プロセスの階層化アプローチの事例

IT システム戦略企画(IT サービス)

1) アクティビティの目的「IT システム戦略企画」においては、IT システム戦略構想に対して、業務プロセス改革要求(詳細)からの IT へのビジネス要求(詳細)、および現状 IT システム課題を反映して、IT システム戦略として IT サービス戦略と IT 環境戦略を策定する。
2） アクティビティの実践ポイント(1)目的達成のための実践ポイント
当該アクティビティの目的を達成するためには、Ⅲ-2 で前述したように、下記の実践ポイントを具体的に実現しなければならない。
①業務プロセスへの改革要求から IT へのビジネス要求(詳細)を定義する
IT へのビジネス要求(詳細)は経営面からの IT への要求である。したがって、事業戦略からの業務システム改革要
求、これを受けた業務プロセス改革要求(概要)、これを反映したレベル３業務プロセス上の業務プロセス改革要求(詳細)から IT へのビジネス要求(詳細)を定義する。
②現状 IT システム課題を抽出する
現状 IT システムから、IT 環境としてハードウェア・基盤系、アプリケーションソフトウェア、データ、開発・運用体制、そして IT サービスに関する IT システム課題を抽出する。
③現状 IT システムの調査・記述の階層レベルと記述要素を適切に規定する
現状IT システムの調査・記述は、IT システム戦略構想の場合は階層レベル２であったが、IT システム戦略企画の場合は階層レベル３で行う。また、記述の要素すなわちメタモデルとしては、IT 環境(IT 資源、データ、IT サービスの開発・運用体制)や IT サービスである。
(2)「IT システム戦略企画」の実施手順
IT システム戦略企画は、図表Ⅲ-2-3-2 に示した IT 要求の各サブモデル定義の共通的な手順に沿って行う。
実施手順１：階層レベル３での現状 IT システムの調査・記述
実施手順２：IT へのビジネス要求（詳細）の抽出
実施手順３：階層レベル３での現状 IT システム課題の抽出
実施手順４：IT サービス戦略と IT 環境戦略の策定
実施手順５：IT システム戦略企画書の取りまとめ
3） 「IT システム戦略企画」の事例「IT システム戦略企画」の実施手順について、事例を交えてその詳細を説明する。
(1)実施手順１：階層レベル３での現状 IT システムの調査・記述
現状の全てのIT 環境やIT サービスの現状を調査・記述しなければならない。ここでは、階層レベル３程度の詳細さであればよい。このアクティビティで必要とする以上の詳細過ぎる調査・記述は無駄である。階層レベル４での詳細な調査・記述は「IT システム計画・調達」で行えばよいからである。
さらに、情報システム部門など IT システムを管理する部門で把握できていない、組織の各部門で独自で構築して運用している IT システムももれなく調査・記述する必要がある。このためには、現状のレベル３業務プロセスをベースに聞き取り調査すればよい。現状の不完全なドキュメントに頼るとリスクが大きい。

63

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例(2)実施手順２：IT へのビジネス要求（詳細）の抽出「業務プロセスグランドデザイン」によるレベル３業務プロセス上の業務プロセス改革要求(詳細)のうち、情報と ITシステムに関する業務プロセス改革区分におけるものが、IT へのビジネス要求(詳細)となる。
なお、IT へのビジネス要求には、機能要求と非機能要求とがある。機能要求は個々の業務プロセスから IT サー
ビスへの要求として定義すればよい。一方、レスポンスタイムや運用時間帯のような非機能要求は、IT 環境への要求となる。IT へのビジネス要求(詳細)の優先順位付けについては、Ⅳ-2-7 にて後述する。
【事例 B】
定型的な業務プロセスから IT へのビジネス要求を抽出した例を図表Ⅳ-2-3-1 に示した。この例では、調達に関して設計されたプロセス改革要求(詳細)のうち、一番右側の「情報と IT システム」に関するものが IT へのビジネス要求(詳細)となる。業務プロセス改革要求(詳細)の直前の番号は、業務プロセス改革要求(概要)との関係を示して
いる。

64

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

図表Ⅳ-2-3-1 事例 B：調達関係での IT へのビジネス要求（一部だけ記述）

ここでは、IT へのビジネス要求(詳細)は他の業務プロセス改革区分との整合性を考慮してある。たとえば、S2.1 発
注プロセスにおける「需要予測のためのシミュレーション機能の構築」に対しては、人の「需要予測に関するスキル養成」が前提となっている。
事例 B では、業務プロセス参照モデルを利用して、S2.1 発注や S2.4 移送といった調達の業務実行だけでなく、
ES.2 調達パフォーマンス管理、ES.2 資材在庫管理、ES.7 資材品目マスタ管理といった共通支援のための業務プ
ロセスから IT へのビジネス要求（詳細）を抽出した。
【事例 A】
事例 A は業務プロセス改革として、販売活動、商品開発、設計という非定型的な業務プロセスが対象となった。現
在、欠落している業務プロセスがかなりあるので、この段階での IT へのビジネス要求(詳細)はまだ曖昧であり、事例として記載しなかった。ただし、業務プロセス概要設計が終われば、IT へのビジネス要求(詳細)はかなり明確になってくる。
(3)実施手順３：階層レベル３での現状 IT システム課題の抽出
Ⅲ-2-3 で前述したように、IT 環境や IT サービス提供に関連する業務プロセスから、IT システム課題を抽出できる。
この場合の IT システム課題としては、階層レベル３に位置するものを選定する。

(4) 実施手順４：IT サービス戦略と IT 環境戦略の策定
IT へのビジネス要求(詳細)のうちの機能要求を集約して新 IT サービス案を設計し、IT サービス戦略を策定する。
65

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

また、関連 IT 動向、そしてプラットフォーム、セキュリティ管理、ソフトウェア開発・導入などの企業の方針を踏まえた上で、IT へのビジネス要求(詳細)のうちの非機能要求や現状 IT システム課題から、IT 環境戦略を策定する（Ⅳ-2-4 で後述）。
(5) 実施手順５：IT システム戦略企画書の取りまとめ
業務プロセス改革企画書と整合性を考慮して、IT サービス戦略と IT 環境戦略の実現について、IT システム戦略
企画書として、全体 IT システムおよび個別 IT システム別に取りまとめる。下記にその主な内容の目次例を示した。
①IT システム戦略の概要
目的、業務プロセス改革要求(詳細)と IT へのビジネス要求(詳細)、改革ロードマップとプロジェクト分割、概算見
積レベル（精度±10～20%）の効果と費用など②IT サービス戦略企画と IT 環境戦略企画(全体と個別 IT システム)
現状 IT システム概要、業務プロセスと IT へのビジネス要求(詳細)、IT システム課題、関連 IT 動向、IT サービス
戦略と IT 環境戦略、各種 IT システム化方針(含むプラットフォーム構成方針、セキュリティ管理方針、ソフトウェア
開発・導入方針)、そして効果と費用など③プログラム計画
プログラムの体制、スケジュール、リスク、前提条件・制約条件など④プログラム計画を構成する個別プロジェクト計画
プロジェクトの目的、範囲、IT へのビジネス要求(詳細)、IT システム化方針、作成すべき要素成果物、プロジェクト
体制、スケジュール、費用など⑤リスクマネジメント計画
なお、IT システムの開発・導入までのプロジェクトフェーズを図表Ⅳ-2-3-2 に示した。
・フェーズⅠ：IT システム戦略構想(Ⅳ-1-3 で前述)、フィージビリティスタディに該当・フェーズⅡ：IT システム戦略企画(Ⅳ-2-3)、基本計画に該当・フェーズⅢ：IT システム導入計画(Ⅳ-2-6 で後述)、実行計画に該当・フェーズⅣ：IT システム導入実行計画

66

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

図表Ⅳ-2-3-2 IT システムの開発・導入までのプロジェクトフェーズ

67

第Ⅳ章

Ⅳ-2-4

IT 経営実現プロセスの階層化アプローチの事例

IT システム戦略企画(IT 環境)

1） アクティビティの目的
IT 戦略の一つの側面として、IT システムの視点から IT 環境の変化を含む経営環境変化に対応でき、継続的に業
務システムを維持していける目標 IT 環境を策定するというものがある。
２） アクティビティの実践ポイント(1)目的達成のための実践ポイント
IT 環境は構築したら終わりではなく、経営環境変化に応じて柔軟に対応できるものでなければならない。現在の業務プロセスを実現するだけでなく、将来も業務を支え続けられるものでなければならない。環境変化によってIT 環境を変更しなければならない事態が発生したとしても、業務の継続性を維持する必要がある。IT 環境の変更
によって、それまでに積上げた業務ノウハウなどを失ってしまうことがあってはならない。そのため、次のことを考慮することが必要である。
①策定時点の流行に左右されず、将来を見据えた IT 戦略を立案すること最新の IT 技術を導入しようとして、十分な検討をせずに流行の IT 技術を導入しようとしてはならない。現在の流行が将来の標準になりうるものなのかを冷静に判断する必要がある。逆に、過去の IT 資産を重視するあまり、時代の流れに取り残されるようでもいけない。例えば、レガシーシステムと呼ばれる時代遅れのシステムを使い続けて、どうにもならなくなってからいきなり最新の技術を導入しようとすると、システム移行の際に過去の情報資産を引き継ぐことが出来ず、完全な作り直しになることがある。それよりもシステムが過去の遺物になる前に計画的に更新をして情報資産を引き継げるようにする方が良い。
IT 戦略立案時には、将来の技術動向を完全には予測できないまでも、トレンドを把握して将来性のある IT 戦略を立案するように注意が必要である。
②将来改造が可能な構造にしておくこと
IT システムは使い続けるうちに必ず環境変化に対応するため、何らかの更新作業を行う必要がある。多くの場合、システムの改造が必要になる。その際に、改造が困難だったり、改造できる人がいなくなっていたりすると、環境対応が出来なくなってしまう。したがって、目標 IT 環境の策定を行う際には、運用・保守だけでなく改造に対応できる体制も検討しておく必要がある。また、IT システムの構成も改造が可能なように構造化しておくことや、設計ド
キュメントを整備しておくことなども最初の計画時に定めておく必要がある。予め想定できる改造については、プ
ログラム改造ではなくパラメータの設定で済むような設計をしておくことも良い方法である。機能を追加するために外部プログラムとインターフェースする場合の API を定義しておくことも良い。
特に、業務プロセスに適合させるためにスクラッチ開発を行ったり、パッケージに対して大幅な改造を行った場合、開発時の担当者でなければメンテナンスできない状況になることが多い。そうなってしまうと、その担当者が異動したり退職した場合にシステムをメンテナンスできなくなってしまう。IT システムの改造の可否が人に依存しないよ
うにしなければならない。
③できるだけオープンで汎用的な技術を使うこと
将来にわたって使い続け、新しい技術が導入された場合に容易に乗り換えられるようにするためには、できるだけオープンで汎用的な技術を使って IT システムを構築しておくことが望ましい。特殊な技術を使って構築された専用システムは、その時点では業務要求に最適なシステムであるかもしれないが、環境変化により新たな IT サー
ビスを導入することになった場合、現行システムの特殊性ゆえに新たな IT サービスが導入できない場合がある。
オープンで汎用的な技術を使っていれば、新たな IT サービスはその技術に対応したものである可能性が高いの
68

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

で、いち早く最新の IT サービスを導入することができる。
また、IT システム環境は自社の都合だけで考えるものではなく、取引関係のある他社との関係も考慮しなければならない。他社との提携や協業を行う場合、オープンな技術を使った IT システムを持っていれば、比較的容易にシステム間連携を図れる場合がある。
また、IT 環境を乗り換える場合、それまでの実績を引き継げるように、移植性の高いシステムにしておくことが重要である。
変化の激しい現代では、環境対応のスピードが事業の勝敗を分ける場合もあるので、IT 環境の選択は近代兵器による戦争のケースと同様に重要である。
(2)プロセスの課題
PGL では、IT システム導入を一連の流れとしてフェーズ分けして導入プロセスを示している。
しかし、この説明はともすると IT システム導入が一過性のものであるかのような誤解を与える可能性がある。IT シ
ステム導入を含む業務改革プロセスは、一過性のものではなく PDCA のループを繰り返す必要がある。
この中で、IT システムは業務改革を実現するツールとして機能するものである。業務改革を実現するために IT シ
ステムが足かせになってはならないのであって、そのためにはシンプルさと保守性が必要である。業務改革に対して IT システムがシンプルで柔軟に対応できるようにするためには、IT システム自身が常に技術の進歩に合わせた更新をしている必要がある。
ビジネスを戦争に例えて経営方針を戦略と呼ぶことがあるが、戦略とそれに基づく戦術を実行するためは部隊と武器が必要であり、IT システムは武器に相当する。競争環境に合わせて適切な武器を選択して、それを適切にメンテナンスすることは、戦略の実現のために非常に重要である。
(3)課題解決の効果① 経営環境変化に追従した迅速な IT システムの対応が可能になる
常に最新でオープンな IT システムを維持していれば、環境変化があった場合に直ちに IT システムを適応させることができる。そうでない場合、環境変化に適応しようとする際に既存の IT 環境が制約になってしまい、業務要求を実現することができないことがある。
② IT に関するトータルコストを削減できる
IT 環境の整備をおろそかにしていると、一見保守費用を削減しているように見えるが、上記のように IT 環境が制約になって業務改革を阻害する場合がある。業務改革のために IT 環境の刷新を図ると、その際には多額の IT 投資が再び必要になってしまう。したがって、常に IT 環境を最適な状態に維持することは、IT に関するトータルコス
トを削減できると言える。
3） 目標 IT 環境策定の事例（１）課題解決策とその実施留意点
一般に企業が保有する IT システムは、大きく分けてオンプレミスとクラウドサービスを利用する場合がある。（中間的な運用方法として、ハウジングサービスやホスティングサービスがあるが、ここでは対比のためにオンプレミスとクラウドという分け方で説明する。）①オンプレミス（自社保有）の場合
オンプレミスとは、構築した IT システムを自社で保有する利用形態のことである。オンプレミスは、従来からの ITシステムの利用形態であり、クラウドサービスを利用しない場合はオンプレミスを選択することになる。オンプレミス
69

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例のメリットとしては、次の項目が挙げられる。
・ 自社のニーズに合った IT システムを選定して保有できる。
・ 自社で IT システムを保有しているので、IT システムの利用料はかからない。
・ インターネットを介さず、自社内にサーバが設置されるならば、インターネット利用によるセキュリティ上のリスクをある程度回避できる。
・ IT システムや情報を第三者が扱うことが無いので、自己責任で管理することができ、セキュリティ上の安心感がある。
・ 自社で運用管理するので、自社の方針で可用性を高めることができる。
オンプレミスで IT システムを運用する場合は、運用・保守体制を確立することが重要である。その上で IT システム
をいつまで使い続けるのかの方針を策定しておくべきである。IT システム投資計画は、システムの寿命を考慮して立案されなければならない。
②クラウドサービスを利用する場合
クラウドコンピューティングについてその定義は様々であるが、一般的にはインターネットを介したコンピュータの利用形態のことを言う。そして、オンプレミスに対して IT システムを自社保有せず、インターネットを介して利用するサービスを提供したものがクラウドサービスである。クラウドサービスを利用するメリットは、次の項目が挙げられる。
・ IT システムインフラを導入する初期コストを抑えることができる。
・ システム開発期間を短くすることができる。
・ 社内にシステムの運用・保守要員を持つ必要が無く、運用・保守業務を業者に任せることができる。
・ システムのバージョンアップが業者により行われ、常に最新のシステムサービスを利用することができる。
・ 自社内に IT システムを資産として持たないので、環境変化に対応してサービスを乗り換えることが比較的簡単にできる。
SaaS などのクラウドサービスを利用する場合は、まず自社に合ったサービスを選定することが重要である。自社の要求事項を完全に満足するクラウドサービスは一般には存在しないので、要求が満たされない部分をどのように扱うか検討する必要がある。また、該当するクラウドサービスの将来性についても考慮する必要がある。現時点で最適なサービスだとしても、それがすぐに陳腐化するようでは使い続けることはできない。他のサービスに乗り換えることができるとしても、同じサービスを使い続けることができればそれに越したことは無い。常に進化を続けて使い続けることができるクラウドサービスを選定することが重要である。

（2）目標 IT 環境策定の具体例【事例 B】
ある中堅製造業では、従来は過去に導入したオフコン（オフィスコンピュータ）による基幹業務システムを使い続けてきたが、該当機種がメーカのサポート切れになったのをきっかけにして長期的な視点に立った IT 戦略を立案した。同社では、経営情報システムを特定メーカのシステムに依存することは危険だと考え、以後選定するシステ
ムは全社 IT 戦略に従ってオープン系システムで統一することにした。各部門で導入するシステムも計画段階で情報システム部による計画審査を行い、全社 IT 戦略に従っているかを確認している。
4） IT 戦略策定の実施手順(1) 内部環境分析
70

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

現行の業務プロセスや現行 IT 環境、さらに組織メンバーの IT リテラシーなど、組織の内部環境の分析を行う。この分析により、内部環境に起因する目標 IT 環境への要求を導出する。目標 IT 環境への要求事項には、業務量によるパフォーマンス要求や運用・保守体制から運用・保守の容易さへの要求など、非機能要求が多く含まれる。
(2) 外部環境分析
同業他社の事例や IT 技術動向などから IT 領域の外部環境を分析する。他社事例を分析する際には、単に IT シ
ステム構成の結果のみに着目するのではなく、その構成を選択した理由を分析する。そうすることにより、単に流行を追ったり他社のマネをして追随するのではなく、自社に適した IT 環境は何かを知ることができる。
また、外部環境の分析では、「今、何が起こっているか？」ということだけでなく、「近い将来どうなるか？」を分析することが重要である。IT 戦略を策定してもそれが実現するのは数年先になることが多いので、将来動向の予測をすることが必要になってくる。
(3) 目標 IT 環境策定
内部環境と外部環境の両方を分析した上で、自社としての目標 IT 環境を策定する。目標 IT 環境を策定する際には、その IT 環境を実現するのがいつになるかを考慮する必要がある。OS やミドルウェアのバージョンアップなど
は予め計画が公開されていることが多いので、そのスケジュールにあった計画を立案することが重要である。
(4) IT 戦略策定
IT システムの視点から求められる目標 IT 環境と、業務プロセスの視点から求められる IT への要求を考慮して IT戦略を策定する。その際、人・組織の視点から、自社の組織構造や人の IT リテラシーから考えて IT 戦略が実現可能であるかというチェックを忘れてはならない。いかに理想的な IT 戦略を策定しても、自社の身の丈に合わな
いものであっては実現が困難であり、使えこなせずに負担が増えてしまうことも考えられる。
(5) IT 戦略展開
IT 戦略を策定したら、その実行計画を立案して、個別 IT システムの企画につなげていく。そのアウトプットを IT 資
源調達フェーズへと引き継いでいく。その際、人・組織の観点から運用・保守体制の構築などの組織変更や、人材育成の計画なども同時に策定されなければならない。
5） 特記事項（１） クラウド時代の人材像
クラウドサービスが普及して、IT 経営実現を支援する IT コーディネータの人材像も変化してきている。従来は要求定義、要件定義までを行って、システム開発は SI ベンダーに任せることが多かったが、クラウドサービスを利用する場合はシステム開発をする部分が少なくなってくる。そのため、システム開発に関する専門知識が無くても実際のシステム導入までを IT コーディネータが支援できる環境が整ってきている。こういった状況では、IT コーディ
ネータは上流工程だけを担当するのではなく、実際の導入・システム移行・運用・保守に至るシステムライフサイク
ルのすべてについてのワンストップサービスができることが望まれている。

71

第Ⅳ章

Ⅳ-2-5

IT 経営実現プロセスの階層化アプローチの事例

業務プロセス概要設計

1) アクティビティの目的「業務プロセス概要設計」においては、業務プロセス改革要求(詳細)を含んだレベル３業務プロセスから、レベル
４業務プロセスを定義する。
2) アクティビティの実践ポイント(1)目的達成のための実践ポイント
当該アクティビティの目的を達成するためには、Ⅲ-1 で前述したように、下記の実践ポイントを具体的に実現しなければならない。
①業務プロセス改革要求(詳細)を階層レベル４に構造化して、レベル４業務プロセスを設計する②階層レベルとプロセス構成要素を適切に規定する
この際に、階層レベルおよびプロセス構成要素すなわちメタモデルを適切に規定して、レベル４業務プロセスを
MECE に定義する。
(2)「業務プロセス概要設計」の実施手順
業務プロセス概要設計は、図表Ⅲ-1-3-2 に示した業務プロセス定義の共通的な手順に沿って行う。
実施手順１：現状レベル４業務プロセスの調査・記述
実施手順２：レベル３業務プロセス設計(業務プロセス改革要求(詳細))からの構造化
実施手順３：現状レベル４業務プロセスの課題抽出
実施手順４：レベル４業務プロセス分析
実施手順５：レベル４業務プロセス設計
実施手順６：業務プロセス改革計画書の立案と更新
3） 「業務プロセス概要設計」の事例「業務プロセス概要設計」の実施手順について、事例を交えてその詳細を説明する。
(1)実施手順１：現状レベル４業務プロセスの調査・記述
レベル４業務プロセスだと、全てだと数千個もの数になる。したがって、新たに設計されたレベル３業務プロセスに含まれるレベル４業務プロセスについてだけ、現状を調査する。業務プロセスフローだけでなく、個別の業務プ
ロセスのプロセス構成要素を正確にかつ効率的に記述しなければならない。
この調査・記述の際に、業務プロセス参照モデルを利用すれば、現状では欠落しているレベル４業務プロセスも明確にできる。そして、プロセス構成要素についても、業務プロセス参照モデルのそれを参考にして調査・記述できる。そうすれば、インプットやアウトプットの不足、業務ルールの未整備などの課題が自然に出てくる。
【事例 A】
まず、現状プロセスの調査・記述の前に、関連するメンバーに業務プロセス参照モデル（レベル４）を簡単に説明した。次に、階層レベル３の業務プロセス改革要求(詳細)の下位に属するレベル４業務プロセスを特定した。まず、業務プロセスフローについて、業務プロセス参照モデルの業務フロー(形式は図表Ⅳ-2-5-3 と同じ)をスクリーンに映して、ユーザー企業の業務担当者に説明し、現状について業務プロセスの有無などを質問しながら記述した。10 数個のレベル４業務プロセスから構成される業務プロセスフローは約 15 分で完了した。
次に、業務プロセスフロー上の個別の業務プロセスについて、業務プロセス参照モデルの業務プロセス詳細記
述書をスクリーンに映して、業務担当者に各プロセス構成要素を説明し、現状について質問しながら図表Ⅳ
72

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例-2-5-1 のように記述した。図表Ⅳ-2-5-1 の左側は業務プロセス参照モデル、右側は調査・記述した結果である。
少し複雑なレベル４業務プロセスでも約 20 分で調査・記述を完了した。
図表Ⅳ-2-5-1 事例 A：業務プロセス参照モデルを利用した現状プロセスの調査・記述(2)実施手順２：レベル３業務プロセス設計(業務プロセス改革要求(詳細))からの構造化
トップダウンアプローチによって、レベル３業務プロセス上の業務プロセス改革要求(詳細)からレベル４業務プロ
セスへと MECE に構造化する。ここでは、調査・記述した現状のレベル４業務プロセスをまだ意識する必要はない。
方法論では、業務プロセス参照モデルを利用して、業務プロセス改革要求(詳細)の業務プロセス改革区分によって、レベル４業務プロセス上の各々のプロセス構成要素に構造化する技法を利用するが、本書では説明を省略する（参考資料 A）。
【事例 A】「業務プロセスグランドデザイン」において、レベル２業務プロセスの定義の結果をレベル３業務プロセスに構造化して設計した。今度は、「業務プロセス概要設計」において、レベル３業務プロセスで定義された業務プロセス
改革要求(詳細)をレベル４業務プロセスへ構造化した。その結果を図表Ⅳ-2-5-2 に示した。
図表Ⅳ-2-5-2 事例 A：レベル３業務プロセス設計の構造化 （一部だけ記述）
73

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

階層レベル３の「RFP の入手と回答プロセス」から、階層レベル４の「RFP/RFQ の入手・確認」プロセスとそのプロ
セス構成要素への構造化は、下記のとおりである。ここでは他のレベル４業務プロセスへの構造化は省略した。
・プロセス機能：顧客要求確認シートを利用して、顧客ニーズを的確に把握して、他部門に伝達する・IT システム機能：案件情報として顧客要求をリアルタイムに共有・閲覧できる
・アウトプット:要求と制約条件が書かれた顧客要求確認シート
・業務ルール：必ず顧客要求確認シートを利用、作成する・担当責任組織・人：この業務プロセスを担当する人は、自社製品や機械技術などへのスキルが必要(3)実施手順３：現状レベル４業務プロセスの課題抽出
上位設計からの構造化とは別に、レベル４業務プロセス自体に内在する、たとえばプロセス機能の欠落や業務ルールの未整備などの課題を抽出する。ここはボトムアップアプローチで行う。
業務プロセス参照モデルを利用して、現状プロセスの調査・記述を行った場合には、両者をプロセス構成要素ごと詳細に比較することになり（いわゆるプロセスベンチマーキング）、たとえばインプットやアウトプットなど、プロセス構成要素に関する現状の業務プロセスの課題を抽出できる。
【事例 A】
事例 A では、不足しているアウトプットデータや確立していない業務ルールを抽出した（図表Ⅳ-2-5-1 右側の赤字の部分）。
(4)実施手順４：レベル４業務プロセス分析
レベル４業務プロセス分析においては、(2)実施手順２のレベル３業務プロセス設計からの構造化の実現、そして
74

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例(3)実施手順３の現状レベル３業務プロセスの課題の解決、この両方のための CSF と根本原因を正確に特定する。
この際に、CSF や根本原因が現状において欠落しているレベル４業務プロセスに位置づけられる場合がある。これが、現状プロセスの調査・記述の際に、欠落している業務プロセスを明確にしておく理由である。
【事例 A】
事例 A では、提案・受注プロセスにおいて、図表Ⅳ-2-5-3 中の sD3.02-3 契約詳細の交渉と契約書の作成、
sD3.02-4 契約書の承認と顧客への送付という２つのレベル４業務プロセスが欠落しており、これが CSF と根本原因を構成していた。
(5)実施手順５：レベル４業務プロセス設計
継続すべき現状プロセス機能を維持しつつ、プロセス分析の結果を解決できる解決策をレベル４業務プロセスとして設計し、プロセス構成要素を完全に正確に記述しなければならない。レベル４業務プロセスの設計の結果として、欠落した業務プロセスを追加した新業務プロセスフローを描き、個々のレベル４業務プロセス詳細記述書にそのプロセス構成要素を記述する。この際に、新たに追加されたレベル４業務プロセスについては、業務プロセス参照モデルを参照しながらそのプロセス構成要素を設計する。そして、IT系プロセスにおいては、インプット・ア
ウトプット説明書はデータモデル定義につながり、業務ルール説明書はアプリケーションのプログラムロジックとなる。
「業務プロセス概要設計」としては、さらに、レベル４業務プロセスの簡素化・標準化、J-SOX などのリスクコントロ
ールの(再)設計、共通ビジネスサービス化の設計などを行う場合もある。
【事例 A】
レベル４業務プロセス設計の結果として、業務プロセスフロー、個別のプロセス詳細記述書、インプット・アウトプッ
ト説明書、および業務ルール説明書を作成した。
a.業務プロセスフローの作成
ETO 品に関する設計したレベル４業務プロセスフローを図表Ⅳ-2-5-3 に示した。これには、提案・受注、商品開発、製品設計、生産準備に関するレベル４業務プロセスを表示してある。調達・製造・出荷プロセスは簡略的にレベル３業務プロセスとしてまとめて表示してある。

75

IT 経営実現プロセスの階層化アプローチの事例

第Ⅳ章

図表Ⅳ-2-5-3 事例 A：新レベル４業務プロセスフロー （一部だけ記述）
顧

RFP/RFQ

sD3.01-1
RFP/RFQの入手・確認

sD3.01-2
回答のためのリ
ソースの確保はIntegrateプロセスへ移動

sD3.01-3
提案書/見積書
の作成

提案書
見積書

注文書
回答（微調整項目）

再見積書

sD3.01-4
提案書/見積書の承認と送付

sD3.02-1
顧客の回答を入手・確認

sD3.02-2
契約制約条件
の確認

客

注文請書

sD3.02-3
契約書の作成と交渉

sD3.02-4
契約書の承認と顧客への送付

sD3.03-1
契約書・注文書の受領・確認sD3.03-4
リソース確保とプ
ロジェクト計画の策定

sD3.03-3
受注オーダの発行

sD3.03-2
前受金の受領処理

sD3.03-5
プロジェクト計画の承認と通知sD3.03-4、sD3.03-5はIntegrateプロセスへ移動

型式＝特注品番号

RFP/RFQ
顧客要求確認シート
提案仕様書

提案・受注プロセス＜商品開発部＞
dI2.1
要求の受領と確認

dI2.1-1
新商品開発要求の受領

顧客要求確認項目
＋設計部門

２次項目

２次項目

dI2.1-2
新商品開発要求の確認

dI2.1-3
受入適合基準の確認dI2.1-4
制約条件の確認

営業へ回答
dI2.1-5
新商品開発プロジ
ェクト憲章の作成

見積案件の
受付ルール

商品開発プロセス

見積書番号、特注品番号＜商品開発部＞
dI2.2
要求の分解

dI2.2-2
新商品開発要求の要素分解

dI2.2-3
新商品開発要求の
詳細化

ポ
ン
チ
絵

見積時
dI2.2-4 分解・詳細化された要求仕様のレビュー

dI2.2-5 分解・詳細化された要求仕様のリソース見積

イージーオーダ
フル設計オーダの判断ルールdI2.2-6 分解・詳細化された要求仕様のリソース調整

dI2.2-7
プロジェクト計画書の策定・承認①提案仕様書特注品差立表

原価計算表
受注時＜商品開発部＞
dI2.3
設計要求仕様の配信
イージーオーダ→福嶋工場技術Ｇ
フル設計オーダ→本社技術部
特注購買品→サプライヤ

設計変更の
受付ルール

dD2.1-2
設計要求仕様の確認

dI2.4-2 製品設計
仕様のレビュー
（対試験評価項目)③最終仕様書
④試作品

設計メンバが分担する場合に必要
dD2.1-1
設計要求仕様の受領

dD2.1-3
試験評価項目の
確認

設計基準

設計基準

dD2.1-5
設計要求仕様の要
素分解

dD2.1-6
設計要求仕様の詳細化<顧客との確認><社内>
dI2.4-1 リサーチ
仕様、製品設計
仕様の受領<イージーオーダ→福嶋工場技術Ｇ><フル設計オーダ→本社技術部>

dD2.1
設計要求仕様の受領、確認、分解

dI2.3-3
設計要求仕様の発行②設計要求仕様
中日程計画＜商品開発部＞
dI2.4
製品設計の入手と確認

製品設計プロセス

dI2.3-1
設計要求仕様の受領・検討

dI2.4-3 製品設計
仕様のレビュー
（対受入適合基準)

dI2.4-3 製品設計
仕様のレビュー
（対受入適合基準)

dI2.4-4
製品設計の確認の完了

製品設計/試作
デザインレビュー
ルール

製造、出荷プロセス

sD1.15-4
入金の確認、
請求消込

計画図
dD2.2
設計活動のスケジューリング

dD2.3
設計とデザインレビュー

dD2.2-1
分解・詳細化された要求仕様の受領、
リソース見積dD2.2-2
利用可能な設計リ
ソースの確認dD2.2-3
設計スケジュール
案の作成

諸設計ルール

設計基準と要求仕様

dD2.3-2
割当済み設計リソ
ースの準備

dD2.3-3 設計作業
・イージーオーダ・フル設計

dD2.3-4
設計のデザインレ
ビュー

設計と試作の一体的運用
本社と福嶋？
dD2.4
プロトタイプ開発

sD1.15-3
請求書の作成・送付

dD2.2-4
設計スケジュール
の選定と承認詳細図sD1.15-2
売上計上③最終仕様書
④試作品

dD2.3-6
設計の完了

sD1.14据付、試運転試作あり
試作あり
dD2.4-1
試作指示の受領

dD2.4-2
割当済み試作リソースの準備

dD2.4-3
試作品の製作と試験評価

dD2.5-2 割当済み
設計リリース準備のリソース準備

dD2.5-3
設計・試作の文書
化

dD2.6-2
設計リリースの承認

dD2.6-3
設計リリースの発行

試
作
品

dD2.4-4
試作のデザインレ
ビュー

設
計
文
書

dD2.5-4
設計・試作の文書化の評価＜商品開発部＞
dI2.7
商品リリース準備④試作品

試作と試験評価項目

技術情報の
保存ルール

dD2.5
設計リリース準備

dD2.4-6
試作の完了

⑥顧客
納入
文書

dI2.7-4
商品開発プロジェ
クトの報告書作成

dD2.5-6
設計リリース準備の完了

sM3.1-1
製品設計、生産
設計の受領

組立図
部品図
製作指示
部品構成表

福島工場
管理技術Ｇ

⑦開発工数･
費用計画対比工場で作成する
文書あり（受注生産のため？）部品表のRev
管理ルール

設計出図ルール
dD2.6-1
設計リリースの検討

sD1.12出荷（輸配送）dI2.7-2
リリースのための
文書化

⑤設計文書
dD2.6
設計リリース

参考図/提案図
制約条件
概算/詳細原価
大日程計画

部品構成表
部品図

調達日程計画と調達プロセス

sM3.1-2
受注オーダ情報との確認

sM3.1-3
製造方法の設定

sD1.11
出荷準備

sM3.1-4
製造方法の確定と通知

製造部品表（手配先、副資材、
製造工程）

特注購買品

sD1.10
仕分・梱包⑥特注品顧客納入文書
生産日程計画と生産プロセス

こ
こ
は
レ
ベ
ル
３
プ
ロ
セ
ス
で
表
記

sD3.04
据付日程の設定

b.プロセス詳細記述書の作成
業務プロセスフローに表示された個々の業務プロセスについて、その機能を正確に設計するため、プロセス構成
要素を記述した。たとえば、図表Ⅳ-2-5-3上の一番左上の丸で囲った場所に位置しているレベル４業務プロセス「RFP/RFQ(Request For Quotation)の入手・確認」に関して、図表Ⅳ-2-5-4 のように詳細なプロセス構成要素を記述した。
図表Ⅳ-2-5-4 の左側は各々のプロセス構成要素名、真中がその意味の説明、右側が当該プロセスにおける定義である。IT システム機能は、IT へのビジネス要求(詳細)が構造化されたものである。また、インプットをインプット
１とインプット２に区別してある。インプット１は、当該プロセスへの指示となる情報エンティティであり、インプット２
は、その制約となるエンティティであり、制約情報や制約条件、そしてプロダクトやリソースである。アウトプットも同様に区別してある。また、当該業務プロセスには３つの業務ルールがあり、当該業務プロセスの遂行を担当する責任組織名を記述してある。
現状で欠落している提案・受注プロセスの２個、そして商品開発の 18 個のレベル４業務プロセスに関しては、業務プロセス参照モデルに定義されているプロセス構成要素を参考に設計し記述した。

76

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

図表Ⅳ-2-5-4 事例 A：個々のレベル４業務プロセス詳細記述書 （一部省略）

c.インプット・アウトプット説明書の作成
図表Ⅳ-2-5-5 事例 A：インプット・アウトプット説明書 （一部省略）

インプットやアウトプットのエンティティに関してはその内容を明確にするために、別途、図表Ⅳ-2-5-5 のようなインプット・アウトプット説明書を作成した。最後の CRUD 区分は、当該業務プロセスにおける処理として、生成
77

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例(Create)、参照(Refer)、更新(Update)、削除(Delete)を区別したものである。
d.業務ルール説明書の作成
業務ルールに関してはその内容を明確にするために、別途、図表Ⅳ-2-5-6 のような業務ルール説明書を作成して、設計した内容を明確に記述した。業務ルールが未整備の場合は、次の「業務プロセス詳細設計」において、
この概要設計された業務ルールを詳細設計する。
図表Ⅳ-2-5-6 事例 A：業務ルール説明書 （一部省略）(6)実施手順６：業務プロセス改革計画の立案と更新
当初は、業務プロセス改革企画書に基づいて、対象範囲についての概算見積レベル(精度±10～20%)の費用を含むドラフト版の業務プロセス改革計画書を作成する。そして、この計画に基づいて業務プロセス概要設計を行って、新しいレベル４業務プロセスを定義する。これによって、次フェーズのプロジェクト計画や詳細見積レベル(精度±5～10%)の費用を含む正式版の業務プロセス改革計画書へと更新する。
この業務プロセス改革計画書によって、業務プロセス改革企画書がより具体化される訳だが、逆に、見直しが発生する場合もある。また、業務プロセス概要設計からのフィードバックの例を下記にあげる。
・「IT システムの視点」では、IT へのユーザー要求が発生する（Ⅳ-２-６で後述）。
・「人・組織の視点」では、たとえば、業務プロセスに必要な人の能力への要求などが発生する（Ⅳ-2-8 で後述）。

78

第Ⅳ章

Ⅳ-2-6

IT 経営実現プロセスの階層化アプローチの事例

IT システム計画・調達

1) アクティビティの目的「IT システム計画・調達」においては、IT システム戦略企画に対して、レベル４業務プロセスから概要レベルの IT
要求（IT へのビジネス要求と IT へのユーザー要求）を定義して、個別 IT システムに対する IT システム導入計画を立案し、調達準備を行う。
2） アクティビティの実践ポイント(1)目的達成のための実践ポイント
PGL を実際に適用して当該アクティビティの目的を達成するためには、Ⅲ-２で前述したように、下記の実践ポイ
ントを具体的に実現しなければならない。
①人間系を含んだ業務プロセス全体から IT へのユーザー要求を定義する
業務全体を連続した流れとしてとらえるため、人間系も含めた業務プロセス全体をもとに、IT へのユーザー要求を引き出して、構造化された IT へのビジネス要求と合わせた概要レベルの IT 要求を定義する。
②調達に適切な IT 要求の詳細度および記述要素を適切に規定する
ここで定義した IT 要求は、IT システム調達のためには「粗すぎず、細かすぎず」の詳細度が適切となる。そして、IT 要求の記述要素には、IT 要求が満足されたことを検収するための項目が必要となる。
③要求工学を適用する
要求工学に沿って、IT へのユーザー要求をもれなく引き出して定義する。この際に、業務プロセスから IT へのユーザー要求を引き出すための具体的な手法が必要となる。
(2)「IT システム計画・調達」の実施手順
IT システム計画・調達は、図表Ⅲ-2-3-2 に示した IT 要求の各サブモデル定義の共通的な手順に沿って行う。
実施手順１：階層レベル４での現状 IT システムの調査・記述
実施手順２：概要レベルの IT へのユーザー要求の定義
実施手順３：階層レベル４での現状 IT システム課題の抽出
実施手順４：IT 要求定義書への取りまとめ
実施手順５：IT システム導入計画書の立案と更新
3）「IT システム計画・調達」の事例「IT システム計画・調達」の実施手順について、事例を交えてその詳細を説明する。
(1)概要レベルの IT 要求の位置付け
概要レベルの IT 要求は、図表Ⅲ-2-3-2 に示したように、IT 要求の３番目のサブモデルである。レベル４業務プロセスから IT へのユーザー要求を定義するので、その詳細度は必然的に「粗すぎず、細かすぎず」という概要レベルになる。そして、IT へのビジネス要求（詳細）は、すでに「業務プロセス概要設計」においてプロセス構成要素の「IT システム機能」に定義されている。したがって、概要レベルの IT 要求は、IT へのビジネス要求が確実に構造化され、かつ IT へのユーザー要求として詳細化されたものとなる。
(2)実施手順１：階層レベル４での現状 IT システムの調査・記述対象となる個別 IT システムについて、現状の全ての IT 環境や IT サービスについて、IT システム戦略企画書よりも詳細に調査・記述する。
79

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例【事例 A】
事例 A の場合は、販売活動、商品開発、製品設計などの非定型な業務プロセスが対象となったが、これに関する
IT システムは、２次元と３次元 CAD、および汎用的な情報共有ツールが導入済みであった。
(3)実施手順２：概要レベルの IT へのユーザー要求の定義
まず、IT へのユーザー要求を引き出すためには、誰から、すなわちどのユーザークラスの代表者に質問するかが重要である。ユーザークラスには、頻繁に入力を担当しているユーザー(パワーユーザーともいう)、情報参照や入力も行うユーザー、情報参照だけを行うユーザーなどがある。そして、企業外の顧客や取引先、他の IT システ
ムもユーザークラスとなる。パワーユーザーだけから IT へのユーザー要求を引き出すと、過剰なユーザー要求が多く出てきて、他のユーザーには使われない IT システム機能になってしまうことがしばしばある。
IT へのユーザー要求はレベル４業務プロセスを基にして、選定したユーザークラスの代表者に質問して引き出し、要求工学の要求定義プラクティス（後述）に沿って定義する。すなわち、IT へのユーザー要求の引き出し、要求の分析、要求の仕様化、妥当性確認(または要求検証)、という４つの手順によって定義していく。
①IT へのユーザー要求の引き出し
後述するように、業務プロセスのプロセス構成要素と IT へのユーザー要求との間には強い関係がある。したがって、選定したユーザークラスの代表者にヒアリングでなく、レベル４業務プロセスの各々のプロセス構成要素について質問することによって、IT へのユーザー要求をもれなく引き出せる。
一つの業務プロセスごとに、そのプロセス構成要素と COBIT (Control OBjectives for Information and related
Technology) の情報要請規準12との組み合わせによって、質問項目として約 60 個を自動的に生成できる。したがって、たとえ経験豊富な要求アナリストでなくとも、この質問項目によって後述する事例 B のように IT へのユーザ
ー要求をもれなく引き出せる。
②引き出した IT へのユーザー要求の分析、仕様化、妥当性確認引き出した IT へのユーザー要求は、分析、仕様化という要求定義プラクティス（後述）の手順に沿って定義していく。妥当性確認では、ユーザーから受入適合基準を確認する。これは、ユーザー側の受入検収テストにおいて、IT へのユーザー要求を実際に満足できているかのテストシナリオになるべき重要な項目である。
③引き出した IT へのユーザー要求の優先順位付け（Ⅳ-2-7 で後述）
【事例 A】
事例 A の場合は、非定型な業務プロセスを対象として、これをいくつかのブロックに取りまとめて、ブロック単位に
アウトプットの標準化を行った。個々のレベル４業務プロセスからではなく、これをくくったブロック単位での ETO
品オーダの進捗管理と情報共有に関する IT へのユーザー要求を定義した。
【事例 B】
需給計画における「実現可能負荷計画の策定」プロセスから、IT へのユーザー要求を引き出した事例を図表Ⅳ-2-6-1 に示した。この一番左側はプロセス構成要素の名称であり、その右側は定義されたレベル４業務プロセス
詳細記述書の内容である。各々のプロセス構成要素ごとに COBIT の情報要請規準との組み合わせから作成した
右端の質問事項（一部のみ表示）によって引き出した IT へのユーザー要求が、中央の「引き出した要求」である。
事例 B では、プロセス構成要素のインプット１の「販売予測（P1.1) ＋在庫計画 （P1.2) - 供給能力計画(P1.2)」
において、下記の IT へのユーザー要求を引き出した。
・「有効な入力とは」という質問から、「需要要求と生産能力のアンバランス修正処置で何処を修正するのが最適か

12

COBIT では、情報要請規準として、有効性、効率性、機密性、インテグリティ、可用性、コンプライアンアス、信頼性の７種類を定義
している。

80

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例を判断できる情報」という要求
・「他システムからの自動入力」という質問から、「販売情報（POS)、在庫情報、生産実績などの直接入力」という要
求

81

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

図表Ⅳ-2-6-1 事例 B：レベル４業務プロセスからの IT へのユーザー要求の引き出し

また、プロセス構成要素の IT システム機能に記述された「複数の能力負荷計画の策定、シミュレーション機能」は、「業務プロセス概要設計」によって IT へのビジネス要求(詳細)をレベル４業務プロセスに構造化・反映したものである。これについて、右端の質問事項によって下記の IT へのユーザー要求を引き出した。
・様々な能力パラメータが設定できる・実行処理速度が速い（数回のシミュレーションが稼動時間内にできる）
・シミュレーション結果のバージョン管理ができる(4)実施手順３：階層レベル４での現状 IT システム課題の抽出
Ⅲ-2-3 で前述したように、IT 環境や IT サービス提供に関連する業務プロセスから、IT システム課題を抽出できる。
この場合の IT システム課題としては、階層レベル４に位置するものを選定する。
【事例 A】
事例 A の場合は、汎用的な情報共有ツールが導入済みであったが、個人ベースでの情報蓄積に留まり、組織的な情報共有には至っていない。
(5)実施手順４：IT 要求定義書への取りまとめ
82

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

こうして、概要レベルの IT へのユーザー要求の定義が完了する。これには構造化された IT へのビジネス要求(詳細)を含んでおり、概要レベルの IT 要求となる。これを IT 要求定義書に取りまとめる。
【事例 B】
図表Ⅳ-2-6-2 に IT 要求定義書の記述例を示した。方法論では、引き出した IT へのユーザー要求について、さらに８Ｗ２Ｈの観点から質問して詳細化しているため、図表Ⅳ-2-6-2 の IT へのユーザー要求は、図表Ⅳ-2-6-1
よりもさらに詳細になっている。
①IT へのビジネス要求
IT へのビジネス要求（詳細）は、「業務プロセス概要設計」によって「IT システム機能」として構造化されたものを記述した。IT へのユーザー要求が IT へのビジネス要求（詳細）とコンフリクトしていないかどうかはここで確認できる。
②ユーザー機能要求
業務プロセスをもとにユーザーから引き出した機能要求を記述した。
③非機能要求非機能要求、およびソフトウェアへの品質属性要求を記述した。
④要求発生元
ユーザー要求の発生元を記述した。
⑤受入適合基準
引き出した概要レベルの IT 要求に関して、ユーザーの受入検収のための受入適合基準として「販売・調達・生産の計画情報（データ）が一元的に管理されていること。かつ、制約条件を加味したシミュレーション結果を関係部門で共有できること。」をユーザーに確認して記述した。

83

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

図表Ⅳ-2-6-2 事例 B：概要レベルの IT 要求定義書(6)実施手順５：IT システム導入計画書の立案と更新
当初は、IT システム戦略企画書に基づいて、個別の IT システムに対してドラフト版の IT システム導入計画書を作成する。そして、この計画に基づいて、概要レベルの IT 要求を定義して、RFP によって IT ソリューションと IT ベンダーの選定後、詳細見積レベル(精度±5～10%)の費用を含む正式版の IT システム導入計画書として更新する。
下記に、その主な内容の目次例を示した。
①IT システム戦略企画の概要(Ⅳ-2-3 参照)②個別 IT システムへの IT 要求
新しいレベル４業務プロセス、IT へのビジネス要求(詳細)、概要レベルの IT 要求と優先順位③IT システム導入のプロジェクト計画の概要
プロジェクト目標（スケジュール、費用、体制）、ユーザー企業と IT ベンダーの役割と責任④主要成果物と作成方針
レベル５業務プロセス、新 IT 環境、新 IT サービス、各種 IT システム化方針（Ⅳ-2-3 で前述）、IT システムの移行などのための要素成果物
84

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

この IT システム導入計画書によって、IT システム戦略企画書が具体化される。しかし、逆に、見直しが発生する場合もある。IT システム計画・調達からのフィードバックの例を下記にあげる。
・「業務プロセスの視点」では、たとえば、コストや技術面から IT 要求の変更や縮小が生じて、設計されたレベル４
業務プロセスが変更される場合がある。
・「人・組織の視点」では、たとえば、ユーザーへの IT リテラシー教育の要求などが発生する。
4） 業務プロセスのプロセス構成要素と IT 要求の強い関係
業務プロセスのプロセス構成要素と IT 要求とは強い関係がある。したがって、非定型的な業務プロセスからも IT要求を引き出せる。以下、受注伝票の入力を例として説明する。
a.プロセス機能
インプットからアウトプットへ自動変換する機能である。受注伝票を入力して、出荷や請求のための受注データを登録する。
b.インプット１(イベントデータ)
プロセスへの指示となるインプットデータを取り込む。受注データ伝票の入力を行う際に、日付や伝票区分、受注明細などの正確性のチェックを行う。あるいは、EDI データをインプットにする場合がある。
c.インプット２(リソースデータ)
プロセス機能の制約となるリソースデータを取り込む。受注伝票の入力では、たとえば、得意先の与信限度額のチェック、商品、価格、在庫の有無のチェックなどを行う。
d.インプット(制約条件)
プロセス機能の制約となる制約条件パラメータを取り込む。計画プロセスなどの意思決定には存在するが、受注伝票の入力の場合にはほとんど必要がない。
e.アウトプット１(イベントデータ)
プロセス機能の結果としてアウトプットデータを出力する。受注番号を自動付番して、受注データをアウトプットする。そして、注文請書を発行する。
f.アウトプット２(リソースデータ)
プロセス機能の結果として消費した、あるいは生成したリソースデータを出力する。受注伝票の入力では、納期に合わせた出荷時に必要な商品の在庫数量の引当てを行う。これによって、リソースとしての在庫は減少する。
g.業務ルール
プロセスが従うべき業務ルールを示す。たとえば、キャンペーン商品については、これに参加した卸・販売店にしか販売できないことのチェックを行う。
h.担当責任（組織・人）
プロセス遂行する権限と責任を示す。受注担当者を入力する。
このように、業務プロセスのプロセス構成要素から IT 要求を質問すれば、IT 要求をもれなく引き出せる上、業務上それほど重要でない要求は出てこない。逆に、パワーユーザーから IT 要求をヒアリングすると、どのような結果になるか想像つくであろう。
5) 要求工学 (Requirements Engineering)
米国では、IT 投資の効果が上がらないという生産性パラドックスによって、1990 年代から要求工学の導入が進ん
85

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例だ。日本でも、要求工学は IT プロジェクトのトラブルを解消するものと大いに期待されている。
要求工学では、IT へのユーザー要求はヒアリングするものではなく、要求アナリストがユーザーに質問して、「要求を引き出す、要求を獲得する」というアプローチを取る。また、ユーザーが自分で気付かない要求を「発明する」ともいう。ヒアリングでは、ユーザーが自ら明示できる要求しか定義できずに、暗黙的や潜在的な要求がもれてしまうからである。
図表Ⅳ-2-6-3 に Karl E. Wiegers が提唱する４つの手順からなる要求定義プラクティス13を示した。要求の引き出し、要求の分析、要求の仕様化、妥当性確認(または要求検証)、という４つの手順をインクリメンタルに繰り返していく。Robertson 夫妻の要求定義プラクティス14もほぼ同様である。また、要求の分析と仕様化を合体させて、３つの手順とする場合もある。
図表Ⅳ-2-6-3 要求工学の要求定義プラクティス

米国では、IT システム開発・導入に際には、ユーザー企業内に PMO (Project Management Office)を設置して、IT へのユーザー要求を定義することが定着し、ユーザー要求に起因する IT トラブルはほぼなくなっているという
15。そして、ここで記述したのは狭義の要求工学であり、現在は IT へのビジネス要求の定義を含む広義のものとなっている。しかし、まだ、IT へのビジネス要求定義プラクティスはまだ確立しておらず、BABOK® という知識体系があるだけである。

13

Karl E. Wiegers「ソフトウェア要求」日経 BP 社、2003
Suzanne Robertson & James Robertson「ソフトウェアの要求発明学」日経 BP 社、2007
15
カリフォルニア州立大学ポモナ校 (Cal Poly Pomona)、一色浩一郎教授のスピーチ
14

86

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

Ⅳ-2-7 IT 要求の優先順位付け
1) アクティビティの目的「IT システム計画・調達」においては、概要レベルの IT 要求（IT へのビジネス要求と IT へのユーザー要求）をもれなく定義するだけでなく、これを優先順位付けすることによって IT 要求スコープを適切にコントロールできるようにする。
2） アクティビティの実践ポイント(1)目的達成のための実践ポイント
当該アクティビティの目的を達成するためには、Ⅲ-２で前述したように、下記の実践ポイントを具体的に実現しなければならない。
①経営面からみた優先順位付けを行う
IT 要求を出したユーザーの「声の大きさ」や所属部門長の力によって、その採否が決まることがあってはならない。
あくまで、事業戦略の実現や業務課題の解決など、経営面への貢献の度合いによって優先順位付けを行う。
②透明で合理的な優先順位けルールを決定し適用する
IT 要求の優先順位が主観的でなく、透明な方法によって決定されなければ、ユーザーの納得は得られない。そのため、事前に IT 要求の優先順位付けのためのルールとして、透明で合理的な優先順位の計算方法、そして優
先順位による IT 要求スコープのコントロールについて組織的な承認を得ておく。
(2)「IT 要求の優先順位付け」の実施手順
実施手順１：IT へのビジネス要求(詳細)の優先順位付け
実施手順２：概要レベルの IT 要求の優先順位付
3）IT 要求の優先順位付けの実施手順
ここでは、IT へのビジネス要求(詳細)および IT へのユーザー要求を優先順位付けの方法を説明する。
(1)実施手順１：IT へのビジネス要求(詳細)の優先順位付け
レベル３業務プロセスへの貢献度からの IT へのビジネス要求(詳細)の優先順位付けの方法を紹介する。まず、階層レベル１、階層レベル２、階層レベル３の業務プロセスにおいて、ビジネスモデル(事業戦略)や事業上の観点から、それぞれの重要性を設定しておく。これによって、各々のレベル３業務プロセスの相対的重要性を３つの重要性の積数として設定できる。
そして、各々の IT へのビジネス要求(詳細)について、レベル３業務プロセスへの貢献度を評価して、これにレベ
ル３業務プロセス自身の相対的重要性をかければ、IT へのビジネス要求の相対的重要性、すなわち優先順位を計算できる。
IT へのビジネス要求(詳細)の相対的重要性 ＝ レベル３業務プロセスの相対的重要性
× IT へのビジネス要求(詳細)の貢献度(2)実施手順２：概要レベルの IT へのユーザー要求の優先順位付け
前述したように IT へのビジネス要求(詳細)は、IT へのユーザー要求として詳細化される。ただし、IT へのビジネス要求(詳細)とは直接に関係しない IT へのユーザー要求もある。IT へのユーザー要求の優先順位付けの方法とし
87

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例て、IT へのビジネス要求(詳細)への貢献度を評価する方法がある。図表Ⅳ-2-7-1 に IT へのユーザー要求の優
先順位付けの方法の例を示した。
図表Ⅳ-2-7-1

IT へのユーザー要求の優先順位付けの方法①レベル４業務プロセスごとの IT へのユーザー要求の相対的重要性の計算
まずは、レベル４業務プロセスごとに、IT へのユーザー要求の相対的重要性を IT へのビジネス要求(詳細)への貢献度をもとに、以下のように計算する。
IT へのユーザー要求の相対的重要性 ＝ IT へのビジネス要求(詳細)の相対的重要性
× IT へのユーザー要求のビジネス要求への貢献度
この際に、IT へのビジネス要求(詳細)と関連のない IT へのユーザー要求は、その相対的重要性を別途、計算する。当然、IT へのユーザー要求は、それ自体の費用対効果が高ければ、相対的重要性は高くなる。そうでない場
合には、相対的重要性は低くなる。
②全体における IT へのユーザー要求の相対的重要性の集計
たとえば、「利用可能在庫の計算」のような共通的な IT へのユーザー要求は、レベル４業務プロセス上で何度も出現する。IT へのユーザー要求の相対的重要性から、全体における優先順位スコアをつぎのように集計する。

88

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

IT へのユーザー要求の優先順位スコア ＝ ∑ IT へのユーザー要求の相対的重要性
以上の方法に従えば、IT へのユーザー要求の優先順位付けによる結果はつぎのような結果になる。
・IT へのビジネス要求(詳細)へ大きく貢献する IT へのユーザー要求の優先順位は高い
・複数の業務プロセスから何度も出現する共通的な IT へのユーザー要求の優先順位は高くなる
・一度しか出現しない IT へのユーザー要求の優先順位は低くなる
・IT へのビジネス要求と関連のない IT へのユーザー要求の優先順位はさらに低くなる(3)IT 要求の優先順位による IT 要求スコープのコントロール
合理的な IT 要求（IT へのビジネス要求と IT へのユーザー要求）の優先順位付けルールは、以下のように複数のフェーズに渡って一貫して適用できるので、適切な IT 要求スコープのコントロールが可能になる。すなわち、もれなく IT 要求を引き出した上で、優先順位によって IT 要求スコープを抑制するのである。
①概要レベルの IT 要求の定義後の絞り込み時
RFP 発行前の IT システム導入計画において、予め優先順位の低い IT 要求を除外して、一定の範囲に IT 要求を絞り込んでおく。これによって、それほど重要でない IT 要求を排除できる。
②RFP 発行時
IT 要求の優先順位を RFP に記載しておく。これによって、IT ベンダーはどこに重点をおいて提案すればよいかが明確になる。
③IT ソリューションの選定時
IT ベンダーの提案について、IT 要求の充足度を単純集計しても意味はない。IT 要求の優先順位を利用すれば、加重的で精緻な充足度を計算できる。そして、IT ベンダーの提案金額によって、さらに IT 要求を絞り込むこともできる。
④詳細レベルの IT 要求の定義時
IT 導入フェーズにおいて、概要レベルの IT 要求を詳細化する際に、詳細レベルの IT 要求の優先順位として、
概要レベルのそれをそのまま採用できる。
⑥ IT ベンダーによるシステム分析時
IT 導入フェーズの IT システム分析においてソフトウェア要求仕様定義が完了した時に、通常、IT ベンダーは再見積りを行う。詳細レベルの IT 要求は、見積られたコストも考慮して優先順位を計算し直せば、どこまでの IT 要求について開発するかを決定できる。
⑥IT システム導入の開発工程における IT 要求の変更管理時
IT システム導入の開発工程において、ビジネスの変化などによって、新たな IT 要求や IT 要求の変更が発生することは止むを得ない。その IT 要求の優先順位がより高ければ IT 要求スコープに含める。そして、より低い優先順
位の IT 要求を外すこともできる。

89

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

Ⅳ-2-8 人・組織概要設計
1) アクティビティの目的「人・組織概要設計」においては、定義されたレベル４業務プロセスと概要レベルの組織モデルから詳細レベルの組織モデルを設計して、その組織機能から職務記述書を作成することで必要な人の能力を明確にして、要員能力開発計画を立案する。
2） アクティビティの実践ポイント(1)目的達成のための実践ポイント
当該アクティビティの目的を達成するためには、Ⅲ-3 で前述したように、下記の実践ポイントを具体的に実現しなければならない。
①概要レベルの組織モデルの組織機能を詳細化する
定義されたレベル４業務プロセスとその担当責任(組織・人)を基にして、概要レベルの組織モデルの組織機能について、当該組織で遂行すべき業務機能としてより詳細に定義する。
②組織機能に必要な職務能力を定義する定義されたレベル４業務プロセスを基にして、これを遂行するのに必要な職務能力を明確にして、職務記述書を作成・更新する。
③要員能力開発計画を立案する
職務記述書をもとにして、要員が職務を遂行するのに必要な能力を備えられるように、要員能力開発計画を立案する。
(2)人・組織概要設計の実施手順
人・組織概要設計は、Ⅲ-3-3 で説明したように、以下の手順で行う。
実施手順１：レベル４業務プロセスから人・組織への要求の抽出
実施手順２：詳細レベルの組織モデルの定義
実施手順３：職務に必要な能力の定義として職務記述書の作成と更新
実施手順４：組織改革計画書の立案と更新、要員能力開発計画の立案
3）人・組織概要設計の事例「人・組織概要設計」の実施手順について、事例を交えてその詳細を説明する。
(1)業務プロセス、業務機能、個人の能力と組織との関係
業務プロセスと業務機能、所属する個人とその能力、そして組織との関係について、図表Ⅳ-2-8-1 に整理した。
レベル４業務プロセスは、業務機能としての職務(図表Ⅲ-3-3-2 で前掲）に関する職務記述書を介在させることで、個人が持つ職務能力そして所属する組織と対応付けることができる。以下に職務記述書の内容の例を示す。
①責任･権限の範囲
職務として、どの業務プロセスを遂行しなければならないかが責任であり、承認なしでどこまでを単独でできるかが権限となる。
②具体的な仕事内容
担当するレベル４業務プロセスの機能そのものが仕事内容となる。職務としては、複数のレベル４業務プロセスを担当することになる。
③ 待される結果
90

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

レベル４業務プロセスに対応する組織モデルの業績評価指標について、これを職務遂行の目標として設定することができる。
④必要な能力職務としてのレベル４業務プロセスの機能から、この職務に必要な人の能力を特定できる。
④ 下の数
図表Ⅳ-2-8-1 業務プロセス、業務機能、個人の能力と組織との関係(2)実施手順１：レベル４業務プロセスから人・組織への要求の抽出
Ⅳ-2-5 で前述したように、レベル４業務プロセスはそのプロセス構成要素を記述することで、その定義が確定する。このレベル４業務プロセスから人・組織への要求を抽出できる。
①業務プロセス機能
組織が遂行すべきレベル４業務プロセスについて、その業務機能、IT システムの機能を定義してある。
②業務プロセスの担当責任組織
レベル４業務プロセスの遂行を担当する責任組織を定義してある。
(3)実施手順２：詳細レベルの組織モデルの定義
業務プロセス改革要求(詳細)を含むレベル３業務プロセスから、レベル４業務プロセスを定義する。これによって、部や課といった概要レベルの組織モデルの組織機能は、係といった詳細レベルの組織モデルが遂行すべきレベル４業務プロセスの業務機能として詳細に定義できる。
(4)実施手順３：職務に必要な能力の定義として職務記述書の作成と更新
職務記述書を作成するためには、職務に必要な能力と能力レベルを定義しなければならない。
① 業務に必要な能力の抽出
業務プロセス参照モデル（参考資料 B を参照）を利用して職務に必要な能力を抽出できる。業務プロセス参照モ
デルでは、レベル３業務プロセスごとにその遂行に必要な能力として複数のスキル（経験、適性、訓練）をリストア
91

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

ップしてある。
【事例 B】
業務プロセス概要設計によって、担当責任(組織、人)に必要な能力への要求が定義された。業務プロセス参照モ
デルを利用して必要な能力を抽出すると、「調達品の受入」プロセスを担当する担当責任（組織、人）では以下のとおりとなる。
a.担当するドメインへのスキル
たとえば、精密機械部品のように、担当する原材料や部品など調達品そのものへのスキル。
b.プロセス遂行に必要なスキル
３面からの受領確認、バーコード処理／RFID、欠陥／紛失プロダクト／不一致の報告と解決、ERP システム、在庫管理など必要な 15 種類のスキル。
c.プロセス遂行に必要なスキル詳細
たとえば、「３面からの受領確認」では、以下のスキルを抽出した。
・経験では、バーコード／RFID、EDI システム、ERP システム、財務会計、MRP（資材所要量計画）
・適性では、コンピュータ操作能力・訓練では、生産在庫管理認定資格、基礎的法的知識（輸出入禁止、環境規制）、基礎的サプライチェーン財務など
事例 B では、これを参考にして「調達品の受入」プロセスに必要な能力を特定した。そして、複数のレベル４業務プロセスを担当する職務として、これらの能力を集約した。
②職務に対応した能力レベルの決定
能力レベルに関しては、以下のような５段階での設定の方法がある。
a. レベル１：見習い
訓練されていない初心者で、経験が無いが、手引きとなる詳細な資料があれば作業ができる。
b. レベル２：初心者
限られた状況判断で仕事を行える。
c. レベル３：適任者
職務を理解して、最終目標に到達するための仕事の優先度を判断できる。
d. レベル４：熟練者
職務の全体局面を俯瞰し、状況に基づいて仕事の優先度を付けられる。
e. レベル５：専門家
職務に本質的な理解力を持ち、経験したパターンを新しい状況に応用できる。

(5)実施手順４：組織改革計画書の立案と更新、要員能力開発計画の立案
当初は、組織改革企画書に基づいて、対象範囲についての概算見積レベル(精度±10～20%)の費用を含むドラ
フト版の組織改革計画書を作成する。そして、この計画に基づいて人・組織概要設計を行って、詳細レベルの組織モデルを定義し職務記述書を作成する。
そして、職務に必要な能力と能力レベルに対して、現在の要員が保有しているそれとのギャップを埋めるために、要員能力開発計画を立案する。能力開発のための教育・訓練の方法としては、OJT、offOJT、自己啓発、ジョブロ
ーテーション、提案活動などがある。能力のうちの経験のウェイトは一般的に高いので、権限委譲によって OJT で
92

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例経験させるのは有効な方法となる。また、提案活動によって、関連する職務や仕事への関心と理解を促進させる
ことができる。
最後に、次フェーズのプロジェクト計画や詳細見積レベル(精度±5～10%)の費用を含む正式版の組織改革計画
書に更新する。
この組織改革計画書によって、組織改革企画書がより具体化される。しかし、見直しが発生する場合もある。人・組織概要設計からのフィードバックの例を下記にあげる。
・「業務プロセスの視点」では、たとえば、詳細レベルの組織モデルから業務プロセスの担当責任（組織・人）の見直しが必要になる場合がある。
・「IT システムの視点」では、たとえば、組織の権限管理に関する IT 要求が発生する。

93

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

Ⅳ-2-9 業務システムの移行計画
1） アクティビティの目的
ITシステムを導入する場合、それまでIT システムが導入されていない場合でも既存業務プロセスからの移行があり、既に IT システムが導入されている場合には、IT システムの移行が生じる。いずれの場合でも、人・組織に対して何らかの環境変化を生じることになり、新しい業務システムを導入するには、チェンジマネジメントが必要になる。
2） アクティビティの実践ポイント(1)移行計画策定の実践ポイント
問題なく業務システムを移行して目的の成果を得るために実践上考慮すべきポイントを以下に示す。
①移行のためのリソースの確保
新しい業務システムを実現するためには、既存の業務システムから大きな変化が生じるため、移行には大きなエ
ネルギーが必要である。移行を成功裏に遂行するためには、計画段階で十分な経営資源（リソース）を確保しておく必要がある。この場合のリソースとは、移行のための人員であり、移行のための期間である。これらを確保するためには資金的な裏づけも必要になる。
②事前の十分な移行計画
業務システムの移行は、無計画に実施したのではその場になって混乱を生じ成功はおぼつかない。十分すぎるほどの準備が必要である。
③三位一体を考慮した移行計画
業務システムの移行には、人・組織、業務プロセス、IT システムの３要素があるが、これらを断片的に計画したのではスムーズな移行を行うことはできない。これらの３要素は互いに影響を及ぼしあうので、三位一体で全体がうまく行くように計画しなければならない。
④現実の直視移行計画を立案する際には、理想論やあるべき論を振りかざして現実離れした移行計画にならないようにしなければならない。自組織の能力や現実の問題点を客観的に評価して、確実に実施できる移行計画を立案する必要がある。
⑤リーダーシップの発揮
組織のメンバーは変化に抵抗を示すことがあるので、移行計画は IT 経営実現プロセスの責任者が関与して、強力なリーダーシップを発揮して推進する必要がある。
(2)移行計画の実施ステップ概要①移行種類確定
最初に移行種類を選択し、確定する。移行種類とは、
a. 新業務システムの新規導入なのか、既存の業務システムからの移行なのか
b. 移行の対象範囲を一括移行するビッグバン方式か、段階的な移行かという分類のことである。
②移行期間・移行体制検討
移行種類に合わせて、移行期間や移行体制を検討する。移行が順調に行かなかった場合でも対応できるような余裕を持った計画が必要である。
94

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例③業務移行手順検討
移行種類に合わせた業務移行の手順を検討する。既存の業務システムがある場合には、既存業務プロセスと新規業務プロセスの並行運用を計画することもある。
④IT システム移行手順検討
IT システムの移行についても、既存システムがある場合には既存システムと新規システムの並行稼動を検討する必要がある。また、データの移行方法についても検討することが重要である。
⑤人・組織の移行計画立案
業務プロセスと IT システムの移行は計画するが、人・組織の計画が忘れられたり軽く見られたりすることがある。
業務プロセスや IT システムを運用するのは人であり組織であるので、移行に関する合意形成と具体的な教育の計画を立案しなければならない。
図表Ⅳ-2-9-1 に、移行計画時の検討項目を示す。

95

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

図表Ⅳ-2-9-1 移行計画時の検討項目

3） 移行計画の事例【事例 B】
ある大手日用品メーカでは、基幹業務改革のソリューションとして、従来の複数の基幹業務システムを統合してERP パッケージを導入することにした。企画から約 2 年掛けてカスタマイズ開発を行い、システム移行の直前になって移行の準備が十分でないことが分かり、サービス開始を 6 ヶ月延長した。
同社では、カスタマイズのプログラムは完成しており、結合テストまでは完了していたが、データ移行のためのマ
スターデータの準備が終わっていなかった。マスターデータが不備なため、総合テストで実データを使うことが出来ずに、テストも不十分だった。
サービス開始の延期を決定して、移行体制も強化してしっかりとした移行計画を策定することにした。延期期間中に行ったことは、①マスターデータの整備、②実データを使った総合テストの実施、③ユーザー教育の実施、④移行リハーサルの実施だった。
全社的な基幹業務をビッグバン方式で移行する場合、移行後にトラブルが多発することがあるが、同社は延期後のシステム移行・業務移行では重大なトラブルは発生せず、トラブルに備えたコンティンジェンシープランを発動することは無かった。
同社の場合、移行の直前で一旦躓いたが、再スケジュール後はしっかりとした移行計画を立てて十分な準備を行ったため、スムーズな移行を実現することが出来た。
4) 移行計画の実施ステップ詳細(1)移行種類確定
移行種類のうち、ビッグバン移行と段階的移行のメリット・デメリットは次の通りである。
①ビッグバン移行
ビッグバン移行は、移行の対象範囲を一括して移行するので、移行が完了するまでの期間を短くすることができる。しかし、移行に失敗する可能性も高く、十分な準備が必要である。
②段階的移行96

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

段階的移行では、パイロット移行部署を決めてその結果を確認しながら部署毎に移行していく方法と、業務機能毎に移行していく方法がある。移行期間中にそれまでの結果によりフィードバックをかけながら移行を進めていく
ことができるので、移行に失敗するリスクが少ない。しかし、全ての移行が完了するまでの期間が長く、移行期間
中は旧業務システムと新業務システムが混在した状態になるため、それによる非効率もある。これらの得失と自組織の能力、移行のためにかけられる期間や人員体制を考慮して移行種類を確定する。
(2)移行期間、移行体制検討
ビッグバン移行の場合は、移行期間は短くなるが移行対象範囲が広いので、短期決戦の体制で十分な人員を用意する。
段階的移行の場合は、一時的に多くの人員を確保するよりも、長期間対応が取れるような移行体制をとる。段階が進むにつれ移行に関与するメンバーが変化することもあるので、一貫した計画とそれを遂行する責任者が必要である。
(3)業務移行手順検討
業務移行には、業務プロセスの追加、変更、廃止がある。
① 務プロセスの追加
業務プロセス設計の結果、これまでに無かった業務プロセスを追加することがある。この場合、自組織には該当
業務プロセスの実施経験が無いので、詳細業務フローまで含めた具体的な検討が必要である。場合によっては事前に業務プロセスの訓練を行うことも検討する。
②業務プロセスの変更
既存の業務プロセスを変更して、新業務プロセスにする場合である。該当業務プロセスを実施する担当者は、変化への抵抗を示す場合があるので、計画段階で合意形成をしておく必要がある。
③業務プロセスの廃止
業務プロセス設計の結果、ある業務プロセスが不要になり廃止することがある。この場合、理論的に不要になっても慣習的に該当プロセスがある前提で業務が回っている場合もあるので、他のプロセスへの影響を考慮して、全体プロセスが問題なく実行されることを確認しながら移行する計画を立てる。
(4)IT システム移行手順検討
IT システムの移行手順を検討する場合には、システム移行の手順とデータ移行の手順を検討する。
①システム移行
IT システムの移行には、ハードウェアの移行、ソフトウェア/サービスの移行、ネットワークの移行が考慮対象になる。いずれの場合も、並行稼動時期があるのでその間は業務負担も倍になることを考慮しなければならない。また、新旧システムの切り替えをどうするかを十分に検討する。
②データ移行
データ移行には、マスターデータ移行とトランザクションデータ移行がある。
マスターデータ移行では、新規にマスターデータを作成する場合と、既存システムから移植する場合がある。後者の場合は既存システムと新システムの間のデータの持ち方が違う場合があるので、移行のためのデータ変換
プログラムを作成するなどの準備が必要である。また、既存システムのマスターデータが必ずしも正しいとは限らず、矛盾を抱えたまま運用していることがある。この場合は、データクレンジングと呼ばれるデータをきれいにする作業が入ることになる。このための期間や工数を見落とさないようにしなければならない。
97

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例

トランザクションデータ移行では、初期データを作成して登録する場合と、既存システムから残高データを移行してくる場合がある。残高データの移行では移行のタイミングにより不整合が生じることがあるので、不整合を回避する方法を検討する必要がある。
(5) 人・組織の移行計画立案
人・組織の移行計画には、移行のための合意形成の計画と具体的な教育計画がある。
①移行のための合意形成
業務システムの移行を成功させるためには、移行の必要性・意義・内容についての社内の合意形成が必須である。新業務システムを企画した段階から、社内のステイクホルダーを巻き込んで早期に合意形成をしておけば、後になってもめることは少なくなる。特に業務プロセスに変更が生じる部署のキーマンの合意を得ておくことが重要である。キーマンとは、該当部署で最も影響力がある人物のことである。キーマンは必ずしもその部署の長とは限らない。
②具体的な教育計画
移行のための合意が得られても、移行後の業務プロセスを遂行する能力が身についていなければ移行は成功しない。新業務プロセスに必要なスキルを教育により身につける必要がある。移行の直前は、該当部署では移行の準備のために忙しくなるので、教育期間は余裕を持って設定すると良い。IT システムの導入の際には、教育用のダミー環境を用意して、事前に十分なシミュレーション訓練ができるようにすることが望ましい。

98

第Ⅳ章

IT 経営実現プロセスの階層化アプローチの事例◆キーワード解説
キーワード項目
ITシステム業務システム経営システム
ITへのビジネス要求
ITへのユーザー要求
業務システム改革モデル

業務プロセス改革モデル

業務プロセス改革要求

業務プロセス改革要求（概要)
メタモデル
業務プロセス改革要求（詳細)

業務プロセス改革区分
オンプレミス
非機能要求項目
情報要請基準グランドデザイン
ロードマップ
マイルストーン
ITアーキテクチャ

キーワード解説Englishコンピュータ、ネットワーク、H/W、S/W、コンテンツ、
information technology system
ITサービス含めた総称(PGLのIT環境に含まれる）人・組織、業務プロセス、ITシステムが有機的で密接
business system
な関係をもつ仕組み
経営目標を達成する経営を行う仕組みの全体
このシステムは業務システムを包含する。

corporate management system

戦略の実現や経営課題の解決などのための経営面
business requirements for IT
からのITへの要求。概要と詳細の２種類がある。
ITシステムの利用者が実際にITを利用して行う必要
user requirements for ITがある業務機能のこと。
ビジネスモデル(事業戦略)を経営システムとしてどう実現するかを記述した対内的なモデルのこと。経営 business system reform model
機能別戦略によって記述される。
経営システム改革モデルを業務機能としてどう実現するかを記述したモデルのこと。ビジネスモデルの最上位のサブモデルであり、業務プロセスの最上位の business process reform model
サブモデル。業務プロセス改革モデルによって、ビジネスモデルと業務プロセスは整合できる。
現状の業務プロセスに対する改革要求。業務プロセスに対して、リソースごとに定義する。階層レベル２または階層レベル３の場合がある。現状のレベル２業 requirements for business process reform
務プロセスに対して業務プロセス改革要求を反映したものが業務プロセス改革モデルとなる。
現状のレベル２業務プロセスに対する改革要求。プ
requirements for business process reform
ロセス改革の構想書として取りまとめる場合にこれを(outline)
使用する。
所定の問題領域でのモデリングに適用可能で有益
meta-model
なフレーム/規則/制限/モデル/理論を意味する。
現状のレベル３業務プロセスに対する改革要求で、業務プロセス改革要求（概要)よりも具体的、詳細。プ requirements for business process reform
ロセス改革の企画書として取りまとめる場合にこれを (detailed)
使用する。
業務プロセス改革要求をより具体化するための区分。
segmentation for business process reform
５つの改革区分：設備・プロダクト、組織、業務ルー
ル、業務プロセス機能、人、情報と情報システム。
構築したITシステムを自社で保有する利用形態のこ
on premise(s)と情報システムが実現すべき機能への要求を支える
nonfunctional requirements item
要求項目を非機能項目という。
COBITが定義した業務プロセス目標から要求をIT目 Information Criteria (= Business Requirement in
標へ変換するための規準である。
COBIT4.0)
全体構想と言われる。広範囲且つ長期わたる図案・
grand design
着想を記述する設計図
プロジェクトマネジメント上、 目標に向かってプロジェ
クトメンバーが共有する大まかなスケジュールの全 road map
体像を指す。
最終目標達成までの中間に設定した目標をいう。道
milestone
標と訳されることもある。
情報システムの設計方法、設計思想、およびその設計思想に基づいて構築されたシステムの構造などの IT architecture
ことである

99

参考資料◆参考資料＆文献

参考資料 A:階層的４モデリング方法論
1)階層的４モデリング方法論 GUTSY-4 (ガッツィー・フォー)とはGUTSY-4 (Grand Unified Theory Synchronizing Four models) は、戦略、プロセス、IT 要求、IT システムを整合させるための方法論である。すなわちビジネスモデル、ビジネスプロセスモデル（業務プロセス）、IT 要求モデル、IT モデルを階層レベルに沿って定義（モデリング）することで、各々を整合させようとするものである。命名には物理学の世界で使われている GUT (Grand Unified Theory, 大統一理論）を借用している。
GUTSY-4 は経営から IT までのモデリング方法論として、SCM 改革、BPM、広義の要求工学を取り入れている。ビジネスアナリシス知識体系としての BABOK® を具体化したものでもある。GUTSY-4 の開発に際しては、参考となる方法論を広く探したようであるが、４つのモデルを統合するという方法論は世に存在しなかったようである。
GUTSY-4 の全体図を図表 XA-1 に示した。IT 経営実現プロセスともよく似ている。トップダウンアプローチによって４つのモデルを整合させようとすると、ほぼこのような体系になるであろう。さらに、組織の各階層からの提案をボトムアップアプローチによって融合させる。GUTSY-4 はこれを具体的なプロセス階層レベルおよび WBS(アクティビティ)によって実現している。GUTSY-４には、業務プロセス改革の一環として、人・組織の視点が入っていたが、本書ではこれを三位一体の一要素として拡張した。
図表 XA-1 GUTSY-4 の全体体系図

２)階層的４モデリング方法論 GUTSY-4 の特長
GUTSY-4 の特長は、大きく以下の点に集約できる。
①ビジネスアナリシスに対して<階層レベル１～３>
101

参考資料

・対象ドメイン全体を可視化し、鳥瞰できる「見える化」で課題や解決案を合意形成できる・自然言語の事業戦略を「構造化」して、業務プロセス改革やＩＴへのビジネス要求として定義できる・トップダウン(方針)とボトムアップ(提案)を融合できる・事業戦略や業務プロセス改革の効果を定量化できる（SCM 分野）
・階層レベルに沿う段階的詳細化によってビジネスアナリシスの品質・生産性を向上できる②業務プロセス設計と IT 導入に対して<階層レベル４、レベル５>
・事業戦略や業務プロセス改革を現場の業務プロセスに「反映」できる
・現状プロセスの調査・記述、分析、設計の品質と生産性を大きく向上できる・参照モデルを利用して、業務プロセスの統一や標準化ができる（特に、グローバルで）・人間系を含めたプロセス記述からＩＴへのユーザー要求をインタビューシートでもれなく引き出し、かつ、IT 要求スコープを４割以上、削減できる（使用されないシステム機能を事前に排除）
３)階層的４モデリング方法論 GUTSY-4 の基本コンセプト(1)コンサルティングをエンジニアリング(工学)化する
GUTSY-4 では「型」として、図表 XA-2 のような WBS・アクティビティを提示している。
図表 XA-2 GUTSY-4 の WBS

GUTSY-4 は、WBS/アクティビティにおいては、インプットとアウトプット（レイアウト例を提示）を規定するだけでな
く、技法・ツール・説明・事例として 400 近いものを提供している。
①参照モデルを利用することで、対象分野への経験・知識は最小で可能にする→参考資料 B②成果物の作成やつながりを「穴埋め」 16のようにエンジニアリング化している
16

日経 BP 社「穴埋め形式で業務分析を可能に 新手の開発方法論「GUTSY-4」を知る」日経コンピュータ 2010/12 号、pp100-105

102

参考資料

③コンサルティングのマイナス方向への属人性を排除できる
WBS/アクティビティではアウトプットを規定しているので、逆にこれ以外のどんな方法でこれを作成してももよい。
(2)相手から課題、根本原因、解決策を引き出しまとめていく「ファシリテーション」型とする① 業務プロセス参照モデル、業務プロセス図、その他の様々な図を使って相手に考えさせる② コンサルはなるべく自分の考えを言わない、ヒントは言う。
(3)IT 要求のトレーサビリティを確保できる
図表 XA-3 に、Ⅳ章の事例 A において、右端のユーザーからの IT 要求が、どのレベル４業務プロセス、IT へのビジネス要求、そして事業戦略から発生したものかを、要求管理ツールを利用して示した。IT システム機能を起点として示せば、それがどの IT 要求そしてビジネス要求から発生したものかをトレースできる。
図表 XA-3 定義された IT 要求のトレーサビリティ4)参照先

渡辺和宣 http://www.mERPi.com/

ここに本書よりも少し詳細な資料がある

103

参考資料

参考資料Ｂ:業務プロセス参照モデル
1)業務プロセスの種類
業務プロセス参照モデルに定義されている業務プロセスには、たとえば、調達から生産、そして出荷へというヨコの機能の流れがある。さらに、以下のようにタテの機能の流れがある。
a.戦略立案：全体戦略や経営機能別戦略を策定し、事業目標を確立するプロセス。
b.戦略計画：戦略から販売計画、マーケティング計画、製品計画、要員・設備能力計画、需要・供給計画などの四半期位の計画を立案、そして計画管理や業務実行を受けて必要な調整を行うプロセス。
c.計画管理：戦略計画を月次の計画に落とし込み、計画の達成状況を管理・調整するプロセス。
d.業務実行：月次計画を週や日々の計画に落とし込み、実行または支援し、管理・調整するプロセス。
業務実行にはこれを共通的に支援するための Enable プロセス（後述）がある。業務プロセスは「機能」であるため
必ずしも現在、実行されているものだけに限定、検討してはならない。このためには、業務プロセス参照モデルが有効となる。
2)業務プロセス参照モデルとは業務プロセス参照モデル（以下、プロセス参照モデルと省略）とは、業務プロセスを調査・記述、分析、設計する
際に、参照できるモデルのことである。たとえば、第Ⅳ章の事例のように、これを利用すると現状の業務プロセス
をもれなく、正確に、かつ短時間で調査・記述できる。そして、プロセス参照モデルのプロセス構成要素の内容を参照して、問題点も発見できる。プロセス参照モデルは自らを写し出す「鏡」のようなもので、それに合わせることを強要するものではない。人は自らを美しくするために、積極的に鏡を使っている。
3)グローバルなプロセス参照モデル(1)ＳＣＯＲ/DCOR
下記のように、サプライチェーンや商品開発・設計の業務領域に関するプロセス参照モデルであり、ほぼ計画管理や業務実行の種類のプロセスを対象としている。
①SCOR (Supply-Chain Operations Reference-Model)
米国 SCC (Supply Chain Council)が開発した、企業内や企業間におけるサプライチェーンに関するプロセス参照
モデルである。対象業務領域は、サプライチェーン計画、調達、生産、受注・出荷、返品・返送である。プロセス構
成要素として、機能やインプット・アウトプットだけでなく、プロセスパフォーマンスを評価するためのメトリクス（測定尺度）、そして改善のためのベストプラクティスを提示している。
②DCOR (Design-Chain Operations Reference-Model )同じく、SCC が 2006 年に発表したデザインチェーンに関するプロセス参照モデルが DCOR である。対象業務領
域は、商品開発・設計の計画、リサーチ、設計、開発統合、修正である。プロセス構成要素は SCOR と同様となっている。
③ESCORTSCOR はレベル３までしかないため、SCC 会員である(株)マネジメント&ERP インテグレーションが SCOR をレベル４へと分解・詳細化したものが ESCORT である。プロセス機能を追加、プロセス構成要素についてはインプットやアウトプットを詳細に分類、業務ルールや担当組織を記述するなど大幅に拡張した(図表Ⅳ-2-5-1 の左側)。 ま
た、DCOR の主要プロセスを同様に分解した EDCORT もある。
104

参考資料

(2)ＶＲＭ （Value Reference Model）
米国 VCG(Value Chain Group, Inc) が開発した、サプライチェーンや商品開発・設計だけでなく、販売活動や顧客サービスに関するモデルである。計画管理や業務実行のプロセスを対象としていること、プロセス構成要素は、SCOR と同様である。まだレベル４プロセスは一部だけしか定義されていない。
(3)PCF （Process Classification Framework）
米国 APQC(American Productivity and Quality Center) が開発した、プロセスベンチマーキング用のプロセス一
覧がＰＣＦである。対象業務領域は、タテの機能として戦略立案、戦略計画、計画管理、業務実行まで、ヨコの機能としてサプライチェーンやナレッジマネジメントまで含んで企業の全業務にわたっている。ただし、プロセス機
能やインプット・アウトプットなどのプロセス構成要素は定義されていないので、厳密にはプロセス参照モデルとはいえない。しかしながら、SCOR/DCOR や VRM がカバーしていない業務領域に利用できる。
PCF には、業種共通版以外に、日用品、自動車、教育、放送、 銀行、航空宇宙防衛、通信、電力、石油下流、石油上流などの業種版がある。業種版に汎用プロセス部品として SCOR・ESCORT や DCOR・EDCORT を組み合わせれば、プロセス名だけの PCF をより詳細に具体化できる。
入手可能なグローバルなプロセス参照モデルを図表 XB-1 に示した。
図表 XB-1 入手可能なプロセス参照モデル（グローバル版）

4)国内版のプロセス参照モデル
日本国内で開発されたプロセス参照モデルを図表 XB-2 に示した。
図表 XB-2 入手可能なプロセス参照モデル（国内版）

105

参考資料

以上、複数のプロセス参照モデルやそれに近いものを紹介した。しかしながら、同一の階層レベルとはインプッ
ト・アウトプットでお互いにつながっていることである。その意味でグローバル版の SCOR、DCOR、ESCORT や
VRM は厳密な同一の階層レベルとなっている。PCF が階層レベルでは厳密性に欠けていることは、PCF の目的からすれば止むを得ない。国内版は業務領域を限定して利用すればよい。
5) プロセス参照モデルのプロセス例
図表 XB-3 に見込生産品の受注・出荷に関する SCOR（階層レベル１～３）と ESCORT（階層レベル４）のプロセスを示した。そして、図表 XB-4 に見込生産のプロセスを示した。
図表 XB-3 と図表 XB-4 の右側には、業務実行に関するプロセスだけでなく、それを共通支援するための Enable
プロセスがしめされている。Enable プロセスが不十分、あるいは存在しなければ実行系プロセスに悪影響を及ぼす。Enable プロセスを定義してあることが SCOR や VRM の大きな特長である。この考えはエンジニアリング業務にも適用できる。Enable プロセスの主な機能を下記に示す。
・プロセスに関わる組織・ルールの管理のためのプロセス・プロセスのパフォーマンス測定と改善のためのプロセス、現場やサプライヤの改善指導も含む
・プロセスに関わるデータの収集と管理のためのプロセス・プロセスに必要な実在庫と在庫情報、プロダクトライフサイクルを管理するためのプロセス
・設備、要員、ユーティリティを管理するためのプロセス
・輸送設備と輸送業者の管理、ナレッジ移転のためのプロセス
・製品、技術、ステイクホルダー(サプライヤ、顧客、外注先、共同開発先）などのネットワーク要素を管理するためのプロセス
・従うべき規制要件を特定し遵守するためのプロセス
・リスクを特定しマネジメントするためのプロセス
・ステイクホルダーとの契約を管理するためのプロセス
図表 XB-3 プロセス参照モデル例(SCOR, ESCORT) DELIVER(受注・出荷)プロセス

106

参考資料

図表 XB-4 プロセス参照モデル例(SCOR, ESCORT)

MAKE(製造)プロセス

6)参照先
バリューチェーンプロセス協議会(VCPC) http://vcpc.org/

上記モデルの日本語版

107◆執筆者紹介 (いずれも IT コーディネータ)1. 執筆者紹介「ITC PGL 活用の勘どころ」ワーキンググループ
井上正和 （グループリーダー）
髙梨智弘 （アドバイザー）
小林正和 （メンバー）
山本

康 （メンバー）渡辺和宣 （メンバー）
小林寛三 （事務局）
2. 監修者紹介
平

春雄

山本米孝
前田信太郎

◆索引

Ｂ
BABOK （Business Analysis Body Of Knowlege） ....................................................................................25, 52, 86, 101
BPM （Business Process Management）....................................................................................................... 1, 16, 101

Ｃ
CSF (critcal success factor) ........................................................... 10, 12, 15, 16, 17, 21, 22, 23, 24, 32, 46, 47, 55, 75

Ｇ
GUTSY-4 (Grand Unified Theory Synchronizing Four models)........................................................................... 101, 102

Ｍ
MECE (Mutually Exclusive and Colletively Exhaustive) ............................................................................................... 16

Ｐ
PMO (Project Management Office)............................................................................................................................ 86

Ｓ
SCM (Supply Chain Management) .................................................................................................. 44, 51, 61, 101, 102

あIT 系プロセス ........................................................................................................................................16, 25, 30, 75
IT システム開発・導入 ............................................................................................................................ 11, 27, 30, 86
IT システム計画・調達 ................................................................................................................ 11, 27, 63, 79, 85, 87
IT システム戦略.......................................................................................................................................... 25, 63, 66
IT システム戦略企画.......................................................................................................11, 26, 55, 63, 66, 68, 79, 84
IT システム戦略企画書 ........................................................................................................ 26, 52, 63, 66, 79, 84, 85
IT システム戦略構想書 ..................................................................................................................................... 26, 52
IT システム導入計画書 .................................................................................................................... 27, 52, 79, 84, 85
IT システム分析................................................................................................................................................ 30, 89
IT 要求 ...................................................................................................... 26, 28, 29, 30, 79, 83, 84, 85, 87, 89, 103
IT 要求スコープのコントロール .......................................................................................................................... 87, 89
IT 要求定義書................................................................................................................................. 29, 79, 82, 83, 84

索引か
階層レベル ............................................................................................................................................................ 44

き
機能要求 ......................................................................................................................................................... 29, 64
組織改革構想書......................................................................................................................................... 35, 38, 52
業務機能粒度 .......................................................................................................................................................... 8
業務システム構想策定.................................................................................................... 10, 11, 19, 22, 26, 35, 48, 54
業務プロセス改革計画書 ....................................................................................................................... 11, 51, 72, 78
業務プロセス改革構想書 .................................................................................................................................. 10, 51
業務プロセス改革要求..................................................................................................................... 16, 19, 24, 49, 51
業務プロセス階層レベル............................................................................................................................. 6, 8, 9, 16
業務プロセス参照モデル .............17, 18, 20, 23, 31, 36, 38, 41, 46, 48, 49, 53, 54, 57, 65, 72, 73, 74, 75, 76, 91, 104

く
訓練 ............................................................................................................................................... 37, 91, 92, 97, 98

け
経営機能別戦略策定・更新 ......................................................................................................................... 10, 19, 44
経営戦略 ............................................................................................................................................................... 44
経験 ................................................................................................................................................................ 37, 91

こ構造化...........................................................................................................................15, 17, 21, 30, 45, 48, 54, 73

さ三位一体 ................................................................................................1, 4, 5, 6, 8, 9, 10, 12, 14, 48, 51, 52, 55, 94

し事業戦略 ......................................................................................................................................................... 44, 45
自動化................................................................................................................................................................... 25
職務記述書............................................................................................................................................................ 90

そ組織改革計画書.............................................................................................................................. 36, 37, 52, 90, 92
組織モデル.......................................................................................34, 35, 36, 37, 38, 48, 51, 59, 60, 61, 90, 91, 92
ソフトウェア要求仕様 .................................................................................................................................. 28, 30, 89

112

索引

ち
チェンジマネジメント ......................................................................................................................................... 37, 94て適性 ................................................................................................................................................................ 37, 91とトップダウンアプローチ ........................................................................................................................................... 17に人間系プロセス ...................................................................................................................................................... 16

ひ非機能要求................................................................................................................................................ 29, 64, 83
ビジネスモデル ................................................................................................................................................ 15, 19
人・組織概要設計 ............................................................................................................................................. 36, 90
人の能力 ......................................................................................................................................................... 37, 91
品質属性要求 ........................................................................................................................................................ 83

ふプロセス構成要素....................................................................................................................................... 17, 33, 85

ほボトムアップアプローチ ........................................................................................................................................... 17めメタモデル.............................................................................................................................................................. 34

ゆユーザークラス ....................................................................................................................................................... 80
優先順位付け......................................................................................................................................................... 87

よ
要員能力開発計画 ........................................................................................................................................... 37, 92
要求工学 ......................................................................................................................................................... 25, 85
要求定義プラクティス .............................................................................................................................................. 86
要求の引き出し .......................................................................................................................................... 29, 80, 82

113

索引

れ
レベル２業務プロセス ....................................................................................................................................... 22, 54
レベル３業務プロセス ............................................................................................................................................. 22
レベル４業務プロセス ............................................................................................................................................. 22
レベル５業務プロセス ............................................................................................................................................. 23

114

おわりに
“IT 経営実現への支援”、この言葉は IT コーディネータにとってのミッションと言える。 この想いを実現
するには、広範囲な知識と実践経験が求められることになる。
このワーキンググループが発足する１年ほど前から、“ITC PGL をより具体的にした手引書のようなものを作ろうではないか。”という自主的な研究会ができ、その後、協会のワーキンググループとして活動を続けてきた。
ガイドラインとしての PGL と実践現場を繫ぐ手引書という観点で方向性作りを始めたが、ITC のあるべき論から始まり、多様な考え方との討議でグループ分裂の危機も含みながら半年以上の激論となった。しかし、この議論が良かったのかもしれない。本書の方向性、章立てが決まった時点で、一気に原稿が上がり始めた。“分かりやすさと統一された論理的構成で仕上げること”を目標に、ITC 協会の各委員会の協力や第一線で活躍の ITC の方々の協力を得て記述表現を統一していった。
PGL をより具体的に実践を踏まえて解説することで、IT コーディネータの方々が IT 経営実現の支援をより的確で、実践力の高いプラットフォームとなることを目指した。IT コーディネータ PGL を勉強した ITCには理解しやすいレベルになったと思う。読者の方々からのさらなるご叱責、ご鞭撻を賜り、さらなる改善ができ、ITC にとって何らかの支援になれば幸甚の至りである。
特定非営利活動法人 ＩＴコーディネータ協会
PGL 実践活用 WG

「ITC のための階層化アプローチによる業務システム設計」Ver.1.0

発行日：2011 年 6 月 1 日
著作者：特定非営利法人 IT コーディネータ協会
発行者：特定非営利法人 IT コーディネータ協会〒113-0021 東京都文京区本駒込 2-28-8
文京グリーンコートセンターオフィス 9 階
電話 03-6912-1081

116

http://www.itc.or.jp/

本著は IT コーディネータ協会の著作物であり、無断引用、改変、複製、配布を禁じます。

117