update it, Inc.社長のブログ

まだまだ暑いですが、徐々に秋って感じにもなってきましたね。

私は先週末、子供の運動会に出て日に焼けすぎて皮膚から出血してしまいました。痛い。

SE（システム・エンジニア）は業務系SEと技術系SEに色分けされることがよくあります。業務系SEは特定の業務に対してのシステム設計を得意分野とする人、技術系SEは特定業務に寄らず、一般的なシステム・アーキテクチャ設計を得意分野とする人、といったところでしょうか？

例えば若いSEが自分が目指す方向として業務系SEを目指すのか、技術系SEを目指すのか、などといった観点で使われています。私自身はというと、証券・銀行などの金融の業務系SEとして今まで歩んできました。特に「業務系SE」という肩書きをもらったことはないですけどね。

今まで経験的に感じていることとして、システムが得意な人ほど業務系SEを志向しない傾向があります。システムが得意な人はシステムだけ詳しければそれでいいと考えている人が多い、ということです。でも私から見ると、これはとてももったいないことをしている気がしてなりません。なぜかというと、両方ができると間違いなく活躍できるフィールドは広がるからです。バリューが高まる、ということです。

私は業務系SEでしたが、目指したのはシステムが得意な業務系SEです。業務についての勉強をしつつ、同時にできるだけ最新のシステム技術動向を取り入れ、それを実際の業務システムにいち早く応用していくことを楽しんでいました。これはとてもやりがいのある仕事ですよ。

そして経験的に感じることなのですが、もともとはシステムが得意でなかった業務系SEが努力してシステムも得意になるよりも、システムがもともと得意なSEが努力してさらに業務も得意になるほうが簡単なようなのです。

そう、若い人がSEを目指すならば、システムが得意な人こそぜひ業務系SEにトライして欲しいと私は思います。実際に業務を知ることで、その中で自分が得意なシステムに関する知識を存分に発揮できる可能性が高まります。最新のアーキテクチャを実際のシステム開発に応用し、実際に皆に使ってもらうのはこの上なくエキサイティングな経験です。また業務系SEは顧客との接点も多いので、コンサルタントとしての素養も磨くことができます。

ま、大変なことも多いです。でもやりがいのある仕事であるのは確かだと思います。

昨日の「お客様の業務を理解することの重要性」において、お客様の業務を理解しないとパッケージやASPサービスはできないよ、ということを書きました。（当たり前の話ですね）　じゃあどうやったら業務を理解してそれをパッケージやASPサービスとして実現することが出来るようになるのでしょうか？

いくつか案を考えて見ましょう。

１．自社でその商売をやってみる。
２．その商売をやってきた人を採用する。
３．お客さんのところに社員を研修に出して商売を覚えてきてもらう。
４．以前その商売をやって来た人たちでシステム会社を起業する。

最初の案はなかなか実行するのが難しいかもしれません。ある意味業種転換するわけですから。またいきなり新参者として新しい商売を始めてもうまくいかない可能性も高いですし、逆にうまくいったのならその先システムを作る仕事はやめたほうがいいかもしれません。

２の案は（金さえあれば）実行は比較的簡単です。ただし気をつけなければならないのは、そうやって採用した人は通常、システム的なセンスがあるわけではないので、その人自身に設計をさせることは難しい場合が多いということです。なので、「その人」の使い方が難しいのですが、でももし対象業務をシステム化したいという高い志をもった人を採用することができれば、これはかなりうまくいく方法だと思います。

３の案も可能であればお勧めの方法です。システム的な設計のセンスをもった人を期限付きでお客様のところに送り出し、お客様と同じ仕事をして覚えてきてもらえれば、その人は業務ノウハウを理解すると同時にシステム設計のヒントを一杯抱えて戻ってきてくれることになります。非常に良い方法なのですが、問題はこのような提案に乗ってくださるお客様がいるか、ということと、実施に時間がかかること、そして場合によっては送り出した人がその業務に目覚めて帰ってこなくなるリスクがあるということです。

