継続は力なり

　23日の朝日新聞にあったイチローの下記の記事に思わずハッとさせられた。

　結果とプロセス、両方とも大事です。
　結果を出せないと、この世界で生きていけない。
　プロセスは野球選手としてではなく、人間を作るために必要です。
　 　座右の銘は、継続は力なり。

　若干30歳にして、この言葉が言える人間値がすごい。

　ビジネスでも、結局最後は、売上と言う結果で責任が問われる。
　しかし、結果に至るまでのプロセスは、結果を出すために必要なだけではなく、一人の人間を作るために必要なのだ、と翻訳できる。結果が全てと言っても、ルールを無視したプロセスは、結局信用を失うから。（例：三菱自動車、等）

　ヤンキースの松井秀喜選手の座右の銘は下記だそうです。

　　心が変われば行動が変わる
　　行動が変われば習慣が変わる
　　習慣が変われば人格が変わる
　　人格が変われば運命が変わる

　高校時代の恩師の言葉らしいが、この言葉を聞くと彼の振る舞いが理解できるような気がする。
　二人のように頂点で生きている人は、自分を成長させるための習慣をいつも大事にしているんだな、と。

　二人の言葉を聞くと、「7つの習慣」を思い出させる。又読み直そう。

ポインタを制する者はプログラミングを制する

　「ポインタを制する者はプログラミングを制する」と最近よく思うのだが、どうだろか？

another level of indirection
「もう一段の間接参照」を導入すると、コンピュータのほとんどの問題は解決できる。

　この言葉、元々Edsger Dijkstraが言い出したそうだ。
　「リファクタリング本」にも、「実践UML」にも、上記の一節が載っていて、いつも気になっていた。
　結局は、ポインタそのものではないか！

　例えば、複数アプリがメモリを気にしないでもいいように仮想メモリを導入したり、複雑になりがちなController層をアプリケーション・ファサード層とビジネス・デレゲート層に分けたり、イベントをCommandパターンに当てはめて使い回す等、応用例は多い。
　ポインタの概念を突き詰めていけば、Aspectにも繋がる。
　C言語に限らず、Javaでも、ポインタでつまずく初心者は多い。（うちの新人もそうだった）

　ポインタが難しい原因は、一つは、メモリ上に本当のデータがどこに置かれているのか分かりにくい事と、もう一つは、ポインタの排他制御が面倒である事の二つではないか？
　前者は、Javaのインスタンスは複数作成できる事実を知っていれば、それほど難しくない。「Java謎+落とし穴徹底解明」には、「マルチプルインスタンス」という言葉で説明している。
　後者は、スレッド制御をどこまで理解しているか、が問われる。
　「モニタ」「セマフォ」は又今度まとめよう。

プロジェクトマネジメントは生産管理のIT版

　最近流行しているプロジェクト管理は、結局、製造業の生産管理のIT版に過ぎないのではないか？
　日本最強の会社トヨタの管理手法をシステム開発に応用したいだけではないのか？

　生産管理で重要なマスタデータは、部品表と工程表。
　プロジェクト管理なら、リソース管理とWBS洗い出しに相当するのではないか。

　システム開発のボトルネックは、度重なる仕様変更が原因であるよりも、お客さんの要望をシステムに反映できるか分析できるだけのモデリング能力と、プログラム修正作業の品質を保証するためのテストの速さ・正確さにある気がする。
　顧客の満足度が高ければ、むしろフィードバックが多いはず。フィードバックをどれだけシステムに反映できるか、それはエンジニアの力量に依存する。

「地球大進化」は凄い！

　7/17放映NHK番組「地球大進化・大量絶滅」を見た。
　凄い！！　面白い！！

　時は恐竜時代のはるか昔の2億5千万年前。哺乳類型爬虫類が地球を支配していた。ところが、95％もの動植物が突然絶滅してしまう。その原因は長い間謎だったが、ついに解明された！

