はじめに

1000年の歴史と基礎蓄積を持つ都市計画技法がベンチャ企業の構想設計に使えないものか、それが今回のテーマです。 きっかけは研究会で南波氏から企 業情報システムアーキテクチャの都市計画アプローチ(注１についてのお話をお聞きしたことです。 南波氏は1972年ソニー株式会社に入社、その後 コーポレートIS＆ソリューションズ(CISS) 情報技術部長兼ネットワーク技術部長、各社のCIO（最高情報責任者)やコンサルタント、産業技術大学 院大学教授、早稲田大学ＭＢＡ非常勤講師を歴任された企業情報管理のエキスパートです。 南波氏のお話の趣旨は、企業情報システムに関する次のようなものでした。

ビジネスは技術をドライブし、技術はビジネスをイネーブルします。 技術としてのITを駆使した情報システムは、ビジネスのイノベーションを導かなければならなが、企業情報システムが複雑化し ビジネス環境の変化および変化のスピードに適合できていません。 「買うソリューション」や「使うソリューション」の実用化により、選択肢の増化により複雑性が増化していることが この傾向を加速しています。 情報システムがイネーブラになるには、複雑性を解消（軽減）し、対象の構造を支配する基本原理（＝アーキテクチャ）を明確化する必要があります。

ここでいう都市計画技法は、都市計画法では有りませんが、都市計画法第1章総則で規定している都市計画の目的や、基本理念を実現し ようとしているところは同じです。(注2）

ベンチャ計画を立てる時には、こんな考え方もあるのだと思って気軽に読み進めてください。

都市計画アプローチとは

南波氏によると、これまで大企業においてITは業務推進のツールであったが、最近は新規業務の開発や業務改善の阻害要因になることもあ るとのことです。 最近の大企業は、企業の統合や分割、SCMなどのように社外の業務との連携、政治経済情勢に迅速に対応するために、データ資源を活用し、迅速に 変わっていくことが求められています。 ところが多くの大企業では、システムがスパゲティ化して保守コストが増加し、容易に変更できない状況です。 さらには技術・知識の影響が大きく、採用している技術にあわせ特定のベンダーに頼らざるを得なくなっています。 そのためムーアの法則に代表されるような、ハードウエアの処理能力を活かしきれなくなっている企業もあるとのことです。

その原因として、人材やスキルが採用しているシステムとマッチしていないことや、経営陣との繋ぎ役と成るCIOが機能していないため部 門間の 業務の横串を刺せる立場にありながらそれを出来なかったと等があげられています。 過去の莫大なデータやソフトウエアの改変が難しくて、会社の変化に対応することが出来ないか、時によっては 企業が変化すること事態を阻止することになって来ているようです。 そのうえ現場部門の要求にひたすら対応する御用聞きのような仕事でアップアップしてます。 こうなってしまうと情報システム部門のモラルも上がらず、画期的な情報システム構想が出てくるわけがありません。

このような状況を改善するために、サー ビスオリエンテッドアーキテクチャ（SOA）もしくはそれに類するアーキテクチャが提案されました。 システム間のインターフェースで渡されるデータとその処理の手順の記述方法を標準化することにより、アプリケーション間の連絡方法を 容易にするアーキテクチャです。 これが実現すれば、システムの一部の変更を行なっても全体を作り直す必要性が減り、システムの維持コストが減ります。 SOAの規約に従ったアプリケーション開発を進めていけば、情報システム部門の負荷は大いに減少するはずです。 しかしそうは言っても一企業内で普及させるだけでも標準化を図り、関連する全てのプログラムを書き直していかなくてはなりません。 一般に普及し実現するのはまだまだ先の話です。

一方、南波氏が提案された都市計画アプローチは1000年の歴史を持つ大都市の建設の計画手法に習って、大企業の情報システムのアーキ テクチャ（構造）見直そうとするものです。 そのポイントは次の図に示す3つの視点から情報システムを捉えなおすことからが始まります。（注1）

3つの視点とは、図1の立体の3つの軸「構造」、「部分と全体」、「内と外」3つです。土木・建築設計や機械設計で使われる平面図、 正面図｢側面図にたとえることができるというのも、いかにも都市計画アプローチらしいたとえです。（ただ、私にはこれらの軸を使って、 正面図や、側面図を書くには相当な苦労を覚悟しなければならないような気がします。）

ベンチャのための都市計画アプローチ

これまでの都市計画アプローチは、大企業の情報システムを対象にしてきました。 ベンチャ企業の情報システムには、歴史ある大企業のような過去のしがらみはないので、移行にまつわる問題はなく、初めから 思い切った理想的な情報システム企画を行なうことができます。その代わり、多くの場合初期のベンチャ企業にはお金もないし、 情報処理関係のベンチャでない限り、情報を専門にこなせるようなスタッフもいません。 そしてほとんどの場合本業で手一杯です。 都市計画アプローチに3つの視点の考え方も一部変更が必要かもしれません。 特にベンチャ企業は、当初は大企業のように市場全体を支配する力はないわけですから、市場そのものを全体と捉え、 自社はその全体の部分として考えるのが良さそうです。　このような前提で、ベンチャ企業の都市計画アプローチを考えてみたいと思います。

① 構造の視点

構造の視点とは図2に示したようなもので、大企業もベンチャ企業もその考え方には大きな違いはありません。 違いはプロセスモデルの内容です。　大企業の場合は、自社が支配している業界のビジネスプロセスモデルから始まるであろうし、 ベンチャ企業の場合は、現状のビジネスプロセスモデルを打ち壊し、自社が新 たに作り上げたいビジネスプロセスモデルづくりから始まるところが 大きく異なるところです。

都市計画でいえば、既にある現実の大都市について考えるか、これから新たに創る地方都市のことを考えるかの違いはありますが、やラなく てはいけないことは同じです。 即ち、このようなイメージの都市を作りたい、そしてその都市には自然環境も大いに取り込んで残していくのだと言った考え方 をもとに、都市生活や自然環境を考えます。 これに相当するのが企業情報システムのビジネスプロセスモデルや概念データモデルです。 その考え方をもとに、実際の都市を設計するための都市構造や町並みを決めることになります。 情報システムでいえばアプリケーションや論理データモデルを決めるところに当たります。 そしてそれをサポートする部分が道路や水道といった都市のインフラです。 これは情報システムでもインフラと呼ばれるものであり、物理データモデルとして表現されます。（図2参照）

②部分と全体の視点

部分と全体の視点の例として、東京都知事の立場をとれば、知事の直接の責任範囲は東京都です。 全体は考えるテーマによりますが、関東、日本国もしくは世界でしょうが、道路計画を作るときには多くの場合は日本で十分でしょう。 都庁の改造計画を考えるときには新宿区の地図が必要でしょうし、場合によってはもっとこまかい図面が欲しくなります。 このような関係を示したのが図3です。

部分と全体の視点で重要なことは、自分の責任範囲もしくは検討範囲は、常に全体の一部であり、なおかつそれは分解できるという考え方で す（図１の都市計画アプローチの入れ子構造）。 当然大企業では全体の部分は大きいでしょうし、ベンチャ企業では全体の部分は小さいわけです。 しかし、ベンチャ企業といえども、競合を考えるときには大企業と同じ範囲を全体として考慮する必要があります。 全体の部分（図３の緑色部分）に注目すると、それを構成する部分と、それらに関わる全体機能に分れます。 この部分と、全体機能の関わり方も、中央集権型、連邦型、連携型、ネットワーク型等いろいろなかたちが考えられます。

しかも、最近のGoogle Mapを使い慣れた皆さんは、階層構造ではなく、もっと連続的に部分と全体を表現出来、連続的に移動が出来る地図を 欲しがるかもしれません。 例えば、マーケット調査や物流システムを考えるときには、道路から200メータ入ったところまでの1000メータごとの人口調査といったようなくもっと柔 軟な部分表現手段を必要とする人もいるかもしれません(GISアプローチ)。 このような柔軟な考え方はマーケティングシステムを考えるときには重要ですが、今回はスキップすることにします。

こうして、全体の構造を分解していくのが政府・軍隊・大企業等の大組織統治の常道です。 しかし、ベンチャ企業の最初の段階では、まだそれほど多くの社員がいるわけではありませんし、仕事のやり方も柔軟です （悪く言えば行き当たりばったり）。 例えば、工事を行っている技術者が、お客様の要求に応じて追加の仕事の注文を受けることもあります。大企業なら、注文を受けるのは営業の仕事です。 この関係を示したのが図3のピンク色の部分です。 各個人はそれぞれ自分の専門の業務（機能）を持っていますが時には自社の他の業務を行なう可能性があります。 これを実現するには、技術者が一々営業に伝言するのではなく自分で社内処理できる組みが必要です。 それも自社の業務担当のところに戻って報告するのではなく、仕事を行なっている現場で出来た方が生産性がそこなわれません。そのためには基本業務を実行で きる簡易でポータブルな端末 (例えばスマートフォンやタブレット端末)が必要となるかもしれません。 営業担当は随時、技術者等の入れた注文データの入った営業情報を確認して正式注文とすれば良いわけです。 そのためには技術者も営業も持っているポータブルな端末から行なえる、受注や出荷等の業務処理、入出金の処理システムが必要となります。

③　内と外

図5はベンチャ企業の規模を想定して企業の内と外についての考え方を模式的にあらわしたものです。

多くのベンチャ企業は、最初は規模が小さいので、一国で始めことが多いかと思います。 そのようなケースを次に模擬的に考えます。

できたばかりの企業V（ベンチャ企業）はB国に本拠を持っており、企業Y（取引先）は現在の取引先です。 しかし、A国やC国にはまだ、支社も取引先も持っていません。 これまで企業V社の情報システムの範囲は、企業内の勘定系で図にあるに緑色の範囲内でした。 企業Vの情報システムを企業Yの業務と接続できれば、生産性が上がることはわかっていても、とてもそのような高度な情報システムを 自社で開発する技術も無く費用も捻出できませんでした。 更には将来A国の企業X、及びC国の企業Yとも取引をしたいと考えても、国内の企業とのシステム連携することすら難しいのですから、 とても海外の企業との業務システム連携を考えることはできません。 そのため、情報先進国Aの企業Xは自社の業務効率を考え、リアルタイムに情報交換のできるB国の企業W（競合する大企業）と提携しそうです。 この様な時には、ベンチャ企業Vは折角いいサービスを開発しても、情報交換システムの制約のため、事業拡大のチャンスを失うことにな ります。

このように多くのベンチャ企業もまた大企業と同じく、情報システムの制約によりを企業戦略に有 効に使った市 場開拓やサービスを行なうことは出来ませんでした。

この状況を解決してくれそうなのが最近話題となっているク ラウドサービスです。 クラウドサービス拡大の前提は、家でも会社でも1人1台のパソコンを持つ時代になり、しかも、インターネットや電話網でどこでも高速で 繋がる時代になったことです。 その特徴は
①　どこでも使える。
②　持っているパソコンが大容量でなくてもデーターセンターの大容量のコンピューターを使って処理ができる。
③　ユーザーはバックアップを意識しなくても処理をできる。
④　プログラムを作らなくても処理ができる。
⑤　低コストでできる：高速大容量のコンピューターを自社で持つにはコストがかかりすぎる場合でも、利用頻度が低くければ設備を共用で き、それなりのコストで処理ができる。
といったことです。 ただ、安全性や故障対策、データが盗まれた時の問題があります。 クラウドでは秘密情報等秘匿すべき情報は扱わないとか工場の機械の 自動制御のようにリアルタイムが必要な業務には使わないといった注意が必要ですが、それ以外の情報処理には十分使えます。

企業としてどうしてもやらなくてはいけない会 計、給与、受発注、売上管理、生産管 理、利益計算等の勘定のシステムはすでにクラウドサービスが始まっています。 これらを利用して サービス管理、技術管理、プロジェクト管理等の重点エリアの業務支援にも使えそうです。 このシリーズの「ITC で本業力の活性化」でも述べた SNSやホームページ 等を有効に使うことによるマーケティング力の強化も出来る時代です。 特にSNSはネットワークを通じて、人脈を広げる効果があるので、ベンチャ企業のように多様な人材を雇用できない時には、 協力者を確保する手段として重要です。 これらの情報システムを使えば、簡単に自社の範囲を越え、時にはグローバルな展開まで行なえるので、 図4の空色のようにベンチャ企業Vの 内と外の境界を国外にまで広げる(バーチャルグローバル 企業) ことも出来ます。 こうなれば、企業Yとの業務の効率化や企業Xとの取引も可能になるかもしれません。

まとめ

都市計画アプローチの3つの視点から、ベンチャ企業の装備すべき情報シス テムの基本要件として、下に示すようなものが見えてきました。
①　自社のビジネスモデルを明確にする
②　SNS、ホームページ等のマーケティングシステムを利用する
③　クラウド上の業務システムを利用する
④　ポータブルな業務報告端末を採用する、
⑤　グローバルに使える企業間連携システムを利用する

しかしベンチャ企業には他にもすぐやらなければならないことが、いっぱいあります、 要員や資金も有限です。　どこから手をつけるかのヒントは部分と全体の 考え方に隠されています。

現場に意欲のある人がいれば、部分の利益になることは、全体を見る人が何もいわなくても部分の責任者が自分の責任でやろうとするはずで す。 問題があるのはその中に全体の利益にならないことが入っている場合です。 例えば麻薬の栽培は麻薬を作っている人に利益をもたらすでしょうが、健康 を損なう人や犯罪に走るケースが増え全体から見ると好ましくないとして規制されています。 鍵をあけるスキルを持つ人が行う泥棒家業もこの類の仕事です。

こういったわかりやすいケースは国の法律によって定められていますが、　無用な在庫積み増しや、一時的な収集しか見込めない固定資産の購入のような企業内 の仕組みで全 社で考えると不利益をもたらすものは、企業が自主的に規制する必要があります。 こうした規制事項は中止するか、外注にするというポリシーをつくり、「自社ではやらないことを見える化」し徹底することです。 一方全体の利益になることであっても、水道工事や道路工事のようなものは一部分だけでやっても効果があがりません。 このたぐいのインフラ構築は、公共事業と思って、全体の面倒を見る人がやらざるをえません。 火星観光旅行や深海の住居建造などは、危険な上にお金もかかり部分を見ている人にも、全体を見ている人にも魅力がないので、 普通は規制しなくても誰も手を出さないはずです。 情報システムの構築にも同じ考え方が使えます。 したがって、ベンチャ企業の責任者は次のような方針で、情報システムを構築すればいいわけです。
1. 部門もしくは個人でやっても効果はないが、全社的にやるとメリットがでる情報インフラ作りは行う。
2. 社会や自社全体に不利益をもたらすような、情報システムの構築は規制する。
3. 部門もしくは個人と自社全社に利益をもたらす情報システムの開発は促進する。
となります。

いかがでしょうか、ベンチャを起こそうと考えていらっしゃる方、ベンチャを始めたばかりの方は、このような方針に従って、 現場もしくは部門の意欲を最大限に発揮できるように仕組んで、この項の①②③④⑤にあげた情報技術の採用計画を検討してみませんか。 何しろ本業力を付けたベンチャ企業が生き残り成長するためには、低コストで、人手をかけないで、出来るだけ早く、 物事を行わなければいけない時代ですから。

なお、「都市計画アプローチ」に興味を持たれた方は下記　注1)の南波氏の著書をお読みになってください。

注1）都市計画アプローチについてのより詳しいことをお知りになりたい方は
南波幸雄「企 業情報システムアーキテクチャ」翔泳社，2009をご利用ください。
　http://www.amazon.co.jp/企業情報システムアーキテクチャ-南波-幸雄/dp/4798116858/ref= pd_rhf_dp_p_t_3

注2）都市計画法の第一章　総則では次のようなことが定められています。
（目的） 　　第一条 　この法律は、都市計画の内容及びその決定手続、都市計画制限、都市計画事業その他都市計画に関し必要な事項を定めることにより、都市の健全な発展と秩序 ある整備を図り、もつて国土の均衡ある発展と公共の福祉の増進に寄与することを目的とする。
（都市計画の基本理念）　　 第二条 　都市計画は、農林漁業との健全な調和を図りつつ、健康で文化的な都市生活及び機能的な都市活動を確保すべきこと並びにこのためには適正な制限のもとに土 地の合理的な利用が図られるべきことを基本理念として定めるものとする。

2013/02/26
文責　瀬領浩一