NO.03　東京商工会議所

1. 商工会議所とは、簡単に言うと、「商業者や工業者などが皆でまとまることにより、それぞれの企業単体
　 では実現できないことを実現していくことを目的にした団体」です。その源流は鎌倉時代の「座」や江戸
　 時代の「株仲間」にまで遡りますが、今のスタイルの商工会議所が確立したのは、明治11年3月に、かの
　 渋沢栄一を会頭として設立された東京商法会議所です。

2.このような成り立ちからも分かるとおり、100%民間の団体であり、会費などを主な収入源としています。

3. その活動内容は、1）：商工業者の振興と発展のためのサポート・サービス、2）： 会員企業の意見を
　 まとめた上での、国政や都政（県市町村政）などへの提言などになります。

ざっと、こんな所です。

そのような業態の東京商工会議所（以下　東商）にとって、「情報活用」とは、どんな定義になるでしょうか。

東商は、営利団体ではないにせよ、民間団体です。民間団体は、会費等によって成り立つものであり、その会費は、顧客（会員）にサービスを提供することで頂戴するものです。したがって、「東商における情報活用」とは、「会員の顧客満足を高めるための情報の活用」になります。その情報活用の理想像は以下のようにも表現できるでしょう。

1. 各会員企業の、各個人が、これまで、東商のサービス（セミナー、検定、会合など）を、いつ、どこで、
　 どのぐらい利用されたかが把握できること。（顧客利用履歴の把握）

2. いろいろな性質のデータを様々な角度から分析し、各会員の個別ニーズを把握したり、また各会員の
　 東商の活動に対する、意欲、姿勢、関わりの度合いも認識できること。（顧客属性の把握）

3. また、東商主催のセミナーや検定に参加された会員以外の方についても、そのニーズを分析・先読み
　 して、先方ニーズに沿ったご案内を送る。最終的には、東商の会員になっていただくことが理想である。
　 そのためにも、相手のニーズを的確に捉えたサービスをタイムリーにご案内する。（新規顧客の獲得）

4. このようなサービス提供を実現するためには、利用する各会員データは各部門にバラバラに存在する
　 のではなく、一つの統合データベースに収納され、利用時のニーズに応じて、わかりやすくレポート形式
　 などで一覧できるのが望ましい。（顧客理解の深化）

5. そして、顧客利用履歴や属性を把握した上で、各個別の顧客ニーズに応じた案内を行う。例えば、
　 個人情報保護に関心の深そうな会員にはそうしたセミナーの案内を、後継者育成に悩んでいそうな
　 会員には、そうした案内を送る。（ワントゥワン・マーケティング。既存顧客へのアップセル）

これらは、一般企業で使われているCRM^※の手法に例えても良いかもしれません。しかし、今述べたことはあくまでも理想像です。実際には、ある基礎条件が整っておらず、そのため、なかなか理想像には近づけませんでした。

※CRM：CRMとはCustomer Relationship Managementの略で、情報システムを応用して企業が顧客と長期的な関係を築く手法をいいます。

商工会議所では、経営を支援する事業サービス部門、企業の声を集約した政策部門、あるいは23支部など、各部門が業務特性に応じて活動しています。そして、これまでは各部門の業務の最適化をめざしたシステムを構築・運用しているため、顧客名簿DBが各部門に存在しています。つまり会員A社のデータが、色々な部門で各業務目的に沿って登録されていることになります。こうなると全体的な利用履歴は追えません。そして、今回の会員情報DB統合化プロジェクトにおいては、この問題を、アシストに解決してもらおうと考えたのです。

アシストと東京商工会議所の関わりが始まったのはいつ頃からでしょうか。

10年ぐらい前に汎用機ユーティリティEasytrieveをアシストから購入したのが始まりでした。ただしその後、アシストが取り扱いをやめたので、付き合いもいったんは自然消滅しました。

それから10年が経ち、再び付き合いが始まったのはどういう経緯からでしょうか。

2004年の初め頃に、アシスト主催のセキュリティセミナーに参加したのがきっかけですね。そのセミナーでは、アシスト自身がISMSを取得したとのことで、その運用ノウハウが語られていました。そして、そのセミナーが終わった後にアシストの営業Mさんからコンタクトがありました。