　昨年（？）、西シベリアの石油採掘で地底に大量の溶岩層が発見された。その広さは中央シベリアまで達するという。科学者は、年代とその規模から類推して、地球史上最大の大噴火を起こした痕跡だと突き止めた！
　大噴火後、地球の酸素濃度は30％から10数％へ激減し、生き残った生物達は更なる生存競争に陥れられた。その後の進化の歴史では、低酸素でも生き抜けるように気嚢システムを持った爬虫類とその子孫である恐竜が大繁栄した。哺乳類は、横隔膜を発達させて肺機能を進化させたが、恐竜の蔭に追いやられた。
　その恐竜も大隕石によって滅び、ようやく哺乳類が地球を制覇した。

　生物の大量絶滅は、恐竜を絶滅させた大隕石だけではなく、地球の内部から来る大噴火でも起きたという事実（？）が凄く衝撃的だった。
　ストーリーが「The After Day」「インディペンデンスデイ」「ディープインパクト」「アルマゲドン」等のパニック映画を思い出させる。
　この学説が正しいならば、来年はパニック映画が流行するのではないだろうか(^_^)

史上最大級の火山噴火が起きた！

　昔、中学生の頃にNHK番組「地球大紀行」があって、地球の歴史をその当時最新の特撮CGで再現して衝撃を受けた記憶がある。恐竜を絶滅させた原因は大隕石だった、とか、生物は火山の傍にいる原始的な微生物から誕生したのではないか、等の説明がすごくインパクトがあって、中学生の僕はワクワクさせられた。
　15年ぶりに「地球大進化」を見て、昔の興奮を思い出したよ(^^)

　NHKのHPを見たら、「地球は2回、全凍結した時がある」等、びっくり仰天の学説まで披露している。思わず、本当なのか、と疑ってしまうけれど。

海も陸も全てが凍りついたとされる地球(スノーボール)

　月1回しか放映しないが、要チェック！

OOAよりもDOAの方がモデリングしやすい

　モデリングを考え始めてから、オブジェクト指向分析(OOA)からどんどん離れて、DOAの考え方を理解しようと努めている。
　DOAの方がOOAよりもモデリングが自然なように感じる理由は何か？
　
　モデリングでは、エンティティの洗い出し、オブジェクトの状態の変化（トランザクション）の二つを深く考える事に尽きる気がする。その二つを突き詰めていくと「洗い出したオブジェクトが現実の業務と整合性があるか？」を考える事に行き着く。

　データがオブジェクトの相互作用で、どのように変化していくのか？
　データがメッセージ送信先できちんと一意に定まるか？
　(だから、クラス図の多重度は重要だ！)

　オブジェクトの振る舞いを考えるのが重要な場面は、例外的なユースケースを洗い出す時だ。
　つまり、作成したモデルが現実の業務を反映しているか、チェックするのに使えるだけ。概念/仕様モデル作成時は、振る舞いの全てを洗い出す必要はないから。

　OOAが有意義に使える場面は、概念/仕様モデルから実装モデルへ落とす作業。GRASPパターンでメソッドを配置していく。
　逆に、概念モデル作成時は、DOAの方がイメージしやすい。
　エンティティを洗い出す基準は、主キーとなるようなデータが存在するかどうか、だから。
　トランザクションの洗い出しも、どんな履歴情報を残したいのか、を突き詰めると、モデリングの文脈に沿ったエンティティ同士の関連から自然に発生する。
　ユースケースを考えるのは手間がかかるし、そもそも難しい。
　
　但し、概念モデル＝DOA、実装モデル＝OOAで開発しても、結局最後は、O-Rマッピングがネックになる。
　O-Rマッピングが解決されない限り、OOAの唯一の弱点(?)は残されたままになる。

オブ・カレーの味(^^)

　オブジェクト納涼祭の感想をBlogに載せたら、オブジェクト倶楽部イベント事務局から御礼の返事が来ました。
　オブ・カレーの辛口の理由も教えてもらいました。

>オブジェクト指向は難しいと認知されているから、
>オブ・カレーは辛口なのでしょうか？

　そのとおりです。なお、
　「オブジェクト倶楽部は中辛を目指しております。」

だそうです。
　「難解なオブジェクト指向は、せいぜい中辛までしか甘くさせることができない」という主張でしょうか？
　やっぱりオブジェクト指向は、理解するための敷居が高いのか(m_m)

部品表の構造

　「生産管理・原価管理システムのためのデータモデリング」を読み始めて、はまっている。
　今まで、部品表や工程表のイメージが無かったけれど、渡辺先生の本は具体的なデータがあるのでイメージしやすい。僕が理解した点を箇条書きで書いてみる。

