はじめに 駅メモ！開発チームの id:kaidan388 です。 昨年の6月に新機能として「アルバム機能」をリリースしました。私はこの開発でリーダーを務めました。 このアルバム機能は、駅メモ！の中でも特に規模の大きな開発となりました。また、これまでの新機能がバトル面の強化やチェックイン・アクセスのしやすさが中心で、ライフログを強化する試みはあまり例がなかったため、「本当にユーザーの皆様に楽しんでいただけるだろうか」という懸念も当初はありました。 今回は、この大規模かつ前例のない開発を無事にリリースまで進めるために、チームで試みた2つの工夫について、そのメリットとデメリットを交えてご紹介します。 はじめに アルバム機能について 工夫1：大規模ドッグフーディングの実施 良かった点 1. クオリティの向上 2. 最適な画質の模索 難しかった点 1. 工数の予想が難しくなる 2. コードの整合成が取れない 3. 環境準備のコスト まとめ 工夫2：アジャイル的な週次動作確認 メリット 1. バグの徹底的な洗い出し 2. 段階的なクオリティアップ デメリット リファクタリングに時間がかかる おわりに アルバム機能について 駅メモ！は、おかげさまで11周年を迎えることができました。これを「20年続くゲーム」にしていくために、ゲームを継続して遊ぶこと自体が楽しさにつながる機能を、より増やしていきたいと考えました。 駅メモ！には、ユーザーの皆様の「おでかけの記録」を残すライフログという側面があります。 しかし、これまでの新機能はバトル面の強化や、駅の回収（アクセス）をしやすくする強化が中心で、このライフログという側面に関わる機能強化は比較的少ない状態でした。 そこで今回、ライフログ機能の強化を行うことになりました。 様々な軸が考えられましたが、まずは情報量が多く、ユーザー様が後から振り返る価値を感じやすい「写真」や「画像データ」の素材としての価値に着目し、それらを記録として残す機能の開発を進めることにしました。 また合わせて、以前からユーザー様からのご要望も多かった「過去の移動ログを残し、いつでも見返せる機能」も追加しました。移動の記録と写真を同時に見ることで、お出かけの思い出としてよりリッチに記録できる仕組みを目指しました。 工夫1：大規模ドッグフーディングの実施 前例のない機能だったため、開発の初期段階から「まずは社員で集中的に遊んでみて、そのフィードバックを元に仕様を変更していく」という方針を前提に進めました。 もちろん、駅メモ！では普段からリリース前に開発したものを社員で動作確認しています。 しかし今回はその規模を拡大し、駅メモ！開発チーム外からも、普段から駅メモ！で遊んでいる社員に参加を呼びかけました。最終的に、普段の動作確認の4~5倍の人数の協力を得ることができました。 この取り組みでわかった、良かった点と難しかった点をご紹介します。 良かった点 1. クオリティの向上 最大のメリットは、やはりクオリティの向上です。 人数が多いだけでなく、駅メモ！の熟練者から、チーム外のライトユーザーまで、多様な視点からの意見が数多く集まりました。これらの意見を集約することで、UI/UXをどのように変更すべきかが明確になりました。 例えば、ドッグフーディング中に参加者から「本当にただ写真を記録するための道具になってしまっていて、ゲームらしい『楽しい』という感情が湧きづらい」という指摘がありました。 このフィードバックを受け、急遽、画像を投稿する際に以下のようなミニでんこ画像を表示する仕様を追加しました。 かわいいでんこの画像を追加することで、シンプルに画面を華やかにしたり、でんこと一緒に記録して旅をしている感覚を高めたりする効果を狙っています。 この追加によってユーザー様の感情にどういった変化が生まれるかを定量的に計測するのは難しいですが、追加後の開発メンバーやドッグフーディング参加者の反応を見る限り、非常に好評でした。 2. 最適な画質の模索 画質についても、シビアな調整が必要でした。 画質を良くしすぎると画像1枚あたりの容量が嵩み、特にサーバーからの配信コストが非常に高くなってしまいます。かといって、画質が低すぎると「画像を記録する」という体験そのものの価値を損ねてしまいます。 ドッグフーディングを何度も行い、参加者から画質についての具体的なフィードバックを受けることで、コストと体験のバランスを見極め、細かく調整することができました。 難しかった点 1. 工数の予想が難しくなる フィードバックに応じて仕様を変更すると、当然工数も増えます。 後から工数が増えることで、開発の完了時期の予想が難しくなってしまいました。 対応策としてアルバム開発では、以下のようにチケット状況をグラフにして可視化し、期限までに完了できるかに注視しつつリソースの調整などを行いました。 傾きが急になっている箇所は、まさにドッグフーディングの結果を受け工数の見積もりが増加したタイミングです。 2. コードの整合成が取れない フィードバックに応じて仕様が変更されることで、開発初期に書いたコードと整合成が取れなくなり、結果定期的にリファクタが必要になりました。 これも工数を増やすことにつながります。 3. 環境準備のコスト そもそも、「本番のアプリで、一部の社員だけがアルバム機能（開発中のもの）を遊べるようにする」という環境を準備する作業自体にも、相応の時間がかかります。 今回は、２種類のビルド成果物を用意しておき、ユーザによってアルバム機能を含むビルド成果物と含まないビルド成果物を出しわける、という方法を取りました。 目的は達成されますが、２回ビルドが必要になるのであらゆる場面で時間がかかってしまい、コストが増えてしまいます。 まとめ クオリティが確実に上がるという大きなメリットがある反面、その分エンジニアの対応負荷が高くなるトレードオフの関係にあります。 何にでもこの規模のドッグフーディングを行うのはコストパフォーマンスが悪いと感じたため、プロジェクトの重要度や特性に応じて実施を判断すべきだと感じました。 工夫2：アジャイル的な週次動作確認 駅メモ！では通常、ある程度仕様やデザインが固まってから開発（実装）を開始する、ウォーターフォール型に近い進め方を取ることが多いです。 しかし今回は、 プロジェクト全体の規模が非常に大きい 前述のドッグフーディングの結果、仕様変更が予想される という理由から、従来のように「ある程度の要件が固まるのを待ってから開発する」という進め方ができませんでした。 そこで今回は、要件が固まりきるのを待たず、すでにある程度仕様が確定している画面から順番に開発を着手していきました。 特にドッグフーディングの実施日がマイルストーンとなるため、そこまでにコア機能（最低限、画像がアップロードできる部分など）を完成させる必要がありました。細かいデザイン調整は後回しにして、まずは動くものを優先する、といった判断も行いました。 感覚としては、「いつもの半分の開発工数で、7割くらいの完成度のものを作る」ことを求められるような状況でした。 また、開発と並行して、週に1〜2回のペースで、そこまでの開発進捗についてアルバム機能開発チーム内で動作確認会を行いました。 結果として、「1週間単位で計画立て→開発→動作確認→次の計画立て」という、アジャイル開発に近い体制を取ることになりました。 この方針にも、当然ながら良い点と悪い点がありました。 メリット 1. バグの徹底的な洗い出し まめに動作確認を繰り返すため、バグを早期に、かつ徹底的に潰すことができます。 実際、今回のアルバム機能は規模が大きかったにも関わらず、リリース時に機能起因の不具合は1件も発生しませんでした。これは大きな成果だと感じています。 2. 段階的なクオリティアップ 大規模なドッグフーディングにかける前、まずは開発チーム内で何度も動作確認を実施しました。これにより、チーム内で見つけた分かりづらい文言やUIの細かい調整を事前に実施できました。その結果、クオリティ向上につながりました。 デメリット リファクタリングに時間がかかる この進め方の宿命ですが、一度書いたコードを、後からの仕様変更に伴って何度も書き直していくことになります。 開発の終盤になるほどコードベースは全体的に混沌としていき、変更作業が辛くなっていく、という場面も多々ありました。 「変更に強いコードを書く」という基本がいかに大事か、改めて痛感させられました。 おわりに 今回は、駅メモ！の「アルバム機能」開発において試みた、「大規模ドッグフーディング」と「アジャイル的な週次動作確認」という2つの工夫をご紹介しました。 どちらもメリットだけでなく、工数の増加やコードの複雑化といったデメリットも抱えていますが、前例のない大規模開発を進める上では非常に有効な手段だったと感じています。 リリース後、多くのユーザー様がアルバム機能をご利用くださり、お出かけの思い出を写真と共に記録していただいている様子を拝見し、開発チーム一同、大変嬉しく思っています。 これからも駅メモ！を長く楽しんでいただけるよう、チーム一同、開発と改善を続けてまいります。

