@ITの記事より。
日本企業では「付き合い残業」が日常的に行われているという。
ほんと、こいつらは大馬鹿もんですな。

彼／彼女らに「何のために働いてるんですか？」という問いを投げかけたい。
企業の利益を上げるために仕事するんでしょ。
残業した分、きちんと利益につながっているって言い切れる人ならいいけど
そうでない人は企業に何も貢献していないどころか
利益を減らしている事になる。

そんな事態を引き起こす「付き合い残業」を正当化している企業は
大企業に多いという。そんなんだから赤字が増える一方なんだよ。

--- 本当に和？ ---
別に僕は残業を否定してるわけじゃない。
勤務人数、成果物の量、納期などを見比べて
本当に必要ならば残業すればいい。
何の考えもなくただ「皆残ってるから」などという理由で残業するのは愚の骨頂だ。

日本人なんだから「和」を大事にしろって？
そんな偽物の和は要らないね。
皆の作業を確実に分担していって、皆の残業時間を減らす方が
よっぽど皆の為になるでしょ。

やる事もないのに残業していたら
その人の本当の作業量が見えてこない。
だから、その日の作業が終わったらとっとと帰るべきなのだ。
もしくは、終わってない人の作業を引き受けるか。

--- 64Bit ---
何やらMicrosoftが64Bitで騒いでいる。
64Bitになったからって、実際は何にも変わりゃしないよ。
一部のハードウェア大好き人間以外はね。
ソフトウェア開発者はそんな事全く歓迎しない。
また一つ対応しなきゃいけない事項が増えただけじゃないか。

もっとも、Java使ってる僕には何の弊害も無いけどね。
64Bitに対応したJavaVMがリリースされるだけで、
僕らが今まで作ってきた全てのJavaプログラムは64Bitの環境で
最大限のパフォーマンスを発揮するように動作するんだから。

--- 夏休みは？ ---
なんか最近、朝の電車が異常に混んでいる。特に西武線。
学生が夏休みに入ったからもっと空くもんだと思ってたのに。
なにかあったの？

さて、現場は大変らしいです。
僕は特に作業も少ないので楽だけど、どうやら定時近くから会議があるらしい。
これじゃ残業確定だなぁ…まぁいいや、この隙に日記でも書いとこう。

が、その時間にすら会議が始まらない。
どうやら相手先の人間が遅れているらしい。
時間にルーズな人間ってのは、全てにおいて駄目な奴が多い。
そして、それは一生直ることは無いのさ。
過去にそんな奴らを山ほど見てきたからね。注意しても無駄って事。

…会議終了。
予想通り、進行が遅くてうんざり。
もっとテキパキやってくれよ。
さっさと帰ろうっと。

さて、先週あたりから現場は次のフェイズに突入。
詳しい説明は面倒なんで置いとくけど、
別の開発会社に丸投げしてたプロジェクトが
どうにも駄目駄目なので
僕らのチームからその開発会社に数人送り込んで
プロジェクトを成功させようという意図があるらしい。

というわけで、先週の後半くらいからは
その相手先の会社に行って開発作業。
作業内容も納期も担当箇所も既に決まってるので比較的楽かな。
ただ、納期が8/19なのでお盆休みは遅れて取ることになりそうだ。

今日も本当は出の予定だったんだけど
そこまでしなくても余裕で納期には間に合いそうなんで
出るのは止めることにした。

相手先に一緒に行っているメンバーは僕も含めて3人。
一人はまあまあ出来そうなのだが
残り一人のオッサンが今だ実力未知。
知識ビンボーな雰囲気なのでちょっと心配なんだけどね。
まぁいざとなったら僕が引き受ければ済む話か。

横浜の佐々木が引退した。
清原との最終対決。あれ何ですか？

まぁ予想はしていたけど、去る者に華を添えようっていう
見え見えのイカサマ勝負は見ててうんざりする。
2ストライクからの最終球。
明らかにストライクコースを外れた球を清原が三振。
始球式かっつーの。

--- 悲しい風習 ---
こういう悪い風習って日本にはまだあるよね。
それで満足してる佐々木に一番の責任があるとは思うけど。
僕が同じ立場だったらそんな事許さないね。
帽子叩きつけて怒鳴るよ。「そんな球空振りしてんじゃねぇ」って。

シアトル・マリナーズで引退したエドガー・マルティネス。
彼の引退試合はある意味すごかった。
相手投手の本気のピッチングに、エドガーは全打席凡退。
でもそれが、プロ本来のやり方だと思うんだよね。

