1. はじめに
独力＋AI活用で月商1億円を目指している。
ここ最近は、目に見える新機能をどんどん追加するというより、サービス公開に向けた足回りの安定化を進めている。
今回の作業も、派手な画面改善ではない。
主な内容は、自動テストの安定化、スクリーンショット確認の改善、入力処理の堅牢化、READMEへの運用メモ追加である。
地味ではある。
ただし、こういう作業を避けたまま先に進むと、後でかなり苦しくなる。
今回の進捗は、見た目の華やかさは少ないが、サービスインに向けた土台としては意味がある。
2. 今回はアプリ本体の大きなUI変更ではない
まず整理しておくと、今回はアプリ本体の大きなUI変更は行っていない。
今回の主な作業は以下である。
自動テストの入力安定化
画面スクリーンショット確認の安定化
送信中状態の撮影まわりの調整
テスト用Cookieの扱い改善
READMEへの運用メモ追記
一部テスト失敗の原因切り分け
つまり、ユーザーから見える新しい機能が増えたわけではない。
ただ、自動テストやスクリーンショット確認の安定性が上がると、今後のUI改善や品質改善を進めやすくなる。
開発が進むほど、毎回すべてを手で確認するのは難しくなる。
だから、自動で確認できる部分を増やし、テストが壊れにくい状態にすることは重要である。
3. 入力欄の指定を安定させた
今回の大きな改善の一つは、自動テストでの入力欄指定を安定させたことだ。
これまで一部の自動テストでは、画面上のラベル文言に依存して入力欄を探していた。
もちろん、それでも動く場合はある。
ただ、画面内に似たような文言が増えたり、説明文が追加されたりすると、テストが意図しない要素を拾う可能性がある。
そこで、既存のテスト用IDを使って、入力欄をより明確に指定するようにした。
これは地味だが、かなり重要である。
画面の文言は今後も変わる。
デザイン改善でも変わる。
説明文の追加でも変わる。
そのたびに自動テストが壊れると、開発速度が落ちる。
テスト用IDで対象を明確にすることで、UI文言の変更に対して自動テストが少し強くなる。
4. スクリーンショット確認が安定してきた
今回、UI品質確認用のスクリーンショットテストも改善された。
主要なスクリーンショット確認は、比較モードで成功した。
これはかなり良い兆候である。
最近の課題は、単に機能が動くかではなく、画面品質をどう上げるかである。
見づらい。
情報の優先順位が悪い。
初回ユーザーが迷う。
操作後の反応が分かりにくい。
こうした問題は、自動テストだけでは完全には拾えない。
しかし、スクリーンショットを残しておくことで、UIの変化を追いやすくなる。
今後、画面を改善するたびに、
「どこが良くなったのか」
「どこが崩れたのか」
「小さい画面で破綻していないか」
を確認しやすくなる。
これは、品質改善の武器になる。
5. 送信中状態の確認も前進した
今回、送信中状態の確認も改善した。
フォーム送信や処理中の画面状態は、ユーザー体験にとってかなり重要である。
ボタンを押したのに何も反応がないように見えると、ユーザーは不安になる。
もう一度押してしまうかもしれない。
画面が止まったと思って離脱するかもしれない。
だから、処理中の状態がちゃんと見えることは大事である。
今回、その送信中状態をスクリーンショットで捉えやすくするための調整が行われた。
開発用の環境差を吸収するため、複数のローカルホスト表現に対応するようにしたことも、地味だが重要である。
こういう細かい安定化が、後々効いてくる。
6. 成功したテストと、まだ残った失敗
今回の作業では、複数の自動テストが成功した。
ログイン系、主要画面のスクリーンショット確認、次操作の導線確認などは通っている。
一方で、長めの一連の確認シナリオでは、まだ1件失敗が残っている。
ただし、この失敗は今回の修正内容が原因ではなさそうである。
失敗しているのは、ある操作を2回行った後に想定されるURL遷移の確認である。
実際には想定したURLにならず、元の画面に残っていた。
原因としては、テストデータ、状態の残り方、上限判定、前回実行の影響など、データ前提の不一致が疑われている。
つまり、今回の入力安定化やスクリーンショット改善とは別の問題である。
ここは次に潰すべき課題である。
7. 進捗率は上がったが、過信はしない
今回の完了報告では、初期サービスインに対する現在地は 77〜83%程度 という仮説になっている。
正式サービスインに対しては 44〜54%程度 という見立てである。
この数字だけを見ると、かなり進んだように見える。
ただし、ここは慎重に見たい。
今回進んだのは、主にテスト基盤や確認の安定化である。
これは重要だが、ユーザーが実際に触ったときの体験品質が一気に改善したわけではない。
以前、自分で初期確認版を触ったときには、デザイン品質や機能品質に不安があった。
つまり、開発側の進捗率と、ユーザー体験としての完成度は分けて考える必要がある。
今回の77〜83%という数字は、
「サービスインに向けた技術的な足場が少し固まった」
という意味では参考になる。
しかし、
「もうすぐ人に見せても問題ない」
という意味ではない。
ここは過信しない。
8. 残っている主要課題
現時点で残っている主要課題は、まだ多い。
特に重要なのは以下である。
長めの一連の自動テストで残っている失敗を潰す
テストデータ前提を明確にする
回帰テストを定期的に回す
主要画面のUI改善を進める
小さい画面幅での確認を安定させる
初期確認版として通しで触ったときの違和感を減らす
実機確認は節目で使う
新機能追加より品質改善を優先する
特に、長めの自動テストで残っている失敗は放置できない。
短いテストが通っても、長い導線で崩れるなら、実際の利用時に問題が出る可能性がある。
ここは次回以降の重要課題である。
9. 残り所要時間の見立て
今回の報告では、初期サービスインまでの残り見通しとして、開発用PC単独なら 約1.5〜3.5人日、確認作業を並行できる場合は 約1〜2.5人日 という仮説が出ている。
かなり前向きな見積もりである。
ただ、自分としては少し割り引いて見ている。
理由は、まだUI品質や体験品質に不安があるからである。
技術的な残件だけを見ると、数日で進む可能性はある。
しかし、人に見せられる品質に引き上げるには、もう少し調整が必要になるかもしれない。
なので、見立てとしてはこう考えている。
技術的なサービスイン準備はかなり近づいている。
ただし、体験品質の引き上げには、まだ慎重に時間を使う必要がある。
ここを混同しないようにしたい。
10. 今後の優先順位
次にやるべきことは、かなり明確になっている。
まず、残っている長めのテスト失敗を安定化する。
次に、データ前提を整理する。
そのうえで、主要画面のUI改善を進める。
順番としては以下である。
長めの自動テストの失敗原因を潰す
テストデータ前提を明確にする
回帰テストを定期実行する
主要画面のUI改善を進める
スクリーンショット確認を活用する
小さい画面幅の確認を安定化する
初期確認版を通しで触る
違和感を潰す
外に見せられるか判断する
ここからは、進捗率を上げるだけではなく、品質実感を上げることが大事になる。
11. 今回の結論
最新の進行状況としては、派手な機能追加ではなく、足回りの安定化が進んだ。
自動テストの入力指定が安定した。
スクリーンショット確認が通った。
送信中状態の確認も改善した。
READMEにも運用メモを追加した。
一方で、長めの確認シナリオではまだ1件失敗が残っている。
これは今回の修正とは別の、データ前提や状態管理に関係する問題と見ている。
進捗率としては、初期サービスインに対して77〜83%程度という仮説が出ている。
ただし、これは過信しない。
技術的には前進している。
しかし、実際に人に見せられる品質かどうかは別問題である。
今後は、テスト安定化とUI品質改善を両方進める必要がある。
月商1億円を目指すなら、ただ動くだけでは足りない。
使って不安にならない。
初回で迷わない。
画面として信頼できる。
また使いたいと思える。
そこまで引き上げる必要がある。
今回の進捗は、そのための土台作りである。
次は、残ったテスト失敗を潰し、主要画面の品質をさらに上げていきたい。
0 件のコメント:
コメントを投稿