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

こんなマンガ見つけた。

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

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

IT土方を感じるこの頃。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

１・ワークステートエンジンとは何か（はぶさんの記事）
ワークステートエンジンとは何か～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つの話はちょっと目が離せないな。

【感想】Kansai.pm 第1回Perl翻訳フェスタ

Kansai.pm 第1回Perl翻訳フェスタへ行ってきた。
このイベントは、Perl愛好者がPerlライブラリなどの英語ドキュメントを翻訳して公開しようという企画。
10人ほど集まって和気あいあいの雰囲気で、前回の勉強会と違って面白かった。

【1】翻訳支援ツール　OmegaT　で翻訳してみる

　翻訳は、Diffやバージョン管理が面倒なため、支援ツール　OmegaTで翻訳してみることになった。
　文節ごとに区切られた前回の翻訳文章を覚えてファジー翻訳など、コード補完の様な機能が付いていたり、結構面白い。
　でも、作成途中のベータ版らしく、スペルチェック、バージョン管理などの機能はまだまだ。

　慣れている人は、8時間で400字詰め原稿用紙10～20枚翻訳していくらしい。僕は全然でした。。

※参考：OmegaTのYahooGroup

　オープンソースライブラリの翻訳活動は、完全にボランティア。
　バージョンアップに追いつけず、やる気がなくなると、ドキュメントはすぐに古くなるらしい。
　また、個人のHPに翻訳ドキュメントを置いていると消失してしまう危険性があるから、なるべくライブラリ本体のHPへUploadしてほしいとのことでした。
　色んな気遣いや注意があるようだ。

【2】SkypeでOmegaT作成者Jean-Christophe Helaryから説明を受ける

　皆初めて使うツールなので、作成者からじきじきにレクチャを受けた。
　Skypeは仕事でも使う時はあるけど、こういう場面で自然に使えるんだよなあ。
　音声だけなのですが、内臓マイクを通して会話して、プロジェクターに映った画面を見ながら操作するのは、見てて面白かった。

【3】Haskell のレクチャを受ける

　昼食後の休憩時間に、まだ世に出ていないPerl6のインタプリタはHaskellで作られているらしいという雑談から、Haskell のデモを見せてもらった。
　Haskell を見るのは初めてですが、「 0 + "hello"」をエラーとしてしまう強い型チェック、モデルの証明のような論理を構成して検証するのがやりやすいという特徴などの話を聞いた。
　Javaでようやく導入されたGenericsも、Haskell には元々付属している機能だと言う。
　色んなデータ型を作りやすいから、Perl6のインタプリタ機構も作れたんですよ、と言う。

　オブジェクト倶楽部でも連載が始まったけど、密かなブームなのだろうか？？

　Perl関西は他のコミュニティと違って、ノートPCがMac、Linux使いの人が多かったり、オープンソースの活動に詳しい人も多く、技術的に面白い。

積読リスト

　4月から購入して読んでいる本たちは下記の3冊。
　システム工学、モデリング、ファシリテーションと様々。興味が発散しているかも。

　システム工学の辞書みたいな本。集中して読まないと難しい。。

　SEに必要なモデリング技術をまとめた本。
　通勤電車で読めるような楽な本だが、内容は濃い。
　問題解決に必要なスキル、考え方について、的確にまとめられている。
　この本に書かれているツールを自分流に解釈すると、PGならデシジョンテーブルやステートチャート図、SEならワークフローと機能モデル(プロセス図に近い)が重要かな。

　プロジェクトマネージャに必要なスキルをまとめた本。
　この本も通勤電車で読める気楽な本だが、色々考えさせられる。
　ファシリテーション、コーチングが最近のIT業界でも流行しているが、コーチングのようにパラダイムシフトが重要なものは、システム思考の発想がすごく重要。
　結局、ファシリテーションやコーチングはリーダーシップを後天的に鍛えるツールだな、と改めて実感する。

　落ち着いたら、もう少し詳しく書いてみたい。

ソフトウェアプロダクトラインとXPは何が違うのか？

細谷さん、トラックバックありがとう。
ソフトウェアプロダクトラインとXPの違いについて考えたことを記述しておく。

【それぞれの定義】
1.ソフトウェアプロダクトライン

2.XP

【1】ソフトウェアプロダクトライン
　品質を保持するには、インフラに近いレイヤーはできるだけ変えず、アプリケーションやUIに近い部分は変更可能とするように設計する。
　これはビジネスの要求に対し、コアとなる部分は再利用可能な資産とし、それぞれの顧客に対してカスタマイズする戦略を取る。
　当然、変化しやすい部分と変化しにくい部分をアーキテクチャだけでなくビジネスドメインの観点からも切り分ける。
　
　対象とするシステムの境界は、ソフトウェアやDBだけでなく、ネットワークインフラやハードウェアまで含む。
　だからこそ、再利用できるものとそうでないもの区別が大切なのだろう。
　
　また、ビジネス関係者だけでなく、ハード開発者、ソフト開発者などと利害関係者が多すぎる。
　ゆえに、意思決定を持つグループと権限はないが影響力を持つ開発グループでワークショップを定期的に開いて意見交換するプロセスも内部に持つ。
　
　この開発スタイルがマッチする例は、組み込み系のように、似たような仕様の製品を少数生産する時だろう。

【2】XP
　過剰な設計、過剰な仕様書、過剰な機能実装は不要だ。再利用することを考えるよりもYANGIを重視する。
　まずはシンプルに作り、早期リリースと頻繁なリリースでシステムを成長させていく。
　リーンソフトウェア開発の1個流しという概念が似ている。
　
　テスト駆動、リファクタリングなどのプログラミング技術で品質をカバーする。プログラマの観点からすると、この技術が面白い。
　だが、プログラミングは重視するが、インフラやハードまで意識していない時が多い。
　
　当然、変化しないものはなく、変化は受け入れるものであり、変化を受け入れる環境や技術を重視する。この観点から、プログラマが働きやすい環境とは何か、という方向に行き、40時間労働とか、最近ならプロジェクトファシリテーションなどのような人間系に向かっているのだろう。
　
　また、オンサイト顧客のように開発チームへ顧客も引きずり込む。
　このやり方だと、顧客は敵というよりも同じチームの仲間という雰囲気になる。利害関係者の数はそれほど多くない。
　
　この開発スタイルがマッチする例は、BlogやSNSのように、永遠にベータバージョンであるようなWebシステム開発が向いているのだろう。

【感想】
　このように、品質を保持するプロセス、操作対象とするシステムの境界が全く異なる。
　それだけでなく、おそらく根本的には、変化に対する態度、再利用性に対する態度が大きく異なるように思う。
　
　ソフトウェアプロダクトラインの考え方は、時間が経つほどシステムは複雑化し、変更に対するコストが大きくなる発想。
　逆に、XPは、うまくコントロールすれば、時間が経っても、変更に対するコストはある上限で落ち着く発想。ウォーターフォールのような計画駆動は、恐竜みたいなものであり、XPを含むアジャイル開発は小さい哺乳類のように素早く変化に対応できるという信念を持っているように見える。

　XPは技術的にも発想も面白いし、人間系も最近はすごく活発だ。
　でも、ソフトウェア工学の昔からの難問であるソフトウェアの再利用性について、確固たる解答を提示していない。
　ソフトウェアプロダクトラインは、少なくとも一つの解答を提示している。

　少なくとも、どちらが絶対的に良いと言うよりも、向いているシステム開発の例が極端なだけかもしれない。

ITの地殻変動はどこで起きているのか？

　Javaエンジニアと開発手法について議論していたら、彼は、お客が求めているのは使いやすいユーザーインターフェイスなんだ、JSFがこれからの主流になる、と言っていた。
　僕は、JSFなんて、ASP.NETのJava版に過ぎないでしょ、と思っている。

　.NETエンジニアと、Javaと.NETの違いについて議論していたら、Javaよりも.NETの方がユーザーインターフェイスを重視したクライアントアプリケーションを作りやすい、と言っていた。
　僕は、Javaに対する.NETの優位性はクライアントアプリ開発だけにあると思っている。

　Javaエンジニアと、RDBとオブジェクト指向の相性の悪さについて議論していたら、JavaならHibernateを使うのが一番の解決策だ、と言っていた。
　僕は、Hibernateは確かに良い技術だが、結局HQLに書く所が納得できていなかった。

　最近、自分の興味がちょっとずつ変わってきた。

　IT技術の地殻変動はどこで起きているのだろうか？

　以前は、「ORマッピング」で事件が起きているように見えていたが、最近はちょっと異なる視点を持っている。
　事件は「プロセス」で起きている。
　キーワードは「ソフトウェアプロダクトライン」だろう。

　ITシステムがこれだけ普及した今、大規模なシステムを最初からスクラッチ開発するプロジェクトはそう多くない。
　既存システムにサブシステムを追加する、あるいは、既存システムをカスタマイズするプロジェクトが多い。
　最初の顧客に売ったシステムをカスタマイズして、別の顧客へ売るビジネスは非常に多い。

　その時に重要な点は、「ソフトウェア部品を再利用したい」こと。
　つまり、古くから続く難問が横たわる。

　その一つの解決手法が「ソフトウェアプロダクトライン」。
　似通った仕様で少数生産するための開発手法。
　コア資産（フレームワーク）とアプリケーションの分離。
　再利用資産の開発（ドメインエンジニアリング）と再利用資産に基づくプロダクトの開発（アプリケーションエンジニアリング）。

　EP法で言えば、プロセス供給レイヤーパターンに相当する。

　でも、コア資産を作ると言う別プロセスが発生するため、普通の開発に比べると、1.5～3倍ものコストがかかると聞く。
　また、コア資産を作っていたのに、時代の変化で使えないものになったというリスクもはらむ。

　事件は技術よりもプロセスに移っている。

プログラミング言語を成分解析したら

はしもとさんのBlogで、巷で噂の成分解析をプログラミング言語で解析した結果を読んで笑った。

perlの83%は宇宙の意思で出来ています

Rubyの99%はむなしさで出来ています

phpの72%は勢いで出来ています

Javaの52%は犠牲で出来ています

JavaScriptの68%は覚悟で出来ています

　調子に乗って、C#を成分解析してみたら。。

C#の71%は毒電波で出来ています
C#の10%は気の迷いで出来ています
C#の9%はミスリルで出来ています
C#の7%はお菓子で出来ています
C#の3%は成功の鍵で出来ています

　毒電波って何だろう？

TRICHORDを試す

　平鍋さんのBlogで紹介されていたTRICHORDをさっそく試してみた。
　すごく面白そう！

　TRICHORDはいわゆるソフトウェア進捗管理のツール。
　「 システム開発の状況の見える化ツール」というコンセプトで、　バーンダーンチャート、ニコニコカレンダーが標準装備されている。
　実際にインストールしてみたら、バーンダーンチャートを描くことが出来て感動した！
　

【感想】
・バーンダーンチャートが簡単に作れるのは楽しい。
・ニコニコカレンダーは可愛い(^^)
・「パーキングロットチャート」「プロジェクトカレンダー」「タスクかんばん」は未実装。
・メニューを見ると、まだ開発途中みたい。
・設定ファイルcurrent.xml　は、文字化けする。{}の間にプロジェクト名やＸ軸名を書かないと反映しないみたい。

　ＳＷＴ、JFreeChartを使っているようで、結構サクサク動きます。

　プロジェクトの進捗管理は結局ＭＳＰｒｏｊｅｃｔを使わざるを得ないが、ＷＢＳの洗い出しやタスクの依存関係を設定するだけで2人日以上もかかってしまう時が多い。
　しかも、ガントチャートが完成したとしても、プロジェクトがどれだけ遅れているか、見えにくい。

　荒削りですが、最近のアジャイル、プロジェクトファシリテーションの活動成果を反映したツールとして興味深い。
　今後の期待大です！

Web 2.0でマーケティングが変わる

　今朝の朝日新聞に「Ｗｅｂ２．０」　広がる参加型ネットという記事が載っていた。
　CNETなどのインターネットの記事で「Web2.0」はよくキーワードになっているけれど、ついに既成メディアも着目するようになったのか、と感心した。
　上記の記事は、分かりやすく書かれてます。
　
　先日の本「ウェブ進化論」にもあるが、インターネットの普及で影響を受けたものの一つにマーケティング手法があると思う。
　iTunesMusicでは、用意した100万曲はどれも少なくとも1回はダウンロードされたと言う。Amazonでも似たような事例があったらしい。
　つまり、売上が小さくても無数のコンテンツが売れれば、売上が上がる。

　今の商品は、ネット上の口コミの影響力が大きくなっているのではなかろうか？
　Blogや掲示板に書かれた情報をGoogleなどで誰もが簡単に調査できる。
　一つの意見ではなく、関係ない無数の第三者の意見の殆どが同じような意見だとしたら、そこには何かしらの真実がありそう。

　この手法を生かしたのがオープンソース。
　100人日かかる作業も、1000人が集まれば、一人0.1人日の作業時間でいい。
　世界中の無数のソフト開発者から、わずかな開発時間をかき集めて、巨大なソフトウェアを作り出す手法。
　外部リソースをうまく利用すること。

　今までの「パレートの法則」によって「上位顧客2割を抑えれば売上全体の8割を制する」やり方ではない。
　Web2.0では、「小さなちりも積もれば山となる」という「ロングテール」のやり方。

　丁度、織田信長が新兵器の鉄砲で武田軍を破ったように、最新技術をいち早く使った者が世界を支配するのだろうか。

GanttProjectを再び使ってみる

　最近、仕事でもコミュニティ活動でもお手軽に進捗管理できるツールを探していて、GanttProjectを久しぶりにダウンロードしてみたら、以前よりも使いやすくなっていた。

【MSProjectファイルと連携できる】
　最も目を引いた特徴は、MSProjectのファイルをインポート＆エクスポートできること！

　実際にMSProjectファイル(*.mpp)をインポートしたら、GanttProjectにタスクとガントチャートが表示できた！
　但し、*.mpxでエクスポートすると、UTF-8の形式ゆえ、そのままではMSProjectで文字化けする。

　この特徴が一番重要な理由は、やっぱりMSProjectが一番使いやすく、更に、MSProjectを使いこなしている人が多いから。
　GanttProjectのおかげで、MSProjectがない環境でも、少なくとも進捗スケジュールを確認することは出来る。

【他の特徴】
・メニューが日本語化されている（但し、詳細設定は英語）
・タスクの先行/後続を関係付けられる
・タスクに要員割り当てが出来て、負荷率を設定できる
・PERT図で表示できる

【今後の主な使い方】
・MSProjectで既に作ったスケジュール表をインポートして閲覧・修正する
・タスクをCSVで取り込んで、先行/後続で関係付ける
・タスクに要員をアサインする

　色々試してみよう。

「国家の品格」と「ウェブ進化論」

帰宅途中で本屋に立ち寄った折、たまたま話題の2冊の本を見かけた。
立ち読みの感想をちょこっとだけ。

【１】「国家の品格 」は失望した

立ち読みでパラパラめくっただけですが、落胆しました。
藤原正彦さんも右寄りになったのかなあ。

中高生の頃、藤原正彦さんの「若き数学者のアメリカ」と古本で読んでいたく印象に残ったのに。
研究の厳しさ、研究の本質は何か、とか色々考えさせられた記憶がある。

でも、この本には中身が何もない。
論理よりも情緒、マネーよりも美しい田園が大事、という主張は綺麗だけれど、現実のビジネスとアンマッチ。

ロックの思想を批判している箇所を読んで、受け入れがたいと確信した。
民主主義と資本主義は密接に関係しているというロックの思想は、今の現代社会の基礎なのに。

あちこちのコミュニティに出て気づいたことは、時間が有り余っている学生よりも、平日は仕事や生活で忙しい中年の人の方がはるかにアクティブな現実があること。
自分の能力を元に私有財産を持っているから、自由に行動できる事実がある。

【２】「ウェブ進化論」は確かにすごい

インターネットの特質は、やっぱり情報のやり取りや製品のコストが殆ど0になったこと。
この恩恵を最も受けている層は女性じゃないかと言う気がする。
BlogやMixiを漁ると、男性よりも女性が書いている記事の方が面白い。
男性にはない発想があるから。

もっと自分の言葉で理解したくて、結局、「ウェブ進化論」を購入した。
ゆっくり読みたいと思う。

Perl関西はハッカーのコミュニティ

　日曜の昼下がりに京都で開かれたPerl関西に行ってきた。
　今日の京都は、雨から小雪交じりになって寒すぎ(m_m)
　にも関わらず、30人も参加者がいて、勉強会も懇親会も盛り上がった。

【１】Perl屋さんはハッカーが多い

　講演者のプレゼンのノートPCを見ると、殆どの人が、MacかLinux上で、Emacsを普通に使いこなしている。
　しかも、Perlを使いこなすだけでなく、RubyやLispを使いこなす人も多い。
　HaskelやMLにも興味を持って話す人もいた。

　彼らの話を聞くと、CよりもJavaの方が1万回のループ処理が速い時もあるんですよ、とか、プログラミング言語のライブラリの中身は、ライブラリを使う人が簡単に使えるようにするために、結局汚い事が多い、等、プログラミング言語の特徴をよく押さえているという印象を持った。

【２】Perlはプログラミング言語として「緩い」特徴がある

　Perlの標語にこんな言葉がある。

　There's More Than One Way to Do It　

　他にもいろんな方法があるよ

　普通に書ける処理を別にこんな風にも書ける、というパターンがPerlには多い。
　いわゆるシンタックス・シュガーを使うと、いくらでも短く書ける。
　なみかわさんの講演では、「頭を柔らかくして、良い刺激を受けて元気になろう(^^)」という話があった。

　でも、この特長には功罪があり、他の人が読めないソースになってしまって保守できないという弱点もある。

　また、Perl関西の他の講演者も話していたが、「プログラミング言語としてPerlは緩い」所がある。
　変数や関数の隠蔽が無頓着だったり、オブジェクト指向の導入が他の言語に比べると....だったり。

　やはりPerlは、正規表現、ファイル操作、CGI、Wikiなど、お手軽に作り上げる所に最大の長所がある。
　すぐに建てて、用が足せば捨ててしまう。

　PerlやRubyなどに触っていると、プログラムは設計そのもの。
　アイデアをすぐにプログラムに起こしてみて、実際にすぐに動かせる所に最大の特徴がある。

【３】開発のスピードとプログラミング言語の関係
　最後に、Webシステムから業務システムへ開発が代わった人と話していた時、業務システムの開発はスピードが遅いんですよ、と聞いたことが気になった。

　PHPやPerlによるWebシステムの開発の場合、3ヶ月ぐらいのスパンでリリースするから、スピードが非常に速い。開発スタイルも、リリース後、お客さんの要望を取り入れながら改善していくことが多い。
　しかし、業務システムの場合、プロジェクトの期間そのものがもっと長いことが多い。
　だから、ずっと忙しい感じで、スピード感がないんですよ、と言っていた。

　とまあ、JavaやC#のようなガチガチの静的型付け言語に慣れている身にとって、刺激になった。

C#のdelegateをTemplateMethodの代わりに使う

　とある勉強会でC#2.0の新機能を議論する機会があった。
　「匿名メソッド」「イテレータ」について説明を聞いたが、いずれもDelegate、コールバックに関わる。

　イテレータはRubyで言うならば、ブロックそのもの。
例：　array.sort{|a, b| b<=>a}

　Perlにも、ハッシュのソートで似たような構文がある。
　Cのクイックソート関数　qsort　も比較関数をコールバックに使っている。

　匿名メソッドは、無名Delegateと言ってよい。
　Javaなら、Threadを使ってインナークラスを実装する時とかに似ている。

　C#のDelegateはEventで使うサンプルしか知らないので、自分はまだ理解し切れていないのだが、Delegateの他の例を教えてもらった。
　彼によると、DBコネクションの管理に使ってみる、とのこと。
　つまり、DBコネクションをオープンしてクローズするルーチン処理を行うメソッドの引数に、デレゲートを置き、そのデレゲート内部でSQL発行の処理を行う。
　これってまさにTemplateMethodそのもの。
　こんな使い方があったとは！
　
　C#がJavaと大きく違う所は、Delegateにある。
　Javaならインターフェイスでベタに書かざるを得ない所が、C#ならすっきり書けるが、慣れないと可読性が落ちる。
　コールバックという概念は奥が深い。

