この事例は、ITC Conference 2004にて活動事例報告として発表した内容に加筆し、文章にまとめなおしたものであり、いわゆる経営改革やIT化事例とは少々異なることをご了解いただきたい。
１ 要旨
ITコーディネータがその行動規範としているITCプロセスガイドラインは、いくつかの理由からそのままでは従業員数数名等の小規模事業者には適用しにくい。そこで、短期間で成果を出してゆく「検証ユニット型」という実施方法を考案し、コーディネート現場に活用したところ良い成果が出た。
本事例では、ITコーディネータ（筆者）は小規模事業者と地場システムベンダー、地場コミュニティの関係や特性を活かし、地場システムベンダーの後ろ盾として行動した。
小規模事業者すなわちスモールカンパニーをITによって活性化するには、（１）IT化推進の共通言語としてITCプロセスガイドラインのフレームワークを柔軟に活用し、（２）地場企業の人的結びつきに着目し、（３）地域振興につながるIT化を意識すべきである。そして、地場のコミュニティがITコーディネータ等と共に信頼できる地場システムベンダーを見極めて、地方の成功例をその地方で育て、「ローカルスタンダード」を育成することが重要である。
『地域コミュニティのニーズに対応できる体制づくりをすすめることにより、日本の80%以上を占めるスモールカンパニー支援のスタンダードになり得るのではないか』という感触を本事例の実践を通して得ることができた。
２ 地場システムベンダーとの出会い
本事例は、ITコーディネートを必要としている企業からの依頼ではなく、小さなシステムベンダー（この会社自体も小規模事業者）からの依頼から始まった。
このシステムベンダーの社長は、地場のユーザー企業にASP等のシステムサービスを提供する事業を行っており、ITコーディネート制度についても明るく、かなり勉強していたが、顧客事業とのコミュニケーションやプロジェクト推進等いくつかの悩みを抱えていた。ITCのプロセスガイドラインをシステムベンダーの立場やITコーディネータの立場で実践しようとしても、なかなか小規模事業者の実態と合わないという。
このシステムベンダーの顧客企業の多くは、従業員数、数名から数十名の会社、いわゆる「小規模事業者」であり、こうした顧客企業ではシステム部等はもちろん存在せず、「社内改革プロジェクト」なるものも構成できる状態ではない。
プロジェクトを開始するにあたり、システムベンダー社長と筆者は議論を重ね、最終的にひとつの考えで合意するに至った。すなわち、ITコーディネータの使命のひとつは、「中小企業の正しいIT化促進」ではないか。ならば、中小企業の80%を占める小規模事業者に適用できるITCプロセスを考えることが重要なのではないか、ということである。そして、「小規模事業者対応」という視点から、現実とITCプロセスガイドラインとのギャップを分析し、それを克服するための仮説を立て、ユーザー企業で実践してみようということになった。
３ 神戸商事
今回事例として取り上げた神戸商事は、神戸に本社を持ち、大阪・東京に支店を持つ服飾アクセサリー（ハトメ・ホック・バックル等）の卸業を営む、従業員数約20名の典型的な小規模事業者である。
第二次世界大戦後に起業し、高度経済成長期を通じ、業容が拡大したこともあったが、近年では長期に渡る業界の構造不況、中国・東南アジア製品の台頭、そして1995年の阪神淡路大震災によって、長田区にある会社自体は幸い大災害を逃れたものの、数ヶ月に及ぶ実質的な業務停止状態となり、経営上大きな打撃を被っていた。
このような中、当然IT化投資には多額の資金を割くことも出来ず下手をすれば悪循環に陥るところまできていた。
この会社は従来、神戸、大阪、東京でバラバラに、伝票発行機やスタンドアロン型の販売管理パッケージなどを導入使用していたが、事あるごとにバージョンアップやハードウェアの買換え等が必要と言われ、データのバックアップ等にも不安を抱えていた。特に2000年問題の時には、震災復興もままならない時期にシステム維持のためだけに多大な出費を必要とし、大変苦しかった。そして何よりも操作が難しかったため、操作が得意な若い従業員だけしか操作できず、その従業員が風邪等で休んでしまうと大変であった。
あるとき、神戸商事の副社長が知り合いの社長から、「便利なソフトを作ってくれる会社が地元にある」という紹介を受けた。それが、前述した地場のシステムベンダーであった。
４ 小規模事業者から見たITの認識とITコーディネートに対する不満
さて、筆者はこのような背景の中で神戸商事のIT改革に間接的に取り組むことが決まり、前述したように「神戸商事だけの特殊な業務改革モデルではなく、もっと小規模事業者全般に効果のあるモデル設定を考えよう」という話になった。
そこで、地場システムベンダー社長と筆者の間で何度か打合せを行い、おおよそ以下のような共通認識を得るに至った。
まず小規模事業者は、中小企業の中でも更に限られた人的資源の中で厳しい経営を強いられている。これらの企業は、
（１）地域コミュニティとの強い結びつき（ベンダーは紹介で決まりやすい）
（２）時間や予算の厳しい制約（数ヶ月で効果が求められる）
（３）意思決定権者による素早い決定（社長家族や永年勤続社員等の意向も強い）
等の特色を持つ。そのため、こうした文脈を無視した提案やIT化は致命的であり、逆にこうした特性を生かした情報化推進が成功の鍵を握っている。
ここでITコーディネータが行動規範としているITCプロセスガイドライン（この時点ではベータ版）を振り返ってみる。このプロセスガイドラインはいわば「器」であるため、当然上記のような小規模事業者の特性を意図した文脈は含まれていない。ITコーディネータ各人の力量によって、小規模事業者と打合せをする中で把握して行かなければならない。
従って、真正直にITCプロセスガイドラインを適用しようとすると様々な障害が発生し、なかなかうまく行かないケースが多い。例えば、彼ら小規模事業者のITコーディネートに対する不満は以下のようなところにある。
（１）ITコーディネート作業にかかるコストの相場観がわからず不安である。
（２）コンサルタントやITコーディネータの言葉は専門用語が多くて難しく、馬鹿にされているように感じることがある。
（３）システムの総額が100万円を超えると、「資金繰りの苦しさ知っているのか」、と言いたくなる。会社の規模も見ず、500万円、1000万円のシステムを検討し始める人がいる。
（４）打合せ相手が多すぎ（ハード屋、ソフト屋、ネット屋、ホームページ屋‥‥他）、それぞれに自分のような素人が説明するために、わけがわからなくなる。
（５）高尚な理論や理屈よりも、目に見える成果を数ヶ月ですぐに出して欲しい。
（６）システム会社やコンサルタントは、契約を交わすまでの、はじめの頃は調子が良く、顔を見せてくれるが、一旦契約が決まり、システムが納品されてしまうと何度も足を運んでくれる会社は少ない。
５ ITコーディネータから見た小規模事業者のITコーディネートに対する課題
一方、ITコーディネータの立場で考えた場合にも、プロセスガイドラインをそのまま適用しにくい要因がいくつかある。
（１）眼前の課題解決を強く求められているにもかかわらず、プロセスが長い。順調に進んでもシステムのサービスインまで１年かかる。
（２）各種企画書、DFD等の専門的な成果物は、ITコーディネータの作業の労苦ほどには、小規模事業者には期待されておらず、読まれないし、理解もされない。すなわち、これでは報酬を取れない。
（３）小規模事業者の現実のシステム導入では、システムベンダー１社丸抱えというケースは稀で、むしろ複数のIT業者（通信業者、システム会社、ハードベンダー等）のコラボレーションが必要なケースが多いが、その部分のガイドラインがなく、各々にすべて深く精通しているわけでは無いITコーディネータひとりではプロジェクトをコントロールしにくい。
（４）コーディネート作業に対する報酬に関するガイドラインがなく、肝心の契約時に、他と比較する術を持たない経営者が不信感を抱きやすい。
すなわち、ITCプロセスガイドラインは、あくまでガイドラインであり、弾力的な運用が望まれる。ITコーディネータの技量に頼る部分も多分にあるだろうが、会社や団体組織の規模、業種により、実例を通した継続的なバリエーションやパターンの研究促進が今後更に望まれる。特に小規模事業者に対しては、その特性を理解して運用する必要がある。
６ 小規模事業者のITコーディネートを支援する場合の留意点
地場システムベンダー社長からは、小規模事業者を顧客にする場合に特有の過去の様々な苦い経験をヒアリングし、そこからいくつかの留意点を抽出した。これが神戸商事のITコーディネートを行う場合の生きた経験則として活用されることになった。
小規模事業者のITコーディネートを支援する場合の留意点を以下に示す。
（１）金銭面
１ 机上理論を最小限にとどめ、常に実績や成果を感じられるように
２ 投資効果を数ヶ月以内に確認できるように
３ 資金繰り、初期投資軽減には十分に配慮する
（２）組織面
１ 社長には細かい分析資料より、社員に語れる強力なキャッチコピーを
２ 事業計画や方針は頭の中。近傍の有力者の意見で趣意替えする可能性もある
３ 社長も手を焼く旧守派の存在には気を使おう
（３）現場対応
１ 伝票管理など、あたりまえの作業徹底に問題解決のヒントあり
２ ノウハウを押し付けるのでは無く、共に体験し、改善する喜びを分かち合う
３ 現場の反発（例外探し、不服従）を軽視せず早めに対処
小規模事業者は社員数が少ないぶん、それぞれの社員の発言力も強く、実に大変である。しかし小規模だからこそ、まだ改善の余地があり、一致団結してIT化を推進したときには激変する可能性を秘めている。だからこそ、ITコーディネータには、経営者といっしょになって汗をかく覚悟が必要である。
７ 地場システムベンダーの裏方としてのITコーディネータ
ここまでの話でお分かりのように、今回の事例では、筆者（＝ITコーディネータ）は、神戸商事と直接打合せをすることは少ない。地場システムベンダーと直接打合せをすることが多かった。先に、「ITコーディネータには、経営者といっしょになって汗をかく覚悟が必要である」と書いたが、これと矛盾するとも言えよう。
神戸商事のスタンスは極めて明白であった。曰く「ITは良くわからないから、とにかく一番いい方法でやって欲しい」。悪く言えば丸投げであるのだが、ITに関して詳しく勉強いただく時間が無いことも確かであり、致し方ないとも言える。それよりも、地場コミュニティの紹介によって繋がった地場システムベンダーとの信頼関係の強固さに感心した。
そしてなにより、地場システムベンダーは「神戸商事の事実上のシステム部門」としての気概で事業経営していることが何度かの打合せを通じ確認できた。そこで今回は、「ITと経営の橋渡し」というよりは、「事実上のシステム部門としてのシステムベンダー」と、経営との橋渡しの形を取った。
今回の事例では、経営者といっしょになって汗をかいたのは、ITコーディネータ制度の知識があった地場システムベンダーであり、筆者自身は主としてシステムベンダーの裏方や知恵袋として動き、時折神戸商事を訪問して全体の流れがIT中心にならないようにバランスを取った。
８ 望ましいスモールカンパニー向けプロセス
先に示した小規模事業者（すなわちスモールカンパニー）の特性にフィットしたITCプロセスはどのようなものであるべきだろうか。細かい検討事項は数多く考えられるが、以下に示す３つのポイントが欠くべからざる最重要ポイントであると考えられる。
（１）小回りが利くものであるべき
小回りが利き、思いついたら（リスクを理解して）すぐに行動に移す。それがスモールカンパニーの良いところ。ITCプロセスがその良さを殺してはいけない。
（２）小さな投資と小さな成功から始めるべき
机上の空論にはお金を払わない。開発ベンダーにもリスクがある。小さな成功をコツコツ積み重ねる方法が向いている。
（３）ハードルが高い「戦略明確化」の扱いを考慮すべき
経営者と共に経営戦略立案、戦略情報化企画を立案するには相応の時間がかかる。中堅企業以上の手間と時間がかかる場合も多い。しかし、ここで時間を掛けて足踏みをしていると、経営者はイライラし、ITコーディネータへの信頼を落してしまう危険性がある。
従って、はじめは軽く、速く、安く、簡単なところから手を付けてゆくことが望ましい。そして、数ヶ月でコストに見合う成果がすぐに見えることが肝心である。
この方法から推論すると、時にはかなり粗治療が必要になる場合もある。例えるなら、事故現場で麻酔もかけずに開腹手術を行うような荒っぽい手法が必要となる場合もあるということである。たとえば、経営戦略もはっきりしていないときに、システムを入れてしまうケースもありうる。むしろ、システムを入れて初めて経営者がそれまでの経営戦略の甘さに気づくことも多い。たとえば在庫管理や入出金伝票など、足元の情報管理をしっかりやる必要性に気がつくのである。教科書的なITCプロセスからは逸脱することもあるが、これで救われる命はけっこう多い。
９ 検証ユニット型ITCプロセス
上記の問題点を克服しながらなおかつ小規模事業者にフィットしたITCプロセスとして、「検証ユニット型のITＣプロセス」を提言する。（本項は、ITCのプロセスガイドラインの内容を知っている方向けの記述となっている。）
この「検証ユニット型のITCプロセス」は、ITCプロセス４フェーズを簡略化して数ヶ月で１回転させる「検証ユニット」という単位を設け、大きな作業プロセスの流れのなかで、これを数回転させるというものである。
通常のITCプロセスガイドラインは、左図のようなフレームワークで構成されており、このフレームが最低でも半年程度、長くて数年のスパンで推進されることとなる。
しかしながら、これでは小規模事業者は疲れ果ててしまう。そこでこれを改良し、以下に示すように、大きなITCプロセスのフレームワーク中に「検証ユニット」という区切りを設け、短期間に評価ができるような体制にする。
検証ユニットは、下図に示すように小さなローリングサイクルから構成されている。このサイクルが数週間から数ヶ月という短い期間で回転することが重要である。たとえばそれは運用サービス・デリバリーから始まることもあれば、情報システム開発から始まることもある。
なぜそのようなことが起こるかというと、ITコーディネータがなんらかのプロジェクトに参画する場合、そのプロジェクトは途中まで進んでいることが多いからである。たとえば、場合によってはすぐにウィルス対策ソフトを導入したり、ホームページを閉鎖したりする必要がある。
あるいは、変な方向に進んでいる情報化資源調達を一旦保留にしながら、眼前の課題を解決しなければならない場合もある（例えば内税方式への表示変更等）。
従って、左図では回転する車輪の如く記述しているが、現実には参画当初の最初の回転は、この順序さえ変わってしまう場合もある。たとえば、とにかくありあわせのサービスで運用デリバリーを行って、必要最小限の手当てをした後、すこし余裕を持ってカスタマイズを行い、そこからゆっくりパソコン等の調達を検討し、その作業を通じて、どこに向かって進めばよいかという意識共有を経営者と行ってゆく場合などがある。
また、この検証ユニットは、闇雲にITコーディネータの都合で設定すべきものではない。あくまでも思考の中心に事業者を置くことを心がける必要がある。
左に示したのは、ユニット分けをする際の注意ポイントである。小規模事業者では、事業者自身の意識改革が次なるIT化推進の最も大きな原動力になる。また、事業者自身がユニットを順々に経験し、成功体験を獲得してゆく中で、ある程度モニタリングできるようになってくるので、もしもプロジェクトが途中で立ち止まることがあるとしても、そのリスクを受け入れる素地が出来上がっていること、あるいは受け入れられる程度のものに抑制できるようになることが最重要となる。
実際、小規模事業者にとってIT投資は非常に大きな賭けである。税理士に毎月支払う顧問料でさえ、大きな負担に感じている小規模事業者が多い。「センセイ」と呼ぶ人にお金を払う余裕は本当に少ない。
そんな中でIT化投資は、大きなリスクである。従って、必ずリスクを受け入れることが出来る単位のIT化でなければならないのである。たとえITによって非常に良い解決策が見つかったとしても、それが経営者自身で納得できなければ、一気に推進してはならない。ユニット化し、かならず納得のいく範囲で推進すべきなのである。
１０ 神戸商事のIT化 －環境変化対応型－
神戸商事の場合、IT化にあたっての一番大きなハードルは「後々追加コストが発生するのではないか」あるいは「使い方が難しいものは、システムを操作する事務員が固定化されるため、経費削減にならない」という不安感、不信感であった。もちろん、ADSLもASPといった用語もわからない。
一方で、地場システムベンダーは自らのASPシステムに自信があった。神戸商事の状況を見て、自らのASPシステムが小規模事業者にどのように役立つか、明確なビジョンを持っていた。そのもっとも重要なテーマを「神戸商事のITは、環境変化対応型にすべき」という点に絞った。ここでいう環境変化とはたとえば、消費税率の変更や２０００年問題、新規取引先開拓に伴う伝票形式の追加や変更などである。
これらは、システム導入時にはシステムベンダーにも小規模事業者にも誰にもわからないことであり、コストとして請求されるリスクを抱えたくない部分である。ASPシステムがこうした根本的な不安を解消することに自信があったため、付随して以下のような具体的なメリットが活きてきた。
（１）ベンダーの意向によるシステム更新料の徴収が無くなる
（２）データバックアップやパソコン故障の心配が減る
（３）多少のカスタマイズが利く
（４）各事業所バラバラのシステム導入が一本化され、経営の見通しがよくなる
（５）利用者はリース契約に縛られる事無くいつでもシステムをやめることが出来る。
この考えは、神戸商事のIT成熟度と併せて考えると事実上の情報化企画であると言えた。そしてシステムベンダーとはいえ、紹介で入っているため他社との競合見積に悩まされることは少なく、神戸商事と中長期レンジで付き合うことが可能な環境にあることがわかった。
そこで、筆者はこの地場システムベンダーを事実上の神戸商事「システム部」とみなし、そのアイデアを事実上の戦略情報化企画とみなした。
１１ 検証ユニットの事前設計
ここから、本論の核である検証ユニットに入るわけであるが、「ビジネスとしてのITコーディネータ」を成立させるかどうかは、この最初の検証ユニットの成功如何にかかっている。この部分では、先に述べたように「事故現場で麻酔もかけずに開腹手術を行うような荒っぽい手法」を取らざるを得ない場合があり、しかも救急医療同様に手術の前にお金を請求できるような性質のものではない。形のあるモノを提供するシステムベンダーでさえお金を貰いにくい場面であり、ましてやITコーディネータとしてお金を貰える場面ではない。
この時点でシステムベンダーは、当然ASPを売り込みたいと思っていたし、この段階では神戸商事は信頼できる筋からシステムベンダーを紹介されたとはいえ、《疑心暗鬼》に思っていた。
神戸商事がハッキリ認識していた目前の課題は、データバックアップや操作などのシステム上の不安であった。しかし、ITコーディネータの立場として筆者の見立てでは、目前の経営上の根本課題は「正確な在庫管理」にあると思われ、地場システムベンダーもそれに同意した。そしてそのためには、正確で素早い伝票発行が必要とされた。元来、神戸商事はボタンや、服飾アクセサリーなど商品点数が多く、価格が安いものを扱うため、売上高の割には伝票枚数が多いという性質を持っていた。
従って、神戸商事と地場システムベンダーとが一致できる当面の目標を、正確な伝票発行に定めた。また、ITコーディネータの筆者の立場からは、ASPによる大量の伝票発行がシステムパフォーマンス上のネックになる危険性が高かったので、そのポイントでのチェックをきちんと行うように、両者に対し働きかけるようにした。
そして、正確な伝票発行が可能になった後、本丸である在庫管理へのチャレンジを仕掛けるように考えた。
１２ 最初の検証ユニット
最初の検証ユニットとして、この地場システムベンダーは、まず販売管理ASPをパソコンやプリンタ共々、オールインワンで貸出しを行い、神戸商事の反応を見ることにした。もちろんこの時点では評価導入であり無償である。
ASPだけではなく、パソコンからプリンタまでシステムベンダーが貸し出してくれるため、神戸商事には金銭的なリスクが一切無く、初期における実質投資は、ADSLの回線費用だけであった。
神戸商事で評価導入したところ、すぐにこのシステムとの相性が良いということがわかった。プリントアウト速度の懸念も支障が無かった。よいと判れば直ぐに方針が変わるのが小規模事業者のよいところである。評価導入からほんの２週間ほどで本契約を結ぶまでに至った。
ASP型であるため支払いは月払い。ハードやソフトのバージョンアップに悩まされることも無く、嫌になればいつでも解約できる。そして操作が簡単であるため（ちなみにマニュアルは無い）、多くの従業員が操作できるようになり、特定の従業員に負荷が集中するということも無くなった。
１３ 2回目の検証ユニット
システムの利用価値がわかった神戸商事では、その後数ヶ月のうちに問題意識の高い順番に、販売、請求、経理、在庫等を順次稼動させていった。一種のERP導入である。
経営者の問題意識は、まず「販売管理でインプットしたデータを請求側で使いたい」というところに向いた。これで伝票まわりの問題がスッキリとし、特定の従業員に作業依存する操作性の問題が大きく解消した。つぎに、そのデータを経理方面に繋げて会計上の判断が素早く正確になることに意識が向いた。そして、最後に正確な在庫管理に至った。このような少量多品種を扱う会社においては、在庫管理がある程度ドンブリ勘定になることも「仕方無い」と考えられていたが、在庫管理の導入の頃にはそういった認識も変化していった。
この怒涛の導入作業の間には、神戸商事固有のシステムカスタマイズも発生したが、大きなもので無かったため、このコストもASP料金内で実施できた。
いわゆる世間で言われるASPの場合は、ASPが特定の業務を提供し、その利用方法に利用者側が合わせる形態をとるが、このような地域密着型のASPシステムであれば、多少の融通は利くため、小規模事業者であっても改善提案が通りやすいというメリットもあった。
１４ 3回目の検証ユニット
ASPを導入してまもなく神戸商事の副社長は、自宅で使えるという長所に自ら気付き、副社長の自宅にもADSLを引いた。そして、土日等に出社しなくても仕事ができる便利さを実感し、ついには税理士の先生に見ていただけるように、先生にもIDを渡した。その結果、生の経理情報を直接見ていただき、指導してもらえるようになり、税理士、経営者の双方がメリットを感じるようになっていった。
税理士の先生にIDを渡すというアイデアは、ITコーディネータやシステムベンダーが出したものではなく、神戸商事の副社長自らが思いついたものである。すなわちADSLやASPの意味はわからなくとも、使い方の応用が利くようになり、システム化の視野が広がったのである。
この事例では、ASPをテスト導入するところまでが最初の検証ユニットであった。経営戦略や戦略情報化企画等と考える前に、目の前のコンピュータに対する不安を何とかしたかったのである。そして、導入を経てASPやERPの良さを体感し、次は何を導入するべきかを判断できるようになっていったのである。これが二つ目の検証ユニットである。
最後に、自宅や税理士事務所でも使えるということに気付き、実践する過程が三つ目の検証ユニットである。最初は「なんとか現状から抜け出したい」という意識であったのが、最後には「こういう使い方もできるのではないか？」と自ら考え、攻めのIT利用に変わってきたのである。
以下に、神戸商事のシステム構成図を示す。
以下に神戸商事における検証ユニットの展開状況を示す。
１５ 本システムの運用コストと導入メリットのまとめ
現在の運用コストは、月額９万円で、システムにかかった初期コストは０円。唯一ADSL回線にかかる数千円だけである。パソコン、プリンタはシステム開発会社からのレンタルであり、運用コスト９万円の中には、カスタマイズ費、バージョンアップ費、日常サポート費がすべて含まれている。
経営者自身が体感している導入メリットをまとめると、
（１）導入リスクが低い。即ちテスト導入による検証が容易で、リースと違い随時解約可能
（２）バージョンアップ費等の心配が無いため、（恐らく）トータルコストは下がっている
（３）自宅からでも業務が確認でき、自分でこまめに情報をチェックできるようになった
（４）税理士がいつでもチェックでき、迅速なアドバイスが受けられるようになった
（５）ソフトベンダーは地元コミュニティの信頼できる人からの紹介なので安心できた
（６）一般の販売管理ソフトはネット対応にすると急に高くなるが、ASPでは端末の増減が簡単
（７）パソコン操作が簡単になり、全社員が伝票入力作業などを行えるようになり、社員スキルに依存した経営から脱却できるようになった。
本来は上記メリットをすべて定量的な観点からモニタリングすべきであるが、残念ながら（これも小規模事業者のIT化推進の特徴かもしれないが）、使用前使用後を定量的に測定する余裕や視点はなかなか存在しない。すべては経営者の体感や感覚に依存する。
たとえば、経営者は現時点においても、自社のIT投資が他に比べて安いのか高いのか、セキュリティが高いのか低いのかなどといったことについては良くわからない、と自ら語っている。ただ、ITに関しては、いつでもしっかりとサポートされていて、相談できるという安心感は何ものにも換えがたいものであるとも語っている。
１６ ITコーディネート作業
先にも少し触れたように、この事例では筆者は、神戸商事と深い打合せは行っていない。企業体力を確認し、情報システムへの習熟度を理解し、地場システムベンダーが無理の無い情報化企画を提案しているかどうかが最も重要なモニタリング事項であった。
また、コーディネート作業の処々のフェーズにおいては、筆者が所属する大阪のITコーディネータの勉強会メンバー（MAIDO Forum http://ekimae-it.com/）に相談を行った。例えばセキュリティ面での相談や税理士と経営者の関係など、一個人のITコーディネータではフォローできない広範な専門知識について相談を行った。
小規模事業者の体力を考えた場合、複数のITコーディネータが事業者とコンタクトを取り各自の得意分野に関してそれぞれミーティングすることは百害あって一利なしである。事業者と顔を合わせるITコーディネータは１名だけにとどめ、できればITコーディネータのプロセスガイドラインが理解できる地場のシステムベンダーがそのまま「よろずIT相談係」として対応することが望ましい。
各専門分野のITコーディネータは、彼らのバックヤードに居て、フロントラインのITコーディネータが専門知識を必要としたときにすぐにフォローできる体制（異能のネットワーク）を組んでおくことが望ましい。ITCプロセスガイドラインはその際の共通言語として有効に働く。
１７ ITコーディネータから見た「神戸商事」IT化推進の成功要因
神戸商事のIT化推進の成功要因を分析した場合、以下のようなポイントが考えられる。
（１）経営者の理解プロセスと行動に重点を置いた
ITCプロセスのベースや根本思想は踏襲しながら、「検証ユニット型」のような応用型も有りうる事が実証できた。
（２）多様性を認識し、経営とITの橋渡しの形を考えた
ITコーディネータの役割をベンダーの競争提案を正しく受けることだけに限定せず、利用者とITベンダーの長期的Win-Winの関係性構築を考えた。
（３）地域コミュニティの存在が大きかった
見過ごされがちだが地域コミュニティは意思決定に大きく影響する外部要因である。本例では特に神戸という「大震災」以前からの助け合う土壌が強く影響していた。
１８ 地域コミュニティとのかかわりについて
成功要因のひとつにも挙げた、地域コミュニティとのかかわりについてもう少し深く掘り下げてみたい。大きな人脈を持たない小規模事業者にとって、地域コミュニティからの紹介は大きな保証となる。
ITコーディネータも地域コミュニティと深く関わりあいながら地場のIT化推進の一翼を担う必要があろう。ITコーディネータと小規模事業者の共通の人脈は、プロジェクトのリスク回避において重要であり、単にシステムの相見積もりを取って、システム化をモニタリングしているだけではITコーディネータとは言えない。
ITコーディネータは、人的にも金銭的にも制約が厳しい小規模事業者に対してだけ指導するのではなく、信用を重視する地場コミュニティの中で、その地域に根ざした地場システムベンダー等情報化のリソースをうまくコーディネートをしてゆくことが重要であろう。
更に言えば、地域コミュニティから継続的に信頼される、地場ITコーディネータや地場システムソフト会社、経営者集団によるIT化の仕組みが重要性を増してくることになるであろう。これを、得てして世間で評判の売れ筋ソフトに習うだけの（うわべだけの）「グローバルスタンダード」に対し、小規模事業者の現場を見つめた「ローカルスタンダード」と名づけたい。
実際、東京など大都市圏を除けば、地方では小規模事業者のためにきめ細かなIT戦略を一緒に練ってくれるITコーディネータはおろか、システムベンダーさえ少なく、数が限られているため、相見積もりを取ることさえ難しいケースがある。このような場合、ITCプロセスガイドラインのような比較検討し調達先を決めるスタンスではなく、調達先ありきで最善の策を考える必要も出てくると思われる。
また、先に述べたように、懐の厳しい小規模事業者がITコーディネータにコーディネート費を支払う所には心理的、物理的ハードルがある。従って、ITコーディネータは地場のシステムベンダーの経営をサポートしながら、地場にとって最も良い影響を与えるシステムサービスのあり方を考えてゆく必要があろう。今回の事例で筆者がとったフォーメーションは、地場システムベンダーの後ろに立って支援するという形であるが、場合によってはこの方式がうまくいくことを証明している。
逆の視点で捉えた場合、作業プロセス中、ITコーディネータにとってのビジネス上の山場は、初回のユニット検証プロセスである。地域コミュニティの輪の中に居ない場合は、このタイミングでひたすら無償ボランティアのような気持ちで相手の心の中に入ることが重要である。この時点で妙な守銭奴根性を見せてしまうと、小規模事業者は警戒してしまうであろう。この時点では報酬は取れないものと思うべきであり、小規模事業者の先にある地域コミュニティの輪に入れるかどうかという試練を受けていると考えるべきである。
以下に、本事例におけるフォーメーションを抽象化したモデルを示す。
様々な地域で、良心的な地場システムベンダーとITコーディネータとが手を組み、そのバックグラウンドに多彩なITコーディネータ人脈網が存在すれば、地域密着型の様々なソリューションが生まれてくる源泉になるのではないだろうか。すなわち各地に農産物や特産品、祭りがあるように、その地域に密着したオリジナルのITソリューションが生まれてくるのではないだろうか。
１９ 提言
最後に、本事例を通して得た教訓を、提言の形でいくつか披露し、将来のITコーディネータ制度の充実を願うものとしたい。
（１）地方の成功例をその地方で育て、「ローカルスタンダード」を育成しよう
（２）スモールカンパニーをITによって活性化するには、①IT化推進の共通言語としてITCプロセスガイドラインのフレームワークを柔軟に活用し、②地場企業の人的結びつきに着目し、③地域振興につながるIT化を意識すべきである。
（３）地域コミュニティのニーズに対応できる体制づくりをすすめることにより、日本の80%以上を占めるスモールカンパニー支援のスタンダードになり得る。 |
ログイン
新規登録
メンバー
ログアウト
