１．はじめに

　　ITコーディネータとしての職務上、顧客企業からERP導入の支援を求められることは珍しくはないはずです。そのときみなさんはどのように顧客企業を支援していかれるでしょうか。もちろん、企業規模、導入目的、企業文化、業種、予算規模など背景の相違により、その進め方はさまざまでしょう。

　　筆者は、最近自社におけるERP導入を統括し、幸い成功裏にかつこの種のシステム導入としては短期間に完成させることができました。このプロジェクトの成功要因（ITC的に表現すると“CSF”）を振り返って考えてみますと、一つひとつは「当たり前のことを実行する」に尽きます。しかしながら、実際の多くのERP導入は、当たり前のことを当たり前にできなかったために失敗したのではないでしょうか。当たり前のことを行って、あるいは行わせて、プロジェクトをリードする手腕こそITコーディネータにまず求められる責務であると筆者は考えています。
類似した業務に取り組まれるみなさんの参考となれば幸いです。

　　なお、本稿では、具体的な名称や数値、商品名などは可能な限り伏せさせていただきました。より具体的な情報を求められる方は「まいど！フォーラム」を通してご遠慮なくお問い合わせください。

２．本稿で扱うフェーズ

　　本稿では、まずERP導入プロジェクトの立上げからERP選定までのフェーズ進め方を述べます。その後、社内承認を経て実際の導入へと進むわけですが、後のフェーズに関しては続編に記述します。

３．事例対象とした企業とプロジェクトの概要

　　以下は、筆者が取り組んだERP導入について、規模観をもっていただくための情報です。

（企業概要）
　企業規模：　年間売上げ　約600億円、　従業員数　1,500名、　
　業種：　
　製造業（工場設備）対象のエンジニアリングと建設工事、システム開発/保守

（プロジェクト概要）
　期間：　プロジェクト立上げ　から　ERP選定　まで　４ヶ月
　　　　　　ERP発注　から　システム稼動　まで　９ヶ月
　対象業務：　
　　事業の原価管理、調達、営業、経理、および決裁にかかわるワークフロー

（付帯状況）
　システムの専門部署を除いて、社内全般にITリテラシーは非常に低い。
　２社合併に伴う基幹システムの統合を兼ねる。
　合併前の２社ではそれぞれオフィスコンピュータで原価管理、調達、経理などを
　処理していた。

４．プロジェクトの立上げ　　・・・・・　プロジェクトとその方針を徹底的に周知する　・・・・・

　　システム再構築の意思表明がトップから出されたのを受けて、対象、構築期間、進め方の手順など、企画書を作成しました。そして、社長が企画書を承認しプロジェクトをスタートさせました。

　　プロジェクト立上げの宣言には次の項目を含めました。
　１） ERP導入の目的（原価管理の精度改善、仕掛り品の減少、など）
　２） 導入方針
　　（ベストプラクティスを導入し自社の業務プロセスを改善する、など）
　３） 社長をトップに置いたプロジェクト体制と実務メンバーの明示と周知
　４） カットオーバー日を明示した工程
　５） 概略の予算

　　プロジェクトの周知について：　プロジェクトの立上げは社長自ら経営会議など社内で公式に宣言します。当該プロジェクトを知らないことが企業内では職務怠慢と見られるまでに、徹底したプロジェクトへの認知を、役員や幹部社員にしてもらう必要があるからです。ERP導入はトップダウンで扱うべき性格を本質的に持っています。なぜなら、多くの社員にとって業務の仕方は変わらないことが心地よく、変えることは個々の社員から必ず抵抗を受けるからです。ITCにとって社長以下の役員や幹部からの支持を得続けることがプロジェクトの成功に必須です。企業幹部にも、当然ですが、プロジェクトに対する義務感と責務感を持ってもらわなければなりません。プロジェクトへの協力義務について、社長や役員の口から折に触れて全社員に繰り返し発言されるようにITコーディネータが仕掛けることも大切です。
　　１）と２）について：　　プロジェクトの目的と方針はプロジェクト完遂まで絶対にぐらつかせてはなりません。事前に十分な議論と意識合わせをITコーディネータが社長および担当役員と行っておくことが大切です。またプロジェクトの途中でも目的と方針の再確認を社長以下と繰り返し行います。プロジェクト遂行の途中で必ず抵抗勢力が現れます。それをはねつける力を推進者はあらかじめ用意しておく必要があります。目的と方針の固守はそのための非常に重要な要素です。プロジェクトへの非協力的な姿勢、非協力社員は個人の人事的評価に悪影響を受けることをさえ社員と管理職に認識させる場合もあってよいと思います。
　　３）について：　　プロジェクトに直接参加する実務メンバーは社内で広く認知されるようにします。核となるプロジェクトメンバーは社内各部署の実務キーマンとうまくコミュニケーションの取れる専任者であるべきです。企業内各部署からも、兼任でよいから、部署要求を整理しまとめる責任を負う担当者をプロジェクトに加えてもらいます。
　　４）について：　　工程はリーズナブルである限り厳しい短期工程を設定し、かつプロジェクトメンバーで工程厳守の高い認識を共有します。これによりプロジェクトは常に緊張感を保って進められます。また、短期間であることは導入予算低減させるためにも非常に有効です。
　　５）について：　　概略予算は、調査により同規模他企業の事例を参考にセットします。他社事例を調べることは、ここで示す予算に説得力を持たすために必要なことです。プロジェクトに用意できる金額が他社事例の金額と比べて桁違いに合わなければ、計画を白紙に戻して組みなおすことが賢明です。

５．対象業務の分析　　　・・・・・　ERPで何をさせるのか把握する　・・・・・

