プロジェクト計画書の作り方｜スコープを明確化する

“目的“を明確化する重要性については以前説明しました。

しかし、その目的は

　達成されなければ意味がない

ものです。

本来、どのような活動・行動であっても、どのようなプロジェクトであっても、資源（時間、人、お金等）を利用する以上、達成できなければ、あるいは達成できなかったとしても別の価値が見いだせなければ、それらはすべて『悪』と断罪されなければなりません。

ビジネスに照らし合わせるなら、会社は株主の持ち物です。
そこで雇われた私たちのものではありません。

通常は社員と経営者、および銀行で持たれてきた株ですが、株式公開されて外部の株主が付くと、彼ら株主が多くの投資を行ってくれたことによるその資金運用において、

　「目的のために投じた資金を、
　　達成もできずに無駄に終わらせました！ﾃﾍｯ」

なんて事態は絶対に避けなければなりません。

喩えて言うなら、母に「晩御飯の材料の買い物行ってきて」と言われてお金を預かっておきながら、自分の欲しいものばかり買って何１つ母の言いつけを守らなかった子供と同じと言うことです。

どうでしょうか。

子供の頃、そんなことをしたら母から怒られませんでしたか？
今、みなさんが親御さんになっていれば、自分の子供を笑って許しますか？

つまり、そういうことです。

目的を掲げ、そのための活動をする、と言ってお客さまと契約し、またお客さまから検収を上げてもらうまでは会社の資金から持ち出されているにもかかわらず、目的を確実に達成するために、最大限の努力を行わない…つまりは、具体的に

　どうやったら目的を達成できるのか

を明確化しない、と言うことは無責任となるということです。

その目的を達成するために、プロジェクトでは

　「何をやらなければならないか（作業）」
　「何を作らなければならないか（成果物）」

すなわち「プロジェクトのスコープ（範囲）」を定義することが求められます。同時に、企業ごと、個人ごとの役割のスコープを定め、役割を十分に遂行できるようにするために役割ごとの権限（裁量）のスコープを定め、その権限と役割をしっかりと果たすようにするために責任のスコープを定めます（一般に言われる「責任の所在」とはコレのことです）。

『目的』を知り、『スコープ』がしっかりと定義されたプロジェクトで開発をしていますか？

もし、まだそう言った開発ができていないようであれば、いい加減与えられた「予算」に見合った責任ある活動を心がけ、計画的に開発できるようにシフトしていきましょう。

「常識は人によって違う」、後でモメないために

プロジェクトを成功させるためには、スコープをあらかじめ明確化しておくことが必要不可欠です。

なぜか？

見積書などでも、未だに「〇〇一式」なんて精緻さの欠けらもない記述が見かけられるケースがありますが、プロジェクトで出来上がるモノ・やるコトが曖昧なまま作業を進めると、

　受注側「そこまでやる必要があるなんて、聞いていないよ！」
　発注側「いや、これをやるのだったら普通それも一緒に作るでしょう！」

と言った“モメごと”が必ず起こってしまいます。不思議ですねー。

起こすべくして起こした人たちが他人を頼らず、自己責任ですべて解決できる自信があるのであれば「〇〇一式」と言う記述でもいいのでしょうけど、そうでなければ価格に見合った価値提供について明文化することは、私たち受注側（価値提供側）の契約義務と思っておいた方が良いでしょう。少なくとも、『契約の会社について揉める』というタスクは、会社としても、契約したお客さまとしても想定していないことで、そこにかかった経費は誰にとっても得しないものだからです。

このような問題を防ぐためには、なによりもプロジェクト計画時にスコープを

　文章や図で“明瞭”に定義して
　関係者達とあらかじめ合意しておく

ことが重要となります。

　「相手もちゃんと分かっているだろう」
　「ここまでやるのが当たり前だろう」

とか、そのような“推測”は厳禁です。日本人がこのことを得意としないのは、「空気を読む」という言葉があるように、

　「責任問題があるから明文化したくない。
　　だけど、受け手はそれすらも察して行動しろ」

という昔からの風土が残っているためです。この考え方は責任スコープをあいまいにするだけでなく、この曖昧になった綻びからなぁなぁの関係性となっていきかねないため、諸外国からは非常に嫌われます。

スコープを明確化する際には「常識は人によって違う」と言う前提で、多少くどくなったり、しつこくなったりしたとしても、きっちりと確認を取らなければなりません。

多少お客さまに疎ましがられても、お客さまに「そこまではしなくていい」と言われても、そう言ったお客さまの勝手な"想い"はビジネスには関係ありません。

ビジネスは、原則として「考える」ものです。
つまりは、頭を動かして進めていくものです。
「思う(想う)」ものではありません。
すなわち、「心」にしたがって進めてはならないのです。