--- 形にこだわる人々 ---
こういう類の奴ってのはこの業界にも多数いる。
形ばかりにこだわって内容が伴っていない奴。
そういう奴のほとんどが、実力無い事への穴埋めだったりする。
外見に執着する人間ってのが僕は嫌いだ。

どんなに優れた外見を持ってても、僕はそんなものに
何の興味も抱けないし何の感動も与えられない。
人でも、物でもね。

さて、今年もまたお盆返上で仕事です。
別に忙しいわけでは無いから気が楽なんだけどね。

--- ゲーム ---
なんか暇だったのでゲームを買いに行く。
それにしても暑い。
真夏日の昼間に外出するなんて今年初かも（それもどうかと）。
いつの間にか新宿は路上喫煙禁止になったらしい。
今日見た感じでも吸ってる人間はほとんどいなかった。

で、買ったのは「メディーバル　ローズ」という
外国産ゲーム（の日本語版）。
いわゆる箱庭ゲーという類のやつで、
有名どころで言えばシムシティみたいな感じ。

地獄のような気候の中、帰ってから早速プレー。
以前買った創世記というゲームの続編みたいな感じなので
割とすんなり入っていけた。
ただ、前作よりもかなり自由度が高くなってる。
長く遊べるゲームだからね。じっくり進めていこうかな。

なんか最近、日曜日にしか日記書かなくなってるな…
先週まで外部出張だったのでネタは山ほどあったんだけど。
とりあえず来月いっぱい位までは
今のプロジェクトを続けることになるらしい。

先週、今週と土日は出勤予定だったんだけど
土壇場で休めるようになったりして
今のところまだ週末2日は休めてます。

--- 掃除 ---
せっかくの休みなのに外出もせず、
台所周りが汚れてきたのでひたすら綺麗にする。
油汚れってのは掃除が大変だ。
で、終わったところで部屋を見渡すと
どうも散らかってたのでこっちもまとめて片付けることにした。

先日ビデオデッキが壊れたので
もう必要なくなった大量のビデオテープを処分。
というか押し入れにしまっただけ（笑）。
まだ廃棄するには勿体ない映像も残ってるはずだし、
捨てるのはまだ早いと思って。

フローリングなので掃除は楽なんだけど、
どうしても片付けきれない物がいくつか残るので
収納を買うことにした。
キャスター付のサイドテーブル。
ちょっとした本とかを置くだけなのでこれ位で充分かな。

床に物置くことだけは避けたいからね。
と言いつつ、電化製品のコンセント類は未だに
床に散乱してる状況。
これ解消するいい製品あったら教えて下さい。

さて、ようやく開発作業も一段落して
元の仕事場に戻ってきました。
これからはバグ修正とドキュメント修正。
しばらくはのんびりした日々が過ごせそうだ。

--- 最強のIDE ---
EclipseはもはやJavaだけの総合開発環境(IDE)ではないようだ。
CDTと呼ばれるC/C++開発プラグインにより
開発者はCの開発にEclipseを利用できる。

Eclipseがここまで発展してきたのは何故だろう。
もちろんフリーという事もあるだろうが、もっと大事なことがある。
それは「安定している」という事だ。

--- 安定 ---
Eclipseのリリース版は非常に安定度が高い。
ほとんどバグも無く、開発者は安心して使うことが出来る。
さらに、リリース版だけではなく
Stream Stable Buildsと呼ばれるベータ版でさえ、
ほとんどバグが混入されずに公開されている。

約1ヶ月単位でこれほど高品質なバージョンを
次々と発表する事など、以前なら考えられない事だった。
何故こんな事が可能になったのか。
それはずばり、自動化テストを実施しているからだ。

--- 高品質の理由 ---
プログラムを修正したとき、
その修正が正しいかを判定するには
実際にプログラムを動かしてみるしかない。
しかし、Eclipseほどの巨大プログラムになると
その作業も不可能に近いほど巨大なものになる。

実際にプログラムを動かさなくても、テストを自動化することによって
アプリケーションの品質を保証できる。
これによって、Eclipseは常に
高品質のまま提供することが出来るのだ。

--- 全体の工数 ---
これは、Eclipseだけでなく
どんなアプリケーションにも言えることだ。
テストを全自動化しておけば、
突然やってくる大幅な仕様修正に何も怯えることは無くなる。

