もう去年の話ですが。
世界で始めてPersonal Computerを生み出した会社が、その事業を売却すると最初に報じられたのはNew York Timesでした。朝出勤してそのニュースを見て、コーヒーをこぼしそうになった記憶があります。

リリースによれば、IBMは6億5千万ドルの現金と、6億ドル相当のLenovoの株式を受け取る。これにより、IBMはLenovoの株式の18.9％を所有し、第2位の株主となる。また、Lenovoは約5億ドルのIBMのPC事業の負債を引き継ぐ。これらの手続きは各方面の承認を得て、2005年第2四半期に終了する予定。
(PC Watch - 2004/12/07)

IBMは現在、ノートブックPC「ThinkPad」、デスクトップPC「ThinkCentre」（旧Aptiva）を世に出していますが、Hewlet-Packard(HP)同様かなりの苦戦を強いられています。では、誰が勝ち組なのか？そう、Dell Computerです。

米IBMが売却するPC部門が過去3年半の間に9億6500万ドルの赤字を計上したことが、米証券取引委員会（SEC）に提出された文書で明らかになった。
IBMはこの文書で、PC部門が2004年上半期に1億3900万ドル、2003年に2億5800万ドル、2002年に1億7100万ドル、2001年に3億9700万ドルの赤字をそれぞれ計上したと報告した。2001年は景気低迷でPC販売が不振を極めた年だった。
（ITMedia - 2005/01/05）

ここからちょっと私的考察に入ります。
IDCのレポートにもある通り、PC市場は既に製品ライフサイクルの成熟期に当たり、今までの市場成長率、PC企業の売上を維持する事は難しいと発表していました。理由は以下の点でしょう。

・製品が普及しコモディティ化した為、機能等での差別化戦略が意味を成さなくなってきた。それに従い、差別化のドメインを「価格」にシフトせざるを得なくなり、結果的に利益率が下がった。
・メモリ、CPUの飛躍的進化に伴い、R&Dから販売までのリードタイムの短縮が要求され、消費者ニーズに合う製品を出す為のコストが累積する体質になった。

何れにしろ、これは戦略的というよりはむしろ「不採算事業の売却」と見た方がよく、パートナーにLenovoを選択したのも「東芝に断られたから」と考えるべきでしょう。
実際、IBMは、システムインテグレーション、アウトソーシング等のサービス事業の方が収益性が高く、BtoCに元々それほど注力していなかったわけですから。

この流れは、IBMがHDD部門を売却した時の流れに酷似しています。

私が最後に一人で思う事は、これにより転籍となる多くのIBMのPC事業の社員が間違いなく、人員削減のターゲットになり、それがまた多くの労働紛争の引き金となるのではないかと懸念しています。

先日、たまたまShanghaiの外注先のリーダーが来ていて雑談する機会があったのですが、彼が面白い話を紹介してくれました。それは"Bug"の由来でした（知ってる人はごめんなさい）。

"Bug"はプログラムの不具合を指す言葉で、有名なOSでも頻発していますし、システムに関わる方は「それはもういい」的な反応を示されるかと思います（苦笑）
"Bug"は英和辞書を紐解くと「虫」と訳されますが、これ、本当に虫が原因だったのです。

時は1940年代後半、米国ハーバード大学のコンピュータ開発センターでのこと。「MarkII」というリレー計算機（昔のコンピュータですね）の出荷前のテストで、どうも動作テスト結果が思わしくないという事がありました。
開発チームは、仕方なく本体の回路1つ1つをしらみつぶしに検査していきました。すると！何と本物の「蛾」がリレーの間に挟まっていたというのです。
蛾のためにリレーの接触が悪く、誤作動を起こしてしまったのですね。蛾を取り除くと正常に動作したことから、誤動作を起す原因を「バグ」、それを取り除くことを「デバッグ」と呼ぶようになったのです。
現在、誤動作を起こし、後世に「バグ」の名を残すことになった蛾は、保管元の米国海軍海面兵器センターから、スミソニアン博物館に寄贈され保管されているそうです。テスト時の操作を記録したノートにセロテープで貼り付けられている状態で。

ちなみにバグ改修に要した時間は7時間。この話をしてくれたリーダーは「なかなか優秀ですね」と笑って話してくれました。

