Kyashのある暮らしに向けて

この記事はKyash Advent Calendar 2022の25日目(トリ!)の記事です。 Kyash創業者の鷹取です。

今年の振り返り

早いもので2022年も残すところあと数日です。 去年のアドベントカレンダーでは「Kyashが大切にするクラフトマンシップについて」について書きました。

2022年を振り返りますと、Kyashカードによる決済のポイントとは別でポイントが貯まる「Kyashリワード」や、国際ブランドのJCB/AMEX(American Express)や楽天銀行等をはじめとする金融機関様からの入金手段を追加させていただいたこと、そしてKyashとして初となるカードの共同発行の取り組みとしてブラジル人コミュニティの皆様向けにMAURICIO STUDIO CARDの発行を開始致しました。 Kyashがサービスとして日の目を浴びた2017年から5年が経ち、サービスの運用態勢の改善についても前進した年だったように感じます。

また、会社としては春先に54億円のシリーズDの資金調達を行い、今秋には表参道から青山一丁目にオフィスを移転致しました。引き続き、お金周りのライフスタイルサービスの開発に努めて行きたいと思います。

去年のAdvent Calendarエントリーの最後に予告的に記した、「Kyashは何を変えたのか」、「ユーザーの暮らしに貢献したポジティブな変化」について書きたいと思います。

Kyashが目指したこと

キャッシュレスやデジタル社会は、今まで不可能であった多くのことを可能にしてきました。同時に、仕組みや制度が追いついていないものが世の中にたくさん生まれました。金融も、その一つだと考えています。そういった社会の変化によって生まれる歪を解消したい。そして行く行くは、その歪みの解消に留まらず、テクノロジーによって便利になることを更に増やしていけることができれば、ユーザーにとっても社会にとっても重要な貢献を果たせるのではないかという大きな希望を持っています。

百貨店の掛け売りが起源とも言われるクレジットカードも、今では大変多くの利用者が様々な場所で利用する決済手段となりました。(下図)

クレジットカードの利用者と利用場所の変遷

キャッシュレス化の促進が叫ばれる日本でも、月間支出の半分以上をカード決済にされていらっしゃる方もいらっしゃいます。今まで、お財布の中で管理できていたお金がデジタルになる時、きっと多くの人がデジタルでお金を管理した方が便利になると考えたでしょう。現実は、支払う体験は確かに便利になったと言えますが、その後の管理については複雑さを増したように感じる方も多いのではないでしょうか。ニュース番組でも、キャッシュレスを「見えないお金」と表現することもあるくらいです。 Kyashでは、決済において「見える化」に着目して、人びとのお金をより扱い易くしていくところに貢献したいと考えてきました。そのために、日本でもいち早くカード決済時にプッシュ通知で決済の内容を通知する仕組みや、利用明細を即座に生成する仕組みを開発してきました。また、「見える化」の対象をKyashが発行するVisaカードに留まらず、Kyashのカードを紐づけられるSuica等の電子マネーQRコード決済なども含めていきたいと考えています。

決済は、暮らしにおけるお金の接点で最も身近なものだと思います。上記のような「見える化」は、キャッシュレスが浸透していく上で、地味ではありますが確実に必要なインフラだと信じています。

来年からはデジタル給与が解禁されるとも言われています。当社を含む資金移動業者にとっては、変化の大きな年になります。Kyashは、ユーザーの日々の様々なお金の接点で、必要とされる存在を目指していきます。

Kyashは何を変えるのか

Kyashは、テクノロジーを通じて従来の制約にチャレンジしていくことでサービスの利便を向上し続けていくこと、そして金融をライフスタイルサービスとして再設計することで利用者の暮らしに必要なサービスや機能を一元的に提供していくことを大切にしています。 金融は、物質的なモノが存在しない分、差別化が難しいと言われます。確かにその側面はありますが、Kyashは機能やスペックの比較だけで差別化を目指しているわけではありません。 Kyashの挑戦は、上記二つの大切にしていることをユーザー起点で行うことです。ユーザー起点とは、お金に関わる行為に対してユーザーに主導権がある形で実現すること。ユーザーが、リアルとデジタルが融合する社会において自分のお金をいつでもどこでも好きなように把握して管理し、扱えるようになる状態、ここに近づけていきたいです。

