各社で役割を分担しながら開始 アプリ開発の具体的なプロセスとは
――今回のアプリ開発は、どのような経緯や体制でスタートしたのですか？
濱津 このプロジェクトはもともとアクセンチュアと一緒に開発をスタートしています。みんなの銀行のメンバーがやりたいことをもとに、それを実現するための開発要件をアクセンチュアと整理。その内容にしたがって開発を進めていきました。当初は、銀行機能の大部分の開発をアクセンチュアが担っていましたが、アプリ開発が進むにつれ、私を含めたエンジニアが徐々にゼロバンク・デザインファクトリーに入社し、このプロジェクトにもジョイン。そんななか、まずはシステムを理解するためにゼロバンク・デザインファクトリーのエンジニアが何名かアクセンチュアのスクラムに入り、一緒に関わっていくという形から取り組みが始まりました。
新たに加わったエンジニアたちが問題なく稼働できるようになった段階から、アジャイルで取り組んだほうが良さそうなものや、作りながらブラッシュアップしていきたい部分をゼロバンク・デザインファクトリーが受け持つことに。そうした文脈から、アプリで自分が使ったお金を振り返るサービス「レコード」からまずは開発することになり、昨年2020年の夏からスクラムチームとしてスタートしました。このレコードサービス開発が、ゼロバンク・デザインファクトリーとして初めての単独内製化プロジェクトになります。
具体的な進めかたとしては、中村を筆頭にデザイングループのメンバーがみんなの銀行の業務面を担うメンバーとともに、アプリケーションの方向性や画面遷移、情報の要素などをざっくりと決めていきました。それに従い、実際にどのようなルックアンドフィールが良いのかを考え、ビジュアルに落とし込んでいく。ここは主に、デザイングループと業務側のメンバーが確認を行いました。
できあがったデザインをベースにどのような機能があるべきなのか、ファンクションはサーバーかモバイルかどちらに入ったほうがいいのか、システム設計としてどのような構成にするのかなどを検討。システム設計のフェーズでは7割ほどをアクセンチュアが担当し、その後のスクラムからはゼロバンク・デザインファクトリーが基本的に主導していきました。
豊島 僕は最初にアクセンチュアのスクラムの一員として参画したメンバーのひとりで MAINRIと呼んでいる勘定系部分の実装を担当していました。2020年末頃から内製開発にシフトし、レコードの開発を担当。現状は、内製のスクラムチームのひとりとして開発をしています。全体の開発体制としては、マイクロサービス単位で各チームが独立して開発進行を行っているため、それがスクラム単位とほぼ等しい形になっています。
何度も重ねた議論 開発過程でも大切にしたのは「コンセプト」
――アプリ開発でこだわった部分はありますか？
豊島 とくにモダンなシステムでは原則的に確定した仕様はないと僕は考えているので、変化に柔軟な作りが大切だと思っています。その意味でも我々が仕様を決めてしまうのではなく、ソーシャルメディアなどの声を集めて仕様を進化させていく「みんなの『声』がカタチになる」というコンセプトは、とても現代的なアプリ開発の考えかたとマッチしていると感じています。変化に柔軟に対応していくためには、コンポーネントや依存し合うサービス同士が可能な限り疎結合な作りこみであることが不可欠です。コードを書くうえでは、基本を大事に、とくにSOLIDの原則は常に心がけています。
あとはリファクタリングによる改善のチャンスがあれば、妥協しないことです。一方で優先度や現実とのバランス感覚も重視していますが、ちょっとした改善に過ぎないからと言って簡単には切り落とさないマインドセットにもこだわっています。
中村 「シンプルでミニマル」がみんなの銀行の起点になっているので、お客さまが迷わずに操作できるよう、基本的にUIやUXはシングルページシングルアクションで作るようにしています。たとえば情報の入力フォームでは、名前や住所、生年月日が1ページに並ぶことが多いかと思いますが、ページ数が増えてもしっかり入力にフォーカスできるよう、ブレイクダウンしました。
また、情報をどのように見せるかにもこだわりました。銀行は非常に情報量が多く、要件として必ず記載しなければならないものもたくさんある。それらをお客さまがみたときに面倒だと感じないよう可能な限り文字を削ったり、情報をまとめ、ひとつのアクションで完結させるなどの対応を行いました。
――アプリ開発で、とくに大変だったことはありますか？
濵津 今回のアプリ開発のひとつの特徴ともいえるのが、ほかの開発案件に比べてデザインへの熱量が非常に強かったという部分です。僕らエンジニアでは見比べても違いがわからないような細部まで、何度もビジュアルの手直しを行いました。
なかでもとくに大変だったのは、デザイナーが使用しているツールで指定したグリッドの数字どおりに開発を行っても、実際にスマホで見てみると想像しているデザインにはならないという点。これはいまでも課題に感じている部分のひとつです。その誤差を埋めるべく、少しずらしてはデザイナーと一緒にスマホで確認するといったやりとりを繰り返しました。感覚的な調整も必要だったので、時間と根気の必要な作業でしたね。
豊島 ウォーターフォールとアジャイルのハイブリッドのような形で開発を進めてきたため、それに起因する設計やテスト行程の考えかたの部分で、フリクションもありました。上流でのシステム設計はある程度おりてくるものの、どこまで設計変更が許容されるかなどの判断はとても難しかったです。設計起因による技術負債を抱えていたこともあり完璧に柔軟な対応ができたわけではなかった。そのさじ加減には悩みました。
反省点はありますが、ここまでは安定稼働こそが最優先でしたのでそこはうまくいきました。これからは柔軟に対応すべき部分の許容範囲が増えていくこともあり、アジャイル寄りの開発にシフトしてきているため、より効率的かつ手堅く開発を行っていくフェーズに入ったと感じています。
中村 我々は開発メンバーの中に銀行業務のプロがいるので、業務要件の部分はプロにヒアリングしながら考えていました。そのなかで、デザインの力を活用しながら、デジタルネイティブ世代に向けて銀行の仕組みをわかりやすく説明しようとすると、いままでの銀行とは異なる、まったく新しいものになってしまう。それが果たして世の中に受け入れてもらえるのか、そもそも業務要件としてアウトな面はないかなど、銀行業務のメンバーとやりとりしながら進めていく過程は苦労することも多かったです。
デザインセッションという形で毎週主要メンバーに集まってもらい、コンセプトやデザインをみながら業務要件を満たしているかを確認していたのですが、ときには議論が白熱することも。業務面でクリアしなければいけない部分とデザインをどのようにすり合わせていくのか、お互いの最低ラインがどこにあるか――。それらを探る作業では、意見が割れることもありましたね。最終的には、法律として守るべき部分は守りつつ、可能な限りデザインを寄せていくという地道な作業を行いました。