　　このフェーズではERPでカバーされるべき社内業務を分析し文書化しました。これをここでは「業務プロセス分析書」と呼びます。今回の場合、プロジェクト立上げ後1ヶ月をかけて業務プロセス分析書を作りました。
　　業務プロセス分析書では、現状の業務とあるべき業務をフロー図などに図式化します。この目的は、ERPで何を行わなければならないか、行わせたいか、ERPで何をさせるのかをプロジェクトメンバー全員が知るためです。ERPを導入し始めたものの、何をさせたいか具体的要求を表現できず、一方で「使いにくい」の大合唱に遭遇し、結局ERP導入が途中頓挫することはよく起こります。社内業務のどこをERPというツールに頼るのか、メンバーが認識を共有する必要があります。そのための図書が「業務プロセス分析書」です。ITコーディネータはこの文書作成を指導し、監査し、まとめさせます。フローは、通常多部門間にまたがる形になるため、部門それぞれがどのタイミングでどのような処理をするか記述させます。一例として、受注から設計、製作、納入、調整、完成検査、検収、売上げにいたる一連の社内業務プロセスがありました。　
　　業務プロセス分析書に対しては、自らが作った要求という意識を対象全部門とプロジェクトメンバーに持ってもらいます。業務プロセス分析書をITコーディネータが勝手に作ったとか、自分たちは内容をよく理解していない、などと言わせてはなりません。自分の責任で作った自分たちのための分析であるという意識を企業の全部署に持たせるよう誘導します。
　　なお、業務プロセス分析書において、いくつかよくある異常処理（例：　返品、紛失、クレーム処理、受注前の先行処置、など）にも触れておきます。この時点ですべてを記述する必要はありませんが、不完全でも異常処理を認識しておくことが重要です。
　
６．RFP作成とベンダー評価　　　・・・・・　ERPベンダーの知恵をフルに使う　・・・・・

　　次にERPベンダーに対してRFP(Request For Proposal)を提示しました。ここでRFPの内容とは、前フェーズで作成した企業の業務プロセス分析書です。ERPベンダーの中から企業規模や実績、知名度からいくつかの候補を抽出し、そこに対して業務プロセス分析書を説明します。ERPベンダーには、当社が説明した業務を自社製品を使ってどう実現するか提案させました。このフェーズに2ヶ月を要しました。
　　これは非常に重要な進め方です。一言にERPといっても多くの製品が市場に溢れており、その中のどれが自社の業務に合うか使う側（顧客企業）やITコーディネータが自分で判断することは非常に困難です。業務分析書をERPベンダーに提示してベンダー側に考えてもらうことが時間の節約と正しい評価に非常に有効です。
　　このフェーズでは次のようにプロジェクトを進めました。
　１） ERPベンダーからの提案書と見積書の提出
　２） 1次評価をして選考対象を絞ること
　３） 選考に残ったERPベンダーの製品を用いたデモ
　４） ERPベンダーの製品を既に導入した企業への訪問調査
　５） 予算と社内事情を考慮してERPでカバーする業務範囲の見直し
　６） ERPベンダーへの追加質問、見積範囲のレベルあわせ
　７） ERP評価表作成

　　１）について：　　ERPベンダーからの提案書には、どの範囲が当該ERPの標準機能によってカバーされ、どの範囲にアドオン（＝追加開発）が必要かを明示させます。いわば荒いフィット／ギャップ分析をここで行っていることになります。言うまでも無く、アドオンが多ければ多いほど初期導入の費用が増加します。期間も余分に必要となります。アドオンされた部分でのバグ検証などシステムの信頼性も落ちます。導入後のメンテナンス、バージョンアップにも手間と時間と費用が余分にかかります。したがって、可能ならばアドオンなして導入できることが望ましいはずです。
　　２）について：　　選考対象を絞るのは、これ以降のフェーズでの評価の手間と日数を少しでも少なくするためです。
　　３）について：　　デモでは業務プロセス分析書に沿った業務イメージを各ERPベンダーに製品を使って実際に示してもらいます。各部署から派遣された兼務のメンバーも必ずデモに出席させます。このERP製品の評価のフェーズにおいても、限られたプロジェクト専任メンバーだけでなく、各部署からプロジェクトに入ったすべてのメンバーに参加意識を持たせる必要があります。そしてそれぞれのメンバーに判断を示させます。後のフェーズで、「自分の知らないところでERPを選んだ」と言わせないための重要な手順です。
　　４）について：　　導入企業訪問では、ERPの評判、導入時に生じた問題、問題に対する対策の工夫など、後フェーズで有効な情報を集めることができます。オリジナルのERPに問題があるとして、それをどのようにクリアできるのか目処を立てることも製品評価の項目の一つとなります。
　　５）について：　　ERPベンダーのデモや仕様、価格など総合的に判断して、本プロジェクトでどこまでの業務範囲をERPでカバーするか決断します。予算、期間、業務プロセス分析書とのギャップ、などを考えます。すべてのERPベンダーの提案で「業務プロセス分析書」とのギャップが大きいプロセスがあれば、今回の対象業務範囲から思い切って除外する決断も必要です。
　　６）について：　　見積範囲の精査など細かな詰めは専任メンバーとITコーディネータの連携で処理します。レベル合わせのための見積範囲調整、追加質問などを行って公平さを確保し、また技術課題の対処方法も提出してもらいます。
　　そして、７）のERP評価表を作成します。

７．ERP評価表とベンダー決定　　　・・・・・　目的/方針を固守しつつ決める　・・・・・

　　いよいよ導入するERPの選択について意思決定を行う段階となりなます。
評価項目は次のようなポイントとしました。
　１） 価格
　２） 当該ERPの特徴と今回の導入方針や目的との合致度当該ERPを選ぶことが、固持すべき当初方針や目的に合致した選択となるかどうか。
　３） アドオンのソフト製作量の大小、およびフィット／ギャップの評価。ERPの仕様や機能に要求との差異や問題がある場合にはその解決方策と費用・工期の概要
　４） 製品デモに対するプロジェクトメンバーからの評価
　５） ベンダー技術者の経験、資質と人数（＝人的動員力）。ERP構築時に万一問題が発生した場合、要員を増強してリカバリーできるポテンシャルを評価する。
　６） ベンダー企業とERP製品の継続性。ベンダーが倒産する、ERP製品へのサポートを止める、などのリスク評価。

