最近はマイクロサービスアーキテクチャ(MSA)について色々考えてアウトプットするという状況がありました。 詰まるところMSAは手段であって、「目的は何か」を考えないといけないということを書きました。 なんか良く分からないことがあると「目的は何かを考えましょう」とか言っておけばとりあえず正論になって詳細を煙に巻けるのでおすすめです。
MSAの導入目的
MSAの特徴のほとんどは「サービスが他のサービスと独立していること」からもたらされます。 独立しているが故の「独立デプロイ可能性」であり、他サービスチームとのコミュニケーション・調整コストの低減であり、技術選択の自由度でもあるわけです。
MSAのメリットがサービスの独立性によってもたらされ、そのメリットを享受することが目的であれば、サービスの独立性を阻むものは須く取り除く必要があります。それは目的を阻む害悪でしかありません。
組織の形とシステムの形
一方で、システムの形はそのシステムに関わる組織の形と相似形を成します。いわゆるwikipedia:Conway's law、そしてInverse Conway Maneuverですね。
つまりサービスの独立性を守るのであれば、そのサービスを支える組織の形もマイクロサービス化しないと捻れを招くのでしょう。 例えば個々のマイクロサービスが独立して開発できるにも関わらず、それぞれのマイクロサービスのビジネスオーナーが互いに強く依存していると、そこがボトルネックになって独立性がなくなる。
すると、テクノロジーだけマイクロサービスになって複雑度は増し、一方でアジリティは発揮できないというデメリットだけの状況が残されます。
組織の形
結局マイクロサービスにしてアジリティを発揮していくためには、小回りが効き、互いに独立した組織構造が必要なのでしょう。このあたりは「リーン」や「DevOps」といった概念が示唆している方向ですし、「イノベーションのジレンマ」も似たようなことを言っていました。
Mode1とMode2
最近あんまり聞かなくなりましたがGartnerがbi-modalを提唱していまして、SIerでもこういったことが必要なんだと感じています。
SIという分野における「大規模」な開発には、おそらく「小回りが効く」ような組織構造はそぐわないのでしょう。 それはSIerというビジネルモデルもありますし、大規模開発で重視されているのは少なくとも現時点では、フロー効率ではなくリソース効率なのであろうと考えているからです。
- SIerとは何か、何であるべきか ― 偉大ならざるリスクテイカー｜ミック｜note
- どっこいSIerは簡単になくならない - 雑種路線でいこう
- なぜリソース効率とフロー効率が両立できないのか - 理系学生日記
一方で一度システムが構築された後のサービスイン・成長フェーズでは、フロー効率の方に焦点が移り、マイクロサービスのメリットが目立つようになるのかなと。
そういう文脈でSIerをみると、最終的なフロー効率という実を取るために、リソース効率を重視しながら職能型組織でマイクロサービスを開発するみたいなことになるのでしょうか。 そうすると、確かにbi-modalは必要だわ、という妄想をしました。
