SEが死ぬほど忙しいのは彼女もわかってくれるよね？

こんなマンガ見つけた。

SEが死ぬほど忙しいのは彼女もわかってくれるよね？

理解できる自分が悲しい。。
「SEの仕事は脳みそで鉄筋を組み立てているようなもんなんですよ」というどこかのフレーズを何故か理解できてしまう。。

IT土方を感じるこの頃。

Appleケア店員は優しかったヨ！

3ヶ月前に購入したお気に入りのiPodに、液晶に白いノイズが混じるようになってしまった。
先日、Apple心斎橋店に行く時があり、何とかしてもらえないか頼んでみた。

すると、購入1年以内だったということで、交換してもらえたヨ。
ラッキー♪

それ以上に驚いたのは、お気に入りのiPodに張ってある薄い透明のシールカバーをわざわざ外して、交換したiPodに張り替えてくれたこと。
セロハンテープを使って、やや手間取りながらも、丁寧に張り替えてくれた。

iPodは単なる音楽プレーヤーだけでなく携帯フォトストレージと化していたから、すごく大切にしていたからね。
Appleさん、ありがとう♪

お金ができたら、MacBookを買うかもしれないヽ(^o^)丿

量子革命がコンピュータ革命を引き起こした

埃を被った本棚から懐かしい本「サイエンス21」を見つけた。
21世紀の科学を予想する2000年に出た本。
当時、夢中で読んだ記憶がある。
その頃の感想を思い出しながら書いてみる。

【1】学習する機械は夢を見る

1980年代、物理学者ホップフィールドが、神経科学のニューラルネットワーク分野で、

脳の中にあるニューロンを格子の中の原子のように扱えるか？

という量子力学の発想を取り入れて革命を起こした。
その当時、人工知能の分野には系統だった組織原理がなく、バラバラの知識の集まりに過ぎなかった。

彼のアイデアでは、原子がエネルギーが最小になるように自らを配置するように、ニューラルネットワーク回路もそのエネルギーを最小にしなければならない。
つまり、「学習」は最も低いエネルギーを発見する過程なのだ、と。

脳内のニューロンネットをでこぼこの地形にボールを転がしている状況にたとえてみよう。

ボールはどこか一つの谷に落ちるように、絶えず最も低いエネルギーの状態(谷)を探している。
つまり、転がっているボールとは、複雑な学習過程の喩えになる。
このアイデアを発展させると、谷は「記憶」に相当する。

このモデルから、強迫観念とは、一つの谷が非常に大きくなって、近くの谷を全て飲み込んでしまった状態とも言える。

更に、このモデルが面白いのは、脳内のニューラルネットワークが夢を見始めるという発見。

ニューラルネットに多くの谷(記憶)を入れると、機能低下を起こす。
つまり、それぞれの記憶をスムーズに思い出せなく始める。

実際の記憶に相当しない好ましくないさざ波(擬似記憶、つまり夢)が地形の表面に出る。
この擬似記憶を取り除くために、故意に地形に小さな乱れを作ると、ボールは谷から投げ出されて再び転がり始める(眠りに相当する)。

眠ったり、夢見たりを何回か繰り返した後、ニューラルネットは機能低下が止まり、同じ速度で全ての記憶を思い出せるようになった(起きるに相当する)、と。

この発見の意味は、高度に発達したニューラルネットはその記憶を処理するために夢を見なければならない。
ニューラルネットに大きな負荷がかかりすぎると、夢と言う現実と異なる記憶が出てくる。
そんな夢を取り除くために眠る、と。

このアイデアは衝撃を受けたし、この発想をシステム開発で生かすとどうなるだろうか？
学習する組織、成長する開発者は、学習するにつれて、谷を増やしていく。
でも、いつかはその谷に飲み込まれてしまうことがあるだろうか？
そうならないように、夢を見るように、一度学習してできた谷を全てなくすようなプロセスが必要ではなかろうか？

そんなプロセスは、XPで言えば、週40時間労働なのかもしれない。
休息は必須なのだ、と。

【2】量子コンピュータこそ究極のコンピュータ

1980年代、ファインマンが、

