Labels:  イベント／登壇, 開発ランチ（lunchers） 投稿者：yoshimoto

ランサーズ開発ランチ（Lunchers ＃7） ～Kyash社でのプロダクト開発プロセス～

2018.08.21

• いいね！ 25
• ツイート 30
• B! はてブ 1

はじめに

• プロダクトの意思決定フロー
• 直近の開発体制 / プロセス

Kyashについて

• 参考：DroidKaigi登壇におけるKyashを使った投げ銭の経緯と結果

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失敗あるある

質問

• Q. OKRの決め方はどのように行っているか。トップダウンで決めるか、ボトムアップで決めるか。
• A. 今はトップダウンでやっている。Q1でボトムアップでOKRを決めてやってみた際にズレが生じ、何が重要なのか現場が混乱してしまった。OKRを始めても形骸化してしまうことが多く見られるので、トップダウンで決めた時はきちんと理由を説明する必要がある。

2部「直近の開発プロセス」

• リーガル、CSと連携するため、チームに一人は含むようにしてスピードをあげる
• 失敗するととりあえずKPTする
• KPTのKPTを行う
• バグ1グランプリの取り組み

質問

• Q. なぜ皆でレビューするようになったのか、始めたタイミングは？
• A. リリース後に問題を発見するという事が何度か発生したため、マーケ、リーガルを含むチーム皆でレビューを行う事で解消につながった。

おわりに