update it, Inc.社長のブログ

このブログを開始して今日がちょうど1周年です。月日がたつのは早いものです。ちなみに1年前の開始したときのブログがこれです。

このブログを立ち上げた当時はまだホームページも用意していませんでした。ちなみに1年前のこのころはcrossnoteの開発真っ最中で、差分抽出のロジックやエディタの基本部分などを作っていました。私自身もバリバリ作っていましたよ。（最近私自身がコーディングするのはを止められていますが）　crossnoteという名前はまだ無く、APISというコードネームで呼んでいました。

以前のブログを振り返るといろいろ写真が入っていたことに気づきます。これらの写真は社員の人が撮ってくれたのを載せていたのですが、最近忙しかったのと寒かったということで、昨年の秋ごろを最後に撮っていませんでした。そろそろいい季節になってきたので、写真も入ってくることでしょう > 担当者さん

このブログを見てくださっている方々、本当にありがとうございます。また、ぜひ気軽にいろいろとコメントをいただけるとうれしいです。これからもよろしくお願いいたします。

昨日、ノークリサーチからSaaS市場の実態と中期予測調査報告というプレスリリースが出ています。それによると、今年2008年の市場規模換算は「ソフトウェア＋サービス」は約8兆6百億円のうち417億円（0.5％）で、2008年の予測は約860億円だそうです。また「SaaS型ソフトウェア開発と普及、ユーザのSaaS利用への心理的ハードルの突破には最低5年はかかる」としています。

たった0.5%。

少ないですね。それにまだキラーコンテンツが無いため、一般に根付くのに最低5年はかかる、という予測になっています。

ただよく読んでみると、技術的に自然にその方向に向かっていくだろう、ということと、カスタマイズしない、作りこまずに業務に適合させるというのがITの理想像であるとしています。私的にはまさに「その通り！」って感じです。

市場における割合からすると、SaaS市場は今はまだ、商品ライフサイクルにおける「導入期」に過ぎないといえます。マーケットにおける強者からすると、いま敢えて参入する必要はない段階だといえます。一方で当社のような弱者の中小企業からすると、まさにこういうところがチャンスなのだと思います。（竹田陽一先生のランチェスター経営で考えた場合）　今は足場を固める時期なのだと考えています。

昨日のブログ東証のトラブルは取引集中のため？で「原因が同じ証券会社からの複数銘柄の一括注文（バスケット取引）が短時間に集中し、あらかじめ設定していた注文処理の制限回数を超えたことによるものだったと東証が発表しているようです」と書いたのですが、タイトルにも？を入れていたように、どうも変な説明だと思っていたら、やっぱりちょっと違うようで、書き込みロックのリトライ回数の制限回数を超えたために処理を停止した、ということのようです。

ただ、この説明のニュースで、「デッドロック」のためにという説明がされているのを見つけたのですが、上記の話であれば、これはいわゆるデッドロックではないのでは？と思うのですが、どうなのでしょう？

デッドロックは2つの処理間で互いに依存関係があり、互いに相手のロックの解放待ちになった状態を指します。一度この状態になると、デッドロック監視の仕組みが強制的に処理を止めたり、タイムアウトを発生させてデッドロックを解消させることになるはずです。ニュースの説明では、「登録の再試行を繰り返し、それが設定数の100回を超えたので『デッドロック』した」、と書いてあったのですが、本来デットロックに陥った場合には試行回数をいくら増やしてもロックは開放されません。ある意味、もしこれが本当に設定回数でロックを開放しているのだとしたら、それは本来のデットロックを開放する仕組みとしては正しい動きをしていることになります。

つまり、もし本当にデッドロックが発生したとすると、おそらく設定が問題なのではなく、デッドロックが発生するアルゴリズムに問題があった、ということになるはずです。ところが「東証は、登録の再試行の回数を無制限に変更するなどしてシステムを修復」と報じられているところをみると、アルゴリズムの問題ではなく、単に想定外の大量処理によりI/O待ちが長くなり、リトライ回数が足りなくて処理が停止した、というのが真相のようで、そうだとするとやっぱりデッドロックじゃないんじゃない？と思うんです。

ま、重箱の隅をつつくような話ですね。

昨日、東京証券取引所で株式売買システムの障害で2銘柄の午前の売買を停止したというニュースが流れていましたが、その原因が同じ証券会社からの複数銘柄の一括注文（バスケット取引）が短時間に集中し、あらかじめ設定していた注文処理の制限回数を超えたことによるものだったと東証が発表しているようです。

システムに処理する上限があるのは仕方がないのですが、設定数を超えた場合に停止するという設計はいかがなものでしょうか？　処理上限を超えた量の場合には遅延が発生します、という設計にすべきだったのでは？と思うのは私だけ？

この辺りは要求仕様レベルで予め決めておくべき事項だと思うのですが、もし検討された結果、処理上限を上回った際には止める、という決定をしていたとしたら、？な感じがします。

