ちょっと今日はやばい位に眠い。
それというのも、昨日放送するはずだったNFLの試合が今日に延びた為だ(ホントかよ)。
なんで野球の優勝祝杯ってのはあんな夜遅くにやるんだ。

あまりにも眠いんで、辺りを散歩。
広?い歩道が延々と続いてるから絶好の散歩地域だね、ここは。

--- やはり、と言うべきか ---
某H社から受け取ったサンプルのコンテンツがどうにも動かない。
が、向こうで動かしたときには正常に動作していた事は、うちのチームのメンバーが確認している。
ということは、こっちの環境周りがまずいということになる。

で、ひたすら調べる。
その結果、何のことはない。データベースのインポートで文字化けを起こしていた事が判明した。
この作業をやったのは……そう、あのオッサンである。
やはり、こういう人種は常に周りを不幸にしていくようだ。

--- 設計者 + プログラマ ---
一応今の現場では、僕とおせっかい君が設計を担当する事になっていた。
が、どうも彼の認識では彼が設計担当で僕がプログラム担当ということにしたいらしい。
まぁそれはいいんだけど、ここでも彼のおせっかいぶりが発揮される。

もともとプロトタイプが腐ってるので、これに色々手を加えないといけない。
彼が色々と修正内容を考えているらしいんだけど
それを僕に口頭で伝えられても困る。

彼が綿密に考えたものを、他人の僕がコーディングするなんて明らかに無駄だ。
そこまで詳細まで考えてあるのなら
それを彼がプログラムに起こすなんて大した手間にならないはずだ。

それを、彼としては設計とプログラマという2者に分けて開発をしたいという。
考えが古いというか、何というか…お互い設計できる能力があるのなら
絶対に両者で設計とコーディングの両方を担当した方がいい。

--- こちらも、やはり ---
というわけで、その部分は彼にコーディングを任せることにした。
が、そこで事態は発覚した。
おそらく、彼は一応プログラムの知識はあるが、ほとんどプログラムを組んだことが無い。
たかが十数行のプログラムを頼んだだけなのにやたらと時間が掛かるからおかしいと思ったんだ。

結局、彼はいわゆる典型的なSEなのだ。
設計ばかりをやっているからロクにコーディングも出来ない。
おそらくデバッグ作業なんてやった事が無いのだろう。

上から眺めてるだけじゃ、本質は決して理解できない。
理論だけじゃ、プログラムはきっとまともに動かない。
綺麗に整理された設計書があっても、
それがアプリケーションの質を向上させるなんて事は滅多に無い。

僕はあえて断言する。アプリケーションの質は、設計書の良し悪しと全く比例しない。
これを決定するものは唯一つ、プログラマの能力に他ならない。

--- 他の業界との違い ---
どんな業界でも、華は決まって設計者(デザイナー)だ。
それは、製品の良さがデザイナーの能力によってほぼ決まるからだろう。

設計図を見れば、どんな人間(もちろん一定以上のスキルを持った職人に限る)でも
製品を作ることが可能な業界もある。
それは、設計図⇔製品の関係がかなり密接に絡んでいるからだ。
少しでも設計図と違った製品を作ってしまえば、それは一目にして判断できてしまう。

でもソフトウェア業界はそうじゃない。
製品を見て(使って)も、設計は全くといいほど見えてこない。
設計は、膨大なプログラムソースを読み込んで初めて見えてくる。
同様に、設計があってもそれをプログラムソースに起こすには相当な手順を踏む必要がある。
だから基本／詳細設計というような区別がなされている。

でも、結局これも同じなのだ。基本設計→詳細設計も簡単にはいかないし
詳細設計→プログラムも一筋縄ではいかない。

--- 逆戻り ---
そして一番厄介なのは、これらの工程には必ずといっていいほど逆戻りが発生する事だ。
プログラムをしているときに、詳細設計を修正する必要が出てくる。ほぼ100％の確率で。
もし同じことを他の業界でやったら大変なことになる。

「先生(デザイナー)、ここちょっと難しいんでこう変えてもいいですか？」

