今日は朝4:30からマリナーズ戦を観る。
結果、今日のヒットは1本。
記録は明日以降のホーム戦に持ち越される事になった。

相手は投手力の弱いレンジャースだから心配はしてないけどね。
あとはどこまで記録を伸ばせるかどうか。
おそらくその記録は、もう何十年先まで
イチロー以外に破れる選手なんていないんだろうけど。

--- 偉大な記録 ---
その理由は、記録を見れば一目瞭然だ。
年間安打の歴代ベスト10を見ると、10位に2001年のイチローが記録した
「242」というものがある。
その上を見てみるとどうだろう。1900年代前半の選手がズラリ。

一番最近の選手でも1930年。
ということは、イチローがデビューの年に出した安打数でさえ
ここ70年以上誰も破ったことのない数字だったのだ。
その事実が全くといっていい程クローズアップされなかった当時の状況にも驚くけど。
ヒット数というのはホームラン数と違って、それほど人々の心に残らないのだろう。

だけど、今回は違う。
イチローは100年以上ある歴史の頂上に到達し、そして超えようとしている。

--- 「新人」の付かない称号 ---
これまでのイチローの記録はどれも、「新人」の冠が付くものばかりだった。
・新人の年にMVP
・新人から4年連続200本安打
などなど。
僕を含め、それをはがゆく感じてた人も多いと思う。
イチローを新人という括りで扱って欲しくない。

しかし、誇り高きメジャーリーグは
外部のリーグから来た人間は誰であろうと新人という扱いにする。
これは決して悪いことだとは思わないし、それをどうこう言うつもりもない。

もうすぐ、イチローに「新人」が付かない称号が与えられる。
「メジャーリーグの歴史上、1シーズンに最も多くのヒットを打った選手」
なんか嬉しい。
明日かな。明後日かな。
記録達成の瞬間にはまた、僕の部屋に絶叫が響きわたるのだ(笑)。

--- 予定オーバー ---
しまった。先月は勤務時間を8時間も(？)オーバーしてしまった。
前半あと1日休めたな、この調子なら。
今月は邪魔な仲介人がいなくなるので真面目に働いてみようかな。

--- 基本 ---
開発者としてあるまじき発言をした奴がいる。
「調べるの面倒くさい」
なんてことだ。自分で調べる事が出来ないようじゃ終わってるぜ。

「このカラムに小数って入るんですかねぇ」
自分でやってみろよ。そこに答えはあるのだから。
自分で調べる事が嫌だったらこんな業界に入ってくるんじゃねーよ。
もしくは本でも買え。

--- よくある光景 ---
またかよ。
なんか隣でトラブル対応をしている。
ちょっと話を聞いてみると、DBのインポート・エクスポートで失敗したらしい。
原因は、CSV形式でエクスポートしたファイルをExcelで編集して
インポートをしてしまったというお粗末なもの。

一体何年この業界いるんだよ。
その行為は大いなるタブーだらけって事くらい学んどいてくれ。

--- 第1のタブー ---
まず、CSVファイルは決してExcelで編集してはいけない。
閲覧だけならまぁ許せるか。
理由は、ExcelはCVSファイルを保存するとき
「既存のデータ形式を無視」して勝手な解釈でデータを保存しようとする。

例えば今回のパターンのように、
「05000」のような文字列型のデータを勝手に数値として解釈する。
そして、保存するときには「5000」と先頭の0を取った形で勝手に保存してしまう。
よって、Excel以外で生成したCSVファイルは決してExcelで修正してはいけないのだ。

--- 第2のタブー ---
次。DBのインポート(入力)にCSVを使ってはいけない。
エクスポート(出力)だけならまだ許せる…って何様のつもりだ、俺は(笑)。

理由は、CSVファイルからのDBインポートは
使うDBの種類やインポート時のオプションによって
インポートされる内容が変化するから。

つまり、エクスポートした内容を正しくインポートできない可能性がある。
DBのインポートには、必ずSQLファイル(INSERT文の羅列)を使用する事。
これを面倒だと思うなら、他の人に任せた方がいい。
もしくは、これらのツールを自作する。

--- 長 ---
今日はいつもにも増してお隣さんが爆睡状態です。
もうかれこれ10分以上も寝たままだぞ。
突っついて起こしてやろうか(笑)。

で、起きたと思ったら何やらガサゴソ始め出した。
これだったらまだ寝てる方がマシだな。人に迷惑掛けない分だけ。

--- 丸一日 ---
今日は4時半起きだってのに、結局夜遅くまで起きてる。
もうすぐ丸一日経つぞ。
そろそろ寝よっかなぁ。明日は11時からマリナーズ戦だから
それまでには起きればいいかな。

その瞬間は、あっという間にやってきた。
今日の第一打席、イチローが打ったボールはサードの頭上を抜けた。
これで、シスラーの持つ年間最多安打に並んだ。

そして、これだけじゃ終わらない。
次の打席もヒットを放ち、軽々とその記録を塗り替えてしまった。
ベンチからチームメイト達が駆け寄ってくる。
感動的な光景だった。スポーツ観てて涙を流したのなんて何時以来だろう。
普段試合中には決して見ることの出来ない、イチローの笑顔がそこにあった。

試合後のインタビューでも、イチローは珍しく(少しだけ)動揺していた。
いつもクールな彼だけど、やっぱり今日という日は特別だ。

--- そしてその先へ… ---
さらに今日はもう1安打を放ち、記録は「259」まで伸びた。
あと2試合、一体どこまで記録は伸びるのか。
今度はそっちに注目が集まってくる。

ここで僕も勝手に予想してみた。
「263」。
今のイチローのバッティングを見ていると、
これくらいは余裕で達成してしまうんじゃないかと思う。
まぁ何にせよ、今は歴史を塗り替えたイチローに感謝感激。ありがとう。

--- こちらも必死 ---
日本ではパリーグのプレーオフが行われている。
試合内容どうこうよりも、実況がうるさくて見る気になれん。
どうして民放アナウンサーってのはああいう実況しか出来ないんだ。
ただ大声張り上げてりゃいいってもんじゃないよ。