今日はちょっとした話を（知ってる方にはつっこみどころ満載＆つまらない話ですがそこはご勘弁を…）。
Webアプリケーション（サーバサイドJavaアプリケーション等）には欠かせないデータベース。こいつとサーバサイドJavaアプリケーションを繋いでくれる素敵なJavaでの技術を、JDBCといいます（余談ですがJDBCはJava Database Connectivity の略と思われがちですが、JavaSoft の資料にはJDBCはTrade Mark（商標）であって、Abbreviation（略語）ではないと書かれています）。

詳しい仕組みは省略しますが、JDBCのコーディングの中で非常に注意しなくてはならないのが、Connectionの処理です。仕事の合間に新人さんのコーディングを見ているとこんな感じになっていました。

try{
　　Connection conn = getConnection();
　　/* DBに対する処理 */
　　conn.close();
}catch(SQLException e){
　　//Exception Handling
}

これを見て、「まずいな」と多くの熟練Java開発者さんは思うでしょう（笑）せめてこんな感じにした方が良いだろうと思い、直してみました。

try{
　　Connection conn = getConnection();
　　/* DBに対する処理 */
　　conn.commit();
}catch(SQLException e){
　　conn.rollback();
　　//Exception Handling
}finally{
　　if(conn != null){
　　　try{
　　　　conn.close();
　　　}catch(Exception e){
　　　　//Exception Handling
　　　}
　　}
}

やはり、例外処理は非常に注意しなくてはいけないと思うのです。特にDBとの連携処理を、ユーザ側からデータを受け行う場合は尚更です。処理を確定するか、元に戻した上で（commit/close）Connectionをcloseしてあげないと、DBはどんなデータを保存するか解らないのですから、慎重にならないといけません。

コンピューターは与えられた命令以外の事はこなせません。最近そんな当たり前の事にようやく気がついた今日この頃です。

*秘密日記にメッセージあります

自分の開発したモジュールの本番移管が、他のインタフェースしているシステムの決算処理と重なり、遅れまくりの今日この頃。次回のプロジェクトの提案書の作成を手伝っています。

今回のプロジェクトでは、あまりに多いインターフェースシステム間のデータのやり取りを円滑化する為、Webサービスを構築する事になったので、そのイメージを一生懸命作っているわけです。現状Webサービスという言葉を聞いた事の無い開発者は居ないと思うのですが、定義が非常に曖昧です。

「サービス提供者（プロバイダ）が提供するSOAPベースのサービス」という感じでしょうか？正直めちゃめちゃ困ってます（笑）何を困っているかと言うと...
?そもそもSOAPという通信プロトコルの正体を知らない
?XMLは知っているが、実装できる程技術力が無い
?根本的に利用技術が多すぎる

ま、何事も勉強なので、今週末にでもTeam内での議論の叩き台としてサンプルを作ってみようかと...ってまた休めないのか...。

【参考】
@IT 「SOAPとWebサービス」
http://www.atmarkit.co.jp/fxml/tanpatsu/02soap/soap04.html

Sun Microsystem 「Web サービスの効果的な使い方」
http://sdc.sun.co.jp/java/j2ee/webservices/using/webservbp.html

統合テスト前夜、嵐の前の静けさの最近。朝会社に来て色んな記事を読んでいたら、過去のこんな記事を目にしました。

Windowsへ移行するATM、セキュリティは大丈夫？（ITmedia:2003/12/08）
http://www.itmedia.co.jp/enterprise/0312/08/epi01.html

これ去年のニュースなんですけど、僕も見た事があるのですよ。
地元のみ○ほ銀行のATMでお金を下ろそうとしたある午後。目の前のATMでお客さんが立ち往生しています。若い方だったので「今時ATMの使い方もわからないのか…」と思って、ふと画面を見てみると…ええ、アレですよ。画面が一面ブルー。ちょっと目を疑ったのですけど間違いありません。
しばらくすると、画面が黒くなり、BIOSの画面へ。ええ、してましたよ、メモリ数え。更にしてましたよ、マウスとキーボード認識。ATMにマウスとキーボードがある事に驚愕していると、見慣れた旗のマークがひらひらと。ええ、Windows NT起動中ですよ。

後日全額引き出したことは言うまでもありませんが、本当に大丈夫なんでしょうか？皆さんもご存知の通り、Windowsといえばその不安定な稼動性と不審な挙動、更にはセキュリティホールだらけの欠陥ぶりで、多くの日本人の賞賛を浴びているOSなのですが、まさか銀行のATMがそうだったとは…。