　　これらの評価表を作成し、まずプロジェクトメンバー内での意識統一を行います。これも、「他のだれかが勝手に決めた。」という意識を持たせないためです。プロジェクトメンバーその意識合わせに基づいて書面にし、社内承認手続きを行います。

８．ERP選定までの結び

　　以上が、ERP選定までに踏んできた各フェーズと進め方のポイントです。筆者の場合には、プロジェクトの立上げを宣言してから社内承認まで4ヶ月を要しました。選考対象としたベンダーは、当初6社程度。本格的な提案要請は3社に対して行い、最終選考は2社に絞りました。
　　内容を見ていただくとわかるように、プロジェクトの立上げ、業務の分析、RFPの作成、ベンダー決定、それぞれに若干の工夫をしつつも、当たり前のことを手順を踏んで行ったに過ぎません。冒頭に述べたとおりです。目的や方針を振れさせたりせず、プロジェクトメンバー全員の当事者意識を維持しつつ、当たり前の手順や行動を着実に実行することがプロジェクトを成功裏に完遂するために必要であることを、改めて強調しておきたいと思います。

　　　　　　　　　　　　　ITコーディネータ　松下　悟　（まいど！フォーラム　メンバー）

ラベル: ERP, ITC, 事例

■失われた２０年とチェンジリーダーの減少

　ＩＴ導入プロジェクトにおいて、その成否を分かつ大きな要因のひとつに「チェンジ・リーダの存在」がある。しかしこの20年近くは、欧米流のマネジメント手法に基づいて数字（成果評価,キャッシュフロー,etc.）を追い続け人材育成をおろそかにしてきた結果、驚くほどチェンジリーダーという人材が減少している。

　チェンジリーダーとは、ＩＴ導入プロジェクトにおいて、情報システムと業務プロセスの変革の中核となって、プロジェクトの目標を達成し成功に導くキーマンである。その立場は、情報システム（ＩＴ）部門であっても、実務部門であっても良いが、外部のＩＴベンダーではなく導入企業側に存在すべきであろう。

　では、企業がそういった人材の必要性を感じていないわけでもなく、また企業によってはそれなりの予算を確保して手厚い人材教育を実施しているにもかかわらず、本当に意味での「チェンジリーダー」が育っていないのはなぜか？

■チェンジリーダーが育っていない具体例

「チェンジリーダー」が育っていない要因を導き出すために、私が関与したＩＴ導入プロジェクトの現場で発生した事実を例示する。まずは、実務部門での事例である。

１）ＳＣＭ／サプライチェーン・マネジメント・システム導入プロジェクト
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　サプライチェーン・マネジメント（以下、ＳＣＭ）システムの導入では、組織や会社の枠を超えた「情報共有」がＩＴ面での中核となる。また、共有した情報に基づいて業務プロセス（ビジネスモデル）を変えてしまうようなケースもある。こういったＳＣＭ導入プロジェクトのチェンジ・リーダーには、複数の組織や企業の枠超えた「調整能力」と、その利害関係者の意識を変えさせる「ビジョン」、そしてプロジェクトを計画し推進する「実行力」が求められる。

　Ｇ社では、実務部門の幹部社員（Ｎ氏）をリーダーとするＳＣＭ導入プロジェクトを組織した。Ｎ氏は、これまでにも部門システムの構築ではリーダを経験したことがあった。ＩＴ部門の経験は無いが、部門におけるシステム化要件をとりまとめ、ベンダーに発注して予定どおりにシステムを稼動させたことがあり、必然的にＮ氏をリーダーとするＳＣＭ導入プロジェクトがスタートした。

　ところが、ＳＣＭ導入プロジェクトが始まってみると、Ｎ氏が立てたスケジュールがことごとく遅延して再スケジューリングを繰り返し、またプロジェクトに参画しているメンバーからもクレームが続出する事態となった。それは、Ｎ氏が自分一人で考えた机上論（理想的なプラン）でプロジェクトを進めようとしたためであった。　ＳＣＭ導入プロジェクトでは、作業効率の向上といったファクターよりも、GIVE&TAKEでの情報提供とその活用がメインであり、Ｇ社プロジェクトでも組織間の利害調整がプロジェクト成否の重要ポイントであった。当然、Ｎ氏に対してそのことは事前に認識をさせており、プロジェクト途中でも何度も確認をしていたいたが、机上論が中心で他部門に対しても高圧的な対応をとるなど、自らの「行動を変える」ことができなかった。

２）基幹システム再構築プロジェクト
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　次は、ＩＴ部門での事例である。

　Ｔ社では基幹システムの再構築プロジェクトを企画し、外部コンサルタントが参画した「新業務システム基本計画の立案策定」を終え、具体的なシステム要件分析設計に着手した。分析設計のプロジェクトは、第一次開発の対象とするサブシステム毎に複数のＩＴベンダーと、対応する社内ＩＴ部門の担当者で組織し、プロジェクト・リーダーは、Ｔ社のＭ氏が担当することとになった。　Ｍ氏は、入社以来18年ＩＴ部門に所属するベテラン社員である。今回の開発範囲はＭ氏の担当してきた分野ではなく他部門から転籍してきたばかりではあったが、人事上も幹部社員一歩手前の評価をうけており、Ｍ氏にとってもこのプロジェクトはキャリアの面からも重要なテーマであった。

　しかし、プロジェクトが発足して具体的な分析設計作業が始まってみると、Ｍ氏のプロジェクト・マネジメントスキルの無さが露見した。チームセションの開始時刻になってもセションが始まらない。来週のセション予定が見えない。プロジェクト課題が整理されていない。プロジェクトメンバーで情報が共有されない。問い合わせに対するレスポンスが遅い、あるいは無い。等など、たとえＰＭＰの資格はなくても、プロマネの立場であれば果たすべき役割が果たせない。当然、ＩＴベンダーからだけでなく社内メンバーからもクレームが上がり、プロジェクトが崩壊の危機に陥いる事態になった。