一生懸命場面を盛り上げようとしてるのかもしれないけど、
そんな作られた演出じゃ逆に冷めちゃうよ。
見る人の感情が割り込めない程に大声が響き渡ってるから。
スポーツを愛してない人間が実況なんてやらないで欲しい。

「やっぱり日本のプロ野球はすごい！」
その言葉にまったく実感がこもってねぇんだよ。
俺には視聴者を洗脳しようとする悪意の言葉にしか聞こえない。

またですか。
性能問題勃発。

調べてみると、やはり問題はSVG。
以前も度々その速度がネックとなってきた。

--- ブラウザの限界 ---
そもそも、このプロジェクトは今までクライアントソフトでやってきたことを
Web上で再現しようというもの。
いくら最近ではJavaScriptやDynamicHTMLなどが進化してきたといっても、
やはり専用クライアントと比べたらその表現能力には雲泥の差がある。

ある程度の妥協をしなければいけない。
もしくは、より適切な表現方法に変更する必要がある。

それが、このプロジェクトでは今まで一切行われていなかった。
専用のクライアントと全く同じ表現方法にしようとしている。
そして現在、その事による様々な弊害が起き始めている。

--- 本末転倒 ---
その結果、奴らが取った行動は。
「SVGを止めてpngを使う」。
あ?あ、予想してた最悪の事態が起きちゃったよ。

僕がこの現場に来た1年前、その事を指摘したじゃないか。
SVGなんか止めようよって。
でもそのときの奴らの反応はこうだった。
「もうSVGでいくって決めたんだから」

こうなる事は目に見えてたのにね。
そのために、一体どれほどの予算が掛かると思ってるんだろう。
まぁ、その作業をするのは僕じゃないから
これ以上文句言うつもりも無いけど。

--- どこでも同じ ---
楽して能力が身に付くなんて、どの業界だってあり得ない。
一流のアスリートだって、日々のトレーニングの積み重ねこそが
結果を残す唯一の方法だ。

開発業界で、よくこんな声を耳にする。
「どうやったら簡単に技術身に付きますかねぇ」
実際に技術を使ってみろ。それしか方法は無い。
大体、こんな事を考えている時点で
そいつの向上心の無さがうかがえるんだけどね。

別にこの業界に限ったことじゃないぜ。
向上心の無い奴は、いずれ堕ちていくのさ。

--- 衝動的に… ---
なんか転職したくなってきた(笑)。
そんなわけで転職サイトで色々情報を探す。
もちろん、この業種を変えるつもりは無いけどね。

最近、営業が以前にも増して使えなくなってきたので
そろそろ潮時かなぁと思って。
本当は一括の仕事やってから、って思ってたんだけど。

とりあえず気になった1社に応募してみる。
それにしても、この転職サイトも相当使えんぞ。
入力フォームでサーブレットエラーは出るし、内容変更しようと思っても出来ないし。
もうちょっと何とかならんのか。かなりの人が使ってるんだから。

というわけで。順調に行けば今の会社とは今月限りでおさらば。
うまく行かなかったらもう少しお世話になるけどね。
ちょうど今の契約が今月末までだから、来月から働けるといいなぁ。

得てして、仕様書というのは穴だらけだ。
こんなものを見てプログラムを作っていたら、おそらく
とんでもない代物が出来上がってしまうだろう。

プログラマは仕様書の穴を埋めるべく、自分で仕様を作らなくてはいけない。
こんな事するんだったら始めからプログラマが仕様書を書いた方が
よっぽど理にかなっている。

--- 伝染病 ---
はぁ、なんかここの周りの奴らはやる気無いのばっかで
気が抜けてくる。
こういうのは社内全体に伝染するね。

--- 雨雨… ---
なんか一昨日くらいからず?っと雨。
どうなってんの。今ごろになって梅雨到来か？

というわけで、明日は休みますか(ぉい)

はぁ、ここの現場も「逃げ」の精神だらけの奴が多い。
仕様書を作ったら、いかにその仕様書に「逃げ道」を作るかを考えている。

通常、仕様書とは「実装されるべき内容」を示したものだ。
何を勘違いしたのか、奴らは「仕様書に載っていない内容は実装しない」という
腐りきった理論を持っている。

つまり、面倒くさそうな要素は仕様書に載せないことで
その実装(作成)を避けようとしているのだ。
レビューの段階でその事が相手にバレなれけば、とでも思っているのだろう。

--- 失敗の理由 ---
こんな事やってるから、ロクなものが出来上がらないんだよ。
前にも書いた通り、設計の段階で要求の全てを満たす事なんて事実上不可能なんだ。
仕様書作って外注先に投げてハイ終わり、というスタイルはもはや止めた方がいい。

そうしないとビジネスが成り立たない？そんな事は無いだろ。
決められた期間内ならいくらだって仕様を変更すればいいのだ。
もちろん、その中で納期を守れるように
実装すべき機能とそうでない機能の切り分けはきちんとしなければならない。

期限内に終わらないような仕様修正を相手から持ち掛けられたら、
そのときは納期と予算を増やしてもらえばいい。

--- 宅ファイル便 ---
こんなサービスがある。
これはいわゆるストレージサービスみたいなもので、
メールでは送れないような容量の大きなファイルを
一時的に保管しておいてくれる。
また、指定した相手にメールで通知を送ったりもする。

無料のサービスなので利用してる人も多いらしいが、
仕事の用途で使う人間の気が知れない。
こんなもの、明らかに外部に情報流されてるに決まってるじゃないか。
そうでなけりゃ、こんなサービスやろうなんて誰も思わないよ。

それを何の疑いも無く使ってるとは、セキュリティ意識の低さを感じるね。
自社にFTPやWebDAVの一つでも立てりゃ良いものをさ。

さて、こんなものがある。
JBossの最新版を落とそうと思ってたら偶然見つけたんだけど。