これを実現するには通常よりも多くの開発工数が掛かる。
だから、ほとんどの企業はこれをやろうとしない。
しかしそれは、間違った選択なのだ。
何故なら、「リリースまでの全工数」を考えれば
明らかにテストを自動化していた方が効率的なのだから。

地獄のようなデバッグ作業、
修正を繰り返す度に発生するデグレード現象。
開発時にわずかな作業をケチった事が
どれだけその後の自分達を苦しめているのか、
実際に開発をしてきた人ならきっとわかるはずだ。

何のために世のシステム開発論研究者たちが
テストの自動化という作業を取り入れようと思ったのか、
それを考えてみてほしい。
開発者の労力を減らすために、プロジェクトに掛かる時間を短縮させるために
必要なのが、テストの自動化なのだ。

さて、また一人チーム内のメンバーでも紹介しますか。
上にも書いてあるように、あだ名はオネムリ君に決定。
理由は…まぁわかるか。気が付くと隣でウトウトしてるのがバレバレなのだ。

彼、なんと家ではPCすら持っていないという
典型的な××さんである。
いや、別に持ってなきゃいけないって訳じゃないが
そういう人のほとんどはPCに疎い。
そんな奴が設計の仕事してるんだから驚きだね。

--- 続けますか？ ---
またまたMicrosoftのナメたメッセージ発見。
Excelでファイルを開こうとしたら、メモリが足りないらしく
「このまま作業を続けますか？」とかいうダイアログが開いた。

が、このダイアログ。
OKボタンしか付いてねぇ！
だったら「続けますか？」とか聞くなよ。選択の余地Nothing。

--- さらに深刻な問題 ---
そう、ここで問題なのはそんな些細なことではない。
メモリが足りないというここのヘボな環境にある。
しかも共有サーバだから、自分ではどうする事も出来ない。

タスクマネージャで現状を調べてみた。
物理メモリ3G、仮想メモリ7Gの環境の内
使用メモリは6.8Gを超えている。
CPU使用率も90％を超え、いつ落ちてもおかしくない状況だ。

大体、使用する人数も予想せずに導入するから
こんな事になるんだ。
今なんか、1台のサーバに20人近くのユーザがログインしてることもある。
サーバ管理者は日々怯えながら生活してるだろうね。

先日、日々長時間残業をすることで知られる(？)
我がチームのメンバー、通称「しったか君」にある作業を頼まれた。

作業内容は、Excelファイルの修正。
システムで使う機能の説明が記述されたファイルで、全部で6つある。
そのうちの一つが目次みたいな感じで、機能一覧表が記されている。
残りの5つのファイルで、それらの機能の詳細を記述するというスタイルだ。

さて、今回。機能一覧に漏れがあることが発覚した。
そこでまずは、目次ファイルの機能一覧表にいくつかの機能を追加することになった。
あとは、機能の詳細を残り5つのファイルのどれかに記述すれば作業は完了…
というわけにはいかないのであった。

--- 無駄な作業 ---
機能一覧表には、機能毎に番号が振られている。
今回、機能を追加することによって
その番号を振り直す必要があると、作業依頼者に告げられた。

まぁ、一覧表の番号を振り直すだけなら簡単だ。
しかし、問題はこれにとどまらなかった。

そう、詳細を記述した残りの5ファイルにも
全てご丁寧に機能番号が記述されているのだ。
つまり、これら全ての番号を振り直さなければならない。
こんな馬鹿みたいな事、時間の無駄でしかないのに。

--- 想定外？ ---
このシステムでは
機能が約100個、それぞれに関連機能として平均3つ程度の機能がある。
合計400個の機能番号を振り直すという面倒な作業が待っている。

この機能表を作成したときに、こういった問題に気が付かなったのだろうか？
今回は漏れによる機能追加だが、仕様追加の可能性だって当然ある。
それなのに、そういった事を全く考慮していないこういう奴は多い。
修正する事を念頭に入れろ。それはプログラムに限らず、ドキュメントでも同じ。
一回作ってハイお終い、なんていうドキュメントは
近い将来何の役にも立たない代物に成り下がるのだから。

これに懲りたらしく、しったか君は多少の知恵を働かせたようだ。
機能番号を分類で分けることにした。1-2-3のようにね。
こうしておけば、将来機能が追加されたとしても
今回のように番号を全部振り直すという無駄な作業をする必要が無くなる。