マジでぶっとばされますな(笑)。
でも、ソフトウェアの世界ではこれが許される。というか、そうする事が自然なのだ。
何故かって？答は簡単。設計を変えても全く変わらない製品を作ることが可能だから。
出来上がるものが同じだったら、誰も文句は言わないだろう。
そしてこれは、開発効率を高める効果がある。だったら逆にしない方がおかしいと思わない？

--- これが自然 ---
そう、アプリケーションの設計は常に変化していく。
そしてこれは決して悪いことではなく、間違ったことでもない。

「実際にシステムを組まなければ、その設計を理解できることは決して無い」

前にも書いた、アジャイルの基本理念だ。
プログラムを作り込んでいくうちに、仕様が固まっていく。
仕様⇔プログラムは柔軟(Flexible)に変化し続けるのが、
ソフトウェアが他の分野と大きく異なる部分なのかもしれない。

--- 両者一体 ---
だから僕は、設計しかできない人間を認めないのだ。
プログラムを組めない設計者は、結局人数として数えられる程の働きが出来ない。
プログラマは、プログラムを組むのはもちろんだが
設計者が作った設計を十分に見直す必要がある。
それはさっきも言った通り、プログラムを組んでいけば
必ず設計のどこかに落ち度が見つかるからだ。

そして、プログラマは仕様を修正できる。
より開発のしやすい設計にする為に。
それは設計者には決して出来ない仕事だ。
綿密な思考の元に完璧な設計書を作り上げたつもりでも、所詮は絵に描いた餅。完成にはほど遠い。

優秀な設計者がプログラムを組めるように、優秀なプログラマは設計もできる。
両者を分けて考えるのは誰が何と言おうと間違った解釈だ。
結局、どちらも出来ないと良い製品は完成しない。

--- 論より証拠 ---
この業界も、論より証拠なのだ。
いくら理路整然と並べられた文書があっても、それが動いて初めて意味を成す。
完璧主義者では、この世界で決して通用しない。
こんな事言うと「前はデジタルには完全が存在するとか言ってたくせに」等の鋭いツッコミが入るかもしれない。

もちろん、100％完璧な仕様書があれば、それだけでプログラムは動く。
が、所詮は人間。100％なんて有り得ない。99.9％の出来では、プログラムは動かない可能性があるのだ。
逆に、50％程の出来でも動くプログラムも存在する。
そこらへんがやっぱり、人間の成せる技なんだろう。
より高きを目指しても、決して頂上に辿り着けないのは人生と一緒だ。
常に自分はミスをする可能性があるんだということを考えに置いとかないとエラい目に遭う。

--- 12 / 20 = ？ ---
ついに先が開けた。バスケットボールの田臥勇太が
NBAのナゲッツと契約を結んだというニュースが飛び込んできた。
野球、サッカーに続き、日本人がトップリーグで活躍できる可能性がまた増えた。

とはいっても、まだ現段階ではトレーニングキャンプに参加できる資格を得ただけ。
それすらも日本人としては初の快挙なのだが、これから先レギュラーシーズンで戦うためには
今いる20人のメンバーの中から12人のロースター枠に入らなければならない。

キャンプに参加しているのが20人だから、単純に計算すれば田臥にも6割の確立でチャンスがある。
が、実際はそうではない。既にレギュラーが確定しているメンバーも多数いる。
そして田臥には同ポジションに強力なライバルもいる。
現実は厳しいが、彼にはそれを何とかものにする力を期待してしまうね。

日本女子オープンゴルフをハイビジョンで見る。
この中継で使われている凄い技術がある。
その名も「ウルトラハイスピードカメラ」。

以前のスーパースローを遥かに超越した、超スロー映像を提供する。
スイングしたときのボールインパクトの瞬間をはっきり見ることが出来るのだ。
いやぁ、これは凄いね。
他にも色々な分野で使える技術なだけに、これからが楽しみだ。

--- 公開はいつ？ ---
何か暇なのでイース6の攻略ページなんかを作っている。
公開するかどうかは未定だけど、するとしてもしばらく先の事になるだろうね。
とりあえずはアイテムが埋まらないのでそこら辺を調査してからじゃないと。

前はあんな事書いたが、僕が好きな日本ファルコムだから評価が厳しくなっただけであって
絶対的には良い出来なんだよ、イース6は。

