リリース1ヶ月で10件以上の不具合、募る不信　品質管理のスタートは俯瞰した視点と当たり前を守ること

自己紹介と会社説明

森脇和也氏（以下、森脇）：株式会社空の森脇です。「守りからはじめるカスタマーサクセス」というタイトルで発表します。

私は、もともと決済領域でエンジニアをしていました。そのあと2019年に空に入社しています。空はバックエンドがRails、フロントエンドがReactとTypeScriptで書いているので、両方使って開発をしています。

空でどういうことをやっているかを、簡単に説明します。昨今の世界情勢として、「密を避けましょう」ということが強くいわれているかなと思っています。

そこにおいて、価格をコントロールして需要の平滑化ができますが、その価格をうまくコントロールして、需要を平滑化していくか。売上を高めたり、必要な人に必要なものを届けたりするお手伝いを「MagicPrice」というサービスを作って、クライアントのみなさまに届けています。

これは複雑なブラックボックスになったロジックというより、ルールベースで、人にわかりやすく、どういった時にどういった価格になるかをしっかりとフィードバックするシステムになっています。

チームの構成としくじりが起きたときの状況

先にまとめを言いますが、これからお話しすることは「品質管理はちゃんとやりましょう」ということにつきます。

まずこの話を始めていく前に、私たちのチーム構成を簡単に説明します。データサイエンティストやエンジニア、プロダクトマネージャー、カスタマーサクセスマネージャー、そしてデザイナー。こういったメンバーで1つのプロダクトを作り、スプリントを回しています。

このチームで開発をしていったときの話になりますが、（スライドを示し）とあるプロダクトの開発をしたときのざっくりとしたタイムラインです。先にお客さんのところに行ってヒアリングをしたり、デザインを作るためにいろいろなデザインスプリントをやったり、UIのワイヤーフレームを変えたり。そのあと実際に開発に入っていくにあたって、いくつかしくじりポイントがありました。大きく分けて3つあったかなと思っています。

1つ目のしくじり：信頼駆動開発

最初のしくじりですが、そもそも今回の案件は半分受注したかたちになるので、受託の意味合いもありました。先にリリース日を握っていたことと、けっこう要件が多く出てきたので、「あふれるものはリリース後に対応しましょう」ということで逃げていました。

ただ、それでもかなりスケジュールがきつかったので、開発メンバーでレビューはもうやっている場合じゃないと。とりあえずインターフェイスだけはお互いに合わせて、おのおので実装しましょうという、相当ムチャなことをやって進めていました。

そして、ユニットテストも個人に依存していたので、書かれているシステムもあれば、まったくないものもありました。

ユニットテストがなければ手動テストをしますが、かといってテスト仕様書みたいなアウトプットもないので、どういった観点でテストをしたのかも、当然あとからは確認できないです。そのため、お互いにエンジニア同士で「よろしく、開発しましょう」という信頼駆動開発みたいに進めていたところが、1つ目のしくじりポイントになります。

2つ目のしくじり：事前テストの共有

続いて2つ目です。ここからテストに入っていきます。

「一通りできあがりましたね」「検証環境があるので、そちらにデプロイをして、実際に使っていきましょう」と。当然お客さんのシステムと接続するので、外部連携試験をやったあとは、モンキーテストでいろいろなバグを出していきましょう、みたいなことをやっていました。でも、「なんかテストの項目1個抜けていますね。これすっかり忘れていました」みたいなのがありました。

お客さんに実際に使ってもらうための受け入れ試験の環境も作って、「こういうシナリオでテストしてくださいね」と言ったのですが、そこも共有だけして、そのままになってしまいました。実際にこの環境を活用してお客さんがテストを事前にやってくれるように進められなかったのが、しくじりの2つ目になります。

ただ、この頃のチームの雰囲気としては、けっこうイケイケな状態でした。、リリースまであと少しというところで、検証環境やモンキーテストにおいて、多くの課題が見つかったし、デザイン上修正しないといけないところもありました。

リリース後、お客さんに対してオンボーディングするのですが、そこのプログラムを作らないといけないとか。あとは実際にMagicPriceを使ってもらって、どういう効果を実感してもらえるか。そういうレポートも考えましょうと。

「これはいいプロダクトになるぞ」と、みんなこういう前のめりな姿勢でいたんですね。ある意味けっこういい状態で、プロジェクトは進んでいました。

