update it, Inc.社長のブログ

@ITのWeekly Top 10のGoogle ドキュメントの進化は止まったのかの中の、Google Appsに関するコメントを非常に興味深く読みました。記者の方はGoogle Docsのヘビーユーザだそうで、ユーザ視点に立った評価をしています。一言で言うと、SaaSってことで注目は浴びるけど、基本がなっちゃいないとみんな使わなくなっちゃうよ、とあります。

マーケティングという観点で考えると、まずは使ってもらうことがとても重要です。ですので、Google Appsの『掴みがいい』（使い始めたときにインストールなしで、すぐ使いだせる）というのは非常に強みになります。しかし、いざ使い込むと、既存のオフィスソフトに比較しての低パフォーマンスやバグの問題など、欠陥ばかりが目立つようになり、利用者の期待に応えたものになっていない、としています。

記事の最後はこのように締めくくられています。

— 引用 —
配信方法だけでユーザーを満足させるのは限界がある。ソフトウェアの基本性能を満たしながら、SaaSならではのプラスアルファが求められるのだろう。
————

私も、Google Appsが従来のデスクトップ型のオフィスソフトのSaaS版だ、という位置づけのままであれば、少なくとも日本では現状の地位から大きく躍進することは可能性として低いと考えています。インストールがないという点はシステム管理者からみた場合、とても重要な魅力ですが、もしそれがGoogle Appsの魅力のすべて、だとしたら、その魅力は非常に薄っぺらいものに思えるのです。

日頃利用するユーザが恩恵を受けるようなものこそが、本当に必要とされるものなのではないでしょうか？

ドキュメントを作る際、そのほとんどはコピーして作って、ある部分だけ書き換えて新しいものを作る、そんなケースって結構ありませんか？　この場合に問題なのは、作ってしまった後のメンテナンスです。共通部分の変更の場合、コピーしたドキュメントの数だけメンテナンスしなければならず、大変です。

次のcrossnoteのリリースではそんな場合に有効な「参照」機能が追加になります。ドキュメントをコピー＆貼り付けする際、「参照として貼り付ける」ことで、そこに表示される内容は、オリジナルのドキュメントの中身と同一のものになります。つまりオリジナルのドキュメントを修正すると、それを参照しているドキュメントも自動的に修正されるようになります。

参照している部分は編集ができなくなっているのですが、編集できる状態にして内容を書き換えることもできます。ただし書き換えてしまった場合には、オリジナルのドキュメントを修正しても、自動的には変更されなくなります。この場合でも参照リンク情報は保持されており、修正を取り消して元の状態に戻すことも可能です。

参照はcrossnoteのドキュメント内の枠の単位で可能です。従って図や表、文章などを枠の単位で部品化して、さまざまなドキュメントで再利用し、かつ保守性を高めることができます。

ある方にこの機能をご紹介したら、「ドキュメンテーションもプログラミングと同じになってきた」とおっしゃっていました。うまい表現だと思います。Eclipseでプログラムを書くように、crossnoteでドキュメントを書く時代がもうすぐやってきます。

この機能のリリースはまだ確定していませんが、今月中には行う予定です。お楽しみに。

ここ最近、工事進行基準に関する情報もだんだん増えてきたようですが、相変わらず当事者のＰＭの方からは不安視する声が聞こえます。そこで、システム開発会社の経営者やプロジェクト・マネージャ、プロジェクト・リーダの方を対象とした勉強会を企画しようと考えています。

この勉強会の趣旨は、プロジェクト・マネージャにとっての工事進行基準とは何か、という理解の部分から初めて、徐々にケース・スタディや参加各社間での対応状況に関する情報交換などの場にしていきたいと考えております。

セミナーではなく、勉強会という形式ですので、できるだけ無料で開催し、参加者が互いに情報交換できる場にしたいと考えています。後日、詳細をホームページなどで告知したいと思います。

通常、会社は期初に予算編成を行い、それに従って事業を進めるという形式のところも多いと思います。このような会社の場合、期初に予算編成をする時点で、全体の枠が決まってしまい、システム開発についてもその枠に縛りがかかることになります。

