なんか今日は朝の電車がメチャクチャに混んでる。
あまりにも混んでたので、一本待って乗ったけど
それでも相当きつい。
たまにこういう日ってあるよね。

--- 蔓延中 ---
やばい。現場では風邪菌が充満してる。
このままじゃうつされそうだ。

スロー君は出勤してきた。
結構元気そうだから、昨日は多分サボリだな。
作りかけの資料が終わりそうにもなかったから
後輩に任せて逃げようとしたんだろうけど
結局資料提出は今日に延期されたから今ごろがっかりしてるんだろう。
案の定、資料のレビューはボロボロだった。

--- 続・考える人 ---
今日もスロー君はひたすら考え事をしている。
しかし、ショージ君は別のプロジェクトに関わ始めたので
もう助けてくれる人がいない。

僕がその役目をしてもいいんだけどね。
それやってばっかだとスロー君のためにもならないから
いざという時まで手は貸さないようにショージ君からも言われてる。

--- もう到着 ---
帰宅後、珍しく料理。
っていっても、インスタントの担々麺茹でて
ニラもやしのパックを炒めて入れただけという…
「自炊」とはとても言えんな。

でもこの担々麺、少々高価だっただけあって美味い。
ちょっとした中華屋のランチで出てくる位のスープの味。
「名古屋錦城 四川担々麺」。最近のお気に入りです。

で、その料理中。我が家に宅配が届いた。
以前注文してた酒である。
結構早いね。一昨日の夕方頼んでたのにもう来るとは。

今回は、以前まで愛用してた店とは別の店にした。
以前までの店はなんか急激に値上げしててね。
今回利用したのは、「ALAK.JP」という洋酒専門業者。
品揃えもまぁまぁで、値段は結構安い。
1万円以上で送料無料だし、1万5千以上で代引手数料無料だし。
前のとこより全然いいぞ。

--- 早速、と思いきや… ---
さて、こうなったらもう飲むしかないな(笑)。
…と思ったけど、まずは先日買ったワインを空けるのが先か。
シャトー・ノエル・サン・ローランという赤ワイン。
結構薄味(？)な感じだね。個人的にはちょっと物足りないなぁ。

この業界に多いのが、知識はあるけど実践経験の無い奴。
資格だけ取って満足してるような類もそう。
こういう輩は現場では役に立たない。
何故なら、実践経験の無い知識ほど当てにならないものは無いからだ。

もちろん知識はあるに越したことがないが
それを実践で使わない事には何の意味も無い。
実践でその知識を使うとすれば必ず、
知識だけでは判らなかった事柄が起こるはずだ。
それを乗り越えてこそ、その知識は本物になる。

--- あるOracleマスターの一コマ ---
さて、ちょっとここで例を出そう。
データベースのチューニング作業をしていたときの事。
SQL文を眺めていたOracleマスターのO君は、ある事に気付いた。

「WHERE句にSUBSTR使ってるなぁ。これはLIKE構文使った方が速いぞ」

例えば、
SELECT * FROM TEST_TABLE WHERE SUBSTR(ATIME,1,4)='2020';
こういったSQL文があるとする。
ATIMEにはインデックスが張られているが、このSQL文ではインデックスが使われない。
そこで、以下のようなSQL文を用意する。
SELECT * FROM TEST_TABLE WHERE ATIME LIKE '2020%';
こうすると、ATIMEのインデックスが使われるようになる。
だから、一般的に言って後者のSQL文の方が速い。

しかし、実際のプロジェクトでこれほど簡単なSQL文が使われることなどまずない。
テーブルをJOINしたり、GROUP BY したり、色々あるだろう。
理由はともかくとして、SUBSTRをLIKE構文に変えることによって
逆に遅くなる事例というのはある(今回が正にそうだった)。

--- 例外付き鉄則 ---
「こうすれば絶対こうなる」といった鉄則など
コンピュータの世界ではごくわずかしか存在しない。
大抵の理論には「一般的には」という前置詞を付けないといけない。
しかし、それをわかってない奴が多い。

「こうすればこうなるはずなんだけどなぁ…どうしてうまくいかないんだろう？」
多分彼は、一生この問題を解決できない。
物事を解決するには、より広い視野が必要だ。

結果は何よりも正直だ。
理論は所詮理論に過ぎない。
ここら辺が、数学とコンピュータとの違いかもしれない。

--- 結果から理論へ ---
ただし、こういう一般論では解決できない場面に陥ったとき
それを解決するために新たな理論を身に付けることで
理論はより完璧なものに近づく。

これには、結果から理論を推測する事が必要だ。
このとき、プログラムソースがあれば
理論はほぼ間違い無く導き出せる。
しかしこれが無いと、あいまいな理論しか導けない。

今回の例だと、ソースから原因を追求できれば
「○○という条件が真のとき、SUBSTRをLIKEに変えることで遅くなる」
という理論が導き出せる。

しかしこれが出来ないと
「SUBSTRをLIKEに変えることで遅くなる場面がある」
といった、後に大して役の立たない情報しか導き出せない。
結局、またこういった場面に陥ったとき
SUBSTRが速いのかLIKEが速いのかを検証して
どちらかを選択しなければならない。
プログラマは、こんな時間の無駄遣いをしたくないのだ。

あぁうぜぇ。
今やってるプロジェクトの相手先に、
暇になるとすぐこっちに色々振ってくる奴がいる。
はっきりいってすげぇ迷惑。

一応こっちが下請けの立場だから
邪険に突き返すことも出来んし。
まぁ僕はその役目じゃないんだけど。
仲介に入ってるスロー君の仕事がそれによって奪われ
ますます作業が遅くなるのが一番困る。
それによって僕も多少なりとも影響受けるしね。

今回はさすがにショージ君も見かねて助っ人に入ったようだ。
自分の仕事も忙しいのに大変だねぇ。
でもさすがリーダー。ショージ君がメール出してから
相手先の奴はすっかりおとなしくなったみたいだ。

そうそう、こういう類の奴は文章だけは強気。
が実際はかなりの小心者な事が多い。
こいつも一回会ったことあるけど見すぼらしいオッサンだったし。
D社という自分の立場を利用してつけ上がるタイプだ。

--- 仕方ないのだ… ---
あ?あ、どうやら明日は休日出勤だ。
スロー君の仕事が全く進んでいない。
リミットが今週末だからね。明日少しやらないと間に合わないだろう。

まぁいいさ。午後からちょろっと出勤して
適当に作業するとしよう。

物事の本質を見極めるには、それを深く掘り下げる必要がある。
そのために必須なのが、ソースコードの存在なのだ。

オープンソースを推進する人達は、ただやみくもに推進しているわけじゃない。
推進するべきちゃんとした理由がある。
「開発をより便利にする為」にはオープンソースが必要なのだ。
ソースを公開することで、僕らの生活はもっと便利になる。

金儲けの為にアプリケーションを公開しているような企業は
長い目で見れば誰の生活も便利にしない。
逆に、そのアプリケーションにつぎ込んだ大金によって
生活はより不便になるだろう。
それを敢えて望む人達が多いのは、より良い選択肢を知らないからだ。

そして別の選択肢を選ぶには、ほんの少しの技術力が必要になる。
何から何まで面倒見てくれる過保護なアプリケーションしか使っていないと
自分では何も出来なくなってしまう。
それでもいいというのなら、もう何も言うことは無い。
好きなだけアプリケーションに金を使うのが正しい選択でしょう。

さて、今日は珍しく休日出勤です。
作業も終わったので日記でも書くとしますか。

休日なのに、なぜか僕の周りには数人来ている人がいる。
おかしな現場だよ。
新規プロジェクトの提案を詰めているらしいが
聞いてるだけで突っ込み所満載の内容。
まっ、別にどうでもいいので放っといたけど。

--- いつも通り ---
で、結局夜はビデオ見ながら酒を飲んでいたりする。

今回は久々にカシスリキュールを買ってみた。
トニックウォーターがちょっと余ってたので
ジン＆トニック＆カシスにしてみる。
やっぱりカシスが入るとトニックの味が消えちゃうね。
こういう濃い味のリキュールは使い方が難しい。
まぁカシスソーダ作ってりゃ外れは無いんだけど。

最近、コンビニで炭酸水が売っていないことが多い。
やっぱ需要低いのかなぁ。
クリスタルガイザーのスパークリング・ウォーターは
結構置いてあるので、これで流用することにする。
軽くレモンも効いてるので中々良いのだ。

好きなカクテルの中でもベスト10に入る
シンガポール・スリングを作る。
本来のレシピはシェイクするらしいんだけど
面倒くさいのでステアで済ます。
ジンとレモンジュース、チェリーブランデーとソーダ。
やっぱ美味ぇ。でもちゃんとしたBarで頼んだことは無いなぁ、そういえば。

クランベリー・フレーバーのウオッカを初めて買ってみた。
ソーダで割ってみたけど、正直「ビミュー」な味。
クランベリーの風味はほんのりする程度。
やっぱこういうのはストレートで飲む用だね。
僕は40度のスピリッツをストレートで飲めるほど強くはないので。
今後こいつをどうやって生かそうか…今後考えることにしよう。

Oracleが10gの無償版をリリースしたらしい。
これが何を意味するか。

MySQLが勢力を伸ばすことをOracleは恐れている。
その証拠に、ついこの間Oracleは
MySQLがストレージエンジンとして採用していたInnobase社を買収した。
そして今回の無償リリース。

あまり深く考えない人なら、「無償だったらOracle使ってみようか」と
考えるかもしれない。
しかし、これはOracleの罠だ。
無償版を使おうと、結局サポートを受けなければOracleはまともに動かない。

