update it, Inc.社長のブログ

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

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

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

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

先日、成功報酬型の業務システムの話を聞きました。そのシステムで扱ったものが売れると、1つ売れる毎にいくら、というのが決まっていて、その分お金が入る仕組みだそうです。開発元はその分リクスをとっていて、開発元がその費用の大部分を負担しているようで、導入費はかなり抑えられていると聞きました。

対象の商品が売れると儲かる仕組みです。リスクはありますが、面白い商売だと思いました。システムを使う側としては商品が売れたときにその分支払えば良いので、システムコストをあまり気にせずに導入できます。ランニングコストとしては効いてくるのですが、売れるか売れないか、売ってみないとわからないのが商売です。売れなければコスト負担が非常に少ないというのは魅力的でしょう。

言い換えると、システムの初期費用を軽くカバーできるほど売れるとわかりきっているものには、この仕組みは使われにくいのかもしれません。その場合にはシステム開発コストを負担してでも、ランニングコストを下げたほうがいい、という判断になるでしょう。

しかし大半の商品というのは、どの程度売れるのかがはっきりしないものではないでしょうか？　このようなシステムがあれば導入する側は大抵は飛びつくと思います。またシステムを売る側としても顧客が儲かれば自分も儲かるという、Win-Winの関係を築けます。

「顧客とともに栄える」非常に良い仕組みのように思いました。

システム・アーキテクチャは業務特性を十分に考慮して、想定する期間、その業務をうまく回すためのアーキテクチャとする。これはシステム設計においては基本中の基本すぎて、いまさら何か言うようなものではないと思っていたのですが、どうも世の中、必ずしもそうとは言えないケースも多々あるようです。

おそらく、眼の前にある（良く知っている）アーキテクチャ以外に選択肢がない、などの理由で最適ではないアーキテクチャが採用されることがあると思うのですが、そうして見切り発車的に作られたシステムはいずれ破たんします。

破たんする前に別のものに切り替えられればいいのですが、場合によっては（コストなどの都合で）切り替えもできずに、どうしようにもない状態になってしまう場合もあります。

システムの開発を依頼する際には、見かけの金額が安いなんてことに惑わされずに、業務特性に応じたシステム・アーキテクチャ設計が提案でき、かつ実装できる能力をもったベンダーを選ばないと、後で結局は大損してしまうことになりかねません。

また世の中で、「業務特性に応じたシステム・アーキテクチャ設計が提案でき、かつ実装できる能力をもった」人やベンダーというのは実はそんなに多くないのかもしれません。システムの世界で人不足が指摘されて久しいですが、実際にはこのような能力をもったＳＥが不足しているということなのだと思います。

最近crossnoteをubuntuで動かしています。説明するまでもないかもしれませんが、ubuntuとはLinuxのディストリビューションの１つで、デスクトップがかなり使いやすく、また見た目もなかなか「かっこいい」です。個人的な印象ですが、ubuntuを使っているとVistaですら1世代前の環境に見えます。

なんか使いやすいな、と思っていたのですが、どうも原因は早さにあるように思えます。全く同じマシン上で動かした場合でも、例えばWindows XP上での動作と比較して早く感じます。Eclipseもそうですし、crossnoteも体感上、早く動いているように思えます。

ubuntuはX Window上で動作しているので、私はどうもX Windowというと（長年付き合った相棒だったのですが）遅いイメージがあったのですが、180度認識が改まりました。

なんでこんなに早いのか？　よくわかりませんが、Anti-Virusソフトの影響はあるのでしょうか？　とにかく、ubuntuすごいです。

なおcrossnoteのLinux版はベータ段階です。そのうちお披露目しますね。

前回の続きです。プロジェクト内でメールを使う問題点を聞いたところ、他にもこんなことを教えてもらいました。

(5) ドキュメントを添付して送るとき、パスワードをかけるのが面倒

(6) 単にドキュメントを送付するだけなのに、いちいち文面を書くのが面倒

(7) 添付サイズによっては送れない場合がある。

(8) サブジェクトの振り分けルールを作って運用するのだが、うまく機能しない

こうして見てみると、前回の(3)もそうですが、ドキュメントの添付に絡む問題が多いですね。プロジェクトでドキュメントを共有したい場合に、単にファイルサーバに置くという方法では共有できないケースがありますが、そのような場合には通常はメールでの送付で済ます場合が多いと思います。

