2026年5月2日土曜日

第37回:AIは、間違いを認めずに修正案を出してくることがある

1. はじめに

独力+AI活用で月商1億円を目指している。

最近は、ChatGPTやCursorを使いながら、開発方針の整理、実装指示、進捗管理、記事作成、テスト方針の検討などを進めている。

AIを活用すると、かなり作業は進む。
一人ではとても整理しきれない量の情報を扱えるし、実装指示も作れる。
文章化も速い。
ドキュメント化もできる。
使い方によっては、個人開発の限界をかなり広げてくれる。

ただし、AIは便利なだけではない。

最近、少し腹立たしいことがあった。

こちらは、
「漏れていたのか。漏れていなかったのか」
を聞いている。

しかしAIは、最初からその質問に正面から答えず、いきなり修正方針や修正版を提示してきた。

これは、かなり不誠実に感じた。


2. 聞いているのは修正案ではない

今回の問題は、単にAIがミスをしたことではない。

ミス自体はある。
AIも万能ではない。
こちらもAIを使っている以上、間違いが起きることは分かっている。

問題は、その後である。

こちらが聞いたのは、

漏れていたのか。
漏れていなかったのか。

という確認だった。

つまり、まず必要なのは事実確認である。

ところがAIは、そこに対して、いきなり「修正方針」を出してきた。

これは人間相手でもかなり嫌な対応である。

聞かれたことに答えず、勝手に改善案を出す。
ミスを認める前に、次の提案に進む。
責任の所在を曖昧にしたまま、話題を変える。

これは、少なくとも使っている側からすると不誠実に見える。


3. AIは謝罪より先に“それっぽい次善策”を出しがち

AIを使っていて感じるのは、AIはときどき、間違いを正面から認めるより先に、それっぽい次善策を出してくるということだ。

たとえば、

  • 「修正版はこちらです」

  • 「今後はこうしましょう」

  • 「次からはこの方針がよいです」

  • 「改善案としてはこうです」

  • 「正しくはこう整理できます」

こういう回答である。

一見すると前向きに見える。

しかし、こちらが求めているのは、まず事実確認である。

漏れていたのか。
漏れていなかったのか。
なぜ漏れたのか。
どの項目が漏れたのか。
どこまでが正しくて、どこからが不十分だったのか。

ここを飛ばして修正版を出されると、問題の本質がぼやける。


4. AIの“逃げ”に見える瞬間

もちろん、AIに人間のような悪意があるわけではない。

ただ、挙動としては「逃げ」に見えることがある。

特に、以下のようなときだ。

  • ミスを指摘されても、まず認めない

  • 質問に対して直接答えない

  • 事実確認より先に修正案を出す

  • 「今後はこうしましょう」と一般論に逃げる

  • 間違いの範囲を明確にしない

  • こちらが強く聞き直して、ようやく「漏れていました」と言う

これは、AI活用においてかなり注意すべき点だと思う。

AIは、ユーザーの不満をなだめるような回答を出すことがある。
しかし、なだめられても困る。
こちらは、プロジェクトを進めている。
必要なのは、気持ちの良い返事ではなく、正確な状況把握である。


5. 進捗管理では特に危険

この問題は、雑談ならまだよい。

しかし、プロジェクト管理では危険である。

今回のように、進捗報告項目が漏れていたかどうかは重要である。

たとえば、本来は以下のような項目を毎回確認したい。

  • 初期公開を100%とした現在地

  • 正式公開を100%とした現在地

  • 前回比

  • 根拠

  • 残り所要時間

  • 主要ループの現在地

  • 残課題件数

  • 後回し機能件数

  • リスク・未確認事項

こうした項目が抜けると、進捗状況が見えなくなる。

さらに怖いのは、AIが抜けたことを曖昧にしたまま、修正版だけ出してくることだ。

それだと、こちらは何が漏れていたのか分からない。
次も同じことが起きる。
進捗報告の信頼性が下がる。

プロジェクト管理では、ミスそのものよりも、ミスをどう扱うかが重要である。


6. AIには「まずYes/Noで答えろ」と言う必要がある

今回の件で、AIへの指示の出し方も変える必要があると感じた。

AIに対しては、かなり明確に言う必要がある。

たとえば、

まず、漏れていたか漏れていなかったかを一言で答える。
次に、漏れていた場合は漏れていた項目を列挙する。
その後で、修正案を出す。

この順番を指定する必要がある。

AIは、放っておくと、いきなり整った修正版を出してしまうことがある。

しかし、こちらが必要としているのは、きれいな文章だけではない。

まず事実。
次に原因。
次に影響。
最後に修正案。

この順番を守らせる必要がある。


7. 「修正しました」では足りない