Javaのようなオブジェクト指向言語の弱点を補うべく考案された、
新時代のプログラミング方式。
とはいっても、オブジェクト指向の概念を覆すわけではなく
オブジェクト指向と共に使っていこうというもの。

--- 管理の方法 ---
簡単に言えば、プログラムソースから
デバッグや例外処理に関する部分を取り出して別々に管理するようなイメージだ。

今までだと、例えばログのコードもプログラム中に記述する必要があった。

　void func(Object param) {
　　logger.debug("enter func()"); // メソッド開始ログ
　　if (param == null) {
　　　throw new MyException("param is null !!"); // nullチェック
　　}
　　... // 処理ロジック
　　logger.debug("x = " + x + ", y = " + y); // デバッグ用ログ
　　... // 処理ロジック
　　logger.debug("exit func()"); // メソッド終了ログ
　}

このように、本来行う処理ロジックと
デバッグやチェック等のコードが同系列で配置されている。
これは、流れを追う上で非常に見にくい。

アスペクト指向の場合、これらを別ファイルに記述することが可能となる。
これによって、基準となるソースには
純粋な処理ロジックのみ記述すれば良いことになる。

--- AspectJ ---
Javaでアスペクト指向を使うには、AspectJというパッケージが一番有名らしい。
これはEclipseグループで開発されているので信頼も出来そうだ。
当然、Eclipseプラグインとしても提供されているので早速使ってみた。

なるほど。とっかかりは難しそうだけど、
なかなか使い勝手はありそうだ。
そのうちにコンテンツとして公開してみようかな。

は?ぁ。またかよ。
例の口だけ君が、今後どうしようか悩んでいる。
「テーブル管理するテーブルでも作りましょうか」

その後もあ?だこ?だ…口で言うだけなら簡単だよな。
だったらそれを形にしてくれよ。
結局、構想だけでいつになっても形にはしないんだぜ。

「やる事あり過ぎて何から手つけていいかわかんない」だって。
そうやって、一生物事を先延ばしにして生きてくんだろうね。
一つ一つ片付けない限り、物事は決して完了しない。

--- AspectJ ---
今日はず?っとこれ。
アスペクト指向についてはまだどういうものはよく判っていないんだけど、
使いこなせば相当に便利かもしれないというのが現在の見解。

ただ、Eclipseとの連携が今イチなのがちょっとね。
Java EditorのQuick Fixが効かなくなってしまうのだ。
Eclipseグループで開発してるんだから、もうちょっと何とかしてほしい気もするんだけど。

今日からMLBプレーオフ第2ラウンド。
注目はもちろん、ヤンキースvsレッドソックス。
日本時間で朝9時から試合なので、仕方無く録画して観ることにする。

しかし、現場でニュースを見れないのがつらい。
大体いつもYahooとかスポーツのニュース見てるから、
うっかり見そうになって慌てて止めるといった状況が続く。

--- ネタ豊富 ---
なんかこんな時に限ってネタが豊富だ。
JBossのEJB3.0対応版がプレリリースされた。
それでなくても今はAspectJの試用で忙しいってのに。

こりゃ仕事なんかしてる場合じゃないな(笑)。
JDK5、AOP、EJB3.0。とりあえず、この3つはどれも魅力がある。
かといって、簡単に身に付けられる技術でもないので
じっくり取り組んでいく必要がありそうだ。

そしてNFL、さらにはMLBプレーオフ。
挙げくの果てには最近ゲームまで買ってるし。
しかも今週は木、土と仕事の面接。
こんなに予定が詰まってる事は珍しいね。
まぁ、ほとんどが自分だけの都合だから大して疲れはしないんだけど。

そして…締めはやはりアルコールですか(笑)。
この前買ったワインは結構うまかった。もう飲んじゃったけど。
ワインにハマると金掛かりそうだからなぁ。

やっと、またEJBに手を付けるときがやってきた。
昔僕がトライしたときには、あまりにもデメリットが多すぎて
結局個人では導入する必要が無いという結論に達した。

しかし、EJB3.0は一味違う。
以前ドラフト仕様が公開されたときに、
僕は「これなら使えるかも」という印象を持った。

--- EJB3.0とJDK5 ---
EJB3.0の核となっているのが、JDK5の機能をフルに生かしたAnnotationなどの採用。
これによってJDK4以前を捨てることになるが、
別にこれはJDK4以前のライブラリが使えなくなるという事ではなく
JDK5のプログラムが過去のJDKで動かなくなるという事だけだ。

以前の資産はJDK5でも問題無く使うことが出来るし、
複数バージョンのJDKを同一マシンにインストールしていても何の問題も無い。

--- Very Simple ---
今までのEJBが駄目だった最大の理由は、その設定ファイルが難解だった事にある。
一つEJBを追加するだけでxmlファイルに何行もの記述を追加しなくてはいけない。
さらに、ちょっと複雑なEntity Beanでも作ろうものなら
悠に100行を超える記述が(Javaファイルとは別に)必要になる。

それが、EJB3.0では劇的に変化した。
もう面倒なxmlファイルは必要無い。
通常のJavaファイルにいくつかのAnnotation(注釈)を付けるだけで、
そのオブジェクト(クラス)はEJBクラスとして使うことが出来る。

もちろん、細かくカスタマイズすることも可能だが
その必要が無ければ記述を省略することでデフォルトの設定を使うことになる。

--- EJB3.0の目指すところ ---
結局、EJBとは何の為にあるのか。
トランザクション管理？分散処理？

違う。EJBが目指すのはそんなちっぽけな事じゃない。
では何か。僕が考える答はずばり、「プログラム(Java)とリソース(Database)の融合」だ。

ほとんどのプロジェクトにおいて、必ずデータベースは必要になる。
そしてもちろん、プログラムも必要だ。
しかし、今までの開発ではこれらの結び付きが非常に低かった。

つまり、プログラムとDBを別々に管理している。
両者は本来強く結び付いているはずなのに。

--- 両者の統一 ---
だから、DBの定義を変更したら
プログラムも修正しなければならない。
しかも、1箇所だけではなく多くの箇所を。
そのため、DBの定義を修正することは極力避けられてきた。

