こんにちは！CTOの田野です！
7月のプロダクトチームでの取り組み、振り返りをご紹介していこうと思います。
プロダクト開発チームの文化策定
プロダクト開発チームのカルチャーとして以下３つを策定しました
作るものの本質的価値を考えよう
- 言われたからやるはNG
- コード書くのが仕事ではなく、コードによる価値を届けるのが仕事
- どのような本質的価値を生むのか意識せずに質の高いコードは書けない
- 採用OK) チケットに仕様は書かれていたが、疑問に思った点はPOやステークホルダーに自分から確認し、必要に応じて仕様検討した
- 採用NG) 違和感を感じたが、チケットに書かれていた通りに実装した
コミュニケーションの期待値を合わせ、心地良く働こう
- 相談したい人が気軽に相談できる、雑談できるだけでは足りない。する側/される側どちらも快適な状況を作っていきたい
- お互いのコミュニケーションスタイル（どのタイミングで何を相談するか）の認識が合っているというのが重要
- 採用OK) どのようなコミュニケーションだと相手もやりやすいのか意識し、会話する
- 採用NG) 自分が話したい、聞きたいことだけを考えて会話する
チームの成果にどう貢献できるかを考えよう
- チームの成果 > 個人の成果
- 何をやるとチームの成果に最も貢献できるかは人次第（要件、仕様に詳しいので調整、コードを書く、PRレビューする）
- enpayプロダクト開発における自走とは、チームの状況を見て、自分が何をやるべきか判断し、行動できること
- 採用OK) チーム状況を見た時に一時的にPRレビューやペアプロに専念して知見を共有した方がチームのパフォーマンス上がりそうだったので、自分のコード書く割合を減らしてそちらに注力した
- 採用NG) とにかくアサインされたタスクだけを見て、それを早く進めることに集中した
策定の背景について、これまではリファラル採用が中心で、以前に働いたことがあってスタンス、パフォーマンス共に強く一緒に働きたいと思える人を一本釣りで採用してきていました。
ただチームの拡大、チーム開発を推進していくにあたって、誘った人と働くのと、チームで働くのの乖離幅が大きくなっていくとも感じており、このやり方では長くは続かないだろうな、、、と思っていました。
そこで、プロダクト開発チームとして大事にしていきたい、何を是とするかを明文化したカルチャーをチームで議論して策定しました。これは今後採用フロー、基準にも使っていく予定です。
浸透、定着のために、それぞれにslackスタンプも用意しており、reacjiを使うことでカルチャーを体現した振る舞いがslackチャンネルに流れるようにしています。 😄
PMFの領域を広げていくための取り組み
プロダクト作りは特定の領域ではPMFしていると思っても、
少し広げたり、隣の領域に行くと全然PMFしていなかった、、、と気づいて作るの繰り返し という文章をどこかで読みましたが、本当にその通りだと感じており、マーケットの整理、顧客へのヒアリングを経て、プロダクトの足りない点に気づく１ヶ月でした。
エンペイでは直近、これから急成長に備えた、組織、フロー作り、負債の返却に集中的に取り組んでいます。
いよいよそちらもゴールが見えてきており、次にどこを目指していくのか、どの顧客のBurning needsを解決しに行くのかを、事業戦略と整合性を取る形でプロダクトのロードマップに反映させていく予定です。
フロー効率性とリソース効率性について
エンペイではこれまで助言プロセスを取り入れた上でのリソース効率性を重視した開発を行っていました。
具体的なイメージでいうと、ある程度の規模の案件（目安:１〜２人月程度）ごとに担当者をアサインして、設計〜リリースまで担当者が原則として行う。ただ設計、実装内容についてはリファインメントすることでチームで共有し、開始時からレビューを密に行う。ただ最終的な意思決定権は担当者にある。というものです。
ただ進捗が５０％あたりを超えた案件が複数走ることでチームの意識が分散しており、目に見えるリリースが落ちてきて勢いがなくなってきているな、、、と感じていました。
そこでゴールが見えてきたタイミングで、ある程度のオーバーヘッドを覚悟で複数人で１つの案件に集中するフロー効率を重視したスプリントを試しに行ってみました。
リソース効率、フロー効率を特定のタイミングでスプリントごとで切り替えるというのはあまりやったことがなかったのですが、結果は上々だったなと思っており、今後も使っていきたいと思います。
- タスクが細分化されていて、どれが完了すればリリースラインを満たせるのかが整理されていた
- チームで案件のコンテキストを初期から共有していた
ということが成功の要因としては大きかったと思います。