「みんなの銀行」プロジェクトの開発体制、開発アーキテクチャ
「みんなの銀行」は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つのアプリケーションになるようにビルドする。このようにすることでチーム別に作業ができるだけではなく、ビルドしたアプリケーションが単一なので、ローカルでの動作確認や開発環境の断面管理が容易となるからだ。そして初版がリリースされれば、一度作り上げたアプリケーションを分割し、独立させることで適切なタイミングで個別にリリースコントロールが可能な枠組みに変更するというのである。
「このように大枠の想定はあるが、データベースを後から分割できるのか、分割後のアプリケーションはどうやって協調するのかなど、解決すべき課題は多い。これからも変更耐性のある開発アーキテクチャの実現に向け、チャレンジしていきたい」
最後にこう語り、星川氏はセッションを締めた。
