プロジェクト計画書を任せられた
上司：「来月から始まるエスアイ社向けの開発案件、お前に任せる。」
私：「はい、わかりました！初めてですがPMとして頑張ります！」
上司：「よし。それじゃプロジェクト計画書を作ってくれ。」
私：「かしこまりました！」
「…しかし、勢いよく返事をしたものの、プロジェクト計画書って何だろう？」
なんて、そんな経験はないでしょうか？
「私」はITベンダーとしてパッケージの導入、開発に携わっていましたが、そんな「私」の過去の経験から、新任PMに向けてプロジェクト計画書についてお話ししたいと思います。
プロジェクト計画書ってどうして作る必要があるの？
私：「プロジェクト計画書か、なんだか沢山資料を作らなきゃいけなさそうで面倒だな。そもそもなんで書かなきゃいけないんだろう。」
最初、「私」はプロジェクト計画書を作る意味をわかっていませんでした。
会社が決めているフォーマットの項目を埋め、プロジェクト計画書を作成するのですが、手続きとして必要なんだという認識でそれまで一度も使ったことはありませんでした。
では何故プロジェクト計画書が必要なのでしょうか。
それに気づいたのはプロジェクトメンバと認識違いがあった事からでした。
とあるお客さんに対して受注システムの改修を行うプロジェクトに参画していた時の事です。
「システム改善による業務効率の向上」をプロジェクトの目的として進めてきたのですが、基本設計をしていたメンバのAさんから
「今回の修正は、画面入力のみで取込機能の修正は必要ないですよね。」
と言われて、ハッとしました。
このお客さんでは伝票数が多く、取込機能を使わないわけがないのですが、Aさんは目的を理解しておらず、改修すべき取込機能を重要視していなかったのです
こういった事態はIT業界では珍しくはないと思います。
PMの目の届くような小規模な案件ならば上記のように早々に気付いて方向転換が出来ますが、サブPM、サブPLを置くような大規模案件では発見が遅れ、結果、当初の目的が達成できず最悪の場合は「作ったはいいが、使われず、作り直しになった」などの結果に陥る事もあります。
プロジェクト計画書としてプロジェクト開始時に達成すべき目的として明確にしておくことで、メンバに共通認識を持たせて、チームで動くための指標とする事が出来るのです。
プロジェクト計画書には何を書けばいいの？
私：「プロジェクトの計画を立ててみようと思って、スケジュールや工数見積を作ってみたけど、結局、プロジェクト計画書には何を書けばいいのだろう。」
プロジェクト計画書を作成する必要性はわかりましたけど、では具体的に何を書けばいいのでしょうか？
納期やスケジュール、コスト、それとも成果物でしょうか。
確かにプロジェクト計画書を広義に「プロジェクト全体の計画」と捉えるならばスケジュール表や工数見積書、要員計画書、リスク一覧や品質基準の設定、顧客と合意を取るもの、取った後に詰めるものなど様々な資料が計画に当たると思います。
これらの資料にはプロジェクト責任者として守るべきQCDが定義され、プロジェクト成功に導くための目標やプロジェクト管理手段も記載されていますので、広くはプロジェクト計画書（の一部）と言えるでしょう。
しかし、これら手段をメンバと共有したとしても、そもそもの目的をメンバが理解していなければ、メンバが自発的に動くような場面で誤った方向を向いてしまう事があります。
「私」も最初は目標を達成する為にはどうすればいいのか、という手段の共有に目が行ってしまい、結果としてメンバとの認識齟齬が生まれてしまいました。
これらを踏まえて、本質的にプロジェクト計画書には何を記載すべきなのか、というと前段にも記載した通りですが、状況が常々変化するプロジェクトの中で目指すべき旗として役割を果たすには何が必要なのか、どうなったらプロジェクトが成功となるのかを定義、記載します。
具体的には
・お客さんが求めている達成すべき目的（ゴール）
・いつからいつまでの期間で実施するか（スケジュール）
・誰を責任者とし、どんな体制でプロジェクトを進めるのか（要員体制）
・どんな作業をし、成果物を作成するのか（スコープ）
上記はどれも目的を達成する為に明確にしておくべき要素です。
どれか1つでも不明瞭ではプロジェクトを実施していく中で、期間内に作業が終わらない、指示が上手く伝わらない、未着手の作業が残る、などのリスクが発生する原因となってしまいます。
逆にいえばこれらをメンバ全員が認識し、プロジェクトが完了するまでブレなければ、そのプロジェクトは計画通りに進められ、成功に導けるでしょう。
ただし、会社によっては上記で紹介したような記載項目の他にも書くべき内容があるかと思います。
その会社が培ってきた独自のノウハウから様々な観点でプロジェクト計画書への記載をルール化している事なので、その場合は何故記載が必要なのか背景を理解した上で、ルールに従って記入が必要です。
プロジェクト計画書を作成する為に必要な事
私：「うーん、今回任されたプロジェクトの目的か…なんて書けばいいんだろう？」
プロジェクト計画書に書くべき内容は分かっても、どう記載すべきか迷いませんか？
「私」も最初は目的を捉えられず、漠然としてしまう事がありました。
この段階でお客さんからの要件書、合意出来ている資料などがあれば、そういった資料を読み返してみるのもいいでしょう。
資料がなければ、過去のプロジェクトを参考にしたり、営業打合せに参加した時の会話を思い返してみたり、今こういう事に困っている、とかこういう事を新しくやりたい、といったところから達成すべき目的を検討してみるのがいいでしょう。
とにもかくにも情報を集める必要があります。
プロジェクトに参画するタイミングもありますが、今までどういう話をお客さんとしてきたのか、という点は押さえておく、営業さんと情報共有しておくことなどがプロジェクト計画書を作る上では重要なポイントになると思います。
プロジェクト計画書って作るだけじゃダメなの？
部下：「○○（私）さん、先日の体制変更で、PLとしてこのプロジェクトを進めさせて頂きます。よろしくお願いします！ 」
私：「うん、途中からの参画で申し訳ないけれど、よろしく頼むね。」
部下：「はい、任せてください。早速ご報告ですが、前回の先方から依頼のあった仕様変更の件、上司と相談して、先方にお受けしますと回答しておきました！」
～上司に確認を取ってみると～
上司：「え、PMを通していると思ってOK出しちゃった。」
…と、部下が勝手に顧客と合意してしまい、実行予算やスケジュールを変更する羽目になってしまった。
上の会話はいささか極端だと思うかもしれませんが、実際に起きた出来事です。
幸いにも私の経験したプロジェクトでは赤字にはならずに済みましたが、一歩間違えれば計画していない大量の作業を請け負わないといけない事態になってしまったかもしれません。
今思い返してみれば、当時はプロジェクト計画書の運用が形骸化していた事、作るだけでメンテナンス出来ていなかった事、新しく参画したメンバなどに周知出来ていなかった事が原因だと分析できます。
特に計画書に含めた役割・体制やルールなどはメンバ間できちんと認識を合わせるべきでした。
プロジェクト計画書を作るのは何度も検討したり、会社によっては稟議を通したりと、とても大変で、一度作ってしまうとなかなかメンテナンスするまでパワーが割けない事も多々あります。
しかし、工程の切り替えやメンバが入れ替わるタイミングなどの各ポイントで見直したり、改めて周知したりするだけでも、上記のようなリスクを減らす事が出来ます。
せっかく作ったプロジェクト計画書を活用してみてはいかがでしょうか。
弊社でのプロジェクト計画書
文章だけではイメージしにくいと思います。
弊社ではプロジェクト管理ツール「SI Object Browser PM（以下、OBPM）」を用いてプロジェクト管理をしておりますので、どのようなプロジェクト計画書を作っているのかご紹介します。
弊社では下記のようなプロジェクト計画書を作成しています。
営業段階を経て、お客さんと目的、スケジュールや費用、成果物などを合意した後、OBPMにプロジェクトを作成し、目的や期間、作業内容や成果物などを登録し、承認ワークフローを回す事でプロジェクト計画書が出来上がります。
別途Excelでプロジェクト計画書を作成する必要がなく、営業から提出した見積などを添付しておけるので、OBPMに情報が集められる点がとても便利です。
プロジェクトが開始してからもOBPMを見れば当初の計画などがわかるので、スタート時点に立ち返ったり、計画を見直したりといった場合でも活用する事が出来ます。
＜プロジェクト管理ツール OBPMのプロジェクト計画書＞
こういったツールを上手く活用し、プロジェクト管理をしやすくすることも、プロジェクトの成功率を上げる要因だと感じています。
