システム開発 失敗が多いのは何故(3)

システム開発 失敗が多いのは何故(3)

ベンダー側の問題として触れた点を、掘り下げて考えてみたいと思います。

『ユーザ企業の経営や業務に関する知識が不足している』

『ユーザ企業との要件調整が不足している』

『システム化をすることが目的となってしまう』

『ユーザ企業のシステム化の目的や目標が理解されていない』


まずは、ベンダーの業務知識不足ということがあります。

ただ、システム開発プロジェクトが短納期化/低予算化するなか、技術者も寝食惜しんでボロボロになり、なかなか新しい知識を習得する時間が取れないという現実があるでしょう。

しかし、この事よりも、IT業界の構造的な問題の方が深刻な事態を引き起こしているのではないでしょうか。

元請があり、2次請け、3次請け・・・・。
実際の話ですが、知人の会社に何と『7社』も仲介業者が存在していたことがあったそうです。下請けになればなるほど、ユーザ企業との関係は希薄になり、一番苦労している『本当の技術者』が、ユーザ企業が何を望んでいるのかが分からない。

仲介業者が手数料をむさぼる為、一番苦労しているにも係わらず、金銭的に恵まれない。

これじゃ、モチベーションも上がらず『言われたとおりコンピュータシステムを作ればいい』という気になりますよね。

しかし、この階層構造を甘んじて受け入れているということが問題の本質でしょうか。
下請けに甘んじているベンダーの中には、大手メーカや大手ベンダーの傘下にいれば、仕事に困らないという実態があります。
その為、営業活動といえば、大手メーカや大手ベンダーとのルート作りと思っている方が多いようです。

自社製品を持って活動している会社もありますが、技術者を商品として『開発現場』に送り込んだほうが会社経営が安定しますし、敢えてリスクを負う必要もないと考えますね。

実は私もシステム開発会社の役員をやっているとき、7:3の比率で事業を構成すべきと考えていました。
7はメーカや他社ベンダーの傘下での仕事。
3はユーザ企業との直接取引での仕事。

この比率を維持しているときが、一番経営が安定していました。

ある時、ユーザ企業との大口案件が立て続けに成約でき、社内に残っている技術者は他のプロジェクトで忙しかったため、プロジェクト編成に苦慮していました。

そこでトップが下した判断は、事業拡大のチャンスであり他社ベンダーで仕事をしている技術者を引き剥がし、新たなプロジェクトへ技術者を配置するとの事でした。

それまで7:3の比率構成が、5:5の比率に構成変更したのです。
当然引き剥がした分の売上は下がりましたが、社内で仕事が出来るということで技術者のモチベーションも上がったのです。

しかし、そのプロジェクトが順調に進捗していれば何ら問題はなかったのですが、納期遅延等の問題を引き起こし、収益を圧迫し始めたのです。

その結果、約2年後に16期続けてきた会社を清算する事になってしまったのです。

事業継続とベンダーとしての気概。
難しい判断ではありますが、IT業界の構造的な問題の解決とベンダーとしての意識改革が行われない限り、ユーザ企業の不満は減らないのでははないでしょうか。

こちらもご覧ください

0 件のコメント:

コメントを投稿

システム設計書

システム設計書 システム開発における設計書。 名前の付け方、内容の記述の仕方、実はこれ、ベンダーによってまちまちなんです。 名前の付け方に関して言えば、外部設計書/内部設計書というベンダーもあれば、基本設計書/詳細設計書というベンダーもあります。 場合によっては...