--- ブランド製品 ---
なぜ僕がオープンソースの製品を使うか。
それは、そちらの方が質が高いし使い易いからだ。
「そんな馬鹿な」と思う人もいるかもしれない。
ではなぜ人々は高額を出してOracleを買うのか。

彼らは「安心」が欲しいだけなのだ。
大手のOracleならば皆使ってるし、サポートもしっかりしてるので安心だ。
しかし実際はどうだろう。
Oracleを使うことによって発生する様々なバグ報告に悩む日々。

--- 便利だから ---
少し現実を見渡せる人ならきっと、Oracleを使うことに疑問を感じている。
しかし、他のDBに移行する勇気が無い。
少しのチャレンジ精神と、それを許される環境にある人は
是非MySQLを使ってみて下さい。
Oracleと比べて何の見劣りもしないし、何より使いやすいです。
訳のわからないバグも発生しません。

客を説得できない人は、OracleからMySQLに移行することによって
今までOracleに投じてきた巨額の資金を
節約もしくはシステムの向上に充てることが出来ることを
アピールして下さい。
Oracleにそれだけの大金をつぎ込んだ価値が
本当にあるのかと問いてみて下さい。
ほとんどの人は、この問いに答えられないでしょう。

--- 所詮DB ---
MySQLに実績が無いと言われたならば、
OracleもMySQLも所詮データベースであり
システムの一部に過ぎないんだと言って下さい。
どんなDBを使っても、それによって安全性が保証される事など
有り得ないのです。
安全を保証するのはシステムであり、DBではないのです。

今までOracleを使ってきて、「Oracle使ってて良かったなぁ」
と思った場面がありましたか？おそらく無いはずです。
逆は山のようにあるかもしれませんが。

MySQLを使っていると、「MySQL使ってて良かったなぁ」
と思うことが多々あります。
正確に言えば「Oracleだったら不便だったけど、MySQLだとこんなに便利なんだ」
という思いです。
どちらも使ってきた僕は、その事を痛感します。

どちらを選択するかは、あなたの自由です。

うむむ…どうも僕に付く営業は
使えん奴である運命にあるようだ。
前の会社でもそうだったし、今の会社でもそう。

特に今回の僕担当は以前にも増して駄目っぽい。
今の現場は、営業の部署が近くにいるんだけど
どうもうちの営業とモメているらしいのが聞いててわかる。
こっちの営業担当の人(女性)がキレかかっててちょっと恐い(笑)。
まぁでもその気持ちもわかる。あれ相手にしてると疲れるんだ。

契約書に不備があったり、
金額が間違ってたり…っつーかそれヤバいだろ。
ちゃんと仕事してくれよなぁ。

本人は「純利益は俺が会社でトップなんだ」とか言ってるけど
それだけじゃ意味無いんだよ。
相手からの信頼得られないようじゃこの先伸びないぜ。

--- 思考停止中？ ---
またまたスロー君は固まっている。
こいつはショージ君がいないと何にも出来ないらしい。
スロー君改め「ストップ君」にでも改名してやろうか(笑)。

今回の作業はもともと、制作が僕で
チェックとテストをスロー君が担当するはずだったのに
結局は僕がテストをしてる。

ってことはスロー君がやってるのはチェックだけ。
なのに何で作業終わんないのかねぇ。
そのせいで休日出勤になった僕の身にもなってほしいよ。

ショージ君もその辺は気にしてるらしい。
明らかに誰の目から見てもスロー君の作業量は少な過ぎる。
もうそろそろ歳なのかもね。常に眠そうにしてるし。
長期休暇にでも入らせてあげた方がいいのかもしれない。
…そういや昔現場にこんな人いたな(笑)。

--- どうやら休み ---
ついこの間までゴチャゴチャうるさかった客も
ショージ君のメール以来めっきり大人しくなったようだ。
っていうか今日もしかして奴ら休みか？
こっちから出したメールへの返答が無いところを見ると。

--- 「通常」状態に戻る ---
あらら、また現場は暇になっちゃいました。
ショージ君も暇そうだ。
昨日仕事出る必要無かったな。
土日出るのは嫌だから、念のために昨日出たんだけど。

そろそろネタ探さないと。
でもここの環境じゃJavaも使えないし。
ドキュメント読んでるだけじゃ眠くなるのだ。

さて、今注目を集めるこの技術。
動的Webアプリケーションを進化させるものとして
一体どちらが主流となるのか。

--- Flash ---
Flashについては知らない人はいないだろう。
現在、かなり多くの商用サイトでFlashが使われている。
見栄えも良いし、外部プラグインとはいえ
ほとんどのPCにはFlashがインストールされているだろう。

唯一の欠点は、開発ライブラリ。
Macromediaから販売されている何らかのツールを
使わない限り動的なFlashコンテンツの開発は事実上難しい。

--- Ajax ---
最近特に注目を集めているのがこれ。
基本的はHTML + JavaScript(Dynamic HTML)なのだが
今までのものと決定的に違うのが
「ページのリロードをせずに画面の一部を動的に変更できる」
というもの。

Dynamic HTMLも動的に画面レイアウトを変更できるが、
サーバリクエストを発生させることは出来ない。
Ajaxはサーバリクエストを発生させながら
ダイナミックに画面を更新する。
最近のほぼ全てのブラウザが対応しているという点も強み。

Ajaxとは仕様名で、実装にはいくつかの方法がある。
僕が今使っているのが「Dwr」というパッケージ。

http://getahead.ltd.uk/dwr/

シンプルで使いやすく、JSPにも依存してないので
Velocityからも使える。オススメです。

さて、僕はいつものように
休日だというのに何もせずに過ごしています(笑)。
この時間を有効に使えたら、
もうちょっと人生楽しくなるのになぁ…
とか思いつつ、結局家にいる日々。

なぜ僕がこんなに出不精なのかというと、
一人で外に出掛けるのが嫌いなのだ。
人と一緒だと外に出るのも苦じゃないだけどね。

かといって友達もそんなに多いわけじゃないから
大抵は一人で家にいることが多い。
はぁ…早く彼女でも作んないとなぁ。
なんて事を考えることもよくあったりする。
どうもそっちの方は昔から苦手なのだ。

--- 酒の力？ ---
結局これですか(笑)。
僕は飲んでると何でも口に出してしまう性格らしい。
シラフでもそういう傾向にあるんだけど、飲むとさらに。

昨日は風呂場で壁に頭を強打してしまった。
久々の激痛。血出てなくて良かったよ。
でもかなり腫れてるはず。
シラフだったのが余計つらいね…って、どっちでも一緒か(笑)。

昨日に引き続き、家でゴロゴロしている僕です。
暇なので通販で色々買ってみた。
そろそろ寒くなるので毛布とか、ちょこまかと。

この前シャルトリューズのイエローを買ったので飲む。
やっぱこいつは美味ぇ。
トニックで割るのが僕のお気に入り。
アラスカとかは美味しいんだろうけど
アルコール度数キツ過ぎるからね。
40度のジンと40度のシャルトリューズを混ぜただけだから。

といいつつこの前Barで友達に勧めてしまって俺って…
あれは正直、酒強い人じゃないと厳しいよ。

--- 連チャン ---
気が付いたら、最近毎日欠かさず日記を書いているらしい。
特に心境の変化は無いんだけどね。
Mixiで公開し始めたってのも原因の一つなのかな。
やっぱ誰かに見てもらってると思うと
書く回数も増えるんじゃないかな。

大規模なWebコンテンツで必要不可欠なのがキャッシュ機構だ。
これが無いと、多数ユーザからのアクセスに耐えられなくなって
システムが使いものにならなくなってしまう。
もちろんマシンを強化するという手もあるが、僕らはもっと
エコロジーなやり方で問題を解決できる。

一言でキャッシュと言っても色々な使い方があるが
今注目しているのが、シンプルで柔軟性のある
オブジェクトキャッシュ機構。

単純に言えば、Javaのオブジェクトをメモリ内にキャッシュしておくという
発想自体は今までのプログラムにもあったものだ。

ただ、今までのキャッシュ機構は柔軟性に乏しかった。
機能ごとにキャッシュマネージャを作り込む必要があったりして
正直スマートな実装とは言えないものが多かった。

最近になって、これらのキャッシュ機構をライブラリ化した
パッケージがいくつか出ている。
ちょっと紹介しよう。

JCS
Apacheグループで開発されている。
まだ開発段階なのに加え、依存性がやや高いのが難点。

JOCache
http://jocache.sourceforge.net/
ShiftOneというグループで開発されている。
ライセンスは今回紹介する中で唯一GPLなので良いのだが
最新リリースが1年半以上前で止まっているので、今後がちょっと心配。

JBossCache
ご存知JBossが開発している。
ツリー構造やマシン間レプリケーションなど機能は多彩だが
その反面ライブラリが巨大過ぎる。

--- Ehcache ---
で、本命がこれ。

http://ehcache.sourceforge.net/

「シンプルで速い」ことをウリにしている。
JOCacheに比べると、キャッシュの設定も豊富で
ディスクへのスワップIn/Outにも対応している。
依存性も低いので使いやすい。
Hibernateで採用されているので今後も成長する可能性は高いだろう。

ただ、ライセンスがApache 1.1なのが気掛り。
一応Forumに2.0にしてもらえないか報告はしておいたけど、
果たしてどうなる事やら。

