なんかこの現場 - というかうちのチーム - は最近ひどい。
まず、チーム構成を説明しておくと。
僕も入れて全部で5人。

まずは社員SE。彼はどこにでもいる典型的な社内SEだ。
当然の如く仕事は全く出来ない。明らかに戦力外。
周りもそれを知ってるから、彼への風当たりは冷たい。
最近では別チームの人間に仕事をせかされて大変らしい。
聞こえてくるのは溜め息ばかり。
一応チームリーダーというポジションなのかな。

--- ここにも遅刻王が ---
続く2人(男女)。二人はいつも一緒。
恋人同士かもしれんが、それにしては会話がよそよそしい感じがする。
まぁそんな事は置いといて。
この二人、朝必ずといっていい程遅刻してくる。
二人とも揃うことはまず無い。

最後の一人は、性格は普通だけど力量が…って感じ。
スケジュール通りに作業が進んでいないらしく、
リーダーに仕事をせかされている。ん？この構図どっかで見たな(笑)。
「○○君(僕)に置いていかれちゃうよ?」って、かわいそうにねぇ。
僕と比べるってのも正直どうかと思うけど。

--- そろそろ… ---
っと、あんまり詳細に書いちゃうとバレたときアレなんでこの辺で。
ここのメンバーにアドレス教えるつもりは無いから
大丈夫だとは思うけどね。

--- 強靭な精神力 ---
今日の夕方、僕はトイレで個室に入っていた(失礼)。
すると、同じく個室から出てきた人間が洗面台のところで何やらボソボソ呟いている。
何を言ってんのかなぁ、と耳を澄ましてみると。


笑いをこらえるのに必死でした(笑)。
しかもこのフレーズをヒソヒソ声で繰り返し呟き続けている。溜め息交じりで。
一体彼は誰なのだろう。
同じフロアの人間なのか？
が、それを確かめるわけにも行かず、ただ黙って笑いをこらえる。

しばらくして彼は出ていった。
「強靭な精神力」というフレーズが今も頭から離れない(笑)。

なんか今週は急にやることが増えた。
もちろん現場は暇ですが(笑)。

以前にも話した内職を進められる段階になったので
昨日からひたすら作業。
ようやく形になるところまで出来上がった。

--- 新PC ---
頼んでいたPCが届いたので、OSをインストールすることにする。
色々悩んだ結果、今回は SuSE Linux というものを使ってみることにした。
Novell 社が出しているLinuxで、技術的な評価は高いらしい。
MySQLが薦めていたのが導入のきっかけ。

ネットワークインストールをしようとしたのだが、
どうもネットワークデバイスを認識しないようなので
DVDインストールをすることにする。
PCと一緒にDVDドライブ(書き込み可能)を買ったので、これに焼くことにしよう。

っと、大事なことを忘れていた。
まだDVDイメージをダウンロードしていなかった。
ファイルサイズが3Gもあるので、ダウンロード終わるのは明日になるなぁ。

ようやく新マシンへのOSインストールも完了。
ただ、すぐにサーバ置き換える必要も無いんだよなぁ。
今のままでも別に足りてるから。

だったら何でマシン買ったんだって話もあるが。
衝動買いに近いかも。
でも流石に新マシンは速いね。

とりあえず今は内職の方を進めよう。
まっ、明日はスーパーボウルなのでお休みする事は既に決まってますが(笑)。

なんかここの現場では最近風邪が流行ってるらしい。
そのせいか休んでる人も何人かいる。
まぁ中には俺のように、それに便乗して休んでる輩もいるとは思うけど。

--- 仕事0 ---
ほんっとにやる事が無いんです。
仕方無いのでネタ探し。
hibernate というデータベース・マッピングツールがある。

とにかくデータベース関連のクラスというのは
Javaの中でも最も再利用性の低いもの。
それをどうやって効率良く作成するかというのは
なかなか重要なテーマでもある。

--- 自作vs普及品 ---
家で使ってるプロジェクトでは、
僕はこれらを独自に作ったパッケージを使って実装している。

もちろんこれも良いのだが、
これらのパッケージは仕事(趣味以外)では使えないという欠点がある。
パッケージ名を変えて現場に持ち込むことは可能だけど
出来る限りそういう事はしたくない。