インターネットとスマートフォンが浸透し、様々な業態が「民主化」されたと思います。例えば、道路で行き交うタクシーに「乗せてもらう」だった感覚が、手元のスマートフォンでタクシーを「呼ぶ」ような感覚になった。お金に関しても、このような体験を創っていけると思うのです。

「お金」が人類の大きな発明であり、姿や形状を変える中で、計り知れない利便をもたらしてきました。Kyashは、その変化に対してより多くの人びとが恩恵を受ける世の中に貢献すべく、独立系としてユニークな立場から挑戦を続けて参ります。 Kyashが、ユーザーの暮らしにポジティブな貢献を果たしていると言えるには、まだまだ長い道のりがあります。しかし、「小さくても」必ず存在していて、ゼロヒャクの世界でなく、着実な前進を続けていくのみだと考えています。

Kyashはおかげさまで今年、100人を越える所帯になりました。日々難しい挑戦に向き合い、道を創ろうと共に奮闘してくれるチームに感謝をしながら、来年もOne Teamで取り組んでまいります。引き続き、よろしくお願いします!


※ Kyashではミッションに共感してくださる方の採用を強化しています。 こちらに募集ポジションを記載しておりますので、弊社の採用チームまたは私までご連絡くださいませ!

カスタマーサポートの面接を担当して気づいた3つのこと

これは、Kyash Advent Calendar 2022の19日目の記事です。

Kyash(以下、当社)でカスタマーサポート(以下、CS)を担当しているすーもです。この記事では、私がCSで面接を担当して気づいた3つのことを紹介します。去年のAdvent Calendarでは『Kyashの全社会議"All Hands"が2021年にやったこと』をしたためました。

続きを読む

2022年Kyash Androidチームがやってきたこと

これは Kyash Advent Calendar 2022 の17日目の記事です こんにちは。@dosukoi_androidです。

2022年Kyash Androidチームは色んなことをやってきました。 それをずらずらと書いていこうと思います。

Compose本格導入

2月にリリースしたKyashリワード機能からJetpack Composeを本格的に導入しました。 それまでに試験的に一部画面でComposeを導入することはありましたが、丸々1つの機能をComposeで作り上げることは初めての試みでした。 初めての本格導入ということで、まだチーム内のComposeに関するお作法が決まっていなかったり、ハマりどころがわかっていないこともあり、かなり苦戦する部分もありましたがこのプロジェクトで培ったナレッジをチーム全体で共有できたのは大きかったです。 Composeであまり使われていないMotionLayoutを使ったり、まだaccompanist時代のWindowInsetsなども使いました。

KMM本格導入

同プロジェクトでKMMの本格導入も始まりました。こちらもCompose導入と同じくお作法が決まっていない、ハマりどころがわかっていない、などの苦労もありましたが、なんとかリリースまで持っていくことができました。 KMMは未だにチーム内で設計の議論が多く行われていて、「Kyashの中でKMMのあり方はこう!」みたいなものが完全に決まっているわけではありませんが、日々の議論の中で少しずつ洗練されていっているので今後が楽しみです。

Widgetリリース

これはAndroidチームというより、Mobileチームの取り組みです。 Kyashで初めてWidgetのリリースを行いました。 Widgetのナレッジがない中、iOSエンジニアと相談しながら進めていきました。 Mobileチーム内に閉じた話だったので、仕様からリリース時期の設定まで全てエンジニアが行うプロジェクトでしたが、いい形に着地できたんじゃないかと思います。

独自ViewModelの廃止