　Ｍ氏はこれまで、手厚い社内教育メニューにしたがって、数々の講習会に参加してどれも好成績で修了している。プロジェクト・マネジメントについても、ＰＭＰ受験対策講座やコミュニケーション,ファシリテーションといったテクニックだけではなく、担当分野での実務を通じた経験も有しているはずである。しかしそれは、自分が得意とする限られた範囲のみでしか機能しないのである。　また、基幹システムの再構築においてもＳＣＭの導入と同様、単に作業の効率化だけでなく、ＢＰＲ（ビジネス・プロセス・リエンジニアリング）も含まれ、利害の対立する実務部門間の調整も求められる。

　Ｍ氏は、自身が知らない分野で、そして初対面となるメンバー構成の中で、プロマネとしてどう振舞うべきかを体得してはいなかったのである。あるいは、頭では理解できていても行動することができないのである。

■「チェンジ・リーダー」が育たない原因

　２つの事例に共通していることは「行動が変えられない」ことである。頭では理解した（つもり）であっても、実際にどうやって行動したら良いのかが判らないのである。つまり、様々な書籍や講習会を通じて、知識としては習得しており、本人も習得したつもりになっている。そして、習得した知識は実践の中で試してみて調整を加えながら体得していくことは、広く一般的に当たり前のプロセスである。

　そう、その「当たり前のこと」が「当たり前に出来ない」ことが問題なのである。

　こういった場合、「行動が判らない」のであれば「行動のやり方を指導（個々に指示）」すれば良いというものではない。本質を理解していない（理解できない）状態のまま個々に指示しても、指示されたことに従う（従おうとする）だけであって、行動そのものには何も変化があらわれない。プロジェクトでは様々な案件が連鎖的にかつ同時並行で進行していく。その内の一つを指示に従って行動したとしても、次々と迫ってくる案件をサバいていくことは不可能である。

　では、なぜ本質が掴めないのか？
　それは、従来は「当たり前」であった「人を育てる」ことを怠ってきたことに他ならない。

　ここ数年、製造現場での熟練工の技能が見直されており、従来は徒弟関係の中で継承してきた技能をＩＴで継承するようなことも始まってはいるが、その基本は「人と人とのつながり」であることには変わりない。これはＩＴ導入の現場でも全く同じである。

　失われた20年の間も、企業内では人材育成の重要性は十分に認識されており、キャリア形成プログラム（ＣＡＰ）制度を導入した企業も少なくない。しかし、その教育内容は「講習会受講」やe-Learning/CBTといった「知識学習」が中心であった。一方で、本質的な人材育成実践の場であるはずの「現場」では、数字（納期,売上,成果,キッシュ,etc.）が最優先され、現場で人材を教育するというミッションが希薄化（消滅）してしまっているのである。つまり「教育は人事部門」のように「他人任せ」にして、「現場での人材育成」を放棄しているのである。

　これは、現場を預かっている管理者あるいはマネージャーの怠慢である。
　また、そういった管理者やマネージャーを放置してきた経営者の怠慢である。

　今、あたなの会社ではどうでしょうか？
　現場で人材（人財）を育成していますか？

■どうやってチェンジリーダーを育成するのか

　チェンジ・リーダーの素養として、不確実で不揃いな情報から、仮説（シナリオ）をたてて情報を収集し、その仮説を検証するスキル（仮説検証）が求められる。常日頃から情報収集のアンテナを高くし、社内外の様々な情報や潮流をウォッチすると同時にコミュニケーションをとっている必要があるが、そういった行動は本人の意識（問題意識,危機意識,当事者意識）から生まれてくるものである。

　では、どうすればそういった意識付けができるのか？

　まず、経営者や管理者／マネージャー自身が、その意識を持たなければならない。　あるいは、経営者や管理者／マネージャー自身が、そういった行動を起こさなければならない。　つまり、チェンジ・リーダーに求める行動を自らも実行することである。
　であるとするならば、経営者の行動はまさにその実践であるといえる。　経営者＝チェンジ・リーダー（オーナー）である。ここで問題となるのは管理者／マネージャーであろう。

　前述の事例でも真因はそこにあった。
　Ｎ氏の場合、実務部門の立場でありながら現場での実務経験がほとんどない。入社以来、いくつかの部門を経験してはいるが、その業務を自らが責任を持って遂行することがなかった。たとえあったとしても、それは極限られた範囲に止まっていた。ただ、理論的なアプローチが出来るという面が、部門情報システムの開発や改善には有効であったため、Ｎ氏のマネージャーは彼を安住させてしまったのである。
　Ｍ氏の場合には、入社以来18年、限られた範囲での業務に携わったきたこと。その中で、意識のあるマネージャーとの出会いが無かったことであろう。ただ、Ｍ氏自身には問題意識はあったが、結果的に前職の管理者との対立から生じた精神面でのキズを引きずっていることも判明した。

　ここ数年、心の病(風邪)である「うつ患者」が急増しており、メンタルヘルスケアが声高らかに叫ばれている。たしかに社会現象として由々しき事態であるが、スキルをアップさせるためには、プレッシャーが必要である。プレッシャーの無い仕事では人は育たない。しかし、プレッシャーが大きすぎると押し潰されてしまう。また、何か行き違いで『心が折れる』こともある。心が折れてしまうと、そのパワーは後ろ向きに流れていく。

　だからこそ「現場教育」が必要なのである。
　現場から遠く離れたオフィスの会議室ではない。ましてや電話やメールでは決してない。

• 現場でのクロスコミュニケーション（重なり合う）
• 知と知、知と情、知と技といったクロスファンクショナルなナレッジ

　それは、場当たり的な「ＯＪＴ（On the Job Training）」ではなく「意識のある現場教育」である。徒弟制度の中で当たり前に伝承されてきた技能であり『共育（共に育つ）』である。

■時間がかかる。だからこそ今すぐ着手！

　以上のように、チェンジリーダーが育たない真因とその対策を考えてきた。

　ＩＴ導入プロジェクトの成否は「チェンジ・リーダー」の存在如何にかかっているともいえる。　しかし、対策を講じれば即座に「チェンジ・リーダー」が育成できるわけではないことは明白である。　中には、ちょっとしたキッカケで瞬間に「チェンジ・リーダー」となる人材もあるが、概ね長い歳月が必要になってくる。しかも、それを企業文化（ＤＮＡ）としての継続がなければ成立しない。

