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.表の使い勝手の改善

といったところです。

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

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

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

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

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

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