Ruby関西が今熱い！～Ruby is Agile!

昨日、Ruby関西に行ってきた。
50人の部屋が満員御礼になるほど盛況で、今、関西で一番熱いコミュニティではなかろうか？

サブタイトル「Ruby is Agile!」は、XPJUG関西の同僚が紹介した言葉です(^^)

感想は以下の通り。

【1】女子大生が書いたソースをコードレビュー
かずひこさんのレッスンで、女子大生が半年前に書いたソースのコードレビューがあった。
20行ほどのプログラムは、放物線の軌道を数値計算する内容で、ループ処理、コメント、変数名に修正が施された。
しかし、それだけにはとどまらず、会場の質問者からの突込みが熱かった(^^)

Q.　変数名をv1, dtではなく、velocity、nextTimeみたいに分かりやすくして欲しい。
小波先生：　コメントと連動させれば問題ないでしょう。

＃コメント無しでも読めるようにプログラムを書くために必要では？
＃保守のたびに、ソースだけでなくコメントまで修正する2度手間がかかりますよ。

Q.　For文を使うのではなく、イテレータやブロックを使うなど、Rubyらしいプログラムを書かないのか？
かずひこさん：この程度のプログラムでやるのは大人気ないと思いまして、やりませんでした。

＃会場は思わず爆笑(^^)

懇親会では、小波先生が「(会場から質問があるたびに)まるでわが子(娘)を切り刻まれるようで胸が痛かった」と言っていたが、プログラムはそんなに悪くなかったと思う。

【2】C、Perl、PHP、.NET、Javaをやっている人がRubyに興味のシグナルを送っている

懇親会で自己紹介を聞いたら、C、Perl、PHP、.NET、Javaなど、開発者が多種多様。
Rubyって、Java開発者はRubyOnRailsに衝撃を受けて興味を持つが、他の開発者はオブジェクト指向のスクリプト言語として興味を持つらしい。
Rubyは殆ど知らないけれど、オブジェクト指向でスクリプトをやるならRubyだろう、という動機が多かった。

【3】コミュニティで学生を育てる

懇親会でスタッフに聞いたら、参加者50人のうち20人は学生。どうりで若い人が多いわけだ。

最も印象に残ったのは、40代の部長の肩書きを持っているスタッフが、勉強会で一番楽しい時間は、かずひこさんの初級者レッスンで、TA(Teaching Assistant)として若い人にRubyの質問に答えることだ、と言っていた事。

小波先生、かずひこさん、更には他の講演者やスタッフ皆が中心となり、学生を育てようという雰囲気がある。
こういう発想や雰囲気を持つコミュニティはあまりないので、大事にして欲しいと思う。

使い捨てのプログラム

　システム開発において、設計・製造・テスト・保守フェーズで一時的なプログラムが必要になる時が多い。

例えば、、

・画面項目から、大まかなDB定義書を作り出す。
・仕様書からプログラムのテンプレートを吐き出す。
・テスト仕様書からJUnitのテンプレートを吐き出す。
・JUnitからテスト仕様書を生成する。
・テストデータ、DB仕様書からSQL文を生成する。
・既存システムにあるソースから、調査時に必要な情報をGrepする。
・既存プログラムからCRUDしているテーブルとソースの対応表を作る

などなど。
結構、力仕事でカバーしていませんか？

【何故、使い捨てのプログラムが必要か？】

システム開発の現場では、結構、頭を使わないルーチンの力仕事は多い。
Javaを使ったWebシステムであろうと、結局、Javaを書いているよりも、PerlやVBAを使う方が多い時もある。

特に、仕様書を作る時や、設計時に既存プログラムを調査して仕様を決める時に、使い捨てのプログラムによって作業を速く正確に行えるかどうかは、設計の品質そのものに響く。
一時的に使うだけだが、作業効率を上げるために大変重要。

これらのプログラムは、使い捨てのプログラム。
プログラムそのものも、インターフェイスをきちんと考えて作る必要はなく、とにかく速く作ることが最優先。
だから、きちんと書く必要はない。

【プログラミング言語は何を選ぶか？】

Excelの仕様書を自由自在にいじるために、結局、VBAが必要になる。
基本は、マクロで基本操作をなぞった後、プログラムをカスタマイズすることが多い。

テキスト処理には、色々あるが、やっぱりPerlが一番簡単。
Windowsなら、ActivePerlかCygwinを入れればいいだけ。
Perlなら、Cライクに書けるし、あんまり深く考える必要がない。

今なら、Rubyを選択する人が多いかな？
WinOLEでExcelも扱えるし、正規表現も使えるし。

でも、Rubyで書いた時、Perlよりも短く書けない。
たかがGrepや一括置換したいだけなのに、たいそうなプログラムを書かざるを得ない。
まだRubyに慣れていないせいもあろうが。。

【プログラミング言語は2種類ある】

言語には、型チェックが厳しい重量級プログラミング言語と型チェックが甘い軽量言語（Light Weight Language）の2種類があるように思う。

前者は今なら、Java、C#、Cとか。
後者は、VBA、Perl、Rubyとか。

型チェックが厳しいプログラミング言語は、品質最優先の業務システムが向いている。
開発スタイルもドキュメント志向で、重量級プロセスになりがち。

型チェックが甘い軽量言語は、速く作ることが最優先のWebサイトが向いている。
更には、テキスト処理などの定型的なルーチン作業で威力を発揮する。

この2つのプログラミングの感覚は大きく異なる。

重量級言語は、プログラムを育てていく感覚。正確さ、丁寧さが大事な感覚がある。
設計では、「疎結合」「コンポーネント志向」を重視するから、リファクタリングなどで品質を保持することが優先される。

軽量言語は、使い捨てのプログラムを早く作る感覚。正確さよりも、早く作る方が大事な感覚がある。
　「3年で陳腐化するWebサイトの構築には軽量言語のほうが向いている」記事では、逆に「密結合」「非コンポーネント志向」が良しとされるようだ。
重量級言語と視線も動機も正反対な所が面白い。

どちらが良いというよりも、向き不向きがあるだけ。

【使い捨てのプログラムを書く能力の重要度は高い】

システム開発の現場にいると、大抵の優れたプログラマはツール作りが上手い。
ルーチン作業を自動化するために、使い捨て感覚でプログラムをすぐに作ってしまう。
後で、そのツールが重要になってきて、後でメンテナンスするようになる時も多い。

使い捨て感覚で作っているからメンテナンスしにくいのかと思ったら、優秀なプログラマだけあって、実は読みやすく再利用しやすい時が多かった。

Javaなどのオブジェクト志向言語をマスターするのも重要だが、使い捨てのプログラムを書けるだけのプログラミング能力も重要ではなかろうか？

【最近の傾向】
RubyOnRails などを見ると、Webシステム開発そのものも使い捨てを念頭に置いて開発する必要性が多くなったのではないか。

知り合いのアジャイラーが、プログラムが使い捨てで良しとされるのは感覚が違う、アジャイルと同様にプログラムを育てていく感覚が大事なのに、と言ったことが気になる。

システムをスクラップ・アンド・ビルドで開発しても良しとされるケースが増えてきているのかもしれない。
特に、Webシステムはスピードが速すぎるから。

軽量言語とビジネスの関係

　「3年で陳腐化するWebサイトの構築には軽量言語のほうが向いている」記事を読んで、開発スタイルとビジネスには密接な関係があることを改めて感じさせられた。

　くらぬきさんの話「EnterpriseXP」でもあったが、XPが使えるビジネスには、サービスを早くリリースしてビジネスを展開するタイプと、金融系のようにきっちりと業務を決めてシステム開発を進めるタイプの2種類がある。
　前者は、軽量言語が向いていて、後者はJavaのような強い型付け言語が向いているのだろう。
　前者のビジネスモデルは、はてなやMIXI等が思いつく。軽量言語としては、Perl、PHP、Rubyがあるのだろう。

　上記の記事で注目すべき点は、システムの受注のスタイルが異なることだ。
　普通は、「ユーザー企業の情報システム部門がシステムを発注し、大手システム・インテグレータ（SIer）が受注する」という形になる。
　ところが、「ユーザー企業の営業部門や広報部門がシステムを発注し，大手広告会社が受注する」という形が多いという。
　となると、顧客サイドは技術に疎いため、技術面だけでなく、システムを開発するプロセスそのものでも顧客をコントロールできる力がより一層重要になる。
　おそらく顧客は、Webデザインの延長でしか考えていないだろうから。
　だから、普通のSIerよりも敷居が高いかもしれない。

　軽量言語は、言語だけでなく、ビジネスそのもの軽く動きやすい方が特徴が出やすいように思える。

dJUnitでカバレッジテスト

　自分が書いたプログラムをdJUnitでカバレッジのテストをするのが楽しい。

　カバレッジを目で見ることができることそのものが楽しい。

　情報処理試験で、分岐網羅やテストについて概念や用語を習うけれど、実際に理解して使いこなせている人はどれだけいるのだろうか？
　カバレッジのテストが重要なのは、プログラムの品質そのものに直結するから。

　JUnitのテストプログラムを書くのは簡単で、むしろテストケースを洗い出す方が難しい。
　テスト仕様書にあるテストケースで全てのステップを通過しているか、更には全ての分岐を通過しているか、を頭の中だけでイメージするのは、ステップ数が多くなるほど漏れが起きやすい。

　dJUnitを使うと、JUnitのテストメソッドを実行後、テストで通過していない行にマーカーが付く。
　少なくとも、マーカーを全て消すようにテストメソッドを実装していく。その作業は結構楽しい。

　テストプログラムが先にありきの本来のテスト駆動のやり方ではないけれど、今のやり方は、既に作られたプログラムが存在し、そのプログラムの分岐を全て網羅するようにテストメソッドを実装していく。
　設計力がしっかりしている人は、最小個数のテストケースで全ての分岐を網羅できるが、漏れがないことを証明するのは結構難しい。
　少なくとも、dJUnitのように網羅した箇所をレポートで自動生成できるなら、かなり手間は省ける。

　Eclipseが出現して４年以上経つけれど、色んなツールが出ていて、開発環境が以前と比較にならないほど整ってきている。
　特にテスト系ツールは、プログラムの品質に直結するから、最重要だ。

　しかし、Java＋Eclipseに比べると、他の言語の開発環境は使いづらい。。
　Rubyも何とかしてくれないかな。

Web 2.0で一番重要なのは価値あるデータベース

　ベンチャー企業の代表者が解くWeb 2.0と経営の本質という記事で、「Web 2.0で一番重要なのは価値あるデータベースだ」という意見が載っている。

　Googleにしても、Amazonにしても、自分たちが持つ地図や商品のデータベースへつなぐAPIを公開することで、自分たちのサイトへのリンク、更には訪問者を増やすというビジネス手法を取る。

　この発想の根本は、データベースが重要なこと。そのデータベースへリンクさせるためにAPIの公開が必要だし、サーバーにアクセスが集中しても、その負荷に耐えられる仕組みが必要。

　その公開手法はオープンソースとは違うけれど、依然とは違い、自分たちのシステムの情報（の一部）を公開する方が実は利益になるという逆説。

　今後、インターネットを使ったビジネスの発想は、Webを通じて自社のデータベースへリンクするAPI公開にあるのかもしれない。

デザインパターン再考

　各人でバイブルと呼んでもいいぐらい影響を受けた本、そして愛用している本はあると思うが、自分にはGoFの「オブジェクト指向における再利用のためのデザインパターン」が相当するように思う。

　仕事で手が空いている時は、この本のCD-ROMに付属していた抜粋HTMLをよく読んでいるからだろう。

　デザインパターンとは、「より良いインターフェイス設計手法」と呼ぶことも出来る。
　23個のパターンは、粒度の違いはあれど、いずれも珠玉の概念だ。
　
　そもそもデザインパターンに惹かれるのは何故だろう？
　それは、似たようなインターフェイス設計を何度も行った経験があるから。
　詳細設計やプログラミングでデジャブをいつも感じるから。
　リファクタリングと絡めると理解しやすい。

　23個のデザインパターンは、個人的には「ポリモルフィズム」「仲介コントローラ」「インスタンス管理」の3種類で分類できると考える。

１．殆どのパターンはポリモルフィズムの原理を使っている。

　ポリモルフィズムの意義は条件分岐の除去だ。
　実際には、複雑なIF文を呼び出し側から呼ぶ側へ移動することにある。この手法を徹底すると、複雑な条件分岐のアルゴリズムがModelからViewへ移るため、最終的にはリフレクションで条件分岐を全て除去できる。

　具体的には、ポリモルフィズムの対象オブジェクトは、アルゴリズム(Strategy)、状態(State)、要求(Commnad)、再帰(Composite)、コンテナ(Iterator)、文法処理(Interpreter)によって観点が異なるだけ。

　2個のパターンを組み合わせたパターンもある。
　DecoratorはCompositeとStrategyを組み合わせたパターンだし、Chain of ResponsibilityはDecoratorにイベントの概念を追加したパターンと言える。

　特異なパターンがVisitorだ。
　以前は「Visitorパターンはどこで使うのだろう？」と疑問に思っていたが、一言で言えば「マトリックス型のポリモルフィズム」。
　つまり、Visitorクラスはswitch文をクラス化したものとして、その構造が自然に現れる。

２．仲介コントローラを導入するパターンは、複雑な処理を委譲する原理を使う。
　仲介コントローラを導入する意義は、処理の複雑さを凝集度の観点から、一つへまとめたり2個以上へ分割することだ。

　仲介コントローラの対象オブジェクトの役割が、インターフェイス適合(Adapter)、処理の仲介(Proxy)、Controllerの共通インターフェイス(Facade)、オブジェクト間の複雑な通信制御を一つにまとめるもの(Mediator)などと観点が異なる。
　
　最も奥が深いのは、Observerパターンだ。Observerパターンはイベントの概念そのものだが、Multicastパターンで実装されることが多い。
　JavaとC#ではプログラミングスタイルが大きく異なる部分でもある。

３．インスタンス管理を導入するパターンは、用途によって異なる。

　ポリモルフィズムと組み合わせ（AbstractFactory）、コンストラクタ置換(FactoryMethod)、唯一のインスタンス生成(Singleton)、インスタンス複製(Prototype)、インスタンスの履歴保持(Memento)などがある。

　デザインパターンは、実装言語によって大きく異なる部分がある。
　Java、C#、VB、Rubyなどで書いてみると、実装言語の制約でデザインパターンを使えない時があったり、デザインパターンそのものの実装が長くなったりする。
　実装言語の比較によって、自分なりのデザインパターンの解釈を今後、連載してみたいと思う。

Ruby関西とiPod

　昨日、Ruby関西の勉強会に出てきました。

　「IE+iPod」「DRUM（ドラム）」「Ruby/TkORCA」「かずひこさんの初級者レッスン～継承と委譲」を聞いてきましたが、初級者向けで聞きやすかった。

　毎回、素敵な講演を用意して下さる講演者、会場準備担当者の方に心から感謝します。

　iPodにはまっている自分にとって、「IE+iPod」が一番興味深かった。

　Yahooの株式情報を自動検索させるとか、iTunesの曲からGoogleイメージ検索でジャケット画像を探して貼り付けるとか、使い方によっては色々と出来そう。Rubyのソースを見ましたが、Unixのシェルスクリプトみたいでそんなに難しそうには見えなかった。

　テキストファイルをWindows付属の音声認識で読み上げた音声ファイルをiPodで聞くサンプルは一番印象に残った。この使い方ができれば、通勤電車や歩いている時間を丸ごと勉強時間に当てることが出来る。朝の通勤ラッシュ時間は無駄な時間になりがちだから。

　cuzic さんは丁度勉強されているという中小企業診断士のテキストを音声ファイルにしていましたが、聞いてみたらお経のようで、慣れないと聞き取れないのは笑いました。

　Windows付属の音声認識コントロールパネル付属のSumは声質が悪い(^^)　音声ファイルはVectorでも買えるそうで、女性の声が一番聞きやすかった(^^)

　速聴は、脳内活性にいいそうです。でも、お経は勘弁だなあ(^^)

 　iTunesのクラスライブラリをRDoc形式で初めて見ましたが、講演者のcuzic さんが話したように、すごく綺麗な構造をしている。

　ライブラリ、アルバム、アーティスト等のクラスは、iTunesの表示メニューそのものに対応していて、メソッドもこんなものかな、とすぐに連想できる。
　COMって僕には印象が悪いのだが、iTunesの場合は勉強してみる価値があるかも。

　iPodの普及で、大量の音声データを持ち運べる環境が整ったことで、Apple自身も予想しなかった使い方が生まれている、という記事を新聞でも読んだ。

　落語をPodcastで無料配信して落語のマーケットを増やそうとする試みや、大学で生徒全員にiPodを配って英語リスニングに使ったり、予備校で簿記や資格試験の授業を音声ファイルで配ったりする例があった。単に音楽を聴くだけでなく、授業や勉強に使ったりもできる。

　テキストの音声読み上げは色んな可能性を感じる。MacOS8の頃から音声読み上げは簡単にできていたけれど、こんなこともできますねえ、ぐらいで、その頃は実用になるとは思えなかった。今は、iPodを使えば、歩きながら聞くことが出来る。現代のように、まとまった時間を取りにくいサラリーマンにとって、重要なツールの一つなのかも。

　一番欲しいのは、詩や本の朗読、ラジオドラマの音声ファイル。特に、詩は読むよりもリズム感があり、すごくイメージしやすい。ネット検索してみたが、まだ発展途上の状況で、まだ量が少ない。

　最近の僕のお気に入りは、下記の「今夜の一冊～湘南BeachFM　Relaxin'Mode 今夜の一冊」。

　金子みすヾさんの詩の朗読などもあり、すごくいい！

　童話や詩は、子供に本を読み聞かせるものだから、Podcastのような使い方が一番似合っている気がする。

SIビジネスに将来性はあるのか？

　くらぬきさんの記事「ディフェンシブな開発 ～ SIビジネスの致命的欠陥」は、SIビジネスの欠陥を突いている。
　IT業界で仕事していると、どうしても土建業界に似ているんじゃないか、と感じてしまう。

　姉歯問題はIT業界でも、実はよく起きているはずだ。
　いくら要件定義や設計に労力を費やしても、ウォーターフォールの開発プロセスをガチガチに守っても、仕様変更や最新技術の検証、ステークホルダーのコントロールなどのリスクを制御できずに、テスト工程で手を抜くなどして、システムの品質が落ちたりするプロジェクトは、結構多くありませんか？

　だから、システムの品質を保ちながらも、いかにローコストでシステム開発するか、そのビジネススタイルを洗練させる方向へ向かっているように見える。

　2006年の日本という状況でSIビジネスを展開する時、日本人SEは、20万円/月の中国人SEと競争せざるを得ない。ベトナム人SEなら、更に10万円/月だ！
　結局、ローコストでシステム開発を早く回す大量受注型のビジネスか、システムの運用保守や会計パッケージなど何かしらの技術に特化したコンサルタントになってコバンザメの様に顧客にしがみつくコンサルビジネスか、選択肢が限られてしまう。
　IT技術は、本来は、AppleのMacintoshやiPodのように、普通の人の生活をよりよい方向へ変化させる原動力になるべきなのに、IT技術をサービスとして売り物にすると、結局、人材派遣ビジネスと何ら手法が変わらなくなる。
　
　何層にも連なる下請け構造、人材派遣ビジネス、中国へのオフショア開発、などの事象を見ると、将来性がないように見える。
　IT技術こそがビジネスの中核であると認識している企業。そこに希望があるのかも。はてな、みたいに。
　

オブジェクトはサーバーみたいなもの

　OGISのオブジェクト広場に記載された丸山さんのインタビューを読むと、オブジェクト指向とネットワークの相性が良いという感想を持った。

