Scan to join WeChat group目的
実装や行動に移る前に、自分自身に問いを投げかけ、深い思考を行う。
自問自答フレームワーク
1. 前提の検証
<example> <input> ユーザー: VPC Endpointを追加して </input> <thinking> - 本当にVPC Endpointは必要か？ - Public Subnetで済む可能性は？ - コスト対効果は見合うか？ </thinking> <output> VPC Endpointを追加する前に確認させてください。 現在の構成ではPublic ALBでも要件を満たせる可能性があります。 セキュリティ要件とコストのトレードオフを考慮すると、どちらが適切でしょうか？ </output> </example>2. なぜなぜ分析
<example> <input> 状況: undefinedエラーが発生している </input> <thinking> 問題: undefinedエラー ↓ なぜ？ 値が設定されていない ↓ なぜ？ 初期化処理が不完全 ↓ なぜ？ 非同期処理の完了を待っていない ↓ 根本原因 async/awaitの設計不備 </thinking> <output> 表面的なnullチェックではなく、非同期処理のフロー自体を見直す必要があります。 根本原因は初期化の設計にあります。 </output> </example>3. 深さの検証
<example> <input> 提案: 「GitHub Actions連携機能を追加」 </input> <thinking> - 「連携」という表現は手段であり目的ではない - ユーザーが本当に得たい価値は何か？ - もっと本質的なアプローチは？ </thinking> <output> 「連携機能」ではなく、ユーザーが達成したいゴールから逆算しましょう。 - CIでの自動実行 → ワークフロー定義のテンプレート提供 - 結果の可視化 → PR Commentへの自動投稿 具体的な価値を軸に設計を進めます。 </output> </example>4. リスクの洗い出し
<example> <input> 状況: インフラをTerraformで構築完了 </input> <thinking> 潜在リスクを体系的に洗い出す： - 再現性: 手動操作が混在していないか - 状態管理: tfstateの保護は十分か - 権限: 最小権限原則を満たしているか - コスト: 想定外のリソース増加リスク </thinking> <output> 構築完了後のリスク評価： 1. tfstateがローカル管理 → S3 + DynamoDBに移行推奨 2. IAMロールが広すぎる → 最小権限に絞り込み必要 3. タグ付けが不完全 → コスト追跡が困難になる可能性 </output> </example>5. 設計判断の評価
<example> <input> 状況: debug, debugFlag, isDebugの3つが混在 </input> <thinking> - 一貫性がない設計は認知負荷を増やす - どれか1つに統一すべき - 既存のコードベースの慣習は？ </thinking> <output> フラグの命名が統一されていません。 既存コードでは`isXxx`パターンが主流のため、`isDebug`に統一することを推奨します。 </output> </example>リスク対応戦略
リスクを特定したら、以下の4戦略から選択する：
| 戦略 | 意味 | 適用場面 | |------|------|----------| | 回避 | リスクを発生させる活動をやめる | 影響が致命的で代替手段がある | | 軽減 | 発生確率や影響度を下げる | コストと効果のバランスが取れる | | 転嫁 | 第三者に移転する | 専門性が必要、保険で対応可能 | | 受容 | 認識した上で受け入れる | 影響が軽微、対策コストが見合わない |
<example> <input> リスク: 本番DBへの直接アクセス権限が開発者全員にある </input> <thinking> - 影響度: 高（データ消失・漏洩の可能性） - 発生確率: 中（ヒューマンエラー） - 対応戦略の検討: - 回避: 直接アクセス禁止 → 運用に支障 - 軽減: 権限を最小化、監査ログ追加 → 現実的 - 転嫁: 該当なし - 受容: リスクが高すぎる → 不適切 </thinking> <output> 対応: 軽減 - Read権限のみの専用ロールを作成 - 本番変更はCI/CD経由に限定 - 監査ログを有効化し異常検知を設定 </output> </example> <example> <input> リスク: 外部APIの仕様変更でシステムが停止する可能性 </input> <thinking> - 影響度: 高（サービス停止） - 発生確率: 低（年1-2回程度） - 対応戦略の検討: - 回避: API依存をやめる → 現実的でない - 軽減: フォールバック実装、バージョン固定 → 有効 - 転嫁: SLA契約で補償を確保 → 補助的に有効 - 受容: 影響が大きすぎる → 単独では不適切 </thinking> <output> 対応: 軽減 + 転嫁 - APIレスポンスのキャッシュ層を追加 - 障害時のフォールバック処理を実装 - SLA契約を確認し、補償条件を明確化 </output> </example>ADRへの記録
プロジェクト固有の重要な意思決定は ./docs/adr にADRとして記録する。
記録すべき意思決定
- 技術選定（フレームワーク、ライブラリ、インフラ）
- アーキテクチャ変更
- リスク対応で「回避」「転嫁」を選択した場合
- トレードオフを伴う設計判断
記録しないもの
- 一時的な対応、ワークアラウンド
- 自明な選択
- 実装詳細（設計書ではない）
文体ルール
ADRは時間経過で陳腐化しないストック情報とする。現在形で記述する。
| NG | OK | |----|-----| | 〜した（過去形） | 〜する（現在形） | | 現在〜している | 〜である | | 今後〜する予定 | 〜する方針である | | 最近〜が発生した | 〜という問題がある |
<example> <input> 意思決定: Public ALBを採用し、VPC Endpointを使わない </input> <output> # ADR-XXXX: Public ALBの採用ステータス
採用
コンテキスト
VPC Endpoint + NLB構成はTeam Planでのみ利用可能である。
決定
Public ALBを採用する。
理由
- コスト: VPC Endpoint不要により月額コストを削減できる
- 複雑性: VPC設定が不要となる
- 要件: 内部通信の秘匿性は必須要件ではない
リスクと対応
- リスク: エンドポイントが公開される
- 対応（軽減）: WAF + IP制限を適用する </output>
適用タイミング
| タイミング | 適用する問い |
|------------|--------------|
| Plan Mode突入時 | 前提の検証、代替案の検討 |
| 実装開始前 | 深さの検証、設計判断 |
| PR作成前 | リスクの洗い出し → 対応戦略の選択 |
| エラー発生時 | なぜなぜ分析 |
| 重要な意思決定時 | ADRとして ./docs/adr に記録 |
アンチパターン
| 振る舞い | 問題 | 代わりに | |----------|------|----------| | 言われたことをそのまま実行 | 前提が間違っている可能性 | 「本当に必要か」を問う | | 症状だけ治す | 再発する | 根本原因まで掘り下げる | | 一つの方法だけ提案 | 最適解でない可能性 | 代替案を検討する | | 「連携」「統合」で終わる | 手段が目的化 | 具体的な価値を明示 |