システム導入プロジェクトでの考察
１．序論
ＩＴを導入する企業やＩＴを提供する企業がまず最初に行うのがプロジェクトを立ち上げることから始まります。
プロジェクトの規模は導入企業と提供する企業を合わせると、小さいものでは数人ら 大きいものでは１０００人規模に近くまでさまざまで、このプロジェクトをどの様に運営管理してゆくのかについては、ＰＭＢＯＫやＩＴＣなどのガイドラインで定義されており、ほとんどのプロジェクトはこれに基づき運営管理され推進されていると思います。
本来であれば、定められたプロジェクト運営方針に従い進めることで計画通り、品質や納期が守られプロジェクトは終わるはずである。
ところが、ほとんどのプロジェクトは品質不安、工程遅延を抱えながら進められ、品質問題、納期遅延により、受入れ側と提供側で深刻な問題にいたり訴訟問題となることもある。
また、社会的には「動かないコンピュータ」として世の中に公表される事態にまで至ることもあります。
なぜこの様な事態が発生するのか、次の視点で考えてみたいと思う。
（１）受入れ企業側の課題
（２）提供企業側の課題
今回は、「受入れ側の企業」でシステム導入段階で、実際にあったプロジェクトで受入れ企業側の問題について考えてみる。
２．本論
ある企業で「営業部門の引合い」、「設計」、「調達」、「生産」、「保守」までを含めた企業活動にまたがるＩＴシステムの見直しを含めた企業内ビジネスフローを見直すと言うもので、この時期アメリカを発端としたサブプライムの不況から６ヶ月がたっており、企業経営はコスト削減を行い経営のスリム化を進めている中で、景気回復に向け競合他社を意識した企業体質強化を図るため、経営トップからの指示で１年で「ＩＴ導入計画」をまとめる事となった。その主要目的は
（１）コスト削減
（２）リードタイム短縮
これに対して、部長クラスを中心としたシステム検討プロジェクトを立上げ検討が行われている状況であった。
プロジェクト体制はシステム部、設計部、生産技術、調達部を中心とした体制であった。偶然この時期に、私が生産技術部門、生産部門の課長、主任クラスにＰＬＭ（プロダクトライフサイクルマネージメント）についての勉強会を実施しており、生産技術と生産部門の導入システム概要、業務上の問題点についてある程度は状況の把握ができている状況であった。
当社も提案を行うこととなりＲＦＰ説明会に出席しＲＦＰの提示を受け、内容を確認した所、全体業務と考えていたが内容は、「設計ＣＡＤ、図面情報管理」の技術情報を中心に要求されたＲＦＰであった。
そこで、経営トップに確認したところ「課題は、リードタイム短縮であり受注から出荷までのＬＴ短縮で指示している」との回答を得たため、情報システム部にも確認したとこ「生産については工場に任せている」との回答があった。
そこで、生産技術、製造部の勉強会メンバーに確認したところ、「そんな話は聞いていない」との一言であった。
ＲＦＰが提示されている以上、これに基づき提案を行う必要があるため、プロジェクト検討メンバーに対してプレゼンテーションを実施し、結果として同業他社への導入実績があるとの事で、当社と他１社の２社に絞られた。
最終提案に向けて、プレゼンてーションを行うとの通知があり、最終提案準備と第１回目のプレゼン評価確認を行った、その状況は次の通りであった。
（１）検討プロジェクトメンバー
モノ作りの部分が説明されていない事が、原点となっている次回はモノ作りの部分
についてプレゼンをしてほしい。
私 ：ＲＦＰには生産に関する要求事項は記載されていませんよ？
システム部：工場の製造部門が言ってきている。
（２）勉強会メンバー（工場の製造部門方々）
前回と同じでシステム導入の話聞いていない、上の方で遅くまで何かやっている。
システム部に工場の状況を確認すると、製造部長からの話しであることが分かり、製造部長に確認したところ、「工場にコンピュータシステムは導入していない。現状は手作業で進めており導入していたとしてもＥＸＣＥＬを使っていると程度」との説明を受けた。
・・・・勉強会メンバーから聞いている話と異なっており、生産実績、調達手配、原価集計
はどの様に処理されているのかをお聞きしたが「そんな事は確認していない」との返
事であった。
そうこうしているうちに１ヶ月が経過して、最終提案プレゼンの日を向かえた当社の提案内容は「勉強会メンバーの話」を踏まえて「設計と技術情報管理」「生産計画・実績システム連携」の内容で提案を実施した。
その１ヵ月後に最終提案の結果があり、「設計ＣＡＤ」は当社に決定したが、生産部分については当社以外で保留となったとの報告を受けた。
保留となった理由について確認したところ次の通りであった。
当社以外の１社に決めたいとの事であったが、辞退されたとの事で次の辞退理由の説明があった。
（１）プロジェクトに現場の課題が反映されていない
（２）現行システムの課題・問題が分からない
（３）改善課題が整理されていない。
提案要求から１年を経過した検討を行ったなかで、ベンダー側の結果として「ベンダーの辞退」、「ＣＡＤの受注」となり、結果が出ていないのは「お客さま」となってしまった。
後日、私から勉強会メンバーに対し「ベンダー側にも問題」があったが、「お客様にもシステム導入の進め方に問題があった」と説明をし、このままであれば代わりのベンダーが見つかっても同じ状況の繰り返しになると最後の挨拶をしたところ、今度は「システム導入検討の方法」について勉強会をして欲しいとの依頼を受け、継続してメールで勉強会を行うことなった。
その後、プロジェクト検討会メンバーは解散し結果を出せなかったとして人員配置があり、メンバーを一新してプロジェクト再検討をスタートすることになったと、勉強会メンバーからメールが届いた。
３．結論
以上の例は、プロジェクト立上げ導入検討段階でのプロジェクト失敗例で、ベンダー側には影響はなかったものの、お客様では、カンパニー社長移動、システム部長移動、生産部長移動となり組織的に大きな影響がでたプロジェクトの結果となった。
検討プロジェクトで「システムの目的」、「導入範囲と優先度」、「プロジェクトの周知」」の
面での問題はあるがコミュニケーションとしての問題も大きいと考えるが
この結論として、日々必要なことができていないの問題と考える。
（１）検討メンバーには、実務担当者が参画していない、意見も求めていない。
（２）上司が現状把握・認識できていない。
（３）システム部門と現業部門との情報交換がされていなかった。
（４）部門、部下に任せ切りで他人任せ状態であった。
（５）ベンダーへの情報提供が皆無であった。
４．考察として
今回のケースでは色々と、問題はあると思いますが以下のように考えます。
（１）経営トップが、検討メンバーに任せ切りで積極的に参加うすべきであった。
（２）検討メンバーである部課長も、部下とのコミュニケーションがなかった。
（３）信じられないが、自部門の情報システムを部長が把握していなかった。
（４）システム部門が現場のシステムを把握していなかった。
（５）導入システムの検討が不十分であった。
５．後日談
勉強会メンバーからの連絡では検討プロジェクトメンバーの主役が一新され、新しくメンバーを一新し検討プロジェクトを再ステートさせるとのトップ方針が決まったとのメールを頂いた。
今度おの社長は営業出身でご自身で先頭を切って主導されるタイプとの事。
内心、楽しみがひとつ増えた。・・・このお客様当社が筆頭顧客なのです。
以上、
三谷浩一