だから、出来る限り普及品を使うというのは大事なこと。
仕事受ける上でのアピールにもなるしね。
自作モジュールの宣伝を面接でするわけにはいかないのだ。
もちろん、使ってみて良いと感じたものに限るけどね。

前にも話したけど、今の現場は正にこの反対の道をつき進んでいる。
出来る限り自作モジュールを使っていて
しかもそれが普及品と比べても遥かに使いにくい。
作るのに多大な時間を割き、さらにそれを使うことでそれ以上の時間を無駄にしているのだ。

--- hibernate ---
そんな話はさておき。この hibernate。
まだ少し使ってみただけだが、なかなか使えるという印象を受けた。
そして何より、JBossが正式にバンドルしているという事は
今後EJB開発が増える時代に向けて仕事上でも有利になってくるはず。

いち早くJDK5の拡張Annotationに対応しているのも嬉しい。
あと2年もしないうちに、間違いなくJDK5は開発の主流になる。
なぜなら、その方が圧倒的に開発の質が上がるからだ。

僕は家でJDK5を使い始めて半年くらいになるけど
互換性などの問題も全く無い。
JDK5はもう仕事で使えるレベルの安定性を備えているのだ。

--- いよいよ… ---
普段サッカーにはそれほど興味が無い僕も、
今日の試合は注目している。
W杯最終予選の初戦。相手はあのにっくき(？)北朝鮮。

最近の日本チームを見てる限りそれほど心配はしてないけど。
一発勝負ではなく全6戦によるポイント制とはいえ、
そんあ余裕を見せられないのがこの戦いの怖いところ。
日本も以前痛い目に遭ってるからね。
それを目に焼き付けてる世代のメンバーだからその点については心配してない。

19:30キックオフだから、定時上がりで十分間に合うってのも嬉しいね。

--- 予想外の苦戦 ---
…いやぁ、苦しい戦いだった。
まぁ何にせよ、日本が勝利。
今後もこんな苦しい試合が続くのかな。

プログラムを組んでいると、
局所的に特殊な処理が必要な場面というのは意外に多くある。

プログラムを組むだけなら、それなりに出来る人はいる。
しかし、この特殊な場面を乗り切れるような人材が
業界にはまだまだ少ない。
それこそ、プログラマの経験によって培われるものであり
最も重要な要素だというのに。

--- フレームワークの危険性 ---
僕が常日頃フレームワークを嫌う発言をしているのは
これらを使っていると、こうした事態に対処できないからだ。
どんなに良く出来た枠組みが用意されていても
必ずその枠を外れる場面がプロジェクトには何回も訪れる。

フレームワーク使いは、この局面を打開できない。
日頃、与えられたものをただ使っているだけだからだ。
これらの局面を打開するには、日頃からアプリケーションの内部にまで
神経を行き届かせている必要がある。

--- 資格の危険性 ---
そういう点から見れば、資格も同じようなことが言える。
資格の試験には、
主題者が想定するようなごく一般的な状況への対処しか載せようがない。

しかし、本当に真価が問われるのは
特定のプロジェクトに強く依存した特殊な場面なのだ。
これらの問題を解決できるかどうか、それは試験では決して判断できない。

--- 発展途上 ---
上で話したことは、もしかしたらあと10年もすれば
成立しないかもしれない。

フレームワークも日々進化している。
本当に、例外的な事が何一つ起きないような優れたフレームワークが
現れるかもしれない。
もしかしたら、僕がそのフレームワークを作ってるかもしれない。

--- 3連休 ---
ちなみに僕は先週も3連休でした(笑)。
今年は3連休の多い年らしいね。

あ、ちなみにゴルフです(笑)。
各国代表ペアで勝負を争う。今年から始まった文字通りの世界戦。

宮里・北田のペアが現在1位タイ。
明日の最終日に向けて最高のポジションにいる。

もちろん北田さんも頑張っているけど、やっぱり宮里藍。
彼女は間違い無く世界で戦える力を備えている。
今まで女子選手の海外進出はあまり無かったけど、
彼女には是非世界に挑戦して欲しいよね。
日本では無敵の強さを誇る不動さんは今回も出場していないし。

