Kyashミーティングガイドラインを公開しました

Kyashの @konifar です。
この記事は Kyash Advent Calendar 2022 7日目の記事です。

社でミーティングのガイドラインを作って半年くらい経ったので経緯や運用の話を書きます。
内容はGitHub リポジトリで公開しています。

github.com

2022-09-09

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

2022-08-31

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

Kyash Meetup

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

2022-07-25

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

はじめに

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

2022-06-15

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

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