そう、今日は全国的にスーパーボウルの日です(笑)。
そりゃもちろん生放送のハイビジョンで見ますよ、ええ。朝の8時から。

今年は両者とも勢いのあるチームで試合前から楽しみだったけど
予想してた以上に凄い試合だった。
同点で延長突入かと思いきや、2年前の再現か。残り4秒で勝ち越して
ペイトリオッツが2回目の優勝を飾った。

誰が何と言おうと、スーパーボウルを超えるほどの試合なんてのはあり得ないね。
準決勝から2週間、ありとあらゆる策略を練ってきたチームの攻防は
途方も無い程に見ごたえがある。
機会があったら一度見てごらんよ。BS観れる人は是非。

--- EJB研究 ---
せっかく休みをとったので、午後からじっくりEJBの研究。
まだまだ使いこなすまでには時間が要るね。
そろそろコンテンツとして公開する予定です。

なんか今週は時間が過ぎるのが早かった感じ。
月曜にスーパーボウルを満喫した後は、後の4日を残業して過ごす。
ようやく開発環境が固まってきた。
で開発を始めようとしたら、余りの仕様未決定ぶりに少々呆れはしたけど(笑)。

--- 遅いのはJavaか？ ---
よくJavaは遅いとか言う奴がいるけど
そういう奴らは大抵、事の真相をわかっていない。

例えば、今回の例を挙げてみよう。
一つの画面を出すのに12秒掛かる箇所があった。
その内訳を見てみると…

DBアクセス：10秒
レスポンス出力：1.5秒
xmlパース処理：0.5秒

こんな感じだ。
DBアクセスは、Javaを使おうがCを使おうが速さは同じだ。
レスポンス出力に時間が掛かっているのは、出力キャッシュサイズを正しく設定していなかったから。
xmlパース処理が遅いのは当然だろう。これはCで組んでいれば多少速くなるとは思うが。

--- 遅い原因 ---
では、これを改善する策はあるだろうか。もちろんある。
DBアクセスは、発行するSQL文をチューニングするだけで劇的に変わることもある。
今回の場合、10秒掛かっていた処理がたった数行の変更で1秒に短縮された。

レスポンスは正確なキャッシュサイズを指定することで、0.3秒になった。
xmlパース処理はどうしようもない。

たったこれだけの事で、12秒→1.8秒にまで処理速度が高まった。
Javaが遅いとか抜かす奴の多くは、こういう現実を知らない。
CPUクロックが軽く1GHzを超える昨今、Javaを使うことによって
処理速度が大幅に落ちるプロジェクトなんて滅多に存在しない。
たった20％程度処理速度を上げる為に、5倍の工数を掛けようとする馬鹿はどこにも居ないだろう。

--- 本当の原因 ---
今回、遅かった原因は2つに分けられる。
一つは、プログラムをチューニングしていなかったから。
もう一つは、高負荷の掛かるライブラリ(xmlパーサ)を使っていたから。

Javaは開発を便利にする為に、便利なライブラリがいくつも用意されている。
しかし、「便利」の裏には「遅い」という弊害もある。
例えばxmlパーサを自分で作った場合、パース処理に掛かる時間は半分以下になる。

xmlパーサを作るなんて相当労力が掛かると思われる人もいるだろうが、
SAXという低級(劣っているという意味では無い)ライブラリを使えば
xmlパーサを作るのは比較的簡単だ。
もちろん全て一から作るより速度が落ちるだろうが、こちらの方が現実的なアプローチだろう。

--- 昔も今も ---
結局のところ、システムの処理速度を決定付けるのは
大半がプログラマの技術力に掛かっている。
この事実は、大昔から何一つ変わっていない。
OSが変わろうと、言語が変わろうと、結局必要なものは一緒なのだ。

--- 身近から ---
いきなり話は変わりますが。
再来週から新しい人が現場に入るらしい。
しかも、その人は以前に日記にも書いた最近うちの会社に来た人だったりする。
例のコバンザメ君がうちの会社をあたってくれたのだろう。

