update it, Inc.社長のブログ

さて今日は昨日の「技術者の立場から見たSaaS」の続きです。

技術者の立場で考えた場合、SaaSにはもうひとつの大きな違いがあります。それは1度作ったら終わりなのか、何度も改善を積み重ねていくものなのか、という違いです。

システム開発会社の受託したシステムの場合、基本的には作って納品してしまえばおしまいです。もちろん保守もあるにはありますが、エンハンスが続く場合は別として、通常の保守の場合システムの障害対応がメインであり、中身を改善して作りかえるということはあまりしないと思います。

一方のSaaSによるシステム提供会社の場合には、そのシステムは大切な商売道具であり、絶えず改善が求められることになります。作ったらおしまいではなく、中身をどんどん改善していかなければ他の競合他社に負けてしまうのです。

この特徴はパッケージ製品を提供している場合でも同じはずです。つまりパッケージ製品の場合でも、通常は何度も改訂を重ねて改善していきます。ただしパッケージ製品の場合には見た目を華やかにする「売る」ための機能追加がメインになっているとおもいます。一方のSaaSの場合、自社で運用するために実際に「使える」製品にすることにも自然と注力せざるをえません。つまりセールストークのための機能追加よりはシステムの安定性や通常の使いやすさの改善に力をいれなければならないということです。

システムを受託開発するとき、きちんと動きはするものの技術者としては納得のいかないレベルでの納品が必要になる場合があります。そして一旦納めてしまうとそのシステムはそうそう改善するチャンスはありません。しかしシステム提供会社の場合には保守をしやすくするための改善をやるチャンスがあります。もちろんマーケットの要求に応じることが最重要ですが、それをやりつつ、既存のコードのリファクタリングも行うことが当たり前になるのです。

さて、あなたはどちらの技術者のほうが幸せだと思いますか？

すごい暑さですね。

今日も自転車で出社したのですが、車が少なくて快適でした。

最近、日経新聞とかにもSaaSという言葉が踊っていて驚かされることがあります。NBOnlineでもつい先日、SaaSでもっとも成功している企業の例としてSalesforce.comの話を取り上げていますね。

以前のブログでシステム開発会社とシステム提供会社というテーマでSaaSの進展に従ってシステム会社の「製造業」から「サービス業」への転換が始まるという話を書きました。SaaSの本質は、技術的な面よりもむしろ、今までオーダーメイドで作っていたのを止めて、既製品を提供する商売へ転換するということだと思います。

その意味ではパッケージ商売と近い部分があります。ただしパッケージ商売の場合、ソフトウェアだけを売り物（正確には使用許諾権ですが）にしていたのに対し、SaaSではもっと広く、利用するためのバックエンドの仕組みを含めて全体をサービスとして提供します。つまり、作っては売る「製造業」の世界から、継続して様々なサポートを提供するサービス業への転換を意味することになります。

システム開発会社の世界では製造力、すなわち技術力（と体力？）の勝負ですが、システム提供会社の世界では技術力もさることながら、他にも企画力や運営能力など、総合的な能力が問われるようになります。

ではシステム開発会社の技術者とシステム提供会社の技術者では違いがあるのでしょうか？　技術者という立場からみれば、作るのは同じじゃんと思うかもしれませんが、実は大きな違いがあります。それは顧客との関係という点です。

オーダーメイドでシステムを作る場合、顧客と開発会社の関係は主従の関係になります。つまり顧客のほうが開発会社よりも圧倒的に強い立場になります。顧客の言うことには従わなければなりません。

一方のシステムを提供する立場の場合、システム・オーナは自分自身（の会社）なのです。もちろん多くの顧客に使ってもらうために様々なサービスを顧客に提供していかなければなりませんが、システムがどうあるべきかは自分達が決めることになるのです。もちろん会社の内側を見ると企画側と開発側での綱引きとなるのですが、そうは言っても自分の会社自身がシステム・オーナであり、どういうシステムとすべきかという部分に技術者がより主体的に関与できるという点で、大きな違いがあるといえます。

自分達のシステムであれば、作るシステムへの愛着も格別かもしれませんね。

