オーパシステムエンジニアリング
会社情報

 

一覧に戻る

失敗に学ぶ中小企業の生きる道 第4回
『古参社員が独断専行もの言わぬSE』

(2000年4月号)

 自社の情報化プロジェクトをシステム・ベンダーに任せきりというユーザー企業は困りものですが、逆にユーザーの言いなりでシステムを構築し、収拾がつかなくなった開発事例も数多くあるのをご存知でしょうか。中途半端な経験を拠り所にした独り善がりなユーザー側の責任者と、「客の言いなり」に身を任せた世間知らずのSE(システム・エンジニア)が繰り広げた何とも悲惨なケースをご紹介します。
 D社は、国内2工場・海外1工場を持つ社員300人の自動車・家電向けスプリングメーカーです。国内工場では10年前、MRP(資材所要量計画)パッケージ・ソフトで生産情報システムを構築済みでしたが、満足に動いているとは言い難い状態でした。
 そんなD社がシステムの刷新を決めたのは、98年の春のことでした。
 開発プロジェクトの責任者は業務に精通した生産管理課長のK氏で、それまでのシステムを一から立ち上げた実績もあり、相当な自信を持っているようでした。システム・ベンダーのSEが最初の打ち合わせに訪れると、彼自身が書いたと思われる「開発指針」を示されました。基本設計についても、基幹になる生産計画システムはK課長が直接担当するとのこと。本人が勢い込んでいるだけあってシステム要件は整理されており、口を挟む余地はありません。
 開発日程表も準備されていたため、これに従ってプロジェクトを進めることに決定しました。打ち合わせはK課長が一方的に進めましたが、システム・ベンダーのSEは一言も口を出しませんでした。

独断で進めるプロジェクト責任者

 設計仕様の最終打ち合わせになって、ようやくD社の総務・製造・営業の責任者が顔をそろえたものの、誰からも積極的な発言がありませんでした。ベンダー側もK課長の一人舞台でプロジェクトが進んでいくことに不安を感じ、「この内容で進めてよろしいでしょうか」と問い掛けるのですが、3人からは何の要望も出ません。
 「K課長の指示通りにやれば問題ないかもしれない」。ついにそんな考えがSEたちの頭をよぎりました。しかし、その見通しがあまりに甘かったことが次第に明らかになったのです。
 打ち合わせが終わって、K課長が席を外した途端のことです。3人の責任者が一斉に「あいつにやらせたんではダメだ!」と言い出すではありませんか。「彼は当社の“生き字引”で実力も認めるが、何でも勝手に決めてしまう。現システムを導入した時だってそうだ。うちの社長はおかしいよ。あいつを全面的に信頼しているなんて…」。
 SEたちは狐につままれた思いがしました。何事も手際良くまとめていくK課長が、実は独断専行型で社内でも孤立しているとは気がつきませんでした。とはいえ、すぐに対策が浮かぶわけでもありません。「営業と相談してみます」としか言えませんでした。

社長も状況を把握せず

 K課長がほとんど独断で進めてきた開発プロジェクトは、この辺から問題が一気に噴出します。システム設計は最終段階に入りましたが、彼の要求通りに設計するとハードの能力をはるかに超える危険性が出てきました。もう少しコンパクトなシステムにすべきだということになり、ベンダーのSEがK課長に交渉しましたが、「君たちの知恵がないからだ」と言下に拒否されてしまいました。
 とてつもなく重いシステムが試行し始めたのは、その年の暮れも押し迫ったころです。並行稼動の期間を1カ月に限定されていたため、徹夜の連続が始まりました。しかし、処理速度が極端に遅く、すべてを検証するには膨大な時間が必要でした。
 さらに、新システムからの出力資料を総務・製造・営業部門の責任者に検証してもらいましたが、まともに目を通してもらえません。異口同音に「こんな複雑な資料では使い物にならない!」と言うのです。
 「新システムでは出力資料の枚数を従来の半分にする。ただし、機能やデータは削らない」ということを決めたのはK課長でした。システム・ベンダーには、K課長を説得できなかったことを責める声が集中しました。ところが、そういう彼らのなかに、K課長に対して直接意見する同僚は1人もいないのです。
 とにかく、処理速度を上げるには要求仕様を基本部分から見直す必要があります。しかし、ベンダーとしても追加費用をもらえない限り修正作業を進めるわけにはいきません。
 システム・ベンダーの営業責任者は、意を決してD社の社長に直談判に及びました。社長はK課長からの報告を真に受け、「従来より優れたシステムになる」と頭から思い込んでいたようですが、事の次第を聞いて問題をようやく認識。善後策を協議し、K課長をシステム責任者からはずすと同時にベンダーのSEも交代し、システムの再設計をすることにしました。費用は両者が折半することも決まりました。

責任者に必要な資質を見極めよ

 この失敗に至った最大の要因は2つあります。
 1つはK課長というベテラン実力者が独断で行動できた企業体質です。今までのMRPパッケージを導入したのも彼の判断であり、誰一人この決定に関与できませんでした。今回のシステム開発の経緯を見ても、経営者は神輿の上に乗っていただけ。「ベテランに任せておけば大丈夫だろう」と考えて、ほとんど管理機能が働いていなかったといえるでしょう。
 社内の生き字引的な実力者は既成概念が強く、他人の意見を受け入れない傾向があります。ましてや情報システムに多少なりとも知識や経験があるとすればなおさらのこと。これが災いの元になることが少なくありません。
 ユーザー側のプロジェクト責任者の適性としては、情報システムに関する知識もさることながら、
  1. 自社の「あるべき姿」を認識していること
  2. 自社の抱えている課題を客観的に把握していること
  3. オープンな議論ができること
  4. まとめ際を心得ていること(システム・ベンダーとの間で適正な妥協点を探る能力と、自社各部門への説得能力)
などが上げられます。
 2つ目はシステム・ベンダーのSEの態度です。限界はあったにせよユーザーへの提案と説得がプロジェクト管理者としての任だったはずなのに、ただ相手の言うがままになった主体性のなさが問題をここまで大きくしたのです。
 SEにとって、「聞く耳を持たない」相手を説得する労力は並大抵のことではありません。しかし、ある程度結果が予測できる状況にあるとすれば、たとえ顧客の意に添わなくても徹底的に立ち向かうことが問題を解決する最適の方法になります。それでも解決を見ない時には、プロジェクト担当者だけでなくユーザー全体を巻き込んで論議する勇気とマネジメント術を包含した「人間力」が求められるのです。

オーパシステムエンジニアリング