重厚長大型のITシステムからどう脱却する？ 「AI活用で何がどう変わるのか」を解説：SIerはどこから来て、どこへ行くのか（2/2 ページ）
レガシーシステムでは「ちょっとした変更」が不具合発生につながることがあり、ユーザー企業がSIerに不信感を抱く理由の一つになっている。こうした課題をどう解決すべきか。SIerのPM（プロジェクトマネージャー）としてシステム開発に長年携わってきた筆者がユーザー企業に向けて解説する。
疎結合の「大きな欠点」とは？
投資信託を販売する銀行や証券会社などの金融機関では、夜間に計算処理を実行する必要がある。そのため、当日の夕方までに計算処理の基となる時価が提供されなければ、金融機関全体に影響が及ぶ。主要な商品である株式は、取引所が終了する15時に価格が確定するため、時価の突き合わせ処理を含めた事務作業が行われるのはその後になる。このように、ITシステムに与えられる時間は限られており、できる部分から処理を進めることが極めて重要だ。
疎結合の設計は、このような状況下で特に有効だ。疎結合を採用すれば、障害発生時の影響範囲を限定できる上、開発にかかるコストや期間の抑制にもつながる。だからITシステムは疎結合を意識して構築しなければならないと筆者は考えている。
しかし、疎結合にも大きな欠点がある。
ここまで述べてきた例で言うと、密結合になっている縦計算では全体の計算処理や個別ファンドの計算処理の終了タイミングが一括で管理されるため、事務処理を実行する側としては作業開始のタイミングを把握しやすい。
一方、疎結合になっている横計算の場合、ファンド単位で時価計算が完了するタイミングが日によって異なる。また、全てのファンド計算が終了したかどうかを把握することが難しい。結果として、事務処理側が作業を指示しにくい構造になっている。
スケジュール管理システムの導入
ITシステムとしてどれほど構造が優れていても、利用者が使いにくいシステムでは本来の価値は発揮されない。しかし、ここにこそITプロフェッショナルの腕の見せ所がある。筆者の先輩たちが試行錯誤の末に考案したのが、スケジュール管理システムだ。
スケジュール管理システムでは、各ファンドの処理状況を事務処理側がリアルタイムで把握できるようになっている。時価計算を終えたファンドを即座に確認し、事務処理を順次進められる。
問題が発生しているファンドは、システムが自動で警告を通知するため、対応方法を迅速に検討できる。この仕組みによって、全ての処理が完了するまでアクションを起こせない縦計算システムに比べ、はるかに柔軟で迅速な処理が可能という意味で優れている。
疎結合に起因する不便さや課題は、ITシステムの適応技術によって十分に克服できる。このことは、新たなソフトウェア開発を進める上で重要な示唆を与えていると筆者は考えている。
マイクロサービスアーキテクチャの利点
いよいよ本題のモノリスシステムの課題に入る。
モノリスシステムの課題に対し、マイクロサービスアーキテクチャがどのように解決するかを説明する（図）。
マイクロサービスアーキテクチャには大きく4つの利点がある。
- システムを改変した際の影響範囲が1つのマイクロサービス内にとどまるので、他マイクロサービスへの影響調査が不要になる
- システムを改変する際に必要な結合テスト（複数の機能を結びつけて動作確認するテスト）や総合テスト（ステム全体の統合後に機能や動作を検証するテスト）が最小限に抑えられる
- マイクロサービスは再利用可能な「部品」として活用できるため、新規開発の作業量を大幅に削減できる
- 規模が大きくなったマイクロサービスは簡単に分割して管理できる
これらはどういうことか。一つずつ解説していこう。
マイクロサービスアーキテクチャの具体例
まず1と2を説明する。図ではデータがオブジェクトD（以降、「D」）に内包されている。Dに項目の追加などの改変が発生した場合を考えてみよう。このときDはオブジェクトAとGにAPI接続されている。
もし今回の改変でAPIそのものが変更されないのであれば、D単独でリリースしても、周囲のオブジェクトに影響はない。逆にAPIが変更される場合は、AとGに影響が生じる。ただし、Aと接続しているBと、AのAPIが変更される可能性は低い。なぜなら、DのデータにBが接続する必要はそもそもないからだ。Gに関しても同様で、必要なテストはD、A、Gの3つに限定されることが多い。こうした極めて限定的なテストだけでリリースを進めることが可能となる。
さらに、Dが新たな修正に必要なAPIを追加し、既存のAPI接続を維持したまま並行運用できるようにすれば、D単独でリリースすることも可能になる。この場合、Dのリリース後、AとGは必要に応じて新たなAPIを利用する形で改変を進められる。
これにより、AとGも独立して対応できるようになる。結果として、大規模なテストや広範囲な影響調査が不要となり、設計や開発の工数が削減されるだけでなく、多くの案件で迅速なリリースが可能となる。
頻繁なリリースが求められる現代において、マイクロサービスアーキテクチャという仕組みがDevOps（開発と運用を一体化した手法）の必要性を高めている。逆に言えば、マイクロサービスアーキテクチャを活用しない場合、DevOpsの導入は必須ではない。
マイクロサービスアーキテクチャを採用する場合はテストデータもAPIだけで済むため、これまでのようにテスト用のトランザクションデータやデータベースを設定する必要がなくなる。そのためテストケースの作成やテスト実施が極めて簡単になる。
「なぜバグをゼロにできないのか」問題をどう解決する？
次に3（「マイクロサービスは再利用可能な「部品」として活用できるため、新規開発の作業量を大幅に削減できる」）を説明しよう。
図のオブジェクトFを見てほしい。Fは階層構造を持っている。この構造は「継承」というオブジェクト指向プログラミングの基本概念を表している。つまり、下位のオブジェクト（小さな部品）が持つ機能をそのまま上位のオブジェクト（大きな部品）に引き継ぎ、上位のオブジェクトの構成要素として活用しているわけだ。
これは自動車の組み立てに例えると分かりやすい。ネジのような小さな部品から始まり、ピストンやエンジンといった中規模の部品をへて、最終的に自動車全体を完成させるプロセスと同じだ。
この仕組みをソフトウェア開発に応用すれば、既存のソフトウェア部品を最大限に活用することで新規開発の作業量を大幅に削減できる。さらに、品質が保証されたソフトウェア部品を多く活用することで全体のテスト範囲が最小化され、結果的にソフトウェア全体の品質が向上する。
第2回でも述べたが、追加開発が必要な箇所はごく一部に限られる。この限られた部分については、全ての論理ケースを網羅的にテストする「ホワイトボックステスト」を実施することで品質を確保する。ホワイトボックステストとは、プログラム内部の構造を把握した上で、全ての分岐や条件を網羅するテストのことだ。
一方、従来のモノリシックシステムでは「ブラックボックステスト」が主流だった。ブラックボックステストとは、システムの内部構造を考慮せず、外部からの入力と出力だけを確認する方法だ。しかし、モノリシックシステムは巨大な論理の塊（かたまり）であり、全ての条件をテストするためには天文学的な数のテストケースが必要となる。そのためテストケースを厳選するしかなく、これがバグをゼロにできない大きな要因となっている。
マイクロサービス化により、ホワイトボックステストを実現しやすくなることは、ソフトウェア開発における革命的な変化だといえる。そして論理的なテストケースの洗い出しはAIが得意とする分野だ。AIを活用すれば、人間をはるかに超える能力で適切なテストケースを自動生成できる。さらに、APIを利用したテストデータもAIで容易に作成できる。このような背景から、大手クラウドベンダーの多くがAIを使ったテストケースの生成やテストデータの自動作成、さらには自動テストの実行までを既に実現している。
ソフトウェア開発の変革
いずれにしても、ソフトウェア開発は部品の組み合わせによる開発方式に移行している。他の製造業では当たり前の製造方式が、ついにソフトウェア業界にも浸透しつつあるのだ。この変化は、手工業から製造業への転換に匹敵するものであり、ハードウェア以上に大きな効果をもたらす。
また、ソフトウェア部品の標準化も進んでいる。その証拠に、ハードウェアの世界で使われるBOM（部品表）に対応する形で、SBOM（ソフトウェア部品表）の標準化が進展している。この動きは、ソフトウェア開発の変革を象徴するものだ。
第2回でも触れたように、オブジェクト指向を活用した開発により、新規開発の作業量そのものが減少し、調査やテストにかかる工数も大幅に削減される。その結果、筆者は10倍程度の生産性向上が見込めると考えている。さらに、部品化の範囲を広げることで、さらなる生産性向上も期待できる。特に、調査やテストの負荷が高いソフトウェア保守のフェーズでは、50倍もの効果を主張するクラウドベンダーも存在する。
アジャイル開発とチーム分割
続いて、4（「規模が大きくなったマイクロサービスは簡単に分割して管理できる」）の利点を説明する。図の元のオブジェクトを2つに分割している部分を参照いただきたい。アジャイル開発を進める上で、1チーム当たり約10人までの規模が適切であることは以前も述べた。オブジェクトの機能が増えればチームを構成する人数も増加する。そのためチームとシステムを分割する必要がある。
図では元のオブジェクトがA・B・DとC・E・G・Fの二つに分割されている。この図はDオブジェクトとGオブジェクトが1つのAPIで接続されており、疎結合の関係を保っていることを示している。分割後のチームは互いに独立した関係だ。
そもそもマイクロサービスアーキテクチャでは、各オブジェクトがAPI接続によって疎結合になっているためシステムの分割が容易だ。この性質がアジャイル開発を支え、アジリティ（迅速性）とスピードを確保している。
マイクロサービス化の課題
ここまでマイクロサービスアーキテクチャの利点を述べてきたが、課題も存在する。疎結合によって各マイクロサービスが独立しているために、それぞれのバージョン管理や依存関係の把握が複雑化する。マイクロサービス間の通信が増えることで、ネットワークの負荷や遅延が問題になるケースもある。
さらに、全体を統括してシステムの一貫性を維持するための設計や運用のスキルが求められる。これらの課題を克服するためには、適切な設計指針やツールの導入、そして組織的な運用体制が不可欠だ。
次回は具体的なマイクロサービス化の課題について説明する。
著者紹介：室脇慶彦（SCSK顧問）
むろわき よしひこ：大阪大学基礎工学部卒。野村コンピュータシステム（現野村総合研究所）執行役員金融システム事業本部副本部長等を経て常務執行役員品質・生産革新本部長、理事。独立行政法人 情報処理推進機構 参与。2019年より現職。専門はITプロジェクトマネジメント、IT生産技術、年金制度など。総務省・経産省・内閣府の各種委員等、情報サービス産業協会理事等歴任。著書に『SIer企業の進む道』（日経BP）、『プロフェッショナルPMの神髄』（日経BP）など。
Copyright © ITmedia, Inc. All Rights Reserved.