やはり丸山さんのご関心はどちらかというとインフラに近いんですか?

ネットワークが好きなんですよ。なぜかと言うと、これからはネットワークが一番の基本になるというのが僕の考えだからです。
コンピュータからネットワークへという大きなパラダイムシフトが進むだろうと考えているんです。
よくコンピュータサイエンスと言いますけれども、コンピュータは 20 世紀の技術で、これからはやはりネットワークの時代だと思います。
だから、ネットワーク上のオブジェクトを扱うプログラム言語みたいなものが出来てきたら面白いと思うんですよね。
僕が、あと 30 才か 40 才若かったら、そういうことをしたいですね。

　インタビューを読むと、丸山さんはネットワークプログラミングからオブジェクト指向へ進んでいったことが分かる。
　GUIアプリを作るとか、Smalltalk使いではなく、Webプログラミングからオブジェクト指向に進む方が、自然ではなかろうか？

　何故なら、オブジェクトはサーバーみたいなものだから。
　つまり、他のオブジェクトからリクエストを受け取り、オブジェクト内部で処理してレスポンスを返す。呼び出し側のオブジェクトは、その間ずっと待機している。
　これはまさにイベントドリブンと同じ構造を持つ。イベントが発生するタイミングは、ブラウザの画面更新時に対応する。

　そう考えると、メッセージパッシングをWebのRequestとResponseの操作のアナロジーと考えることもできる。
　だから、そのアナロジーを発展させれば、Webの処理に時間がかかるなら処理オブジェクトそのものを切り出して生成＆実行するProxyオブジェクトや、リクエストのパラメータに応じて処理を動的に変えるCommandオブジェクトが必然的に現れる。
　
　オブジェクト指向の説明として、動物の鳴き声の例とか、手続き型プログラミングとの比較とか、給与計算の例とか色々あるけれど、Webという舞台装置による説明が一番しっくり来るのではないかと思う。
　丁度、JavaがWebの爆発と共に発展していったのと同じように。
　

PEAAにある.NET特有のアーキテクチャパターン

　仕事納めの今日、仕事の手も空いたので、「エンタープライズ アプリケーションアーキテクチャパターン」(マーチン・ファウラー著、通称「PEAA」)を一通り読み通した。
　すごく面白い！

　業界のアーキテクトやモデラーが、以前から注目していた本。
　PEAAは、業務系システムの設計パターンのうち、ORマッピング、トランザクション、WebUIなどを詳しく解説している。
＃余談だが、Amazonの感想文のうち、プロモデラーさんと奥村さんの感想がまさに的確。

　僕の場合、「AAfN(Aplication Architecture for .NET)を理解したいなら、PEAAを読むべき」と同僚から薦められたきっかけもあった。

　長年Javaで開発してきたので、J2EE特有のアーキテクチャ（ドメインモデル、データ変換オブジェクト、ページコントローラ）は自然に理解できた。純粋なオブジェクト指向開発者なら、これらのアーキテクチャは無意識でも使っている。

　特に目を引いたのは、.NET特有のアーキテクチャを説明している所。
　第1部では、ドメインモデルとテーブルモジュールの比較は目から鱗が出た。
　ORマッピングは、JavaとADO.NETで発想が全く違う。DataSetは、確かにテーブルオブジェクトそのものゆえ、DOAに近いと言っていい。DataSetは使いにくいのかと思ったら、むしろ、DataGridにDataSet丸ごと渡せるので、プログラムはすごくすっきり書ける。
　VBでは、DataSetやDataGridのAPIがないから、データ検索の結果一覧をFormへ表示するだけのロジックがすごく面倒。
　でも、DataGridもやはり機能が足りないので、FlexGridのようなサードパーティのモジュールを使う時も多い。
　
　Javaにはテーブルモジュールと言う発想はなく、ドメインモデルという発想。
　J2EEでオブジェクト指向をフルに使った開発では、RDBを意識することなく、POJOで処理を考えるのが普通。だから、コストがかかるEJBを使わない場合、DAOを自作することになる。そして結局、ORマッピングがボトルネックになり、Hibernate、TorqueなどのオープンソースのORマッピング・フレームワークが乱立している状況にある。
　
　また、EJBにはトランザクション管理だけでなく、分散オブジェクトの一面も持つのがいつも開発のボトルネックになる。
　だから、データ変換オブジェクトを使って、ドメインへの問い合わせ内容を一括して直列化するのが普通のやり方。いわゆるDTOパターンだが、Javaの場合自作するケースが多いから手間がかかる。

　では、.NETの場合どうするのか、と疑問に思っていたが、Webサービスを使うのが自然に設計に出てくる。「Webサービスとは単にリモート用途のインターフェイスにすぎない」という一節は、まさにその通り、と思わず相槌を打った。。
　VisualStudio.NETならば、Webサービスはウィザードで簡単に作れるし、クライアントは公開されたWebMethod属性のメソッドを単なるAPIとして利用するだけでいい。
　
　他にもなるほどと考えさせられる所はあるが、.NETのアーキテクチャは、純粋なオブジェクトのモデルを志向するJavaと違い、APIが多少複雑になろうとも使いやすさを優先しているという感想を持った。
　丸半日しか読んでいないのに、腑に落ちて理解できた所や重要そうな所に付箋を貼り付けたら、20本以上貼り付けてしまった。。

　Javaに限らず、.NET開発者にもお勧めの本です。

何故Webサービスはキラー技術にならないのか？

　とある勉強会後の飲み会で、ある人から、今年は技術の世界でキーワードとなるようなワクワクする技術が出なかった、せいぜいAjaxぐらいだ、と言われた。確かに、Aspect、DI、Tiger(Java)は昨年からずっと続いているだけであって、今年に一気に爆発した技術ではない。

　一番不思議なのは、Webサービスは何故出てこないのだろうか？
　3年前にSOAPやWSDLとかあれだけ騒がれたのに、何故、IT業界でWebサービスはキラー技術にならないのだろうか？

　技術的難点とすれば、サービスを提供する側がXMLデータを吐き出すインターフェイスになっていない、或いはサーバー側に負荷がかかりコストがかかること。
　ビジネス上の難点とすれば、クライアントがWebサービスを使おうとする時、成功したのか失敗したのかに関わらず課金せざるを得ないこと。
　
　多分、根本の理由はWebサービスを使ったキラーサービスが出ていないからではないか？

　Blogのように、プッシュ配信サービスは昨年から一気にインターネットの世界を変えた。Webサービスもうまく使えば、サーバー側から情報をプッシュするサービスとか考えられないだろうか？
　Webサービスはサーバーとクライアントが完全に分離して、Bestに近い技術なのに。

ムーアの法則が経済ルールを支配する？

　今頃になって、「新・資本論」―見えない経済大陸へ挑む（大前研一）を読んでいる。
　読み出した理由は、今年になって、技術やビジネスの流れが急激に変わりつつある予感がして、その予兆を既に予見していたと言うこの本が紹介されていたから。

　本に出てくるビジネスの例は、6年以上前のことだから古い。
　ボーダーレス経済、サイバー経済、プラットフォーム、色んな単語が出てくるが、僕には本質が読み取りにくかった。

　以前のケインズ経済理論が成り立たなくなった理由は、梅田さんが言ったように、IT業界で生まれたムーアの法則が全ての産業に波及したからではなかろうか？
　「半導体の集積度は1年半で2倍になる」ことから始まって、「1年半で製品の値段は半額になる」ことまで行き着く。つまり、世の中の全てのモノ、情報の値段が1年半には半額になるとしたら、数年後には殆どタダになってしまう。
　だから、世の中の競争がどんどん激しくなっているように感じる。
　しかもその競争は、全てを無にしてしまう。

　かと思えば、はてなの近藤さんが実行しているように、情報を隠すよりもオープンにしてしまう方が実は力になる、という例もある。
　例えば、不具合を起こしたプロセスをオープンにするとか、はては、新規ビジネスの企画会議までオープンにしてしまうとか、今までは考えられないことをやっている。
　記事を読んだら、情報を隠すのはコストがかかる、しかも、情報を公開して外部リソースを使う方がはるかに有用だ、という内容だった。昔のビジネススタイルでは考えられないやり方。

　オープンソースも、ネット上のコミュニティ運動も、いずれも、コミュニケーションや情報を公開することのコストが下がったおかげで成り立ち、コミュニケーションのプロセスを公開することで更に信頼を得て、ネットワークを広げているように思える。
　それによって、無数の人が集まり、そこにリソースが集まるのを目ざとく見つけた人は、ビジネスのマーケットを嗅ぎ取る。

　ムーアの法則と経済理論について、本質的な洞察をした人はいないのだろうか？

スティーブ・ジョブズ～偶像復活

　「スティーブ・ジョブズ-偶像復活」をたまたま立ち読みしました。面白い！

　ジョブズの人生をジャーナリストが書いた風な本ですが、ジェットコースターのような彼の生き様がドラマのように映し出されていて、読んでてワクワクします。
　自信過剰で尖がっていた性格も、年齢を経るにつれて、少しずつ大らかになっていく所も見所がある。
　彼は技術者と言うよりも、経営者タイプですね。どの製品が売れるか、その嗅覚が誰よりも鋭い。
　最近のiPodを見ても、未知の製品に人々が何を求めているのか、それを探し当てるのが凄い。

　個人的には、ゲイツよりもジョブズの方が好き。
　今はお仕事上Windowsですが、この業界に入るまでMac一筋だったので、雑誌も日経ITProなんかよりもMacPowerの方を貪るように読んでいた時期もありました。
　何故Macにはまる人は多いんでしょうねえ。

　ジョブズの言葉で今も記憶に残るものがあります。
　一つは「このコンピューティングパワーを世の中の人に解放しよう！」というもの。どこの引用だったか忘れましたが、政府や大企業が独占していたコンピュータを普通の人にも使えるようにしたというのは、今になってみれば先見性があったということになる。

　もう一つは、「パソコンはテレビの代用にはならない。テレビを見るときは頭をOFFにしているから。」
　家電製品とパソコンが融合するか、という引用だったと思うが、ジョブズは、パソコンに独自の価値観を持っているようだった。

　以前読んだ暴露本「アップル薄氷の500日」も面白かった。再建屋のアメリオが連れ帰ったジョブズが反乱を起こして、会社を乗っ取ってしまとは。
　
　Appleは今が旬ですね。

PS
「スティーブ・ジョブズ・偶像復活」の記事を読むと、この本の裏話がある。

プログラム＝インターフェイス＋アルゴリズム＋データ構造

ここの記事「「アルゴリズム＋データ構造＝プログラム」？ 本当に？」がすごくホットで面白い。

普通、IT業界に入社した当初は、現実世界をコンピュータ上へシミュレートする時、全てのロジックを構造化された形式に直すのがSEの仕事だと習う。
まさに、アルゴリズムやデータ構造を考えているのと同じ。

プログラマは、インターフェイスよりも、アルゴリズムを考えたり、データを保持するためのデータ構造を考える時が多い。

インターフェイスは、設計者によって既に作成され、プログラマは設計書に従ってコーディングする時が多い。

だから、インターフェイスを考えるプログラマは少ないのでは？

昔のFortrunやBasicのプログラムを読むと、ローカル変数が存在せず全てグローバル変数とか、サブルーチンが存在せずGoTo文しかないとか、今では考えられないような制約があった。
その頃の考え方の遺産が「アルゴリズム＋データ構造＝プログラム」。

最近何故かVBを仕事でやらされているが、JavaやC#がいかに書きやすいか、まざまざと感じさせられる。

・型チェックが弱い。コンパイルしても、実際に動かさないと、コンパイルエラーすら見つからない！！
・実装継承がないのでポリモルフィズムが使えない。Case文がやたらと多い。
・例外処理がないので、GoTo文を使うしかない。
・Formに全てのロジックを書いてしまっているために、シーケンス図で書くと、肥大化したクラスそのものになってしまう。
・クラスを使うロジックが少ないため、関数の引数がやたらと長い。
・関数の引数に戻り値を渡す書き方が多いため、混乱しやすい。
・VBはFTP等のネットワーク系ライブラリが使いづらい。
・Collection等のコンテナのライブラリの機能が少ないため、基本的なアルゴリズムをわざわざ実装する手間がかかる。

オブジェクト指向プログラミングは、アルゴリズムやデータ構造をオブジェクトの中に隠蔽してしまい、インターフェイスだけを考えれば良いプログラムが書ける、という発想。
インターフェイスを突き詰めて考えると、複雑な処理は、多数のクラスへ分割され、プログラム構造は階段状のシーケンス図で書き表される。
GoFのデザインパターンは、結局インターフェイス設計を説明しているのと同義。

現代の考え方は「プログラム＝インターフェイス＋アルゴリズム＋データ構造」。

しかしながら、少なくともVBプログラマにはそういう発想はないみたい。
VBなんか、消えてしまえばいいのに。

Web 2.0メモ

　最近、巷で流行しているWeb 2.0のメモ。

Web 2.0：次世代ソフトウェアのデザインパターンとビジネスモデル（前編）

Web 2.0：次世代ソフトウェアのデザインパターンとビジネスモデル（後編）

　アプリケーションはOSではなくサーバーにあるべき。
　Windowsは古い。
　Googleが生み出すWebのサービスの方が、はるかに刺激的。

いま、会いにゆきます

　昨夜、友人と酒を飲みながら「いま、会いにゆきます」のDVDを鑑賞した。

実は初めて見ましたが、とても綺麗な映画だった。
亡くなった奥さんが戻ってきて、「いってらっしゃい」「おかえり」と言われたら、男ならジーンと来て泣くだろうねえ。
澪がいなくなった後のシーンが良かった。
タイトルの意味がようやく分かった(^^)

竹内結子ってこんなに綺麗な女優さんとは思わなかった。。
竹内結子がこの映画で共演した男優と出来ちゃった結婚したのも何となく頷ける。

今思うと、昨年は映画の当たり年だったのかも。

プロフェッショナルの条件

かずひこさんのBlogに刺激を受けて、「プロフェッショナルの条件―いかに成果をあげ、成長するか はじめて読むドラッカー (自己実現編)」を読んでいる。
この年齢になって、ようやくドラッカーは面白いと思えるようになった。

情報化社会という現代で生きるために必要なスキルは何か、を解説している。

気になったフレーズは、ドラッカーの経験話。
若いドラッカーがウィーンで、当時80歳のヴェルディのオペラに圧倒されて、彼の言葉を知り、衝撃を受けたこと。
その言葉とは、

完全を求めていつも失敗してきた。だから、もう一度挑戦する必要があった

と。この言葉をいつも道標にしてきた、とドラッカーは言う。

完璧主義者は些細な事にはまりすぎて自らペースを崩す時があるが、そんなレベルの話ではなかった。
レベルの高い人はストイックな性格を持つ人が多いが、それはより高次元の完璧さを求めているからだろう。

他にも色々と参考になる所があります。
すごく味わい深い。

追伸

P.F.ドラッカー氏が11日に死去されたらしい。
ご冥福をお祈りします。

最近のお気に入り

iPod nano

Google Mapsで鈴鹿サーキット試走

面白い記事を発見！

Google Mapsで鈴鹿サーキット試走

Spaceキーでアクセルを踏みすぎたせいか、オーバーランばかり(^^)

当然ながら、JavaScriptを使っているわけか。
ソースをチラリと見たら、GMap、GPointというクラスにX・Y座標や諸々のデータがあるので、いつでも取得できるみたい。

GISのシステムは、実はすごく難しい。
例えば、地図上の距離を計算しようとしたら、直線ではなく、球面上の測地線なわけだし。
GISは地図描写エンジンが鍵を握っている。

Googleはどんなエンジンを使っているのだろう？

ふりかえり(Keep, Problem, Try )の実践例

　平鍋さん提唱のふりかえりの実践例として、Ruby勉強会＠関西-KOF2005 ふりかえりがある。

　チームをよりよく改良していこう、という意図が強く感じられる。
　Wikiを使うのもいいアイデアだと思う。

インターネットが既成メディアを脅かす

　今日の朝日新聞のオピニオン欄に、TBSと楽天の騒動に対する藤田晋氏と氏家斉一郎氏の二人の意見が記載されていた。意見が全く違いすぎるのが面白かった。

　氏家斉一郎氏は日本テレビ社長。内容に新鮮味はない。規制緩和で守られた官公庁の立場の意見にすぎない。

　対して、藤田晋氏はアメーバブログを作っているITベンチャー社長。
　現状のネット企業の強み・弱みを認識している。強みはIT技術をビジネスに展開できる能力に長けていること。これは誰でも知っている。

　弱みは、ライブドアとフジテレビのバトルから判明してきたが、ネット企業にはコンテンツがないこと。だから、楽天は欲しがる。AppleもiTunesで音楽コンテンツだけでなくビデオまで販売している。
　そもそもネット上の情報は信憑性が薄い。信用がない。だから、テレビ等の既成メディアのコンテンツがあると、少なくとも信用価値は高まる。それによるアクセス数、広告収入、等のビジネス上の価値。

　何故、コンテンツを欲しがるのか？
　「楽天は本当にAppleに対抗しようと考えたのか？」の記事では、もっと泥臭い事実を指摘している。
　
要するに、もう楽天の「ショッピングモール」というビジネスは、寿命間近なのだ

　楽天にしてもライブドアにしても、ビジネスの基盤ははるかに脆い。

　そんな弱みを持ちながらも、藤田氏のチャレンジャー精神が興味を惹いた。

　経営実態よりも高い株価は、批判もあろうが、なにかをやってくれるのではという期待感の現れ。その期待にこたえず何もしないのは、仕事をしていないのと同じだ、と。
　
　全くその通り。その期待に対する経営責任を背負いながらビジネスをやっている。
　既成メディアにいるビジネスマンから、こんな言葉は出てこないのではなかろうか？

　最近、メディアとネットが反発している背景には、その企業を支えるビジネススタイルが根本的に違うからだろう。
　木村剛のBlog「マスコミはインターネットが嫌いなのか？」を読むと、少なくとも、ブロガーと既成メディアの間に緊張関係が存在している事実が読み取れる。
　しかも、既成メディアは、世の中の人達の意見を吸い上げて、展開していく能力がなくなってきている。
　既成メディアは現状に安住しすぎて、ムーブメントを起こすだけの力をなくしつつあるように見える。

10分で作るRailsアプリ

　最近、Ruby on Railsが熱い。
　ふと見つけた驚異的な記事。

「10分で作るRailsアプリ アプリケーション編」

　Javaを始めた時と同じぐらいのインパクト有り！

NAgileメモ

メモ。

NAgileで始める実践アジャイル開発

第1回 .NET＋アジャイルなら本当に幸せになれるのか？

Ruby関西勉強会に行ってきた

　第6回 Ruby勉強会＠関西へ行ってきました。
　面白かったー。

　関西でもRubyやっている人は多いんですねえ。
　京都女子大で開かれたせいなのか、松江、東京、広島から駆けつけた人もいて、50人も集まって大盛況でした。
　内容は、Rubyでゲームアプリを作る話とRubyのTestUnitを使う話で、業務系システムの話やRuby on Rails、BioRubyに興味を持っていた僕にはちょっと物足りませんでしたが、勉強会の雰囲気がいいし、懇親会も女子大生とか京大生も来て元気だし、楽しかった。

　場所を提供した小波先生と、懇親会でずっと話し込みました。

「Rubyを大学教育で使っているのは、うちしかない」
「以前はPascalを使っていたが時代遅れになった。Rubyならオブジェクト指向にも触れられるし、ソースの可読性が高い」
「プログラミングには、コンピュータの仕組みを知らないと書けない部分と、書きたいロジックそのものの部分の2つがあるが、Rubyなら、後者に意識して書くことが出来る」

　小波先生は教育熱心な先生で、僕も大学時代はこんな先生の研究室へ行きたかったな、と思ってしまった。。

.NETよりもJavaの方が面白い

　.NETは面白くないなー、と違和感を感じつつやってます(m_m)
　オブジェクト指向設計とか、AAfNによる3層構造とか、Webサービスとか、技術的には面白いのですが、Javaと違うなーという点がすごく多すぎな気がしてます。