--- Tomcat & ehcache ---
うむむ…どうもTomcat上でehcacheを使うと
コンテンツの再デプロイが行われる度にメモリが膨れ上がってしまう。
どっかに開放されないメモリが残ってるらしい。
ehcacheを外したらこの現象は起こならかったので
おそらく原因はehcacheだろう。

とはいっても、これはehcache自身に問題があるというわけではない。
ehcacheが元々メモリリークの問題があったJCSを置き換えるために開発された
という経緯から考えても、この製品にメモリリークがあるとは考えにくい。
ShiftOneを使っても同じような現象になったから、
どうやら問題はTomcatの再デプロイにありそうだ。

とりあえず回避方法としては、
ehcache.jarをTomcatのcommon/libの下に置くという手法がある。
こうすればコンテンツを再デプロイしても
ehcacheは再ロードされないので問題は回避できる。
が、どうもスマートじゃない。
暇が出来たらそこら辺調べてみようかな。

僕が今済んでいるアパートは
毎月家賃を口座に収めるシステムになっている。
これが面倒くさいので、よく忘れたりするのだ。

今回も先月分を払ってなかったらしく
不動産屋から電話が掛かってきた。
帰り、駅のすぐ近くにあるみずほ銀行で振込しよう…と思っていたら。

なんとその場所はDocomoショップに変わっていた。
結構大きい銀行だったのに、こんな事ってあるんだね。
ちなみに2FはUFJになったらしい。

銀行よりDocomoの方が需要があるって事か。
でも駅前に銀行無いってのは淋しいね。
携帯をほとんど使わない僕としては嬉しくない。
皆、携帯メーカに躍らされるのに気付かないのかな。
そんだけ金を払う価値のあるものか？携帯って。
Docomoはボロ儲けだよな、実際。

Oracleがまた適当な事を言い出した。
10gでは、アプリケーションサーバとDBが融合してるから
システムのボトルネックを簡単に解決できるという。

断じて違う。こんな大嘘をよく言えたもんだ。
アプリケーションサーバとDBを繋げるという考え自体は良い事だが
そのやり方が間違っている。
Oracleのやり方だと、それぞれがお互いに依存し過ぎてしまう。
分離性、独立性を求める現代のシステム開発とは全く逆の方向なのだ。
Oracleはいつだって
「実際の」開発者の立場に立ったアプリケーションを作ろうとしない。

なぜ、両者を融合させてはいけないのか。
それは、これらはあまりにも無関係なアーキテクチャ(構成)だからだ。
これらを強引に結び付けるとどうなるか。
大量のバグが発生する可能性が高まり
開発者はそのフレームワーク(枠組み)に縛られて苦しい思いをすることになる。

--- 分業のススメ ---
人間は万能ではないのだ。
だから、人間が作ったアプリケーションも決して万能ではない。
全てを賄おうとするから、全てが駄目になる。
一つの事に特化したアプリケーションを組み合わせて使う事こそ
安全で頑丈なシステムを作るために必要なことだ。

N個の機能をまとめて実装したアプリケーションは
1つの機能を実装したアプリケーションと比べて
2の(N-1)乗のバグを持っている可能性がある。

1つの機能を実装したアプリケーションをN個組み合わせて使っても
そのとき発生するバグの可能性はN倍にしかならない。
※ ただしこれは他アプリとの依存性が強いMSのアプリなどには成立しない

Oracleは、大まかに分けても数十の機能を持ち合わせた
複合型アプリケーションだ。
こんなシステムが安全なわけが無い。
少しでも大きなプログラムを作ったことがある開発者なら
そんな事はすぐにでもわかるはずだ。

いつも月曜の朝は桁違いに眠い。
が、今日は火曜なのにまだ眠い。どうしたものか。

隣のイネムリ君。電話するときの声のデカさが尋常じゃない。
はっきり言って超迷惑だ。
「はい！はい！」って何度も頭下げてるし。
お前はあるある探検隊か(笑)。

--- 銀行受難 ---
おいおい、どうなってんだ。
昨日に引き続き、今日は現場のみずほがやってない。
こっちは改装中らしいが。

--- 不思議な匂い ---
さぁ、ここで匂いの実験です。
喫煙室に入った人は、煙草の匂いがします。
これは当然。が、喫煙室から出てくるとまた別の匂いに変わる。
表現しようの無い、何か妙な匂い。

で、突然ですがクイズです。
スロー君が喫煙室から出てくると、どんな匂いがするでしょうか？

早速ですが回答を言いますと…なぜかカールの匂いがします(笑)。
はい、お菓子のカールにそっくりな匂いです。
う?ん、不思議。
というわけでアダ名はカール君に決定(今だけ)。

彼らは何度同じミスを繰り返せば気が済むんだろう。
実装も完了した段階になって性能要件をゴチャゴチャ言うなよ。
そんな事どうして要件定義のときに決めておかなかったんだ。

大抵の奴らは
「とりあえず動くもん作って、それから性能のことは考えよう」
と思っている。

あり得ねぇ。それじゃ遅すぎなんだ。

「何とかなるでしょ。頑張ってよ」

嫌だね。もう手遅れだ。
一からプロジェクト作り直してくれ。

性能を改善したいというくせに、
今さらDBにインデックスは張れないだのカラムは追加できないだの
ぬかしやがる。

「プログラムで何とかしてよ」

馬鹿やろ。DBだってプログラムだ。
DB構成変更するのもプログラム修正するのも
リスクの質には全くの差が無い。
大抵の場合はDBを変更した方が簡単だし安全なのに。

--- 要件定義者 ---
オブジェクト指向、抽象化。いくらこれらの考えが進んだとしても
必ず避けて通れないのが性能問題。
だから絶対に、要件定義の段階で性能要件を決めておかなければならない。
しかしほとんどの要件定義者は、プログラムの実装などほとんど経験が無いので
この性能要件を決めることが出来ない。

だから、プログラマが要件定義に関わる必要がある。
これを日本の企業はやろうとしない。
プログラマ、SEなどと役割分担を決めてしまっている。
こんな分け方は全くのナンセンスだ。
設計と実装を分断して考えることなど絶対に不可能だからだ。

DBが得意な人、HTMLが得意な人。
色んな得意分野を身に付けた人がいるほど
プロジェクトはスムーズに進行する。

設計が得意な人？そんなのは要らねぇ。
何だよ、その中途半端な得意分野は。
設計するには本来、山ほどの技術知識が必要なんだ。
それを全て一人で賄おうなんて無理なんだよ。
プログラムもまともに書けない奴が設計やるなんかもっての他。

--- 性能を常に意識せよ ---
性能の事を考えて作業を進めると、
当然その分の工数が掛かる。
だから奴らはこの工程を省こうとする。

しかし、現実はどうだろう。
保守の段階にまで入っているのに性能問題が表面化して
プログラムの大幅な修正が必要になる。
これに掛かる費用と、それによる信頼低下。
開発時に少しの費用をケチった事が、これほどの損害になっているんだ。

未だに製作と保守を分けて考えている人達がいる。
両者は別ものじゃない。
だってそうでしょ？扱うのは同じプログラムなんだから。
製作がまともに出来てないから、保守に苦しむんだ。
保守の事を考えていないから、製作で手を抜くんだ。
これじゃいつまで経っても腐ったプログラムは
この世から無くならない。

なんか最近よく喉が渇く。
乾燥してるのかなぁ。
それとも、昨日飲んだ酒が原因か(笑)？

--- 眠い理由 ---
今週はどうやらずっと眠いらしい。
よく考えたら、仕事内容が原因かな。
ずっとドキュメント修正してるだけじゃ飽きてくるよ。

…ふと斜め前を見ると、スロー君も寝ているではないか(笑)。

--- 勤務時間 ---
スロー君が何やらショージ君に相談している。
「今日、用事あるんで定時に帰っていいですか？」
おかしな奴らだよ。どうして定時に帰るのに許可が必要なんだ。

本来逆だろ。「定時で終わらないので残業します」。
定時ってのは飾りじゃねぇんだ。
「この時間までに作業を終わらせます」という決められた時間。
毎日残業するような企業は、いっその事定時を遅らせた方がいい。

そうしないと残業が当り前になってしまうし
時間内に作業を終わらせようという自覚が薄れてくる。

--- 守るべきもの ---
プロには納期というものがある。
納期は守るのが絶対だ。それは相手(客)の為。
客は納期にシステムが収められることを想定しているから
これに間に合わなければ当然様々な弊害が生じる。

そして、定時を守るのも基本。それは会社の為。
会社は社員に給料を払っている。
残業をすれば、(普通の企業ならば)残業代が発生する。
つまり、残業が増えれば増えるほど会社の赤字は増えていく。
そして明らかに、残業をすればするほど人の集中力は途切れてくる。
だから勤務時間に比例した働きが出来ない。

--- 心のゆとり ---
常に残業をしている人は、心に余裕が生まれない。
余裕が無いと、人の心は病んでくる。
ストレスも溜まるだろうし、新しいものを生み出そうという
活力だって出てくるはずが無い。

もちろん人によって差はあるだろうけど。
僕は短期集中型の人間だから、少ない勤務時間で
密度の濃い作業をする方がよっぽど効率がいいのだ。

時間は大切だしね。
出来るだけ多くの自由時間が欲しい。
…って結局酒飲んでるだけじゃねぇかっていう突っ込みは勘弁です(笑)。
それも僕にとっては大事な時間。

今日はどうも体調が悪い。
っつーか喉が痛い。
こういう日は、空気の汚れとかに過敏に反応してしまう。
タバコの煙にも耐えられない。
咳が止まらんぜ。

この業界には、いくつかの役目を持った人達がいる。

