update it, Inc.社長のブログ

最近家でもcrossnoteを使っています。crossnoteはご存知（？）ネットワークワープロなのですが、Eclipse Rich Client Platformという技術をベースに開発しているので、たとえネットワークがつながっていなくても利用することが可能です。またインターネットさえ使えれば、サーバにドキュメントを保存できるだけでなく、他の人とドキュメントを共有し、他の人が行った修正内容を確認したり、履歴管理したり、などといったことができます。

なので、crossnoteを使うと家からでも問題なく使えます。ノートPCでの利用にも便利です。

１つ制約事項として、会社のPCと自分の家のPCなどのように、異なるPCにおいて同じユーザIDで共有することは「お勧めしていません」。サーバとクライアントPC内では常に同期が取れた状態を維持する必要があり、同期がずれている状態だと自動的にその同期を合わせる機能があります。別のPCで修正して、修正点をアップデートしないまま同じユーザIDを使って他のPCでログインしてしまうと、元のPCに戻ってログインした直後に同期処理が実行され、アップデートしていなかった修正内容が消えてしまうことになります。（ただし、明示的に終了前にアップデートしておけば、修正内容は消えません）

ということで、会社と家で、別々のPCでドキュメント共有を実現したい場合には、別々のユーザIDを利用してください。

Googleなどには自動翻訳してくれる仕組みがあります。私もよくお世話になっているのですが、実にすごい仕組みですね。

以前SwingUnitの開発でブログを書いていたときに、外国人の方でその日本語で書かれたブログを読んでいたという人がいました。なんとGoogleで自動翻訳して読んでいたそうです。今の人にとっては当たり前に近いことなのかもしれませんが、私は非常に驚いた記憶があります。

本来、言葉の壁というのは非常に大きいものです。日本のIT産業は見えざる参入障壁に守られている、という話がありますが、まさにこの「言葉の壁」に守られているということなのだと思います。（それ以外にも文化的な違いから起こる壁もありますが…）　自動翻訳はその壁を突き崩す可能性を持っているのだと思います。

自動翻訳は精度といった面でいうと、未だに変な結果になりがちですが、意味を理解するという観点でいうと、十分なレベルになってきているのではないでしょうか？　Googleは自動翻訳のAPIを公開しているという話を聞いたことがあります。可能であればそのうちcrossnoteにも自動翻訳機能を入れてみたいな、と密かに思っています。

（ついでに言うと、crossnoteは最初からオフショア開発での利用を前提に、プロジェクト内のメタ情報を2ヶ国語で保持する仕組みを持っています。）

以前、crossnoteはネットワーク・ワープロという言い方でどうでしょうか？というのを書きましたが、似たような言葉にオンライン・ワープロというのがあります。こちらは既にある程度一般化している言葉で、相当するものに例えばGoogle Docs & SpreadsheetsやZoho Writer, Think Free Officeなどといった、Web2.0系のオフィスソフトがその代表格となっています。

crossnoteもSaaS的に利用するという観点でオンライン・ワープロの一種と言えると思います。一方で、ネットワーク・ワープロという名前は「通信機能の付いたワープロのように聞こえる（弊社関係者）」という声もあり、オンライン・ワープロと名乗ってしまったほうが良いのか、ちょっと悩みどころです。

ただ、crossnoteは上記のようなオンライン・ワープロとはだいぶ性格が異なっています。どのように違うのかをまとめてみましょう。

１．表現力の違い
オンライン・ワープロの場合、要素技術としてAjaxを使っています。このためと考えられますが、図形編集の機能が弱く、貼り付けることはできるものの、ワープロ上で直接図を編集することはできないものが多いようです。
crossnoteはRich Client技術(RCP)を用いているので、例えばシステムの設計書などで必要なレベルの、そこそこの図であれば十分に書くことができます。また紙に印刷したときにも十分な品質のドキュメントとして利用できるように、表紙や目次を付け、ヘッダやフッダなどがきちんとセットされた、ページを意識したドキュメントを書くことができます。

２．オフラインではどうか？
やはりAjaxをベースとしているための制約ですが、オンライン・ワープロというだけのことはあり、オフラインでは使えません。（ただしGoogle Docsなどは今後オフラインでも使えるようになっていくようですが）
オフラインで使えない場合、例えばネットワーク障害があったり、サーバ側のトラブルがあるときには一切利用できなくなってしまうのですが、crossnoteの場合、オフラインモードがあり、かつドキュメントは手元にあるので、ネットワーク障害があっても、またサーバ側でトラブルがあっても、ドキュメントを読んだり修正したりすることができます。

３．プロジェクト向けか？
オンライン・ワープロの場合、個人でアカウントを取得して、みんなで利用する場合には個別に招待する、という方式をとっているところが多いようです。プロジェクトという単位での管理手段は提供されていません。
crossnoteははじめからプロジェクト内での利用を前提とした仕組みとなっており、プロジェクト内の管理者がユーザIDやプロジェクトの管理を行い、プロジェクト内のメタ情報などを一元的に管理する仕組みとなっています。

４．ドキュメント共有の方法の違い
オンライン・ワープロもcrossnoteもドキュメント共有が可能ですが、crossnoteは、変更差分管理の機能が特に強化されています。前回アップデートしてからの変更点が通知されるのはもちろんののこと、その単位で履歴管理されますので、過去にさかのぼってバージョン間の比較が可能になっています。このため、ある部分を誰がいつ、何のために、どのように変更したのか、といったことが簡単にわかるようになっています。

会社を起業するときとか、他の人に自分のビジネスモデルを説明する際には、事業計画書が必要になります。金融機関からお金を借りる場合には当然ですが、そうではない場合でも事業計画書を作っておけば、自分の考えを整理し、事前にビジネスのリスクを分析しておき、早め早めに手を打つことが可能になります。

そして、会社を起こした後でも事業計画書は適宜更新していくと良いようです。そうすることで当初の予定と現在の状態を比較し、見直すいい機会になります。

実は今、まさにその事業計画書を現状に合わせてアップデート中なのですが、当初の事業計画と比較すると、リリース予定が1ヶ月半延びたのを再度認識しました。

見積もりが甘い、ということなのですが、そもそもやろうとしていることが大きすぎて、通常のやり方では現状のupdate it, Inc.の陣容では出来る内容ではありませんでした。crossnoteを作り上げるというのはProject X的なプロジェクトだったので、はじめからこのようなブレは想定済で、良くここまでたどり着けたな、と思っています。

なんとか「もの」は出来てきたのですが、この事業計画書のストーリーの中では、これはちょうど折り返し点に来たに過ぎません。気を引き締めて、後半戦に臨みたいと思います。

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