プロジェクト失敗の原因

あるべき姿（Should Be）と将来（To Be）はイコールなら理想だが、現実は目的と目標（※）の関係に近い！

To Beは将来であり、必ずしもあるべき姿（Should Be）ではありません。『現状』分析から、先ずは全ての制約条件を外した『あるべき姿（Should Be）』を描いた上で、将来における制約条件を加味した現実的な『1年後の将来』『3年後の将来』『5年後の将来』等を描くべきで、これを間違えて、1～2年先のシステム導入後をTo Be（ここでは「将来」ではなく「あるべき姿」）としたために導入効果がわからなくなり、プロジェクトが失敗したと判断されているケースも少なくありません。

会計の世界では有名な話ですが、Balance Sheet（バランスシート）をバランス(均衡)しているから貸借対照表と日本人が誤訳したのと同様（会計用語でBalanceは残高という意味）に、To Beに「将来」と「あるべき姿」の両方の意味を持たせて混同してしまったことが、その失敗の原因ではないでしょうか。

As Is（現状）を山麓、Should Be（あるべき姿）を山頂（目的）と仮定すると、To Be（将来）が中腹（目標）となり、 途中のコース、時間、誰と登るか等は、山の大きさ、企業の体力や資金力等によって異なってきます。
小さい山ならお金をかけず全て徒歩で真っ直ぐ、大きい山なら体力がないため時間をかけて徒歩で遠回り／ お金をかけてロープウェイやケーブルカーで素早く／最初だけお金をかけて勢いつけて車だが最後は徒歩等、様々です。
但し、一気に山頂までいけない程の大きさの山の場合、 切りの良いところで寝泊まりする必要があるため、 例え効率が悪くともテントを張るためにルートを変えたり、 まだ日が暮れていなくともその日はストップしたり （プロジェクトのフェーズを区切る ＝将来における制約条件を加味した現実的な 『1年後の将来』『3年後の将来』『5年後の将来』等を描く）、 ある程度登ってノウハウを蓄積してから一旦下山し、 改めて登頂することもあります。

グランドデザインは全体構想のため、１手段についてのシステムグランドデザインという言葉には違和感あり！

「部分最適（※1）の集合体は全体最適（※2）にならない」と言われていますが、システムグランドデザインは「目的に対する1手段であるシステム」を中心とした構想（※3）を描くため、その部分最適を目指したプロジェクトが失敗に終わるケースも少なくありません。
システムは非常に重要かつ有力な目的達成のための手段ですが、「ITが経営やビジネスの中心になる」と考えると、方向を見失ってしまう可能性があるため注意が必要です。

※1 例えば仕入、生産、販売、物流等で、それぞれの業務機能だけ生産性を上げたり、各部門や個々の従業員単位で最適化すること
　　⇒企業全体の効率低下が問題
※2 各業務機能、各部門や個々の従業員が歩調を合わせ、同じ方向に最適化すること
　　⇒トップの積極的な関与が必須
※3 経営視点を追加しようとシステムの延長線上で検討
　　⇒経営にはたどり着くことが困難

システム構築は「湖⇒川⇒海」で経営は「雲（源流）⇒川⇒湖⇒川⇒海」

システム構築における上流は湖付近の川で1～2本程度、下流は海に近い川で1本。
一方、経営における上流は極端に言えば雲、もしくは源流で、数十～数百本程度の川が集まって湖になり、その湖に近い数十～数百本程度の川も下流。海に近い1本になった川も下流。
また、雲から湖を経由せずに湖の先の川や海に雨が降ることもあり、上流と下流の関係は非常に複雑かつ広範囲。

上記はあくまでも例えでしかないため、色々と矛盾点もあるのですが（※）、システムの延長線上で検討しても、なかなか経営にはたどり着かないことを説明する例としてはわかりやすいと思い記載しました。
システムグランドデザインが違和感のある言葉であることの補足説明として参考にして戴ければ幸甚です。
また、上流経験が豊富と紹介されたコンサルタントにも、何に対して上流かは確認しておいた方が良いでしょう。

