業務部門編の上では，大手製造業に勤めるマネージャのAさんが古巣の部品倉庫のシステム再構築に乗り出すケースを語った。Aさんは部品を統合管理するシステムを夢見るが，予算獲得の段階で早くも，夢を縮小せざるを得なかった。

システムは完成すれども，悩みはつきない

　システムがほぼ完成し，現場スタッフの教育のために古巣の部品倉庫を訪れたAさんは衝撃を受けた。かつては社員たちが様々な問題意識をもって改善に取り組んでいた。それが今の現場はパートタイムや日本語すら通じない外国人労働者が多くいる。こうした人たちにモチベーションを持たせて，新システム導入に伴う業務プロセスを変えてもらわなくてはならない。一体どうやって彼らを教育すれば良いのか，Aさんは頭を悩ませた。

　さらに，かつて尊敬した現場の元上司すら，新システム導入で現状のプロセスから大きく変わる部分については抵抗を示し，そのメリットを理解しようとはしなかった。これではせっかくのシステムがいかされないとの危機感から，システムの最終チェックを部下に任せ，Aさんは全国の倉庫を直接訪れ，現場調整に多くの時間を割かざるを得なかった。

　一方，システムの運用にあたっても，新たな問題が発覚した。当初以上に現場へのサポートが必要と判断したことから，ヘルプデスクを強化する必要が生じていた。システム自体もハードの保守以外に，導入したパッケージのライセンス・フィー，開発したソフトのメンテナンス，それに絡むミドルウエアのメンテナンスなど，当初の見積もりより多くの費用が発生した。

　そこで，Aさんは当初，全面的にサポートすると言ってくれた上司に相談に行った。ところが，会社のおかれている状況では，追加の申請は難しいとにべもない。別の部門費をなんとか切り詰め，運用費用をまかなおうとはしたものの，金額が大きく上回っていることから，結局上司をなんとかなだめ，追加申請を行うことにした。

　このプロジェクトは，こうした様々な障害から，予定のスケジュールや費用を大幅に上回ることになった。それでもなんとかシステムを導入したAさんは，当初見積もった効果について誰も言及しないことを祈りつつ，今日も現場スタッフの不満やシステムの不備についての問い合わせの応対に慌しい日々を送っている。

Aさんの落とし穴

　さて，こうしたAさんのケースをお読みになって，読者の皆さんはどのように感じただろうか。コンサルタントとしていろいろな現場を見てきた立場からすると，後知恵になるかもしれないが，Aさんの打ってきた手について，もっと良い手があったのではないかと思うところもある。

　まず，パッケージ導入について。パッケージを，自社特有の業務プロセスに合わせるためにカスタマイズに工数をかけていては，パッケージ導入のメリットは薄れてしまう。通常，カスタマイズ部分が多ければ多いほど，パッケージを利用は避けるべきであろう。また，パッケージを利用することにより業務改革を起こし，作業の無駄やコストを抑えることを主眼としているのであれば，初めからそうした心構えで行くべきであった。

　Aさんは，当初は業務改革を狙っていたかもしれないが，現場の反発などから腰砕けになってしまったのではないだろうか。結局，パッケージのメリットをいかし切れない形での導入となってしまった。最初の段階で，パッケージを利用する際のメリット・デメリットをもっと良く検討すれば，こうしたことは防げたかもしれない。

　要件をまとめ，ベンダーを選定する際にも，細心の注意が必要である。Aさんの場合には社内の意見を統一するのに手間取り，要件定義やRFPの作成に十分な時間を割けなかった。結果としてベンダーからは前提条件の違う，価格比較のできないプロポーザルが並んでしまった。

　そればかりか，その後の開発に向けては多くの誤解が発覚することになった。しっかりビジネス要件を固めておくことが重要であり，ベンダーからアイディアをもらいたいところではその旨を明記しておくのも手である。どうしても社内に要件をまとめるスキルがない場合には，RFPの作成段階から外部の専門家と契約してしまう手もある。

　また，プロジェクトの投資対効果の検証はできていただろうか。会社から貴重な投資原資をもらうのであれば，それを十分正当化するだけの効果をコミットしなければならない。こうしたプロセスがなければ，言った者勝ちとなってしまい，企業は，現実味のない効果を並べているプロジェクトに対しても，予算を支出することになってしまう。

　システム投資の効果をモニターするために，KPI（Key Performance Indicator：主要業績評価指標）を設定しておくという方法がある。予算申請時にKPIを設定しておき，システム稼働後，KPIが達成できているのかを絶えず確認することにより，予算を獲得したプロジェクトが正当なものであったかをチェックする。思ったような効果が出なかった場合には，その原因究明，対応策の検討に役立てることができる。

　仮にAさんがシステムの導入により残業時間が20％削減できるとの試算をしたのであれば，その効果がでるかを定期的にチェックする必要がある。もしこの削減が達成されていないのであれば，どこにその問題があるかを究明し，解決策を講じる必要があろう。例えば現場スタッフのトレーニングが不足しているだけかも知れない。

　最後に現場に落とし込む場面であるが，せっかくのシステムも現場が使って何ぼのものである。本社と現場で別れている場合には，特に綿密なコミュニケーションが必要である。システムの開発時には，必ず現場を巻き込んで策定することが，後々のトラブルを回避できる。

　Aさんが，システムがほぼできあがった段階で，久しぶりに古巣の現状を目の当たりにした，というのは遅すぎたのではないだろうか。早くから現場に出向き，開発に元上司なども巻き込んでいれば，大幅な追加投資を避けることができたかもしれない。

　これらの点に注意を払えば，Aさんはより有効に時間を活用でき，システムの開発にもそれほど多大な出費を避けることが可能だったのではないだろうか。

■著者紹介： こぐれ　ともゆき。1991年，上智大学を卒業後，東京銀行（現東京三菱銀行）に入行。 為替資金部，ロンドン支店，投資顧問などの業務に携わる。2000年セピエントに入社。金融，製造，情報サービス，旅行業などのWeb戦略の立案および構築プロジェクトを指揮。また製造業における各種トラブルITプロジェクトに関する火消し役としてプロジェクトを推進。2003年1月にサイエント ジャパンへ移籍。