BTABOK：Repository ～リポジトリとは？～

今回のコラムはBTABoKにおける“Repository“について取り上げます。

https://iasa-global.github.io/btabok/repository.html

ビジネスやシステムを説明するメタデータを格納するリポジトリは古くからその必要性が説かれてきましたが、複雑化、巨大化するエンタープライズアーキテクチャにとって、益々その重要性が高まっている今日です。本コラムではこのリポジトリの目的にはじまり、リポジトリの構造、ツール要件、さらにはその運用保守について、BTABoKの詳細な解説を紹介します。

サマリー：一般的にリポジトリは文書化ツールとみなされることが多いと思われます。技術の観点からはそうかもしれませんが、リポジトリの目的はアーキテクチャチームに2つの基本的な要素を提供することです。

アーキテクチャリポジトリ

アーキテクチャリポジトリには、必要不可欠なアーキテクチャ成果物や情報を保管するためにアーキテクチャチームが使用する手法、ツール、テクニックが格納されます。アーキテクチャリポジトリはチームにとってのシステム、プログラム、ビジネスエンティティの構造に関する知識体系を示します。

エンゲージメントの原則：リポジトリはまずアーキテクトのためにあり、次に企業のためにあります。

リポジトリには、アーキテクチャの決定が記述され、これが影響を与えるすべての成果物が含まれます。

実践

アーキテクチャリポジトリは、非常に単純な文書や成果物のセットから、非常に複雑な企業全体のシステムのセットまで、幅広い範囲に及ぶ可能性があります。このレベルの複雑さは、産業に大きな混乱をもたらします。

エンゲージメントの原則：アーキテクチャはドキュメンテーションではない

リポジトリはとかく文書化ツールとみなされます。テクノロジーの観点からはそうかもしれないが、リポジトリの目的はアーキテクチャチームに2つの基本的な要素を提供することです。第1に、デジタル戦略におけるより良い意思決定の支援。2つ目は、アーキテクチャと他のメンバー間の迅速で透明性のあるコミュニケーションの支援です。

まずアーキテクトを大切に

最初のエンゲージメント原則では、リポジトリはまずアーキテクトのためにあるとしています。つまり、アーキテクチャ実務が最初に目標を達成できる必要があり、リポジトリにはそのために必要なものだけ、そしてアーキテクトが「エバーグリーン」（常に最新であるべき成果物を意味する）に保つことに同意したものだけが含まれるべきだということです。

アーキテクチャリポジトリの難しさは、ステークホルダーに対しての成果物と、他のアーキテクトが容易に識別できる重要な要素とを区別するのに苦労することが多いことです。

エンゲージメント・モデルの開発プロセスの一環として、チームは、最新状態を維持し保存しなければならないアーキテクチャの要素と、どの要素を標準的なエンタープライズ・コンテンツ管理システムに保存するかを特定しなければなりません。

実際、ほとんどのアーキテクチャチームは、チーム内のアーキテクチャを記述するためのドキュメントをほとんど必要としませんが、チームにとって必要なものと、企業全体にとって望ましいものの判断を織り込むべきです。

例えば、多くの組織ではケイパビリティモデルを使用してエンタープライズを記述しており、アーキテクチャチームがモデルの導入と保守を担当しています。このようなモデルは、ステークホルダーにとってもアーキテクチャの決定にとっても非常に有用です。

しかし、一般的には、アーキテクチャチームはケイパビリティモデルの非常に最小限のバージョンを必要とするのに対し、エンタープライズではより堅牢でよく保守されたバージョンを必要とします。このシナリオでは、チームはまず、その用途に応じたケイパビリティモデルを設計し、そのモデルを企業に導入します。他の利害関係者がこのモデルに価値を見いだした場合、彼らは進んでこのモデルを維持しますが、そうでなければ、チームはアーキテクトにとって有用な元の維持しやすいバージョンに戻します。

リポジトリの構造のデザイン

リポジトリは少なくとも、どのような種類のものをどのように格納すべきかを導くために柔らかな構造を持たなければなりません。アーキテクチャリポジトリの構造モデルとして最もよく知られているのは、おそらくTOGAFのアーキテクチャリポジトリでしょう。この標準は、アーキテクチャリポジトリのエンタープライズの記述を提供します。

メタモデルの要素

以下の表はリポジトリに保存されている主要な要素と、それらが互いにどのように関連しているかを強調しています。

トップダウンローディングとボトムアップローディング

“バックパックを軽くしましょう…動きが遅いほど、早く死にます”　George Clooney, Up in the Air

（ジョージクルーニー主演の映画からの引用）

BTABoK は、アーキテクチャ リポジトリが軽量でありながら、アーキテクチャ チームの最低限の目標を満たしていれば、ツール、ドキュメント、モデルが少なくなり、チームの負担が軽減され、よりアジャイルな状態を維持できると示唆しています。

これはまた、完全なリポジトリ（事実、チームを後ろに引っ張る）など存在しないことを示唆しています。トップ・ローディングとボトム・ローディングの選択肢は、そのほとんどがチームの好みと、チームとその利害関係者のエンゲージメント・モデルに対する理解の質に基づいて決定されます。