本人にはまだ一回しか会ったこと無いけど、
同じ会社の人が一緒の現場にいるっていうのは良い事だね。
どうも僕の下に着くらしい…向こうの方が年上でキャリアも上なのに(笑)。
まぁそんな事を気にするような人じゃ無さそうだから心配は無いけど。

プロにとって、納期を守ることなんて当たり前だよね。
でも、僕が今まで経験してきた数々の現場は、その当たり前の事すら出来ていない。
もはやこの業界の常識ともなっている、納期の延長。

なぜ、納期が延びるのか？
それは、決められたアプリケーションを完成させるのに
どれだけの工数が掛かるのかを正しく求められないからだ。

--- いくつかの原因 ---
ではなぜ、正確な工数が出せないのか。
一つは、自らが開発をしない人間(例えばプロジェクトマネージャ)が工数を計算するから。
自分で開発をしないのにどうやったら工数が出せるというのだ。
通常、こういうものは現場におけるプロジェクトリーダー(開発のトップに立つ人物)に
算出させるのが自然だろう。

もう一つ。工数の見通しも立たないまま仕事を引き受けてしまうから。
これが最も多いパターンだろう。
会社としてはとにかく仕事が欲しい訳だ、当然だが。
そして、自分達の能力もわきまえずに仕事を取ってしまう。

もちろん、工数等は向こうが提示したものを受け入れるしかない。
こういった場合の多くは、依頼主が大企業だからだ。
とにかく自分達を売り込みたい。その一心で仕事を取ってきてしまうという
とんでもない無謀な奴らだ。

--- この現場は… ---
最後に一つ。外部に開発を任せるから。
多くの現場で行われている、この仕事丸投げ主義。
この場合、正確な工数など出せるはずもない。
このケースの場合、ほぼ間違い無く納期は延長される。

さて、今の現場の場合。
後半の二つが当てはまる。
そして、プロジェクトリーダーなる人物すら存在しない。
まとめ役のいないチームが、正常に機能するはずが無い。
僕は入ってから約5ヶ月の間、平均稼働時間20％程で過ごしてきた。

この時間をあと50％でもプロジェクトに費やしていたら、
本来去年末にあるはずだったリリースは何の問題も無く行われただろう。
ちなみに、実際にはこのリリースは今週末にまで延期されました(笑)。

--- 現在の意義 ---
僕がこのような現場にいて、明らかなメリットが一つある。
それは、開発のノウハウを徹底的に学ぶことが出来ることだ。
今までプログラムの経験は長いけど、それはあくまで趣味の範囲だから
納期等を気にする必要は無かった。

そして、僕は今プログラムで飯を食っている。
当然、プロとして果たすべき事は山ほどある。
その最低限として僕がラインを引いているのが、納期を守る事。
それが守られていない現実を僕は沢山見てきた。

--- 将来のために ---
でも、それは僕のせいじゃない。そして、僕に責任が掛かる事も当然無い。
僕はまだ入りたてのペーペーだからね。
だけど、いずれ僕がそういう責任を負う立場になったとき
絶対に納期を守るようなノウハウと実力を身に付けていかなきゃいけない。

幸い、僕の周りには数えきれない位の反面教師がいる。
昔から僕はそうだった。父親の姿を見て、こんな人間にだけは絶対ならねぇという気持ちで
今まで生きてきた。そしてその事は多分僕を強くした。
今もそう。納期を破ることが日常になってしまった奴らみたいには、絶対になりたくない。
そんな中途半端な気持ちで仕事をしたくないから。

なんだ、明日は休みだったのか。
今日の昼頃現場の人と話してて初めて気付いた。
あやうく明日何の疑いもなく会社行くとこだったぜ(笑)。
一方、チームの人は明後日に迫るリリースの為に休日出勤だとか。

