2017/12/15（金）にエンタープライズアジャイル勉強会2017年12月セミナーで「アジャイル開発を支えるアーキテクチャ設計とは」という話をしました。資料は以下から。
僕の話したかったのは「アーキテクチャ設計といっても『大きなアーキテクチャ設計』と『小さなアーキテクチャ設計』というレベルがあり、後者はチーム内で解決すべきだが、前者はチーム外で解決すべきだ」ということです。
大きなアーキテクチャ設計：システム間連携のレベル→アジャイルチームの外で実施
小さなアーキテクチャ設計：システム内連携のレベル→アジャイルチームの中で実施
なぜ分けるのか、というと、それぞれのレベルで求められる性能も可用性も保守性も違うからです。
小さなアーキテクチャ設計は「チームが好きにすればいい」わけですが、大きなアーキテクチャ設計は「チームをまたがって企業内でそれなりに最適化されるべき」です。
よって、「チームがアジャイルに、自治的に小さなアーキテクチャ設計を進められるようにするためには、大きなアーキテクチャ設計をチームの外に意図的に出すべきである」という考え方になります。これを混ぜたまま進めようとすると、
- 大きなアーキテクチャ設計についてチーム内の部分最適で判断したために余計な問題やコストが発生した
- 小さなアーキテクチャ設計に関わることなのにチーム外が全社最適で判断しようとしてチームが動けなくなってしまった
というようなことが発生します。特にアジャイルチームではチームが小さいがゆえに、大きなアーキテクチャ設計に巻き込まれるとリソース不足に陥ったり、スケジュールの遅延が発生し、なによりもモチベーションを著しく下げることになります。「なんでもいいから早く結論を出してよ。それに合わせてサービスの実現度はPOと話して決めるからさ」みたいな。
一方で、このレベル感を混乱させるのがマイクロサービスアーキテクチャ（MSA）です。MSAでは「システムを構成するコンポーネント（＝マイクロサービス）同士をネットワーク越しに連携させる」ことが主流になっています。一方で、昔から「システム同士をネットワーク越しに連携させる」というのは一般的です。
だからこそ、その連携が「システム同士の連携」なのか「マイクロサービス同士の連携」の差というのが分かりくくなっている気がしています。もちろん、あるサービスにとって、それが「システムからの連携」なのか「システム内のコンポーネントからの連携」なのかは見分けがつきませんし、付ける必要もありません。これまでのシステム間連携だって同じことですから。
MSAは、これまで大きなアーキテクチャ設計でしか語られていなかったシステム連携を、小さなアーキテクチャ設計に持ち込みました。ネットワーク連携の様々なオーバーヘッドを許容できるだけの技術の発展があり、その変化を許容しやすくなるメリットが享受できるようになったからです。
というわけで、MSA環境では大きなアーキテクチャと小さなアーキテクチャは見分けにくいのですが、見分けないといけません。繰り返しますが、それは技術論ではなく求められる性能も可用性も保守性が違うから、です。
MSAでは前者をプラットフォームよび、後者をマイクロサービスと呼ぶことで分離していくのでしょうね。プラットフォームチームはアジャイルチームから分離すべき、です。
「大きなアーキテクチャと小さなアーキテクチャ」はエンタープライズ界隈でアジャイルに取り組もうとするときに問題になりがち、という実感のうえで提唱しました。まだまだ粗い整理なので議論の余地もあります。
エンタープライズ界隈でも、改めてアーキテクチャ設計が重要性が高まっているからこそ、無用な混乱を避け、各エンジニアが的確な活動ができる助力になればと思います。