むしろ要求仕様レベルでは明記されていなかったので、システム開発側で「気を利かせて」そのような制限を付けた？ということも考えられなくはないですが…

しかしこの手のシビアなシステムの場合、要件定義（特に非機能要件）が非常に難しいですね。

今日、ブログを書いていたのですが、ブラウザを何気なくリロードしてしまい、下書きとして保存し忘れていたため、全て消えてしまいました。  😯

ま、当たり前なのですが、Webってリロードするとすっかり消えちゃうんですよね。怖いです。

ちなみにGoogle Appsはリロードしたりページをクローズしようとすると、警告ダイアログが出るようです。他のWebアプリもこのぐらいのことはして欲しいですね。（かなり負け惜しみ）

米国ではOffice 2.0と呼ばれるコラボレーションを重視したワープロやスプレッドシートなどのオフィスソフトがいろいろと出てきています。それらは特徴としてはAjaxやFlashを使ったWebベースで作られていて、すぐに使いはじめることができること、そしてその割にはユーザインターフェースが良いことを売りにしています。またWebベースなので、インターネットさえあればどこでも使えるというクラウド・コンピューティングを謳うものも多いです。

でもそういったOffice 2.0系ソフトも結局のところ、既存のオフィスソフトの機能をWeb上で実現しました、というものばかりです。だから既にMS Officeを持っている人からすれば、それで何が新たにできるようになるのか、と感じてしまうのではないでしょうか？　しかもAjax系のオフィスソフトの場合、直接図形編集ができないなど、実際のビジネスの現場で使うには制約があるものも多いです。

crossnoteも、ぱっと見にはOffice 2.0系ソフトとして捉えられるかもしれません。（一応言っておきますが、crossnoteは直接図形編集ができます）　でも私はcrossnoteは Office 2.0とは次元の異なる、Office 3.0系として考えています。その違いは、crossnoteの目標はワープロとメールの垣根を取り払うことだからです。

少し前のブログフロー/ストックで、crossnoteはメールやメッセンジャーのようなフロー型ツールと、文書管理ソフトのようなストック型ツールの両方の特徴を兼ね備えている、という話を書きました。それは相手に自分修正した差分を送り付けあうことで、ストックとしてのドキュメントを修正するだけでフローとしての知識の共有を実現できるからです。

もちろんフローとしてのやり取りの中では「考え方」や「気持ち」など、ドキュメントには記述したくないことをやり取りする必要もあります。その場合にはコメントを送りあうことで、メールのようなやり取りだけをすることもできるのです。

crossnoteのドキュメントの中の変更されたところだけを通知する仕組みは、メールにドキュメントを添付したりリンクを書いて「これ（全部）見てね」というやり方とは根本的に違い、相手に変更点を確実に伝えることができるものです。なので、私はcrossnoteは既存のオフィスソフトを単にWebにしたOffice 2.0ではなく、まったく新しいOffice 3.0だ、と「勝手に」主張させていただきます。  😀

昨日、マイコミジャーナルにcrossnoteのレビュー記事が掲載されました。

「ドキュメントを共同編集! – オンラインワープロcrossnoteを試してみる」

ぜひご覧ください。

ITPro Watcherにある田中克己さんの黒船の大砲がソフト業界に構造改革を迫るを読みました。今の日本のソフト産業がオーダーメイドによる開発ばかりで、同じようなシステムをあちこちで開発するというムダを続けてきたが、いずれ外国のソフト企業に市場を奪われたり、中国やインドのソフト企業に買収されてしまうのではないか、という話です。

確かに今の日本のソフト産業は世界的に見て、ほぼ内需だけで成り立っているという、かなり特殊な状況です。私も「黒船の大砲」がきたらひとたまりもないのではないか、と非常に危機感を覚えています。

この記事の中では自動車産業のように専門部品を作るソフト部品会社とシステムインテグレータと呼ぶシステム組み立て会社に分業化という「近代化」が必要だと説いているのですが、ちなみにこの記事に「ひがやすを」さんが噛み付いているようです。SIerが自動車産業をまねしようとするのはいい加減やめなさいによると、「ひがやすを」さんは真っ向から反論して、

–以下引用–
『SIにあてはめると、外部設計を作り続ける会社、内部設計を作り続ける会社、プログラムを作り続ける会社に分業化するってことでしょ。今と一緒ジャン。そして、インテグレータが上澄みをはねていくと。』
–ここまで–

と言っています。プログラムは「異なるもの」を製造することに意味があり、そういう観点からは同じような部品を作り続ける、というような製造業とは単純に対比できないわけで、これはこれでなるほど、です。

私はというと、上記の二人とはまた別の観点を持っています。ソフト業界の近代化というのは、ソフトウェアを「個別には作らない」方向に進むべきなのでは、ということです。オーダーメイドを減らしていくべきだ、と。前述のような議論が起きるのは、おそらく日本のソフト業界がオーダーメイドにどっぷり浸っているからで、ソフト業界はソフトウェアを作るのが仕事だ、となってしまっているからではないでしょうか？

