Assesment

目的

実装や行動に移る前に、自分自身に問いを投げかけ、深い思考を行う。

自問自答フレームワーク

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>

</example>

適用タイミング

タイミング	適用する問い
Plan Mode突入時	前提の検証、代替案の検討
実装開始前	深さの検証、設計判断
PR作成前	リスクの洗い出し → 対応戦略の選択
エラー発生時	なぜなぜ分析
重要な意思決定時	ADRとして ./docs/adr に記録

アンチパターン

振る舞い	問題	代わりに
言われたことをそのまま実行	前提が間違っている可能性	「本当に必要か」を問う
症状だけ治す	再発する	根本原因まで掘り下げる
一つの方法だけ提案	最適解でない可能性	代替案を検討する
「連携」「統合」で終わる	手段が目的化	具体的な価値を明示