ようやくEA導入プロジェクトの進め方について合意を得られた。ただし，実際のプロジェクトが始まる前に，あえて実施したアクションがある。それは，表1のような一覧表を作成し，A社のメンバーと合意したことだ。
表1●期間の制約を踏まえた進め方の方針
|
この表は，「検証対象範囲の網羅性」や「現状調査の詳細度」といった項目を挙げ，その選択肢（オプション）ごとに期間への影響度を示したものだ。例えば検証対象範囲の網羅性が「高い」と期間への影響は「中」，現状調査の詳細度が「高い」と期間への影響は「大」といった具合だ。
3カ月という期間では，ベストプラクティス通りに現状（AS-IS）とあるべき姿（TO-BE）の成果物をすべて作成するのは不可能に近かった。だがユーザーは，できるだけ多くの成果物を要求するのが常である。「大風呂敷を広げたら失敗する」。そう思った筆者は，スコープと期間のトレード・オフの関係をきちんと示し，A社と合意しようとした。「採否」に○が付いているものが，最終的に落ち着いたところである。
プロジェクトのキックオフに当たっては，もう一つ以下のような副次的な目的も追加した。
- EAのフレームワークを活用し，システム構築を伴う本格的なEA導入の可能性を検証する
3カ月のEA導入プロジェクトは，システム構築を伴うものではない。そこで，システム構築を伴う本格的なEA導入プロジェクトにつなげるという意味合いを持たせたのである。
検討テーマの原案を作成するために，A社のメンバーからアンケートもとった。その結果，最初のアンケートでは，20を越える課題が浮かび上がった。そこから同様の課題を集約し，検討価値について議論した。最終的に残った検討テーマには以下のようなものがある。
（1）全社DB体系の一元化
（2）統合販売生産計画
（3）プラットフォームの方向性
（4）アプリケーション構造
システム構築を伴うプロジェクトにつなげる
ここまでが，EA導入プロジェクトの提案に際して，筆者が奮闘した経験である。実際にはここから，3カ月間のEA導入プロジェクトが始まった。3カ月間で約20回のセッションを実施。メンバーの出席率も高く，議論は白熱した。各セッションごとに目標としていた結論について合意形成できた。
何よりも，木村部長がほぼ毎回出席してくれたことが大きい。上記（3）のようなインフラ寄りのテーマは優先順位を落としたので，深いディスカッションまでできなかった。それでも何とか3カ月間で検討を完了。無事，報告書をまとめることができた。
そして，システム構築を伴う本格的なEA導入プロジェクトにもつなげることができた。A社はその後，統合DBやSOA（Service Oriented Architecture）への取り組みを開始。まもなく成果を上げつつある。
最後に，今回のEA導入を経験することによって得られた三つの教訓を挙げて，本特集を締めくくろう。
| その1： | ベストプラクティスをそのまま用いるのではなく，ユーザーの要求，期間や体制といった制約に基づき，実施可能なアプローチにアレンジすることが大事である |
| その2： | 特にスコープや検討対象に当たっては，あらかじめユーザーと合意形成し，むやみに大風呂敷を広げてはいけない |
| その3： | スポンサーとなる上位マネージャの参画によって，検討対象ごとに結論を明確化し，全員で共有することによって着実な進行が可能になる |
|