KyashはJetpackのViewModelが誕生する前からリリースされていたアプリです。それ以前からMVVMというアーキテクチャは存在していたため、独自にライフサイクルに合わせてkillされるようなViewModelを作っていました。 ですが、JetpackのViewModelが誕生してからそちらを使うようになり、JetpackのViewModelと独自のViewModelが混在している状況が発生していました。 そこで2021年中頃から独自のViewModelを廃止して、JetpackのViewModelに統一しよう、という流れになっていました。 2021年にある程度の独自ViewModelを消すことができ、まだ残っていたかなり大きめの独自ViewModelを2022年にほぼ消すことができました。 記憶は定かではないですが、統一しようと話が出てきた頃は100以上の独自ViewModelがあり、骨が折れる作業だなと思ってましたが、終わってみるとかなり嬉しいものですね。

Compose Themeの策定

これは主に@_rmakiyamaさんが主導してくれたものです。 Kyash AndroidはComposeを導入したのはいいものの、ダークテーマ対応を見越したThemeの設定ができていませんでした。 というのも色の設定をするのに

@Composable
fun Hoge() {
    Box(modifier = Modifier.background(color = KyashTheme.colors.blue))
}

というように直接色の設定をしていました。本来はprimarysecondaryを使うべきです。 それをmakiyamaさんが「ダークテーマ対応の時に泣いちゃうよ」と助言をくれたので、入社して2週目くらいのタスクでお任せすることになりました。

マルチモジュール分割

Kyash Androidは元々マルチモジュール構成にはなっていたものの、大半の機能がcoreモジュールに集約していました。新規機能は新しくfeatureモジュールを作るものの、既存機能はcoreモジュールから切り離せていない状況でした。 これではマルチモジュールの恩恵をうまく享受できません。coreモジュールをいじるといちいちビルドに時間がかかるし、coreモジュール内ならどこへでも依存できてしまいます。 ということで、機能ごとにモジュールに切り出すことになり、2022年初めは5つのfeatureモジュールだったところを12個のfeatureモジュールに分割できました。 計測してないのでフルビルドが早くなったかは不明ですが、coreをいじることは確実に減ったと思います。

これから

今年は古くなっている技術を新しい技術に置き換えていったり、新しい技術を取り入れたりしてきました。 ですが、まだまだ古い技術を採用している部分、Deprecatedになっているのに放置されている部分が数多く存在します。(warningが400近くあったり...) 新機能の実装も大切ですが、プロダクトの保守性もかなり大事です。そしてKyashはそれをエンジニアだけでなく、多くのPMやbizのメンバーも理解してくれているので、保守性を高めていくことを是とする文化になっています。 来年も新しい技術の導入やリファクタリングをたくさん進めていけたらいいなと思っています。 Kyash valueの”頂点思考”にもあるように、これからもKyash Androidの技術を最高の技術に近づけられるように頑張っていこうと思います。

おわりに

Kyashの技術に興味がある方、俺ならもっとKyashをイケてるプロダクトにできるぜ!という方、イケてない技術を見るとワクワクする方、ぜひお話ししましょう。 * Podcast Kyashfm * Kyash People Team | note * 株式会社Kyash の全ての求人一覧

Kyash法人送金サービスについて

※本記事は Kyash Advent Calendar 2022 の16日目の記事です。

Kyashで事業開発を担当している山原 紳太郎です。
この記事では、私も企画から提案、改善まで関わっている、法人向け送金サービスについて記載しています。

Kyash法人送金サービスとは?

法人から個人のKyashアカウントへ、報酬や売上金などを送金できるサービスとなります。
また、事業者の所属社員に対する経費精算の支払いにも活用できます。

Kyash法人送金サービスの導入例

フードデリバリーアプリにおける配達員への報酬や、買取ショップにおける買取代金、マーケットプレイスにおける売上金など、様々なサービスにて活用されています。
参考までに、こちらの記事もご確認ください。

利用イメージ

例えば、事業者が提供するサービス内のマイページにおいて、利用者が売上金の出金手続きを実施するとします。
その際、振込方法としてKyashを選択して所定の手続きを行うと、即時にKyashの残高に売上金が入金される仕組みとなります。

