システムを本番に出して大丈夫かを判断する力のゴールは、「全部を等しく心配すること」ではなく、「自分のコードが最後の砦になる場所を見つけて、そこに守りを集中すること」です。この記事では、なぜインフラは怖くなくて決済やデータ変更が怖いのかを言語化して、レビューしてくれる人がいない個人開発でもコードに自信を持つ方法を解説します。「本番に出して大丈夫か毎回不安」という個人開発者向けです。
これは「AI時代のエンジニアに必要な基礎スキル」シリーズの3本目です。1本目「コードの目利き」、2本目「設計の妥当性」に続いて、今回は「信頼性を判断する力」を掘り下げます。
信頼性は範囲が広すぎて動けない、をどうするか
信頼性って、動画や書籍で挙げられる範囲がめちゃくちゃ広いんですよね。テスト、セキュリティ、認証・認可、Docker、CI/CD、監視、運用…。全部大事なのはわかるけど、「じゃあ何から手をつければ？」でフリーズしがちです。
僕もそうでした。でも、自分の中の「怖い」という感覚を素直にたどってみたら、意外とシンプルな答えが見えてきたんですよね。
結論から言うと、範囲が広くて動けないのは、全部を同じ重さで守ろうとするからです。実際には守るべき場所には濃淡があって、そこを見分けられれば一気に動けるようになります。
なぜインフラは怖くなくて、決済は怖いのか
僕の場合、インフラはそこまで怖くないんです。でも決済まわりと、大きなデータ変更（一括UPDATEやマイグレーション）は本気で怖い。同じ「本番」なのに、この差はなんなんだろう、と考えてみました。
軸1：戻せるか、戻せないか
まず一つ目の軸がこれかなと。
- インフラ：壊れても戻せる。サーバーが落ちても再起動できるし、デプロイをミスってもロールバックできる。やり直しがきくから、そこまで怖くない。
- 決済：現実世界のお金が動く。二重に引き落とした、課金したのにサービスが有効にならない。なかったことにできない。
- 大きなデータ変更：WHERE句をミスった一括UPDATE、マイグレーションでの破壊。元のデータがもう無い。
前回のシリーズ2で「変えにくいもの＝あとから戻せないもの」という話をしましたが、信頼性の怖さもまったく地続きなんですよね。怖さの正体は「その操作、間違えたら戻せる？」に集約されます。
軸2：誰を信じるか
でもこれ、実はもう一段深い軸があって。決済が怖い本当の理由は、「自分のコードに自信を持たないといけない部分だから」なんです。
- インフラ：信じる相手が自分じゃない。サーバーの安定性はXserverやAWSが担保してくれるし、Dockerやnginxは世界中で叩かれまくった「枯れた」もの。プロが作った仕組みに乗っかってるから、自分のコードの出来にそこまで依存しない。
- 決済：信じる相手が自分のコード。決済サービス（Stripeなど）自体は堅牢でも、「課金が成功したらDBのフラグを立てる」「失敗したらロールバックする」という繋ぎ込みの部分は自分が書いた責任範囲。ここがバグってたら、いくら決済サービスが堅牢でも意味がない。
これ、シリーズ2の「退屈な技術を選ぶ（枯れたものは他人が信頼性を保証してくれる）」とそのまま繋がるんですよね。
怖くない領域 = 他人（プロ）が信頼性を保証してくれる部分
怖い領域 = 自分のコードが最後の砦になる部分つまり、決済で感じるあの緊張感は、「ここは自分が守らないと誰も守ってくれない」というセンサーが正しく働いている証拠。信頼性の判断力って、この「自分が最後の砦になる場所」を見つける力なんじゃないかなと思います。
例え話：道路のガードレールは崖にだけある
ここでエンジニア向けの例えを2つ。まず全体の骨格から。
道路って、全部にガードレールがあるわけじゃないですよね。崖のそばにだけある。平地には無い。
- 平地（戻せる操作）：落ちてもすぐ這い上がれる。ガードレールは要らない。
- 崖（戻せない操作＝決済・データ破壊）：落ちたら終わり。ここにだけ全力でガードレールを立てる。
信頼性の判断力って、要は「どこが崖か見分ける力」なんです。全部の道にガードレールを立てようとするから動けなくなる。崖だけ見つければいい。
そしてもう一つ、エンジニアなら絶対に体で知ってる例えがあって。本番DBで DELETE FROM ... WHERE ... を打つときです。
あのとき、無意識に儀式をやってませんか。WHERE句を二度見して、先に SELECT で件数を確認して、トランザクションを張って…。取り返しがつかないコマンドの前だけ、異常に慎重になる。あの感覚こそ信頼性の本質だと思うんです。
だから僕が言いたいのはこれです。決済コードは、本番でDELETEを打つときと同じ緊張感で扱え。 逆に言うと、戻せる操作にその緊張感は要らない。崖にだけ集中する。
レビュアーがいない個人開発で、どう自信を作るか
さて、ここからが本題です。「自分のコードが最後の砦になる場所」がわかったとして、じゃあどうやって「大丈夫だ」という自信＝根拠を作るか。
一番安心なのは、誰かにレビューしてもらうことです。でも個人開発だと、レビューしてくれる人がいない方が普通なんですよね。ここで多くの人が詰まる。
そこで考え方を変えます。そもそもレビューの何が安心かというと、「自分以外の視点が入る」ことなんです。自分の思い込みの外から「そこ大丈夫？」と突っ込んでくれる。ということは、その”別視点”を人以外で用意できれば、レビューの代わりになる。方法は3つあります。
① テストに喋らせる
テストって「レビュー」というより、自分が決めた仕様を、機械に見張らせるものなんですよね。決済でいうと、「起きたら困ること」を先にテストにしておく。
- 二重に課金されない
- 課金が失敗したらDBのフラグは立たない
- 同じ注文を2回送っても1回しか処理されない
一度書けば、これは24時間文句を言わずにレビューし続けてくれる他人になります。特に「戻せない操作」は、ここにテストを全集中させる。
② AIをレビュアーにする
これはシリーズ1でやった「AIを感覚の通訳にする」の応用です。決済コードを貼って、観点を指定して聞く。
この決済処理で、二重課金・課金成功なのにサービスが有効化されない・返金漏れが起きるパターンを、コードの流れに沿って指摘して人間のレビュアーがいなくても、観点を持ったAIが疑似レビュアーになってくれます。ただしAIも見落とすので、これは補助輪であって最後の砦にはしない、というスタンスが大事かなと。
③ 問いのリストで「自分を疑う」
3つ目は、思い込みを外から壊す問いのリストを持っておくこと。「もし〜だったら？」を機械的に自分へ浴びせます。
- もし途中でネットワークが切れたら？
- 同じボタンを2回押されたら？
- 決済は成功したがDB更新前にサーバーが落ちたら？
- テスト用キーのつもりが本番キーだったら？
①②をやってる人ほど、③が「次の一手」になる
ここが今回一番伝えたいところです。
実は僕自身、①テストと②AIレビューは今までもやってきました。個人開発してる人なら、自然とこの2つはやってる人が多いと思います。でも、両方やってるのに事故るパターンがあるんですよ。
それは、①も②も「自分が思いついた範囲」しかカバーしてないから。
- テスト：自分が「これは危ない」と思ったケースしか書かない
- AIレビュー：自分が貼ったコードの範囲しか見ない
つまり①②は「自分が気づいてる危険」には強いけど、「気づいてもいない危険」はスルーするんです。そして決済で本当に怖い事故って、だいたい「そこが危険だと思ってなかった」場所で起きる。
だから③の「問いのリスト」が効いてきます。③だけ性質が違って、自分の思い込みの外から質問を浴びせるもの。①②の穴を埋める役割なんですよね。
① テスト → 自分が気づいた危険を、機械に見張らせる
② AIレビュー → 自分が貼った範囲を、疑似レビュアーが見る
③ 問いのリスト → 自分が気づいてない危険を、外から掘り起こす（①②の穴を埋める）しかも③は、①②の入力を生み出す装置にもなります。
「もし同じボタンを2回押されたら？」（③の問い）
→ その状況をテストにする（①）
→ AIに「この2重送信、コードで防げてる？」と聞く（②）こうやって③を起点に①②が回り出す。①②をやってきた人にとっては、③を足すのが自然な次の一手になるはずです。
まとめ
- 信頼性の怖さの正体は「自分のコードが最後の砦になる場所」（＝決済・大きなデータ変更）
- 全部を等しく守ろうとするから動けない。道路のガードレールと同じで、崖にだけ守りを集中する
- 「決済コードは、本番でDELETEを打つときと同じ緊張感で扱え」
- レビュアーがいない個人開発では、別視点を自分で仕込む（①テスト・②AIレビュー・③問いのリスト）
- ①②は「気づいてる危険」に強いが、事故は「気づいてない危険」で起きる。だから③が次の一手
他人（プロやAI）が守ってくれる部分は任せて、自分が最後の砦になる部分を見極めて守る。これがAI時代の信頼性の判断力なのかなと思います。次回はシリーズ最終回、「何を作るかを言語化する力」を扱う予定です。
よくある質問
テストはどこまで書けばいいですか？
全部に等しく書くのではなく、「戻せない操作」に集中するのがおすすめです。決済・データ削除・不可逆な外部連携など、失敗したら取り返しがつかない部分を優先します。戻せる操作のテストは後回しでも大きな事故にはなりにくいです。
AIレビューだけでは不安です。信用していいですか？
AIレビューは「補助輪」として使うのが安全かなと思います。観点を指定すれば見落としを減らせますが、AIも漏らします。テスト（①）と問いのリスト（③）と組み合わせて、複数の視点で確認するのが現実的です。
「問いのリスト」は何を入れればいいですか？
「もし〜だったら？」の形で、自分の思い込みを壊す質問を入れます。ネットワーク断・二重送信・処理途中のサーバー停止・本番と検証環境の取り違えなど、「正常系では起きないけど現実には起きること」を中心にすると効果的です。
個人開発でもコードレビューは必要ですか？
理想は必要ですが、いない場面の方が多いのが現実です。この記事の①〜③は「レビュアーがいない前提で別視点を自分で仕込む」方法なので、一人開発でも近い効果を作れます。
コメント