プロジェクトでは、プロジェクト計画、全体テスト計画などの計画を策定する際に「方針」を決める場面がある。今回は「方針」についての考え方や整理の仕方を述べる。
プロジェクトの方針
１．「方針」とは何か
「方針」とは一言でいうと”方向性”のことであり、これから計画を立てようとしている場合、ある程度「こういう風にしよう（こういうことはやらない）」と決めておくことだ。一方、「計画」とは一言でいうと”目的に至るための「段取り」”のことだ。この「段取り」の選択肢を絞るのが「方針」だと考えている。また、そもそものプロジェクトの目的を整理するという側面もあるかもしれない。
方針を決める
一般的な例で「方針」を整理してみよう。
あなたのご両親を旅行に連れていくきたいとする。選択肢は無数にあると思うが、仮にご両親がご高齢かつ体力的に強くない場合は、できるだけ徒歩が少なくなるように気を使ってプランを立てるのではないか。
となると、
| ・海外ではなく国内としよう（場所、移動時間） ・ハイキングなどのアウトドアや電車の乗り継ぎが多い観光地などは選択肢から外そう（何をするか） ・あまり長く滞在はしない。長くても2泊3日程度にしよう（期間） ・車、電車（新幹線）、バスあたりで飛行機は外そう（交通手段） ・温泉とか、美味しいものを食べに行くとか、車か電車で行ける絶景ポイントを巡るとか（目的） ・熱くも寒くもない時期がいい。春か秋かな（時期） ・15万円～20万くらいにしよう（予算） など |
というように、ご両親の負担が少なくなるような旅行計画が立てられるよう、ある程度選択肢を絞る必要がある。
上記のことを踏まえて、仮に出発が東京だとすると、新幹線で行きやすいし美味しいものもたくさんある熱海、長野、北陸、東北、京都あたりが旅行先の候補となり、例えば「1日目：京都（神社仏閣巡り） → 2日目：北陸（金沢兼六園、海鮮料理） → 3日目：東京（帰宅）」という旅行を組み立てることができる。
このように、計画を立てる前にそもそもの目的を整理し、そこまでの進め方をざっくりと決めるという過程を踏む必要がある。
計画を立てる
次に計画だが、これは決めた方針を踏まえて具体的な行動（段取り）を決めることになる。
| ＜計画＞ ・交通費や宿泊費はどのくらいか（コスト管理） ・旅行期間はどのくらいか（スケジュール管理） ・出発は何月何日とするか（スケジュール管理） ・交通手段はどうするか（進め方） ・どこに宿泊するか（場所） ・天候が悪くても大丈夫か（リスク管理） ・宿泊場所、レストランなどのキャンセルはいつまでにすればよいか（リスク管理） など |
計画では、基本的に5W1H（5W2H）を押さえておけばよい。プロジェクトでは、これに加えて、進捗、課題、リスクなどの管理の方法やコミュニケ―ションなど、プロジェクト管理についても触れる必要がある。
今回は旅行を例にして、方針→計画という流れをまとめてみた。要は、計画を立てる前に様々な観点で整理しなければならないことがあるということを知っていただければと思う。
方針を決める際に、もう一点重要なことがある。方針では、プロジェクトではやらないことを明確にしておくことも大事だ。プロジェクトは人、モノ、金、時間に制限がある。あれもこれもやっている余裕はない。例えば、システム更改のプロジェクトであれば、現行のサービスや機能が新しい環境で問題なく動けばよいという考え方にし、必要最低限のテストを実施するという方向性でテスト内容を決めて計画を立てるのもアリだと思う。
２．「方針」はどうやって決めるのか？
プロジェクトにおいて、計画（プロジェクト計画、テスト計画など）を立てる際の「方針」はどうやって決まるのかを考えてみる。
方針を決めるための材料
「方針」のInputとして思いつくのは下記の点だ。
| 「方針」のInput： ①お客様の意向 ②自社の意向 ③前提条件・制約事項 |
①「お客様の意向」はプロジェクトを立ち上げる前の企画段階で要求事項（”要件”とされているかもしれない）として整理されている場合が多く、プロジェクトの要求事項を整理したドキュメントである企画書やRFPなどにまとめられていると思うので確認しておくとよい。非機能要件としてまとめられている場合もある。システムに求める要件というよりは、プロジェクト計画を立てるうえで整理すべきことを意識する。
| （お客様の意向）例： ・旧システムから新システムへの切り替え作業は長期連休や閑散期を考慮し20XX年12月末とする ・次期システムへの切替は12月31日の22：00～1月1日6：00とする ・本番切替には、徹底したリスクの洗い出しを行うこと ・本番切替には、リハーサル計画を策定しリハーサル実施結果を報告すること ・機能については、スケジュール上すべての実装が難しい場合、必須機能以外はリリース後に実装することを前提とした現実的な計画を立ててほしい ・プロジェクトにかかわる人員の名簿を作成し毎月更新すること |
②「自社の意向」については、プロジェクトを受注する際にお客様に提示した提案書に記載されている場合もあるのでこちらも確認しておこう。
| （自社の意向）例： ・計画書、成果物、報告のフォームは自社既定のものを使う ・品質評価基準は、自社のものを利用する ・開発は自社（専用プロジェクトルーム）にて行い、会議はWeb形式で行う |
③「前提条件・制約事項」は、システム開発を依頼する側と受ける側の両者間で、プロジェクトを進めるうえでこれが覆ると計画の見直しが必要であるととらえるとよい。前提と制約の違いはあまり気にする必要はないかもしれないが、簡単に言うと、
・前提：これが崩れるとプロジェクトが成り立たなくなること（開発方式、スケジュール、環境、体制、プロジェクト運営方法など）
・制約：範囲が決められており拡張できないこと（人。モノ、金、時間、法律、企業イメージなど）
| （前提）例： ・プロジェクトはウォーターフォール方式で進める ・プロジェクトにおける成果物の格納、ファイル交換はXXXを利用する （制約）例： ・新たな税制が20XX年4月1日から開始されるので、それまでに次期システムの切替を完了させ新システムでのサービスを前提とした業務を開始すること ・プロジェクトで使用するPCは、インターネットへの接続はできない |
プロジェクト計画書は、開発側企業にとっては「この内容でプロジェクトを進めます」と顧客側企業と合意するものになり契約内容と同じ意味を持つものと考えている。プロジェクトを進めるうえでの前提や制約はできるだけ漏らさないように双方でしっかりと認識合わせをしておきたい。何を進めるにしても最初の取り決めが肝心だ。
３．どんなことが「方針」となるのか
さてさて、どんなものを「方針」として整理していくのか。これはプロジェクトによる正解があるとは思えないが、今後、プロジェクト計画を立てていくうえで何らかの参考になればよいという程度で気軽にまとめてみた。
まずは、観点と内容を下記に示す。
|
具体的にはこんな感じ。
| (方針）例： ・ユーザーテストは20XX年3月までに終了とする（スケジュール、テスト） ・セキュリティテストについては、外部業者への委託とする（テスト） ・セキュリティテストの内容については、ペネトレーションテストは必須とし、そのほかの検査内容は予算やリソースなどを考慮し全体テスト計画にて検討する（テスト） ・業務移行は、本プロジェクトの範囲外とする（移行） ・ステコミ報告では、その工程の完了状況、次工程への持越し事項、次工程の目標、次工程への準備状況、現状の課題（重要度の高いもののみ）を含める（報告） ・ステコミ報告とは別に、経営層へのプロジェクト進捗報告を20XX年12月中旬に実施する（報告） ・進捗報告会を週1回は開催する（管理、報告） |
あとがき
「方針」については、あまり整理できていないプロジェクトが多い気がする。なんとなく決まったことを計画書に描いてる場面を多く見る気がする。あらゆる観点で検討したうえでの結論としてそれらを書いてあるのでは問題ないが、実際のところは、前回の計画書や他のプロジェクトの計画書を流用して、チョチョイと修正しているというケースが多いだろう。
「方針」の整理があまいと、計画が立てられなかったり（もしくは根拠のない行き当たりばったりの計画になる）、課題につまずいた場合に対策の方向性が見いだせなくなることも多いので、方針の整理は割と重要だと思っている。
正直なところ、自身も整理の仕方をきちん理解しているわけではない。今回は、まずは「方針とは何か」というタイトルで方針の概念をまとめてみたが（いや、あまりまとまっていないが・・・）、結局のところ、それぞれの計画策定に向けてどんなことを方針として整理しなければならないか、というところをもう少し考えてみて整理していきたい。
コメント