正直ですね、どうかと思うのですよ。仮にもATMを作っている方々はITのスペシャリストなのですから、オープンソースのLinuxを使うとか、OS/2でガマンするとかやりようはなかったのかと。毎日Windows Updateを監視し、パッチが出たら即座に各ATMに当てまくるなんて作業を、エンドレスで行う保守担当者の姿が目に浮かび涙を禁じえません。セキュリティホールほったらかして、ウィルスにやられた日には目も当てられませんしね。

銀行の勘定系等は絶対に止まってはいけない（Mission Critical）システムの代名詞にも拘らず、敢えてWindowsを利用するあたりは、無謀なチャレンジャー精神すら垣間見えます。Windowsの利点といえば恐らく、技術者が扱い易い事のとGUIの自由度なのでしょうが、利用者はそんな事より、安全と信頼を第一に考えているのではないでしょうか。

【ちょっと知ってる方へ】
取り敢えず、組み込みなのにEmbededでない事に驚愕ですね。WindowsNTのSP5でしたから、SP6じゃないと当てられないパッチ（去年でしたっけ？結構ありました）なんかあった日にはどうするんでしょう？
ベンダー側も対処はしているようですし、専用線を使っている以上、端末に偶発的にウィルスが紛れ込む事態にはならないと思いますが、保守端末のケアが余程厳重でないといけないでしょうね。

相変わらずシステム監査で体内時計狂いまくりです。

システムというのは開発したらしっぱなしじゃいけないわけです。ものすごく当然ですけど。例えばそのシステムが銀行の勘定系と直接繋がっていたり、大量の顧客情報を扱う時等は、尚更そのシステムに不正が入り込む余地がない事を証明するのが、責務ってものなのです。

ところでエンロンって会社をご存知ですか？
この会社、元はと言えばアメリカのエネルギー企業だったのですが、次第にエネルギー先物市場において急成長を遂げた会社でした。しかし、2000年以降のアメリカの景気後退に伴い、粉飾決算をし始めました。そして2002年SECにより摘発を受けました。

実はこの事件、僕の今のシステム監査を厳しくした張本人なのです。2002年7月にこの事件の反省を受け、「企業会計改革法（サーベンス・オクスリー法）」が制定されました。要は企業の会計監査に対する目が一層厳しくなったわけです。
会計監査の法律ではありますが、同時に会計を司るシステムにも同様にその厳しい目は向けられたわけです。

思えば、エンロンの事件さえなければ、企業会計監視委員会によって会計事務所におけるコンサルティング部門の分離なんて提言も出ず、今のような（多少）不本意な仕事をする必要もなかったわけで、エンロンの経営者はとんでもない事をしてくれた、とか思う訳です。

Extreme Programming:　A gentle introduction.

http://www.extremeprogramming.org/

最近ウチの部署では「XP」（Windowsではありません）という言葉がブームです。「XP」(eXtreme Programming)というのは開発の方法論で、クライスラーでの Smalltalk によるシステム開発において、伝説のプログラマーとも言われたWard Cunningham、Martin Fowler、Ron JeffriesらとともにKent Beckが体系化したものです。
長所は上記記事で色々言われているのですが、このXPという方法論で勘違いされている点があります。

（1）仕様書は要らない

「XP」ではハッキリとした成果物が定義されていません。しいて言うなら、複数のPost-itが貼られたChartぐらいのものでしょう。
これは要求をReal Timeで汲み上げ、仕様に反映させるという事なのですが、悪く言えば「作りっぱなし」です。
保守はコード第1ですが、仕様書を参照することが多々あります。開発者が保守担当者になるのは稀なので、仕様書は非常に有効です。仕様書・設計書は、頂いたお金の対価と考えるべきだと思うのです。

（2）プログラム開発者に必須

「XP」は先程お話した通り、スーパープログラマの作った方法論です（実践原則に1日40時間労働とか書いてあるし）。万人が出来る訳ではありません。

他にもXP Value(Nearly Concept)の1つに「勇気」があったり、なかなかGeniusな方法論ですが、常に顧客の要求をシステムに反映させる即応性と、ペアプログラミングによる常時レビュー等素晴らしいコンセプトがあります。
何より開発を成功させる根本は、技術的な側面ではなく、CommunicationやFeedback等人間的な側面に依存するというのは非常に共感できます。