【１】オブジェクト指向をやっているという感覚よりもWindowsAPIを必死に覚えている感じ

　C#、ASP.NET、VB.NETをやると、確かにプログラミングはオブジェクト指向っぽいけれど、何か感覚が違う。
　昔C++をやっていた頃、C++をやっているのではなく、MFCライブラリを必死に覚えているのと同じのと同じ感覚に近い。
　プロパティ、イベント、デレゲート、属性、など、Javaよりも優れている部分は確かにある。
　でも、フォームを作って、コントロールをペタペタ貼り付けて画面を作っていく操作に、オブジェクト指向設計を意識している人は多いのだろうか？

【２】.NETは、昔のVBで作ったC/Sシステムの置き換えの延長にあるから、ややこしい

　レジストリに登録したり、COMを使ったり、仮想ディレクトリを設定する時にセキュリティレベルを考慮したり、Windows特有の環境構築が面倒なことが多い。
　つまり、昔の遺産（VB資産）があるので捨てられないのではないか？　実際の案件でも、過去にVBやAccessでやっていたシステムを.NETで置き換えるシステム開発は多い。。
　.NETを使う最大の理由は、VB資産を再利用できる所にあるからだろう。
　でも、ネックになるのは、COMじゃないだろうか？　.NETで作ったDLLは、Javaのjarのように自然に使えるのに、COMだと使いづらい。
　Javaなら、過去の古い資産はないから、簡単なのかもしれない。

　MSツールの理想系は、C/Sシステムではなかろうか？
　リッチクライアントはその流れにあるのではないか？
　C/Sシステムは、本質的に２層構造にならないか？
　以前のASP（VBScript）のシステムは、開発者が設計を意識しないと２層構造のアーキテクチャになり、ぐちゃぐちゃになる。
　ASP.NETは、AAfNのおかげで3層構造を意識させられるけれど。

【３】何故、いちいちコンパイルするのに、必ずビルドボタンを実行しなくてはならないのか？

　Eclipseを使っていた人から見ると、保存（Ctrl＋S）でコンパイルしてくれなくて、いちいちビルド（F5）を幼くてはならないのは、違和感がすごくある。
　プログラミングは、やっぱり書きながら、ああだこうだと考える部分が多い。だから、リファクタンリングをよくするけれど、その作業はサクサクやってほしい。考える作業を邪魔する作業はなくして欲しい。
　こんなことを感じるのは、かつてVBでえらい目に遭った僕だけだろうか？

　僕がJavaに惹かれるものは、「なぜJavaにこだわるのか」の記事と全く同じ。
　Javaを突き詰めることは、IT業界の最新技術を追いかけるのと同義。オブジェクト指向をマスターすることにつながるし、更には、開発プロセスやオブジェクト指向設計、デザインパターン、ビジネスモデリングまでつながる。すごく面白い。
　Javaには「愛嬌」がある。全くその通り。興奮させられる所がある。
　オープンソースを探してみれば、Javaの方がはるかに多いし、ERPやプロジェクト管理など、とてもフリーとは思えない業務システムも転がっている。
　全ては、プログラマがJavaの潜在力を知っていたから。

　.NETやJavaを比較すると、開発環境もプログラミング・スタイル以上に大切であるように思う。
　丁度、SmallTalkでも、ガベージコレクションなどオブジェクト指向開発環境が表裏一体であったように。

プロジェクトリーダーやマネージャに問われる能力は何か？

　今日の昼に50代のマネージャと昼食しながら、プロジェクトリーダーの仕事に関して考えることがあった。

【１】プロジェクトリーダーの特徴
　5人ほどのチームで開発する時、プロジェクトリーダーの能力には特徴がある。
　一つは、システムの設計や技術を細部まで知り尽くして技術者としては殆ど完璧なタイプ。この場合、基本設計や仕様確認ではお客さんよりも詳しいので信用できるが、プロセス管理や交渉にあまり長けていない。2次請け以下の会社に多い。

　他方は、仕様や技術は詳しくないが、お客さんとの交渉やプロセス管理に長けているタイプ。この場合、サブリーダーが技術統括者の役割を担う。1次請けの会社に多い。この人達は基本的に手配師。

　プロジェクトリーダーは現場監督そのもの。ソフト会社で最も戦力となる人達だ。
　手配師はプロジェクトリーダーと言うよりも、もう一段格上のマネージャに近いように思う。

【２】技術者と管理者の役割を使い分けて、問題解決にあたる

　プロジェクトリーダーの仕事は、トラブル解決にある。それができなければ必要ない、と言い切っていた。
　よく考えてみれば、作業担当者が責任を果たせなかったり、進捗が遅れたりする諸々のトラブルを解決する役割をプロジェクトリーダーは持つ。
　その時の解決方法として、技術でカバーするのか、プロセスを変更して攻めるのか、リソースを増やすのか、色々手段がある。

　はぶさんの本にも書いてあったが、困難な場合に陥ったら、意識的に自分の立場を変えてみることも、手段を思いつくヒントになりうる。
　技術者で駄目なら管理者になって、人の入れ替えやプロセス変更で対応してみる。
　管理者で駄目なら技術者になって、自分でカバーするとか、アーキテクチャを見直したりしてみる。

　彼がやるべきことは、どんな手段を選択してもいいから目的を果たすこと。
　彼が考えるべきことは、問題解決によって目的を果たすことであり、手段にとらわれすぎることではない。

【３】手配師に必要な能力は何か？

　僕の少ない経験から見ていると、手配師はリソースの補充・管理の能力が優れている。優れた技術者を引っ張ってきたり、スケジュールの調整をしてバッファを持たせたりするのが上手い。

　マネージャから聞くと、プロジェクトリーダーとマネージャは仕事の質が違う。
　僕はチーム運営が仕事の殆どとイメージしていたが違っていた。
　チーム運営は1割に過ぎない。むしろ、コスト管理、リスク管理、スケジュール管理が3割ずつぐらいの割合でどれも大事ということだった。
　コスト管理とリスク管理は、プロジェクトリーダーが見落としやすい所かもしれない。

　今のIT業界は、中国でオフショア開発し、日本で設計とプロジェクト管理をするように役割分担する流れにある。
　でも、ビジネスとしてうまく成り立っているのだろうか？
　XP祭り2005でMSの萩原さんが

「日本人は個人や小集団では優秀だがマネジメント能力に欠ける」

と言ったことが気になって仕方ない。

.NETをやっていくためのTODO

　Java一筋だったのに仕事でC#をやっている(m_m)
　プログラミングも設計もやり方はJavaと同じだけれど、何か違和感を感じつつやっていて気持ち良くない。
　.NETを今後やっていくために理解すべきタスクをリストアップしておく。

【１】NUnitでUnitTest

・VisualStudioと組み合わせたテスト環境
・Javaにはない.NET特有の注意点
・NAgileを調査

【２】Application Architecture for .NET (AAfN)に学ぶ.NETシステム設計

・J2EE Blueprintsにある設計思想とどのように違うのか？
・J2EEのPetShopとの違い
・O-Rマッピングは.NETでは問題にならないのか？

【３】次世代開発基盤技術“Software Factories”詳解

・Software Factoriesの思想はパッケージ製品の設計・開発にどれだけ役立つか？
・開発プロセスとの関連
・VisualStudioの次期バージョン調査

　ネットで検索しても、@ITやGotNetぐらいしか有用な情報がない。
　色々いじってみた所感では、.NETはJavaよりも技術が枯れていないな、と感じる。
　本当のところはどうなのだろうか？

インターネットが及ぼす変化とは？

　「フォーサイトクラブ・セミナー「ウェブ社会『大変化』への正しい対応・間違った対応」梅田望夫さん講演ログ」を読むと、以前書いた「インターネットは高速道路」の内容を煮詰めている気がする。

【１】インターネットは能力増幅器

　計測データや考え方のフレームワークは、Googleで検索すれば、少なくとも集めることは出来る。インターネットは能力増幅器、というフレーズは鳥肌が立った。
　インターネットをうまく利用できれば、簡単に飛び級できる。梅田さんの話によれば、若い人ほど、そのツールをうまく使いこなせるし、それによって過去の世代よりも大きな可能性を秘めていること。

　ただ、これから問われるのは、知識よりも、論理的に自分の考えを組み立てて、仮説を作り出す能力だろうか？

【２】インターネットが人間関係の精神的距離を狭める

　上記の内容は、大前研一と似たようなことを言っていたなあと思う。
　「考える技術」を立ち読みしたけれど、こんな一節があった。
　大前研一の理論を研究している人達との会合で、ニュージーランドやヨーロッパでも、彼だけでなく奥さんの趣味まで知っていたことに彼は驚き、そして、初対面なのに色んな話が出来て、以前から友達だったような懐かしい雰囲気を感じた、と。
　この感覚は僕も分かる。メーリングリストやインターネット上のコミュニティで知り合った人達とネット上でやり取りした後、リアル世界で会ってみると、あまり違和感なく、以前から友達だったように、すぐに親しくなれる。

　インターネットがもたらす波及効果はまだまだあろうが、この2点が僕には、自分自身の経験も込めて、大きく感じる。

「リーンソフトウェア開発」～アジャイルとウォーターフォールを繋ぐミッシングリング

　とある勉強会で「リーンソフトウェア開発」第4章「できるだけ速く提供する」を発表した。
　レジュメを作りながら、そして、議論しながら、色々と考えさせられる所があった。

【１】「リーンソフトウェア開発」の読者層は、オブジェクト指向や反復型プロセスを知らない計画主導プロセス経験者である

　XPの解説本を読んでも、原則やプラクティスの本質が何なのか、ペアプロやイテレーションなどのプラクティスがどのように関連付けられているのか、分かりにくい。
　この本では、２２個の思考ツールを使ってアジャイルの本質を説明している。4章では、制約理論や待ち行列、リトルの法則などを使って、計画主導プロセスのどこに弱点があるか、アジャイルプロセスで気を気を付けることを明らかにしている。
　オブジェクト指向開発者やアジャイラーが当たり前に思っていることと、計画主導経験者がどうしても理解できないギャップを埋める本ですね、と仰った人がいたが、その通りだと思った。

【２】アジャイル開発の優位性を、もっと理論的な説明で補強できないか？

　制約理論や待ち行列、リトルの法則などを使って論理的に説明を組み立てているのは面白かった。
　でも、細かく疑問をぶつけてみると、アナロジーは分かるのだが、しっくりこない点がある。自分が説明できるほど理解し切れていないのかもしれないけど。
　もう少し理論的に補強できないだろうか？　また、他の理論を使って、説明を補強できないだろうか？

　久しぶりに面白い本だったな。

モテ男バイブルにはデータモデリングがある？

　「お姉さんの「男の恋愛相談室」」という怪しいBlogに「モテ男バイブル」本リストがあるのだが、何故か渡辺さんの本「業務別データベース設計のためのデータモデリング入門」が飾られている！

　モテ男にはデータモデリングが必須なのか？
　謎だ。。
　週末に読んでみよっと(^^)

P.S.
　上記の本に「女性とデート先の組み合わせに関する諸問題」からデータモデルを導く一節があった。
　もしこれを指しているなら、Blog作者はDOAを使いこなしているのか？？

概念に正しい言葉を当てはめないと混乱の原因になる

　要件定義のプロセスで、コンサルタントが作った要求定義書から不明点を洗い出している時、「概念に正しい言葉を当てはめないと混乱の原因になる」ことを経験した。

　とあるシステムの要件で、データを論理削除する処理があったのだが、「この文脈では論理削除と言うべきではなく、法律用語に従って、廃棄とか廃止と呼ぶべきだ」と指摘を受けたことがある。
　論理削除という言葉では、削除という意味合いが強すぎて、本来は、データが別の異なる状態に移ったことを強調すべきだ、ということだった。

　要件定義では、用語集を作るのが大事ですが、その理由をもう一度再認識した。

　ネーミングは難しい。
　だが、XP祭りで会ったXPerたちはネーミングが上手かった。
　例えば「ふりかえり」「ペアボード」「ニコニコカレンダー」「あんどん」のように。

　以前、数セミで、数学者よりも物理学者の方が概念に対するネーミングがうまい、彼らは抽象的な方程式に隠れている物理的意味を知っているからだろう、みたいな記事があったのを思い出す。

　最後に関係ないけれど、ウイスキー「Early Times」がありますが、どのような言葉を当てはめるべきか？
　僕は、「早すぎた日々」などとトンチンカンな訳をした。
　後輩の子は「若気の至り」と訳していた。さすが文系出身(^^)

ITの技術革新はOSよりもWebソリューションへ移っている

M$が次期WindowsOS　Vista　を来年に売り出すらしいが、盛り上がってないように見える。
理由は、OSの技術革新の衝撃が薄くなっていて、むしろGoogleのようなWebソリューションへトレンドが移行しているからではないか？

WindowsOSやOfficeのバージョンがUPしたからといって、我々ユーザの環境が劇的に変わるわけでもない。バージョンアップを煩わしいと皆呟いている。
ActiveDirectoryの導入で余計に手間がかかっていないか？

むしろ、Googleが生み出すサービスの方が我々のWebの使い方そのものを劇的に変化させている。
例えば下記のサービスがある。

１．容量１GものWebメールサービス　GMail
２・デスクトップ検索サービス　GoogleDesktop
３．地図検索サービス　GoogleMaps

【１．容量１GものWebメールサービス　GMail】
GMailをまず使ってみて驚いたのは、勝手にリフレッシュし、メール一覧を更新してくれること。
さすがAjax。

【２・デスクトップ検索サービス　GoogleDesktop】
以前まで、ローカル内のテキスト・Office・PDFファイルを検索できるようにするために、Namazuをインストールし、定期的にバッチファイルでインデックス検索させるようにしていた。
ActivePerl＋Kakashi＋Namazuを入れて、日本語で検索できるように設定するために結構手間取った。
GoogleDesktopなら、ファイルだけでなくメールまで検索で来てしまう。

【３．地図検索サービス　GoogleMaps】
GoogleMapsは面白い。
市販の地図情報システムは今だにC/Sアーキテクチャの古いシステムが多く、有料のため使っていて楽しくない。
記事「渺望と俯瞰　：keyhole　が　3D地図と検索を関連づけるか：Google　Earth　スタート」ではGoogleMapsの威力を下記のように説明している。

（引用開始）
(前略)
GoogleMapを見ればわかるが、日本の地図表示・検索サイトよりも遥かに豊かな情報が関連付けて閲覧できる。
１．Mapまたは衛星写真
２．現在のレストランなどのWebコンテンツ
の２つを、検索エンジンが、位置座標と関連付けてView+スクリプト表示しているだけである。
一方、多くの一般の地図サイトは、なんと時には有料で、サーバーに入力させて、（労力と費用を使って）、ほとんどのレストランが参加していないレストランガイドサイトとなっている。
このGoogleMapと同様の機能をMyサーバー上に、実現できるのが　GoogleWebAPIである。思わぬアイデアが出現しそうなので、お楽しみである。
（引用終わり）

つまり、日記を手軽にUpできるBlogのように、自分オリジナルのレストラン地図とか、自分の地区の選挙マップとか作れる。

例えば、GoogleMapsEditorを使えば、こんなに簡単に地図が作れてしまう。

なにわのお笑い劇場：ワッハホール

他にも、AmazonのWebサービス、ライブドアが提供したWikiサービス、Skypeもワクワクする。

次から次へと現れるWebソリューションに触れると「IT技術は、コスト削減のようなつまらないことに使われているが、本来は、新しい産業を生み出すことに使われるべきだ」とXP祭り2005で講演したM$の萩原さんの意見を思い出させる。

XP祭り2005の公式記事

XP祭り2005の公式記事は下記が一番詳しい。

http://itpro.nikkeibp.co.jp/article/NEWS/20050905/220618/
XPの祭典「XP祭り2005」開催，「顧客にすらわかっていない要求をいかに引き出すか」が大きなテーマに

XP祭り2005の感想

9/3にお台場で開かれたXP祭り2005に行ってきました。
面白かったー。
朝5時に起きて新幹線で東京へ向かい、夜12時まで講演＋懇親会＋2次会で騒いだので、1日がすごく長く濃かった。
代表の倉貫さんほかスタッフの皆さん、感動をありがとう。

受けた刺激があまりにも多すぎて整理し切れていないので、感想を箇条書きで残す。

【XP祭りの会場　お台場】
「お洒落なお台場」のイメージがあったが、場所はちょっと離れたオフィス街。
会場は、円形劇場の座席に講演者が舞台で発表するため、場の雰囲気がどんどんヒートアップしていく感じだった。
スタッフによると200人もの来場者が来たとのこと。遠く沖縄（！）から来たエンジニアもいた。
大阪から来たエンジニアは、僕を含めて6人ぐらいだろうか？

【平鍋さんのProject Facilitation】
最近よく聞く「見える化」のお話。
ソフト開発はプロセスも成果物も見えにくいという難点を解決するために、こんな手法を考えてみました、という話。

ビルドが失敗したら赤ランプが付く「ソフトウェアあんどん」。
開発者の気分を1日の最後に赤と青でカレンダーに張っていく「ニコニコカレンダー」。
こういうツールがあると、開発者のモチベーションも上がるだろう。何よりも楽しい。

劇団ぺけぴー（XPを日本語で読み直したみたい(^^)）による朝会のアンチパターン例は面白かった。
・一人の話が長い
・リーダーがメンバーの話を遮る
・誰も喋らない
朝会だけでなく会議でも、場の雰囲気が建設的でないケースによく当てはまる。

PFの価値や原則、アンチパターンの解決方法など、もう少し詳しく聞きたかったなあ、というのが率直な感想。

【ひがさん】
今日のひがさんはオールバックの金髪に、黒Tシャツとジーパンでカッコイイ(^^)

講演する時は、会場の雰囲気に呑まれないように「スター」になりきるために、いつも外見を大きく変えるらしい。他の講演者がひがさんのなりきりメガネを借りてました。

業務マニュアルを作ることで上流工程を進める話は興味深かった。

僕の現場では開発プロセスそのものが標準化されていないため、ひがさんのやり方がおそらく一番しっくり来る気がする。
きちんと仕様書が揃った環境でないとプログラミングできない若手がいるし、マニュアルや仕様書が最終的に納品物に含まれるから。

でも、話はXPにあまり関係なかったかも。

【ディスカッション】
豆蔵の荻本さん、M$の萩原さん、Seasarのひがさん、関さん、平鍋さんを交えて、言いたい放題のディスカッションも面白かった。

ひがさんも関さんも萩原さんも皆揃って、フレームワークは嫌いだ、という発言はビックリ！
理由は「俺様が作ったフレームワークを、下々のPGに押し付ける」のが嫌いらしい。
「メンバーがフレームワークとアプリケーションのチームに分かれるのが嫌だ」
「アプリ開発者が見つけたFWのバグをすぐに直せない。だから、そのFWのバグを回避するようなぐちゃぐちゃのプログラムを書いてしまい、後でメンテナンスするのが大変」
という関さんの話が最も率直だった。

M$の萩原さんの話が興味深かった。

「私はソフトウェアアーキテクトであってITアーキテクトではない」
「アジャイルはソフトウェア工学ではない。工学的基盤の上でアジャイルのプラクティスがあると理解している」
「今の私の興味はSoftware Factoriesにある」

「個々の日本人は技術者として能力は高いが、集団になると質が落ちる」
「欧米人はマネジメント能力が比較的高い」

ソフトウェア開発の動機は何ですか？というコメンテーター倉貫さんの質問に対し、M$の萩原さんの答えが一番印象に残った。

「ITを使って革命を起こしたい」
「現在は鉄道が普及し始めた時代と同じ。百貨店は鉄道という産業が興隆して作られた。鉄道によって、消費都市と生産都市が結ばれ、都市の拠点に百貨店が作られて、新しい産業ができた」
「ITも同じで、ITの普及によって新しい産業を作り出せるはず。今はコスト削減とかつまらないことにITを使っている」

