update it, Inc.社長のブログ

何事にも先人の知恵をうまく生かすことは重要です。ただ、先人の知恵を本当に理解するのがたやすくない場合も多々あります。そんな場合には、先人のたどった軌跡と同じ軌跡をあえて辿ってみることも有効なのだと思います。そうすることで、深い理解が得られ、さらにその上の世界が開けてくるからです。単にうわべだけの理解では得られない世界です。

アジャイルの世界で一時「守破離」という言葉が有名になっていました。

「守」とは師匠の教えを正確に、忠実に守る、学びの段階。

「破」とは、それをさらに洗練させ、自分なりのものを創造する段階。

「離」とは、独自の道を確立する段階。

フレームワークやライブラリーを扱う場合、通常は先人（作った人達）の教えに従い、それを使います。これは「守」の段階です。それを使いこなしていくうちに、徐々にその足りない部分を自分で改良して使うようになってきます。これは「破」の段階ですね。そしてそういった経験を経て、見えてきた問題点などを解決するための全く新しい仕組みを新たに創造する、それが「離」の段階なのだと思います。

早く「離」の境地にたどり着きたいものですが、でも「守」や「破」を経て、本当の問題点を良く理解しないことには「離」はできないのだと思います。そういった意味ではあえて先人の軌跡を辿ってみるのも、遠回りのようでいて、実はその道を極めるための最短コースなのかもしれません。

最近個人持ちのノートPCのセキュリティソフトを、広告の入る無料タイプのものに切り替えました。PCを起動すると、そのたびに広告が表示されるのですが、それ以外は普通のセキュリティソフトとして使用できるものです。セキュリティソフトとしての出来はそんなに悪くなく、使用感も上々です。

それまでは年額5,000円程度の金額を払ってセキュリティソフトを買っていたのですが、広告を見るという条件だけでそのコストを払わずに済む、というのはうれしい気がします。使い始めた頃に比べ、表示される広告の内容が増えているようにも思えます。ビジネスとしてはそれなりに順調に伸びているのかもしれません。

ただ、ふと、このビジネスモデルは本当に継続可能なのか？という疑問が沸いてきました。というのは、広告業は広告主がいて成り立つ商売です。もしいくつもの会社がおなじビジネスモデルで参入したとしたら、広告代金を払う側の広告主は増えないので、必然的に1社辺りの取り分は減ることになります。でももしこれが優れたビジネスモデルならば、皆が参入してくることでしょう。

これって、Consumer向けのIT産業のビジネスモデルのジレンマなのかもしれません。

最近の流れで、Consumer向けのITビジネスはいずれも広告モデルが主体となってきており、Consumerから直接お金を徴収するビジネスというのはあまり流行らなくなってきています。Consumerは当然安いほうがいいに決まっているので、自然にそちらに流れるのは理解できますが、全てがその方向の流れてしまうと、そもそもビジネスが成り立たなくなる場合が増えてしまうのではないでしょうか？

次の「新しい」ビジネス・モデルに期待、ということでしょうか？

今朝の日経新聞の1面に「ITシステム　ネットで提供　NTT、次世代網で」「安全性高く　企業向け年内参入」という記事がでかでかとでています。

「ITシステム　ネットで提供」とあるのは言わずもがなSaaSのことです。NTTではSaaSを事業として開始し、サーバーを置くデータセンターや認証・決済機能を整備するとのこと。国内外のソフト会社に呼びかけて…云々と書いてあります。NTTが乗り出すということであれば、SaaSの時代に一気に突入しそうですね。

ただちょっと解せなかったのが、なぜNGN（次世代網）でなければならないのか？という点です。まあ戦略上はわかりますが、NGNの場合、どこでも使えるというユキビタス性が確保できるのはいつになるのでしょうか？　また海外とのやり取りには使いにくい？　結局はインターネット経由になる？　疑問は尽きません。

昨日、車輪の再発明というブログを書きましたが、果たしてNGNは車輪なのでしょうか？　キャタピラなのでしょうか？
いずれにせよ非常に気になるニュースでした。

システムの世界では、既に存在するものを利用せずに、別途作ってしまうことを「車輪の再発明」と呼ぶことがあります。そんなの無駄だよね、という意味を込めて使います。過去の偉大なる発明をうまくりようすべきではないか、と。

