anti-patterns

拒否すべき SDLC のアンチパターン

参照用カタログです。提案を却下するときは、アンチパターンの名前を挙げてください。問題を議論するための明確な用語をユーザーに提示できます。

アーキテクチャのアンチパターン

A-1. ゴッドサービス

兆候： 1 つのサービスが認証、課金、検索、ファイルストレージ、メールを担っています。 問題点： デプロイ単位も障害の単一障害点も 1 つになり、すべてのチームがそのサービスに手を入れるため、時間とともに変更の速度が落ちます。 対策： ビジネス能力（DDD の境界づけられたコンテキスト）ごとに分割します。

A-2. 分散モノリス

兆候： マイクロサービスは 12 個ありますが、データベースを共有し、一緒にデプロイしています。 問題点： 分散システムのコスト（レイテンシー、結果整合性、運用のオーバーヘッド）はすべてかかるのに、そのメリット（独立したデプロイ、分離）は得られません。 対策： 本当に分離する（独自の DB、独自のデプロイパイプライン）か、統合します。

A-3. 同期呼び出しの連鎖

兆候： リクエスト → サービス A → サービス B → サービス C → サービス D。 問題点： 障害の発生確率が累積し、p99 レイテンシーも積み上がります。 対策： イベントを使った非同期処理にするか、ホットパスを同じ場所に配置します。

A-4. 早すぎる最適化

兆候： 最初の有料ユーザーを獲得する前に、カスタム Redis Lua スクリプトや手作業で調整したバイナリプロトコルを導入します。 問題点： 複雑さのコストを先払いすることになり、取り戻せません。 対策： シンプルな構成から始めます。負荷データを得てから最適化します。

A-5. 履歴書のための開発

兆候： 解決すべき現在の問題がないのに、「Kubernetes／GraphQL／イベントソーシング／DDD を使いましょう」と提案します。 問題点： ユーザーの成果ではなく、エンジニアの履歴書を最適化しています。 対策： 「機能するもののうち、最もシンプルなのは何か？」と尋ねます。

計画／プロセスのアンチパターン

P-1. ビッグバン書き換え

兆候： 「これを で書き直しましょう。」 問題点： 書き換えの 80% は失敗します。古いシステムには、何年分ものバグ修正が組み込まれています。 対策： ストラングラーフィグパターンを使います。新しいコードに新しい振る舞いを実装して古いコードと共存させ、トラフィックが移行したら古いコードを削除します。

P-2. ヒーロー文化

兆候： 「深夜 3 時のインシデントは、いつもシニアの X が解決します。」 問題点： バス係数が 1 です。X は燃え尽き、知識も共有されません。 対策： 運用手順書、ポストモーテム、オンコール担当の交代、ペアデバッグを実施します。

P-3. 元に戻す計画がない

兆候： 計画に、後戻りできない変更（データ移行、公開 API の変更、互換性を破るリリース）が含まれています。 問題点： 誤っていた場合、復旧に数日から数週間かかります。 対策： 承認前に、ドライランとロールバック手順を必須にします。

P-4. 時間枠のない計画

兆候： 終了条件のない「機能 X を実装する」といったタスクが設定されています。 問題点： スコープが際限なく広がり、時間もそれに合わせて膨らみます。 対策： 各タスクを 4 時間以内にし、「完了＝X」という明確な条件を設けます。

コードレベルのアンチパターン

C-1. ゴッドクラス／ゴッド関数

兆候： 500 行を超えるクラス、または互いに無関係な 5 つの処理を担う 100 行を超える関数です。 問題点： テストが統合テストになり、差分の読みやすさが損なわれます。 対策： 単一責任に従い、協調オブジェクトを切り出します。

C-2. 文字列型頼み

兆候： ステータスを enum なしで文字列（"open"、"closed"、"blocked"）として渡しています。 問題点： タイプミスがコンパイルを通過し、新しいステータスを switch で処理し忘れます。 対策： Enum／判別共用体／ブランド型を使います。