っていうか俺もチームの一員なんだけど(笑)。
明日中に溜まったバグ程度は明後日にまとめて片づければ問題無いはずだ。

という訳で。
今後は僕が祝日を忘れないように、どなたかスケジュールのページに
「祝日」とか書いといて下さい(笑)。

--- その気満々？ ---
いよいよ明後日に迫った仮リリースだが、
ベトナムの開発が完了しない可能性は濃厚になってきた。
プロマネも営業担当に「明後日は(完成しないから依頼主に謝罪を)よろしく」と、
早くも負け犬宣言をする始末。
そりゃこんだけ放ったらかしにしてて開発が進むわけないよ。ある程度は突っついていかないと。

そんな事思ってると、今度はリリース後の話をしてる。気が早い奴だ。
一日一画面のスピードで開発してほしい等と抜かしてるが、
どこをどうやったらそんな考えが出てくるんだ。
今までの期間で開発側の実力は見えただろ。それを急にピッチ上げろと言っても所詮無理な話。
こんな人物にプロマネを任せてる会社に未来は無いね。

なんか今日はいきなりスゲー暇なのです。
昨日まで忙しかったから、すっかり油断してました。
JBossの資料を家から持ってきておくんだった。

--- Firefox ---
以前に紹介した、次世代ブラウザのFirebird。
確かに機能は良いんだけど、起動がかなり重いのであまり使ってなかった。

その後継として発表されたFirefoxを使ってみる。
おぉ、メチャメチャ起動が速くなってるぞ。IEに匹敵する速さ。
前回の派手すぎるアイコンも改善されて良かった良かった。
これで完全に移行できるかな。

家に帰ってメールチェックをしていると。
「あなたはラッキーです」というタイトルのメールが。
まぁ内容自体はよくあるスパムなんだけど、
あまりにもストレートすぎるタイトルに思わず笑ってしまった。

--- 時間の問題？ ---
いよいよMySQLが本気だ。
次期バージョンのMySQL5.0で遂にストアドを装備。
ビューとトリガ機能は5.1までに装備することが確定しているようだ。
ちなみに、サブクエリー(副問い合わせ)はにMySQL4.1から対応している。

これで、通常の業務に必要な構文は全て揃うことになる。
今までは何の疑いもなくOracleを使ってたプロジェクトも多いが、
これを機にMySQLが使われる機会はさらに増えるだろう。
そしていずれはOracleマスターなんて何の存在価値も無いものに成り下がる…
かどうかは知らないが、その地位をMySQLが脅かすことになるのは
「間違いナイっ！」(←長井秀和風に)

すげーな。Winnyの通信をブロックするソフト(アタッチメント)が発売されたらしい。
値段は100デバイスで98,000円也。
そんな事するくらいなら最初っからポート塞いどけよ。
会社でダウンロードするような勇気のある奴がこの世には山ほどいるって訳か。

記事を読むと「同社は Winny の暗号化通信を解読」ってあるけど
Winnyって確かソース公開してるんじゃなかったっけ？
あ、ちなみにWinnyを知らない人のために書いておくと。

インターネットを通じたファイル共有システムの事です。
つまり、Winnyネットワークに繋いでいる全てのパソコン内にあるファイルが
全世界から参照、検索が可能になる。特定のポートを通信に使う(多分)。
これがフリーソフト。かなり普及しているらしい。
もっぱら使われてるのは音楽とか、映画とか、まぁ当然そっち系とか…
最近逮捕者も出たらしいからね。のん気に使ってる奴らは少々考えた方がいいよ。

--- その名前は… ---
またもニュースネタです。暇なのがバレバレですな(笑)
Linux環境で動くWindows互換OS(これで合ってる？)の名称が変更になったらしい。
以前は「Lindows」って名前だったんだけど、裁判で負けて
新しい名称が「Lin---s」。

さすがにその名前は無いだろ。第一読めないよ、それじゃ。
正式の読み方は何？結局「リンドウズ」？