なお、入金された残高は、VisaやQUICPay+が使えるコンビニエンスストアなどの実店舗や、ネットショッピングにてすぐに利用できます。
もちろん、銀行口座への出金や、セブン銀行ATMで現金を払い出すこともできます。

導入事業者のメリット

1件あたりの送金手数料が、銀行振込などと比較して非常に安価となっている為、本サービスを導入することで事業者のコスト削減につなげることもできます。
なお、初期費用や月額費用も無料となっているので、導入にかかるコストの心配はありません。

利用者のメリット

銀行振込の場合は銀行の営業日の関係で、指定銀行口座への着金までに時間がかかってしまいます。
対して本サービスの場合はリアルタイムで送金が行われるので、24時間365日、いつでも事業者からお金を受け取ることができます。

導入パターンについて

現在Kyashでは、API接続の他、CSVファイルをアップロードして送金を行う方法の2種類があります。

  • API接続の場合
    前述の利用イメージのように、利用者の手続きをトリガーとして即時にお金を受け取ることができます。
    なお、弊社にて提供するAPIの仕様にあわせて事業者側で開発を行う必要がありますが、非常にシンプルなAPIとなっている為、開発工数の心配はありません。

  • CSVファイルをアップロードして送金を行う場合
    弊社にて用意する管理画面上からCSVファイルをアップロードすると、即時に送金を行うことができます。
    その為、事業者の所属社員に対する経費精算の支払いや、あらかじめ利用者に売上金を支払うタイミングが決まっている事業者等にとって適した方法かと思います。
    なお、こちらはAPI接続と違い開発が不要な為、すぐに導入できるのもメリットとなります。

デジタル給与の解禁について

最近では、デジタル給与の解禁も話題となっています。
一方で、「デジタルウォレットで給与を受け取って本当に活用できるのか」と心配している事業者や会社員の方も多くいるかと思います。
現時点でデジタル給与払いの提供事業者や細かい点については決定していませんが、デジタル給与解禁に向けた準備段階として、まずはKyashで経費精算を行い、デジタルウォレットでお金を受け取ることに慣れていくという使い方もできるかと思います。

終わりに

本サービスに関して詳細を聞いてみたい場合や、資料請求を行いたい場合は、こちらからお問い合わせください。

なお、Kyashでは積極的に採用活動も行っています。
少しでもKyashにご興味がありましたら、こちらをご確認ください。

SwiftUIで少し凝ったアニメーションを実装した話

はじめに

はじめまして。KyashのモバイルチームでiOSアプリの開発を担当している emoto です。 Kyash Advent Calendar 2022の12/11担当分です。

今回、下のような少し凝ったアニメーションを SwiftUI で実装しましたので、その概要を紹介します。

このアニメーションを実装したのは、Kyashアプリでカード発行を申し込む際に最初に表示される画面です。
Kyashで発行するカードは利便性だけでなく、デザインにもこだわっているので申し込み時に実際のデザインや選んだカラーを表面と裏面で切り替えて確認できるようにしています。

実装のポイント

この記事のポイントは下記の2つです。

  • アニメーションを2つに分割する
  • アニメーションの完了を判定する方法

こちらのサンプルアプリでコードを一部紹介します。

前提

まず前提から。
Viewの「Z軸方向の上下」と「位置」を変えたいので、ZStackで囲って .offset.zIndex を使います。

ZStack {
    blueView
        .offset(x:y:) // 位置を指定
        .zIndex() // Z軸方向の上下を指定

    redView
        .offset(x:y:)
        .zIndex()
}

アニメーションを2つに分割する

ここからが本題です。
アニメーションの動きを見て reverse を上手く使って実装できないか考えたのですが、カードの上下が入れ替わって画面中央に戻る時の座標が元の座標と異なるので実現できませんでした。 そこで、

  • ①左右に広がるアニメーション
  • ②カードの上下を入れ替えて画面中央に戻るアニメーション

