【連載】品質をめぐる冒険：MagicPod・伊藤望氏「品質の良さとビジネス成果が直結したものでありたい」

——伊藤さんがテストに関わるようになった経緯をお聞かせください。

元々はデベロッパーとして、株式会社ワークスアプリケーションズ（以下、ワークスアプリケーションズ）で製品開発に従事していました。1年ほど働くうちに製品・サービスの品質部分がボトルネックだと感じるようになりました。品質が悪いためにお客様のところでトラブルが発生し、その調査や修正に時間がかかる。そうすると次の開発のテストに十分な時間が取れず、また問題のある製品をリリースしてしまうという悪循環に陥っていました。

この悪循環を断ち切るには、テストの自動化が必要だと考え、テスト自動化ツールの開発に着手しました。その後3年ほど取り組む中で、QA（Quality Assurance）チームの方々と関わる機会が増え、彼らの考え方や実際の自動テストの作り方などについて深く理解できるようになりました。それまではQAエンジニアの人たちとあまり接点がなかったのですが、この経験を通じてテストの世界の奥深さを知ることになりました。

——先ほど品質面がボトルネックだったとおっしゃいましたが、特に品質の重要性を痛感した具体的なエピソードはありますか？

今までテストは面倒くさいなと思っていたのですが（笑）、一つトリガーになった出来事があって。それは、エンタープライズ向けのインストール型製品を開発していた際の経験です。その製品はバージョンアップを重ねながら、複数のバージョンを同時にサポートする必要がありました。重要な修正を行う場合、複数のバージョンに対して同じ修正を適用しなければならず、時には3バージョンに及ぶこともありました。

3バージョンに修正を入れる際、2つのバージョンはテストしたものの、最後の1つも同じだろうと考えてテストの一部を省略しました。するとそこでバグが発生してしまいました。実はソースコードに不要と思われるコメントアウトの部分があって、それを全て削除したところ、その中に必要なコードが1行紛れていたのです。

当然、上司には「全部テストしろよ。勝手にコメントを消すな」などと怒られました。でも、同じようなテストを3回も実行するのはばからしいし、雑なプログラミングのコードはきれいに整理したいわけです。この時の苦い経験から手作業によるテストの限界と、自動化の必要性を強く意識するようになりました。

——その後、テスト自動化ツールの会社を興すわけですが、起業は以前から考えていたのですか？　それともワークスアプリケーションズでの経験からビジネスチャンスを感じたのでしょうか？

学生時代から起業はしたいと思っていましたが、当時は具体的なアイデアはなく、まずは社会人としての経験を積もうと就職を選びました。4年ほど働いてそろそろ起業するべきだと考えたとき、自分が取り組んでいた自動テストの分野に大きな可能性を感じたのです。

当時、会社の開発部門の半分近くがQAエンジニアでして、テストに多くのコストと労力を使っていました。手動テストでは十分なカバレッジを確保できず、大きなフラストレーションになっていました。自動テストという新しいソリューションでこの課題を解決できると確信し、これをテーマに独立を決めました。

社内での自動テストプロジェクトが成功を収めたことも、起業を決意する大きな要因となりました。起業してから最初に作ったツールは必ずしもうまくいきませんでしたが、その後オープンソースの展開なども含めて、自動テストに関するビジネスを進めていきました。

——当時はテスト自動化ツールを開発している人は少なかったのでしょうか？

ワークスアプリケーションズでも「UWSC」という無料のツールや、「QTP」というライセンス料が100万円ほどするツールなど、いくつかの製品は試していましたが、うまくフィットせず、スクリプトを頑張って書いても、すぐに使えなくなってしまうような状況でした。そのため自分でWindowsアプリケーション向けのツールを作り始めることになったわけです。

独立する際には、海外や国内にもいくつか製品はありましたが、使いやすさや費用面で本格的な導入が難しかったり、無料でも機能が限定的だったり、プログラミングスキルが必要だったりと、時代のニーズに合った製品とは言えませんでした。その後、「Selenium」などのツールが登場し、使い勝手も向上してきましたが、起業当時はまだまだ発展途上の段階でしたね。

——MagicPodでは製品やサービスの品質を高める上で、どのような取り組みをされていますか？

