プロジェクト計画書の作り方｜作業リストを作る

プロジェクト活動において「スコープ明確化」の次にやることは、そのスコープの中で実施すべき“作業”を洗い出してリスト化することです。

スコープとは「範囲」です。

　どんな作業をするのか
　どんな成果を作成するのか
　どんな責任を負うのか

などの範囲を明確に決めることです。それらのスコープを、スコープの境界線を明確に定めたら、次に行うべきはそのスコープ内の"作業"を明確にすることです。

まぁそもそもこれが自分たちの業務ですらできないようなら、業務システムにおいて、要件定義ができるスキルはないと言っても過言ではありません。なぜなら「自分の範囲内の作業を洗い出せない／整理できない」ということは「業務フローの作成ができない」と言っているようなものだからです。

先の見通しがない仕事にお金や時間を投じることはできません。もちろん見積書の見積り根拠もあいまいで信用できるものにはなりません。

そこで、「新たなチャレンジ活動」であるプロジェクトであったとしても、計画段階でスケジュール表を作成したり、必要な作業量を見積もったりして
懸命に“モヤモヤ”を取り除いて「プロジェクトの見通し」を立てる訳ですが、それらの“基礎”になるのがこの作業リストです。

また、プロジェクトで実際に作業を進める際にはそれぞれの作業の進み具合などをこのリストの項目毎に確認することになります。つまり「作業を管理するための単位」にも利用することになる訳です。

したがって、作業リストはプロジェクトの計画や実行時の管理の根幹となるものであり、

　「プロジェクトの背骨」

といえる非常に重要なものになります。

逆にこうした作業リストを作成しなかった時のことを想定してみましょう。

たとえば、

　・プロジェクトの目的（なぜ、プロジェクト活動するのか）がわからない
　・プロジェクトの目標（どうなったら終了なのか）がわからない
　・プロジェクトのスコープ（何を作り、何をするのか）がわからない

と言う状況で開始して、どんな作業をするべきかも洗い出さない状態で

　「〇〇を作成しました」
　「進捗は50%です」

と言えるでしょうか？
また「〇〇作成、進捗50%です」と聞いて、

　「よし、順調だな」

と判断できるでしょうか？

何を根拠にそう言えるのかはわかりませんが「できる」という人もいるかもしれません。けど、すいません。私は絶対にできません。むしろできる人がいたら、その人から教えを乞いたいくらいです。

作業リスト作成における原則

たとえ計画時に作業を洗いして見通しを立てていても、後になって作業リストに“漏れ”が見つかると、その見通しが崩れることになってしまいます。

しかし、慌てる必要はありません。

漏れることも、計画通りに進まないことも想定の範囲内です。そもそも未来予知ができるわけがないのですから、どんなに計画通りとなるようコントロールしたところで、予想外のことは起きるものです。

そのような漏れがあった場合には、その作業を追加で行わなければなりません（それを諦めるという手もありますが、プロジェクトの目標に影響を及ぼすような漏れは簡単に諦めることができません）。

作業が増えるとなれば、スケジュールを伸ばさないといけないかも知れません。要員や予算を積み増す必要もあるかも知れません。

インパクトが小さい漏れであれば良いのですが、致命的な漏れが発見された場合には即座にプロジェクトを窮地に追い込むことになってしまいます。

ですから、本当に誰から見ても「想定外」と呼べるようなものはともかく、そうでない範囲において、最低でも deliverable（後ほど説明します） となるよう過不足のない作業を洗い出すことは、計画をするうえで決して疎かにしていいものではありません。「責務」と言えばわかるでしょうか。

当初計画の時点で「漏れなく作る」、これが作業リストを作るときの一つめの原則です。

ただし、ここで勘違いしてはなりません。

　「作業リストを漏れなく作る」＝「作業リストを細密に作る」

ということでは必ずしもないからです。

もちろんプロジェクトの見通しを立てるためには細かく作業リストを洗い出すべきなのですが、あまりにも細か過ぎると今度は別の弊害が起こります。