--- 悪夢再び ---
何だろう…この歯切れの悪い試合は。
ワールドカップ予選がついに始まった。

日本vsオマーン。前半を0-0で終了。
焦っている。焦りすぎている。
試合時間は90分もあるのに、限りなく速く時間が過ぎていく。
何年か前の日本を見ているようだ。

でも、思えば日本がこうやってワールドカップ予選を戦うのは実に7年ぶりだとの事。
全ては「勝つ」為だけにある試合の緊張感は、試合を観ていても伝わってきた。

--- その結果 ---
勝つこと。それは点を取ること。
後半、日本は攻めた。攻め続けた。
オマーンは守る。ひたすらに守る。
このまま0-0で終わるのが、いつもの全日本。
その度に、いつだって僕は落胆を重ねてきた。

でも、今日は違った。ロスタイム過ぎ、こぼれ球を久保がゴール。
この1点を取るために、日本は今までやってきた。
そしてその結果は出た。どんな形だっていい。1点という結果が全てなのだから。

もちろん、今後に課題は残った。でも、それは次に直せばいい。
今日の試合で勝ち点3を取れた。
だから、僕はあえて「日本は最高のスタートを切った」と言いたい。

試合終了2分前まで、そんな気持ちは全くなかった。
「結局これがお前達の力かよ」と罵ってやろうかと思った。
でも今は違う。「これからも期待してるぜ」

現場ではJBossをローカルで立ち上げて作業している。
とにかくこいつはメモリを食う。
起動しただけで軽く150MBは消費してしまう。

今日なんか知らずに作業してたら、Windowsのメモリ使用量が900MBを超えてる。
実メモリは512しか積んでないのにこれは危険だ。
まぁ再起動すれば済む問題なんだけどね。

それにしても、Windowsのタスクマネージャが表示するメモリ使用量はあてにできない。
「パフォーマンス」タブの方はいいんだけど、
「プロセス」タブの方は実際のメモリ使用量よりも少なく表示されている。
気を付けろ！(←長井秀和風に)

--- Java標準？ ---
以前、C言語のビルドプログラムといえばmakeが標準だった。
そしてJavaの場合、これがAntという事に置き換わる。
makeはその使いにくさで評判だったが、
果たしてAntが使いやすいか？僕は常々疑問に思ってきた。
その中でも、特に使えないと思うAntの仕様を挙げてみよう。

--- プロパティが上書きされない ---
これが最大に厄介だ。
通常、Antの設定ファイルであるbuild.xmlというのは
プロジェクトの細分単位で作成される。
そして、全コンパイルを行うためのbuild.xmlを使用して
複数のbuild.xmlをまとめてビルドできる。

が、その際に問題がある。
Antの環境変数ともいえるプロパティが、全build.xmlで共通のスコープしか持たないのだ。
そして、異なるbuild.xmlで同名のプロパティを宣言していると
「後から宣言された方が無視される」。
こんな酷い仕様があるだろうか。
無視されたプロパティは何の警告も出ず、作業が進められていく。
せめて、ローカルプロパティの宣言くらいは出来てもいいのではないだろうか。

--- 宣言されていないプロパティ ---
またもプロパティ関連だ。
Antでは、宣言されたプロパティを使用するのに ${name} のような使い方をする。
例えば、
<property name="build.dir" value="build" />
<mkdir dir="${build.dir}" />
上の設定ファイルは、buildという名前のディレクトリを新規作成する。

ここで、1行目のproperty要素を削除してAntを実行してみよう。
build.dirプロパティは宣言されていない。
このとき、Antは何ということか。
${build.dir} という名前のディレクトリを作成するのだ。
こんな馬鹿な仕様があるか。
大体、こんな動作を必要としているユーザがいるとはとても思えない。
警告を出すとか、他に方法はいくらでもあるはずなのに。