　企業の経営者にとっては、今さら「中長期的な人材育成を・・・」といわれても、今まさに直面しているプロジェクトを何とかしないわけにはいかない。人材が育つまで待っているわけにもいかないので、外部の人材を活用することになるが、そこにＩＴコーディネータという切り札がある。

　ＩＴコーディネータは中立的な立場であり、そのスキルと経験次第では「チェンジ・リーダー」となりうる人材像である。また、ＩＴＣプロセスの中では人材育成計画も含まれており、中長期的な人材育成計画の立案を支援することができる。

　ただ、やはり本来は社内にそういった人材は不可欠である。
　人材育成には膨大な時間が必要になる。

　だからこそ今すぐ着手！
　人材育成計画の立案に際しては、様々な教育カリキュラムとともに、
　現場教育(共育)をぜひ取り入れてもらいたい。

（ＩＴコーディネータ／植松栄介）

ラベル: ITマネジメント

本日セミナーに参加した植松です。

今日は大変興味深いセミナーでした。
ありがとうございました。< (_ _)>
懇親会に参加できずにとても残念ですが、
またぜひ参加させてくださいませ。

今日の論文は投稿論文コーナーにＵＰしておきました。
Niftyの論文CUGですと「守秘義務」が前提ではありましたが、
BlogにUPするということは「公示／公開」ですよね。
そのあたりは投稿者が踏まえないといけないんでしょうね。
# といっても拙い論文なので恐縮です。(^O^)

今後とも、よろしくお願いいたします。

＜はじめに＞
　これまでの考察で、ＩＴＣが企業と契約を結ぶに至るプロセスにおいて、われわれ“まいどフォーラム”が提唱する「検証ユニット方式」がいかに役立つか、その実践的手法について明らかにしてきた。
　前回は、「検証ユニット方式」実践の第１回転めに専門家派遣制度（各都道府県に設置された中小企業支援センター等が実施する助成事業）を活用し、より潤滑に契約獲得に結びついた事例を紹介した。
　今回の事例もまた、専門家派遣制度を活用した契約獲得例であるが、第２回転め以降に経済産業省の「ＩＴ活用型経営革新モデル事業」という別の公的な助成制度の活用を組み合わせて、顧客便益を大幅に向上させているところに着目いただきたい。
　毎度のことであるが、仕事の発端はささいなキッカケである。本事例（Ｃ社＝小売業とする）は、ＩＴＣのＹ氏が、共通の知人であるＶさんから、販売管理システムの刷新を検討しているＣ社のマネージャを紹介されるところから始まる。

＜１回転めの経過＞
　１回転めの留意点については、前回までの考察とほぼ同じであるので、詳しいことは省略するが、肝要なことはやはり、「はじめに成果ありき」を鉄則して、第１回転めにできるだけ相手にお金を使わせないことである。信用創造に重点を置く初期段階にあっては、特に相手が価値や意味を理解できない箇所にお金をかけさせるべきではない。
　本事例では、Ｙ氏は専門家派遣制度の枠内で助言事業を行ったわけであるが、Ｃ社が新たに購入しようとしていたＰＯＳシステムについて、Ｃ社経営陣の意思決定を覆す決定的なレポートを作成した。そのあらましは以下のとおりである──。
　Ｃ社はＬ社製のＰＯＳシステムを採用していた。が、各端末がＣ社の直営する各店舗でスタンドアロンで稼働していたために、売上の情報を集めるのに、数年前まではフロッピーディスクを回収しなければならなかった。ここ２?３年は、売上情報をネット上で稼働する別のＡＳＰシステムに入力し直してサマリーだけは本社で把握できるようになったが、単品管理はできておらず、ＰＯＳとは名ばかりになっていた。
　それでもＣ社は、新規出店のたびにＬ社製のシステムを購入していた。同じメーカーのもので統一しておくほうがなにかと安心だというのが経営トップの判断根拠であった。他メーカーのシステムが混在すると、予測不能の混乱が起こりそうで不安だというわけであるが、これがＹ氏の目には明らかに不合理に映ったのである。
　Ｌ社のＰＯＳは、スタンドアロンで動いているのだし、導入年代が異なるためにソフトのバージョンがちがっているものもある。日々の売上実績はそもそも別のシステムに店長が手入力し直している現状では、他メーカーのシステムが混在したところで大した混乱が起きるはずがなかった。
　そこでＹ氏は、将来は全店の業績をネット上で即時に一元的に管理することを命題として、それが可能なシステムにリプレースすることをＣ社に進言した。そのニーズを完全に満たすシステムはその時点では存在しなかったが、開発できそうなソフトハウス（Ｍ社とする）はあった。うまくいけば節約効果は数百万円に上ることが素人目にも明らかであった。そこで、１回転めの検証ステップとして、まずＣ社でいちばん規模の小さい店舗にＭ社のＰＯＳシステムを採用し、Ｌ社にこだわる必要がまったくないことを確認したのである。

＜２回転めの経過＞
　２回転めの留意点についても前回までの考察とほぼ同じである。すなわち、１回転めで得られた小さな信用と小さな報酬をテコに、もうひとまわり大きな信用と報酬につなげるという点である。
　１回転めの助言活動で、数百万円に上る目に見える節約効果を実現したＹ氏は、Ｃ社のニーズを完全に満たすシステムをＭ社に開発させることを提案することになるのであるが、このときにＹ氏は、経済産業省の「ＩＴ活用型経営革新モデル事業」（以後、単にモデル事業と呼ぶ）の活用をＣ社に勧めたのである。もちろんＣ社のうち誰ひとりとしてこのような助成事業について知る者はなく、はじめはいぶかしげな反応だったわけだが、コンサルタントであれば誰でもこのような中小企業支援策についての趣意は心得ていて、その活用を促進するミッションを負っているといえるだろう。
　Ｙ氏の提案によれば、Ｃ社のニーズに完全に満たす独自のシステム──すなわち、グループとして運営する多くの店舗の稼働状況を、インターネットを介してリアルタイムに本部で一元的に管理できるシステム──を、新たにＭ社に委託開発すれば、満足度の低い既製のシステムを使うよりも劇的にコストが削減できるとのことである。しかも新たに開発するそのシステムは、ネットやモバイルを活用した新規性の高いシステムであったため、その開発費について国から助成金が出るかもしれないとなれば、Ｃ社にとってはたいへん魅力的な提案である。
　２回転めの検証ステップとして、モデル事業に応募する前提条件として、Ｙ氏の助言に従えば本当にＣ社のニーズを満たすシステムが開発可能なのかどうか、Ｍ社にプロトタイプを作成させて実地でテスト稼働させる必要があった。この過程でＹ氏の“まいどフォーラム”を中心としたＩＴＣの人脈（ＩＴＣには大別して経営系とベンダー系があるが、そのうちベンダー系のＩＴＣ）が役に立ったことを書き添えておく。

