こんにちは！関西支店勤務の大西です。
私の役割は、新規事業開発室におけるエンジニアの責任者 兼 Bill Oneの開発リーダーです。今回のブログでは、Bill Oneの開発リーダーの立場から、オンボーディングを成功させるために取り組んでいることを記載させてもらいます。
Bill Oneとは
Bill Oneとは今年の5/11（月）に公開した新規事業で、ミッションは「あらゆる請求書をオンラインで受け取る」です。
サービスについては、以下を参照してください。
bill-one.com
Bill Oneの現在のフェーズは、ミッションに価値を感じ契約してくれた顧客に対して、オンボーディングを成功させるフェーズです。オンボーディングの成功定義はこのブログでは詳細には紹介出来ませんが、Bill Oneを業務利用してもらい、価値を体感してもらうことです。
Bill Oneの体制
Bill Oneは社長直轄のプロジェクトとなっており、合計8名（そのうちエンジニアは4名）で構成されています。社長の下で大きく顧客開発チームとプロダクト開発チームの2チームに分かれています。
- 顧客開発チームは主に営業や契約後のオンボーディングが中心です。
- プロダクト開発チームは主にプロダクトの機能強化が中心です。
チームとして2つに分かれていますが、Bill Oneのミッションを達成するという共通のゴールを全員が持ち、ゴールに向けて全員でプロダクトとして具現化するという仕組みやマインドでやっています。
チームの切り口ではなく、役割の切り口だと以下に分割されます。
- プロジェクトリーダー（主に顧客開発チームに所属）
- 営業（顧客開発チームに所属）
- カスタマーサクセス（顧客開発チームに所属）
- 開発（主にプロダクト開発チームに所属）
こちらもチームと同様に、役割で完全分担されているというより、お互いの役割を重複しながら日々の業務をこなしています。
上記のチームや役割に対して、私はプロダクト開発チーム側のリーダー（開発リーダー）として以下2点の役割を担っています。
- 開発チームマネジメント（体制構築、メンバーの成長支援、開発スケジュールへの責任・コミット）
- プロダクトマネジメント(プロダクトミッションに向けての戦略や仕様決め、プロダクト全体俯瞰しての意思決定)
ただ、プロダクトマネジメントは、プロジェクトリーダーと共に役割を担っています。
主要なイベント達
2020年7月時点で私が関わっている主要なイベントは以下の通りです。
各イベントの詳細
| イベント名 | 目的 | 参加者 | 時間 |
|---|---|---|---|
| 朝会・昼会・夕会 | 進捗に対する課題共有・解決と雑談 | プロダクト開発チーム | それぞれ最大15分 |
| プランニング第1部 | 優先順位に沿って開発するストーリーとストーリーの開発担当者決め | プロダクト開発チーム+一部の顧客開発チーム | 30分 |
| プランニング第2部 | 今週開発するストーリーに対するタスク・設計のレビュー・相談。開発着手前に手戻りを最小化 | プロダクト開発チーム | 最大90分 |
| オンボーディング定例 | 契約企業がBill Oneを利用する上での課題に対する解決策やオンボーディング戦略を検討 | 顧客開発チーム+一部のプロダクト開発チーム | 30分 |
| 数値集め | 打ち合わせ形式ではなく、プロダクトとして分析したい観点での数値を週次で計測 | - | - |
| Bill One定例 | プロジェクト全体を俯瞰しての情報共有や意思決定 | Bill Oneに関わる全メンバー | 60分 |
| プロダクトデモ | 完成したストーリーに対してのリリース判断（開発中のストーリーもデモするケースあり） | プロダクト開発チーム | 最大30分 |
| バックログリファインメント | 次イテレーションで開発着手するストーリーの優先順位決めまたはストーリーの詳細仕様決め | プロダクト開発チーム+顧客開発チーム | 最大60分 |
| 振り返り | 小さな改善を繰り返し、良いプロダクト・開発プロセス・チームを作る | プロダクト開発チーム | 最大30分 |
| ラーニングセッション | 小さなことから大きなことまで、今週学んだ主に技術的なことを共有する場で、学習する文化の促進 | プロダクト開発チーム | 最大30分 |
月曜始まり、金曜終わりの1週間ごとのイテレーションを回しています。イテレーションを導入している意図は以下の通りです。
- 週単位で定期的なリズムを作って開発したい。
- 不確実性を考慮して、週単位でやることを決めたい。
後者に関して補足しますと、開発のストーリーに対する仕様と優先順位は直近約2週間分だけ決めている状況です。ビジネス（主にオンボーディング）の状況が変わるので、それ以上先に開発するストーリーの仕様と優先順位は決めないようにしています。ジャストインタイムの考えで、イテレーションを回しながら最適なストーリーを選択できる仕組みを採用しています。
開発の流れ
ストーリー単位での開発の流れは以下の通りです。
- エピックレベルの荒い粒度でやりたいことを決める by プロジェクトリーダー（または開発リーダー）
- エピックレベルからストーリーに分割する by 開発リーダー
- ストーリーの詳細仕様を言語化する及びプロトタイプを作る by 開発リーダー（または開発エンジニア）
- ストーリーの詳細仕様及びプロトタイプのレビュー by プロダクト開発チーム+顧客開発チーム
- ストーリーの開発 by 開発エンジニア
- ストーリーのタスク単位でプルリクレビュー by プロダクト開発チーム
- ストーリーのデモ by プロダクト開発チーム
- ストーリーをリリース by 開発エンジニア
特徴的な点としては、3番のストーリーの詳細仕様を言語化する際は合わせてプロトタイプを作る部分で、プロトタイプを作ることの価値は2点あります。
1点目は、プロトタイプでレビューすることにより、機能を利用するユーザー（ペルソナ）の立場に立ってUX含めた詳細仕様を検討しやすくなり、本当にユーザーにとって価値のあるサービス（機能）を提供できることです。そのため、4番のレビュー時の会話は、「社内の誰々さんがやるならどう反応する？」や「こういうメールが突然来たらどう感じる？」や「社内のユーザにヒアリングしてみよう」などかなり具体的な利用シーンを想像しながら、最終的な仕様を確定させています。
2点目は、新たに提供しようとしている機能に対して、顧客からフィードバックがもらえることです。顧客開発チームのメンバーが営業時やオンボーディング時に顧客に見せることが可能なため、実際にプロトタイプでデモをやっています。ただ、「うまくフィードバックをもらってます」と胸を張って言える状態ではないので、今後の伸び代として改善していきたいです。
オンボーディングとエンジニアの関わり方
まず、カスタマーサクセスの役割を担っている人が責任を持ち、オンボーディングをリードしています。
顧客ごとのオンボーディング状況と個別具体の課題はオープンになっているため、エンジニアならいつでも情報が確認できます。ちなみに、オンボーディング状況は信号で表現しており、順調なら青、ピンチなら赤、どっちでもないなら黄色となっています。プロダクトとして解決する課題は、上記で説明した「開発の流れ」に沿って進めていきます。
オンボーディング自体はまだまだ手探り状態で進めているため、エンジニアの関わり方も手探り状態です。そのため、現時点ではプロダクト開発チームのリーダーだけが、オンボーディングに深く関わっています。具体的には、顧客とのオンボーディングミーティングと上記イベントで説明した「オンボーディング定例」に私も参加しています。
エンジニアの私が顧客とのオンボーディングミーティングに参加している目的は、以下の通りです。
- 顧客からの良いフィードバックも悪いフィードバックも直接聞き、プロダクト開発に活かす。
- まだまだ機能不足が否めないサービスで顧客をリードしているカスタマーサクセスの立場・気持ちを理解して、カスタマーサクセスのメンバーとコミュニケーションを円滑にする。
手探り状態に目処が立てば、私以外のエンジニアも何らかの形でオンボーディングに関われる仕組みは考えたいです。
まとめ
いかがだったでしょうか？このブログでは、オンボーディングを成功させるために取り組んでいることを中心に現在の活動を紹介してきました。このブログを通して、誰かの気づきになってくれたら幸いです。
最後になりますが、ビジネスを成功させるために、既存の何か（体制や仕組みや文化）に縛られず、今とこれからにとってベストな解を模索し続けることが大事だと思っています。半年後、1年後にここで記載した内容から進化した内容をお伝えできるように頑張ります。
Bill Oneというサービスの進化にご期待ください！！！