3つ目のしくじり：1ヶ月で10件以上の不具合

そして、しくじりの3つ目になります。いよいよリリースです。

リリースは無事できました。これから、リリース時に落とした機能も、「なるはや」で実装していきましょう。

あと、（当初は）同じお客さんの中でシステムを利用してもらっていたのですが、同じシステムを利用されている他社さんに対してもMagicPriceは使えるので、そういったところにも実際に導入してもらうという、けっこういいスタートダッシュが切れた状態でした。

なおかつ、売上とかプライシングに対する効果検証は、リリース時点ではこれからやっていく予定だったのです。価格の設定業務とか、そこに付随する業務とかもかなり効率化を図れました。

なので、いよいよプロジェクトチームみんな、さらなるプロダクトの進化を目指して、全員がイケイケの“攻め”の姿勢になっていました。

そんな中で、問い合わせが徐々に増えていくわけです。「社内で管理している数値や予約数が、MagicPriceで出ている数字と合っていないんですけど」とか、あとは冒頭で話したとおり、「ルールベースによる価格の決定というのをやっているのですが、どう見てもルールを満たしている気がするんだけれど、なんかルール発火していない気がします」とか。また、「データ更新されていないようですよ」とか。

というのが続き、1ヶ月で10件以上の不具合を出す結果になってしまいました。その結果、「MagicPriceは本当に大丈夫なのか」という不信を招く結果になってしまいました。

社内で緊急事態宣言を発令

これはさすがにまずいということで、社内で緊急事態宣言を発令しました。なぜこうなったかという振り返りと、あとはそもそもプロダクトの品質をしっかりと担保するガバナンスが効いていなかったので、体制を作りましょうと。

あとは、今まで不具合が発生したときに、「修正リリースすればいいじゃん」という文化で来ていたところもけっこうありました。なので、「そこはしっかりとやりましょう」というような、見直しを進めていきました。具体的にどういう対策をしていたかは、次のスライドになります。

当然、テストが甘いところがあったので、テストをもう1回やりましょう、と。仕様書がないものはしっかりと再作成して、単体レベルから総合テストのレベルまでもう1回全部やりましょう、と。ユニットテストがないところはもう当然書きましょう、となりました。

けっこう時間も限られているので、書かない場合はプルリクエストにテストケースとして、「どういう観点でやりました」とか「手動の結果を貼っていく」ことをやって進めていきました。あとは、開発メンバーでしっかりとレビューの時間を毎日押さえて、「こういう観点で書いています」という相互レビューする時間を取りました。

あとはインシデントの管理です。ここはチームの中でもしっかりと認識を取りました。（インシデントを）やっぱりなかったことにするのが、お客さんにとっても一番まずいので。けっこう障害が続くともう嫌になっちゃって揉み消したくなる気持ちも働くのですが、そこはやらずに真摯に向き合いましょう。これをやってしまうと、もう一気に信頼を損ねるので、それだけはやめましょう。

障害一覧をしっかりと管理をして、再発防止策をそれに対して練っていくのを、チーム全体で回していきました。同時に、プロダクト上でアラートは出しているのですが、「本当にエラーになったときにアラートが出てるの？」というところも精査しないといけなかった。そこをしっかりと精査して、修正することをやっていました。

まだあるのですが、リリースのフローの整備を一緒にしています。本番にデプロイするまでにどういう経路をたどって、どの環境で何の項目がOKだったら次のステップに入れるかをしっかりと定義をした上で、そのフローに沿ってリリースしましょう。

また障害が起きたときに、どういう対応のフローに沿ってやっていくかをしっかりと決めました。お客さんに対する伝達の方法や、「このパターンのときはこういうリカバリをします。これはどれぐらいかかります」とか。休日や祝日に起きた場合は対応するのか、翌営業日にやるのか。そういうところまでしっかりと決めた上で運用することをやっていました。

まずは当たり前をしっかり守る

最後、まとめになります。今まで話してきたことは、けっこう当たり前のことではありますが、そこが多く漏れている部分があったので、当たり前に守るべきところはしっかりと守りましょう。

今回はけっこう手ごたえがあったぞとか、これはけっこういいプロダクトになるぞ、みたいなそういう部分でチーム全員が前のめりになってしまった結果、“守る”意識がわりと低くなってしまったところもあります。