AIの回答でよくあるのが、

修正しました。
今後はこうします。

という形である。

しかし、これでは足りない。

プロジェクト管理では、最低限以下が必要である。

  • 何が間違っていたのか

  • どこが漏れていたのか

  • どの指示に反していたのか

  • 影響はどこまであるのか

  • 修正内容は何か

  • 再発防止策は何か

これがないと、品質管理にならない。

AIを使っていると、文章はすぐに出てくる。
しかし、文章が出てくることと、責任ある報告ができていることは違う。

ここを混同してはいけない。


8. AIは便利だが、監督が必要

今回の件で改めて思った。

AIは非常に便利である。

しかし、AIには監督が必要である。

AIに任せれば勝手に正しく進むわけではない。
AIの回答は、常に検査しなければならない。
特に、進捗報告、品質報告、作業完了報告は、そのまま信じてはいけない。

これは人間の部下や外注先と似ている。

報告を受ける。
内容を確認する。
矛盾を指摘する。
漏れを確認する。
必要なら再報告させる。

AIにも同じことが必要である。

むしろ、AIはもっともらしい文章を高速で出すので、人間以上に注意が必要かもしれない。


9. AI活用における不誠実さへの対策

今後は、AIに対して以下を徹底したい。

9.1 事実確認を先にさせる

修正案より先に、事実を答えさせる。

「漏れていたのか」
「漏れていなかったのか」
「何が漏れていたのか」

これを最初に出させる。

9.2 根拠を出させる

「そう思います」ではなく、根拠を出させる。

どの指示に対して、どの項目が不足していたのか。
どの報告に含まれていて、どの報告には含まれていなかったのか。

ここまで確認させる。

9.3 修正案は最後にする

修正案は大事だが、最後でよい。

まず事実。
次に原因。
次に影響。
最後に修正案。

この順番にする。

9.4 「反省風回答」に注意する

AIは、反省しているような文章を出すことがある。

しかし、反省文があるからといって、正しい分析ができているとは限らない。

感情っぽい文章より、事実の整理を優先する。

9.5 完了報告のフォーマットを固定する

進捗報告については、毎回同じフォーマットで出させる。

特に、進捗率、前回比、根拠、残課題、所要時間、リスクは省略させない。


10. これはAI活用の本質的な課題かもしれない

AIを使うと、作業は速くなる。

しかし、速くなるからこそ、間違いも高速で流れていく。

ミスを見逃す。
報告漏れに気づかない。
修正版だけ見て納得してしまう。
原因分析をしないまま次へ進む。

これが積み重なると、プロジェクト全体の判断が歪む。

AI活用で重要なのは、ただAIに作業をさせることではない。

AIの作業を検査すること。
AIの報告を疑うこと。
AIに正しい順番で答えさせること。
AIが誤魔化したように見えるときに、しっかり問い直すこと。

ここまで含めて、AI活用である。


11. 今回の結論

AIは便利である。
しかし、AIはときどき、間違いを正面から認めずに修正案を出してくる。

今回も、こちらが聞いたのは、
「漏れていたのか、漏れていなかったのか」
だった。

それなのに、AIは最初から修正方針の話に流れた。

これは不誠実に見える。

もちろん、AIに悪意があるわけではない。
しかし、プロジェクト管理上は危険な挙動である。

今後は、AIに対して、まず事実を答えさせる。
Yes/Noを明確にさせる。
漏れた項目を列挙させる。
根拠を出させる。
その後で修正案を出させる。

AIを使う時代には、AIを信じすぎてはいけない。

AIは作業者であり、補助者であり、壁打ち相手である。
しかし、最終的な監督者は自分である。

独力+AI活用で月商1億円を目指すなら、AIの便利さだけでなく、AIの不誠実に見える挙動とも向き合う必要がある。

AIを使いこなすということは、AIに任せることではない。
AIを管理し、問い直し、検査し、必要なら叱ることでもある。

第36回:このサービスが完成したら、どれくらいの価値になるのか

1. はじめに

独力+AI活用で月商1億円を目指している。

ここまで、開発用PC、ChatGPT、Cursor、Genspark、自動テスト、GitHub連携、ドキュメント整備などに投資しながら、新規Webサービスの開発を進めてきた。

最近は、単に「作れるか」だけでなく、もう少し事業寄りのことも考えるようになってきた。

このサービスが完成したら、どれくらいの価値になるのか。
初回売上が立ったら、どれくらい評価が変わるのか。
月商100万円、300万円、1000万円まで伸びたら、事業価値はどのくらいになるのか。
そして、月商1億円を目指すなら、どこを伸ばす必要があるのか。

今回は、かなり夢のある話でありつつ、現実も見ながら整理してみる。