スタートアップ企業としてさまざまなリソースの制約がある中で、何よりも優先すべきはスピード感です。全ての製品・サービスをバグなしに100パーセント完璧に仕上げることは困難ですし、それが求められる時代でもないと思います。ユーザーも現状99パーセントの品質レベルを100パーセントにするために倍のコストをかけることなど望んでいないでしょう。そのため優先順位を付けて、ユーザーにとって最もクリティカルな部分に注力しています。

特に重視しているのは、自動テストの実行部分とセキュリティーです。自動テストの実行はツールの信頼性に直結し、繰り返しエラーが出るとそのまま使われなくなってしまいます。そのため、さまざまなブラウザでの動作確認や、複雑なケースでのテストを入念に行っています。

セキュリティーに関しては、一つの不具合が企業ビジネスを破綻させるリスクになり得ます。スタートアップ企業ではセキュリティーを軽視しがちですが、それは経営上大きな問題と言えます。そのため当社ではフレームワークレベルで安全性を確保し、例えば、他社のデータが原理的に見えないような仕組みを構築したり、セキュアではないコードを書いたら静的解析でそのパターンははじかれるようにしたりしています。また、使用するライブラリの脆弱性があれば随時アップグレードするなどのセキュリティー監視システムは当たり前に導入しています。恐らく社内で私が最も口うるさいセキュリティーエンジニアだと思いますよ。

——伊藤さんのそうした品質に対する意識を組織全体に浸透させるために、どのような取り組みをされていますか？

会社設立当初から品質重視のカルチャーを築いてきました。新機能のリリース前には必ず自動テストを実施し、全てのテストがパスしないとリリースできないというルールを徹底しています。

ある意味、自動化して定量化できないと、それが守られているかどうかは測定できません。ですから測定可能というのは大前提ですね。

品質が浸透できていない組織というのは、結局のところトップがそこまでの意識を持っていないからだと思います。加えて、その品質に対する意識が定量化されていなければ、それを守るのは難しいと思います。

——一方で、現状の課題や改善点はありますか？

テスト自動化の会社として、問題が発生した際は極力自動化や仕組み化で対応すべきだと考えています。現在、クリティカルな部分は自動化でカバーしていますが、まだカバーできていない部分もあり、不具合が発生するケースも出てきています。

現在は2週間おきのリリースサイクルを採用しており、リリース前の3日間は機能開発を極力避けて、全員で触ってみたり、問題があったらレポートしたりする期間を設けています。そうすることで自動テストではカバーできていない部分を担保しています。しかし、リリース期間が1週間に1回、あるいは毎日となると、ユニットテストなどシステムテスト以外のテストレベルでカバーできる範囲を増やしていく必要があります。

また、QA担当者がいない中で、自動テストのケースが整理されずに雑然としている状況も課題です。数ある品質特性の中で何がカバーできているのか、できていないのかが明確ではありません。自動化を担当するQA人材を入れて、テスト項目の整理や体系化を進めていく必要があるとは感じています。

——伊藤さんにとって「品質」とは何でしょうか？

品質はビジネスにとって重要かどうかに尽きると思います。商品の品質が悪くてもビジネスがうまく回り成長している企業もありますし、営業力で売り切って長期契約を結べば、その後のサービス品質はさほど重要ではないと考えるビジネスモデルもあります。結局のところ、多くの場合、品質はビジネスに対して論じられるものですよね。

しかし、そうした中で、私たちは品質の良さがビジネスの成果と直結するビジネスモデルにしたいと考えています。当社のような１ヶ月単位で契約することができるサブスクリプション型ビジネスでは、ユーザーはいつでも解約できるため、常に品質レベルを保つ必要があります。また、エンジニアにとっては、品質の悪い製品・サービスを出した結果、それに対して顧客が怒っているという状況は、当然喜ばしくないわけです。私も社員がフラストレーションをためるようなビジネスモデルにはしたくないですし、それで儲かってもうれしくはありません。

——では、品質の良さを感じる製品やサービスとはどのようなものですか？

品質とは、バグの有無だけではなく、使い勝手やセキュリティー、使うことによる生産性の向上など、ユーザーにとって価値のあるもの全てを指します。その上で理想的なサービスとは、SlackやLINEのように、ユーザーがその存在を意識せずに使えるような「透明」なものだと考えています。逆に、使い方が分からない、動作が遅いといった形でサービスの存在を意識させてしまうものは、品質が十分だとは言えません。

ユーザーが目的とする業務に専念できる、そんな透明なサービスを提供することが、私たちの考える真の品質なのです。