Tech Teamの生産力を爆上げすべくGrowth Technology Teamが爆誕しました

はじめに

KyashでBackend Engineerをしている uncle__ko です。
この度、KyashのTech Teamの生産力を爆上げするべく新たにGrowth Technology Teamが発足しました。
このTeamが発足した背景や、これからどのようにプロダクトや組織に貢献していくのかを記載しようかと思います。

なぜ新Teamが発足したのか

Kyashはいままで沢山の機能を世の中に届けてきました。
ここ数年で言えばKyash Cardなどのリアルカードの発行をはじめ、Apple Pay・Google Payへの対応、資金移動業を取得しての銀行口座入金リリース、 カテゴリ機能や共有口座機能、さらにはBNPL（後払い）サービスであるイマすぐ入金やKyashリワードなどです。
小さな機能も合わせればもっと沢山あります。
これだけのサービスを世の中にリリース出来ていれば生産性という意味ではそこまで低くはないと思います。

しかし会社の考えるロードマップを実現するには、まだまだ生産性は低いのが現状です。

突然ですがKyashには頂点志向というValueがあります。

Kyash の Value についてご紹介です！ | 株式会社Kyash

Tech Teamも現状で満足せずに頂点志向で生産力を伸ばしていく必要があります。

そのためにTech Teamとして1つの目標をVPoEである konifar sanが中心に掲げました。

それは

界王拳 - 生産力を3倍にする

です。
※「界王拳」は、ドラゴンボールに登場する戦闘力を高める技

生産力って?

ちょくちょく言及している生産力の定義は下記です。

  • 生産力 = 単位時間あたりにTeamで生産できる価値の量
    • 生産性の向上 + 人数の増加
    • 縦軸が生産性、横軸が人数の四角の面積

なぜ3倍なのか

細かく計算したわけではないのですが、 会社の求める事業の成長スピードを考えると、たぶん3倍くらいにはしないといけないと考えています。
高い目標を設定することによって飛躍した発想で解決することを目指すためです。
konifar sanが決めて、Engineerに経緯と意図を事前に説明し、賛同を得て決定しました。

なぜTech Team全体で生産力を追うことにしたのか

  • Tech Teamの価値は、最終的に「世の中 (=ユーザー)に 何を届けたか」にあると思っています
    • 「技術的負債をなんとかする」「インシデントの数を減らす」といった取り組みで生産性を上げるのはもちろん、採用や外注で開発人員を増やすという選択肢も含めて考えていくために「生産力」を置きました
    • 「生産力をあげるために => 技術的負債に向き合い採用もやっていく => 価値を早く届けられるように => ワクワクして誇れるTeamに」という考え方です

なぜ新Teamが発足したのか

Engineerをしている方ならわかると思いますが、普段プロダクト開発をしていると工数や期限を考慮して技術的負債を産んでしまうことは多々あります。
そしてあとでその負債を解消しようとしても、次の開発に追われて結局負債は積んだまま、次の負債を産んでしまうという負のループ……。

生産力を3倍にするためには、Engineer採用に力を入れるのはもちろんのこと、きちんと技術的負債にも目を向け解消していくことで達成できるのではないかと考え、それらの課題解決に特化した新TeamをTech Team内に発足するに至りました。

Growth Technology Teamが追うべきもの

Tech Team全体では生産力を追っていくという方針を決めましたが、その中で新TeamであるGrowth Technology Teamは何を追っていくのかを書いていきます。

Four Keys

あたらしく発足したGrowth Tech TeamではLeanとDevOpsの科学やGoogleのDevOps Research and Assessment (DORA)で検証されているFour Keys（リードタイム・デプロイ頻度・変更失敗率・復元時間）を追うことにしました。

それぞれの定義は各社・各Teamで決めてよいとされていますが、Growth Tech TeamではDORAに合わせて下記のように定義しています。

指標 概要
デプロイの頻度 組織による正常な本番環境へのリリースの頻度
変更のリードタイム commit から本番環境稼働までの所要時間
変更障害率 デプロイが原因で本番環境で障害が発生する割合（%）
サービス復元時間 組織が本番環境での障害から回復するのにかかる時間

なぜFour Keysを追うことにしたのか?

