シェア
はてブ
ソフトウェア開発では、スピードと品質の両立が求められます。しかし、特にスタートアップでは限られたリソースの中で品質保証の仕組みを整えることが難しく、開発の後工程で問題が発覚するケースも少なくありません。
株式会社WiseVineは、予算編成・経営管理システム「WiseVine Build&Scrap」（以下、「Build&Scrap」）を開発するスタートアップです。同社のプロダクトには高い品質が求められ、開発初期からQAを迎え入れました。まだプロダクトが形になる前から品質保証に取り組み、どのように開発とQAを両立していったのでしょうか。
本記事では、“一人目QAエンジニア”として、WiseVineのQAチーム立ち上げに関わった松本卓也さんに、そのプロセスや工夫を伺いました。
プロダクト設計段階から“一人目QAエンジニア”としてジョイン
――まず、松本さんのキャリアについてお聞かせください。
2016年3月に大学院を卒業し、パナソニックヘルスケア株式会社（現PHC株式会社）で電子カルテシステムの開発に携わりました。その後、本田技術研究所でディスプレイオーディオシステムのベンダーコントロールを担当しました。
その後、ドイツの部品メーカーでレーダーセンサーの品質保証を担当し、テストマネージャーとしてシミュレーションテストのプロセス構築を進めました。さらに、ライフサイエンス業界では化学分析機器のQA業務を担当。さまざまな分野でのQAを経験するうちに、Web業界、特にスピード感のあるスタートアップに強く惹かれるようになりました。そんなときに「Build&Scrap」のQAチーム立ち上げのお話をいただき、2023年7月に入社しました（早期キャッチアップのために5月から業務委託として参画）。
――“地方自治体の予算編成”という公共性の高いドメインでシステムの難易度も高そうですが、その点についてどのように感じましたか？
確かに行政向けシステムには独特の専門用語が多く、会計知識も求められるため、最初は資料の内容を理解するのに苦労しました。さらに、運用やユースケースの複雑さもあり、システムの振る舞いが立場や時期によって変わるため、多くのケースを想定する必要がありました。
しかし、そのような難しさがあるからこそ、QAエンジニアとして取り組む価値のある仕事だと考えていました。
――WiseVine入社当初、QAエンジニアとしてどんな風に動いていたのでしょうか？
入社当初はCTOとフロントエンド、バックエンドのエンジニアが数名。プロダクトもコンセプトを基に案件を獲得しながら開発を進めている段階でした。まだ触れるプロトタイプがないなか、ドメイン知識のキャッチアップのために、「どこを品質保証すべきか」を意識しながら調達仕様書を徹底的に読み込んでいました。また、PMと連携してシステム運用に必要なデータ項目の洗い出しや項目定義書の作成も行っていましたね。
――開発が進み、プロトタイプに触れるようになってからの動きはいかがでしょうか。
テストの実施内容、期間、ボリュームの見積もりを記載したテスト計画書を作成しました。
開発の進行に合わせてテスト手法を調整していったのですが、当時のメインは探索的テストでした。あらかじめテストケースを用意して進めるのではなく、仕様を理解した担当者が知識や感性を活かし、実際に触れて挙動を確かめる手法です。
この手法を採用した理由は、メンテナンスコストです。採用準備を進めてはいたものの、当時のQAはまだ自分ひとりでした。しかしアジャイル開発では仕様変更や修正は頻繁に発生するので「テストケースは最終的には必要になるが、作成時期を後ろ倒しにすることで、開発前半のメンテナンスコストを抑える」という方針を取りました。
この時期はプロダクトのユースケースを網羅できるフェーズではなく、主要な機能が未完成の状態でポツポツと点在しているような状態でした。機能単位で動作を確かめながら「この機能はこの仕様で問題ないのか？」と自分で調べながら確認する必要があり、判断が難しい場面も多かったですね。最終的な成果物やプロダクトの目標をイメージしながらテストを進めていきました。
――プロダクトが一通り出来上がっていない段階から、QAが開発に関わる。このメリットは何だと思いますか？
仕様の抜け漏れやあいまいさを早期に発見できることが最大のメリットだと考えます。開発が進んでから仕様の曖昧さが発覚すると修正コストが高くなりますが、上流からQAが関わることで、要件定義や受け入れ基準をしっかり整えた状態で開発をスタートできます。
さらに、設計段階から非機能要件やテスト容易性も考慮されるため、バグが未然に防がれ、リリース後のトラブルが減少します。また、チーム全体で品質を意識し、開発プロセスの効率化につながる環境を構築できるのも大きな利点です。
リリース前: 少ない人数で、いかに品質保証しながらリリースに間に合わせるか
――その後のQAチームの体制や動き方は？
E2Eテストができる段階になって2人目のQAエンジニアの方も入ってきたところで、自動テストを導入しました。ログイン、予算の入力操作のような基本的なシナリオから自動化を進めていき、毎朝すべて定期実行していました。
ツールはいくつか検討したのですが、「これからどんな人がQAチームに入るか分からないので、全員にとって使いやすいメンテナンスツールを選びたい」などの理由から、コマンドが日本語で書けるMagicPodを採用しました。料金の手頃さや、実行回数が無制限で遠慮なく使えることなどもポイントでした。2人目のQAエンジニアの方が自動テストに精通していて、導入や方針を決める上で非常に助けられましたね。
リリースが迫っていたこのころの大きな課題は「開発チームの規模が拡大していくなか、どうやって限られたQAメンバーで品質保証しながらリリースを乗りきるか」。2人目のエンジニアの方に自動テストの作成を担当してもらうことで、QAの負担を軽減していきました。並行して、受け入れテストに向けてシナリオテストの準備を進めていきました。これは私の担当で、Notionに400件近く書きましたね。
――「開発を加速させる」「開発をリリースに間に合わせる」といった観点では、どのような取り組みをしていましたか？
まず大事なポイントは「不具合がクリティカルかどうかを判断すること」。そして、「発見した不具合のフィードバックを、可能な限り速やかに行うこと」を徹底しました。
リリースまでの時間が限られているなかで、見つかった不具合を修正すべきか / 許容すべきかどうか。この最終的な判断は、PMの方などが担当します。QAチーム側では「セキュリティに関するインシデントがある / システムを利用できない」「重要な機能が動作しない」など、不具合の深刻度をユーザーへの影響度にしたがって4段階に分類することで、PMに判断基準を提供するということをしていました。
リリース後: いかに安定運用を実現するか
――「Build&Scrap」は、松本さんが関わりはじめてから約1年後、2024年4月にリリースされました。リリース後の動き方はいかがでしょうか？
リリース直前に3人目のQAエンジニアが加わり、業務委託のテスターも増えました。人数が増えたことでQA業務の負担が分散され、より戦略的に品質保証に取り組めるようになりました。
新メンバーの教育にも力を入れ、業務委託のテスターにはテストケースの作成基準やバグ報告のフォーマットなどのルールを共有しました。また、開発チームにもQAの基本的な考え方を伝えることで、仕様の段階からテストしやすい設計を意識してもらうようにしました。
開発中は「リリースに間に合わせる」ことが最優先でしたが、リリース後は「安定して運用できるか」が焦点になります。新機能を追加するたびに既存機能に影響が出る可能性があるため、システム全体の整合性を確認することが重要です。回帰テスト（リグレッションテスト）のために、自動テストのカバー範囲を広げていきました。
カバー率は、各画面や操作をリスト化して、初期段階は入力操作から自動化を進めつつ、処理の共通化を進めることで自動化・メンテナンスの効率化を計る方針としました。そのうち自動化できた割合として計測していたのですが、リリースから約半年たった2024年11月ごろには90％以上に達しました。ほぼすべて画面で入力操作を自動テストで担保できるようになったのは、大きな成果だったと思います。
また、大きく体制が変わったところでは、リリースの2カ月後から開発チームが4つに分かれ、各スクラムチームにQAエンジニアが1人ずつ入ることになりました。
――スクラムチームにQAエンジニアが入ることで、どんな変化がありましたか？
開発の初期段階からテストの視点を取り入れられるようになり、設計段階で品質について議論できるようになったのは大きな変化でした。
私にとってスクラムに入るのは初めての体験で、毎日のように起こる仕様変更をキャッチアップしつづける難しさもありました。しかし、開発の動きがよく見えるようになったことで「次にこの開発が終わるから、このテストを準備しておこう」と事前に動けるようになったのは良かったと思います。
開発側にフィードバックを返すことがQAの第一使命。それによってどうしたら開発スピードを上げられるか、テストがボトルネックになることを避けられるか、ということを考えていましたね。
QAチームを立ち上げた経験を振り返って
――スタートアップでQAチームを立ち上げた経験を振り返ってみて「ここが面白かった」「ここが難しかった」という点はありますか？
面白かったのは、プロダクトがどんどん出来上がる過程を間近で見られたことです。QAの視点から「こうしたほうがいいのでは？」と提案できる機会が多く、単なるテスト作業にとどまらず、プロダクトそのものに影響を与えられるのは大きなやりがいでした。要件定義の段階から意見を出せる環境だったので、「品質」という視点でプロダクト開発に深く関わることができました。
QAチームを立ち上げたとき、一番大きな課題は「属人化」でした。
たとえば、初期の段階では「この仕様は〇〇さんしか知らない」という状況が多くて、誰かが休むと業務が止まってしまうことがよくありました。特にスタートアップでは、人数が少ないぶん、1人の知識やスキルに頼りがちなんですよね。
そこで、まずテストプロセスを標準化しました。最初はバラバラだったテストケースのフォーマットを統一して、誰が見ても分かる形にしたんです。例えば、新しい機能のテストをするとき、以前は「このケース、前回どうやってテストしたっけ？」と調べ直すことが多かったんですが、フォーマットを統一することで、すぐに過去の事例を参考にできるようになりました。
次に、ナレッジ共有の仕組みを整えました。たとえば、ドキュメントを整備して、テストの進め方を明文化したり、定期的に仕様変更のキャッチアップをする場を設けたりしました。特に仕様変更は、開発のスピードが速いスタートアップでは見落としがちなので、これを仕組み化することで、認識のズレを防ぐことができました。
さらに、特定の人だけに負担が集中しないよう、タスクの担当を分散させる仕組みも作りました。主担当・副担当のペアを決めて、誰かが休んでも業務が止まらないようにしたんです。実際、この体制を作ったことで、突発的な休みがあっても「どうしよう…」と焦ることがなくなりましたね。
こうした取り組みを続けることで、結果的に「このタスクは誰でも対応できる」という状態を作ることができました。
スタートアップではQAの業務範囲が広いので、「属人化を防ぐ仕組みづくり」はとても大事だと実感しました。
――例えば、松本さんの場合は「IT業界に限らず、多様な分野でQAの経験を積んでいる」ことが特徴になるのでしょうか。「Build&Scrap」の開発で経験が活きた場面はありましたか？
特に自動車業界でのQA経験は大きく役立ったと思います。
自動車は部品ごとに開発され、最終的には全体を組み上げてテストを行います。しかし、テスト車両を大量に用意することは難しいので、「いかにテストのバリエーションを減らすか」「限られたリソースとスケジュールの中で、どう効率的にテストするか」といったことを考えつづけていました。その思考回路は、Web開発の領域でも活きたと思います。
――QAチームの立ち上げや運営を経験された中で、学んだことや気づいたことはありますか？
コミュニケーションの重要性です。多くの問題はここに帰結すると思います。
特に「Build&Scrap」はドメインが難しく説明や情報共有が複雑になりがちで、「この機能は何のために存在するのか？」「誰が使うのか？」といった認識を合わせながら進めていくことの大切さを痛感しました。プロダクトとしての強みを高めることや、ユーザーに選んでもらうための品質の作り込みを目指すのであれば、やはり「なぜこのテストをするのか？」を理解することが不可欠になると思います。
――最後に、読者へのメッセージをお願いします。
「開発スピードと品質はトレードオン」だと考えています。QAエンジニアが開発初期から関与することで、仕様や設計の段階で問題点を指摘することで内部品質を向上でき、品質を担保しながら開発スピードを上げることは可能です。
品質は、期待と現実の差であり、技術的品質（コードの保守性、パフォーマンス、セキュリティなど）、プロセス品質、ビジネスの視点によって成り立ちます。
この記事を読んだ方には、開発や販売に関わるすべての人がユーザーの期待について共通認識を持ち、多くのステークホルダーに受け入れられるプロダクトを目指してほしいと考えています。その一環として、上流工程からQAエンジニアが関わり、品質を組織全体で支えるプロダクト開発を実現してほしいです。