まずわかりやすいのが、実際のシステムを作るメンバー。
開発グループと呼ばれる人達はここに属する。
開発グループの中にもいくつかの分担が分かれている。

プログラマ
通称PG。実際にプログラムを組む人。

システム・エンジニア
通称SE。設計書を書く人。

チーム・リーダー
PGやSEは通常、何人かでチームを組んでいる。
そのチームを統括する人。
彼らのスケジュールを管理する。

プロジェクト・マネージャ
通称PM。プロジェクト全体の管理をする人。
例えばプログラマを雇ったり、
プロジェクト全体の予算やスケジュールなどを管理する。

開発グループは大体こんな感じだ。

実際にシステムを使う側からの発注を
開発グループに渡すための橋渡しとなる人達もいる。
ITコンサルタントとか呼ばれる職種で、
コンピュータの事を何もわからない人達の要求を
ある程度具体化して「こんな感じのシステムを作ったらどうでしょうか」
という事を提案(コンサルティング)する。

さらに最近では、ITコンサルと開発グループの橋渡しをする
「ITアーキテクト」なる職種もあるらしい。
彼らは実際の運用を意識したハードウェア構成を決めたりする。

--- システム完成までの流れ ---
では今度は、実際にシステムがどのように完成していくかを見ていく。
正直僕はあまり上位の工程の事は知らないので
そこら辺は省くことにする。
本来なら経営戦略やら何やらの工程もあるが、とりあえずパス。

要望
まず、「こんな事がやりたい」という漠然とした要望が
客から出てきたとしよう。

提案
ここで出てくるのがITコンサルだ。
客の望む事を実現するためには、こういったシステムが必要で
規模はこれ位だから予算は…などといった感じで
客と交渉を進めていく。

そして、ある程度システムの概要が決まったら
ITアーキテクトと呼ばれる人達が
実際のハードウェア構成などを決めていく。
OSは何にするのか。サーバは何台くらい必要なのか。
DBの多重化は必要か、等々。

要件定義
ここまで来たら、要件を具体的に固めていくという作業に入る。
担当するのはSEだ。
どんな機能を実装するのか、性能要件はどれ位まで必要か。
ここで作成される要件定義書が、今後の開発をしていく上での指針となる。

仕様作成
では開発…というわけにはいかない。
要件定義書はあくまで「客向けの文書」であるから
実際にシステムを構築するには詳細な情報が少な過ぎる。

よって、開発に必要な情報をまとめた文書が必要になる。
これが基本設計書、詳細設計書と呼ばれるものである。
前者は主にSE。後者はプログラマが担当することが多いようだ。
現場によっては詳細設計書が無いところもあるだろう。

開発
さて、ここまできてようやく開発に入れる。
基本設計もしくは詳細設計を元に、プログラマが開発を始める。
あとはプログラムがうまく動けばシステムは完成。
めでたしめでたし(笑)。

--- より上位へ進もうとする奴ら ---
で、今業界ではITコンサル及びITアーキテクトへ
転身する人が多いらしい。
開発で経験を積んだ人間は、これら上位の工程へ行くことで
給料も上がるし、より良いシステムが作れると彼らは言う。

一見的を得ているように見えるこの意見だが
ほとんどの人間はこれが実現していない事を知っている。
僕が考えるに、彼らは給料の為だけに
上位へ行こうとしているように思える。

--- 上位vs下位 ---
なぜ、現場で経験を積んだ人間が上位に行っても
システムの質が向上しないか。
それは、現場の質が全く向上していないからだ。

上位(主に開発以前)工程にいる人間は言う。
「いくら下位工程で努力しても、
　上位工程でちゃんとした設計がされていなければ
　良いシステムが出来るはずが無い」

下位(主に開発)工程にいる人間は言う。
「いくら上位工程で努力しても、
　下位工程での作りが悪ければ
　良いシステムが出来るはずが無い」

--- それぞれの意見 ---
どちらの意見も正しい。
要するに、どちらも良くなければ良いシステムなど
完成するはずが無いのだ。

上位工程の人間は、こんな考えを持っている。
上位には優れた人間(つまり自分達)が必要である。
そして、上位さえしっかりしていれば何とかなる。
下位の人間は適当にみつくろってきて大丈夫だろう。

下位工程の人間は、こんな考えを持っている。
上位で適当な設計してるから、こっちが苦労するんだ。
そんな設計はとてもじゃないが実装できないよ。
実装できるように適当に設計変えといたから。

お互いがお互いを敵視し、軽蔑している。
こんな状況で、良いシステムが出来るはずが無い。

--- 教育 ---
さて、現在。どちらの出来が悪いかと言えば。
圧倒的に下位(開発)の方だ。
なぜか。開発スキルを育てようとしないからだ。

開発を「下位」と呼び、使い捨て同然の扱いをしている。
そして設計を「上位」と呼び、ここの向上ばかりを目指している。

それじゃ駄目なのだ。
両者はどちらも重要なポジション。
片方でも欠けてしまったら何の役にも立たない。
さらに言えば、開発者を育てなければ
決して優秀な設計者は育たないのだ。

--- 今、必要な事 ---
最終的にシステムの質を決定付けるのは
間違い無く開発側なのだ。
何故この事実に気が付かないのか。
現実を見てみれば、そんな事は一目瞭然なのに。

一つの理由は、上位の人間が
システムの質を上げようと思っていない事にもある。
金さえ稼げればいいと思っているのだ。
もちろん金にならなければ意味は無いが
まず金ありきという発想が破滅を招く。

良いシステムを作り、良い売り込みをする。
そうすれば金は自然と入ってくる。
全ての基本は技術力だ。

--- 技術の重要性 ---
日本最大の企業、TOYOTA。
TOYOTAは決して技術開発に資金を注ぎ込むことを惜しまないという。
それが、TOYOTAがここまでの大企業に成長させた。
技術こそ企業の基盤だという事を知っているからだ。

日本のIT開発技術は今、信じられない位に低下している。
このままでは、中国やベトナムなどに
そのポジションを全て奪われてしまうだろう。
果たしてそれで良いのか。

技術を持たない日本に、生産をしなくなった日本に。
明るい未来は来るだろうか。

う?む。今日は朝から何もすることが無いぞ。
僕だけじゃない。
周りの皆も暇そうにしている。
なのに何故帰りは遅いんだ？

--- 意外な救世主 ---
さて、暇な僕らに仕事が舞い込んで来ました。
バグ報告です(笑)。

しょうもない仕様バグなのに
スロー君はなぜあんなに焦っているのか。
見てるだけで面白い。
僕が助言してあげたのに、まだ何かに悩んでいるようだ。

その様子を隣で見ていたショージ君は
少しダンマリを決め込んでいたようだが
20分も経たないうちに見かねて手を貸した。

あ?あ、結局この構図ですか。
でも実は、スロー君ってショージ君より6つ、
僕より10歳位は上なんだよね。こんなんでいいのか。

--- 人を怒らせるDNA ---
…にも関わらず、やはりスロー君はやってくれた。
バグに対する回答メールで相手を怒らせてしまったようだ。
どうしてこうなるかねぇ。

以前もそうだった。リーダーが休みで
スロー君が相手とやりとりをしていると
何故か相手がキレ出したらしい。

彼の相手をすると皆いらいらしてくる。
これはDNAレベルの問題じゃないか？もはや直すことは不可能。

結局、ショージ君がそれに対する誤りメールを入れて
問題は無事解決したようだ。

--- 新メニュー ---
金曜の帰りはよくモスで夕食を買って帰る。
新製品が出ていたので買ってみる。
バタフライシュリンプ。海老の揚げものだ。
正直、味は普通。また買おうって気にはならなかったなぁ。

昨日は久しぶりに地元に帰って友達と
いつものように(？)お好み焼きを食べてました。
その後行ったゲーセンで大ブレイクした
某友人の話は置いといて(笑)。

やっぱ地元はいいね。心が落ち着くよ。
今日は珍しく両親と昼飯食べに行って
自然公園みたいなところを散歩してきました。
たまには、こういうゆとりのある生活もいいもんだ。

--- 生ライム ---
って、いきなり酒の話かよ(笑)。
今日は1時間近く散歩してたせいで結構疲れた。
ホント、運動不足を痛感するね。

生のライムを買ってくる。
とりあえずジン・リッキー。
ジンにライムを絞ってソーダで割るだけ。
お手軽で美味しい。

今日は初めて生ライムでモスコー・ミュールを作ってみた。
ウオッカにライム、あとはジンジャーエール。
ただ、カナダドライとかだと甘過ぎるので
ウィルキンソンのジンジャーエールで作る。
ライムの酸っぱさとジンジャーエールの甘さが絶妙。美味いぜ。

本物はジンジャー・ビアーっていうのを使うらしいけどね。
そんな代物、僕は売ってるのを見たことが無い。

またですよ、奥さん。
僕が携わっているプロジェクトでまたも問題発生。
しかも原因は以前と同じように性能問題。
一体何回この失敗繰り返せば気が済むのかなぁ。

これから先、絶対性能問題が発覚するよって忠告しといたのに。
奴らはそれに対応しようとしない。
「問題発生してからでいいでしょ」とでも言わんばかりだ。

それじゃ遅いっちゅーの。
いずれ発生するのは判りきってるんだから。
夏休みの宿題を先延ばしにするのとは訳が違う。
こんな事をしてたらスケジュールだって崩れるし、精神的にも疲れる。
この体質、何とかならんかな…

--- 役目果たせず… ---
リーダーであるショージ君の仕事を引き継いだスロー君だったが
やぱりその役目を果たすことが出来なかったようだ。
結局、重要な場面ではショージ君が作業をすることになった。
そうでないとプロジェクトがメチャクチャになるからね。