しかし、これでは駄目なのだ。
プログラムと同じように、DBも修正しなければならない場面が必ずある。

EJBは、プログラムで定義したクラス(オブジェクト)が
DB上に適切なテーブルとなって構築される。
というより、もはやDBの存在を意識する必要が無い。
DBはプログラムの一部として取り込まれているのだ。

--- 今後 ---
良い事ばかりのEJBだが、もちろん問題点はある。
最大の問題が、大幅なパフォーマンス低下だ。
これほどまでに便利な方式が今まで使われてこなかったのは、
それによる処理速度の低下があまりにも大きかったから。

これを解決するのは、もちろんCPU処理速度の向上もあるだろうが
それ以上に必要なものがある。
それが、「EJBに特化したデータベース」の存在だ。

これに挑戦しているのが、JBossとMySQL。
両者が手を組んだという事は、相当の物が出来ることを期待していい。
それが完成したとき、EJBは真の実力を発揮するはずだ。

--- 面接 ---
仕事終わりに面接行ってきました。
今日は、現在所属してる会社の方ね。
一括のグループだっていうから期待してたのに、話聞く限りロクでも無さそうな雰囲気も。
なんかやる気無くしたけど、とりあえずうちの営業の人が
もう一回話を聞く機会を設けたいって事なんで、また来週面談かな。

ここは自社グループの現場だから、他のどこよりも自分の意見が通せる可能性がある。
そういう意味では簡単に捨てるのも惜しいと思うしね。
今週の土曜には、別の会社の面接も受ける予定なので
そことも比較しながら今後の身の振り方を決めていくつもり。

何にせよ今は、少しずつでも自分の望む現場に近づいていくだけだ。

何だよ…現場でJBoss立ち上げようとしたらこのエラー。
どうもJNDIで使ってる1099番のポートが既に使われているらしい。
昨日まではこんな事無かったのに。

原因は何だろう。考えられるのはこの前やったWindows Update。
でもUpdateしたのは確か一昨日だったから、昨日動いてたってのが謎。
とりあえずconfファイルのポート番号を変えることで応急処理。
ひょっとして俺のマシンだけか？

--- 近づいてる？ ---
今日はお隣さんがいつもにも増してやばいです。
9割以上は寝てるぞ。
もうそろそろ倒れるんじゃないの？
そうなってからじゃ遅いんだけどねぇ。
会社の人の忠告もむなしく、今だに病院にも行ってない様子。
結局本人が行く努力をしなけりゃ、どうにもならないんだからね。

--- 再びEJB ---
今日もずーっとEJB。
使い始めて再確認したが、やはりEJBは難解だ。
一番の問題が、エラーメッセージ。
ロクなエラーメッセージが表示されないのだ。
そのせいで、ユーザは「何が間違っているのか」が判らない。
こうなると、もうどうにも先に進めなくなる。

今日も、プライマリ・キーをString型にする方法がわからず四苦八苦。
結局判らず終まいだ。
サンプルで提示されていたのは全てキーがinteger型になっていた。
僕も個人でDBを作るときは必ずそうしているが、
ビジネスの世界ではそういう常識はまだまだ浸透していない。
大抵は文字列型(しかも複数カラム)のプライマリ・キーが使われている。

これをEJBで作ろうとしても、そのやり方が判らない。
まだプレビュー版が発表されたばかりなので
Webからサンプルを探すこともほとんど出来ない。
こういう時は自分で何とかするしか無いのだが、
ソースも公開されていないのでどうしようも無い。
あぁ、齒痒いぜ。

おいおい、ここの現場はどうなってんの。
この寒いのに冷房が掛かってる。
もうそろそろ暖房でもいい時期だってのに。
参ったなぁ。

--- 探し続ける ---
仕事ではなく、今度は部屋探し。
とりあえず転職はまた今度の機会にすることにした。
なんか面倒くさくなったので(笑)。

そろそろ部屋を変えようと真剣に思ってきた。
資金もたまってきたしね。
今狙ってるのは目黒近辺。以前は中目黒にしようと思ってたけど
調べたところ目黒と大して相場が代わらない。
だったら山手沿線の目黒の方がいいかなーと思って。
そう考えたら恵比寿でもいいかも。

ただ、いずれにせよ今の給料じゃ厳しいのは間違い無いので
もう少し先になりそうだけどね。

--- デジタル化 ---
ただ引越すだけじゃアレなんで、その機会にはデジタル録画でも始めようかな。
今まではケーブル会社のチューナーにiLink端子が付いてなかったから
興味持たなかったけど、引越した先ではデジタルチューナー買おうと思ってる。
まだ高いんだけどね。

そうすればデジタル録画できるから、ついでにDVDレコーダーも買おうという計画。
ただ、出費がかさむなぁ。
もう少し資金に余裕持ってからの方がいいかも。

--- 皆の部屋 ---
あー…なんか声のボリューム間違ってる奴がいるぞ。
ここは会議室じゃないんだから、もう少し周りの事考えてくれ。
それとも、彼は小さい声で喋る事が生まれつき出来ない体質なんだろうか。
何にせよ、すごくうるさいんです…

--- 終了間際 ---
もう今月で終わるとあって、僕に振られる仕事がほとんど無くなってきて暇だ。
かといって現場全体が暇なわけではなく、
例の社員は忙しそうにしている。

なんで作業を分担させようとしないのかねぇ。
全然回ってないのにさ。
自分で済ませたいっていう無意味なプライドかもしれんが、
それがプロジェクトとして赤を出してるっていう事実を認識した方がいいよ。
こんな事やってるから儲からないんだ。
まっ、それも全てプロマネ(≒置物)が何も努力してないからなんだけど。

--- 土台が必要 ---
この前も話した現場の面接で、プロマネの補佐についてみないかという話があった。
別にプロマネに興味が無いわけじゃないが、まだその段階では無いと思っている。
それは、僕の能力がどうというよりも
開発の「土台」がまだ出来ていないからだ。

