『アトカラ』開発で学んだデザインとエンジニアリングの融合【GMO Developers Day 2024】

登壇者の自己紹介

今回のトークセッションに参加したGMOペイメントゲートウェイの4名について。

登壇者についての補足

秋山：森さんと櫻井さんは、前職でも事業会社のシステムエンジニアとして働いていたということですね？

森・櫻井：はい、そうです。

秋山：一方で宮寺さんは、エンジニアとしてのキャリアをスタートさせた後にデザイナーへ転身されています。なぜその道を選んだのですか？

宮寺：エンジニアの頃からデザインに興味があったんです。例えば、公共の税金システムのフロントエンドデザインにも積極的に関わっていました。ただ、その頃は、サービスごとに外部へデザインを依頼したり、私のようなエンジニアが兼任してデザインを手掛けたりと、体制がバラバラだったんです。それが課題だと感じていました。加えて、UI/UXデザイナーとして本格的に取り組みたいという思いもありました。それで、社内でデザインチームを立ち上げたいと希望し、デザイナーへ転身したんです。

秋山：なるほど。事業会社にとって、デザインを内製化できる体制は大きな強みになりますね。これからもぜひ頑張ってください。

アトカラサービス概要

秋山：ではまず、「アトカラ」というサービスの概要についてご説明いたします。

「アトカラ」は、クレジットカード不要の後払いサービスであり、分割払いの機能を搭載していることが大きな特徴です。我々の既存サービスである「GMO後払い」との違いをご説明します。「GMO後払い」は、支払い方法が1回払いのみで、販売形態もウェブショッピング限定の対応となっています。

一方、「アトカラ」では、分割払いに対応していることに加え、対面店舗、つまり実店舗での決済も可能となっています。これが「アトカラ」の大きな特徴です。

サービスのイメージ（非対面）

秋山：サービスの利用イメージをご説明します。現在スライドに表示されているように、まず加盟店様のウェブサイトでお好きな商品を選択し、チェックアウトの際に「アトカラ」を選択していただきます。

次に、携帯電話番号とメールアドレスを入力いただきます。これらは個人を認証するキーとなります。その後、SMS認証（4桁の認証コード）を入力することで決済が完了します。

決済後のお支払い方法は口振やコンビニ払いなどがあります。例えば、「アトカラ」アプリ上に表示されるバーコードを利用し、例えばコンビニのレジで提示することでお支払いいただけます。

サービスのイメージ（対面）

秋山：次に、対面店舗での利用についてご説明します。「アトカラ」のアプリでは、PayPayなどと同様に、1次元バーコードおよび2次元バーコードを表示することが可能です。このバーコードを「アトカラ」に対応している加盟店で提示することで、簡単に決済を行うことができます。

秋山：次に、プロジェクト体制についてお話しします。「アトカラ」は、多くのステークホルダーが関わる共同事業として進められました。

まず、本プロジェクトは、GMOペイメントゲートウェイ、GMOペイメントサービス、そして三井住友カード様による共同事業です。事業会社としては、GMOペイメントサービスと三井住友カード様がビジネス部門を担当されました。一方で、我々GMOペイメントゲートウェイは、主にエンジニアリングおよびデザインを担当しました。

アジェンダ

秋山：本日のトークテーマは主にこちらの5点についてお話ししますが、特に上位3つである「開発プロセス」「チーム間コミュニケーション」「要望への対応スピード」について中心に進めてまいります。それでは、早速進めていきます。

開発プロセス

秋山：1つ目のトークテーマ「開発プロセス」についてです。このテーマについては、櫻井君に全体の開発プロセスで何が行われていたのか説明してもらいます。よろしくお願いします。

アトカラプロジェクトの特徴

櫻井：はい、それではお話しします。個々の工程を詳しくお伝えする前に、「アトカラ」プロジェクト全体の特徴について説明します。