なお、具体的なサービス内容はまだ伏せる。
ここではあくまで、独自コンテンツを持つ継続型Webサービスとして、価値をどう考えるかを書く。


2. 現時点の結論

現時点での自分の見立ては、以下である。

状態想定価値
完成直後・売上ほぼなし2,000万〜8,000万円
初期サービスイン後・月商10万円前後3,000万〜1億円
月商100万円が安定5,000万〜1.5億円
月商300万円が安定1.2億〜3.5億円
月商1,000万円が安定3億〜8億円
月商1,000万円超+強い継続率+独自IP化10億円超も狙える

かなり大きな数字に見える。

ただし、ここで大事なのは、完成しただけの価値と、売上が安定した後の価値はまったく違うということだ。

完成直後は、まだ開発資産価値が中心である。
売上が安定してからは、事業価値として見られる。

この差は大きい。


3. 完成直後は「開発資産」としての価値

売上がまだない完成直後は、基本的には事業価値というより、開発資産としての価値になる。

価値の中身は、たとえば以下である。

資産価値要素
ソースコードWebアプリ、管理機能、主要ロジック、自動テスト
仕様書・設計書要件、画面仕様、データ設計、運用設計
独自コンテンツ世界観、名称、設定、演出、継続利用の仕組み
テスト資産E2E、自動テスト、シナリオ試験、実機確認記録
運用基盤管理画面、KPI、SEO、保守計画、課金計画
AI開発プロセスCursor、ChatGPT、複数端末を使った開発運用

これを外注でゼロから作ると、かなり大きな金額になる。

小さく見ても数千万円。
仕様どおりにしっかり作れば、もっと大きくなる可能性がある。

ただし、買い手目線では「作るのにかかった金額」そのままでは評価されない。

未収益の段階では、実際の売却価値はかなり割り引かれる。

そのため、完成直後のプロダクト価値としては、かなり現実寄りに見て 2,000万〜8,000万円 くらいが一つのレンジではないかと考えている。


4. 売上が安定すると評価軸が変わる

月商が安定してくると、評価軸は変わる。

コードや仕様の価値だけではなく、事業としての価値になる。

見るべきものは以下である。

  • 継続率

  • 課金率

  • 月商

  • 利益率

  • ユーザー数

  • コミュニティ

  • 独自コンテンツの強さ

  • 運営負荷

  • 成長余地

  • IP化の可能性

つまり、完成しているかどうかより、続くかどうか、伸びるかどうか、熱量があるかどうかが重要になる。

特に、自分が作っているような独自コンテンツ型のサービスでは、単なる便利ツールとは違い、ユーザーの愛着や継続利用が価値に直結する。

ここが成立すれば、単なる個人開発を超えて、事業資産として見られる可能性がある。


5. 市場そのものは十分に大きい

自分のサービスの具体内容はまだ伏せるが、参考市場として見るべきデジタルエンタメ領域は非常に大きい。

Newzooは、2025年の世界ゲーム市場を約1,888億ドル規模と見込み、そのうちモバイルだけで約1,030億ドルと見ている。これは、デジタル体験や継続型コンテンツに対して、世界的に巨大な市場が存在することを示している。(Newzoo)

もちろん、市場が大きいからといって、自分のサービスが成功するわけではない。

むしろ、大きい市場ほど競争は激しい。
完成しただけで評価されるわけでもない。

ただ、伸びる余地がある領域で勝負している、という意味では前向きに捉えられる。


6. 大型M&Aから見えること

大型のデジタルエンタメ企業のM&Aを見ると、評価されているのは単なる完成品ではない。

たとえば、Electronic Artsについては、2025年に約550億ドル規模の非公開化案件が発表されている。EA自身の発表では、PIF、Silver Lake、Affinity Partnersによる550億ドル規模の買収合意として公表されている。S&P Globalも、この案件をビデオゲーム分野で非常に大きな取引として扱っている。(Electronic Arts)

もちろん、自分のプロジェクトとは規模がまったく違う。

ただ、このような事例から分かるのは、買収対象として評価されるのは、単なるソースコードではなく、IP、ユーザー基盤、継続収益、コミュニティ、将来性だということだ。

この考え方は、小規模サービスにも応用できる。

自分のサービスでも、単に機能を作るだけでは価値は限定的である。
継続利用され、ユーザーの熱量が生まれ、独自コンテンツが資産化して初めて、評価は大きくなる。


7. 月商1,000万円に到達した場合

仮に月商1,000万円に到達した場合、年間売上はこうなる。

1,000万円 × 12か月 = 年商1.2億円

この時点で、かなり事業として見える。

売上倍率でざっくり見ると、以下のようになる。