--- 妥協は禁物 ---
こんな使いにくいものを使うのは、技術者として納得のいかない所だ。
ベターではなく、ベストのものを使うのが技術者のあるべき姿。
今のところ他に選択肢が無いので、僕も仕方なくこのツールを使っている。

しかし、AntはもはやJava標準のビルドツールとして定着してしまった。
外部が公開するプログラムも、ほぼ100％がAntの設定ファイルを採用している。
だから、むやみに他のビルドツールを使うことも良くないのだ。
ビルドツールというのは、全世界共通であることに意味があるからね。

--- すぐやる課 ---
こんな課があるのをご存知だろうか。
以前ニュースにもなってたから知ってる人も多いと思う。
お役所っていうのは何をするにも時間が掛かるから、
市民の声をすぐ実行に移すために作られたんだよね。

僕はもちろん、この課の精神が大好きだ。
ここの現場の人間は、何でも後回しにしようとする。まさにお役所的。
そして、彼らがお役所よりもタチが悪いのは
結局最後までやらないままってのも結構ある。

もっとも、彼らがすぐやらないのには訳がある。
「出来ない」からだ。
そして、今出来ないものは後になってもきっと出来ないままだ。
だから結局、出来ないまま他の人間に投げてしまう。
そのお役所体質、早いうちに改善してくれよ…

今現場で作っているプログラムは、
設定ファイルを全てxmlから読み込むようにしている。

今回、初めてSAXというものを使ってみる。
通常xmlの読み込みにはDOMというライブラリを使うんだけど
これがとにかく遅い。たかがテキスト解析にそんな複雑な処理必要無いでしょ。

というわけで登場するのがSAXライブラリ。
これを使えば自分用のパーサを簡単に作ることが可能だ。

--- SAX使用上の注意 ---
開発を進めていくうちに、以下のようなエラーに遭遇した。

FWK005 parse may not be called while parsing

うむむ…なんじゃこりゃ。
検索に掛けても日本語サイトでは一つもヒットしない。
ログを出して確認してみると、その謎が解けた。

要は、一つのファイルを同時刻にパースしようとしていたらしい。
画面をフレームに分け、上下のフレームから同時にアクセスしていたのが原因。
SAXライブラリというのはスレッドセーフの作りにはなっていないようだ。
同期化を取ることで無事に解決しました。

--- 把握不足 ---
うちの会社っていうのは、自社では仕事を取らず
よその現場に技術者を派遣するという形を取っている。
いずれは受託(自社で開発を引き受ける事)をするという話も出てはいるのだが
営業サイドからすると、どうも乗り気ではないらしい。

もちろん、受託っていうのは失敗したらモロにその損害がうちの会社にくる訳だから
躊躇するのも解る。が、その状態のままじゃいつまで経っても
会社として成長できない事にもなる。
「失敗して会社潰れるのも嫌でしょ」こんな事を言う。

あのなぁ、それを何とかするのが俺ら技術者の役目だろ。
結局は営業側が技術者の能力を把握していないから失敗するんだ。
俺に任せてくれたら絶対そんな事はさせない自信はあるけど、それに
会社の存続や全社員の給料が掛かってる訳だから
そこまで強く言うことも出来ないのが正直なところ。

皆苦労してるんだから、ある程度の妥協は仕方無いかなぁ、と思ったりもする。
でも、俺はそんなギリギリの状況で仕事をする事が出来たら
今の何倍も能力を発揮できるのになぁ、とも思うのである…

朝起きたらPGAツアーがやっていた。
そういや今日は最終日だっけ。
昨日は丸山が5打差の2位だったのは知ってたんだけど。

おぉ、もう2打差まで詰めてるじゃないか。
これはもう見ていくしかないな。
という訳で遅刻覚悟で観戦開始。

…うむむ、惜しかったね。
最終ホール前でトップに追いつくも、ラストホールで優勝を逃がす。
じゃ、会社行きますか。

--- 新入りさん ---
なんか現場に知らない人がいる。
どうもうちのチームに入った人らしい。
しかもまた女の子だ。向こうにいるジジイも嬉しそうにしている。

