mark-wada blog

企業情報システムモデル

さて、会社の業務の構造ができるとそれにかぶさるように必要な情報システムの姿が見えてくる。

グループ会社全体の管理統制の部分では、経営に必要な情報が集められ、ガバナンスを効かすための意思決定支援の仕組みが重要となる。細かい情報より正確なマクロ情報が経営者にと届けられることが望まれる。

従って、データウエアハウスのような情報活用のシステム化が必要となる。なお、法務や税務のようなプロフェッショナルサービスはシステム化しにくい領域であるが、プロの判断を助けるような情報提供の仕掛けあたりが可能性がある。

事業執行の部分では、SCM（Supply　Chain　Management）が主体となり、ここはERPがカバーする領域でもある。このなかには、製造業ではプラント制御や生産管理システム、金融業ではATM、流通業だとPOSなどが含まれるが、これらについてはそれぞれ個別の要件なのでここでは議論しない。

サプライチェーンサポートでは、コアプロセスのシステム化が先行しているが、それでもパッケージを適用した管理システムの導入が行なわれている。ただし、今後は各社特有のものがあるため柔軟なつくりが求められているように思える。ですから、このような領域は、いまはパッケージベースですが、「CMS+BPM」による開発が適用できる可能性が大きい。

あと最近重要なのは、顧客接点と従業員サービスです。まさにここはWebアプリケーションによる情報共有の仕組みが大事になります。最新のインターネット技術やサービスを大いに活用する領域でもあります。
こんな感じで大づかみの企業情報システムの構造が浮かんできます。

次回から、こうした仕組みを実現していくためのソリューションやサービスといった話へと進んでいきます。

最近、システムの開発のことを考えているので、何か開発するとき一番難しいあるいは重要なポイントは何かというようなことに思いめぐらせている。システムもモノもサービスもみな一緒で結局、多くの人に使って（買って）もらい、喜んでもらえるかどうかに尽きる。

そういうものをなかなか開発することができないのは、思いもよらないものをひらめくことができないことなのか、こんなものを作りたいが作り方がわからない、あるいは作るのが難しいからなのか、使い勝手やデザインがうまくいかないのか、などいろいろな要因がある。

ぼくはこれを解決するには３つIが必要と考えている。Imagination、Idea、Intelligenceの３つのIのことで、「豊かな想像力により生まれた斬新なアイデアを高い知性で実現する」とでも言ったらよいが、創造の３Iと呼んでいる。どれも重要であるのはわかっているが、それに関してある有名な話を思い出した。

“痛くない注射針の話”は皆さんよくご存知だと思いますが、岡野工業の岡野雅行社長（浦和レッズの選手ではありません、念のために）が、0.2mmという蚊の針とだいたい同じ太さの極細の注射針を開発した。プレス加工で実現した信じられないしろもので、製作を依頼したテルモという医療機器のメーカもさんざんいろんなところをまわったがどこもできなかったのを岡野社長が作ってしまった。

この注射針は細く作ることももちろん重要だが、もし細いだけだと液量が出なくなるのでここをどうするかがポイントだったが、実は途中まで太くて先だけが細い形にしたことで壁を乗り越えた。まあ、このアイデアとそれを実際に作ってしまう技術には驚かされる。

で、この“痛くない注射針”で有名になったのは岡野社長であったが、ぼくは待てよと思ってしまった。というのは、その“痛くない注射針”を作りたい、作ってしょっちゅう注射をしているひとに喜んでもらいたいと思ったのは、テルモの企画担当者なのだ。それで何社も頼んで断られてもあきらめずに岡野社長のところに行ったのもそのひとだ。だから、ぼくは最初に考えついたひとがエライのではないかと思ってしまう。テルモの社員をもっとほめてあげたい。

当然、素晴らしいWhyとWhatがあってそれをすごいHow　toで実現するのがいいに決まっているが、日本ではもう少しWhatを考えたひとがスポットを浴びてもいいような気がするがどうだろう。

ソリューション体系とサービス体系

マクロ的な構造としては、ユーザが自分たちの業務を実行するためのソリューションやサービスと、それを支えるシステム基盤から成っている。そして、システム基盤には大きく業務アプリケーション、システム開発、システム運用・管理、情報インフラの４つのレイヤーがあると考えている。さらに、それぞれのソリューションやシステム基盤もそのなかは構造化された構成となる。

そこからまず、ソリューションとサービスの体系を見てみる。

ソリューションというと、昔ある上司から意味がわからないと言われた。その上司は化学を勉強した人だったので「溶かしてどうするんだ」と皮肉られた。だから、あまりこの言葉は使いたくないのだが、他に適当な言葉が見つからないので、“ITによる解決策”という意味で使う。

ソリューションも業務別と業種別の二つに分けられる。業務別ソリューションというのは、前々回に示した業務分類に従ったもので、例えば大きく基幹業務系と支援系、実行系があり、そのなかでもさらに細かく、販売や生産、会計、人事系などに分類され、それぞれに適した業務アプリケーションが提供される。

業種別ソリューションは、事業部やグループ会社にはいろいろな業種のものが含まれてくるので、その業種に応じたソリューションを用意しておく必要がある。

一方、これら業務アプリケーションをどういった形で提供してもらうのか、また保守や運用をどうしてくれるのかといったサービス提供形態を決めておくことも必要となる。

全部自社内で抱えるのか、外部サービスをSaaS、ASPの形で受け入れるのか、グループ会社に対してはASP提供でいくのか個別なのか、アウトソーシングするのかなど効率的な運営をめざした体系つくりが重要になってくる。

UEFAチャンピオンリーグの準決勝でACミランが逆転で決勝進出を決めた。ファーストレグで３対２と敗れたACミランであったが、ホームのセカンドレグで３対０とマンチェスターユナイテッドを圧倒した。

この勝利の立役者はだれでも認めると思うが、１点目を入れたカカだ。素晴らしいゴールだった。いまやロナウジーニョを抜いて世界ナンバーワンのプレイヤーだと思う。シュートもできるし、ドルブルは早いし、パスも出せるオールラウンダーで、見ていてもほれぼれする。なんといっても彼の姿勢がいい、ぼくの好きなプレースタイルである。まだ、２５歳になったばかりだからこれからさらに進化していくのだろう。

決勝は、リヴァプールと２３日アテネで今度は一発勝負で行なわれるが、ぼくはどちらを応援するか特に決まっていないが、カカのプレーとリヴァプールのジェラードのプレーに注目している。

このクラブチームの最高峰が戦う試合は、レベル的にはワールドカップ以上ではないだろうか。きっとすごい試合になるぞ。

もう二度と書けなくなるかもしれないので早く書いておく。わがベイスターズがついに３年ぶりの単独首位に立った。やはり、今年は何か違うと思ったらこの快進撃だ。