あと、プロジェクトマネージャー的な人もいなかったので、俯瞰して見る人が必要でしたねという部分もあります。ここは引き続き、今も空ではエンジニアの人数が足りていませんので、ぜひ助けてくださいと言いたいところです。

テスト前には最初に計画をしっかりと決めておきましょうねということを、まとめにしたいと思います。

最後に、これを通してやった結果、10件あったインシデントが翌月4件ほどになり、今は1件ほどと、障害の数をかなり減らせている状況です。といったところで、発表を終了したいと思います。ありがとうございました。

質疑応答

田仲紘典氏（以下、田仲）：ありがとうございました。これは品質保証の話なのですが、ちょっと一筋縄ではいかないところもけっこうあると思います。質問がいくつか来ているので、1つずつ聞いていきますね。レビューや単体テストを省いてまで、厳密にリリース日を守らなければならなかった理由は何ですか？

森脇：そこは、プロジェクトが始まる前に、すでに「この日までにリリースをしましょう」というお互いの合意がありました。それをあとから変えていいかどうかが、私は途中から入ったのでよくわかりませんでした。「リリース日はこの日だ」という前提で進めてしまったのは、確かに反省すべき点ではあったかなと思っています。

「このままリリースしたら、まずいですよ」「もう少し時間が欲しいです」みたいなところは、内部でも話はしていました。だからその時に、リリース日をちょっと延ばしませんかという話をしていたら、状況は変わっていたかもしれません。

田仲：ユニットテストや、手動テストから切り替えられた部分はありましたか？　

森脇：そうですね。そこはもう少し時間をかけて、その品質の向上に時間をあてられたかなと思っています。ただ一方で、先ほども言ったとおり、その当時のチーム状況からして、次の開発をしてしまっていたリスクもあるなと思っていて。今となっては「たられば」の話になってしまいますけど。しっかりと品質に向き合える判断をできたかは、ちょっと自信はないです。

田仲：なるほど（笑）。質問がめっちゃ来ていますが、あと2点聞いて、発表を終わろうかと思います。

2つの質問のうち、1つ目が、「ビジネスサイドからもっと早くみたいな無理難題が来て、品質が犠牲になるケースがスタートアップだとあるとは思いますが、こういう時、どう対応するのがいいと思いますか」。森脇さんはどうですか？

森脇：そたぶんこれ、みんなが悩んでいるポイントだと思います。なんでしょう。守るべきラインをあらかじめ決めておくというところかなと思います。

当然、最初から完璧なものなんてできないので、そこはお客さんにもしっかりと説明をしてわかってもらいつつ、コミュニケーションツールとしてMagicPriceはまだ子どもなので、最初はエラーがあるかもしれませんが、徐々に大人になって、よくなっていきます。

メンバー間でコミュニケーションはしていますが、今回に関してはそもそものテストができていなかったとか、お客さまにそのリリースを報告したと言える状態には遠かった点がありました。今回の例で言うと、最低限、しっかりとデータが反映できるか、ルールが発火するかのテストは、やってからリリースすべきだったかなと思っています。なので、そこの線引きを最初から決めておくところかな、と思いますね。

田仲：クライアントとしっかり品質のことをビジネスサイドと交渉しながらやる、というところですよね。

森脇：そうですね。

田仲：品質は絶対担保する、という守りを絶対やっておく感じですね。あともう1点、みんな前のめりになっている状況でも、本番リリース直前になにかしらの予兆はあったんじゃないかなと思って。今振り返って、何かありましたか？

森脇：そうですね、予兆はありました。開発をしている中で、スケジュールもキツキツだったので、けっこう心配というか。そういったアラート、「けっこう時間ないですね、どうしましょう」という話はチーム内でしていました。スタートアップだからじゃないですが、そこはなんか気合で乗り越えようという判断でした。

田仲：気合で（笑）。

森脇：だからそこは気合と根性で乗り越えたんですね。そこの部分で、もしかしたら、「このままだとマズいね」という判断をする人がいれば、当然「ちょっとスケジュールを見直しましょう」という話にはなったと思います。

田仲：はい。気合と根性は、バズワードみたいになっていますね（笑）。という感じで、いったん質問は切り上げようかなと思います。