変えるべきところ、守るべきところを意識したアーキテクチャ設計とは？

クラウドネイティブな金融システムの開発をアクセンチュアのアーキテクトが語る

ディスカッションの質が上がり、醸成されたカルチャーはお客様にも伝播

大谷：さて、今回のシステム開発に関わって、個人やチームの成長や達成感があれば、教えてもらえますか？

角山：マイクロサービスで構築されたクラウドネイティブな銀行のシステムを構築し、マルチクラウド、マルチリージョンで運用するという最初の目標は達成できたと思います。

ただ、サービスを成長させ、ユーザーを獲得するために必要な機能を考えると、やはり足りないものはあるなあと思います。たとえば、クラウドの障害が起こったりすると、アーキテクチャはもっと突き詰める部分があると思いますし、迅速に機能を改善・変更できる体制や品質を担保できる仕組みが完璧にできているかというと、これはまだ発展途上です。実際、開発はまだまだ続いていますし、前のフェーズでやりきれなかったことや新しい課題は、次のフェーズでチャレンジしている感じです。

アクセンチュア 角山恵介氏

大谷：星川さんはどうですか？

星川：チャレンジについてはまさに角山さんが言っているとおり、これからも続けていくんですが、今回感じたのは改めて分散システム難しいなあと（笑）。データ整合性を考え、しかもミスが許されないとなると、やっぱりマイクロサービスとして単に切り分けるだけじゃダメだなと感じています。そのジレンマとどう向き合うか、どう割り切るかは、自分の中でも成長したと感じた部分です。

あとはこの規模の開発なので、当初は各チームをどれくらいケアすればよいかわかりませんでした。私のチームはいろいろなチームに対する技術的な相談役だったりもしたので、とにかく高圧的になってはいけない。気軽に相談してもらえるにはどうしたらよいか考えたし、時にはなにも言われていないのに話をしにいったりしました。コロナ禍でみんな籠もりがちだったので、オープンな環境をいかに作るかはけっこう意識しました。

大谷：そういう意味では、コミュニケーションやチーム開発のスキルが上がったのかもしれませんね。阿部倉さんはどうですか？

阿部倉：やはりチームとしてのディスカッションですかね。

アーキチームの視点で言うと、今回はけっこう複雑なアーキテクチャでしたし、ウォーターフォールみたいに最初に決めたものを淡々と開発するという進め方ではなかった。だから、アプリチームがどんどんスプリントを回していく裏で、アーキチームもどんどんシステムのアーキテクチャをブラッシュアップしたり、検討が追いつかなかった部分を検討していきました。とにかく課題が生まれたら、それに対するアーキテクチャをひたすら設計していく感じでした。

じゃあ、これをアーキテクトチーム数十人で実際どうやっていたかというと、週に2時間の定例枠を設けて、みんなで課題を持ち込んでもらう。その上で、解決方法についていろいろディスカッションして、得られた回答をお客様に説明してさらにディスカッションしたうえで、承認をいただくというやり方です。このディスカッションの準備や回し方が以前に比べてすごくよくなったと思うんです。

大谷：アーキテクトチームのメンバー自体が成長したんですね。

阿部倉：最初はリーダークラスが自分で資料を用意し、話して、自分たち同士で解決法を提示するような感じだったのですが、今は若いメンバー主導で資料を持ってきたり、説明するようになりました。デリバリーのカルチャーの醸成と若いメンバーの成長が実現できたのがよかった。

星川：時間が限られているので、論点をミスると議論が発散してしまいます。だから、自らストーリーをきちんと考えて、どこまで決めるかも事前に明示するようになったメンバーもいます。

大谷：なるほど。話の進め方や議論の回し方がうまくなったということですね。

阿部倉：結局、修正点を改善しないと、システム開発・アーキテクチャのプロフェッショナルであるお客様からも指摘を頂くことになります。だから、内部できちんと議論をし、アイデアを整理して進めなければなりません。

星川：お客様とのミーティングより、内部の方が厳しいって話がありましたよね（笑）。内部ミーティングで鋭い指摘が飛ぶようになったので、逆にお客様から指摘をいただくことは少なくなったと思います。

阿部倉：われわれがそういったミーティングで事前に”もんで”から提案しているのをお客様も知っており、今では課題の緩い段階からお客様とアーキテクチャのあるべき姿をディスカッションし、一緒にアーキテクチャを作り上げていく感じになっています。

大谷：それは素晴らしい！お客様とともにカルチャーを醸成しているのですね。