みずほ銀行では「みずほダイレクトアプリ」を開発・運用しています。
みずほ銀行のデザイン組織であるUXUIチームが中心に、2019年から2022年にかけて大規模なリニューアルを実施しました。リニューアルに関する事例はこちらに詳しくまとめられています。
もちろん、リニューアルの後の運用フェーズにおいても、常に多くのプロダクト改善が走っています。
今回は、みずほダイレクトアプリという規模感の大きなサービスの運用フェーズにおいて、サービスグロースを優先しながらもプロダクトの品質を高水準に保つための「デザインフロー構築」「デザインシステム運用」の裏側をまとめます。
2019年からリニューアルを開始し、2022年にリリースしたみずほダイレクトアプリは、数百万人規模のお客さまにご利用いただいているサービスです。
リニューアルプロジェクトの後の運用フェーズにおいても、数多くの機能追加・改善を続けています。
みずほダイレクトアプリは、単一の機能を提供するアプリケーションではなく、「残高照会」「振込」「税金支払い」「ローン」「資産運用」など、いくつものサービスが集合してできている複雑なサービスです。
サービスの規模が大きいので、常にいくつもの機能開発・改善が複数走っており、そのためデザインのコンポーネントも複数生まれます。
このような構造なので、デザインの運用は非常に難易度が高くなります。
このような背景を踏まえつつ、みずほダイレクトアプリの運用においては、サービスグロースを優先し、そのためUI上の負債は必ず起こるものとして考えています。
あくまでみずほダイレクトアプリはサービスを急速に成長させるフェーズです。
デザインの一貫性を意識した堅牢な設計をするよりも、グロースを優先させる方がお客さまのメリットが大きく、そのためデザインガイドラインを順守するよりもグロースを優先しています。
とはいえ、もちろんUI負債を許容しているわけではありません。
重要なのは、デザイン段階でUI負債を生まないよう精密に管理をすることはせず、サービスグロースのためにスピーディーにデザイン・実装を進めつつ、UI負債を管理しておき必ず潰していくための体制をつくることだと考えています。
具体的には、以下の2つの仕組みで運用しています。
スピーディーな開発... 「デザインタスクの段階分け」
UI負債を解消する... 「デザインシステム運用」
まず一つ目の仕組みは、スピーディーなデザイン・実装のためのデザインフロー構築です。
みずほダイレクトアプリのデザインは、すべての案件で、内製で全画面をつくりこむことはせず、重要度や余力を踏まえて案件ごとにどのくらい内製でデザインをつくりこむのかを段階別に整理しています。
(内製でつくらない部分は、社外のデザイナーに協力してもらうことが不可欠です。)
イメージとしては、以下のように整理しています。
主要画面のデザイン + デザイン仕様書 ... 全案件実施
1に加えて、正常系の全画面デザイン … 重要度中 or 余力ありの際に実施
1, 2に加えて、エラー系画面のデザイン … 重要度高 or 余力ありの際に実施
iOS/Android両方のデザイン … 現在は実施しない
重要度や余力は、案件ごとにPdMとデザインチーム内のディレクターで議論しながら決めていき、デザインタスクの規模を毎回決めるようにしています。
デザインタスクの規模が決まったら、基本的にはガイドラインに沿ってデザインを進めます。
(詳しくは後述しますが、ここで、もしガイドラインにないものをつくる必要があれば、デザイン承認会というデザインチーム内のMTGに持ち込み、ガイドラインに反映します。)
このようなスピードを重視したフローを取っているので、デザイン段階では、デザイナーが作成していない画面もあります。
そのため、開発ベンダーの方から出てきたリリース前の画面にUI負債があれば、必ず解消できるようにするように対処する必要があります。
同時並行で機能開発・改善を進めながら、UI負債を管理し、必ず解消できるようにデザインシステムの運用にも取り組んでいます。
みずほダイレクトアプリのデザインシステムは、コンポーネント集と、ガイドラインから構成されています。基本的にデザイナーが利用するもので、デザインのスタイルを定義しています。
コンポーネント集の内容は一般的なものと捉えていただいて良いかと思います。カラーやフォント、UIコンポーネントをまとめたものです。
対になるようなものとして、ガイドラインも別ファイルに用意しています。例えば、みずほダイレクトアプリのコンセプトや、カラー・フォントなどの構成要素の説明をまとめています。
また、各コンポーネントに対する使用用途・扱い方についても具体的にまとめています。
みずほダイレクトアプリのパーツ自体は特に変わったものはありませんが、利用者が非常に多い金融系サービスということもあって細かな用途もブレが生まれづらいようにしていくために作成しています。
ちなみにリニューアル当初のデザインガイドラインは、パワーポイントで作成されていました。そのままでは運用しづらかったため、最初はパワーポイントに移し替えましたが、結局デザイナーが運用できるのが大事だろうと考えて、現在はFigmaで運用しています。
UI負債の解消フローは以下のように定義しています。
デザイン段階、実装後のテスト段階などで各デザイナーがUIのコンフリクトを発見したら、議論できるようにまとめておき、チーム全体でどのように解消するのかを決めていくような流れです。
UI負債を発見できるタイミングはいくつも用意されています。
デザイン段階で、他画面との整合性を確認していく時
実装後、リリース前にUAT（User Acceptance Test）を行う時
リリース後に、ユーザーテストを行う時
みずほでは金融サービスを扱っているので、必ずリリース前にUATを行います。この時に、ガイドラインとズレがある部分があれば、気付いた人がUI負債をまとめておくようにします。
発見されたUI負債は、週1で行っているデザインルール検討会という、デザインシステムやデザイナー同士の連携を高めるためのMTGに持ち込まれます。
その場で、各UI負債に対して、ガイドライン上・実装上のそれぞれの対応方針を決定するような運用を行っています。
ガイドラインの更新は、デザイナーだけで行えるので、基本的に発見後すぐに行うようにします。
UI負債と同じように、ガイドラインの更新イメージをデザインルール検討会の中に持ち込み、反映となったら、デザインシステムに組み込まれていきます。
実装への反映については、ビジネス側のプロジェクトリーダーが管理している実装タスクの中に組み込んで対応しています。リリース前でも、クリティカルなものであれば、差し込んで修正します。
このようなデザイン体制改善の結果を示すのはなかなか難しいですが、「便りがないのは良い便り」と言わんばかりに「そもそもの使い心地・使い方が分からない」といったお問い合わせは少なく、スピーディーな機能開発と、UI上の品質担保を両立できています。
また、みずほダイレクトアプリでのデザインシステム運用のノウハウを、社内に横展開していくことも積極的に行っています。
例えば、先日公開されたみずほ銀行のHPリニューアルの案件でも、デザインシステムの運用基盤をUXUIチームで構築し、継続的な改善を行っています。
他にも、グループ会社の方から「デザインシステムの相談がしたい」と話をもらい、デザインシステム構築や体制づくりをアドバイスさせていただいています。
最後に、今後の展開について、想定していることをまとめておきます。
みずほダイレクトアプリ内の話でいうと、今はiOS/Androidのどちらかしかデザイン段階では画面をつくらないという運用になっていましたが、今後は両方のガイドラインを整備していき、デザインフローとしても工数少なく両画面を設計できるように体制改善をしていこうとしています。
また、アクセシビリティガイドラインの設計も始めました。2024年4月1日より、障害者差別解消法が改正され、民間事業者の合理的配慮が義務化されていますが、非常に多くのユーザーの方を対象とするみずほダイレクトアプリでもアクセシビリティに配慮した設計を進めています。すでにガイドラインをデザインシステムに組み込み、運用を一部開始しており、こちらについても今回まとめたような体制で継続的に改善を行っていきます。
UXUIチームとして、さらにみずほ全社にデザインシステムの浸透を進めていけるように、引き続き、行内全体にデザインが浸透するための「触媒」として動いていければと思います。