--- 2月 ---
なんか2月は寒いね。当たり前のことだけど。
ちょっと外出るだけで寒さが身にしみる。
部屋にいると外の寒さがわからないからなぁ。

内職もとりあえず終わったので、今週はのんびりしてみるか。
酒でも飲みながら(結局それか)。

いやぁ、やりましたよ。
宮里・北田の日本チームが見事優勝。

お互いのスコアが直接結果に結び付く最終日、
両者の出来は正に両極端なものになった。
宮里が6アンダー。対する北田は9オーバー。

北田さんも、自分がこれだけ悪い結果なのにトップを守っていることが
逆にプレッシャーになってたみたい。
後半一気に崩れて、今にも泣き出しそうな彼女が
最後の最後で決めた意地のバーディ。
あのシーンは良かったね。

--- 必要なドキュメント ---
とかくドキュメントというと成果物に過ぎないというイメージがあるけど
僕らみたいな開発者にとって本当に必要なのはそういったドキュメントではない。

メソッドの処理概要や使い方を示したJavadoc、
コード中に埋め込まれた適切なドキュメント。
これがあると無いのとでは、他人が作成したソースを解読し修正していく作業に
大きな差が生まれてくる。

--- 第3者 ---
が、仮にこれらのドキュメントが記述されていても
何の役にも立たない事が多い。
それが、第3者が読むという事を前提に置いていない文章だ。
コピペで貼り付けられそのままにされたコメントなどはもはや問題外とする。

コメントは、コードを見てもそれが何をしているのか
瞬時に判断できない場面に適切に記されるべきだ。
他人が見て理解できないようなコメントなら、書くだけ無駄だ。
さらに、間違ったコメント(処理内容)でも書こうもんなら
それはゼロを通り越してマイナスの要因となってしまう。

--- 最も大事なこと ---
適切なコメントを書くよりも、もっと大事なことがある。
それが、適切なコードを書くことだ。
わかりやすいコードを書いていれば、コメントを書く量も減る。
コードを一目見てわからない部分にコメントを付けるのだから、当然とも言える。

--- 現実 ---
なぜ今回こんな事をテーマにしたかというと。
…そう、現実はそう甘くないのです。
オブジェクト指向のカケラも無いコードが羅列され、
意味の無いコメントがコードを汚す。

それが最終的な品質の低下につながってるんだから、
もう少し真面目に取り組んでほしいもんである。

--- 昭和の風習 ---
ホントさぁ、彼女達も好きでやってる訳じゃないとは思うけど。
義理チョコなんか貰っても嬉しくないどころか
迷惑になることだってあるっての、わかってる？

まぁ当然相手にもよるけどさ。
結局来月にはお返ししなきゃいけないし、面倒臭いことさせないでほしい。
しかも俺は甘いものが苦手だ。

そろそろこの腐った風習を無くしたらどうだろう。
本命の方は貰った側も嬉しいだろうから、無くす必要は無いとは思うけど。

やべ、今日はメチャクチャ腹が痛いぞ。

原因はわかってる。
昨日の夜、ついうっかり食べてしまったチョコレートに間違い無い。
生タイプっていうの？
あれはどうも俺の身体が受け付けないようだ。

--- 社長？ ---
今日の昼、今の会社の社長が現場まで遊びに(嘘)来た。

なんか知らんが、僕に付く営業はいつも頼りないのが多い。
この前も色々あって、とりあえず会社の方に伝えておくかと思ったのだが
僕が社内で知ってる人って言ったら営業と社長しかいない。
で、仕方無く社長にメールを出したら
今日の昼食をセッティングしてくれたというわけ。

それにしても、うちの社長はホント腰が低いな。
別に卑屈なって感じじゃないので気にはしないけど。
そういや前の会社の社長も似たような感じだったかも。
営業も変えてくれることになった。

--- 事業家へのススメ ---
で、今後の展望なんかを振られる。
彼は僕に将来事業家になってほしいという。

自分で受注をとり、必要なメンバーを揃えて開発を請け負う。
そういう職に付けば、山のような財産が入ってくるらしいが。
だけど、前から言っているように
僕としてはまだ技術の現場を離れるつもりはない。
自分が満足した作品を手掛けて市場に送り込むまではね。

