どうすれば泥沼プロジェクトに陥らないようにすることができるのでしょうか。今日では、泥沼プロジェクト予防策や打開策は分かっています。しかし、ＩＴプロジェクト失敗の原因は様々であり、医療におけるような“標準治療”と呼ばれる方法が確立されていないのが現状なのです。

　本稿では、私がコンサルティングした事例と私自身の失敗体験とを取り上げ、これらの失敗の原因を明らかにします。そして、同様の失敗を招かないようにするためにどうすべきかについて述べます。

１．失敗事例と原因

１．１　事例１

（１）ある顧客システム開発の失敗

　顧客システム開発の失敗事例で最も多いケースは顧客がプロジェクトに参加しないことです。

　私が、あるベンダーの顧客システムの支援を依頼されたとき、担当マネージャーと面談し、それまでの生産物（機能仕様書と構成仕様書）を見せてもらいました。それは５〜６００ページに及ぶものでした。数日間を費やして読み下していく間に分かったことは機能仕様書として書かれたものから顧客の要求が読み取れないことでした。雰囲気は掴めるのですが、顧客から見た仕様が厳密に定義されていないのです。構成仕様書についても、大雑把なハードウェアのシステム構成は書いてあるのですが、モジュール一覧やそれらの関係を示すソフトウェア構成が書かれていませんでした。詳細設計で共通に使用するデータベース仕様やER（Entity Relation）図などもありませんでした。

　このような状況では、詳細設計に入ることはできません。当然のことながら、担当マネージャーに対して、顧客から要求内容を明確にしてもらうよう求めました。ところが、顧客の担当者は社内の現場部門の業務をきちんと把握していないのです。詳細は現場に聞いてくれと言うのです。それなら、現場との橋渡しをしてくれると期待したのですが、実際はそのようなこともなく、時間がどんどん過ぎていきました。納期は守れと言われているものですから、開発部隊は遊んでいることもできず、こうあるべきとの見込みで開発を始めました。このまま作業を続けていては、顧客要求を反映しないシステムが出来上がる恐れが出てきたため、顧客に対して開発に参加してもらうよう依頼しました。顧客の担当者も次第に焦りが出てきて、ようやく参加することになりました。この時点で、顧客の担当者はシステムの開発状況が厳しいものであることを認識したのです。このプロジェクトは当初予算を大幅にオーバーし、現場部門の要求を満たすため、何度もやり直しを続けることになりました。

（２）事例１の失敗原因

　事例１における失敗の原因はプロジェクト開始当初から顧客が参加しなかったことです。どのように小さなＩＴプロジェクトであっても、顧客が参加しないプロジェクトは失敗します。ところが、実際には顧客が他人事のような顔をしているケースが見受けられます。顧客は機能仕様書、構成仕様書を書く段階で最も活躍しなければならないのですが、この段階を不完全な状態にしたまま、詳細設計以降の工程に進むと、結局は要求を満たしていない訳ですから、何度も機能仕様や構成仕様のやり直しが必要となり、いつまで経ってもプロジェクトは終息しないのです。
顧客の中には、ベンダーに対して大雑把な開発要求を行って、後はベンダーが良きに計らってくれると考える人達がいます。このようなプロジェクトは決して成功しません。顧客システムは、顧客とベンダーが一緒になって完成させるものです。

１．２　事例２

（１）私の失敗体験

　今を遡ること３０年近くになりますが、金融機関の大型システム開発に関わりを持ったことがあります。このシステムの開発期間は２年程度、受注条件として「既存アプリケーションの移行」がありました。元のアプリケーションがCOBOL言語で書かれていれば、アプリケーションの移行は容易でした。しかし、このシステムのアプリケーションはシステム記述言語上の特殊なマクロ言語で書かれていたため、そのマクロ言語に合わせた言語とコンパイラを新たに開発することを前提としていたのです。

　言語やコンパイラの開発は通常のアプリケーションを開発するほど容易ではありません。たった１つのアプリケーションシステムの開発を目的とした言語とコンパイラを開発するなどと言うことは常識外れのことでした。始めの年の春、この開発を行えとの指示が私に下りました。私は当然反対しましたが、上司はもう決まったことだからやれと命じて、その直後に転勤してしまいました。

　私は、この開発のために、他のプロジェクトから4人の技術者をアサインしました。本来ならば、１０人〜１５人の技術者が必要でした。予算管理をまかされていない私には現状の仕事からやり繰りして４人を引き出すのが精一杯でした。４人で構造設計が完了すれば、詳細設計工程以降は他のメンバを振り向けて凌ごうと考えたのです。

　言語仕様の設計は私自身が行いました。３ヶ月程かけて言語仕様とコンバーターの仕様書を書き上げました。これさえあれば、とりあえずSEを遊ばせておくことはありません。

