「三菱東京UFJ銀行は5月12日、情報システムの一本化をいよいよ始めたが、大きなトラブルは無く、年末まで続く一本化作業はまずまずの滑り出しとなった」 こういう書き出しと論旨の一文を書いて公開したら、読者の皆様の多くは「テレビや新聞は、12日から13日にかけてシステム障害が発生と大々的に報じていたではないか」と首をひねるに違いない。「まずまずの滑り出し」と筆者が書きたいのは、システム全体を見渡すときちんと動いており、一部で発生した不具合を当日すぐに修復できたからだ。 筆者は4月23日付本欄で「失敗を期待するマスメディアを裏切って、三菱東京UFJ銀は一本化プロジェクトを成功させると確信している」（関連記事「失敗を待つマスメディアの監視下、システム一本化を始める三菱東京UFJ銀行」）と書いた。続く4月24日には、IT（情報技術）専門家向けウェブサイト「ITpro」のコラム欄に「この巨大システムは

Rails勉強会@東京 第30回の懇親会の席で話していて、 id:takahashim さんがハッとすることを言った。バグバグなコードは負債であると。 バグバグなコードは、それだけでメンテに定常的な出費を産む。書き直せばそのコストはいらないのに。バグバグなコードはあらゆる危険性を産む。なまじモノがあるだけについコードを無条件に資産と見なしてしまいがちだが、実は怪しいコードは負債であると。 そして、でっち上げのコードが必要な場合も確かに存在するのだ、とも。「無借金経営だけが経営じゃない」そうだ。なるほどね。 ここで、自動化されたテストケースが存在しないことをもって負債と見なす、と基準を定めよう。テスト可能性が担保されていればそのコードはそれなりに安全であるわけだし、差し換えもローコストなわけなので。「レガシーコード = テストが存在しないコード」という定義は『 Working Effecti

まぁ当たり前のことなんだけれども。世の中には2テラバイト／Dayのデータ転送を行わないといけないミッションも当然だが存在する。そんな転送を信じられないぐらいアナログに解決した事例をみつけて思わず笑ってしまいつつ、企画マンとして面白いなぁと思ったので紹介したい。 「遅いネットワークより、犬が咥えたフロッピーディスクの方が速くて確実」 http://www.hpc.co.jp/hit/B-Introduction/IA-DataCenter-ALOS2.html 衛星から送られてくる巨大な生データを地点Aで受信、地点Bにある研究所で画像解析する、というミッションにおいて転送量が200G/dayに及ぶため、2テラのNASを毎日宅急便でピストン輸送するという暴挙に出た、という話。 まぁもう3年も前の話なので今では回線の値段も下がり、200Gというデータの話だけいえば回線で送ったほうがいいんじゃねぇ

三菱東京UFJ銀行の一部キャッシュカードが、5月12日の午前7時から約5時間セブン銀行のATMで使えなくなった原因が分かった。三菱東京UFJ銀のシステムからセブン銀のシステムに送信する取引結果データの文字コードに誤りがあり、セブン銀のシステムが取引結果を正常に処理できなかった。約2万件の取引が影響を受けた。 取引ができなかったのは、取引対象が旧東京三菱銀の店舗の口座で、かつ通帳に未記入の明細が10件以上あるときに限られる。この条件を満たす場合、三菱東京UFJ銀のシステムは、通帳記帳を促す案内文を取引結果データに加えて、セブン銀に送信する。この案内文はカタカナだけを使用すると両行で取り決めていた。 一方、三菱東京UFJ銀は5月10日の夜9時から12日朝7時までシステムを臨時停止し、旧東京三菱銀ベースの勘定系システムに旧UFJ銀の機能を追加した新システムを稼働するための切り替え作業を実施した。

ことの発端はこの辺。 国際的に競争力のある産業の中核で働いているエンジニアは幸福感がある。 確かに、国際的に競争力のある産業の中核で働いているエンジニアは幸福感があるかもしれない(これも怪しいと思うけどね)けど、こんな風にかかれると、国際的に競争力のある産業の中核以外で働いているエンジニアは、幸福感は得られないという主張に見える。 残念ながら，日本のソフトウエア業界というのは過去の歴史において国際競争力を持ち得なかった。 あるいは、新しいところで競争力を生んでほしいですよね。ネットの世界はこれからなんです。まだ勝負がついていない。 いわゆるシステム・インテグレーションの業界は，1970年台から競争が始まって，30年かかって今の秩序ができあがった。30年かかってできたインダストリの構造を，ひとりふたりが頑張ったって変えられないですよね この文章の裏には、日本のソフトウエア業界は過去の歴史にお

