DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

先週末（2014年2月8日土曜）は、関東地方も記録的なドカ雪で、週末の計画が一気に吹っ飛んでしまいました。まあ、ここのところいろいろと気忙しい日々が続いていたので、たまには家でのんびりするのも良いかと思いつつ、ブログを書いています。

さて、週末の計画と言えば、あなたは旅行の計画を綿密に立てるほうでしょうか？それとも、行き当りばったり派ですか？今回は、旅行の計画について、考えてみたいと思います。

【　行き当りばったりの計画って何？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
旅行については、良く綿密に計画を立てて行く方が好きな人と、旅先での気分にまかせた行き当りばったりの行動を好む人と、主張がわかれることがありますね。

この「行き当りばったり」というのも、どこまでがその範囲なのか人によってとらえ方が異なります。今回のタイトルのように、「京都ひとり旅」ということまで決まっている場合などは、たとえ京都についてからの行動がまったく白紙のままだったとしても、それほど冒険でも無く（リスクはそれほど高く無く）、それだけで「行き当りばったり」ではなく、十分計画されていると感じる人もいるかもしれません。

話をわかりやすくするため、ここでは、「綿密な計画」と「行き当りばったりの計画」を以下のように定義してみます。

＜京都ひとり旅：綿密な計画＞

• 滞在期間　：　決まっている
• 宿泊場所　：　決まっている
• 予算　　　：　決まっている
• 京都での訪問先　：　事前に全て決めている
• 各訪問先への移動手段　：　事前に全て決めている
• 食事の場所　：　事前に全て決めている
• おみやげ　：　誰に何をどこで買うか決めている

＜京都ひとり旅：行き当りばったりの計画＞

• 滞在期間　：　決めていない（時間の許す範囲）
• 宿泊場所　：　決めていない（行く先々で決める）
• 予算　　　：　決めていない（必要に応じてコンビニ等でお金をおろす）
• 京都での訪問先　：　決めていない（その日の体調や気分で決める）
• 各訪問先への移動手段　：　決めていない（行きたい場所や気分に応じて決める）
• 食事の場所　：　決めていない（行く先々で食べたくなったものを食べる）
• おみやげ　：　決めていない（行く先々で気に入ったものがあれば購入）

さあ、あなたはどっち派でしょうか？「ひとり旅」という状況設定からして前者は決まり過ぎなような気がするので、私個人としてはどちらかと言えば後者に近い方が楽しいように思います。「ひとり旅」の目的としては、やはり、日ごろの気忙しい世界から少しでも遠い世界に身も心も浸りたいというところなので、あまり綿密な計画を立ててしまっては「ひとり旅プロジェクト」の目標は達成できないでしょう。まあ、実際は宿泊場所ぐらい決めるでしょうが。。。

【　システム開発プロジェクトの計画はどっちが良い？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
ここで少し現実に戻りましょう。システム開発のプロジェクト計画は、「綿密な計画」と「行き当りばったりの計画」のどちらが良いでしょうか？

―――　プロジェクトマネジメント研修を受けてきたばかりの新人Ｐ子さんの意見です。

＜新人Ｐ子さん＞　：　「もちろん綿密な計画に決まってるわ！綿密な計画を立てずにプロジェクトを進めたら、失敗するのは当たり前じゃない！なんで、そんなわかりきった質問するんですか？」

―――　長年現場でプロジェクトと戦い続けてきたベテランＰＭのＭ男氏の意見です。

＜ベテランＰＭのＭ男氏＞　：　「現実はそんなに簡単じゃないんだよ。プロジェクト計画書なんて、会社の規定として決められているからプロジェクト開始前に形式的に作るが、要件定義をやってみないとどんなシステムを作んなきゃいけないかわからないだろう。そんな状態で綿密な計画なんてできるわけ無いのは当たり前だ！」

うーむ。「京都ひとり旅」と同じぐらい、システム開発のプロジェクト計画についても、こんなに意見が割れるとは。。。