コンピュータはどれくらいまで小さくなりえるか？

というアイデアで、量子コンピュータを考えた。
つまり、コンピュータを原子の大きさまで小さくした加算器と見なしてみよう、と。

例えば、沸騰した液体、二つの粒子の衝突といった事象という量子物理学の興味深い問題にチューリングマシンでは答えを出せない。
つまり、量子物理学で出てくる経路積分は無限大を計算する必要があるからだ。

彼の発想の根本は、量子の問題は量子コンピュータで計算させればいい、というもの。

量子コンピュータの理論は90年代の数学で聞いたことがある。
象徴的な結論は、量子コンピュータは全ての暗号を解くことができる、というもの。
すなわち、全ての素因数分解を解くことができることを意味している。
本当に実現されてしまうと、安全なクレジットカード決済などは全て意味がなくなってしまう。

今は量子コンピュータは、頭の中にある空想の産物に過ぎない。
でも、過去の歴史を見るように、いつかは実現されるだろう。

その時、P＝NP問題なども量子コンピュータで全て解けてしまうのだろうか？

【3】量子力学がバイオテクノロジー、コンピュータ科学の思想を根本的に書き換えた

量子力学はコンピュータ、人工知能を完全に書き換えた。
更に、バイオでも同じ現象がある。

1944年、量子物理学者シュレディンガーが「生命とは何か？」で、

生物は原子の量子論で解明できる。
分子配列の中に閉じ込められた「遺伝暗号」(彼の造語)によって生命は支配されている。

と大胆に断言して革命を起こした。
そこから、DNAの2重らせん構造の発見、DNA塩基配列の調査が始まる。

＃ちなみに、「生命とは何か？」は岩波新書で出版されていて、専門知識がなくても初心者でも読めるレベルです。
＃でも古本しかないのか。。僕は図書館で借りて読んだ記憶しかない。。

これらの事象を振り返ると、20世紀前半に生まれた量子力学が全ての科学とその現象を根底から覆して、新しいモデルを作り出したことが分かる。

サイエンス21では「量子革命がコンピュータ革命、バイオ革命を引き起こした」と言い切っている。

更に、サイエンス21では、2020年、2050年の未来も予想しているけれど、当たっているような外れているような所もあり、結構面白い。

最近のお気に入り

iPod classic(white 80G)を買った。
携帯音楽プレーヤーだけでなく、携帯フォトストレージとしても使える。
すごくイイ！

業務フローで非同期キューが現れる理由

プログラムを書くよりも「絵を描いて説明してくれ」という仕事が多くなって、いつも感じる疑問は「業務を分析する時の基本的な観点は何か？」ということ。

その疑問に対する解答のひとつとして、僕が何度も読み返している記事は下記の３つ。

１・ワークステートエンジンとは何か（はぶさんの記事）
ワークステートエンジンとは何か～Long Way To S2Buri～　その１

ワークステートエンジンとは何か～Long Way To S2Buri～　その２

２・SOAの実現: サービス設計の原則～柔軟なITのためのサービス設計（IBMの記事）

【１】業務フローの分岐が業務分析を難しくする

大抵の業務システムのプログラムは、そんなに難しいアルゴリズムを使っているわけではない。
でも、難しくなる理由は、業務フローを制御する分岐処理がデリケートだから。
分岐にはフラグとIF文が組み込まれているだけなのに、カスタマイズしていくうちに誰もが手に負えなくなる。

はぶさんの記事にある「休日判定処理」の例はすごく分かりやすい。
「完全週休２日制」から「第４土曜日は会議のため出勤」へ条件が変わった時、IF文を複雑化させていませんか？

ビジネスルールと業務要件をきちんと分離して分析していますか？

【２】フロー制御＝状態遷移、つまり業務フローはステートマシンそのもの

仕事とは、IPO（Input→Process→Output）に過ぎない。
その仕事を実行させるには、月末締めとか上司の指示待ちとか、イベントに依存する。
つまり、仕事を起動するためには、その前の仕事の状態が完了、あるいは、起動する仕事が実行状態になって、初めて動く。