こんにちは。株式会社SHIFTのアジャイルコーチの平井（しげ）です。

急成長を遂げるメガベンチャーにおいて、QA組織の役割は単なる不具合の発見にとどまりません。 プロダクトの多角化やマイクロサービス化が進む中で、テスト管理ツールはQAチームだけでなく、PdMやエンジニア、外部パートナーまでがアクセスする「品質情報のハブ」となります。 しかし、この利便性の裏には重大なリスクが潜んでいます。 テスト管理ツールが扱う未公開の仕様、脆弱性情報、あるいは検証用の個人データが漏洩すれば、それは組織全体の致命的な脆弱性になりかねません。 現場のスピードを維持しつつ、経営層が求めるガバナンスをどう両立させるか。 そこで今回は品質管理の現場でセキュリティが最優先課題となっている背景を整理し、大規模組織の全体最適を支える堅牢なテスト管理ツールを紹介します。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼テスト管理ツール11製品の完全比較はこちら▼ 【2026年対応】テスト管理ツール11製品の徹底比較！【脱Excel】 なぜセキュリティ重視のテスト管理ツールが必要なのか 急成長を遂げるメガベンチャーにおいて、QA組織の役割は単なる不具合の発見にとどまりません。 プロダクトの多角化やマイクロサービス化が進む中で、テスト管理ツールはQAチームだけでなく、PdMやエンジニア、時には外部パートナーまでがアクセスする品質情報のハブとなります。 しかし、この利便性の裏には重大なリスクが潜んでいます。もしテスト管理ツールのセキュリティ対策が不十分であれば、それは組織全体の脆弱性になりかねません。 ここでは、なぜ品質管理の現場でセキュリティが最優先課題となっているのかを整理します。 テスト管理ツールが扱う機密情報 テスト管理ツールには、外部に漏洩した場合に事業継続を脅かすような機密情報が凝縮されています。 まず挙げられるのが、リリース前の新機能に関する仕様やロードマップです。 これらは競合他社に対する優位性を左右する戦略的な情報であり、未公開の段階で漏洩することはビジネス上の大きな損失を意味します。 また、テストの過程で発見された脆弱性情報も極めて危険です。 修正が完了する前にその詳細が漏れれば、攻撃者に悪用のヒントを与えることになります。 さらに、本番環境に近い条件で検証を行うために、顧客データを含む検証データが取り扱われるケースも少なくありません。 もしAPIキーや認証情報がテストケースの記述や設定内に不用意に残されていれば、そこからクラウド環境全体への侵入を許すリスクさえあります。 セキュリティ事故が発生する典型パターン 現場で発生しやすい事故の多くは、ツールの設定不備や運用の隙を突いたものです。 典型的な例として、不適切なアクセス権限の設定が挙げられます。 本来は特定のプロジェクト担当者のみが閲覧すべき機密情報を、全社員が閲覧・操作できる設定にしていたことで、意図しない情報流出を招くパターンです。 また、誰がいつ何をしたかを記録する監査ログの不備も深刻です。 万が一事故が起きた際、操作履歴が追えなければ原因の特定や再発防止策の策定が困難になります。 そのほか、クラウド型のツール（SaaS）を利用する際の単純な設定ミスや、テストデータに適切なマスキングを施さずに実機テストを強行してしまうといった人為的なミスも、重大なインシデントに直結します。 セキュリティ観点での評価基準 QAマネージャーとして持続可能な品質体制を築くためには、ツール選定の段階で厳格な評価基準を持つことが不可欠です。 まず重視すべきは、RBAC（ロールベースアクセス制御）の実装です。 役割ごとに細かく閲覧・編集権限を制御できることは、最小特権の原則を守る上で基本となります。 また、社内のID基盤と連携して安全なログインを実現するSSO（シングルサインオン）やSAML対応は、アカウント管理の属人化を防ぐために欠かせません。 さらに、不正操作の抑止と事後調査を可能にする監査ログの完全性、および保存時と通信時の両面におけるデータ暗号化も必須要件です。 これらが客観的に担保されている指標として、ISO27001（ISMS）やSOC2といった国際的なセキュリティ認証の準拠状況を確認することも有効です。 組織のポリシーによっては、インターネットからの遮断が可能なオンプレミス対応の可否が決定打になることもあるでしょう。 これらの基準をクリアすることで、初めてスピードと品質、そして安全性を両立させた全体最適のQA設計が可能になります。 セキュリティに強いテスト管理ツール5選 メガベンチャーのような大規模かつ複雑な開発環境において、セキュリティと効率性を両立させるためには、組織のフェーズやガバナンス方針に合致したツール選定が欠かせません。 ここでは、高度なセキュリティ要件を満たし、エンタープライズ利用に耐えうるテスト管理ツール5選を具体的に紹介します。 PractiTest PractiTestは、情報の透明性と厳格な統制を同時に求める組織に最適なSaaS型ツールです。 最大の特徴は、米国市場でも信頼の厚いSOC2 Type IIおよびISO 27001に準拠している点にあります。 これらの認証は、単に仕組みがあるだけでなく、一定期間にわたってセキュリティ運用が適切に機能していることを外部監査が証明しているものです。 また、操作履歴を詳細に記録するフル監査ログ機能や、SSO（シングルサインオン）およびSAML対応により、ID管理の集約化が可能です。 特筆すべきはフィールドレベルでの権限制御で、プロジェクト内の特定の情報のみを隠匿するといった、緻密な情報ガードを実現します。 セキュリティ要件を明文化し、厳格な監査対応を前提とする企業にとって、非常に有力な選択肢となります。 TestRail 画像： 公式サイト より 世界的に高いシェアを誇るTestRailは、柔軟な導入形態と詳細なロール管理が強みのツールです。 クラウド版だけでなく、社内ネットワーク内に環境を構築できるオンプレミス版を提供しているため、データを外部に出せない極めて機密性の高いプロジェクトでも活用できます。 ユーザーごとに細かく権限を設定できるロールベースのアクセス制御（RBAC）を備えており、外部パートナーと協力する際も適切な情報隔離が容易です。 またすべての変更履歴を保持する監査ログ機能や、REST APIによる豊富な連携機能を持ち、既存のセキュリティ監視システムとの統合もスムーズに行えます。 自社のポリシーに合わせてインフラから運用設計までをコントロールしたい企業に適しています。 Tricentis qTest 画像： 公式サイト より Tricentis qTestは、大規模なエンタープライズ組織での統制設計に特化したツールです。 SSOやLDAPとの連携はもちろん、要件定義からテスト、不具合修正に至るまでの「完全なトレーサビリティ」を管理できる点が大きな特徴です。 すべてのデータ変更には詳細な履歴トラッキングが適用され、いつ誰がどの値を変更したかを瞬時に特定できるため、コンプライアンス遵守が求められる現場での信頼性が非常に高いです。 DevOpsサイクルへの統合も強化されており、スピードを落とさずにガバナンスを効かせたいメガベンチャーの品質推進リードにとって、全体最適を実現するための強力な基盤となります。 Zephyr Enterprise 画像： 公式サイト より Jiraを開発の核に据えている組織であれば、Zephyr Enterpriseは極めて自然な選択肢となります。 Jiraとのネイティブな統合を実現しながら、大規模利用を前提とした強固なセキュリティ機能を備えています。 RBAC（ロールベースアクセス制御）による厳格な権限管理に加え、エンタープライズ水準の監査証跡保持機能を搭載しています。 これによりアジャイル開発のスピード感を維持したまま、セキュリティ監査に必要な証跡を自動的に蓄積することが可能です。 DevSecOpsの考え方を取り入れ、開発・運用・セキュリティを一体化させて管理したい組織にとって、その親和性の高さは大きなメリットをもたらします。 QAComplete 画像： 公式サイト より QACompleteは、品質統制とリスク管理に重きを置いたテスト管理ツールです。 特に規制の厳しい業界や、高度なコンプライアンスが求められるプロジェクトでの活用実績が豊富です。 要件に対するテストの網羅性を可視化するトレーサビリティ機能が強化されており、すべての操作は監査ログとして記録されます。 また独自のワークフロー統制機能を備えているため、承認プロセスを経ていないテスト実行やステータス変更を制限するなど、人為的な不正やミスを防ぐ仕組みが組み込まれています。 文書化や証跡管理を徹底し、属人化を排した持続可能な品質体制を築きたいマネジメント層に高く評価されています。 セキュリティ視点で失敗しない選び方 メガベンチャーのような大規模な組織でQAの全体最適を目指す際、テスト管理ツールの選定は単なる機能比較に留まりません。 複数のプロダクトが並走し多くの関係者が関与する環境では、ツールの脆弱性がそのまま事業リスクに直結するためです。 特に、機密性の高いテストケースやバグ情報、ソースコードとの連携情報を扱う特性上、セキュリティ要件を最優先事項として評価する必要があります。 選定の要諦は、現場の利便性とガバナンスの維持をいかに両立させるかにあります。 現場のスピードを損なわない操作性を確保しつつ、経営層やセキュリティ部門が求める厳しい基準をクリアしているか、多角的な視点での検証が欠かせません。 以下に、導入前に必ず確認すべき具体的なチェックポイントと、陥りがちな失敗パターンを整理しました。 導入前チェックリスト まず確認すべきは、自社のISMS（情報セキュリティマネジメントシステム）やPマークなどの認証基準との整合性です。 ツールがSOC2 Type2レポートを保持しているか、暗号化方式が自社のポリシーに適合しているかなど、コンプライアンス面での適合性を精査します。 これを怠ると、導入の最終段階でセキュリティ部門から却下されるといった手戻りが発生し、組織全体の信頼を損ねる要因となります。 次に、データの保管場所と主権の確認です。 クラウド型（SaaS）を採用する場合、データセンターの所在国や法的な管轄権が自社のデータ取り扱い方針と矛盾しないかを確かめます。 同時に、万が一の事態に備えた監査ログの出力テストも必須です。 誰が、いつ、どのテストケースを参照・変更したかを正確に追跡できることは、インシデント発生時の初動対応だけでなく、内部不正の抑止力としても機能します。 さらに権限設計のレビューを詳細に行います。開発者、QAエンジニア、業務委託パートナーといった役割ごとに、最小権限の原則に基づいたアクセス制御が可能かどうかを検証します。 プロジェクト単位での閲覧制限や、一部の機密情報の非表示設定など、柔軟かつ堅牢な管理ができるかどうかが、大規模運用における安全性の鍵となります。 よくある失敗 最も頻繁に見られる失敗は、権限設定の形骸化です。 導入初期は厳密に設計していても、運用が複雑になるにつれて「とりあえず全員管理者権限」といった運用が常態化してしまうケースです。 これにより、退職者のアカウントが残存したり、本来閲覧権限のないユーザーが機密情報に触れたりするリスクが高まります。 役割に基づいた権限管理（RBAC）が直感的に行えないツールを選んでしまうと、運用負荷に耐えきれず、結果としてセキュリティホールを生むことになります。 また、テストデータの未マスキングも重大なリスクです。 本番環境に近いデータを利用する際、個人情報や機密情報がそのままテスト管理ツール上にコピーされ、それが適切に保護されないまま共有される事態は避けなければなりません。 ツール側で機密情報を扱う際のガイドラインが未整備なまま運用を開始すると、意図しない情報漏洩を招く恐れがあります。 最後に、運用設計が不在のままツールを導入してしまう失敗も少なくありません。 セキュリティ機能が豊富であっても、それを誰が定期的に監査し、設定を最適化し続けるのかという体制が決まっていない場合、ツールの防衛能力は宝の持ち腐れとなります。 ツールの機能に依存しすぎず、組織としての運用フローにセキュリティチェックを組み込む視点が、持続可能な品質体制を築くためには不可欠です。 セキュリティに強いテスト管理ツールをお探しならPractiTest テスト管理ツールのセキュリティを重視するなら、エンタープライズレベルのセキュリティ対策とガバナンス機能を備えたツールを選ぶことが重要です。 その選択肢の一つが、PractiTestです。 エンタープライズ基準のセキュリティ体制 PractiTestは、企業利用を前提としたSaaS型テスト管理ツールとして、以下のようなセキュリティ機能・体制を備えています。 ・ISO 27001認証取得 ・SOC 2 Type II準拠 ・通信データの暗号化（HTTPS/TLS） ・保存データの暗号化 ・定期的なセキュリティ監査・脆弱性対応 これらの第三者認証・監査体制により、情報管理の透明性と信頼性が担保されています。 厳格なアクセス管理と統制 セキュリティリスクの多くは「不適切なアクセス管理」から発生します。 PractiTestでは以下のような仕組みが提供されています。 ・SSO（シングルサインオン）対応 ・ロールベースのアクセス制御（RBAC） ・ユーザー権限の詳細設定 ・監査ログの取得・追跡 特にエンタープライズ環境では、最小権限の原則に基づく運用が不可欠ですが、PractiTestは組織単位での厳密な権限制御を実現できます。 安全なクラウド環境での運用 PractiTestはクラウド型（SaaS）で提供されており、インフラレベルのセキュリティも考慮されています。 ・セキュアなクラウドインフラ上での運用 ・定期的なバックアップ ・高可用性を前提とした設計 自社でセキュリティ対策を一から構築・維持する負担を軽減しつつ、エンタープライズ水準のセキュリティを確保できます。 セキュリティとテスト統制を両立したい企業に テスト管理ツールは、単なる「テストケース管理ツール」ではありません。 設計情報、不具合情報、場合によっては機密性の高いデータを扱う重要な情報基盤です。 そのため、 ・エンタープライズ基準の認証取得 ・厳格なアクセス管理 ・監査可能な運用体制 ・クラウド環境における高水準のデータ保護 これらを満たすツールを選定することが不可欠です。 セキュリティを重視したテスト管理基盤を構築したい場合、PractiTestは有力な選択肢の一つと言えるでしょう。 まとめ メガベンチャーのような急成長を続ける組織でQAの全体最適を実現するためには、ツール単体の機能性やコストパフォーマンス以上に、組織の信頼性と継続性を担保する「セキュリティガバナンス」の視点が不可欠です。 複数のプロダクトやマイクロサービスが混在し、開発スピードが重視される環境だからこそ、守りの基盤が揺らいでしまうと、一度の事故が事業全体の足を止める致命傷になりかねません。 QAマネージャーとして、現場のボトルネックを解消しながら経営層からの信頼を勝ち取るためには、ツール選定の軸を「統制設計」「権限制御」「監査ログ」という3点に集約して評価することが重要です。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）