「○○さん、9時から9時4分の間に、
　設計書の日付欄を和暦で埋めることになっていますが、
　できていますか？」

「○○さん、9時4分から9時8分の間に
　設計書の作成者欄を埋めることになっていますが、
　できていますか？」

ちょっと極端な例ですが、こんな調子では確認する方も確認される方もヘトヘトになってしまいます。

作業リストは「日付を書く」「作成者を書く」…ではなく、「設計書の必要事項を埋める」が入っていれば良いのです。

“日付”を「和暦」から「西暦」に変えたからと言ってスケジュールにほとんど影響ないでしょうし、それによっていちいち作業リストやスケジュール表を更新する負担もなくなります。

大雑把過ぎず、細か過ぎず。

これも作業リスト作成における原理・原則です。

作業リストは階層的に作る

では、実際に作業リストを書いてみましょう。
たとえば身近な例として、スーパーに買い物に行く際の作業リストを考えてみます。

　1. きゅうり1本を買う
　2. シャンプーを買う
　3. 牛スジ100gを買う
　　　・
　　　・

…と、思いつくままに書き出してみましたが、これだと洗い出すのが難しいし、本当にそれだけでいいのか漏れが起こりそうです。

そこで、作業を段階的／階層的に考えて洗い出すことにします。

いかがでしょう。

大きな作業から初めて段階的に詳細化すれば考えやすいですし、漏れも少なくなります。このように作業リストは階層的に洗い出して書き出すことが基本となります。

こういった考え方はMECE（漏れなく、ダブりなく）な考え方と言いますが、こうして構造化することを

　WBS（Work Breakdown Structure）

と言います。

WBSとは、プロジェクトマネジメントで利用される計画手法の一種で、プロジェクトにおける作業を細かい単位に分割し、階層構造などで管理する手法のことです。

WBSでは、最初に必要な作業の洗い出しを行い、可能な限り細分化し、それぞれの作業について必要なコストや人員配分を割り出します。PMBOKを導入しているマネジメント主体の企業では、当然のごとく行います。

これによって、作業全体の把握や各作業の体系的つながりの把握を行うことができ、進捗管理や計画の調整に関する精度を向上させることができるからです。

WBSにおいて細分化された作業の要素は「ワークパッケージ」などとよばれており、作業リストとは要するにこのワークパッケージの一覧ということになります。

これが作成できないと、計画の本題に移れません。

なぜなら、

　「誰が」
　「何を」
　「(いつから)いつまでに」
　「どのように」

作る(する)のか、と言う計画のうち「何を」の部分がハッキリとしないためです。

「何を」がハッキリしないと「誰が」が決まりません。なぜなら「何」の難易度によって、選定すべきエンジニアの要求スキルが異なるからです。

そして「何を」と「誰が」が決まらないと最低限のスケジュールも決められません。「何を」には順序性があります。なんでも自由に始められるわけではありません。先の料理を例に挙げると、おでんを作ろうにも下ごしらえをしないままいきなり作ることはできませんよね。

どんな活動にも

　「Ａの成果物が完成しないと、
　　Ａを参照して作成するＢの成果物に取り掛かれない」

と言った相関関係のある作業や成果が存在します。

そして人は同時に2つのことができません。

　「Ａの作業をしてもらいながら、ＣとＤの作業も同時に実施してもらう」

と言うことは現実的ではありません。

そのため「何を」と「誰が」が決まれば、次は「(いつから)いつまでに」を決めることになります。

最後に、それぞれの成果物や作業に対して、ルール、基準／標準、規程、手順などを明確にすることで、一つひとつのプロジェクト活動においてメンバーが迷わなくて済む、プロジェクト計画が完成します。

もしも今までに炎上プロジェクトやトラブルプロジェクトにかかわったことがあるエンジニアの方がいらっしゃれば、思い返してみてください。

プロジェクト発足時点で

「誰が」
「何を」
「（いつから）いつまでに」
「（具体的に）どうやって」

