制作・開発ガイドライン〜魂の羅針盤〜

このドキュメントは、我々クリエイターが「今日も生き延びた」と呟きながら帰宅できるよう、知恵と経験と少々の祈りを凝縮したものです。教条主義的な「べき論」は一切ありません。あるのは、現場で揉まれてきた人々の優しい嘘と本当のことだけです。

1. 納期とスケジュールの哲学

「納期とは、関係者全員が『なんとかなった』と言える魔法の瞬間のことである」
— 弊社エンジニア、某朝5時のSlackより

納期は神聖なものです。しかし、その解釈には少し余白があります。

クライアントが「明日まで」と言ったとき：
深呼吸してください。「明日」とは地球が1回転する間のことです。地球は意外と速く回ります。あと、「明日の何時まで？」と聞くだけで人生が変わることがあります。
スケジュールのバッファについて：
「確認の時間」「思ってたんと違う調整」「原因不明のデプロイ失敗」は、物理法則のようなものです。見積もりに含めましょう。含めてください。お願いします。
アジャイルとは何か：
仕様変更を「バグ」ではなく「新機能の先行発表」と捉えられるようになったとき、あなたはアジャイルを理解したと言えます。

本番環境はデリケートな生き物です。優しく扱ってください。

タイミング	理由
金曜17時以降	バグの週末旅行を見送る羽目になります
飲み会の直前	人間は酔っていてもSlackを確認してしまう生き物です
「軽微な修正だから」と思ったとき	「軽微」という言葉を信じた先人たちの目が光っています

💡 先人の知恵
「テストを書くのが面倒だという気持ちはよく分かる。でも、本番で初めて動作確認するのはもっと面倒だ」

コードは「動く」だけでなく、「3ヶ月後の自分が読める」ことが重要です。なぜなら、3ヶ月後の自分は今の自分を完全に忘れているからです。

コメントは未来への手紙： 「なぜこう書いたのか」を残しましょう。// ここ絶対触るな（理由は聞かないで） という手紙も、何もないよりはるかにマシです。
変数名について： data2, data_final, data_final_rev3 という歴史は繰り返してはいけません。
魔法の数字： * 86400 と書くより * SECONDS_IN_A_DAY と書くほうが、読んだ人の心拍数が正常値を保ちます。

コミットメッセージは、チームへの「今日何したか」報告書です。
情緒は大切ですが、意味不明は困ります。

良いコミットメッセージの例：

feat: お問い合わせフォームにバリデーションを追加
fix: SP表示時にヘッダーが崩れる問題を修正
refactor: ユーザー取得処理をuseQueryに移行

愛嬌はあるが改善の余地があるコミットメッセージ：

fix: なんか直った
update: いろいろ
WIP: 意識が遠のいてきた（でもなんとか動いてる）

後者にも魂は宿っていますが、git log を見た人が「いろいろ」の詳細を把握できないという致命的な問題があります。

本番でなにかが起きたとき、重要なのは「原因究明」より先に「サービス復旧」です。

🎯 ゴール
インシデントで怒る文化より、インシデントから学ぶ文化を。怒鳴っても障害は直りません（実証済み）。