　一方、コンパイラの開発は、極めて危ない状況でした。アサインした若手の技術者は必ずしもコンパイラ開発に精通していた訳ではありませんでした。至上命令でやれと言われていますので、問題があっても何とかしてくれと言い出せない立場にありました。

　運悪く、私は他の業務を抱えていましたので、このプロジェクトに全力投球できる状況にありませんでした。それでも、若手のエンジニアはコンパイラの構造設計書を何とか書き上げ、詳細設計に入っていました。私の抱えていた他の業務が終わり、当該プロジェクトに専念できるようになったときには、既に夏は終わろうとしていました。その間、後任の上司から、私のプロジェクトが危ないのではないかとの指摘を受けていました。しかし、予算を持たない私にとって新しい技術者の投入を行うことはできませんでした。その頃にはコンパイラの前半のフェーズはようやっと動作するようになっていましたが、バグだらけの状態でした。

　システム部門からは、年末にはコンパイラを納入しないと、システム側の開発業務が止まってしまうと言ってきます。また、年内には成果物として既存アプリケーションのコンパイル・リストを納入しなければ７、８億円の検収ができないとも言います。そのようなことがとてもできる状態ではありませんでした。
私が引き起こした問題は、客先にも伝わり、私は営業システム事業部の事業部長に呼び出され状況報告をすることになりました。その結果、営業的な配慮、中間納入物の品質の調整が行われました。品質は悪くても、年内にコンパイラとコンパイル・リストは納入しなさいというものでした。コンパイラの最終納期は翌年の３月末でしたが、それは変わりませんでした。

　このような段階になって、部長が陣頭に立ち、対応策が練られました。私の配下の全メンバに加えて他の部署からコンパイラ開発に手馴れた多数の人材を投入し、開発マシンを優先的に割り当ててもらい、コンパイラの作り直しが始まりました。朝には、前日から夜間に行った作業結果の報告を聞き、状況を把握して、次の役割を決め実行し、夕方には、昼間に行った作業結果の報告を聞き、状況を把握して次の役割を決め実行し、・・・という作業を延々と３ヶ月に亘って行いました。すべてのメンバは昼夜を問わず働き、１２月になってようやく完了の目処がつき、コンパイル・リストを納入し、3月末にはある程度の品質のコンパイラを納入することができました。

　結果的に、当該コンパイラの開発トラブルが金融システム開発に大きなダメージを与えることは回避できましたが、自他部署から多数の人材を投入したため、他の開発計画を大きく狂わせるという結果を招いてしまったのです。

（２）事例２の失敗原因

 （ａ）不十分な技術評価

　事例２に上げた失敗の中で、最も大きな失敗は技術評価が不十分だったことです。以前のシステムが特殊なマクロ言語で書かれていたにせよ、事務処理システムの開発用のCOBOL言語を採用しなかったことが重大な判断ミスでした。従来のソフトウェア資産をそのまま使用できれば、資産の有効利用ができることは理解できますが、たった1つのシステム開発のために、新言語とコンパイラの開発という大きなリスクを犯していました。この判断を下した人達には、COBOL言語および関連資産を活用することが将来に亘ってコスト削減に役立つこと、新言語およびコンパイラの開発がどれほど困難なものか分かっていなかったのです。因みに、この後継システムはCOBOL言語で書き直されました。

 （ｂ）不完全なプロジェクト状況把握

　私自身がこのコンパイラ開発プロジェクトが危ないと感じていたのは、かなり早い段階です。失敗の主因は私が上司に対し警告を発することを怠ったことでした。しかし、警告を発してもそれに応えてもらえる確信がなかったのです。当時は、プロジェクト状況報告は作業担当者の判断をそのまま報告するものでした。プロジェクト状況は計測データに基づいて報告し、誰が見ても同じ判断ができるものでなければならないのですが、プロジェクト管理という視点からすると未熟なものでした。

 （ｃ）予算管理の権限を持たないプロジェクトリーダー

　プロジェクトは予算管理と切り離して考えることはできません。当該コンパイラの開発には、最終的に３０人規模の人材が投入されましたが、プロジェクトを無難にこなすには当初から１０人〜１５人の技術者の手当てをしておけば問題なく開発できたと考えています。このような判断は管理職のミッションでしたが、私は当時管理者ではなく、そのような権限が与えられていませんでした。私の権限は、現有の人材を使って開発することだけだったのです。

２．失敗を繰り返さないために

　上記の２つの失敗事例の原因は、ＩＴプロジェクト失敗原因のほんの一例に過ぎません。ＩＴプロジェクトはそれぞれ異なる環境で進められますので、失敗の原因は数え切れないほどあります。

　ここ数十年の間にＩＴプロジェクトの管理手法はかなり進歩しているのにも拘わらず、ＩＴプロジェクトの失敗は減っていません。何故なのでしょうか。