--- Javaだから？ ---
現場で暇だと言うと、「Javaなのに珍しいねぇ」だって。
ホントよくこういう声を聞く。
Javaの現場には他の現場と比べて素人が多い率が高いんだろうね。
だからどこの現場も忙しい。

ここの現場も、一部の人間は忙しくしてるよ。
僕の見たところ、約1割は激忙、約3割は普通。
残りの6割は暇してそうだね。
忙しい人間の大半はピラミッドの上位にいる。
つまり、下に適切に仕事を振れてないという事だ。
仕事振るのだって、それなりの能力が要るんだぜ。

--- レビュー ---
今日は午後からレビューがあった。
社内の偉い人を集めて、今作ってるシステムの実演会。

その後、その偉い人に簡単な状況報告。
本当のこと(超暇で?すetc.)言ってやっても良いのだが、そんな事しても
どうにもならない事はわかっているので面倒事は避けた方がいい。
特に問題は無いと言っておく。

レビューは2時間くらい掛かる…疲れたぁ。
でもちょうど終わったら定時だったからキリ良く帰れたよ(笑)。

ふぅ、今日も疲れました。
いくら慣れてるとはいえ、こんなに暇なのは久しぶりかも。
そろそろ次のネタを探さんとマジでやばい。
仕事行く気がしなくなってくるぞ。

にしても今日は寒かったね。雨だし。

なんか現場でまたトラブルが起きたらしい。
「また」っていうのも、先週もそんな事があったから。
月曜はいつも全体朝礼があるんだけど、そこでのトラブル報告。
システムがダウンした模様。
まぁ当然のように現場は大慌てなわけだが。

--- 意味の無い対策 ---
今回システムが落ちたのは、データベース関連。
接続数が350を超えたんだって。

1分間に200回程度の不正アクセスがあったらしい。
…数が合わんな。どうも嘘くさい。ちゃんと調査してんの？

大体、接続数が一時的にオーバーしたくらいで
何でサーバがダウンするんだ。
Oracle側に原因があるとみた。

--- 被害はこちらまで… ---
このトラブルのせいで、全く関連の無いこちらまで被害が及ぶことになった。
こちらで作っているシステムの機能テストを強化するらしい。
まったく、奴らはどこまで見当違いの事をやれば気が済むんだろう。

というわけで、今日からはしばらくテスターです。
まっ、おそらくロクでもないテスト表なのは目に見えてるので
これによって品質が上がる事なんて無いんだけどね。

--- 絶対？ ---
何やら隣でモメている。2人の会話。

「ここを修正すれば、他に影響は出ませんよ」
「絶対？絶対に影響無い？絶対？」

あぁウゼェな。
絶対だとして、それが一体何になるというのか。
なぜ彼はそんなに「絶対」を必要とするのだろう。
ちょっと推測してみよう。

--- 勝手に推測 ---
・その1
その意見を撤回させようと思っている。
「絶対」を繰り返すことで相手に不安感を募らせようという作戦。

・その2
その意見が間違っていたときに、自分が優位に立つため。
「それ見たことか。絶対って言ってたくせに」

--- 結論 ---
まぁどちらにしても、彼は頭の良い人間ではないという事だ。
世の中に「絶対」なんて事、そうそう無いんだから。

明日地球が滅亡しないって事を、絶対だってアナタは言い切れますか？

ましてや、不確定要素の多い開発現場で
こんな事を口走る奴の気が知れない。
ヘッドコーチは常に、最悪の状況を想定していなければいけないのだ。
…って誰がヘッドコーチですか(笑)。

--- 否日本語 ---
さて、今日は少し仕事でもするか。
ここ2週間位、平均稼働率5％くらいだったからな。

…テスト表に書いてある文章の意味がわかんねぇ。
どうして出来ない奴ってのは日本語も下手なんだろ。
おそらく自分でも何書いてるか理解してないんだろうね。

--- 久々のC ---
いや、別に下ネタじゃありません(笑)。
しばらくC言語のソースなんて見る機会無かったんだけど、
ちょっと暇だったんでとあるライブラリのソースをボーッっと眺めていた。

