家族運営でTOGAF演習【1】 Preliminary Phase
ビジネス・アーキテクチャチームに参加してしばらく経った。職場でエンタープライズ・アーキテクチャ、ビジネス・アーキテクチャをなんとか学びながら進めている。職場ではTOGAFというエンタープライズ・アーキテクチャ・フレームワークを使っているが、現在進めているプロジェクトのためにある程度カスタマイズされていること、最初のフェーズが私が参加する前に終わっていたこと、全体像が非常に広範囲であることなどから、まだピンときていない部分も多いまま進めている。
と、いうわけで、自分で練習してみよう、と、思い立った。小さなエンタープライズで、自分がビジネス側でもあるものを題材に。私の所属するエンタープライズ、それは家族である。
エンタープライズの定義は以下：
戦略的な目標を達成するために組織内のリソースやプロセスを調整・統合し、最適化されたビジネス成果を実現する組織または事業体です。TOGAFでは、エンタープライズを単なる企業や組織の集まりではなく、ビジネス戦略を支えるためのアーキテクチャを持つ複雑なシステムと捉えています。
家族だってエンタープライズでしょ？ いろんな戦略をもとに運営されてる。
そんなわけで、今回から、ファミリーエンタープライズを例に、TOGAFのADMサイクル、特にビジネスアーキテクト周りまでを一つ一つ、練習してみようと思う。
TOGAFとは
EA（エンタープライズアーキテクチャ）チームに入った時、「うちではTOGAFっていうフレームワーク使ってるから」とだけ言われた。初めて聞いたし、そもそもエンタープライズ・アーキテクチャチームが何をしているのかもよくわかっていなかった。前回も書いたが「新しいソリューション作るときにアーキテクチャボードにかけて、そこでEAチームが、ウンとかスンとか言う、くらいの認識だった。
とりあえず、TOGAFと検索して読み始めた。しかし、なんとも掴めない。サービスデザイン、デザイン思考をバックグラウンドとして持つ私としては、デザインスプリントみたいなはっきりした「これをフォローすればできる」というメソッドが欲しかった。今となってはTOGAFの「これをフォローすれば」みたいなのがぼんやりと見えてきたけれど、最初は本当になんともつかみどころがなかった。
TOGAFの定義
TOGAF（The Open Group Architecture Framework）は、企業や組織の**エンタープライズアーキテクチャ（EA）を設計、開発、維持するための標準的なフレームワークであり、ITとビジネスの整合性を取るための体系的な方法論を提供します。TOGAFは、企業の戦略的目標に沿ったアーキテクチャの構築と、業務プロセス、情報システム、テクノロジーの最適化を目的としています。
今回から、TOGAFというフレームワークを使って、ファミリーエンタープライズのアーキテクチャを設計、開発、維持していこうと思う。
アーキテクチャ開発メソッド（ADM）とは
さて、TOGAFについて読み始めると出てくる「とりあえずこれフォローしとけばできそう」というのが、下の図で表されるADM（Architecture Development Method）。最初に準備段階のPreliminary phaseの後、実際のアーキテクチャ開発をしていきます。詳しくはThe Open Groupのウェブサイトを参照のこと。ライブラリにたくさん勉強するための資料があります。
Preliminary Phase
上図で一番上にポンとあるのがPreliminary Phaseである。これは、エンタープライズアーキテクチャをするための準備段階とも言える。
このフェーズにすべきことは大きく分けて二つ。アーキテクチャをするための能力が何かをきめ、それを確立すること。そのために以下を明確にしていきます。
アーキテクチャ開発のための枠組み（Architecture Framework）
今回はTOGAFの練習なので、TOGAFフレームワークを使います。
アーキテクチャガバナンスモデル（Architecture Governance Model）
ガバナンス機関:
ファミリーボード: 重要な意思決定に参加する家族のメンバー。
ファミリーアドバイザー（外部）: 金融アドバイザー、医療専門家、またはカウンセラーなど、専門的な助言を提供する外部のアドバイザー。友人、家族含む。
役割と責任:
家長: 財務及び決定、長期計画、安定目標をリードし、日常のルーチン、健康、感情的なウェルビーイング、教育支援を管理。
家長補佐: 財政管理、家族全体の方向性を考え、家族のアーキテクチャに必要な構造を提供。
子: 個々のニーズ、好み、関心について意見を提供。
意思決定プロセス:
家族のメンバーは毎月、主要な意思決定（例：予算、教育計画）について話し合うために会議を開きます。
主要な家族目標（例：財務計画、健康施策）に影響を与える決定は合意に基づいて行われます。
アーキテクチャレビュー:
家族の目標に対する進捗を評価し、必要に応じて優先順位を調整するために、四半期ごとのレビュー会議を実施します。
ステークホルダーマップ（Stakeholder Map）
家長（役割: 提供者、意思決定者）: 財政的安定、長期計画、健康に関心を持つ。財政的安定、長期的な貯金、健康管理を確保すること。
家長補佐（役割: ケアギバー、オーガナイザー）: 家族のルーチン、健康、感情的なウェルビーイング、教育に焦点を当てる。
子（役割: 学び手、成長する個人）: 一貫した構造、感情的なサポート、個人的成長の機会、教育を必要とする。
アーキテクチャ能力の成熟度目標（Architecture Capability Maturity Target）
組織のアーキテクチャ能力の現状を評価し、目指すべき成熟度レベルを設定します。これにより、アーキテクチャの進化を追跡する基準を定めます。
現在の成熟度: 現在、家族のアーキテクチャ能力はレベル１（初期段階）にあり、アーキテクチャの取り組みが非体系的で、標準化されていない。
目標成熟度: 組織は次の3年間でレベル4に到達することを目指します。具体的には、アーキテクチャのプロセスが定量的に管理され、ビジネス目標との整合性を測定可能な指標で追跡できるようにします。
アーキテクチャリポジトリの設計（Architecture Repository Design）
アーキテクチャ関連のドキュメントや情報を保管・管理するためのリポジトリの構成を設計します。これにより、情報の整理と活用が容易になります。
具体的には、Google Driveの中に以下のようなフォルダ構造を作りました。
構造:
ドキュメントセクション:
家族の目標やビジョン
財務計画
健康とウェルネスの計画
モデルセクション:
家族の役割と責任のモデル（役割ごとの責任範囲）
教育や成長計画のフロー
ガバナンスセクション:
定期的な家族ミーティングの記録
財務レビューや健康チェックリスト
ステークホルダーセクション:
家族メンバーの関心事、目標、懸念
ツールと技術:
Google Driveを利用してドキュメントとデータを管理し、Google Docsでナレッジ共有を行う。アーキテクチャモデルはVisio, Mural, Google Spreadsheetを使用して作成。
ミーティング議事録等はGoogle Docs。
カレンダー共有はGoogle Calendarです。
バージョン管理とアクセス制御:
各ドキュメントとモデルにはバージョン管理を設定し、各家族メンバーが自分の役割に関連する情報にのみアクセスできるようにアクセス制御を行います。
リスク評価とリスク軽減計画（Risk Assessment and Mitigation Plan）
アーキテクチャ開発を実行する上で発生する可能性のあるリスクを洗い出します。家族エンタープライズにおけるアーキテクチャ開発に関連するリスクとして、以下が考えられます：
リスクの特定
リソース不足
リスク: 家族メンバーがアーキテクチャ開発の活動に十分な時間やエネルギーを割けない可能性。
影響: アーキテクチャ開発が遅延したり、計画通りに進行しない可能性が高まります。
役割の不明確さ
リスク: 家族メンバー間での役割分担が明確でない場合、責任の所在が不明確になり、アーキテクチャ開発が進まない可能性。
影響: プロジェクトの進行が遅れ、重要な意思決定が行われないまま進行するリスク。
変化への抵抗
リスク: 家族メンバーが新しいアーキテクチャに対して抵抗感を持ち、適応に時間がかかる可能性。
影響: 家族内での協力が得られず、アーキテクチャ導入がスムーズに進まない。
意思決定の遅延
リスク: 家族内での意思決定が遅れることにより、重要なタイミングでのアーキテクチャの変更や進行が滞る可能性。
影響: アーキテクチャ開発の遅延、目標の未達成。
リスクの評価
各リスクについて、その影響度と発生確率を評価します。例えば：
リソース不足:
影響度: 高
発生確率: 中
評価: 重要なリスク。家族内での役割分担をしっかりと設計し、リソース（時間やエネルギー）を確保するための対策が必要。
役割の不明確さ:
影響度: 高
発生確率: 中
評価: 家族メンバー間での明確な役割定義が求められます。
変化への抵抗:
影響度: 中
発生確率: 中
評価: 家族メンバーに対するコミュニケーションと教育が重要。
意思決定の遅延:
影響度: 中
発生確率: 中
評価: 定期的な家族会議で意思決定を迅速に行う体制が必要。
ついでに表にして、先ほど作ったドキュメントレポジトリに保存しました。
レポジトリ等をGoogleに頼っているという点もなんとなくリスクな気もしますし、他にもリスクはありそうですが、とりあえず…
なんだかだんだん格好がついてきました。
次はアーキテクチャ開発をトリガーする文書、The Request for Architecture Workについてやっていきます。