＜３回転めの留意点＞
　モデル事業に応募するための事業計画を作成する頃には、Ｙ氏の助言に寄せるＣ社の期待はかなり大きなものになっている。ただでさえ数百万円の節約効果のあるシステムが、意外に低い費用で新たに開発できることがわかり、しかもその半分を国が助成してくれるというのだから当然といえば当然である。逆にいえば、Ｙ氏としては、この期待をここで裏切るわけにはいかないことになるから、モデル事業として採択されるかどうかが３回転めの肝となる。
　通例の「検証ユニット方式」でも、ちょうど３回転めあたりが「経営戦略」であるとか「ビジョン策定」という意識を経営者側に抱かせる段階であるから、モデル事業応募を名目として、ここで事業計画作成に着手できることはＹ氏としても都合がよい。しかし、計画作成は必ずしもＹ氏の得意とするところではないため、またここでも“まいどフォーラム”を中心としたＩＴＣ人脈が活躍することとなる。公的機関（この場合は近畿経済産業局）向けの書類は、書式が煩雑であったり、言い回しが微妙であったり、数字が厳格であったりするために、慣れていないと摩擦の元となるのである。そこでＹ氏は“まいどフォーラム”の提唱する「ちょいサポ」（それぞれのスペシャリストが自分の得意な分野に関して少しだけサポートするという意味）という仕組みを使って、別のＩＴＣ（公的支援活用を得意とする）に応援を依頼したのである。

＜３回転めの検証＞
　結果として、Ｃ社の事業計画は、競争率５倍以上の狭き門をくぐってめでたくモデル事業として採択され、Ｙ氏はＣ社の期待に応えることができた。モデル事業に値すると進言したＹ氏の仮説が、公的機関によって検証され、実証されたわけである。ではここでＹ氏はお役ご免となるかというと、もちろんそんなことはない。近畿経済産業局には事業の進捗を報告するための書類は、Ｙ氏とその仲間のＩＴＣの助言がなければ、とても中小企業家自身の手に負えるものではないし、開発委託先ベンダーとの交渉も簡単ではない。今後展開する大きなプロジェクトにとってＹ氏は必要不可欠な存在となったわけである。

＜結論＞
　モデル事業として採択された事業計画に基づいて、Ｃ社のプロジェクトが進行していくわけであるが、このモデル事業が完結するまでが「仮説?検証サイクル」の４回転めにあたるといえる。
　さらに、モデル事業終了後も、このモデルを世間に広める（Ｃ社の知的財産となったモデルを他社向けにカスタマイズして販売）というプロセスがあり、それが５回転めになる。
　このようにＹ氏は、小さなきっかけから始まり、だんだんと大きな回転になっていくプロジェクトにおいて、各フェイズで立てた仮説が絵に描いた餅にならないように常にコーディネイトし続けるミッションを負うことになるわけである。つまりＹ氏は、「検証ユニット」の描く成功パターンどおり、めでたくＣ社と長期に及ぶ顧問契約を締結することができたばかりか、ＰＯＳシステムの有効活用を図りたい他社からも声のかかるコンサルタントとなったわけである。
　本事例は、公的な中小企業支援施策に関する若干の予備知識があれば、それを「検証ユニット」にうまく乗せるだけで、実績や信用に乏しいＩＴＣであっても、よりスケールの大きいプロジェクトに参画できるという好例を示すものであろう。

ＩＴコーディネータ／永田祥造

ラベル: 事例, 検証ユニット

■はじめに　

RFPは提案依頼書であり、RFIは情報提供依頼書である。システム開発にあたり、自らのニーズや現状をとりまとめ、書類の形で複数のITベンダーやシステム･インテグレーターに渡す資料を言う。口頭でニーズを伝えるのとは異なるため、依頼の目的や求めている物事がハッキリし、曖昧さや人情（普段の営業付き合い）要素が排除されるため、適切で公平な競争提案を貰いやすくなる。

小職は、仕事柄、RFPを発行する立場とRFPを受け取って提案する立場の両方を経験することがある。そのときの経験からすると、提案する立場から見て良いRFP/RFIを書く人は、会って話をしても優秀であるし、提案しにくいRFP/RFIを書く人は、会って話をしてもなかなかピントが定まらない場合が多いように思う。

本論では、そのときの経験などを踏まえ、RFP/RFIを作成する際に陥りやすいモラル上の問題を指摘し、より良いRFP/RFIを作成する為の参考とするためのヒントを提示する。

■RFP/RFIが流行り始めた

ここ最近、RFPという言葉がシステム開発ベンダーの中でもかなり知名度を上げてきている。ほんの少し前であれば数億円以上の大規模なシステム開発でなければRFP/RFIといった言葉は聞かれなかったし、プログラマでもその言葉を知っている人は少なかった。こういう変化の中の一部には、システム提案を依頼するときにはRFP/RFIを書いて依頼しようという、ITコーディネーターの地道な呼びかけや活動もあるのだろう。

ただ、依頼をかけるユーザー企業や団体が純粋に自前でRFP/RFIを作成する場合はまだまだ少ないように思われる。多くの場合、RFPやRFIを書くためには相応の専門能力が必要であるため、ITコーディネータがRFP/RFI作成に携わったり、普段から出入りのあるITベンダーが作成する場合が多いように思われる。（小職もその一人である）

