（前回からの続き）
EAガイドラインは260ページを超える大作なのですが、実はそのうちの半分をドキュメントの書き方で占められています。ページが多く割かれている分、かなり詳細にわたって記述されていますので、EAガイドラインに従えばドキュメント生産をどんどん進めていくことができます。
それ以外にもEAガイドラインには、EAによる改善サイクル（EAプロセス）を回すことが重要である旨がしっかりと謳ってあります。つまりドキュメントは一度きり書くのではなく、その内容が陳腐化するのを防ぐために常に改善サイクルを回しつつメンテナンスし続けることをガイドラインは求めているのです。
ところが、です。ドキュメントの書き方の詳細さに比べて、肝心の改善サイクルをどうやって回すのか、という具体的方法の記述が圧倒的に足りません。EAをサポートする強力なツールや方法論が無ければ改善サイクルを回すことなど不可能なのですが、その点については「EAにおいても標準的なツールの提供が望まれる」と他人ごとのような書き方で済まし、現場に改善サイクルの回し方を委ねてしまっているのです。
この時点でEAガイドラインを読んでできるEAはドキュメントを書くところまで、という状況が出来上がります。
更に霞ヶ関で設けられた制度がこれに追い討ちをかけます。霞ヶ関における主だったシステムの更改には”EAの実施”が義務化されたのです。そしてこの義務を果たさなければプロジェクトは次のフェーズに進むための予算が下りないという制度が導入されました。これは一見すると国の機関が率先して全体最適に取り組む、という素晴らしい話に見えます。ですが残念なことに、ここでいう”EAの実施”はまさに”ドキュメントを作るところまで”だったのです。
するとお役所的な発想でこの制度が次のように解釈されます。
「ドキュメントさえ作ってしまえば、プロジェクトは次のフェーズの予算を獲得できるのだ。」
このような経緯から各省は一斉にドキュメント生産に走り出したのです、それもEAという大義名分のもとに。彼らにとっては予算獲得のため活動です。予算を獲得したら、プロジェクトは次のフェーズに進み、改善サイクルは回らないままEAは終了してしまうのです。
こうして霞ヶ関における”EA＝単なるドキュメント生産活動”という図式が出来上がってしまいました。
ここまで好き勝手に書いてきましたので、多少デフォルメした箇所もあります。誤解のないよう補足しますが、霞ヶ関で行われたEAプロジェクトも全てが悲劇だったという訳では決してありません。中には粛々と進められ、無事にシステムの刷新を済ませたという案件もいくつもありました。
筆者がここで言いたいのは、もっとEAの本質を正しく捉え、正しく実践するための具体的な手法が世に示されていたならば、EAも悪者になることなく、企業や行政機関が当たり前のように取り組む価値ある活動として定着していたのではないか、ということです。そしてそのような世界が出来上がっていれば、EAに携わった現場の人々の苦労や経験が、その価値ある活動の中で活かされることでその人の糧にできていたかもしれないのです。
当時の某省庁の大変偉い方がこんなことをつぶやきました。
「EAのドキュメントを修正したいんだが、どこまで修正していいのか見当もつかないから手出しできないんだ」
ちなみにその方はEAガイドラインの策定に携わり、そこにしっかりと名前が刻まれている業界の大御所です。
悲劇を巻き起こした犯人は、決してEAではないのです。
（EAが巻き起こした悲劇 完）
※前回までのリンク
EAコラム(1) みなさん元気にEAやってますか？
http://www.ariscommunity.com/users/hide-char/2010-08-25-ea-1-ea
EAコラム(2) EAが巻き起こした悲劇 ①
http://www.ariscommunity.com/users/hide-char/2010-09-03-ea-2-ea
EAコラム(3) EAが巻き起こした悲劇 ②
http://www.ariscommunity.com/users/hide-char/2010-09-07-ea-3-ea
