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

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

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になりすぎているマイクロサービスやデータベースがあるのも事実で、この点は後述する通り改善が必要だと考えています。 また、モバイルチームではビジネスロジックiOSAndroidのプラットフォームに依存しないようKotlin Multiplatform Mobile(KMM)を採用する決定をチームで行いました。組織もiOSAndroidというプラットフォーム毎のチーム構成を廃止し、mobileチームとして統合することでこの推進を後押ししています。

これからのKyashの展望

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

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

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

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

最後に

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

meety.net

meety.net

open.talentio.com