ベテランＰＭのＭ男氏が言うように、プロジェクト計画書をプロジェクト開始前に作成することは、どんなシステム開発の組織においても義務付けられていて、プロジェクト計画書の承認がおりないことには、プロジェクトを進めることはできないでしょう。そりゃそうですよね。プロジェクトを開始するということは、リソースやコストを既に使い始めるということであり、ちゃんとシステムが出来上がるかどうかわからない状態で、プロジェクトを開始することは、組織として許容できることでは無いでしょう。

しかし、一方で、これもＭ男氏の言うように、要件定義も終わっていない状態では、どんなシステムが出来上がるかはまだ明確ではないので、設計・開発・テストの全工程に関する綿密な計画が立てられないというのも事実です。

では、Ｍ男氏が正しいのでしょうか？当ブログの　【第１９回】プロジェクト計画書に魂を吹き込め！（振り返り）　で主張していることは、理想論に過ぎないのでしょうか？？？

【　プロジェクト計画書はいつ完成するか？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
さあここで、ひとつのヒントを出します。Ｐ子さんの意見もＭ男氏の意見も、真っ向から反対のように見えますが、ある視点を加えることで、どちらもそれほど間違っていないということに気付くはずです。このサブタイトルから既に連想されている方も多いと思いますが、その視点とはズバリ「時間軸」のことです。

Ｐ子さんの意見の、「綿密な計画を立てずにプロジェクトを進めたら、失敗するのは当たり前」の具体的なシチュエーションを少し想像してみてください。

たとえば、

1. 基本設計の具体的な成果物やルールが決まっていないと、仕様の抜け漏れをレビューで検出できるかどうかわからない
2. どのプログラムを誰がいつまでにコーディングするかが決まっていないと、全てのプログラムの開発がいつまでに終わるか見通しが立たない
3. システムテストでどういう順序でテストを実施していくか決めておかないと、本番稼働後に起こりうる状態でのテストができているかどうかわからない

これらのシチュエーションでは、どれも確かにプロジェクトが失敗すると思えますね。ということは、Ｐ子さんの言っていることは正しいと言えます。

じゃＭ男氏の意見はどうでしょうか？「要件定義をやってみないと、綿密な計画なんてできるわけ無い」の具体的なシチュエーションを考えてみましょう。

1. 要件定義前段階で運用要件や性能要件が決まっていないのに、具体的なシステム構成やサーバーのスペックに基づく、ハードウエア手配の計画詳細化は難しい
2. 基本設計前段階で機能分割もできていないのに、どのプログラムを誰がいつまでにコーディングをするのか具体的な計画を立てることはできない
3. 新システムのデータベース構造が決まっていないのに、移行ツール製造・テストの作業計画の詳細化は難しい

そうですねえ。確かに、ここにあげたシチュエーションにおいては、どれも綿密な計画をたてるのは難しいと思えますよね。ということは、Ｍ男氏の言っていることは正しいと言えます。

つまり、システム開発のどの場面におかれているかによって、どこまでの計画を詳細化できるのかが決まってくると言えるのです。逆に、いつまでにどこまでの計画を詳細化しておく必要があるのかをしっかり意識して、プロジェクト計画書の完成に向けた計画を立てる必要があるのです。これが、一般的に言うプロジェクト計画の「段階的詳細化」です。（※１）

この「段階的詳細化」、および、「プロジェクト計画書に魂を吹き込み」続けることにより、

「プロジェクト計画書の完成時期は、プロジェクトの終結時期とほぼ等しい！」

と私は本気で思っています。実は、システム開発のプロジェクト計画は「京都ひとり旅：綿密な計画」よりも、「京都ひとり旅：行き当りばったりの計画」に近いと言えるかもしれませんね！（※２）

それでは、次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　プロジェクトマネジメント計画書の段階的詳細化については、PMBOKガイド参照
Project Management Institute, Inc.(2013)『プロジェクトマネジメント知識体系ガイド（PMBOK®ガイド）』（第5版）Project Management Institute, Inc.

※２　当ブログ　【第１８回】計画が先か？リスクが先か？　の「図２　一般的なリスク・マネジメント手順とその課題」で示すように、プロジェクト実行段階におけるリスクへの対応策をプロジェクト計画に反映し続けて行くことを主として「プロジェクト計画書に魂を吹き込む」と私は呼んでいます。