update it, Inc.社長のブログ

もう20年近く前の時代の話です（うーん、こういうとずいぶん昔に聞こえる…）。証券の分野でデリバティブが急速に普及してきた時期に、ニューヨークの金融街でデリバティブ・トレーディングを行うチームには一定のスタイルがありました。

それは、そのチームには、トレーダーと数学者とプログラマーが1セットになっていて、いずれも「あ、うん」の呼吸で仕事ができるようにすぐ近くで仕事をしていた、ということです。数学者がマーケットの歪を分析し、プログラマがそのリスク分析をするプログラムを書き、それを使ってトレーダーが実際にデリバティブを売買するのですが、互いに密に連携しあって仕事をしたほうが良いということで、机を並べあって仕事をしていました。

ちなみにその当時は、そのスタイルでトレーディングをして大儲けしていたようです。

私が当時いたところでも（日本ですが）、このスタイルを真似てやっていたところがあります。これって今にして思うと、XPスタイルなんですね。先日ある勉強会に行った時に話していたら、「それってXPですね」と言われて、おお、やっぱりそうか、とあらためて思いました。

純粋に、一番儲けるにはどうしたらいいかを考えた結果、XPスタイルになっていた、ということになります。現在のシステム開発はどうしてもエンドユーザから遠い位置で開発しがちですが、分野によってはこのように、エンドユーザと密になって開発するというスタイルももっとあっていいような気がしています。

ただ、ひとつ付け加えることとして、この立場で動けるプログラマというのはかなり高度な能力と、対象分野に対する専門性が必要で、かつ体力も要求される、ということは一応伝えておきます…

今日のZDNet Japanの記事に、ガートナーが昨日都内で行った「Gartner Symposium/ITxpo 2007」の基調講演で、松原榮一氏が「グーグルのサーバ数は日本の年間サーバ出荷台数より多い」と語った話が載っています。

すごいですね。すごすぎです。

でも実は私がもっとも敏感に反応したのは、このグーグルのサーバ数そのものではなく、以下のくだりの話です。

この話の冒頭に、「企業は海外との競争に巻き込まれていることを認識すべきだ。新興国が成長し、パワーバランスにも変化が起こっている」と述べられています。

少し前のブログで、日本のIT産業は研究投資していない、情報化投資していない、という話を書きましたが、海外の様子をいろいろ調べてみると、少なくともITの分野では日本はかなり遅れた国になりつつあるという現状が見えてくると思います。

問題だと感じるのは、当事者の日本国内のIT産業に携わる人達の中で、どれだけの人が危機感を抱いているのか、ということです。ITの世界は大掛かりな資金などなくとも、頭脳さえあれば十分に勝負できる世界です。資金力に限りのある新興国でもITの世界では十分に戦うことができるのです。今まで人海戦術でシステムを構築してきた日本のSIerは、このままでは「ゆでがえる」になるということを自覚すべきではないでしょうか？

2日前の「藍屋の白袴」のブログに対して「日本の場合、開発ベンダーはツール類を顧客指定（実態はＳＩｅｒの売ったもの）で対応するケースが多い」というコメントを頂きました。そういえば、受託開発において顧客側で全部買い揃えて開発するということも良くあります。日本のSIのお客さんは、何から何まで自前主義のところが多いのかもしれません。（でも開発そのものは自前ではないのですけどね）

こういったケースで問題になりがちなのが、そのような開発において自社ライブラリが利用できるのか、という件です。効率的に開発を進めるにはSIerが自社でライブラリを整備してそれを使うようにすべきですが、もしお客さん側から成果物全体についてのすべての権利を譲渡するように要求された場合には、ライブラリを使うことができなくなってしまいます。（もしそのような契約形態で自社ライブラリを使ってしまうと、そのライブラリは他のお客様のSI案件では使用できなくなる恐れがあります）

最近は使用許諾権のみをお客様に与え、プログラムの著作権や著作隣接権などは開発者側で保持するという契約形態が増えていると思いますが、まだまだ「金を出した側がすべてを所有する」という考えのお客様も多いと思います。でもそうすることで、IT業界全体が非効率で高コストなものとなっていたとしたら、それは結局のところお客様がそれを被ってしまっていることになるのです。

先日、ある技術系の勉強会に出席した後の懇親会で、日本のSIは必要以上に高コストになっている、と指摘されていた方がいらっしゃいました。もっとオープンソースなどを利用して安く提供できるようにすべきではないかと。