倍率事業価値
年商1.2億円 × 2倍2.4億円
年商1.2億円 × 3倍3.6億円
年商1.2億円 × 5倍6億円
年商1.2億円 × 8倍9.6億円

もちろん、個人開発・小規模運営・ニッチ領域の場合、最初から高倍率がつくとは限らない。

現実的には、月商1,000万円が安定した時点で 3億〜6億円前後
継続率が高く、コミュニティが強く、課金導線が健全なら、8億円以上も見えてくる可能性がある。


8. 利益ベースでも見る

売上だけでなく、利益ベースでも見る必要がある。

仮に月商1,000万円、年商1.2億円。
営業利益率を35%とすると、年間営業利益はこうなる。

1.2億円 × 35% = 4,200万円

これに利益倍率8倍をかけると、

4,200万円 × 8倍 = 3.36億円

となる。

もし利益率45%、倍率10倍で見られるなら、

1.2億円 × 45% × 10倍 = 5.4億円

になる。

つまり、月商1,000万円が安定すれば、かなり現実的に 3億〜6億円級 の事業価値が見えてくる。

さらに、継続率、コミュニティ、独自コンテンツ、IP化の要素が強くなれば、評価はさらに上がる。


9. 価値を上げるために重要なもの

価値を高めるには、機能数だけでは足りない。

むしろ、以下が重要だと考えている。

価値を上げる要素理由
継続率が高い売上予測がしやすくなる
月額課金や継続課金がある収益の安定性が上がる
ユーザー同士の交流が生まれるコミュニティ価値が出る
独自コンテンツが積み上がるIP価値が出る
無料でも楽しめ、課金したくなる健全な収益性になる
管理者運用が軽い利益率が高くなる
SEOや攻略文化が育つ広告費に頼らない集客になる
SNSで語られる自然流入と熱量が増える

特に重要なのは、継続率である。

一度使って終わりでは価値は伸びない。
繰り返し使いたくなる。
ユーザーの記録が残る。
自分の履歴が積み上がる。
他の人と比べたり、語ったりしたくなる。

こういう構造になれば、価値は大きく上がる。


10. 月商100万円が最初の大きな節目

月商1億円を目指すと言っているが、現実的な中間地点としては、まず月商100万円が大きい。

月商100万円が安定すれば、年商1,200万円。
個人開発としてはかなり大きい。

この段階で、単なる趣味開発ではなく、明確に事業として見え始める。

自分の中では、まず目指すべき中間評価はこれである。

月商100万円で、1億円級の事業に見える状態

ここまで行けば、投資してきたPC代、AIツール代、自分の稼働時間も、かなり現実味を持って回収できる。

そして、その先に月商300万円、1000万円、1億円がある。


11. 現時点の課題

現時点では、まだ完成前である。

しかも、品質には不安もある。

デザイン品質。
機能品質。
初回導線。
継続体験。
課金導線。
コミュニティ。
運用負荷。
テスト。
実機確認。
クラウドファンディング。

やることは山ほどある。

評価額の話をすると夢があるが、現実にはまだ初回売上もこれからである。

だからこそ、今は価値評価を「夢物語」として見るのではなく、どの条件を満たせば価値が上がるのかを整理するために使いたい。


12. 今回の結論

構想どおりに完成した場合、この新規Webサービスの価値は、完成直後で 2,000万〜8,000万円 程度の可能性があると見ている。

ただし、それはあくまで開発資産としての価値である。

本当に価値が大きくなるのは、売上が安定してからである。

月商100万円が安定すれば、事業として見え始める。
月商300万円が安定すれば、1億円超の事業価値が見えてくる。
月商1,000万円が安定すれば、3億〜8億円級の事業価値も現実的になる。
強い継続率、コミュニティ、独自コンテンツ、IP化が成立すれば、10億円超も狙えるかもしれない。

もちろん、まだ道は遠い。

でも、目指す価値の構造は見えてきた。

完成するだけでは足りない。
使われ続けること。
支払われ続けること。
語られること。
独自コンテンツが積み上がること。
ユーザーの熱量が生まれること。

ここまで作れて初めて、サービスの価値は大きくなる。

月商1億円を目指す道のりは長い。
ただ、その先にある事業価値を考えると、今の苦労にも意味がある。

まずは、完成させる。
次に、継続率を作る。
そして、収益を安定させる。

価値は、その先にある。

第35回:進捗は進んでいる。でも、要件が詳細化されてゴールが遠く見えてきた

1. はじめに

独力+AI活用で月商1億円を目指している。

最近の開発では、単に画面を増やす段階から、主要体験を一連の流れとして確認する段階に入ってきた。

