弱いIT発注者のためのプロジェクト頓挫回避法

4つの視点からITプロジェクトに関するご相談に乗ることができます。
●51の頓挫事例研究から得た7つの場面、50のありがちな兆候
●20年超実践経験から見た取引プロセスの罠と標準プロセスによる防衛
●実プロジェクトで実証済み、人材パワーバランスによる予算納期定量超過予測
●国内有数企業基幹IT100億円超開発運用実務者から見たマズい設計

→　プロジェクトを発注するのが心配
→　一定規模のプロジェクトが初めて
→　プロジェクトが開始されたが何だかうまく進んでいないようだ
→　今のITをいっそのこと作り直したい
といった方の力になれたらと思っています。
これまで国内有数製造流通企業の情報システム開発保守運用を20年超行ってきました。プロジェクトリーダー、マネージャーを経験後、いわゆる基幹ITの責任者として10年ほど現場にどっぷりつかってきました。プロジェクトでは多少なりとも失敗はあるもので、なんとかならないものかと原因について常に考えてきました。ある間接的に関わったプロジェクトが危なく頓挫しかけたのを目のあたりにしたのをきっかけに、最悪の頓挫ケース、すなわちIT取引において訴訟に至った事例を分析しました。

●51の頓挫事例研究から得た7つの場面、50のありがちな兆候
IT開発プロジェクトの取引に絞って訴訟事例を51ほど取り上げ、分析しました。その結果、ITプロジェクトの様々な場面で頓挫する兆候や原因となる事象が発生していることがわかりました。
その場面は7つの場面に分類できます。さらには具体的な51の頓挫兆候要素があり、複数あなたのプロジェクトに該当するなら、頓挫のリスクは高いです。
ITプロジェクトは期待感と絶望感が裏腹です。そして失敗の原因は典型的です。

●20年超実践経験から見た取引プロセスの罠と標準プロセスによる防衛
ITプロジェクトでの取引は圧倒的にベンダーにノウハウがあります。弱いIT担当ですと対応手段を持たず、言いくるめられてしまうでしょう。
頓挫プロジェクト事例において、発注者側のプロジェクトマネジメントの欠如が問題視され、結果敗訴となった事例がいくつもあります。発注者は、常に取引について自分に問題がないかを気にかけていないといけません。
ITの取引は完成物が見えづらく、例え高額な契約金にて請負で発注したにも関わらず、発注者が相応に関与しマネジメントしなければ完成しません。であるがゆえに、発注者と受注者のいざこざは絶えません。
取引について標準的な契約書が存在し、比較的新しい取引形態にも対応しています。ただし、契約をきちんとしていても振る舞いが伴っていなければ負けです。
また、標準といってもやや供給サイド寄りですので、発注者としてはより注意深く対応しなくてはなりません。

●実プロジェクトで実証済み、人材パワーバランスによる予算納期定量超過予測
ITプロジェクトでは予算や納期の超過はかなりの確率で起きます。許容の範囲であればよいのですが、気づかないうちに潜在的な問題が膨らみ、プロジェクト後半で辞めるにやめられない状態となっていると最悪です。
多くは初期段階での取りこぼしが発生していることに起因します。
ITプロジェクトではコミュニケーションに特徴があり、多くの人同士がレベルの違った抽象度で話すことで、方向性の取り決めを行います。抽象度レイヤを行ったり来たり器用にできる人は相当優秀で稀です。
初期段階においてはゴールを明確にしなければなりませんが、コミュニケーションの難易度をあまり考えずに期間を設定してしまうことが多いです。万物の流れの法則という考え方があり、それを情報フローに当てはめて考察してみました。そうすると、プロジェクト初期段階でどの程度取りこぼしが発生したかが、定量的にわかりました。持ちうるパワーとプロジェクトの組み方で、行く末は予測できるということです。

●国内有数企業基幹IT100億円超開発運用実務者から見たマズい設計
設計や構成、移行方式などにより、プロジェクトの進行に大きく影響することがあります。
設計にはシンプルな原則があります。ただそれが守られない要因があるのも確かです。つまり楽で早そうなほうを選んでしまうということです。プロジェクトを納品する立場ではなおさら軽視しがちで、発注者側がその後の運用も見据えて設計の良し悪しを見極めることが肝要です。
設計のマズさにより、プロジェクト後半に来れば来るほど制約を大きくしていきますので、設計を始める前から潰す必要があります。調査した頓挫事例においても、設計のマズさから次第に悪い方向に進んだと読み取れる事例がありました。ただ、すでに出来上がってからでは問題点として浮上しません。設計のマズさはシンプルな原則により早めに潰したいです。

■その他
地域: 東京、神奈川