いつにも増して人影がまばらです。今日は休んでいる人も多いのでしょうね。

私はソフトウェアの仕事が好きです。なぜ好きかというと、もちろん純粋にソフトウェアに対する興味という部分もあるのですが、何よりも魅力的なのは、クリエイティビティ=イノベーションを追求できる世界だという点です。

この分野では次々にイノベーションが起きていて、そのスピードは明らかに他の分野より速いです。ぼやぼやしているとあっという間に取り残されてしまいます。No.1がいつまでもNo.1でいられるとは限らない世界。非常に刺激的で魅力的な分野だと思っています。

従来の資本主義というと、巨大な資本力を持った者が圧倒的な強さを持っていたのですが、ソフトウェアの分野では必ずしも巨大な資本力を持った者が勝者になるとは限りません。新興の小さな会社が起こしたイノベーションにより、あれよあれよという間に成長して巨大な企業を打ち負かす、などという戦国時代さながらのことが当たり前のように起こり得ます。

「ペンは剣よりも強し」という言葉がありますが、ソフトウェアの世界では「アイデアは資本よりも強し」だと思います。どんなに資本力があっても、イノベーションを起こすアイデアがなければこのソフトウェアの世界では生き残れない。逆にイノベーションを起こすアイデアがあれば、誰にでもチャンスがある。このフェアな部分がソフトウェア分野の魅力だと思います。

資本主義から知本主義への転換。ソフトウェアの分野から世界を変えていきたいと思いませんか？

今日はcrossnoteネタです。

告白。

crossnoteはEclipseベースです。つまり、Swingベースではなく、SWTベース(+Draw2D/GEF)です。SwingUnitを作っていながら、これは何？　といわれてしまいそうですね。  😀

正直なところ、初期のころにSwingベースで一からつくるか、それともEclipseベースのRCPアプリケーションにするかでだいぶ悩みました。私自身はSWTはまったくの初心者ということもあり、自信はなかったのですが、以下の理由でEclipseベースを選択しました。

１．社員のメンバーの中にEclipseベースの開発に強い人がいたこと。
２．ワープロ部分の漢字入力への対応がSwingベースよりもEclipseベースのほうが確実に対応できそうであったこと。
３．多くのツールがEclipseベースで開発されていることを考えた場合、同じプラットフォームで動くメリットを享受できる可能性があること。

一番の決め手になったのは、３の理由です。

やってみてわかったことですが、Eclipseベースの場合、Swing系に比べるとOSのAPIがベースになっているだけに、その制限に縛られることが多く、アプリケーション全体として仕様が制限されることが多いという問題がありました。おそらくSwing系でJava2Dなどを利用したほうがもっと多様なことに対応できたのではないかと思います。まあでも、そもそもcrossnoteはプロジェクトのドキュメント作成用のワープロを目指しているのであって、アーティスティックな表現が求められているわけでもありませんので、そこは割り切って考えています。

今悩んでいるのは、テスト駆動開発に関する記事を書いておきながらお恥ずかしいことですが、ユーザI/F周りのユニットテストの自動化です。いまのところ人力でやっているのですが、回帰テストの量が膨大になります。でも、当然のことながらSwingUnitは使えません。何かいいものはないでしょうかね？

自分が普段使っているPCの裏で、どんなプロセスが裏で動いているか把握している人っていますか？　最近のPCにはいろんなものがてんこ盛りになっていて、知らないプロセスが一杯動いていて、わけがわかりません。Windows95のころまでは、どんなプロセスが動いているかぐらいはだいたいというか、なんとなくは把握できていたのですが…

先日、使っているPCが突然ウィーンとうなりを上げて冷却ファンが回り始めました。CPU負荷の高いようなことは何もやっていません。なので、気になってタスクマネージャを開いてみてみたのですが、CPUの%が高いのはSystem Idle Processだけです。でもCPU使用率の履歴グラフにはなんかのプロセスがCPUを使っているように表示されています。System Idle Processっていうのは、CPUの空きを示しているんじゃなかったでしたっけ！？　まあそれは置いておいて、改めてそこに並んでいるプロセスを眺めてみて思ったのは、ほとんどが知らないものばかりだということでした。（あの、一応ウイルスチェックはちゃんとやっていますよ）