プロマネというのは、プロジェクトを成功に導くための役職だ。
プロジェクトに必要な期間や人材を割り出し、
その為のスケジュールを立てる、等々。他にも山ほどやる事はある。

要するに、プロジェクト全体のトップに立つ存在。
それなのに、現状ではおそらくその下に就く人材が全く揃っていない。
こんな状態では、プロマネの存在意義は限りなく低くなってくる。

--- 土台の育成 ---
では、その土台とは何か。
僕が考えるに、それは開発工程の確立にある。
プロジェクトの一番下の部分、それは実際にプログラムを組む部分だ。
そこがしっかりしていないと、まともなシステム開発など出来ない。
逆に、そこさえしっかりしていれば後は何とかなる。

プロジェクトの進行を遅らせる原因として
プログラムの作成が遅れたりバグが大量に発生したりと
技術面が未熟なために起こるものが多い。
ここを改善しない限り、プロジェクト開発が正常に進行するはずがない。

各自が勝手に作り、汎用性の無いクラス群が散在している現状。
これらを解決するために、プログラマのリーダー的な存在が必要だ。
適切な開発工程の確立をメンバー全員に浸透させれば、プロジェクトはスムーズに進行する。

僕は、今そういう立場になるのが理想だと思っている。
プロマネのような管理的役職は、それが成功してからでいい。
僕が安心して任せられる、現場のリーダーがいるようなプロジェクトでね。

--- 上下関係 ---
よく、役職に上下関係を付けたがる奴がいる。
わかりやすいところで言えば、SE(システムエンジニア) > PG(プログラマ) とかね。
僕から言わせれば、これは全くのナンセンスだ。

各役職は、専門職であるべきだ。
各自がその道を極めることが、プロジェクト成功への鍵になる。
PGなんかその辺から集めてくればいいや的な考えでは、
いずれプロジェクトは破綻する。間違いない(長井風)。

--- 今後 ---
業界が成熟してくれば、僕もプロマネやコンサルといった
職種に興味を持つかもしれない。
だが今は、そんな事をやっている場合ではない。

質の悪いプログラムは、全てにおいて有害だ。
まずは、質の高いプログラムを組む事。それを作る人材を集める事。
そういう人材が揃わないと、僕はとてもじゃないが他の人に任せてなんかいられない。
そしておそらく、こういった状況は後何年も続くだろう。

上からのんびり眺めて指図してるような、
偉そうな立場は僕には向かない。
やるとしても、まだまだ先の話。キャリアを10年位は積んでからね。

やべっ、面白すぎる…
また隣でゴチャゴチャ言ってるのがいる。
そいつが繰り返し言ってるのが、「As Soon Asでやれって言われても…」
お前はルー大柴か(笑)。すぐに、でいいじゃん。

ほんと、この会社はロクな技術者がいないんだよな。
自分の責任を人のせいにしようとするし、
自分は出来ると自信持ってる割に何も出来ないし。

--- 本日、台風につき ---
仕事中、嬉しいニュース。
今日は台風が近づいてるので4時で上がっていいそうだ。
やったね。

--- 最大のライバル ---
すごい事になってきた。
ヤンキースvsレッドソックスはいよいよ明日、最終の第7戦へともつれ込んだ。

正直、今年はヤンキースが3連勝した時点で僕は「これで決まったな」と思ってしまった。
過去にも、3連敗の後4連勝して勝ち上がってきたチームなど一つも無い。
3戦目の勢いからいっても、そのままヤンキースがsweep(4連勝)してしまう雰囲気がしていた。

しかし、この両者の戦いはそんな過去の歴史など全く関係無いかのように
激しい試合を繰り広げた。
レッドソックスからしてみれば、ヤンキースはまさにライバルだ。
このチームに勝たないと、ワールドチャンピオンへの道はあり得ない。
幾度となく、ヤンキースはその道を塞いできた。
もう80年以上も、レッドソックスは世界一になった事が無い。

--- 因縁の対決 ---
彼らは諦めちゃいなかった。
連夜のサヨナラ勝ち。5時間近いゲームを連日戦った翌日、
ニューヨークに戻って移動日無しで今日の第6戦。

ここに来て、レッドソックスの投手力が本領を発揮してきた。
ヤンキースの打線が繋がらない。
3連敗の後、奇跡的とも言える3連勝。
これで、勝負の結末は全くわからなくなってきた。
去年に引き続き、両者の対戦は最終戦で決着をつける事になった。

おそらく明日は、壮絶な試合になるだろうね。
今から楽しみだ。

どうも今日は眠い。
昨日珍しく酒を飲まずに寝てしまったせいか。

最近、酒を飲んでる方が生活のリズムがいいことに気付いた。
寝る時間も早くなって、朝の目覚めがよくなる。
でも、朝飯抜くことになっちゃうから身体には良くないんだけどね。

--- 防ぎきれず… ---
うむむ。
やっぱり今日は家に帰るまで試合結果を伏せておく事は出来なかった。
昼休みの時間に色んな所で話題になってたから
この段階で結果を知ってしまった。

ヤンキースとしたら、屈辱以外の何物でも無いだろうね。
3連勝からまさかの4連敗。
ここまできたら、是非レッドソックスには優勝してもらいたい。

--- インターフェイス ---
Javaにはインターフェイスという概念がある。
クラスと似ているのだが、こちらの方は実体は無く
「実装すべきメソッドの一覧」だけが定義されているのがインターフェイス。
C++でいうところの抽象クラスと考え方は一緒。

「抽象化」というのは、オブジェクト指向において重要な考え方となっている。
なぜ、こんな解りにくい概念が必要なのか。
それは、より開発をスムーズに行うための手法だからだ。

--- 開発の実際 ---
プログラムというのは、常に変化していくものだ。
それは、仕様の変更や追加であったりバグ修正であったり。

仕様の変更を止める事は出来ない。バグの発生を無くす事も出来ない。
だったら、やらなければいけない事は何か。
それは、プログラムの変更をし易い作りにしておく事だ。
そうする事で、あらゆる事態に柔軟に対応する事が可能となる。

