1. はじめに
独力＋AI活用で月商1億円を目指している。
ここ最近、開発環境にいくつかのツールや仕組みを追加した。
これまでも、ChatGPT、Cursor、GitHub、自動テスト、新PCなどを使いながら開発を進めてきた。
しかし、実際に初期確認版を触ってみると、デザイン品質や機能品質にかなり不安が出てきた。
画面が動くことと、使いたいと思えることは違う。
ビルドが通ることと、人に見せられることも違う。
自動テストが通ることと、サービスとして魅力があることも違う。
そこで、今後の品質改善に向けて、UIまわりや自動テストまわりの仕組みを少し強化した。
今回は、その期待について書く。
2. UI品質を上げるための土台を入れた
今回大きいのは、UI品質を上げるための土台を入れ始めたことだ。
具体的には、Tailwind系のスタイリング基盤や、再利用できるUIコンポーネントの仕組みを段階的に入れた。
ただし、既存画面を一気に全部作り直すわけではない。
既存のCSSや画面構成をすべて捨てるのではなく、重要なセクションから少しずつ適用していく方針にしている。
これはかなり大事だと思っている。
一気に全面置換すると、見た目は変わるかもしれないが、既存機能やテストが壊れるリスクも高い。
特に今は、初期確認版の品質を上げたい段階であり、大規模な作り直しで迷子になるのは避けたい。
だから、今の方針はこうである。
既存の構造を活かしながら、重要な部分からUI品質を段階的に上げる。
このやり方なら、リスクを抑えながら、見た目と使いやすさを改善できる可能性がある。
3. 共通部品を入れる意味
今回、カード、アラート、バッジのような共通UI部品も入れ始めた。
これは単なる見た目の話ではない。
共通部品を使えるようになると、画面ごとの品質差を減らしやすくなる。
今までは、画面ごとに見た目や余白、色、強調の仕方がバラバラになりやすかった。
その結果、サービス全体として統一感が弱くなる。
共通部品を使えば、
重要情報の見せ方
注意メッセージの出し方
状態表示の見せ方
カード型レイアウト
ボタンやラベルの一貫性
をそろえやすくなる。
これは、初期確認版の品質改善にかなり効くはずである。
特に今は、サービス内容そのものよりも、まず「画面として不安にならない状態」にすることが重要だ。
共通UI部品は、そのための土台になる。
4. スクリーンショット確認の仕組みも強化した
もう一つ期待しているのが、スクリーンショット確認の強化である。
これまでも自動テストは使っていた。
ただし、自動テストは基本的に「動くか」「表示されるか」「エラーにならないか」を確認するのが得意である。
一方で、UI品質の問題はそれだけでは拾いきれない。
たとえば、
画面が崩れていないか
余白が不自然ではないか
重要な導線が見えているか
ローディング状態が表示されるか
小さい画面幅で破綻していないか
こうした部分は、スクリーンショットを残して確認できると強い。
今回、主要状態のスクリーンショットを自動で取る仕組みも整え始めた。
これはかなり期待している。
今後、画面改善を重ねていく中で、
「前より良くなったのか」
「別の場所が崩れていないか」
「ローディングや空データ状態がちゃんと見えているか」
を確認しやすくなる。
UI改善は感覚に寄りがちだが、スクリーンショットがあれば比較しやすい。
5. ローディング表示の問題も一つ潰せた
今回の作業では、ローディング表示の問題も一つ切り分けた。
単純に「処理が速すぎて撮影できない」のではなく、仕組み上、期待したローディング状態がDOMに出ていないことが原因だった。
そこで、該当部分をクライアント側の処理に切り出し、送信中の状態がきちんと画面に出るようにした。
これは地味だが重要である。
ユーザーにとって、処理中かどうか分からない画面は不安である。
ボタンを押したのに反応がないように見えると、二重クリックや離脱にもつながる。
ローディング表示は、小さなUIに見える。
しかし、実際の使いやすさにはかなり効く。
今回そこを安定させられたのは、今後の品質改善にとって良い前進だと思っている。
6. ただし、ツールを入れれば品質が上がるわけではない
ここで勘違いしてはいけない。
Tailwindを入れた。
共通UI部品を入れた。
スクリーンショットテストを入れた。
ローディング表示を直した。
だからといって、自動的にサービス品質が上がるわけではない。
ツールはあくまで道具である。
問題は、その道具を使って何を直すかである。
今の課題は明確である。
主要画面が見づらい
初回導線が弱い
操作後の反応が分かりづらい
空データやエラー状態の見せ方が弱い
小さい画面幅での確認が不足している
人に見せるにはまだ不安がある
これらを直すために、ツールを使う。
ツール導入そのものを成果にしてはいけない。
7. まだ未解決の問題もある
今回の作業で、すべてが解決したわけではない。
むしろ、まだ課題は多い。
特に、モバイル幅のスクリーンショット確認では、ローカルDBまわりの問題で途中停止した。
これはUI崩れではなく、検証環境やDB前提の問題と見ている。
つまり、UI確認を安定させるには、画面だけでなく、テストデータやローカル環境も整える必要がある。
また、全体の回帰テストも、まだ十分に回し切れていない部分がある。
今後やるべきことは多い。
ローカルDBを安定させる
スクリーンショット確認を最後まで通す
主要導線の回帰テストを再実行する
重要画面に段階的にUI部品を適用する
小さい画面幅の見え方を確認する
一人で通して触ったときの違和感を潰す
ここからが本番である。
8. 今後期待していること
今回入れたツールや仕組みに期待していることは、大きく3つある。
8.1 UI改善の速度を上げること
共通UI部品やTailwind系の仕組みにより、画面改善の速度を上げたい。
毎回ゼロからCSSを書くのではなく、ある程度そろった部品で改善できるようにしたい。
これにより、主要画面を段階的に底上げできるはずである。
8.2 品質確認の再現性を上げること
スクリーンショット確認や自動テストにより、品質確認の再現性を上げたい。
人間の感覚だけでは、前回と今回で判断がぶれる。
スクリーンショットが残れば、比較しやすくなる。
これは、今後のUI改善でかなり重要になる。
8.3 AIへの指示を具体化しやすくすること
UI部品やスクリーンショットが整うと、Cursorへの指示も具体化しやすくなる。
「いい感じにして」ではなく、
このカードを共通部品で整理する
この状態表示をアラートに寄せる
このラベルをバッジ表現にする
この画面のスクリーンショット差分を確認する
のように指示できる。
AIに仕事をさせるには、指示の具体性が重要である。
今回のツール導入は、その意味でも効果があるはずだ。
9. 期待と同時に不安もある
もちろん、不安もある。
ツールが増えると、管理するものも増える。
依存関係が増える。
設定ファイルが増える。
テストが増える。
スクリーンショットも増える。
修正時に考えることも増える。
これをうまく運用できなければ、逆に開発が重くなる可能性もある。
また、見た目だけを整えても、体験が良くなるとは限らない。
本当に大事なのは、ユーザーが迷わず使えること。
操作して不安にならないこと。
また触りたいと思えること。
UI部品や自動テストは、そのための手段でしかない。
ここは忘れないようにしたい。
10. 現時点の進捗感
今回の作業で、初期公開に向けた現在地は少し前進したと思っている。
ただし、まだ「公開できる品質」ではない。
開発側の見立てでは進捗率が上がったように見えることもある。
しかし、実際に触ったときの品質感はまだ不足している。
だから、進捗率をそのまま信用しすぎない。
見るべきなのは、
「何%進んだか」
だけではなく、
「人に見せられる品質に近づいたか」
である。
今回のツール導入は、その品質改善に向けた土台作りである。
11. 今回の結論
いろいろなツールや仕組みを入れた。
UI改善のための土台。
共通UI部品。
スクリーンショット確認。
ローディング状態の安定化。
テスト補助。
設定まわりの整備。
これらによって、今後の品質改善が進みやすくなることを期待している。
ただし、ツールを入れただけでは何も完成しない。
ここからが重要である。
主要画面を直す。
初回導線を直す。
小さい画面幅を確認する。
空データやエラー表示を整える。
人に見せられる品質まで引き上げる。
月商1億円を目指すなら、ただ動くサービスでは足りない。
触った人が不安にならず、使ってみたいと思える品質が必要である。
今回入れたツールは、そのための武器である。
武器をそろえた。
次は、その武器で本当に品質を上げる番である。
0 件のコメント:
コメントを投稿