すべてのカテゴリ

【2026年7月19日更新】Google Playクローズドテストの12人・14日要件、登録・opt-in・インストール・起動確認の違い、製品版アクセス申請前の確認事項を最新状況に合わせて見直しました。※この記事は、BySho2が提供しているGoogle Playクローズドテスト支援サービスの案内を含みます。サービス利用は任意であり、Google Playの審査通過や製品版公開を保証するものではありません。AndroidアプリをGoogle Playで公開しようとしたときに、最初につまずきやすいのが「クローズドテスト」です。アプリ自体は完成しているのに、「12人のテスターが集まらない」「テスター登録のやり方が分からない」「14日間テストしたつもりなのに条件を満たせていない」「申請時に何を書けばよいか分からない」という理由で、製品版公開まで進めないケースがあります。特に新しい個人デベロッパーアカウントでは、製品版アクセス申請の前に、12人以上のテスターが14日間継続してクローズドテストに参加している状態が必要になります。この記事では、Google Playクローズドテストで失敗しないために、事前に確認しておきたいポイントを整理します。Google Playクローズドテストとは？Google Playのクローズドテストは、製品版として一般公開する前に、限られたテスターだけがアプリをインストールして確認できるテストです。単にAABをアップロードするだけではなく、Play Consoleの設定、テスター登録、参加リンクの案内、インストール確認、14日間の運用まで含めて進める必要がありま

はじめに「ちょっとお願いしたいんだけど…このプロダクト、テストお願いできますか？」そう言われて見せられたのは、完成間近の画面と、簡単な概要だけ。「仕様書…は、まだなくて。とりあえず触ってみて、バグがないか見てほしいです！」──実はこれ、QAとしてご相談いただく中でも、とてもよくあるシチュエーションなんです。個人開発や小規模チームでは、「正式な仕様書を用意する余裕がない」なんてこと、めずらしくありません。でも、そんなときでも、テストを始める方法はちゃんとあります。今回は、私がこれまでに実際やってきた「仕様がない状態からのQA」について、お話してみます。「仕様がない」ってどういうこと？まず、「仕様がない」というのは、本当に“何も決まっていない”という意味ではないんですよね。たとえば…・開発者さんの頭の中にある・Slackのメッセージでざっくり話した・FigmaやNotionにUIだけはある・以前のバージョンがなんとなくベースになってるこんなふうに、言語化・明文化されてないだけで、実は“期待される動き”は存在していることが多いんです。なので、QAとして最初にやるのは、「仕様があるかないか」じゃなくて、どこに“仕様のヒント”が隠れているか？を探すというアプローチだったりします。私が実際にやっていることでは、そんなときにQAとしてどう動くか？いくつか、私の定番パターンをご紹介しますね。● まずはユーザー視点で触ってみるいわゆる“アドホックテスト”のように、ざっくり触ってみて違和感や気づきを拾います。「これってこう動くと思ったけど、実際は違う？」といったポイントは、仕様を考えるうえでのヒン

“見落とし防止”のためのヒント「テスト項目、作ったけど…なんか不安」「チェックリストはあるけど、これで十分なのかな？」そんなふうに感じたこと、ありませんか？この記事では、“テスト観点”ってそもそも何？というところから、観点を考えるためのヒントまで、やさしくお話ししていきます。観点って、なに？テスト観点とは、「何をチェックすべきか」という視点や切り口のことです。・たとえばこんなものがあります：・機能が正しく動くか（正しいデータ入力、エラー処理 など）・操作しやすいか（UIの使いやすさ、ナビゲーション など）・セキュリティ的に問題がないか（認証やアクセス制限）・パフォーマンスが落ちないか（読み込み時間、同時アクセス など）つまり、「何を、どんなふうにチェックすべきか？」を考えるための“地図”のようなものなんです。観点が抜けやすい理由経験上、観点が抜けてしまうのには、こんなパターンがあります：・ユーザーの使い方を想像していない→「どんな人が、どんな状況で使う？」が抜けている・画面単位でしか考えていない→全体の流れ（登録→確認→保存→戻る…など）が見えていない・過去の失敗から学べていない→以前あったトラブルを参考にしていない「項目をひたすら並べて終わり」だと、どうしても見落としが出てしまうんですね。観点を考えるヒントでは、どうすれば観点をうまく出せるのでしょうか？私が現場でよく使っている方法をご紹介します。✅ ユーザーのストーリーを想像する「どんな人が、何をしたくてこの機能を使うんだろう？」と考えてみます。たとえば：・忙しい主婦がスマホで買い物をしているかも？・通信状況が悪い中でログイ