大きくは下記が理由です。

  • 定量的に計測できる

    • 定義を明確にすれば計測できる。推測するな、計測せよ

  • 世の中の水準で現状を評価できる

    • Google Cloud で実行されている DevOps 組織の有効性を評価する にあるように、それぞれのKeyごとにElite、High、Medium、Lowの4レベルでイケてるかどうかを確認できる

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_breaking_down_devops_perf.max-2800x2800.jpg Google Cloud で実行されている DevOps 組織の有効性を評価する より引用

https://storage.googleapis.com/gweb-cloudblog-publish/images/Four_Keys_pipeline.0805029014550550.max-1100x1100.jpg エリート DevOps Teamであることを Four Keys プロジェクトで確認する より引用

この辺の自動化、ダッシュボード化については新Teamで最初に取り組む課題でもあるので、達成したら別途Blogを書こうかと思います。

Product開発を行っているメンバーにアンケートを取る

Four Keysが定量的に計測する目標とするならこちらは定性的な目標です。
生産性やインシデント数を減少させるのはもちろん大切ですが、実際にProductを開発しているメンバーに不満が溜まっては意味がありません。
Growth Technology Teamが行った施策の感想や開発する上でストレスなこと、Growth Technology Teamに解決してほしい技術的課題などを定期的に吸い上げていこうかと思います。

2022年内の目標

  • リードタイムを3倍にする
  • デプロイ頻度を3倍にする
  • 変更失敗率を2/3にする
  • 復元時間は現状を維持する(2022年度内にここに向けた施策をやる余力がないため)

まだ発足したてなのでアンケートについての目標は設定していません。
来年度以降に取り組んでいきます。

2022年に実施予定のタスク

目標達成のために実施する予定のタスクは下記です。

  • Four Keysの自動計測
    • まずは目標を計測できるように自動計測の仕組みを構築します
    • 変更障害率の計測のためにインシデントフローの整備も必要かもしれません
  • Featureフラグの導入
    • Feature flgを導入することで、リードタイム、デプロイ頻度を改善します
    • すでに取り組みを初めているので詳しくは下記をご覧ください
  • 安全にQAを行える環境を整える
    • 現状、Kyashの開発環境はカオスな状態です
    • カオスな開発環境やQA環境をきちんと交通整理します
    • こちらも達成したらBlogを書こうかなと思います
  • お知らせ and Push通知欲張りセット
    • Kyashのお知らせとPush通知基盤は現状あまりイケていません
    • しかしお知らせやPush通知は新機能を作る上で避けては通れません
    • 基盤を作り直すことで工数を大幅に削減できそうであるので、こちらに取り組みます

2023年以降実施したいタスク

  • マイクロサービスの単位の見直し、切り出し
    • 神サービスがいたり、明らかに必要なサービスが存在していないことが多々あるので、きちんとした単位でサービスを切り出します
  • 定常業務の管理画面化
    • Engineerが手動作業しているような定常業務を管理画面化します

最後に

このように技術的負債の解消に取り組み、色々な仕組み化を行っていくことでデプロイ頻度が増え、障害発生率も減っていき生産力が爆上がりするといいなと思ってます。
Kyashで働くEngineerがKyashでProductを作ることが楽しいと思えるような環境をGrowth Technology Teamが作っていければなと思います。

現在KyashではEngineer採用に力を入れています。
Growth Technology Teamで生産力を爆上げしたい方はもちろんのこと、一緒にProduct開発をしていきたい方も募集しています。
ぜひご応募いただければと思います！

また、ここでは書ききれなかったこともあるので、詳しく聞きたい方はカジュアル面談でお話しましょう！

MobileチームがKMM化、宣言的UI、Widget対応などを話すKyash Tech Talkをやります

Kyashの @konifar です。

2022年4月21日 (木) 13時から Kyash TechTalk #3 Mobileチームのチャレンジと課題 - KMM化、宣言的UI、Widget対応 というMeetupをやります。

これらのテーマはチームで半年以上取り組んでいるものですが、対外的に話すのは初めてです。せっかくやるならたくさんの人に来てもらいたいのでしっかりめに告知します。

kyash.connpass.com

続きを読む

