20周年を迎えたサービスでビジネスドメインと向き合いモダナイゼーションを推進

モダナイゼーション アジャイル プロジェクトマネジメント アドプラットフォーム事業

どうも、アドプラットフォーム事業で取締役CTOをしている大曲です。毎年、花粉症が辛かったのですが、良い病院に出会い今年は楽でした。

JANetは昨年２０周年を迎えました。この節目のタイミングでトラッキングのモダナイゼーション(PerlからGo言語)することに挑戦しました。
今回のモダナイゼーションでは外部の会社（Tanzu Labs）の支援を受けて推進しました。会社としてもこの開発に大きな投資を行いました。

話すこと

  • モダナイゼーションを社外と一緒に取り組むこと、投資をすることになった背景
  • ビジネスドメインに真正面から向き合い、そこから得られた成果

話さないこと

  • モダナイゼーションの具体的なステップ
  • 開発言語や手法の細かなあれこれ
    • XPの手法であるペアプロ、TDDを徹底的にやる経験をした

背景

改善ポイントがインフラからアプリケーションへ

数年前からオンプレミスからクラウドへの移行を行なっていました。

ちなみにデータベースを移行する前の2〜3年は、Embulkを利用してクラウドにDBをクローンして新機能開発は出来るだけクラウドで出来るようにしておりました。

DBを移行したことで色々な選択が可能となりました。コンテナへの推進ができ、コアな機能の一部（トラッキングの社外連携）をクラウドで完結できるようになりました。開発や構築はクラウドの恩恵もありスピーディーになった一方で細かなアーキテクチャが複雑化していきました。一部ではレガシーを避け、別の基盤で間接的なアプローチをやったり、新しい機能を作るたびに新しいECSのクラスタ構築やマネージドサービスの採用が加速しました。

新しい基盤をたくさん作ることは良いことです。
クラウドの恩恵もあり、スピーディーにできるでしょう。ただし、それがレガシーを避けるためにあったり、ビジネスドメインが似たもののシステムが複数に分かれたりするのはシステムとして複雑性が増し、障害時の原因特定の長期化や開発体験の悪化をもたらす状態でもありました。

これは開発しているエンジニアが悪いというわけではないのです。その時々において最適な判断をしていると思いますが、ビジネスの変化に伴いシステムの意義も変わるのに適応できていない部分が大きいと思います。

インフラ的なクラウド移行が終わり、徐々にアプリケーション側のモダナイゼーションの優先度が高まりました。

事業方針がビジネスモデルを革新する

去年に子会社化を行い、事業としては古き良きアフィリエイト広告を再定義し、新しい価値を創造することをミッションに置いてます。

プロダクトのビジョンでもビジネスモデルの再定義をプロダクトがリードする目標が立ち上がりました。その前段としてJANetではJANEEEシリーズという新たな価値を提供しています。

この長年のビジネスに変化を与える上でも、20年を支えてきたシステムをモダナイズする価値が高まりました。

Tanzu LabsからのSWIFTメソッドの提案

縁あってTanzu Labsのオフラインイベントにも参加しました。

Tanzu LabsからSWIFTメソッド（開発言語ではないです）の提案を受け、現時点でのモダナイズしたいものと手法で重視したい価値が一致すると考えました。そこで、今回のモダナイゼーションではTanzu Labsの支援を受けて推進することにしました。

Tanzu Labsの開発内容の影響は以下の記事が非常に分かりやすいです。

SWIFTメソッドの一つにEvent Stormingがあります。
AWS Dev Daysなどでも発表されており、アーキテクチャをビジネス視点から考えるのに興味があり、挑戦したいと強く思っておりました。（AWSの発表のEvent StormingとSWIFTメソッドは少し違います）

目的

プロジェクト開始前の目的は以下の通りです。
プロジェクト自体の目標は、プロジェクト開始直後に決めました。（OKRとその結果を参照）