【1】部品表に出てくる品目の扱い属性表（製造・販売・購入）は、継承を使う。
【2】部品表は階層構造を持つ。故に再帰ルールが付属する。集約型のルールでは、データの不整合が起きる可能性がある。

　工程表の考えはすごく独特な気がする。「工程の順番をいかに表現するか」が重要な気がする。
　又今度まとめよう。

開発のボトルネックは「変化への対応」

　システム開発のボトルネックは、変化に俊敏に対応できる（is agile）か否かではなかろうか？
　うちの営業さんは「ディシジョン(決定)の速さ」と言っていた。

　開発プロセスや開発環境がオープンであるほど、アジャイル開発環境が以前よりも導入しやすくなっている。
　

オブジェクト納涼祭の感想

　7/9に開かれたオブエジェクト倶楽部（場所：品川）の納涼祭に行ってきました。
　面白かったー。
　有名人(平鍋さん、渡辺幸三さん、牛尾さん)を初めて見て、ワクワクしました。皆さん気さくな方でした。

　僕が一番興味を抱いていたのは、オブジェクト指向とあまり関係ないDOAの渡辺先生の講演でした。

　渡辺先生は「業務別データベース設計のためのデータモデリング入門」 、「生産管理・原価管理システムのためのデータモデリング」の著者の方です。
　オープニングトークで講演した平鍋さんが「これらの本は”日本のアナパタ”と言って良いくらいの本です」と紹介してました。
　大阪に住んでいるそうで、すぐに打ち解けられました。僕が持ってきた本に快くサインしてもらいました(^^)
　
　渡辺先生は熱い！　僕がメモした先生の言葉集は、以下の通り。

「SEにとってホワイトボードは大事です。ホワイトボードに書きまくらないと」
　「モデリングはやっぱりホワイトボードで書きまくらないと駄目ですねえ。書きまくって修正して、という作業をしないとモデリングの実力はつきません。でも女性のSEにそれをさせたら、泣き出されて困った事があるんです」
　「私の美学では、テーブルのリンクはL字型ではなく曲線でないと許されないんです」
　「製造業の情報システムでは、MRPが一番基本なんです。でもMRPは在庫削減に現実では役立たない。理由は杓子定規な在庫指示しか出せないので、現場の感覚と合わないから」

　もう少し、渡辺先生のお話を聞きたかったのが正直な感想です。やはりDOAはモデリングの一つの技術として重要であると再認識しました。

　今回の納涼祭は、手作りの文化祭みたいな雰囲気で、永和マネジメントのスタッフの皆さんがお面をつけて、楽しそうに裏方で働いているのが印象的でした。
　最後に、僕が思わず吹き出してしまった、会場のドアに張られていたポスターを紹介します。

　
オブ・カレー（!）

　ボンカレーのマダムが平鍋さんの顔に変わってます(^^)
　オブジェクト指向は難しいと認知されているから、オブ・カレーは辛口なのでしょうか？
　僕は、小学生が好きそうな甘口カレーの方が好きです(^^)

モデリングで大事なのはメッセージ送信

　ビジネスモデルをクラス図で書くようになって、意識し始めたものがある。それは、メッセージ送信だ。
　
　以前、ある勉強会で僕がクラス図をラフに書いていたら、先生から、多重度をきちんと書いてくれ、多重度は大事だから、と注意された事がある。今思うと、多重度からクラス図の背後にあるオブジェクト図を意識していたのだと思う。
　「UMLモデリングの本質」（児玉公信著）でも、最初はオブジェクト図からモデリングしよう、と主張しているが、その意図は、オブジェクト同士のリンクを辿っていくと他のオブジェクトが一意に定まるのか、という点にあると読み取れる。
　リンクを辿る事は、オブジェクト同士がメッセージをやり取りして、きちんとメッセージが伝わっていくのか、を意識することそのものだから。

　ビジネスモデルをソースコードから考える人（ソースコードドリブンな人）は、データのやり取りに気を使う。その発想は関数Callそのものだから、メッセージをやり取りするオブジェクト思考と根本的に異なる。
　関数Callとメッセージ送信の違いは、オブジェクトが属性を持つかどうかの違いだ。属性を持つならば、受け取ったメッセージをインスタンスに保持し、更に別のオブジェクトへ飛ばすことができる。