だから、業務フローを制御する分岐とは、前の仕事、あるいは今の仕事の状態を判定すること。
つまり、業務フローとはステートマシンそのもの。

実装者は仕事そのもの（消費税の計算とか）の詳細に陥りがちだが、分析者は仕事がどのタイミングで切り替わるか、業務の状態管理に力点を置く。

では、状態とは何かというと、業務のライフサイクル。CRUDそのもの。
業務インスタンスは、あるタイミングで生成され、更新され、あるタイミングで消える。
まさに状態遷移図そのもの。

【３】業務の状態が重要な意味を持つ2つの理由と２つの指針

理由の一つは、業務の状態にアクターが依存するから。
例えば、支払いが完了するまでは顧客、支払いを請求する時は業務オペレーターが仕事を管轄している。
業務フローで業務が変わる時、業務に関わるアクターが変わる。
これは結構見落としやすい。

理由のもう一つは、業務の状態遷移によって、別の業務システムへ切り替わるから。
例えば、支払いが完了すると、注文システムから請求処理システムへ支払データが流れる。
業務フローで業務システムが変わると、インターフェイスのやり取りや更新の責任に注意を払う必要が出てくる。

このための指針として、IBMの記事では、下記２点を挙げている。

A・サービスはステートレス・インターフェースを持つべきである
B・サービスはステート・トランザクションを使ってモデル化すべきである

Aの意味は、仕事（サービス）に前の仕事の状態を参照しないようにすること。
前の仕事の状態の判定処理後、仕事を実行するようにすればいい。
つまり、業務状態の判定処理のIF文は、仕事の外に置くこと。

Bの意味は、仕事（サービス）の状態によって実行される仕事内容が変わるから。
業務フローごとに仕事を実行するために、業務の状態を知る必要がある。
つまり、仕事は生成され、実行され、更新され、完了すると最後は消える。

【４】非同期キューの使い道

例えば、支払いが完了すると、注文システムから請求処理システムだけでなく、別の情報系(分析系)システムへデータが流れる。
二つの別々のシステムを同時更新する時、どちらか片方が止まると、もう片方のシステムへの更新も止まってしまい利用できなくなる。

その対策として、非同期キュー機構を使う。

業務フローはいつも同期である必要はなく、むしろ非同期であってもいいし、その方が使いやすい。
先延ばしにしてよい業務処理は非同期にして、負荷をかけず、レスポンスを向上させる利点がある。
そもそも、次に実行する業務が実は手一杯で実行できない状況にあることもよくある。

更に、非同期キュー機構によって非同期キューにキューイングされているので、非同期業務がダウンしても、回復後に実行可能になる。

同期、非同期、更には非同期キューの機構はネットワークでスレッド通信で使うだけのものと思っていたが、業務フローでは自然に現れる。

業務フローが難しいのは、複雑な分岐と同期・非同期機構の使い分けにあるのではなかろうか？

【５】最後に、最近購入して、バイブルにしている２冊を紹介。

２冊ともデータモデリングの本だが、業務分析の具体例を考えるのちょうど良い。

はぶさんの本は、帳票(レシート)からモデリングする。
渡辺さんの本は、お客さんとの会話からモデリングする。

二人の性格が出ていてすごく面白い。

ソフトウェアプロダクトラインが解決しようとするもの～品質と再利用

ソフトウェア業界が生まれてからずっと抱えているテーマは、「品質」と「再利用」ではなかろうか？

構造化にせよ、オブジェクト指向にせよ、またRUPやXP、そしてソフトウェアプロダクトラインまで、全てはこの二つをいかに解決するのか、にかかっている。
そして、結局、誰もが納得する答えはまだない。

【１】何故、品質と再利用がそんなに重要なのか？
ソフトウェアは所詮、コンピュータに命令する作業手順に過ぎない。
しかし、それに修正を施して保守・運用し続けていくうちに、複雑化して最後には誰もが触れなくなるようになってしまう時がある。

システムが稼動して品質が保証されると、そのシステムはパッケージ製品・ライブラリとして再利用して、次の製品を安く高い品質で作ろうとする。
しかし、カスタマイズしていくうちに複雑化し、品質を制御できず、落ちてしまう時がある。

