守りからはじめるカスタマーサクセス（空）：スタートアップ開発しくじり先生（8）

2021-08-23
Coral Capital

スタートアップの開発の失敗を赤裸々に語るライトニングトークに8社のCTOやエンジニア、プロダクトマネージャーが登壇。本記事では、株式会社空でソフトウェア・エンジニアを務める森脇和也氏による「守りからはじめるカスタマーサクセス」と題したトークの内容をお伝えします。

※本記事はCoral Capital出資先約80社からなるスタートアップコミュニティー「Coral Family」のうち、CTO・エンジニアが定期的に集まるCoral Developers。その中から生まれたイベント「スタートアップ開発しくじり先生LT」の発表を記事化したものです。

森脇です。もともとヤフーで決済領域のエンジニアをしていました。2019年に空に入社しました。RailsとReactの両方で開発しています。

空では、プライシング運用ツールMagicPriceを作っています。昨今、密を避けることが大事になってきていますが、価格をコントロールすることで需要を平準化させる効果が大きいと考えています。そこのお手伝いをします。説明可能なロジックによるプライシング、価格算出を行っています。ルールベースで人にわかりやすいシステムを提供します。

先に、今回のまとめです。品質管理はちゃんとやりましょう。

前提として、私たちのチーム構成です。データサイエンティスト、エンジニア、プロダクトマネージャー（PdM）、カスタマーサクセス（CS）、デザイナー、このチームでスプリントを回しています。

今回の「しくじり」の対象となったとあるプロダクトのざっくりしたタイムラインです。大きな「しくじり」が3つありました。

1番目のしくじりは開発です。今回のプロダクトは、半分は受託開発の意味合いがあり、リリース日を先に決定、合意する形で進めていました。要件が多く出てきたので、あふれたものは次のフェーズに回す形としていました。また開発メンバーでレビューをすっ飛ばしていました。開発者同士でインタフェースだけ合わせておのおの実装、ユニットテストも個人に依存しており、テストが書かれているサブシステムもあれば、ないものもありました。テストが書かれていないものは手動テストしますが、テスト仕様書はない状態です。いわば、エンジニアどうしでよろしく開発しましょうという信頼駆動開発でした。

2番目のしくじりはテストです。検証環境にデプロイし、外部連携テスト、モンキーテストでバグを出していきましょう、とやっていました。機能ごとのシナリオを作成し、顧客とも共有しました。しかし、それだけでは顧客がテストをやってくれるとは限りません。実際、顧客によるテストはほとんどできていませんでした。

この頃のチームの雰囲気はイケイケでした。「リリースまでもう少し！効果検証のやり方も検討。これはいいプロダクトになるぞ」という前のめりな感じで、ある意味いい感じにプロジェクトは進んでいました。

3番目のしくじりは、リリースと改善・機能追加です。無事にプロダクトをリリースしました。リリース時に落とした機能はなる早で実装していこうとしました。顧客と同じシステムを利用している系列会社への導入も進んでおり、結構いいスタートダッシュを切った状態でした。導入した効果も、価格設定業務が69%削減、付随業務75%削減と効率化できました。プロジェクトチームではさらなる進化を目指していて、全員がイケイケでした。

緊急事態宣言を発令して体制づくり

その結果、「社内の予約数と合っていません」「ルールを満たしていると思うのですが、発火していません」「データが更新されていないようです」といった問い合わせが相次ぎました。1か月で10件以上もの不具合が発生し、顧客からの不信を招く結果になってしまいました。

社内で緊急事態宣言を発令しました。振り返りをして、プロダクト品質のガバナンスが効くように体制作りをしました。ここで守りを固めないと信頼がゼロになりかねません。そこで機能開発をストップ。「不具合が発生しても修正リリースすればいい」という文化を見直しました。

対策です。まずテストを実施します。テスト仕様書がないものは作成します。単体テストから総合テストまで1週間かけて実施します。ユニットテストがない箇所は当然、書きます。テストを書かない場合は、PRにテストケースと結果を書きます。開発メンバーでレビューの時間を取るようにします。

インシデント管理を徹底するようにしました。障害が続くと「なかったことにする」誘惑が出てきますが、それはやめて真摯に向き合うようにしました。障害一覧を管理し、再発防止策を検討しました。すべてを防ぐことはできないので、なぜ起きたか、どうすれば次回防げるのかを記録するようにしました。社内で先に気づけるようアラートを出すべき箇所を精査・修正しました。

リリースフローの整備を行いました。本番環境にデプロイするまでのフローチャートを定義し、対象とする機能によっては受け入れテスト環境で顧客に確認してもらうケースを導入しました。

対応フローも整備しました。メール、Slack、電話と、影響度に応じた顧客への伝達方法を決めました。リカバリ方法やリカバリに要する時間、休日深夜の対応可否も定義しました。

教訓：品質管理を後回しにするのは危険

まとめです。今まで話してきたことは当たり前のことが多いのですが、当たり前の品質は守りましょう。「いいプロダクトになるぞ」という手応えの良さから機能開発に前のめりになってしまいましたが、守りは大切です。またチームには俯瞰して見ることができる人も必要でした。最終的に顧客をサクセスさせるのがプロダクトの役割です。

最後に、この活動を通して障害発生頻度は改善されました。当初の月10件超から、翌月には月4件、今ですと月1件ほどと障害の数を減らすことができました。