でもこれは、たまたまみんなが調子がよくてというわけではないのでひょっとしたら長続きするかもしれない。投手陣だってやっと三浦が勝てたくらいだから出揃っているわけでもないし、攻撃陣も仁志と村田はがんばっているが、チーム打率も低いし、だからなぜこんなに強いのかわからない。大矢さんの采配かな？

いずれにしろ、毎日スポーツニュースを見るのが楽しいのであります。

以前、ブログでyabuさんという方から薦められた「安心社会から信頼社会へ」（山岸俊男著、中公新書）を読む。「日本人はいじわるがお好き？」というような話をこのブログで書いたら、もっと先行している研究があって、上記の本に書いてあるので読んでみたらというコメントをいただいたのだ。

確かにすごく面白かったのと感心させられた。のっけに“人を信じることは、おろかなお人好しのすることでしょうか。それとも逆に、誰も信じないで「人を見たら泥棒と思え」と思っているひとこそ、おろかな人間なのでしょうか”と問いかけてくる。

そこから、社会的ジレンマの実験や信頼ゲーム実験などからいろいろな仮説を導き検証していく。それらをいちいち書くわけにいかないので、現在の日本の社会が直面している問題について、本書から抽出してみる。

いま「日本型システム」の不信が拡大していて、これはこれまでの安定した社会関係が崩壊していることを意味している。それは、コミットメント関係、とくにやくざ型のコミットメント関係の形成による安心の維持が、機会費用の急速な上昇によって「高くつきすぎる」ようになったために生じた変化なのだそうだ。

そして、こうした集団主義的な組織原理から、より開かれた組織原理へ向かう日本社会の変革を進めるためには、一般的信頼の醸成が不可欠であるといっている。いいかえれば、コミットメント関係の内部で情報を共有しながら外部に対しては情報を漏らさないというやりかたで関係を安定させ、その内部で社会的不確実性を低下せしめてきたがそのコストが増大したというわけである。

だからそれとは逆に開かれた関係になった場合の不確実性をどう低減するかが問題で、それにはさまざまな組織における情報開示あるいは情報の透明性を高めることがその解決策であるといっている。

とまあ、かなり乱暴にまとめてしまったが、いまネットを中心に明らかに大きな情況の変化がおきているように思えます。この変化もまた、山岸俊平のいう“新しい文化の創造のプロセス”なのかもしれません。

もう世界は開かれたものになってしまったわけで、従来のように内輪でこちょこちょするようなことはやめなくてはいけない。ぼくの足元のシステム開発においても、必要なアプリケーションという意味でも、またオープンソースに代表されるような開発形態においても情報共有と情報開示がすごく重要なキーワードになっているような気がする。また、「ギークなひとたち」と「スーツなひとたち」の融合も開かれた変化の結果として実現してほしいと思う。

そのときわれわれは、「人を見たら泥棒と思え」とふるまうのか、だまされてもいいからひとを信じ続けるのか、ただ乗りするのか、意地悪行動をとるのか。少なくともぼくは、楽観主義の高信頼者でいようと決めている。

業務アプリケーションの構造化

業務別あるいは業種別ソリューションのための業務アプリケーションをどのような構成でどうラインアップしていくかということになる。これまで述べたように業務プロセスもミッションクリティカルなものから、しょっちゅう変更を余儀なくされるものなど様々であり、こうした業務プロセスの性格に応じた作りにすることが重要となってくる。

大きく固定的業務プロセスと変動的業務プロセスに分けられる。固定的業務プロセスというのは、例えば、決算システムのように会社を運営していくための根幹の業務プロセスはビジネス環境が変わってもそう大きく変化するわけではないものをいう。一方、変動的業務プロセスというのは、顧客接点の業務など変化が激しいものや、競争優位を保つためにあえて変えていく業務プロセスなどである。

固定的な業務プロセスに対するアプリケーションを開発する場合は、自社のもつデータの解析、特にリソースデータは自分たちがビジネスで戦っていくための原動力なのできちんと整理し、データベース化することが大事だ。そこから堅牢なシステムができてくる。変動的な業務については、変更が容易な、要するに簡単に安く早く作れる構造にしておくことが望まれる。

「ビジネスコンポーネント指向開発」という提案で、コンポーネントを「書類のライフ」とみたてて、それらをBPMで組み合わせて開発するとしているのは、特に変動的な業務プロセスに対する簡単に安く早く作れることをめざしたものである。

ここでビジネスコンポーネントであるが、狭義の意味では「書類のライフ」としてみたが、広義の意味では、固定的業務プロセスに対するアプリケーションそのものもコンポーネントと呼べないこともない。例えば、会計パッケージなどはそのものをコンポーネントとして隠蔽してしまってもかまわない。

“変わるもの（業務プロセス）は変わらないもの（コンポーネント）の組み合わせ”といえるので、コンポーネントには大きなものから小さなものまで様々な粒度がある。その粒度を決めるのは、いかに固定・変動の区分けができ構造化できるかになってくる。

ここのところやっと映画を観る機会が増えてきたが、それ以前はなかなか時間がとれず観損なったものが数多くある。そこで連休中にDVDやテレビの録画でリカバリーすることにした。

昨年、一昨年のキネマ旬報のベストテンを中心に観た。とりあえずは日本映画を対象に、「男たちの大和／ＹＡＭＡＴＯ」「嫌われ松子の一生」「かもめ食堂」、それとベストテンには入っていなかったが「ハチミツとクローバー」である。これでも、まだ半分に満たないのでもう少しがんばって全部クリアしようと思う。

以前ブログで日本映画がいい方向に進んでいる実感がないと書いたが、さすがキネ旬のベストテンに選ばれるような作品は安易なつくりではなく優れたできである。

「男たちの大和／ＹＡＭＡＴＯ」は、当初はあまり期待していないで、まあＣＧ駆使した戦争スペクタクルかと思っていたが、ぜんぜん違ってすごくいい作品に仕上がっている。まず、下級兵士の目線で描かれていることや構成がしっかりしていることに感心。またぼろぼろ涙を流してしまった。

「嫌われ松子の一生」は、こりゃ中谷美紀がすげえや。“松子を演じるために女優を続けてきたのかも知れない”と言ったらしいが、まさに体当たり演技で彼女の代表作になった。前回の「安心社会から信頼社会へ」という話のなかで、だまされてもいいからひとを信じ続ける態度のことを話したが、この松子はまさに男にことごとくだまされ、捨てられながらもまたすぐに新しい男に尽くす一生を描いている。で、こういう作品は観終わったとき、ひとの不幸を見せつけられて嫌な感じになるのか、それにめげずに生きていく主人公をみて元気をもらうのかで評価が分かれます。ぼくは、後者の感想をもちました。