　大きな理由として、ＩＴプロジェクト管理ノウハウ（暗黙知）の伝承が行われていないことを指摘しておきます。ISO9000やCMMI、PMPの認証を受けることによってＩＴプロジェクト管理の能力がつくと考える向きがあります。しかし、これは、逆なのです。ＩＴプロジェクト管理能力がつけば、その結果としてISO9000やCMMI、PMPの認証を受けることができるのです。ＩＴプロジェクト管理能力をつける方法は日々のＩＴプロジェクト管理で、実践を積み重ね、トップから担当者までがその活動に参加しなければなりません。ＩＴプロジェクト管理ノウハウは一朝一夕にして組織に定着するものでなく、ISO9000やCMMI、PMBOKなどの形式知と組織メンバの信念、取組姿勢、改善努力、判断力、連帯などの暗黙知が融合してなし得ることです。

　ＩＴプロジェクトにおける方法論（ISO9000やCMMI、PMPなど）を一部の管理者だけが理解し、実践しようとしても、なかなか実を結ばないのは、ＩＴプロジェクトに関わるすべてのメンバがその方法論を理解し、訓練を受け、実践的に理解していないからです。

　形式知（方法論）は暗黙知（体験、訓練、OJTなどを経て掴んだ個人の内面的知）と一体となって初めて使える知識となります。

　ＩＴプロジェクトが属している組織の能力強化を計るには、その組織に合った作業標準（組織にはプロジェクトがいくつも存在することがあるのでその組織に汎用的な方法論）を確立し、データベースとして保存し、組織の誰もが利用できる状態にしておきます（図１参照）。この作業標準は言わばその組織の文化を明文化したようなものです。新しく参加する組織のメンバには、この作業標準を演習や合宿などを通して訓練する必要があります。単なる講習では身につかない暗黙知を獲得するためです。

　組織の各ＩＴプロジェクトの遂行のためには、組織が定め、組織メンバの常識となっている汎用の方法論を基にして、そのＩＴプロジェクトに適した実施ベースの方法論（作業標準）を立案します。これについても、プロジェクトの全メンバが利用可能となるまで訓練を受ける必要があります。

　実際にＩＴプロジェクトを開始すると、いろいろな問題が発生します。ものごとはプロジェクト当初に計画した通りに運ばないのが普通です。そのため、プロジェクトの活動として、本来の開発作業を推進するメンバ以外に、プロジェクト状況をウォッチし、

図１組織のスパイラルな改善

その時点で最も望ましいやり方を見出し、プロジェクトメンバに浸透させる役割をもつ管理者もしくは推進グループが必要となります。

　ＩＴプロジェクトの開発を通して明らかになった反省点や改善点は文書化し、汎用的な方法論としてフィードバックします。また、ＩＴプロジェクトの報告会を開催するなど、組織の他のメンバと情報や体験を共有し、組織の能力強化に役立てます。

　上記を実際に行うには経営者あるいは上位管理者の強い意思と覚悟、現場管理者、担当者、外部ソフトハウスなどのプロジェクト関係者全員が同じ意識の下に価値観を共有して望むことが大切です。

　組織のメンバに、ただ単に仕組みや方法論を教育し、訓練をしただけでは、ものごとは旨く運びません。メンバを引っ張るリーダシップを発揮する管理者の存在が欠かせません。

　ここで述べた組織的対応ができていれば、先に挙げた２つの失敗事例の原因は排除できたはずです。

　事例１の失敗は、契約時に当該ＩＴプロジェクトにおける顧客の役割を規定していなかったことに原因があります。当該ＩＴプロジェクト開始に先立ち、顧客に対し、作業プロセスを説明し、その中で、顧客の役割を明確に規定しておくべきでした。組織としては、顧客の役割を盛り込んだ「ソフトウェア開発委託契約書」モデルを用意しておき、個別のＩＴプロジェクト開始に際し、顧客に対する作業プロセスの説明を義務付けることで、同様の失敗を防止できます。このようなモデル契約書として、社団法人情報サービス産業協会（JISA）が公開している「ソフトウェア開発委託モデル契約書」は大変参考になります。

　事例２の失敗原因となった「不十分な技術評価」は、ブラックボックス・ツールを多用する昨今のシステム開発現場では、リスクがますます高まっています。組織内に技術評価専門チームを設置する必要があります。

　事例２の２つ目の失敗原因：「不完全なプロジェクト状況把握」は、作業標準としてソフトウェア計測技術を導入していれば救えたはずです。

　事例２の３番目の失敗原因となった「予算管理の権限を持たないプロジェクトリーダー」ははじめからあってはならないことでした。作業標準として、予算との関係を常時ウォッチする仕組みを導入しておく必要があります。

　本稿では、ＩＴプロジェクト失敗の原因の所在、失敗防止の対策について述べました。結局は、しっかりした組織的取り組み以外に方法はないということになります。上記の組織的対応が１つの指針として役立つことを期待しています。

■