営業部が発注したシステムを運用部門が受け取り拒否！――ユーザー社内のゴタゴタに巻き込まれた新興システム開発会社の運命：開発残酷物語（10）（3/3 ページ）

トラブルの原因は何だったのか、どうすれば良かったのか。実在する開発会社がリアルに体験した開発失敗事例を基に、より良いプロジェクトの進め方を山本一郎氏が探る本連載。今回は、外国人エンジニア同士の感情のもつれが由来のトラブルと、ユーザー企業の営業部門（発注元）と運用部門（納品先）の合意が取れていなかったために納品後1年以上もシステムが塩漬けにされたトラブルの2本立てでお送りします。

[竹内充彦，＠IT]

後出しジャンケン

　「そうなんです。私も突然のことに驚きました。プロジェクトの初期段階できちんと要件定義はしていたのですが、出来上がったシステムを見た倉庫管理の現場から『業務フローが変わってしまうのは困る』と不満が出たので既存の在庫管理データベースを作り直してほしいと」（林氏）

うわー（楽しそう）

　「マスターデータベースを書き換えると分かっていれば、開発費も1桁は違うし、期間も要員も仕切り直しになってくる。そんなこと、後から言い出されても無理ですよね」（山本氏）

　「はい。それで、『今からそれをやるには、費用が追加でこれだけかかる』と見積もりを出したら、また連絡が来なくなりまして（苦笑）」（林氏）

　林氏が後から聞いた話では、その見積もりを高いと思い込んで他の発注先を探したが、他社からは同社の倍以上の額を見積もられたらしい。結局、追加の改修は行われず、納品したシステムが使われることはなかった。

　システムの作り直しを納品1年後に言ってきたり、料金をふっかけたと疑ったりしてきたユーザー企業との関係は、その後どうなったのだろうか。

　「社長から食事に誘われて、そこで謝罪されました。それで、水に流そうということになり。今では同社のITコンサル的な役割でお付き合いが続いています」（林氏）

　「引き受けたんですか？　お話を伺っていて、林さん本当に誠実な方ですよね。というか、よく食事の席に行きましたね。私だったら絶対に行かないなぁ。必ず罵り合いになるから（笑）」（山本氏）

　「……（苦笑）」（林氏）

中小企業にはよくあること

　トラブルの原因は、発案者である営業部門と、実務を担当する倉庫部門との温度差やコミュニケーション不足にあった。

　営業部門の「新しいビジネスを創り出そう」という思いばかりが先行し、運用部門が要件定義に携わっていなかったため、出来上がったシステムを突然渡された運用部門は「余計な仕事が増えた」と受け取ったのだ。

　林氏もその点について「システム開発に慣れていない中小企業は完成形をイメージしていないことが多いので、私たちがしっかりと周知していくべきでした。会社を設立して1年もたたない頃の話で、どうしても取りたい案件だったため、私にも焦りがありました。技術的な部分の説明に終始していたかもしれません。もっと実務面で踏み込んだ説明をしておいた方がよかったと今となっては思います」と、謙虚に反省点を認める。

　さらに、中小企業はオーナー会社が多いため、システム導入に際しては、社長をいかに巻き込んでいくかが成功への大きな鍵になると悟ったそうだ。社長が陣頭指揮を執り、現場を巻き込むことで、少なくとも今回のような部署間の温度差は解消できるからだ。

　ただし、経営層と現場の温度差はある。システム開発企業は自分たちでも、要件定義の段階で関係部署の担当者にしっかりとヒアリングを行い、ワークフローの変更などについても合意形成しておくと安心だろう。

---

　海外オフショアでのケースも、ユーザー企業のケースも、「組織内のコミュニケーション不足に端を発した問題」といえる。

　システム開発企業はパートナー企業や顧客企業の組織内のコミュニケーションにどこまで踏み込めるか、今後はそうした面が問われるケースが増えていくだろう。

　「しかし、サンシステムさんは、どのケースもきちんと対処されていて『残酷物語』になる手前で回避している。当連載としては寂しい限りですが、スゴイことだと思います」（山本氏）

　「ありがとうございます（苦笑）」（林氏）

顔で笑って、心で泣いて

次回も、山本一郎氏が「炎上」事例を斬る！

　次回以降も山本一郎氏が、開発会社の炎上事例をぶった切ります。お楽しみに。

写真：渡邊宏

発注ナビとは

「発注ナビ」は、システム開発を中心としたITサービスに特化した会社の検索・比較サイトです。

システム開発を検討している発注者をサポートし、日本全国の数ある開発会社の中から最適な発注先を見つけられるよう、さまざまなサービスを展開しています。