「金を出した側がすべてを所有する」という考えのお客様の場合には、自社ライブラリはおろか、オープンソースも利用できないのです。これでは非効率・高コストになってあたりまえなのだと思います。この考えから変えていかないと、日本のIT産業はなかなか浮かばれないのではないでしょうか？

今日は書く時間が取れないため、ブログを休みます。

今日のタイトルは「藍屋の白袴」としてみました。この「藍屋」の１つの例として、IT業界を取り上げてみたいと思います。

最近マーケティング資料を作っている中で、ちょっと驚きの数字を見つけました。

JISA(社団法人情報サービス産業協会）の出している統計で、2007年版情報サービス産業基本統計調査というのがあります。このなかで、売上高設備投資率・情報化投資率という項目があり、IT企業が売上高に対してどの程度の割合の金額を情報化投資に回しているのかについての統計が載っています。

グラフを見るとよくわかるのですが、IT企業のうち、売上高に対して情報化投資の金額の割合が「たった」0.5%未満しかない一番端の部分がもっとも山が大きくなっています。統計値で見ても中央値が0.63%、加重平均値で2.42%という結果です。ちなみに加重平均が中央値よりもだいぶ大きめになっているのは、がんばって情報化投資を行っているところもあって、そこが全体の水準を押し上げているのだと思われます。

この中央値が0.63%だ、という事実。これはあまりにも情けない水準だと思いませんか？　IT業界が業務の効率化のためのIT投資を行っていない、という事実なのです。実際、日本のIT業界は建設業界と同様に、人月単価の世界です。なので、生産性が上がれば収益が下がる、というトンでもない構造になっているのです。しかもそれでは付加価値はほとんどないため、収益率は非常に薄いものになってしまっていて、結局は自らの首を絞めてしまっているのです。

他の指標を見ても、売上高研究開発投資率に至っては中央値が0.06%、加重平均が1.15%という水準です。これでは日本がITにおいて世界の中で遅れた存在になってしまってもしょうがないことを裏付けている事実だと思うのです。

皆さんはこの事実をどう考えますか？

SaaSが進展してくると、システム開発会社からシステム提供会社への転換が起きる、という話を以前書きましたが、システム開発会社の進むべきもうひとつの道として、ファブレス化というのがあると思います。ファブレスとは設計やマーケティングに特化した、製造を持たない会社形態を指します。システム開発会社にもこういった、製造を行わないという方向に進むという選択肢があると思います。

つまり、上流工程に特化して、要求定義から仕様設計までを担当するような会社です。製造は製造に特化した会社=ファンドリに任せる、という考え方です。SaaSの世界ではファンドリに相当するのがシステム提供会社となると思います。

ファブレス型のシステム開発会社というのは実は既に存在しています。対象分野が特定の専門領域に特化していると、このようなファブレス化というのが行いやすいのだと思います。

ファブレス型のシステム開発会社の問題点として、仕様設計ばかりに特化してしまうと技術面が弱くなってしまいがちだ、という面があります。いわゆる「丸投げ」体質になってしまう、ということです。

しかしファブレス型だからといって技術面が劣ってよいわけはありません。ファンドリの能力を吟味しなければならないわけで、むしろファンドリよりも優れた技術能力や知識が要求されるはずです。

これからは、ファンドリ側にはSOAアーキテクチャでシステムを提供してもらい、それをファブレスのシステム開発会社側で「マッシュアップ」して提供する、という選択肢もあると思います。このやり方であればうまくコンポーネント単位での水平分業が進みますし、ファブレスはファブレスらしい付加価値を提供できるのではないでしょうか？

最近、システムの開発期間がどんどん短縮されてきているという話を良く聞きます。技術的要因としてはシステムの基本要素のコンポーネント化やライブラリー化が進んだこと、優れた統合開発環境が誰でも手に入りやすくなったこと、非技術的要因としては昨今の一般マーケットにおける商品サイクルの短縮化などにより、儲けるためには時間がかけられなくなってきているということ、などが理由でしょうか？

システムの開発期間が短くなっている、というのはほとんどの場合、開発の期間のことを指していると思います。設計期間が短いというのはおそらく、同じようなものを過去何度も作ってきているので、いちいち設計しなおす必要がない場合など、特殊な場合のみで、大規模な受託案件だと設計期間が長く、かつそれは開発期間に比べ、あまり短くなっていないと思います。

開発期間はできるだけ短く、という話になるのに、設計期間が短くならないのは、1つにはその仕様決め作業にユーザ側自身が関わっているため、無茶なスケジュールになりにくいということ、もうひとつには「考える」時間は短縮できない、ということがあると思います。

で、工数という観点で考えると、昔は設計工数に比べ、開発工数のほうが圧倒的に大きかったのですが、今は開発工数が期間が圧縮されて少なくなった分、設計工数の割合が大きくなってきているように感じます。設計工数の中にユーザ側の参加者の工数まで含んでしまうと、実はかなり大きな数字になっていたりしますよね。

システム開発というと開発のほうにばかり目が行きがちですが、全体の最適化という観点ではもう少し設計工程の効率化も検討していくべきだと思います。

フロントオフィス・システム（省略して、フロント・システム）とは主に金融系のシステムにおいて、収益に直接結びつく業務をサポートする領域をカバーするシステムのことを言います。一方、勘定などお金の管理などを行うシステムをバックオフィス・システム、リスクやコンプライアンスなどを担当する部分を、その中間をとってミドルオフィス・システムと呼んで区分けすることがあります。

私は以前、金融系のシステム・エンジニアだったのですが、その中でも主にフロント・システムの領域を担当していました。（なおミドルオフィス・システムも若干やっています）

このフロント・システムの領域はまさに時間との戦いなんです。マーケットで儲かる業務をサポートするためのシステムを出すということは、儲かり始める前にシステムを提供しなければなりません。いくら立派なシステムを提供したとしても、マーケットで儲からなくなってからでは遅いんです。

しかし皆さんもご存知のとおり、一般にシステムとは開発に時間がかかるものです。それを創意工夫によって、出来る限りの短時間で目的の業務をサポートするシステムを作り上げることが、フロント・システムには求められます。

最近のWebシステム系においても、ある意味非常に似た状況だということを聞いています。最近は、そもそも全般的にシステムの開発期間が短くなっており、昔のフロントシステムの開発と似たような状況になってきているのかもしれません。

フロント系システムを担当していたときに出した１つの答えは、まずはExcelと計算用のDLLなどを駆使して、なんとか業務をまわせるものを予め提供しておき、少し時間を稼いでいる間にきちんとしたものを仕上げて置き換える、というやり方でした。商売はまずは儲かってなんぼ、の世界です。厳格さが要求されるバックオフィス業務はさておき、フロントオフィス業務をサポートするためには機動力が重要なので、できるだけ柔軟性が要求されたのです。そのためにはExcelはまさに最高の道具でした。

最近EUCというとマイナスのイメージが強く、Excelが悪者のように言われることが多いですが、まずは商売は儲けられるようにすることが重要です。業務にもよりますが、特に柔軟性が要求される分野では、まだまだExcel君が活躍すべきではないでしょうか？

ちょっと前の「言葉の大切さ」というテーマで書いたブログで、crossnoteを一言で表すと何？というのを書きました。そのときには「共同作業のためのワープロ」と書いていたのですが、いろいろ考えた挙句、「ネットワーク・ワープロ」というのはどうか、と思いつきました。略すと「ネット・ワープロ」でしょうか？

なんかわかったようで実は良くわからない説明ですが、何かネットワークを使って皆で使うワープロだっていう感じは出ているのではないでしょうか？　じゃあネット・ワープロをもうちょっと説明すると、「変更したところを教え合うワープロ」だよ、ということになります。

ネット・ワープロ = crossnote、よろしくお願いします。

昔、プロジェクト・マネージャーの研修を受けたときに、顧客と「握る」ことの重要性を習ったことがあります。「握る」とは、私なりに解釈するならば、

１．システムの目的（何のためにやるものなのか）をはっきりさせ、
２．目的に沿った形で要件の大枠を固め、
３．要件の範囲内で十分であることを顧客側の実質的なヘッドに納得させる

行為です。最初に握れるかどうかがシステムの成否を決める、と教わりました。

今ASP（今流に言えばSaaSか）を扱っていますが、この「握る」という行為はASPやSaaSの場合、存在しないんですね。握る場合にはお客様の代表がいなければならないのですが、ASPやSaaSの場合、当然そのような方はいらっしゃいません。お客様は皆、お客様なわけで、ある客様との間で「握った」としても、他のお客様がそれで満足するとは限りません。

ASPやSaaSの場合、そこから収益が得られているならばどんどん改善していくことができるということ、そして対応する要件の優先順位の決定権が、最終的には提供する側にあるということが「握れない」ことへの代償といえましょう。

とはいえ、お客様からの要望は最優先ですね…