裏で何か知らないプロセスがうじゃうじゃ動いているというのは気持ちのいいものではありません。メモリを食いますし、遅くなる可能性もあります。また「よくわからないものが動いている」という状態はセキュリティ的にも問題があるといえます。

しかし、最近のPCには実にわけのわからないプログラムが一杯プリインストールされてしまっています。また必要なプログラムをインストールする場合でも、そのプログラムがおまけのプログラムをいろいろ一杯インストールしてしまったり、更新をチェックしたり起動をスピードアップさせる常駐プログラムを裏に仕込んいる、なんてことはよくありますよね。

一方で、どのプロセスは必要で、どのプロセスは必要のないものなのかがよくわかりません。私は勝手にPCにインストールされている必要のないプログラムはさっさとアンインストールしてしまう派なのですが、果たして本当にそのプログラムをアンインストールしてしまって問題がないのか、いつも悩まされています。

食品の分野では消費者に対して使っている原材料を明記することが義務付けられていますが、システムの分野でも同じようにすべきではないでしょうか？　つまり、せめてアプリケーションをインストールすることによって、どんなものが追加されるのか、またどういう場合に必要で、逆にどんな場合には必要のないものなのかをユーザがわかるようにする、ということです。セキュリティの観点からは結構重要なことのように思えます。みなさんはどう思いますか？

だいぶ以前に、?設計書に書くべき範囲という似たようなタイトルでブログを書いていますが、今回は「詳細化」という観点から考察してみましょう。なおここに取り上げていないドキュメントについては、下のいずれかに相当するものとして考えてください。

昔は詳細設計書というのがあって、フローチャートなどという懐かしい図とともにかなり細かいレベルのドキュメントを書いていましたが、最近では詳細設計書は書かないのが当たり前になってきたと思います。（ただしミッションクリティカルな分野については違うかもしれません）

理由の１つにはオブジェクト指向の普及などにより、詳細設計書とソースコードがほぼ同義語と考えられるレベルになってきており、「２つのドキュメント（詳細設計書とソースコード）」の二重メンテナンスは避けるべきだと考えられるようになってきたこと、そして、コンピュータリソースが貴重だった時代とは異なり、昔では考えられないような高度な統合開発環境が誰でも使えるようになってきており、詳細設計書のレベルのことはソースコードで十分じゃん、というのがはっきりしてきたため、ともいえると思います。

では他の設計書はどうでしょうか？　基本設計書や概要設計書はその名の通り、詳細化しては「いけない」ものです。ここに詳細なことを書き込んでは、読み手が本当にそれを読んで押さえるべきツボを押さえられなくなります。基本設計書には基本的なこと、概要設計書には概要を書くべきであって、それ以上のものを書く場所ではありません。詳細化を避けることによって、これらの設計書が読みやすくなり、プロジェクト全体の方向性を定めるコンセンサスを取るための道具として、またプロジェクトへの新しい参加者向けの導入書として、またテスト設計する上での基準としても役に立つようになります。

では外部設計書はどうでしょうか？　これは十分に詳細化されてしかるべきものでしょう。もしシステム間インターフェースとなるデータベース項目やファイルフォーマットなどが最終化されたものがない状態で開発し始めると、後になって大きく回り道をする羽目になります。ユーザーI/Fも同じです。ユーザーI/Fが詳細化されていない状態で開発が進んだ場合、操作の一貫性が損なわれたり、同じような処理があちこちに散らばる結果になります。

ただし外部設計書も最初から詳細化されたものがいきなり出てくるわけではありません。通常はいくつかの段階を踏んで、徐々に詳細化していくものだと思います。最後に残ったドキュメントは詳細化されているべきだ、というだけで、途中の中間成果物まで詳細化されているべきだ、とは申しません。

トム・デマルコさんの書いた書物のいくつかには、ユーザマニュアルこそが究極の設計書だと書かれています。ユーザマニュアルは、ユーザが読む視点で書かれた外部設計書といえます。外部設計書としてはユーザマニュアル程度の詳細化が必要だ、ということかもしれません。