「かもめ食堂」は、だれでもホンワカになれる映画だ。川上弘美の本を読んで「空気感」といったが、この映画にはそれがある。小林聡美、片桐はいり、もたいまさこの３人の距離感がかもし出す微妙な雰囲気がいい。最近同じくらいの年頃で男ひとりというのも増えているので、だれか男三人の「アヒル食堂」でも作ってくれないかなあ。

「ハチミツとクローバー」は、蒼井優が出ているので思わず手にした。蒼井優は「男たちの大和／ＹＡＭＡＴＯ」にも出演していたから、最近の出かたはすごい。もう少しセーブしたほうがいいのではないかと親心を抱く。この作品もぜんぜん予備知識がなくて、有名な漫画の映画化だったことも知らずに観る。基本的にぼくはこの歳になってもこういった青春映画は好きなのですんなり入る。観終わったあと爽快感もありいい映画でした。

というわけで、どれも秀作で楽しめた。

業務アプリケーション調達方針

さて、業務アプリケーションをどうそろえていくかを検討しなくてはいけない。今は、全部自前で作りこむ会社はないでしょうから、自作しないで買ってくるだとか、借りてくるだとかの選択も行なっていくことになる。

買うというのは、出来合いのパッケージを買ってくることで、借りるというのは、最近登場してきたASPやSaaSのように使用量・頻度に応じた従量料金を払うことでサービスを利用することをいう。そういう意味では以前から比べると選択の幅がかなり広くなったといえる。

それぞれの選択の基本的な考え方としてはつぎのようになる。まず、買ってくるのは、たいしたカスタマイズをせずにそのまますぐに使えるもので、作るよりも安価であり、再利用をしないようなものが対象となる。例えば、業種・業態別給与計算パッケージなどである。

借りてくるのは、変化が激しくいつやめるかわからない機能だとか、法制度等の変更が頻繁で個別にメンテナンスがやってられないものなどである。例えば、特許情報などです。

ですから、それ以外、例えば自社固有のこだわり機能が多いものや、1回作ったら再利用先がいっぱいあるものだとかは自社開発となる。

こうした特性を見ながら対象業務アプリケーションを調達あるいは開発をしていくが、忘れてはならないことは、ラインナップされた業務アプリケーションが孤島システムにならないようにうまく繋いでいくことが非常に重要であるということである。

「作る」「買う」「借りる」のバランス、そしてそれらを「繋ぐ」連携が大事であるといえる。このマクロ的なシステム基本構造がSOAの概念で作られるイメージです。基本構造は下図のようになる。

業務アプリケーションプラットフォーム

各種業務アプリケーションをどのようなプラットフォームに置くかを検討していく。こうしたプラットフォームも構造化しておく必要がある。

大きく、入力・ポータル系、業務処理系、出力・情報活用系に分ける。入力・ポータル系では、実際にデータを入力する仕組みでさまざまな方法がある。単純にEXCELシートから入れる場合や最近ではRFIDの利用などがある。さらに、EDIなどでシステム的に連動させるケースも増えてきている。

業務処理系では、確定した後のデータを処理するプラットフォームとそこへ投入するデータを確定していく処理するプラットフォームに分けて考える。前者は会社の根幹となるシステムでおおざっぱにいうと「有価証券報告書」を作るためのシステムとなる。後者は、再三出てくるように情報共有型の仕事により、データを確定していくためのもので、そこにオープンＣＭＳのようなものを活用することを薦めているわけです。

こうして、蓄積されたデータを見せる仕組みが出力・情報活用系のプラットフォームになる。日本ではまだまだ帳票文化が残っているのでレポーティングのシステムは重要になる。ここでもきちんと構造化し、トータルシステムとして機能させることが大事になってくる。意外とここの仕掛けは難しい。データをダウンロードして、分析して意思決定を支援したり、その後のアクションプランに反映することも重要である。最先端は流通のＰＯＳシステムであろうが、そのほかの業種でもこの仕組みをどれだけ生かせるかは、その企業の競争力に大きく影響する。

このデータのハンドリングはただ生成されデータを持ってくるだけでは不十分で、最初のデータベースの設計が非常に大切であることはいうまでもない。

各プラットフォームの構造

それでは、各プラットフォームの構造を見ていきます。

まず、エンドユーザが業務処理や情報へのアクセスなどを行なうための入り口であるポータルがあります。また、ポータルは内外の関係者との情報交換や情報共有を行なう連携の場でもあります。

従って、連携の範囲により、Personal、Group、Companyに分かれ、情報の処理形態により、Business、Analysis、Knowledgeに分かれます。従来この領域はグループウエアと呼ばれるものが主流を占めていましたが、これからはCMSを使ったブログやHPのようなWebサイトがその機能を担うことでしょう。

次に、出力系であるレポート管理システムがあります。

いまは帳票レスの方向へどんどんシフトしていっていますが、法定帳票や一覧性を要求されるチェックリストの類などはなかなかなくなりません。

また、開発のとき意外と手間がかかるのも帳票ですし、運用における面倒臭さもつきまといます。このレポート管理はどちらかというと業務アプリケーションごとだったり、エリアごとだったりと個別の対応にまかされていて、またデータ形式もばらばらだったりと非効率的であることが多い。

ここでも、フォームのデザインを開発する機能、それを使って実際の帳票を作成する機能、できた帳票を仕分して配信する機能、また電子帳票化する機能などに構造化する必要がある。さらにそれらを統合的に管理する仕組みを持つことが望まれる。

最後にデータ活用という意味で全社的なデータウエアハウスの構築が必要になる。

データにもさまざまな性格をもったものがあり、また使われ方もまちまちであるため、それらに適したデータベースが配置され、各データベースが整合性をもって統合化された形を作ることが重要である。

会社のリソースとしてのマスタDB、業務アプリケーションを動かすためのトランザクションDB、そこから、情報活用に必要なデータを集約したセントラルデータウエアハウス、また用途に応じて使いやすいように抽出されたデータマートに整理される。さらに、最近では、ネット上（外部サーバー）にある各種データも使われるようになってきている。

５月４日放送の「たけしの誰でもピカソ」で岡本光平という書家が齋藤けさ江という９２歳のひとを紹介していた。このおばあさんは７０歳で字を覚えたという人でそれからすぐに書を始めたそうだ。その書は素朴で自然体の字が素晴らしく、岡本光平は「いい字」だと言っていた。

またもうひとり８歳の高橋卓也君という子が登場。この子はモントリオール国際芸術祭・書道部門グランプリを受賞した有名な子で、その奔放なそして絵画的な漢字を書く。まあ天才ですね。けさ江ばあさんも言ってみればこどものようなものだから、おとなと違って余計なことを考えずに一生懸命書くということが素晴らしいのだ。

