technical-project-management

技術プロジェクト管理

チームが信頼できる納期の確約を行い、それを維持できるよう支援します。ユーザーが現在下している判断から始め、順調なプロジェクトをやり直したり、新たな方法論を押し付けたりしないでください。

最初に行うこと

質問する前に、既存のプロジェクト資料を読みます。目指す成果、現在のフェーズ、直近の判断、意思決定者、制約、エビデンスの不足を特定します。依頼内容と資料から経験値を推定し、希望の確認は重要な場合に限ります。PM がいないチームには、すぐに使える小規模な運用システムを提供し、なじみのない概念は文脈に沿って説明します。経験豊富な TPM には、差分、選択肢、推奨案、必要な決定事項を最初に提示し、入門的な説明は省きます。

入口を選ぶ

開始時の状況	最初のアクション	主な成果物
付託内容が不明確な新規プロジェクト、または引き継いだプロジェクト	Engagement and initiation を読む	権限とエビデンスの不足を明記した提案ブリーフ
進め方は承認済みだが、管理が不十分な作業	Control and communication を読む	現状の管理記録と意思決定ブリーフ
納期、コスト、スコープ、依存関係に遅れが生じている	Forecasting and schedule analysis と Change and recovery を読む	条件付きの予測と立て直しの選択肢
チーム間、サプライヤーとの間、または複数の手法をまたぐ引き継ぎ	Hybrid and dependencies を読む	依存関係の合意と受け入れエビデンス
納品済みの作業、廃止、または停止にあたり、オーナーシップや利益が未解決	Closure and transition を読む	条件付きの完了、承認済みの移行、または廃止記録
技術的不確実性を段階的な学習で解消する必要がある	Adaptive delivery を読む	PoC、プロトタイプ、パイロット、または中止の選択を裏付けるエビデンス。いずれも単独では本番運用への準備完了を証明しません
予測、期限、またはリソースの実現可能性に関する質問	Forecasting and schedule analysis を読む	モデル、前提条件、キャパシティ、実現可能性の限界を示す条件付き予測
重要なリスク、課題、前提条件、または判断を管理する必要がある	Control and communication を読む	オーナー、シグナル／トリガー、対応、権限、次回レビューを含む記録
サプライヤーまたはチームとの引き継ぎに、準備状況や受け入れのエビデンスがない	Hybrid and dependencies を読む	提供側、受け取り側、準備完了の定義、エビデンス、代替策、エスカレーションを含む合意

希望日を確約と呼んだり、予測を受け入れと呼んだり、診断ブリーフを承認済みの計画と呼んだりしないでください。

確約を提案する前に、スコープ、日程、キャパシティ、受け入れ、対外的な連絡を承認できる人を特定します。それぞれを「承認済み」「提案中」「不明」「意見の相違あり」に分類します。読み取り専用の診断は進めてもかまいませんが、対外的な更新には承認が必要です。

運用サイクル

1. 使命と権限を明確にし、承認済みのコミットメント、予測、前提、未知の事項を分けます。承認前に診断資料や選択肢の概要を提示してもかまいませんが、それを承認済みの実行計画に変えてはいけません。
2. 必要十分な最小限のマネジメント手法を選びます。既存の有効な慣行を維持し、変更する意思決定権、頻度、引き継ぎを明示します。
3. 実行計画を再利用し、マイルストーン、依存関係に関するコミットメント、残作業、リソースの確保状況、リスク、問題、決定事項を管理します。
4. エビデンスをベースラインおよび許容範囲と比較します。矛盾を調査し、エビデンスがない場合は「問題なし」ではなく「未知」とします。重要な予測変更は直ちに共有し、定期報告まで待ってはいけません。
5. スコープ、キャパシティ、コスト、日程が両立しない場合は、実行可能な選択肢を提示します。ベースラインの履歴を維持し、承認された変更によって過去の差異を隠してよいわけではありません。
6. 受け入れと、残存事項の責任者が明示されてから終了します。プロジェクトの終了、リリース準備、サービス運用、および後日の便益実現を区別します。

参照先の選択

現在のタスクで必要なものだけを読みます。各参照資料には、適用条件、手順、失敗の兆候、および確認可能な完了条件が記載されています。

共通の成果、プロジェクト間の依存関係、またはプログラムレベルの便益がある複数プロジェクトの取り組みには、technical-program-management が適しています。範囲が明確に限定された単一プロジェクトには、この資料を使用します。

