ランサーズ(Lancers)エンジニアブログ > イベント/登壇 > 開発ランチ(lunchers) > ランサーズ開発ランチ(Lunchers #7) ~Kyash社でのプロダクト開発プロセス~

ランサーズ開発ランチ(Lunchers #7) ~Kyash社でのプロダクト開発プロセス~

yoshimoto|2018年08月21日
イベント/登壇

はじめに

はじめまして、開発部の吉本です。

今回の開発ランチ(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について意見を交換するなど、お互いに学び合う良い機会となりました。