--- 久々の実家 ---
今週は実家帰ってのんびりしてました。
親父も定年になって9月からはこっちに戻ってきているようだ。
それにしても、いつの間にこんなに寒くなったんだ。
半袖で行ったら寒いの何のって。東京の方が気温が高いのかなぁ。

…と思ってたら、東京帰ってきてからも寒い。
もう秋ですなぁ。

なんか今日は休みだというのに一日中プログラムだ。
というのも、今の現場にいる人からちょっとした仕事を頼まれているのだ。

まぁ仕事といっても会社絡みじゃなく、どっかの学生が利用してるシステムを
IIS→Tomcatに移植してほしいという話。
現行を見たところ、大して骨の折れる作業でも無さそうなので引き受けることにした。
多少なりとも報酬はあるみたいだし。

今回はあまり時間が無いので、Strutsを導入するのは避けることにした。
まだStrutsでスイスイ作業が出来るほどは使いこなしてないからね。
とりあえず明日中に一部の機能だけに限定した試作版を作ってほしいそうなので
一昨日あたりから頑張っている。もう大体完成したかな。

--- 日本vsルーマニア ---
それにしても、このフジのサッカー実況者。何とかならんのか。
淡々とした口調で実況してるかと思えば、ちょっと日本がチャンスになっただけで
いきなり叫び出す。そのボリュームの差がデカすぎてうるさいのだ。
某TBSのゴールSEよりはマシかもしれないけど。

実況の口調も、ほぼお決まりパターン。
なんか聞いててつまんないどころか逆に耳障りだ。
もっとマシなのはおらんのか。
…で、試合結果は(笑)？

なんなんだ、この部屋は…外も充分寒いっていうのに
どうして冷房がこんなに効いてるんだ。
寒くてしゃーないぜ。

--- 身変わりの術？ ---
営業課ってのは変わったところだね。
電話で「私、○○(社名)の××(自分の名前)ですが…」と言ってるのだが
聞く度に○○の部分が変わってるのは何故だ。
まったくうさん臭い業種ですなぁ。

プロ野球。中日の来期監督が落合に決まったのは結構前の話。
これまでも数々の「落合語録」がマスコミなんかで取り立たされてきたが、
今回のはどうか。

「日本シリーズ観戦禁止令」

別に自己流を貫くのは構わんが、仮にも来年自分達が目指す戦いを
あえて見るなというのは訳がわからない。
「あくまで他人のやってる野球」というが、あんた以外は皆他人だろ。
もし来年、ダイエーと日本シリーズ争うことになったらどうするのさ。

僕の予想だと、彼は大した監督にはなれない気がするなぁ…
そろそろ日本でもコーチのスペシャリストを育てたらどうよ？
名選手≠名監督じゃないって事は既に立証済み。
プロ野球がさらに上を目指すには、そういった事もしていく必要があるよね。

--- 地震 ---
仕事中、かなり強い揺れ。
今ちょうどそういう関係の仕事してるから、通常以上に過敏に反応したりするのだ。

昨日行われたMLBのプレーオフ、ヤンキースvsレッドソックスの最終戦。
試合開始が午前9時過ぎからだったので、仕方無くビデオに録って後から見る。
今までの現場だったら間違い無く会社休んでたとこだけど(笑)、今回はそうはいかないのだ。
試合レポートを見たい人はここをクリック(おそらくIEしか機能しません) → Click



--- 久々の終電 ---
はい、レポート終了です(笑)。
昨日の夜は会社の飲み会(一応会議含む)に参加してました。
久々に終電で帰ってそのまま倒れ込むように寝てしまったので、今日の朝から試合観戦。
何とか試合結果を知らずに観れたので、生放送と同じ感覚で楽しめました。
ではでは。また今度。

いや、ホントです(笑)。
別にPGAの丸山とワールドシリーズの松井を見るために休んだわけじゃないんです(嘘つけ)。
でも結果的に、丸山の優勝も見れたし松井のホームランも見れたから良かった良かった。

--- タクシーで昼食 ---
先週の金曜、今行っている現場のオッサン…もとい部長が
僕ともう一人いる現場のメンバーを昼食に誘ってくれた。
彼は以前にも話をしたベトナムから来ている人材で、
今週いっぱい(つまり今日)で作業を終えて向こうに帰るらしい。