「XP」という方法論は、大規模開発ではサブシステムよりも更に狭い範囲で絶大な効力を発揮するのではないかと思います（勿論定義されたシステム全体の要件を変更する必要が出るような事は手戻りになるので避けますが）。

今回議題にした「XP」や構造化手法、RUP（Rational Unified Process）等の開発方法論は万能ではありません。
その長所・短所をハッキリさせ、Projectの特性によって選択するのが最良ではないかと思います。

早朝に先輩のオンライン開始に付き合っていた時にちょっと面白いものを見つけたので紹介します。先月のBusiness Weekの記事の中でMicrosoft Co.のBill Gatesがインタビューに答えていたのですが、そこで彼はこんな事を言っていました。

"You can sit on the existing [products] -- that’s a perfectly legitimate choice. This is not a soft drink where you get thirsty and say， ’I drank my word processor. Let’s have another."’

Bill Gates流のアメリカンジョークでしょうか？（笑）確かにソフトウェアというのは雨後の筍のようにボコボコ需要がでてくるものではありません。そもそも世の多くの消費者にとって、PCに必要なソフトウェアって、OS、文書作成ソフト、表計算ソフト、Webブラウザ、メールソフトぐらいのものでしょう。

Microsoftは万人が知っているソフトウェア会社で、1999年には、ダウ工業株三十種平均に選ばれる等、名実共にGEに次ぐ、アメリカを代表する企業なわけですが、需要がないと売り上げが立たないのは当然の事です。

だから「買う理由」を作る事が、ソフトウェアの売り上げには必要だという事を言っているわけですが、これだけBugばかりのSoftwareを売り出して、Bug FixだのVersion Upだので稼ごうとする姿勢が現れた一言だと思いました。
こんな発言を見ると「じゃあ、次世代OSのLonghornの『買う理由』は何？」と思わずつっこみたくもなりますが。

ただ、Bug FixだのVersion Upだので稼ごうとするのは、何もMicrosoftに限った事ではなく、業務用ソフトウェア（パッケージベンダー）も似た様な事しているわけで、ソフトウェアという特殊な製品を扱う企業の性なのかと感慨深くなった早朝なのでした。

※上記はBusiness Week記事の引用。全文はこちら。
[Business Week - Microsoft’s Midlife Crisis ]
http://www.businessweek.com/magazine/content/04_16/b3879001_mz001.htm

パコパコキーボードを叩きつつ、今日も開発しております。
以外に日記が書ける分余裕があると思いきや、土日に纏めて書いているので、もはや「日記」では無いですね。

漸く開発も佳境に差し掛かってきました。ま、半分程度ですが。いよいよ取り込んだデータをDBに保存する部分の開発になりました。フレームワークが古い為、当然JDBC(Java Data Base Connect)を利用するわけですが、世の中はEJB(Enterprise JavaBean)一色です。

The Enterprise JavaBeans architecture is an architecture for component-based distributed computing.Enterprise beans are components of distributed transaction-oriented enterprise applications.

EJBは米JavaSoftが提供する「Enterprise JavaBeans Specification v1.1 (release 12/17/99)」には上のように定義されています。
つまり、「分散トランザクションを実行する分散型エンタープライズ・アプリケーションを構築するためのコンポーネント・モデルである」という事らしいのです。
実装観点で言えば、EJBはアプリケーションサーバーのEJBコンテナで動作し、ローレベルのサービス（トランザクション制御、EJB自身のライフサイクル管理、マルチスレッド制御、各種オブジェクトのプーリングやキャッシングなど）を提供します。
特にWork Threadを使用しているWebアプリケーションの場合は、インスタンスの寿命やDBアクセスのタイミングを制御する必要があります。これらを実装する事無く、Webサービスとして制御出来るとなれば、かなり楽になるわけです。

でもですね、遅いんですよ、EJB。CMP 1.1の仕様通りの実装になると、EJBの変更の有無を判断できないので、無条件で読み出しては書き出すという処理を実行してしまうのです。
インスタンス化の度にSQLを発行していたら、いくらトランザクション管理がなされているとはいえ、サーバーリソースを無制限に使う事になってしまいます。