芸術家というのはみな、子どものように無心になれるか、邪念を振り払ってありのままを表現できるかどうかということを盛んにいう。

それと同じようなことを言っていた人たちがいた。ずっと前に中村勘三郎と柄本明が出演する「弥次喜多」の映画撮影現場の取材でふたりが異口同音に言っていた言葉に「こどもの学芸会のような芝居ができたら」というのがある。これも同じで、何というかそれこそ芝居っ気なしに素直に演じられてこそいい演技になるということを言っているわけで、さっきの書の話と通じている。

だが、芸術家になりたくてもなれないぼくらにとって、２つの問題を考えてしまう。
ぼくだってもちろんこどものときがあったわけで、じゃそのときぼくは芸術家だったのかということと、こどもが大人になるとそのみずみずしさを失っていくのかという点である。やっぱ、才能はもって生まれたものでしょうね。卓也君なんて２歳のときに漢字を書いているんですよ。ああ、ぼくなんか無心で書いた習字を先生が朱色に染めてくれたんだから。

また芸術的天才は、その天才を続けるにはある種の「狂い」がないとだめなのじゃないかと思ってしまう。それによって、「子ども」をかろうじて維持しているのではないかと。ちょっと大胆だったかな。

ハブ＆スポーク構造

さて、アプリケーションプラットオームの構造を見ていくと、骨格がハブ＆スポーク型に描かれているのがわかると思います。データにしてもアプリケーションにしてもいったんハブに集められ、そこを経由して配信されるイメージである。

今まで提示してきた構造は、まだSOAとかESB（Enterprise Service Bus）という言葉がない時代に筆者が考えたものであるが、そのSOAやESBとどう違うのかという議論がある。ここで厳密に違いを明らかにする意味はあまりないと考えるが、ざっと整理してみる。

システム間連携の歴史を追うと、最初は２つのシステム間の直接のデータのやり取りでした。しかし、これだと同期をとらなくてはならないのでかなり難しい。そこで登場したのがMQ(MessageQueuing)で間接的、非同期のやりとりにより統合がスムーズになったが、１対１ならまだしも１対NとかN対Nのような統合となると複雑になりすぎて現実的ではなくなった。

そこで、考えられたのがハブ＆スポーク型の構造でこれにより複雑さが解消された。EAIである。従って、いままではEAIのアーキテクチャーであるハブ＆スポークは、主としてMQなどのメッセージ伝送用APIによる独自の仮想化のことでした。ところが、いまや多くの異種システムを抱えてきてそれらの連携にはどうしても標準化と分散化というのが避けて通れなくなった。そこにオープン技術で標準化されたSOAやESBという概念が登場したわけです。

ですから、おわかりのようにSOAはハブ＆スポークと同列の話ではないし、ESBもあくまで仮想化の話だから、基本的な構造概念はハブ＆スポーク型でそれがバス的な接続になっているだけと筆者は考える。

それで重要なのは、どういうハブを用意するのかである。SOAだからサービスをつなぐんでしょと言われそうだが、そりゃちょっと粗っぽいわけで、もう少し分類しておく必要がある。

まず、データの連携のためのハブ機能は従来型のEAIであり、またデータウエアハウスもデータハブといえる。「ユーザ目線のBPM」でさんざん議論したように機能のハブはBPMである。前回紹介した「統合レポート管理システム」は言ってみれば帳票のハブでもある。そして忘れてはいけないのは、データ総研の椿さんが言っている、業務アプリケーション（プログラム）のハブ／通信場としてのデータベースの役割です。

ですから、システムの構造を規定しているハブ＆スポークという考え方は幅広い概念といえるのです。
統合化されたプラットフォームイメージを下図に示す。次回から開発技術について論を進めていく。

開発技術

業務アプリケーションの調達には、作る・買う・借りるという選択肢があると言ったが、そのうちの作るという場合はその形態にバリエーションがある。すなわち、純粋に自社要員（情報子会社も含めて）と自社技術で開発する場合とSIerに作らせる場合がある。またその中間のような常駐外注に委託するようなものもある。

やはり、情報システムの重要性を感じているのなら、自社で開発できる技術とリソースを確保すべきであろう。なかには、持たざる経営とか言ってアウトソーシングに走る会社もあるが、経営とITの狭間がますます拡がるように思える。

しかしながら、IS部門や外販を志向しない情報子会社（こうした子会社の問題はあとで議論する）が、IT専門会社のように開発技術を深く突っ込む必要はない。基本的には、プログラムレスで開発する技術を追求すべきであるから、設計寄りのスキルを保有し、プログラミングは外部へというのがめざす方向性となる。ここは多少気になるところで、プログラミングができないで設計ができるのかという声が聞こえてくる。理想的には、ほんの少数の優秀なプログラマーを抱えておければいいのだが。

プログラムレスの開発ということになると、フレームワーク、コンポーネント、テンプレートを使った開発ということになる。すなわち、これらフレームワークなどはスーパークリエーターにプログラミングしてもらい、それを道具としてプログラムをあまり書かないで済む開発方法である。

「ビジネスコンポーネント指向開発」とはまさにこの開発方法論である。詳しくは、既に書いてあるが、簡単に言うと、ビジネスコンポーネントを書類のライフと見立て、その機能をオープンCMSで実現し、そのコンポーネントをBPMで組み合わせて業務プロセスを作り上げることにある。

従来の開発方法と違ういくつかのポイントがあるが、それも「ビジネスコンポーネント指向開発」に詳述しているが、書き忘れたことがあるので補足的に述べる。CMSを使ってあるタスク（書類の作成－承認）を遂行するというのが大きな特徴なのだが、それは昔のある経験から思いついた。

もうかれこれ１０年くらい前になるが、工場の生産管理システムを開発したときのことである。当時筆者は情報システム部門に来たばかりであったが、立場上プロジェクトマネジャのような役割であった。システムは、営業・製造・品質保証・物流が関係するけっこう大きなものであったが、初めてということもあって、この開発プロジェクトではさまざまな貴重な経験をした。

開発対象となったなかである重要な業務プロセスに、製造部門がバッチで生産された製品を入庫し、品質保証部門が引き当てて、物流部門がローリーで出荷するというのがあった。これをシステム化するのだが、多くの例外処理や戻り処理が発生し大変なことになる。

例えば、出荷規格あるいはユーザ規格から先入れ先出しで自動で引当するなんてロジックを組むのだが、いざ運用すると、規格内に収まっていてもあるユーザにはもっといい品質でないとだめだとか、つぎの出荷に大事なユーザが控えているので引当てたものはとっておくといったふうになり自動で運用できないとか、最低在庫を割ってしまうからそのサイロから出庫できないはずが、いやその程度なら経験的に量は確保できるからだいじょうぶだとかになる。