私は、ソフト企業はこれからソフトをサービスするのが仕事、というように徐々に変わるべきではないのか？と思うのです。もちろん、真のサービスの部分は最高のものを作り上げ、改良し続けます。でもそれ以外の部分は、エンドユーザが使いやすいように組み合わせたり、ちょっとだけ手直しをするだけにして、極力個別には作らない。こうしていかないと海外の巨大なパッケージベンダーに勝てるわけがありません。

サービスする単位としては今までのパッケージという単位は当然のこととして、もっと細かい粒度でのサービスとして提供する、という方法も考えられるわけです。この世界では細かい粒度のサービスを提供する側も、けっして下請けではなく、全体のインテグレータと同等にサービスを提供する、という世界が考えられます。

ソフト企業は製造業からサービス業へ。このパラダイムシフトがないと日本のソフト産業は将来、簡単に乗っ取られてしまうのではないかと私は考えています。

CNET-JapanにEメールに関する興味深い記事が出ていました。「電子メールに未来はない」–米国のウェブ専門家らが指摘というタイトルで、Future of Web Apps（FOWA）カンファレンスで電子メールに関する議論において、出席者からメールはもはや時代遅れで、後進的で、誰もが嫌っている、という厳しい意見が相次いだ、と報告しています。

読んでみると、問題はやはり膨大な量の「スパムメール」に集約されるようです。でも一方で、記事の終わりのほうでは新興のWeb2.0系のメッセージング機能に関する不安についても触れています。

Eメールは非常にシンプルな仕組みだし、ビジネス的にも欠かせない道具だし、これだけ普及したということもあり、なかなかこれに代わるものが現れるとは私には思えないのですが、一方で既存のEメールに不満を持っているのも確かです。

というのは、送ったEメールが相手に届いているのかどうか、読んでもらえたのかどうかが怪しいと感じることが最近良くあるからです。スパム対策でフィルタリングしていることが多いと思いますが、送ったメールが誤ってフィルタリングされている場合もあるんじゃないの？　と疑心暗鬼になります。またスパム扱いされていなくても、大量のメールをやり取りしていると、見落としてしまうことも多々あるように思えます。

メールというのは基本的にはプッシュ型のコミュニケーションツールです。ところがプッシュ型が有効なのは、そこに表示される情報量が少ない場合で、膨大な量の情報がプッシュされた場合には役に立ちません。膨大な量の情報に対しては、プル型、つまり自分が関心のあるデータをピックアップするモデルでないと回らないのです。

メールで日ごろやり取りされるデータが膨大だったり、スパムメールに埋もれてしまっていたりすると、プッシュ型のツールだったメールをプル型として使わざるを得なくなり、結果として伝えるべき情報が伝わらない、という現象が起きるのではないかと思います。

メールの本来もっとも重要な点は、確実にプッシュできる、ということだと思います。メールの未来は、この「どうすれば重要な情報を確実にプッシュできるか」という点に絞って進化できるかどうかにかかっているのではないでしょうか？

金曜日にある勉強会に出ていたのですが、その会ではコーディング規約が守られないのを如何に守ってもらうか、という話をしていました。（趣旨としては「ある特定の条件において」なのですが、その話はいろいろあるので省きます）

そもそもコーディング規約は何のためにあるのでしょうか？　Sun Microsystems社のJava言語のコーディング規約の「コーディング規約の必要性」には以下のようなことが書いてあります。

— 以下、引用–
・ソフトウェアの生存期間におけるコストは、その80%が保守に費やされる。
・ソフトウェアの保守が最初から最後まで元の制作者によって行われることは、ほとんどない。
・コーディング規則は、エンジニアが新しく目にするコードをすばやく完全に理解できるようにして、ソフトウェアの可読性を向上させる。
・ソースコードをひとつの製品として出荷する場合、それがその他のすべての製品と同様にちゃんと梱包されていて、綺麗なものであることを確かめなければならない。
— ここまで —

つまり「ソースコードを誰にでも読みやすくするためのルール」がコーディング規約であるといえます。自分にとって読みやすいということではなく、誰にとっても読みやすいかどうか、です。

もし汚いコードを書いて、そのままにしてしまうと、それは当然、他の人にとって「読みにくい」コードであり、いわば負債を抱えた状態になります。後でそのコードに含まれたバグを取らなければならない人は非常に苦労することでしょう。

この考えからすると、独自のコーディングルールというのはこの精神からは外れたものだ、といえます。独自のコーディングルールは、そのルールに皆が慣れ親しんでいれば良いのですが、人材が動いたときにそのコーディングルールに慣れるまで余計な時間（＝コスト）が発生する、という問題があります。

C言語のように「何もない」場合にはいろいろと独自のルールを導入しなければならないかもしれませんが、JavaとかC#のような言語の場合、むしろできるだけ素な、元々の言語に用意されたコーディングルールをそのまま採用するというのが正しい戦略だと私は思います。