そこでどんな話になったのでしょうか。

セキュリティの話も少ししましたが、Mさんが「何か業務上のことでお困りのことはありませんか」と聞いてきたので、「実は、各部門がもっている会員DBを横断的に見られる方法を模索しているんだけど」と持ちかけたところ、ではこんな製品がありますがということで、DataSpider の紹介を受けました。こうして再び、アシストとの付き合いが始まったのです。

東商の課題に合う話をしてくれるのかどうか、それが基準です。それは、電話で2～3分話しただけでも結構、判断がつきます。こちらの抱えている課題を二言三言、示してみる。それに対し、どう返してくるか、どんな大枠を示してくるか、こちらの琴線に触れるようなキーワードを口にするかどうか、それで判断します。例えば、こちらが事務局員全員に使ってもらえるシステムにしたいと言っているのに、相手の営業マンが、クライアント・サーバ型のシステムを提案してくるようなら、それは、こっちの話を理解していないか、あるいはその会社がクライアント・サーバ型のシステムに自信をもっているかのどちらかでしょう。どちらにしても、その営業マンと会うことにお互い実りは少ないことが予測されるので、そういう場合はご遠慮します。

今回のアシストの営業マンMさんの、初対面の印象はいかがでしたか。

純朴そうな若者が来たなあというのが正直な第一印象。ただ話してみると熱意は感じたし、こちらの要望に対する察しも良さそうだという印象がありました。

察しが良さそうというのは、どういう点でそう感じたのでしょうか。

アシストというと、「ソフトウェアの商社」というイメージがあるわけです。しかし、今回の会員情報統合DBの課題においては、我々は商社よりはむしろSI会社を求めていました。そうした雰囲気を察したのでしょうね。アシストの非商社的な側面を強調したりして、これはなかなか感性も良さそうだなと。また、自社の製品のアピールばかりするのではなく、まずこちら側の問題・課題をヒアリングし、ワンステップずつ理解して、ワンステップずつ、話を進める。その姿勢に好感が持てました。

Mさんのそうした姿勢は、皆様の目から見て、どこに起因すると思えるでしょうか。

Mさん自身の感性の高さはもちろんとして、Mさんの上司であるKさんとのリレーションがしっかりしていることも一因でしょう。とにかく、こちらが何かリクエストした時の、その反応にブレが少ない。「こんなことしたいんだけど」という相談には、100％答えが返ってくるし、時には「もっとこうすると、さらによくなります」という120％の答えが来ることもある。これは、アシストの会社としてのあり方が、Mさんの回答の質をバックアップしている側面もあるのでしょう。

さて、今回の会員情報統一化プロジェクトですが、はじめからスムーズにアシストに決定したのではなく、業者選びにおいては、東商なりの基準を以て比較検討なさったことと思います。最初にどのような基準をお持ちだったのでしょうか。

今、振り返ってみると、業者の選定基準や、問題解決方法の選定基準は、以下のようなことであったと思えます。

　1. 各部門の既存システムはそのまま残す。
　2. 開発中も、既存システムの運用・実用に制限が生じないことが望ましい。
　3. 試行錯誤が可能な形で開発を進める。
　4. 独立系の開発会社のような顔を持つ会社が望ましい。
　5. その一方で、「商社」としての側面も持ち合わせていてほしい。
　6. フットワークの軽い会社、つきあいやすい会社が望ましい。
　7. 東商の意思決定の手順、スピードを理解してくれる会社が望ましい。

まずは費用と時間の問題です。システムを一から作れば、費用も時間も莫大にかかり、一方で各部署のシステムにも制限を加えることになります。

しかし、「費用や時間がかかっても本格的な良いシステムができれば、それでいいではないか」という考えもあると思うのですが。

そういう考え方もあるでしょう。しかし、冷静に考えると、お金と費用をかけたからといって、本当に良い物ができるかどうか、実は保証がありません。かえって、大がかりに始めると、方向転換もできなくなり、極端な話、何かが間違っていると心の片隅で感じながらも、そのまま最後まで行ってしまうという、困ったことにもなりかねません。また、東商内部のシステム運用構造を考えると、今回のプロジェクトは、最初に仕様をFIXして突き進むのではなく、途中、各部門のニーズを取り入れることで、試行錯誤が何度も出ることは間違いないと、予測されました。