--- 作業量 ---
しかし、しったか君の凄さはこれに留まらなかった。
作業内容は、約400個ほどある番号の振り直し。
それを彼は「一日じゃ終わらないと思いますので…」と言ってきた。
本気でそんな事を言っているのか疑問に思ったが、
どうやら本気のようだ。

一日の作業量は約7時間。420分だ。
ってことはつまり、番号を一つ振り直すのに1分も掛かるって計算か。
一体どんな非効率な手順を踏めばそうなるのだろう。

僕は作業にあたり、予め番号の振り直し表を印刷した。
これを見ながら作業をすれば、効率も上がるからね。
400項目の修正に約1時間。
なるほどね、彼が毎日残業してるのに納得。

--- 机上に頼る奴ら ---
プログラムのデバッグには2種類ある。
一つは机上デバッグと呼ばれるもので
プログラムソースを見ながら動作を予測することでデバッグを行う。

もう一つは…そういや正式名称知らないや(笑)。実行デバッグ？とでも言うのかな。
実際にプログラムを動かしてデバッグを行う。

机上デバッグが有効だという人も相変わらずいる。
が、これは大昔に実行デバッグが困難だった環境で
仕方無く取られた手法であり、
現在その重要性は低くなっているように思える。

--- 百聞は一見にしかず ---
昔から開発に携わっている人間は
とかく机上デバッグにこだわる。
実際に実行できる環境があるのに、意地になって
机上確認だけで済ませようとする。

百聞は一見にしかずとはよく言ったもので
いくら机上デバッグを繰り返したところで
実際に実行しないとわからない部分など山ほどある。

それに、実際に実行した方が時間も早く済む。
そして、実際に実行するのだからその信頼性も非常に高い。
論より証拠。この言葉を、机上デバッグにこだわる人達に送りたい。

--- 久々 ---
なんか今日は眠い。
最近は暇じゃない日が続いてたので久々。
やはり、やる事が無いと眠くなる。
日記でも書いて気を紛らわすことにしよう。

台風一過ってことで、えれぇ暑いですな。
暇なんで今日は以前までのように定時で速攻帰るぜ。

以前注文していたサイドテーブルが届いた。
ちょっとした家具なんかは、わざわざ店まで行って買うのも
最近面倒に思えてきた。
結局郵送してもらうわけだし、通販で買う方が安いし。

今回のは組み立て式のサイドテーブルなんだけど
今までに無いくらい手順が多くて大変だった。
では早速、組み立て実況。スタート！(笑)

--- いきなりのつまづき ---
厳重に包まれたダンボールを開けると、
中から大量の部品と、何枚もの組み立て説明書が出てきた。
説明書を読むとこんな事が書いてある。

「組み立ては、できるだけ二人で行って下さい」

この野郎、喧嘩売ってんのか(笑)。
あいにく我が家には手伝ってくれる人など誰もいない。
仕方無く一人で作業を始めるぜ。

--- 謎の部品 ---
まずは順調に作業が進む。
引き出しの部分にネジや何かを取り付けていく。
と、ここで謎の部品を発見。
小っちゃい木の棒で、板と板を繋げるための部品らしい。

気になるのがその名称、「木ダボ」。
ダボって何ダボ？…………これでシラフなのが悲しい(笑)。

まぁそれは置いといて。
その名称に妙にウケてしまい、作業中もやたらと木ダボを連呼する俺。
「木ダボ、木ダボ、木ダボダボダボ♪」
…しかしこの馬鹿を止められる者など、この部屋に誰もいないのであった(笑)。

--- 最難関 ---
木ダボの取り付けも終わり、いよいよ底板の作業に入った。
あとはスムーズに組み立てにいけるはず…が。
キャスターを取り付けることろでえらい苦労する。

ネジが異様に固い。計16本も延々とドライバーでネジを締める俺。
握力も段々無くなってきた。
こんな時は木ダボSongでも歌って力を出すしかない。

--- 完成間近 ---
歌の力のおかげで(やや嘘)、ネジは全て締め終わった。
あとは組み立てるだけだ。
側面に底板と天板付けて、引き出し付けて…

あれ？何か変だぞ。
何てこったい、引き出しの底が無いじゃないか(泣)。
組み立てる時に底付けるのを忘れてしまったのだ。
慌ててバラして底を付け直す。

--- 完成 ---
というわけで、約30分に及ぶ格闘の末
我が家のサイドテーブルは無事完成した。