４がもっとも理想ですね。実際こういった形で起業するベンチャーも多いと思います。敢えて問題があるとすれば、その人たち自身はシステムについて十分知っているわけではない場合が多い、ということだと思います。でもその場合にはシステムに詳しい人を仲間として採用すればよいのです。またこういうケースの場合には、最初はシステムに素人でも本人達が問題意識を持って取り組むので、自然にシステム的なセンスを身につける場合が多いということもいえます。

日本でも４のようなケースがもっと増えるといいと思います。

昨日はなぜ受託開発がこんなにも多いのか？というタイトルで書きましたが、今日はその「なぜ」の部分に踏み込んでみたいと思います。ということで、タイトルは「お客様の業務を理解することの重要性」です。

なぜ受託開発がこんなにも多いのか、それは、大半のシステム開発会社はお客様の業務を知らないことに原因があるのではないでしょうか？　業務を知らないからパッケージ化できない、もしくはアプリケーションフレームワーク化したくても、どの部分をどうまとめればよいのかがわからない。そういうことだと私は考えます。

最近オブジェクト指向ばやりで、システム分析にもオブジェクト指向分析を導入するケースが増えています。これは正しいことなのですが、なぜこれが必要かというと、作る側がお客様の業務を理解していないために必要なのです。もし、お客様がやっていることを全部理解していれば、いちいちこんな回り道をしなくてもシステムは作れてしまうのです。（しかもこの場合でもシステムの作りとしてはオブジェクト指向的に「作る」ことはできるんです）

もちろん、作る側のチームにはお客様の業務に精通していない、ジュニアなメンバーがいる場合もあり、そういうメンバー向けには必要だと思いますが、例えばすべての設計者が対象業務に対して十分な知識を持っている場合には本来省いても問題のないことだといえます。

パッケージやASPなどのサービスをしている会社は、自社でそのようなお客様の業務に関するノウハウを持っています。だからシステムとして実現できているのですが、「なんでもやります」的な受託をベースにしている会社の場合、その会社にはお客様の業務を理解している人はいません。だからどう転んでも、この状態では受託開発しかできないんです。

もしシステム開発会社がパッケージやASPなどをサービスする会社に変身したいのであれば、まずはお客様の業務を徹底的に理解しなければなりません。ではどうやったらお客様の業務を徹底的に理解できるようになるのか、それはまた次の機会に書きたいと思います。

この間、あるベンチャー系の展示会の案内を見つけて、その出展企業のリストからITおよび情報通信系の会社をピックアップして見ていたのですが、ひとつ感じたことがあります。それは、受託開発（もしくは人材派遣）を基本としているところがあまりにも多い、ということです。前から感じていたことではあるのですが、調べてみてあらためて強く感じた次第です。

受託開発が悪いというつもりはないのですが、私には受託開発は受身の商売のように思えます。基本的なスタンスはお客様の希望するとおりのシステムを作ることなのですが、もしそのお客様の商売が良くわかっているのであればその商売をサポートする仕組みをパッケージやASP、SaaSなどといった形態で提供することができるはずです。また完全なパッケージ化が難しい場合でも、業務ノウハウ部分をアプリケーション・フレームワーク化して様々なオーダーメイド的な要求にも耐えうる、セミ・パッケージ化はできると思います。

特定の商売をサポートするパッケージやフレームワークを持つほうが会社としてのプレゼンスや利益率が大きく改善すると思うのですが、いろいろなITおよび情報通信系の会社案内を見てみた感想は、受託開発を基本に「なんでもやります」的な会社があまりにも多いな、ということでした。

ここ数年は景気回復の恩恵を受けてどの会社もそれなりに仕事が受注しやすい環境といえます。でもこの状態がいつまでも続くとは限りません。そうしたときに、この「なんでもやります」的な会社が競争に打ち勝つには価格で競争せざるを得なくなると思うのです。