これに反して、一から完璧なものを作ろうとする輩がいる。
徹底的に仕様書を作り込み、プログラマに仕様書を渡す。
これで、彼らの仕事はお終いだ。
後は、自分の書いた「完璧な」仕様書を元にプログラムを起こすだけ。

--- 現実見てない人(否ジョン・レノン) ---
ただし、残念ながらこのプロジェクトは成功しない。
何故か。それは、完璧な仕様書など決して存在しないからだ。

この意見を言い逃れや妥協だと思う人は、一度設計論でも学んだ方がいい。
人間、完璧な事など何一つ無い。
失敗する可能性を考えるのは当り前。
むしろ、その可能性を無視しているのは現実逃避としか言いようが無い。

--- 話を戻して… ---
少し話が横道にそれてしまった。
で、何だっけ。そうそう、インターフェイスと抽象化について。

仕様の追加でよくあるのが、既存の機能と似たような機能を追加するというもの。
例えば「ある物体の表面にある形を描く」というシステムがあったとしよう。
物体には球、平面など様々なものがあり
形には四角形や楕円などこれまた様々なものがある。

--- 具体化の場合 ---
ここに、一つ形(星型)を追加する事になったとする。
抽象化の概念を使っていないと、
一つ形を追加するだけで何ヶ所もの変更が必要になる。
「球に星型を描く」「平面に星型を描く」という風に、物体の数だけ修正が必要になる。

つまり、修正の手間が相当掛かってしまう。
そして、修正箇所が多いことはよりバグが混入しやすくなる事を示す。

さらに、もし他のプロジェクトでこのモジュールを使おうとした場合に
楕円の形が必要無くなったらどうだろう。
ただ単純に楕円のクラスを削除してしまうと、球と楕円はガッチリ結び付いているので
球の物体のクラスがコンパイルエラーになってしまう。

この状態を「球は楕円に依存している」という。
楕円という形が無いと、球の存在が成り立たない。
依存度が高いという事は、こういった面で保守性が低くなるのだ。

--- 抽象化の場合 ---
上の話を聞いて、随分現実の世界と異なるという事は判ってもらえただろうか。
本来なら、楕円という形の存在有無に関わらず
球の存在は不変であるべきである。
こういった、現実世界の考え方をプログラムに適用したのが、抽象化という考え方だ。

抽象化の概念を使うと、球も平面も一つの「物体」という抽象的なとらえ方をする事が出来る。
同じく四角形や楕円も「形」というとらえ方をする。
一つの「形」を追加することによって発生する修正箇所は、1箇所でいい。
それは「星型」というクラスを追加して適切なメソッドを定義する事だけ。

つまり、これによって
球や平面などの「物体」側を修正する必要が無くなる訳だ。
物体からすれば、星型が追加されようとそれは「形」の一つに過ぎない。
このとき、物体には「形を描く」という機能(インターフェイス)さえあればいいのだ。

仮に星型を使わないプロジェクトがあった場合でも、
そのときにやるべき事はただ星型のクラスを削除するだけだ。
球と楕円は直接的に結び付いていない。
結び付いているのは「物体と形」という抽象的なものであるからだ。

--- 実際に使ってみる ---
実際にシステムを作っていると、抽象化が使える場面というのは意外に多くある。
やっと僕も最近、実践の中で効果的に抽象化を使えるようになってきた。
そして実際、これを使うことによって
プログラムの修正箇所というのはかなり減少することも解ってきた。
それはプログラムの質の向上を意味するし、よりシンプルな作りになることも意味するのだ。

…久びさに、専門用語全開の日記になってしまった。
たまにはこんな日もあるよ、って事で。

--- 面接 ---
今日も面接。
とりあえず、今の会社にまだお世話になることは決めたので
そっちの方で探してもらう。

今日のは、内容自体はおそらくごく簡単なもの。
僕一人でやったらまぁ1週間も掛からないであろうシステムを
僕を含めて3人2ヶ月で仕上げるという。

ただ、完全な素人2人を教育しながら僕はリーダーとして働かなくちゃいけない。
暇になることは間違い無いが、
小さいなりにもプロジェクトを最初から最後まで、しかも一番上で
やり遂げるっていうのは、僕にとっても良い経験になるはず。
2ヶ月っていう短期なのも嬉しい。

明日も面接なんで、それと比べてどちらかに行くという形になるのかな。

システム開発には、ドキュメントが必須である。
ただ、今回テーマにするドキュメントとは、いわゆる設計書の類ではなく
「コード(プログラム)のドキュメント」の事を指す。

僕から言わせれば、システム開発において
設計書よりもずっとコードドキュメントの方が重要であり、有用だ。

前者はおそらく、システム開発初期に作られたもので
その後ほとんど手が加えられていない。
しかし実際には、開発を進めていくにあたって様々な仕様の変更が行われているはずだ。
その変更が、仕様書には反映されていない事が多い。
いや、全てが反映されていると考える事にそもそも無理があると言えるだろう。
仕様書は大方、ビジネスの場面で存在意義を示す。もちろんこれも大事な事だが。

それに比べて、コードドキュメントは日々書換えられている。
もちろん、そのプログラマがさぼっていなかったら、という前提にはなるが。
「ソースこそ唯一のドキュメントである」という言葉があるが、
コードドキュメントを記載する事によってこの言葉はより確実なものになる。

--- 一時vs永遠 ---
初心者プログラマというのは、とにかく楽をしたがる。
ここでいう「楽」とは、僕が普段から言っている「シンプル」とは全く別のものである。
言い換えれば「手抜き」。
一時の楽を求めて手を抜く事が、永遠の保守に苦しめられるという現実を彼らは知らない。

開発というのは、作成よりも修正・デバッグ・保守の面を考えて進めるべきだ。
何故なら、そちらの方に費す時間の方が圧倒的に多いからだ。
いくら手を抜いて短期間で作成したとしても、
後の作業でその何十倍もの労力を要していたのでは全くの本末転倒だ。
しかし現状、こういった事態はどの現場でも繰り返されている。