実現するかについて、メンバーの誰もがわかる形で用意されていたでしょうか。「アレが決まってない」「コレのやり方がわからない」そんな状態になっていた李はしていませんでしたか？

もし、あらかじめ「決める」ということを優先せず、他のことばかりに注力しているマネージャーがプロジェクトを進行しているようであれば、もう発足当初から危険信号です。それが会社の都合であっても、マネージャーの独善であっても、顧客の指示であっても、結果的に「失敗する」可能性はそれだけでグンと上がります。

私はこの計画において「誰が」「何を」「（いつから）いつまでに」「（具体的に）どうやって」を決める作業も１つの準備であり、段取りだと考えています。そして準備や段取りは、いわば装備です。武器であり、防具です。

ですので、これを疎かにするというのは

　「富士山に、素人が、軽装で挑む」

というのに似ています。多くの企業は、焦げ付いたプロジェクトを見つけると「人（マネージャー）を変える」「人を増やす」と言った対処を行うでしょう。ですが、殆どのケースで大きな効果は出ていないはずです。

だって

　素人だろうが、玄人だろうが、「人」だけどうにかしても
　「装備」が軽装である限り富士山登頂するのは困難に決まっている

からです。仮に管理職や経営層がそのような手段しか取れないのなら、それはマネジメントとしてとてもプロのするような方法ではありません。

２パターンの作業の洗い出し方

作業リストの洗い出し方として、

　・作業をその手順によって分解して洗い出す方法
　・作業によって生み出される成果物を要素に分解しながら洗い出す方法

があります。
業務改善を行うプロジェクトを例に、2パターンの方法で作業リストを洗い出して見ます。

これは作業手順で分解した作業リストですね。

こちらは成果物で分解した作業リストです。

どちらでも作業の洗い出しは一応できるのですが、実はどちらの方法にも弱点があります。

作業手順だけで洗い出しを行うと完成する成果物に漏れが起こる可能性がありますし、成果物視点だけで洗い出しを行うと「どうやって成果物を作るのか」が曖昧になってしまうのです。

一般的には成果物視点で管理し、作業手順はルールや手順書などを別途用意します。「計画書」にそれらを明記することが最も望ましいのですが、プロジェクトごとに特性があって記載方法が画一化できないことも多いため、別紙にまとめるプロジェクトもよく見かけます。

その最たる例が「コーディング規約／命名規則」などです。

すべての作業は、成果を生み出すためにある

聞きなれない言葉ですが、対訳されていない原文には"deliverable"と言う言葉があります。読み方は、デリバラブル（デリヴァラブル）。

意味は、直訳で「届けることができる」「提供できる」「もたらすことができる」となりますが、意訳では

　納品物および、納品物に直接関係する要素成果物

と考えてもらえればいいでしょうか。

GOALを構成するのは紫の要素が３つですね。この３つの要素の内、１つでも欠けているとGOALの完成にはいたりません。一番上の紫の要素を構成するのは３つの緑の要素ですね。このように、最後のGOALに至るためには必要不可欠な構成要素というものが決められています。

わかりやすく言えば、

　「カレーを作りたければ、カレールー要るでしょ？」
　「水やご飯だっているよね？野菜は？肉は？」

ということです。カレーという最終成果物に対して"deliverable"であるということは、不可欠な要素を１つ残らずきっちり用意してみせるということです。

そもそも、マネジメントの概ねの対象となっている請負契約プロジェクトですが、「請負」契約である以上、検収対象となるのは作業や頑張り、努力ではなく、

　結果、成果、成果物

に重きが置かれます。購入側としても結果や成果に対してしか支払い義務がありません。すなわちdeliverableであるという１点に対してのみ対価を支払っているということになります。裏を返せば、最終成果物に直結する活動以外で請求することはできないということです。

ではみなさんは、上司やリーダー、お客さまから依頼されている作業や、求められている成果物一つひとつが、「確実に」「100%」