今後は今以上に中国、インドなどのIT系企業との競争も激しくなるでしょうし、そうなると国内で受託開発を基本にしている会社の場合、価格以外の面で競争できる柱がないと太刀打ちできなくなると考えらないでしょうか？　そして、その価格以外の面での柱とは、特定の商売をサポートするパッケージやフレームワークを持ち、それでブランドを確立することだと私は考えます。

間が空きましたが、デスクトップアプリの生き残り策　その３です。デスクトップアプリの生き残り策の最初のエントリーデスクトップアプリの生き残り策において、デスクトップアプリもできるだけインストール・レスにすべきだ、という話を書きました。ではどうやってそれを実現するか、ということを書いてみます。

そもそもなんでインストールが必要なのでしょうか？　PCの世界ではアプリケーションはインストールして使うものだ、という思い込みがありますが、歴史を紐解く（？）と、昔は必ずしもそうではなかったということがわかります。

過去の大型コンピュータやミニコンの時代はアプリケーションの利用モデルが今のWebアプリと非常に良く似ています。TSS(Time Sharing System)端末やVT端末がWebブラウザになったようなものです。当然個々の端末にアプリケーションをインストールする必要はありませんでした。

次のUNIX全盛時代には個別のクライアントマシンにインストールする場合もありましたが、LAN上のNFSサーバにアプリケーションを置き、各クライアントマシンではNFS mountしてサーバ上のアプリケーションを利用する、ということが比較的良く行われました。（この場合、アプリケーションはクライアント・マシンで動きます）　さらに自分のホームディレクトリのデータもNFSサーバに置く（フリーシーティング=どこの端末でも同じデスクトップ環境とすること）ことができたので、こうすることでクライアントにはアプリケーションを一切インストールはしないで使うこともできたのです。

ちなみにこの考え方はシンクライアントそのものです。

ただ、このUNIXのときに良く用いられたやり方は、LANの中ではうまくいくのですが、ノートPCのようにLANの外に持ち出して使う場合には役に立ちません。またWindows系のPCの場合、フリーシーティングの設定にすると、ホームディレクトリーをマウントするのではなく、プロファイルという単位で丸ごとコピーするという仕組みになっているので、ログイン、ログアウトが重くなる上、プログラムはインストールすることを前提に作られているために同様の方法が取りにくいという事情があります。（Windows Terminalはシンクライアントの一種と言われますが、アプリケーションの実行はサーバなので、むしろ大型コンピュータやミニコンのモデルに近い）

さて、話を戻してどうやったらインストール・レスでデスクトップアプリが使えるようになるかは、このシン・クライアント抜きには考えられないでしょう。特にUNIX的なシン・クライアントは管理が楽になる上、CPUは分散処理なのでスケーラビリティが良いというメリットもあります。ただ、現状ではシン・クライアントは閉じられたLANの世界を中心に考えられているので、ノートPCを中に組み込めるようなモデルに修正したいものです。ノートPCの場合、LANに接続したときにアプリケーションを同期するような仕組みです。

誰かこんな仕組みを作ってくれませんか？

以前、iPhone欲しいとブログで書いたことがありましたが、まだ当面は日本の携帯電話としては認可されそうもない現状の隙間を埋めるかのように、iPod touchでちゃいましたね。そろそろCLIEもぼろぼろになってきたし、ここは思い切り買い換えてしまおうか、と本気で考えています。

やっぱりこの薄い、軽い、小さい、これに尽きます。でも私の場合、このなかで使いたい機能は１番はスケジューラで２番目がアドレス帳なんだけど、この２つについてはレビュー記事がほとんどありませんね。そもそもそれを期待して買うヤツはあまりいない、と。

このiPod touchはエンターテイメント側に寄ったPDAと考えることができますが、この類の製品はCLIEでもいくつかありました。CLIEの場合には最終的に生き残れず、製品がなくなってしまいましたが、果たしてiPodとCLIEの違いはあるのでしょうか？　そしてiPod touchは今までPDAが繰り返してきた歴史（どれもこれも結局は根付かずに次々と消え去ってきた歴史）を根本から変えることができるのでしょうか？

