品質の観点

コードを読まずに品質を確かめる手段は、実際に操作することと、機械に確かめてもらうことの2つです。ここに挙げる言葉は後者の仕組みの名前で、実装はClaudeに任せられます。捨てる予定の試作なら何も入れない判断も正しく、長く運用する製品なら早く入れるほど効きます。

テスト

コードが期待通り動くかを、別のコードが自動で確かめる仕組みです。テストは動作確認ではありません。動作確認は「今この瞬間、目の前で動くか」を人が一度見る行為で、テストは「これからも動き続けるか」を機械が何度でも確かめられる形にした資産です。一度書いて、後述のCIと組み合わせれば、修正のたびに全項目を確かめ直せます。

範囲の狭い順に3層あります。単体テストは関数や部品ひとつの確認、結合テストは部品同士やデータベースとのつながりの確認、E2Eテストは「フォームに入力して送信すると完了画面が出る」のような利用者の操作の再現です。どの層をどれだけ書くかは、Claudeに相談しながら決められます。

テストが保証するのは書かれた確認項目に通ったことだけですが、コードを読めない人にとっては、それが壊れていないことを知る数少ない手段になります。書くのも直すのもClaudeがやってくれるので、修正が続く製品なら頼んでおいて損はありません。

主要な操作のE2Eテストを用意して。今後は修正のたびに実行して
単体・結合・E2Eのどの層に何を書くべきか、この製品の場合で提案して

テストしやすい設計

同じ機能でも、部品が分かれていて計算と外部への作用が分離されたコードはテストを書きやすく、すべてが絡み合ったコードは書きにくくなります。つまりテストのしやすさは、設計の良さの実用的な指標です。この観点は、口に出してお願いするだけで価値があります。

このコードはテストしやすい設計になってる?なっていない箇所は設計から直して

mock

開発やテストの間、本物の外部サービスを偽物へ置き換えることをmockと呼びます。本物を使うと、開発中の操作で本当にメールが送られ、本当に課金され、本番のデータが汚れます。外部サービスやお金が絡む機能の開発では、mockを前提にします（環境の分離）。

開発中はメール送信と決済をmockにして、実際には実行されないようにして

CI

pushやPull Requestのたびに、lint、型チェック、テストなどの検査を自動で実行する仕組みです。人が確認を忘れても機械が止めるため、確認の質が個人の注意力に依存しなくなります。

Pull Requestのたびにテストと型チェックが自動で走るようにして

別のAIによるレビュー

書いたコードを、書いた本人以外の目で確認することです。実装したAIに同じ会話の中で「問題ない?」と聞くと、実装した時の前提ごと肯定されやすくなります。別のAI、または実装の文脈を持たない別のセッションにレビューをお願いすると、前提を共有していないぶん思い込みを突けます。人間同士のダブルチェックと同じ構図で、弊社では重要な変更を別のAIにレビューしてもらっています。

この変更を、実装の経緯を知らない別のAIの視点でレビューして。前提から疑って

レンズを変えて疑いを晴らす

「これで本当にいいのか」という疑いは、同じ視点で何度見直しても晴れません。晴らすには、見る角度を変えます。開発の知識がない読者、初めて使う利用者、攻撃者、事実確認、というようにレンズを決めてレビューを依頼すると、同じ成果物から毎回別の問題が見つかります。レンズはAIと話しながら増やしていけます。

この文書を、開発の知識がない読者のレンズでレビューして
今度は、書いてある事実が本当に正しいか疑うレンズで確認して

ただし、どのレンズでも見つからない問題があります。開発の外にある事情、つまり顧客との経緯、社内の背景、市場の空気は、コードにも会話にも残っていない限りAIには知りようがありません。最後に人間のセンスで見る工程は、この外部の文脈を当てるためにあります。レビューをAIに広く任せるほど、人間の確認は「文脈と照らして違和感がないか」へ集中できます。

監視とエラー通知

公開後の問題は、自分の画面の前では起きません。エラーが起きたら通知が届く仕組みを入れると、利用者からの報告より先に気づけます。「壊れてたよ」と言われてから知る製品と、言われる前に直っている製品の差はここで生まれます。

本番でエラーが起きたら通知される仕組みを入れて

性能

表示の遅さは離脱に直結します。原因は画像の大きさや読み込みの順序から、サーバー処理やデータベースまで様々ですが、計測して特定するところからClaudeに任せられます。公開前に一度、計測だけ頼んでおきます。

主要ページの表示速度を計測して、遅い原因があれば直して