まず1点目として、このプロジェクトでは要件定義の初期段階からデザインチームが参加していました。他のプロジェクトや他社の事例では、設計段階からデザインチームが加わることが多いと聞いています。しかし、「アトカラ」では要件定義の初期からデザインチームが関わり、エンジニアも同様に初期段階から参加していました。このため、エンジニアとクリエイターが協力して要件定義を進める機会が多く、他社の事例に比べてもエンジニアとクリエイターが担う役割が広かったと感じています。

要件定義ではリサーチやデザイン検討を行う

櫻井：次に、各工程で具体的にどのようなことを行ったかについて説明します。特にエンジニアとクリエイターの関わりが深かった要件定義とテストについて詳しくお話しします。

まず、要件定義ではリサーチを最初に実施しました。対象としたのは自社の「GMO後払い」と、既に後払いサービスを展開している他社のサービスです。「GMO後払い」については、冒頭で説明があったサービス仕様の差分を確認しながら運用にも携わり、その仕組みを学びました。他社サービスについては、実際に利用し、画面キャプチャを取りながらサービスの違いを比較しました。例えば、認証方法ひとつをとってもサービスごとに異なる点が多く、それらを確認しつつ「アトカラ」としてどのような要件を設けるべきかを検討しました。

秋山：エンジニアがリサーチを行うというのは、一般的にはビジネス部門の仕事に見える部分もありますよね。実際にやってみてどう感じましたか？

櫻井：前職ではこういった経験はありませんでしたが、他社サービスも含めて調査を行うことで、自社との差別化ポイントや強化すべき点を把握でき、結果的にサービスの理解を深めることができたと思います。

要件定義ではリサーチやデザイン検討を行う

櫻井：次に、リサーチを基にデザインの検討を進めました。このフェーズでは、色使いやロゴ、フォントなどの要素を決めました。ただし、その前に、「アトカラ」というサービスがどのような人に、どのような印象で利用してもらいたいか、そしてどのような価値を提供するのかを言語化することから始めました。このコンセプトをチーム内で共有することで、サービスの方向性に基づいたデザインを具体化することができました。

また、システム面では表示仕様や入力項目を検討しました。1画面内の要素をどの順番で配置するかなども議論し、リサーチで得た知見を活かして検討を進めました。

ユーザビリティテストなどで課題を抽出

櫻井：最後にテストフェーズです。この段階では、「アトカラ」に直接関わりのないパートナーに協力を依頼し、実際に触った際の感覚をフィードバックとして収集しました。その結果、デザインをブラッシュアップすることができました。

秋山：これはよく言うABテストのようなものですよね。宮寺さん、当初のデザイン案と実際のユーザーの使い方にはギャップがあったと思いますが、どのような点が多かったですか？

宮寺：例えば、入力項目が多い画面では、すべて必須項目として設計していたため、必須マークを省略していました。しかし、実際に操作しているユーザーから「これ全部入力する必要があるの？」という声があがり、必須マークを付けたほうが分かりやすいという結論に至りました。こうした点が想定外でした。

秋山：なるほど。デザインはユーザーの動きを想定して設計しますが、やはり実際の利用とは異なる部分もありますね。では、続けていきましょう。

まとめ

櫻井：以上が開発プロセスのまとめです。2つポイントを挙げると、1点目は要件定義からデザインチームが参加したことで、エンジニアを含めたメンバー全員の理解度が向上し、サービスコンセプトが反映されたデザインを実現できたことです。2点目は、プロジェクトメンバーの裁量権が広く、自分たちで作り上げたサービスであるという実感が強かったことです。

以上が「アトカラ」の開発プロセスについてのご説明でした。ありがとうございました。

チーム間コミュニケーション

秋山：では、次のテーマに移ります。2つ目のテーマは「チーム間コミュニケーション」についてです。このプロジェクトでは多くのステークホルダーが関わっており、その中でエンジニアとデザイナーを含む関係者間で、どのように円滑なコミュニケーションを図ったのかをお話しします。これについては宮寺さんから説明していただきます。よろしくお願いします。

チケット管理し、ステータスを分かりやすく

宮寺：はい。それでは私から、チーム間コミュニケーションについて工夫した点をお話しします。主に2つあります。