--- 現状の問題 ---
それを解消する為に必要なことが、コードドキュメントを書く事だ。
これは、若干開発の期間を遅くする事になるが
後で必ずそれ以上の見返りを求められる。

しかし、それを判っていながらこの事が行われていないのは
開発を依頼する側にも問題がある。
それは「設計」「開発」「テスト」「保守」などを別の会社に行わせているという事だ。
設計担当の会社(もしくはグループ)は、設計書を作って依頼主に渡す。
依頼主はそれを開発担当会社に渡し、という風な流れ。

こういった開発スタイルでは、開発側はコードドキュメントを書く事を
しない事がほとんだ。正直、僕もその立場だったらしようとは思わない。
それは、先程話した「見返り」が大して得られないからだ。

自らテストや保守をしないのなら、時間を掛けてドキュメントを書いても
自分はそれほどのメリットが得られない。
コードドキュメントを詳細に書いたからって契約金が上がることはないだろう。

--- 本来あるべき姿 ---
だから本来、設計から保守までを一貫して行うべきなのだ。
依頼主はむしろこちらの方を望んでいるはずだ。
あちこちの会社に任せていたのでは、その分大幅に経費が掛かる事くらいは
誰にでも判ることだろう。

しかし、ほとんどの開発会社はこの形態を取らない。
その最も大きな原因は、堕落した大会社にある。
こういった会社は、設計(もしくはさらに前段階の要件定義)の仕事しか引き受けない。
そして、何も知らない依頼主も他の会社にこれらを任そうとしない。
「大手だから安心」という考えか、それとも得意先ゆえに断れないのか。

--- 上流工程 ---
何にせよ、こういった会社は
開発やテスト、保守の作業を各下請け会社に丸投げ依頼する。
自分達は「上流工程」にいる、とでも言いたいのだろう。
それ故、中小企業は設計?保守という一貫した依頼を受ける事が出来ない。

もしくは、受けて成功する自信が無いので受けようとしない。
そういった企業の場合、問題はさらに悪化する。
例えば、テストを依頼された企業は何かトラブルがあっても
それをあらゆる手段で(他の工程を担当した)他の会社のせいにして逃れようとする。

開発を担当した場合、1年後に依頼主からバグを指摘されたらこう言うのだ。
「当時の担当者がいないので、対応できません」
コードドキュメントを付けていない場合、そのプログラマが現場から去ってしまったら
残ったソースコードを修正する事に相当の労力を要するからだ。
残念ながら、こういった企業に他人のソースを解析できるような人材は存在しない事が多い。

--- 技術力と労働時間 ---
そして、こういった技術力の高い人材を育てようとも思っていない企業が多い。
そうする事によって開発工数が減れば、その分の利益を減らしてしまうという。
ホント、勤務時間水増ししてる奴らと同じ位腐った奴らだよ。

残業残業、また残業。こんな現場でプログラマに必要なものは忍耐力だけだ。
もちろんプログラマに忍耐力は必要だが、それ以上に必要なものがもっと他にたくさんある。
技術力が身に付いていなければ、結局また次のプロジェクトも
同じ事の繰り返しだろう。

--- そして再び ---
帰りにまたも面接。
何の因果か、今日面接を受けたところは正にこんな奴らだった。
面接中、さっさと切り上げて帰りたかったよ。

といった訳で、おそらくは昨日受けた方に行くことになりそう。他に話が出てこない限りね。
まぁ2ヶ月間なんで別にここでいっか、という気もする。
「つなぎ」の現場としては、それなりに楽しめそうな環境らしいし。
建物全体が電子マネー…っと、ここまで。

さぁ、その2ヶ月間にやる事を今から見つけなければ。
なんか内職のバイトでもあったら喜んで受けるんだけど。

あらら…また始まりました。
お隣さんのメール攻撃。
もう忠告受けたの忘れたのか？どうやら脳内保持期限を過ぎた模様。
こりゃまた言ってもらわないと駄目ですな。

さっき定時15分前のチャイムが鳴ったということは、
こいつメール終わったら速攻帰るつもりか。
ここまであからさまに仕事やる気見せないのもどうしたものか。

--- 最終週 ---
いよいよ、1年以上続いてきたこの現場とも今週でおさらば。
その割には大した引き継ぎの作業もせず。
まぁ僕が気にする事じゃないけどね。こんなんだから無駄が大量発生するんだぜ。

どこにでもこういう輩はいるもんだ。

「巨人、今年はFA選手獲りません」
今シーズン、金にものを言わせて選手を獲得した結果
リーグ優勝にも届かなかった現実を受けての発言がそれかよ。
こんなんじゃまた来シーズンも落ちぶれるのが見えてるね。

今年弱かった原因は「FA選手獲った」事が直接の原因じゃないだろ。
何の考えも無しに年俸高い選手集めりゃいいと思った奴らが問題なんだ。
そいつらの考えを改めさせなきゃ何も始まらないぜ。
大体、そんな基本的な事すら判ってないとは
監督やGMのレベルの低さを感じるね。

よく巨人とヤンキースは似てるっていう人がいるけど、全然違う。
強力な選手をかき集めるところまでは似てるけど、
ヤンキースの試合戦術は監督自ら「小技チーム」というようにしっかりしている。
やっぱり監督の違いかね。

--- どうなる事やら… ---
ここの現場はプログラマがいない。
今月限りで僕は辞めるというのに、その現状は今も変わっていない。
今日も簡単なログ削除モジュールの作業を頼まれる。
別に俺は構わないが、この先の事を考えてそろそろ自分達で何とかする力を
身に付けようとしたらどうだろう。

このままじゃ、僕がいなくなった後の状況が目に見えてるぞ。
おそらく、完全に外部に投げる体制になるんだろうね。
断言する。このプロジェクトは永久に赤字を出し続ける。止めない限り。

--- 顔見せ ---
昨日は、来月から働く現場に顔見せに行ってきた。
僕の下に就くのが完全なド素人なのはこの前の面接で聞いてたんだけど、
それ以外のメンバーも技術レベルは相当に低そうだ。
話を聞いててそんな印象を受けた。

