1. はじめに
独力＋AI活用で月商1億円を目指している。
ここ最近、開発用PCとSurfaceの使い分けについて、かなり試行錯誤してきた。
開発用PCでは、Cursorを使って実装、修正、自動テスト、ビルド、PR作成まで進めている。
一方で、Surfaceは当初、実機UI確認用として使おうとしていた。
ただ、常時並行でSurfaceを動かすのは、思ったより効率が悪かった。
毎回確認させても、指摘が重複しやすい。
まだ画面が荒い段階で確認しても、同じような違和感ばかり出る。
しかも、下手に指示すると、実際の確認ではなく、報告書やテンプレート作成に流れてしまう。
そのため、Surfaceを常時稼働させるのではなく、節目ごとの実機確認に回す方針にしていた。
しかし、それだとSurfaceが少し暇になる。
そこで今回、考え方を少し変えた。
暇をしているSurfaceに、シナリオ試験を実施させることにした。
2. シナリオ試験とは何を見るのか
ここでいうシナリオ試験は、単なる画面単位の確認ではない。
1画面だけを見て、ボタンがあるか、表示が崩れていないかを確認するだけではない。
もっとユーザーの流れに近い形で確認する。
たとえば、以下のような観点である。
初回利用者として迷わず始められるか
ログイン後に何をすればよいか分かるか
主要導線が自然につながっているか
操作後に結果が分かるか
履歴や状態を確認できるか
空データやエラー時に不安にならないか
途中で詰まったときに復帰できるか
画面をまたいだときに文言や導線が矛盾しないか
つまり、単体の画面確認ではなく、一連の利用体験として成立しているかを見る。
これは、今のプロジェクトにとってかなり重要である。
3. 自動テストだけでは分からない部分がある
Playwrightのような自動テストはすでに使っている。
自動テストは非常に重要である。
ログインできるか。
主要画面が表示されるか。
特定の操作でエラーにならないか。
重要な導線が壊れていないか。
こうした確認には強い。
ただし、自動テストだけでは分からない部分もある。
たとえば、
初めて触ったときに意味が分かるか
画面遷移が自然か
情報の出し方が親切か
文言が分かりやすいか
同じような案内が重複していないか
途中で「次に何をすればいいのか」が見失われないか
体験として気持ちよく進めるか
こういう部分は、実際に流れで触ってみないと分からない。
だから、Surfaceには単発のUI確認ではなく、シナリオ試験をやらせる方が向いているのではないかと考えた。
4. Surfaceに向いている仕事が見えてきた
Surfaceに常時開発をやらせるのは効率が悪い。
これは以前から感じていた。
2台で開発すると、ブランチ管理、作業範囲、Gitの状態、ファイル競合など、余計な管理が増える。
では、Surfaceは何に向いているのか。
今回見えてきたのは、開発ではなく、長めの確認作業である。
開発用PCでは、実装や修正を進める。
Surfaceでは、開発後の成果物を使って、ユーザー目線で長めに触る。
この分担なら、Surfaceの価値が出やすい。
Surfaceは、開発担当ではなく、確認担当。
しかも、単なる画面チェックではなく、シナリオ確認担当。
この役割の方が合っている。
5. 以前のSurface運用で苦労したこと
Surface運用では、かなり苦労した。
テストをしてほしいのに、なぜかファイル作成ばかりしてしまう。
報告書のテンプレートを作る。
チェックリストを作る。
新しいMarkdownを追加する。
しかし、肝心の実画面確認が進まない。
これはかなり困った。
今回のシナリオ試験では、その失敗を繰り返さないようにしたい。
Surfaceにやらせることは明確にする。
新しいテンプレート作成を目的にしない
実際に画面を開く
操作する
詰まった箇所を記録する
スクリーンショットを残す
期待結果と実際結果を書く
開発用PC側が修正できる粒度で報告する
つまり、成果物は「きれいな報告書」ではない。
実際に触った結果と、修正につながる指摘である。
6. シナリオ試験で見たいこと
今回、Surfaceで見たいのは、主に以下である。
6.1 初回導線
初めて使う人が、何をすればよいか分かるか。
説明が足りないのか。
ボタンの位置が悪いのか。
最初に見るべき画面が分かりにくいのか。
そもそも文言が硬すぎるのか。
ここを見たい。
6.2 ログイン後の中心導線
最近、ログイン後の「次にできること」の案内は改善された。
ただし、それが本当に機能しているかは、実際に流れで見ないと分からない。
案内は出ているが、既存カードと重複していないか。
次に押す場所が自然か。
状態ごとの表示が分かりやすいか。
ここを確認したい。
6.3 主要操作の流れ
主要操作が、一連の流れとして自然につながっているか。
単体では動いていても、続けて触ると違和感が出ることがある。
この確認は、シナリオ試験向きである。
6.4 空データ・エラー時の見え方
データがない場合や、取得に失敗した場合に、画面が不安にならないか。
何も表示されない。
壊れているように見える。
次に何をすればよいか分からない。
こういう状態は、初期公開前に潰しておきたい。
6.5 最後まで触ったときの印象
一連の流れを触った後に、
「まあ、少し分かってきた」
「次も触ってみようかな」
と思えるか。
逆に、
「何をしているのか分からない」
「画面が不安」
「説明不足」
「まだ見せるのは厳しい」
となるのか。
この印象を見たい。
7. 今のプロジェクトに必要なのは通し確認
最近の開発では、細かい改善が進んできた。
ログイン後の案内。
文言の統一。
自動テストの安定化。
スクリーンショット確認。
UI部品の整備。
PR単位でのmain反映。
これらは前進である。
ただし、個別の改善が進んでも、通しで触ったときに成立していなければ意味がない。
今必要なのは、まさに通し確認である。
画面Aは良い。
画面Bも良い。
でも、AからBへ移動したときに分かりにくい。
操作後にどこを見ればよいか分からない。
同じような説明が複数あり、逆に迷う。
こういう問題は、シナリオ試験で見つかりやすい。
8. Surfaceを暇にさせない使い方
Surfaceを常時動かすのは効率が悪い。
しかし、完全に眠らせておくのももったいない。
そこで、Surfaceには節目ごとのシナリオ試験を担当させる。
開発用PCが一定の改善を終えたら、Surfaceで長めのシナリオ試験を行う。
たとえば、
初回利用シナリオ
ログイン後の基本操作シナリオ
状態確認シナリオ
履歴確認シナリオ
エラー・空データ確認シナリオ
小画面での操作確認シナリオ
こうした形で、まとまった流れを確認する。
Surfaceが暇なときに、なんとなくファイルを作らせるのではない。
きちんとシナリオを与えて、実際に触らせる。
これなら、Surfaceの使い道としてかなり意味がある。
9. 期待している効果
Surfaceでシナリオ試験をやることで、期待している効果は大きい。
| 期待効果 | 内容 |
|---|---|
| 導線の弱さ発見 | 画面間のつながりの悪さを見つけられる |
| 初回体験の改善 | 初めて触る人の迷いを減らせる |
| UI重複の発見 | 同じ案内や似たカードの重複に気づける |
| エラー時の不安解消 | 空データや失敗時の見え方を確認できる |
| 自動テストの補完 | Playwrightでは拾いにくい違和感を拾える |
| 開発優先度整理 | 次に直すべきP0/P1を抽出できる |
特に、最近は「中心画面のカード重複」や「次にできること」の見せ方が課題になっている。
これはまさに、シナリオ試験で見た方がよい部分である。
10. 注意点
もちろん、Surfaceにシナリオ試験をやらせる場合にも注意は必要である。
またファイル作成だけに逃げられると困る。
だから、指示では以下を明確にする必要がある。
新規テンプレート作成は禁止
実画面を確認する
操作した結果だけを書く
未確認を確認済みにしない
スクリーンショットを残す
P0/P1/P2で分類する
開発用PC側が直せる粒度で書く
長文の感想ではなく、修正につながる指摘にする
Surfaceには、文書作成係ではなく、シナリオ試験担当として働いてもらう。
ここを間違えないようにする。
11. 今回の結論
暇をしているSurfaceに、シナリオ試験を実施させることにした。
Surfaceを常時並行で動かすのは、効率が悪い。
しかし、節目ごとの実機確認や、長めのシナリオ試験には価値がある。
開発用PCでは実装と自動テストを進める。
Surfaceでは、ユーザー目線で通し確認を行う。
この分担なら、Surfaceの存在価値が出る。
今後は、Surfaceに単なるファイル作成をさせない。
実際に画面を開かせる。
流れで触らせる。
迷った箇所、詰まった箇所、不安になった箇所を記録させる。
スクリーンショット付きで、開発側が直せる指摘にする。
月商1億円を目指すなら、ただ機能があるだけでは足りない。
ユーザーが迷わず、安心して、また触りたいと思える体験が必要である。
そのために、Surfaceにはシナリオ試験担当として働いてもらう。
暇な端末を遊ばせるのではなく、品質改善のために使う。
これも、独力＋AI活用の開発体制を強くする一手になるはずである。
