「スケーリング」という概念をシステム開発時に適用
「アプリケーションやサービスをリリースして、利用者が増えていったとき、サーバの台数を増やすなどのスケーリング作業を行う。これによってアプリケーションとサービスの単位時間当たりの価値が効率化されていく。同じようにスケーリングという概念をシステム開発時に適用するとしたら、どのようにすればよいのか。これは難しい質問だと思う」という問いかけから、星川氏のセッションは始まった。
星川氏は2014年にアクセンチュアに新卒で入社し、以来、カスタム開発で利用するアプリケーションアーキテクチャの開発及びメンテナンスに従事している。
システムはスケールアウトもしくはスケールアップすることで対応できるユーザ数を増やし、効率よくサービスを提供することができる。一方、システム開発において単位時間における開発のアウトプットを増やし、効率よく開発する方法はいくつか考えられる。開発者の数を増やしたり、システムを細かく分割したりするアプローチが一例だ。だがこれらのいずれにおいても「そうそううまくはいかない」と星川氏は語る。では開発効率を上げるアーキテクチャはどのようにすればよいのか。星川氏が携わった「みんなの銀行」プロジェクトは、10人から250人規模のプロジェクトにスケーリングし、高い効率で開発を実現したという。
「みんなの銀行」開発プロジェクトが立ち上がったのは、2018年10月。ちょうどFinTechという言葉が流行っていた時期でもある。「ヨーロッパ中心に勃興したチャレンジャーバンクと渡り合える銀行を作りたい」、そんな思いから、今あるIT技術でゼロから銀行を作ることになったという。
チャレンジャーバンクと競争できる銀行を作るため、アーキテクチャはどうあるべきか。これはプロジェクト立ち上げ時から考えていたという。
求められる要素の第一はクラウドネイティブであること。2018年でもクラウドは一般化していたので、「オンプレミス前提はあり得ないと思った」と星川氏。第二にアジリティのある開発が可能なこと。既存の銀行の基幹システムは変更するのが難しい状況になっている。「マーケットの反応を見ながらアジリティのある開発ができなければならないと思った」と星川氏。第三は堅牢かつセキュアであることだ。「この3つの条件を満たし、スケールする銀行を作ることが最初の検討事項だった」（星川氏）
これらの要素を持っている既存のパッケージやソリューションをいろいろ探したが、近しいものはあっても決め手に欠けていた。そのため、「フルスクラッチで基幹システムを開発するという判断が下った」と星川氏は説明を続ける。
この要件を満たすべく開発されたのが基幹システム実行アーキテクチャ「MAINRI」である。MAINRIはマイクロサービスアーキテクチャを採用し、将来的に必ず分割できるアーキテクチャで構成されている。また同アーキテクチャは早期からGCPを活用していくことが決まった。GKEを使ったコンテナのオーケストレーションで、開発言語はGo、通信インタフェースはgRPCを採用しているところが、「技術的に面白いところ」と星川氏は胸を張る。
それ以外も、GCPのサービスであるDataflowの実行フレームワークに、Apache Beamも採用しているバッチアーキテクチャを採用。それによりスケーリングが可能で、かつ高速に作れるようなアーキテクチャを目指すことにしたという。
「みんなの銀行」プロジェクトの開発体制、開発アーキテクチャ
「みんなの銀行」は1月4日に銀行システムの稼働を開始した。「サービス開始はこれからですが、すでに銀行としては機能しています」と星川氏は話す。
みんなの銀行は前述したようにゼロから作った銀行である。そのため「類を見ない開発となった」（星川氏）という。銀行の開発において、関わるのは開発エンジニアだけではない。「いろんなチームが関わっていくため、250人以上、もしかしたら300人を超える人たちが同時に関わったプロジェクトになった」と星川氏は明かす。
250人を1チームにすると非常にタフになるため、複数のチームに分割。アプリ開発チームはおよそ10チームで構成され、各チームの人数は約10人。多いところでも30人ぐらいとし、ビジネス要件を元に開発するサービスによって、チームのサイズを変えたという。そして各アプリ開発チームがビジネス要件の実装に集中できるようアーキテクトチームを組成。横断的に開発チームをサポートすることで、統率の取れた開発を実現できるようにしたという。
このプロジェクトのユニークな点は、当初からマルチロケーションでの開発を採用していたこと。新型コロナウイルス感染症拡大を抑制するためリモートワークを加速させる動きはあったが、元々アクセンチュアの開発メンバーも東京、北海道、福島・会津の拠点に分散していた。さらにみんなの銀行の企画立案をしたのはふくおかフィナンシャルグループであり、同グループのIT子会社であるゼロバンク・デザインファクトリー（所在地は福岡）も共同で開発を進めてきていることも、マルチロケーションでの開発を行った理由だ。そのほか、開発には中国やフィリピンといったオフショアの開発者も参画している。
このように「みんなの銀行」開発プロジェクトにはさまざまなバックグラウンドの人が関わる。アーキテクトチームとアプリ開発チームのコミュニケーションを円滑にするため、OSSを活用しつつ、カバーできない部分はプラットフォームをゼロから開発した。
ADOP（Accenture DevOps Platform）は、標準的な開発で使われるOSSをセットにしたプラットフォーム。「Redmineでチケット管理、GitLabでコード管理、Jenkinsでパイプラインの指定、Nexusで成果物を管理し、コミュニケーションはSlackを活用するというモダンな開発プラットフォームになっていると思います」（星川氏）
これだけでも十分プロジェクトを回すことができるが、カバーできない部分があるため、スクラッチでもう一つプラットフォームを作ったという。それがADIP（Accenture Data Integration Platform）だ。マイクロサービスアーキテクチャでは、各サービスの相互連携が重要になってくるため、どのデータがどのように配置されているのかを一元管理することがポイントになる。ADIPは、各チーム横断で、データモデルを登録・参照することのできる開発プラットフォームだ。
ADOPではRobotPMOを活用し、Slackをハブとした開発時のコミュニケーションに役立つ機能を提供するなど、「独自のカスタマイズは入れている」と星川氏。例えば対応期限のリマインドについてメンションを飛ばしたり、GitLabと連携してレビュー依頼のコメントにタイムリーにキャッチアップできるようにしたりしているという。
利用するアーキテクチャは共通化されており、「学習アセットとともに開発ガイドラインも整備している」と星川氏。このようにすることで、育成をサポートし、開発者のチーム間移動もスムーズになる。
続いて星川氏は、今回の「みんなの銀行」プロジェクトについて、開発体制としてはどんな体制だったのだろうかと振り返った。
今回のプロジェクトでは、アーキテクトとアプリ開発チームは別の体制とすることで、横断的に対応するという中央管理型の開発アーキテクチャになっていた。メリットはあるものの、その一方で、アーキテクトチームでしか解決できない問題も発生するため、開発チームの独立性が低下すると言う問題が発生する。仮にアーキテクトを各チームに分散する体制にすれば、各チームの独立性は高まるが、局所最適解の発生率が上がるため、横断的な対応には工夫が必要になる。いずれもメリットデメリットがあるため、「プロジェクトの性質によって、中央管理型、分散体制のいずれかを選択することお勧めする」と星川氏。
今回のプロジェクトでは中央管理型を採用したが、「リリースした後に各チームが独立できるような、変更耐性のある開発アーキテクチャを作れないか考えている」という。大規模な開発になればなるほど、チームを分割しても横断的にサポートするチームの存在が必要になってくる。だがリリース後にマーケットのニーズに応えながら開発を行うのであれば、開発チームの独立性を高めてベロシティの安定化およびリリース頻度の向上に努めたいと思うからだ。「あくまでも仮説」と前置きした上で、星川氏は変更耐性のあるアーキテクチャの構想を披露した。
分割を前提としたアプリケーションにすると、リリース後にアジリティを高められると想定する。つまり初版リリースまでは各チームが協調、リリース後に各チームが独立することで、フェーズごとに開発がスケールしやすくなる。
具体的な開発体制としては、まずは各チームで個別に作業ができるようにリポジトリを分割し、すべてのリポジトリの資源を集めて1つのアプリケーションになるようにビルドする。このようにすることでチーム別に作業ができるだけではなく、ビルドしたアプリケーションが単一なので、ローカルでの動作確認や開発環境の断面管理が容易となるからだ。そして初版がリリースされれば、一度作り上げたアプリケーションを分割し、独立させることで適切なタイミングで個別にリリースコントロールが可能な枠組みに変更するというのである。
「このように大枠の想定はあるが、データベースを後から分割できるのか、分割後のアプリケーションはどうやって協調するのかなど、解決すべき課題は多い。これからも変更耐性のある開発アーキテクチャの実現に向け、チャレンジしていきたい」
最後にこう語り、星川氏はセッションを締めた。