1つ目は、チケット管理ツールを活用してステータスを分かりやすくした点です。元々は、デザイン修正の依頼や課題管理をチャットや複数のExcelファイルで行っており、誰からの依頼で、進捗がどこまで進んでいるのかが非常に分かりにくい状況でした。

そこで、Backlogというチケット管理ツールを導入しました。このツールを活用することで、誰がどこまで進んでいるかが一目で分かるようになり、エンジニアやデザイナーだけでなく、関係者全体で情報を共有しやすくなりました。

宮寺：さらに、ステータスに説明文を追加する工夫を行いました。単に「処理中」や「確認中」といったステータスだけでは、誰の担当なのかが分かりにくいという課題があったため、「UIチームのボール」や「開発のボール」といった情報を説明文として加えました。これにより、担当者を明示しなくてもステータスだけでどのチームが対応中か分かるようにしたのが工夫した点でした。

修正案連携用ファイルを作成

宮寺：2つ目の工夫は、デザイン修正案の連携方法を改善した点です。従来は、デザインツール「Figma」のファイルに直接修正を加え、コメントだけで依頼内容を伝えていました。しかし、150以上の画面がある中で、どのチケットに対する修正なのか、コメントだけでは分かりにくく、開発チームとの追加やり取りが必要になることが多々ありました。

宮寺：そこで、修正案を個別のファイルに分けるようにしました。このファイルには、チケットのタイトルとURLを緑色の部分に記載し、すぐに該当するチケットへアクセスできるようにしました。また、修正案については、ビフォーアフターの画像を並べて見やすくし、さらに補足情報をメモとして加えることで、詳細な修正内容を正確に伝えられるようにしました。

秋山：これは単にBacklogを使うだけではなく、関係者全員に伝わりやすい工夫を加えているということですね。森さん、エンジニアの視点から見ると、この改善でどのような変化がありましたか？

森：エンジニアとして非常に助かりました。以前はExcelファイルに画面キャプチャを貼り付け、それを各部署に送る方法で進めていましたが、こうした取り組みによって、各部署への確認作業が効率的になり、対応スピードも向上しました。おかげで、エンジニアとしては非常に作業がしやすくなりました。

秋山：これで作業効率が10%以上向上したという実感がありますね。

森：はい、そう思います。

秋山：以上が「チーム間コミュニケーション」についてのお話でした。ありがとうございました。

要望へのスピード対応

秋山：では3つ目のテーマ、「要望へのスピード対応」についてお話しします。このテーマでは、ユーザー部門やビジネス部門から、工程や時期を問わず様々な要望や変更依頼が寄せられた中で、我々がどのように対応してきたかについて、森君に話してもらいます。よろしくお願いします。

課題

森：このプロジェクトが抱えていた課題について、まず説明します。

1つ目は「プロジェクト面」の課題です。工程に関係なく追加の要件や仕様変更が発生しました。その背景として、「アトカラ」は割販法やその他の法令に準拠する必要があり、システム開発と並行して、ユーザー部門では法務確認や運用体制の確立を進めていました。これに伴い、本番稼働に向けた具体的な要件が決定するたびに新たな要望が寄せられる状況でした。

2つ目は「体制面」の課題です。このプロジェクトにはユーザーである三井住友カード様や、GMOペイメントサービスのメンバーも関わっていました。それぞれと画面デザインや仕様を調整する必要があり、非常に時間と手間がかかった点が大変だったと感じています。

クリエイターが同組織に所属

森：次に、こうした課題に対して我々がどのように対応したかについて、良かった点を2つ挙げます。

1つ目は、クリエイターが社内に所属していた点です。他社ではクリエイターを外部委託するケースも多いと思いますが、我々のチームでは社内にクリエイターがいたため、要望があればその場で立ち話レベルで対応を相談し、その日のうちにデザイン案を決めて回答することが可能でした。この迅速な対応がプロジェクトをスムーズに進める要因になったと考えています。

エンジニアが橋渡し役