UnicodeがASCIIを追い越し、World Wide Web上で最も多く利用されている文字コード体系になったとGoogleのシニアインターナショナルソフトウェアアーキテクトMark Davis氏がブログで述べている。また、UnicodeはASCIIだけでなく、Western Europeanもほぼ同時に追い越している。 Unicodeは多くの言語に対応した標準文字コード体系で、発音区別符号などを利用したローマ字なども扱っている。何十年も前に定められたASCIIコードは128文字あるいは256文字（ASCIIで128 文字、拡張ASCIIで256文字）しか表現できず、タイプライターの影響を受けた同文字コードの拡張は苦戦している。 UnicodeがASCIIとWestern Europeanを追い越したのは12月で、双方が追い越された日は10日も違わなかった。 Unicodeの動きについ

大学院卒業を目前に控えたある日。携帯電話が鳴った。父からだ。「お前の実印、どこだ？」。何のことか分からないまま答えた。「机の2番目の引き出しにあるよ」 その実印で父は、1つの会社を登記した。「株式会社ワディット」。名字の「和田」と「IT」をひっつけた。父の和田正則さん（59）と息子の裕介さん（26）、2人だけのIT企業。所在地は神奈川県鎌倉市。自宅だ。 社長は裕介さん。「大学院を卒業したら、いきなり社長になっていた。特に会社でやりたいこととか、なかったんですが……」。2006年9月、24歳のころだった。 Webの「あちら側」「こちら側」という考え方がある。梅田望夫さんが「ウェブ進化論」（ちくま新書）で提唱して広まった。あちら側とはGoogleやAmazonなどがサービス展開するWebの世界。こちら側とは、企業内の情報システムなどローカル環境のことを指す。 「あちら側とこちら側をつなぐ試みは

プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら

最盛期の開発要員6000人，開発工数11万人月，投資額2500億円，取引件数1日1億件。三菱東京UFJ銀行が「Day2」と呼ぶ，勘定系システム一本化プロジェクトの成果物である。6000人のシステムズエンジニア（SE）が作り上げた巨大システムは，2008年5月の連休明けに必ず動くはずだ。 23年間にわたって情報システム開発プロジェクトの取材を続けているが，6000人のSEを集めた事例は過去に一度も見聞きしたことがない。世界を見渡してもおそらく例がないはずだ。これから何年間，記者を続けるのか分からないが，今回の三菱東京UFJ銀行を除けば，6000人を動員するプロジェクトを取材する機会は二度とないだろう。 6000人のSEが同時期に集まったのであって，「6000人月」ではない。開発工数は先に書いた通り，11万人月である。この数字も凄い。一体何を作ったのかと思ってしまう。正確にはこのSEパワーは開

今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 これまでは、「ユニットテストは、できる

今の彼氏は、一応エリートと言われる職種についているんですが、年収が微妙です。最終的には3000万くらいにはなるみたいですが、それってすっごいお金持ちってわけじゃないですよね？外資系の証券会社なら億単位で稼ぐ人もいるって聞きますし。どうしたらそうした人達と付き合えるんでしょうか？結構出会いは多いほうだと思うんですが、いつも想像したのより年収が低くてがっかりしています。将来、出世してお金を稼ぐようになる男の人を見抜くコツを教えてください！付き合う前から年収を聞くなんてことはできません。将来性をどうしたら見抜けるのでしょうか？ ちなみに二十歳の学生です。今まで付き合った人とは全員合コンで出会っています！出世している旦那さんや彼氏をお持ちの方がいたら、是非とも教えてもらいたいです。 これを見てむかついたあなた。わかります。でも、あなたも、彼氏/彼女/フレームワークを将来性とかで選んでませんか? は

