チームの紹介と仕事内容

我々のチームは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というリアルなテストコースがまだ存在しておらず、当然ユーザーも潜在的にしか存在していないことにあります。
これは我々のチームだけでなく、全てのチームに言えることです。他のチームが開発中の機能を使いたいと思っても、それがまだまだ不安定であることはしょっちゅうです。一方で一般ユーザーがいないということは、ある程度不安定であっても(少なくとも今は)構わないとも言えます。
不安定だから使わないのではなく、お互いに使って叩いて磨き上げるという精神で、この不安定な状況をお互いに楽しみ、尊重し合いながらも率直に指摘して、よりよいものを目指したい人は是非、我々のプロジェクトに参加してもらいたいです。