ボトムアップローディングは、主に、製品／プロジェクトレベルから作成されるアーキテクチャの収集に依存します。これは、アーキテクチャモデルや記述、ビューやビューポイント、重要な意思決定記録などです。この方法のリスクは、質の低い詳細な成果物をリポジトリに入れすぎてしまい、すぐに有用性の低い成果物でいっぱいになってしまい、長期間使われずにメンテナンスされないままになってしまうことです。

トップダウンローディングは、チームが実践に必要な成果物の厳密なセットを定義し、階層の「トップ」からそれを投入し始めることを提案します。これは、ビジネスモデル・キャンバスやケイパビリティモデルのような、ビジネスに焦点を当てた成果物ではよくあることです。これらの多くは、アーキテクチャチームにとって非常に有益なものですが、しばしばそれ自体が一人歩きし、本来のケイパビリティである価値提供からチームを引き離します。トップダウンモデルの本質は、アーキテクチャチームが他のグループのドキュメントを保守せず、まずデジタル戦略を伝える要素のみを必要最小限の範囲で考慮する必要があります。

アーキテクト・エンゲージメント・ワークショップ - リポジトリ

ワークショップの目標は、リポジトリの運用面を定義し、アーキテクチャ開発ライフサイクル（ADLC）と統合できるようにすることです。エンゲージメント・モデル運営グループ活動の一環として取り組む必要があります。

ステップ 1：エンゲージメント範囲の決定

エンゲージメント範囲は、アーキテクトの人数、企業内での関わり方、ステークホルダーコミュニティのレビュー、そしてチームの目標に基づいて定義されます。200人のアーキテクトからなる専任チームは、小規模なスタートアップ企業の2人のアーキテクトよりもはるかに広範囲に関与することになります。

ステップ2：ライフサイクルにおけるインタラクションポイントを定義

ライフサイクルの各フェーズを、インタラクションの種類、対象範囲の観点から考察します。フェーズについては、a) アイデアが生み出され取り込まれる場所、b) それらのアイデアがどのように比較され投資されるか、c) チームやグループがプロダクトにどのように割り当てられるか、d) どのように提供されるか、e) どのように最適化され測定されるか、という観点から考察します。

ステップ3: 保存の必要がある成果物を定義

アーキテクトが各フェーズで使用したいツール、テクニック、成果物、タスクに関する情報を特定します。

ステップ4：含める必要のあるリポジトリ要素を特定

以下の表は、リポジトリに重要な要素を示しています。

エンゲージメントの原則： リポジトリ管理は、チームのすべてのアーキテクトの責任であり、職務記述書とチームのパフォーマンスレビューの一部であるべきです。

ナレッジマネジメントプロセスを運用できるようにする必要があります。成果物の廃棄期限を設定し、リポジトリを維持する役割を割り当てることで、ITアーキテクトはリポジトリの鮮度と最新性を保つことができます。その結果、知的財産の再利用が促進され、情報を単一のストアに保存する傾向が強まります。

＜訳者所感＞

本セクションを和訳し最も痛感した点は何と言っても、海外の有識者においては、リポジトリの重要性はもはや当然のこととして、アーキテクト集団での利用に留まることなく、ビジネス価値向上への支援に至るまで、非常に広い範囲を包含するものとしてリポジトリの存在を位置付けていることでした。

翻って、我が国のリポジトリに対する認識は未だに低く、目の前のITシステム構築と人海戦術の保守に明け暮れている現状を見るにつれ、さらなる周回遅れに拍車がかかる懸念が強まった次第です。

よく考えれば、「巨大化、複雑化した企業システムは、これを維持管理、拡張するためには、“企業システム全体を管理するシステム“（すなわちリポジトリ）を、リファレンスモデルやフレームワークに基づいてきちんと設計、構築し、これを運用保守すること以外にはない」ということは至極当然のことです。日本企業も、早いうちに人海戦術から脱しリポジトリの構築に向かうべきでしょう。

ところでこのような悲観的な我が国の状況にも、少なからず明るい兆しも見えてきたので、少し紹介したいと思います。近年、AI活用も含めたデータ分析業務が、DWH＆BIツール、その利用者“データサイエンティスト”ともに脚光をあびてきました。データサイエンティストがデータ分析するためには、企業のメタデータを可視化＆格納するリポジトリ（データカタログ）が必要不可欠です（近年のDWHツールにはカタログ機能も附帯されている）。このような直接的目的からリポジトリを導入する先進的企業が出始めています。

未だデータ分析基盤構築の一環としてのリポジトリですが、（何年かかるか分かりませんが）本コラムにあるように、将来はその範囲がエンタープライズレベルでのビジネス価値向上に至るまで拡大されることを期待したいところです。また、とかくツール導入が目的となり運用、保守の観点を忘れがちですが、本コラムにあるように“リポジトリがエバーグリーンな状態であること”が重要であり、これが損なわれたリポジトリはやがて使われなくなるということを肝に銘じなければなりません。