(#007) 2003.11.04
復刻シリーズ第４７弾！
━━━━━━━━━━━━━━━━━━━━━ 2003.11.04 Vol.067 ━━━━━ ☆☆★★★ ☆☆★☆☆ 日刊「SOHOのツボ！」 ★★★☆☆ http://www.soho-union.com/soho/ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 配信部数 805部 「ソフトエンジニアの雇われない生き方」(#007) 福井修@Fsys 【○】本日のお題 顧客 (ベンダとユーザの距離) ━━━━━━━━━━━━ こんにちは福井です。もう１１月になってしまいました。 10月31日,11月1日と関西オープンソース＋フリーソフト2003が開催されました。 http://k-of.jp/ 私は、Rubyコミュニティで自主企画「 オブジェクト指向 Ruby の実践例 紹介」 http://k-of.jp/1101.htmlで参画しました。結構立ち見の盛況でしたので、うれ しかったです。また来年もやります（たぶん^^）ので、見逃した方は、来年どう ぞ。 前回 注1) 『 家庭は志の本拠地。増えよ市民起業家クリエータ仲間！ 』 と書きました。 本日は、顧客 というテーマでベンダとユーザとの距離についてです。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■ ベンダとユーザ ──────────────────────────────────── 何かを提供する人がベンダで、それを利用してお金を払う人がユーザです。 お米を作るのは、農家で、そのお米を食べる人がユーザです。 医療サービスを提供するのが医者で、患者はユーザです。 知識や知恵を提供するのが先生で、生徒はユーザです。 システムを作るのは、エンジニアで、そのシステムを使う人がユーザです。 単純な構図なのですが、お金の受け渡しが絡んだり、いろいろな状況で、途中 にいろいろな機構が介在することになります。 ユーザとベンダと言う関係と発注者と受注者言う関係とは、必ずしもイコールで はありません。顧客は、誰かというのは、重要なポイントです。 ユーザとベンダの間には、介在者が存在することがあります。ニーズがあって、 それに応えるためにいろいろなビジネスが存在する訳で、途中のサービスであっ ても価値を生み出していれば存在価値はあります。 イチローや松井の存在は、野球を介して国境を越えて、人に感動を与え、そして 大きくお金も動くわけです。彼らのプレーを、見る人に提供するには、様々なビ ジネスが存在します。 歌がとても上手であれば、人は、お金を払ってもその歌を聴こうとします。 CDが売れると、演奏者や、作曲家や作詞家にもお金がはいりますし、レコード会 社が、潤います。 レコード会社がベンダで、部品・材料として、曲や演奏を調達して売り出すと いうモデルが存在しますが、インディーズというモデルも存在します。 ユーザとベンダの関係には、様々なビジネスモデルがあり得るわけです。 直接モデルもありますし、いろいろなエージェントが仲介するモデルもあります。 既存のビジネスモデルのなかで、どう位置づけるかという視点もありますし、今 後、どんな新しいビジネスモデルを構築するかというテーマにも、興味深いもの があります。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■ ２階から目薬 ──────────────────────────────────── ユーザとベンダには、いろいろな『 距離 』があります。 現場 ─(1)→ 現場管理者 ─(2)→ スタッフ部門 ─(3)→ スタッフ部門責任者 ─(4)→ 発注部門 ─(5)→ 一次会社営業 ─(6)→ 一次会社技術 ─(7)→ 一次会社発注部門 ─(8)→ 二次会社営業 ─(9)→ 二次会社技術 ─(10)→ 二次会社発注部門 ─(11)→ 三次会社営業─(12)→ 三次会社技術─(13)→ : 開発管理者 ─→ 開発者 規模が大きくなると、関係者もどんどん増えてゆきます。 総額１千億のプラント建設とかだと、相当なものです。私のエンジニアとして最 初の仕事は、八幡の製鉄プラントでそんな規模のシステムでした。 現場のニーズが開発者に伝わるには、なかなかの距離がありました。 「２階から目薬」 どころの距離ではありません。 今 小規模の会社のシステム構築だと 現場の社長 ─→ 開発者(私) 「こんなんが欲しい」 ─→ 「こんな画面が出来ました、こう操作します。どう でっか」 たぶんこれが、ユーザとベンダの最短『 距離 』のシステム構築でしょう。 現場のニーズをしっかりとらえ、かつまわりも見渡せて、お金も決済できるキー マンが、システム全体を把握し、かつプログラムの実装もできるエンジニアに、 直接発注する。 というパターンが成立すると、無駄がありません。やる方も、気持ちいいもので す。 まあ一般には、 ユーザの中で、ニーズのある現場とお金を握る部署が別で、ま たいろいろ横から口だしするところが別にあったり、またベンダの中で、営業と 技術がコミュニケーションとれていなかったり、設計する人と実装する人とで齟 齬があったりいろいろありがちです。 インターネットで、産地直送で農産物のおいしいものが安く手に入るようになり ました。私も玄米を買いましたが、マーケットで買うより相当安いです。 途中のオーバヘッドが無いのが、有利です。 インターネットでの仕事のマッチング（発注したい人と受注したい人との出会い） もどんどん進んでいます。 エンドユーザと実ベンダの距離は、もちろん規模によるわけで、超高層ビルは、 大手建設業者が建てる（実際には、沢山の下請けが）しかないでしょうが、中層 のビルは、中堅業者が、そして、きめ細かい注文建築には工務店（大工さん）が 向いているでしょう。システム構築も同様ですね。 実際の例えば、中企業のオフコンリプレースやPCサーバ構築の何百万〜何千万の 案件は、「２階から目薬」でなくユーザが実務をこなすSOHO(や「市民起業家」 注2))と直接取引するのが、有利でしょう。 SOHO(や「市民起業家」)直接では心配というユーザには、事業協同組合経由とい う方式でリスク回避するというのもありです。 途中経路は、出来るだけ少ない方が無駄なオーバヘッド（＝コスト）が避けられ るので、 エンドユーザ←→実ベンダは近い方が有利です。 本日のツボ 『 エンドユーザ←→実ベンダは、近い方が双方に有利 』 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ※ 注釈、資料、参考情報 ──────────────────────────────────── 注1) http://www.melma.com/mag/75/m00094675/a00000057.html 注2) 「市民起業家」という言い方は、少し大げさですが、前回せっかく紹介しま したので、使っておきます。趣旨としては、下記「バザール」の感じでしょ うか。何億掛けて緻密なシステムを作るのと、見かけの費用を掛けずにうま くお手軽(かつ効率よく)にシステムを作るのでは取り組みが違う訳ですし。 伽藍とバザール Eric S. Raymond 著 山形浩生 YAMAGATA Hiroo 訳 http://cruel.org/freeware/cathedral.html 【プロフィール】 福井 修 ( FUKUI Osamu )o-fukui@po.iijnet.or.jp 福井システムリサーチ http://fsys.net/ 主幹。システム構築歴２７年。 システム構築エキスパート 日本Linux協会、神戸商工会議所、情報処理学会 会員 関西ソーホ・デジタルコンテンツ事業協同組合員 デジタルハリウッド三宮校 Java講師
