自分のノート

**原典を持たないもの。**手元で書いて溜めたもので、現場で決めた判断、実際の設定ファイル、 使うときに引く構文のメモが混ざっている。裏を取っていないので、読むときはそのつもりで。

**プロジェクトの時系列に並べてある。**ただし前半の「前提知識」はフェーズに属さない。 SQL の構文や Go の書き方は、プロジェクトが始まる前から持っているもので、 どの段階でも同じように引く。

1. 始まる前

判断の基準

• 原則 — いい人を集める、シンプルが一番。判断に迷ったときに戻る場所

前提知識

プロジェクトと関係なく持っているもの。引くための資料であって、判断ではない。 出所を書いていないので、仕様が変わっていないかは都度確かめること。

• データベース — テーブル設計、データ型、インデックス、SQL の構文 15本
• 言語・フレームワーク — Go、Rails、React、Solr
• 環境 — Mac のセットアップ、エディターに求めるもの、~/.zshrc、~/.vimrc
• MySQL のインストール — ローカル環境の構築、アップグレード

2. 要件を決める

自分のノートには無い。原典側の 要求と見積りと パフォーマンス予算を見る。

3. 設計する

• 設計 — できるだけシンプル、ポーリングはしない、モノリス、先を読む、廃止を考えておく
• API 設計 — URI、HTTP メソッド、レスポンス、ステータスコード、エラー情報
• API クイックリファレンス — 設計時に一目で見る短縮版
• API チェックリスト — 公開前に潰す項目
• キャッシュ — Memcached と Redis の比較

4. 実装する

• コード — フォーマッター、姿勢、ブランチ、命名、言語特有の機能との付き合い方
• バグ — テストコードで検知できない可能性のあるもの
• Git の運用 — SSH と ~/.gitconfig の設定、日々のコマンド、ブランチの運用基準
• ビルド — 速さ、冪等性、外部依存関係の決定性とセキュリティ
• 依存関係 — 信頼性の検証、自作と利用、バージョンの選び方
• コードレビューの進め方 — レビュアーがやること、開発者の姿勢、アンチパターン
• レビューチェックリスト — レビュー時にひととおり見る短縮版
• テストの方針 — テストスイートの健全さの見方、依存の置き換え方

5. リリース後に足す・直す

自分のノートには無い。原典側の リリースとデプロイ、 デプロイ戦略、 スキーマ変更の運用を見る。

6. 運用する

• インフラ — 自作しない、全部コード化する、使わないものは掃除する
• DB の運用 — トランザクション、ビュー、レポート、ビッグデータ、DB と API の境界
• 設定 — 時間、文字コード、上限、SQL モード、オートコミット
• ユーザーと権限 — 通常ユーザーとシステムユーザーの分け方
• セキュリティ — 攻撃者側の動きを攻撃の順番どおりに並べたもの 9本。守る側が何を見ればいいかを逆算するための資料

7. 廃止する

自分のノートには無い。原典側の 廃止と データ保持ポリシーを見る。

読むときの注意

推奨は反転する。 2026-08-31 の監査で3件見つかった。

反転しやすいのは「こう書け」と勧めている記述、とくにブラウザの実装や フレームワークの流儀が変わる領域。反転しにくいのは安定した API のリファレンス (SQL の構文、ルーティング DSL)と、「弱くなる」方向にしか動かないもの(暗号のアルゴリズム)。

原典から取ったものは 本・業界の原典から にある。

ここにある判断を AI に守らせる側の話は AI駆動開発のためににある。 原則の7項目のうち、AI 相手で重くなるのは 「推測ではなく実際にどうなるか」 「シンプルが一番」「なんのためか目的を考える」「全体を俯瞰してみる」の4つ。 残りは書き手が誰でも変わらない。