の2つに分割しました。こうすることでアニメーションの記述がとても単純になります。

①左右に広がるアニメーション

let animationDuration = 0.2

// RedViewが上に来ているかどうか
@State var isRedViewAbove = true

ZStack {
    blueView
        .offset(x:y:)
        .zIndex()
        // アニメーションの実行時間と、どの値の変更を監視してアニメーションするかを指定
        .animation(.easeInOut(duration: animationDuration), value: isRedViewAbove) 

    /*
     * redViewも同様
     */ 

    Button {
        // どちらのViewが上にあるかで場合分けして、左右に開いた時のOffsetに更新する
        if isRedViewAbove {
            // Update Offset for Slide Horizontally
        } else {
            // Update Offset for Slide Horizontally
        }

        // アニメーションのtriggerになるisFrontCardAboveを更新する
        isRedViewAbove.toggle()
    } label: {
        Text("Tap to Change")
            .foregroundColor(.white)
            .background(
                 Color.black
                 .contentShape(Rectangle())
                 .frame(width: 150, height: 44)
            )
    }

}

②カードの上下を入れ替えて画面中央に戻るアニメーション

let animationDuration = 0.2

// RedViewが上に来ているかどうか
@State var isRedViewAbove = true

ZStack {
    blueView
        .offset(x:y:)
        .zIndex()
        .animation(.easeInOut(duration: animationDuration), value: isRedViewAbove)
        // アニメーション①のtriggerを監視して、アニメーション②を実行
        .onChange(of: isRedViewAbove) { newValue in

                // どちらのViewが上にあるかで場合分けして、画面中央に戻る時のOffsetとZIndexに更新する
                if isFrontCardAbove {
                     // Update Offset for Slide Center
                     // Update ZIndex
                } else {
                     // Update Offset for Slide Center
                     // Update ZIndex
                }
            
        } 

    /*
     * redViewも同様
     */
    
}

アニメーションの完了を判定する方法

アニメーションを上記の①②に分けたことで、アニメーション①の完了を検知してアニメーション②を実行する必要が出てきます。SwiftUIではアニメーションの完了を検知する手段が用意されていないので、

「アニメーション①の実行時間と同じ時間だけ、アニメーション②を遅延実行する」

ことで間接的に検知しました。正直ここは改善の余地があると思っています。

let animationDuration = 0.2

// RedViewが上に来ているかどうか
@State var isRedViewAbove = true

ZStack {
    blueView
        .offset(x:y:)
        .zIndex()
        .animation(.easeInOut(duration: animationDuration), value: isRedViewAbove)
        // アニメーション①のtriggerを監視して、遅延実行
        .onChange(of: isRedViewAbove) { newValue in

            // アニメーション①の実行時間と同じ時間だけ、アニメーション②を遅延実行する
            DispatchQueue.main.asyncAfter(deadline: .now() + animationDuration) {

                if isFrontCardAbove {
                     // Update Offset for Slide Center
                     // Update ZIndex
                } else {
                     // Update Offset for Slide Center
                     // Update ZIndex
                }
            }
        } 

    /*
     * redViewも同様
     */
    
}

最後に

Kyashでは一緒に働いてくださるエンジニアを募集中です。 Fintechにご興味のある方是非是非選考のご応募待っております

herp.careers

従業員たちでKyashの未来の機能を考える会を開いてみた

Kyashの @masamatsu66 です。
この記事は Kyash Advent Calendar 2022 10日目の記事です。

Kyash歴は年末でちょうど2年半となります。TechのServerSideチームでEMをやっております。今回はTechチームの話題ではなく、会社でちょっと変わったイベントを開催したので、その件を紹介したいと思います。

イベントを開催した背景

まずKyashでは、新しい企画やサービスを作る際にまずPR/FAQというものを作成します。これはAmazonが始めたもので、ざっくり言うと通常リリース後に発表するPress ReleaseやFAQを企画段階で作成するというものです。そうすることによって、ターゲット層やどういった課題を解決しようとしているのか、想定し得る問題に対してどのように考えているかについて社内でも認識を揃えやすくするための方法として使われます。