「ソフトウェアで世界を変えたい」と言った(はずの)ビルゲイツの言葉を思い出させる。
ITエンジニアもこれぐらいの気概を持たないとね。

最後に、劇団アンプラーズ（Anti-Practiceからひねたらしい）の活劇が面白かったので、2コマほど載せます。関西人ならボケツッコミを入れて、もっとひねることができるかも。

弟：あにきー、ペアプロって何だ？
兄：ペアプロっていうのはな、ペアで入る風呂のことなんだよ。





The End

非同期処理のアーキテクチャとは

最近、リッチクライアントが流行している（ように見える）。
理由は、UIの操作性よりも、非同期処理の実現にあるのではないか？

Webの技術では同期処理が基本である。HTTPのリクエストを投げてレスポンスを待ちページを表示する。
だから、WebはUIの操作性だけでなく、技術的にも制約が大きい。

非同期処理は、つまりバッチ処理。
業務系では至極当然のアーキテクチャ。
バッチ処理は設計力が鍵を握る。

Web上での非同期処理の実現方法は何がBetterか？
答えはWebサービス。
つまり、クライアントはXMLデータをバックグラウンドでサーバーとやり取りする。
Googleがこのアーキテクチャをうまく使ってサービスをどんどん提供している。

Ajaxの凄さは、UI操作性だけではなく、非同期処理にある。
Ajaxの威力を見せつけた例は、Google Mapsだった。

GMailは、勝手にリフレッシュし、メール一覧を更新する。
GMailにもAjaxが使われている。

GoogleMapsEditor　は、GoogleMapsAPI を利用して地図を作成する。
ユーザが住所と関連付けて書き込んだ情報はローカルのXMLに保存される。
すごいのは、そのXMLを使うと、地図情報を埋め込んだ出力したHTMLファイルだけでGoogle Mapsが利用可能になること。
一般に地図情報システムは、クライアント：VBアプリ＋サーバー：ベンダーごとの製品ゆえ、非常に高価で、バッチ処理が基本なのでレスポンスも良くなく、使い勝手が悪い。Google Mapsは、普通の地図検索製品よりもはるかにお手軽でしかも無料で地図を作れるサービスと技術を提示したことに意義がある。

他にも、Blogがある。RSSはWebサービスそのもの。
つまりプッシュ配信サービスと言ってよい。

Webソリューションの進化系はおそらく非同期処理のアーキテクチャを洗練させることにあるのではなかろうか？

XP祭り2005がもうすぐ！

今週末9/3に開かれるXP祭り2005へ行ってきます。
平鍋さん、ひがさんという大物の講演があるので、すごく楽しみだぞー。

XPJUG関西とXPJUG東京本部は何か違いがあるのだろうか？　
XPJUG関西のコミュニティにいると、東京の活動を殆ど意識してませんが。。

XPにも関西流、東京流という流派があるんでしょうか？
行ってみてこの眼で確かめてきます(^^)

情報を共有化した方がリスクが少ない

「情報の私物化を禁止する」記事を読んで、情報の共有化について改めて考えさせらる所があった。

ソースコードの共有化は、XPだけでなく、普通のウォーターフォール型プロジェクトでも、VSSやCVSのようなソース管理ツールで実現される。その意味は、複数人の開発でソースの修正権限を制限したり、バージョンごとのリリース管理などの技術点があげられるけれど、「会社の資産であるソースコードを自分のPCだけで保持してはいけない」という発想はなかった。
ソースコードの共有による長所は、先の技術点だけでなく、他人のソースを参照できたり、自分固有のライブラリを作らないようにしたり、他人に見られることでより綺麗なプログラムを書こうとするようになる、などがあげられる。
だが、もっと大事なのは、情報を共有することで、悪い情報をすぐに知ることが出来るようになることではないか。

顧客と要件定義や見積もりのメールのやり取りでは、必ずステークホルダー全員にCCすることが多い。その意味は、プロセスの状況提示であり、CCされた人は誰でもそのプロセスに割り込みできる。
特に顧客とのメールのやり取りは、こちらの状況が悪くなった時、「以前こんなことを言ってましたが」と引っ張り出して、履歴として後で使える。

ソース管理やメールだけでなく、ビジネスプロセスに関する情報を生成から消滅まで保持しておくことは、「何かおかしい」という時に原因探しなどトラッキングに使える。
情報を共有化したほうが、状況が悪くなったことをいち早くキャッチできるようになる。
ビルゲイツも、「悪い情報は早く知らせた方がいい」と言っていたが、そんな仕組みをMSも持っているのだろう。

Think small

　はぶさんの日記を読んで「think small」「分割統治」の考え方は、プログラミングだけでなく、決断のようなマネジメントの側面でも使える事実に改めて気付かされた。

　また、別のBlogでは、考える総量100kgl(kgl=考える)をチームごとに分割したとしても、どこかにしわ寄せされてしまい、何も状況が変わっていない経験談が載せられている。

　物事を小さく分割して、難しさを落としていくこと。
　決断する勇気を小さく分割して、すぐに決断できる内容に落とすこと。
　小さくすれば、イテレーションを短くできるから、失敗したとしてもすぐに取り返せる。
　マネジメントに携わるポジションにいると、役割分担できるようにするために仕事を分割していく。
　「Think small」は一つの技術。

XPファシリテーションによる信頼形成

　明日から開かれるソフトウェア・プロセス・エンジニアリング・シンポジウム2005（SPES2005）で「XPファシリテーションによる信頼形成 ～ 実践！計画ゲームによる顧客と開発者との信頼づくり ～」が催される。
　関西のXP関係者が殆ど集合して、実演するとのこと、内容が興味津々。
　すごく行きたいーが、当然仕事で無理。

　仕方ないので、本を2冊購入してきた。

ファシリテーション入門 日経文庫

コーチング・マネジメント―人と組織のハイパフォーマンスをつくる

　2冊とも、軽く読める本だが、書評が良くて以前から気になっていた本。
　マネジメントに関するハウツー本は何となく訝しくて敬遠気味だったが、アジャイル関係を漁っているうちに、一つの知識体系としてまとめられている気がする。知識があるだけでも意外に役立つ。
　チームを回す技術は奥が深い。

再帰SQL part2

yuuntim さん、半年前に書いた記事「再帰SQL」のコメントありがとうございます。
最近はOOAからどんどん離れて業務屋さんになった経験も踏まえて、もう一度考えを整理してみます。

【１】再帰ＳＱＬはツリー構造の情報を検索する時に使える

あの時は再帰ＳＱＬの意味や使い道が全く分かっていなかった。しかし、今の仕事のおかげで、再帰ＳＱＬは重要であり、色んな所で使えることを経験した。
再帰ＳＱＬが使われる具体例は二つすぐに思いつく。
一つは、個人の組織情報が階層構造になっている場合、もう一つは、商品がカテゴライズされていてカテゴリ情報が階層構造になっている場合だ。
組織構造の例は、アナパタのパーティそのもので、再帰構造になっている。
どちらにせよ、組織マスタとかカテゴリマスタのテーブルに階層構造の情報がツリー構造で保持されている時に有効になる。
但し、当然のことながら階層が深いほど、再帰ＳＱＬのレスポンスは悪くなる。

【２】再帰ＳＱＬはOracleでは普通に使われている
Oracleでは、CONNECT BY 句を使えばよい。
例えば、下記の例は良く出てくる。

--job='PRESIDENT' が、親子関係の頂点で、親子関係は empno=mgr が条件である従業員を検索する
select empno,level,lpad('-', 2*(LEVEL-1),'-') || ename ename ,mgr,job from emp
connect by prior empno = mgr start with job='PRESIDENT

余談だが、connect by 句はＳＱＬ本をいくら漁ってもなかなか出てこなくて、調査に随分苦労した。ツリー構造のデータなんて、生産管理でも良く出てくるのに、何故解説がないのだろう？
実はSQL ServerやDB2では上記SQLは使えないし、再帰SQLも最近までサポートされていない。Oracleだけver8以前からもサポートされていたらしい。さすがOracle。

【3】「生産管理・原価管理システムのためのデータモデリング」再考
今頃になって読み返して、まだ理解できていない点はありますが、少しずつ腑に落ちつつある。

「部品構成のループのチェック」についてすぐに思い浮かぶのは、ツリーを深く下がって検索する時に最下層がどこまでなのかを既に把握できていれば、計算しやすくなるはずだろうということ。
だから、構成品の削除・更新があるたびにLLCを再計算しているわけだ。これは確かに重い処理だと思う。

「所要量計算（あるいは原価計算）を行う品目の順序を決定する」処理の解説、yuuntim さんありがとうございます。
親品目の所要量の総計が計算できた後に、下層の品目の計算を行うために、ＬＬＣの昇順で降りていくわけですね。なるほど。この計算はすごく重たそう。
MRP所要量計算のアクションダイアグラム（P176参照）はPL/SQLで書いたとしたら、一時変数のカーソルでループ処理するために、すごく読みにくいだろうなあと勝手に想像します。

この本はまだ奥が深いです。また読み直します。

最近はクラス図よりもER図を片手に仕事する時が多い。仕様を理解できない時、ER図からインスタンスごとのリレーションを結んで、データがどのようにつながっているかを自然に書き散らすようになった。その感覚はオブジェクト図を書いているのと同じ。
データモデリングだろうがオブジェクト指向モデリングだろうが、やっていること、考えるやり方は結局似ている気がする。

手配師になるか技術屋で生き残るか

「技術力のないSE」
「技術力のないSE(2)」

の記事を読むと、今の日本のIT業界の限界が見える。
「最近の大手ベンダーのSEは、「手配師」っぽくなっている」というのはよく見かける。
彼らも昔は汎用機で腕を鳴らしたのかもしれないが、ドッグイヤーで進化するオープン系システムの流れに付いていっていない。
ではプロジェクト管理が上手いのかというとそんなことはない。いくら元請であろうとも、利害関係者が多くなるほど、状況を制御しにくくなる。

IT業界に身を置くと、手配師になるか技術屋で生き残るか、その選択にいつも迫られる。
マネジメントが必要なのは分かるのだが、手配師は営業でもないし技術屋でもないから役割が中途半端に感じる時がある。でも、日本で技術屋として生き残るには、超一流の技術があるか、最先端の技術を常に持っているか、どちらにせよ相当に難しい。

今のご時世、プログラミングという最も技術力を身に付けやすい工程が中国に流れている。だから、中国へ仕事を流すために、日本人SEは仕様書を書くこととプロジェクト管理の二つの仕事をこなすように、と口を酸っぱく言われる。でも、何かおかしくないか？
最近思うのは、WordやExcelで仕様書を大量に書いても、進捗スケジュールを素早く詳細に書き上げたとしても、ステークホルダーとやりとりしても、スキルは上がっていない気がする。中途半端なんだよね。中間管理職であって、技術者でも経営者でも営業でもない。

以前なら、若い日本人は開発フェーズでスキルをつけて、設計・要件定義・プロジェクト管理のフェーズへスキルアップして行った。でも今は、プログラミングさせてもらえる環境がはっきり言ってあまりない。日本人SEが技術を磨く場所がどんどん減っている。
何かが間違っていないか？

アジャイルプロジェクトマネジメント

「アジャイルプロジェクトマネジメント 最高のチームづくりと革新的な製品の法則」がついに出版されました！

さっそく購入して、あとがきに自分の名前が掲載されているのを確認して、ちょっぴり嬉しいやら。
「リーンソフトウエア開発～アジャイル開発を実践する22の方法～」と共に、読めば読むほど奥が深く感じる本だと思う。

マネジメントの断層

　仕事を数年すると、次のステップに上がるには断層があることに気付く。
　ヒラ→中間管理職→経営者へステップアップする時、仕事の内容が大きく変わる。その変化についていけない時がある。断層の本質は何かを考えた時、「ビジネス・リーダーへのキャリアを考える技術・つくる技術」に「断層はマネジメントにある」と書かれてあって思わずはっとした。

　ヒラからプロジェクトリーダーになる時、仕事の質が変わる。
　言われた仕事をこなすことから、チームを回すためにチーム内の問題を解決することに変わる。メンバーが仕事しやすい環境を整えたり、経営者や顧客をコントロールしたり、まさに中間的な階層で調整する役割を果たす能力が必要になる。
　プロジェクトリーダーになると、プレーイングマネージャとはいえ、現場の仕事から離れる時が多くなる。

　経営者になる時、更に仕事の質が変わる。
　ビジネスの戦略を打ち出すことや、自分の会社に足りないものは外部からリソースを調達できる人脈が必要になる。現場の仕事から完全に離れて、組織を動かすことが仕事になる。

　断層を越えるには何が必要か？
　本を読んでも、他人の行動を見ても、身に付かない。
　そのポジションで仕事して結果を残すしか身に付かないのだろう。

高速にサルのように失敗を繰り返す

　渡辺さんのBlogで、要件定義フェーズでモデリングする場合のコツが書かれていた。

（前略）気に入ってもらうまで、山ほど失敗を繰り返さねばなりませんが、そのときに必要なのが「似てないならアカラサマに似てないとわかるような図法」で、ＤＦＤやＥＲＤやパネルイメージはそのために適しています。高速に、サルのように失敗を繰り返す。これがカギです。

　最後の一文だけ着目すると、これってアジャイル開発のプロセスに似ている。モデリングでも短いイテレーションを何度も繰り返してモデルを洗練させていくわけだ。
　でも、短いイテレーションで回すには、短時間でモデルを書くために複雑な仕様を分割する技術と本質を表現できるモデリング手法が必須だ。
　業務系システムを開発する時は、結局、ＤＦＤやＥＲＤを書かざるを得ないのではないか？

Smalltalkにはif文がない

　「Smalltalkにはif文がない」記事を読んで、なるほどと腑に落ちた。
　SmalltalkではTrue・Falseクラスがあるのは知らなかった。
　IF文もWhile文も全てメソッド、ブロックで実現できてしまうのか。

　「プログラミングの基本はIF文を極力排除する」記事と同じく、オブジェクト指向の良さは、ポリモルフィズム、イテレータにあると思うが、それらは結局、IF文、While文を除去する方向へ進化している。

関連クラスの概念はOOAではDOAよりも理解しにくい

　渡辺さんのBlogで関連クラスを通してOOAとDOAの対比が議論されている。すごく面白い！！

「関連クラス」をデータモデルで解き明かす（前編）

「関連クラス」をデータモデルで解き明かす（後編）

　関連クラスをクラス図で書くとどうしても違和感があるが、渡辺式ER図を見ると違いは一目瞭然。
　多対多の関係はOOAでは整理し切れていないという感触があるが、渡辺式ER図では親子関係に相当するため不自然ではない。
　「オブジェクト指向は元々下流工程の技術に過ぎなかったのに、上流工程に進出してきてからIT業界に混乱をもたらしている」という渡辺さんや佐野さんの意見は納得せざるを得ない部分はある。

エンタープライズ アプリケーションアーキテクチャパターン

　ついに出た！

「エンタープライズ アプリケーションアーキテクチャパターン Object oriented selection」

マーチン・ファウラー (翻訳), 長瀬 嘉秀

　しかし、6,090円は高いなあ(T_T)

モデル・ギャラリーって何処かにない？

　とある講演録を読んでいたら、ミュージシャンも他人の曲を聴いて、真似て弾くことを繰り返してうまくなっていくように、モデリングも優れた教材を真似して試してうまくなるはずなのに、いい教材がない、という意見があった。（渡辺さんのBlogにもありますが）
　モデル・ギャラリーは何処かにないのだろうか？
　
　僕がイメージするモデル・ギャラリーは、DOAやOOAという技術レベルではなく、業務に特化したモデル群。小売、製造業、金融、医療、などの業界で頻繁に出てくる業務フローをモデル化したもの。
　そして、そのモデルは、システムとして落とせるものでなくてはならない。業務用語だけの話で閉じているだけでは、ITエンジニアとして無意味だから。
　となると、本でもインターネットでもなかなか見つからない。

　すぐに思い浮かぶ本はアナリシスパターン―再利用可能なオブジェクトモデル」。しかし、難しくて読みにくい。
　最も読みやすく役立ちそうな本は、渡辺さんの本生産管理・原価管理システムのためのデータモデリング」ぐらい。この本の最後にある会計の章は、DOAの観点から説明されていて、非常に分かりやすい。他の会計の本は、経理屋の視点から書かれているので、モデルへ変換するのに手間がかかる。

　最近、面白そうだと思うのは、モデリング道場ML。
　2ヶ月前に「『酸っぱいブドウの論理』と『甘いレモンの論理』」を題材としてモデルに書いてみる話題があった。こんな話をモデルにできるのか？と疑問に思っていたが、その時の児玉さんのコメントが面白い。
　この現象は心理学でいう認知的不協和に当たるそうだが、似たような話として、

「UFOがX月X日に降りてくると大々的に宣伝していた団体が，その日に降りてこなかったという事実を突きつけられて，その団体のメンバーはどのような行動を取ったか，なんて心理学の授業で教わりませんでしたか。」

と。その答えは、他のアーカイブにあります。面白すぎ(^^)

IT業界は残業が多いのですか？

　今日、母校の大学へ会社説明会に行ってきました。
　3回生の人から
「IT業界は残業が多いと聞いたのですが、本当ですか？」
と尋ねられて、返答に正直困りました(^^;)
　この業界のビジネスマンは、後輩から上記の質問をされた時、どのように答えているのだろうか？

　僕の少ない業界経験では、1年に1回は修羅場が津波のようにやって来る。終電帰り、休日出勤、徹夜の開発が1ヶ月くらい続いて、本番システムリリース後、ようやく落ち着いて元の生活に戻る。初めて徹夜で作業させられたときは、皆さんこんな安月給でよく仕事しているなあ、と他人事のように思っていた。

　この業界、1ヶ月200時間労働なんて当たり前。
　はぶさんの本
では「月40時間程度の残業が3ヶ月続いたくらいで過労死なら、この業界の人間90%は死んでいます」と書かれていますが、同感。
　青色ダイオードの中村修二さんは、その業績にもかかわらず低収入だったため、「スレイブ中村」と言われたそうだが、IT業界で働いている人達も奴隷と言われても仕方ないのかもしれない。

　学生さんには、「確かに残業する時はありますが、普通は1時間程度の残業で退社できますよ」とかわしておいたが、最初から最後までそんなプロジェクトは滅多にない。
　学生さんにこれだけIT業界の評判が悪いと、今後、優秀な頭脳はこの業界に入って来ないかもしれない。

＃余談ですが、最近の日本に犯罪が多いのは、日本人男性の働きすぎに原因があるんじゃないかと思う。
＃つい20年前までは、こんなに残業して働いている人はそんなに多くなかったのでは？
＃親子夫婦そろって朝ご飯、夕ご飯を毎日取っている日本人の家庭って、今の日本に存在するのだろうか？
＃多分、存在しないと思う。
＃殆どの日本人の家庭は壊れていると思う。多分、普段は母子家庭になっている。最近は共働きが主流だから、たまたま一つの住居に住んでいるだけで、皆バラバラに生活していないか？
＃そんな生活は人間的（むしろ、本能として自然）なのだろうか？　子供の成長にとって悪い影響しか与えていないのではないか？

　経営者だけでなく、現場のエンジニアも今の環境を改善していくことを考えないと。

プロジェクトの危険信号は会議で分かる

　プロジェクト管理者になって、ミーティング（会議）が多くなり、また自らミーティング（会議）をコントロールする必要性が出てきたが、＠ITの記事「プロジェクトの危険信号は会議で分かる」を読んで、プロジェクトの成功率とミーティングの時間は反比例することを改めて実感した。

　僕の過去の経験からして、ミーティング（会議）が1時間を軽く越えるプロジェクトは失敗している。成功したプロジェクトは、どんなミーティングも30分以内に終わった。だから、基本的にミーティングはなくてよいか、あるいは30分以下で十分と思う。