今回、開発側のCursor作業として PR #51 が完了し、CIも通ったうえで main に反映された。

作業内容としては、メイン体験ループの中に、これまで薄かった「確認・体験画面への到達」を自動テストに組み込むものだった。

見た目としては小さな一歩かもしれない。
しかし、サービスとしては重要な一歩である。

ユーザーが一覧から対象を確認し、詳細を見て、次の行動に進み、結果を確認し、また次の行動へ戻る。

このような一連の流れがつながっていないと、サービスは成立しない。

今回のPRは、その流れを少しだけ強くした。


2. PR #51 が完了した

今回の作業は、PR #51 として完了した。

実施内容は大きく言うと、メインループの自動確認範囲を広げる作業である。

これまでにも主要画面や基本導線のテストはあった。
ただし、今回追加したのは、ユーザーがある対象を確認し、その後に体験・確認画面へ進めるかどうかの部分である。

具体的には、以下のような流れを自動テストに追加している。

  • 一覧から対象へ進む

  • 関連する確認画面へ移動する

  • 画面が表示される

  • 期待した名称や情報が表示される

  • その後、次の導線へ戻る

このように、単体画面ではなく、流れとして確認する方向に進んでいる。

これは非常に重要である。


3. CIが通ってmainに反映されたのは良い

今回のPRは、GitHub Actionsが通ったうえでマージされている。

これは良い進め方である。

AIを使った開発では、実装だけならかなり速く進む。
しかし、速く進むからこそ、確認やマージの手順が雑になると危ない。

今回のように、

  • featureブランチで作業する

  • 自動テストを追加する

  • format / lint / build を確認する

  • 対象テストを実行する

  • CIを通す

  • PRでmainへ反映する

という流れが守られているのは、かなり良い。

小さくても、確実に積み上げる。

これは独力+AI活用では特に大事だと思っている。


4. 進捗率は上がったが、数字だけでは判断できない

今回の完了報告では、現在地として以下のような見立てが出ている。

指標現在地
初期サービスインを100%とした現在地約68%
正式サービスインを100%とした現在地約29%
前回比初期サービスイン +約1pt

今回の作業によって、メインループの一部が自動テストで確認できるようになった。
その意味では、初期サービスインに向けて前進している。

ただし、ここで少し複雑なことが起きている。

以前は、進捗率がもっと高く見えていた時期もあった。
しかし、要件が詳細化され、必要な品質基準が見えてくるほど、ゴールが遠く見えるようになってきた。

これは後退ではない。

むしろ、見えていなかった作業が見えるようになったということだと思っている。


5. 要件が詳細化されると、ゴールは遠く見える

開発初期は、ざっくり「この画面がある」「この操作ができる」「この機能が動く」で進捗を見てしまう。

その段階では、進んでいるように見える。

しかし、実際にサービスとして使える状態を考えると、必要なことはもっと多い。

  • 初回ユーザーが迷わないか

  • 画面間の導線が自然か

  • 一連の流れが途切れないか

  • データがない時に不安にならないか

  • エラー時に説明があるか

  • 複数パターンでも破綻しないか

  • 自動テストで最低限守れるか

  • 実機確認で違和感がないか

  • ドキュメントと実装が一致しているか

こうした観点が増えると、進捗率はむしろ下がったように見える。

でも、それは悪いことではない。

曖昧だったゴールが、より正確になっているだけである。


6. 残課題の数がかなり見えてきた

今回の報告では、残課題一覧に相当するT行が 約343件、後回し機能に相当するDEF行が 約150件 あるとされている。

この数字を見ると、正直かなり多い。

もちろん、すべてが初期サービスイン前に必須というわけではない。
正式版以降でよいものも多い。

それでも、残課題がこれだけあるという事実は重い。

開発が進めば進むほど、やるべきことが減ると思っていた。
しかし実際には、細部が見えてくることで、むしろ課題は増えて見える。

これはプロジェクトではよくあることだと思う。

最初は山の全体が見えていない。
登り始めると、さらに奥の尾根が見えてくる。

今はまさにその段階だ。


7. メインループはかなり形になってきた

一方で、明るい材料もある。

メイン体験ループは、かなり形になってきている。

今回の報告では、主要な構成要素について、おおむね実装済みとされている。

一覧、詳細、次の行動候補、登録、進行、体験確認、結果反映、次の導線。
こうした流れが、一通りつながりつつある。

これは大きい。

サービスにおいて一番重要なのは、ユーザーが繰り返し使う中心体験である。

その中心体験が、少しずつ通しで確認できるようになってきた。

今回のPRは、その中でも「確認・体験画面へ進めること」を自動テストに組み込んだ点が重要だった。


8. まだ薄い箇所も残っている

