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でも応募でもぜひ気軽に連絡をお願いします!

Goの勉強会はじめました

Goの社内勉強会はじめました

はじめに

Kyashの @uncle__ko です。
普段はTechチームの生産力向上のためにfourkeys基盤の構築や、リアーキテクチャ含めた技術的負債の解消などを行っております。

僕のやっている仕事については記事を書いてるので、興味があれば見ていただけると幸いです。

blog.kyash.co

今回は社内でGo言語の勉強会をはじめてみたので、そのことについて書こうと思います。

KyashとGo

KyashのServerSideは基本的にGoで書かれています。
一部Pythonを使っていたりScalaを使っていたりしますが、9割以上はGoで書かれています。
ですのでKyashのServerSideエンジニアとして働く以上は絶対にGoと関わることになりますし、勉強は避けては通れない道です。

KyashがGoを採用している理由はいくつかありますが、主に以下のようなことが挙げられます。

  • 文法がシンプルで可読性が高く、直接機械語コンパイルするため、消費リソースも抑えられ実行速度も早くなる傾向がある
  • 言語レベルでGoroutineという軽量スレッドがサポートされていて、平行処理も比較的簡単に書くことができる
  • クロスプラットフォームに対応していて、あらゆる環境用に簡単にコンパイルできる
    • 金融系だとWindowsでしか動かないツールと共存しないといけないこともよくある

採用の面でも、Goは比較的注目されている言語で、創業当時は感度の高いエンジニアが多く応募してくるという意味でも、Goを選択したのは正しい選択だったと思います。

Goの勉強会はじめてみました

そんなわけで、KyashのServerSideエンジニアとして働く以上避けては通れないGoの学習を会社の中でわいわい楽しくできるといいなと思い、勉強会をはじめてみました。 また、Goコミュニティは比較的Goへの愛がある人が多いイメージもあり、Gopherを増やすべく社内勉強会を開催している企業の噂もよく聞くので、Kyashでもはじめてみたいという想いもありました。

社内でのGo勉強会「Kyash.go」の目的

目的としては下記を置いています。

  • 社内のTechチームの中でGoの知見を広げていこう!
  • 社内のTechチームだけではなく社外にもKyashはGoでやってるぞ!っという発信もしていこう!

すごい気軽にはじめてみたので、あまり重すぎたり準備が必要だと負担に感じてしまうかなと思い、気軽にだれでも準備不要で参加できる勉強会にしていこうと思っています。

どんな感じで運用しているの?

開催間隔は隔週で行っています。
まだ初めてみたばかりですので、もしかしたら週イチ開催になるかもしれません。
時間は45minで、僕と一緒にこの勉強会を立ち上げた @convto と僕でファシリを行ってます。

短期的な成果や発信するノルマ(ブログ書けとか)は特に設けずに、ゆるく楽に続けていくことが目標です。

来るもの拒まず、去る者追わず。
参加したいテーマの会だけ参加するのもOKとしています。

もちろん資料を作ってがっつり話したい人がいれば、作ってもらっても全く問題ないです。
楽に長く続けていくことが大事だと思っているので、できるだけ運用負荷は少なくはじめました。

どんなことしてるの?

準備不要でどんなことをするのか記載すると、下記のようなことを想定しています。

  • Go Spec をみんなでワイワイ読んでみる
  • Proposal 眺める
  • Release notes みる
  • The Go Blogとかよむ(Memory Modelとかおもしろそうなやつ)
  • 標準パッケージ読む

直近ですと、1.19 がリリースされたので、みんなでRelease Notesをみてワイワイ盛り上がったりしました。

ゆくゆくはGo Conferenceのスポンサーしたり、Proposal出してみたりしてもいいかなっておもってますが、まずは勉強会を継続していくことに重きを置いていくつもりです。

さいごに

Kyashでは、こんな感じでゆるく勉強会をはじめてみました。
Goが好きなエンジニア、Goに興味があるエンジニアの方は積極採用中ですので、お気軽にご応募ください!

herp.careers

KyashのServersideにまつわる新しい挑戦について話すKyash Tech Talkをやります