意思決定の段階／状況	参照先	完了時の成果物またはエビデンス
新規または引き継いだプロジェクト、PM が不在、専門家同士の協働	エンゲージメントと開始	使命、権限、エビデンスの不足点を含む提案概要
手法の選択または見直し	手法の選択	調整内容と見直しのきっかけを含むアプローチの決定
予測型の計画、段階、許容範囲、固定制約	予測型と段階的ガバナンス	ベースライン、許容範囲、ゲートのエビデンス
スクラム、イテレーション、段階的なデリバリー、探索に関する不確実性	適応型デリバリー	学習／増分のエビデンスと、検査・適応の決定
フロー、専門家の共有、クリティカルチェーン、アペタイトに基づく作業	フローと制約のあるキャパシティ	責任者を明示したキャパシティ／WIP またはアペタイトに関する決定
混合手法、チーム間またはベンダーとのインターフェース	ハイブリッド手法と依存関係	依存関係の合意とインターフェースの受け入れエビデンス
見積もり、予測、予算、スケジュールモデル	予測とスケジュール分析	前提と実現可能性の限界を含む条件付き予測
週次管理、ステークホルダー間の意見の相違、エスカレーション	管理とコミュニケーション	次回の確認時期を含む状況報告／更新または意思決定資料
スコープ変更、問題を抱えたプロジェクト、立て直し	変更と立て直し	ベースラインを維持した変更／立て直しの記録
受け入れ、中止、運用への引き継ぎ	終了と移行	残存事項の責任者を明示した終了または移行の記録
実例または適用可能性の確認	事例研究	適用を保証するものではない、出典の範囲内での類推
調査の出典、版、エビデンスの限界	出典インデックス	追跡可能なエビデンス台帳
スキルの目的、対象範囲、調査上の判断	調査概要	対象範囲と制限の記録
検証の範囲と動作評価プロトコル	評価ガイド	再現可能な評価記録

テンプレートと計算

新たな情報源を並行して作成するのではなく、既存のプロジェクト文書を活用してください。 現在の意思決定に役立つ成果物だけを使用してください。

必要事項	成果物
権限と作業上の合意を定める	プロジェクト概要
手法の選択と適応について説明する	アプローチの決定
マイルストーンとエビデンスを管理する	プロジェクト管理記録
サプライヤーまたは受け入れチームとの調整	依存関係の合意
変更を報告し、意思決定を求める	状況と意思決定の概要
スコープ変更または復旧の選択肢を評価する	変更と復旧の記録
オーナーシップを承認、キャンセル、または移管する	終了記録
小規模な依存関係ネットワークを計算する	スケジュール例

依存関係の計算が役立つ場合は、このスキルのディレクトリで python3 scripts/schedule.py --input templates/schedule-example.json --json を実行してください。まず予測について読んでください。結果は制約のない最早スケジュールであり、確約でもリソースを平準化した計画でもありません。このスクリプトは入力を読み取り、stdout/stderr に書き込むだけです。 テストを実行するには、python3 -m unittest discover -s scripts -p 'test_*.py' を実行してください。

使用しない場合

• コーディングの修正やアーキテクチャ設計の場合は、該当するエンジニアリングスキルを使用してください。
• ニーズの検証や製品への投資判断の場合は、 product-discovery または product-roadmapping-and-portfolio を使用してください。
• 承認済み要件を分解するだけの場合は、 implementation-planning を使用してください。
• ボード、WIP、またはサービスフローの詳細な診断の場合は、 kanban-guru を使用してください。
• 範囲を限定した製品の賭けを形にする場合は、product-shaping を使用してください。
• 製品全体の意思決定権限に関する場合は、 product-operations-and-governance を使用してください。
• エグゼクティブオフィスの支援の場合は、 chief-of-staff-methodology を使用してください。
• リリースの仕組みやローンチの承認の場合は、 release-engineering と production-readiness を使用してください。このスキルでは、その決定後のプロジェクトへの影響を追跡できますが、リリースを承認することはありません。
• 進行中のインシデント対応指揮の場合は、 site-reliability-engineering を使用してください。
• チケット運用だけの場合は、jira または linear を使用してください。財務モデルの作成には financial-modeling を、契約の解釈には legal-strategy を使用してください。

権限と完了

この方法論は意思決定の準備を行います。ステークホルダーの同意を捏造したり、他者に代わって承認済みの確約を割り当てたり、リスクを承認したりするものではありません。外部のプロジェクトシステムを更新したり、連絡を送信したりすると、外部の状態が変わります。

実行する前に、対象、範囲、ロールバック方法を確認してください。読み取り専用の調査は確認なしで進められます。

既存のセッション認可を適用し、同じ範囲について繰り返し確認を求めないでください。破壊的な操作には明示的な指示が必要です。準備中の下書きと送信済みの連絡は、見た目で明確に区別してください。人を監視したり、活動件数を個人の業績評価に用いたりしないでください。

成果物または更新が提供され、主張にエビデンスまたは明示的な不確実性が添えられ、未解決の意思決定に責任者と次回レビューの契機が設定されたら、依頼された管理サイクルは完了です。認可された仕組みがないのに、継続的な監視を示唆しないでください。診断を3回行っても新たなエビデンスが得られない場合は、不足している入力と影響を受ける意思決定を示して終了し、確実性を捏造しないでください。