ITプロジェクトを失敗させる方法～失敗要因分析と成功への鍵～（読書メモ2：提案・受注編）
前回に引き続き、今回は「提案・受注段階での失敗」について。
この工程は「超上流」と呼ばれ、プロジェクトに失敗をもたらす大きな要因となる工程。
事業や業務の検討から要件定義まで（システム化の方向性、システム化計画、要件定義）を行います。
ここで超重要事項が 2点。
- 経営戦略とIT戦略の一致
- ユーザー企業内での合意形成
上記について、ユーザー企業（クライアント）の経営者が責任を持って積極的に関与（ユーザー企業による主体的な要件の決定・明確化）することがポイント。
本書では、失敗の要因を発注側（ユーザー企業）、受注側（ベンダー企業）それぞれで整理されている。
発注側（ユーザー企業）における失敗要因と成功への鍵
失敗要因は主に 9つ。
①経営者の関与が弱い
昨今のITシステムは経営戦略と密接なかかわりがあります。経営戦略と乖離したIT戦略は企業にとって価値を生み出すことは難しいといえます。
ここで大切なのが経営者の思いは当然ながら、そのこことに対する合意形成。思いだけ語って後は部下任せ、だと上手くいかない。
②ユーザー側に取りまとめ役が不在
昨今のプロジェクトはステークホルダーが多く複雑なため、ユーザー側にユーザー内の関係者を取りまとめ合意を形成する担当者が必要。
決裁者が席を外した瞬間に担当者が愚痴をこぼすようであれば、それはまさに修羅の道の始まりですね。。
③要件を取りまとめる技術や人材の不足
要件定義の責任はユーザー企業にあり。以下のような問題を解決しないと、しわ寄せはベンダへ。
表面的な同意をつくろうために、定めるべき仕様の決定を曖昧なままにしたり、先延ばししたりする。
調査・検討が不十分で、機能要件や非機能要件に漏れがある。
要件定義書の表現が不十分かつ曖昧で、内容が生活に伝わりづらい。
④適切なRFPを作成する技術や人材の不在
⑤組織全体が強いプレッシャーを受けている
ゆとりのない中で生まれたプロジェクトは根拠の無い楽観性によっているのでリスク対応策もまったく講じられていないことが少なくありません。
週末にブログ書けるくらいのゆとりは丁度良いのかな。
⑥組織内の上層部に政治的な争いや不安定な人間関係がある
ITプロジェクトの本質的な目的は、企業価値を高めるためにあるのですが、このような企業においては社内競争のための道具として使われてしまうためです
個人的には、二人以上の人間が集まれば政治が生まれるので、これは仕方の無いことだという解釈（政治を超越して信頼してもらえる人間になれれば一気に解決するのだけれど、、、）。
⑦独裁的な企業でボトム<ミドル>アップのフィードバックがかからない
遅れを「遅れ」と言えない雰囲気。
⑧ベンダ企業の能力を適切に評価できない
⑨ベンダに丸投げし、無理な契約条件を強いる
「超上流」工程（案件によっては外部設計も）の契約に対して請負をベンダに強いることは無理がありますし～（中略）～請負契約にしてしまうとユーザー側は「まる投げ」した感じを持ち、責任感が弱くなりますし、ベンダ側はできるだけ請け負う作業の範囲を狭めたいという意志が働きます。
協調が必要な工程で対立関係になってします。恐ろしや。
受注側（ベンダ企業）における失敗要因と成功への鍵
失敗要因は主に 6つ。
①「成功させること」ではなく「受注すること」が目的になっている
売上を上げるため、多少無理をして受注する。曖昧含みの受注なもんだから後工程で綻びがでる。開発工程（請負）で正式見積りをしても、概算見積りを超える額は認められない。結果大赤字、お客様からの信頼も失う。
という事例が、本書には書かれていました（汗）
②自分の言動が与える影響力を経営者が理解していない
影響力のある人は無邪気に発言したちゃダメ。強い人の言葉を聞くと下の人は思考停止になって、表面上の言葉面だけで動いちゃうって話し。
③問題の先送り
ユーザー企業との安易合意形成を行うために（とりあえず受注するために）利害関係の不一致を曖昧にして問題を先送りにしてしまうことがあります。
例えば、要件が確定していないにもかかわらず、5,000万円という予算の範囲内で仕様を調整するという、極めて安易な合意形成をしてしまう（って事例が書かれてた）。
④間違った顧客思考
御用聞きは顧客思考じゃないよって話し。
ITプロジェクトに関してはユーザー企業に対して単なるイエスマンになることは間違った顧客思考だと言えます。これは提案・受注段階においても同じです。ユーザー企業の仕事の出し方や契約のしかたに問題があると思えば、そこも含めて提案する必要があるといえます。ここをスムーズに乗り越えるためには、ベンダ企業に対話能力や質問する能力が必要となります。
⑤リスクに対するレビューが行われていない
見積り段階での、リスクの洗い出し、リスク分析、リスク対策の立案が必要。
これが行われない理由はいくつかあるが、「受注する」ことが目的になっているケースは、まず行われない。
⑥受注審査のルールや手順が確立されていない
成功への鍵：プロジェクト内プロジェクト「提案・受注プロジェクト」の立ち上げ
しかし、多くのベンダ関係者にとって、提案・受注活動は営業というルーティンワークですので、ユーザー企業のプロジェクトを成功させるという観点でかかわっているケースは少ないと思われます。しかし、このことがプロジェクトの失敗に影響を与えていることは否めません。すなわちベンダ企業のこの段階でのかかわり方が、プロジェクトの成功に対して少なからず影響を与えているのです。そうであるなら、この経営活動については、営業活動というベンダのルーティンワークとしてとらえるのではなく、サブ・プロジェクトとしてマネジメントする必要があります
ベンダ側のメインとなる関係者が以下をきちんと理解する必要がある。
- ユーザー企業の経営戦略やプロジェクト（システム化）の目的
- 自社にとっての目的
後者について大切なのが、「財務的視点」からの目的ではなく、「業務プロセスの視点」や「学習と成長の視点」に関する目的を設定すること。
自分とこの話し（問題先送りソリューション）
最後にちっちゃな体験談を。
プロジェクトも進み、「不安なことがあればこれが最後の言うチャンス」というMTGを開いた時の話し。
「素直にゲロっちゃいなよ！」というメッセージをこめて、閉じられた空間で『ゲロルシュタイナー』という炭酸水を用意してMTGをしたことがあった。
上司にはスベリ扱いされたものの（涙）、多少みんなの舌は滑らかになっていたのではと自画自賛（アイデアをくれたＹ井氏に感謝）。
