はじめに
はじめまして、開発部の吉本です。
今回の開発ランチ（Lunchers）では、Kyashでプロダクトオーナー兼プロダクトマネージャーをしている重松さんにゲストに来て頂いて、 Kyash社でのプロダクトの意思決定フローと開発プロセスについて2部構成でお話しして頂きました。
社内のPMから話しを聞いてみたいという要望から実現しました。ありがとうございます。
- プロダクトの意思決定フロー
- 直近の開発体制 / プロセス
Kyashについて
まず、ウォレットアプリの「Kyash」についてです。KyashはアプリからVisaカードを即座に発行して、買い物や送金が手軽にできるサービスです。今回の参加者のほとんどの方が、Kyashを知っていました。
Kyashは送金が手軽にでき、39円を投げ銭として送金すると特別なアニメーションがみれるそうです。
1部「プロダクトの意思決定フロー」
一部はプロダクトマネジメントについてのお話しです。
Kyashの文化
- Kyashでは「動いて風を知る」という文化があります。これは、まずやってみる、振り返りとしてKPTする、失敗してもすぐに振り返りTryして改善することを習慣にしていることを表しています。
OKRの導入
- Q1(1月-3月): OKRをプロジェクトごとに決める。->プロジェクトが多くなり、またそれぞれのOKRと会社全体のOKRとの連動性が見えづらくなる
- Q2(4月-6月): 開発チームとしてOKR持ち、また内容もシンプルに(〜までに〜の機能をリリース) -> PO1人に意思決定が集中しボトルネックとなる
- Q3(7月-9月): OKRの立て方はQ2を引継ぎ、意思決定者を分ける。POはフォーカスを決め、howはチームで決める。
Kyash社では、ランサーズでも導入しているOKRで目標の設定を行っていました。
OKR導入にあたり、失敗もあったそうですが、OKRについて四半期ごとに振り返り改善していました。OKR導入でもKyashの文化が表れていると感じました。
弊社でも、はじめOKRの失敗から試行錯誤を繰り返してきていたので、共感できるポイントもとても多くありました。
質問
- Q. OKRの決め方はどのように行っているか。トップダウンで決めるか、ボトムアップで決めるか。
- A. 今はトップダウンでやっている。Q1でボトムアップでOKRを決めてやってみた際にズレが生じ、何が重要なのか現場が混乱してしまった。OKRを始めても形骸化してしまうことが多く見られるので、トップダウンで決めた時はきちんと理由を説明する必要がある。
2部「直近の開発プロセス」
2部では直近の開発プロセスについて、以下のようなお話がありました。
- リーガル、CSと連携するため、チームに一人は含むようにしてスピードをあげる
- 失敗するととりあえずKPTする
- KPTのKPTを行う
- バグ1グランプリの取り組み
Kyashでは、デザインや色など使用感も含んで、エンジニアだけでなくチームの皆でバグを発見する、「バグ1グランプリ」を行っており、皆でレビューすることで、リリース後の後戻りが生じにくくなるなど良い取り組みだと感じました。
質問
- Q. なぜ皆でレビューするようになったのか、始めたタイミングは？
- A. リリース後に問題を発見するという事が何度か発生したため、マーケ、リーガルを含むチーム皆でレビューを行う事で解消につながった。
おわりに
今回、プロダクトの意思決定フローと直近の開発プロセスについてお話しして頂きました。講演の後も、ランサーズの開発体制との違いやOKRについて意見を交換するなど、お互いに学び合う良い機会となりました。