　納品物を作り上げるために絶対必須である

かどうか吟味したことはありますでしょうか？

たとえば、雑談や談笑交じりの会議体や、結論が出ても出なくてもどっちでもいい定期的な会議体などは、本当に納品物をお客さまにお届けするために必要不可欠なものでしたか？

たとえば、なんとなくお客さまにWBSを渡されて「当社はいつもこれを作ってもらっているので」と言われて、その作業に対して工数を見積もるだけで、本当に納品物作成のために必要な中間成果物であるという認識で対応していましたか？

わかりやすいところで

　「画面一覧」

という成果物は、本当に最終的にシステムを納品するために必要不可欠なドキュメントでしたか？なんとなくいつも作っているから「必要である」と思考停止して思い込んでいたりしませんでしたか？

プロジェクトで失敗する要因の１つに、"deliverable"と各作業や各中間成果物との相関関係や因果関係、依存関係を検討もせずに、言われたことをただ言われるがままに受入れ、なにも疑わず、言いなりになっているだけの作業と化していることが挙げられます。

コンサルティングや要件定義などの提案活動を行う者は、与えられたものとを与えられたまま受け入れるのではなく、まずはその妥当性と正当性を検討、検証し、本当にお客さまの要求を満たすために必要なことであるかどうかを判断しなければなりません。

しかし、そう言った視点でプロジェクトに取り組めるマネージャーと言うのは極わずかです。

技術的には決して特別なことをするわけではないのですが、だからと言って今までしてこなかった人が急に「やれ」と言われても、その面倒くささと大変さをイメージしただけで立ち竦むのもわかります（実際、慣れてしまえば何１つ大したことじゃないんですけど。なんなら子供でもできることですし）。

そこで重要となってくるのが、先ほどの２パターンのいいところだけを組み合わせた、

　ハイブリッド式ＷＢＳです。

ハイブリッド式では、

　どちらかのパターンを“主軸”にし、
　もう一方のパターンでそれを“補強”する

という組み合わせ方になっています。

では、どちらのパターンを“主軸”に据えるべきなのかみなさんはおわかりになるでしょうか？

正解の前に、いま一度 “プロジェクト”とは何かを振り返って見ましょう。

プロジェクトとは「ある期間の中で独自の成果を生む活動」です。つまりプロジェクトにおけるすべての作業は最終的な成果物を生み出すために行われ、逆に最終的な成果物に繋がらない作業は一切必要としないのです。

なんとなく「必要だ」と言う人はいますが、おそらくそういう人に限って明確な根拠はありません。少なくとも、国際的な標準化機構の中では「成果につながらない仕事は、プロジェクトの活動とは認めない」としています。

それに異を唱えるのであれば相応の根拠の提示が必要ですが、私には無理です。

従って、プロジェクトでは

　「作業はなにがあるか？
　　→作業によって生まれる成果物はなにか？」

ではなく、

「最終的な成果物を構成する成果物はなにか？
　→それらの成果物を生み出すための作業はなにか？」

という逆算的な順番で考えた方が非常に効率的なのです。

なぜなら、前者の順序の場合、生み出される成果物とプロジェクトの最終的な成果物を見比べて過不足を検証し、その結果によっては作業を見直すことが必要になってくるからです。

よって正しくはハイブリッド式では「まず成果物で分解する方法」を主軸にします。そして分解された成果物を“骨格”とし、それらの成果物をどのように作るのかを作業手順の分解によって“肉付け”していくのです。

なお、ここまで話をシンプルにするため“成果”＝“成果物”として説明していますが、プロジェクトの成果は必ずしも“モノ”ではない場合もあります。

たとえば、新サービスを提供する体制の構築など“ヒト”が対象になるケースもありますし、意識の改革や知名度の向上といった直接目に見えない価値を求めるプロジェクトだってあります。

状態の変化が成果となっていることもありますが、どちらにしても監視または測定が可能な状態でなければなりません。