確かに既にある機能を使ったほうがよいことが多いのは確かです。ですので、この言葉は良く肝に銘じておくべき言葉だと思います。しかし現実問題として、車輪の代わりにキャタピラが必要になるようなケースが多々あることが事態をややこしくします。

車輪を発明した時点ではそれでどこまでも行ける、と人々は思い込んでいるのですが、実際には舗装路しか走れないことにいずれ気づきます。ま、4WDにすれば悪路もへっちゃら、という話もありますが、さらに重いものを運ばなければならないとなると、いよいよ車輪では限界がきますよね。こうなると、ものを移動させるための方法としては車輪から離れなければならず、キャタピラが必要になってきます。

これは「車輪の再発明」ではなく、車輪では役に立たない場合に対する発明なので、意味があるのです。しかしこの見極めが非常に難しい。車輪を使いこなしている人であれば、「うーん、この目的であれば車輪でいけるけど、これ以上の場合には無理だな」ぐらいのことがすぐにわかりますが、普段車輪にあまり接していない人が同じような場面に遭遇した場合、簡単には判断が付きません。

おそらく「車輪の再発明」されるのは、こういう場合なのではないでしょうか？　結局のところ、「車輪の再発明」なのか、「キャタピラを創造したのか」はある程度後になって振り返ってみてから判明することがほとんどなのだと思います。

SaaS型のアプリケーションの運用において、データを運用者側に預けることがセキュリティ・ポリシー上問題になる、というお客様は結構います。アウトソーシングモデルでも同じような問題があるとはいえますが、アプリケーション毎に契約先が異なるSaaSの場合、一括して運用を任せるアウトソーシングに比べ、問題にされやすい傾向があります。

これはデータを預けるという行為が、相手を信頼しなければ成り立たない部分があるからだと思います。アウトソーシングの際には１対１の関係で、相手のことを十分に理解したうえで依頼するわけですが、SaaSの場合のように、このアプリケーションはここ、このアプリケーションはこちら、のようにアプリケーション毎に依頼先が異なると、個別にまかせられるのかどうかのチェックが必要になると大変なわけです。

先日、経済産業省のほうからSaaS向けSLAガイドラインというのが公表されました。その中ではインターネット経由で利用する場合に、障害が発生した場合の使えなくなる期間の長さや、データ保管に関するサービス内容、範囲、品質などを保証するためのガイドラインが含まれています。

内容を見ると、自社所有のスタイルに比べSaaSのモデルがいろいろな面で優れていることがわかるのですが、安全性の面からいろいろと検討事項があることもわかります。預けるデータの質やコストとの見合いもあると思いますが、できる限り安全なものを提供していくことがサービスを提供する側の努めだと思います。

当社としても、SaaS型でのサービスを提供するものとして、できるだけ早くSLAをお客様にご提示できるよう準備を進めて行きたいと思います。

@ITに取り上げていただきました。

アップデイティットがEclipse RCPで開発
開発者向けコラボワープロをOSSコミュニティに無償提供

ぜひご覧ください。

— 追加です(20:14) —
Open Tech Pressにも載せていただきました。
アップデイティット、ドキュメント共有管理システムをOSSコミュニティに無償提供

今日は２つほどご報告があります。

１．crossnoteのFree Trial開始しました

■評価期間はたっぷり2ヶ月間
■5名分のユーザIDをご用意
■リポジトリー容量は2GByteまで
■一人辺りの作業領域は100MByte
■すぐに使ってみることができるように、プロジェクトを3つ予めセットアップ
■翌営業日には使えるようにします。

2. crossnoteをオープンソース・コミュニティ向けに無償提供します。

■期限は1年毎に更新申請すれば期限なし
■30名分のユーザIDをご用意
■リポジトリー容量は20GByteまで
■一人辺りの作業領域は300MByte
■こちらはセットアップに少々お時間をいただきます。（まあでも、長くても1週間以内です）

詳しくは弊社ホームページをご覧ください。

来週の月曜日、何かが起きる！

なんて、まあ、そんなにたいしたことではないのですが、楽しみにお待ちください。