　ビジネスモデルをビジネスから考える人（ビジネスドリブンな人）は、自然にオブジェクト思考になると思う。

技術検証のスコープ管理

　システム開発でマネジメントしにくいフェーズは、要件定義やモデリングだけでなく、技術検証も該当するのではないか。（多分、既に誰か主張しているしているだろう）
　特にWebシステム開発は、色んなミドルウェアを組み合わせるため、思わぬ爆弾が至る所にある。まるでMineSweeperをやっているようだ。

　例えば、帳票をPDFで出力する機能を技術検証する事になったとしよう。
　最初は、HTMLのボタン押下後、PDFをダウンロードする仕組みを作るのが普通。その仕掛けのために、お金があるならSVF（1ライセンス50万円以上！）を使えば簡単に実装できるが、安く作りたいなら、ApacheFOP等のオープンソースを使ってみるしかない。それらフリーのライブラリの使い勝手や負荷の検証は情報が余り無いから、意外に時間を取られる。
　更に、帳票印刷はDB接続だけでなくPDF作成にも時間がかかるものだから、ユーザ画面でPDF作成を指示後、後でいつでもPDFをダウンロードできる仕組みにしておくのが普通。すると、PDF作成を指示したイベントをRDBへキューとして貯めておき、バッチでPDFを作成する仕掛けが必要になる。バッチ処理はテスト作業量が多くなるので、時間が取られる。
　だから、帳票PDF作成時に、機能のスコープを決めるだけでなく、PDF作成の技術検証のスコープもあらかじめ決めておかないと、いつまで経っても終わらない。

　お客さんからすれば、技術検証はSEの腕の見せ所でしょう、と思われるので、正直辛いものがある(m_m)
　プロジェクトマネジメントで一番大事なのは、スコープ管理だと個人的に思っている。理由は、スコープが時々刻々と変化するのにその事実になかなか気付けないから。

AIXの謎

　僕が今まで扱ってきたAIXのJDKのバージョンは、どれも1.1.8。
　AIXのデフォルトのJDKがそのバージョンらしい。
　だから、HashMapもArrayListも使えないし、VectorやHashtableで使えないメソッドもある。
　余りにも古すぎる！　仕事にならない。
　SolarisやLinuxでもJDK1.3.xが普通なのに、AIXだけ何故？

時系列に依存しないモデリング

　クラス図でビジネスをモデリングすると、時系列に依存しない抽象的構造を見出す方向で思索を深めていく。その感触が新鮮に感じる時が多い。

　理由は、プログラムはたとえJavaのようなオブジェクト指向言語であろうとも、処理を逐次実行に並べていくことに気を使うからだ。処理の逐次実行という思考は、元来、フォン・ノイマン型計算機に発するから逃れられないけれど、論理的思考力に良くない気がする。
　モデリングに慣れていない人を観察すると、クラス図を時系列に並べたトランザクションに書いている事が多い。その発想は、まさにソースコード・ドリブンだ。多分それでは、ソリューションとなるようなモデルにはならないだろう。

　サイエンスは元々、多種多様な自然現象から普遍的構造を見出そうとするものだ。ビジネスの業務フローのように移ろいやすい処理を逐次実行に並べる行為では、ビジネスを支配する原理を見出せない気がする。
　オブジェクト指向言語は、コンポーネントを組み合わせてシステムを作るという発想で、ある程度、時系列という枠組みから離れることができる。
（疑問：時系列に依存しないプログラムは存在するのだろうか？）

　時系列に依存せずにロジックを考え直す行為は、ロジックをHowから考えるのではなく、Whatから考えることに通じている。オブジェクト指向アプローチを突き進めると、データの出し入れに気を使う発想ではなく、モデルの普遍的構造、つまりパターンを洗い出すことに繋がるのではないだろうか？

　最近、パターンが流行しているのは、そんな所にあるのかもしれない。

ショーシャンクの空に２