「QAまで手が回らない…でも、ちょっと不安」「バグが残ってないか心配だけど、自分ひとりでは確認しきれない」「テストって何から手をつけたらいいの？」「お願いするほどでもないけど、誰かに一度見てほしい…」そんなふうに感じること、ありませんか？実はこのお悩み、個人開発者さんや小さな開発チームの方からよく聞く声なんです。今日はそんな方に向けて、「テストや品質保証（QA）って、ちょっとだけ頼ってもいいんですよ」というお話をしたいと思います。QA支援は「ちょっとだけ」でも、大歓迎です「QAって、全部任せるもの」「準備が整ってから依頼するもの」そんなふうに思っていたら、どうか気軽に考えてみてください。こんな“部分的なご依頼”もよくあります：・作ったテスト項目のレビューだけ・今の仕様で、バグの観点が足りているかだけ見てほしい・「このアプリ、大丈夫そう？」って感覚的に見てもらいたい・テストを始めるにあたって、どう進めたらいいか相談したい実は、こうした“小さな依頼”こそ、開発初期や少人数体制ではとても効果的なんです。ひとつの気づきや、ちょっとしたアドバイスで、大きなトラブルを防げることもあります。実際に、こんな支援をしてきましたたとえば過去にはこんな事例があります：・治験管理アプリのテストケース作成＋テスト実施開発者さんの「一通りテストしたいけど時間が足りない」という声にお応えして、チェックリストの作成と、テストの実施をお手伝いしました。・カードゲームアプリの観点出し＋チェック項目作成仕様に沿ったテスト項目だけでなく、ユーザー視点の気づきも加えたことで、初期リリース前の不安がグッと軽減されたとのご

はじめに：テスト観点って、なんとなく難しそう？「観点って、どうやって考えるの？」「なんかセンスが要りそう…」そう思ったこと、ありませんか？実際、私も新人の頃は「この仕様、どこをテストすればいいの？」と悩んでばかりでした。でも今は、「観点はセンスではなく“考え方”で出せるもの」と思っています。今回はそのコツを、やさしく解説していきます。「テスト観点」って、そもそも何？テスト観点とは、かんたんに言うと「どこを注目して確認するか」という“着眼点”のことです。たとえば、ユーザー登録機能をテストするなら──入力値に間違いがあったらどうなる？メールアドレスは正しく保存される？パスワードは安全に扱われてる？といった「確認したいポイント」が、まさに観点です。観点を考えるための3ステップ「どうやって観点を出せばいいの？」という方へ、私が普段使っている3ステップを紹介します。ステップ①：目的をはっきりさせるまずは、「何のためにテストするのか」を考えます。安心して使えるようにしたい？不正利用を防ぎたい？ユーザーが迷わないようにしたい？目的がはっきりすると、「それなら、こういう点が気になるよね」という観点が浮かびやすくなります。ステップ②：対象をざっくり把握する仕様書があれば軽く読んで、どんな動きになるのかをイメージします。画面だけでもOK。「何ができるのか」がわかれば、観点のヒントになります。ステップ③：「もし◯◯だったら？」と仮説を立ててみる観点は、「もしも」に注目すると出しやすくなります。もし入力が空だったら？もし通信が不安定だったら？もし同じアカウントで2人がログインしたら？いろんな“もしも”