そうそう、近々現場では新人さんを面接するらしい。
うちのプロジェクトに入るかどうかは不明だけど。
それより課長が「若いから安けりゃいいや」的な発言をしていたのが
とっても不安。使えねぇ人材送り込まれてもこっちが困る。

ホント駄目だよ、こういう奴は。
使えない人間二人入れるより
デキる人間を倍の金で雇って一人入れる方が
よっぽど効率良いのにさ。
日本の企業はそういう金の使い方が出来ないらしい。
もったいないね…

どうしてか、このプロジェクトの設計書には半角カナが
多く使われている。

僕は半角カナと全角英数字が大嫌いなのだ。
後者については、ほとんどのIMEがデフォルトでそうなっているから
仕方が無い部分もある。ホント止めてほしい。

見栄えが馬鹿っぽいんだ。企業サイトで全角英数字使ってるところがあったら
その企業は世界から信用を失うね。
日本人だけだよ、こんな使い方してるのは。
まぁ全角って概念自体一部の国にしか無いんだけど。
ちなみに僕が使っているSKKでは英数字がデフォルトで半角。

そして半角カナ。こっちの見栄えはもっと最悪。
なぜ彼らは半角カナを使うのだろう。
重度の2チャンネラーだとしか思えん。
そして実際、半角カナを使っている現場の人は
いかにも2chやってそうな雰囲気だった…

今の現場では毎週、リーダーに週報を提出することになっている。
週報といっても勤務時間書くだけの簡単なものだけどね。

毎週月曜に先週分のを出すことになっているんだけど
先週は久しぶりに数字が綺麗に並びました。
つまり全日定時です(笑)。

昔はこれが日常だったんだけどなぁ。
最近は少し忙しくて残業が当たり前になってたから。
これを普通としたいよね。

--- 退屈 ---
定時で帰ってても稼働率が8割超えてりゃいいんだけどね。
今の状況は稼働率1割以下…
こんだけ暇だと疲れます。

ついにこんな日が来ちまった。
うちはW録だから2本までは大丈夫なんだけど、
見たい番組が3本重なるという事態に。

ちなみにその番組とは…

・サッカー 日本vsアンゴラ
・女子バレー 日本vs韓国
・NBA(対戦カード不明)

全部スポーツかよ(笑)。
とりあえずサッカーはそんなに興味無いのでTVで見ることにする。
後の2つは録画しておこう。

--- この電車で一番 ---
今日は朝いつもより一つ早い電車に乗る。
一番後ろの車両が乗り換えに楽なので
人をかき分けながらホームを歩いていると…
こんな駅のアナウンスが。

「次の電車は、この電車で一番混雑する車両です」

嫌なアナウンスだな(笑)。
一番後ろだと乗れない可能性もあると思い、
仕方無く少し前の方の車両に乗る。
でも、大して混んでなかった。奴らの脅し(？)に屈する事は無かったぜ。

--- 復帰 ---
しばらく今の駄目プロジェクトにしか関わってなかったんだけど
とりあえず今週からちょっと(いや、かなり)稼働も空いたので
以前まで携わってた某プロジェクトにも参加することになった。
とはいえ、こっちも相当なヘボプロジェクトなんだけど。
この現場はこんなんばっかりだ。期待するだけ無駄だろう。

何しろ担当はあの超ド級機械オンチのイネムリ君だ。
今日も早速作業頼まれたんだけど、あまりのダメっぷりに撃沈。
ちなみに彼は、1日で出来るような作業を
1週間位の工数に引き伸ばすという特技を持つ(笑)。

--- 今日のスロー君 ---
さて、今日のスロー君は珍しくテンパってないです。
ここで、スロー君の一日の行動を比率で表してみよう。

40％ : 考えている
10％ : 寝てるんだか考えてるんだかわからない状態
10％ : 席を離れている(主にタバコ)
3％ : ウロウロしている
2％ : ショージ君に怒られている
20％ : ボーっとしている
15％ : キーボードを叩いている(メールやドキュメントを書いている)

こんな感じだ。マジでっせ。

--- 最後の最後で ---
帰ってサッカーを見る。
いつもの展開。チャンスが何回もありながら点を奪えず
はぁ、また0-0か…と思っていた後半ロスタイム間際。
松井のヘディングで待望の先制点。
そしてそのまま日本は勝利した。
やっぱり最近はこういう「諦めない」ところが変わったよね。
欲を言えばもう少し試合序盤から安心した展開ってのも見てみたいもんだけど。

--- 永遠のライバル？ ---
続けて女子バレーボール。宿命の日韓戦。
が、今年の韓国は以前までの「永遠のライバル」という雰囲気が無い。
選手の入れ替え途中らしく、まだチームとして固まっていない。
次のオリンピックに向けての調整時期とはいえ、
ここまで弱くなった韓国には正直がっかりだね。

今年は日本が4連勝。
もはやライバルではなく「お得意様」になっている韓国。
今日もストレートで日本が完勝。
韓国は監督に問題あるんじゃないかなぁ。

先日JavaOne Tokyoが開かれた。
Javaが登場してから10年。今Javaは次世代への進化を問われている。
そして、いくつかの変化が起きようとしている。

--- オープンソース化 ---
今まで、JavaといえばSunの独壇場だった。
IBMもjikesなどを作って善戦してはいたようだけど。

ついにGNUがJavaの実装を開発し始めた。
「GNU Classpath」と呼ばれるこのプロジェクトは現在
Apacheグループとも連携して
JDK1.2レベルでかなりの互換性を達成するところまで来ているらしい。

SunもJavaコアソースの公開を始めたが、そんなものGNUが求める
「Free」の定義には遠く及ばない。
JavaがSunの独占状態になる前に、GNUは「Free」なJavaが必要だと考えたのだ。
これは大いなる決断であり、Javaが今後の開発をリードしていく事の証しとも言える。

まだまだ時間は掛かるが、今後はさらに多くのプロジェクトが
Javaで開発されるようになってくるだろう。
そんなとき、Sunが突然Javaの使用にライセンス料を課したら
どんなことになるか。誰でも想像は付くと思う。
自分の身は自分で守れ。GNU Javaの登場はそんな不安を解消してくれる。

--- 拡張構文 ---
SunはJDK5.0(1.5)で大幅な言語拡張を行った。
Enum(列挙型)、Annotation(注釈)、Generics(C++テンプレートのようなもの)…等々。
これらは開発効率を上げるために導入された構文で
僕は今実際にこれらの構文を使っているが非常に便利だと感じている。

しかし、前述したGNU JavaはまだJDK5に対応していない。
EJB 3.0など、Annotationを使ったプロジェクトは
今後のスタンダードになることは確実なので、いずれ何らかの形で
GNU Javaがこれらの実装をすることは予想できる。
しかし将来、両者のJavaは少しずつ別々の道を歩むかもしれない。

僕は今のところ、JDK5に頼った開発をしているから
GNU Javaに移行することは出来ない。
まだしばらくはSunのお世話になりそうだ。

--- その先は… ---
Sunは既にJDK6.0の開発を進めている。
このバージョンでは今まで以上の機能追加がされるそうだ。
正直、最近のJavaは肥大化し過ぎている。
便利になるのは良いことだが、
それによって起こる弊害の可能性もまた増えるのだ。

なんか今日は午前中から
やけにたくさんやる事がある。
いつも午前中はぼーっとして過ごすのが日課なのに。

--- ボジョレ解禁 ---
さて、今日の午前0時にボジョレが解禁になりました。
なぜか僕はコンビニで予約していたので(ぉぃ)
昨日の深夜に行って買ってきても良かったんだけど
それやると今日現場に来れなくなる可能性が高かったんで(笑)
我慢しました。
今日は帰りにでも買って帰るぞぉ！

--- わかりやすい奴 ---
なんかプロジェクトで不具合が出たらしく、
イネムリ君は珍しく作業をしている。
それにしてもわかりやすいね。
作業してるときだけ急に独り言が多くなる。貧乏ゆすりしたり。
いつも何もしてないのがバレバレだ。

--- 僕だけ？ ---
早速ボジョレを買いに行く。
予約したボジョレはレジの後ろの方に置いてあるようだ。
その数、1本…って俺だけかよ(笑)。
もしくは昨日の夜中に買った人間がいるとか。

まぁ何にせよ、別に予約なんかしなくても買えるので
わざわざ予約する必要は特に無いよな、正直。
でも万が一ってこともあるしね。

この現場は、以前から言っているように共有サーバを使っている。
だから自由にソフトウェアをインストールすることが出来ない。

例えば今、僕は相当に暇だ。
本来ならこの時間を利用して様々なソフトウェアを試してみたい。
しかしこの現場ではそれが出来ない。
これだけの時間を無駄に過ごす事が、僕には苦痛だ。
こんなんじゃ社員(僕らのような派遣も含め)は成長しないよ。

ニュース見て最新の動向調べるだけじゃ不十分なんだ。
実際にその新技術を使ってみて
果たしてどれくらいの価値があるのかという事を
見極める必要がある。
そのためにはそれらのソフトウェアを
自由にインストールする環境が必要なんだ。
そしてもちろん、それを実行するだけの余裕がね。

--- 過剰セキュリティの罰 ---
最近、大企業はますますセキュリティを厳しくする傾向にある。
相手先からの信頼を得るためには仕方が無いって？

とんだ勘違い君だ。
それによって企業はさらに技術力を失っていく。
そんな企業を信頼する相手先もどうかと思うね。
ISMS持ってるから安心？そんな安心、インチキ占い師の言葉以上に
アテにならないんだぜ。