また、RFP/RFIを受ける側のシステムベンダーも、仮にその内容が自社でできない内容であっても、名乗りだけは上げておくという態度をとることも多い。営利活動からすれば、そういう態度をとるのは自然な話である。そして、肝心のRFPはシステムベンダーの関係会社や子会社、協力会社等の手に渡ってゆく。

一般的にRFP/RFI発行の手続きを行う場合は、依頼元と依頼先と秘密保持契約を締結してから、RFP/RFIを提示するものだが、同等の秘密保持契約を継承する限りにおいて、依頼先がさらに他に依頼することを認めているケースが多い。

実際、システムベンダーやシステムインテグレーターは、ハードウェアメーカーや、通信業者、関連ツールベンダー等に相談しながら進めなければ、納期、金額、性能保証体制などRFPに書かれている事項は満たすことができないので、これは特異なケースではない。

■RFP/RFIを受けたシステムベンダーの立場から

さて、RFP/RFIにも出来、不出来がある。もちろんユーザー企業内での現状分析の具合やRFP/RFI作成までの時間等の問題で満足に要件を固めることができない場合も多いため、内容の正確さや濃さについての出来、不出来はあっても仕方が無いと思うのだが、それ以前の問題もある。それは、RFP/RFIを貰って提案ベンダーの立場になった時に提案書を書いて提出する側の不満や苛立ちとして現れてくる。多くの場合、RFP/RFIの提出期限は２週間程度であるが、２週間で作成できる限度を超えた情報提供を依頼してくるRFP/RFIに出会うことがある。

■開発ベンダーの手法に深入りしたRFP

たとえば、「開発ソフトウェアの品質管理をどのように行って、提供製品の質を維持するのか？」という課題に関して、プロジェクト管理手法やテスト手法、使用しているツール等を事細かに記述させ提出させようとするものがある。ある程度の開示は必要であろうが、提案書を記述する側は、別のことを警戒するのである。

すなわち、このRFP/RFIが他のシステムベンダーの手によって書かれたものであるとすると、秘密保持契約があるとはいえ、事実上、こちらの手の内を他のシステムベンダーに読まれてしまっていることになってしまう。ユーザーに理解してもらうのはよいとしても、開発効率を上げるための工夫は、基本的には他社に知られたく無いことでもある。

あるいは、パッケージソフトのデータベース設計図、スキーマ構造図、エンティティ設計書を出してください、などといったRFPも存在する。ERPソフトにおいて、データベース設計は一種の知的財産であり、秘密保持契約があるとはいえ、購入するかどうかわからない人々に簡単に開示するわけにはいかない。

■矛盾したRFP

あるいは、ベンチャー企業や新規事業のシステム提案依頼で多いのが、将来計画が非常に曖昧で、どの時点の企業規模で見積もればよいのかわからないといったものである。
これらにはRFP自体に矛盾があるものも多い。

たとえば、一人１個を買うのが普通の、１個ｎ万円の商品があるとして、その伝票発生数や、営業担当の数、年間販売計画数量などが、矛盾している場合である。１営業マンが１０分に１個ずつ訪問販売してゆかなければいけない計画になっていたり、月に１０台程度販売している工作機械が、システムを導入した直後から毎月８０台ぐらい売れる計画になっているが、生産設備は現状のままで月産５０台が限度であったりという具合である。

■経営計画を考えさせようとするRFP

一見IT提案のようで、よく読むと新規事業やビジネスモデルの検討依頼のようなものもある。

通常、RFPでは、ユーザーニーズとベンダー各社が持つ技術や製品、ソリューションとのフィット＆ギャップを明確にしてゆくことにより、依頼ベンダーを絞り込んでゆくことが重要になる。

ところが、時折「あなたが持っているIT技術を使って、私たちのビジネスモデルをどう変えることができるのかを示してください」とか「ホームページを開設すれば、月商いくらぐらいになると考えられますか」といった質問が設定されていることがある。そして「そう考えた前提条件を残さず書き出しなさい」といった注意書きが載っていることが多い。

たしかに、RFP/RFIの目的のひとつとして、ユーザーが知らない画期的な手法や製品を市場から情報提供してもらうという事があるのだが、そこに裏付けを求めるべきではないだろう。

また、経営者からRFP執筆者やITコーディネータには「IT化でいくら儲かるんだ？」といった投資効果に直結した質問が降りてきて、対応しないければならない場合もあるが、その質問をRFPに記述するのは、仮に依頼元の正直な気持ちだとしても、馴染まないように思われる。

■前提条件不足のRFP

RFPを書いている現場では、時間不足、情報不足のまま見切り発車してしまうことが多い。十分なITコーディネートを受けていなかったり、社内の情報化戦略が固まっていない場合には、特にそうなりやすい。

問題は、RFPの中に提案するのに十分な情報が盛り込まれていないことである。たとえば、依頼企業・団体のIT経営成熟度に関する情報や、情報システム部門やシステムに詳しい人の能力や権限に関する記述が少ない場合がある。

たとえば、導入後のサポートやシステム運用等について見積もりを得ようとするならば、その組織のIT経営成熟度や担当者のスキル等がわからないと、なかなか提案しづらいものである。つまり、全社のシステム運用体制や会社の情報化がどのように浸透しているのかがわからないため、提案自体が非常にブレたものになる。

他にも、サービスレベル、セキュリティレベル、おおよその予算感覚などが抜け落ちていることが多い。

そして、こうした前提条件が不足しているRFPに対して、質問をすると「貴社が最適だと思う構成で提案してください」といった曖昧な逃げ口上で回答される場合や、「それでは数パターン例示してください」という場合がある。

だが、システム提案する側からすれば、まじめに数パターンを検討し、コスト算出することは難しい場合が多い。それこそ、松・竹・梅の３パターンで金額が数倍違うものを提示することになってしまう。これではRFP/RFIによって要件を整理したことにはならない。
しかし、多くの場合見積金額の根拠はかなり細かく書くことが求められている。