竹芝にあるビルまでタクシーで連行…もとい招待される。
そこの最上階にある中華レストランで食事。
メッチャ眺めが良い席で、このデブ…いや、オッサンも満足そうだ。

--- 個人契約 ---
まぁ誘われた段階で何かあるなとは思っていたけど、予想通りありました。
ベトナムの彼が来週から本国に戻って指揮を取るわけだけど、
僕にそこに常駐して欲しいという話。
前々からチラホラそんな話は出てたから、まぁそんなこったろうと思ってはいたけど。

海外にすら行ったことが無い僕がいきなりベトナムでの滞在生活を送るっていうのは
少々ムチャだ。もちろん断ったのだが、今度は別の話を振られる。
現在、「僕の会社→どっかの知らない誰か→今の現場」という3段階スライド方式(嘘)で
僕はこの現場で働いている。

当然、向こうがそれなりの金を払っていても僕の手元にくる額はわずかだ。
それで、個人契約を考える気は無いか、という話。

--- 時期尚早？ ---
確かに、僕にとってもその方がメリットはたくさんある。
給料も増えるし、今よりも大きな仕事に参加できる可能性も出てくるはずだ。
でも、正直まだフリーでやるには早いかな、という気もしている。

それに、一番大事な問題もある。僕自身、まだこの会社の技術力を把握できていない点だ。
オッサンの話だと、この会社にはいくつか支部があって
東京支部に技術者が少ないのが悩みらしい。
確かに、ここには技術者と呼べるような人物がいない。
別の支部ではそれなりに優秀な人材がいるという話だが、それを僕の目で確かめるまでは納得できない。

--- ひとまず… ---
というわけで、今の段階ではまだ現状を維持しようと思う。
これから先しばらくはこの現場で働く訳だし、その間にここの技術力を査定すればいい。
今の会社にはもう何の未練も無いから、いずれ動こうとは思ってたわけだし。
また何か動きがあったら逐次報告するんでヨロシク。

今回のプロジェクトは、元々H社(開発はn社)がVB/VCで作成したものを
Javaに移行しようというもの。
よくあるこの構図だが、これが会社として
どれだけの損害を出すかという事に何故気付かないんだろう。

「たかが移植なんだから簡単でしょ？」
こんな声が聞こえてきそうだ(おそらく営業サイド)。
甘い、甘すぎるぜ。その考え。

--- 逆作業 ---
もちろん、移植元のアプリケーションに詳細な設計書があれば話は別だ。
だがそんなものは所詮夢物語。
移植するには、元のソースを読み崩し仕様書を書き上げ
それを元に新アプリケーションを作成しなければならない。

不思議に思う人もいるかもしれない。
「作った本人だったら大体の仕様くらい頭の中に入っているんじゃないの？」
確かにその通りだ。

--- 逃げる奴ら ---
だが現実は厳しかった。
大抵の場合、移植元と移植先は別会社だ。
なぜこんな事が起きるか？移植元はもう二度とこんな汚いプログラムを見たくないからだ。

手が付けられない位に肥大化したプログラムと適当過ぎる仕様書を
移植先に手渡したら、奴らの仕事は完了だ。
「わからない事があったらソースを見て下さい」これが奴らの逃げ道だ。

--- 今回の場合 ---
今回は、幸い移植前の汚いソースを僕たちが見ることはなかった。
数種類のコンテンツに絞って奴ら(H社)がJavaでプロトタイプを作ってくれたからだ。
だが、これももちろん相当に汚いプログラムになっていた事は言うまでもない。

--- 次なる理由 ---
そして、移植を困難にする最大の理由がある。
依頼主は、単なる移植では満足しない。
当然だ。これまで長年そのシステムを使ってきたのだから不満も色々ある事だろう。
そして、追加機能と称された様々な機能を付加したアプリケーションを作らせようとする。
これが、破滅の前兆だ。

--- ＋α？ ---
それらの追加機能を足していった結果、出来上がるアプリケーションは
もはや移植品では無くなってしまう。
それなのに、開発者は移植元のプログラムにあれこれ手を加えて
強引にアプリケーションを仕上げようとする。

ただでさえ汚いプログラムにこれ以上手を加えたらどうなるか。
誰でも判るだろう。