Kyash Techチームの展望

こんにちは、Kyash CTOの山﨑です。

3月17日にアナウンスさせていただきましたとおり、49億のシリーズDとなる資金調達を行いました。 このblogでは約2年前のシリーズCの調達からKyashがやってきたことを開発や事業目線で振り返り、今後どういった領域に注力するかということを書いていきます。

シリーズCから今までプロダクトKyashがやってきたこと

2020年3月、シリーズCの直後にtoBのプロダクトとして立ち上げたKyash Directを事業譲渡し、会社のミッションである「価値移動のインフラを創る」をtoCのプロダクトであるKyashで実現していくことを決定しました。 その後、銀行口座からの入出金、カテゴリー（家計簿）、共有口座などバンキングとしての機能を強化してきました。また、券面にカード番号を印字せず非接触決済に対応したシンプルでスタイリッシュなKyash Cardのローンチ、Apple Pay対応、モバイルのみで本人認証が可能な3Dセキュアに対応し、カード決済における新しいユーザ体験をいち早く届け業界を牽引してきました。更に後払いサービス（イマすぐ入金）の提供を開始し、決済や送金に留まらない価値を提供してきました。

事業としては、ユニットエコノミクスの黒字化を達成できました。決済事業のみで持続可能な事業構造を描くのが難しい業界において、大きなマイルストーンを一つ達成できたと感じています。

当時私はKyash Direct事業の開発推進をメイン業務にしていたこともあり、正直に言えば事業譲渡の方針を残念に思いましたが、プロダクトとしてのKyashの進化にフォーカスし、結果を作ってきた点が評価されたことは本当に嬉しく思います。また一つひとつのプロジェクトに対してお客様への価値を真剣に考え、全力で取り組んでくれたメンバーに大きな感謝をしています。

シリーズC以降のKyashのTechチーム

Go言語でマイクロサービスを開発するという基本方針は変わっていませんが、実行環境をAWS Fargate+ECSに移行したり、内部設計はレイヤードアーキテクチャを採用するなど、ある程度自分たちのベストプラクティスが見えてきた状況です。このあたりはマネージドサービスの進化やマイクロサービスの運用、PCI DSSなどシステム監査を組織としてしっかりと積み重ねてきた結果と言えるでしょう。 では課題が無いのかと言ったらそんなことはなく、責務がfatになりすぎているマイクロサービスやデータベースがあるのも事実で、この点は後述する通り改善が必要だと考えています。 また、モバイルチームではビジネスロジックをiOSとAndroidのプラットフォームに依存しないようKotlin Multiplatform Mobile（KMM）を採用する決定をチームで行いました。組織もiOSとAndroidというプラットフォーム毎のチーム構成を廃止し、mobileチームとして統合することでこの推進を後押ししています。

これからのKyashの展望

現時点で金融システムの規制緩和の様々な議論が進んでいます。今年は新しい少額決済インフラのローンチが予定されていますし、資金移動業者のようなノンバンク決済事業者に全銀システムや給与支払いが開放される動きなどもあり、私達のようなプレイヤーはここに対してしっかり準備していくことが必要だと考えています。すでに社会的なインフラを担っている自負はありますが、その責任や影響がより高まっていくと感じています。

そこで、システムのスケーラビリティやパフォーマンス、品質などの非機能要件を更に向上させる必要があると考えています。上で課題に上げましたが、責務がfatなマイクロサービスやデータベースがあるという状況に対するテコ入れが必要だと考えています。しかしエンジニアの数も十分とは言えない状況で、多数のマイクロサービスを運用しきれるのか、ビジネス推進と両立させられるのか、といったポイントとともにこれを進めていくことは個人としてもチーム全体としてもチャレンジになる部分です。

更に不正アクセスへの備えや帳簿書類（お客様の口座にある残高や取引情報のレポート）など、サービスの信頼性の根底となる部分への技術投資も必要だと考えています。不正アクセスや不正決済の検知は業界でもAIの導入が進んでいますし、帳簿書類は1円でも誤差が許されない領域です。この分野のクオリティを更に上げるためのソフトウェアやミドルウェア、もしくはマネージドサービスの導入を推進したいです。

