プロジェクト計画書の作り方｜目的の明確化

『計画を立てる』

それは実際には「プロジェクト計画書」という書類を作り、関係者へ周知し、合意を得ることを指しています。個人スケジュールであれば個人の中で決めておけばいいことですが、集団活動の場合

　"関係者へ周知し、合意を得る"

は100%必須な行為です。そしてそれは内部の人たちに対してだけでなく、顧客等の外部の人たちに対しても同様です。これは先に金額や期限のゴールが定められたようなビジネスでは「任せるに値するか否か」を決めるうえで重要な指標となるからです。

様式はどんな形でも構いませんが

　「自分以外の第三者が見てわかるもの」
　「メンバーが活動するにあたって不備がないもの」
　「最新版となっているもの」
　「関係者間で合意されているもの」

であることは『計画』という存在であるうえでは必須と考えておいた方がいいでしょう。

そしてそれら計画を言語化し、可視化を図ったものがプロジェクト計画書となります。プロジェクト計画書とは、そのプロジェクトで取り組む範囲（スコープ）や作業スケジュール、体制、想定されるコストなど、主にプロジェクトの推進にあたって予定している事柄を記した書類のことで、プロジェクトメンバーはこの計画書に沿って作業を進めることになります。

計画書を作ってはみたけれどもプロジェクト進行中、

　・１度も見ようとしなかった
　・「計画書通りに進めるためにはどうすればいいか」を検討しなかった
　・「どうせ計画通りになって進まない」と思っていた

と言うマネージャーは、もうこの時点で残念ながらマネージャー失格です。「マネージャー」が何の役割を担っていて、どんな責任があるのかわかっていないはずです。リーダーではあるのかもしれません。良くも悪くもメンバーを牽引するリーダーシップはあるかも知れません。しかし、マネージャーとしては全くダメダメです。

　「多くの利益が出ていれば別にいいじゃん」
　「終わりよければすべてよしじゃないの」

と言う人もいるかもしれませんが、そんなことはありません。

もし、それでも自分が正しいと思っている人がいれば、あと１年同じやり方で進めてみてください。もしこれが１年プロジェクトでもある"経営"であったならば再来年の監査か株主総会あたりで、八方から突き上げを食らうことになるでしょう。

マネジメントにおいて重要なことは、

　先に宣言し、宣言通りに終わらせる

という当たり前の責任を、全うする（させる）ことです。
稼ぐか稼がないかではありません。仮に

　「１億の利益を出します！」

と宣言して

