TOP＞プロジェクト管理＞ ケース1：人材活用

だからあなたの会社のシステムは動かない 〜システム発注担当者の悩みを解決します〜 第11回：先達に学ぶ 〜トラブル事例紹介〜 著者：システムクリエイト  田中 徹   2005/2/3

1   2  次のページ

このコーナーでは、いかにしてシステム発注で失敗をなくすかということについて述べてきました。今回は、いくつかの失敗例を紹介します。その原因を探ることで、失敗を未然に防ぐための参考にしてみましょう。

ケース1：人材活用

情報システム部の担当者が元SEということで、彼を開発リーダーにし、派遣会社からSE、プログラマを数人派遣してもらい開発にあたった。しかし、スケジュールが大幅に遅れ、システムに対する評価も十分なものは得られなかった。

失敗原因

開発のリーダーになった元SEは、開発経験はある程度あるものの、現場を離れて数年たっていた。そのため、開発環境、運用環境の変化、データベース、開発言語を始めとするツールの進歩に精通しているとは言いがたく、結果、システムに求められる要求を十分に実現する設計が出来なかった。    また、派遣会社からきた数名のSE、プログラマについても、個々のスキルはある程度納得できる人材だったが、特に必要なスキルのエキスパートや、設計能力を有する技術者という点では不足であった。    これは、開発前の企画から基本設計の段階で、どんな環境で運用するのか、開発環境はどうするのかということについて、社内で十分な検討が行われず、いわば見切り発車した形で技術者を揃えてしまったことが原因である。

対応方法

能力があるとはいえ、やはり開発現場を離れて久しいので、相談できる対等な立場のリーダー的人材を初期の段階から受け入れていれば、基本設計、技術者の選定、開発スケジュールなどで質の高い作業ができたであろう。    また、外部の人間が1人入ることで、同じ意見を上に提言するにも、受け止める側の姿勢が違ってくることになるので、問題点は問題点として、聞く耳を持ってもらえることになる。

ケース2：社内体制の不備

開発会社に依頼し、一応の本番稼動はしたものの、いくつかの面で不備が目立つ。開発会社に修正を依頼すると、追加仕様として有償での対応と言われたが、納得できない。

失敗原因

発注側において、開発会社から渡される仕様書等について、内容は見ても分からないし、専門家が作ったものだから大丈夫だろうと、詳しい説明を受けなかった。開発会社も納品した仕様書について特に何も言われなかったので、納得してもらえたと判断。    しかし、その仕様書について詳しく見てみると、不備な点が目立つのは明らか。特に細かい点で具体的な処理が書かれておらず、決して満足な仕様書とは言えない。その点について開発会社に話を聞くと、「ある機能についての詳細な処理を質問しても、回答が返ってくるまで時間がかかったり、明確な答えではない場合が多い。」と言う。それでもスケジュールが迫っていたので見切り発車的に設計を行ったとのこと。見切り発車については、発注側に説明済みであると主張。    仕様書とは、「専門家による専門家のためのもの」ではなく、「専門家が作成する、一般の人が理解できるもの」という認識のもと、内容について分からないことがあれば積極的に質問するべき。

対応方法

最大の原因は発注側の体制の不備が挙げられる。担当者に権限がないため、開発会社からの質問に対して即答できず、担当部署に聞きに言っても、時間がかかったり、その場で明確なやり取りができず、開発会社が求めるものと違う方向性の回答をしたりすることもあった。    ただ、開発会社もそのことについて指摘し、体制を整えてもらえる様進言するべきであったのではないだろうか。それでも体制が整わず、後のトラブルの要因になると判断したなら、打合わせ等の議事録を常に作成しておくべきであった。そうすれば、発注側も何が問題点か、どんなことが後のトラブルの種になり得るかが分かってくるので、発注側も体制を整えることを優先したであろう。

ケース3：開発会社への対応

開発を任せたシステム開発会社や担当SEに対し、「専門家だから…」「プロだから大丈夫だろう…」という気持ちから、不満があるのに言えずにいた。その結果、満足いくシステムにはならなかった。

失敗原因

システムとは、発注側と開発会社の共同作業で作り上げていくもの。そのことを理解していれば設計、開発は全面的に開発会社に任せるとしても、業務に精通している発注側がリーダーシップをとるべきである。

対応方法

開発会社や担当SEの技術スキルやコミュニケーションスキルに疑問をもったら、率直に意見をぶつけることも大切である。いままで手掛けてきたシステムを訊いたり、担当SEの業務経歴を提出してもらうなど、必要に応じて訊いてみる。

1   2  次のページ

著者プロフィール システムクリエイト有限会社  田中 徹 代表取締役。1963年生まれ。MS-DOS時代から、汎用機−PCでのデータ送受信を行ってのチャート（金融業）、表・グラフ描画（財務系）などのシステム開発を行う。 社内人事管理（勤怠・人材活用）、流通業、制御系の分野や集計業務なども手掛ける。ソフトウェアハウスや大手開発会社まで多数の現場で開発を経験し、33歳で独立。現在は各業種・分野でSEとして、またシステムコンサルタントとして活動中

INDEX 第11回：先達に学ぶ 〜トラブル事例紹介〜 ケース1：人材活用   ポイント別トラブル対応方法

だからあなたの会社のシステムは動かない 〜システム発注担当者の悩みを解決します〜 第1回 システム発注担当者の苦悩 第2回 システム開発の流れ 第3回 開発形態と開発会社の規模による違い 第4回 見積もりについて 第5回 発注側の体制・社内体制を整える 第6回 発注担当者に必要なもの（1）〜業務知識とIT知識、業務フロー〜 第7回 発注担当者に必要なもの（2）〜社内調整、SEとの付き合い方〜 第8回 そもそもSE、プログラマってどんな人？ 第9回 さあ困った 〜その時発注担当者がするべき事は〜 第10回 本番に向けてのテスト 第11回 先達に学ぶ 〜トラブル事例紹介〜 第12回 よりよいシステムにするために