さて、いろいろと問題があるプロジェクト内でのメールの使用ですが、果たしてメールに代わる別のソリューションがある場合、それにスイッチするものでしょうか？　スイッチするのであれば、満足化原則を満たしていなかった、ということになります。

そしてそのスイッチする先がcrossnoteだと皆さんに認めてもらえるよう、がんばります。

一昨日、「最適化 vs 満足化」というテーマを書きましたが、今日はその続きです。今日はメールについて、この「最適化 vs 満足化」を考えてみたいと思います。

メールは今や誰でも使う、非常に基本的なインフラとなっています。そして普通にメールを使っている人にとっては十分便利であり、満足している人も多いと思います。なので、これより少し便利なものが別に現れたとしても、なかなか普及しないでしょう。

でも、プロジェクトなど、チーム・コラボレーションに話を絞った場合にはどうでしょうか？　チーム・コラボレーションにおいても基本ツールとしてメールは欠かせないものですが、果たしてこのシチュエーションで使っている人たちは満足して使っているのでしょうか？　ぜひ皆さんに意見を聞いてみたいのです。

私がチーム・コラボレーションにおいてメールを使っている際に感じる不満としては、こんなことがあります。

(1) 送り先を指定するのが面倒。間違えてひどい目に合うこともある（いや、あった）。

(2) 後になって、「あ、このときの議論、文書に反映されていないけど、メールでやり取りしてたな」というシチュエーションが良くあるが、探すにの骨が折れる。またこういった情報はチーム内で共有されることがない。

(3) メールに文書を添付すると様々なバージョンのドキュメントが散乱して、どれが最終版なのかがわからなくなりやすい。最悪なのは、その添付されたドキュメントを互いにやり取りし合うものだから、本当に訳が分からなくなる。

(4) 重要な質問などを送っても、相手が忙しくてほったらかしにされてしまった場合、そこでその仕事が止まってしまう。

他にはどんなことがあるでしょうか？　ぜひ教えてください。

良くある話なのですが、仕様が間違っていることに気付くことがありますよね。そんなときって、どうしますか？

影響の大きいもの、小さいものさまざまですが、仕様の間違いは結構良くある話だと思います。そんなとき、普通は「これ、間違っていませんか？」と確認します。で、間違っていたことが判明した時点で仕様変更とする。これが普通の流れです。

でも問題なのはその修正を行うためには開発工数が膨らんでしまう場合です。まるでマーフィーの法則のように、仕様の間違いが見つかると、ほぼ必ずといっていいほど工数が膨らみます。減る方向になることはほとんどありません。

間違いのまま実装してしまえば、必ずシステムは何らかのトラブルを起こすことになります。だからやっぱり修正するしかありません。じゃあその工数の増加分はだれが被るのでしょうか？

１つには発注者という考え方があります。もしその間違った仕様を考え付いたのが発注者であれば、多少ロジカルにその増加分について契約内容を検討してもらう、ということができるかもしれません。でももしその仕様を書いたところが開発も請け負っている場合には、発注元が重要な情報を提示し忘れていたために発生したということでもない限り、開発している側が被らざるを得ないかもしれません。この場合は自分のミスを自分で尻拭いするということなので、仕方がないでしょう。

ではもし、仕様を書いたところと開発を請け負っているところが異なる場合にはどうなるのでしょうか？　発注者がおそらく前フェーズで仕様書を検収しているので、仕様を書いた側に責任を転嫁するのは難しい場合があります。でも発注者はシステムの素人であるが故、仕様を作ってもらっているのですから、発注者が完璧なチェックして検収時にそのような仕様ミスを見つけるのは難しいのではないでしょうか？

工事進行基準が浸透してくると、仕様を固めるフェーズと開発（製造）フェースを分離して別契約にすることが増えてくると思いますが、その際それぞれを別会社に発注することもあると思います。仕様ミスによる工数の増大を誰が被るべきなのか、契約時にはっきりさせておく必要があると思います。

5/17に「ぴあが90─100人の希望退職者を募集、社員数の3分の1」というニュースが流れていました。なんと「チケットシステムの不具合を主因とした業績悪化を受け、人件費の圧縮を目指す」となっています。