完成してから言うのも何だが、さすがに安かっただけあって
作りはかなりショボい。
上座ったら潰れるぞ、これ。

まぁ、とりあえず床に散らばってた物が整頓できるから
これで良しとするか。

--- 時間も忘れ… ---
と、テーブルが届いたのは昨日の話。
今日は土曜日だってのに、ひたすら家でプログラムをしている。
気付いたらもう夜10時だ。
ふぅ、今日はこれくらいで終わらせるか。

以前にも出てきた「知ったか君」。
今日新たに「金食い君」疑惑説が浮上してきた(というより、僕が勝手に)。

毎晩残業しているのは、どうやら作業が終わらないからではないようだ。
とある人が、自分の作業が終わったので
知ったか君に「何か手伝える事ありますか？」と聞いていた。

連日残業しているのだから、当然残作業があると思ったはずだ。
しかし、知ったか君曰く…無いという。
それでいて残業しているということは、つまり
彼は自ら進んで残業をしているわけだ。残業代が欲しいが為にね。

--- 超過料金 ---
こういう奴らはこの業界には意外と多いのだろうか。
もちろん、別の理由として
「皆が帰らないので何となく帰りずらい」という人もいるだろう。
どちらにしても、そんな理由で会社は大量の残業料金を支払っているのだ。

本当に作業が終わらなくて残業してる人は仕方が無い。
でも、そうじゃない人が残業して何の意味があるのか。
中国では、「残業 = 仕事の出来ない人」という認識があるらしい。
僕も正に同意見だね。

--- 時間で判断する奴ら ---
僕はいつも早く帰るので、以前はリーダーに
「仕事に協力的でない」と思われていたようだ。
うちの営業にそのような話が来たらしい。
その頃はまだ直接リーダーと接触が無かったから、
そう見えたのも仕方無いのかも知れないが。

今ではリーダーの直属で働いているので、
もちろん彼もそんな事は微塵も思っていないだろう。
別に僕は作業をしなくて早く帰ってるわけじゃないからね。
充分にプロジェクトに貢献してるし、他の人の作業も手伝っている。

僕が定時で上がっても、彼は僕に何も言わなくなった。
まぁ以前だって別に何か言われてたわけではないけど。
表情でわかるんだよね。「何もう帰ってんの？」っていう。

--- 実力社会 ---
全てがそうではないけれど、それなりにこの業界は実力社会だ。
現場に入ってしまえばね。
ただ、どうしても年少の僕が年上メンバーの上に付くわけにはいかず
あまり重要なポジションに就けないという現実はある。

一回相手に実力を見せておけば、
あとは割と勝手に出来るのが僕にとっては良い点だね。

--- 最近の日々 ---
ここのリーダーはマネージメント業務にはそれなりに長けていて
人を使うことは上手い。僕が手持ちぶたさでいる事を承知してるし
作業があればすぐに僕に振ってくれる。
おかげで最近は、暇な時間がなく過ごせるようになった。

今月いっぱいは、今のプロジェクトが続くらしい。
来月以降はまた今までの暇々な生活に戻るのかと思うと、少々残念だ。

この業界にいると、
自分の思っている事を相手に伝えなければいけない時がよくある。

例えば、これから構築するシステムの内容を口で相手に伝えたり
調査結果を文書にまとめて提出したり。

そんなとき、全く相手に伝わらない会話や文章を使う奴がいる。
日本語が出鱈目だったり、肝心なところが書かれていなかったり。
というより、約9割はそんな感じだ。

--- 視点 ---
自分の中で考えがまとまっても
それがそのまま相手に伝わる事などありえない。

ある程度の共通認識がある同士なら別だが、
ほとんど接点の無い人に伝えようと思ったら
かなり丁寧に説明してあげないといけない。

僕はいつも、第3者の視点で物事を見ることにしている。
自分の視点で考えたら、自分の意見が何も言わなくても伝わるのは
当たり前のことなのだ。
そうではなく、自分ではない他の誰かが同じ立場に立ったときに
どう感じるのかを考える必要がある。

--- 仕事でも日常でも ---
これはもちろん仕事だけに限った話ではなく、
日常の生活でも同じ。
相手の立場を考えないで行動する自分勝手な奴ってのは
非常に迷惑だ。

一言で言ったら「思いやり」って事なんだけど
なんかこの言葉だと仕事の事にまで結び付く感じがしない。
「優しさ」とかも同じ。
なんかいい言葉無いもんかな。