項目 Before After
技術の改善戦略の手法を学べる 感覚的にシステムドメインを捉えて技術の改善を実施 Event Stormingを軸としてマイクロサービス化すべきもの、そうでないものを実施
XP・スクラムの徹底 自分たちのみでスクラムを行なっている（他社からのサポートはない）。TDDやペアプロは、頭では分かっているけど徹底することまでは出来ていない 徹底的なXP・スクラムのやり方を体験し、自分たちにとってどこまでが良いのかを判断しアドテクノロジーDivの開発文化として根付かせる動きに繋げる
システムがモダンになる Perlが大半を占めている Tanzu Labsのリソースも活用してシステムリプレイスが推進される。自分たちで継続的に動けるようにもなる

ちなみに会社を挙げての大きな投資でしたので、ただ単なるモダナイゼーションではなく開発組織全体が変わるものを持ち帰ることを強く意識しました。今回のプロジェクトではPdMも参加した形となりましたので我々の開発文化に影響あるように参加メンバーで認識統一をしました。

意識を高めるために。

モダン化のゴールは一部のモダン化のスコープにはなると思うが、 システム設計や開発プロセスは何がなんでも5年後（理想は10年）も通用するモダンな設計を考えぬく。 色々なシンプルさが求められる。疎結合や部分適応をしやすくして変化に適応できるようにする。変わる技術もあるが変化しない技術もあるから。

PdMはどうなるかわからないが、「PdMとはこの動きをやること」だと5年後もブレないPdM像を作る認識でいく。

引用：社内キックオフ資料

SWIFTメソッドの紹介

具体的な内容はこちらの記事を読んでみてください。

  • SWIFTメソッド自体は色々な手法の組み合わせである
    • Event Storming、Thin Slice、Boris、Snap-EはSWIFTメソッドの言葉である
  • このメソッドを通じて段階的にどこをどうモダナイズするべきかを決められる
    • 要件決めのフェーズで活躍するもの

出典:Labs流 アプリケーションモダナイゼーション ”SWIFT”ってどういうもの？

４ヶ月間のプロジェクト結果

2023/12~2024/03までTanzu Labsと並走して進めました。
2024/04からは我々だけでモダナイゼーションを進めています。

タイムライン

出来事をタイムラインでまとめるとこんな感じです。
全てはお見せできないので、付箋の数で雰囲気だけでも伝わればなと思います。

12月がSWIFTメソッドのEvent StormingからSnap-Eまで徹底的に対面でやりました。ここが一番の学びでした。
その後の1~3月はリモートでXPでの開発（TDD,ペアプロ）を行いました。
大きなイベントは無いもののXPの徹底さを体感できました。ここは別の機会に他のメンバーがブログを書いてくれます。また途中で新しいメンバー交代などあり、新しいメンバーへの文化浸透も同時に行えました。

対面でのアウトプットではたくさんの付箋を使い整理しました。

OKRとその結果

OKRは全部で3つ立てました。それぞれのフェーズや目的別でOKRを設定しました。
どんなことを体験したのかイメージできればなと思います。

1, Thin Sliceを使った 機能のインクリメンタル・マイグレーション

Thin Slice 価値の薄切り。

そして、なるべく小さく小さく開発＆リリースしていくことを目指します。一般的にはデータやUIなどレイヤーごとに切り分けながら設計・開発していくこともあると思いますが、我々は「価値」の単位で薄切り(=Thin Slice)にし、いわゆるプロダクト開発でいうところのMVPのようなものを切り出しながら開発を行なっていくアプローチを取ります。

出典:Labs流 アプリケーションモダナイゼーション Tanzu Labsのアプローチ方法

Objective: Thin Sliceを使った機能のインクリメンタル・マイグレーション

SWIFTメソッドの中で決めたThin Sliceを正しくリリースできるまでを意識したOKRです。