形ばっかりにこだわらないで、成果を出すものを信頼すべきだ。
それが資産となり、世界で生きていく為の財産になる。
小手先ばかりの知恵ばかり付けても、本物の力にはならない。

朝、いつものように現場ビルのエレベーター前で待ちぼうけ。
ここのエレベーターは非常に頭が悪い。
7台もあるのに、そのうち同時に開くのは一つだけ。
こんなんだから朝は毎日長蛇の列。

ようやく次のエレベーターが到着。
続々と人が乗り込んでいくが…誰も「開」を押しやがらねぇ。
一体こいつらの神経はどうなってんだ。
非常識な人達だね。そのうちドアが勝手に閉まって
挟まれることになる人の気持ち考えたこと無いんだろうか。

最初に乗った人が「開」押すのって常識じゃねぇ？
なんかこういう非常識な奴らが多い。
自分だけ良けりゃいいって考え。
それによって周りを不幸にしてるって事に気付いてよ。

--- 金曜の朝 ---
なんかうちのメンバーは金曜になると少なくなる。
今日も半分くらいしか来てない。
そういやスロー君は休み取ったんだっけ。

そしてショージ君はいつものように遅刻だ。
とんだリーダーだな。
俺が入ったときは時間厳守って言ってたくせに
自分が守れてないもんね。
こんなリーダーに付いていく人間は一人もいないよ。

--- 避難訓練 ---
今日は現場のビルで避難訓練があるようだ。
しかも全館一斉に。
面倒だなぁ。まっ、暇だから出るとするか。

ってちょっと待てよ。
避難訓練ということはつまり、
僕達は非常階段で二十何階か降りるって事？
体力もつかな(笑)。

…と思ったら、代表者だけでいいらしい。意味ねー。
このビルの非常階段は狭いから、実際に災害が発生したら
皆生き埋めだね(洒落になってない)。

何か隣でゴチャゴチャもめている。
新システムの設計をしてるらしい。

今問題になっているのは、パフォーマンスの話。
リクエストが発生する度にあるデータを取得する処理があるのだが
そのデータはDB上に置かれている。

で、毎回DBにアクセスするか、
メモリにキャッシュしてそれを参照するかどうかを決めかねている。
キャッシュすればパフォーマンスは上がるが
実装は複雑になる。

--- 抽象化のススメ ---
僕からの回答は「今決める必要は無い」だ。
こういう細かい実装は、今机上の空論を語り合っても
何の意味も無い。
実際のパフォーマンスは実際にシステムを構築しない限り
正確な値は出ない。
もちろんある程度の予測をする事は大切だけど。

こういう事を解決するためにオブジェクト指向があり、
抽象化という概念が存在するのだ。
パフォーマンスの事を考え、それに対応できる作りにしておく。
始めからキャッシュしてしまう必要は全く無いのだ。
プログラムは出来るだけシンプルに。
必要ならば、キャッシュ機構を後から「注入」すれば良い。

こんな事言うと、
「前はパフォーマンスの事を始めから意識しろって言ってたくせに」
という意見が聞こえてきそうだ。
もちろん、意識をする事は大事。
意識した作りにしておけば大丈夫って話。
始めから全てを実装しておく必要は無いのだ。

--- 機能注入 ---
機能を注入するという考え方は今DI(Dependency Injection)として
注目され始めているが、別に新しい技術というわけではない。
確かにJDK5で導入されたAnnotationにより
このDI技術はより使いやすくなったとは言えるが。

ただ、注入といっても必ずしも機能を別クラスに分ける必要は無いし
単純に既存クラスを改造するだけでも良い。

キャッシュというのは汎用的な作りにできるほど
シンプルには出来ない。
パフォーマンスを重視するためには、
クラスの再利用化が出来ない場面だって沢山あるのだ。
物事は、臨機応変にね。

昨日は毎月恒例、会社の食事会。
僕はここ入ってから皆勤賞なので(笑)
結構知った顔も多いんだけど、今月から入った人も何人かいた。

で、その人曰く。「同窓会みたいですね」
何か雰囲気がそんな感じだったらしい。
実際は皆知り合って数ヶ月程度だけど(笑)。
この時くらいしか顔合わせないメンバーなのに、
意外と話合うんだよね。

先月くらいから二次会も普通にやるようになったらしい。
今回も15、6人が参加…って、多くねぇ？(笑)

--- 3人 ---
さらにその後、飲み足りなくて三次会に突入。
これが失敗だった(笑)。
男3人で行ったもんだから、何となく嫌な予感はしてたんだけど。

いきなり僕以外の二人がトークバトルし始める。
かなり激しいぶつかり合いだったんで
なだめるのに必死だったよ。
その後今度はそのうちの一人が俺に絡んできて…
なんか前もあったな、この構図(笑)。

二人とも僕よりかなり年上だからねぇ。
どうも年上の奴らってのは年下に説教をしたくなるらしい。
自分が今まで生きてきた事を反省してか知らんが
それを他人に押しつけようとする。

僕はその考えがわからん。
自分の生き方が他人に通用するわけないでしょ。
まぁでも人の話は聞いた方がいいという事もあるし。

--- 暖房器具 ---
最近ますます寒くなってきて、
とうとう我が家も暖房器具を出すことにした。
冬はあまり好きじゃないなぁ…

さて、今のプロジェクトでこんな出来事がありました。
Web画面で情報を検索して表示するという
よくあるシステムでの話。

検索条件には複数の項目が指定できる。
「社員コード」とか「電話番号」とか(あくまで例)。
で、通常これらの数値ってのは半角で扱われる。
だからWeb画面の入力欄にも丁寧に「(半角)」と書いてあった。

正確に言えば、この欄に「全角」で入力をした場合
検索に引っかかるレコードは存在しない。
全角で登録された電話番号なんて一つも無いんだからね。

でも、Webプログラム側で全角を半角に変換してやれば
ユーザが間違えて全角で入力してしまった場合でも
それは自動的に半角に変換されて検索が成功する。

--- 仕様に拘る奴ら ---
さて、本題。
今回のシステムでは、この自動変換を「親切」にやっていた。
しかし、監査側がテストしている際にこの親切を「バグ」だと言い出した。
画面に「半角」って書いてあるんだから、半角でのみ検索すべきだ、と。

僕らは、何のためにシステムを作っているのか。
それは、使う人が便利になる為。
この自動変換をすることよって、使う人が不便になる事など何も無い。
逆に、変換をしない事は一部の「全角も半角もよくわからない人々」にとって
非常に不親切である。

百害あって一利無し。
こんな仕様を「正しい」と思う奴らは、使う人達の事を何一つ考えていない。
「俺達が正しいと思うものが正しいんだ」という
乱暴な考え方しか持っていないんだ。

こういった、自己中心的な考えをする奴らがこの業界にはたくさんいる。
システムを作る側、それを監査する側、使う側。
それぞれが歩み寄る必要があるのに。

正直、すっかり最近彼女の事を忘れていた。
シドニーでの劇的な優勝が、彼女のピークだと思っていた。

度重なる怪我。
アテネの選考会で2位に終わり、代表からも落選。
僕は、人々は彼女の存在を忘れ欠けていた。

--- 自己管理 ---
本来なら、去年末に出るはずだった試合で彼女は復活を遂げるはずだった。
が、その試合直前でまさかの「減量オーバー」。
本来の体重から激減していた彼女の身体は
42.195Kmを走れる状態では無くなっていた。

小出監督は食事については彼女に任せていた。
「もう30も過ぎて、自己管理くらいは自分でやるだろう」、と。
しかし彼女は甘えていた。
「監督がいるから、見てくれていると思った」、と。

--- 好きなこと ---
「かけっこが大好きなんで」
そう話す彼女の瞳は純真だった。
でもそれは、プロとして生きていく上では時として障害になる。

そして彼女は決断した。
監督から旅立ち、自分で生きていこう。
少しのスタッフと共に、この大会を目指して練習を重ねてきた。

僕はこの大会を始めから見ていなかった。
それほど注目もしていなかったし、彼女の結果に興味も無かった。
しかも、またしても直前になって足を怪我したという情報も入る。
そんな彼女の走りに、僕は期待していなかった。

--- 5年前の再現 ---
偶然見ていたテレビで、彼女が走っていた。
30Km地点。トップ集団の3人の中に、彼女はいた。

何か、やってくれるんじゃないかと思った。
僕は夢中で画面に見入っていた。

35Km地点。突如、彼女が集団を飛び出した。
まるで5年前のシドニーを思い出すかのような、
誰をも寄せ付けないスパート。
その彼女の姿に、僕は身震いした。

--- 感動の瞬間 ---
高橋尚子が優勝した。
やっぱり彼女は、人を感動させる力を持っている。
彼女の生きることへの力強さが、そうさせてるんだと思う。

また、彼女の時代がやってくる。
そんな予感がした。

--- 一息ついて… ---
っていうか熱過ぎです、俺(笑)。
でもね、それくらい感動したって事なんよ。

明日からまた仕事かぁ。がんばるぞ?。
っていってもする事ないけど、多分(笑)。

SunがSolarisでPostgreSQLをサポートするようだ。
僕が今いる現場では、かなりサポートを重要視するらしい。
しかし僕は言いたい。「サポートって、そんなに重要ですか？」

例えば、OSにバグがあったらそれのパッチを出すのは
非常にわかりやすいサポートだ。
しかし、OSに付属するDBをサポートするっていうのは
意味がわからない。おそらく
「OS(Solaris)が原因と思われるバグがPostgreSQLで発生したら対応する」
ということなのだろう。

