Labs流 アプリケーションモダナイゼーション
こんにちは、Tanzu Labs PMのWataruです。今回は僕らが普段多く手がけているプロダクト開発、ではなく、既存のアプリケーションのモダナイゼーションについて、その中でも特にSWIFTという手法についてお話ししようと思います。
そもそもモダナイゼーションって何？
みなさんは「2025年の崖」という言葉を聞いたことがあるでしょうか？多くの企業で使われているITシステムが老朽化・肥大化などによってその企業の現在のビジネスの変化についていけなくなり、競争力低下をもたらし経済損失をもたらすという問題のことです。世間一般ではこういった古いITシステムのことを「レガシーシステム」と呼んだりしますが、これらを「モダナイズ/Modernize」、直訳すると「近代化」することで、セキュアで変化に強いアプリケーションに生まれ変わらせること、それをモダナイゼーションと呼びます。
日本のIT界隈では同義語として、システム更改・システムリプレイスなんて言われたりもしますが、対象となるシステムはいつも巨大で複雑、歴史が重ねてきた熟成されたロジックが搭載されており、「ソースコードだけが真実」みたいなことがよくあります。そういったシステムを丸っと刷新しようと思うと、年単位の時間と億単位の予算がかかることが多く、且つビッグバン的なアプローチはなかなかQCDのどの観点から見ても成功することが難しく、デスマーチになる上にユーザー側の満足度もなかなか上がらない、最悪のケースではリリースできずそもそもの問題が解決できないということも少なくないのが実情だと思います。
我々Tanzu Labsではこういった状況に対してもアジャイルで解決していく具体的なアプローチを有しています。
Tanzu Labsのアプローチ方法
- Top-Down ビジネス/業務から
通常ITシステムを作り替える場合は、「どういったソースコードでどういった仕様になっているか？」というボトムアップなアプローチで「現状のシステムを把握する」ことから始めるのが一般的かと思いますが、我々はどういったビジネス・業務を支えているのか？というトップダウンなアプローチで「現状のビジネスを把握する」ことから始めていきます。
- Thin Slice 価値の薄切り
そして、なるべく小さく小さく開発＆リリースしていくことを目指します。一般的にはデータやUIなどレイヤーごとに切り分けながら設計・開発していくこともあると思いますが、我々は「価値」の単位で薄切り(=Thin Slice)にし、いわゆるプロダクト開発でいうところのMVPのようなものを切り出しながら開発を行なっていくアプローチを取ります。
- Co-existence レガシーとの共存
リリースは1度に大きく行うのではなく、2.で切り出したThin Sliceを小出しにする形で進めていきます。それと共に、既存のレガシーシステムと共存しながら稼働させ、徐々にその比率を上げていき、いつの間にか新しいモダンアプリに切り替わっている、というような状態を目指しています。そのため、通常年単位かかるリリースまで数日や数週間で行い、何度もリリースを繰り返していくことになります。
これらのアプローチを実現する具体的な手法として、Tanzu Labsでは冒頭でご紹介したSWIFTという手法を使っています。具体的にどのようなものか、説明していきたいと思います。
”SWIFT”ってどういうもの？
SWIFTとは、モダナイゼーションをアジャイルに行うための手法の総称で、いくつかの具体的ないくつかのプラクティスによって構成されています。
(※SWIFTと聞くとプログラミング言語のSwiftを思い浮かべる人も多いと思いますが、それとは違うものですのでご注意ください。)
上図はSWIFTの概要なのですが、見て分かる通り全体の流れが円状に、つまりそれぞれ1度やったら終わりではなく何度も繰り返しながら行なっていく手法になります。今回はこの中から主要な3つのプラクティスを紹介します。
Event Storming
SWIFTの図の中で2.にあたる工程で、アプローチの1つ目にも書いたビジネス/業務からのTop-Downに通じるプラクティスであるEvent Stormingです。このプラクティスでは、システムが支えているビジネス（業務）の全貌を明らかにすることを目的としており、関係するユーザのビジネスイベントの洗い出しを行なっていきます。
あるビジネスのフロー(≒ユーザーフロー)を取り出し、それにかかるビジネスイベントを時間軸で列挙していきます。例えばフードデリバリーサービスの場合、「ユーザがアプリを開く」→「注文する食べ物を選ぶ」→「届け先を入力する」・・・・「ドライバーが注文をレストランでピックアップする」→「ドライバーがユーザ宅に注文を届ける」のような感じです。ある程度書き出し終わったら、現状抱えているペインポイント(例：検索が遅い、クーポンが使いにくい、など)や外部サービスとの連携(例：OpenIDConnectでログイン、外部決済サービス、など)も合わせて列挙していき、1つのビジネスフローの中身を徐々に明らかにしていきます。
その後、Event Stormingの中で出たそれぞれのビジネスイベントをビジネスドメイン単位でカテゴライズしておきます。例えば、上述のフードデリバリーサービスで言えば、Cart (注文カゴ)、Payment (支払)、Delivery (配達)などいくつか大きな括りのビジネスドメインに括ることができます。我々はこの括りのことをService Candidate (サービス候補)と呼んでいて、次に続くプラクティスにおける重要なインプットとなります。
Event Stormingを実施するにあたってにポイントとなることをいくつかお伝えすると、
- ビジネスフローはビジネス的に最も重要だと思うものから始める。
- ビジネスドメインに詳しい人を呼ぶこと。大勢で認識を揃えながらワイワイやる感じが望ましいです。
- 全てを完璧にしようとせず、80点程度を目指して作る。
という感じです。特に2点目、プロジェクトメンバーに固定せず必要なStakeholderは適宜参加してもらい、認識も合わせながら実施できると理想的です。
Boris
続いては、SWIFTの図の中で4.にあたる工程で、前述のService Candidate同士の関係性やコミュニケーションについて理解するBorisというプラクティスです。この辺から、段々とマイクロサービスやシステムアーキテクチャを少し気にした内容になってくるので、エンジニアサイドがリードしていくとよりスムーズです。
見にくいかもしれませんが、上の図ではService Candidateに加えてUIや外部サービスも1つの付箋として付け加えて、お互いのリクエスト/レスポンスやその関係性の同期/非同期などを分かるようにしています。
フードデリバリーサービスなら、
アプリのUI → Cart (注文カゴ)：注文内容の追加
アプリのUI → Cart (注文カゴ)：現状のカートの中身の参照
Payment (支払)→ Cart (注文カゴ)：最終的なカートの中身の参照
・・・
のようなイメージです。それぞれをAPIに見立てて、お互いどういうリクエストやコミュニケーションをするかを可視化していく、と考えると何をしたいのかより想像しやすいかもしれません。Event Stormingではビジネスのすべてを「イベントの集合」として表現するようになっており(いわゆるEvent Driven Architectureと呼ばれる方式)、このイベントをより細かく記述していくのがBorisと考えることができます。具体的には「どの部署(Service Candidate)からどの部署へのイベントなのか?」「原因は何で結果は何か?」「ビジネス上の『待ち』が発生する(同期的)か否か?」といったことを決定していくイメージです。
Snap-E
最後にご紹介するのは、SWIFTの図の中で5.にあたる工程で、Snap-Eと呼ばれます。これは実はBorisと同時に行います。これは要するにBorisで出てきたService Candidate1つ1つについて、扱うDataや用意すべきAPIなどを書き出していく工程です。オフサイトでやる場合には、下記のように1つのService Candidateにつき1つの大きめの紙を用意して、Borisで線を結んだら同時に他の人がSnap-Eをどんどん書いていくような感じです。
お気づきかもしれませんが、これらはService Candidate(サービス候補)、つまり1つ1つがマイクロサービスになるかもしれない候補、として扱われています。BorisとSnap-Eを通して各サービスが有する機能やデータ、またそれぞれとの関係性を可視化し、実際のアーキテクチャとしてふさわしい形を検討していきます。
まとめ
非常に簡略化していましたが、以上がSWIFTのご紹介でした。Event StormingとBoris/Snap-Eの重要な違いの1つとしてEvent Stormingは技術的なことに一切触れず、Boris/Snap-Eはシステムの実際の動きを考えながら行うということが挙げられます。SnapEまで見れば、エンジニアはほぼシステムの動きが想像できるようになっているのが理想です。つまり、「ビジネス的な要求」を「システム的な要求」に段階的に変換していくのがSWIFTのプロセスと考えることもできるかもしれません。
ここまでの工程、ビジネスやシステムの規模にも依存はするものの、なるべく早く小さく進めていくことを目指していますので、1つのEvent stormingだけを扱うのであれば1週間程度で終わらせるイメージです。その後我々の普段のプロダクト開発と同じく、ユーザーストーリーを書いてXPで開発していく工程に入っていくのですが、Event stormingを複数フロー実施してから開発に入るなど、その辺はプロジェクトとしてやりやすい形を都度取っています。
ただし、あれもこれも可視化してから、という気持ちになるとどんどん対象が肥大化していきます。重要なビジネスイベントのために本当な必要なものから小さく早く作ってモダナイズしていく、という気持ちは忘れずに進められると良いと思います。
いかがだったでしょうか？概念的なことや手法の説明で少しイメージがつき辛いところもあったかと思います。今後実際のプロジェクトの様子なども可能な限りお伝えしていこうと思います。ご興味ある方は是非Tanzu Labsまでお声掛けください！
