■ mikeneko.ne.jp閉鎖のお知らせ

がーーーーーん!!!

ご冥福をお祈りします。

■ 小川直也にチャレンジ!!「QUICK & HUSTLE!!」(クィック アンド ハッスル!!)

Jwordプラグインかよー。

■ ソーシャルネットワーキングBARの店舗名募集

つーわけで、朝のぼーっとした頭でちょっとまじめに考えてみる。マインドマップを描いて、ぐにぐにやってたらデキた。こんなのどうでしょうか。

【店名】

pit bar

【命名した理由】

• ちょっと立ち寄れる場所、元気をくれる場所、みんながいる場所、という意味を込めて、F1 などの "ピットイン (pit stop)" から取りました。
• pit は bit の "b" を裏返したものです（つまりデジタルではなくリアルの意）。
• ピッ！(pit) という効果音としても使えます（何に使うんだ）。
• ドメイン名として有効のようです。
• 日本語オンリーでググると「"pit bar" の検索結果 8 件」。あまり使われていない様子。
• pit[名] には、「地獄」や「最低な場所」という意味もあります（笑）

■ DataModelingWiki

データモデルに関する情報はというと、【より良い】データモデリング【モデルを】しかメジャーなものは知らないので作ってみた（情報が無いって、おじさんたちの怠慢だと思うなあ）。淡々と更新していく予定。

ML&参加フォームも作ってみたよ（HTMLを書けばいいだけのプラグインなので簡単!!）。

■ [WORK] 今から新宿

情報システム部門はいかに生き残るか

ですって。

帰ってきた。

情シス部門の位置づけって何なんだ！というお話デシタ。分社化してみたり、SIerみたいになったりする必要は必ずしもなく、それよりもユーザー企業の代表として全社的なIT投資のことをもちっと考える必要があるんじゃねーの？……というのが、まず最初の問題提起。

昨今、EA (Enterprise Architecture) という言葉が流行ってて、特に公共の落札なんかだと「EAに準拠してもらわにゃ困るよー」とかなんとか言われるそーな（何の根拠もなく）。でも、外部の人間（SIer）が、その企業のIT投資の最適化をEAに準拠して提案……なーんてことが出来るわきゃーあなくて、情シス部門こそがその橋渡しをすべきなんじゃねーの？という主張につながる。名言だなーと思ったのが、第１回目の議事録をどちら側（SIerか情シスか）が書くかによって、プロジェクトの明暗が決まることが多いという言葉（情シスが書けボケ）。

で、結局、情シスに必要なのは（足りないのは）何なのだろうか、というと、とりとめもないパネルディスカッションだったので、ぼくが勝手にまとめてみるよ。

• 業務知識
• 経営者と現場との調整力（両者の合意によるIT導入の支援）
• EAに沿ったRFPの作成スキル
• SIerの提案書の読解力（技術スキル）
• 決定力（設計フェーズ以降の決めごとを経営者レベルに持って行かない）

XPで言うところの、オンサイトカスタマー的な役割がそれだと思う。

で、特に重要となるのが「経営者と現場との調整力」になるんじゃないかな。EAというのはアメリカ式なもんだから、基本的にトップダウンの考え方なのね。でも、それじゃあ、会議室じゃなくてココで起きてるんだ！とかなんとか言われて、現場にブーたれられてしまっても困る。そこで、両者のバランスを見極めながら、もっとも最適な方法を見つけていかなければならない。しかも、ROIを気にしながら。情シスは、経営者の立場かつ現場も分からなきゃいけない。

まあ、理想なんだろうけどね。

ここらへんからツッコミたくなる。ROIと簡単に言うけれど。

ROIという言葉で思い出すのが、はぶさんの講演。いつだったか忘れたが、IT投資のグラフは

√

のような形になるとおっしゃっていたような気がする（勘違いかも）。まず、投資があって回収なのであって、いきなり回収できるわけじゃない、と。これってすげー重要なことなのに、分かってないひとが多い気がする。ROIの「I」が何なのか忘れてるんじゃねーかな。どんなに頑張っても、100% 確実に成功できるって保証はあり得ないわけね。「投資」なんだから。同時にリスクも取らなきゃいかんわけ（もちろんリスクを最小にする努力はするべきだが）。マジで大丈夫？

EAとか。EAとか。EAとか。

なんかさーEAを是として話を進めているのはおかしくねーか？

私は平鍋さんの言葉を思い出しましたよ。

Google の I'm Feeling Lucky が要求定義から出てくるか？

この言葉いいよねえー。何度も思い返しています。

EAってのは、最下部からのフィードバックが無いのだよ。オール・トップダウン。そんなのダメだよ。「ITは目的ではなく手段」って知ったかぶって言うけれど、手段から学ぶことも多いのであります。手段に立脚してないビジネスプランは、夢物語でしかありません。

20年前のデータモデルが今でも使えるんですよ！（興奮気味）

テクノロジーからのフィードバックをやってないがために、そんなことでいちいち自慢するのよね。堅牢なモデルという印象ではなく、「あー古くさいビジネスやってんのねー」という印象だけを受けます。

今はヒドいですよね。PL1の頃は良かった。

いつの話だそれは。

「SE」という肩書きばかり。

トリビア：ThoughtWorks のジョブタイトルは……自分で決められる。

補足トリビア：でも、Martin Fowler は……自分で決められない。

結論：肩書きなんかどーでもいい。

ある人のお話

• 上流はIDEF0。そこからIDEF1x でデータモデリング。
• お客様と成功イメージ（とリスク）を共有する（リスクシェア）
• 設計フェーズ移行、協力会社に依頼する場合は、CREATE TABLE させない。
• 投資回収の段（つまり現場への適用）になるところまでお手伝いする。
• プロジェクトが優先になってしまうので、人材育成がなかなか出来ていない状態。
• 人材育成は予算問題に密接に関係しているため、難しい。
• WBSはコストの最小（PMBOKは間違い）

データモデルはRDBのために行うんじゃありませんから!! 残念!!

RDBに落とすまでがデータモデルです。おじさんのお絵かきなんか要りませんから!! 残念!!

UML使ってドメイン分析なんかできるの？

UMLなんかよりも、TDD のことを知ってくださぁぁぁぁぁい!!!!!

結論

データモデル作るだけで全部終わりとする考えは、もう obsoleted ですから!!

■ 夏休みに作った陶芸が届いたわけだが。

興奮しながらダンボールを開封したら、想像以上に小っちゃくなってる器ども。

相方と二人で

これ……邪魔だね

と小さくつぶやき、件のモノたちは台所の奥深くに沈められた。

■ ソースを開放できないため、同時進行で修正できない

C V S を 使 っ て な い の か ！