　そもそもミーティングや会議を開く理由は何なのか？　開発者一同を集めて説明したり、利害関係者を集めて承認を得るプロセスは無駄。
　開発者には各々その時々に応じて説明すればいい。開発者はプロジェクト全体の動向を知る必要なく、課せられたタスクをスケジュール通りにこなしてくれればいいから。
　利害関係者を一同に集めたとしても、その場で生産的な結論に至ることは稀。むしろ、お互いの利害の観点から眺めた問題提起を頂くぐらいしか利点がない。それは個別にメールで尋ねれば十分。

　とはいえ、会議はやはり存在し、議事録を取る作業を初めてやったのだが、そこで大事なポイントは2つあるように思う。
　一つは、会議で決定した内容をリストアップすること。その意味は、議事録が後でメールで渡されると、その時点で議事録の内容は全関係者でコミットされたという事実に変わるから。当たり前のことだが。
　もう一つは、次回延期になった議題の納期と担当者を明示すること。これによって、次回の会議の議題が少なくとも1つ以上は決まったことになる。その担当者が納期までに解決できなければ、それなりの理由を説明せねばならなくなる。だから、担当者欄に書かれると、次回の会議では緊張感あふれる雰囲気になりやすい。
　
　とある勉強会で、更にもう一つ指摘を受けたことは、目的と達成度を書き記すこと。
　会議はどうしてもダラダラなりがちゆえ、時間と人員というリソースを結構無駄に使うときが多い。だから、当初の目的を明確にすること、そして目的がどれだけ達成されたのかという目安を書き記すと、会議の生産性が一目で分かる。
　実際にやってみたら、達成率が50%を超える項目は半分以下だった。反省(^^;)
　でも、全ての項目で達成率が100%なら、会議をやる必要はない。事前のメールで十分だから。
　故に、会議の生産性と達成率は何らかの関係があるかもしれない。

　会議とは関係ないが、今のプロジェクトでは朝礼と夕礼をやっている。朝礼でその日にやる作業をメンバーから聞き出し模造紙にリストアップして壁に張り付け、夕礼でその結果を聞くだけ。メンバー全員が起立したまま10分ほど集まるだけなのだが、これだけでプロジェクトが結構うまく回る。
　平鍋さんの朝会ガイドに似ているが、平鍋さんのやり方の方がノウハウが多いので非常に参考になる。例えば、メンバーが話しやすい雰囲気を作ることとか、話が脱線しないコツとか。
　
　この辺りのノウハウは、XPやアジャイルの方がはるかに洗練されている。チームビルディングのプロセスは、アジャイルが得意とする分野ではなかろうか？
　プロジェクト管理者の仕事は、スケジュール管理も大事だが、ミーティングのコントロールも大事であることを再確認した。

データモデルパターン

　「データモデルパターン」というHPを見つけた。
　DOAに関するパターン集。アナパタのDOA版というイメージ。

　アナパタに出てくるパーティ、責任関係、勘定パターンに似ている。
　DFD、ER図というよりはクラス図っぽく見えるけど、本当はどうなのだろうか？

在庫は商品の集合が示す状態

　「在庫」という概念がモデルに出てきたら、いつもすぐに反応してしまうのだが、今まで完全に理解していなかった。
　在庫って、結局なんだろう？

　はぶさんのBlogでは、下記のように回答されている。すごく納得。

在庫は、商品の集合が示す状態であって個々のインスタンスにはつかないです。クラス変数とインスタンス変数を混ぜて議論するから尺度が合わないと考えています。んで、ステートレスってことを主眼におけば、在庫は在庫管理係ってのを置いてそいつに「教えて」ってするのが整理しやすいアプローチだと考えます。

システム開発のボトルネックはメインフレームに有り

　システム開発のボトルネックは、メインフレーム（ホスト）の存在そのものにあるのではなかろうか？
　JavaでWebシステムを開発していると、いつもそんなことを感じてしまう。

　どこの大企業に行っても、必ず10年以上稼動し続けているメインフレームが既に存在している。メインフレームなしでは企業活動そのものが存続できないようだ。最近の流行であるそのメインフレームをオープンシステムへリプレースすることは、どこの大企業でも殆どありえないように見受けられる。
　そもそも何故メインフレームが存在するのか、本当の理由を僕は知らないが、とあるBlogでは、「企業の基幹システムは最終的に財務諸表を作るために存在する」と書かれていた。
　しかし、財務諸表や損益売上決算書などは、オープン系システムでできないのだろうか？

　普通、どこの大企業でも、メインフレームは顧客データや請求・契約などの会計に関するデータを管理している。つまり、企業にとって死活的に重要なデータは、必ずメインフレーム内で管理している。
　いくらOOAをフルに使ったWebシステムを作ったとしても、Webシステムは、集めた受注データをホストへ送り、入出荷や請求のデータをホストからもらうだけ。業務的には、入り口のシステムに過ぎない。
　Webシステムがダウンするのは当然困るが、企業活動そのものが止まってしまうわけではない。

　僕がメインフレームを毛嫌いする理由は、OO技術者にとって、メインフレームがブラックボックスだから。メインフレームでデータをどのように加工し出力しているのか、全く意味不明だから。

　更に、ホストとのやり取りのために、無駄なインターフェイスが必要になる。
　例えば、受注データをリアルタイムにホストへ送信したり、月次請求や四半期決算のデータをホストから特定の日に受信する処理がある。
　仕組みとしては、ホストはバイト長データしか扱えないため、バッチプログラムがバイト長データを変換してRDBのワークテーブルに一旦保管し、Javaが扱うテーブルへ移し変える。そのプログラムは、典型的なCのプログラムで、オブジェクト指向以前の古い設計に基づく。しかもテストしにくい。

　オブジェクト指向をフルに使った設計やオープンソースのフレームワークを適用したオープン系システムを開発しようとしても、結局、メインフレームとの整合性を取るためのシステムテストがボトルネックになる。
　何しろ、受け入れテストに必要なシナリオやテストデータを洗い出し、実際の業務をシミュレーションするために、1週間とか1ヶ月も時間を費やす。オープン系システム内部で閉じたシステムなら、システムテストは楽なのに、ホストと連携するテストを行うために、無駄なコストがかかる。

　「メインフレームはオープンシステムに取って代われる」という記事を随分昔から見てきたけれど、未だに実現されているとは思えない。それらの記事は、単なるデマだったのだろうか？

【参考記事】「5年後，メインフレームはなくなる」　日経コンピュータ2003年3月24日号

　IT業界に入って、結局いつもぶち当たる壁は、ORマッピングとメインフレーム。
　それらを再考し直すと、結局、メインフレーム・RDB・オブジェクト指向プログラムの3つはどれも思想的に全く異なるシステムであって、それらのインターフェイスを合わせる為に、ORマッピングやバッチプログラムという無駄な中間レイヤーが必要になる。
　企業システムとは、結局、これら３つの相容れない混合システムであるべきものなのか？
　多分そうでないはず、と思うし、皆そう感じているのではなかろうか？

　メインフレームが今もなお存在する理由は、IBM・NEC・富士通・日立等のような大手ベンダーが過去あるいは今までメインフレームを製造し続けてきたからだろう。
　メインフレームというハードを中心にしたビジネスが長らく続き、そのビジネススタイルからなかなか脱皮できない所に原因がある気がする。

ソフトウェアテスト293の鉄則

　テスト仕様書やテスト計画を作るために「ソフトウェアテスト293の鉄則」の本を読み始めているが、理解しきれない部分と、なるほどと思う部分がある。

　今、最も関心があるのは下記の項目。ちょっと書いてみる。

第11章 テスト戦略の立案
鉄則278 テスト計画は戦略，段取り，成果物の三位一体と心得よ

戦略
どの範囲をテストするのか？　どこを重点的にテストするのか？　どのテスト技法を用いるのか？

段取り
戦略を実現するためにどのようにリソースを適用するのか？　誰がいつてすとするのか？

成果物
どんなドキュメントを残すのか？　どのようにバグを管理するのか？

　単体テストやシステム内の結合テストの仕様書や計画を考えるのは簡単。というか、それはプロジェクト管理者がやるべき事柄。
　むしろ、納品したモジュールが本番システムや他のサブシステムと連携して動くか、という受入テストやシステムテストについて、テストスケジュールやテスト仕様書をまとめるのが大変だ。
　その時に上記の本が役立つのでは、と思っている。

　オブジェクト倶楽部MLのスレッドでも、上記の本が絶賛されている。
　また感想をまとめよう。

大いなる力には、大いなる責任が伴う

　プロジェクト管理者にいざなると、割り込みの仕事に忙殺されて、モチベーションが落ちてしまう時がある。
　そんな時に、自分の使命（？）を思い出させて、奮い立つ言葉を見つけた。　

　「大いなる力には、大いなる責任が伴う」

　スパイダーマンが亡き叔父さんから言われた言葉。
　カッコイイ。。(^^)
　確かスパイダーマン１で、スパイダーマンとなった主人公の乱暴な振る舞いに見かねて忠告した場面だったように思う。
　
　プロジェクト管理者になると偉くなった気がするが、実際はそんなことはない。自分がプログラミングすれば早いのに、メンバーにお願いしてプログラミングしてもらっている。理由は、リーダーがプログラミングに携わるとチームが回らなくなるから。
　過去のプロジェクトを思い出しても、リーダー自らが実装していたプロジェクトは殆ど破綻していた経験がある。

　自分ならメンバーの2倍以上のタスクはこなせる自信はあるが、それを内に秘めて、チームの人数分の責任を感じて、チームを回している。
　その責任の重さに疲れる時があるけれど、その言葉を肝に銘じていると自分がスパイダーマンになったような気がして、何故かやる気が出てくる。

　しかし、自分も単純だよなあ(m_m)

モデルの所有者は誰か？

　IT21の会オープンカンファランス2005で児玉公信さんの講演を聞いて、1年間モデリングし続けた概念が全て一つに揃ったような気がした。
　最も印象に残った言葉は「モデルとは、ある人から見たある状況における明示的な解釈である」ということ。
　つまり、モデルを書くには、人が必要。人はモデルの所有者に相当する。
　そして、状況とは、モデルの文脈を指す。

　クラス図でモデルを書く時、とある勉強会でモデルの所有者が誰なのか、という議論がよく出る。つまり、このモデルはどの人が眺めて、どんな文脈でモデル化したものなのか？という質問がよく出た。
　「UMLモデリングの本質: 」には、「モデルの所有者はモデルの中に登場しない」という一文がある。当たり前なのだが、クラス図を書いていくと、文脈を忘れて、たくさんのアクタが登場して混乱してしまう時がある。

　下記のクラス図の所有者は誰だろうか？

契約モデル

　児玉さんが講演で説明していたが、売り手と買い手のロールが登場しているから、所有者は売り手でも買い手でもない。所有者は仲介業者になる。
　売り手や買い手が所有者の場合、上記のクラス図から所有者が消えて、何かしらの制約が追加されるだろう。

　他の例として、「本質」の後半の章に「航空チケット予約システム」のクラス図がある。そのクラス図の所有者は、売り手、例えば、旅行代理店になる。

　モデルの所有者が重要なのは、要求から要件を定義し、概念モデルまで落とす作業で意識する必要があるから。
　シナリオを書いている時、普通はユーザの視点からシナリオを書く。例えば、アクタごとのシナリオのように。
　しかし、ビジネスモデリングであるからには、ユーザのアクティビティを追跡してどのサービスから課金するか、を探す。その時に、モデルの所有者がビジネスを提供する人へ変わる。
　そのことを意識する必要がある。

【参考文献】
UMLモデリングの本質: 　児玉公信著

テスト・ビルドプロセスの重要性

　最近のシステム開発の傾向を眺めると、テストやビルドプロセスを重視しているのが分かる。

　ウォーターフォールモデルでは設計や実装を重視するが、アジャイルやMSの開発フレームワークはテストやビルドを重視している。
　そのような傾向が生じた理由は、開発のボトルネックが、コンピュータ・リソースではなく、いかに変化に対応できる環境を作るか、へ移ってきたからだろう。
　そうなると、作ったシステムの正当性を保障するテストプロセスや、作ったシステムを安定稼動させるビルドプロセスがおのずから重要になってくる。いくら設計や実装をしても、早く実際に動かしてみなければ無意味になる状況が多くなってきたのだろう。

　更に理由の一つとして、テスト・ビルドの技術が面白く、実装と同じレベルのプロセスに組み込めるから、開発者でもテスト・ビルドプロセスに関心を持つ方向へ誘導できるのではないか？
　開発者の視点から眺めると、最近のテストプロセスやビルドプロセスは技術的に面白い。
　テスト駆動の技術としては、モックオブジェクト、プロキシ、リフレクション等の高等技術がふんだんに使われている。
　ビルドプロセスなら、AntやMavenなどがあげられるだろう。特にMavenは、プロジェクトが一つのコンポーネントに対応している特徴があるが、それはオブジェクト指向の再利用性の話につながる。
　
　Mavenの根底にある思想は、プロジェクト管理につながるように感じる。
　Mavenについては、もう少し調査してみたいと思う。

MSはCMMに取り組む必要なし

　とある勉強会MLで「ソフトウエア企業の競争戦略」の話が出た折、著者クスマノ氏が「M$はビジネス上CMMに取り組む必要はない」という指摘を昨年の講演で話したらしい。
　うーむ、すごすぎ(^^)

　どんな文脈でそんな話があったのか知らないが、インパクトがある。
　僕の少ない経験では、日本のソフト会社でCMMに取り組んでいるとしたら、それは製造業のISO等の品質管理のソフトウェア版に相当する。その作業はドキュメントが非常に多すぎて、普通の業務にも支障が出るぐらいなのに、やらざるを得ない。
　CMMでレベル5を取ったからと言って、それでビジネスの利益に結びつくのか、と言われると、心もとない所は確かにある。

　CMMのようなプロセスはウォーターフォール型開発に近い。しかし、今のソフト開発の流れは、繰り返し型開発プロセスが主流。
　重要な点は、ウォーターフォール型開発では、設計や実装を重視してテストを軽視するが、繰り返し型開発プロセスでは、ビルドやテストの方を重視していることだと考える。

　「ソフトウエア企業の競争戦略」感想文が載っているここのBlogでは、下記の問いが投げられている。

「Windows開発プロジェクトチームのうち、最も強い「権力」を持っていた
のはどれか?

　　1.プログラマ
　　2.テスタ
　　3.ビルダ
」

　僕は「テスタ」だと思っていたが、実は「ビルダ」だった。
　ビルドって、1日の最後に夜間バッチで働いてくれるぐらいしか思いつかないし、ビルド担当者は新人SEが任せられる時が多いけれど、実は一番重要なんだよね。

　最近、「構成管理」という言葉が流行しているけれど、その概念は「ビルド」プロセスに密接に絡んでいる。
　なのに、構成管理の概念はCMMなどのプロセス管理の本でよく出るのに、ビルドプロセスとの関連を説明している本は少ないらしい。

　日本人は品質管理にうるさい面はある。その特徴が製造業では有利に働くが、IT産業では実は優位性がそれほどないのだろう。少なくとも、日本のどのソフト会社よりもM$の方がITビジネスで成功しているし。
　ソフトウェア開発のプロセスはもっと研究する余地があるように思う。

継承→Aspect→DI へプログラミング言語は進化している

　オブジェクト倶楽部の定期MLで、「オブジェクト指向の再定義」と題して平鍋さんが連載記事を書かれているが、すごく面白い！
　記事の中で印象に残った言葉は、下記の二つの文章。

「EoT(Ease of Testing、テスト容易性)の高い設計が、よいオブジェクト指向設計である」
「EoC(Ease of Changing、変更容易性)の高い設計が、よいオブジェクト指向設計である」

　オブジェクト指向言語のあらゆる機能は「テスト容易性」を実現するためにある、と言い切っている。実際、下記のことが思いつく。

１．MockObjectを作るには、無名クラスで実現するために継承を用いる。
２．インターフェイス優先は、テストしやすくさせるため。
３．パッケージ循環依存性を排除するのは、テストしやすくするため。
４．オブジェクトの責務割り当ては、テストしやすいモジュール分割をするため。

　更に、「再利用性」よりも「変更容易性」の方がオブジェクト指向設計で重要だと主張している。最近のアジャイル開発の流行を見ると、そのことを強く感じる。プログラムの変更リスクが低い方がはるかに変化に強い。
　一昔前はコンピュータやネットワークのリソースが高価だったため、変化への対応能力はあまり重要視されていなかった。でも今は違う。変化に強くないと、プログラムの品質そのものも低下するから。

　変更容易性を実現する技術が、継承や委譲だったり、最近ならAspectやDIだったりする。それらの技術を比較してみると、「継承→Aspect→DI」の方向へプログラミング言語が進化しているのが分かる。

A．継承・・・実装時に既に依存関係がある。最も強固な依存関係ゆえ、できるだけ避けるべき。
B．委譲・・・OOでは継承よりも良いと言われるが、無駄な空メソッドが増える。
C．Aspect・・・コンパイル時に依存関係ができる。プログラム同士の依存関係はないが、バイナリ同士には依存関係がある。
D．DI・・・・ランタイム時に依存関係ができる。プログラム同士にもバイナリ同士にも依存関係はない。

　ランタイム時に依存関係ができるということは、パソコンの組み立てと同じく、プログラムを部品と見なすことができることを意味する。インターフェイスさえ合致していれば、いくらでも部品を組み合わせることができる。
　とはいえ、プログラムではインターフェイスを合わせることに四苦八苦することが多いが。。。

　平鍋さんの記事を読むと、プログラミング言語の将来像について深く考えさせられる。

再帰SQL

　Javaやモデリングを検索すると、2chのスレッドにたどり着いてしまうのだが、面白い記事を見つけた。
　「部品表から、未来のある時点での在庫の推移・過不足を見たいが、どのようなデータモデリングとSQLを使えばよいのか？」という質問に対し、「再帰SQLを使うしかないだろう」という答えがあり、下記のリンクが張られていた。

　オブジェクト指向、Javaを取り入れた新しい業界標準「SQL99」詳細解説 (共通表式 WITH句/再帰SQL)

　共通表式は、外部結合等でFROM句にあるサブクエリを何度も使わざるを得ない時に使った経験があるので知っていたが、再帰SQLについては知らなかった。
　上記HPの例題を読むと、「部品構成表から、自転車を構成する全部品と各部品の所要数の一覧を作る」時のSQLが再帰SQLとして書かれている。
　更に、「パリからサンフランシスコまでの乗り継ぎのある経路のうち、最少費用の経路を探す」ためにも再帰SQLを使っている。
　こんな問題の解決に再帰SQLを使うんだなーと感心した。（感心してはいけないが）

　この方法は、MSProjectで作ったスケジュール表のリソース平準化のアルゴリズムにも使われているのだろうか？
　クリティカルパスの検索や工数最適化にもこのアルゴリズムは使えるのではないか？
　再帰SQLを使えば、最短経路検索の問題が全て解けてしまうのでは？と思ってしまうが、無限ループの問題とかあるみたい。

　上記の記事には、再帰SQLの他に、渡辺さんの本「生産管理・原価管理システムのためのデータモデリング」に載っている「LLCを使ってシングルレベル展開して最後の階層まで集計する」アルゴリズムが回答されていた。
　LLC(ローレベルコード)の意味は、「ある部品が部品構成表でどれくらい最下位にあるかを示す位置」なのだが、恥ずかしながら僕もLLCの使い道がよく分かっていなかった。

　渡辺さんの本にある「MRPの所要量計算アルゴリズム」は理解し切れていないけれど、再帰SQLのアルゴリズムと似ている感じがするのだが、正しいだろうか？　もう少し考えよう。

Javaを突き詰めるとEJBの壁にぶち当たる

　JavaでWebシステムを開発していくと、必ずEJBという大きな壁にぶち当たる。
　EJBを使えば確かにプログラミングは楽になるが、その技術を使いこなすには手間がかかる上に、APサーバーに更にEJBサーバーまで動かしてリソースを派手に浪費するから、使い勝手はイマイチ。
　
　EJBの弱点を更にもう一つ見つけた。
　EJBはAPサーバーに依存しているから、他のAPサーバーに使えない。少なくとも、JBossとWASでは、Deploymentの記述が全く違うから、動くわけがない。Javaのメリットが全く生きていない。そもそもAPサーバーに依存しているようでは話にならない。

