update it, Inc.社長のブログ

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

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

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

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

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

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

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

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

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

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

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

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

ZD Net Japanのちょっと前の記事で、勝者と敗者を明確にするところに真の価値がある – Enterprise 2.0 SUMMITレポートというのを読みました。Enterprise 2.0という言葉は、ここで質問に答えているハーバードビジネススクール准教授のAndrew McAfee氏が提唱した言葉だったんですね。

ちょっと注目したのが、McAfee氏が「9X Problem」と呼んでいるものです。簡単に言うと、既にあるツールと新しいツールを比較する場合、使い慣れたものは3倍良く評価され、新しいものは3分の1の価値でしか評価しれもらえないので、既にあるツールを新しいツールで置き換えるには9倍以上いいものでないと受け入れてもらえないよ、ということらしいです。

9倍ねぇ。ボタンが9倍でかいとか、文字が9倍でかいというのならすぐわかるのですが、「良さ」が9倍というのは実際なんのことか、よくわかりません。ただ言わんとしていることは、革新的に良くならないと、ツールの移行は進まない、ということなのですね。

McAfee氏によると、Enterprise 2.0とは「企業内や企業間、あるいはパートナーや顧客との間で自由にソーシャルソフトウェアプラットフォームを活用する」ことらしいのですが、ここで言うソーシャルソフトウェアプラットフォームとはあるグループ内でコミュニケーションや情報共有を行うためのソフトウェアのことです。

一般にコミュニケーションや情報共有をする際には文章や図などを書いて、それをみんなに読んでもらう、という形式が一般的です。メールもWikiも掲示板も、結局のところ「何かを書いて、みんなに見てもらう」ということをシステム上で実現しているのに過ぎません。

9倍ルールで革新的に良くなろうとした場合、そもそもこの基本的な「何かを書いて、みんなに見てもらう」という部分を変えない限り、なかなか難しい気がします。この基本路線が同じである限り、目先を変えたところで「同類」とみなされてしまうのではないでしょうか？

「何かを書いて、みんなに見てもらう」という部分から離れて、システムにしかできない新しいコミュニケーションのあり方を実現したときに、初めて革新的なコミュニケーション手段が生まれると考えています。

# それがcrossnoteでありますよーに。 😎

最近きちんと技術情報をウオッチできていなくて、JavaOneが始まっていたのに気付きませんでした。なんてこった。

でもなんというか、Javaってだいぶコモディティー化した技術になってきていて、悪く言えば新鮮さに欠けてきているように思えます。実際ITMediaのNewsには今時点ではJavaOneのニュースが１つも入っていません。＠ＩＴ側は１つ入っていますけど。

ニュースの内容もJava FXがメインなのでしょうか？　AIRやSilverlightについで第3のRIA構築ツールとしての登場ですが、なかなか両者に対するアドバンテージを得るのは難しいのではないかと思えます。というか、どれも勝者にならなかったりして…

Java FXの話を聞くと、JSFを思い出します。あれほど騒いだのに、今現在JSFで開発されているという話はごく少数です。（結局ほとんどがStrutsベース）　まだまだ開発途上なので、これから増える可能性は否定できませんが、ちょっと期待はずれの部分があったのは確かです。

Java FXが同じ運命をたどらないと良いのですが、どうなのでしょうかね？

5月3日にMicrosoftがYahoo!に対する買収提案を取り下げた、というニュースが流れていました。やっぱり根底にあるのは、Yahoo!としてはMicrosoftに飲み込まれてしまうのがいやだったのではないかと私は勝手に推測してしまいました。

会社は誰のもの？という問いかけに対して、「株主のもの」という教科書的な答えだけで考えるとMicrosoftの提案に乗って巨額の利益を得たほうがよかったのかもしれません。でも会社は営利組織であっても、単に「金儲けだけのための存在」ではありません。社員や創業者たちの特別な思いが詰まったものでもあり、さらにはさまざまな社会的責任がある器でもあります。

新しいＩＴ企業はみな、何らかの形でMicrosoftを目標にしているのではないでしょうか？　ITの業界でもっとも成功した企業であるだけに、Microsoftを抜くことを究極の目標に掲げて励んでいる会社も結構あるのではないでしょうか？

Yahoo!もネット企業の雄として、Microsoftを目標に掲げてきた部分があるのではないでしょうか？　そうやって頑張ってきている社員達がいる中で、いきなり飲み込まれしまう、というのも割り切れない思いがあるのではないかと、私は勝手に推測しています。

ちょっと前に工事進行基準の話に触れましたが、正直なところ、実務的なところがまだよくわかっていません。特に

■赤字プロジェクトの予定見積総原価の見直しはいつ行う？

■仕様変更による収益の変更管理はどうすべき？

などなど、実際にやってみないとよくわからないことだらけです。

仕様変更は、あらかじめバッファというか費用のプールを用意しておいて、期間内で発生する仕様変更をそのプールから取り崩して行う場合が多いと思いますが、その場合でも1件1件きちんと収益管理していくことが求められそうです。現場はその都度正確な見積もりを作って計上し、管理していかなければならないので、これだけで大変なことになると思います。

また要件のベースライン管理も重要になってきます。どこまで要件の範囲か、ということをきっちり詰めなければならないからです。

こうなってくると、要件に対して実現(実装)方法がいくつか考えられるような場合、お客様にとって一番良い解決方法を探る、ということがやりにくくなったように思えます。やりたいこと=要件に対してその実現(実装)方法は1つではありません。それを要件定義段階で事細かに指定しなかった場合には、たとえ多少難がある場合でも要件を満たしてさえいればそれで押し切ってしまう（お客様からみれば押し切られてしまう）ケースが多くなるのではないでしょうか？

結局、システム開発においては準委任契約で行える上流工程の比重が増し、単なる開発工程が圧縮される形になるのかもしれません。

またこの形態が一般化すると、開発工程のオフショア化が一層進展する可能性もあるかもしれません。日本国内では準委任契約の工程のみを行い、開発工程はオフショアで行う、といった感じです。今まではオフショア開発で行う場合、いちいち事細かに要件を定義しなければその通りに作ってくれないという部分があったと思いますが、これからは国内でもそうしなければならなくなる、ということになり、国内での開発メリットが低下することが予想されます。

一方で、受託業務ではアジャイル開発はかなり難しくなりそうですね。研究開発的な要素の大きい自社のパッケージ開発のような場合でないとアジャイル的な仕事の進め方はできなくなってしまうのではないでしょうか？

いずれにせよ、いろいろとインパクトがありそうですね…