# おととい、昨日とちょっとどたばたしていてブログが書けませんでした。

昨年はKY（空気が読めない）という言葉が流行りました。確かに空気が読めるというのは重要なことで、読めないよりは読めるほうが良いに決まっています。ですが、それだけ(空気が読めるヤツのほうが偉いんだ)になってしまうと、何か違うかな？　と私は感じています。

空気を読むというのもいろいろなシチュエーションが考えられますが、人の顔色を伺う、という使い方で考えた場合、人の顔色ばかり伺っているようではだめですよね。日本は、やたらに人と同化したがる傾向が強い人が多いと思います。同化していると妙な安心感を得るのがその理由だと思うのですが、自分の主義・主張を言う、という部分を、その「空気を読め」という暗黙の了解が押し殺してしまっていたら、大きな損失なのではないでしょうか？

で、今日の本題はKYではなく、GYです。（前振りが長い）　Gとは「行間が」、Yは「読めない」。

日本のシステムの仕様書などでは行間を読む、ということが古来行われてきました。仕様書にはすべての情報が明示されているわけではなく、システムを作る側が仕様書を読み解き、行と行の間に省略されているであろうことを嗅ぎ取る能力が求められました。

で、最近のオフショア開発ではどうも２つの傾向があるようです。

１．仕様書を書く側が行間を埋める方向

２．オフショアの受託側が行間を読み取れるように教育する方向

最初の、仕様書を書く側が行間を埋める方向というのは、国際スタンダードな方法に自分達のやり方を変える、という、通常のやり方です。面白いと思うのは、結構２のやり方を推進するケースも多い、ということです。GYなヤツは相手にしない、という方法です。

確かに教育は大変ですが、長期的に見ると２のやり方のほうが理にかなっていると思われます。システム開発においては様々なフィードバックが開発現場側からもたらされます。もし行間を読める教育をしていれば、そのようなフィードバックが得られる可能性が高まるからです。

ただ問題なのは、行間を読み取れるオフショアのSEは、そう多くはなく、かつ成長すると他に移ってしまう可能性がある、ということだと思います。１．と２．の両方をうまく使っていくやり方が必要なのかもしれません。

昔のホストコンピュータ全盛時代はすべての処理はサーバ（ホストコンピュータ）で行われていましたが、それがPCの時代になり、一時は逆にほとんどの処理がクライアント側で実行されるようになりました。それがWebの時代に入り、またサーバ側に集められたかと思いきや、またAjaxが出てきて、画面周りの処理はクライアントに戻され、と、行ったり来たり。処理をサーバ/クライアントのどちらで行うべきか、というのは永遠のテーマのようです。

基本的にはビジネス・ロジックはサーバで、といわれます。ビジネス・ロジックを処理するためにはデータが必要ですが、データはサーバ側で一元的に扱うべきものだから、という側面があると思います。昔はそれが極端に走ってビジネス・ロジックをDB上のストアド・プロシジャで書くのが流行った時期がありましたが、メンテナンス性や移植性（特定のプラットフォームにロックインされてしまうこと）の観点で問題が多いように思えます。確かにストアド・プロシジャのデバッグはあまりやりたくないですよね。

最近SOA（サービス指向アーキテクチャ）が取り上げられることが多くなっていますが、これは処理すべき単位（サービス）をできるだけPureに、Simpleに設計することで「どこで処理をする」という部分にできるだけ自由度を与えるやり方だと思います。このどこで、というのは通常はサーバを指すと思うのですが、SOAの考え方を広げれば、極端に言えば別にサーバでなくてもいいわけです。

SOAで作りました、でもすべての処理は１つのサーバで集中処理しています、ということであれば、実は昔のホストの一極集中型処理と本質的には変わらないことになります。いろいろなところのサービスを「利用して」新しいサービスを創造する、というのがSOAの真髄です。「処理」を行うための束縛からできるだけ自由でありたい、そういうインフラを徐々に整備していくべきなのでしょう。

最後に。とはいえ、これらの自由を保ったまま適切なパフォーマンスを実現するためには設計上の工夫が必要です。これって昔の分散オブジェクト(CORBAとか)の設計と同じなんですね。心して設計しましょう。