このサポートが、一体どれほどの人に恩威を与えるというのか。
Oracleなどと違い、PostgreSQLはオープンソースだ。
ほとんどのOSで使われているし、テストもされている。
今さらSolaris特有のバグなど、そう出るはずも無いだろう。
出たとしたらそれは、PostgreSQLのバグではなくSolarisのバグなのだ。
それをSunが直すのは当然と言える。

--- サポート無への不安 ---
現在、ほとんどSolarisユーザはDBとしてOracleを使っているはずだ。
この「サポート」を機に、PostgreSQLに乗り換えるユーザも多いだろう。
一体、このサポートで何の安心が得られるのかが僕には判らない。
もちろん、Oracleのサポート受けてたって状況は同じだが。

Oracleのサポートで恩威を受けている人達は、その真実を知らない。
彼らは「Oracleが出したバグで遭った被害をOracleによって助けられている」
に過ぎないのだ。

始めからOracleがバグなど出さなければサポートなど必要無い。
しかし、数々のバグが当たり前となっているOracleユーザは
サポートが無い他のDBを恐くて使えないのだ。

今後Postgreに乗り換えたユーザは、
特にサポートなど必要無いことに気付くだろう。
僕はほとんどPostgreを使ったことは無いが
オープンソースとしてここまで発展してきたPostgreは
MySQLに匹敵する安定性を持っていることは期待できる。
そうでないと、この世界ではやっていけないのだから。

早く、偽りのサポートでユーザを騙している企業を捨てるべきだ。
これらの企業はわざとバグを出し、サポートすることで金を稼いでいるという
最低の「自作自演」者に過ぎないのだから。

--- 良いものを選ぼう ---
もっと良いものがある。
金の為ではなく、僕らの生活を便利にするためにソフトウェアを作っている
素晴らしい人達がたくさんいる。
彼らの作るソフトウェアはバグも少なく、
ユーザを便利にするために様々な工夫が凝らしてある。

そしてもちろん、万が一これらのソフトウェアにバグが発生したら
彼らは全力をもってそれに対処してくれる。
自分の作ったソフトウェアにバグが見つかったら、それを放置しておく事など
彼らのプライドが許さないからだ。

ソフトウェアのサポートなんて、大抵の場合必要無いのだ。
生命保険とは訳が違う。
サポートは何の保険にもなりゃしないのさ。

--- オープンソース推進派へ一言 ---
最後に。企業でオープンソースを使う人達に一言言いたい。
ただ「無料だから」という理由だけで、オープンソースを使わないで下さい。
彼らは自分の時間を削ってソフトウェアを開発しているのです。
皆が自由になる為に。

そのソフトウェアで得た利益を是非、彼らに寄付しましょう。
それが、彼らに対するせめてもの礼儀です。
そうしないと、今後そのソフトウェアは
保守されなくなってしまうかもしれません。
それによって苦しむのは、あなた方なのです。

寄付という形が企業として難しいのならば
その団体とサポート契約を結びましょう。
これこそ、本来のサポート形態です。

うぃーっす、風邪ひいちまった。
今日はとりあえず休む。
急に寒くなったよなぁ。

現場のメンバーが遅刻してくるらしい。
本人から現場のML(メーリングリスト)に連絡があった。
が、その理由がウケる。

「本屋に寄っていくので、遅れます」

こいつアホだな。
たとえ本当でも、そんな私的な理由言う奴いるかよ。
本屋なんていつでも行けるだろ。
現場の近くにだっていくらでもあるし。

--- 流行中 ---
やっぱり現場でも風邪が流行ってるらしい。
普段でもそうだけど、風邪のときは特に喉が敏感になる。
タバコの人間からは極力離れるようにしたい。
あの匂いは喉に浸みるんだ。

--- 典型的日本人 ---
まぁ自分も日本人なんで、こんな事言うのもあれですが。
僕はどうも典型的日本人タイプの人と合わない。

仕事で自分の言いたい事も言わず、相手にはヘコヘコ頭を下げ、
付き合い残業する事を正常だと思い、
結果ではなく表面上の形(体裁)を重視する。

和を大事にすること自体が悪いことだとは言わんけど
それしか見てないのはどうかと思うよ。
結果(利益)出してナンボでしょ、仕事ってのは。
でも逆にそれしか見てない奴ってのも困るんだけどね。
う?ん、難しい問題だ…

最近、いくつか情報流出のニュースを聞く。
そのどれもが、超初歩的なセキュリティ対策漏れによるものらしい。

例えば、Apacheのセキュリティ警告がもう何年も前に出されているのに
アップデートしてなかったり。
ユーザからの入力をそのままSQL文に使用してたり。
こんな単純な事、別にセキュリティ専門者じゃなくても
当然の認識として持ってるものだ。

開発者内にそういう事を知ってる人間が
一人もいなかったって事は大問題だね。
皆、もうちょっと勉強しようよ。

「自分とこは大丈夫」なんて思ってるわけじゃないよね？
仮にも顧客情報にアクセスしてるサイトなんだから
それじゃ余りにも無責任だよ。

う?ん、まだどうも風邪が直らないなぁ。
昨日遅くまで起きてたのがいけなかった。
今日は早く寝るぞっ。

とりあえず禁酒です。
せっかく直りかけてたのに、一昨日飲んでしまったせいか
また具合が悪くなってきた。
仕事行けない程じゃないけどね。

飲む事自体が悪いっていうより、飲むと熟睡できないのが問題。
昨日もせっかくの休みなのに朝早くから起きちゃったし。
昼寝でもできればよかったんだけどなぁ。
やっぱ睡眠は大事だよ。

--- 本末転倒 ---
さてさて、現場ではまた動きが。

発注元である会社が、仕様書とソースの提供を依頼してきた。
で、ここからが面白い。
仕様書に合っていないソースを修正させる気でいるんだって。

笑っちゃうね。
もう実際にシステム動いてるんだぜ。「ソースの通り」に。
それを今さら「仕様書の通り」に直したらどうなるか、
想像しただけでも愉快なことになりそうだ。

--- 急なんです ---
向こうの依頼ってのはいつも急なんだ。
今日までに仕様書提出しろって？
ほら、またそんな無茶な要求出すとスロー君がテンパるだけだぜ。

よりによって今日はショージ君が風邪でダウンだ。
スロー君は何をする事も出来ずただ固まっている。
お地蔵さんみたいだ(笑)。
そのうち精神疲労で倒れるかもな。

--- 終業チャイム ---
最近この現場では、終業時間になるとチャイムが鳴る。
「○時○分になりました。終業時間です」ってね。
これで、何の気兼ねも無く帰れるって訳だ。
…嘘つけ、そんな放送無くたって気にせずに帰るくせに(笑)。

朝の電車が遅れている。
いつも乗る電車に乗ろうとするが、メチャクチャに混んでいる。
無理だ。乗りきれない。
仕方無く次を待つことにする。

すぐ各駅停車電車が来るが、せっかく1本待ったんだ。
次の快速に乗ろう。その方が早い。

しかし、次の快速が来る前、駅にアナウンスが流れた。
「次の快速電車は非常に混雑しております。
乗れない場合もございますのでご注意下さい。」

そのアナウンス遅ぇよ。
そういう事はさっきの各駅電車が来たときに言ってくれ。
結局次の快速にも乗れず、さらにその次の各駅に乗ることにする。
こんな事ならその前の各駅乗ってればよかったよ。

そして連鎖反応のように、乗り換え先の電車も混んでいる。
ホームが人で埋まっててうんざりするが、
とりあえず強引に乗り込む。
さっきの電車に比べりゃ全然余裕だぜ。
ここで待つわけにはいかないのだ。

--- 原因は？ ---
イネムリ君が死にそうです。
風邪？それともいつものように飲みすぎか(笑)？
こいつは体調悪いと独り言が多くてうるさい。
周りに迷惑だから帰ってほしいよ。

かなり現場では風邪菌が蔓延してるらしく
皆調子が悪いようだ。
そのせいでほとんど作業が停滞している。
僕はそれなりに元気なんだけど、いかんせんやる事が無い。
もう帰って寝たい。

現在サーバとして動いているRedHat 7.2にMySQL5をインストールしてみる。
Debianでインストールするときは何の障害もなくうまくいったんだけど
やはりサーバマシンは古いので色々と足りないモジュールがあるようだ。
glibcの2.3.2以上が必要と言われたので、まずはそこからやってみることにする。

まずはgcc。
新しいglibcをインストールするにはgccも新しくする必要がある。
gcc4系列もあるんだけど、とりあえずちょっと自信無いので
3系の最新である3.4.4にしてみる。

ftp://ftp.gnu.org/pub/gnu/

続いて、binutils。
最新版の2.16.1をインストールする。
コンパイルはいつものようにconfigure, makeでOK。

ただ、このままだとインストールしたファイル群が
/usr/local/bin 以下に配置されているので
PATH設定により /usr/bin 以下のバイナリが実行されてしまう。
/usr/bin にコピーする手もあるが、それやって取り返し付かなくなると困るので
とりあえず環境変数のPATHを修正して /usr/local/bin を優先させるようにした。

さて、ここでようやくglibcのインストール。
が、どうやらLinuxのカーネルが古いらしく
linuxthreads が使えないという警告が出た。
--disable-sanity-checks
というオプションを付ければとりあえずOKらしいが、
せっかくなのでカーネルもコンパイルしてみる事にする。
カーネルコンパイルはこの前Debianでやったので大丈夫かな。