今回のプロジェクトはかなり小規模なものだけど、
ここの会社ではそれなりに大きくて先進的なプロジェクトも進めているらしい。
そういう意味では、この2ヶ月で力を認めてもらえれば
そういったプロジェクトに配属される可能性もあるという事かな。
一応「つなぎ」の現場とはいえ、こういったチャンスは貪欲に探していかないとね。

--- プレッシャー？ ---
何はともあれ、今回は僕が製作する訳にはいかず
新人2名に教育も含めて作らせなきゃいけない。
ちょっと余計な手間が掛かるけど、それも仕事なので仕方が無い。

「プレッシャーとかは無い？」とか聞かれたけど、こんなチープなプロジェクトの
どこにプレッシャーを感じる必要があるのかよぅ判らんぜ。
まっ、まだ向こうはこっちの力を信用してる訳じゃないからしょうがないか。

何でもかんでも信じ過ぎちゃうような奴よりはよっぽどマシだ。
今の現場のPMが正にそう。
奴の場合は「過信」を超えてもはや「責任転嫁」になってるけどね。
「あの件ですか？○○君に任せときました」。常にこれだから。

--- トップに立つ人達 ---
僕は大抵、「一番」という響きのものを嫌う。
「一番が一番でしょ」って、どっかのCMで言ってたっけ。
でも「一番売れている(人気がある) = 一番良いもの」では無いという考えを持っているのは
僕だけじゃないはずだ。

どこに行っても、一番上にいるという事は僕にとってあまり魅力的な事では無い。
トップというのは責任もつきまとうし周りの目もある。
国のトップである総理大臣や大統領という人物でさえ
到底国で一番優れている人だとは思えない。

だから、僕にとってトップになる意味というのはさほど無い。
もちろん、トップになる人物というのは必要な訳で
そういうのはやりたい人がやればいい。トップでいる事を好きな人が、ね。

--- 残業の理由 ---
むむむ…参りました。
引き継ぎの作業する会社の人達がこっちの現場に来てるのだが、
定時過ぎてもまだ帰ろうとしない。
早く帰ってほしいんだけどな?、そうしないと僕が帰れないじゃん(笑)。
一応僕がアドバイザーという事になってるから、勝手に帰るわけにも行かないのだ。

…う、駄目だ。もう限界。持病の発作が…(嘘付け)

ふぅ。現在8時。ようやく帰ってくれました。
これじゃ今日の夕食は弁当だなぁ。今からじゃ料理する気になれん。

--- 寒 ---
おいおい、ちょっと前まで夏かと思ってたらもう冬並に寒いのはどういうこと？
秋を感じないままに今年を終わってしまうのか。

NBA初の日本人選手を目指す田臥勇太。
彼の夢が、今現実になろうとしている。
レギュラー争いを続けていた同ポジション(ガード)の選手が解雇され、
田臥の開幕ロースターは確実になったようだ。

もちろん先発ではないと思うけど、
ロースターに入っているという事は試合展開によって必ず出るチャンスが回ってくる。
そのときには間違い無くBSで放送するだろうから楽しみだね。

--- 残念ですが… ---
またもイラク人質事件。
ただ、今回の人質はあまり褒められたものではないようだ。
「旅行」感覚でイラクに行ったという動機なんかも含めてね。

正直、こういった人間を相手にしていたら
国としても疲れるだろう。
だからと言って、完全に無視している訳にもいかないだろうから
政府はそれなりの対処をすると思うが。

僕だったらこういった勝手人は見捨てるけど、
当然国のトップとしてそういう対応取るわけにはいかないから
総理さんは大変だね。でも、その割には自衛隊撤退させないとか言ってるし。
あぁ矛盾だらけ。彼が殺されちゃったら何て言い訳するんでしょう。

--- 蛙くん ---
ちなみに「かわず」と呼んで下さい。
相変わらず、設計で悩んでる奴がいる。
話を聞いてると、まるで現実が見えていない発言が続く。
こいつは正に「井の中の蛙」だな。というわけで、彼のアダ名は蛙くんに決定。
もう明日で僕辞めるから今度登場する事は無いと思うけど(笑)。

そうそう、明日は僕ともう一人の人が現場を去る(その人は移転だけど)という事で
送別会をやってくれるらしい。
もちろん、当人である僕は会費ゼロ。
よっしゃ?、明日はタダ酒飲みまくるぜぃっ！

さて、今日から現場が変わりました。
今回のは入る前から大体現場の雰囲気が掴めてたので
特にグチる事もありません(笑)。

ただ、予想してた以上にショボいプロジェクトだったね。
まぁ素人達に作らせる訳だから仕方無い事なのか。
彼らに全部作らせていたら到底終わりそうにも無いので、
共通部分が僕が提供する形にしようとは思ってるんだけど。

--- 片手間 ---
今回、作成に携わるPGは全部で3人。
ただその内2人は、他のプロジェクト(テスト担当)も受け持ってるので
半分位の工数で計算してくれとの事。

その中途半端な考え方が腐ってるね。
今回は、彼らにプログラムを勉強させようという目的があるらしいのだが
だったらそれに集中する環境を与えてやれよ。
片手間で作ってロクなもんが出来る訳ねーっての。
プロジェクト掛け持ちするのはもっと能力が付いてから。

--- 電子マネー ---
現場のあるビルは、全ての施設で電子マネーが使える。
中には電子マネーしか使えない場所もあったりする。
例えばとあるメーカー直営店のゲーセンとか。

っていうか何で仕事中にゲーセン行ってるんだ、俺は(笑)。
というのも、現場の人と昼食べた後に
ちょっと寄ってこうと言われて行ったんだからしょうがない。
ここの現場の人は結構行ってるらしいね。随分自由な現場だこと。

ただ、予想通りシューティングゲームが無い。
STGの無いゲーセンなんて俺に言わせりゃゲーセンとは呼べないぜ。