Key Result 結果
レガシー・アプリケーションから最低1つのビジネス・クリティカルなThin Sliceを抽出し、新サービスに展開する クリックリクエストを受け付ける機能の開発をリリースできたため達成
選択されたThin Sliceに関連するトラフィックの20%を新しいサービスに正常にルーティングし、残りの80%のトラフィックを従来のアプリケーションに維持する legacy:modernでの比率を75:25にできたため達成
新サービス(Go言語)とレガシー アプリケーション(Perl)の両方で高いレベルの可用性 (99.95%) を維持し、隣り合わせの運用モードでシステムの共存に成功していることを示す 移行直後の１ヶ月は100％のまま
新しいサービス（Thin Slice）が、選択したThin Sliceに関連するトラフィックの20％を処理する期間中に、許容できる応答時間50ms以内（PC90）に示すように確保してください レガシー:35~40ms、モダン:27ms
モダンにすることでより安定化しました。もちろん負荷テストでもパフォーマンスは上がってます
レガシーモノリスと新しいマイクロサービスの共存を監視・検証し、最低99.99%のデータの一貫性と整合性を確保する 受け入れテスト基盤を活用し、0.04%の差があるも全てに理由付けができ不明なリクエストはない
ほぼ100%一貫性があると言えた
ビルド、テスト、デプロイの各フェーズをカバーする包括的なCI/CDパイプラインを確立し、自動化する。パイプラインの自動化率を90%以上にする 開発当初は77%だったが、90.9%以上に改善し達成。レガシーは5~15%。

受け入れテスト基盤とは

Perlのレガシーシステム対策として本番に近いテストを実現するため基盤です。
これを活用することでトラッキングの追加開発やクラウド移行での最終確認として利用していました。
正直、いくらリプレイスをしても、全てのPerlのコードが無くなるわけではないのでこのような基盤にクラウド移行時に投資をしました。

  • 本番データを複製（Embulk）
    • 個人情報に関わるものはマスキング
  • 本番のリクエストを複製（Go Replay）
    • トラッキング処理を行うサーバの一部にGoReplayをインストールしておき、必要なテストに応じて数時間から数日をキャプチャリングを行う

Perl同士を比較するためにVerifyとProdを比較しておりましたが、モダナイズに伴いModernを構築しProdとModernを比較するようにしました。

以下は受け入れテスト結果の例です。最初はいくつか仕様漏れがあり随時対応していき、最終的にほぼズレがない状態でのリリースが出来ました。

# リリース直前のもの
Response diff : 58/137679
 - Legacy performance 24 (including 2 errors)
 - URL valid 6
 - UA check 27
 - Error handling 1 (Legacy: JANet top Modern: Site URL) -> No problem
Data diff : 22 / 128052
 - Legacy performance 22

パイプラインを可視化する際はP2P=Path to Productionを使いました。
開発プロセスのバリュー・ストリーム・マッピングみたいなものです。開発当初でも十分自動化率は高いですが、P2Pを用いることでもっと自動化の余地がある部分は再認識できました。（やりすぎは良くないですが、サクッと自動化できる部分を変に残すのは違う）各リポジトリでもこれを使い技術スタックや開発ステップを可視化したいと思いました。

2, JANetのアプリモダナイゼーション戦略と想定アーキテクチャの定義

Objective: JANetのアプリモダナイゼーション戦略と想定アーキテクチャの定義

継続的なモダナイゼーションの取り組みが実施できるように戦略付けに必要な動きが出来るのかを確認するOKRです。

Key Result 結果
ビジネスへの影響と技術的な実現可能性を考慮し、モダナイズのための将来のThin Sliceを少なくとも3つ特定し、優先順位をつける 4つに分解でき達成
初期の移行においてBoris/Snap-Eの優先順位付けと文書化を行い、クリックトラッキングプロセスの少なくとも40％をカバーする
全クリックトラフィックの80%をカバー 		プロセスは70%、トラフィックは97%カバーでき達成
想定アーキテクチャ (Boris) と詳細ドキュメント (Snap-E) を、プロジェクト開始後3週間以内に、Thin Sliceの100%について完成させる 最初のリリースに8週間かかったため未達成
すべてのThin SliceのADR(=Architecture Decision Record)を文書化し、共有する。やるべきADRのうち90 %が完了すること Go言語やSQSなどADRの記載完了

Event Stormingでは12月に3回、3月に1回やりました。

BorisはSWIFTメソッドを繰り返すことで追加されていくドキュメントになりますが。一番最初はこの程度か〜と落胆していた部分もありましたが、徐々に大きくなりセンスが問われるな〜と意義を感じながらビジネスドメインに対してチームで議論しました。新機能開発で新たなドメインが出来た際もBorisを更新するようにしたいと思っています。

1回目のBoris

4回目のBoris

3, イネーブルメントと適用

Objective: イネーブルメントと適用

Tanzu Labと並走することで我々のスキルが向上したかを認識するためのOKRです。