これでは、むしろ提案者側に重たい負担だけがのしかかってくる。

■提案依頼者と提案者の関係

RFPを受け取ったシステムベンダーの行動を考えてみよう。システムベンダーの営業としては当然仕事が欲しいから、自分の事業範囲に少しでも関係しそうな部分があれば、会社に戻りRFPを提案書作成者であるシステムエンジニアに渡すことになる。

しかし、多くの提案書作成者は、他の十分な仕事量を抱えた上で、１週間とか１０日といった限られた提案時間を与えられ、大量の資料を作成してゆかなければならない。特に優秀なシステムアナリストやシステムエンジニアには普段の仕事でも業務が集中しがちである。

ある提案では、RFP/RFIどおりに提案書を作成したら、200ページに及ぶ大作になったことがある。添付資料などをあわせると、ざっと300ページである。ところが、断るときには、電話１本である。営業が訪問しても、プロジェクトが始まって忙しいからとなかなか会えない。

このような体験を重ねてゆくと、次回RFP/RFIが提示されても、まじめに返事しようという気にはならない。

■良いRFP/RFIとは

良いRFP/RFIとは、必要十分な情報が矛盾なくコンパクトに伝えられていることは重要であるが、それが提案書作成者に気持ちよく情報開示してもらうものでなければならない。 特にシステムベンダーの選択肢が少ない地方では、良いRFP/RFIを作成してベンダーとの関係を良好に保つことも重要である。 これを踏まえたうえで、前述した良くないRFP/RFIの例に対して、どのようにすればよいかを以下に示してみたい。

■開発手法に深入りしないRFP/RFI

プロジェクト管理能力に対する不安や、システム品質に対する不安を取り除いて欲しいというスタンスで、記述することが重要である。つまり、どの程度のシステム品質やプロジェクト管理が遂行できれば不安ではないのかを提示することが重要で、そのような経験が過去どの程度あるのか、不安を除去する証明する提出資料は開発費用に含まれるのか、別途費用を払えばどのような上位オプションがあるのかを訊くようにする方が良い。

■矛盾しないRFP/RFI

RFP/RFIに矛盾が見つかると、提案書作成者はそのRFP/RFIの全ての記述が疑わしくなる。したがって、矛盾が発生しないようにチェックをすることが肝要であるが、どうしても整合性が取れない場合は、どの数字を基軸に提案を展開してゆけばいいのかを明示する必要がある。

つまり「現段階では将来の売上計画と今回のビジネスモデルおよび費用計画は必ずしも整合性を持っていません。したがって、別紙に示す費用計画を元にご検討頂き、売上計画などは参考程度にお考えください」等と、提供情報の精度に濃淡を付けるなどの工夫が必要となる。

■経営計画を与えるRFP

経営計画に関わる情報は、遮断し、決まっていないことは決まっていないと明示し、それ以上の要求は書くべきではない。

■前提条件をはっきり記載するRFP/RFI

前提条件は変動があるとしても、はっきり記載することが必要である。例えば、３年後の新規顧客数がどの程度になるかは、誰だって分からない。しかし、RFP/RFIの主目的は、同じ前提になった時にどのベンダーが一番良い提案を返してくれるかを判断するというところにあるわけであるから、３年後の新規顧客数のような数値は固定させてベンダーに提示しないといけない。同様に、セキュリティレベルは、「Pマークを取得できる程度の企業環境だと仮定し、それに相応しいセキュリティを提供すること」といった表現が考えられる。

システムの二重化や信頼性に関しても、システムコストが大きく変わる要素である。ハードウェア価格だけではなく、二重化のための特別ハードウェアや、それらを正しく起動／終了させる運用手法等も変わってくるため、RFP/RFIには必ず記載するようにする。どうしても明確な記述が出来ない場合は、「現在のシステムと同等か、やや高いレベル程度とする」といった記述等を検討する。

また、システム部門が保有するスキルに関してはできるだけ記載したほうが良い。技術者（社員、協力会社）のおおよその年代とスキル等をたとえばITSSの技術レベルで表現し、日常の業務内容や保有技術（開発言語、システム設計力など）を表にまとめ、人事異動が頻繁かどうか等を示すだけでも、運用の提案には大きく役立つ。一般従業員のパソコンスキルに関しても、社員教育を見積もりに含むのであれば、触れておいたほうが良い。

また、はっきり記載できない部分がある場合、要求する情報や提案は精度を落として提示してもらうような配慮が必要である。

■まとめ

良いRFP/RFIなのかどうかを判断する為の、絶対的な指標や客観的な測定値を設けることは難しいしコスト的にも馴染まないと思われる。もとより、世間にRFP/RFIを書き慣れたエンジニアやアナリストはまだまだ少ない。

もし、RFP/RFIを書きなれた人が近くに居ないのであれば、まずちいさなRFIを書く機会を沢山与え、RFI/RFPを書くための文書部品を書き溜める機会を作っておくと良い。最初に社内のシステム構成図や、システム部門のスキルマップなどを書いてしまえば、数年経ってもそれなりに使えるものである。

また、提案を依頼し、どこか１社に決めた後、選に漏れたベンダーを呼び、落選理由を説明すると共に、「また次回別件でRFP/RFIを提示する機会があると思うので、今回お渡ししたRFP/RFIの中で書きにくかったところがあればお教えいただきたいと思います。またもし、参考になるような他社のRFP/RFIがあれば、章立てだけでも見せていただけないでしょうか？」という依頼をしてみてはどうでしょうか？

こうしたタイミングはRFP/RFIを書く技術を磨く良いチャンスである。良いRFP/RFIには良いベンダーが付き、提案書作成者も真剣に取り組むものであるから、長期的な視点から考えても、非常に有用なミーティングになるはずである。

多くのRFP/RFIに接する機会を持っているITコーディネータは、良いRFP/RFI、悪いRFP/RFIを世に問うてゆくのも責任の一部ではないかと感じている。

ITコーディネータ／太田垣博嗣

ラベル: ITマネジメント