そして注力したいポイントがもう一つあります。それはITガバナンスやセキュリティ領域です。 リスクや脅威は、外部はもちろん内部からも起こりえます。お客様の資産をお預かりし社会的なインフラを担う責任があるサービス提供者としては、両方を適切にリスクマネジメントをする必要があります。日々お客様へ価値を届けようと頑張っているメンバーが、内部不正のリスクや疑いを負わないようなガバナンスの整備を更に強化したいと考えています。また、外部からの攻撃手法の多様化や国際化が進んでいる中で、カード情報セキュリティにおけるグローバルセキュリティ基準であるPCI DSSの取得はしているものの、更なるセキュリティの強化を目指しています。

最後に

このblogで開発チームの今後の概要となる部分を書きました。これからサービスとして大きくジャンプしていくためにも、これまで以上にチームを強化をしていきたいと考えています。課題を見つけ解決していきたい、事業貢献を肌で感じたい、自分が使っているサービスを自分で良くしていきたい、技術をスキルアップさせたい、そんなエンジニアの皆さまからエントリーをお待ちしております！詳しく記載できていない箇所も多いので、カジュアル面談でお話ししましょう！

meety.net

meety.net

herp.careers

Kyashの挑戦

こんにちは。Kyash CEOの鷹取です。

先日発表しました当社シリーズDの資金調達という節目のタイミングで、
① Kyashのこれから

② Kyashのチャレンジ

について書きます。

 

まず、資金調達について少しばかり。
ありがたいことに今回も様々な記事に取り上げていただきました。

ドーシーCEOの米決済ブロック、日本のKyashに出資: 日本経済新聞

Block backs Japanese fintech startup Kyash in $41.2M round – TechCrunch

f:id:s_takatori:20220325152458p:plain

今回の資金調達に関しては、2020年にKyash DirectというBtoBのホワイトラベルでのカード発行事業を事業譲渡し、消費者向けに注力すると意思決定をしてから初めての資金調達でした。その後も、経営体制の強化や資金移動業の登録、後払いサービス「イマすぐ入金」の提供など組織や事業で様々なことがありましたが、今回のラウンドで国内外の業界を代表する方々に参画いただけたことは、私たちの勇気になっています。

 

資金調達は切符

 

創業から心がけているのは、資金調達は不可逆であり大切な一方、「資金調達それ自体によってプロダクトは一ミリも変わらないことを忘れない」です。プロダクトが価値を持ちうるのは、情熱あるチームやパートナーによってしか創られ得ないと思うのです。

今回の資金調達で投資家のみなさまにコミットしたビジョンとインパクトは、現在の100人のチームだけでは到底実現できないのです。

Kyashは、今後も積極的に人材の採用を行なっていきます。スタートアップとしてはレイターステージと言われることもありますが、Kyashは会社として生き長らえることを目的にはしていません。チャレンジャーとして価値移動のインフラを創り、お金の新しい文化を創ることを通じて、変わりゆく社会に貢献することが目的です。

ここでいうチャレンジャーは、他社に対する趣旨ではなく、新しい社会 = New Economy に対するチャレンジャーであり続けたいという想いで使っています。

 

Kyashは何をやっているのか

GDP世界3位、民間最終消費が300兆円ある日本が、キャッシュレスや金融サービスの進化という点においては、国としてまだまだ道のりが長いことが下のグラフからもわかると思います。国全体のGDPの約20%を占める最大産業である金融が変われば、社会に対するインパクトが大きいことも明確です。そして、Kyashを創業してからの直近数年のうちに、金融のインフラは業界を超えて、Eコマース・小売や貿易、法人や行政サービスへのインパクトが極めて大きいことを認識しました。

f:id:s_takatori:20220322090411p:plain

主要国の現金比率（Statista）

f:id:s_takatori:20220322090408j:plain

業種別のGDP（Coomerce Department : WSJ）

Kyashはその中にあって、キャッシュレスのみを目指している会社ではありません。新しい価値移動のインフラ、それはすなわち人々が価値交換をするインフラ自体を1行のコードから創ってきました。そのインフラという新しいお金の高速道路を創りつつ、Kyashは「Kyash」というアプリケーションを通じて人々がお金をコントロールできるサービスの提供に努めています。

 