やはり、Cのソースってのは尋常じゃないくらい読みにくいね。
たった500行足らずのプログラムを読み砕くのに余裕で1時間以上は掛かる。
別に大した事はやってないのにね。
今さらながら、Javaの開発効率は非常に高いという事を認識した。

せっかくなんで、これをJavaに移植してみようかと思う。
ただし途中で飽きなければ。
大体こういうのって未完成のまま止めちゃうんだよね。

なんか今日は非常に現場が荒れております。
昨日のトラブルが原因だろうね。
それをハタから眺めて楽しんでる不謹慎な俺。

--- 前フリ ---
前フリの長い人間ってのは困る。
なかなか本題に行こうとしない。
開発現場においてもこういう輩がいるんだ。

今日の夕方、例のライブラリJava化計画を一生懸命(笑)していたところ
修正依頼があった。
こっちとしては、細かい説明なんかどうでもいいんだ。
知りたいのは「どうしてほしいか」という要望だけ。

あまりにも遠回りが過ぎるんで僕の方から用件を聞き出す。
「で、何がしたいの？」と。
聞いてみれば大したことはない、画面のレイアウト修正だった。
なんでこんな事の説明に延々と時間割く必要があるんだよ。
時間の無駄ってもん。

--- 貸し出し ---
定時の30分前になって、突然の会議。
あのなぁ、そういう事はもっと早く言えよ。
ホントここのリーダーは出来損ない君だ。

今、現場では2つのチームが動いている。
プロジェクト自体は同じなんだけど、
システム的には完全に分割された作りになっていて
基本的に別々の流れで作業をしている。
が、このチームの進行が大幅に遅れているとの事。

さらに、先日の不祥事のせいで品質管理部隊までも出来たようだ。
っていってもまだ一人しかいないらしいけど(笑)。
その部隊に、僕らのチームから一人を貸し出すことになったらしい。
当然のように、最も必要の無いであろう(リーダーを除いて)人物が選ばれた。
正直、彼女がいなくなったところでうちらのチームには何の損害も無いはずだ。

--- さらに忙しく？ ---
一応、チームからメンバーが抜けるわけだから
会議には現場の偉い人も同席していた。

「今後は今まで以上に忙しくなるだろうけど…」

あらあら、このお偉いさんもかわいそうに。
やっぱりこの現実を教えてあげた方がいいのかな、と思い
今回は珍しく言ってみることにした。
僕のこの暇っぷり状況を。

--- 結局… ---
これで何かが変わればいいけど、かなり高い確立でそうはならないんだよね。現実問題として。
結局、あのお荷物リーダー君が仕事の割り振り役である以上
彼の能力を超えてチームの進捗が上がる事など有りえないのだ。

僕がよっぽどのおせっかいで無い限りね。
例えば、リーダーは放っておいてもっと上の人間に直接仕事をもらいに行くとか。
でも、そんな事してまでこのプロジェクトに貢献しようなんて気には到底なれない。
それよりも、自分のスキル磨いてた方がよっぽどタメになるからね。

--- フェイズ2 ---
よくこの業界で聞かれる言葉がある。
それがこの、フェイズ(Phase)という単語。
プロジェクトが長期に渡る場合、一定の区切りを設けて
段階(Phase)的に製品を作っていこうという考え方だ。

今の段階はフェイズ1。
そして2月末に一旦リリース(一般向け発表みたいなもの)があって
それからフェイズ2へと進んでいく。

--- 即刻破綻 ---
が、早くもこのスケジュールは崩れ掛かっている。
まず、2月末のリリースは無し。
理由は先程も話したように、別チームの進行が遅れてるから。

その代わりに、フェイズ2の期間を大幅に縮める(早める)ことになったようだ。
本来4月末以降だったはずが、3月末なんて話も出ているらしい。
早速来週からフェイズ2の開発がスタートする。
…ってことは、今週あと3日はまた放置プレーですか(笑)。

昨日の件もあり、リーダーが仕事を持ってきてくれた。
Linuxでの環境構築だから楽チンだね。