以前のブログPDAに書いたのですが、PDAは今まで進化の方向を間違えたために行き場をなくした、と私は考えています。もともとはビジネス用の便利なオーガナイザーとしてスタートしたものの、本来のビジネス用途では使い道が細り、一方でエンターテイメント側にも完全にはシフトしきれず、非常に中途半端な存在になってしまったことが、今までの失敗の原因だと思うのです。

今までのPDAの流れはそうだったのですが、iPod touchの場合、そもそもiPodそのものであり、完璧なエンターテイメント専用マシンです。基本がiPodなので、実際にはPC（というかMac）に非常に近い存在であるにも関わらず、使う側はPCのサブセットとしてではなく、手軽にどこでも音楽とビデオを視聴するためのマシンという位置づけで使うと思います。それにたまたま無線LANとWebブラウザがくっついた、という存在です。

つまり、使い道が非常に明快なんです。通常のiPod touchを買う人はそれをPDAとして考えているのではなく、高級版iPodとして捉えるのだと思います。だからiPod+iTMSという商売がうまくいく限り、高級版iPodとしてうまくいく可能性が高いと私は考えています。たとえそれが、中を良く見てみると昔のCLIEのエンターテイメントバージョンに非常に良く似た存在だとしても、です。このわずかな立ち位置の違いから、CLIEとは異なる結果になるのではないかと期待しています。

今日も昨日の続きで、デスクトップアプリの生き残り策について考えてみたいと思います。

二日前のブログWebアプリを選ぶ３つの理由において、Webアプリへ移行している理由の２番目として、「２．別なマシンからでも同じ環境で使うことができるから」というのを挙げました。

これは例えばWebメールの場合、例えば出先のノートPCと会社のデスクトップPCの両方で使った場合：

１．どちらで見てもメールボックスの中身を同じにすることができる。
２．どちらで見ても、未読・既読の管理が正しくおこなわれる。
３．例えばノートPCで作った未送信のメールを引き続いてデスクトップ側で作業することができる。

等といったことを意味しています。

デスクトップアプリケーションでは、データがマシンにローカル保存されるため、マシン毎に環境が異なることになります。もし、そういったデータをサーバに保存して利用したら、Webメールとほぼ同様に別なマシンからでも同じ環境で使うことができるようになります。

ところがデスクトップアプリケーションにおいてこれを実現するには、データを保存しておくためのサーバが別途必要なことを意味します。また当然のことながらデータがサーバに保存されるようにするには追加のプログラム開発が必要になります。技術的には不可能ではないにも関わらず、こういった現実的な理由から、デスクトップアプリケーションではデータをサーバに保存するということが無視されてきたのだと思います。

しかし、もしこの先もデスクトップアプリとして生き残りたいのであれば、このデータをサーバに保存する機能はぜひ提供すべき機能なのだと思います。これを実現すると、どこでも同じ状態で使えるというメリットに加え、さらに万が一、使っているPCが壊れて使えなくなったとしてもデータが必ずバックアップされるため、安心して利用できるようになるからです。

ちなみにcrossnoteでは、主要なデータについてはupdateボタンを押したタイミングでサーバ側に自動的に保存されるようにしています。主要な、という辺りがちょっと微妙なのですが、新着の修正点の判定やコメントの既読・未読の管理などはローカルPCに保存されたデータで行うようにしているためです。

今日は、昨日のWebアプリの続きで、逆にどうしたらデスクトップアプリを生き残らせることができるかについて考えてみましょう。

デスクトップアプリがWebアプリに比べ、利用者の利便性から考えても不利な立場であることは昨日述べたのですが、ではデスクトップアプリがなくなってしまうかというと、そうも言い切れません。デスクトップアプリでなければ実用に耐えられないという分野があるからです。