品質と再利用はコインの表と裏。
品質が保証されたシステム、プログラムはパッケージ製品、ライブラリとして再利用できる。
再利用できるシステム、プログラムは、色んな使い方で運用されるため、品質が保証されている。

システム、プログラムは運用されて保守されてナンボのもの。
開発時の品質はテスト品質に過ぎず、運用品質に満たない。

【２】SEA関西プロセス分科会にて感じたこと
8月末にSEA関西で、ソフトウェアプロダクトラインの本の翻訳者の講演があった。
小林さんと佐々木の話はとても分かりやすかった。
お二人のソフトウェアプロダクトラインに関する話を聞いていたら、とどまるところ「品質」と「再利用」がテーマそのものだった。
ソフトウェアプロダクトラインが解決しようとしている「品質」と「再利用」の解答は、ソフトウェア工学の知識の集大成みたいなもので、すごく自然なような印象だった。
何も難しいことは言っていない。

興味深かったことは、品質にアーキテクチャとチーム構成が関わること。
アーキテクチャと品質の関係性は当たり前。
でも、後者は、トヨタやアサヒビールの例のように、成果物の品質には、開発チームのマネジメントが密接に関わるという示唆は、最近のIT業界の人間系の流れ(ファシリテーション等)と関連があるのかもしれない。

【感想】RubyOnRails 勉強会@関西とデータモデリング

デスマーチ・プロジェクトに束の間の休日ができたので、RubyOnRails 勉強会@関西に初参加してきた。
Ruby勉強会＠関西と同じく、女子学生や女性エンジニアも多くて、華やかな雰囲気で、講演も甘辛だった。
僕はRubyOnRails初心者なので、聞きやすかった。

聴講の目的は、もちろん渡辺さんの「アジャイルにデータモデリング」。
「何故、RubyにDOAの第一人者の渡辺さんがいるの？」みたいな。

【1】RubyOnRailsに、複合キー(複数の識別子)を持つテーブルはない！？

渡辺さんのお話は、業務システムとデータモデリングの関係から始まり、テーブルの項目の関数従属性の説明と演習まで、というとても初心者向けの講義。

懇親会で業務に携わっていると言うエンジニアの女性が、
「私はRailsのインストール方法も知らない初心者だが、渡辺さんが話した関数従属性や正規化の話はとても基本的な話です」
と言っていたのが印象的だった。
後で聞いたら、Rails開発者は、データモデリングに詳しくないらしい。

RubyOnRailsで驚きなのが、複合キーを持つDAOは作れないという話。
渡辺さんは、在庫テーブルのように、品目CDと倉庫NOを主キーに持つテーブルが作れないのは痛い、と言っていたがまさにその通り。
そのために、変換テーブルを用意して、N対Nで関係付けるようにするとか話が出ていたが、大丈夫か？

【2】ActiveRecordから覗けるJavaとRubyの違い

かずひこさんとあゆさんの初心者レッスンで、ActiveRecordの説明と演習があり、とても分かりやすかった。
ActiveRecordとは、RubyOnRails用のORマッピングそのもの。

Javaに例えるなら、HibernateやSpringと同じ感覚で使える。
SQLをRubyで操作しているのと同じ感覚だった。

面白かったのは、irbを使ってActiveRecordを実演したデモ。
PersonオブジェクトとPeopleテーブルにデータをCRUDしただけなのだが、画面上半分はirbのコマンド操作で、画面下半分は実行ログで、SQLそのものが吐き出されていた。
つまり、PLSQLのようなバッチ処理を1行おきにデバッグしている感覚と同じで、感心してしまった。
ストアドプロシージャのデバッグは普通は使い物にならないから、スクリプト言語のRubyでSQLを代用する発想は面白い。

また一つ気になったのは、InsertとUpdateが同じ操作で使えること。
Javaの普通のDAOならば、Insert用マネージャとUpdate用マネージャはクラスが異なるため、意識して使い分けないといけないが、ActiveRecordならば、Rubyのオブジェクトをsaveする操作だけでいい。

【3】RubyOnRailsの弱点と可能性