--- 他人任せ ---
最良の選択肢は、このアプリケーションを新規のプロジェクトとして始めることだった。
最終的な納品期間を考えたら、必ずこの方法をとった方が成功する。
だが頭の回らない奴らはそれに気付かず、あくまでも元のプログラムを修正しようとする。

もっとも、これにも原因がある。
1からプログラムを作って成功する自信が無いからだ。
どこかに逃げ道を作っておかないと不安でしょうがない。
何千万払って買ったOracleのサポートに逃げようとする奴らもこれと同じ。
他人に頼ってばかりいるから、いざという時の自力がいつまで経っても付かないのだ。

--- 逃げ会社 ---
この現場もそうだ。
開発は外部に振る事で、自分達にリスクが無いような形態を取る。
仕様決めで納期に追われるという事は少ないが、
開発が遅れて納期に間に合わない事実があることを知っているからね。

--- 第2ステップ ---
いよいよ今週からベトナム部隊による開発がスタートする。
とはいってもまずは環境構築や仕様理解から入るわけだから
実際の開発は来週以降になるはず。

既に決まってしまった事だが、このプロジェクトは間違い無く成功しない。
とにかく、仕様がまるで決まっていないのだ。
今動いている現物があるのに仕様が決まらないというのも滑稽な話だが、
これが本当なんだからしょうがない。

--- 競争？ ---
依頼主であるK社内部が複数に分かれているらしく、
今あるコンテンツは別の部署が担当して作っているから
資料が無いというとんでもない話。

会社内で資産を競争し合ってたら会社が成長するはずないでしょ。金も掛かるし。
社員同士が切磋琢磨して競争するのとは全く違う話だ。
お前らみたいな企業がいたら日本が不況なのも頷けるよ、まったく。

--- 信頼のための資格？ ---
今回のプロトを作ったのはH社ということは前に話したが、実際の開発は完全に別会社。
n社という会社らしいので早速調べてみた。
会社概要にこんな文章があった。

SI認定、ISO9001、プライバシーマーク…
こういった資格や認証を取得することで客の信頼を得ようというのが奴らの考えらしい。
が、現実はどうだ。構造化されていないプログラム、無駄だらけのクラス群。
これだから僕は資格が嫌いなんだ。こんなもの、全くアテにできない。

信頼を得るために唯一必要なことは、相手の要件を形にして
確実に納期を守り、それを遂行するだけのスキルを磨くことだ。

--- 浪費家 ---
さっきからず?っと電話で打合せかなんかをしている人間がいる。
何を隠そう、うちのメンバーである。
そんな事いくらしても全くシステムは完成に近づきませんぜぇ。

とにかくここは作品を完成させる為に何が必要なのかを理解した人間がいない。
「?だそうですよ」「?らしいです」こんな会話が続く。
プログラム全く見てないお前がどうしてそんな適当な意見出せるのさ。

--- 販売系 ---
とりあえず、この会社は販売系ということもあって
金銭中心の動きになってるから
来年の3月まではこのままダラダラ行きそうだ。

そう、こいつらにとって作品を完成させる事などハナから考えちゃいないのだ。
こういうのと居ると俺の職人魂が消えかかりそうで嫌になる。
いずれは見切りを付けることも考えなきゃね。

--- テキストベース ---
僕は昔から、出来る限りテキストベースの作業をするようにしている。
確かに昔はそれしか手段がなかったから自然とそうなったのかもしれないけど、
世の中に蔓延するGUI文書の使いにくさは依然として変わらない。

なぜ使いにくいのか。
それはExcelやWordが専用のファイル形式を取っているからだ。
つまり、これらのソフトを使わないと閲覧・編集することが出来ない。

--- ドキュメントの特性 ---
これだと、色々な場面で困ることがある。
Unix上での利用が不可能ということもあるが、それ以上に大変なのが保守の面だ。
ドキュメントというのは、常日頃変わっていくものだ。
尚、この事実を受け止めていない現場はもはや論外とする。

そして時に、ドキュメントの修正は一括処理を必要とする。
こういった時、テキストベースでない事はかなりのデメリットになるのだ。

「Excelのマクロ使えばいいじゃない」
という声が聞こえてきそうなので、ここで一言。
あんなクズみたいな言語使えるか！
ふぅ。気が済みました(笑)。