要するに担当者の頭の中で決められてしまうことがけっこうあり、しかも製造、品質保証、物流の三者が別々の場所にいて、主に電話でやりとりするわけで、このコミュニケーションがうまくいかないと手違いが起きたり、戻って処理するようなことが起きる。

そのとき、プロジェクトのメンバーに言ったことをいまだによく覚えている。「この問題のもっとも効果的な解決策は何かわかるか？　それは、３つの部門の担当者を一つの建屋に集め机を並べて仕事をさせることだ」。

で、もちろんそれはできなかったのだが、業務を安定化させるあるいはデータを確定させる作業は非常に不安定なふるまいだから、不定形な会話を繰り返しながら徐々に確かなものにするのがいちばん早いように思えたのだ。ですからここをシステムに乗せるというかプログラムで書くことはしょせん無理なのではないかとずっと思っていた。

しかし、いまや机を並べて会話しながら仕事を進めることと同じように双方向コミュニケーションがシステム的に可能となったのだ。すなわち、CMSを使った情報共有的作業である。ここに「ビジネスコンポーネント指向開発」のヒントがあったのだ。

また、開発技術というと言語レベルのような実装ITを考えがちだが、企業のIS部門にとっては、業務プロセスをデザインするスキルこそ最も重要かつ必須なものである。何回も繰り返すが、事業に役立つ業務プロセスがデザインできてこそ、ITが使えるわけで、先にITありきではないというのが基本です。

ただ、全くそうかというと逆のアプローチも必要なことももちろんある。Web技術のCMSから情報共有プロセスを考えつくなんてはこうしたアプローチに近い。今後は、RESTとかRSS、Wikiとかいった技術から新しい知的生産作業プロセスが生まれてくるだろう。

企業のなかには、業務プロセスのデザインを外部のベンダーやSIerにまかせているところもあるが、それは間違っています。そこのスキルは死守しなければなりません。それがここでいう開発技術ということになります。

システム運用

さて、いよいよ運用の話になるが、ユーザからみてここの領域は、専門性が高いところでもあり、技術的な突っ込みは限界がある。むしろ、体制だとか管理プロセスといったソフト的な対応が重要となる。

まずは、運用業務はITIL(Information Technology Infrastructure Library)でほぼ網羅的に規定できる。ただしITILはあくまでIT業務プロセスのフレームワークであるので、これに基づいて自分たちの体系・基準・手順に落とし込んでいかなくてはいけない。よくITILに限らずこういったフレームワークやガイドラインをそのまま適用すればOKだと勘違いするひとが多くいるが、そんなものはありません。あくまで指針であり、リファレンスですから、それを参考にして自らの手で自分らの身の丈にあったものを作り上げないと意味がない。

そういった観点からITILをみると、ITILはよく整理されていて、その言わんとしてるところをよく理解すれば、非常に参考となるフレームワークだ。ITILは大きくサービスサポートとサービスデリバリーがあり、そのなかに６つと５つ合計１１の管理項目が提示されている。これらを厳密に全部やろうとするとけっこうしんどい話なので、まずは肝のところを確立するのが現実的だ。

サービスサポートでは、IT資産管理台帳の整備とヘルプデスクの充実だ。クライアントPC、サーバー、ストレージ、プリンター、ネットワーク、ソフトウエア、ライセンスなどを一括管理できるデータベース（CMDB（Configuration　Management　DB）の基本部分）を作り、それと不具合や故障履歴などと連携させ、ユーザからの問合せに迅速に対応できるようにしておくことが大切である。

サービスデリバリーでは、SLA（Service　Level　Agreement）の作成である。それも、完璧なものはできないので、決められるものから始めるのが大事である。何よりもユーザとの合意が必要なので、できないことを謳ったり、どちらともとれる曖昧な表現は避けたほうがよい。

従って、ITIL準拠の運用管理の基本は、CMDBとSLAということができると思う。このあたりは、普通の業務システムと同じで、データベスと業務機能・プロセスの適正化のことなのです。

セキュリティに関しては、セキュリティポリシーの策定とそれにそれに付随するセキュリティ対策基準、技術基準などが必要となる。これもやみくもに対策を打つのではなく、きちんとしたリスク評価をして実施することが大事である。

その他、最近ではBCP（Business　Continuity　Plan）やDR（Disaster　Recovery）といった地震災害などを想定し、事業の継続性をどう維持していくのかといった対応策を策定しておく重要性も増してきている。

運用体制については次回に議論する。

高校野球の特待生の話題で盛りあがっていますが、高野連が緩和策を提示して、どうも世論は特待生制度に肯定的になっているようだ。だいたいの人がこうした制度があることを知っていただろうし、いまさら何を言い出すのだという感じではないでしょうか。

スポーツに限らず何かに秀でた子を経済的に支援するというのは別に悪いことだとも思わない。昔は、勉強ができる子がお金がないので進学できないときに助けてあげるなんてことはよくあったわけで、今は勉強できる子はお金持ちの子だから援助はしなくてもいいというだけで、それとどこがちがうのかと思う。

つい勉強するのがいいことでスポーツでお金もらうのは汚いみたいに思う人がいる。プロ野球の選手になるのに特待生はおかしいということなのだろうが、勉強だってある意味お金を稼ぐためでもあるんだから、要は、才能がある子がその才能を伸ばすために経済的に援助してあげると考えればいいのだ。

みなの心情的な部分で、学校教育というのは傑出した人間を作る場ではないと思っているが、実はそうではなくて、いい例が、甲子園が終わるとマスコミがこぞって「さあ次の甲子園のスターはだれでしょう」なんてことを平気で言う。スターを作らないのが学校スポーツじゃなかったのかと思ってしまうが、特に日本の高校野球の世界はちょっといびつなのだ。それでも、できる子の道がそこしかないのだからそれはそれでいいんじゃないのと思う。

むしろ、ここでぼくが言いたいのは、勉強、スポーツ、芸術に秀でた子はいいけど、おおかたの子は普通の才能で、まあ他人より少し勝てるものをちょっと持っているだけであるわけで、その子たちを忘れないでねということになる。

つい才能豊かな人たちをすごいと思うが、もっと「平凡であること、平凡でいること」のよさ、価値を考え直してほしいと思う。

ここの「平凡でいること」も意外とできないものなのです。例えが飛躍して恐縮ですが天気のことです。天気予報などでよく「今年は平年並みの気候です」なんていうことがあるが、平年の天気ってあるの？と思ってしまう。特に最近なんか毎年異常気象といって、暑かった寒かったり、雨ばかりだったりというふうに、いつも同じような気候ではないのだ。昔だれだかが、言っていましたが「天気は異常なのが普通です」。