Key Result 結果
Event Storming、Boris、Snap-E を含む SWIFTメソッドのファシリテーションをアドウェイズチームメンバーがリードするセッションを少なくとも2回開催し、参加する ３回実施完了
契約開始時と終了時にアドウェイズチームによる自己評価を実施し、レガシーアプリケーションの残りの部分をモダナイズするためのSWIFTのスキルについて、最終的な平均スコア3.5以上を達成する 平均スコア4.08達成
契約開始時と終了時にアドウェイズチームによる自己評価を実施し、アプリケーションモダナイゼーションおよびXPにおける専門知識3.5以上を達成する 平均スコア4.32達成
契約終了後、アーキテクチャ・パターンとレシピの文書化において90%以上の完成度を達成する レシピを15作成(Golang,ACL..etc)

SWIFTメソッドについて手順書をまとめました。細かく手順をまとめ、これをそのままやれば自ずとアウトプットは出せるようにしてあります。SWIFTメソッドはルールが細かく決まっているのではなく、ある程度の柔軟性がある取り組み方になっているため回数をこなして経験を積むためにも出来るだけ細かい手順を残し後々自分たちにとって良い落とし所を見つけられるようにしました。

開発の中で出てきたツール選定やプラクティス、方針などをレシピとして残すようにしました。
アドテクノロジーDivには、新機能開発を行うプロダクトチームと技術負債を解消する技術改善チームがいます。
モダナイゼーションは技術改善チームがリードするため、改善した結果をプロダクトチームに還元するためにレシピなどの技術的知見を残すための取り組みに挑戦しました。

やってみてどうだったか？

Event Stormingは有効的だが難しい

どんなケースで有効か。

  • ビジネス的に色々なパターンがある場合
  • 過去のモダナイズの取り組みの中でシステム的な歪みが生じている場合

ビジネス的に色々なパターンがある場合

広告のトラッキングには一つのみではなく、常に複数の種類があります。
時にはビジネス種類だったり、トラッキング手法だったり、広告商品のジャンルごとで異なったりします。エラー処理も状況によって数多くあります。大半は同じ処理を行うはずなのに、ちょっとした差がより複雑性を増したりします。

そんな時にEvent Stromingベースで整理することで現状のビジネスにおいて何が価値を生み、何が価値を生まなくなったのかを把握・整理できます。

今回のトラッキングにおいてもいくつかのロジックのビジネス価値を見直したことで削除できたロジックがあります。エンジニア目線では、細かいエラーハンドリングまで考えてしまいます。ただし、重要なのはコアな体験である正常なフローであり、それを軸に考えると感覚的に複雑であると感じていたフローも切り分けることができ、シンプルに考えられるようになりました。

過去のモダナイズの取り組みの中でシステム的な歪みが生じている場合

今回学んだSWIFTメソッドの理解を深めるために、別サービスでEvent Stormingを行いました。そのサービスではある画面をオンプレミスとクラウドでそれぞれのAPIで制御しており、フロントエンドで各APIを処理しておりました。それをEvent軸で整理することでAPIとして統一できる部分を見つけることが出来ました。
そのプロジェクトではとりあえず全てをクラウドに移行することがメインでしたので、APIの再定義まではやりませんでしたが、モダナイズできる余地を発見できた良い機会でもありました。このようにその当時は良かれと思ってモダナイズを進めていたものでも、徐々に時間が経つことで新機能や改善が進んだことで別の切り口での歪みを発見できました。

難しい観点

  • イベントの粒度はプロジェクトによって様々であるため柔軟性が求められる
  • 全てを整理したいという誘惑に駆られる

イベントの粒度は、プロジェクトによって様々であるため柔軟性が求められる

Event Stromingはエンジニアだけではなく、ビジネスサイドやPdMも含め実施します。そうすることでビジネス視点を取り込みますが、イベントの粒度はプロジェクトによって様々だと思います。今回のトラッキングでは粒度が大きいユーザー体験からテクニカルなロジックまで詳細を洗い出しました。これはトラッキングの特性上、細かいテクニカルなロジック（Cookie処理）も含め洗い出すことで価値の再確認ができました。

