マイクロサービス化はBPRプロジェクトと心得よう

本コラムの前編・中編では、「なぜ今基幹システムをマイクロサービス化するのか」「どのように機能を断捨離すべきか」を示してきた。最終回となる今回は、残すシステム・機能が決まった後に、それをどのように再構築するかを考えていく。
とはいえ、現行の基幹系システムは盛りだくさんで、業務と機能が密結合してしまっているので、マイクロサービス化するにもどこからどう手を付けていけばいいのか。筆者は2ステップで進めるのが良いと考えている。

システム・機能を3+1に分類してみよう

現行の基幹システムを全てマイクロサービス化しようとすると、費用対効果に見合わない可能性がある。システム・機能を下記のように、企業活動に必須の機能群（No.1～3）とそうでない機能群（No.4）に分け、さらに前者を3つに分類することで、マイクロサービス化すべき機能群が判断しやすくなるだろう。

表3-1 システム・機能分類

マイクロサービス化の主戦場となるのはミッションクリティカル系だろう。伝票処理系、業務系、その他バック系の機能群については、パッケージやSaaSを活用しやすい。もし、現行システムとして完全に独立している機能であれば、再構築せず、そのまま残すという選択肢もある。

この分類活動における最難関は業務系を切り出せるかどうかだ。業務系は機能一覧上に通知や帳票として表現できていれば、比較的簡単に切り出せるが、トランザクションデータ内に社内担当者を紐づけるような項目を持っていたり、社内画面にイレギュラーケースでのみ使用するボタンがあったり、業務に直結するトランザクションとは別のデータを生成・更新する機能が潜んでいたりと、一つの機能の中に、ミッションクリティカル系の処理と業務系の処理が混在していることも多い。さらにこれらの機能を前提として業務フローが組まれていると、見分けがついてもシステム部門の独断で切り出すことができなくなる。前章の断捨離活動と合わせて、業務部門と協業しよう。

マイクロサービス化の範囲を特定でき、検討ボリュームも難易度も下げることができていたなら、ここまでは成功と言える。

マイクロサービスを定義し、機能を振り分けよう

現時点の機能一覧は現行システムとひもづいていて、複数のシステムをまたいで一つの業務機能を成立させていたり、似たような機能が複数のシステムに分散していたり、複数の業務で使用される機能が一つのシステムに集中していたりするので、これを「サービス」という単位で、業務機能の固まりを定義し、適切な機能配置に整理する必要がある。

適切なサービス定義をする上でポイントになるのは「粒度」と「非同期化」だ。前ステップの「受注機能」を例にとって説明する。

ECサイトで買い物する時のことを思い浮かべてほしい。下図のアクションに示す通り、買いたいものを検索し、カートに入れ、注文内容を確認して決済し、確定する。場合によっては、注文履歴を確認し、キャンセル・変更・返品することもある。ここで該当のアクションが処理を実行するために利用する機能を真ん中の列に示している。マイクロサービス化ではこれらの機能をサービスという単位に分類する。

図3-2 ECサイトのアクションと機能

「マイクロ」というくらいだから、ここに書いた機能の単位でサービスを区切ればいいか、というとそうではない。同じデータを処理する機能をサービス分離してしまうと、サービス間で密結合になってしまう。そこで、処理する対象のデータでくくってみると上図の右列のようになる。在庫サービスと注文サービスの機能が相対的に多いが、一旦粒度はOKとして、次に課題となるのは「非同期化」だ。

例えば、決済～注文確定～在庫引当だ。注文チェック、在庫チェック時点では在庫が残っていて、購入可能だったとしても、注文内容を確認したり、決済処理中、別の人に同一商品を購入されて在庫が無くなったりすると、決済、注文確定に成功しても、在庫引当に失敗する。
対策例を挙げる。

表3-3 サービス分割による業務影響

システム部門だけでこれを判断できないことはお分かりだろう。事業部門として何にプライオリティを置くかによって、選択は異なるだろうし、選択によって業務フローも変わる。サービスを定義するということは業務を再設計することと同義なのである。

マイクロサービス化はシステム部門がやるべき、BPRは業務部門がやるべきという人ごと感覚で居続けたら、基幹再構築は失敗に終わり、2025年の崖を越えることはできない。ぜひとも両者協業の元、進めていっていただきたい。

要件定義不備の対応方針をあらかじめ合意しておこう

要件定義段階では「納得感を持って断捨離」「BPRを意識して機能をマイクロサービス化」したはずでも、実際に新システムを目の前にする（テスト環境で打鍵する）と、リリース後運用できるかどうか、不安になることが多く、UAT（ユーザ受入テスト）の障害報告として、要件定義不備の課題や仕様変更要望が大量に上がってくる。これは生理現象のようなもので、回避不可能だと筆者は考えている。とはいえ、プロジェクト終盤になってから、これらの課題・要望を全てシステム機能として実装するのも非現実的である。（追加予算を取って、リリース予定も延期するなら可能ではあるが、その判断を下した時点でプロジェクトは失敗という評価になる）

ではどうしたらよいか。筆者が考える一つの解は、テスト工程で発生した課題を、ステークホルダー全員に対して平等に優先度付けできるような客観的基準（以下に例を示す）を、プロジェクト計画時点で合意しておくことである。

表3-4 課題の優先度判断基準

システム機能を完璧に作り切ることではなく、移行・リリース後に業務を回せるかどうかに焦点を当てて欲しい。優先度「最高」「高」については業務を止める可能性があるので、システム対応が必須となるが、「中」「低」については、せっかく身軽にした基幹システムを不用意に肥大化させてしまうことになり兼ねない。

実際に筆者も、優先度「中」以下のシステム対応を見送る方針としたが、移行・リリースから1ヶ月経つ頃には、リリース前の業務負荷まで落ち着き、断捨離判断は正しかったと証明できた。

ここで重要なのは、要件定義のアウトプットは工程を進める中で変化していくということだ。「決めたことは決めたとおり完璧に実装されなければならない」という、請負契約に基づくシステム開発に縛られすぎると、本来不要な機能にパワーを掛けてしまったり、逆に必要な機能にパワーを掛けられなかったり、バグか仕様変更か、瑕疵か追加改修かの討議に業務部門、システム部門、ベンダーのキーマンが長時間拘束されたり、Lose-Lose-Loseの関係になってしまう。
また、マイクロサービスごとにチームを分けて、設計・開発を並行して進めることができれば、規模に対する設計・開発工期を圧縮できる可能性がある。その分、UATの期間を長めに取るなどして、上記の「移行・リリース前に恒久対応する」ための時間と人的リソースを確保するのが生産的な考え方かと思う。ベンダーも設計書通りに開発したら終わりではない。設計・開発を進める中で業務をより深く理解し、業務部門、システム部門との対話を通じて、継続的に業務・システム改善をリードしていくような役割が求められる。三者（業務部門、システム部門、ベンダー）がお互いをビジネスパートナーとして認め合い、同じ方向を向いて協力し合えることができれば、Win-Win-Winの関係になれるだろう。

執筆者情報

MSシステム事業部　深沢 直輝：
2006年に野村総合研究所に入社。メーカー・卸・小売・通信・教育業界等に対して、IT戦略立案～システム化計画、要件定義、システム開発～リリースに従事。専門はクラウドサービスを活用したシステム化計画、業務改革の推進。

マイクロサービス化で2025年の崖を飛べ（前編）

DX時代のシステム導入最前線一覧ページへ

産業ITソリューションNewsletterのご登録（別サイトへ）

産業ITソリューションサイトへ