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レベルでイケてるかどうかを確認できる

Google Cloud で実行されている DevOps 組織の有効性を評価するより引用

自動化できる
- GitHubやJira、Kibela、SlackのAPIを使ってダッシュボード化も可能

エリート 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を導入することで、リードタイム、デプロイ頻度を改善します
- すでに取り組みを初めているので詳しくは下記をご覧ください
  - 軽量feature flag導入の手引き - Qiita
安全にQAを行える環境を整える
- 現状、Kyashの開発環境はカオスな状態です
- カオスな開発環境やQA環境をきちんと交通整理します
- こちらも達成したらBlogを書こうかなと思います
お知らせ and Push通知欲張りセット
- Kyashのお知らせとPush通知基盤は現状あまりイケていません
- しかしお知らせやPush通知は新機能を作る上で避けては通れません
- 基盤を作り直すことで工数を大幅に削減できそうであるので、こちらに取り組みます

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

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

最後に

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

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

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