### プロジェクト進行用：タスク分解・構造化チェックリスト「Architect-Flow」 本リストは、混沌としたプロジェクトを「静的な構造」へと変換し、実行可能なタスクへ彫刻するためのフレームワークである。単なるToDoリストではなく、思考の解像度を段階的に高めるための階層構造として定義する。 #### 1. プロジェクト基盤の定義（Foundation Tier） プロジェクトの「輪郭」を定めるフェーズ。ここが曖昧であれば、後のタスクは崩壊する。 * **[Core-Goal] 最終成果物の定義**: 誰が、いつ、どのような状態で手にするか。 * **[Boundary-Constraint] 境界条件**: * 予算・時間・人的リソースのハードリミット。 * 「やらないこと（Non-Goal）」の明文化。 * **[Stakeholder-Mapping] 関係者相関図**: * 意思決定者（Decision Maker） * 実務実行者（Executor） * 監視・承認者（Approver） #### 2. 分解と構造化（Decomposition Tier） プロジェクトを「塊」から「粒子」へ砕く工程。以下の分類表（Matrix）に沿ってタスクを配置する。 | フェーズ | 深度 | 期待される出力 | 依存関係 | | :--- | :--- | :--- | :--- | | **初期調査** | レベル1 | 市場/競合分析レポート | なし | | **設計・構築** | レベル2 | プロトタイプ/仕様書 | 初期調査の完了 | | **実行・実装** | レベル3 | 実働モジュール/原稿 | 設計の承認 | | **検証・統合** | レベル4 | テスト結果/FBログ | 実装の完了 | | **最終展開** | レベル5 | リリース/アーカイブ | 検証のパス | #### 3. タスク実行の解像度チェック（Resolution Check） 各タスクが「動詞」として機能しているかを確認する。曖昧なタスク（例：「準備する」）は、以下の基準で「実行可能な状態」まで彫刻し直す必要がある。 * **[Actionable] 実行のトリガー**: 「いつ、どこで、何を見たら開始するか」が明確か？ * **[Output-Defined] 完了の定義**: 「何が出来上がれば終了したと見なすか」が客観的か？ * **[Dependency-Clear] 依存の連鎖**: 次の工程へ渡すための「引き渡し基準」は合意されているか？ #### 4. プロジェクト・パラメーター設定（Parameter Configuration） 進行の停滞を防ぐための動的制御設定。 * **[Risk-Buffer] リスク・バッファ**: * 全タスク合計時間の20%を予備時間として確保。 * 「高リスク・高インパクト」なタスクを最優先で着手（フロントローディング）。 * **[Feedback-Loop] 構造的フィードバック**: * 定例会議の目的：進捗報告（Status）ではなく、障害物の除去（Blocker Removal）に限定。 * 各マイルストーン通過時の「振り返り（Retrospective）」の義務付け。 #### 5. 進行のメンテナンス・サイクル（Lifecycle Management） プロジェクトは生き物である。以下のサイクルを回し、構造の歪みを修正する。 1. **Weekly-Scrub（週次洗浄）**: * 今週のタスクが「完了」か「未完了」か、あるいは「不要（削除）」かを判定。 * 期限を過ぎたタスクを即座にリスケジュール、または「プロジェクト・バックログ」へ移動。 2. **Milestone-Audit（区切り監査）**: * フェーズ終了ごとに、プロジェクト全体の「骨組み」が当初の目的とズレていないかを確認。 * 必要であれば、全体構造の再設計（Re-factoring）を行う。 #### 6. 運用上の禁忌（Anti-Patterns） 以下の状態に陥った場合は、直ちに進行を停止し、再定義を行うこと。 * **[Task-Bloat]**: タスクが細かすぎて管理コストが実務コストを上回っている。 * **[Ghost-Dependency]**: 実在しない、あるいは責任者が不明な依存関係に引きずられている。 * **[Deadline-Drift]**: 期限が「目標」ではなく「希望的観測」として扱われ、形骸化している。 --- 本リストは「体系化の美学」に基づいている。タスクを単なる作業の列挙として扱わず、一つの完成された彫刻を削り出すプロセスとして捉えること。整理された思考は、実行の速度を最大化させる。