　後輩H君と焼肉＋缶ビールを飲みながら「ショーシャンクの空に」を再鑑賞。
　彼は、アンディがフィガロの結婚を刑務所全てに流す場面を絶賛した。最終的に人の心には音楽が残る、というシーンを象徴的に表していることが理由らしい。
　ミュージシャンを目指していた人ならば誰でも、この映画をBest３に入れるかもしれない。

　えがぴーさんがこの映画を好きな映画の一つに入れていたのも僕が鑑賞したもう一つの理由。
　彼もミュージシャンのセンスを持っていそうなので、ミュージシャンにとって普遍的な感触を持つ映画なのかもしれない。

　映画鑑賞はアルコールを飲みながら、親友と一緒に見るのが一番楽しい気がする。理由は感動が2倍になるから。しかし、2人で9本も缶ビール・缶チューハイを開けたので、明日仕事する気にならない(m_m)

ショーシャンクの空に

「ショーシャンクの空に」をパソコンで作業しながら見ていたけど、途中で見入ってしまった。
　DVDタイトルの歓喜のシーンが映画の最大の山場。何となくプラトーンのシーンを思い出した。
　缶ビールを飲みながら見ていたから、普段よりも興奮しやすかったかも。
　後輩H君から、映画に恋愛は要らない、と議論したのが見たきっかけなのだが、その意見にも納得。

モデリングの発想方法

　業務フローをモデリングしようとすると、特定のパターンを当てはめて組み立てていくよりも、モデルの文脈からどんどん抽象化していく手法の方が、システムの本質に近付く気がする。
　「UMLモデリングの本質」で「酒屋問屋の在庫管理」をモデリングする章がある。
　最初は、「予定/実績」「タイトル＝アイテム」パターンを使って、発注と出荷のトランザクションを関連付けるモデルが出来上がるが、それではシステムの中核機能を実現していない。
　児玉さんがよく言う「揺さぶり」によって、色んな業務フローをモデルに割り当て、モデルを変形していく過程で出てくる特徴は、「オブジェクトをどんどん抽象化していくこと」だ。例えば、発注や出荷などのトランザクションは「取引」へ汎化され、小売店やメーカーは「パーティ」へ汎化されてゆく。オブジェクトの状態や種類を汎化によってまとめて、クラス図はより抽象的構造を表現するようになっていく。
　モデリングに慣れていない人は、この抽象化の過程が抜け落ちている。ユースケースに出てくるオブジェクトにいつまでも囚われすぎて、トランザクションをただ単に並べたクラス図しか作れない。それではシステムの本質的構造がいつまで経っても見えてこない。
　但し、オブジェクト指向モデリングが難しい理由の一つは、概念を抽象化するやり方がモデラーによってマチマチゆえ、どれが正しいのか分かりにくい事だ。OOAの弱点は、DOAよりもモデルの属人性が高いように見えることだと思う。

　OOAが一つのモデリング技法として確立するには、「動的分類」と「多重分類」をクラス図のどの箇所で使うのか、を一つのパターンとしてまとめることでないか、と思うのだが、それは「アナパタ」に書いてあるわな(^^)
　Fowlerさん、あなたはやっぱり偉いが、「アナパタ」のクラス図はいい加減、UMLで書き直してくれ！！

トランザクション

　トランザクションは技術よりもビジネスモデリングから攻めた方が分かりやすい気がする。
技術から攻めると、ACID特性とかトランザクションレベルとか排他制御とか、重要なんだけどイメージしにくい点が強調されて、理解した気がしない。
　ビジネスモデリングでは「事象の履歴を記録する事がビジネスでは重要」という発想が根底にあるから、トランザクションは自然に現れるし、モデルの文脈に沿って自然に意味付けできる。
　銀行口座の普通預金を例に取れば、commit/rollbackは理解しやすい。送金元と送金先のトランザクションが完了して初めて、送金が完了する仕組みが2-fase-commit。送金が失敗したら処理前に状態を戻さねばならない処理がrollback。
　ある勉強会で、新人が「トランザクションをどのようにクラスとして表現したらいいのか分からない」と質問したら、先生が「ビジネスの現場では、受注番号や出荷番号のようにトランザクションをエンティティの一つと昔から見なしていた。ビジネスを知っていれば自然に出てくる」と返答したのを思い出す。

　ソースコードドリブンではなく、ビジネスドリブンである方が、トランザクションは理解しやすい。