インサイドセールスの特化型のCRM開発を担当
井上翔太朗氏：「チームで品質を高めながらSaaS開発を続けるためにやったこと」というテーマで話します。まず自己紹介をします。私は新卒でSIer企業に入社し、少し特殊な経歴かもしれませんが、営業から納品までを経験しました。そのほかに案件の受託開発や、2社目ではtoC系のマッチングサービスでマッチングアプリの開発リーダーをやっていました。その後は、スマートキャンプ株式会社で新規メディア事業の立ち上げや、メイン事業である「BOXIL」の開発や保守運用をやりました。今は「BALES CLOUD」の開発リーダーをやっています。
社内のカフェスペースで喫茶店のようにコーヒーを淹れるという活動をしているので、周りからは「コーヒーを淹れる人」と認識されています。
弊社の紹介をしたいと思います。スマートキャンプでは「Small Company, Big Business.」をビジョンとして掲げ、「テクノロジーで社会の非効率をなくす」をミッションとしています。今私が担当しているBALES CLOUDというプロダクトでは、それにちなんで「効率的かつ効果的な営業組織を世の中に広める」をビジョンにしています。
当プロダクトでは、インサイドセールス特化型のCRMを扱っています。インサイドセールスは、今までの営業組織の推移から生まれたものです。これまでの営業組織は、架電、商談、受注、顧客サポートのすべてに、幅広い経験と知識が必要で属人的な業務になっていました。
それが、今ではマーケティングの部分が分離され、最終的には顧客サポートの部分がCSに移管されて、どんどん業務が専門的になり分割されていきました。私たちは、この中のインサイドセールスという部分を担っています。ただ、このインサイドセールスの認知度はまだ低く、立ち上げに苦しんでいる方々が多いので、いかにわかりやすいツールを紹介できるかに注力しています。
（スライドを指して）少し古いですが、実際にデモの画面をお見せすると、このように操作性が高いことを強みにしています。わりと自由度の高いUIで実装しています。
ただ、こういうプロダクトを私たちのチームで開発するにあたり、品質という壁ぶつかったので、その話をしようと思います。
複雑な機能を開発した結果、陥った負のスパイラル
（スライドを指して）1年前のBALES CLOUD開発チームの状態です。私がジョインしたのもその頃です。1年前からプロセスとしてスクラムで開発し、プロダクトバックログからスプリントバックログで運営するほか、スプリントレビューなどもやっていました。その中のスクラム開発は、新規事業ということもあってスピードを意識しつつテストコードも書いていましたが、途中から修正に時間がかかり、手戻りが発生しがちな状態が続いてしまったんです。手戻りが発生すると発生のタスクをやらなければならず、本来やるべき開発に集中できなくなりました。
なぜそのようなことが起こったか。ユーザビリティを意識すると機能が複雑になりがちですが、弊社もそれにならった結果、複雑な機能を作ってしまったんです。複雑な機能は修正が難しく、テストを網羅的に書くのも難しいので、品質を担保する工数がかかるうえに網羅するのが難しくなっていました。その結果、機能開発のスピードが遅くなり、受け入れテストの手戻りが多くてなかなかリリースできない。手戻り修正に時間を費やしたため、本来やるべき開発のアイテムが積み残された状態になってしまったんです。
なぜこの問題が起きたか。機能が複雑なところに集約されていて仕様や影響範囲がわかりにくい、そもそもテストを書くコストが高いという課題にぶち当たりました。これをチームで考えた時に「結局保守性が低いのではないか」という話になりました。保守性の要素は、テスト容易性、理解容易性、変更容易性の3つに分けられると思います。
保守性が低いことでなにが起こるか。テスト容易性が低いと、テストがしにくいので書くことができない。理解容易性が低いことで理解ができない、コード変更もテストもできない。変更容易性が低いと変更しにくいので、リファクタリングや改善が難しい。このように、どんどん複雑さが増すという負のスパイラルに陥っていました。
ここで考えたのが、保守性の要素はそれぞれすごく密接な関係にあるということです。密接な関係とは、理解できないと変更やテストが難しい。変更が容易でないということはテストが難しい、または理解が難しい。テストが容易でないということは変更が難しい、または理解が難しい可能性があり、その各要素が重要な役割を果たしていて、それぞれが達成されないとどんどん複雑化していくことがチームとしてわかってきました。その保守性をよく内部品質と呼びますが、それが低いとユーザーが起こすバグなどの外部品質にも影響することがあります。
それはなぜか。理解できないものは影響範囲もわからないので、バグが起こるかどうかもわからない。変更が容易でないと、修正による影響が大きい、または測れない状態。テストができないと、品質が担保できないので、外部品質にも影響していました。
品質に対するWhy・What・Howの認識をチームで合わせた
では、SaaSプロダクトの品質を高めるために、チームでどのような取り組みをしたか。 あらためて、SaaSについて紹介します。SaaSは「Software as a Service」の略で、利用料を支払うとインターネット経由でサービスが提供されることです。以前は買い切りでしたが、現在はビジネスモデルと、途中で必要なくなれば解約ができるモデルがあります。
そのSaaSに対してBALES CLOUDは、継続的にユーザーが払う利用料に見合う価値を提供し続けることが大事だと考えています。そのROI（費用対効果）が見合っていないと、解約や他のサービスに乗り換えられる可能性があります。
だからこそSaaS開発は、価値提供のスピードが求められる分野でそのスピードや品質を大事にしなければなりません。その中で、なぜ保守性が重要なのか。SaaS開発は継続的にサービスを提供するものなので、継続的に機能を追加・変更して価値を高めるというサイクルがあります。そのため、保守性が低いと中長期的に機能変更や追加の難易度が上がって、スピードも品質もどんどん下がっていくんです。
これでは、私たちがSaaSのインサイドセールス業界で勝ち抜いていくのはやや厳しい。だからこそ高品質かつ速いスピードで開発し続けるために保守性が重要だと考えました。チームでそれをどうしたか。まず、価値観の共通認識が取れている状態を作る。なぜ品質を上げるのかをしっかり話し合って、Why・What・Howの認識を合わせる取り組みをしました。
価値観の共通認識が取れている状態にするため、私たちがなぜこのように価値を届けるのか、なにを大切に開発するのかというレベルから認識を合わせていきました。たった3人のチームですが、私たちがどういう意味をもって開発するのかというビジョンを作っていきました。
その中で4つの基準ができました。この中でも私たちが大事にしたいなと思ったのは「高品質」です。ここに注力しようと思い、品質に向き合うことにしました。
なぜ品質を上げなければいけないのか。私たちは品質を上げたいというより、プロダクトグロースのために、価値ある機能のために、開発のために時間を使いたい。そのためには、保守性を上げて手戻り工数を減らし、機能開発や改善時間を増やすことが必要です。まずは私たちが改善しやすい状態を作るためのテストを作ろうと話しました。
どのようなテストをどのくらいの工数をかけてやるのか
品質を高めるためのテストに関する取り組みを紹介したいと思います。あらためて、なぜ品質を上げるためにテストを書くのか。それは、私たちが自信をもってコードを変更できる状態にしたいからです。変更しやすくしたうえでリファクタリングし、本当の保守性に近づいていくという活動です。このサイクルを続けることが重要で、保守性を保つためにやっていると認識しています。
実際、どのようにテストを作っていったか。（スライドを指して）アジャイルのテストの4象限というものがありますが、チームでこれを確認して、どういうテストをやっていくか。私たちがテストを自動化するのはこの緑の部分、現在は緊急度と重要度が高くないので問題を検知できるレベルにするのが黄色い部分、というように区分けをして取り組みました。
では、その中でどのテストにどの程度工数をかけるか。（スライドを指して）有名なテストのピラミッドがあります。Unit Tests、Integration Tests、E2E Testsのように、ピラミッドの上にいくにつれてコストが高くてテスト時間がかかるというものですが、これに合わせて保守に時間を取られすぎない分量でテストを作成するという取り組みをしました。
実際にやった取り組みとしては、「継続的単体テスト追加の仕組み化」とUIのテストとして「Visual Regression Testの追加」。ほかに「E2E自動化サービスmablの導入」です。
テストにおける取り組み1 「継続的単体テスト追加の仕組み化」
「継続的単体テスト追加の仕組み化」としては、まずリファインメント。スクラムで開発しているので、リファインメントの段階からテスト工数を含めて見積もりとプランニングです。プランニングの段階からテスト工数も含めて見積もりを追加して、どのようなテストが必要か認識を合わせたうえで、単体テストのテストカバレッジの推移を計測するような活動をしていました。
テストカバレッジの推移を計測したのは、私たちが保守運用していくうえで現状テストが漏れていないかをチェックするためです。テストカバレッジの推移を計測できるようにして、追加が漏れていないか検知するために、このように可視化しています。
テストにおける取り組み2 「Visual Regression Testの追加」
「Visual Regression Testの追加」については、そもそもUIテストはコストが高くて導入に時間かかります。コンポーネント単位だと導入コストが高いからでもありますが、その中でも簡単にデザイン崩れを検知して追加も簡単にしたいということで、ページ単位のVisual Regression Testを追加しました。その結果、ページごとにどのくらい崩れているかを検知できるようになりました。最近ではVueのアップデートに着手して、その際にデザインがチョイチョイ崩れましたが、（スライドを指して）このように検知できるようになっています。
テストにおける取り組み3 「E2E自動化サービスのmablの導入」
最後に「E2E自動化サービスのmablの導入」について。「mabl」の主な特徴として、コーティング不要でテスト作成が簡単かつクラウド/SaaS環境なので初期構築コストがないのが特徴です。また、よくあるE2Eテストの保守コストが高い問題であるちょっとしたUIのズレをAIが自動修復してくれるのでかなり運用コストが低いSaaSでした。
その導入の際、mablの用語理解の認識合わせと、クリティカルパスのテストの洗い出しと作成を実施しmablとBALES CLOUSの用語を整理して、会話にズレがないようにしました。E2Eは、mablを導入したことによって、エンジニアだけでテストを作るのではなく、PMやビジネス側もテストを作れる状態になりました。また、いかに会話にズレがない状態を作るかが重要だったので、用語を合わせていきました。
チームの取り組みが改善につながった
テストに関してもPMやビジネス側と話して作っていきましたが、どこがクリティカルなのか、どこが必要なテストなのかという認識をしっかり合わせて進めていて、今ではひと通りこれらのテストが網羅されています。詳細は、弊社のブログ記事『mablを導入した話』を是非見てください。
ほかにもいろいろな改善をしました。現在どのくらい利用されてるかデータを取っていますが、ほとんどの機能が利用されていて、営業のフィードバックにもリリースした機能がより使われていると思っています。1つだけリリースが難しい機能もありましたが、ほぼすべての機能が1週間くらいでリリースできました。半年間のバグ発生率を計測したところ3件くらいで、2営業日ほどで修正リリースが完了する軽微なものしか出ないものを作ることができました。
最後のまとめです。継続的に品質を維持する取り組みをしなければ、どんどん品質は落ちていきます。品質を上げることで、価値提供のスピードもどんどん上がっていきます。私たちはチーム全員がその共通認識で進むことが非常に大事だと考えています。ご清聴ありがとうございました。
