プロジェクト計画書に「方針」を書くことがあるので、（ここでは自身の経験とかちょっと調べたことをベースに）それらのネタをまとめる。
プロジェクト計画を策定する前に、開発の全体的な進め方や各工程（フェーズ）のについて、おおよその進め方を決めておく必要がある。また、コストなどはいくらまでしか使えないなどの制限があるだろう。こういった、プロジェクト計画で策定する上での前提や制約を明記し、これらを踏まえてプロジェクト計画をどのように策定していくかを方針として記載する。この方針に従ってプロジェクト計画が策定され、このプロジェクト計画を基に、各工程の計画（テスト計画、移行計画など）が策定されることになる。プロジェクト計画の考え方の根幹となる部分なので、非常に重要である。
プロジェクト計画書の全体（章立て）は こちら
3章 方針
「方針」というものを明確にする必要はあるのだろうか。答えは「必要」である。プロジェクトに限らず、旅行でも何でもよいが、何か計画を立てるといってもその段取りの選択肢は無数にある。この無数にある選択肢の中から、ある程度最適な進め方を取捨して絞らなくてはならないので、その指針となるのが「方針」となる。また、ビジネスの場では、なぜそのような選択肢に絞ったのかその根拠（前提事項とか制約事項とか）を明確にし、顧客や上位の責任者に説明する必要がある。
「方針」を明確する前に、まずは前提や制約があればそれらを整理する。これらは、方針を決める上での材料になる。
・参考： 方針とは何か
前提事項
・「前提」とは、計画を策定する上でのベースであり、この前提を基にプロジェクト計画が策定される。これが覆るとプロジェクト計画の見直しが必要になる事項のこと
・プロジェクト計画を策定する前段階の企画の内容を踏まえて洗い出す
・開発ベンダーとしてプロジェクト計画書を作成する場合は、提案書を踏まえて洗い出す
・観点としては、５W1H、QCD、人物金時間、業務などを踏まえて考えてみるとよい。例えば、技術仕様、コスト、スケジュール、リスク、業務影響、開発環境、ステークホルダー、スコープ、など
| 例： ・開発、テスト、移行は業務に影響が出ないように進める。リリース時においても業務時間外で作業を行う ・基幹システム及びデータベースは現行のソフトウェアやサービスを踏襲する ・開発はウォーターフォールで行う ・リリース次期は繁忙期を外す（X月orX月とする） ・リリース後の旧システムの停止、破棄については、本プロジェクトには含めない ・新た機能の追加や性能向上が必要な場合は、コスト、難易度、リリース時期、優先度などを検討、整理したうえで、両社間にて対応を決定する。 |
参考：
・プロジェクトを立ち上げる前に作成した企画書（に該当する資料）には少なくとも、業務及びシステムに関する課題や要求事項が整理され、今回のプロジェクトで何を実現するか（追加したい機能、性能アップ、サービスに求める事項など）が要件（要求）として整理されているはずである。このれらの要求事項と、プロジェクト計画書の骨子を踏まえて、前提となることを整理していく。「前提」を基に後述する「方針」が決まり、「方針」を基にプロジェクト計画の内容が具体的になっていくことを意識し、論理性が保たれるような内容にする必要がある
・「例：」に記載している最後のポチ「新た機能の追加や性能向上が必要な場合は、～」の件については、「１．はじめに」でプロジェクトの運営についてのルールとして述べた方が良いかもしれない。ここでは、あくまで計画策定の材料を洗い出したいので毛色が違う気がする。（と、あとになって思った）
制約事項
プロジェクト計画を策定する上で、人、モノ、カネ、時間、品質など、様々なことについて資源は無限ではない。
何か制約（初めから決まっていること）があれば記載しておく。
・テストに関する事項
・リリースに関する事項
・開発環境
・体制
| 例： ・現行システムから新システムへの移行（本番切替え）は、一括方式で実施する ・本番切替えによる業務停止期間は金22：00～月6：00とする（この時間を超過する見込みの場合は切り戻しを行う） ・例があまり思いつかない（もう少し整理する） |
参考：
前提と制約とすると、なんとなく語呂が良いので「前提事項」を前述したが、何らかの制約により「前提事項」が決まる場合の方が多いのかもしれない（と後になって思ってしまった。。）
方針
・ 方針とは前提事項や制約事項を踏まえたプロジェクトを進めるための方向性
・ 業務、システム、プロジェクト全体の進め方、各工程、に関する取り組みをハイレベル書く
| 例： １．全体 ・プロジェクト管理は、社内プロジェクト管理標準に基づいて行う ・プロジェクトのフェーズ完了時点で、ステークホルダーに向けての報告を行う。報告には、フェーズの目標と結果、課題、次フェーズの目標と事前作業を含める ・業務に関する要件定義、業務テスト（UAT）計画およびテストは主管業務部門が主導で実施する２．開発 ・ウオーターフォール形式で行う３．テスト ・セキュリティテストは社内システム開発セキュリティ標準に基づいて行う ・システム移行後の重点監視については、現行の運用・保守業務を踏襲した形で行う ・現行システムのシステム停止および破棄については、本プロジェクトのスコープには含まない ・UATに関する計画、シナリオ作成、結果報告はXX部門にて実施する ４．移行 ・移行計画には、リスク、切り戻し、リハーサル計画、本番移行計画、移行判定についても含める ・移行リハーサルは移行ツールの動作テストが完了している前提として計画する ・移行時期は20XX年X月X日とする ５．引継ぎ ・次期システムの操作については、開発チームにてマニュアルを作成する。マニュアル作成は現行の操作マニュアルを修正する形で行う ・引継ぎについては、引継ぎ計画を策定し、Web会議による説明会および更新したマニュアル配布を行う ・業務部門からの次期システムの問合せについては、次期システムの運用・保守にて対応する（本プロジェクトのスコープ外） |
補足：
・後述の章でテスト計画や移行計画の内容をまとめるのでその内容を踏まえて上記の例は追加見直しを行う
・テストや移行については、全体テスト計画書や移行計画書を作成するので、それらで「方針」について触れてもよい
・なぜこの方針になったのか、トレースできるようにしておきたい（Inputとなる資料にたどり着けるようにしておきたい）
・参考： 方針とは何か
コメント