Kyashの @convto です。

普段はサーバーサイドの開発をゴリゴリ頑張っていますが、お祭り事も好きなので開催予定のmeetupの運営についてもガッツリ関わっております。

2022/9/12(月) の13時から Kyash TechTalk #4 - Serversideと新しい挑戦 - connpass を開催するので、より広く知ってもらうために告知しつつ、YouTube Liveでお昼開催!などのチャレンジもしているので、そのあたりの狙いや背景を紹介できればなと思います!

kyash.connpass.com

開催の経緯

今年の4月ごろに Kyash TechTalk #2 - Serversideのシステム構成とアーキテクチャ - connpass を実施しました。
とてもありがたいことに多くのかたにご参加いただきKyashの取り組みを知っていただけました。ご参加いただいた皆様のおかげでよいイベントとなり、とても感謝しています!

いっぽうで、前回のイベントではありのままのKyashを知ってもらうことを重視していたため、イベントの内容としては

  • Kyashのシステムの現状や現実世界の制約を受けた難しさの紹介
  • その中で良いものを作っていくための努力

など、すこし泥臭い話題がメインでした。

じゃあKyashは泥臭い仕事ばっかりで、前向きなチャレンジはしてない開発チームなの?というとそんなことはありません!

前回のイベントではテーマが噛み合わず紹介できませんでしたが、Kyashでは日々より良い体験をユーザーに届けるため、技術的なチャレンジを伴う「システムをより良くするための開発」も行っています。

たとえばすこし前の事例だと、gRPCの導入のタイミングで整備した proto定義や成果物の管理用レポジトリを構築した話 - Kyash Product Blog などは前向きなチャレンジの一例です。

今回のイベントではそんなチャレンジにフォーカスをあてて、Kyashの魅力の別の側面をご紹介できたらなと思っています!

YouTube Liveでお昼配信なのなんで?

いろんな人に気軽に見てもらいたいなーと思っていろいろ考えた結果こうなりました。

例えばお子さんがいたり、またはプライベートの用事と重なったり、ご家庭の事情やタイミングよっては業務時間外だと参加が難しい方もいそうなため、できるだけ多くのひとが参加できるように平日お昼の開催としました。

YouTube Liveでの配信は前回イベントからですが、それぞれのライフスタイルに合わせてご参加いただけるように考えて少しずつやり方を変えています!

URLを押すだけで手軽に様々なデバイスでLive配信がみれるので

  • お食事中にタブレットなどからご視聴いただいたり
  • 本腰いれて聞きたい方は作業デスクのPCからそのまま聞いてもらったり
  • 散歩しながらPodcastを聞く感覚で聞いてもらったり
  • はたまた作業中にラジオ感覚で流し聴きしてもらったり...

など、それぞれの自由な形でご参加いただければと思います!

(なお一応補足しておくと、イベント内ではスライドをつかったLTなどもあるため、Podcast的な聞き方だと画面ありでみるより若干わかりづらいとは思います。が、そのあたりも含めて自由に選べるということで)

なにを話すか

「最近こんなチャレンジしたぜ!」「これからこういうチャレンジしようと思ってるぜ!」みたいな話を主軸に、15分の発表3本 + 45分のパネルディスカッションで話します。

またパネルディスカッションについては、事前にアンケートで集めた内容やその場で出た質問に回答するなど、ある程度インタラクティブにやりとりできればと思っています!

登壇するのはserversideのメンバーと、いつもserversideをサポートしてくれているSREのメンバーです。

細かいタイトルなどはまだ未定なので、内容だけチラ見せします!

ローカル開発環境をAWSへ移行した話

SREチームから @yuu26 が登壇します!

Kyashではローカルでの開発時に複数マイクロサービスをdocker経由で開発環境を動かしていました。

このやり方は当初はうまく行きましたが、サービス数も年々多くなりつつあるため、次のような課題がありました。

  • ローカル環境に負荷がかかり開発体験を損ねていた
  • 複数サービスを手元で起動する都合で周辺ツールのインストールなどが必要で、オンボーディング負荷につながっていた