例えば弊社のcrossnoteもそうなのですが、ワープロや表計算ソフトなど、反応速度などの点で本質的にクライアント側で動かさなければならない部分が多いアプリケーションはデスクトップアプリにせざるを得ないと思います。確かにGoogleはAjax版のワープロとスプレッドシートを提供していますが、MS Officeなどに比べるとかなり機能を絞り込んだものであり、今までWordやExcelで行ってきた仕事をそのまま移行できるものではありません。最近OpenOfficeをGoogle Appsに追加したようですが、この事実がそのことを物語っていると思います。

他にもローカルリソース（例えばCDなど）を使わなければならないアプリケーションも必然的にデスクトップアプリケーションにせざるを得ませんね。

では、デスクトップアプリとして存在し続けなければならないアプリケーションはどのように進化していくべきなのでしょうか？

私はそのキーワードの１つは、やはり「インストール」という点にあると思っています。ディスクトップアプリケーションの場合でも、できるだけインストールしない、もしくは非常に短時間でインストールが完了するようにすべきだと思うのです。デスクトップアプリケーションが忌み嫌われるのは、インストールやバージョンアップのために手間隙がかかり、いろいろなものが勝手にセットアップされてPCが「汚れる」からで、もしインストールしないで、もしくはほんの一瞬のインストールで使えるようになっていて、かつPCが汚れなければ、誰もそんなに文句を言わないと思うのです。

え、crossnoteがどうか、ですか？　残念ながら今時点ではインストール・レスとはいきません。ただ、ぜひ挑戦していきたい課題だと考えています。

言うまでもない話ですが、今、ものすごい勢いでいろいろなシステムがWebベースに置き換わってきています。企業内の業務用アプリでも同様です。約１０年ぐらい前に作られたVisual Basicで書かれたデスクトップアプリケーションをWebベースのアプリケーションにリプレースするという流れはどんどん加速していて、止められないように思えます。

さて、なぜ皆がこぞってWebに移行しているのでしょうか？　主な理由を３点挙げてみます。

１．保守が簡単だから。
２．別なマシンからでも同じ環境で使うことができるから
３．インストールが要らず、すぐに使えるから。

１番目の理由はシステムを運用する人にとってのメリットです。メンテナンスは基本的にサーバ側に集中するので、保守が簡単だ、ということです。そして２番目は、Webブラウザさえあればどこでも同じ環境で使えるようにできるということ。Webメールなどを使っていると、このありがたみが良くわかります。

３番目の理由が、今回着目するポイントです。今日、Webアプリというタイトルで記事を書いたのは、このインストールが要らないという観点に着目したかったからです。（３つの理由と書いておきながら、ちょっと強引ですね  :grin:）

最近、私のノートPCのアンチウィルスソフトが更新されたのですが、そのバージョンアップには20分近くかかりました。その間、ノートPCでは何も作業ができなくなります。しかも途中でリブートしなければならない上、バージョンアップが終わった後にもハードディスクのフル・スキャンを要求され、それを完了させるのに数時間かかりました。フル・スキャン中は使えないことはないのですが、動作がかなり緩慢になって使いづらくなります。

これはちょっと極端な例かもしれませんが、今までのディスクトップアプリケーションには必ずインストールが必要でした。このインストールという作業が行われている間は、ユーザが本来やりたい作業が行えません。最近のPCではバージョンアップが自動的に行われるアプリケーションが多くありますが、たとえ自動的であろうと、そのバージョンアップ（インストール）の間はアプリケーションが使えないのは一緒です。

ちょっと考えてみてください。あなたはPCで仕事をしているうち、OSも含めてどの程度をインストールやバージョンアップなど、本来の仕事とは関係のない作業に時間を費やしていますか？　使っているアプリケーションにもよりますが、無駄に時間を使っている人も多いのではないでしょうか？

一方、Webのアプリケーションはインストールやバージョンアップすることなしに、いつでもすぐに、最新のバージョンで利用することができます。そもそも使う側はWebのアプリケーションが最新版にバージョンアップされているなんてことは気にしませんよね。なんか、いつの間にか画面が変わっている、ぐらいの意識だと思います。この待たずに使える、というのも、デスクトップアプリに対するWebアプリの大きなアドバンテージの１つだと思います。