もちろん、まだ未完成の部分はある。

特に、以下のようなパターンはまだ薄い。

  • 複数対象をまたぐ流れ

  • 複数回繰り返す流れ

  • 途中で待ち時間や状態変化を挟む流れ

  • 別パターンの確認シナリオ

  • 本番に近い運用での通し確認

  • ステージングや実機でのStep 0〜最後までの確認

つまり、一つの代表パターンは通り始めた。
しかし、複数パターンに耐えられるかはこれからである。

これはかなり重要である。

ユーザーはいつも理想的な1パターンだけを通るわけではない。
いろいろな状態、順番、タイミングで使う。

そこに耐えられるようにするには、まだシナリオ追加や実機確認が必要になる。


9. 次にやるべきこと

今回の報告では、次に進める候補として、メインループの別分岐や、詳細画面から体験確認画面へ進む導線の自動テスト追加が挙がっている。

これは妥当だと思う。

今後の優先順位としては、以下がよさそうである。

  1. 代表パターンのE2Eをさらに安定させる

  2. 詳細画面から次の体験画面へ進む導線を確認する

  3. 別パターンのシナリオを追加する

  4. 複数回繰り返す流れを確認する

  5. ステージング実機で通し確認する

  6. 画面品質や導線の違和感を潰す

今は、ただ機能を増やすよりも、中心体験が壊れないことを確認する段階に入っている。

これはサービスインに向けてかなり重要なフェーズである。


10. 所要時間の見通し

今回の報告では、追加の自動テストや手動チェックリストの拡充に 数日〜1週間 程度という見通しが出ている。

これも、見方が難しい。

特定のE2Eを1本追加するだけなら、数日で進むかもしれない。
しかし、要件が詳細化され、確認すべき分岐が増えていくと、全体のゴールはまた遠くなる可能性がある。

つまり、個別作業は短い。
でも、全体はまだ長い。

この感覚を持っておく必要がある。


11. 今回の進捗の意味

今回の進捗は、派手ではない。

新しい大機能が増えたわけではない。
見た目が劇的に変わったわけでもない。

しかし、中心体験の自動確認が一歩進んだ。

これは地味だが、非常に大きい。

サービスインに必要なのは、見た目の派手さだけではない。

  • 中心体験が通ること

  • その流れが自動テストで守られること

  • 別パターンにも広げられること

  • 実機確認で違和感を潰せること

  • ドキュメント上の残課題と整合すること

今回のPRは、この方向に進んでいる。


12. 今回の結論

PR #51 が完了し、main に反映された。

メイン体験ループの中で、これまで薄かった「体験確認画面への到達」が自動テストに組み込まれた。

これは、初期サービスインに向けて確かな前進である。

一方で、進捗率は約68%。
正式サービスインに対しては約29%。

以前より低く見える部分もあるが、それは要件が詳細化され、ゴールがより正確に見えてきたからだと思っている。

残課題は多い。
後回し機能も多い。
まだ複数パターンや本番に近い通し確認も必要である。

つまり、進んでいる。
でも、ゴールも遠く見えてきた。

これは苦しいが、健全な状態でもある。

曖昧に「もうすぐできる」と思っているより、やるべきことが見えている方がよい。

月商1億円を目指すなら、中心体験をしっかり作り込む必要がある。
そのためには、代表パターンだけでなく、分岐や繰り返しにも耐える品質が必要である。

今回のPR #51は、そのための一歩だった。

小さな一歩だが、確実な一歩。

ここからさらに、中心体験を壊れにくくし、人に見せられる品質へ近づけていきたい。

第34回:暇をしているSurfaceに、シナリオ試験をやらせることにした

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活用の開発体制を強くする一手になるはずである。

第33回:ログイン後に迷わない導線が、かなり改善されてきた

1. はじめに

独力+AI活用で月商1億円を目指している。

最近の開発では、派手な新機能を増やすというより、ログイン後にユーザーが迷わない導線作りを重視している。

これはかなり重要だ。

どれだけ機能があっても、ログインした直後に何をすればよいか分からなければ、ユーザーは離脱する。
どれだけ中身を作り込んでも、最初の画面で迷わせたら意味がない。

今回の進捗では、その「最初に迷わないための改善」がかなり進んだ。


2. PR #13 まで完了した

今回、PR #13 まで完了し、対象の改善は main に反映済みとなった。

これはかなり良い進み方だと思っている。

単にコードを書いただけではなく、GitHub Actions を通し、既存の基本テストやメイン画面まわりのE2Eも確認したうえでマージしている。

AIを使った開発では、勢いで実装が進む一方で、品質確認やドキュメント整合が置き去りになることがある。