わかりやすいところで１つ例に挙げてみましょう。
たとえば、周囲に

　「俺はそんな風には思わない」
　「私はこう思う」

と口癖のように"思う（思わない）"という言葉を多用する人はいますでしょうか。もし、彼らのあるいはみなさんのその思いに明確な「根拠」の提示がなければ、その言は一切信用できない…と判断していいでしょう。

　相手にしない方が良い

と言っても差し支えないと思います。
思い（想い）とは、直感や感情によって動くものです。その人の個人的な都合や感情が意見のベクトルを動かします。ほんの少しでも自己保身に走ったり、悪意や害意があった場合、それを発見し対策するのは非常に困難になります。最悪の場合、頭の中で考えていることとは真逆のことさえ発してしまう危険性があるのです。

そういう人たちの言の大半は、超個人主義的な感情に縛られていることが多々あります。ですから、そういう人たちの言に乗せられて動いても、まともな達成には行きつきません。

私も稀に「思います」と言う表現を使いますが、大抵の場合は、明確な論拠とは別のところで、個人的な感想を述べている程度にしか使いません（私にも好き嫌いはありますから、理屈とは別のところで異なる感情がある場合、
あるいは同調する場合には「思う」と言う言葉を使うこともあります…が、その際も思いだけしか伝えず、あたかもそれが正論であるかのような使い方をする、と言うことはありません）。

どのようにスコープを明確化するのか

では、具体的にどうやってスコープを明確化すれば良いのでしょうか？

それにはまず、しっかりと情報を集めることです。

全体像を把握できないのに、範囲なんて決められるわけがありません。ベン図の一番外側の枠が無いのと同じです。

よくある失敗が、今ある情報だけで勝手に「これ以上は無理」と決め込んでスコープ定義に踏み切ってしまうことです。そんな進め方でプロジェクトを始めてもまともな進行はできません。「作るモノ」「すべきこと」が明確でないのですから、当然です。

効果的なのは、類似する事例を参考にしながら確認を行うことです。

具体的に言うと、

「根拠をある程度伴い、参考となり、しかしそのことに固執せず、
　臨機応変に行動するためのたたき台(ベースライン)を作る」

「たたき台はたたき台と割り切って、現実を見据え、
　臨機応変にベースラインを改変しながら、最適化を図る」

と言うことです。

たとえば、一般的なプロジェクトであれば、
「前回のプロジェクトはどのように準備したのか話を聞く」
「成功しているプロジェクトの実際の会議体を見学に行く」
などによってあらかじめ情報を得ておけば、“モレ”を防ぐことができたかもしれません。また、プロジェクトのステークホルダー（関係者）から、
「プロジェクトに対して、何を、どこまでやることが期待されているのか」
を十分にインタビューしておきましょう。

この本音が聞きだせるか否かは「プロジェクト」を進めるうえで最重要事項となります。

エンジニアの中にも営業行為をしている人は多いと思いますが、本音が聞きだせないのであれば、無理に営業行為することを推奨しません。特にユーザーと取引先が異なる場合（Tier-2以下となっている場合）、プライムに商社やSIerなどが間に入っていることでしょう。

こうした人々からの本音としての期待値を聞いておかないと、

　「(ふわっとした)やること」
　「金額」
　「あとはその場の状況に応じて適当に…」

だけしか聞いていないと高い確率でトラブル化します。そうでなくても、現場は相当疲弊する状況となることでしょう。大抵のプロジェクトでは、プロジェクトを斡旋してくる商社やSIerの担当や、ユーザーの決裁責任者などが主な関係者となります。

この人たちを巻き込まず、この人たちから必要な情報を得ず、勝手に自チーム内だけの仕事と割り切った時点でトラブル発生率が25%は上昇します。

　「プロジェクト活動なんて計画を立ててもすぐに状況が変化して
　　計画自体が無意味になってしまう」

そう思って多くの人が「計画を立てる」と言うことに対し、否定的な意見を持っていることでしょう。その理由の急先鋒として

　「どーせ計画なんて立てたって、その通りに進められるわけじゃない」
　「現実はそんな、敷いたレール通りに進むものじゃない」

と言うところでしょうか。

しかし、そう考えるのはもはや「一方的な誤りである」と断じざるを得ません。そもそもPMBOKを含め、世界中のありとあらゆる『計画』に対する考え方において、

　計画を立てなさいとは言っているが、
　計画が絶対で、必ず計画通りに進めなければならない
　と謳っているものは１つもない

ということを忘れてはいけません。そんなものはどこを探しても見つかりません。計画を立てても「計画通りには進まない」が当然で、そのことを前提に計画を立てなさいと言っているのです。

過去、いかなる書物・文献においても、「計画立てたら、あとは勝手に計画通りに進みます」なんて言っていません。計画は未来に対する"予測"であって、決して"予知"ではありません。そこを履き違えるからいつまで経っても計画の重要性が理解できないのです。

