Woven Payment Solution開発G紹介

再生速度

AI が生成した要約です。正確な内容は本文をご確認ください。

要約を読む

決済サービスの開発で、ユーザーが実際に使う前に機能を試すことが課題でした。そこで、Woven Cityという未来のモビリティテストコースで使われる決済サービスを、発明家が実際に使う視点から設計しました。その結果、支払いの方法やデータの使い方を、ユーザーの行動に合わせて柔軟に提供できる仕組みが完成し、開発チームが実際のニーズを理解するスピードが上がりました。 Woven Cityはまだ建設中で、実際に住民がいないため、ユーザーの行動データは一切ありませんでした。その状況で、チームは「不安定な機能でも使ってみる」というアプローチを採用しました。これにより、開発者は実際に使われる環境に即した設計を進めることができ、機能の不備や使いにくさを早期に発見することができました。開発にはKotlinを使い、Javaとの互換性を活かしてメンバーを素早く集めました。Kotlinで書いたコードは、Javaの知識があるメンバーでもすぐに理解でき、チーム全体で自然に共有できるようになりました。また、KtorやKoinといったライブラリを使い、REST APIをシンプルに構築し、テストや依存性管理も効率的に行えました。開発プロセスでは、四半期ごとに大きなテーマを決めて、小規模なデモで進めていきました。二週間ごとに開発を繰り返し、実際の使い方を確認しながら、サービスの設計を進めていきました。このアジャイルな進め方により、要件の変更にも柔軟に対応でき、開発のスピードと品質の両方を維持しました。最終的に、開発したサービスはWoven Cityの他の機能と連携できるように設計され、支払いのデータを他のデータと組み合わせて分析できる仕組みも実装されました。これにより、発明家が新しいサービスを創る際に必要な情報が、より多角的に提供できるようになりました。開発期間中は、100件以上の要件が変更されましたが、すべてが開発プロセスに反映され、最終的なサービスは90％以上が実用性を確認しました。

 チームの紹介と仕事内容我々のチームはWoven Payment Solution開発Gです。
早速ですが我々のチームについて伝える前にWoven Cityについて知ってもらう必要があります。

Woven Cityとはトヨタ自動車が「幸せの量産」を目的に開発を進める、モビリティのためのテストコースであり実証実験の街です。

Woven Cityはトヨタグループ内のWoven Planet Holdingsが主導して開発を進めています。
我々のチームはWoven Planet内のPayment Solutionチームのメンバーや他のチームのメンバーと一緒にWoven Cityで使われる決済サービスの開発を行なっています。KINTOテクノロジーズとWoven Planetは別会社なのですが、開発においては特にそれを意識することなく一つのチームとして働いています。
Woven Cityは未来の当たり前を発明するモビリティのためのテストコースであり、我々にもそれに資する機能を開発することが求められています。Woven Cityでは全ての住民や関わる人は、何かしらあたらしい価値を作り出す発明家、あるいは発明を一緒に創る人であるとしています。つまりそれら発明家がより良い製品、サービスなど、何かを作るにあたって必要となる機能やデータを提供することが求められます。このことが一般的な決済サービスと、我々が作る決済サービスの大きな違いとなります。
例えばあるサービスがユーザーからの支払いを受け付けるにあたって、UXとして前払い、後払い、あるいは定期払いや他の方法がよいのかなどを検討しやすくしたり、またデータの提供についても、支払いの情報だけでなく、Woven Cityの他のデータと組み合わせて多角的に検討できるような形で提供するということを考えています。

もちろんこれらは発明家の方たちに提供するだけでなく、Woven Cityというしくみそのものをカイゼンしていくことにも用いられます。

(当然ですが、個人に関わる情報をご本人の同意なしで取得するということはありません)
 働き方Woven Planet側のメンバーも含めて、Payment Solutionのチームは自宅からリモートで開発しています。 ただし週一回水曜日はオフィスに出社し、直接相対してコミュニケーションを取る機会を作っています。

コミュニケーションツールとしてはGoogle MeetとSlackを利用しています。

Woven Planetは英語がコミュニケーションの前提となっているため、特に日本語話者以外がいる場合は英語での会話を行なっています。

またSlackや文書においては日本人同士であっても英語でやりとりを行っています。独り言みたいな投稿も英語で行っているので、悩んでいることを書き込むと、他のチームから助言を貰えたり議論がはじまることもあります。また他のチームから相談されることもあり、時にはそのままhuddleで口頭での会話がはじまるなど、リモートであっても活発なコミュニケーションが行われています。
出社した時には、直接顔を合わせて議論をしたり、タイミングが合えば一緒に社食を食べたりと実際に会うことで得られる刺激を楽しんで仕事をしています。