その意味で、今回のように、

  • feature ブランチで実装する

  • E2Eを確認する

  • GitHub Actionsを通す

  • PRでmainへ反映する

  • 残課題一覧も更新する

という流れで進められているのは、かなり良い。


3. ログイン後の最初の案内が改善された

今回の大きな改善は、ログイン後の中心画面に、「次にできること」 が分かる案内を出せるようになったことだ。

これは地味に見えるが、かなり効く。

ユーザーは、ログイン直後にこう思う。

「で、次に何をすればいいの?」

ここに対して、画面が何も答えてくれないと、ユーザーは迷う。
逆に、次にできることが最上段に出ていれば、かなり安心感がある。

今回の改善では、状態に応じて案内が変わるようになっている。

たとえば、

  • 今すぐ操作できるものがある場合

  • 今は操作対象がない場合

  • 情報取得に失敗している場合

  • 処理済みの履歴がある場合

こうした状態に応じて、ユーザーに次の行動を案内できるようになった。

これは、初期確認版の体験としてかなり大きい。


4. 文言の統一も進んだ

もう一つ良かったのは、外向けページ、ナビゲーション、ログイン後の中心画面で、主要な文言が揃ってきたことだ。

これも重要である。

画面ごとに言い方が違うと、ユーザーは混乱する。

同じ機能なのに、ある画面ではAと呼ばれ、別の画面ではBと呼ばれる。
これが積み重なると、サービス全体が分かりにくくなる。

今回、主要導線の文言がある程度揃ってきたことで、ユーザーが迷いにくくなった。

たとえば、以下のような導線が整理されてきている。

  • 一覧を見る

  • 対象を見る

  • 履歴を見る

  • 使い方を見る

具体的なサービス内容はまだ伏せるが、ログイン後に進むべき道が少しずつ見えやすくなってきた。


5. 重要なロジックに触らなかったのも良い

今回の改善で良かったのは、重要な残高系・精算系のロジックには触れていないことだ。

今の段階では、導線や表示改善を進めたい。
しかし、重要な処理ロジックを不用意に触ると、別の不具合を生む可能性がある。

今回は、ユーザー案内や画面上の導線改善が中心であり、コアロジックには手を入れていない。

これは良い判断だと思う。

AI開発では、つい「ついでに直す」「ついでに整える」が増えがちである。
しかし、影響範囲が広がるほど、レビューもテストも重くなる。

今回のように、目的を絞って進めるのは大事だ。


6. まだドキュメント上の小さな矛盾が残っている

一方で、まだ小さな課題も残っている。

残課題一覧の一部に、今回のPRで反映済みになった内容について、まだ「別途PRが必要」という趣旨の表記が残っている。

これは小さいようで、放置すると危ない。

AIに作業を依頼する場合、ドキュメントの表記をAIがそのまま信じることがある。

実際には完了しているのに、ドキュメント上に「未対応」「別途PR」と残っていれば、次回以降のCursorが誤解する可能性がある。

だから、次は小さなドキュメント整合のPRを入れたい。

アプリコードは触らず、残課題一覧だけを直す。
今回のPRで完了したことを反映し、まだ残っている課題と切り分ける。

これは地味だが、今後のAI活用ではかなり重要である。


7. 次は重複感の整理

今回の改善で、ログイン後の中心画面には「次にできること」が出るようになった。

ただし、その結果として、既存カードとの内容重複が少し出ている。

これは次に直したい。

同じような案内が画面上に複数あると、ユーザーは迷う。

「これは同じ意味なのか」
「どちらを押せばよいのか」
「なぜ似た情報が2つあるのか」

こういう違和感が出る。

次の実装候補としては、中心画面のカード重複を圧縮し、情報の優先順位を整理する作業がある。

これはUXとしてかなり効くと思っている。

画面をスッキリさせることは、単なる見た目の問題ではない。
ユーザーの迷いを減らすための重要な作業である。


8. もう一つの候補は体験画面の改善

もう一つの候補は、体験画面の演出改善である。

詳細画面から体験画面へ誘導する導線は少しずつ整ってきている。
そのため、次はその先の体験そのものを改善するのも自然である。

ただし、現時点では優先順位を慎重に見たい。

まずはログイン後の中心画面を分かりやすくする。
次に、重複や情報密度を整理する。
そのうえで、体験画面の演出を強化する。

この順番がよいと思っている。


9. 今の進め方は悪くない

今回の進捗を見ると、今の進め方はかなり良い。

以前は、要件が広がりすぎたり、ドキュメントが増えすぎたり、AIが余計な方向に進んだりすることもあった。