それでも世の中がこぞって「計画を立てなさい」と言っているのは、計画と現実が乖離した時に、

　「あ、ヤバい（調整しなきゃ or 再計画しなきゃ）」

の判断ができるようになるからです。

上図で言えば、イテレーションサイクル…多くのマネージャーは週単位程度で行っていると思いますが、そうです「進捗確認」がこれにあたります。この時に

「遅れてるのかどうか」
「間に合いそうかどうか」
「計画を見直すべきかどうか」

といった判断が下せるのは、計画が存在しているからです。計画と実績を比較評価することができるからこそ、状況が正確に把握できるのです。

無計画の状態だと、正しい進め方(と思っているもの)から脱線しているのか、脱線しようとしているのかもわかりません。判らないまま突っ走るから、大きなトラブルになってから報告があがり、いきなり気付かされる羽目になるのです。

マネジメントは、計画があって初めてできるものです。

計画を軽視するということは、すなわちマネジメントしないということです。マネージャーとしての責務を果たさないということであり、ひいては管理職の職務を放棄するのと同義と言うことです。

情報が十分に集まったら、スコープの定義を誰もが認識できる形式に起こします。まぁ一般的には資料化します。EXCELでも紙でも、何かツールがあるならそれでもかまいません。大事なのは

　オープンにする

ことです。

また、ここでスコープは２種類あることを忘れないでください。

　「プロダクトスコープ」・・・出来上がる「もの」
　「プロジェクトスコープ」・・・やる「こと」

出来上がる「もの」によって、やる「こと」も変わってきますから、

　“プロダクトスコープ”→“プロジェクトスコープ”

の順番で考えて定義します（たとえば、システムにログイン機能を付ける必要がなければ、ユーザ認証の必要性を検討する作業も不要になりますよね？）。

PMBOK的には、「WBS」とか「アクティビティ」と言う単語で説明されますが、まずはそう言った用語は無視してください。最初のきっかけは、自分たちにとってわかりやすい単語で良いのです。

とはいえ、いずれ協働する他社や取引先とも会話できなければ困るでしょうから、徐々に専門用語を覚えていけばいいでしょう（覚えなくて良いとは言いません）。

ここで、先ほどの例に立ち返ると、見積書などに「〇〇一式」と書くような場合、具体的なプロダクトスコープがまったく分かりません。

「プログラムだけあればいいのか？」
「設計書は必要なのか？」
「お客さま用のユーザーマニュアルは必要なのか？」
「保守・運用時の手順書は？」
「トラブルシューティングはどうすればいいのか？」

など、何もわからないのです。これでどのようにしてプロジェクトスコープを定義できるのでしょうか。そしてプロジェクトスコープ（やる「こと」）もはっきりしないのに、どのようにして見積金額を算出しているのでしょうか。

トラブルプロジェクトにおいて、あとになってから

　「プロジェクトのボリュームがまったく合っていなかった」

と言う報告を受けますが、それはお客さまのせいではなく、見積もった人のスキルや、スコープ…ひいては計画に対する軽視思想に問題があったということです。

スコープを定義する際のポイントは、「境界線を明らかにする」と言うことです。言葉だとちょっと分かりづらいので下図を見てください。

スコープを明確化すると言うことは、つまり図のグレー部分をハッキリさせると言うことです。

たとえば、スコープ内部をお客さま側、スコープ外部を開発側とします。この時、「ユーザーマニュアルは作るのか？作るとしたらどちらが作るのか？」を境界のあやふやなところに置きっぱなしにしていると

　開発側「お客さまが自分で作るだろう（業務の詳細わかんないし）」
　顧客側「開発側で作るだろう（システムの使い方わかんないし）」

と思って、互いに互いがすると思い込んだままとなってしまい、納品直前になって揉め始める…ということが非常に多発しています。

具体的な内容については検討したうえで「仕様書」や「設計書」に記載していくのですから、スコープ内部についてはあまり詳細でなくてもいいでしょう。

範囲の内部、あるいは外部はあっさりとした定義で構いませんけど、範囲の内か外か“微妙”な部分は精緻な定義が必要となります。

先の例で言えば、「〇〇一式」の中に、具体的に何が含まれるのかが定義できていない以上、この円の大半がグレーで埋め尽くされるということです。グレー部分をハッキリさせるための手法として効果的なのは、

　「作らないもの、やらないことを明記する」

ことです。

人は否定的なことを明確に相手に伝えることが意外と苦手です。「これはやりません、それから、あれもやりませんよ！」などと言って、「なんだか非協力的な感じだなぁー」と嫌がられるのが怖く、つい「曖昧なことを曖昧なまま」進めてしまいがちです。