システム開発においてこの方法が問題になるのは、その期初に予算編成する際にはまだ要件が確定していない、ということです。要件が確定する前に金額がざっくりと決まってしまうので、本来はその金額の枠内に収まるように要件を固めていかなければなりません。

しかしシステムの受注開発の場合、要件を金額の枠内に収めるためにはどうすべきかについて、明確な手法はありません。システム開発を請け負う側が頑張ってできる範囲がすべて要件の範囲となってしまい、結果としてその「頑張り」はすべて末端のプロジェクト・メンバの負担へと転嫁されてしまいます。

システムを発注する側としては、金額の枠が決められてしまっているのは事実で、いきおい「金はこれしかないけど、なんとかなりませんか？」という話になり、それが上記のような流れでシステム開発の現場は常に忙しい、となってしまっているように思います。

この循環を断ち切るにはどうしたらよいのでしょうか？

Googleのストリートビューの日本版を早速試してみました。なんと我が家が映っていました！　航空写真のときにもすごいと思ったのですが、これはそれに輪をかけてすごい。しかしいつ撮りに来ていたのだろうと思います。例のGoogleカーで撮りに来ていたのでしょうか。

私のうちは横浜なのですが、うちの近所のカバー率は結構高いように思えます。おそらく地図で青い道路はストリートビューがあると思うのですが、主要道路だけでなく、結構細めの道でもちゃんとデータがあるようです。

会社は、というと、会社の表側は遊歩道になっていて車が入れないため、残念ながらupdate it, Inc.の看板は見えなかったのですが、会社の裏の道路から会社の建物は移っていました。

ちなみに私はFireFox 3で見ているのですが、なぜか地図の下側にちゃんと描画されない領域ができてしまいます。バグかな？

Google Mapsは最初出たときの衝撃がすごく、特に外国まで地図や航空写真で見れたのが楽しくて、最初のころは暇があれば昔、香港に転勤していたときに住んでいたマンションを見つけたり、子供の時に住んでいたあたりを探索したりなど、いろいろ楽しんでいました。ただ最近は他の地図も追い付いてきた上にGoogleの反応が遅くて使いづらくなってきたため、ちょっとご無沙汰気味でした。でも久しぶりに使ってみたら、反応がかなりまともに戻った気がします。

またしばらくは使ってみて、ストリートビューにはまりたいです。（そんな暇はないですが）

@ITの記事で「注目のRIA環境JSライブラリ「Ext JS」が国内販売開始」というのが紹介されています。これはJavaScriptベースのユーザインターフェース用の部品ライブラリーです。ちょっとサンプルを見てみた（こちらのページ）のですが、これはすごい。ぜひデモを試してみてください。

Zimbra並のRIAが簡単に作れそう。JavaベースのUI構築ツールであるSwingやSWT以上のことが軽くできる気がします。

しっかし、JavaScriptでこんなものが作れるのに、なんでSwingには同様なものがないのだろうか？　（ま、SWTはネイティブだから仕方ないけど）　条件として、そんなに差があるわけではないと思うし、むしろJavaScriptでやる方が制約が大きくて難しい部分も多いと思うのですが、この差はいったいなんなのでしょうか？

Swingも次のJavaFXに期待ってことなのでしょうか？　SWTはいったいどうするんだ…　UIは進化が早いので、SWTにようにWindowsネイティブの世界に縛られているとどんどん遅れていくような気がしてきました。

今夜、予定どおりにいけば crossnoteをver 1.2.2にバージョンアップします。今回のバージョンは主に細かい使い勝手の改善で、大きな機能追加はありません。

主な内容は、
1.Proxy認証関連の修正

2.Word 97/2000ファイルの変換取り込み（暫定版）

3.質問＆課題管理表のフィルタ機能の改善

4.表の使い勝手の改善

といったところです。

ソフトウェア開発に関するデスマーチについて調べているうちに、デスマーチには敵がいることがわかりました。そうですよね。何か敵がいるから、デスマーチになるわけです。

でもどういうわけか、あまりその敵について言及しているものは少ない気がします。遠慮？　体裁？　人間関係？　仕事？　いろいろな要因が絡んでいるのでしょうが、デスマーチが如何にひどい状態かが書かれていても、その敵について詳しく書いているものはあまり多くありません。

