アジャイル手法とマイクロサービス(MSA)には妙な親和性があって、ほおっておくと簡単に結びつく。ユーザ企業にとっての顧客が直接利用するSoE系のソフトウエアであれば話は別だが、ユーザ企業のバックエンド業務を支える基幹システムの開発でこれらを導入すれば、事業のDX（デジタル変容）はさらに遠のく。順を追って説明しよう。
IPAの資料「エンタープライズシステムへのマイクロサービスアーキテクチャー適用の実践」では、アジャイルとMSAを組み合わせた開発事例が報告されている。公開時期は2017年なので、まだバズワード的期待がMSAにあったのかもしれないが、それにしても評価はMSAに対して甘すぎるように思える。
甘いといえば、この手の記事でいつも思わされるのが課題選定の甘さである。この報告でもエンタープライズシステム（業務システム）への適用事例と謳っているが、取り上げられている課題が「機器管理システム」なのが腑に落ちない。なぜ在庫管理や受発注管理といった本格的かつ正統的な分野を取り上げないのか。機器管理のような周辺業務を選定しても、エンタープライズ系での実践例としては迫力不足と言わざるを得ない。
じっさいのところ、機器管理業務を支援するシステムがあるとして、それが他システムとやりとりするとしたら、社員情報、組織情報、資産情報くらいだ。その程度であれば、無難にマイクロサービスとしてアジャイル開発できてしまうだろう。それらの組み合わせが業務システム開発でも有効である――という結論ありきで恣意的に選んだ業務分野ではないかと勘ぐりたくもなる。
では、正統的な分野向けにアジャイルとMSAを組み合わせて開発したらどうなるか。たとえば「受注・出荷管理」あたりに適用したとしよう。マイクロサービスの粒度設定は難しいのだが、図の下のように構成したとする。図の上側では、MSAではない単一の統合DBを核とするサブシステム構成を表している。それらのサブシステムをマイクロサービスの切り出し単位とするやり方は、粒度としては大きすぎる嫌いがあるが、これより細かくしても以下の議論に影響は与えない。
マイクロサービスとして分けられた各モジュールは独立したデータストアを持ち、異なる技術で実装されてもかまわない。外部にはAPIだけがイントラネットに対して公開され、他サービスとの情報連係はAPIを介してなされる。開発と保守にはサービス毎の専任チームがあてがわれる。そのようなソフトウエアの集合として下側の図を眺めてほしいのだが、MSAの異様さがわかるだろうか。問題は少なくとも３つある。
まずはトランザクション管理の困難だ。受注にもとづいて出荷すれば、受注残を更新するだけでなく、現在庫を引き落として売掛残高を加算する必要がある。各サービスはネットワーク上のノードとして独立しているので、３つのノード（受注・出荷サービス、売掛管理サービス、在庫管理サービス）に渡る更新トランザクションを完遂しなければいけない。つまり、２つ目か３つ目のノードで更新を失敗した場合、全体をロールバックするかリトライしなければいけないのだ。その判断や仕掛けは想像以上にややこしい。そもそもノードによってはロールバック不能なデータストアが使われている可能性もある。いわゆる結果整合性に恃んでも対処は容易ではない。
２つ目の問題は、事業全体のデータモデルが統制されなくなる点だ。MSAにアジャイル手法が組み合わせられることで、事態はさらに悪くなる。本来であれば業務システムのような典型的SoRの開発では「管理したい情報はどのような形か」を起点として仕様化が進められないといけない（データ構造が複雑だから）。ところがアジャイル手法では「動かしたいソフトウエアはどのような形か」が起点になる。その結果、UIが洗練されるわりに、全体のデータ構造が一貫した形でまとまらない。いくら個々のサービスのAPI仕様が明らかでも、全社的な情報活用やDXを構想しにくい。サービス分割を隠れ蓑として、事業全体のデータ構造の見える化という重要課題をサボれてしまうということでもある。じっさい、マイクロサービス化した結果、各サービスで似たようなテーブルを重複して作ってしまうようになったという証言もある。それらの整合性は誰がどのように担保すればよいのか（そもそも重複があると認識されるとは限らない）。
３つ目の問題は、このブログでも以前に指摘したが、開発・保守コストが嵩む点だ。実装技術やデータストア技術がそれぞれに異なることがマイクロサービスの持ち味なので、必然的にマイクロサービスにはそれぞれ独立したチームが張り付く。ECサイトやサービス系プロダクトのようなSoEは「お金を稼ぐソフトウエア」なのでそれでかまわないが、営業活動をするわけではない業務システムは１円も稼がない。稼がないソフトウエアをわざわざ複数サービスに分け、それぞれにチームを張り付けて維持することに経済合理性はない。
言うまでもないが、私はサービス指向の考え方そのものを否定しているわけではない。業務システム、会計システム、人事システム、ECサイトやサービス系の顧客向け営業システムといったブロックが相互にAPI連係することにまったく問題はないし、むしろ積極的に取り入れるべきだ。ようするに業務システムはそれ以上サービス分割できない特性を持つソフトウエアであって、その内部構造を考える際にサービス指向の考え方は無用なのだ。業務システムにMSAを導入すれば小さなブロックに切り出されるゆえに管理が容易になる――なんて言説にだまされてはいけない。
にもかかわらず、業務システム開発で安易に「MSA+アジャイル」が適用されやすいのはなぜか。欧米由来の技術系バズワードに弱い技術者やコンサルが多いといった素因はあるだろうが、「全社的な統合DBを含めた全体構想を担える技術者」が現場からいなくなったからだと私は睨んでいる。そしてそれは全体構想の意義や価値が忘れられた結果ではないか。
高層ビル建設に喩えるならば「構造計算なんて面倒だし古臭い。力学的なインタフェースを明らかにした小さなモジュール毎に設計・施工し、それらを組み合わせて高層ビルにしよう」と言い始めたようなものだ。構造計算を担える技術者がいなければ、本来ならば高層ビル建設は始まらない（無理に始めれば施工中に倒壊する）。ところが業務システム開発は無謀にも開始されてしまう（倒壊しないがデスマーチが始まる）。この場合にやるべきことは唯一つ。全体構想を担える技術者の確保、または育成である。やるべき仕事をはしょれる開発手法など存在しないということだ。
