マイクロサービス化のグランドデザインフェーズ (をコンサルティングで支援する)
マイクロサービスアーキテクチャ化案件っていうのは新規システムじゃなく既存システムで発生します。
では実装に入る前のグランドデザインフェーズってどう過ごしたらいいの? と最近よく質問されるので、言語化しておきたいと思います。
ここから先はあくまで
マイクロサービスアーキテクチャなんてやったことないよ！
…という組織を、組織外のコンサルタントが支援する
という視点でどのように進むものかという話をさせてください。
内容はマイクロサービスアーキテクチャやモダナイゼーション初心者向けの内容です。
熟練の組織はもっとスピード感のある優秀なやり方があるかもしれません。
TOGAFとはなんぞや
マイクロサービス化プロジェクトってウォーターフォールじゃないとダメでしょ？とよく聞かれますが、そんなことはありません。
そもそもアーキテクチャ策定にはアーキテクチャ策定のフレームワークがあります。
The Open Group Architecture Frameworkの頭文字をとってTOGAFと言います。
これはエンタープライズアーキテクチャの策定フレームワークなのですが、全体の中に粒々の独立したコンポーネントが存在し、それが合わさって全体になるという構造がマイクロサービスアーキテクチャもエンタープライズアーキテクチャも同じ構造になるので、マイクロサービスを活用したアーキテクチャの策定にも活用されます。
今回はこのフレームワークに従ってグランドデザインフェーズであるA-Fでは具体的にどんなことをするのか、NGパターンは何かを解説していきたいと思います。
またその後G-Hではアーキテクチャの観点から何が必要かも併せて記載したいと思います。
ただしこの記事ではTOGAF用語は積極的には用いません。
TOGAFを知らない人でもわかるように、一般的な用語を使って解説します。
(例: ターゲットアーキテクチャ --> To Beアーキテクチャ)
なぜTOGAFベースなのか？
お詳しい方はTOGAFには重厚すぎて時代に合わないと言った批判があることもご存知かと思います。
それでもTOGAFをベースとして使うことがおすすめです。
なぜなら非常に多くの検討や議論が同時並行で進むため、今自分たちが何をしているのか、この議論はなんのためのものなのかを忘れがちです。
B-Dの設計活動の中でいつの間にかアーキテクチャリポジトリの拡充に熱中してしまっていたり、BやCを実施せずいきなりDから議論がスタートしていたりなど、どうしても議論が発散する傾向があります。
自分たちは今何をしているのか、どのフェーズにあるのか、このフェーズのゴールは何で、自分たちがいましている議論が適切かを常に振り返ることができるようにするために、確立されたフレームワークであるTOGAFを使って現在地の確認ができるようにしておくことをお勧めします。
A. アーキテクチャビジョン
まずはなぜ (Why) それをやるのか、どんな状態を目指す (What) か、ゴールを明確にします。
例えばとあるお客様はプラットフォーム費用の削減とバッチの実行時間の短縮を同時に実現したいというのがゴールでした。
夜間バッチの予定終了時刻に現在ギリギリになっており、間に合わないこともあるそうです。単純にリソースを割り当てれば解決しなくもないですが、1トランザクションあたりのプラットフォーム費用を計算すると、1トランザクションあたりのプラットフォーム費用がかさんでおり、利益率が非常に悪くなってしまいます。
そのため、バッチの実行時間の短縮とプラットフォーム費用の削減を同時に実現すべきという結論に至ったそうです。
ビジネス課題を明確にすること
重要なのはIT課題ではなくビジネス課題です。
マイクロサービス化を含むリファクタリングはお金も人手もかかります。予算がきちんと出ないと実現できません。
たいていの組織では、予算を出す方はビジネス課題を相手にしています。
従って予算を出す人に「確かにそれは大きな問題だね！」と言ってもらえるように説明しなければなりません。
端的にいうとビジネス課題は
売り上げ向上
コスト削減
利益率の向上
のいずれかを実現する上でのハードルです。
上記のプラットフォーム費用とバッチの実行時間の例で言えば、
これ以上ユーザーの利用が増えるとシステムキャパシティの問題で対応しきれない = 売り上げ向上に対するハードル
トランザクションあたりの利益率が悪い = 利益率向上に対するハードル
IT課題は深掘りの必要あり
マイクロサービス化案件でよく出てくる課題はIT課題であることが多いです。
よく出てくる例として、
開発からリリースまでのリードタイムが長い
簡単な機能追加がシステム全体のテストやデプロイメントになってしまう
スパゲッティ状態になっている
スパゲッティ状態から不具合が発生しやすい
これらはIT課題です。
これらのIT課題がビジネス課題として認識されるのは、『LeanとDevOpsの科学』が組織全体の当たり前として共通認識が確立されているところだけです。
たいていの組織では、これらがビジネスに対してもたらすインパクトまで訴求しないといけません。
例えば
「開発からリリースまでのリードタイムが長い」
--> リードタイムが長いことでどんな損が発生しているか？を深掘りする必要があります。
リードタイムが長いことで競合が自分たちに先立って機能をリリースし、マーケットシェアを失うような事象が発生しているか？しているとするとどの程度の機会損失が今までにあったか？
リードタイムが長いことが人的コスト (工数) の多さからきているのであれば、プロセスのどこにどんな工数のかかり方をしているか？それは人件費としていくらに換算されるか？
なお前者は売り上げ向上に対するハードル、後者はコスト削減に対するハードルになることが多いです。
これを把握するために活用できるのが中期経営計画や決算報告などのIR情報です。支援側である我々は必死にクライアントのIR情報を読みます。おそらく直近の中期経営計画で定義されたいずれかのイニシアチブに基づいて案件が来ていると思われるため、
元々のイニシアチブはなんだったのか？
どのくらいビジネスが伸びることを想定しているか？
などを把握する目的で頑張って読みます。
意外と思われるかもしれませんが、ここで得たインプットがアーキテクチャレベルの設計のヒントだったり決め手だったりになります。
B~D: アーキテクチャ策定
ここが一般的に全体アーキテクチャ「設計」(別種のWhat) の領域です。
TOGAFについて詳しく解説するのはこの記事の本意ではないので、ここではざっくりと次のように理解してください。
B: ビジネスアーキテクチャ
--> 対象のビジネス領域を特定し、ビジネスの構造を把握する。
C: 情報システムアーキテクチャ (アプリケーションアーキテクチャ + データアーキテクチャ)
--> アプリケーションとデータモデルの論理構造を定義する
D: テクノロジーアーキテクチャ
--> それぞれどんな技術要素を使って実現するかを定義する (例えば、ここはコンテナオーケストレーションにする、というレベル感)
マイクロサービスアーキテクチャの案件であっても、ここまで来て初めてマイクロサービスアーキテクチャにするか、あるいはモノリシックなアーキテクチャにするかが確定します。大事なのはビジネス課題の解決であり、解決に最適なツールを使うことです。アーキテクチャスタイルがモダンかどうかはあまり大切ではありません。
B-DではAs IsとTo Beの両方を調べることになります。
古いシステムを捨てる場合でもAs Isは以下を把握する目的で調査する必要があることがほとんどです。
なぜこれまでのシステムで課題が発生してしまったか？繰り返さないためには何が必要か？
たいていの場合で段階移行の必要が発生する。どこからどのように移行できるか、現在発生している業務的/技術的依存関係が移行の障害になるとすると、それはどこか？
顧客提供のシステムではビジネスモデルは重要なインプット
顧客に対して販売する機能を提供するシステムのグランドデザインに呼ばれることも多いので、SaaSのマルチテナントの議論をすることがあります。
マルチテナント構造の場合は以下と切り離せません。
どう売りたいか？
どういう機能セットで売りたいか？
全体として担保したいガバナンスは何か？
全体のガバナンスが必要ない領域はどこか？
どこまでテナントの自由を許すか？
オンプレ版がある場合、誰がインストールするのか？逆に自社エンジニアが必ずインストールするなどの縛りは可能か？
今後の事業ロードマップは何か？機能拡張ロードマップは何か？
結局ビジネスモデル全体を議論することになりがちです。
ビジネスモデルやそこで求められるガバナンスモデルは重要なインプットの一つです。
まずはシステム全体のことを考える
NGパターンとしていきなりマイクロサービスごとのことを考え始めると、システム全体で担保すべき非機能要件を見失ってしまいます。
個別最適を積み上げようとする組織は多いですが、残念ながら個別最適の積み上げは全体最適にはなりません。
例えば秒間1万トランザクションが必要というような非機能要件が明確な場合、
1日の間でアクセス数に偏りがないか？週や月ではどうか？
これだけ多くのトランザクションが発生するとすると、どこがボトルネックになるか？
ではボトルネックを解消するため、どこはどの程度のスピードで処理をしたいか？
ここまで来て初めて個別のマイクロサービスの話に移行します。
着目したいのは非機能要件
実装においては機能要件も重要なのですが、アーキテクチャの策定ではどのような非機能要件がそこにあるのか把握し、非機能要件をどう実現するかを定義することが重要です。
例えばA. アーキテクチャビジョンで例とした「プラットフォーム費用の削減とバッチの実行時間の短縮」の例では、
どの機能 (バッチ) でどのくらい時間がかかっているか？
どの機能のところは日中帯でも問題ないか？どの機能を夜間に残さざるを得ないのか？
夜間に残すべきものはどのようにすれば並列処理ができるか？
シリアルに実行しなければいけない箇所はどこか？
締切時間そのものを変更できないか？変更できない場合そこにはどんな制約があるか？
を把握し、締切時間に間に合い、かつ今後のビジネスが中期経営計画の想定通りあるいはそれ以上に伸びた場合に吸収できるようにするため、どのようなスケールアウトを可能にしておくか、その仕組みを考えます。
移行のことは後で考える
ある程度As IsやTo Beが見えてきたり、開発や運用を日常的な業務にしている方々からは、ある程度To Beが見えてくるとどうしても移行のフィジビリティが気になってしまいます。
気になる点はメモなどで残しておき、この段階では将来的なTo Beをどう定義するかに集中します。
議論を進める際は、今は今後何年かけてでも到達したい理想的な状態 (To Be) を気にしているのか、直近のプロジェクトのフィジビリティやリスクを気にしているのかを意識してください。
直近のプロジェクトのフィジビリティやリスクを検討するのはE-Fになりますので、後で別に議論します。
E-F: 製品選定とマイルストーン
To BeアーキテクチャとAs-Isとのギャップが特定できると、ではどのようにしてギャップを埋めるか (How) が議論できるようになります。
ここはよく「プロジェクト計画」と呼ばれます。
E: 機会とソリューション
--> 全体として変更箇所がどこか、どのような変更が行われるべきかを特定。新しいソリューションを採用するのであればソリューションの選定
F: 移行プランニング
--> 一括で移行するのか、段階的に移行するのかを決める。多くの場合は段階的に移行せざるを得ないので、マイルストーン段階のアーキテクチャがどのようであるべきかを決定
B-DのAs-Isの分析結果はEのどのような変更が行われるべきかの特定、およびFの移行のフィジビリティの検討に使います。
いきなり理想形を作るところに着手できるところはあまり多くありません。
まずは技術的負債の返済に集中せざるを得ないところも多いため、現在どう実装されているかの情報は非常に重要です。
ここまでが一般的にグランドデザインフェーズと呼ばれます。
G-H: アーキテクチャのガバナンス
GやHが実際の開発プロジェクトです。
このように進んでいくため、アジャイル開発かウォーターフォール開発かはGの進め方として個別に検討すればよく、Fまでは主にアーキテクチャフレームワークをベースに実施します。
G: 実装ガバナンス
--> 開発プロジェクトが実行されるため、それぞれの開発プロジェクトであらかじめ策定したアーキテクチャに従って実装されているか、乖離がある場合はAで定義したアーキテクチャビジョンに対するリスクがどの程度発生するかを把握し、必要に応じて是正する
H: アーキテクチャ変更管理
--> Gで実装されたアーキテクチャに対して変更が発生する時の変更管理を実施。
Gが実際のリファクタリングプロジェクト、Hがリファクタリング後の機能追加など開発や保守開発フェーズと考えていただくと考えやすいかと思います。
自社内にこんな活動ができるアーキテクトチームがあるともっと良い
最近はやりのTeam Topologiesから実は上記のような活動を支援する類のチーム形態の発表が随分前にありました。
Architecture Modernization Enablement Team (AMET) というパターンです。
これは上記に書いた内容のさらに概要になっており、非常に良い内容ですので英語にアレルギーがなければぜひどうぞ。
なかなかこういうケイパビリティがない組織が多いため、我々のようなソフトウェア会社のコンサルティング部隊がこのような支援ができるチームを立ち上げつつあります。弊社だけではありません。
ただし上記で書いた通り、結構会社の未来を決めてしまったり、ビジネスモデルに踏み込んだ議論が必要なので、なかなか外部から完全に支援を提供するのは難しさが伴うシーンが多いんです。
このようなチームが我々外部の人たちではなく、近い将来に自分たちで要員を確保して支援チームを立ち上げられるともっと良いですよね。
この記事が気に入ったらサポートをしてみませんか？