　「あ、やっぱ２億出ちゃいました(ﾃﾍ」

と言うことをやっていれば、投資家から大目玉を食らうことでしょう。投資家にとって"売り"と"買い"のタイミングを見計らうことができないからです。経営者（運営者）の発表や報告は何一つ信用するに値しないと判断されるのは明白です。なにせ、良くも悪くも発言に責任を持てないということ、有言実行しないということで、そんな人間や会社の何を信用して投資すればいいのかわからないのですから関心は薄れ、株価の暴落は避けられません。

ですから、マネジメントを担う責任を持つ人種に必要なことは、

　先に宣言し、宣言通りに終わらせる

と言うことに尽きるのです。

すなわち、実行前に綿密な計画を立て、計画通りに完遂させ、できるだけ誤差が無いようにするということなのです。あらかじめ計画を立てないことも、計画通りに終わらせないことも、社会的に見ればマネジメントとして忌避すべきことなのです。

計画の形骸化は計画的に行われる

システム開発（構築）を「モノづくり」と考えがちなプログラマーやエンジニア、あるいはそうしたポジションから叩き上げで昇格してきたリーダーやマネージャーは、ここが理解できていない人が多いのです。

そもそも計画書自体を「書いたことさえない」と言う人も多いかもしれません。そんな状態から無理やり「書け」と言われ、正しい方法やマネジメントも教わらないまま計画書を書かされると、そりゃ

　・１度も見ようとしなかった
　・「計画書通りに進めるためにはどうすればいいか」を検討しなかった
　・「どうせ計画通りになって進まない」と思っていた

が常態化するプロジェクトが増えるのも無理はありません。挙句の果てに「計画通りに進めるつもりは全くない」と言い切るマネージャーも出てくるほどです。曰く

　「監査するために作るものじゃない」
　「本質的な品質とは関係ない」

とも言い放つ子もいたほどです。そんな開いた口が塞がらない状況を許す環境というのも案外身近にあるものです。結局、彼のやり方を許してしまうと、

　結果が正しくなるかどうかは、結果が出てからのお楽しみ

というギャンブルのようなビジネスを許容するということでもあります。そんな組織、そんな企業をお客さまはどうやって信用すればいいのでしょう。

一応計画は作るのかもしれません。
その一応作られた計画書は体裁が整っているかもしれません。
だから合意形成は可能なのかもしれません。

でも実際にはその計画書通りに実施するつもりはないし、計画書通りに実施しなくても品質的には問題が無いと思っているし、その自信がある…というわけです。

…これって少なくとも傍から見ればギャンブル以外のなにものでもありませんよね？

というか、最初から計画通りに実施する気が無く、だけど"嘘"の計画書を作成するわけです。端的に言えば

　計画的に、計画通りに遂行しない

ことを最初から決めているわけです。こうした部分は案外他のマネージャーたちにも見受けられる点が多いのではないでしょうか。

実現性が高く、その通りに実施すれば計画通りに完遂できるような計画書を作成するというのはたしかに大変です。

特に「不確実性」が高いと言われるプロジェクト運営の場合、計画通りに物事が進むとは限らないのが実情で、都度計画の見直しを要求される負担も大きいものです。

ですが、想定外の状況を除く範囲においては、計画をしっかりと練り込んでその内容を明文化しておかなければ、関係者とプロジェクトの進め方を正確に共有することができません。

プロジェクトの実際の作業に早く取り掛かりたい気持ちも分かるのですが、ここで計画書を丁寧に作っておくことで後の作業のスムーズさは断然違ってくるのです。特にこれまであまり一緒に仕事をしたことのないメンバー…つまり「あ・うんの呼吸」が通じない相手と共にプロジェクトを実施する場合、「アイマイでイイカゲンな計画書」が、往々にして無駄な作業や致命的なミスの原因となってしまうのです。

マネージャーにとって、メンバーに対し、自分が思った通りに活動してもらい、確実な成功を納めさせたいと思うのであれば、ここはグッとこらえて「急がば回れ」を心掛けましょう。結果的にそれが最も効率的になります。

また、プロジェクト計画書を作る際には重要なポイントがもう一つあります。

それは、計画書はプロジェクトマネージャー１人で悩んで作るものではなく、プロジェクトの主要メンバーに予定している関係者達をしっかり巻き込んで作り上げるものだということです。

プロジェクトの進め方を相談したり、一緒にアイデアを検討したりすることで、計画の精度が上がるだけではなく、メンバーの参画意識を高めることができますし、メンバーがより具体的な作業をイメージできるためパフォーマンスが向上しやすいという側面もあります。

　「プロジェクトマネージャーから与えられた計画」

ではなく、

　「共に知恵を出し合って作った計画」

として、より主体的にプロジェクト推進に協力して貰える関係をここで築いておくべきなのです。なお、プロジェクト計画書の書き方にもいくつかの流派みたいなものがあったりしますので、そこで揉めないように調整することだけは忘れてはいけません。それもマネージャーの醍醐味と言えるのではないでしょうか。

最初に明示すべき内容

プロジェクト計画書で最初に記載すべき内容、それはそのプロジェクトの

　「目的」

です。

プロジェクトを実施するからには、

　「なぜ、お客さまはそんなプロジェクトを発注してきたのか」
　「なぜ、我々はそのプロジェクトをやるべきなのか」

という「ハッキリした目的（最終目標）」がなければなりません。

そうでなければ、要所で設けるゴール（目標）の設定があやふやになってしまうからです。しかしその目的が不明確なプロジェクトがなんと多いことでしょう！

たとえば、「ご飯を作る」と言う目標があったとします。
その理由は

　「おなかがすいたから」
　「おなかがすいた状態を続くと餓死するから」
　「餓死するわけにはいかないから」

であり、その結果として、

　「餓死しないために」
　「生きるために」

という目的があるから、目標として「ご飯を作る」ができあがるわけです。

たとえば、「美味しいご飯を作る」と言う目標はなぜできるのでしょう。
その理由は

　「食べてくれる人が、マズそうな顔をするから」
　「美味しいご飯の方が良いに決まっているから」

だったりするのでしょう。
その結果として

　「食べてくれる人が美味しそうに食べてくれるために」
　「美味しいご飯を食べて、幸せを感じるために」

と言う目的ができ、その目標として「美味しいご飯を作る」が出来上がるのではないですか？

これらと同じことを仕事の中でも明確にしましょうというだけのことです。

みなさんはなぜ、その仕事をするのですか？
その仕事は本当に必要なことですか？
その仕事は本当にお客さまの予算を費やしてまですることなのですか？
その仕事をすれば、お客さまが対価として支払うに値する成果物を確実に納められるのですか？

今まで考えたこともなかったかもしれませんが、なんとなく作業していたのではこれからも他人を巻き込む計画というものを実現することはできません。常に嘘をつき続け、常に自分の中で何となく正しいと思う"我流"を貫き通し、いずれその我流が通用しなくなって後悔するまで延々と繰り返されていくのでしょう。

プロジェクトの目的は、そのプロジェクトの根本…スタートラインになった時に"はじめの第一歩"を間違った方向へと進めないようにする重要なものです。

目的があって初めて

　「プロジェクトで何をするのか（しなければならないのか）」
　「プロジェクトをどうやって進めるのか」

をしっかり決められるのであって、根本がグラグラした状態でプロジェクトを行うと次のような重大な問題が起こってしまいます。

・プロジェクトにおいて何を優先すべきで何を切り捨てるべきか、
　適切な判断ができない
・プロジェクト終了時、目指すゴールが達成できたのか
　（つまりプロジェクトが成功したのかどうか）を評価できない
・プロジェクトの関係者の意思統一ができず、メンバーのモチベーション
　（やる気）低下を招く

目的とは、プロジェクトによって「何を手に入れたいのか」「何が嬉しいのか」「何で満足するか」を明らかにするものです。これによってプロジェクトの母体となる組織（企業など）のベネフィット（便益）と、プロジェクトの活動を結びつけることができ、プロジェクトを行うことの必要性が説明可能になります。

逆にそのことが明確になっていないというのは

　「企業の便益なんて無視したい」
　「給料がもらえれば何でもいい」
　「とにかく自己満足以外に興味がない」

と言っているのと大差はありません。そう考えると、むしろ実現性の高い計画をしっかりと定めていない、計画を実現するための努力をしていないマネージャーを野放しにしている企業が非常に多いことに驚きです。

ちまちまと小規模のプロジェクトですべて手が届く範囲内にあるからかろうじてコントロールでき利益を損なわずにいたとしても、それは結果論でしかなく、何一つ信用できるプロセスをなっていないはずなのに、とにかく利益が出ていれば手放しに褒めようとする組織は未だに後を絶ちません。

だからある時にトラブルプロジェクトが起きると、自分たちでは何もできないんですね。トラブルを起こしかねないマネジメントを自分たちで推奨し続けてきた結果です。

さて「目的」の重要性については、少々マネジメントの知見があればなんとなくわかっているマネージャーというのは多いと思います。

ですが、計画書に「目的」の記載項目自体はあっても、その内容が適切ではないケースが非常に多いのをご存じでしょうか。たとえば、次のようなパターン（不適切な目的設定）です。

目的と手段を混同している

「AとBの情報システムを1つに統合する」

こんな目的を掲げるプロジェクトを見かけることがあります。
…子供のオウム返しを見ているようです。

これだけでは「何故そうしたいのか」、「何を手に入れたいのか」、「何が嬉しいのか」がピンときません。システムを統合することは手段（プロジェクトで何をやるのか）であって、目的（何のためにやるのか）ではありません。目標としては間違っていないかもしれませんし、契約上のゴールはそこまでなのかもしれませんが、これを目的としてしまうと

　「統合しさえすれば、他はどうでもいい」

と言っていることになりませんか？

情報システムの統合がゆるぎない方針として決まっているのであれば、そのことを目的の文章として含めることは否定しませんが、必ずそれによって得ようとしているものを明確化しなければなりません（例えば、「AとBの情報システムを1つに統合し、業務コストの削減と顧客サービスの向上を実現する」など）。

なぜそのような目的を設定したのか、理由が説明できていない

「目的」はプロジェクトの根本を成すものですから、当然マネージャーは「目的自体が適切であること」が関係者に説明できるようになっていなければなりません。

設定した目的について問われて「いや、だってお客がこれをやれって言うからさー」と開き直りたいかも知れませんが、それはお客さまの意図を理解していない、あるいは意図を汲み取っていない証拠です。

それではマネージャー自身も、プロジェクトメンバー達も、やる気も出なければ、責任感も沸きません。言われたことを言われたとおりに実施しようとするロボットと変わりありません（そんなことをしているから、「いずれAIに取って替わられると言われるのです）。

設定した目的が適切であることを説明するには、プロジェクトが立ち上がった「背景」を捉えておくことが必要になります。これはマネジメントをするものであれば、プロジェクトであるかどうかに関わらず、全員に存在する「説明責任」というものです。

常に説明責任を果たす覚悟がない人はマネージャーに向いていません。

つまりプロジェクトの母体となる組織が置かれている状況やその組織が向かおうとしている方向性、そしてそのために今課題となっていることなどを、プロジェクトの目的と関連付けて理解しておくということが必要なのです。

いっそ、プロジェクト計画書にもその「背景」を整理して書いておきましょう。それによっていつでも明確に説明することができますし、プロジェクトメンバー達の目的意識も一段と深いレベルで共有できるはずです。

具体性に欠けており、達成を判断できない

プロジェクトが成功したかどうかを評価できるよう、目的は具体的であるべきです。もちろん具体的に書く以上、必ず達成する責任と覚悟が伴わなければなりません。口先だけの薄っぺらい表明はいらないのです。

数値目標はプロジェクト計画書の別の項目で設定することも多いと思いますので目的の項目ではそこまで詳細化しなくても構いませんが、ゴールとして「どのような状態を実現するのか」定性的にでも評価できるようになっていなければなりません。

ただし、多くの場合プロジェクトのゴールを明確化するためには、複数の状態を定義しなければならず、それらを目的として一連の文章にすると逆に分かりづらくなってしまいます。

個人的に、オススメとしては「目的」を簡潔かつストレートな表現で書いた後、「目標」としてゴールの状態を箇条書きで定義していくことです。

「目的」…プロジェクトによって手に入れるものや嬉しいことの「方向」
「目標」…その方向に向かってどこまで走ればゴールかをあらわす「状態」

と考えていただければ分かりやすいかと思います。

1.プロジェクトの目的
1.1.背景
近年、当社の規模は拡大傾向にあり、着実に市場開拓に向けて歩みだした現在、今後も各プロジェクトがおおむね順調に推移しさえすれば、拡大傾向が続くものと予想される。そのような状況の中、当社の中で１つの課題となっているのが、「年間のトラブル発生率」とその「規模」である。１つトラブルを減らせば、容易に７桁８桁の利益改善が見込める。
しかし、いまだ多くのＩＴ企業が割拠する中、市場における様々な競争が苛烈になってきており、高品質であることが既に当たり前として求められていながら、さらなる付加価値を提供するサービスが要求されている。
今後も業界の地位を獲得・向上していくうえで、当社のシェアが低価格や高技術を武器とする新興企業に脅かされないための土台作りが必要となってきた。
当社では、〇〇地区（または〇〇業界向けシステム）を中心に築いてきたこれまでのブランドイメージを守るため、サービスのさらなる向上を図りつつも、既存コストを低下させず、無駄な出費となるトラブルを低減し、高品質が当たり前となる競争力を確保することが最優先の経営課題となっており、品質、およびマネジメント、コミュニケーションなどのトラブル原因となっている業務および既存の開発プロセスの改革を進めることが急務となっている。
このプロジェクトは、その改革の一環としてプロジェクト監視業務とその仕組みの効率化を図るために実施するものである。

1.2.目的
情報システムとして、監視対象となったプロジェクトの状況を適宜管理し、
営業、技術の業務コストの削減と各部門長の管理・監督業務の向上を実現する一方で、それらのデータの「視える化」「データ共有」を行い、過去の経験の再利用によって、成功からの引用を、失敗からの反省と改善を全社員へ展開する。

1.3.達成目標
・ 営業、技術部門それぞれのオペレーションコストを大幅に削減する。
・ 管理職会などで報告されるプロジェクトの監視コストを削減する。
・ マネジメント不良の根源的原因の発生頻度を低減する。
・ 計画や振り返り等のリードタイムやスイッチングコストを短縮する。
・ 紙やEXCEL運用、口頭だけの属人的な管理体系からの脱却を推進する。

どうでしょう。

まぁ、なんとなく頭の中で「プロジェクトの状況をリアルタイムで確認できるシステム」があったらなー…と思って、成長途上の中堅企業をイメージしてみました。

ここまで10分ほどです。

明確に目的を持った活動を日頃から心がけていれば、この手の作業はあまり苦になりません。一つひとつの業務、作業にも意味があり、その意味を最大値化することを意識していれば、日々「これは何のためにやってるんだろう」「どうすれば最も価値が高まるんだろう」と考える癖が身につきます。何か優れた才能や能力は必要ありません。

成果をあげる人とあげない人の差は才能ではない。いくつかの習慣的な姿勢と、基礎的な方法を身につけているかどうかの問題である。しかし組織というものが最近の発明であるために、人はまだこれらのことに優れるに至っていない（P.F.ドラッカー『非営利組織の経営』）

ただただ年単位で継続し、習慣化にまで達すれば、さほど苦労することはないでしょう。

上記の例のような構成で書かなければならない…という訳ではありませんが、計画を立てる際にはこのような視点をしっかりと意識してみてください。

これができなければ、

　「何のために計画するのか？」

を理解することはこの先も難しいのではないでしょうか。