これでサーバマシンに自由に入れるようになった。
予想通り、必要最低限の環境しか整っていないのでまずはそこから整備。
emacsくらい入れとけっちゅーの。
何で今どきviで作業せにゃあかんのだ。

--- 環境構築 ---
僕はLinux環境にいつも必ず入れるものがいくつかある。
仮想スクリーン機能の screen。
エディタの emacs。
そして高機能シェルの zsh。
これさえあれば大抵の作業効率は格段に上がる。

最近のLinuxはscreenが標準パッケージに入ってるから
残りの2つを手でインストールすることに。
が、zshのコンパイルが通らない。
ここのLinuxはTurboLinuxなのでそれが原因かな。
こんな状況のままじゃ、当分の間主流はRedHatに安泰だろうな。

--- 突っ込み所満載 ---
夕方に会議。
この前話したように、現場は来週からフェイズ2という段階に突入する。
それに向けてのスケジュール調整だ。

簡単なタスク(作業)一覧を挙げて、それに掛かる工数を割り出していく。
が、案の定「漏れ」が山ほどある。
それでもこいつ(リーダー)は言う。
「とりあえず、大体で工数出してみよう」

こいつらは何度言ったらわかるんだ。
「大体」で工数出すことの愚かさを。
何度となくそれで失敗してるのにまだ懲りないのか？

--- 味方 ---
メンバーの一人もそこら辺はよくわかっていて、
この事については僕と同意見のようだ。
もう一人の彼は寡黙で何も言わないが、おそらく賛成のはず。
これでリーダーは孤立無縁状態だ。へへ、ざまーないぜ。

しかもこいつ、何故か自分の作業の工数を出そうとしない。
とある作業の箇所を尋ねてみると…
「そこは僕担当なんで、こっち(俺らの担当箇所)の工数だけを出してくれれば良いです」

理由はバレバレだけどな。自分の作業の工数を出す自信が無いのだ。
おそらく、正直に数値を出したらとても期間内には終わらないような数値が出てしまうのだろう。
だからそれを避け、いかにして逃げながら生きていくかを考えている。

--- 現実的に ---
まぁそんなわけで、現実的なスケジュールを組むべく調整。
彼が出来ないのなら、僕らに振ってくれればいい。
幸い、僕は暇をもて余しているからね。

周りへの建前か、それとも自分へのプライドか。
理由はともあれ、なかなかメンバーに残作業を振らないリーダーは多い。
だからプロジェクトが破綻するんだよ。
何のために俺ら外注を雇ってるんだ。

メンバーに強引にでも作業を振ればいい。鬼と言われようが。
そうしないと、メンバーの力量が見えてこない。
毎日残業をしているようだったら、おそらく彼には負担が大きい。
いつも定時で帰ってるようなら、まだまだ余力があるはず。

作業が終わらないようだったら、その段階で別の手段を考えればいい。
こうすれば無駄が無いでしょ？
奴らの発想はまったくもって逆なのだ。

今日は現場のチームで飲み(食事？)に行くらしい。
その幹事を任されたのが、おなじみ某リーダー。

やはりというべきか、当日なのに場所も時間も何の連絡も無い。
隣の人に聞いてみると、彼もやはり不審に思っていたらしく
さきほど直接リーダーに聞いたらしい。

で、その結果がまたひどい。
開始時間が7時半って…おい。遅すぎんぞ。
なんでわざわざ作業のトロいてめぇの為に1時間も残業せにゃあかんのだ。
もう帰りたいよ。

昨日は結局、予定時間より1時間近く遅れて飲み会がスタート。
まったくさぁ、時間決めたらその時間に来いよ。
仕事長引いてるのか何なのか知らんが。
こういうときに遅れてくる奴ってのは大抵仕事でもそうなんだよね。

--- 内部紛争勃発 ---
相変らず、もう一つあるチームの進行状況は思わしくないようだ。
そのせいで、うちのチームにまで影響が及んでいる。
その事をあまり良く思っていないメンバーもいて、
飲み会はお偉いさんと彼とのトークバトル(？)となっていた。

正直、僕からとってみればそんな事どうでもいいんだけどね。
他の人間がどうなっていようとも。
大体、そういう心配するのは現場のリーダーやお偉いさん達だけで充分だろ。