「東商内部のシステム運用構造」と言いますと？

先ほどシステムが部門別なので、顧客名簿が統一化できていないのが問題だと言いました。しかしそれは「データベース統一」という視点から見ての話。日常の業務運営の視点からすれば、各部門のシステムは、業務効率を最適化したシステムです。それに対して、システム運用する我々が、システムの一元化や再構築が必要だと提言したところで、とうてい受け入れられるものではありません。それを考えても、一からシステムを作ることは、望ましくないと予測されました。

その前提条件が、「試行錯誤が可能な形で開発を進める」になるのでしょうか。

そういうことです。またその前提条件がアシストから提案のあったDataSpiderを選んだ理由でもあるのです。

と言いますと？

DataSpiderを使えば、既存のシステムはそのままに、さらに、各部門でのシステムの利用や運用に制限を加えることなく、データベースだけを集めて（互いに連結して）、統合DBを別の所に作れるという説明でした。運用に制限が入らないのなら、各部門の業務に影響を与えないでしょうし、ニーズに応じた試行錯誤も自由にできます。これが本当なら素晴らしいことです。この期待を、念押しの意味で確認するために、DataSpiderを活用している大手建設会社に見学に行った時に、「DataSpiderは本当にカンタンに使えますか？　既存システムに制限は入りませんか？」と何度も尋ねました。すると「できます。大丈夫です」ときっぱり返事が返ってきました。これはどうも大丈夫そうだという自信を深めました。

先ほどは「商社」では困るといった表現をしました。しかし一方で、商社には商社の良さがあるとも思っています。自社製品を持つ技術会社の場合は、やはり自社の製品を売りたくなることでしょう。極端に言えば、東商側のニーズと多少ズレていたとしても、自社開発した製品の開発費を回収するために、営業マンは自社の製品を売り込もうとするでしょう。気持ちは理解できますが、それはユーザ側としては困りものです。この点においては「商社としてのアシスト」は、そうしたシガラミとは無縁であり、こちらの課題に沿った製品を提供してくれると期待できます。また試行錯誤の過程で、予期せぬ課題が発生した場合も、それを解決する製品を何とかどこからか引っ張ってきてくれることと期待できます。これは「商社」という業態の良い点です。

それが次の項目「フットワークの軽い会社が望ましい」という点につながるのでしょうか。

そういうことです。試行錯誤が前提なのだから、フットワークが軽いことは必須。「これで仕様はFIXします」といった、杓子定規な対応はしないでほしい。それを言われるようだと、おつきあいは勘弁かなというのが本音です。この点では営業のMさんは、非常に、きびきびと、しかも柔軟に対応してくださいました。途中、何度か、的を外した対応もありましたが、その点は、忌憚なく指摘できました。何と言いましょうか、忌憚無く指摘のできる人柄だったのです。指摘をするのは、もちろん期待の表れです。余談ではありますが、プロジェクトの途中に、Mさんがご結婚なさるということを知ったので、当方の気持ちの表現として、個人的にお祝いをさせてもらいました。

最後の項目、「東商の意思決定の手順、スピードを理解してくれる会社が望ましい」については。

先に述べたとおり、東商は各部門が、業務特性を持って活動しているという構造もあり、全体の意思のとりまとめにおいて、それなりの手順を踏むことが必要です。だから、発注の決定までにどうしても時間がかかります。しかし、それは決して、その気がないという意味ではなく、ここは誤解されたくないところ。営業マンMさんには、その当りの機微をご理解いただき、根気強い対応をしてもらいました。

すると、どのような対応が？

担当SEのKさんからは、「分かりました。10日ぐらいで持ってきます」との返事がありました。実際には、8日で持ってきてくださり、無事、プロトタイプを見せることができました。私は内心では、この相談に対し、本当にちゃんとしたサンプルを持ってくるようであれば、アシストを、単なる商社ではない、開発会社の実力も持った会社であると認めようと、そう思っていました。率直に言うと、アシストを、試したのです。そして見事、期待に応えてくれました。

そして、今、アシストと共に会員情報DBの構築が進んでいます。現在、プロジェクトはどのような進捗でしょうか。