これを解決するためにSREチーム主導で開発環境をEC2インスタンスに移行しているので、その取り組みについて紹介します!

ポイント付与の非同期化について

serversideメンバーから @k_omotani が登壇します!

Kyashでは決済やKyashリワードなど色々な条件でポイントが付与されているのですが、もともとは各サービスの任意のタイミングにポイント付与処理を埋め込む形で同期的に付与していました。

これにはポイント付与コードが各サービスに散ってしまうだけではなく、ポイント付与と元処理が同期的に行われるので付与経路の条件によってポイント付与の失敗が元処理の結果に影響する場合がありました。

その課題に対応するために、ポイント付与のメッセージングによる非同期化を進めた話です!

(なお余談ですが、この設計作業はチームを超えて広く社内のメンバーと議論をし、今後の汎用的なイベント伝搬を想定した作りになっています)

開発生産性を可視化するためにfourkeys基盤を整えた話

serversideメンバーから @uncle__ko が登壇します!

以前 Tech Teamの生産力を爆上げすべくGrowth Technology Teamが爆誕しました - Kyash Product Blog の記事などで紹介した、開発生産性の向上のためのGrowth Technologyチーム所属のメンバーです。

このチームでは生産性向上のためにさまざまな施策を実施してくれているのですが、その一貫として生産性を可視化するためにfourkeys基盤を整理した取り組みを紹介します。

GitHubなどの各種プラットフォームからの情報の集め方、grafanaを利用したダッシュボードでの可視化など、さまざまな構成要素で実現しているのでそれらについて話を聞けると思います!

パネルディスカッション

serverside 2名 + SRE 1名 でざっくばらんにいろいろお話する予定です!
たとえば今回の発表で触れていない今までのチャレンジについてや、これからやろうと思ってるチャレンジなどについて話す想定です。

質問などがあれば回答するなど、ある程度インタラクティブなコンテンツにしたいと思っているので、当日の流れ次第で別の内容を話すかもしれません。

また、connpassのアンケート機能で参加者に事前に気になるトピックについてアンケートをとっているので、そこからの意見も参考にしてパネルディスカッションのお題を決めようと思ってます!

まとめ

2022/9/12(月) に開催する Kyash TechTalk #4 - Serversideと新しい挑戦 - connpass についての告知でした!

Kyashは 前回のイベント でご紹介したとおり、現実に向き合い、泥臭いことにも真摯に取り組んでシステムを作り上げています。
いっぽうで将来のためにより良いシステムを作るための努力もしています。

このふたつの要素のバランスは難しいですが、どっちも大切だからどっちも一生懸命やろうとしているのはKyashのすきなところの一つです。

なんですが、どっちも真剣に向き合おうとすると、より多くの人の助けが必要なことがわかっています。

まずは自分たちの現状や課題感、そのなかでやっているチャレンジなどを発信してこそ、そのような協力が得られるのだと思っています。
そのための一環として、今回のイベントでは前向きな取り組みにフォーカスをあてて、事例やこれからやろうとしてることをたくさん紹介します!

そしてイベントを通じて「いっちょ手伝ってやろうかな」ともしも思っていただけたら、気軽にご連絡ください!(コンタクトとりやすいようにアンケートにもそういう項目を入れておきます)

最後にあらためて、2022年9月12日 (月) 13時にイベントを開催します。YouTube Liveなので流し見もできます!ぜひ気軽にご参加ください〜!

kyash.connpass.com

テストプロセスにテスト管理ツールを導入した話

はじめに

こんにちは、Kyashの品質管理を担当している Tokkiです。品質管理のテストプロセスの一部である、テスト活動においてテスト管理ツールを導入したお話をしたいと思います。
前半では、何の課題があって導入したのか、実際の導入の流れ、導入してどうだったかの話。 後半では、実際にツール上でこういうことをやったという、作業レベルの話に触れたいと思います。

続きを読む

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の科学GoogleDevOps 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開発をしていきたい方も募集しています。
ぜひご応募いただければと思います!

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