前回の「読者が伝えた70の動かないコンピュータから考える（上）」に続き，読者の皆さんにいただいた動かないコンピュータについての経験談やご意見を中心に，「動かないコンピュータが生まれる理由」を考えていきたいと思います。
よろしければ，今回の記事と併せて「読者が伝えた70の動かないコンピュータから考える（上）」および，ご意見を募集した前々回の「大募集！ 動かないコンピュータが生まれる理由は何か 」をお読みください。
また今回も是非，この記事の最後にあるFeedBack!に，読者の皆さんからの動かないコンピュータ体験に対するご意見をお聞かせ下さい。皆さんのご意見を参考に，次回の「動かないコンピュータ・フォーラム」の内容について考えていきたいと思います。
前回は，予定通りに完成してはいても，思ったような成果を出せなかったシステム，当初の予定を大幅に超えて開発が難航したプロジェクトのなかから，コミュニケーション不足やプロジェクトマネジメントの失敗が原因だった「動かないコンピュータ」の事例をご紹介しました。
今回は，開発が難航して失敗したプロジェクトのなかで，より具体的に「ここに原因があった」とご指摘のあったご意見，例えばユーザーやベンダーの体制や能力，ハードウエアやミドルウエアの不具合，そして完成したはずのシステムに障害が多発して苦しまれたご経験などについて紹介します。
失敗プロジェクトの“戦犯”はだれか
現在では，ユーザーが独力でシステムを開発するケースはほとんどありません。多くの場合，ユーザーはベンダーに開発業務を発注しています。ユーザーとベンダーの一方だけの責任でプロジェクトが失敗することがあるのかどうかは，意見の分かれるところだと思います。ただ，みなさんのご意見の中には，「コミュニケーション不足」のように，ユーザーとベンダーの双方にかかわる原因ではなく，ユーザーやベンダーの力不足がプロジェクトの失敗を招いたというものも少なくありませんでした。
単なる責任の押し付けあいになっては不毛でしょうが，具体的に何が問題だったかを考えなければ，失敗プロジェクトの反省を生かすことはできないはずです。ユーザーやベンダーの皆さんには，「相手の立場を分かっていない，それは甘えではないか」と思われるかもしれませんが，あえてそのままでご紹介します。
まず数はそれほど多くはありませんが，プロジェクトのオーナーであるユーザーに問題があったとされたご意見から紹介します。
全機能完成の遅れ。複合的要因。
1.主に実務ユーザーの改革意識の低さからくる業務構想策定の遅れ。
2.主にシステム開発担当部門の保守的な姿勢に起因するシステム構想の大きなズレの修正。
3.プロジェクトリーダーの力不足による利害関係者調整と全体計画策定の遅れ。
4.開発ベンダーの開発能力の低さとテスト作業の不足による低品質な納品プログラムの繰り返し修正。（ユーザー）
ユーザーの無理な注文（社内開発）
もちろん，一言で「ユーザー」といっても単純ではありません。システム部門，利用部門といったそれぞれの立場だけを考えることが，プロジェクトに混迷をもたらすことがあります。以下のご意見はその典型といえます。
生産管理パッケージ・ソフトを購入したが本番稼働できなかった。情報の一元化を意図したが，製造現場の個別事情を言い立てられ統一できなかった。（ユーザー）
ユーザー側の問題を指摘した最後のご意見として，以下をご紹介したいと思います。
全5段階でのリリースを行うシステムであったが，最初の3つめのリリースまではユーザー検証の段階やひどい時には本番稼働時に動作不能に陥り大問題となった。
リリースごとにトラブルの段階がより一般的な（初歩的でない）ものになっていったが予算を大幅にオーバーしたため，撤退せざるを得なかった。
・ユーザーのシステムへの理解度の浅さ （安易に変更が可能であると考えていた）
・新人を大量に配属したことによる，全体的な開発者の成熟度の低さ（作り込みの弱さ）
・派遣体質である自社の人員流動性が裏目に出た（他重要プロジェクトへの無断アサイン）
・まとめると，すべての局面においてプロフェッショナルが不足していた。（そこそこの技量の人間ばかりではあったが）難しいことではあるが，見積もりや計画段階で「相性」や「人間力」といった数値化が難しいものも考慮に入れることは絶対に必要であると感じた。（ベンダー）
ユーザー側のプロフェッショナルをいかに育成していくかは，開発に伴うトラブルを減らすための大きなポイントの一つだと思います。ローテーション人事や塩漬け人事によって人材のダイナミズムがなくなったうえに，バブル崩壊後に大型の開発案件が減少したことによって，システム部門のプロが減ってしまった現実は重く受け止めなければなりません。
開発の失敗で強いベンダー不信
一方で，失敗の大きな原因はベンダー側があったとされたご意見は多数ありました。「丸投げ」という言葉がIT業界で一般化していることの裏返しなのか，開発の業務はベンダーが担当することが多いせいなのか，開発費を受け取るのがベンダーだからなのでしょうか。いずれにせよ，ベンダーへの視点には厳しいものがあります。
ベンダーの力不足が問題を引き起こしたというご意見には，にはいくつかのパターンがあるようです。一つは，ベンダーの技術力不足です。このほかに，プロジェクトマネジャーなどカギとなる部門に力のある人間を配置しなかったことが失敗を招いたというご意見もありました。現実には，これらの理由が複合しているケースもあるようです。