社会における行動変容は消費者から

上記のような、新しい価値移動が社会に定着していくには、一定の手順があると思っています。まず、このような変化は消費者の行動変容から始まっていくということです。Kyashがこれからチャレンジしていくのは、まさにその行動変容を促す部分であり、大きな変革の可能性を秘めています。Kyashでのプロダクトで大切にしていることはこちらの記事を参照ください。

このチャレンジをしている最中にも、世の中は変わります。人々と社会の未来を想い描きながら、どこにセンターピンを置いて人々の暮らしに貢献するかをチームでこれからも考え抜き、チャレンジし続けていきたいと思います。

そして、企業として取っていく戦略も、社会にとって正しい選択肢かという視点を軸に、意思決定をしていきます。

 

最後に

2015年の創業以来、ことあるごとに見返していたYouTubeでのJack Dorseyの言葉、" You are making the bet that other people want to see the same thing in the world." は、答えが示されない世の中で信念を持つ尊さを私たちに伝え、私も大変魅了されてきました。
奇しくも、今回の資金調達でJack Dorsey率いるBlock社が参画したことは個人としても感慨深いことです。

Kyashの挑戦を一日でも早く、より良い形で実現するためにも、チャレンジャーの方々に加わっていただきたいと心から思っています。

 

募集職種はこちら

カジュアルな面談も随時行なっておりますので、私もしくはKyashのチームメンバーに気軽にご連絡いただければと思います。

 

引き続き、Kyashをよろしくお願いします。

 

==== 告知 ====

3月31日(木) 19:00よりオンラインイベント「Kyash プロダクトカンパニーとしての挑戦」を開催予定です。

イベントページ： https://kyash.connpass.com/event/243044/ 

これからのKyashの挑戦と上記で書いた内容をもう少し踏み込んでお話しさせていただきます。

Kyashが大切にするクラフトマンシップについて

この記事はKyash Advent Calendar 2021の25日目の記事です。 Kyash創業者の鷹取です。

今年の振り返り

早いもので2021年もあと数日で終わりを迎えようとしています。去年のアドベントカレンダーでは「Kyashは口座をソフトウェア化する」について書きました。その象徴的な取り組みとして、ちょうどつい先日Kyash法人送金をリリースしました。（ニュース記事）チームで構築しているこの送金インフラがさらに大きく社会に貢献できる確信を持つ年になりました。Kyashのミッションである「価値移動のインフラを創る」取り組みを前に進めていきます。 法人送金サービスについて少し補足しますと、今般開始したKyashの法人送金は、デジタルウォレットアプリとしての「Kyash」の利便性向上を目指したもので、昨年事業の一部を譲渡したことを発表したホワイトラベル（OEM）の法人向けカード発行ビジネス「Kyash Direct」とは異なります。

Kyashのクラフトマンシップ

さて、今年のエントリーはKyashが大切にするクラフトマンシップについてです。ここではクラフトマンシップを、合理的なサービス作りに留まらず、「ユーザーの期待を越えるプロダクト創りにコミットする姿勢」とします。それはスピードであったり、圧倒的に簡単な体験だったりと要素は様々あります。 今回は、このクラフトマンシップを貫く上で、Kyashのテクノロジーとデザインが果たしている役割がとても大きいことを書きたいと思います。

Kyashはプロダクトカンパニー

Kyashはプロダクト中心の会社でありたいと思っています。まずは価値観の背景についてです。

これは私自身の生い立ちに関係があると思います。私の母方は大阪で100年以上営む寿司屋をやっています。こだわって握る一貫でお客様に笑顔になって欲しいという祖父や叔父の想いを聞いて育ちました。ウェブサービスやプロダクトも、寿司屋と同じだと感じることがあります。寿司屋でいう店構えをどうするかは、プロダクトでいうUI（インターフェース）であり、店内の空間や寿司の味はUXや利便性であると。インターネットという住所のない場所でプロダクトを提供し、サービスの中ではユーザーの皆さまを私どもが直接お出迎えすることが叶わない環境だからこそ、プロダクトの体験やユーザーの心情に一層想いを馳せたい。これこそがKyashの消費者（C向け）ビジネスの醍醐味だと思うのです。そしてこれがユーザーの皆さまに支持いただけるレベルで実現できれば、ウェブサービスの強みを発揮して、より多くのお客様にご提供することが可能になります。 このプロダクト造りにおいて、テクノロジーとデザインが果たす役割は実に大きいです。メニューがわかりづらく、注文しても待ち時間が長いお店にお客様は戻ってきません。同じように、ウェブサービスでは、いかに直感的でストレスがないプロダクトの体験を創れるかが問われてます。そのレベルをいかに高められるか、従来の常識に囚われずにユーザーの期待値を越えられるかが面白味でもありチャレンジだと思っています。

