![見出し画像](https://assets.st-note.com/production/uploads/images/55358821/rectangle_large_type_2_d9bf47f640f4caa213adf6c58baccb86.png?width=1200)
アーキテクチャを徹底的に使い倒す
政府内ではいくつのの戦略や政策が並行して検討されます。長文の文書を相互に参照しながら整合性を取りながら進めていくのですが、戦略の目的により章立てなどの文書構造も違い、複数戦略を相互に参照し抜け漏れなく作るのは非常に難しい作業です。そこで、Society5.0のアーキテクチャを使って戦略の整合性を取る取り組みを試行してみました。プラットフォーム整備に向けてブレイクダウンもしています
そもそも、Society5.0のアーキテクチャって何?という人は、以下のnoteを見てください。
データ戦略策定でのアーキテクチャの活用
そもそもデータ戦略は、分野横断また各分野の戦略を整理するためアーキテクチャベースで検討が行われました。関連政策をアーキテクチャを使って分析して、各分野で必要な取り組みを明確化し、抜け漏れがないかなどの確認をしています。
また、世界各国のデータ戦略とアーキテクチャを使って比較し、検討項目の抜け漏れをグローバルな視点から整理し、さらに、日本の優位点などの検討もしています。
このようにアーキテクチャを使って戦略を作ったため、戦略に書ききれなかった点も含め、論点が明確になっています。
戦略に書かれていない詳細レベルのことなどは、関係者がきちんと状況を把握しているということが重要です。
2020年12月に公表した3つの戦略類
そして2020年12月に、このようにアーキテクチャをベースに検討した「データ戦略タスクフォース第一次取りまとめ(76ページ)」が公表されました。同時に、デジタル庁の方針である「デジタル社会の実現に向けた改革の基本方針(本文18ページ、別紙51ページ)」、デジタルガバメントの今後の方向性である「デジタル・ガバメント実行計画(全体335ページ)」が公表されました。これらは、内容は相互に密接に関係しています。
480ページの3つの文書を比較して関係性を整理するのは大変です。そこで、データ戦略のアーキテクチャがありますので、折角ですのでその軸をもとに他の2つの戦略を整理してみました。
左の縦のブロックが「デジタル社会の実現に向けた改革の基本方針」、真ん中の縦のブロックが「データ戦略タスクフォース第一次取りまとめ」右の縦のブロックが「デジタル・ガバメント実行計画」です。少しづつフォーカスするポイントが違っていながらも、相互に連携しています。
組織や業務・基盤のレイヤーを拡大すると、以下のように関連性を整理しています。
デジタル庁全体の中でデジタル人材について検討していて、データ戦略の中でさらにデータ人材をブレイクダウンしています。また、デジタル庁全体の中でeGovやマイナポータル等のフロントエンドをUI/UXとともに検討していて、データ戦略ではより専門的でフロントエンドを支えるカタログサイト群の整備を検討しています。
このように整理することで全体像や役割分担が明確になります。
さらに海外のモデルと再検証
全体が整理できたところで、再度、プロジェクトベースで海外の取り組みを整理し、抜け漏れの確認を行っています。
![画像9](https://assets.st-note.com/production/uploads/images/55968178/picture_pc_5818868242a54794b531f4e7f22e3a39.png?width=1200)
分野横断の検討に威力を発揮
データ戦略は、分野別や分野横断のプラットフォームの検討をしていくので、ここでアーキテクチャを活用しています。これまでは、各分野の担当部門に取り組み状況を示してくださいとお願いすると、バラバラなフォーマットで、ルールについて説明する人やシステムばかり説明する人がいるなど全体を俯瞰して整理するのが困難でした。それを、下図のように他分野との関連性を整理するとわかりやすくなってきます。縦軸にアーキテクチャ、横軸に各分野を並べると、様々な分野でPDSを検討していることが分かります。バラバラと整備すると、コストもかかるし、将来のPDS連携もできなくなってしまいます。しかし、PDSの基本的要件やモデルを共通的に考え、各分野で考えている要件との差分をフィードバックする等の方法で検討を進めることで、重複や祖語なく効率的に検討を進めることができます。またデータ標準も、基本モデルを共通的に作り、それを各分野で拡張するという形をとることで、分野横断での相互運用性が高まるし、開発コストも削減することができます。
このような簡易なモデルで、まずはアーキテクチャの重要性や有効性を理解してもらうことが重要です。ただ、これを詳細化するだけでは議論はその先に進めません。そこで、先行する分野で全体アーキテクチャを具体化していくことが重要になります。下図のようにモデル化していきます。
これだけではなかなか進められない
しかし、突然、モデルですと図を示されても、検討が進んでいることはわかりますが、内容までわかってもらうのは大変です。
やっぱりもう少しかみ砕いて書くこととしよう
このようにアーキテクチャの詳細化モデル化を進めるていましたが、一方で、データ戦略タスクフォースの第一次取りまとめを踏まえ、6月に再整理したデータ戦略をまとめていく必要がありました。そのために、専門的なモデリングの議論は補足資料として置いておいて、いったん、みんなが慣れ親しんだパワーポイントに戻っています。そして、データ戦略タスクフォース(第6回)の資料で、以下のようにアーキテクチャを使った検討方針を示しています。
さらに関係府省と議論することで、データ戦略タスクフォース(第7回)で以下のように詳細化を図っています。
アーキテクチャの詳細化も水面下で推進
パわ^ポイントで取りまとめをする一方で、アーキテクチャの有効性の認識が広がってきたこともあり、ゴリゴリとモデリングの検討も進めました。アーキテクチャの記述には、アーキテクチャモデリング言語のArchiMate🄬を使っています。理由は、「パワーポイントやエクセル上でアーキテクチャを記述する日本の悪習から脱却するため」「アーキテクチャ作成の効率を高めるため」「国際的に議論できる形でアーキテクチャを記述するため」です。
このため苦労たのが、記述、活用方法の習得です。国内にはArchimate🄬に関する書籍は、2016年に出た「現代エンタープライズ・アーキテクチャ概論 - ArchiMate入門 」の1冊しかありません。既に5年前に出た入門書ですので、これを参考にするのではなく、海外から直接知識を習得する道を選択しました。EIRA(European Interoperability Reference Architecture)を参考にしつつ、Youtubeの教材を見たり、Mastering Archimate - Edition II(ハードカバーの図鑑みたいな本)で補完しています。
そしてIPAのデジタルアーキテクチャ・デザインセンター(DADC)と協力してアーキテクチャ作成の試行をしています。その中で、上記の参考資料ではわかりにくいところがたくさん出てきました。
品評会や勉強会をやってみた
2021年3月に、政府CIO補佐官、IPA・DADC、IT室で、メンバーが作成した各分野のアーキテクチャを模造紙大に印刷して比較検討会を行いました。このパーツはこう使ってみたとか、リレーションの使い方が悩ましいとか課題を共有し、それを踏まえてArchiMate🄬の簡易マニュアルを作成しています。
そしてさらに検討を重ねて、6月に政府CIO補佐官、IPA・DADC、IT室、経済産業省で勉強会をして、アーキテクチャ策定プロセスやツールの在り方も含めて議論しています。また、データ標準がルール層でデータと離れていると書きにくいので、データ層の下に記載するようにする等の工夫もしています。
これらも踏まえてArchiMate🄬の簡易マニュアルの改善も行い。記述方法等の意識がメンバー全員で大体あってきました。EUのインタオペラビリティ確保を目標としたガイドよりももう少し使えるパーツを増やして、ArchiMate🄬をフル活用すると記述できるシステム実装レベルの記述は省略した中間的なレベルを目指しています。
記述ルールが決まると量産ができるようになりますので、データ戦略の各プラットフォームについてアーキテクチャの詳細化に取り組んでいます。
全体設計の流れも明確になってきた
表記の方法を固めていく中で、アーキテクチャの設計方法も見えてきました。まずは、関係資料を集めてきて、最上位レイヤである戦略というか目的の明確化をし、資料に出てくる業務内容やWebサービスなどを明確にしていきます。そのうえで、データもわかる範囲で記述していきます。それを機能などに細分化していくことで大体のアーキテクチャの骨格が書けます。その上で配慮や変更をしなければいけないルールを記載していきます。組織やアセットは備忘録的に最後に書くことが多いです。各要素間のリレーションは、関連する要素をまとめて書く時にはその時に記述することもありますが、プロセス化のレベルではなくアーキテクチャレベルの時には、後からまとめてリレーションを追記していく方法が効率的に感じます。そして、ギャップやノートを付加していきます。
またいつ時点のアーキテクチャを書くかというのはアーキテクチャを書く上でいつも議論になります。現在は目指すべきToBeベースで記述して、AsIsは記述せず、その差はギャップで記述しています。
ブレイクダウンが必要になってきた
全体像から話をしていくと、「申請の改革重要だよな」とか、「PDS重要だよな」という議論まで来たところで議論が足踏みすることが多いです。それは、そこから下の具体的な現場に近い内容に関する知見が不足しているからです。問題の所在はわかるのだけど、具体的にはどう解決しようかわからないから専門家にお願いして検討してもらおうかという外注的な流れになりがちです。
そこを自分たちで一歩踏み込むことで、圧倒的に良いものができるようになります。
また、アーキテクチャのモデリングにはArchiMate🄬を使っていますが、それをブレイクダウンするプロセスモデリングにBPMN、データモデリングにUMLクラス図を使っています。こうすることで、手順レベル、データ項目レベルの課題などを明確化することができます。
ツールの検証
モデリングするためのツールの検証も行っています。Enterprise Architectですべての図は書けるのですが、専門ツールのほうが使いやすかったり、無料ツールのほうが普及しやすいので、組み合わせて使っています。将来的にはモデリング間の連携なども考え統合ツール一本で行きたいのですが、当面は様々なツールを評価しながら進めていきたいと思います。現在使っているツールは以下のものです。
ArchiMate🄬:Archi(無料版)
BPMN:Bonita(無料版)
クラス図:Enterprise Architect
クラス図も無償ツールがあるのですが、機能が不足しているため有償版を使っています。
今後に向けて
こんな感じでアークテクチャを使って様々な検討を進めているのですが、もっと普及していくためには専門家の確保が重要です。しかし、国内に1冊しか本が出ていないくらいですから、ガイドや取り組みの流れを公開して人材の裾野を拡大していくことが重要と考えています。
また、以前政府で推進した4階層のアーキテクチャモデルもよく使われていおり、そのアーキテクチャの方法論とここで試行している方法論が違うのではないかと感じるかもしれません。一方、データの検討はグローバル視点で考える必要があるので、このように、世界最先端で使っている方法論を試行していくことが重要だと考えています。
この記事が気に入ったらサポートをしてみませんか?