　IT業界に入ってJavaだけで開発してきたが、いつも最終的に、EJBとO-Rマッピングの技術にぶつかる。
　僕の少ない開発経験を振り返ると、EJBはO-Rマッピングの最適解ではない。その思いは僕だけでないのだろうと思う。何故なら、Hibernate等のO-Rマッピング・フレームワークや、SpringとかSeasarのようなDIコンテナが雨後の竹の子のように流行しているから。
　最近、O-Rマッピングの最適解はHibernateよりもS2Daoではないか、と思っているけれど、本当の所はどうなのだろうか？

「ソフトウェア企業の競争戦略」

　「「ソフトウエア企業の競争戦略」」の本が、ここやあそこに紹介されていた。
　内容は、ソフトウェア・ビジネスとして成立させるために必要なことは「製品とサービスのハイブリット形態」である、ということで興味津々。しかし、立ち読みしてみたが、いまいちピンと来なかった。

　ソフトウェア・ビジネスは製造業や小売業などのサービス業と異なるのではないか、と漠然としたイメージは常々持っていたが、本質はまだ分からない。
　僕の少ない現場経験を整理すると、システム開発は普通の製品開発と異なるプロセスなのに、現場の環境が古いため、ちぐはぐな印象をずっと持ち続けている。
　例えば、いくらJavaでWebシステムを作ったところで、請求処理など一番大事な基幹システムはメインフレームで動かしているため、データ転送で無駄なインターフェイスを作ったり、オブジェクト指向技術が徹底できなかったりする。
　更に、Webチームとメインフレームチームに分かれているため、Webチームがいくらオブジェクト指向に則った開発プロセスを応用しても、旧式プロセスでやっているメインフレームチームと共同作業せざるを得ない。
　又、日本のITビジネスは土建業界のような下請構造で成立しているため、いくらアジャイル開発をやろうとしても、ウォータフォール型プロセスから脱却できない。
　この辺りの矛盾をきちんと説明しているのか、と思ったがよく分からなかった。どこかにいい本はないのだろうか？

機能スコープと設計スコープ

　あるビジネスのシナリオを書く時、スコープを意識するのが重要なのだが、機能スコープと設計スコープを意識して使い分けるのが重要と改めて認識した。

　「ユースケース実践ガイド―効果的なユースケースの書き方」で、機能スコープと設計スコープの話が出てくる。
　機能スコープは、システムが提供するサービスを意味する。成果物は、アクタ・目的リストとユースケース概要の2つ。これらは、ペルソナ・シナリオ法を使えば、アクタごとのシナリオとして洗い出すことができる。
　これらのユースケースは、受け入れテストで使える。

　設計スコープは、ハードやソフトもこめて設計するシステムの集合を意味する。このイメージがなかなか湧かなかった。本の例を見ていると、イメージとしてはDFDやER図に似ていないか？
　つまり、システムとして設計すべき機能なのか、設計外の機能なのか、を把握するには、企業・システム・サブシステムの視点からデータの受け渡しをイメージしないと書けない気がする。

　とある勉強会でシナリオを書くタスクを背負ったが、メンバーのシナリオに対するイメージがバラバラで、どんなシナリオを書けば概念モデルや詳細モデルが書けるのか、プロセスすら分からなかった。
　今になってようやく、下記の成果物は必須だと分かった。

１．各シナリオ・機能がスコープ内にあるかチェックするためのIn/Outリスト
　→議論が発散しそうになったら、どんな要求がシステムに必要なのか、原点に立ち戻る時に使う。

２．アクタ別のシナリオを書いたユースケース概要
　→ペルソナ・シナリオ法はオブジェクト図の位置づけに相当する。アクタ・目的リストはクラス図の位置づけに相当する。受け入れテストで使える。

３．色んな視点からシステムを眺めた時の設計スコープの図
　→モデリングを行う時、どのシステムに着目して詳細化していくのか、を確認するのに使う。

　ユースケースなんてモデリングで意味があるのか、と常々思っていたのだが、モデリングを行う前の仕込み段階であるシナリオを書きまくっていくうちに、ユースケースの威力が分かってきた。
　モデリングへ辿りつくには、シナリオを具体化したユースケースが必要。そのシナリオはスコープに大きく依存している。

　シナリオやユースケースを書いていると気づいたのは、IF文を極力排除していること。IF文を使う箇所はアクタ別のシナリオに分けられる時が多い。

　ユースケースは奥が深い！

プロジェクトマネージャ＝ディレクター＋プロデューサー

　はぶさんの本「幸せなＩＴパーソンになるためのいきいきする仕事とやる気のつくり方」に、「プロジェクトマネージャの職務をディレクターの役割とプロデューサーの役割へ意識して使い分けるとうまくいく」という一節があって、何故プロジェクトマネージャは普通の管理職の仕事と違うのか、という疑問に答えられそうな気がした。

　本では、2つの役割を下記のように説明している。

【ディレクターの役割】
→成果物を作成するプロセスを管理する。
　課題達成重視。
例：計画策定・遂行、進捗管理

【プロデューサーの役割】
→全ての成果物に責任を持つ。
　問題解決型。
例：
プロジェクトの目的と成果物の明確化
プロジェクトの運営体制の構築
リスク管理
利害関係の調整

　丁度、演劇や映画の「監督」「演出家」に相当するのではなかろうか？
　Wikipediaでは、「監督」「演出家」を下記のように説明している。

演出家の職務は、劇を作品的成功に導いていくことである。そのために俳優の演技や、舞台に必要な様々な要素をコーディネートし、演出していく。演劇は複数の人間・芸術分野のコラボレーションから成り立つ芸術だが、一つの劇をつくる際に必要な様々な部門の中でも、演出家は戯曲の解釈、コンセプトや作品の芸術的方向性、表現手法などについて具体的なヴィジョンを持ち、なおかつ最終的な決定権を握っている。（中略）
演出家の仕事は通常、本番開始後には舞台監督に引き継がれる。その場合、舞台監督は演出家の定めたコンセプトや劇の進行を、公演期間中維持する責任を持つ。

　つまり、演出家は成果物に最終責任を持つから、成果物をより良い物にするためのあらゆる問題を技術面、政治面から解決する。監督は、そのプロセスを管理する。
　「はぶさんの本」に書かれている通り、監督の役割に固執すると、問題解決の糸口が見つからない。むしろ演出家の役割から、困難な状況を変えてくれそうな本質的問題を発見して、解決することで、現実を変えることができる。

　僕の少ない経験では、プロジェクト管理者はどうしてもスケジュール管理ばかり追われて、スケジュールが遅延する真の問題を考えることまで頭が回らない。つまり、現状を維持するプロセスにしか能力を使っていないわけだ。
　会社の中間管理職は、普通はプロセス管理しかやらないから、監督の役割だけで演出家の役割を担っていない場合が多いのではなかろうか？
　プロジェクトマネージャの仕事は奥が深い。

　「はぶさんの本」はいい本です。是非ご賞味あれ(^^)

口酸っぱく言われていること--スコープ管理とマイルストーン設定--

　仕事でプロジェクト管理していても、勉強会の発表資料作りでも、同僚から指摘されていることは、「スコープ管理」と「マイルストーン設定」の二つ。

　スコープ管理は、プロジェクトを成功づけるだけの成果物とその仕様範囲、成果物のレベルに密接に絡んでいる。どうしてもより良い成果物を作ろうとして、スコープがどんどん広がってしまう時に指摘を受ける(m_m)
　マイルストーン設定は、成果物を披露する期限を公開することでプロジェクトをコントロールする所に意義がある。一度マイルストーンを守れなくなると、どんどん遅れてしまい、プロジェクトだけでなく自分自身の作業目標すら制御できなくなる。マイルストーンを無視したより良い成果物を作ろうとした時に指摘を受ける(m_m)

　スコープ管理もマイルストーン設定も、プロジェクトの範囲と期限に連動する。この二つがいつも念頭にないと、プロジェクトは予想しない方向へ走ってしまい、制御できなくなる。
　二つとも当たり前だけれど、もっと良い成果物を作ろうと作業に没頭してしまうと忘れやすい。気をつけよう。

プログラミングの基本はIF文を極力排除する

　「IF文を極力減らすと見晴らしのいいプログラムになる」を読んで、プログラミングの基本を改めて痛感した。

　新人のプログラムをレビューすると、メソッドが長すぎたり、IF文が入れ子構造になっていたりして、後で保守しにくい。
　オブジェクト指向の強みは、ポリモルフィズムを使えば、IF文を排除できる所にある。ループ処理もIteratorやJDK1.5の新しいAPIを使えば、for文を排除できる。
　Seasarのように、Dependency Injectionを使えば、IF文で呼び出されるロジックの依存関係をdiconファイルに書くことで、より綺麗なプログラム構造になる。

　そんなことを考えると、プログラミング言語は条件分岐やループ処理がない逐次実行形式で書けるように進化してきたように思える。

要件定義はスコープ管理から始まる

　仕様のすり合わせプロセスは、まず仕様のスコープを決めることから始まる、という当たり前だが最も忘れやすいことを再認識した。

　仕事でも勉強会でも、あるビジネスのイメージからビジネスルールを一つずつ確定していき、最終的に設計書という成果物を作っているのだが、各設計者のイメージが異なると、いくら議論しても仕様が確定しない。
　「ユースケース実践ガイド―効果的なユースケースの書き方」には、議論のスコープを追跡するために「In/Outリスト」を提唱している。In/Outリストは、各トピックが作業スコープ内にあるのかスコープ外にあるのか、を示すテーブルに過ぎないのだが、実際、議論はよく食い違う。

　作業スコープが定まったら、更に「アクター・目的リスト」を作成することを提唱している。アクター・目的リストは、システムが要求するユーザ目的のリストに過ぎないが、各トピックの整合性を考えると、不一致が生じたり、トピック漏れが起きたりすることが実際多い。

　最近はプログラミングよりも、ユースケースの妥当性を確認するテクニックをひたすら追いかけている気がする。
　管理職や経営者のような部下をマネジメントする立場にある人は、まずスコープを意識してコントロールするというテクニックが最も基本的なスキルとして要求されているのかもしれない。

GanttProjectは使える？

　進捗管理のために、MSProjectよりも線表を簡単に使えそうなツールを探してみたら、GanttProjectが見つかった。

　下記の特徴あり。

・ガントチャートを作成編集できるJavaアプリ
・PDF、HTML、CSV出力可能
・WebDAVを利用して情報を共有できる
・mm2ganスクリプトを使うと、FreeMindと連携できる

　プロジェクト管理者にとって、線表作成は作業の一番のネックであると思う。
　まず、線表作成は工数が結構かかる。Excelで作った場合、タスクの日付をずらすと全てのタスクの日付を修正しなくてはならない。しかも、作成中はPGは作業できないから、何とかお手軽に早く作りたい。
　更に、線表は頻繁に更新されるので、開発者に更新版を早く見て欲しい。そのために公開できる環境が必要なのだが、そこまで手が回らない。

　GanttProjectなら、手軽に作れそうだし、PDF出力すれば綺麗に印刷できそう。
　WebDAVを設定すれば、Wikiのように開発者がいつでも最新の線表を閲覧可能になりそう。

　今度試してみよう。

パンダは可愛い

　昨夜遅くに、NHK裏番組でパンダのルポを見た。
　母パンダが生後4ヶ月の子パンダを抱えている仕草が可愛いー。
　パンダは生後半年は眼も見えず、まともに歩けないので、母親の母乳だけで生きているらしい。
　しかし、母パンダが子供を放置して、半日も竹の笹を食べている行動は解せない。子供を抱きながら食べればいいだろ！と怒ってみたりする。

　しばらくして「地球大進化--全球凍結」も見た。
　マイナス50度の超氷河期が1000万年以上続いたという仮説は恐ろしすぎ。
　そんな地球で生命は絶滅しなかったのか？
　下記のように、はぶさんも感動して観ていたと、Blogで読んで、何故か安心。

昨日の灼熱世界、全海洋蒸発から一転して全球凍結のお話です。火山が出す二酸化炭素での温室効果によって、全球凍結が終わったのだそうで。ここからハイパーハリケーンを経て微生物が大型化していくくだりはかなり燃えます。正に因果という感じです。

　「因果」からSystem Thinkingの因果ループ図を連想する僕は異常だろうか？　おそらく、因果ループ図とすれば、「成功には成功を」パターンに相当するのか、と考える僕は変だろうか？

　最近、恐竜のニュースを何故かチェックしまくり。
　お金やビジネスの話よりもサイエンスの話の方が、何故か心が和らぐ気がする。

日本のIT産業は国際競争力がない

　「日本のソフトウェア産業は競争力がない」という記事を読んで、自分がいる日本のIT業界の現実を改めて思い知らされた。

　貿易収支をみれば一目瞭然なのだが、「2000年のソフトウェアに関する日本の輸出額はわずかに90億円であり、9189億円もある輸入額の１％弱しかない」。2004年でもそう変わらないだろう。　
　この事実は、日本のIT産業は海外勢と競争できるだけの財力も体力も知力も欠けていることを示している。

　中国やインドから発注されたシステムを日本で開発しているのか？
　日本で作ったソフトウェアをアメリカへ輸出しているのか？

　いずれも答えはNoで、現状は正反対。
　日本から発注されたシステムを主に中国で開発しているのが普通。
　アメリカで作られたハードとソフトを日本が輸入しまくっているのが普通。

　冷静に考えると、日本のIT業界の将来はやばそう。
　青色ダイオード発明者の中村修二さんは「今後の日本が生き残る道は、アメリカのような独創性ではなく、中国やインドのようなコストの安い製造体制でもなく、短期間に試作品を作り上げる所にある」とどこかの本で主張していたが、日本のIT業界にそのような道はまだ残されているのだろうか？

ウォーターフォール型開発は日本の業界構造と表裏一体

　「ソフトウェア開発におけるパラダイムシフト」の記事を読んで、日本でウォーターフォール型開発プロセスが幅を利かせているのは、大手SIerにとって土建業界のように階層化された業界構造が好都合な開発モデルだから、という一節にすごく納得した。

　元請から下請まで5層もの階層構造にするから、元請は上流工程と称して、要件定義しかやらない。しかし、詳細設計で初めて、仕様漏れが見つかるのが普通。結局、仕様漏れが積み重なってデスマーチ・プロジェクトに陥るのではなかろうか？
　最近は、最下層の下請は中国へ流す。だから、言語のコミュニケーションギャップも加わり、より問題が複雑になっているように思う。
　
　「アジャイル開発は元々日本的なものだ」という上記記事の主張は、なるほどと思わせる。完璧な計画を作って進めるスタイルは、どう見ても西洋式。トップダウンで物事を進めるよりも、ボトムアップのプロセスの方がはるかに日本的。
　そうならない理由は、結局、ウォーターフォール型開発プロセスが大手SIerのビジネス構造に組み込まれているからだろう。

　アジャイル開発の方が利益に直結するように、自分たちのビジネス構造を変えていかなくては。

失敗はプロジェクトマネージャーにとって経験にならない

　「プロジェクトマネージャー養成塾」のメルマガで、

「IBMでは、一度、失敗したプロジェクトマネージャーは失敗を繰り返す傾向がある」
「失敗はプロジェクトマネージャーにとって経験にならない」

というショッキングな意見が述べられている。

　理由は、プロジェクトには不確実性があり、マニュアル通りに解決できるものではなく、プロジェクト遂行中の様々な局面の判断が重要であるから、と。
　だから、失敗したプロジェクトマネージャーは、どのような判断ややり方がまずかったのかではなく、判断や行動のベースになっているその人の「プロジェクト観」を是正する必要がある、と結論付けている。

　上記の意見はショッキングだけれど、経験上納得せざるを得ないように思う。
　現場で、プロジェクトを火だるまにさせてしまうPMはいつも同じ。例えば、いつも会議を長引かせてしまうPMは、いつになっても会議をコントロールできないように思う。（対人交渉術はそう簡単に身に付かない）
　現場で、何度も失敗するPMは、どのプロジェクトに行っても失敗する。例えば、今まで国内で開発していたプロジェクトを中国へ持って行ったが、同じように失敗。（当たり前か(^^)）

　プロジェクトの失敗経験が役立たないのは、同じプロジェクトはそもそも存在しないため、失敗に対する対策が次のプロジェクトに生かされないからだろう。
　その意味では、製造業の品質管理とは違うマネジメント能力が問われているのだろう。
　僕の勝手な思いとしては、スコープ管理がプロジェクト成功の鍵を握る気がする。
　スコープマネジメントを軸にして、リソース管理やスケジュール管理、ステークホルダーの利害調整を行うのが、プロジェクトマネジメントの王道ではなかろうか？
　スコープマネジメントには、プロジェクトの現状を客観的に把握する能力と、プロジェクトの現状を打破するだけの政治能力が必要なため、意識を高く持たないと、スキルを身に付けにくいのではなかろうか？

ユースケース図でスコープを可視化する

　「スコープを可視化する」記事で、ユースケース図はPMにとって強力なツールだと書かれている。
　以前、開発している時、ユースケース図なんて何の存在意義があるのか？と疑問を持っていたが、実際、自分がプロジェクト管理者の立場になって、初めてユースケース図の重要性を認識した。
　ユースケース図は、システムの仕様のスコープを整理するために使える。かなり有効に使えそうな予感がする。

　自分がプロジェクト管理者になって、設計者に内部仕様書を書かせているが、曖昧な要件定義から作らせているので、ユーザに外部仕様を確認して調整する場合が必ずある。
　その時、設計者に下記のように質問している自分に自然に気付いた。

未確定な仕様は、何が分かれば確定するのか？
未確定な仕様以外の部分は正しいか？
未確定な仕様の影響範囲はどれくらいか？
未確定な仕様をブラックボックスにして、作業を続けられるのか？
未確定な仕様が決まったら、工数はどれだけかかるか？

　上記の質問をしている理由は、未確定な仕様を仕様書から切り離して、設計者の作業を続行させ、その間に未確定な仕様をユーザと調整したいからだ。
　自分としては、仕様を機能単位に分割し、未確定仕様のスコープをできるだけ小さくしたい、という動機がある。
　すなわち、ユースケースを洗い出し、ユースケース図の外枠を狭めているのと同じ。

　ユースケース図の外枠がスコープに相当する。枠内には、システムで実現する機能(ユースケース)がある。だから、このユースケースはシステム内部でやるのか、あるいは、システムの外部でやるのかがハッキリする。
　上記記事でも書いてあるが、スコープを意識する時、ユースケースの詳細度はあまり関係ない。
　理由は、プロジェクトスコープはWBSのおかげではっきりしているので、ユースケースが大きすぎて工数が大きくなる場合は、スコープを基準にしてユースケースを分割できないか考えるようにしているから。

　ユースケースとスコープを意識し始めて、幾つか気になることはある。
　ユースケースの詳細度は、プロジェクト管理者と設計者で異なるように感じる。当然、設計者の方が細かい。プロジェクト管理者にとって、ユースケースとWBSはNearlyEqual。
　又、アクターが単なるユーザだけではなく、外部システム(うちならHost)が自然に出てくる。システムを実現するために、データの主体を実行者にしてしまうことがよくある。

　残りの問題は、ユースケースの種類とWBSに関係はあるか？とか、ユースケース図とスコープの関連をもっと研究してみる、とか。
　「ユースケース実践ガイド―効果的なユースケースの書き方」を最近になって、もう一度読み始めている。
　以前はさっぱり理解できなかったけれど、本の中にも「スコープ」のことが書かれている！
　後でまとめよう。

スコープを公開する重要性

　プロジェクトはスコープを管理しているだけでうまくいくのではないか？
　そのためにも、プロジェクトスコープを可視化して、チームメンバーに常時公開することが重要ではなかろうか？

　普通、プロジェクトスコープはWBSのおかげで案外はっきりしている。
　しかし、だからといって、プロジェクトがスムーズに進むとは限らない。メンバーがスコープを意識して、進捗を滞りなくこなすことへつなげなくてはならない。