これらは「新しいモノを手に入れる」というより、「変化によってある状態を実現する」ことで成果を生み出すプロジェクトであると言えますが、そのような場合は「最終的に実現すべき状態」を出発点として、変化させる“領域”を細分化することで成果物と同じように分解することが可能です。

たとえば、新体制を構築するプロジェクトでは、“営業”、“事務処理”、“顧客サポート”など役割の領域を分割していけば良いわけです。

作業手順を分解するための“基本形”

成果物を分解した上で、各成果物を生み出すための作業手順を肉付けする、ということは分かりましたが、ここでまた困ってしまいます。

一体、作業手順をどうやって洗い出せば良いのでしょうか？

その一つの考え方として、成果物がどのような作業の流れによって作られるのか“基本形”を知っておくと便利です。

この考え方は、みなさん概ね持っているかと思います。

持ってない人は、まだマネジメントをしたことがない新人や担当かも知れません。

たとえば「〇〇設計書」と言う成果物を作業リストに載せたとします。

実際にはステップ①の検討や準備、あるいは事前に調査する時間も必要になるかもしれません。特に現行システムからのリプレースなどの場合、現行システムの設計書や仕様書が破損／劣化していると、プログラムソースからのリバースエンジニアリングをしなければならないケースも少なくありません。

こうした作業を想定もせず工数を見積り、予算をはじき出すと、

　確実に赤字化またはトラブルプロジェクトに陥る

ことになります。そして必要な情報(インプット)が揃えば、設計書の作成に取り掛かります。

しかし、成果物は作成して終わりではありません。

多くのエンジニアが進捗報告で冒す過ちが「作成が終わったら100%だと思っている」点です。進捗はその作業リストが完全に完了し、次の作業リストに取り掛かっていい状態となって100%です。この点は、よくマネージャーとの間で認識が乖離していることも多いので注意しましょう。

しかし、エンジニアの中には"作る"ことしか頭になく、進捗報告当初には残作業を甘く見積もって、高めの進捗率を報告する傾向があります。

これを"90%シンドローム"と言います。

この症状は成果物の作成だけでなく、いたるところで発生します。

たとえば、テスト工程においてもテスト項目の消化率だけで進捗を報告しがちですが、それで成立するのは１件も不具合が出なかった時だけで、１件でも不具合が発生した瞬間、不具合対策の工数が発生し、大幅にスケジュールに影響を与えることになってしまいます。

そして、ステップ③でレビューやチェックをしてもらい、承認してもらわなければなりません。作成者自身の思い込みが介入しないようにするため、必ず第三者がチェックする必要があります。

プログラムソースでさえ、クロスチェックやペアプログラミングと言う手法があるのはそのためです。問題があればさらに工数がかかることになります。

それらが完了して初めて次の作業に移れます。

中には、こうした取り組みをせず、作成者の自己満足に依存して進めさせるプロジェクトもあるかも知れませんが、そうしたプロジェクトでは稀に次工程以降や納品後にとんでもない事故を起こして、お客さまや周囲に迷惑をかけることが起きていませんでしょうか。

２つの注意点

ここまででハイブリッド式の基本的な考え方が掴めたかと思いますが、注意すべき点が２つあります。

共通化できる成果物はまとめておく

1点目は、成果物を分解する際の注意点です。
それは「別々の成果物を構成するものであっても、共通化できる成果物はひとまとめにしておく」ということです。そのことによって、実際に作業を行う際に同じことを何度も行わなくて済み、効率的に作業できるためです。

たとえば、夕食にチキンカレーと肉ジャガを作ることになったとします（現実にそのような組み合わせが嬉しいかどうかは別として、たとえば翌日以降のために作り置きするかもしれませんし）。

ジャガイモとニンジンは同じ材料が使えるので、まとめて皮を剥いて切り分けてしまった方が効率的です。このような場合には、共通的なものを抜き出し、“共通材料”などとしてひとまとめにしておきます。

こうした考え方をオブジェクト指向と言います。
部品化し、再利用性を高める考え方です。