クロスコミュニティカンファレンスの「ITゼネコンをぶっつぶせ」BOFですが、時間が参加しにくいという意見があったので、18:40分開始に変更しました。また、時間も90分に延長し、後半の4,50分は、会場の皆さんとのディスカッションにあてたいと思います。 ITゼネコンの問題点を指摘したい方、ITゼネコンを倒すアイディアがある方、是非、会場にお越しください。 http://www.java-users.jp/contents/events/ccc2008spring/sessions.html#BOF2 また、当日参加できない方でも、いろんな意見をお持ちの方がいらっしゃると思います。「はてぶ」や「はてだ」のコメントなり、トラックバックなりで、引き続きみんなで考えましょう。 「ISIDだってITゼネコンじゃん」と思う方もいらっしゃるでしょう。昔は、そんなこともありましたが、最近は違います。「丸投

ユーザーの要件定義があいまいでシステム開発中も修正に次ぐ修正。プロジェクトは大幅に遅れて、予算が超過。しわ寄せは下請け、孫請けへ。デスマーチ……。新3Kともいわれるこんな日本のIT業界が2009年4月に大きく変わるかもしれない。そのきっかけとなるのが「工事進行基準」の原則義務付けだ。 【関連記事】 工事進行基準を分かりやすく解説してみよう【基本編】 工事進行基準を分かりやすく解説してみよう【対応編】 工事進行基準（用語解説）とは会計基準の変更によって2009年4月にシステム・インテグレータ（SIer）など受注ソフトウェア開発業に原則として義務付けられる収益の計上方法。開発期間中にその売り上げと原価（費用）を、工事（ソフトウェア開発、システム開発）の進捗度に応じて、分散して計上する仕組みだ。 これまでSIerは、工事進行基準ではなく、開発終了時に売り上げと原価を一括計上できる「工事完成基準」

ということである。そのようなプログラムがネット上に無数に公開されている。オープンソースを利用すれば，無駄なコードを書かなくてもよくなるので，短期開発が求められるWebシステムなどでの採用が当たり前になってきた。ジャンルも幅広い。LinuxのようなOSからPerl，PHP，Python，Rubyといった開発言語，Ruby On RailsのようなWebフレームワークまである。 オープンソースの利用や修正は自由ではあるが，無料だと思ってはいけない。何かトラブルが起きた際に，オープンソースは，商用製品のように問い合わせたり対応してもらえたりすることは基本的にない。問い合わせ対応をしてくれるベンダーもあるが，そういうベンダーのサービスを受けるには，コストを払わなければならないのである。例えば，レッドハットが提供している「Red Hat Enterprise Linux」を利用して，サポートを受ける

昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保

「自動車のような産業構造に再編すべきだ」。NTTデータの山下徹社長はインドや中国など海外ソフト会社が日本市場に本格進出してくる前に、ソフト産業の構造改革を実行する必要性を説く。日本のソフト産業が崩壊の危機にあるからだ。 パッケージベンダが自動車産業を参考にするのは、100歩譲るとありかもしれない。消費者に受け入れられるだろうという予想にもとづきプロダクトを開発していくモデルだから。 でも、やっぱないな。車は、多少の違いがあっても、どれも基本的な構造は同じ。パッケージは、いろんなものがあるからね。 それに対して、SIは一品ものだもの。規格(パッケージ)通りじゃないものを作るのがSIです。 マフラーだけを作るソフト部品会社、タイヤだけを作るソフト部品会社と、システムインテグレータと呼ぶシステム組み立て会社に分業化することで、インテグレータはソフト部品会社から調達した部品を組み合わせてシステムを

「MacBook Airの外観は無駄がなくてスマートですけど，中身は無駄ばかりってことですか？」。作業の後に宇野記者が発したこの一言が，分解を終えた技術者たちの感想を代弁していた。 日経エレクトロニクス分解班は，国内大手パソコン・メーカーの技術者複数名の協力を得て，再生が困難なところまでMacBook Airを解体してしてみた。その結果明らかになったのは，意外な内部構造だった。参加した技術者たちは，「事前の想像と全く違った」「ODMの製品も含めて，これまで見たどんなパソコンとも違う」と振り返る。 技術者一同を驚かせたのは，非常にコストのかかる作りになっていたことである。例えば，部品を固定するネジの本数が極めて多い。キーボードを据え付けるものだけで，30本ほどもある。「全体のネジの本数は，うちの会社が作る場合と比べて数倍」（技術者の一人）。上下の筐体をつなぐヒンジや外装部品の内面を見た技術者