update it, Inc.社長のブログ

昨日のIT Mediaで「発注者ビューガイドライン」が紹介されていました。「システムの作り直しをなくしたい」――SIer9社がガイドライン公開

まだ全部を読んではいませんが、なかなかの力作です。というか分量がかなり多いです。想定する読み手が

■ 情報システム開発を請け負う側である、SIベンダの従事者

■ 情報システム開発を発注する側である、ユーザ企業の情報システム部門、および業務部門の各ユーザ

となっているのですが、SIベンダの従事者はわかるとして、ユーザ企業側の特に業務部門の各ユーザがこれを見て、果たして分かるかなぁ？　という感じがしました。

おそらく書いてある内容が、SIベンダの視点で書かれているからだと思います。実際外部仕様書を書くベンダ側という観点では、気をつけるべきチェックポイントがいろいろと具体的に書いてあり、とても良い資料のように思えます。でも発注者側の、特に業務部門のユーザがここに書いていることをきちんと理解できるまでにはだいぶ時間がかかるように思えますし、もし理解した暁には十分システムの上流工程設計で飯を食っていけるようなレベルになっているようにも思えます。

とはいえ、きちっとやりたいと考えているユーザにとっては（どの程度いるのかはわかりませんが）なかなか良い資料なのかもしれませんね。

エクストリーム・プログラミング(XP)で有名なケント・ベックの書いた本「Extreme Programming Explained – Embrace Change」のEmbrace Changeの日本語訳として有名な「変化を抱擁せよ」ですが、現実のシステム開発の現場ではどの程度「変化を抱擁」できているのでしょうか？　現実問題として大きなプロジェクトの場合、「変化を抱擁」して失敗した、という例も多いため、できるだけ変化しないで済むようにコントロールすることが多いと思います。

変化を受け入れるためには、できるだけ小さい単位で「完結」していることが重要です。その単位で完結していれば、完結する範囲では変化を固定することができます。一旦完結した後で、次回（次のイテレーション）で次の変化を取り入れればよいのです。逆にいうと、完結していない単位でいろいろと変化を抱擁してしまうと、収束しない、デスマーチ状態になりがちです。

大きなプロジェクトの場合、それを細かい単位で完結するようにするように進めるのはなかなか難しい部分も多いと思います。だからどうしても長めの時間が固定されることになる。これはある程度仕方がないことだと思います。

それでもやはり、できるだけ細かい単位で分けられるような構造にして、それぞれがイテレーションの1単位として完結できるようにすべきでしょう。そのような形にすれば、プロジェクト管理の観点からも非常に望ましい結果を得られると思います。

細かいイテレーションの単位に分解した場合、その当初「どういう仕様にしたのか」をきっちり管理することが必要です。ベースライン管理ですね。イテレーションを基準としたベースライン管理がきちんと出来ていることが「変化を抱擁する」ための最低条件だと思います。

ということで、ベースライン管理にはcrossnoteをどうぞ。（なんだ、結局宣伝か。）  😀

今月の日経新聞の「私の履歴書」は住生活グループ（トステムとかINAXなどの持ち株会社）の前会長の潮田健次郎さんが書いていらっしゃいます。非常に興味深く読ませていただいているのですが、特に他社との差別化にこだわったという辺りが、成功の鍵だったのだと強く印象付けられました。

今日（17回目）の話に中空構造の形材を使ったアルミサッシの話が載っています。アルミサッシのメーカーとしてはトステムは後発で、しかも当時はまだ中小メーカーだったころで、市場には既に大手メーカーがいたそうです。それにも関わらず後発のトステムが勝ち残っていったのは、中空構造の形材のために他社の製品に比べて強度があり、しっかりしていたこと、そして密閉性に優れていたことなど、他社との差別化をしっかりはかっていたからだと思われます。

そしてその差別化したことを営業担当者が売り込みにおいて、とても分かりやすくデモをして見せた、ということも大きな要因だったようです。商品に差別化を図り、その違いをはっきりアピールすること。とても大切なことだと感じました。

では、当社のcrossnoteはどうかというと、もちろん差別化を図っているつもりなのですが、まだまだアピールの仕方がだめというか、こちらが差別化したつもりの部分がきちんと伝わらないことが多いと感じています。「差別化の見せ方」の問題ではないかと。

トステムは自社のアルミサッシの良さを、大手の先発メーカーのサッシと並べて実際に勢い良くホースで水をかけて実験して見せて、密閉性の良さをアピールしたと書いてあります。できるだけ分かりやすい方法で、差別化のポイントをアピールできること、このことが非常に重要なのだと感じました。

このブログを開始して今日がちょうど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を試してみる」

ぜひご覧ください。