C-3. 例外を握りつぶして処理を続ける

兆候：

try { doThing(); } catch (e) { console.log(e); }

問題点： バグを隠し、気づかないままデータを破損させます。 対策： 対処できる例外だけを捕捉し、それ以外は再スローします。コンテキストを付けてログに記録します。

C-4. シークレットのハードコード

兆候： API キー、パスワード、DB URL をソースに記述しています。 問題点： Git の履歴に永久に漏えいし、ローテーションには強制プッシュが必要になります（不可能です）。 対策： 環境変数またはシークレットマネージャーを使います。sk-、ghp_ などを検索するコミット前フックを設定します。

UI のアンチパターン

Google AI Studio の生成インターフェースを仕上げるためのガイド（2026-09-16）からの抜粋です。 意味のない装飾が、アンチパターンを見つける最も手早い手がかりです。

U-1. 意味のないチップ

兆候： どの状態にも対応していないステータスピル、バッジ、カウンター、タグです。画面上で新しいもの、ベータ版のもの、数えられたものが何もないのに、「New」「Beta」「AI」「3 insights」と表示されます。 問題点： 読み手はシグナルと装飾を見分けられず、同じ視覚表現を使った本物の警告も無視されます。これは、生成された UI を見分ける最も確かな手がかりです。 対策： 各チップは、その意味と、それに対応する状態を示すようにします。そうでなければ削除します。

U-2. プレースホルダー画像

兆候： 公開予定のビルドに、灰色のボックス、Lorem の写真、リンク切れまたは外部サイトから直接読み込むストック画像の URL が含まれています。 問題点： 第一印象が未完成の製品になります。外部サイトから直接読み込むアセットは予告なく表示されなくなったり、変更されたりする可能性があり、ライセンスがない場合もあります。 対処法： すべての画像に、製品向けに生成したもの、所有しているもの、またはライセンスを取得したもののいずれかの出典を明記し、製品独自のアセットから配信します。

インシデント／運用上のアンチパターン

O-1. SLO がない

兆候： 「今日は本番環境が遅いようです」と言う一方で、SLO の目標がありません。 問題点： 違反と通常の状態を区別できません。 対処法： p99 レイテンシー、エラー率、可用性の SLO を設定します。予算の消費状況を追跡します。

O-2. アラートのスパム

兆候： エラーのたびにページが鳴り、エンジニアがアラートを読まなくなります。 問題点： ノイズに埋もれて実際のインシデントを見逃します。 対処法： ユーザーに見える障害がある場合にのみページを鳴らします。それ以外のシグナルはページャーではなくダッシュボードに表示します。

O-3. ポストモーテムでの責任追及

兆候： 「エンジニア X はテストせずにデプロイしました。」 問題点： 今後のポストモーテムが行われなくなります。責任を追及しても、システムは改善しません。 対処法： 非難のないポストモーテムを実施します。人ではなく、不足していたガードレールに焦点を当てます。

O-4. スノーフレークサーバー

兆候： 「SRV-PROD-3 は IaC にない特別な設定があるので、再起動しないでください。」 問題点： 災害復旧が不可能になります。 対処法： すべてを IaC で管理します。サーバーはペットではなく家畜です。

このカタログの使い方

提案やレビューでこれらのアンチパターンを見つけた場合：

1. ユーザーが共通の用語を使えるよう、コード（A-3、P-1 など）を示します
2. 提案にある具体的な兆候を引用します
3. 具体的な対処法を提案します
4. ユーザーが同意しない場合は、代替案のセクションを記入した ADR として記録します

適用しない場合

• 趣味のプロジェクトや学習用の演習 — アンチパターンは規模に関するものです
• // TODO delete in 2 weeks と明記された使い捨てコード
• 目標が「API が実際に動作するか」の検証である、時間を限定した POC