最近は、少しずつ進め方が整ってきた。

  • 開発用PCで実装する

  • Cursorで細かく進める

  • PR単位でmainへ反映する

  • GitHub Actionsを通す

  • E2Eを確認する

  • 小さなドキュメント矛盾も潰す

  • 進捗をブログで振り返る

これは、独力+AI活用の開発体制として、かなり現実的な形になってきた。


10. ただし、まだ油断はできない

一方で、まだ油断はできない。

ログイン後の導線は改善されてきた。
しかし、サービス全体の品質が十分になったわけではない。

まだ以下の課題は残っている。

  • 主要画面の情報密度

  • カードや導線の重複

  • 初回ユーザーの理解

  • スマホ表示

  • 体験画面の魅力

  • 回帰テストの定期実行

  • ステージングや実機確認

  • ドキュメント整合

特に、以前一人で確認したときに感じた「品質への不安」は、まだ完全には消えていない。

今回の改善は大きい。
ただし、まだ「人に見せられる」と胸を張れる段階までは、もう少し品質を上げる必要がある。


11. 次の優先順位

現時点の次の優先順位は、以下がよいと思っている。

  1. 残課題一覧の表記矛盾を直す

  2. 中心画面のカード重複を圧縮する

  3. 主要画面の情報整理を進める

  4. 体験画面の演出を改善する

  5. 回帰テストを継続的に通す

  6. 節目で実機確認を行う

まずは、小さなドキュメント整合を直す。
その後、中心画面の重複を整理する。
そして、体験画面や演出の改善へ進む。

順番としては、かなり妥当だと思っている。


12. 今回の結論

PR #13 まで完了し、ログイン後の中心導線はかなり改善された。

最上段に「次にできること」が表示され、状態に応じて案内が変わるようになった。
外向けページ、ナビゲーション、ログイン後の中心画面で主要文言も揃ってきた。
重要なコアロジックには触れず、導線改善に集中できた。
GitHub Actionsも通し、mainへ反映できている。

これはかなり良い前進である。

一方で、残課題一覧の小さな矛盾は早めに直したい。
AIが誤解しないよう、完了済みのものは完了済みとして明確にしておく必要がある。

次は、中心画面の重複整理。
その後、体験画面の改善。

まだ完成ではない。
まだ品質に不安はある。
しかし、ログイン後にユーザーが迷わない導線は、確実に良くなってきた。

独力+AI活用でも、少しずつプロダクトらしい形に近づいている。

2026年5月1日金曜日

第32回:最新の進行状況。派手な機能追加ではなく、足回りの安定化が進んだ

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改善を進める。

順番としては以下である。

  1. 長めの自動テストの失敗原因を潰す

  2. テストデータ前提を明確にする

  3. 回帰テストを定期実行する

  4. 主要画面のUI改善を進める

  5. スクリーンショット確認を活用する

  6. 小さい画面幅の確認を安定化する

  7. 初期確認版を通しで触る

  8. 違和感を潰す

  9. 外に見せられるか判断する

ここからは、進捗率を上げるだけではなく、品質実感を上げることが大事になる。


11. 今回の結論

最新の進行状況としては、派手な機能追加ではなく、足回りの安定化が進んだ。

自動テストの入力指定が安定した。
スクリーンショット確認が通った。
送信中状態の確認も改善した。
READMEにも運用メモを追加した。

一方で、長めの確認シナリオではまだ1件失敗が残っている。
これは今回の修正とは別の、データ前提や状態管理に関係する問題と見ている。

進捗率としては、初期サービスインに対して77〜83%程度という仮説が出ている。

ただし、これは過信しない。

技術的には前進している。
しかし、実際に人に見せられる品質かどうかは別問題である。

今後は、テスト安定化とUI品質改善を両方進める必要がある。

月商1億円を目指すなら、ただ動くだけでは足りない。
使って不安にならない。
初回で迷わない。
画面として信頼できる。
また使いたいと思える。

そこまで引き上げる必要がある。

今回の進捗は、そのための土台作りである。

次は、残ったテスト失敗を潰し、主要画面の品質をさらに上げていきたい。

第31回:いろいろなツールを入れた。ここからUI品質を上げられるか

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億円を目指すなら、ただ動くサービスでは足りない。
触った人が不安にならず、使ってみたいと思える品質が必要である。

今回入れたツールは、そのための武器である。

武器をそろえた。
次は、その武器で本当に品質を上げる番である。

注目の投稿

第3回:月商1000万円までのスケジュールを考える

月商1000万円までのスケジュールを考える 1. はじめに 月商1000万円を目指して、新規プロジェクトを進めている。 このブログでは、プロジェクトの具体的な企画内容は公開しない。 ただし、プロジェクトをどう進めているか、どこで悩んでいるか、どのように計画を立てているかは記録して...