森：2つ目は、エンジニアが橋渡し役となり、ビジネス部門とクリエイターの間に入って推進した点です。一般的なプロジェクトでは、ビジネス部門がクリエイターと話し合い、その結果をエンジニアに落とし込む流れが多いと思います。しかし、「アトカラ」では、エンジニアが直接ビジネス部門やクリエイターとやり取りし、実現可能性や仕様に関する質問に即答することで、非常にスピーディーな対応が可能となりました。

秋山：一般的なプロジェクトでは、クリエイターやデザイナーがビジネス部門に所属して調整するケースが多いと思いますが、今回はエンジニアが中心に入って進めたというのは珍しいですね。これは意図してそうしたのですか？

森：正直なところ、成り行きで決まった部分が大きいです。しかし、「アトカラ」のように業務内容や仕様が非常に複雑なプロジェクトでは、エンジニアが深く関与したことでスムーズに進められたと思っています。

秋山：宮寺さん、他のプロジェクトでも同様の進め方をすることはありますか？

宮寺：プロジェクトによって異なりますが、ビジネス部門とクリエイターだけで進める場合、仕様を検討してからエンジニアに確認するという流れになります。この場合、やり取りにラグが生じることがありました。しかし、今回のようにエンジニアが早期に関与してくれると、そのラグがなくなり非常に助かりました。

秋山：なるほど。「アトカラ」はウォーターフォール型開発のように見えて、実際にはプロトタイプを作りながら進める部分も多かったですね。こうした進め方はスピード感があって良かったと思います。

宮寺：そうですね。非常に効率的に進められたと思います。

プロジェクトを終えて

秋山：それでは、4つ目のテーマ「プロジェクトを終えて」についてです。今回の「アトカラ」プロジェクトは、業務面でも体制面でも非常に難易度が高いものでした。プロジェクトを通じて感じたことや、今後に活かせそうなこと、学んだことがあれば、一言ずつ教えてください。では、櫻井君からお願いします。

櫻井：はい。私が入社して間もなく、このプロジェクトの要件定義が始まりました。そして、2年弱でリリースに至ったという、非常にスピード感のある開発でした。その中で、GMOペイメントゲートウェイがスピード開発を実現できる要因を学ぶことができました。

具体的には、プロジェクト推進に必要なスキルを持つ人材の存在、メンバー同士が助け合うマインドセット、そして必要なときに組織としてマンパワーを集中できる体制、これらが重要な要素だと感じました。これらの学びは、今後のプロジェクトにも活かせると思います。

秋山：確かに、内製化されているというのは大きな強みですね。引き続き、この体制を活かして頑張りましょう。では、宮寺さんお願いします。

宮寺：私は他のサービスも担当していますが、依頼する側と依頼される側という関係性になりがちで、受け身の姿勢になることもありました。そうした関係性では、クリエイターはここまで、デザイナーはここまで、といったように線を引いてしまうことがあります。

しかし、このプロジェクトを通じて、チーム全体で一丸となり取り組むことの重要性を実感しました。受け身にならず、積極的に関わる姿勢が非常に大事だと感じました。

秋山：なるほど。それでは最後に、森君に締めてもらいましょう。

森：はい。私は前職ではBtoB案件やバックエンド開発のみを担当しており、今回のようなプロジェクトは初めてでした。そのため、未知の領域に取り組むことが多く、大変な面もありました。

しかし、デザインだけでなく業務面にも深く踏み込み、プロジェクトを推進する経験を得られたことは非常に勉強になりました。この経験を活かし、今後の案件でもさらに貢献できるよう頑張っていきたいと思います。

今後の展望

秋山：それでは最後に、私から「今後の展望」についてお話しします。

「アトカラ」は、2024年2月に誕生したばかりのサービスです。まだ競合他社に追いつき、追い越していく必要があり、さらなるサービスの強化や新機能の開発を進めている段階です。
私たち事業会社のGMOペイメントサービス、三井住友カード様、そしてGMOペイメントゲートウェイが力を合わせ、「アトカラ」をナンバーワンのサービスに育てていきたいと考えています。

今後とも皆様のご支援をよろしくお願いいたします。本日はありがとうございました。

※本コンテンツ内容の著作権は、GMOペイメントゲートウェイ株式会社に属します。