　プロジェクトマネージャーは自らWBSを作るので、プロジェクトスコープの詳細まで知り尽くしているが、メンバーは線表から自分のタスクしか見ないから、自分のタスクがプロジェクト全体でどれだけのウェートを占めているのか、分かっていない場合が多い。
　だから、スコープをメンバーに公開して、メンバーが自身の現状をいつも把握できるようするのは大事。

　最近平鍋さんが「進捗管理でバーンダウンチャートが有効」と言っている。「バーンダウンチャート」とは、縦軸が完成させるべきソフトウェアの要求、横軸が時間のチャートのこと。予定と実績を書き込めば、どれだけ進捗が遅れているか一目で分かってしまう。つまり、進捗をビジュアルにマネジメントするツールのことだ。
　バーンダウンチャートを公開すれば、メンバーが自身の現状をいつも把握できる。
　でも個人的な経験では、バーンダウンチャートは嫌い。予定から実績が遅れてしまうと、マネージャーから、「いつまでに取り戻せますか？」という質問が来て、「月曜までに徹夜で仕上げます」と返事せざるを得なくなった時があった。メンバーには諸刃の剣なのかもしれない。

　スコープや進捗を公開するためのツールはあるだろうか？
　以前、XPlannerを使ったことがあったが、機能不足でイマイチだった。でも、最新版ではかなり使いやすくなっているらしい。
　他のオープンソースのツールも今度探してみよう。

ステークホルダー同士のスコープのずれ

　スコープ管理が難しい理由は、ステークホルダー同士の頭にあるスコープが大きくずれているからではないか。

　PMBOKを解説しているHPを見たら、スコープには、「成果物スコープ」と「プロジェクトスコープ」の２つがあるらしい。
　成果物スコープとは、プロジェクトの成果物を定義するもの。例えば、納品のためのプログラムや仕様書。
　プロジェクトスコープとは、成果物を作り出すために行う作業の分担を表すもの。例えば、要件定義、設計、テスト、データ移行、ユーザー教育など。

　普通は、成果物スコープからプロジェクトスコープを作っていく。つまり、WBSを作るのと同じ。
　だから、WBSがしっかりしていれば、プロジェクトスコープが曖昧になることはないはず。

　しかし、WBSが曖昧な場合もある。初めてのユーザ、初めての技術を使ってプロジェクトを始める場合、成果物に対するステークホルダーの認識が一致していても、成果物を作り出す作業が見えないため、WBSに漏れ抜けが発生することが多い気がする。すると、ユーザは、たったこれだけの成果物を作り出すのに、何故こんなに工数がかかるのか、とSIerに問い詰める事態になったりする。
　だから、ステークホルダー同士のスコープに対する思惑は、WBSがしっかりと固まるまで違いが顕在化しないと思う。

　更に、ステークホルダーが多ければ多いほど、スコープのずれが大きくなる可能性がある。そして、全てのステークホルダーが認識するスコープをすり合わせる手間もかかる。
　プロジェクトが発足した後で、ステークホルダーは増えることはあっても減ることは、現実では殆どありえないのではないか？

　XPなら、WBSを作る作業は計画ゲームに相当する。しかも、1人日で収まるタスクまで詳細化するし、チームへ顧客を巻き込んでいるから、ステークホルダーの認識のずれは小さいと言える。
　
　何故、プロジェクトでスコープ管理が大事なのか？
　理由は、スコープがステークホルダー同士の利害関係に直接依存しているからだろう。
　プロジェクトマネージャーがスコープ管理をするということは、ステークホルダー同士の利害関係を解きほぐすだけの政治能力があるという意味も含まれていると思う。
　プロジェクトマネージャーの仕事は難しい(m_m)

P.S.「スコープ管理はプロジェクト計画書から始まる」の内容と似ているよな(m_m)

インターネットは高速道路、そして大渋滞 part2

　別の記事「インターネットの普及がもたらした学習の高速道路と大渋滞」を読んで、僕がかつて生きてきた時代と現在が全く違う環境であることを再認識した。
　記事では、「この10年のITの進化とインターネットの普及によって将棋の世界の何がいちばん変わったか」という問いに対し、羽生名人の下記の話が載っている。

「将棋が強くなるための高速道路が一気に敷かれたということだと思います。でも、その高速道路を走り切ったところで大渋滞が起きています」

　つまり、「ノウハウの共有と迅速な公開」と「インターネットを介して強敵との対局機会を常に持つことができる」環境が突然できあがったことにより、状況は下記のように変わった。

「将棋の駒の動かし方すら知らない小学校高学年生が5年くらいでプロ棋士にまで駆け上がる」ということが将棋界では起きているそうなのだが、そのことは、天才・羽生善治をもってしても、
「自分たちの世代の感覚からすると、全く信じられないスピードなんです」
ということになる。

　では、大渋滞の意味を問われて、羽生名人は下記のように答えている。

「確かにそのレベルまでは一気に強くなれるのだが、そこまで到達した者たち同士の競争となると、勝ったり負けたりの状態になってしまい、そこから抜け出るのは難しい。一方、後ろからも高速道路を駆け抜けてくる連中が皆どんどん追いついてくるから、自然と大渋滞が起きる。最も効率のよい勉強の仕方、しかし同質の勉強の仕方で、皆が、高速道路をひた走ってくる。結果として、その一群は、確かに一つ前の世代の並のプロは追い抜いてしまう勢いなのだが、そうやって皆で到達したところで直面する大渋滞を抜け出すには、どうも全く別の要素が必要なようである」

　この記事には、時代とか生き方について考えさせられた。
　自分が過ごした80年代は、根性論真っ盛り。授業中に先生が生徒を殴るのは当たり前だったし、運動中（特に野球）に水分補給は厳禁だった。（今じゃ考えられない(@_@)）
　でも今では、受験勉強やスポーツのノウハウなんて、インターネットでいくらでも探せるし、掲示板やMLの対話で得られる。
　将棋だけでなく、10代の勉強も同じ状況が起きているのではないか？

　その果てが、高校生・大学生の就職難だったり、オーバードクターだったり、公認会計士試験に受かったのに就職できない合格浪人だったりする。
　いずれも、前の時代に「良い」と言われていた生き方に従った真面目な人たちが、突然、生き方のルールが変わった現状に翻弄されている印象を受ける。
　現在の生き方が変わってしまったという事実に気づかない人たち、そして古い時代の生き方に忠実な人に教わっている人たちが一番苦労しているのかもしれない。

　結局、インターネットという高速道路で取得しやすい技術や知識、資格よりも、マネジメント等のようなメタな知識が求められているのかもしれない。
　インターネットという高速道路を使って追いかけてくる人たちとの競争と大渋滞を避ける生き方は何か？が問われている気がする。

インターネットは高速道路 part1

　「インターネットは高速道路」を読んで、インターネットの環境があれば技術力を伸ばせる可能性がある事を改めて痛感した。

　その記事では、「(人の成長に影響を与えるものとしての)インターネットは、高速道路だ」という一節がある。
　例として、Perlのハッカーが、昔は力技満載のスパゲッティ・プログラムしか書けなかったのに、インターネット上にある優れたソースコードを参考にしてどんどんプログラミング・スキルを伸ばしていったという話が載っている。
　他方、20年間のキャリアを持ったあるベテランプログラマがC言語で書いた最近のソースは、20年のキャリアを感じさせない力技ごり押しのソースコードだったという。
　記事では、二つの例を下記のようにまとめている。

片や数年で誰もが参考にするコードを書くハッカーに育ったかと思えば、20年経っても当時のままというプログラマもいる、彼らの決定的な違いは何だろう?
個人のセンス、能力?
いえ、それは成長の過程のなかにインターネットというメディアが存在していたか否かが決定的なのでした。

　プログラマにとって、プログラムを書くのと同じくらい、プログラムを読むことは大事だと特に最近思う。
　Javaの場合、フレームワークやライブラリを駆使したサンプルソースがいくらでもあるし、デザインパターンやリファクタリングでソースの構造を見通しよくする技術紹介がインターネット上にいくらでもある。DIコンテナやアスペクト指向等の最新の技術動向にもすぐに触れられる。
　だから、Javaプログラマは若い人ほど成長するスピードが速いように感じる。インターネットさえあれば、10年前のJava黎明期からやっている人と対等に話せるレベルまで駆け足で登り詰めることはできるから。

　でもC#やCの場合はどうなのだろう？Web系ではなく組み込み系はどうなのだろう？
　Java/PHP/Perl等のWeb系システムは、安いハードにオープンソースのフレームワークを組み合わせる技術力さえ磨けば、誰でも実現できる。でも、組み込み系の場合、高価なハード（例：大企業の家電製品）と密接に絡んでいると、いくら書いても動作確認できない。Javaよりも状況が異なるのかもしれない。

　IT業界に入ってJava一筋だけど、技術はまだまだ面白い。

Aspect思考

　「asatoの技術的な内容の日記」はAspect指向のBlog。内容がすごく興味深い。

　「アスペクト思考」の記事では下記の記述がある。

特定の機能（上の例では、時間の測定）の存在を意識しなくてもすむ、というのは、プログラムの理解の点からは、やや優しさを感じる。
つまり、特定のアスペクトを使って機能を分離することにより、プログラミングする上での思考の軽減になると感じている。
これは、オブジェクト指向（思考）での、ポリモーフィズムなどにも通じる現象かもしれない。
ある部分を気にせずにすることにより、コードを読む上での精神的な負担が減ると思う。この負担の削減は、思っていたよりも、効果的に感じる。

　システム保守のフェーズでAspectを導入するのはリスクが大きいのではないか、という考えから離れられなかったが、ポリモルフィズムのようにAspectを使うことで「コードを読む上での精神的な負担が減る」という意見は深く考えさせられる。
　今の軽量コンテナや脱EJBのように、普通のPOJOをAPサーバーでロードしたら勝手にトランザクション管理やログ出力の機能が追加されるような仕掛けを作りたいという流れがある。その流れに進むと、今までのプログラミング構造の考え方と違うやり方が出てくる気がする。
　実際、「asatoの技術的な内容の日記」に出てくるサンプルソースを読むと、オブジェクト思考とは違うように思う。

　「Aspect思考」は今後も要チェック！

体制上のレイヤーが多いと開発は失敗しやすい

　PM見習いの読書日記にこんな記事が書かれていた。

上記に関連して最近強く思うのは、開発のときに体制上のレイヤーが多いと開発は失敗するだろうということ。やっぱりレイヤーが多いと、身動きは遅くなるし、情報はどんどん欠落していくし、責任はあいまいになっていくし。「ユーザ」と「開発者」だけがいればいいと思う。

　自分の経験と合致する部分が多い。
　IT業界っていくら格好よく言っても、土建業界と同じゼネコン体質で、建築プロセスよりもはるかにプロセスの完成度は低いし、プロジェクト管理のスキルも低い。
　レイヤーが多いと無駄なドキュメントが多くなる。外注を使うと、彼らとコミュニケーションを取り、管理するコストが余分に増える。そもそも、同じチームの開発者を管理できないのに、海を隔てた中国の開発者を管理できるのか？

仕様の決定を遅らせる

　PM見習いの読書日記にこんな記事が書かれていた。

仕様の決定を出来る限りディレイさせよう、というのと、スコープを定義しない、というのは別だと思う。

　「リーンソフトウエア開発～アジャイル開発を実践する22の方法～」でも同じ言い回しが載っている。
　要件定義から仕様を制御しようとすると、必ず確定できない仕様が出てくる。スコープを定めようとしても、スコープ内に入れられない仕様が必ず出てくる。だから、区別して優先順位を付けるのが大事なのだろう。

　自分の少ない開発経験では、確定できない仕様は、テストケース漏れや設計漏れから出てくる時が多い。
　例えば、新たな機能追加で今までとは異なる画面遷移や制御ロジックが付け加わるとか、実は他のサブシステム(特にHOST！)とデータ連携していたとか、設計時には分からず、テストやレビューで判明する時が多い。
　だから、仕様はこうだ！と勝手に決めて進めてしまうと、後で途方もない手戻り作業が待ち受けている。
　
　アジャイルプロセスから学ぶべきノウハウはまだまだ多い気がする。

ペルソナ/シナリオ法はサービス洗い出しに使える

　とある勉強会で「ペルソナ/シナリオ法」を使って、あるビジネスのサービスとユースケースの洗い出しをやってみたら、議論が弾んで面白かった。かなり使えそう感触。

　「ペルソナ/シナリオ法」は、ペルソナという仮想ユーザーからシナリオを作ってみるという手法。元々ソフトウェアの「ユーザビリティ」のお話で良く出てくる。例えば、パソコン初心者とか、オペレーターとか、プログラマ等の仮想ユーザからアプリケーションの使い勝手を検証するのに使うらしい。
　下記記事が詳しい。

ユーザビリティの時代──ペルソナ／シナリオ法 理論編

　ペルソナを規定するコツは具体的な人をイメージするのがいいらしい。年齢・性別・年収だけでなく、性格まで決めた方が、行動特性が出てくるので、シナリオの信憑性が高まるから。だから、名前まで付けてしまう方がイメージしやすい。
　シナリオは、ペルソナがどのように行動するかという物語そのもの。RPGのキャラクターの行動に似ている。

　とある勉強会では、3人のペルソナを出してみた。
　一人目は27歳の独身男性サラリーマン。このペルソナは世の中にいくらでもいるので簡単。
　二人目は45歳の既婚男性の外資系証券部長。マスコミに出てくるイメージそのままに「自分で仕切りたがる」「自信過剰で説教口調が多い」と提案したら、紋切りすぎと皆から突っ込まれた(^^)
　三人目は23歳の独身女性で保育園教諭。インターネットに出てくるイメージそのままに「ショッピングが好き」「ファッションにお金をかける」「可愛い物が好き」等と提案したら、あまりにもステレオタイプだと皆から突っ込まれた(^^)
　ここまでペルソナの性格が定まると行動にも特徴が出てくるので、あるビジネスサービスを各ペルソナがどこでお金を使うのか、というシナリオがくっきりと出てくる。
　上記記事にもアドバイスが載っているが、2人以上でペルソナとシナリオを作っていく方が色んなアイデアが出てきやすい。実際、勉強会でも思わぬシナリオが出てきて、ペルソナが違うとここまでサービスが違うのか、と考えさせられた。RPGをやってるみたいで議論も白熱して楽しいしね。

　感想としては、新規ビジネスモデルを構築する時、トップダウン式にユースケースと概念モデルを作っていくと、それらのモデルが果たして現実に即しているのか、という不安があるけれど、「ペルソナ/シナリオ法」を使えば、特定の顧客層に対してはこのサービスが有効だからこのモデルが必要、と言える。
　もう少し、利点と弱点をはっきりさせてみたい気がする。

　但し、人をステレオタイプに見るのは女の子から嫌われるから気をつけなくては(^^)

弱い絆が価値観を増大させるという事実

　「弱い絆が価値観を増大させるという事実」という記事を読んで、今自分が感じていることと一致していることに共感した。
　記事に下記の一節がある。

「社会的絆によって形成される社会ネットワークにおいては、古くからの友人といった、自分にとって強い絆で結ばれている人物よりも、ちょっとした知り合いのような弱い絆で結ばれた人物のほうが、自分に与える影響が大きい」というものです。

　関西にいるので、IT業界有志の勉強会は東京よりも格段に少ないけれど、あちこち顔を出すうちに、彼らの仕事ぶりや価値観に刺激を受けて、自分が少しずつ変化しているのが分かる。
　仕事が終わった平日の夜や週末の昼から夜の宴会まで、議論してお互いの価値観をぶつけ合うのが好きな人たちは、一般人よりもはるかに向上心が高い。週末なんて彼女とデートや友達と遊ぶのが普通なのに、プライベートよりも勉強会を優先している人も多い。

　但し、関西の勉強会に参加して感じることは、「20代前半と30代前半の人が多く、20代後半の人が少ない」「メーカーや中小ソフトハウスのSEやPMが多く、大手SIerは少ない」という事実。
　20代前半の人は経験は乏しいけど、すごくアグレッシブ。30代の僕よりもはるかに潜在力を感じる。30代の人は、一通りの仕事を覚えた後現実に何か疑問を感じている人が多い。彼らの経験談は非常に刺激的。
　なのに20代後半というキャリアが最も充実した世代がオープンな勉強会に顔を出さないのは何故だろう？

　メーカー出身のSEやPMは勉強会の運営が上手い。勉強会のお題目を作り、議論となる資料をPowerPointで作り、発表会で成果を公開するプロセスをきちんと制御している。彼らは生産管理を勉強しているのだろうから、勉強会のようなオープンなチームでもマネジメントが上手いと思う。勉強会を運営し続けるのは、アジャイル開発に似ている部分がある気がする。メンバーの士気を高めて、メンバーに能力相応の役割を分担し、成果をまとめ上げるには、CMMのような管理プロセスよりも、アジャイルプロセスの方がふさわしい。
　僕のような中小ソフトハウスSEは知的好奇心に飢えている。彼らはプログラミング技術は優れているが、プロジェクト管理やモデリングのスキルは不足している。だから、メーカーSEやPMと議論し合うのはすごく刺激的。
　なのに、大手SIerのSEは殆ど見かけない。彼らは一体何をしているのだろう？

　12月は時間が空く限り、全ての忘年会に出るつもり(^^)

cygtermを使う

　CygwinのシェルをTeraTerm上で動かすやりかたを発見！
　CygTermを使えばいいらしい。
　さっそくインストールしてみたら、、、うまくいかない。

　cygwin.bat　を

bash --login -i -c cygterm

　へ修正してようやく使えるようになった。

　Cygwinを使うケースは、

PostgreSQLを使う
Perl、Lisp、Ruby等のプログラミング言語で遊ぶ

ぐらいかな。以前は色々と試していたのだが。。

「バイオインフォマティックス」は面白そう

　「バイオインフォマティックス」のMLに入会してみた。「バイオインフォマティックス」とは、コンピューターを活用して遺伝子やたんぱく質の研究を進める手法。膨大な遺伝情報をRDBに格納して検索・計算するのが主な手段らしい。

　バイオの知識は全然無いけれど、RDBとGridを使う所に興味を持った。

【１】遺伝情報をRDBで格納した時、ER図はどう書けるのか？
　モデリング技術とバイオの知識が両方必要なんだろう。
　下記の記事・本に少しだけ載っているようだ。

【主な紹介記事】
Oracle Japan/バイオ研究・開発のためのOracle活用術

【紹介本】
「バイオ研究・開発のためのOracle活用術」
水島 洋 (著), 川原 弘三 (著), 日本オラクル ライフサイエンス推進部 (著)

【２】Gridとの関連は？
　複雑な計算・検索処理にGridを使うようだ。
　GridはSunが技術を公開しているけれど、使い方が良く分からない。
　下記Wikiを読むと、MacOSX上のXgridを使うと、遺伝解析にGridが手軽に使えるらしい。

Mac OS X#Xgrid - Ogishima Homepage

　でもMacOSXが動くマシンを持っていないから試しようが無い。
　生物系・化学系はMacが主流みたい。数学系もそう。物理系だけWindowsか？
　すごく興味があるので、いつかMacを購入して試してみたいが、いつのことになることやら。

プロジェクトの不吉な匂い

　とある勉強会の飲み会で、「プロジェクトの不吉な匂い」の記事の話題になった。
　プロジェクトが失敗する時に、以下の不吉な匂いがしていないだろうか？

（1）優し過ぎるクライアント
（2）不明瞭な非機能要件
（3）神の不在
（4）暗黙知の群れ
（5）収束しない会議
（6）最新技術への猛進
（7）パターンの乱発
（8）怠け者エンジニア
（9）無駄の山
（10）笑わないプロジェクトマネージャ

　僕の経験では「優し過ぎるクライアント」「不明瞭な非機能要件」「笑わないプロジェクトマネージャ」が当てはまると思う。
　「優し過ぎるクライアント」は、クライアント自身が、自分が要求するシステム要件を理解していない状況。
　「不明瞭な非機能要件」は、負荷テストやシステムテス