DOAをやっている人から見れば、【1】のような弱点がある限り、RubyOnRailsは多分、実用的ではない。
モデリングとは、データ構造を明確に定義するのが基本だから、モデラーさんから見ると頼りないのかもしれない。

でも、ORマッピングをここまで簡単に自動生成できる環境はすごく魅力的。

モデリングは大事だけれども、データ構造(クラス図、ER図)を作っただけではシステムは動かない。
データ構造を操作する処理を入れるためにORマッピングが必要だけれども、今まで、ORマッピングがどのオブジェクト指向言語でもクリティカルポイントになっていた。
ORマッピングは、Javaをやっている人ならいつもこの箇所で開発の半分を浪費してしまうブラックボックスみたいな無駄な作業。

Rubyなら、スクリプト言語という利点も生かし、SQLをデバッグする感覚で作れてしまう。
「From Java to Ruby」という本が既に売られているようだが、今後、この流れが少しずつ発展していくような気がする。

【余談】
かずひこさんが、RubyOnRailsの本を紹介していました。
表紙の機関車の意味は何でしょう？

【告知】XP祭り関西2006 in ワッハ上方

※注意：
早めの申込をお勧めします。
6月のRubyカンファレンス、8月のLLカンファレンスと同じく、多分すぐに売り切れになると思います。

～参加する～実践する～体感型イベント
『XP祭り関西2006 in ワッハ上方』を９月３０日（土）に開催します。

=====================================================================
ＸＰ祭り関西２００６
～ We love XP! Let's join us! ～

参加する、実践する、体感型イベント
『ＸＰ祭り関西２００６ ｉｎ ワッハ上方 』

http://xpmaturi-kansai.org/top.html
---------------------------------------------------------------------

東京にて毎年恒例のXP祭り（アジャイル開発手法で有名なエクストリー
ム・プログラミングの祭典）が、ついに関西で実現。

あの上方演芸の伝道の地『ワッハ上方』で大阪独特の「笑いの文化」と
豪華スピーカー陣との夢のコラボレーションが実現しました！？

プロジェクト・ファシリテーションを提唱されておりアジャイル開発の
第一人者でもある平鍋健児氏、 日本発オブジェクト指向スクリプト言語
Rubyの作者、まつもとゆきひろ氏、そして国際ファシリテーション協会
理事の本間直人氏らの豪華スピーカー陣！
そのほかにも、関西に由来のあるエンジニアが集まります。

ぜひ、XP祭りにご参加いただき、現場で楽しく開発していくためのエネ
ルギーを持ち帰って欲しいと願います。

多くのゲストの方のご参加をお待ちしております。

～ We love XP! Let's join us! ～

◆開催概要
日　時：2006年9月30日　10:00開場～16:00
場　所：大阪が誇る笑いの殿堂『ワッハ上方』（なんば駅徒歩5分）
主　催：日本XPユーザグループ 関西支部
後　援：アジャイルプロセス協議会
　　　　ソフトウェア技術者協会 関西支部
定　員：300名
参加費：2,000円（前売り）

当日プログラム終了後、スピーカーの方々と共に懇親会を予定しています。

プログラムなどの詳細は、XP祭り関西のWebサイト
http://xpmaturi-kansai.org/top.html
をご覧ください。

※申し込み予約ページは準備中です。今しばらくお待ちください。

※協賛スポンサー様募集中です。よろしくお願いいたします。

お問い合わせは下記までご連絡ください。
omatsuri@xpmaturi-kansai.org

Ruby関西はかなり甘口です

　第11回 Ruby勉強会＠関西に行ってきた。
　丁度、京都で祇園祭が開かれていたから、受付のあゆさんが浴衣姿で、華やいだ感じでした。
　今回も50人以上も集まり、女性も随分いて、ITセミナーとは思えない雰囲気でした。

　講演内容は、回を経るに従って、初心者も聞きやすいように甘口になっている。
　気づいた点は下記の通り。

【1】かずひこさんのレッスンで、あるチームが、yieldを使ったプログラムを発表していた。
　Rubyのyieldの使い方が良く分かっていなかったが、これはまさに、コールバックそのものじゃないの！

class Array
def find3
each do |n|
return true if n == 3
end
false
end