このPR/FAQはProduct Managerが作成することが多いのですが、Kyashでは社員の誰でもPR/FAQを企画し提案できることとなっています。しかし、ぼんやりと「こんなことをやると面白いかも」と思うことはあってもそれを企画書として提案するまでに至ることは中々ないでしょう。実際、KyashではまだProduct ManagerやMarketing職以外から提案された事例はありません。

一方で私は、ベンチャーのような比較的規模の小さい組織にJoinする動機の一つに、自分の本来の役割を超えて関われる余地が大きいという点があると考えています。過去に自分のチームから、銀行口座からKyashへの入金に対して自動チャージの機能を入れたいという話が持ち上がり、当時はPR/FAQという方法ではありませんでしたがProduct Managerとも議論を重ね実現することができて自分自身の決済体験がとても良くなったという経験をしたことがあります。そうした経験から是非、自分が先陣を切って社内に企画を提案する人たちを増やす動きができないかと考えるようになりました。

周囲の反応

何か新しい試みを始めようとするときに周囲の温度感というのはとても大事です。賛同してくれる人が多ければモチベーションが上がりますが、無反応だと下がってしまうものです。なので若干ドキドキしながらですが、Kyashでどんなことが出来るようになると良いだろう、という話をみんなとしてみたいと提案をSlackに投げてみることにしました。すると最初はポツポツとスタンプが付いてくる感じだったのですが、数日後には20名を越える方々からポジティブな反応をいただきました。

自分も話したいという人はもちろん、予定が合わないけど録画してくれれば後で見たい、子供の世話などがあって議論には参加できないけど聞くだけでも参加したいなどもいたので全員で議論できたわけではありませんがポジティブな反応をいただいたので自分のモチベーションも上がりました。また後日に「イベントの開催を知らなかったけど、次があれば参加したい」と言ってくださる人もいたのが嬉しかったです。

当日

議論には自分を含め8名となり、聞くだけ参加の人が数名という形での開催になりました。各々が十分に発言するには8名は少し多かったので4人グループ x 2に分けて行うことにしました。

進めるにあたって少しだけルールを設けさせてもらいました。

  • この場は発散が目的。実現可能性は一旦忘れる。

  • 否定から入るのはこの場では禁止。「法律がー」「リソースがー」「資金がー」「利益がー」「それは既に他社がー」というツッコミは今はしない。

企画が本職の人たちの間では半端なアイデアを出すと厳しいツッコミも色々受けるのかもしれませんが、社員たちが各所で「あんなことできるといいな」という議論が活発に行われるようにするためのきっかけにもしたいので、この場ではこのようなルールとしました。

各グループで一時間ほど議論しましたが、結構な数のアイデアが出てきました。中には現実的で良さそうなものもありましたし、方向性として良い整理にできそうな発想のものもありました。

議論で出てきたアイデアの付箋
議論で出てきたアイデアの付箋

まとめ

良いアイディアも出てきたし、こうした議論をしたがっている人が社内に多くいると確認できたのは良かったです。一方で本当に大変なのはここからで、出てきたアイデアをPR/FAQなどの企画書の段階に昇華させるという作業を普段の仕事とは別にやるのは中々時間を取るのも大変です。しかしこういった活動から実際にユーザーに価値を提供できる機能やサービスを実現した体験を生み出せるとみんなのモチベーションにもプラスになるし、これからKyashへのJoinを検討してくれる人にも、こういったことが出来る会社なんだということをお見せできればなと思っていますので引き続き頑張っていきたいと思っています。

Kyashでは会社の仕組みもプロダクトも皆で作っていっています。「まずやってみる」みたいな動きが好きな人にはわりとオススメできる環境だと思うので、興味がある方はDMでも応募でもぜひ気軽に連絡をお願いします!