最近、IT企業に分類される会社で広告モデルに走っている会社が増えています。Googleを先頭に、マイクロソフトまでが広告モデルの事業を展開しています。同じ「IT企業」でも、純粋にシステムを作って販売している会社と、Web2.0時代の広告モデルで成り立っている会社ではまったく別のイメージです。そもそも同じ分類（業種）と考えるべきではないのかもしれません。

広告って金融と同じく、企業が活動していく上では必ず必要になるものです。そしてGoogleの急成長振りを見ても、そこで大きなイノベーションと変革が起こっているのは明らかだと思います。だから様々な会社が乗り遅れまいと広告型モデルへと走る。今はいわば、ゴールドラッシュ的なものなのでしょう。

でももし、5年後の世界から今を覗き見たら、どんなように見えるのでしょうか？　おそらくこんな感じではないでしょうか？　「おー、このころはまだみんながんばっていたね。でも結局、みんな○×△に収斂しちゃったよなー」　みんながこの○×△の枠内に入ることを目指していると思うのですが、みんながこぞって参入しているということはそれだけ競争が激しいわけです。5年後において、果たしてどれだけの会社が残っているのでしょうか？

孫子の兵法で有名な「戦わずして勝つ」という言葉がありますが、戦わないことも１つの戦略です。人と同じ方向に走っても、その集団で競り勝つのは至難の技です。勝つためにはむしろ、人と違う方向に走るべきだと思うのです。

今、私の下の子がサッカーチームに入っているのですが、まだ低学年なので、みんな団子のようにくっつきあいながらボールを追い回しています。みんなが一斉に同じボールの方向に向かって走ってしまうのです。でもシュートを決めることができるのは、むしろその集団から離れてちゃんと自分の役割を考えながら機会を狙っている頭のいい子なんですよね。

え、では　update it, Inc.がどうだって？　他の会社とは違う方向を向いているつもりです。私は戦わずして勝つことを信じていますよ。

先週、デモ用に買ったVistaの載ったノートPCのインストールに苦労したという話を書きましたが、今日はVistaを使ったインプレッションを書きます。というか、書きたくてしょうがない。

というのも、「遅いぞ、こら！」

今回買ったマシンはCore 2 Duoで2GByteのメモリーが載った、最初からVistaに対応している最新機種です。にも関わらず、信じられないくらいすべてが遅い。特に漢字変換の反応の鈍さはたまりません。なかなか変換しないんで、いらいらしてしまいます。あとログイン・ログアウトが限りなく遅い。マシンはActive Directoryのドメインに参加させているのですが、Control+Alt+Deleteキーを押してからログイン画面が出てくるまでにしばらく待ちます。ログアウトも同じような感じで、XPのマシンの倍ぐらいかかっているんじゃないか？って感じです。

VistaのノートPCの場合、電源ボタンを押したときにはデフォルトでスリープ状態（メモリーに電源が供給されたままの低消費電力状態）になるようなのですが、これだとそのまま数日放置するとかなり電池を消費していしまいます。なので休止（メモリーの内容をハードディスクに書き出してから電源をとめた状態）になるように変更したのですが、2GByteのメモリーがたたったのか、実際に休止されるのに結構待たされます。

あとわけがわからんというか、ちょっと呆れたのが、Windowsサーバー上のドライブがネットワークの一覧に表示されないこと。Sambaじゃないっすよ。最新のWindows Server 2003のドライブ。VistaからはLink-Layer Topology Discovery(LLTD)という仕組みが使われているらしく、このLLTDレスポンダがインストールされていないXPやWindows ServerはVistaマシンから一覧で見ることができません。しかもLLTDレスポンダはXP用しかでていない！　まあSambaサーバが見えないのは百歩譲ったとしても（あまり譲りたくはない）、なんでWindows Server 2003用がないの？

MSはVistaをビジネス用には売りたくないのだろうか、と勘ぐってしまいました。正直なところ、仕事に使うにはまだ早いのかもしれません。最近、VistaマシンをXPに載せ変えることを「アップグレードする」というらしいですが、うーん、なるほど、ですね…