Architecture is Leadership
Joe ReisとMatt Housleyの著書『Fundamentals of Data Engineering』はデータエンジニアリングにおける基本的な考え方を網羅的に説明した本で、その中にデータ・アーキテクチャの基本原則を説くチャプターがある。9つある基本原則の1つとして「Architecture is Leadership」という考え方が登場する。引用してみよう。
Data architects are responsible for technology decisions and architecture descriptions and disseminating these choices through effective leadership and training. Data architects should be highly technically competent but delegate most individual contributor work to others. Strong leadership skills combined with high technical competence are rare and extremely valuable. The best data architects take this duality seriously. (p.144)
(日本語訳) データアーキテクトは技術的な意思決定とアーキテクチャの説明に責任を持ち、効果的なリーダーシップとトレーニングを通じてこれらを普及させる役割がある。データアーキテクトは高い技術的能力を持つべきであるが、ほとんどのインディビジュアル・コントリビューターとしての仕事は他の人に任せる。高い技術力と強力なリーダーシップを兼ね備えた人材は稀であり、非常に貴重である。最高のデータアーキテクトはこの二面性を真剣に受け止めている。
一般的に、「アーキテクト」という言葉からは、映画『マトリックス・リローデッド』に登場するアーキテクトのようなイメージが持たれることが多い。重要な意思決定をすべて一人で実施し、ほかのメンバーはその意思決定に従うのみである。Martin Fowlerはエッセイ『Who needs an Architect?』の中で、この種類のアーキテクトを「Architectus Reloadus」と名付けた。*1。
Architecture is LeadershipはArchitectus Reloadusに反対する存在を生み出す考えだ。技術的な実力を持っているだけではなく、トレーニングとリーダーシップを通じてチームの実力を向上させ、チーム全体のケイパビリティを高めることができる。Martin Fowlerは この種類のアーキテクトを「Architectus Oryzus」と名付けた。Oryzusは「米みたいな」くらいの意味（かも）*2。
データアーキテクチャ（基盤）を構築するうえでは、Architectus Oryzusとしての役割を果たすことが重要になる。データ基盤はプラットフォームであり、データ分析チームだけではなく、データの利用者、データの生成者など、さまざまなアクターの利害が交錯する場所である。複雑かつ素早く変化する状況でデータが真に価値を発揮するためには、チームのそれぞれのメンバーに高い自主性とスキルが求められる。具体的には、ステークホルダーとコミュニケーションを実施し、コードの変更に落とし込み、デプロイまで実施できる主力級のメンバーが必要になる。そのうえではチームの実力を高めるArchitectus Oryzusの存在は必須だろう。
Architecture for Leadership
実際には、Architecture is Leadershipの実践にはハードルがあることが多い。例えば、退職するエンジニアから役割を引き受ける場合を考えてみる。
- なぜSQLでできることをわざわざGlue Job (Spark) を使ってやっているのだろう？保守コストや学習コストのことは考えなかったのだろうか？
- なぜgit-flowの構成にしたのだろう？一般にこのフローが運用に乗るには今より多くのエンジニアが必要なのに、なぜ一人エンジニアの体制でこの構成を選んだのだろう？
などと、アーキテクト自信が納得いっていないケースがあった。詳しくは以下を参照してほしい。これは実際に起こったことだ。
アーキテクト自身が合理的に説明できないのに、リーダーシップが生まれるのだろうか？答えは否だ。合理性のない技術選定はリーダーシップの欠如も意味する。*3
「なぜこんな風になってるんですか？意図とかってありました？」 「外部のコンサルにそういわれたからです」
仮に合理的な説明ができたとしても、技術的なハードルが高ければ普及させることは難しい。特に、データマートを作成するSQLをアナリストが変更を加える場合などは、技術的なハードルの高さは致命的になる。Gitに慣れていないデータアナリストにgit-flowの運用は不可能だ。
そこで、Architecture for Leadershipという考え方を思いついてみた。リーダーシップをとれるようなアーキテクチャを構築しよう、という考え方である。では、リーダーシップをとれるようなアーキテクチャとはなんだろう？三つの要素に分けて考えてみた。
1. 設計思想がある
- 設計思想を持たせて、すべての技術的な意思決定はその思想の演繹の結果として成されるようにする
- シンプルな、3つ程度の原則から構成されるのが望ましい
- 寄って立つ思想があれば、トレードオフに正面から取り組むことができる
2. 設計思想から逸脱しないようにする
- 設計思想から逸脱する部分は切り捨てるか、思想に合わせ修正する
- 設計思想に矛盾することはあってはならない
- 思想に対して一貫していることは、リーダーシップを発揮するうえでは必要になる
3. 説明しやすくする
- ほかのメンバーがコラボレーションするハードルを下げる
- 参画しやすい体制を作る
- 例えば、以下のような思考実験をしてみよう。「オンボーディングを作るとしたら、どのようなことを説明しないといけないだろうか？この説明は非合理的ではないだろうか？」説明が非合理的にしかできない場合、説明力が足りないのではなく、設計そのものが非合理的な場合が多い。
おわりに
データ基盤を取り巻く環境は素早く変化するため、自律的な主体を作り出すArchitectus Oryzusの存在は必要だ。だが、リーダーシップを取りづらいアーキテクチャでは、貴重なArchitectus Oryzusの労力は無駄になってしまう。その状況を回避するためには、アーキテクチャそのものをリーダーシップをとれるような形に変更してしまえばよい、というのがArchitecture for leadershipの考え方だった。
政治とかいろいろ考えるべきことはありますが、それはまた別の話...
*1:https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
*2:なぜ米なんだ...？
*3:ただし、上記ブログの場合は、そうせざるをえなかったという事情があるが