現在は、パイロットシステムの構築が終了した段階です。今後は、非会員のDBの統合にかかります。前段で述べたとおり、既存部門のシステム利用に制限を加えずに、慎重にシステム構築をしていかなければなりません。今後も試行錯誤をしながら、必ずや良いシステムを作り上げなければなりません。これまでのアシストさんの働き振りを見る限りでは、間違いなく良いシステムを作り上げてくれるものと期待しています。

これまでのアシストの仕事ぶりにおいて、評価できる点はどこでしょうか。

まずは、先ほど述べた、開発会社としての側面、商社としての側面、全体の設計図を作ってことを進めるプロデュース会社としての側面、それぞれをバランス良く併せ持ちながら、期待通りの働きを見せてくれています。

一方、アシストの仕事振りにおいて、改善して欲しい点も、お聞かせいただければ幸いです。

改善して欲しい点も、ありますね。何と言えばいいんでしょうか、アシストの技術者の皆さんは、少々、奥ゆかしすぎるかもしれません。

これまでDB統合ツールDataSpiderについてお話いただきました。もう一つ、WebレポートツールWebFOCUS も導入されています。こちらへのご評価はいかがでしょうか。

DataSpiderによって、会員情報の一元化のメドがつきました。しかし、顧客情報が、DBとして存在しているだけでは意味が無くて、その情報内容がユーザである各局員に、わかりやすく伝わるような道具立てを整えないと、「情報活用」になりません。WebFOCUSについては、閲覧のためのレポート制作や見せ方の試行錯誤が、非常に短期間で行えるツールであると言う、アシストからの触れ込みでした。

実際に活用してみてのご感想はいかがでしたか。

我々の立場と言うのは、直接、WebFOCUSを活用してレポート画面を開発するというものではなく、極論すれば、画面に対する要望をSEに述べて、あとはSEが画面に向かってキーボードを叩いて開発しているのを、後ろからじっと見ているイメージになるわけですが、その上での感想ということで申しますと、いや、ずいぶんカンタンに変更が利くものだなと驚いています。従来の我々のイメージだと、帳票の変更というのは、もっと手間取るものなのですが。

「従来の帳票の変更イメージ」とはどんなものでしょうか。

帳票の見易さというのは、利用者である我々にとっては、非常に重要な話ですし、また見易さというのは感覚的なものなので大いに試行錯誤してみたい部分ではあります。そこで開発会社に、ああして欲しい、こういうことを試みて欲しいと持ちかけるのですが、たいていは「いや～、表面を変えるだけだからカンタンだとお思いかもしれませんが、実際には結構手間取るものなのですよ」との説明が返ってきます。よしんば対応してもらえても、「では、次回の定例ミーティングでサンプルをお見せします」といった重い話になります。ところがWebFOCUSの場合は、「じゃあ、ちょっと作ってみましょうか」という返事で、カチャカチャっと10分でサンプルができてしまう。えっ、もうできたの!?という、何ともびっくりするようなスピーディさです。これなら、今後のプロジェクトでの試行錯誤も自由にできるでしょう。良い道具を用意してくれました。

アシストには、その両面に対応した提案を期待するということでしょうか。

そのとおりです。まず最初の段階では、こちらの課題を良く理解していただいた上で、一発目から、「琴線に触れる提案」をしてほしい。そして次のフェーズにおいても、ツールだけの提案ではなく、運用やコンセプトもセットにした提案をしてほしいと思っています。アシストは自社でもISMSを取得しているようですし、ソフトウェア商社として活動する中で、さまざまなナレッジや運用事例もお持ちですから、それらを生かした総合的提案に期待しています。アシストには、商社と開発会社の二つの業態の「いいとこどり」をした上で、東京商工会議所の「情報活用」の発展と、そのための試行錯誤をご支援願いたいと思います。アシストならできる。期待しています。

※現在、ご利用いただいている製品、サービス
　　・リレーショナルDB（設計～実装支援含む）：Oracle
　　・データ連携ツール（設計～実装支援）：DataSpider
　　・レポーティングツール（設計～実装支援含む）：WebFOCUS
　　・各種保守サポート

※ 東京商工会議所のWebサイト
※ 取材日時 2005年11月【取材協力：（株）カスタマワイズ】