※ダムや末無し川の存在、途中で蒸発、農地や工場等での利用、地下に染み込む水など

構想フェーズでWBSを活用しようとする誤りは、恋愛に例えるとわかりやすいかも！？

上流フェーズで停滞して困っていると聞いて参画するプロジェクトは、“WBS”と言うキーワードが飛び交っていることが多いです。
そして、そういうプロジェクトを推進してきたコンサルタントを名乗る方々は、SIerから上流フェーズに進出した会社の方や、マネジメントを専門としている会社の方が多いです（所謂広義のSEさんで、下流フェーズでWBSを使う生活が長かったため）。
たまに有名コンサルティングファーム出身者のこともあり、何を経験してきたのかと、呆れてしまうこともあります。
共通している誤りは、作業内容が明確になっていないフェーズでも、とにかく作業に落として進捗管理すれば解決すると信じていることです。
中には「WBSに落とすのが王道です！」と顧客に堂々と語り出すコンサルタントもいるので、私の方が恥ずかしくなります。
こういうコンサルタントは、一部の例外的な案件の場合を除き、上流工程の経験が浅いため要注意です。尚、WBSの意味を誤解している上流フェーズのコンサルタントを名乗る方の割合は8～9割ぐらいと非常に多いです。逆に純粋な業務コンサルタントで勘違いしている人は、たまにいるぐらいで、9割以上は正しく理解していると思います（そもそも上流工程のコンサルティングでWBSという言葉は出てきません）。
ちなみに例外というのは、プロジェクト計画を淡々と過去の案件に倣って作るだけだが、フェーズ名としては構想フェーズになっていて、役割分担が必要な規模の場合です。
構想フェーズでは、ステップに落とすことができても、決定していないことが多く作業に落とすことが容易でないため、スケジュールで管理するのが一般的です。

※WBS（Work Breakdown Structure：作業分解構成図）
　作業（Work）を分解（Breakdown）して構造化（Structure）
WBS導入の目的は「プロジェクト全体（作業、スケジュール、役割分担、工数、進捗、スコープなど）を可視化すること」と言われており、「作業を明確にせずスケジュール化すると、プロジェクト失敗リスクが高まる」と考えられることもあるようです。
ただし、これはタスク（作業）と作業時間・担当者が明確なケースにのみに当て嵌まるボトムアップ型（タスクを積み上げてスケジュール作成）の考えで、構想フェーズなどのタスク・作業時間・担当者が明確でないケースでは当て嵌まらず不向きです。明確でないケースとは、As Is（現状）、Should Be（あるべき姿）、To Be（将来）を“紐解く”様なケースです。また、構想フェーズで全作業を抜け漏れなく抽出しようとすると、仮定でタスク化するため、無駄になるタスクが大量に発生して非効率です。
そのため、構想フェーズでは期間・コスト・リソースなど、様々な制約を加味したスケジュールを立て、トップダウン型（大枠のスケジュール作成後に詳細化）で進めるのが一般的です。

この辺の話をわかりやすくするため、システム構築の本番稼働を恋愛の結婚（入籍）に例えてみることにしました。
どちらも安定するまで（しても）油断できないことや、結婚（稼働）がゴールでないことまで共通しています、、、
WBSが有効な場合というのは恋愛であればプロポーズ（婚約）してから。
大枠のスケジュールを決めた後に、日単位の詳細な作業計画を作成し、実行に移すことが可能で、当然進捗管理も可能です。
システム構築であれば案件によりますが、要件定義以降か、基本設計以降ならWBSが有効な場合もあるでしょう。
逆にまだ付き合ってもいない状況で、日単位のデートの計画（1回目でどこに行き、2回目でどこに行くとか、何回目で両想いになるとか）を細かく立てていたらどうでしょうか？？しかも結婚まで。相手がどんな人かも、自分がどう思われるかもまだわからないのに。
同様にシステム構築の前の構想フェーズで、現状分析したり、業務のあるべき姿や、将来像を描いたり、要望を纏めるのに、細かな作業計画を立てて意味があるでしょうか？どんな話が飛び出すかわからないのに。