プロジェクト計画策定
プロジェクト初期フェーズのプロジェクトマネージャの大事な仕事の1つがこの計画策定です．プロジェクトによって，計画策定が必要か否か，計画書の内容は千差万別だと思います．計画策定の目的を読めばわかると思いますが，3つの目的が完全にクリアならば不要かもしれません．しかし，たとえ少人数であっても，文章に書いて置いておくという事には意義があるではと思います．｢書くということは考える｣ということだからです．書くことで自分自身の思考も整理され，新たな発見があったり，より深い洞察が自然と可能になります．
これから述べるそれぞの項目を全てを網羅して計画を立てるべき，ということではありません．それぞれのプロジェクトの規模に応じて取捨選択されるとよいと思います．中規模開発(30名〜100名程度)の1つの例として書いておきます．
目的は？
プロジェクト計画を作成する目的は，大きく3つあると思います．
- PM自身のプロジェクトへの深い洞察
- ステークホルダに対する説明
- メンバへの意思伝達/共有
プロジェクト計画を決められたフォーマットに従って作成することにより，プロジェクトマネージャとして始めに考えなければならない事に抜けがなくなります．特に初めてプロジェクトマネージャを任された人は，何を考えなくてはならないかの指針になります．米国プロジェクトマネジメント協会（PMI：Project Management Institute）が策定した，プロジェクトマネージメントの実質的な国際標準知識体系である，PMBOK(Project Management Body of Knowledge)(ピンボックと読む)というものがあります．もちろん時間があれば，これに目を通すことでさらに抜けはなくなるでしょう．(PDFはこちらからDL可能)
ステークホルダへの説明は，いまさら言うまでもありません．もっとも重要なのは，最後の項目｢メンバへの意思伝達/共有｣です．意思という言葉を使うと，プロジェクトマネージャという人間個人の意思と思われるかもしれませんが，それだけではなくプロジェクトの意思といってもいいかもしれません．プロジェクトの成功とは，｢メンバ全員で最終ゴールを目指し，それを成し遂げること｣です．僕らの目指す最終ゴールは，どっちの方向またはもっと具体的にどこなのか．どういう道のりで，どういう戦略/手段を使って僕らは行こうとしているのか．これはプロジェクトの意思ですよね．と同時にプロジェクトマネージャの意思でもあります．プロジェクトマネージャの頭の中をわかりやすくみせてあげることは，メンバの人数が多ければ多いほど非常に大事になってきます．
計画の内容
ビジョン
日本語でいうと，将来の見通し，未来像，構想．幻想ではないです．プロジェクトのゴールをシンプルに表現したものかなと思います．ごくありふれた一般的なフレーズ，あいまいな表現，陳腐な言葉ではなく，メンバをぐっとひきつけるフレーズが理想的です．
組織，プロジェクト，チーム，個人のゴール(目標)は必ずしも一致しない事が多いです．そのフレーズの背景や根拠をメンバ全員にしっかり説明し，それがチームや個人それぞれのゴールにどう関連してくるかを意識させてあげることは後々の個人のパフォーマンス，モティベーションに大きく影響します．メンバの視点で考えると，どうしてもプロジェクトのゴールが自分のゴールに合わないと感じたときは，チームリーダーや同僚，もしくはプロジェクトマネージャに相談すべきです．そこがクリアにならないままでよい仕事ができるはずがありません．また話すことでクリアになってしまうことも実は多々あります．
優れたビジョンに備わる5つの品質
- シンプル
- 意図重視(目的駆動)
- 統合
- 閃き
- 覚えやすい
(『アート・オブ・プロジェクト・マネジメント』Scott Berkun)
｢統合｣がわかりにくいかもしれないので補足しておくと，ビジョンの背景や調査結果といった参考資料を無作為に取り込むのではなく，各内容間で整合性がとれた形で，一箇所にまとめて整理するということだと述べられています．
成果物の定義
プロジェクトの成果物に対して，メンバ間で誤解や勘違いが発生しないように明記します．具体例としては，ソフトウェアが搭載されるモデル，システムまたは機種，リリースバージョン，仕向け地域，多言語対応などがあるでしょう．
開発項目
要求開発，仕様策定の進み具合によって，記載される粒度は変わってきますが，それでも問題ありませんのでわかっている事を記載しておきます．システム，アーキテクチャ，コンポーネント，DB，機能，GUI，制限，開発/製造/運用/保守ツールなどが様々な項目があります．普通は機能についてのみ書かれることが多いではないでしょうか．
開発規模，アーキテクチャ，ソフトウェアスタック
主にステークホルダ向けに，今回の開発がどれほどの規模のソフトウェアになるのかをおおまかに説明するためのものです．派生開発の場合は，全体に対する今回の修正/追加の割合や(ソフトウェアスタック上の)修正箇所がわかるようにしましょう．できればグラフィカルなものがよいと思います．設計者向けの資料とは別にこれらを用意するのが普通です．
開発プロセス(メソドロシー)
組織でプロセスが規定されていれば必要ないかも知れません．規定されていても遵守されてない場合，プロジェクトごとに臨機応変に変更している(変更できる)場合，新たなプロセスを採用する場合などは，今回のプロジェクトのプロセスについてメンバに説明しておかねばなりません．メンバによっては，ウォーターフォールやXP，RUPといったメソドロシーについて，全く知らないことも多々あります．これは，若手であろうが熟練であろうが，両方に言えます．Webアプリ開発を学生からやっている若手エンジニアは言葉は知らずとも，アジャイルな方法で開発していることが多く，逆に熟練エンジニアはウォーターフォールしか知らないということがあります．説明の目的は，採用するメソドロシーの言葉の説明ではなく，プロジェクトの進め方の理解であることを勘違いしないように注意してください．
チーム/体制，役割/責務，窓口，一般業務分担
これらの重要性については，いまさら説明するまでもないのですが，よく問題が起こるのもこれらに起因していることが多いです．対外的な窓口はステークホルダ間でよくトラブルになりますので，担当者の任命のみならずやりとりの方法も決めておくべきでしょう．一般業務分担もよくもめます．｢これは私の担当ではない｣というおなじみのやつですね．プロジェクトに共通の，開発環境，機材，サーバ，リリース作業，ドキュメント管理，レイアウト，などの業務は，あらかじめ担当を決めておくことです．問題が発生してからのアサインは誰でも嫌がります．
会議体，指示/報告経路，情報共有
プロジェクトの動脈ともいえるかもしれません．体全体にいつでもフレッシュな血液がスムーズに流れるように，プロジェクトマネージャが知恵を絞るところです．大規模なプロジェクトの場合は，もっとも重要かつ問題な部分でもあります．メール，RSS，Wiki，SNS，ブログといったツールが最近では使われますが，FaceToFaceな口頭でのコミュニケーションがやっぱり重要なのは言うまでもありません．
開発環境
構成管理，自動ビルド/テストサーバ，バグ/課題/スケジュール管理についての記載です．
スケジュール
プロジェクトのマクロな視点でのスケジュールです．オフショアやアウトソース先のスケジュールも忘れずに記載します．チーム毎か機能毎のラインで書くことが多いと思います．
課題/リスク/戦略
担当者と期限は最低限書いておくべきだと思います．プロジェクトマネージャから一方的に指示を出すのではなく，課題/リスクの洗い出しなどはアサインする人にやってもらうか一緒にやるようにしましょう．一方的な指示は担当者のコメットメントがされてない場合が多々あり問題となりやすいです．
戦略は，具体例としては，イテレーションの回数だったり，リリース時期だったりもしますし，ウォーターフォールならば，手戻りを最小限にするためのレビュー，システムリスクのためのプロト実装，下流工程よりも上流工程の比率を増やしたスケジューリングなどが考えられます．人(工数)の流動化であるかもしれません．成否はここにかかっているといっても過言ではないです．
メトリクス
今回のプロジェクトでは，どんなメトリクスをどんな手法で取るのかを明記します．
計画の運用と見直し
計画の策定はプロジェクトマネージャひとりで行うのではなく，過去プロジェクトのプロジェクトマネージャに相談したりしながら，プロジェクトのチームリーダー/メンバや主要なステークホルダといっしょに内容を決めていくことが大切です．計画から参画することで，みんなのプロジェクトに対する意識が変わり，モティベーションもあがりますし，なによりみんなが自分の事としてプロジェクトを捉えやすくなります．
計画ができたら，ちゃんとメンバ全員を集めて説明していますか．Webページに張るだけでは全く意味がありません．プロジェクトマネージャ自身が口頭で説明することで，計画の背景や本当の目的，そして何よりもあなたの熱意/意思が伝わります．人は論理だけでは動きません．感情の生き物ですから．
特に，ステークホルダへの説明の際には，過去の類似プロジェクトの実績やデータの比較資料をバックアップとして用意しておくことをお薦めします．ソフトウェアはみえないですから，なるべくみえやすくしてあげると，ステークホルダのあなたへの信頼はぐっと増します．当たり前のことですが，可能な限り相手の言語で話してあげましょう．ハードウェアに詳しい人ならば，｢ハードでいうと…｣とか，建築や医療にたとえるのも効果的です．
計画は始めに一度作ったら，終わりではありません．内容はかならず変化するはずです．その都度修正しましょう．現状とあってない古い計画なんて，すぐに誰も見なくなります．ブログもそうですよね．大きめの見直しが入ったときは，必ず全員を集めてどう修正したかを説明します．みんなのゴールや道すじのブレは容易にプロジェクトを失敗させます．
よい計画とは？
行き当たりばったり，出たとこ勝負，気合で…，初めからこんな風に考える人はいないと思うのですが，客観的にみるとこういう風にみえてしまうプロジェクトマネージャは実に多いです．結果からみると，この問題は予測できたとか，兆候はあった，あのときあ〜していれば…なんて思ってしまう事はほんとうによくありますよね．
優秀なプロジェクトマネージャはどうするかというと，戦略的な計画を立てるのです．戦略的とは以下の3つを考えることだと思います．
- 綿密な分析
- 問題の予測/仮定
- シナリオの作成
データやヒアリングを駆使して，プロジェクトの現状および既知の問題(課題)を分析/把握します．つまり今の立ち位置をしっかりと認識するのです．次に，未知の問題(リスクほど大きくないもの)や変化(例えば，ユーザの要求やシステムの制限，スケジュールの変更など)を仮定し，それが起きたときにプロジェクトがどう動いていくかを予測します．要はゴール(標的)がどう動くかです．そしてシナリオ(物語)を作っておくのです．リスク管理といってしまえばそれまでですが，これらを熟考した上でたてた計画が戦略的計画になり，プロジェクトを成功へと導きます．