--- 自動化 ---
Excelマクロは、VisualBasicという世にも恐しい言語で構成されている。
はっきり言ってこんな言語、時代遅れにも程がある位に使いにくい。
それに引き換え、テキストベースならば自分の好きな方法で修正できる。

スクリプト言語を使うのが一般的だが、CやJava等を使ってもいいし
もちろんVBを使っても可能だ。
当然俺はここでRubyを推しておく(笑)。

--- テキストの柔軟性 ---
「でも、テキストベースじゃ見栄えが悪いでしょ」
何を言いますか。何にでも変換できるのがテキストの柔軟なところ。
ここは一つ、LaTeXでも使って製版レベルの印刷をしてあげましょう。
Windows上ならば、Text⇔LaTeX⇔pdfが自由自在に変換できます。

とにかく、開発者なら効率重視。
テキストベースの作業を心掛けた方が後々絶対有利ですぞ。
依頼主への提出物なんかはExcelやWordでないとダメな事が多いので、
こういうのは最後にササッと仕上げましょう。

--- 情報不足 ---
なんかまた暇になったので、LaTeXについて調べ始めてみる。
が、圧倒的に情報量が少ない。文献の紹介は山ほどされているのに
Web上の情報はごくわずか。ろくなリファレンスすら無いのは痛いね。

英語圏で探すしかないのかなぁ…
これじゃ普及しないのも判るね。わざわざ本買ってまで覚える気にはなれない。
というか、それじゃ仕事中にできないじゃん(笑)。

--- Yahoo!メッセンジャー ---
今、ベトナムにいっている彼とのやりとりをするのに
Yahoo!メッセンジャーを使っている。
こういうのには手を出すまいと思っていたが、仕事だからしょうがない。

まぁ便利だよね、こういうのがあると。チャットより反応速いし。
ただ、こんなので仕事の会話してていいのかっていう疑問はある。
簡単に盗聴されちゃう訳だし。
まぁそんな事をしてるのは暇人くらいだろうから気にすることも無いか。

弟がやってるバンドでホームページを作りたいらしいので
昨日色々とアドバイスをした。
掲示板や日記は携帯から使いたいらしいのでレンタルを探したらすぐに見つかった。
いずれはうちの日記も携帯からアクセスできるようにしないとね…

--- 現在の結論 ---
現場でEJBを使っていることもあってか、最近は家でもちょこちょこEJBをやっている。
色々やってみたが、やはり僕はこの結論に達した。

「EJBを導入するメリットは無い」

分散等が必要な大規模なプロジェクトでない限り、今のところ
EJBを導入することによるメリットは見当らない。
結局、記述するコード量は今までのやり方と大差無いように思える。
それでいてスピードは明らかに遅くなる訳だから、
まだまだEJBは魅力ある規格とはなっていないようだ。

今日からバレーボールのワールドカップが始まった。
4年に一度のW杯。そして今回のメンバー、前回のW杯メンバーが何と一人もいない。
しかも、スターターの内2人がまだ19歳。明らかに、今までの全日本とは異なっている。

正直、今日僕はこのメンバーを見て少し不安だった。
国際経験の少ない10代を起用する事が、無謀に思えて仕方無かった。

--- 今の全日本 ---
でも、その不安は第1セットで簡単に吹き飛んだ。
左サイド、通称「エース」と呼ばれるポジションに着いた二人の19歳は輝いていた。
彼女達中心にゲームが展開していく。
両センターよりも高い186,187cmという身長を武器に次々とスパイクを決める。

これが、今の全日本なんだ。
小さいエースが必死に頑張っていた過去のチームとは違う。
日本が長い間待ち望んできた「大砲」が一挙に二人も入ったことで
世界と同等に戦える高さが揃ったんだ。
今大会、12チーム中上位3チームまでに与えられるアテネへの出場権。
確かに厳しい条件だけど、これを狙えるだけの力を期待できるのが今のチームだと思う。

--- Eclipse Plugin ---
最近少し手を出し始めたのがこれ。
総合環境Eclipseは、自分で好きなプラグインを作れるのが特徴。
資料が少ないから結構苦労してるけど、まぁ暇だからいいのだ(ぉい)。
これやってると時間潰せるしね。