彼女はマニュアル作成担当らしい。
もうそんな時期ですか。実物はまだ全然未完成なのに(笑)。

--- 経費節約？ ---
ここは営業の現場だから、よく金銭の話は飛び交ってる。
もちろん経費節約は大事な仕事の一つだ。
だけど、技術者を雇う上での経費節減方法を全くわかっていない。

まず、新規で人が入るというのにまともなマシンが用意されていない。
社内で空いてるマシンを探して、それを無理矢理使おうとする。
そのせいで相当スペックは低い。しかもCDやハードディスク等がイカれている。
そんなマシンを当てがおうとするこいつらの無神経さに驚く。

マシンのスペックが上がれば、それがそのまま作業効率の向上に繋がる。
もちろん一定以上のスペックがあれば充分だよ。
しょっちゅうハードディスクがイカれてたら、その度にハードディクスの全走査が必要だ。
これで2時間は大事な時間が潰れる。

たかが数万円の出費を惜しんだ事が、月何十万円という損害を出していることに
こいつらは気付いていない。
結局「一人いくら」という単純計算しか出来ないからこういう事になるんだよね。

--- また逆戻り ---
ふぅ、またまた暇になってしまった。
先週あたりからほとんどやる事が無い。
かといって休むわけにもいかない。今月は2月だから日数が少ないのだ。
そろそろ次のネタ探しでも始めますか…

あ?あ、言わんこっちゃない。
新しく入った人のマシンがメモリ不足で大変らしい。
そんな事判りきってた事だろうよ。
入ったばっかでこんなんじゃやる気も出ないよな、実際。
メモリくらい買ってやれよ。

--- 見捨てる時期 ---
いよいよ minidns.net を見捨てる時期が来たようだ。
今日はAM1:30から停止していて、13:00現在まだ復旧していない。
これじゃ完全に使えない。
しかも、停止していた事実をサイトに全く載せないというのは許せないね。
ZiVEとかはきちっと公表してますぞ。

という訳で、自宅でDNSサーバを立てることに決定。
tinydnsを使うんだけど、うまくいくかどうか…
とりあえずはセカンダリDNSに指定しておいて様子を見よう。

--- また？ ---
わかった。何でこの現場がこんなに金が無いか。
また新しい人材を取るらしい。しかも面接するメンバーの一人はうちの会社から。
でも、もう余ってる席もマシン無いぞ(笑)。どうするんだ？

ここの現場が相当貧乏だってことはこの前話した。
たかがメモリ1枚すら買えないのには訳があった。

奴らは「追加経費」という形の出費を嫌うらしい。
つまり、月額80万という固定経費は気にしないくせに
メモリ1枚2万円という追加経費だと許可が下りない。
こいつは相当アホだ。超低性能の脳を装備しているに違いない。

だって、考えたら明白でしょ。
固定だろうが追加だろうが経費は経費。
全体としての出費を抑えるには、追加経費に金をつぎ込んだ方が
よっぽど良い成績を残せるのに。

--- サウナ？ ---
おっそろしい程暑いぞ、この現場は。
推定温度、28℃(マジです)。
こんなんじゃとても仕事できる環境とは呼べない。
何回か外回って気分転換するも、やはり帰ってくると尋常じゃない暑さ。

これでまた、「暖房過多」によるプラスの経費と
「労働力低下」によるマイナスの利益がどんどん増えていく訳だ。

…やばい。マジで熱が出てきたようだ。
そのせいか頭痛がひどい。
これで風邪でもひいたらどうしてくれるんだ。
そうかそうか、休めってことだな(笑)。

--- 原因不明 ---
またうちのサーバが止まってたようだ。
原因は不明。おそらく、昨日設定したtinydnsが問題か。
でも、調べてみたらそれだけでは解決できない問題に次々とぶちあたる。
頭が痛いっていうのに、なんでこんな日に限ってトラブルが続くんだ。
とりあえず、何とかサーバは復旧。色々と苦労しますな。

