2000年代の政府のEA導入の成果と教訓は何か
政府へのアーキテクチャ導入の草分けであったEAは失敗プロジェクトのように言われることがあります。しかし、得られた知見も大きいです。何が得られて何が失敗だったのか振り返ってみましょう。
なぜEAを入れようと思ったのか
当時は各地でIT調達が問題になっていました。特に、ブラックボックス化してベンダーロックインされているのが問題とされていました。初年度に1円で入札して受注し、次年度以降随意契約で初年度分も含めて回収するようなビジネスモデルが横行していました。
その中で対策として行われたのが、調達の総合評価方式における技術点重視、モダン・プロジェクト管理の導入、アーキテクチャの導入、cio補佐官制度の導入でした。
調達評価、プロマネ、アーキテクチャ、人材による総合的な調達対策です。
ここで参考にしたのが米国連邦政府のIT調達改革です。特にプロジェクト管理におけるEVM（Earned Value Management）とFEA（Federal Enterprise Architecture）に注目していました。
どうやって作ったのか
日本版EAを作るにあたっては、問題意識を強く持った経済産業省とITベンダと監査法人が中心になりITアソシエイト協議会を作り議論を行うとともに、そのサポートチームが会社の始業前に虎ノ門のスターバックスに集合して検討作業を進めていました。当時は、EA、プログラムマネジメント、プロジェクトマネジメントの3分冊が作られていましたが作成は難航しました。簡単に言えば、生産性を重視したフレームワークにするか、監査や透明性を重視したフレームワークにするかの思考の相違です。結局は、そこが決裂し、プログラムマネジメント、プロジェクトマネジメントのガイドブックはほぼ完成していましたが両方とも没になり、EAガイドブックに一本化されました。
ここでは、大手ベンダも監査視点のチームに賛同したため、全体としては透明化に重きを置いたガイドに仕上がり、2003年にITアソシエイト協議会からEA 策定ガイドラインとして公表されました。
以下が基本的なアーキテクチャの考え方です。アーキテクチャはFEAと同じく4階層モデルが採用され、業務、データ、アプリケーション、テクノロジで構成されています。
また、各層には必要なドキュメントとモデリング手法が指定され、それぞれのひな型である参照モデルを整備していく計画になっています。
モデリング手法の課題
アーキテクチャを具体化するにはモデリング手法が重要です。ここで採用されたモデリング手法を見ると、機能モデルにDMM（Diamond Mandara Matrix）、プロセスモデルにWFA（Workflow Diagram）、それをつなぐモデルとしてDFD(Data Flow Diagram)が採用されています。また、データモデルにクラス図とER図(Entity-Relation Model)が採用されています。
この当時、米国では機能モデルにIDEF０、プロセスモデルにIDEF３、データモデルにIDEF１Xが採用されていました。また、オブジェクト指向対応としてUMLが広がっているところでした。
ところが、これらのモデリング手法は難しくて行政機関では理解できないということで、機能モデルにソフトウェア開発手法ではなく単なるメモ取り手法であるDMMが採用されました。また、プロセスモデルのWFAも政府独自標準のプロセスモデリング手法として定義されました。そして機能とプロセスとデータがつながらないものをDFDで連結させています。
この日米の両者は、最終的に整備されたモデルを見れば似たような姿になっていると思うかもしれません。しかし、米国の開発はモデリングツールと統合フレームワークを使っています。一方、日本の開発は、そもそもモデリング手法が特殊なので、PowerPoint、Visio、Word、Excelを駆使してモデリングをしています。
モデリングツールを使わずにモデリングするというのはどういうことかというと、ワープロと手書き位の差があります。
モデリング手法では、既定の枠が用意され、そこに間違ったことを書くと警告が出て、一か所修正すると関連したすべての箇所に修正が反映されます。また、機能からプロセスなどがリンクしていてクリックして移動することができます。モデリング内容は画面で確認し、そのまま製造工程に引き継がれることが前提になります。
日本は、モデリングツールを使わないで開発を行ったため、プロセスモデルとデータモデルをつなぐためにDFDという追加のモデリングをする必要があり、大量のドキュメントが作られました。このため、設計に時間がかかり、大量の修正ミスが出るとともに、紙で目視確認する前提なのでレビューにも大量の時間を使いました。さらに、ドキュメントからモデルが出力できないので、設計時に設計書を書き直す必要がありました。
データの設計ではクラス図とER図ですので様々なモデリングツールがありましたが、ここでも、モデリングツールを使わずほとんどの人がPowerPoint、Visio、Word、Excelで作成していました。
このモデリングを使わないというところが致命傷でした。
なぜこのようにモデリングツールを使わないで日本のシステム開発が行われているかというと、歴史的な背景があります。欧米は如何に業務を標準化して効率を上げるか、人が変わってもそれができるようにするかという思想があります。一方、日本は、モデリングツールを使うとメモを書くとかの創意工夫ができないとか、ツールそのものが不完全であるとか、モデリングツールに懐疑的でした。
そのため、モデリングの世界は、あらゆる分野で日本は完敗しています。文書のモデリング、図面のモデリング、アニメーションのモデリング等、日本は優秀な現場を持っているにもかかわらず、優秀な現場や職人がそれを支えていたため、その知見をモデリングするところに昇華できませんでした。結果として、各分野の重要なモデラーは海外製品で押さえられています。それにAIが乗ってきてさらに苦しい状況になっています。
また、モデリングツールを使わなかったのにはもう一つの理由があります。この分野が遅れた大きな原因はソフトウェア・エンジニアリングの軽視です。昔から各ベンダは、優秀な人はフロントのサービス実装などに重点的にに配置し、品質管理などを行うソフトウェア・エンジニア部門に十分な人や予算が投入されてきませんでした。
これを象徴する事として、ベンダのソフトウェアエンジニア部門の人に言われて印象に残った言葉が3つあります。
「EAプロジェクトをやってくれてありがとう。今まで社内で全く日が当たらなかったのが注目されて、やっと様々な取り組みを始めることができる」「生産性なんて関係ない。我々は人月で商売しているのだから。」
「このエンジニアリングの社内手順書をあげるよ。わが社では活かせないから」
全て違う会社でいわれた言葉ですがソフトウェア・エンジニアリングの位置づけがひしひしと伝わってくる言葉です。
とにかく前に進もう
調達改革は急いで推進する必要があり、EA策定ガイドラインは、総務省により、「業務・システム最適化計画策定指針（ガイドライン）」という政府全体のルールに引き継がれていきます。第一版は概要を書いたものでしたが、第二版で本格的にアーキテクチャの構造やプロジェクト管理の方法を整理しています。さらに第三版でその内容を拡充し、2006年に行われた大改定ではEVM等のプロジェクト管理手法も追加しています。
このころのCIO連絡会議を見ると、山のような最適化計画が各省から報告されています。これにより各システムは透明化が図られました。また、ITコンサルは最適化計画策定という特需に沸きました。ただ、この特需は、山のようなドキュメント作成作業であり、作業には多くの若手が投入されましたが成長にもつながらず、早期に見直しが図られるべきでした。
また、大量のドキュメントを納品された府省側も、設計の基礎資料は入手できたわけですが、大量すぎてそれを読み込むことが困難でした。特に、業務改革を伴うシステム開発においては、全体感と細部を行き来しながら全体デザインを整えることも多いですが、少しの修正が全体の大幅修正につながるため、契約期間が固定されている中で柔軟に設計していくことも困難でした。
前述しましたようにEA導入は透明化をするところから始めましたが生産性の観点も必要で、その検討はガイド改定の裏で並行して行われました。機能モデルのツリーモデル化、プロセスモデルのBPMN化などが検討され、データモデルも含めモデリングツールの導入を検討しましたが、2006年の業務・システム最適化指針改定のタイミングに合わずに改定できませんでした。そのため、業務・システム最適化指針が2014年に廃止されるまで、日本政府独自のモデリング手法が踏襲されることとなりました。
EAの導入初期の成果と教訓
ここまでで中間的に導入期における成果と課題を整理してみましょう。
成果
ブラックボックスだったシステムが、機能やファイルまで見られるようになった。
仕様作成がきちんと行われるようになった。
全体としてコスト削減になった。
教訓
透明化と生産性の両立が重要である。
モデリング手法を前提としないアーキテクチャ管理はあり得ない。
モデリングはツールが豊富にある国際的に通用する手法を選択する。
手法の改善を継続的に行っていく必要がある。
コスト削減については定量的な評価が行われ、効果があったと会計検査院から報告が行われています。これらの効果は、単体のプロジェクトを精査したことによる予算の適正化と無駄の削減です。
教訓にあるように、今後、アーキテクチャを推進するには、国際的視点を持ってモデリング手法を選定し、活用していく必要があります。この教訓はすでにアーキテクチャ設計に生かされており、以下のノートに取り組みを整理しています。
法律・制度との闘い
EA導入時の思いとして、これはシステムの改革ではなく業務の改革なのだという思いが強くありました。その思いが、「業務・システム最適化」という言葉に表れています。業務の中に法律や制度も含んでいます。しかし、当時は、制度側でそこまで考えている人は少なく大変苦労をしました。制度所管組織が制度変更をなかなかしてくれないため、システム側でカスタマイズをせざるを得なくなりプロジェクトが肥大化、複雑化してリリースが大幅に遅れたプロジェクトもあります。
BPRをしてからシステム化をするべきというのはその通りですが、法律や長年培ってきた観衆を変えるというのは並大抵の努力ではできません。
法律・制度の変更に関する成果と教訓
法律・制度の変更に関する成果は、とにかく法律・制度の見直しを並行して行わないとシステム改革が破綻するということです。
ただし、最近になってやっと制度も変えなければいけないという機運が生まれてきました。押印の見直し、氏名ヨミガナの検討等の日本の制度の基幹にかかわるところも見直しがかかりつつあります。
デジタル化の進展、世論、政治の後押しなどにより、見直さないのがおかしいという機運を作っていくことが重要ではないでしょうか。
アーキテクチャによる横串の改革
個々のシステムの透明化やコスト削減に効果があることはわかりましたが、アーキテクチャをもっと大きな視点でとらえる必要があります。
建築物でもコンピュータでもアーキテクチャを使うことで、レイヤーやインタフェース等が明確化し、共通基盤整備や様々な部品やサービスの組み合わせがやりやすくなります。
EAプロジェクトでは複数プロジェクトを比較して共通サービス化する検討を取り組み当初に行いました。人事給与や旅費などの主に府省のバックエンドのサービスの共通化プロジェクトがそれです。この共通化プロジェクトのターゲット選定の過程で知られていないのが、政府全体の大規模業務・システム調査です。後述するBRMという業務分類を使って、全府省に対して、どのようなサービス（業務）やシステムを持っていて、いくら予算を使っているのかの調査をしています。
ここでシステムではなくサービスを調査したのは、システム化の潜在需要を調査するためです。例えば、届出業務を調べようとしたときにシステム数は3しかなかったとしても、手作業で行っている部門が数十部門にわたることが考えられたからです。
結果として府省共通システムは、だれでも共通化したらよいと考える人事などの当たり前のシステムが選ばれています。
しかし、この調査で実現したかったのは府省、サービス横断の新サービス創出や見直し、類似システムの統合、連携という抜本的な改革でした。例えば環境という業務区分でどのような業務やシステムがあるか調べることで、それを連携した付加価値の高いサービスができるのではないかという考え方です。
米国政府は予算要求で業務区分を使った査定を実施しており、そのようなものを当時は目指しました。
調査では、○○分野であれば、関連サービスが50あり、そのうちシステムが12システムあり、5府省が関連しており、年間120億円使っているという情報が整理されました。さらに、システムが多い分野や予算額が多い分野は、そこで想定されるサービス案、民間や海外政府の事例の整理を行っています。この整理は重点的に行われました。
その調査結果は、報告を聞いた担当者が「全く評価しない」と判断し、窓口の担当者の無理解によりプロジェクトが失敗する典型的なパターンにはまり日の目を見ませんでした。所属部門にも「あの調査は無意味であった」と結果の共有もしなかったと後から聞きました。
しかし、その当時の検討結果の資料を数年後に見た人のほとんどが、当時としては革新的プロジェクトであり、政府全体のマネジメントに使うべきだったと評価しています。
この調査の中で、コンポーネントレベルや機能サービスレベルの共通化も検討されましたが、その結果も同様に活用されませんでした。
アーキテクチャの横串活用の成果と教訓
アーキテクチャの横串活用のこれまでの取り組みを、成果と教訓として整理してみましょう。
成果
業務分類や機能分類による共通システム管理が有効なことが分かった。
業務分類や機能分類による共通システム管理の手法が整理できた。
利便性とコスト削減に寄与することが分かった。
教訓
アーキテクチャが理解できない人にプロジェクトを任せてはいけない。
取り組みには透明性が必要である。
この結果から言えることは、業務分類や機能分類が重要なことです。後述されるようにサービス・カタログのプロジェクトとして現在推進がされています。また、この政府内の全システムを整理する取り組みは、デジタル庁が今後実施するシステムの一元管理に先行した取り組みとして参考になります。このような機能や予算による整理と今後強化していくITdashboardを組み合わせて推進していくことで、透明で適正なIT投資が実現できると考えられます。
一方、米国政府も、これらの取り組みに先行しながらまだ方法論を模索しています。諸外国の取り組みとも連携しながら、最適な方法を検討していくことが重要です。
リファレンスモデルの活用
アーキテクチャを導入しろと言われても、多くの人が「取り組むのが難しいのではないか」と感じると思います。そこで、アーキテクチャでは参照モデルが使われます。聞きなれた言葉でいうと「ひな形」や「テンプレート」です。
EAプロジェクトでも、2004年にリファレンスモデル・プロジェクトが行われました。
業務分類とプロセスのひな型を示すビジネス・リファレンスモデル（BRM）、KPIのひな型を示すパフォーマンス・リファレンスモデル（PRM）、データのひな型を示すデータ・リファレンスモデル（DRM）、共通コンポーネントを示すサービスコンポーネント・リファレンスモデル（SCRM）、技術仕様書のひな型を示すテクニカル・リファレンスモデル（TRM）の５プロジェクトです。
ビジネス・リファレンスモデル（BRM）は、現在進行中のプロジェクトでいうところのサービス・カタログとIT投資一元化です。行政で行っているサービス分類を策定し、各サービスやシステムを分類します。そうすることで、投資を分類して管理したりサービス連携を検討することができます。
パフォーマンス・リファレンスモデル（PRM）はKPIのひな型群で、現在は類似のプロジェクトはありません。KPIは各プロジェクトで思い思いにつけているので全体としての共通的な評価指標は予算額くらいしかありません。しかし、体系的にKPIを使うことで、複数サービスを共通軸で評価することができるようになります。
データ・リファレンスモデル（DRM）は、現在進められているデータ戦略のデータ標準部分が相当します。当時は、府省のデータ標準を既存保有データをベースに解析したのですが、既存データの関連性が複雑で実用レベルに至りませんでした。
サービスコンポーネント・リファレンスモデル（SCRM）は、コンポーネント分類を作成しました。現在検討が進められているデータ連携基盤や公共サービスメッシュに近い取り組みです。しかし、システムの内部構造的な部分であり実用に至りませんでした。
テクニカル・リファレンスモデル（TRM）は、現在は類似のプロジェクトがありません。技術に詳しくない人も技術の仕様書が書けるように、様々な技術要素の仕様書のパーツを作りました。仕様の曖昧性や検討不足を防ぐことができて非常に有効でした。ベンダも、この仕様であればこの製品ですとリストを作り、導入当初は仕様書作成に活用されましたが、対応範囲を拡大していくうちにメンテナンスが十分できなくなり使われなくなってしまいました。
これらのリファレンスモデルは、IT投資管理とも相性が良く、一緒に検討が進められましたが、経済産業省での試行にとどまり、一部先進自治体での施行までは行いましたが、政府全体には普及できませんでした。政府全体としては、個別の業務・システム最適化計画の推進で手いっぱいであり、アーキテクチャの全体俯瞰まで手が回りませんでした。
リファレンスモデル活用の成果と教訓
リファレンスモデル活用のこれまでの取り組みを、成果と教訓として整理してみましょう。
成果
業務分類、機能分類の有効性を証明できた。
業務分類を使った業務改革の可能性を検証できた。
成果指標を構造化する有効性を検証できた。
データモデル標準化の重要性を整理することができた。
技術仕様書のひな型化は、調達効率化と高度化に有益であった。
教訓
政府全体でリファレンスモデルを推進する意思が必要である。
政府全体の方針にしないと、どんなに良いものを作っても普及できない。
全部を作るのではなく、コア部分を定着させることが重要である。
現在、アーキテクチャは、Society5.0リファレンスアーキテクチャを使い、データモデルに参照モデルを用意する等、やっと当時の思想に時代が追い付いてきました。サービスカタログもベータ版で公開しましたし、SCRAとしてはデータ連携基盤の整備が進んでいます。しかし、PRMとTRMは有益なことはわかっているのですが承継するプロジェクトがありません。今後、検討していくべきではないのでしょうか。
アーキテクチャ導入で再スタートを切った日本
2002年から2005年まで盛んに行われたEAプロジェクトは様々な成果を上げたものの、アーキテクチャに積極的でない人たちも一定数いていて、いったん下火になりました。アーキテクチャを理解をする以前に、EAの大量のドキュメントや作業に忙殺され、アーキテクチャそのものに懐疑的になっている人達です。導入方法を改善するべきという意見は何度もあげられたのですが、2014年に見直しが行われることとなり、12月に業務・システム最適化計画策定指針（ガイドライン）が廃止され、「政府情報システムに関する整備及び管理に関する標準ガイドライン」に代わりました。その後、このガイドラインは「デジタル・ガバメント推進標準ガイドライン」へと進化していきます。最適化ガイドラインから標準ガイドラインへの移行の最大のポイントはアーキテクチャをベースとした推進からプロジェクト管理を中心とした推進への転換です。
一方、米国ではアーキテクチャ思考が定着したこともあり、2013年頃にはFEAも目立った更新がされないようになりました。ただし、2010年にもっと詳細化されたアーキテクチャとして国防総省のアーキテクチャのDoDAF2.02（DoD Architecture Framework）が公開されており、さらに、実装部分にフォーカスして、ミッションとプロセスとデータを重視したBEA（Business EA）も推進されています。
ここではモデリング手法が詳細に定義され実装ベースの推進が行われています。（当然、市販ツールが豊富なモデリング手法が使われています。）
欧州ではインタオペラビリティを重視したEIFを2010年に公開していましたが2017年にその延長としてEIF2.0を公開しました。インタフェースと運用を重視したアーキテクチャです。データを中心として取り組みを進め、制度やプロセスへ取り組みの幅を進めています。
世界ではアーキテクチャの詳細化と簡易化という2つの流れと、制度も含んだ大きな枠組みに展開していく中で、日本はいったん立ち止まって再スタートを切ろうとしています。
2018年にSociety5.0参照アーキテクチャとして最新化されたアーキテクチャの推進が始まり、2020年のデジタル庁検討に合わせてアーキテクチャの試行が始まっています。また、「デジタル・ガバメント推進標準ガイドライン」の標準ガイドライン群の中にデータのリファレンスモデルが位置付けられており、ガイドライン自体はプロジェクト管理中心ですが関連ドキュメントの一部としてアーキテクチャの検討が行われています。
自治体でも、システム標準化の取り組みが行われているところであり、今後もアーキテクチャ思想は重要な位置づけになっていくと考えられます。
そのために、このような過去プロジェクトの評価、最新アーキテクチャ手法の検証が重要になります。
今後に向けて
これまでのEA推進を簡単にまとめると、ブラックボックスを可視化したのとアーキテクチャ思想を明確にしたというのは大きな功績です。一方で大量の紙の作成と再利用が困難という生産性の低さが課題でした。
しかし整理してみると、システムの調達の見直し、システムの一元管理、プログラム管理、データ戦略など現在の取り組みの参考になる事項がたくさん含まれています。
今振り返っても当時はかなり先進的な取り組みでした。今後の改革を最短コースで実施していくためにも、この知見はぜひ活用していきたいものです。
この記事が気に入ったらサポートをしてみませんか？