update it, Inc.社長のブログ

連日すごい暑さですね。

夜にせみに襲われるとちょっとびびりますよね。

せみが毎夜、会社の窓に捨て身のタックルをしています。びっくりするような音です。また、会社の窓から洩れる明かりに反応してか、昼間と同じくらいの大きな音で鳴いています。

昨日までは技術者の立場から見たSaaSというテーマで書いていましたが、今日は自分が経営者になったつもりで見てください。以降では受託開発をベースとしたシステム開発型モデルとSaaSを利用したシステム提供型モデルの対比として話を進めます。

昨日の技術者の立場から見たSaaS その２で「改善」という観点の話を書いたのですが、このことは経営者の立場から見た場合、大きな強みになります。

例えば今、Salesforce.comに対抗するようなシステムを受託によるシステム開発型モデルで作り上げることができるでしょうか？　SaaSを利用したシステム提供型モデルのシステムはマーケットの要求に応じてどんどん改善＝進化していきます。一方でシステムが進化しても価格が上昇するわけではありません。それらはすべて、サービス料の中に含まれているのです。最初は受託でもあまり差がなかったとしても、システム提供型モデルのシステムは徐々に改善を続けた結果、いずれ受託開発では追いつけない高みにいってしまうことになります。

こういうとERPの例を出して否定する人もいるかもしれません。つまり、ERP導入がさかんだったころ、パッケージをベースにしても対象顧客向けの作りこみ（アドイン）が大量に必要になることが多く、かつそのアドインを開発するにはそのERPの専門の技術者でないと対応できないということがありました。このためパッケージを導入してもあまりメリットがなかったじゃないか、SaaSにしてもこれは同じではないの？という意見です。

しかしSaaS時代のシステムの場合、システム間連携のためのインターフェース（API）はWebサービスという標準的な技術で提供されます。これは対象のシステムの専門の技術者でなくてもシステムへのアドインが開発できることを意味し、システムのコンポーネント化、すなわち水平分業化が可能になることを意味します。

継続的な改善は大きな力となります。継続的な改善が可能なSaaSを利用したシステム提供型モデルは受託開発をベースとしたシステム開発型モデルを徐々に駆逐していくことになると考えます。

さて今日は昨日の「技術者の立場から見た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が詳細化されていない状態で開発が進んだ場合、操作の一貫性が損なわれたり、同じような処理があちこちに散らばる結果になります。

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

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