またまた事件です。
今まで放ったらかしにしてあった同系統プロジェクトのスケジュールが
昨日になって決まった…もとい、勝手に決められたようだ。

ホントこの現場は無計画すぎる。何のスケジュールも決めないまま進めているから
相手がいきなり出してきた無謀なスケジュールに対しても
「ハイわかりました」としか言えない。何のためにプロマネ置いてるんだ。
こういう事にならないようにするのがお前の役目だろ。

--- プロの考え ---
しかし、そうやってスケジュールが発表されたにも関わらず
こいつらのやる事は決まって同じだ。
「どうやってスケジュールを延ばそうか」
もっと建設的な考え方ができないものか。まぁ、今回のスケジュールは一般的に考えたら
無理な程の量だから、そう考えるのも解らなくは無いが。

「与えられた仕事はキッチリこなす」
これが、プロである僕が最低限守るべき事項だと考えている。
それが多少無茶な要望であったとしても、だ。

「全部やるのは無理なので」
ハナっからこういう事をいう奴と一緒にいると、その意識が揺らぐんだ。
だったらこんなスケジュールを発表しないでくれ。
嘘とごまかしを駆使して世の中を渡っていくのは、
正当に生きることが出来なくなった敗北者だけで充分だ。俺はそうなるつもりは無い。

--- 同類 ---
このプロジェクトは、H社がプロトタイプとして作ったものを
こちらでカスタマイズして使う作りになっている。
過去にあった同様のアプリケーションを作っていたのがH社だからだ。
それをWebに焼き直す(＋α)のが僕らの仕事。

しかし、今になってもまだH社のプロトタイプは完成していない。
そんな状態でこちらが開発をするのは、本来間違っている。
H社が新しいビルドを出す度にこちらの修正分をマージしなければならない。
冗談みたいだけど、これがホントの話。
幸いマージ内容はほぼ把握したので、1時間もあればマージ作業は終わるのだが。

もちろん、元々こんなスケジュールだった訳じゃない。
本来ならとっくにプロトタイプは完成してる予定だ。
それが延びに延びて現在に至る、という形。
今まさに、この現場も同じ局面を迎えようとしている。

営業のリーダーが言う。
「H社がこれだけ延びてんだから、うちも遅れたって何とかなるだろ」
いかにも日本人らしい発想だ。とてもアメリカで働いた経験もある人間の発言とは思えないな。
よその企業と一緒の事をやってたんじゃ、いつまで経ってもその企業を超えられない。
他がやらない事を自分達でやれば、それが大きなアドバンテージになる事に何故気付かないのだ。

--- 今年初 ---
さて、明日は土曜ですが出勤です。
今年初、というかこの現場に来て初めての休日出勤。
まぁ年に2,3回はあることだ。しかも今回は13:00?17:00まで。
本部で作業する本部隊のサポートをする為に現場で待機するだけだから非常に楽だ。
適当に過ごして終わらせよ?っと。

先週は土曜日出たので今日はお休みです。
本当は行く予定だったんだけどね。土曜はほとんど何もしなかったし(笑)。
朝起きてニュース見たら雨だったので行くのを断念。

さらに、カレンダーを見たら今月は平日が23日もある。
これなら余裕で休めるなぁ、とか思って今日はのんびり家で過ごすことにしました。

--- 3月 ---
なんか3月になったらまた寒くなるようだ。
やっぱ今日は休んで正解だったね。
で、僕の現場との契約も今月いっぱいなんだけど、どうやら
もう少し延びることになりそう。

前にも話したけど、一緒にうちの会社から来てる人がいるので
僕だけさっさと辞めちゃう訳にもいかなくなったのだ。
営業の方でも心配してるみたいだから、
もう少し続けようかなぁ…というところ。まだ正式な契約延長はしてないはずだけど。