ですが、そういう線引きが嫌で、馴れ合いで仕事をしたいのであれば、それはチームメンバーをふくむ他の人に迷惑をかけないところで自己責任で行ってください。

そもそも、個人の好き嫌いで仕事のスコープを定義すること自体が許されることではありません。もちろんお客さまとの関係性を構築する上で、言い方にも細心の気を配る必要はありますが、ここでスコープ外のものを明らかにしておくことによって、後でモメごとに発展する事態を回避出来るのです。

実際、私も「非協力的」だとお客さまから文句を言われたことはありますが、ちゃんと

　「やるといったことはやる」
　「やらない線引きをしてまで推し進めた以上、絶対成功させる」

ために、できることはすべて最大限の努力をした以上、終わってみれば感謝されたあるいは信頼されたと言う結果になってきました。

最終的には、お客さまが求める「結果(=解決)」が形としてすべて納められれば、お客さまは必ず満足します。なぜなら、取引先の担当の方も、最終的に揉めずに成功させることができれば、取引先企業の中で担当の方の評価も上がり、やった甲斐もあったと思ってもらえるからです。

ここでスコープについての線引きを怠ると、問題は先延ばしにされ、限られた時間が無くなったのちに揉め始め、互いの関係性はもう二度と復旧できないところまでめちゃくちゃになってしまいます。

そうならないために、スコープの線引きは絶対に必要なことなのです。

そして、スコープの定義を書き終わったら、それを顧客、上司、メンバー、外注等、関係者達に十分に説明し、「分かった、OK！」との合意をしっかりと取っておきます。これで計画段階でのスコープの明確化は終わりです。

たとえば、「〇〇一式」ではなく

2.プロジェクトの範囲
2.1.成果物（プロダクトスコープ）
・基本設計書
　　画面設計
　　　画面遷移図 ×１
　　　画面レイアウト定義書（項目定義、イベント定義） ×画面数
　　　メッセージ定義書 ×１
　　ＤＢ設計
　　　テーブル定義書(論理) ×テーブル数
　　　ＥＲ図 ×１～
　　　インデックス定義書 ×索引数
　　機能設計
　　　オブジェクト図 ×ドメイン数
　　　クラス図 ×ドメイン数
　　　ステートチャート図 ×状態遷移数
　　　シーケンス図 ×業務フロー数
・詳細設計書
　　処理遷移
　　　シーケンス図 ×イベント数
　　ＩＦ設計
　　　テーブル定義書(物理) ×テーブル数
　　　ファイル定義書 ×ファイル数
　　　ＤＤＬ ×テーブル数
　　　ＤＭＬ ×ＤＢ問い合わせ数
・プログラム
・結合テストチェックリスト ×イベント数

＜プロジェクト対象外＞
・テストエビデンス
・操作マニュアル

2.2.実施範囲（プロジェクトスコープ）
・報告（定期：部長会／不定期：メール(大幅更新、変更時)）
・プログラムの制作とその過程にある中間成果物の作成
・監視対象プロジェクト情報のデータ化
・データベース構築（仮設）
・Webサーバー構築（仮設）
・PMBOK委員会への操作説明
・一定期間(瑕疵)の保守・運用

＜プロジェクト対象外＞
・マイルストーン以外の詳細なスケジュール化
・運用説明（過去の通達にて運用フローは展開済）
・リリース後のバージョンアップ等
・受決システム以外の他システム連携
・一定期間後の保守・運用（情報システム部に移管）
・仕様変更/追加（スモールスタートおよび２～３年しか運用しないため）

などと詳細化してみるとどうでしょう。あまり長すぎるようであれば、別途WBSなどを用意しておいても良いかもしれません。

こうした定義は、計画書を作成するかどうかに関係なく、マネジメントを嗜む者として絶対にしておかなくてはならないものです。作業全体量を把握できなくて、メンバーにどのように仕事を割り振りすればいいのか、その妥当性を証明、説明できないからです。

適当に"機能"単位で「これやっといて」と言う渡し方しかできない人の下では、

　・まともなマネジメントができない人
　・言われたことだけしかできない人（リーダーになれない人）
　・疲弊して去っていく人

のいずれかしか生み出しません。たまたま、運よく、言い渡された人のスキルと、渡された仕事内容がマッチングした時だけ、こうした事例からはずれることもありますが、まず間違いなく例外扱いとなるでしょう。

こうしたことは、日頃の生活の中でも色々と練習できるものです。

　休日に子供とお菓子を作る
　友達との飲み会のセッティングをする
　パーティを企画する
　旅行の計画を立てる

と言ったものでもいいでしょう。

当然そうした「開発」以外の活動にも使える以上、こうした取り組みは営業や総務などと言った生産部門ではない部署でも、計画的に行わなければならない活動であればどこにでも適用できます。