人生だってそうかもしれません。異常の繰り返しや突如降ってわいたような不幸が舞い込んだり、健康を損なったりするわけで、これも例えが悪いかもしれませんが、拉致被害者の家族にしても、本当はごく普通の人生であったかも知れないのが、全く違った人生になってしまうわけです。だから、「平凡でいること」も難しいのです。

ただし、この場合はかなり他力的な部分が大きいのでしょうが、「平凡であること」は自力の問題です。実は何もしないでぼおーとしていてはできないのです。そこには、堕落しそうになったときの倫理観だとか、有頂天にならない自制心だとか、もとにもどすバランサーが働いていること重要なのです。大げさに言えば「中庸」ということかもしれない。

そこには、教養だとか徳だとかいった裏打ちがあってこそできることのように思える。教育再生会議で「教えるべき徳目」とか「子育て提言」なんて言うけど、その前にこの「平凡であること、平凡でいること」の価値をみんなで認め合うことも大切ではないかと思う。

ここ二年間のキネマ旬報ベストテンに入った日本映画で見損なっているのをDVDで観ているということを書いたが、その第二弾として、「リンダ　リンダ　リンダ」、「雪に願うこと」、「博士の愛した数式」の３本を借りてくる。

「リンダ　リンダ　リンダ」は、これは、女子高生が学園祭でバンドをやる話で何となく「スイングガールズ」を思い出させるが、こちらのほうもよかった。女の子４人の個性がうまく出てて、青春という感じで好感が持てる作品。ぼくはこんな作品はみんな好きなのだ。

「雪に願う」は、最初は「ばんえい競馬」の存続が危ぶまれていた時期でもあり、そういったストーリーかと思ったら、そうではなくて東京で挫折した弟を結局は暖かく迎える兄と故郷というなかに、ばんえい競馬を重ね合わせた映画で、何とも帯広のひとたちの朴訥とした雰囲気がいい。そして、最後に馬の姿とおのれの姿をだぶらせてそこで終わるという終わり方がすばらしい。さすが、根岸吉太郎だ。

「博士の愛した数式」は、原作を読んでいないのでなんとも言えないのだが、どうして吉岡秀隆扮する数学教師が思い出を語るのだろうかと思ってしまう。博士と家政婦親子の交流だけに絞って見せてくれたほうがよかったんじゃないかな。同じように、浅丘ルリ子の義姉との関係や能のシーンは余計のような気がする。小川洋子と藤原正彦の対談かなんかで数学のおもしろさや美しさを教えてもらったので、それを博士自らにしゃべらせればよかったのにと思う。

小泉 堯史は「雨あがる」「阿弥陀堂だより」に続いて監督３本目だが、全部主演は寺尾聡なのだ。このコンビすげえ渋くて、癒される感じなんだけど観ていてどうももうひとつ元気が沸いてこないのだ。

さて、続けて７本観たのだけどそこに複数回出演したひとを調べてみた。（暇だなあ）そうしたら、３本出ていたのが伊勢谷友介で、あとは２本だが、蒼井優、松山ケンイチ、中村獅童、香川照之、本田博太郎、甲本雅裕、山本浩司といった面々。いまどきの旬な俳優さんと重宝に使われる個性派バイプレイヤーといったところですね。

運用体制

企業の多くにはIS部門あるいは情報子会社を抱えている。もちろんそうした部門を持たない中堅企業も存在する。どちらにしろ、何から何まで自社でやれないので、どこの部分を自社要員でやって、どこの部分を外部にまかせるのかという、いわゆるソーシング戦略が重要となる。ひところフルアウトソーシングといって全部アウトソーサー（といっても情報子会社を大手ベンダーが買収して作った会社が受け皿になるのが多いが）にまかすこともやられたが、さすがに溝もできたようでフルアウトソーシングは難しいようだ。

従って、アウトソーシングとインソーシングのバランスがポイントになってくる。通常は戦略的な機能は自社で、オペレーショナルな機能は外部にというのがよく採られる戦略だ。

具体的には、まず親会社の企画部門のようなところで経営戦略や事業方針に則った情報戦略が立案される。それに従ってIS部門や情報子会社は情報化計画を作る。しかし、この経営戦略や事業方針からの情報戦略というのをきちんとやっているところは少ないのではないだろうか。もちろんITがコアコンピタンスになっているところは別にして、普通の会社の情報システムでは、システム部門が勝手に類推して、こんなことを経営者は言っているから、こんなものを作ろうとかとなり、実際に開発の申請をするとさんざん投資対効果の説明を求められ、コストダウンや定量的メリットが示せるものだけしか通してくれないなんていうのが実情ではないだろうか。それでも、事業部や現場とのコミュニケーションを継続してやるという不断の努力が必要であり、そこからエンドユーザのニーズを拾い上げるしかない。

単純な運用・保守はできるだけ外部のアウトソーサーを活用したほうがいいと考える。例えば、ホストコンピュータやメインサーバさらにネットワーク（WAN）の運用などは設備の整った、そして多くのオペレータがいるセンターに預けるのが賢い選択だ。預け方には、ハウジング、ホスティングという手もあるが、大きなリソースをシェアすることで更なるコストダウンが図れるアウトソーシングのほうが有利であると思われる。このとき、きちんとしたSLAを結んでおくことが重要であるのは言うまでもない。

運用の中では、ヘルプデスクの機能はアウトソーシングしないほうがいいと筆者は考える。ユーザとの接点であり、日々の会話からシステム化のヒントや改善案が出てくるので、直接自社要員が対応することを薦める。

大きな会社ではたいていグループ会社をもっているが、親会社のIS部門あるいは情報子会社がグループ会社の情報化を一手に引き受けることがグループ経営にとって効率的である。すなわち、グループ会社のアウトソーサーになるというイメージだ。連結重視の経営になった今日、余計にこうしたシェアードサービスの考え方は重要であろう。

情報インフラの構造化

さて、情報インフラであるハードウエア設備をどう構成し、配置していくのかになる。実際には運用体制のところで述べたように、かなりの設備はアウトソーサーのセンターに配備されるわけだが、物理的な問題というより、安全性、安定性、可用性、利便性などからみた構成の考え方が重要である。また、コストとの兼ね合いもあるので、コストパフォーマンスのよい構造化が必要となる。

ネットワークでは、ミッションクリティカルな業務が乗るものと多少の停止は我慢できるものとは別系統にしてコストダウンを図るだとか、情報量による区分け、バックアップ回線の持ち方など最近のネットワークサービスの多様化を利用して工夫するところでもある。今後は、テレビ会議システムなど音声やさらに動画が乗ってくると思われる。

サーバー／ストレージでは、集約と分散のバランスということになるが、集約には器の集約と場所の集約があり、その会社の環境条件やリソースで構成を決めていくことになる。ちょっと話はそれるが、ブレードサーバーが出現したとき、あれこれはプラント制御に使うコントロールステーションと同じではないのかと思ってしまった。分散計装の世界と事務処理システムとがだんだん近づいているように思える。

