Kyashのプロダクト開発

この記事は Kyash Advent Calendar 2019 4日目の記事です。

今回は、面接などでも良く聞かれるKyashのプロダクト開発、
特にウォレットアプリ(※1)のプロダクト開発について、エンジニア目線で書いてみたいと思います。

簡単に自己紹介

2019年2月にKyashへ入社。サーバサイドエンジニアとして日々開発をしています。
現在はウォレットアプリのサーバサイドTech Leadなる役割もやりつつ、
CSM（認定スクラムマスター）として Scrum の推進などもやらせて頂いております。
詳細な紹介は こちら とか こちら に記載しておりますので、ご興味ある方はご覧いただければ幸いです。

体制

現状のプロダクト開発体制としては下記のような形になっています。

エンジニアの内訳はこちら。

Kyashではいくつかの案件ごとにプロジェクトが発足することが多く、そこに対してリソースを充てていきます。（下記はイメージ）

あとはプロジェクトごとにプロダクト開発を進めていきます。

日々のプロダクト開発

Kyashでは Scrum というフレームワークを用いていて、1週間1Sprintで下記のようなスケジュールで進めてます。

■月曜: Sprint PlanningとProduct Backlog Refinement
PO/PM から今回の Sprint のフォーカスポイントを確認しつつ、各プロジェクトごとに Sprint Planning を実施します。
その際、同時に Product Backlog Refinement も実施するようにしていて、
新しい Product Backlog Item の追加、優先順位の入れ替え、詳細化（細分化）、ストーリーポイント付などを適宜やるようにしています。
ポイント付けに関しては、プランニングポーカーを使い、チームで認識を合わせながら Planning を実施しています。

その際に使うカードは、上記のものに留めておき、それ以上（＝上記の画像でいうと？の時）は Product Backlog Item を分解する作業をして、再度ポイント付けをしてます。
下記のように、出したポイントが異なれば、仕様などの認識違いな部分があるぞ！というサインなので、何をしなければいけないかをチームで認識合わせてして、それからポイント付けをするようにしています。

Product Backlog Refinement が終わったら、今回のSprintでやれる量を Sprint Backlog に積むのですが、その際に注意していることがあります。
Kyashアプリは既に世の中にリリースしているサービスなので、突発的に発生する作業が多々あります。その作業は急ぎであることが多いので、それをやる分の余白が必要です。
ただ、それがどの程度必要なのかがわかりませんでした。
そのため、1Sprintにどの程度発生するのかを、数 Sprint で計測し、それを元にどの程度のポイント分の余白をあけておくと良いかを決めています（ここは今だに計測してチューニングしています）。

■毎朝: Daily Scrum（スタンドアップ・ミーティング）
Kyash内ではスタンドアップと呼ぶことが多いですが、Daily Scrumも実施してます。
弊社では Jira を使っているので、下記のように Jira の画面をみながら確認していきます。

■金曜日: Sprint Review&Retrospective
金曜の夕方に、Sprint Review と Retrospective を実施。
Sprint Review では出来上がった機能のデモを見せたり、翌週実施されるプロモーションの内容をシェアしたりなど。開発に限定せずに、どんなことでも共有できるようにしてます。（とはいえ、Sprint に対して共有するものが少ないのは、スクラムマスターである自分の力量不足だと反省中...）
Retrospective では KPT で振り返りを実施し、プロジェクトの改善に取り組み中です。

このようにして、日々のプロダクト開発に取り組んでます。

そして全てではないですが、ベロシティも計測するようにしてまして、最近の状況は下記のようになっています。
①最近のもので、徐々によくなってきたパターン

②すごく計画通りにいけてテンション上がった時のパターン

まだまだ Scrum をやっているぜ！と自信を持って言えるレベルではないですが、引き続きよりよくできるように取り組んでいるところです。

サーバサイドでの取り組み

プロダクト開発の中の取り組みで、「技術的負債の返済」というものにもちゃんと取り組み始めたので紹介させていただきます。

なぜこういう取り組みが始まったのか

Kyash はまだまだベンチャー企業なので、リソースを事業側の開発にあてることが多く、なかなか技術負債を解消できない懸念がありました。
その状況をみて CTO が、「日頃の開発ではできないことを開発側視点でやっていこう！」と言ってくれて、まずはクォーター中に1週間（10%くらい）のリソースをかけてやってみようとなりました。
余談ですが、その取り組みの名前は、

のような経緯で、PAN 祭りと呼ぶことになりました（笑）
（一説にはクレジットカード番号の Primary Account Number の頭文字をとったとかとってないとか）

何をやったのか

Kyashアプリのサーバサイドで取り組んだのは、下記になります。

・Go言語のバージョンアップ
・ログフォーマットの整形と修正
・監視強化（Datadogの導入）
・テストの強化

一見すると地味であり、本来なら日頃の開発でやりたいところですが、メインプロジェクトとの優先順位を考えるとなかなか手がつけられませんでした。
そのため、日々の運用として強い課題感としてあること、かつ10%という範囲でやれること、かつ自分たちがモチベーション高く保ってやれることを、自分たちで選択しました。

どのようにやったのか

PAN祭り Week を作り、1週間丸々それに取り組む週を用意。
会議なども全てでずに、この取り組みに没頭しました。
（とはいえ、ここも Planning と Daily Scrum、Retrospectiveなどは実施）

やってみてどうだったのか

PAN祭り後に、”Fun, Done, Learn”という手法で振り返りを実施してみた結果はこちら（字が汚くてごめんなさいmm）

技術的負債の解消という取り組みでしたが、自分たち発案でやることができた分、楽しく、かつ学びのあることができました。これは引き続きやっていきたい取り組みです。

おわりに

こんな形でプロダクト開発をおこなっている Kyash ですが、一緒にプロダクト開発をしてくれる仲間をまだまだ募集中です！

ご興味ある方はオフィスに遊びに来ていただくとかでも大丈夫なので、ご連絡お待ちしております！
明日は @Temma Fukaya による Kyash Directの品質保障について です！
最後まで読んでいただきまして、誠にありがとうございました。

※1 KyashにはtoC向けの ウォレットアプリ と、toB向けの Kyash Direct という2つのプロダクトがあります。