それをハタから眺めてる、僕ともう一人。
彼も僕と同じタイプ。飲み会で仕事の話するなんて論外だってね。
もっとも、それだけ彼らが仕事に熱心だっていう証拠でもあるんだけど。

--- ほぼ不明瞭 ---
さて、ここからは今日の話。
今後のスケジュール調整について打合せがあった。
が、予想通りほとんどが不明瞭なまま。
今のままじゃ間違いなく、リーダーの作業が終わらなくて
他の人間は待ちぼうけをくらうだろう。

僕のほうはかなり余裕がありそうなので、
仕方無く彼に助け船を出してやることにする。
作業が終わらないようだったら僕の方で引き受ける事になった。
当然、これは彼を助けようという気持ちではなく
単に僕が暇になるのが嫌だっていう理由に過ぎないんだけど。

--- 引き際 ---
今回、僕がこの現場と結んだ契約は3月末まで。
が、スケジュールの区切りからいってその時期に抜けるのは難しいかもしれない。
今のフェイズが終了するのが4月以降に延びそうだからね。

だからといって、このままズルズル行ったんでは
いつまでも抜けられなくなることは目に見えてるので
キリのいいところで辞める決断が必要だ。
今の会社の人はそこら辺キッチリしてるので、あまり心配はしてないけどね。

昨日は珍しく外で飲み。
まぁメンバー的にはいつもと一緒。

普段は地元に帰った時に飲んでるんだけど
それだとなかなか集まる機会も少ないからね。
今回は都内で集まろうということになった。

たまにはこういうのもいいよね。
やっぱ酒はうまい料理と一緒に飲むのが一番だよ。
家で飲んでるとそこら辺がどうしてもショボくなるからなぁ。
といいつつ昨日も帰ってから飲んでる俺って一体(笑)。

また現場の人間が遅刻だそうだ。
理由は人身事故だって。
まったくよぉ、よくそういう見え見えの嘘付くよな。

こいつは都内全線のどれか一つでも事故ったら遅刻になるのが定例。
完全にそれを利用した言いわけに決まってんじゃねーか。
大体、遅れてんのにつまらん言い訳考えてるところが情けないったらありゃしない。
男が言い訳してんじゃねぇ。
遅延届け貰ってる暇があったらその時間を早く出社することに使えっての。

--- バトル勃発 ---
あらあら、現場はますます戦争が激しくなってます。
別チームのリーダーと、現場の開発主任との一騎討ち。
それにしてもこのリーダーはガラが悪いのだ。いきなりキレ出すし。
こんなの飼ってても会社にとってもメリットは無いと思うんだけどなぁ。

言い合い聞いてるだけでも面白いね。
近くにいる人達はたまったもんじゃないと思うけど。

--- Webアプリ ---
昔のシステムっていうのは、専用のクライアントを使うのが当り前だった。
それが今じゃ、どこもかしこもWebアプリ。
別に悪い事じゃないが、使う側は果たして
それによる弊害というものを考えた事があるのだろうか。

Webアプリ最大の利点は、誰でも簡単に導入できるという事。
Webサーバを立てて、ユーザにURLを教えればそれで完了。
専用のクライアントをインストールする手間を考えたら
これは格段に優れた導入方法だ。

システムをバージョンアップするのも簡単だ。
これが従来の専用クライアント方式だったら、バージョンアップの度に
全てのユーザに新クライアントプログラムを送らなければならない。

--- デメリット ---
こう書くと、Webアプリ万歳って感じもするが決してそうでは無い。
数々のデメリットも今だにある。

一番が、レスポンスの遅さ。
専用クライアントとWebシステムじゃシステムの構造自体が全然違う。
レスポンスが遅くなるのは当然っちゃ当然なのだが、
ユーザはそんな事わかっちゃくれない。
しかも、専用クライアントからWebへの移植だったりすると話はさらに酷くなる。
「昔の方が速かったなぁ」と言われたら、開発者は返す言葉が無いんじゃないだろうか。

もう一つが、出来る事の貧弱さ。
専用クライアントならば、ほぼ大抵の事は実現可能だ。
しかし、Webアプリというのは極端に出来る事が限定されている。
もともと、ブラウザというのはWebページを見るため(だけ)に開発されたものなので
専用クライアントでやっていたような複雑な処理を
これに求めるというのは少々酷だ。

