コンサルティング現場のカラクリ

IT部門の苦悩(4)--相変わらずプロジェクトは失敗する

宮本認(ビズオース )

2018-03-17 07:30

(本記事はBizauthが提供する「BA BLOG」からの転載です)

相変わらずプロジェクトは失敗する

 コンサルタント仲間と会食をしたりしていると、どこどこで新しいプロジェクトが起きたというような話は、多かれ少なかれ耳に入ってくる。結構な取り組みならば、われわれは、聞いたとたんに「失敗するな」と答える。コンサルティング会社A社が、C社の基幹系プロジェクトをやっていると聞くだけで「できるわけないじゃん」と直感する。なぜなら、進める側の企業も、受ける側のコンサルティング会社も学んでいないのだ。それが実態だ。

 キャチーなキーワード、例えば、グローバルスタンダードといった言葉を、整然とした美意識にあふれるパワーポイントで散りばめる。構想まではそれなりにお互いに満足を持ってまとめることができる。データベースも、土管を1つ2つ書いておけばいい。システムの箱をそれっぽくつなぎ合わせ、今のシステムとは違う整然とした構成で作り上げると宣言する。

 なお、その中には、外資系の場合には輸入された「グローバルスタンダードなソリューション」が入っていることが、国産ベンダーの場合は、各社が持っているヘンテコなソリューションが入っていることが多い。そして、進め方はプロトタイピングといったり、CRPとか言ったり、順次作るアプローチが最適などという。現実は、とりあえず払える予算分だけまずもらうという意味なのだが。

 そして、要件定義に入る。ここから様相は少々おかしくなる。要件定義になると、これまでの優秀な部隊から、だんだんと玉石混交の部隊になってくる。委託している会社も人数が増える。本来なら、企業の仕組みを判断できる経験豊かで、現実と理想のバランスがとれ、周囲から一目置かれる人が参加するのが理想だが、残念ながらそんな人は、リストラ後の今の日本企業にはいない。たとえいたとしても、その部署の中核だから出せない。

 せいぜい、若くて、右も左もあまりわかっていない社員が投入される。コンサルティング会社に代表されるプライマリベンダーも同様。構想時の有能なマネジャーは、ひどいケースではいなくなり、代わりに若手が大量に投入されはじめる。「ヒアリングさせてください」「セッションさせてください」とプロジェクトで何も生まないコミュニケーションが始まる。

 双方のメンバーとも、やる気がないわけではないし、会社にとってはさほど重要ではないが当人にとってのはずれた大きな問題意識を持ち、中には害ともいえる理想をもっていたりして、プロジェクトがあらぬ方向に向かうことが頻出する。ひどいケースでは、方向が変わり過ぎてスケジュールさえなくなる。しかし、プロジェクトリーダーの評価の問題もあるので、ひとまずは進んでいく。

 そうこうしている中で、なんとか、要件定義っぽいことをまとめあげ、もう一度見積もりを取る。1.5倍。ひどい時は、2~3倍。プロジェクトは大騒ぎになり、業務要件を切る、プライムベンダーに呑み込ませる、そこかしこで交渉が始まる。もはや、当初の構想などそっちのけ状態だ。

 それでも、なんとか設計に入る。細かいことを考えていくと、抜け・漏れが数多く発覚する。当初想定していたやり方ではできないことも多発する。課題管理がなされるが、何が書いてあるかわからない課題が増え始める。そう、プロジェクトに入る人の質が格段に落ち始めるのだ。課題は、終わっているか終わっていないか、わからなくなる。

 それでも一応の解決が合意されれば、新しい仕様が多発することになり、グローバルなソリューションは見る影もないお化けへと、国産のヘンテコソリューションは開発基盤と化し原型とは全く異なる別物が出来上がる。外資系は利にあざといので、この段階から、「要件を切ってほしい」と言い始めてプロジェクトはもめ、国産ベンダーは問題をマグマのようにため込む。いずれにしても、2ちゃんに「デスマ」と書き込みが始まるようになる。

 プログラミングは進む。間違った仕様で。ハードウェアとソフトウェアの導入は進む。ここは、建設、すなわちConstructionなので目に見える。だから、まあ、できる。というか、問題は顕在化しない。

 時々、この段階で問題が噴出することがある。詳細設計ができないのだ。日本企業は、個別化(顧客毎の対応)を鬼のように進めている。基本設計まではなんとか乗り切るのであるが、実際にものづくりに入ってそろそろ物知りのユーザーがとても不安になってくる。「あれはどうなるの?」「これはどうなるの?」という例外ケースを山のように持ってくる。

 業務改革の名のもとで、あるべき論だけ語っていたケースでは、もう目も当てられない。標準化なんて言った日には、個別化自体が標準になる冗談にもならないことが起き始める。結局、例外ケースをたくさん作らねばならなくなる。しかし、例外ケースを知っている人はもう会社を辞めていたり、他の部署に異動していたり。今のプロジェクトに参加している人が、どういう例外ケースがあるのか、そんなものは知らない。プロジェクトは、もうどうしようもなくなってくる。

 それでもプロジェクトは進んだとしよう。さあ、テストだ。動かない。プロジェクトでは、みんなわさわさと働くのだが、バグが多すぎて、処理に困る。みんな家に帰れず、疲労困憊。会社に出てこない人も増える。課題管理と言っても、バグを検知して、入れる人の日本語が稚拙すぎて読めない。理解できない。テストを管理するツールにも、不慣れな人が多くて状態が分からない。それでも、その中で有能な人が現場に入り解決を始める。結果、全体の状況がわからない。違う場所で大きな問題が起きたりする。真剣に、英語で書いてくれた方がまだわかると思ったりする。仕様変更も、要件自体がおかしかったことも、日々生じる。

 外資系のパートナーや営業がやってくる。そろそろ赤字になりますと。知ったことではないと突っぱねると、「撤退しろと会社から言われている」などと脅しが始まる。プロジェクトマネジャーやPMOは会社上層部に怒号を浴びつつも、なんとか追加予算の確保に奔走。そのための、プロジェクト状況や見通しのための資料作りに忙殺される。

ZDNET Japan 記事を毎朝メールでまとめ読み(登録無料)

ZDNET Japan クイックポール

自社にとって最大のセキュリティ脅威は何ですか

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]