リスク管理SaaSを支えるQAエンジニアの挑戦 | Resilire Tech Blog
はじめに
サプライチェーンリスク管理クラウドサービスResilire の@bbbar326です。
アーリーステージのスタートアップでは、スピード重視の開発が求められます。しかし、私たちResilireは「品質」もまた重要な価値だと考えています。今回は、品質管理に取り組む私たちの姿勢と、その中でQAエンジニアが果たす役割についてお話しさせていただきます。
Resilireとは
Resilireは、サプライチェーンに関わる企業のリスク管理と事業継続計画（BCP）を支援するSaaSプラットフォームです。自然災害、サイバー攻撃、パンデミックなど、様々なリスクに対する事前準備から有事対応までをサポートしています。
サプライチェーンをツリー構造で可視化したり、地図上に拠点位置をマッピングしたりする機能を備え、お客様の「もしも」に備える力を高めることができます。
なぜResilireでQAエンジニアが重要なのか
一般的なSaaSは、導入によって業務効率や売上の向上に直結することが多いのですが、Resilireはちょっと違います。私たちは、お客様の事業継続という「当たり前」を守るためのプロダクトを作っています。
そのため：
- 災害時や緊急事態でこそ利用されるプロダクトのため、そのような状況下での機能の品質を確実に担保する必要があります
- 災害対応時にのみ利用する機能もあり、通常時にはフィードバックできない使いづらさなどが起きる可能性があります。また、緊急時は対応に追われているため、適切なフィードバックをもらえない可能性があります
- サプライチェーンに影響を及ぼすリスクは自然災害から人為的リスクまで幅広く、お客様ごとに異なる判断基準や優先順位があるため、様々なユースケースを徹底的に考え抜く必要があります
- お客様の業務に寄り添った、確実な品質が求められます
つまり、品質の担保は私たちの価値そのものなのです。
品質改善への取り組み：BTSの導入と試行錯誤
実際の取り組みとして、BTS（Bug Tracking System）の導入についてお話しします。
課題感
当時、リリース後もお客様に安心してご利用いただけるよう、より確実な品質担保の仕組みが必要だと考えていました。そこで、開発プロセスの中で品質を担保する仕組みとして、BTSの導入を決めました。
具体的な取り組み
BTSの導入は、当初想定していたよりも複雑な取り組みでした。
1. プロジェクト構成の整理
まず、社内の運用プロジェクトを以下のように整理しました：
- 不具合運用ボード：不具合の一元管理
- Voice Of Customerプロジェクト：顧客からの要望管理
- Nice To Haveプロジェクト：UX改善の提案管理
- リリース用プロジェクト：リリース日ごとのタスク管理
この整理には、既存の運用フローの言語化と一部運用変更が必要でした。というのも、それまでは複数のプロジェクトが存在しており、タスクをどのプロジェクトに起票し、その後どのように対応を進めていくべきかが不明確でした。これらを一元管理する運用に変更するには、各プロジェクトの特性を考慮しながら整理する必要があり、関係者間での認識合わせと調整に多くの労力を費やしました。
2. 起票フォームの設計
次に、ビジネスサイドとプロダクトサイドそれぞれの視点に合わせた起票フォームを作成しました。
入力項目の定義
-
必須項目（起票時）
- 概要：報告内容の端的な説明
- 報告者：不具合発見者
- 発生日時：事象の発生タイミング
- 詳細報告：再現手順や期待結果
- 不具合レベル：重要度の判定
-
オプション項目（後続フェーズ）
- 影響機能：機能単位での影響範囲
- 原因種別：設計ミスや環境依存など
- 品質特性：機能適合性や性能効率性など
分類支援の仕組み
不具合の分類を支援するため、以下の判断基準を設けました：
- リリース前後の判別
- 不具合かフィードバックかの区分
- インシデントの有無
各項目について、判断基準、責務、タイミングを明確にする必要がありました。
3. 運用フローの確立
フォームの設計と並行して、以下のような運用面の整備も行いました：
- 入力担当者の役割と責任の明確化
- 確認フローの確立
- 入力補助機能の開発
- 他システム（GitHub、Asana、GAS）との連携設計
4. 分析基盤の構築
最後に、収集したデータを活用するための分析基盤を整えました：
- 不具合の傾向分析
- 重要度別の集計
- 検出フェーズの分布
- 原因分類の統計
ダッシュボードの構築には：
- データの正規化
- 集計ロジックの実装
- 自動更新の仕組み作り
といった技術的な課題も伴いました。
現実は甘くなかった
このように体系的な仕組みを整えたものの、実際の運用では様々な課題に直面しました：
良かった点：
- 再現手順や期待値が明確になり、コミュニケーションが円滑になりました
- プロジェクトの整理ができ、起票する時にどのプロジェクトに起票するか迷うことが減りました
- 不具合の傾向を可視化する基盤を整えることができました
一方で：
- 起票の手間が増え、むしろ報告がしづらくなってしまいました
- 必須項目が多く、入力に時間がかかる
- 分類の判断に迷うケースが多発
- データは集まったものの、分析する時間も人員も足りませんでした
- 定期的な振り返りの実施が困難
- 傾向分析のための人的リソースが不足
- 分析結果を活かすための対応リソースも限られていました
- 改善提案を実装に移すための余力がない
- 優先度の高い開発タスクとの兼ね合い
正直に言うと、私たちのフェーズにしては少し大掛かりすぎた取り組みだったかもしれません。アーリーステージのスタートアップとして、もう少しリーンなアプローチが適していたと考えています。
現在の取り組みと今後の展望
この経験を活かし、今は以下のような方針で進めています：
-
まずは肌感でも良いので振り返りを実施
- 開発振り返りで不具合の傾向を議論
- 重要な不具合やインシデントについては原因分析と再発防止策を検討
- チーム全体での知見の共有を重視
-
主要導線の定義と、可能な範囲での自動化
- 重要な業務フローを優先的に文書化
- E2Eテストの自動化を段階的に実施
- リグレッションテストの効率化
-
PRDやユースケースやDesign Docなど、基本的なドキュメントの整備
- 要件定義の品質向上
- レビュープロセスの確立
- ナレッジの蓄積と共有
そして、テスト戦略についても見直しを進めています。
プロダクトフェーズに応じた品質担保
私たちは、プロダクトのフェーズによって品質に対するアプローチを変える必要があると考えています。PoCフェーズでは新機能の検証を優先し、グロースフェーズでは既存機能の安定性を重視するなど、状況に応じた柔軟な対応が求められます。
ただし、どのフェーズにおいても「顧客の期待値に応える」ことを最優先しています。これは品質を軽視するということではなく、「何を重視して品質を担保すべきか」の優先順位付けを意味します。
例えば：
- 基本的な機能の正常性や、データの整合性は必ず担保すべき品質基準です
- 一方で、UIの使い勝手や業務フローの最適化など、継続的な改善が必要な領域もあります
- 操作ステップ数の多さ
- ボタン配置の最適化
- 特殊な業務ケースへの対応
これらは私たちが改善できる「伸び代」として捉えています。QAエンジニアがユースケースと照らし合わせながら優先順位を決定し、より良いユーザー体験の実現に向けて主体的に改善を進めていく領域です。
リスクベースでの優先順位付け
次に取り組みたいと考えているのが、「絶対に守るべき品質基準」の言語化です。事業継続に関わる重要機能や、データの整合性に関わる処理、そしてセキュリティ要件など、プロダクトの根幹に関わる部分を明確にしていきたいと考えています。
その上で、プロダクト全体のリスクを可視化する作業に着手したいと思います。各機能がどの程度の影響を持つのか、不具合が発生する可能性はどの程度か、そして対策にかかるコストはどの程度なのか。これらの要素を事業状況を含めて総合的に判断し、優先順位をつけながら品質改善を進められる体制を整えていきたいと考えています。
将来的には、こうした取り組みを通じて、不具合の定量的な分析や効果的なテスト戦略の確立、そして開発プロセス全体での品質向上を目指していきたいと思います。
QAエンジニアを募集しています
Resilireは、プロダクトの品質向上に情熱を持って取り組んでいただけるQAエンジニアを募集しています。
私たちは、品質管理を単なる「バグ探し」とは考えていません。お客様の事業継続を支える重要な価値創造の一環として捉えています。
もし、以下のような方がいらっしゃいましたら、ぜひご応募ください：
- リスク管理の重要性に共感できる方
- 品質を通じて事業価値の向上に貢献したい方
- プロダクトの成長とともに、自身も成長したい方
一緒に、お客様の「当たり前」を守るプロダクトを作っていきましょう。
詳しい採用情報はこちらからご確認いただけます：
Discussion