しかし、別サービスで実施したときは裏目に出ました。細かく出し過ぎたことでチームの議論がAPI設計の話になり過ぎました。この時はエンジニアだけでEvent Stormingをやったためそれらの悪影響でもあるかもしれないです。
どこまでのイベントを洗い出すべきかはプロジェクトによってうまく工夫をしながらやる必要があります。これらは経験を積むのが一番だなと思いました。Event Stormingをセールスサイドも含めた実施の経験は出来ていないです。ぜひ、挑戦したいと思っています。

全てを整理したいという誘惑に駆られる

前半に記載がありますが、Google検索で出るEvent StormingはSWIFTメソッドのものとは異なります。オリジナルのEvent Stormingでは全てのイベントを洗い出し、そこからプロセスモデリングを行います。
参考：https://speakerdeck.com/fatsushi/aws-dev-day-2023-e-3?slide=24

SWIFTメソッドでは軽量的なEvent Stormingであり、時系列にイベントを整理し、Borisでドメイン同士のコミニケーションを明確にします。そのためプロセスモデリングで行う「コマンド」「ロール」「リードモデル..etc」は設定しません。

必要なイベントを必要な分だけ整理するのがベストであるSWIFTメソッドではあります。ただ、システム全体の理解も含めとりあえず、重要だと思うイベントを洗い出したいなと思う時はありますが、ここは堪えて一歩一歩少しずつやるだけなのだろうと考えてます。

Borisを活用したシステム全体の概念整理の運用はこれから

SWIFTメソッドのBorisは、システム全体の概念を表したものであるべきなのでモダナイズの動きだけではなく、新機能開発を通した新たなドメインも取り込むようになります。

ある新機能開発でEvent Stormingに近い形でユーザー体験を整理し、新たなドメインを定義してBorisに更新することにしました。ただ、これが適切な粒度であるかは疑問が残りました。新機能にのみ視点を置くのなら適切に思いますが、関連したイベントも他にあるのではないかと感じました。これに関しては、新機能開発を通して既存のビジネスドメインとの統合などを考える必要があると思いました。

また、モノリシックなシステムをマイクロサービス化するためのSWIFTメソッドであるが、モジュラーモノリスを念頭に置いた構成図ではないです。そのため、ドメインの候補となるものは常に忘れないようにどこかに留めておく必要があります。

現状の組織タイミングにおいてSWIFTメソッドがベストであると考えている

自分がMGRとして組織をリードし始めた頃と比べて、メンバーの人数も増えシニア層も増えました。冒頭の背景にも記載をしましたが、クラウド移行（＝インフラのモダナイゼーション）は着実に進んでいてハイブリット（オンプレとクラウド）で運用するフェーズが終わりに近づいています。後は、クラウドネイティブに進むだけであるため、目下の課題がインフラからアプリケーション面に変わりました。ただ、クラウドだからアプリケーションが自然と良くなるわけではないです。

SWIFTメソッドを活用し、システムをビジネスドメインから正しく捉えることが出来るから、新機能も自然と統廃合される動きになることでより保守性を高め、開発速度を高められると信じています。

経験上、正しく統廃合をしないとレガシーよりも開発体験が悪くなる（マイクロサービス化しすぎて結局辛いとかもある）と考えています。

技術改善チームをリードする身として何かをリプレイスと言ってただ言語が変わっただけではなくて、ビジネス（ビジネスイベント、ユーザー体験）にあったシステムに作り変える動きを適切に推進したいと思っています。技術改善チームだからこそ、技術の関心事に籠るのではなく、過去と未来のビジネスを理解した上で新しいアーキテクチャを目指す組織になれたらいいなと思っています。

まとめ

書きたいことはまだまだたくさんありますが、今回の記事でどんな目標に向き合いビジネスからシステムを考えることについてどう考えているかを頑張って書きました。

会社としても大きな投資をしたモダナイゼーションでした。Tanzu Labsと共に一緒に取り組むことは良かったと思っています。

今まで20年を支えてきたシステムに敬意を払いつつ、次の20年を戦える基盤にするために今後もビジネスと向き合い続ける技術改善を推進できればと思います。

Tanzu Labs側でまとめてくれたインタビュー記事はこちらです。

こちらも是非ご一読いただけますと幸いです。