1. はじめに
独力＋AI活用で月商1億円を目指している。
最近、開発用PCと既存端末の2台体制について、かなり試行錯誤してきた。
最初は、開発用PCで実装を進め、既存端末でテストや確認を並行して行えば、かなり効率が上がるのではないかと考えていた。
開発用PCが作る。
既存端末が確認する。
既存端末が指摘する。
開発用PCで直す。
この流れが常に回れば、一人で進めているプロジェクトでも、開発担当と確認担当を分けるような体制に近づける。
ただ、実際に運用してみると、そこまで単純ではなかった。
結論として、既存端末での実機確認には意味がある。
ただし、常時並行で走らせるほど効率はよくない。
そのため、今後は既存端末を常時稼働させるのではなく、節目ごとの実機UI確認・スクリーンショット付き指摘係として使う方針に切り替える。
2. 実機確認には価値がある
まず、既存端末での実機確認そのものは無駄ではない。
むしろ、効果はある。
開発用PCだけで確認していると、どうしても開発者目線になりやすい。
コードが通るか。
ビルドが成功するか。
自動テストが通るか。
エラーが消えているか。
もちろん、それらは重要である。
ただ、サービスとして本当に重要なのは、実際に画面を見たときに、
見やすいか
迷わないか
ボタンの意味が分かるか
情報の優先順位が自然か
画面として成立しているか
触っていて不安にならないか
使ってみたいと思えるか
という点である。
こうした部分は、自動テストだけでは拾いきれない。
だから、別端末で実際に画面を見ることには価値がある。
3. ただし、常時並行は効率が悪い
一方で、既存端末側を常時動かすと効率が悪くなりやすい。
ここが今回の大きな反省点である。
テストや確認には意味がある。
しかし、毎回並行して動かすと、以下のような問題が出る。
既存端末側でもAIツールの使用量を消費する
テストよりドキュメント整備に寄りやすい
報告書作成に時間を使いすぎる
指摘が感想寄りになり、修正しづらい
開発側がまだ作業途中なのに確認してしまう
同じような指摘が何度も出る
管理コストが増える
つまり、確認作業そのものには価値があるが、使うタイミングを間違えると効率が落ちる。
2台あるからといって、常に2台を動かす必要はない。
4. 確認側に必要なのは、感想ではなく修正可能な指摘
確認側の役割は、ただ感想を出すことではない。
「見づらい」
「分かりにくい」
「微妙」
「使いにくい」
これだけでは、開発側が修正しづらい。
必要なのは、開発側がそのまま対応に入れる指摘である。
たとえば、以下のような形が望ましい。
どの画面か
どの操作で起きたか
本来どうあるべきか
実際にはどうなっていたか
どれくらい重要か
スクリーンショットはどれか
どう直すとよさそうか
ここまで整理されて初めて、確認結果が開発作業につながる。
今後、既存端末側の役割は、広い設計や実装ではなく、実機UIレビューと修正指摘に絞る。
5. 節目ごとの確認に切り替える
今回の結論は、既存端末での確認を完全にやめることではない。
常時並行をやめて、節目確認に切り替えるということだ。
たとえば、以下のようなタイミングで使う。
| タイミング | 実機確認 |
|---|---|
| 大きなUI変更を入れた後 | 実施する |
| 主要導線を修正した後 | 実施する |
| 初回ユーザー向け画面を修正した後 | 実施する |
| サービス公開判断の前 | 実施する |
| 毎日なんとなく確認 | 原則不要 |
| まだ開発途中の状態 | 原則不要 |
| ドキュメント変更のみ | 不要 |
| 自動テストで十分確認できる範囲 | 不要 |
確認側の端末は、常時稼働するものではなく、開発成果物を実機で検収する端末として使う。
この方が効率がよい。
6. 当面は開発用PCに集中する
現時点では、開発用PC側で前に進めることが最優先である。
実際に触ってみると、デザイン品質や機能品質に不安がある。
つまり、今必要なのは、確認側を常時動かすことではない。
まず、開発側で主要画面と導線をしっかり直すことだ。
当面は、開発用PCで以下に集中する。
主要画面のUI改善
初回導線の整理
操作後のフィードバック改善
空データやエラー表示の整理
スマホ・小画面表示の改善
自動テストの維持
ビルド確認
コミットとプッシュ
残課題の優先度整理
まだ荒い画面を毎日別端末で確認しても、似たような指摘が大量に出るだけである。
まず開発側で直す。
一区切りついたら、別端末で見る。
この順番にしたい。
7. 実機確認で見るべき観点
既存端末を節目確認に使う場合、見るべき観点は絞る。
毎回すべてを見る必要はない。
重点的に見るべきなのは、以下である。
| 優先度 | 観点 |
|---|---|
| 高 | 最初に何をすればよいか分かるか |
| 高 | 主要画面が見やすいか |
| 高 | 重要な操作導線が目立つか |
| 高 | 操作後に結果が分かるか |
| 高 | 空データ時に不安にならないか |
| 高 | エラー時に説明があるか |
| 中 | 小画面で崩れないか |
| 中 | 文言が自然か |
| 中 | 情報量が多すぎないか |
| 中 | また触りたいと思えるか |
サービス内容に直結する具体的な画面名や機能名は、公開記事では書かない。
ただし、内部的には対象画面を決めて、節目ごとに確認する。
8. 確認報告は短くてよい
確認報告は、長い設計書である必要はない。
むしろ、短くてよい。
重要なのは、開発側がすぐ直せることだ。
理想は以下のような形式である。
# 実機UI確認報告
## 1. 確認対象
- branch:
- commit:
- 起動URL:
- 実施日時:
- 端末:
- ブラウザ:
## 2. 総合評価
- UI全体:
- 操作導線:
- 公開可否:
- 最優先で直すべき点:
## 3. 重要指摘
### UI-YYYYMMDD-001
- 画面:
- URL:
- 操作:
- 期待結果:
- 実際結果:
- 問題:
- 修正方針案:
- スクリーンショット:
## 4. 主要画面チェック表
| 画面 | 判定 | コメント | スクリーンショット |
|---|---|---|---|
| 主要画面A | OK/NG | | |
| 主要画面B | OK/NG | | |
| 主要画面C | OK/NG | | |
## 5. 開発側への修正依頼要約
1.
2.
3.
これで十分である。
毎回、大きな指示書や設計書を作る必要はない。
むしろ、それをやると効率が落ちる。
9. これは後退ではなく効率化である
一見すると、既存端末側の常時稼働を弱めることは後退に見えるかもしれない。
しかし、そうではない。
これは効率化である。
PCが2台あるからといって、常に両方を動かす必要はない。
AIツールを契約しているからといって、すべての端末でAIを使い続ける必要もない。
大事なのは、サービス公開に近づく使い方をすることである。
今は、開発用PCで品質改善を進める段階。
既存端末は、成果がまとまったタイミングで確認する段階。
役割とタイミングを間違えないことが重要である。
10. 今回の結論
2台体制の使い方を見直した。
結論は、既存端末での確認を完全にやめることではない。
常時並行での確認を弱める。
節目ごとの実機UI確認に絞る。
直近の実機確認は無駄ではなかった。
UI品質を見るうえでは意味があった。
自動テストでは拾いにくい違和感を拾う効果もある。
ただし、常時動かすと効率が悪い。
AIツールの消費も増える。
ドキュメント作成に流れやすい。
報告の粒度が弱いと開発側が修正しづらい。
まだUIが荒い段階では、同じような指摘が大量に出る。
だから、今は開発用PCに集中する。
開発用PCで作る。
節目で既存端末が見る。
既存端末が重要度付きで指摘する。
開発用PCで直す。
この流れに整えて、品質を引き上げていきたい。
2台体制は、常時フル稼働させることが正解ではない。
必要なタイミングで、必要な役割に絞って使うことが重要である。