オブジェクト指向と言うとどうしてもプログラムの構成で難しく考えるものだと勘違いしがちですが、オブジェクト指向の根源は私たちの生活モデルのなかに昔から既にあるもので、何も特別なものではありません。むしろ普段の考え方と親和性が高いものなので、日頃のありとあらゆるところで取り込むべきものです。

たとえば、子供に年子の兄弟がいたとします。

上の兄が着古した服を、下の弟が適齢期になった時にお古として使おう…と言う考え方も、「衣服」を１つの部品（オブジェクト）とみなしたときに、同じ体格（インターフェース）となった時に再利用するという、オブジェクト指向の典型的な活用法です。着せ替え人形やRPGゲームで装備品を交換するのも同じような思想によるものです。

どの単位で4ステップにするかを考えなければならない

2点目は、作業手順を洗い出す際の注意点です。
それは必ずしも分解された成果物すべてに4ステップの作業が必要となる訳ではない、ということです。先ほど説明した４ステップは基本形ではありますが、当然すべてがそうなるわけはありません。何事も例外や応用と言うものはあります。

たとえば、夕食を作るときに「チェック／承認」をすべての成果物に対して行うと、

　「お母さん、玉ネギの切り方はこれで大丈夫でしょうか？」
　「お母さん、チキンの大きさはこれで良いでしょうか？」
　「お母さん、ライスの量はこんなものでしょうか？」

と、ほぼ嫌がらせみたいになってしまいます。通常は出来上がった料理単位ぐらいでOKを貰えば良いですよね。

同じように、ある程度ルール化（標準化）し、１つチェックすればあとはある程度任せるということもあります。4ステップを考えるときには、どの階層の成果物でどのステップが必要かを考慮しながら作業を洗い出す必要があるのです。

これらを踏まえ、ハイブリッド式の作業リストの作り方をまとめると次のような手順となります。

(1)プロジェクトの成果物を細分化する
(2) 共通化できる成果物をまとめる
(3)各成果物の作成に必要な作業を4ステップに沿って洗い出して肉付けする
（※ただしすべての成果物に4ステップの作業がある訳ではない）

実際の作業リストの例を見てみることにしましょう。

この表では成果物を分割している箇所を青色、作業手順で分割している箇所を黄色に色分けしています。

例は何でもいいのですが、ＩＴの開発の進め方は実は「建設業」の進め方を模倣したもので、建設や建築との親和性が高くなっています。そして建設の考え方は元々製造業の流れを汲んでいるため、製造業の考え方とも酷似している部分が多々あります。

たとえば、ＩＴ業界の多くで進捗管理にガントチャートを使っているのも、元を正せば工事現場や建築現場の日程表を真似したものです。

また、オブジェクト指向における２３のデザインパターンにも、FacadeやBridgeなど建築用語がいくつか取り入れられています。

会計の基本である「工事進行基準」や「工事完成基準」なども、本来は"工事"に当てはめられた会計処理方法ですが、当たり前のようにＩＴ業界で適用されています。

まぁ当然ですね。

作るものが異なるだけで、進め方が同じ、契約形態も同じ、納品・検収も同じ。経理的なお金の動きはすべて同じ仕組みなのですから、同じルールが適用されるに決まっています。

わかっておいてほしい『本質』は、最後に出来上がるべきモノ（スコープ）から始めて、その構造を分解し、ある程度管理が出来る単位にしたら、さらに作業に分解していく…ことで、業務の全体像が、素人の目に見てもわかりやすくなるということです。

これによってマネージャーはもちろん、新人を含むメンバー全員やお客さまも、安心して仕事を任せられることができるようになり、そしてその作業ごとに進み具合を管理することで、対策を講じる必要性の有無が判断できるようになるということです。

こうした計画があるとないとでは、対策や助力の必要性を周囲は気づいてあげられず、気が付くほど（隠しきれないほど）になってからでは、すでに手遅れになる可能性の割合に大きな差が出るということです。