--- いつの間にか… ---
とか何とかやっているうちに、何故かMySQLが落ちている事に気付いた。
原因は不明だけど、ソケットファイルが消失している。
MySQLサーバ自体は動いているようだ。

ソケットファイルが消失すると、mysqladminからシャットダウンすることが出来ない。
仕方無いので、プロセスを見てmysqlプロセスを全てKILL。
これでうまくいった。
あとは通常通りMySQLを起動して完了。

--- カーネルコンパイル ---
さて、一騒動あったところでカーネルコンパイルに取り掛かることにする。
最新の2.6.14.3を落としてみる。

make menuconfig
make clean
make bzImage

ここでも先程のPATH設定をしないと
最新のgccなどが使われないのでうまくいかなかった。
カーネルコンパイルにもそれなりに新しいglibcのバージョンが必要なようだ。
コンパイルには相当の時間が掛かる。
その間に酒でも飲みましょう(笑)。

--- カーネルコンパイル(続) ---
よし、ではカーネルコンパイル再開。
make bzImage までは完了しているので、あともう少しだ。

# make modules
# make modules_install
# make install

make installでエラーが出るが、liloの設定を書き替えようとしているので
とりあえず無視して大丈夫らしい。うちはGRUBを使っている。
/boot 以下に vmlinuz-xx と System.map-xx がコピーされたが
initrdが無い。
Debianのときもそうだったが、どうやらこれは別コマンドを使えば作成できるらしい。

# mkinitrd /boot/initrd-2.6.14-3.img 2.6.14.3

これで、/boot 以下に initrd が作成された。
あとは /boot/grub/menu.lst を編集すればOK。

title Red Hat Linux (2.6.14.3)
root (hd0,0)
kernel /vmlinuz-2.6.14.3 ro root=/dev/hda5 hdc=ide-scsi
initrd /initrd-2.6.14-3.img
savedefault
boot

こんな感じで。

--- 無念 ---
早速新カーネルで再起動。
…が、ネットワークデバイスの認識に失敗している。
時間掛けて調べれば解決できるとは思うが、
サーバマシンを長い間つながないってのは
どうも落着かないので、今回はとりあえずここまで。

もともとglibcのコンパイルにカーネルが必要だっただけなので
設定を変えて再度glibcをコンパイルすることにしよう。

% ../glibc-2.3.6/configure --disable-sanity-checks

が、うまくいかない。
スレッド関連のコンパイルに失敗している。
うむむ、どうしよう…

原点に戻って考えてみる。
MySQL5を動かしたいという今回の目標に立ち戻って、
再度MySQLのダウンロードページを見てみる。
すると、ちゃんとglibc-2.2用のバイナリもあるではないか。
これを使えばうまくいくに違い無い。

…ふぅ、何なく成功。
初めからこっち選んどけばこんな苦労しなくても済んだのにな?。

う?む、どうも最近仕事やる気が出ない。
っつーかやる事がほとんど無い。

現在任されている仕事は、
例の工数引き伸ばし大作戦チーム隊長(←そんなチームは無い)から
振られているものなので
急いで作業してしまうとあっという間に終わってしまう。
30日近い工数が割り振られてはいるものの、
おそらく全力でやれば3日で終わってしまいそうな
しょーもない作業だったからね。

他に仕事振ってもらおうにも中途半端な時期らしく
片手間で受けられるような仕事は無いようだ。
とりあえず今日は休む。
行っても暇なのは目に見えてるから。

来月くらいになれば別のプロジェクトも始まるらしいから
そのときまで我慢…するしかないかなぁ。
とりあえずやばい位に暇なんである。

いよいよフィギュアスケートの終盤戦。
それにしても今年はロシアのスルツカヤが強い。
あんな点数出されたら誰にも勝ち目無いよ。

少し前から採用されている、この新採点システム。
過去の6点満点じゃなくて、各技に点が付けられていく。
で、なぜ彼女が強いか。
それは、新システムでは「コンビネーションスピン」に
高得点が入る仕組みになっているのだ。

ジャンプも決めれば高得点になるけど、失敗すると
それは致命的とも言える減点になってしまう。
スピンは、ジャンプに比べれば失敗する確率が低い。
だから選手達は難易度の高いジャンプを封印して
演技を構成してきた。

そんな中で、難易度の高いビールマンスピンを持つ彼女は
圧倒的に有利となる。
もちろん演技も素晴らしいけど、それだけじゃ
あの高得点は説明できない。
以前までのシステムでは難易度の高いジャンプを決めないと
高得点は出なかったからね。

でもこれによって、多少ギャンブル性が減ったと思うのだ。
確実なジャンプに、確実なスピン。
大博打をして4回転ジャンプを成功させても、大した加点が得られない。
だから誰も無理をしない。
ちょっと物足り無さを感じるんだよなぁ。

--- 開発環境 ---
さて、3連休も終わり今日からまた仕事です。
とりあえず、次の仕事に取りかかる。
ようやく腐ったACCESSやASPから離れたJavaの開発だ。
しかし僕は重要な事を忘れていた。この現場の最悪とも言える開発環境を。

ローカルマシンが与えられてない上に、共有サーバでEclipseを
立ち上げることも出来ない。
さらに、与えられたノートPCはメモリが256MBしか無いだけでなく
ネットワーク環境に繋ぐには別の島に行ってケーブルを繋ぐ必要があるので
これも却下。

結局、ローカルでファイルを編集(しかも通常のエディタで)して
それをFTP経由でサーバにアップロードしてから
サーバでAnt実行してwarファイルを作って毎回デプロイするという
信じられない位に手間の掛かる開発作業となる。

確かに、こんだけ酷い環境で作業してりゃ
それなりの工数も掛かるよ。
ローカルで開発できれば、工数は1/3位まで縮められるのに。
っていうかマジ苦痛だ。こんな手間の掛かる開発ってのは。

…久びさ専門用語バリバリの日記で失礼。
プログラムの方に書こうかとも思ったけど、一応現場の話だし。
まっ、こんな回もあるさ。

家の環境では、JavaソースチェックにCheckstyleを使っている。
これは、ソース中のあらゆるチェックを行ってくれるもので
例えば「Javadocコメントが付いているか」とか「インデントは合っているか」
など様々。詳しくは ここ を参照。

これをやっていると、常にソースの質を上位に保つことが出来る。
個人でやる分にはそれほどメリットは感じないけど
大きなプロジェクトなんかでは相当の威力を発揮するはず。
汚いソース書いてる奴はすぐにチェックに引っかかるだろう。
でも、これを実践してる現場は未だかつて見たことが無い。

Eclipseのプラグインで一つバグ報告を。
文字コードをUTF-8にしてると、エラーが発生する。
これはおそらくマルチバイト文字列を2バイトに仮定してるものだと思われる。
UTF-8は1文字3バイトになるからね。
ここはちょっと注意。次のバージョンでは直ってることを祈ろう。
…っつーかバグ報告出せばいいんだけど。
どうもまだ英語サイトに投稿する勇気が無い。
返信されても読めないと困るからなあ。

さて、昨日は我が現場の惨憺(さんたん)たる現状をお送りしたわけですが
今日はまた別の環境問題が発覚。
現場が乾燥し過ぎている。

そのせいで休む人が続出。
ショージ君とスロー君は揃って休み。
そして例のナメた新人君(っていっても歳は上)は
午後2時から来るというメールを午後になってから送ってくるという
暴挙に出た。

こういう奴には一言言っとかないとね。
彼が来ることを想定していたリーダーが困り果ててるよ。
このリーダーだって風邪をおして来てるのにさ。

というわけで、加湿器でも買ってくれという意見が
一部で勃発したようだ。
いや、でもマジで必要でしょ。

この現場では未だに多くのプロジェクトで
絶対パスが使われている。
つまり、特定のディレクトリに入れないとシステムが動かなかったり
インストールディレクトリに合わせて
設定ファイルのディレクトリ記述を(大抵の場合、何箇所も)
修正する必要があったり。

こんな作りは、当然のことだが止めた方がいい。
相対パスにしておけば、その後の管理がずっと楽になる。
設定ファイルにディレクトリの一覧をずらずら書くのもどうかと思う。
せめて、デフォルト値を設定しておいて
変更があるディレクトリだけ記述するとかにしてほしい。

設定ファイルの記述を1箇所間違っただけで
システム全体が動かないとか、そういうのもある。
だったらそのエラー内容を、ユーザにわかりやすく表示する仕組みを作りなよ。
今後保守する事を考えたら、そういった親切な作りはとても大事なのだ。

作る方の都合しか考えてないから、こういうシステムになってしまう。
ちょっとは使うユーザや管理者の事考えて作ろうよ。
作ることでいっぱいいっぱいなんだろうけどさ。

お?い、何だってんだ。
今日になっていきなり大量の仕事依頼が舞い込んできた。
ショージ君が言う。「○○君(←僕)、悪いけど今週は残業だな?」。
へっ、それを時間内に終わらすのが俺の役目だぜ。

最近は仕事無くて身体なまってたからね。
こんな時こそ集中して仕事すれば
効率もいいし暇じゃなくなるし。

--- ダメ君 ---
あ?あ、スロー君のダメっぷりにショージ君がキレかかってる。
かなり危険な状況だ。口調が荒い。

さらに、障害対応グループの対応が悪いらしく
ショージ君の怒りはMAXモードに突入だ。

--- 高稼動 ---
ふぅ、今日は珍しく一生懸命仕事に励んだ。
ちょっと気合入れてやり過ぎたので少々疲れた。
明日は…また暇かなぁ(笑)。