調べてみると、今年の年初に新システムに切り替えたのだけど、それがトラブル続きで予定していたチケット販売が消化できず、業績が傾いたということらしいです。切り替えてからトラブルが頻発しているところを見ると、明らかにテスト不足だったのではないでしょうか？

今までもシステムトラブルがニュースで報じられることは多々ありましたが、システムトラブルが原因で会社が傾いたという話はまだあまり聞いていませんでした。ぴあの場合、チケットの発券業務が一番の稼ぎ頭の業務で、そこがトラブってしまってはどうしようにもないのでしょう。

私は以前、証券会社の発注系システムを担当していたことがあったのですが、この手のシステムはトラブルが非常に「こわい」です。ぴあのチケットシステムというのもある意味、発注系の一種であり、トラブルが発生すると手痛い打撃を受けます。

トラブルが発生したときのリスクを金額換算すれば、どれだけテストをしておくべきかがはっきりします。シビアなシステムでは開発費を削るなんてそもそもとんでもないことで、多少金をかけてでもきちんとやる必要があり、またきちんとそれが実行できる所に任せないと、結局は大損をしてしまうリスクが高い、ということです。ぴあのケースでもそういう感覚が経営陣に求められたのではないでしょうか？

昨日三菱東京ＵＦＪ銀行のシステム統合で障害が発生したというニュースが流れていました。今回の統合作業は世界の金融界でも異例の規模で行われる超巨大プロジェクトで、今日配信されている産経新聞からのニュースによると、「システム統合の投資費用は総額３３００億円。昨夏のピーク時には国内のシステム技術者の約２割に当たる６０００人が携わり」とあります。

国内のシステム技術者の2割が6000人？　ってことは、国内のシステム技術者の数って全部で3万人ってことになるけど、JISAや経産省の統計の値と比較してもどこからそんな値がでてくるんだ？　という突っ込みは、この際止めておきます  😕

しかし6000人費やそうが、1年間統合スケジュールを伸ばして万全を期そうが、やっぱり障害は起こるのかもしれません。しかも今回のトラブルは外部システムとの接続で発生したとのこと。難しい面も多いと思います。

マスコミは当然はやし立て、金融庁も行政処分云々という話をしていますが、これだけ大きなプロジェクトがまったくのミスなしに完了させるのは、少し不謹慎ですが、そもそも達成が無理な領域に入ってきているようにも見えます。

いっそのこと、完璧を期すために外部システムと合わせてすべてのシナリオのテストを自動的に行えるような環境を作ってテストすべきかもしれませんね。テスト用データセンターやテスト用銀行支店、テスト用ATM、テスト用他銀行などを丸ごとすべて作ってテスト用の世界を作り上げ、…
なんてことをやったら、いったいいくら金がかかるんでしょうか？

ちょっとぐらいトラぶっても大丈夫なようにできたら楽なんですけどね。

最近、いろいろな意味でビジネスインフラとしてのメールに疑問を感じることが多いです。

今日、社員の人がインターネットで注文した商品がまだ届いていないという話をしていました。楽天の店で注文をしたのですが、楽天からはすぐオーダー確認のメールが来たのだけど、店の方からはなかなか来なくて、確認のメールを送ったのだけど、それもまだ返答がない。仕方がないので電話したのですが、先方曰く、メールには返答した、商品も発送済みなのでもうすぐ届くと思う、ということでした。

先方の話が嘘でないとすれば、先方が返したメールが届かなかったことになります。その社員の人は個人のメールでやり取りしていたのですが、そのメールを受け取るまでにいくつかのスパムフィルタを介しているので、それが原因かもしれない、と話していました。でも本当のところはよくわかりません。

ちょっと別な話をすると、ビジネス上のセールス活動においても、メールはいまいち信頼性がないというか、意味が薄い媒体になってきていると思います。ちょっと前まではメルマガが流行っていた時期もありますが、今はあまりにもその類のものが多くなりすぎて、見てもらえなくなっているように思えます。

これだけ普及したインフラだけに、この状況は惜しいと思います。誰にでもコストをかけずに気軽に送れるがために、逆に信頼性の低い通信手段になり下がってしまったというわけです。

そろそろインターネット・メールとは別に、送信コストがかかる代わりに確実に相手に読んでもらえる「ビジネス・メール」の世界が出現してきてもいいように思うのですが、無理なんでしょうか？