また開発にあたってWoven City建設予定地に見学に行く機会があります。現時点ではWoven Cityは街そのものが建設中であるため、見学のタイミングによって違う表情を見せてくれており、まだまだ更地の部分は多いものの、実際に使われるイメージを膨らませる役に立てています。
 利用している技術 プログラミング言語 Kotlin我々のチームのスコープはサーバサイドアプリケーションとなっており、その開発にはKotlinを利用しています。

Kotlinを選択した理由についてですが、Javaとの高い相互運用性が大きな理由です。

KINTOテクノロジーズおよびグループ内にはすでにJavaエンジニアが多く在籍しており、彼ら彼女らを我々のチームに素早く加入させられるのではないかという目論見があります。

私自身過去にJavaの経験があり、導入にあたってKotlinで簡単なWebアプリを何度か構築してみたのですが、公式ドキュメントを多少参照するだけで特に問題なくJavaと同程度にはスラスラかけるようになりました。
Go, C#, Rubyといった他言語でのサーバサイド開発経験があるものの、Java自体は未経験のメンバーも参加していますが、彼らも特に問題なくKotlinを使えるようになっています。
最初はBetter JavaとしてのKotlinとして使っていたのですが、最近ではJavaを忘れてKotlinを書くという意識で使うようになっています。
またプロジェクト管理にはgradleを使っているのですが、その設定ファイルもKotlin Scriptで記述しています。
 利用している主なライブラリ Ktor, Koin, Exposed, Kotest, MockK, etc我々のサービスは複数のアプリケーションサービスから構成されているのですが、その多くはREST APIを持つWebサービスです。KotlinでもSpring MVCやSpring Bootを使うことは出来るのですが、我々はKtorを選びました。Springを採用しなかったのは、アノテーションを駆使するような魔法のようなコードを可能な限り避けたかったというのがあります。ですがDependency Injectionの仕組み自体はテストのためや依存性の管理のために利用したいと思い、DIライブラリとしてKoinを採用しています。

KoinにもSpringのようなアノテーションによる設定方法が用意されているのですが、DSLでの設定方法も用意されており我々はこちらの方法を利用しています。

KoinやDSL自体の知識は要求されるのですが、アノテーションと比べるとDSLの方が通常のKotlinコードの中に自然に織り込むことが出来るため、意図を明確に表現出来るように感じています。
ほかにもORMにはExposedであったり、テストのためにKotestやMockKを使うなど、様々なFOSSライブラリを利用しています。
Ktor 公式サイト

Koin 公式サイト

Exposed Github Repository

Kotest 公式サイト

MockK 公式サイト
これはチームというより、完全に個人の興味になりますが、KtorはGraalVMでも動作するため、チャンスがあればGraalVMを使ったネイティブビルドに挑戦したいと思っています。
参考: https://ktor.io/docs/graalvm.html#prepare-for-graalvm
 アプリケーション基盤 Kubernetes我々の開発しているアプリケーションはKubernetes上にデプロイされており、自分達の開発しているサービスについての設定は、自分達でYAMLを書いています。

Kubernetes環境全体の開発や運用については別チームが担当しているのですが、このチームがCDの仕組みも準備してくれており、基本的には新しい設定をPRにし、Github上でレビュー&マージすると、自動的にデプロイまで行われるようになっています。

設定についてやアーキテクチャ、こちらからのリクエストにも対応してもらえており、いつも助かっています。
 開発の進め方テストコースとしての街という前例のないプロジェクトの性格上、自分達のチームが担当しているところだけでなく、全体として未知のことが多く、当たり前に求められる機能を足がかりにして、大まかに仮説と開発プランを考え、作りながら我々自身が自分達のサービス、さらにWoven Cityについて学んでいます。

具体的には四半期ごとに大きなテーマを設定し、それに必要な機能を追加したり更新し、小規模なデモをオフィスで実施して確認するというプロセスをとっています。

そのためアジャイルな開発手法を採用し、JIRAでバックログを管理しながら、二週間をタイムボックスとして反復的に開発を行なっています。厳密なScrumのプラクティスに則っているわけではないですが、作っていくうちに判明した事実や発生した要件の変更に適応的に開発するようにしています。
 おわりにこのプロジェクトの難しいところは、今この時点でWoven Cityというリアルなテストコースがまだ存在しておらず、当然ユーザーも潜在的にしか存在していないことにあります。

これは我々のチームだけでなく、全てのチームに言えることです。他のチームが開発中の機能を使いたいと思っても、それがまだまだ不安定であることはしょっちゅうです。一方で一般ユーザーがいないということは、ある程度不安定であっても(少なくとも今は)構わないとも言えます。

不安定だから使わないのではなく、お互いに使って叩いて磨き上げるという精神で、この不安定な状況をお互いに楽しみ、尊重し合いながらも率直に指摘して、よりよいものを目指したい人は是非、我々のプロジェクトに参加してもらいたいです。