情報端末は、今後携帯電話がどのような形で企業情報システムに入ってきるのか、仕事する場所の概念が変わるかということも含めて興味があるところである。

五木寛之の「林住期」を読む。

古代インドでは、人生を四つに分けて「学生期」「家住期」「林住期」「遊行期」と呼ぶ。五木寛之は、人生１００年として２５年区切りでみると、５０歳から７５歳までが「林住期」にあたり、この期間こそ、人間の一生のなかでの絶頂期であり、黄金期、収穫期であると言っている。そして、５０歳でいったんリタイアすることを薦めている。

一般的な感覚では、５０歳までが人生の絶頂で其れから先は余生で人生のオマケのような捉えかたをしてしまうが、そうではなくて５０歳からは自分の本当に好きなこと、やりたいことをやることですばらしい人生となる。

意外だったのは、「林住期」を生きるためには、まず独りになることが必要だという。人間は元来群れをなして生きる存在で、夫婦、親子、家庭、地域、会社、クラブ、学友、師弟その他もろもろの人間関係が周囲にひしめいているが、その人脈、地脈を徐々に簡素化せよと説いている。自分ひとりで生きるために生きるということだろうが、ほんとうにできるだろうか、さびしくないだろうか、確かに最後は孤独の中で死んでいくのだと思うのだが。

５０歳から楽しもうと言われても、問題は人間のからだは５０年経てば“がた”がくるということだ。昔は人生５０年と言われていたわけだから、それを薬や医学が延ばしているだけで耐用年数は５０年なのではないか。いくらオーバーホールしても戻らないところが出てきて、若いときのようにはいかないのだ。

ぼくは５０歳をもうだいぶ越えて「林住期」真っ只中ですが、７５歳まで生き生きと過ごすなんて到底無理なような気がする。ただ、ぼくは昔から理想の死に方をひとに言いふらしていて、７０歳になってある朝孫がぼくの部屋を空けたら死んでいる、それを見て孫が「おじいちゃん、昨日まであんなに元気だったのに」という、そんな死に方が理想だと言っていた。で、この本を読んで「林住期」を何とか元気に乗り切って「遊行期」に入る直前の７５歳にぽっくり行くことをめざそうと考えている。

それにしても、「大河の一滴」で次のようなことを言っていた五木寛之がずいぶん変わったような気がする。

前向きに生きることは悪いことではない。プラス思考でおのれを励まし、人間性を信じ、世界の進歩を願い、ヒューマニズムと愛をかかげて積極的に生きることも立派な生き方である。
しかし、一方で現代の人間の存在そのものを悪と見て、そこから出発する生き方もあるのではないか。その真っ暗闇の虚空に、もし一条の光がさしこむのが見え、暖かな風が肌に触れるのを感じたとしたなら、それはすばらしい体験である。まさに奇蹟のような幸運であると思いたい。

人材育成・活用

いくらいいシステムを作っても、あるいはいくら素晴らしい体系を作っても、最後はヒトだといういうことを筆者の経験から言わざるをえない。従って、あえて人材育成・活用というタイトルで書かせてもらう。

会社で働く人には４つのタイプがあるように思う。能力が高くよく働くAタイプ、能力はそんなないが、言われたことは確実にこなすBタイプ、能力はあるのだけれど自分の気に入ったことしかやらないCタイプ、能力もやる気もないDタイプである。これは、よく言われる２：６：２の法則に近いのだけれど、その６の中に２つのタイプがあるのではないのかというのがここのポイントです。人材育成は、B、C、Dタイプの人間をどうやってAタイプにもっていくかになる。

まず、Dの人間をCかBにするわけだが、Cにするのはなかなか難しい。たまに、ユーザ部門でふてくされていてIS部門に来たがITを勉強し出したらすごい早さで習熟してしまったなんて人がいないことはないが、やはりITスキルは専門性が高いのでハードルが高い。現実的には、何とかうまく指導してBタイプにもって行くことになる。

CタイプをAに持っていくには、いろんなインセンティブでやる気を起させることだ。報酬もそうだが、いわゆるギークに近いので名誉だとか、外部で発表させるだとかそういったインセンティブも有効かもしれない。

結局、創造的な仕事はAタイプにやらせ、そこでできた成果物を使って多少のカスタマイズや運用・保守をBタイプにやらせるという棲み分けが必要ではないでしょうか。そして、いかにDタイプの人間を減らせるのか、Cタイプの人間を早く戦力化できるのかで総合力を上げていくのが望ましい姿となる。

こうした人材育成・活用には、ベースとなるのがスキル・キャリアマップである。ITSS（ITスキルスタンダード）があるのでそれを参考に自社独自のキャリアパスとそれに必要なスキルをマッピングする。そのまえに、意外とやられていないのが現状の保有技術の棚卸ではないでしょうか。やはり、現有リソースとレベルが把握できてこそ、これからどういう人材を育成するのかが決まってくるので重要な作業である。

いずれにしろ、ヒトが能力を高め、稼働率をあげるには、それ相応のモチベーションを与えることに尽きる。そのためには、組織として、個人として、それぞれの達成目標と役割を明確に示し、気持ちよく働ける環境をみんなで作り出し、結果を正当に評価するというシステムを機能させることが大切である。

情報子会社のありかた

企業はIS部門を社内に抱え込むのか分社化するのかという選択がある。情報システム部門を分社化するのは、少し波があって最初の波は多角化の一貫として情報会社を作るというのがあった。ですから、このときは外販主体で外で稼いでこいよという形態だった。

そのあとの波は、選択と集中の動きの中でコアコンピタンスではない事業や機能は売却したり、分社化したりした結果、情報子会社ができたケースである。前者の場合は、まだ本体のなかにIS部門を残し、本体業務はそこでやっているという形態も多く、中途半端になっていてそこを整理する動きもある。

情報子会社がめざすところはおおかたは外販比率を高くし、収益性のある、親会社から自立した会社になることだが、これが難しい。外販比率を上げるすなわち親会社依存率を下げていくと必ず収益性悪化の谷に落ち込む。そうですよね、外販するためには売上が上がらない中、教育投資やリソースの確保などコストがアップするわけだから、当然収益があがらないことになる。この谷を越えられるかどうかが大きな試練になる。

そこが難しいとなると親会社べったりの経営になるが、そこはコスト優先だから人件費を下げなくてはならない。ところが、それじゃ人員を親会社に帰すかとなると、分社化の意図と矛盾するというジレンマを抱えている。従って、分社化したのならやはり外販をしていくことをめざさない限り存在価値はないように思える。