こんにちは、Ruaです。ふだんはゲームやアプリ、WebサービスなどのQA（品質保証）に長く関わっていて、今はメガベンチャー系企業でQAリードをしています。今回は、「開発初期の段階からQAって必要？」というテーマでお話ししたいと思います。「まず動くものを作ってから考えたい」という個人開発や小規模チームの気持ち、すごくよく分かります。でも…あとから直すのって、すごく大変なんですよね。QAってテストだけの話じゃないんですQAというと、「リリース前にバグを見つける役割」と思われがちなのですが、じつはもっと広い視点でプロダクトに関わる立場でもあります。たとえば、・仕様の“抜け漏れ”に気づく・ユーザー視点で「これ、わかりづらいかも…」と指摘する・優先順位の整理を手伝うといったように、“作る前”や“作っている途中”にこそ価値が発揮できる場面がたくさんあるんです。“後戻り”はコストが跳ね上がる「とりあえず作ってみて、あとで直せばいいでしょ？」……それ、本当に直せますか？プロダクト開発って、一歩進むごとに周辺の仕様やコードが複雑になっていきます。つまり、あとから直すには「つながっている他のところ」も直す必要があるんです。結果として、・修正範囲が広がる・スケジュールが押す・テストし直しになる・モチベーションが下がるなんて悪循環に…。QAは「リリース直前に慌てて呼ぶ存在」ではなく、もっと前から一緒に走る仲間としていると、こうした手戻りを未然に防げるんです。初期から取り入れられる“軽いQA”とはいえ、いきなり「がっつりQAを入れよう」となると、ハードルが高いですよね。そこでおすすめしたいのが、“軽めの

「テストって、何をすればいいの？」「バグが出てこないか、ちょっと不安…」そんなとき、QA（品質保証）の力を借りられるって知っていましたか？一人でがんばっている開発者さんや、少人数チームで走っている方にとって、品質のことまで手が回らないのは自然なこと。でも、だからこそ“ちょっとだけ”QAを頼ってもらえるとうれしいのです。今回は、「QAに何が頼めるのか？」をわかりやすくまとめてみました。1. QAは“テストだけ”じゃないんです「QAって、バグを見つける人でしょ？」実は、それだけではありません。QAは、開発の前・途中・終わった後、いろんなタイミングで「見落とし」を防いだり、「これで大丈夫？」を一緒に考えたりできる存在です。例えるなら、道に落ちている石を拾っておいたり、「この先に坂道があるよ」と声をかけたりする“伴走者”のようなイメージです。2. こんなタイミングで頼れますQAに相談していただけるタイミングは、思っているよりたくさんあります。たとえば…開発初期：「テストのこと、まだ何も考えてない…」実装途中：「ざっくり動くようにはなったけど、ちゃんとチェックできてない」リリース前：「動作確認したけど、誰かに見てほしい」運用中：「不具合があったとき、どう対処すべきかわからない」どの段階でも、QAは「いま必要な品質の視点」でサポートできます。3. QAにできる具体的なことたとえば、私がお手伝いできるのはこんなことです。・テストの 計画づくり（何を、どう確認するか）・テストケース・チェックリストの 作成・探索的テスト／アドホックテスト でのバグの洗い出し・「この仕様で大丈夫？」という 壁打ち

「品質保証（QA）」って、どんなイメージがありますか？マニュアルやルールに厳しくて、手順どおりにチェックしていくような…ちょっと堅苦しくて、近寄りがたい印象を持っている方もいるかもしれません。でも実際は、もっと柔らかくて、チームに寄り添う仕事なんです。実は“気づき”の積み重ねが大事な仕事品質保証の仕事って、よく「間違いを見つける人」って思われがちです。もちろん、バグを見つけるのも大事な役割のひとつ。でもそれ以上に大事なのが、「違和感」や「不安」に気づけることなんです。たとえば…「この動き、ユーザーにとって分かりづらくないかな？」「仕様がふわっとしてるけど、これはこのままでOK？」「この機能、他の操作とのつながりがちょっと不自然かも？」…といった“なんとなく引っかかる感覚”を言葉にして、開発チームと一緒に、どうしたらより良くなるかを考える。それが、品質保証という仕事の一番の役割だと私は思っています。QAって、プロダクトの相談役です小さな開発チームや個人開発では、「仕様を誰かに見てもらいたいけど、エンジニア同士で忙しくて相談できない」「品質のことを気にしたいけど、どこから手をつけていいかわからない」…そんな声をよく聞きます。そんなときこそ、QAはチームの“相談役”になれる存在です。仕様の確認からテストの進め方、開発効率と品質のバランスの取り方まで、「ちょっと聞いてほしい」ことに寄り添えるのが、QAの強みです。Ruaのご紹介私はこれまで、ゲーム・アプリ・Webサービスなど、さまざまなプロダクトのQAに関わってきました。現在はメガベンチャー系企業でQAリードを務める一方、副業として様々