テクノロジーチャレンジ

Kyashは、自社でKyashカードを利用した世界中の決済を処理するシステムや個人間送金システムをエンジニアがゼロから開発してきました。金融の世界は、ベンダーが構築するパッケージシステムを使用することが多いのですが、提供できる体験に多くの制約がかかるためです。モバイルアプリケーションよりも一段低いレイヤーで金融インフラ自体の技術を創っていることから、創り出したい体験に対する自由度が極めて高いという大きな強みがあります。他方で、機能のラインアップが増えることで発生する複雑な処理やサーバー負荷をコントロールし、直感的でストレスのない体験を維持する必要があります。Kyashには、日々技術的な研鑽を積み、汎用性が高くスケーラブルなアーキテクチャを追求し続けてなるべく早くユーザーに価値を届けようと取り組むエンジニアチームがあります。実際に金融業界出身のエンジニアはほとんどおらず、ウェブサービスとしてのKyashによってユーザーの暮らしに貢献しようとするエンジニアが集まっているのは、Kyashの大きな特徴でもあり強みになっています。

デザインチャレンジ

プロダクトの体験という意味で、Kyashのデザイナーが果たす役割は大きいです。デザイナーは、「ユーザーの課題を解決する」というとても大きなミッションを持っています。その中で、Kyashが担うテクノロジーの深さから、変えられる要素が大きいため、体験のアクセントをどのように設計するかとても悩ましいところだと思います。Kyashのデザインチームは、プロダクトでできることが増える途上にあるとき、その時々でどのようなカスタマージャーニーを理想とするのかを考え抜き、プロダクトやクリエイティブに落としています。Kyashの直感的なプロダクト体験が提供できているのは、Kyashのデザインチームの貢献によるものが大きいです。またKyashは、社会的な意義をどのように捉えるのか、そして未来のお金と人間との関わりをどうデザインするのか、といったインダストリーデザインの要素があります。この領域に関しては、今後デザインチームと共に掘り下げていき、発信を増やしていきたいと考えています。

Kyashのビジョン

Kyashは、世の中でも最も色がなく、無機質の象徴とされる「お金」をテーマに挑戦しています。私自身が元銀行員として業界が抱える課題を認識していることもあります。ただそれよりも大きな要素として、Kyashのチームは今まで「システムを正しく動かすこと」が最優先だった金融サービスを人間中心（Human-centered）に再設計していきたいと考えています。 その意味で、Kyashはフィンテックでありながらライフスタイルサービスだと捉えています。人びとの暮らしの中で介在するお金はどうあるのが良いのか、暮らしが良くなるのか、を考えながら今後もプロダクトを創っていきます。ワクワクする理想の体験が求めるテクノロジーやデザインに対して期待されるレベルはとても高いのです。このようなプロダクト創りを通じて、ちょっと先の未来をもたらすミッションに興味を持っていただけそうなデザイナーやエンジニアの方、ぜひお話をさせてください。

herp.careers

来年のエントリーでは、Kyashは何を変えたのか、ユーザーの暮らしに貢献したポジティブな変化について書けるような年になるよう、Kyashのチーム一同努めてまいります。

Kyashの全社会議"All Hands"が2021年にやったこと

これは Kyash Advent Calendar 2021 の23日目の記事です。

Kyashでカスタマーサポートを担当しているすーもです。この記事では、Kyashの全社会議「All Hands」の1年間を振り返ります。2020年の取り組みについては『KyashでやってるAll handsの話』で紹介していますので、ぜひご覧ください。

続きを読む