ところが、外販に向かうにしても、親と子のめざすところや思いが微妙にずれていることが多い。親の第一の望みはコストダウンだ。子としてはコストの多くが人件費だから人員を減らしたいが、さっき言ったように親会社が引き取ってくれるわけではないから、余った人員を外販にまわそうとする、しかし外販するには優秀な人材を投入せざるを得なくなる。

だから、優秀な人材を外販にまわし、そうでない人員を本体向けに残して置くことになる。そうなると親からの声は、内へのサービスを質を落としてまでも外販するなとなる。さあどうしよう。

ここをうまく突き抜けないと自立した情報会社になれないのだ。

おろおろしてもしょうがないので、がんばって戦略をたてなくてはいけないのが、もう少し本質的なところ、もっと会社としての基本的な問題のところを議論する必要があるのではないだろうか。すなわち、外販だろうが内販だろうがまず何を売るのかということがある。サービスなのかソリューションなのか技術なのか単にプロダクトを売るのか、こうした事業ドメインの定義が重要である。

情報子会社の問題は最初から親会社へのサービス提供がありきから始まってしまい、そのモデルをそのまま使をうとするところに無理があるのではないでしょうか。ですから、親会社以外へどういう商品を揃え、どういうビジネスを展開するのかという戦略を描くことがもっとも大事であり、そこが大きな課題となろう。

全く新たに起業することを考えた場合、会社というのは本来売りたいものがあり、それを作れるひとがいて、それを売って儲けたいひとがいて成り立つのですが、情報子会社の場合は、そういう能動的なひとが少なくほとんどが親会社から行けと命令されたからしかたなしに移ったとういうひとたちが多いようです。従って、ひとの意識の問題とともにどうしたら起業プロセスを持ち込めるかが大事な要素ではないでしょうか。挑戦より堅実、変化より安定といった志向のうちは基本構造問題は永遠の課題になってしまうでしょう。

また、ユーザ系会社は業務知識が売りみたいなことですが、それなら業務要件に合ったソフトウエア、プラットフォームなどをなぜ提案できないのか。いまはほとんどソフトベンダーが作ったＥＲＰやパッケージに振り回されて、それをどう使いこなすかが問われています。これっておかしいわけで、ひとつには情報子会社がアイデアを出せない、コンセプトを作れないことなのでしょう。本当にその会社の経営に貢献できる情報システムを作れるのは本来その会社にいる（いた）人間ができなければいけないのではないでしょうか。

ですから期待を込めて情報子会社が主導権をとり、既存のSIerの地位を奪い取るくらいの覚悟でやることが、自立した情報会社になる道ではないかと思う。

この連載はこれで最後になるが、今回は比較的図を入れるようにしましたが、わかりやすかったでしょうか。

また、企業情報システムの美しいかたちは見えてきだでしょうか。結局、この美しいかたちを作るのもヒトです。そのヒトが企業の業務機能やプロセスを俯瞰できる目があり、それらの本質を見極めてシステムに落としこめるかが勝負です。

そのとき、ここでもやはり「ユーザ目線」ということが非常に重要なキーワードになるといえます。

ぼくは、ほとんど毎日決まった人たちのブログを読む。その中には梅田望夫、茂木健一郎、内田樹、高城剛やそのほかIT関連のひとたちがいる。RSSリーダに入れているので毎日それを開いて更新されたブログ記事を読むという算段だ。全部読むとかなり時間をとるのでしんどいのですが追っかけ出すとやめられない。でも、それでかなりの情報が入ってくるので昔に比べれば格段に効率的である。

同じようなことが、いま読み終えた「フューチャリスト宣言」（梅田望夫、茂木健一郎　ちくま新書）にも書いてある。この二人のブログを毎日読んでいるので、この本の中で語っていることはおおかた予想できることでもあり、二人のベクトルも似通っていることもわかっているので、そう驚きや感動はなかったのだけれど、それでも改めて未来志向の楽観主義には敬意を表する。ぼくは、梅田さんの「ウエブ進化論」からそうだけど、９９％賛同する。茂木さんの考え方にもちょっと難しいけど好ましく思っている。そんな二人の対談だから、もうそうだそうだとうなづくばかりである。そのなかでも特に感心したとうなところを抜いてみる。

「茂木」　アメリカには、日本では評価されないし頭角を現しづらいタイプの人、つまりビジョナリーがいますよね。自分ではすべてをこなすわけではないけれど、ビジョンを示す。

「梅田」　自分では手を動かさなくても、駄目なものは駄目と言って、きちんと方向性を示して全体を動かしていくタイプの人はいますね。日本の現場主義はこういうタイプを嫌う傾向にあります。

「梅田」　バックアップ体制と言ったときに、官僚的なロジックでお金をいくらいくら出して、というのは全然だめで、本当に必要なバックアップ体制って、社会における精神なんですよね。欠点を含む小さな芽に対して「良き大人の態度」がとれるかどうかということ。ここがいちばんのボトルネックです。日本は新しいことをやった人を賞賛しないですね。それが根源的にまずい。新しいことをはじめると最初は不安だし、何か既存のやり方や既得権にさわっていくという直感から、危険性をまず指摘する。それがよくない。日本はその度合いが強いです。

「茂木」　　ネットってそれぞれの人の倫理観が試されているような気がしますね。ブログの書き方ひとつにしても気を遣う。僕の倫理観としては、基本的にポジティブな気持ちを広げる感じにしたい。イヤなことは書かない。

「梅田」　ブログは教育メディアと限定されるわけじゃないし、自己表現でもあるけれど、若い人がそれを読んで勉強する、という意味が大きいと思います。結局教育って、ポジティブなものを与えるということ以外に何の意味もない。

「茂木」　ポジティブなビジョンを与えること以外に教育はない。梅田さんと同じことをシリコンバレーの人は言うでしょう。でも日本はネガティブな人が本当に多い。僕も梅田さんもそういう意味では孤立しているなあと時々感じる。

まだまだ書きたいことがいっぱいあるが、本の中味を全部ばらすようなことになるのでこれくらいにするが、１％注文があって、特に梅田さんにだけど、若いひとにみんなとんがれとか意識を変えろとか挑発的な言葉を発している傍らに、そうは言っても能力がなかったり、楽観的にはなれない人たちに対しても暖かいまなざしを持っていてほしいと思う。

最後に、この本は「若い人たちに希望と勇気を与えたい」と書いていたが、全くその通りだと思うと同時に、若い人に限らずぼくらのおじさんたちにもあてはまると思う。そう思うような人間だったら「フューチャリスト同盟」に入れてくれますよね。

最近良くないことばかりが続いていて滅入っているんだけど、こういう時って今は運気がないとか、寝ている方角が悪いんじゃないかとか、ついそんなところに逃げ込みたくなる。だから、占いとかスピリチュアルだと