でも何が敵なのかがはっきりしないことには、対策が打てるわけがありません。（でも上記のようなケースは、敵ははっきりしているのだけれども、対策が打てない状況を表している気もする）

ここで言う敵とは、デスマーチに至った根源的な原因です。もちろんその原因だけではなく、いろいろな要因が絡み合ってその状態になってしまうのだと思いますが、でも誰もが声には出さないまま、心の中では、「これは×××のせいだー！」っていうのがあるのではないでしょうか？

敵をあぶりだすことは、デスマーチを減らすための第一歩でしょう。

でもそれを声高に言えないという点に、デスマーチが起こるそもそもの理由があるのかも。目的をきちんと共有するなど、風通しを良くするための努力をしていれば、起こりにくくなるかもしれません。

最近、「キャズム」（ジェフリー・ムーア著、川又政治訳　翔泳社）という本を読んでいるのですが（これも同じ営業を教わっている方に勧めらた本です）、当社のようなテクノロジー・ベンダが立ち上がるには、その初期段階においてイノベータ（テクノロジー・マニア）に続いて、アーリーアダプタと呼ばれるビジョナリーが必要だ、と書いてあります。

キャズムという話は、むしろそのあとのアーリーアダプタからアーリーマジョリティに移行する際に、深い谷（キャズム）があり、難しいよ、というのがメインなのですが、今の私の関心事は、初期段階からどう離陸するのか、という点なので、ビジョナリーという言葉が強く印象に残りました。

ビジョナリーとは、自分の夢を描き、それに向けてリスクを取って行動することを厭わない人だと言えます。つまりコンサバなタイプではビジョナリーとはなり得ません。

私たちは、私たちの思い描く夢と、そのビジョナリーの夢を一緒に共有していきたい。そしてビジョナリーのためであれば、最大限の努力によって、その夢の実現し、喜びを分かち合えるようにしたいと思います。

これは、先日ブログで書いた「顧客との対話をベースに、ベストプラクティスをいち早く取り込み、誰よりも早く成長するシステムサービスを提供できること」という話とぴったり一致する戦略だと考えています。

我こそはビジョナリーだ、と思う方。ぜひコンタクトしてください。

ここのところ、アップデイティットの会社としての強みって何だろう、とずっと考えてきました。将来会社を発展させるにあたって、他の会社と何が違うのか、を明確にしなければならないからです。

ここで言う会社としての強みとは、商品の強み以外の、会社としての強みのことです。会社の成長戦略を描くうえでは、会社としてどこが他と違うのかを明確にできなければ、将来に渡る成長曲線を描くことができません。

そして最終的に達した結論が、次のことです。

「顧客との対話をベースに、ベストプラクティスをいち早く取り込み、誰よりも早く成長するシステムサービスを提供できること」

これは今まで私が過去のＳＥ時代を通して実践してきたことです。

私はもともとは金融系のＳＥとして、キャリアの大半はデリバティブやスワップ、債券トレーディングなどを扱う、フロント・ミドル分野にかかわってきました。こられの分野では売れる商品がどんどん変わり、如何にそれに先んじて対応できるかが勝負の決め手です。ですのでいつも私は顧客のそばにいて、顧客との対話をベースに彼らの望むものをいち早く提供することができるか、という点に注力してきました。

その結果、顧客の方にびっくりされるのがたまらなく好きだったんです。そして実際そうすることが、顧客の利益に結びついていたと考えています。

そしてそれを実現するためには、どのようなシステムでなければならないかを常に考え、オブジェクト指向プログラミングを実システムにいち早く導入したり、ＲＡＤ手法やイテレーション開発などを活用したりなど、その時代の最先端の仕組みをいち早く利用して、勝負を乗り切ってきました。

こういったことを通して得たノウハウが、先に書いた「顧客との対話をベースに、ベストプラクティスをいち早く取り込み、誰よりも早く成長するシステムサービスを提供できること」だと考えました。

次のステップは組織としてこれをＤＮＡとして確立し、浸透させることです。
がんばります。