最近ではかなりの事が出来るようになったとはいえ、
やはり到底「何でも出来る」というレベルには達していない。

--- ブラウザ互換 ---
大抵のWebコンテンツにはこんな注意書きがある。

「このページは、Internet Explorer5.5以上で閲覧して下さい」

つまり、このブラウザで見たときの動作しか「保証」しませんよという事。
なぜなら、数あるブラウザの動作はどれも異なっていて
互換性が低いからだ。

それを解消するために、W3Cという団体が共通規格を作ってはいるが
ブラウザ本家であるところのMicrosoftがああいう姿勢を取っている限り
これにだけ合わせて作るというのは現実的に厳しい。

--- 互換性の代償 ---
今僕が参入しているプロジェクトもWebアプリだ。
しかも、不特定多数のユーザが見るシステムなので
対応するブラウザの数は出来るだけ増やす必要がある。

しかし、それ相応の工数も掛かるので
ある程度のところで妥協をしなければならない。

普通こういうのはシステム開発以前に決まってるものなんだが
そこはさすがうちのリーダー。
開発の第1フェイズも終わる頃になってようやく対応ブラウザの一覧が出てきた。

その対応は、本来別の人が一人でやっていたのだが
かなりの数の対応が必要だということで
僕も駆り出されることになった。

--- 初Mac ---
今回僕が担当したのは、Macintosh上のブラウザ数種。
何しろ今までMacなど触ったこともない。
独特のインターフェイスや1ボタンマウスにかなり苦戦する。
こりゃあれだね。MacユーザはWindowsはもちろんLinuxに乗り換えるのも苦労するだろう。
LinuxのGUIは完全にWindowsを真似たものなんだから。

--- 次世代の行方 ---
そろそろ、この無駄工数を何とかしようという企業も現れるだろう。
新しいブラウザが出る度に、開発者はそのブラウザに対応したHTMLを書かなくちゃいけない。
これを変えるための選択肢はまだ少ない。

その一つの答えがFlashだ。
なにせ、世界にあるPCの約97％にはFlashがインストールされているというデータもある。
Flashで作れば、ブラウザ間の互換も完璧に保たれる上に
従来のWebシステムを遥かに凌駕する高級なインターフェイスが実現できる。

--- Flex ---
しかし、Flashをプログラムと組み合わせるのは容易ではない。
Macromediaが売り出しているFlexサーバプログラムを使えば
Javaプログラム(J2EE)とFlashの連携が可能だというが
150万以上するこのプログラムを購入しようという企業はまだ少ない。

果たしてそれがどれだけの性能を持ったフレームワークなのかという事も未知数だ。
が、僕はFlexに多少魅力を感じている。
これは、Webアプリに専用クライアントと同等の機能を提供するための架け橋になるかもしれない。
Webアプリもそろそろ次の世代へ進む時じゃないだろうか。

無料で評価版が落とせるらしいので、早速使ってみることにしよう。

今日もひたすら暇をつぶすだけの現場。
なにやらチーム内のメンバーがもめている。

例のブラウザ問題。
今になって多くのトラブルが発生しているらしい。
そりゃそうだろ。今まで全くそんな事意識しないで作ってきたんだから。

--- 後付け ---
前にも言ったように、複数ブラウザ対応の話が出てきたのは最近になってから。
こういう重要な事を後付けで作業して、うまくいくわけがない。
ホントこいつらの犯すミスは典型的だよな。
そのうち本でも出してやろうか(笑)。「失敗する開発者のパターン100」とか。

もうこういうの相手してても疲れる。
僕は僕の作業をするだけだね。

--- Flex受難 ---
昨日評価版を落としたはいいが、なぜか解凍に失敗する。
どうやらファイルが壊れているようだ。
仕方無いのでもう一度落とすことにするが、このダウンロードサーバがやたら遅い。
この調子じゃ1時間以上掛かるぞ。

大して使ってもらう気も無いんだろうなぁ。
こういう対応を見てるとそう思うよ。
そんなわけで、使う前からやる気がダウンしてる僕なのでした。