EJB2.0の仕様で大分改善が成されたとはいえ、まだまだJDBC隆盛は続く事でしょう。SQL発行と同時にJavaBeansをインスタンス化し、使う度にインスタンスを破棄するか、Sessionに格納すれば任意の場所でデータ使えますし（Sessionが重くなってしょうがないですけど）。

新しい技術が次々と生まれてきますが、実際使えるかは自分のスキル次第と言う事でしょうか。私の様な未熟者にはまだまだ難しい技術ではあります。
でもですね、便利な技術が沢山生まれてくるからといって、それが流行るかどうかは別問題で、そのサポートをするかは更に別問題です。作っても保守できないと意味が無いですしね。
さて、テスト仕様書書かなくては…。

開発が始まって2週間が経過しました。プログラムの設計書を起こしつつ開発・単体テストをこなし、本体プロジェクトのバグ直しとなかなか忙しい日々が続いています。

今回の機能を実現するのに大きな制約が2つありました。それは「パフォーマンス」と「フレームワーク」。今日の設計ミーティングでの議題は「フレームワーク」でした。
「フレームワーク」という言葉は、糸井重里の「オトナ語の謎。」的に「ざっくり」とした感覚で使われる事の多い言葉です。
簡単に言ってしまえば、Webアプリケーションを開発する際の必要な基盤を指します。
有名な所で言えば、JakartaプロジェクトのStruts、J2EEのMVCもこれに当たります。Webアプリケーションでは共通で使用する機能が存在します。ロギングやDBとの接続、ユーザからのリクエストを一括で処理するServlet等を備えているのが、フレームワークなのです。

長所はもちろん、慣れてしまえば開発が比較的短時間で進む事にあります。しかし、フレームワークは同時に「制約」でもあります。フレームワークは想定される利用機能の集合体であって、想定外の機能を作り込もうとした場合、とてつもなく難しい開発を迫られる事になるわけです。今回のシステムは、自社開発のフレームワークを利用しているのですが、何分古かった為、フレームワークを踏襲すると、今回実現する機能が作り込めない事が判明してしまったのです。

結局、新しくその部分の設計を、フレームワークを踏襲しつつも僅かに改造する事になりました。でも、開発スケジュールは変更されませんから、来週から更にシンドクナリソウデス。

前回の日記で書いたように、システムは使い捨てのものではありません。お客様の投資の額も半端ではないのですから、当然減価償却する（=元を取る）までは大切に利用する事になります。当然そこには保守や追加開発が付属するわけで、その拡張性までも考慮する必要があるわけです。
「新しさより保守が容易で拡張可能なものを」そんな事を学んだのでした。

今日の話をする前に、「デザインパターンって何？」って話から始めます（あんまり興味の無い方にはゴメンなさい）。
「オブジェクト指向における再利用のためのデザインパターン」を著したGoF(Gang of Four)の文書をちょっと引用しました。

Design patterns solve specific design problems and make object-oriented desings more flexiblem elegant， and ultimately reusable. They help designers reuse successful designs by basing new designs on prior experience. A designer who is familiar with such patterns can apply them immediately to design problems without having to rediscover them.

要は、「オブジェクト指向プログラミングにおいてさー、開発者は大抵同じ問題に直面するのだよ、きっと。いや、絶対。でもさ、結局皆同じパターンの解決策にたどり着くじゃん？だったらそれを予め纏めておいたら便利だよね」という事になります。

コード解析が簡単に済んだのは、以前少し勉強していたGoFのデザインパターンを知っていた事にありました。もう少し優秀なプログラマさんはきっとデザインパターンに対して一過言あることでしょう。
例えば、Factory Method パターンの場合、あまり関連のないクラスをFactory Methodの中でnewするようにしてしまうと、「なんでそんなFactory Methodを呼ばなければならないんだよ（怒）」と思考停止になり、使い方を間違えたり、解り難いコードを書いてしまう可能性が高くなるでしょう。
しかし、デザインパターンはあるプログラムのフレームが想像できると言う点で「共通言語」にもなるのです。
各デザインパターンを組み合わせて使い、そして各パターンの弱点を良く知った上で使えば、かなりいいプログラムになるのかな？と不勉強ながら実感したのでした。

【今日の勉強】
デザインパターンは万能ではない。その効能と弱点を知り、利点を最大限に活かせる様に留意すべき。