KDDIのアプリが直面した「肥大化」と「モノリシック」の問題　組織やチームに寄り添って課題を解決する重要さ

KDDIビジネスオンラインサポート

岡澤克暢氏（以下、岡澤）：ここから説明者が変わりまして、法人向けサービスにおけるマイクロサービス化ということで、佐々木が説明いたします。佐々木さんよろしくお願いします。

佐々木徹氏：（以下、佐々木）：KDDIの佐々木が法人向けサービスにおけるマイクロサービス化として、事例を紹介いたします。本日紹介するプロダクトですが、KDDIビジネスオンラインサポートという、法人のお客さまに提供しているポータルサイトになります。

みなさんご存知のとおり、KDDIは通信会社ですけど、その上で利用していただくoffice 365とかG SuiteといったSaaSの製品も販売しており、KDDIから購入いただくと、このポータルサイトもセットで提供されます。現在約4万社、15万IDのお客さまに利用していただいています。

左下に、自社の契約状況を可視化しました。お客様さまの中で、人数の入れ替わりとかがあるかと思いますが、そうしたライセンス数の変更をこちらの画面から申し込むことができ、各サービスに自動で即時反映されるポータルになっています。

こちらは先ほど岡澤から紹介がありましたけれども、KDDI初のアジャイルプロジェクトとして開始されて、今7年目ですね。継続して機能開発を実施しています。こちらのポータルの開発チームの体制と基盤について、少し紹介いたします。

「アプリの肥大化」とモノリシック・アプリの問題

こちらのチームは、日本とベトナムのオフショア先のエンジニアを合わせて、現在50人強が1つの基盤上でアプリケーションを開発しています。

左下のとおり、当初は1チーム5名程度から始まったんですけど、現在は5つのアプリチームとインフラチーム、さらに基盤を改善するチームの合計7つのスクラムチームで開発の運営を回しています。こちらはKDDIのIaaSサービスであるKCPSの基盤上で構築されており、お客さまに安定してポータルサイトを利用していただいています。

ただ、もともとアジャイルというかたちでアジリティを求めていたにもかかわらず、6年、7年と長年開発を続けていくと、チーム拡大とともにアジリティが低下する問題に直面しました。課題としては大きく2つあります。まず1つ目がアプリの肥大化。7年も継続していると当然コード量が非常に大きくなって、アプリケーションをビルドするのにも何時間もかかってしまうと。

あと、1つのアプリケーションで大きく開発することを「モノリシックな構成、アプリケーション」とか言いますが、1つのモノリシックなアプリを7つのチームみんなでいじくると、当然衝突などが発生するので、そこの調整コストが発生したり、意図しない変更が他チームに影響を与えることがあります。そういった調整コストを下げる必要がありました。

続いて、OSやミドルウェアのEOSLですね。サービスイン当初は最新のピカピカなもので揃えていても、これだけ時間が経ってくるとすべて軒並みEOSL。何度改善しても、またさらにEOSLがやってきて、開発チームがユーザー価値に集中できない状況に陥ってしまいました。

マイクロサービスアーキテクチャとサーバレスによる負荷軽減

これら2つの課題を解決するために行ったことが、本日お話するマイクロサービスアーキテクチャとサーバレスによる負荷軽減。この2点を実施いたしました。ただ、こちらを実際にやろうと思っても、一気に今まで作り上げてきたものを、左から右へドンと移行するのは、非常にリスクを伴います。そこで、解決したい課題にフォーカスして、段階的に進める戦略を採りました。

左下にコンポーネントの図が書いてあるかと思うんですけど、こちらのポータルサイトは、大きくポータルとしての機能と認証基盤があり、それをセットで提供しています。ここ6、7年の開発を振り返ると、こちらのポータルが非常に更新回数が多い一方、認証基盤で求められるのは安定性で、更新頻度は求められていませんでした。

そこでポータル側は、数々のマネージドサービスをもつAWSに移行。逆に認証側は、高い稼働実績をもつKCPSで構築を継続利用するかたちで、マルチクラウド構成にする戦略にしました。

続いて、アプリケーションのポータルの部分です。こちらも非常に多岐に渡る機能をもっているので、やはり一度に全部移行するとなると、相応のリスクを伴います。そこで数ある機能の中から、もっとも優先順位が高く、他の機能との結合度の低いアプリケーションを段階的に移行することによって、移行のリスクを低減しました。

さらに、開発チームとしても、これまでKCPSを使ってきたチームがいきなりAWSを使うのは非常に心理的にも負担がかかるので、こうしたリスクを下げつつ、新しいものを学習してチームが楽しく開発できるように進めてきました。

その結果、当初の目的だったアジャイル開発というところでアジリティが復活して、さらなる価値提供が可能になっています。

組織やチームに寄り添って課題を解決していくことが重要

では最後に、私からのセクションのまとめを簡単にしようと思います。私の場合は、組織やチームのかたちに寄り添った課題を解決していくことが、非常に重要かなと思っています。本日はサーバレスやマイクロサービスアーキテクチャなど、非常にバズってるものを使いましたが、こういったものを使うと、手段と目的が入れ替わってしまうこともあります。

なので、我々はいったいどんな課題に直面しており、それをどう解決していったらいいかにフォーカスをして、考えて進めていくべきではないかと考えています。

アジャイル開発の場合、ビジネスやプロダクトの成長が非常に重要なキーワードになります。それと同時に重要なのが、そこの成長に伴って、開発者も一緒に成長して、楽しんでお客さまに価値提供していく、という考え方です。

本日登壇した内容はブログでも公開しています。「KDDI マイクロサービス」と検索していただくと、KDDI Cloud Blogがヒットしますので、そちらを参照してください。同時に、こちらのブログは、運用しているアイレットさま、また、アーキテクチャの支援していただいたグロース＆アーキテクチャチームスさまにも、同時に公開をしていますので、そちらも併せてご覧ください。

では私からの紹介は以上としまして、続いてコンシューマ向けサービスの事例としましてKDDI須田が紹介します。

（次回につづく）