設計者の発言

業務システム開発とデータモデリングに関する語り

アジャイルとマイクロサービスは最悪な組み合わせ

 アジャイル手法とマイクロサービス(MSA)には妙な親和性があって、ほおっておくと簡単に結びつく。顧客が直接利用するSoE系のソフトウエアであれば話は別だが、バックエンド業務を支える基幹システムの開発でこれらを導入すれば、事業のDX(デジタル変容)はさらに遠のく。本来であれば事業ごとに慎重かつ巧妙に構造化されるはずのDBが、全社での情報活用がやりにくい形で固まってしまうからだ。

 IPAの資料「エンタープライズシステムへのマイクロサービスアーキテクチャー適用の実践」では、アジャイルとMSAを組み合わせた開発事例が報告されている。公開時期は2017年なので、まだバズワード的期待がMSAにあったのかもしれないが、それにしても評価はMSAに対して甘すぎるように思える。

 甘いといえば、この手の記事でいつも思わされるのが課題選定の甘さである。この報告でもエンタープライズシステム(業務システム)への適用事例と謳っているが、取り上げられている課題が「機器管理システム」なのが腑に落ちない。なぜ在庫管理や受発注管理といった本格的かつ正統的な分野を取り上げないのか。機器管理のような周辺業務を選定しても、エンタープライズ系に対する実践例としては迫力不足と言わざるを得ない。

 じっさいのところ、機器管理業務を支援するシステムがあるとして、それが他システムとやりとりするとしたら、社員情報、組織情報、資産情報くらいだ。その程度であれば、無難にマイクロサービスとしてアジャイル開発できてしまうだろう。それらの組み合わせが業務システム開発でも有効である――という結論ありきで恣意的に選んだ業務分野ではないかと勘ぐりたくもなる。

 では、正統的な分野向けにアジャイルとMSAを組み合わせて開発したらどうなるか。たとえば「受注・出荷管理」あたりに適用したとしよう。マイクロサービスの粒度設定は難しいのだが、図の下のように構成したとする。図の上側では、MSAではない単一の統合DBを核とするサブシステム構成を表している。それらのサブシステムをマイクロサービスの切り出し単位とするやり方は、粒度としては大きすぎる嫌いがあるが、これより細かくしても以下の議論に影響は与えない。

f:id:dbconcept:20220316130913p:plain

受注・出荷管理のための2つのアーキテクチャ

 マイクロサービスとして分けられた各モジュールは独立したデータストアを持ち、異なる技術で実装されてもかまわない。外部にはAPIだけがイントラネットに対して公開され、他サービスとの情報連係はAPIを介してなされる。開発と保守にはサービス毎の専任チームがあてがわれる。そのようなソフトウエアの集合として下側の図を眺めてほしいのだが、MSAの異様さがわかるだろうか。問題は少なくとも3つある。

 まずはトランザクション管理の困難だ。受注にもとづいて出荷すれば、受注残を更新するだけでなく、現在庫を引き落として売掛残高を加算する必要がある。各サービスはネットワーク上のノードとして独立しているので、3つのノード(受注・出荷サービス、売掛管理サービス、在庫管理サービス)に渡る更新トランザクションを完遂する必要がある。2つ目か3つ目のノードで更新を失敗した場合、全体をロールバックするかリトライしなければいけない。その判断や仕掛けは想像以上にややこしい。そもそもノードによってはロールバック不能なデータストアが使われている可能性もある。いわゆる結果整合性に恃んでも対処は容易ではない。

 2つ目の問題は、事業全体のデータモデルが見えなくなる点だ。MSAにアジャイル手法が組み合わせられることで、事態はさらに悪くなる。本来であれば業務システムのような典型的SoRの開発では「管理したい情報はどのような形か」を起点として仕様化が進められないといけない(データ構造が複雑だから)。ところがアジャイル手法では「動かしたいソフトウエアはどのような形か」が起点になる。その結果、UIが洗練されるわりに、全体のデータ構造が一貫した形でまとまらない。いくら個々のサービスのAPI仕様が明らかでも、全社的な情報活用やDXを構想しにくい。サービス分割を隠れ蓑として、事業全体のデータ構造の見える化という重要課題をサボれてしまう。

 3つ目の問題は、このブログでも以前に指摘したが、開発・保守コストが嵩む点だ。実装技術やデータストア技術がそれぞれに異なることがマイクロサービスの持ち味なので、必然的にマイクロサービスにはそれぞれ独立したチームが張り付く。ECサイトやサービス系プロダクトのようなSoEは「お金を稼ぐソフトウエア」なのでそれでかまわないが、業務システムは1円も稼がない。

 稼がないソフトウエアを複数サービスに分け、それぞれにチームを張り付けて維持することに経済合理性はない。多くの大企業では業務システムは必要以上の人員によって保守されているのが実情ではあるが、うまく設計すれば5名程度で維持できるようになる。MSAの必要人員はその数倍ではきかないだろう。無理に人数を減らせば、実装方針が異質な複数サービスを一人で保守する羽目になる。これはつらい。

 言うまでもないが、私はサービス指向の考え方そのものを否定しているわけではない。業務システム、会計システム、人事システム、ECサイトやサービス系の顧客向け営業システムといった大きな粒度のモジュールが相互にAPI連係することにまったく問題はない。むしろ積極的に取り入れるべきだ。ようするに業務システムはそれ以上サービス分割できない特性を持つソフトウエアであって、その内部構造を考える際にサービス指向の考え方は無用なのだ。業務システムにMSAを導入すれば小さなブロックに切り出されるゆえに管理が容易になる――なんて言説にだまされてはいけない。

 にもかかわらず、業務システム開発で安易に「MSA+アジャイル」が適用されやすいのはなぜか。欧米由来の技術的バズワードに弱い技術者やコンサルが多いといった素因はあるだろうが、「全社的な統合DBを含めた全体構想を担える技術者」が現場からいなくなったからだと私は睨んでいる。そしてそれは全体構想の意義や価値が忘れられた結果ではないか。

 高層ビル建設に喩えるならば「構造計算なんて面倒だし古臭い。力学的なインタフェースを明らかにした小さなモジュール毎に設計・施工し、それらを組み合わせて高層ビルにしよう」と言い始めたようなものだ。基本設計を担える技術者がいなければ、本来ならば高層ビル建設は始まらない(無理に始めれば施工中に倒壊する)。ところが業務システム開発は無謀にも開始されてしまう(倒壊しないがデスマーチが始まる)。この場合にやるべきことは唯一つ。全体構想を担える技術者の確保、または育成である。やるべき仕事をはしょれる開発手法など存在しないということだ。