def myfind
each do |elem|
return elem if yield(elem)
end
nil
end
end

p [1, 2, 3].find3 # => true
p [1, 2, 3].myfind {|n| n == 3} # => 3
p [1, 2].myfind {|n| n == 3} # => nil

　このプログラムの構造は、C言語のクイックソートと全く同じ。
　なるほど、だから、IteratorはRubyで重要なんだ。

【2】かずひこさんに聞いてみたら、オブジェクト倶楽部の聴衆はまるで職業軍人の集まりでした、と言っていたのが面白かった。
　いわく。彼らは仕事でしかプログラムを書かない職業軍人だが、オープンソースの僕たちは趣味でもプログラムを書いている。ちょっと雰囲気がアウェーでした。
　あちこちで講演するにつれて、逆にもっと勉強しないと、と思うようになりました、と。

　このコミュニティは、アットホームで面白いです。
　どんどん甘口になっているけれど、そろそろ中辛程度のマニアックな講演も聞きたいこの頃。

【感想】SEA Forum in Osaka～アスペクト指向技術は実用に使えるか

　「SEA Forum in Osaka～アスペクト指向技術は実用に使えるか」セミナーへ行ってきた。
　和気藹々、そして白熱したパネルディスカッションもあり、面白かったー。

　2年前に刺激を受けたＡｓｐｅｃｔセミナーでは、アスペクトは非機能要件でしか使えないという話だったが、技術は確実に進んでいた。

【1】Aspectを使うコツはポイントカットにある（増岡さんの講演から）

　東大の増岡さんの講演は、初心者向けのお話で、例が多くて分かりやすかった。
　その中で、before, after, aroundなどのアドバイスを図形エディタで使ったサンプルを良く見ると、メソッド呼び出しのタイミング(ポイントカット)に制約をつけるのがキーだった。
　cflowのようにメソッド呼び出しスタックの履歴を使って、メソッド呼び出し先に他のメソッドが呼ばれているかチェックできる例もあった。

　後のディスカッションでも、ポイントカットの研究は盛んで、メソッド呼び出しの実行履歴からアドバイスを制御する研究もあるらしい。

　ポイントカットを使った他の例として、関数呼び出しのルールをアスペクトで書くツールの紹介もあった。
　FindBugsとかLintみたいなものかな。
　こういうツールは品質を高めるのに使えそう。

【2】アノテーションを使えば、Aspectをより簡単に使いこなせる(山根さんの講演から)

　ポイントカットを書く時に、どのメソッド呼び出しを制御するか、というために、メソッド名を正規表現でマッチするものを選択する手法しか今までなかった。
　だから、フレームワークのように、将来のシステムでも修正作業が閉じていないシステムではリスクがあると言う問題があった。
　アノテーションを使うと、メソッド名にタグ付けすることによって、ポイントカットするメソッドを特定できるようになるので、より安全にAspectを使えるという話。
　この手法は、Ｊａｖａだけでなく、Ｃ＃でも使えるね。

【3】Aspectの思想は、SoftwareProductLineに通じる

　パネルディスカッションで、小林さんが、Aspectとソフトウェアプロダクトラインに関連があると指摘した点は非常に興味を持った。
　どうやら、メソッドの振る舞いに着目するアスペクトと、ソースの変化に着目するソフトウェアプロダクトラインは動機こそ違う。
　でも、オブジェクト指向のようなクラス単位ではなく、フィーチャーという構造化設計のような機能単位で機能を切り出す点が似通っているようで、ＡＯＰとソフトウェアプロダクトラインを組み合わせた研究も韓国の研究者がやっているらしい。

　関西のＩＴ業界は、組み込み系技術者が多い。
　その組み込み系プロジェクトでは、製品ごとに機能を少しだけ変えるプロジェクトが多い背景から、ソフトウェアプロダクトラインに興味を持つ人は多い。
　アスペクト志向をそんな視点から考える発想はすごく刺激的だった。

　アスペクトにしてもソフトウェアプロダクトラインにしても、プログラムの再利用について、一つの解決方法を提示している。
　この2つの話はちょっと目が離せないな。