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

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

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

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

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

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

昨日見事失敗に終わったFlexのダウンロード。
サポートメールを出してみたが、
返ってきたのは「CD送りますんで住所教えて下さい」という内容。
親切？単にサーバのメンテナンスする人間もいないだけだろ。

郵送なんかにしたらいつ届くかわからないので、
仕方無く本家(アメリカ)のサイトからダウンロードする。
当然のようにあっさり成功。
ホント日本の企業ってのは遅れてるよな。こういう対応一つ取ってみてもそう。

--- ぬるま湯 ---
この技術力の低さは一体何なんだろう。
おそらくやる気が無いだけだろうね。
大した事やってなくてもそれなりの金が貰えてる現状じゃ、
この状況は決して改善されない。

あと10年くらいしたら、
本当の意味で競争が始まるだろう。
技術力の無い人間の大半はクビを切られる。
中国やインドに仕事を丸投げする会社がさらに増えそうだ。

まぁどの業界でもそうだと思うけど、自分のやっている事が
果たしてどれだけの価値があるのかって事を
考え直した方がいいと思うね。
世界中にいくらだって代わりはいるんだから。

--- 時代の変化 ---
企業としたら安い方、優れている方を選ぶのが現実なのだ。
これを冷酷だという人もいるかもしれない。
でもそれが今の時代。年功序列のような古いシステムではいずれ破綻する。

別に昔が駄目だったと言ってるわけじゃない。
物事の善し悪しだって価値観だって常に変わっているんだ。

時代の流れに逆らうことだって時には必要。
でもそれを実行するにはとてつもない力と忍耐がいる。
僕は面倒なのは嫌いだからね。
自分の好きな事やって人の為にもなってる現状をひっくり返すつもりは無い。
少しずつでも環境を良くしたいと思ってはいるけど。

なんかこう書くと某不正会社みたいだけど。
そうではなくて開発現場のお話。

「全く同じ情報」を2つ(以上)の場所に記述すること。
これが多い現場ほど、そのプロジェクトが失敗する確率も高くなる。
2重管理をしていると、一方のドキュメント(やソース)に修正を入れたときに
もう一方にも必ず同じ記述をしなければいけない。

始めのうちは忘れずにやっているかもしれないが、いずれ両者にズレが生じてくる。
そして、どちらのドキュメントも不完全なまま更新され続けてしまう。
結果として、これらのドキュメントは両方とも使い物にならない。
それまでに掛けた時間が全て無駄になってしまうというわけだ。

--- 自動生成 ---
これを回避するために、同じ情報は必ず2箇所以上に記述しないというルールを定める必要がある。
しかし、そうはいっても別途それらの一覧が欲しいことも事実だ。
ではどうするか。これらの一覧は自動生成すればいい。

全ての基準はソースであるべきだ。
ソースこそが実体であり、今動いているシステムを証明できる唯一のもの。
ドキュメントが間違っている可能性はあるが、プログラムが間違っている可能性は0％だ。
もしプログラムが間違っていても、システムは「プログラムの通り」に動いているのだから。

ソースを元にしてドキュメントを自動生成する。
これが一番確実だ。もっとも、これが可能なのは単純な一覧表のようなものに限られる。
それでも、一般的なプロジェクトにおいてこの作業がかなり有用であることは間違いない。
それは無駄な工数を減らし、ミスを無くす。
必要なのは、自動生成するためのスクリプトを書く知識だけだ。

--- 熱い論争 ---
現場の昼休み、談話室では男達による熱い論争が繰り広げられていた。
題目はずばり。上戸彩とヨッシー(モー娘)のどっちが可愛いか(笑)。
んなこと職場で熱く話してんじゃねーよ。しかもいい年した大人が。
聞いててこっちまで恥ずかしくなるぜ。

…ちなみに僕は、ヨッシー派です(笑)。

--- 雪 ---
また雪が降るらしい。もう3月だってのに。
あ、でも幸い明日は金曜日だ。
3連休するいいチャンスではないか(笑)。

3月末以降も今の現場で続けることになりました。

一昨日に現場の人から呼ばれてね。
相手は某リーダーと現場の主任。
今後は僕に「上流」工程を任せてくれるという運びになったようだ。

今まで、僕があまりに暇していたのは現場の構成に問題があった。
4人いるメンバーの中で、設計を担当しているのはリーダー唯一人。
残りの3人が開発を行っていた。

--- 間違った配分 ---
これではどう考えたってうまく回らない。
しかも、設計担当には他の仕事も回ってくるので尚更だ。
僕は2週間くらい前、暇だから他の仕事も回してくれと言った。

しかし現実、その後僕に回された仕事は1、2個。
結局問題は改善されない。
だから僕はこの現場を続ける気も無かった。

--- 躊躇の理由 ---
それが今回、リーダーと主任が僕に設計をやってほしいと言ってきた。
僕としてはそれで大歓迎だ。
少しでも「待ち」の時間が減らせるのだから。

それでも彼らは何やら渋っている。
何故そんなに仕事を回すことを躊躇うのか不思議に思った僕は聞いてみた。
すると、意外な答えが返ってきた。

以前、既に現場にいるプログラマからある前提条件を出されたという。
「設計書が全て整った状況でないと開発を進めませんよ」。
つまり、自分達は設計にはノータッチなので
そこまではあなた達で完成させておいて下さいよ、という事だ。

--- 使えないプログラマ ---
こういう類のプログラマがいる事は僕も知っていた。
以前の現場でもそういう輩はいたからね。

俺から言わせたら、こんな奴はプログラマとは呼べない。
前々からずっと言っているように、完璧な設計書などこの世には存在しないのだ。
設計書が揃っていないと開発出来ませんよと言うのは、
責任を全て設計者に押し付けようとする奴らの単なる逃げ道に過ぎない。

大体、今の現状を見たら設計者が足りない事くらい解るはずだ。
自分の能力に自信が無いのか、それともただ楽をしたいだけか。
いずれにせよ彼らは現実を改善しようとする力と心を持っていない。

完璧な設計書なんてあったら、熟練のプログラマなんて必要無い。
あとは、駆け出しのプログラマかちょっと良く出来たAIプログラムに設計書を渡せば
完璧な実装が出来上がるだろう。

--- 穴埋め ---
だけどこれは理想論だ。
どんなに優れた設計者でも、完全な設計書など作成できない。
その設計書の穴を埋めるのが、プログラマにとって最大かつ重要な仕事なのだ。
設計書が無いとプログラムできないような人材は、現場では何の役にも立たない。

以前の会議でも、リーダーがそんな話をしていたのを思い出した。
だから僕はその場で言ってやった。
「設計書が完成するのを待ってたら遅い。だったら僕の方で設計しますよ」と。

リーダーはこの言葉に助けられたようだ。
何せ以前までのメンバーは、設計を任される事を初めから拒否するような人材だったのだから。
彼らは、自分達に必要以上の仕事が割り振られることを恐れていた。
それは彼らにそこまでの余裕が無かったのか、単に仕事が増えるのを面倒だと思っていたのか
そこまでは判らないけど。

--- 受動的 ---
今の僕の稼働率が1割を切ってる事を伝えると、主任は頭抱えてたよ。
そりゃそうだろう。主任とリーダーは殺人的なスケジュールで
日々時間に追われているのだから。
それを知りながら放置しておいたリーダーにも問題あるんだけどね。

まあ何はともあれ、今後は僕が色々な作業を担当するようになった。
品が完成するまで待ってるような受動的な人間はこの業界に必要無い。
いかに早く、素晴らしい製品を完成させるかが重要なのだ。

その為に現場の上下関係など全く無意味だ。
SEだろうがPGだろうが、能力の有る者がより多くの仕事を担当する。
これによって、現場はスムーズに進行するだろう。

--- 今後 ---
そんなわけで、僕はもう少しこの現場を続ける決断をした。
以前よりはマシな日々が送れるだろうからね。

ただ、この会社自体には依然として良い印象は持ってないから
延々と続ける気は無いけどね。
今のフェイズが終わって一段落着くまではやろうと思う。
そう考えると5月末くらいかな。
契約上は6月末が区切り良いのでその辺だろう。

先日の新マシンに続き、またも衝動買いをしてしまった。
それはビデオキャプチャ。
カノープスのMTV2005という機種で、実売19,000円位。
随分安くなったよね。昔はハードウェアエンコード付のキャプチャなんて
軽く10万超える代物だったのに。

画質もなかなか。
もともと地上波放送の画質なんてタカが知れてるんで大したことは無いけど
S端子経由でBSデジタル撮るとかなり綺麗だ。

これがあればわざわざDVDプレイヤー買う必要も無いんだけど、
やっぱりPC上からだと面倒なんだよね。
ハードウェア変換とはいえ、他の作業しながら録画してると
たまにコマ落ちするし。
それでも、ハイビジョン録画できるタイプで5万切らないと買う気が起きないなぁ。

--- ピンチ公表 ---
何やらリーダーが騒いでいる。
「あ、しまった！」「あれ！？」などなど。

おそらくファイル編集に失敗したとかそんなトコだと思うけど
わざわざ周りに公表しなくていいよ。
こっちは笑いこらえるのに必死なんだから。

と思ったら、今度は別の場所から「ひっ！」という世にも恐しい声(笑)。
どうやったらPC触ってるだけでそんな声が出るんでしょう。謎。

Java環境で動作するスクリプト言語が登場した。
まだベータ版だが、それなりに使える言語らしいのでちょっと調べてみた。

色々なところで言われていることだが、まずこの名前。
読みは「グルービィ」。
まぁ言ってみりゃRubyの完全なパクリなわけだが。
もう少しマシな名前は無かったのか。
Javaの文字が完全に消えてますがな。

ともあれ、構文などもRubyにかなり近い作りになっているので
移行はしやすいかもね。
だからといって、これでRubyが絶滅するとは思っていないけど。

--- 凄い奴、現る ---
会社からの帰り道、僕はとある駅のエスカレーターに乗っていた。

すると、隣のエスカレーターに向かって走ってくる男が目に写った。
「止めてやるぞ?！」
その男は叫んでいた。そして、天高く舞上がるように(←やや大げさ)ジャンプすると
エスカレーターに飛び乗ったのだ。

次の瞬間。
そのエスカレーターは本当に止まってしまった。
おそらく安全装置か何かが働いたのだろう。
乗っていた人達は皆唖然としていたが、やがて仕方無く歩いてエスカレーターを登り始めた。
飛び乗った男は叫び散らしながらどこかへ消えてしまった…

--- 変わり者 ---
いや?、東京ってのは本当に変な奴が多いね。
今回は僕の乗っていたエスカレーターには何の支障も無かったから
笑わせてもらったけど、実際自分が乗ってたら結構腹立つぞ、多分。

--- 恒例？ ---
毎度おなじみ、Oracle JDBC のバグ報告コーナーです(笑)。

データベースのカラム型には、CHAR型というものがある。
これは「固定長文字列」型で、あらかじめ長さの決まったものを格納するためのもの。

例えば、CHAR(10) と定義されたカラムには
「0123456789」とか「ABCDEFGHIJ」のような長さ10文字の値を格納することができる。
では、「01234」のように10文字に満たない値を入れようとしたらどうなるだろうか。
一般的なDBでは、これらの値は右側を半角スペースで埋めた形で格納される。
この例だと、「01234     」といった形になる。

--- 利便性 ---
これらのスペース埋めは、DBによって自動的に処理される。
そっちの方が便利だからね。
わざわざ毎回10文字ピッタリの文字列を用意するのは面倒なのだ。

Oracle JDBC は、この自動処理を一部省いている。
具体的には、PreparedStatement を使ってCHAR型に文字列をバインドするとき。
例えば、CHAR(5)型を持つCOL1というカラムを持ったテーブルを考える。

SELECT * FROM TABLE_A WHERE COL1=?

こんなSQL文があったとする。
ここで、?の部分に「ABC」という文字をバインド(割当)させてみよう。
バインド後のSQL文は、以下のようになるはずだ。

SELECT * FROM TABLE_A WHERE COL1='ABC'

先程話したように、COL1はCHAR(5)型だから
「ABC」という値が存在することはあり得ない。
あるとしたら、「ABC  」といった値だろう。
だから通常、DBではこのSQL文を

SELECT * FROM TABLE_A WHERE COL1='ABC  '

と解釈する。
この方が、ユーザにとっても便利だしそれによる不都合も起きない。
誰が好き好んで、決してレコードの返ってこないSQL文を発行するだろうか。
SQL文は、ユーザが便利にデータベースを扱うためのものなのに。

--- 拒絶の理由 ---
これを Oracle はバグでないと言うかもしれない。
そういう仕様なんですよ、と。

しかし、そんな仕様は「誰も望んじゃいない」んだ。
ユーザの誰一人として望まないような仕様をそのまま放置しておいて
これをバグと言わず何だと言うのだ。

通常、こういったものはライブラリ側で解消すべき問題なんだ。
それをOracleはユーザ側に押し付けようとする。
自分達が作ったものに文句は言わせない。
あとは使いたい人が勝手に使って下さいよ、という傲慢なスタイルにしか僕には見えない。

だから僕は、Oracleを使いたくないんだ。

さてさて、お久しぶりです。
実はまた内職なんぞをしておりまして。
今回のはスケジュールがハードだったんでしばらく日記書く暇が無かったのだ。
とりあえず一段落したかな。
今後はもうちょっとゆっくりしたいよ。

--- 理解不能 ---
深夜、チャンネルを回すと民放で野球を放送していた。
試合は0-0。なのに画面右上に表示されていた文字は。

「この回、巨人先制！」

…呆れて物が言えないね。
先に結果バラすスポーツ中継があるかよ。

これに限らず、とにかく最近のスポーツ中継ってのはこういった類のが多い。
常に画面上にテロップが出てる。
「渋井、トップ独走中！」とかね。
これは一体何なんだろうか。視聴者を引き付けておくための作戦？
僕には完全に逆効果にしか見えない。
スポーツってのはな、自分で面白さを見つける事に意義があるんだよ。
人から与えられたシナリオを楽しみたい人は映画やドラマを観てるだろうに。

--- 僕が望むこと ---
デジタル化によって時代は双方向へと進もうとしているのに、
いまだにこういった一方的なTV放送は後を断たない。

ただ、僕がスポーツ中継に望むことはそのどちらでもないけどね。
スポーツ中継に必要なのは、自分が会場にいるかのような臨場感。
無駄なテロップや口うるさい実況はまっぴら御免だ。

テロップ流す放送ってのは、数年前からかなり一般的に使われてるよね。
これも国民性か。お笑い番組であれやられると引く。
「どうですか、面白いですよ?」という製作者の意図が見え見えなんだもん。

自分で考えることを失ったとき、その人はもはや社会の飼い犬と成り下がる。
連日のようにニュースを賑わす税金の不正使用。
それを「俺もそんな身分になりたいな」などと思う人も日本中には山ほどいるのだろう。
自分だけ豊かになって、それで幸せだと思えるその図々しさが俺には理解不能だ。
人が苦しむ姿を見て笑ってられるような冷血な人間に、僕はなれそうもない。

相変わらずやる事無ぇな?。
設計担当する事になったっていっても、結局作業の絶対量が少ないから
当分この状況は続きそうだ。
もう今月は2回も休んでるから、これ以上休むわけにもいかないし。
まぁ来週は連休あるし、それまで頑張ろう。

--- DWR ---
久々に面白そうな技術の登場だ。
DWRとはDirect Web Remotingの略で、簡単に言えば
JavaScriptからサーバアクションを行うというもの。

http://eireneh.thorubio.org/dwr/

どうやって実現してるのかはまだ不明だけど、レスポンスも速いし中々。
特殊なコンポーネント入れる必要も無いので
今後流行する可能性は高いね。

またまた現場でバグ発生。
原因は、自社開発してる稚拙なライブラリにあった。
これの代用品は世の中にいくらでもあるというのに、
奴らはそれを使おうとしない。
自分達で作った方が良いとでも思っているのだろう。

しかし現実はどうだ。
既存品に比べてバグは多いし、機能は低い。
さらに言おう。汎用性も無い、拡張性も無い、開発性も低い、保守性も低い。
ライブラリを開発するための工数も莫大に掛かる。

これだけデメリットしか浮かばないのに、
それでもこの使いにくいライブラリを捨てようとしない。
おそらく上の奴らはこういう事実を知らない。
ここを変えれば、大幅な経費削減と品質向上が出来るというのに。

--- 非効率な人達 ---
僕がいつも昼食を買いに行く弁当屋の店員は
いつ行ってもドタバタしている。
毎日作業してるんだから、いいかげん慣れてきてもいいもんなのに。

物事を効率良くやろうっていう心構えが出来てないんだろうね。
そう、この現場の人達と一緒なんだ。

--- 斬新 ---
モスにある菜摘バーガーって知ってる？
僕はこの前これを初めて食べて衝撃を受けた。

通常のハンバーガーは具がバンズに包まれてるよね。
これが、菜摘バーガーではレタス(を何重にもしたもの)で包まれてるのだ。
以前ライスバーガーが出たときは「つまりはおにぎりじゃねーか」と
鼻で笑って(？)いた僕だが、今回ばかりは感服。
よくこんな事考え付くよなぁ。やるなモス。

この商品、確か以前はテイクアウトの対象外だったので食べる機会が無かった。
今は菜摘シリーズも全メニュー持ち帰りOKなので嬉しいね。

--- 慣れ ---
今日は珍しく仕事中にずーっと仕事をしている(当たり前)。
最近こういう事があまり無かったせいか、集中力が続かんぜ。

やってる事にあまり興味が無い(=楽しくない)っていうのもあるけど。
さっき話したように、このプロジェクトで使っているフレームワークが
あまりにしょぼい出来だからね。もっとマシなもん作ってくれ。

さらにはソースの標準化ということで
規定のルールに則った作りにしなくちゃいけない。
こんな非効率なコーディング作業はしてて疲れるのだ。

絶対そうとしか思えない。
「求刑懲役４月、手鏡１枚没収」。
そんな判決あるかいな。

--- 嫌われもの ---
なんかニッポン放送は大変らしい。
ライブドアが来たら、出演者は降りるわ社員は辞めるわの大騒動。

そんな事なら何で株式上場したのかねぇ。
こういう危険性がある事くらい上の人間は認知してたはずなのに
この有様だもん。
にしても、堀江さんもまさかここまで嫌われるとは思ってなかっただろうねぇ。

…とか何とか言ってたら、今度はソフトバンクが出てきたぞ。
ありゃりゃ、またライブドアはここに負けるのか。
正直ライブドアに勝ち目は無いだろうな。

--- 毎度恒例 ---
また後ろで始まった。
リーダーとプログラマの醜い言い争い。
プログラマ曰く。
「これとこれが無いと出来ません。だから作って下さい」

ホントこいつには現実を見るという力が無いらしい。
既に手いっぱいのリーダーにそんな作業やる時間がある訳ないのに。
なんでも人任せ。それでこいつはまた「待ち」に入る。
「自分でやる」という選択肢が無いのか。

--- 100％超 ---
ふぅ、今日は珍しく稼働率が100％を超えてる。
つまりは残業だ。
何でこんなに働いてるかと言えば、昨日休んだ分を取り戻すためだ。
一昨日の夜、久々に「仕事なんか行ってられるか」モードに突入してしまって。

僕の理想的な稼働率といえば、大体80％くらいかなぁ。
1日8時間の作業時間の内、1時間半くらいを趣味に費す程度。
これだとかなり快適に作業が出来る。
50％を切ると暇でつらいし、100％を超えると残業しなきゃならない。

ちなみに、今日はたくさん働いたみたいな書き方しておいて
実際の残業時間がたった30分だったことは内緒だよ(笑)。

ちょっと皆さん、聞いて下さいよ。
例のヘナチョコリーダーがまたとんでも無い事を言い出した。

まだ細かな仕様や工数さえ決まっていなかった
5機能のスケジュールをいきなり発表したかと思えば
担当者が全部俺っていうのはこいつ、喧嘩売ってんのか。

--- 超無計画男 ---
計画性が無さすぎるんだよ。
もし俺が倍の工数出したらどうするつもりだったんだ。

本来ならこんな奴のムチャなスケジュールに付き合う気は無いが
何しろここのメンバーは皆こと無かれ主義者だ。
俺がやらないからって代わりに誰もやろうとしないのは目に見えてる。
幸い僕はこういうときの為にスケジュールは余裕持たてせるからね。

それにしても奴には腹が立つ。
無茶なスケジュールを出す事自体そうだが、
それに全く反省していない所がね。
こういう奴には己の無能さを徹底的にわからせてやる必要があるぜ。

--- 計画崩れ ---
あ?あ、それにしてもこのせいで
この先現場でやろうとしてた趣味が台無しになったよ。
あと2週間はそんなに暇も無くなりそうだ。
まったく、タイミング悪いぜ。

昨日書いた通り、一気にやる事が増えてしまった。
締切は来週末だから、そんなに急いでやる事も無いんだけど
僕の性格上、残作業は出来るだけ早く済ませたいっていうのがあって
今日はいつになく気合入れて開発を進める。

正直、僕はペース配分というものを間違えている。
こんなに急いでやったら今後また暇になってしまうというのに。
まぁ今回はそれでも良いんだけど。暇つぶしのネタはもう見つけてあるからね。

--- 年度末 ---
今週は今年度最後の週ということもあって、
現場はおそらく日に日に荒れていくだろうね。

金曜には別チームのリリースがあるらしい。
何てったって、1週間前にはまだ正常系すらまともに動いてない状態だったらしいから
今の段階でもまだまだバグが山のように残ってるはず。

でも、ここのリリースが遅れると
うちのチームにまで影響が出てくるんだよね。
来月末には僕らの方もリリースが待ってるから
実は他人事として見てるわけにもいかないんだけど。

なんか昨日の試合は冷や冷やしたね。
まぁ勝てたからいいけど。
でもあのままじゃとてもアウェー行って勝てるとは思えないよ。

--- トレードオフ ---
こんな言葉がある。
何かを得るためには、何か別のものを切り捨てる必要があるという意味。
この業界では、トレードオフという概念が重要なのだ。

例えば、アプリケーションの速度を速くしようと思ったら
プログラムを改造する必要がある。
そのためには、それを行うための人材と時間が必要だ。
つまり、「アプリの速度」と「時間・人材」はトレードオフの関係にある。

人材は費用という考え方をすれば「時間・費用」と言うこともできる。
さらに「時は金なり」という言葉もある。
これにより、ほとんど全てのトレードオフの対象となるのは
「Cost(費用)」という言葉に集約されるのだ。

--- システム設計 ---
アプリケーションを作るには、まずそのシステムを設計する必要がある。
このとき、トレードオフの考えを持っていない人間が設計してしまうと
とんでもない設計書が出来上がる。
そのシステムを実装しようと思ったら一体いくらの費用が掛かるのか
考えただけでも恐ろしい。

そして、プロジェクトが進んでいく段階でも問題が発生する。
設計上は見えていなかった問題が次々と見えてくるからだ。
これは前にも話したように、どんな設計者が設計したって起きることだが
それをどうやって解決するかは開発者の手腕に掛かっている。

機能を削るのか、それとも時間を掛けてその機能を実装するのか。
決定には予算もからんでくるだろうから
プロジェクトの管理者と開発者がお互いに話し合って決めないといけない。

--- 実態 ---
このプロジェクトでも様々なトレードオフがあるようだ。
しかしそこで対象になっているのは、費用と呼ぶのにふさわしいかどうか…単なるメモリ容量だ。
現代、たった数万出すだけで数GBというメモリを買えるというのに
上の人間はそれを渋っているようだ。
大馬鹿もんだね。開発者を一人1ヶ月雇うだけでその何倍のコストが掛かるんだぜ。

結局、何がシステムの出来を決めるのかということを
全くわかっていないからこういう事態になるんだ。
ここの上層部は、システムの応答時間を0.2秒速くするよりも
2万円の金を節約することを選んだ。

--- ほんの1割 ---
たかが0.2秒というなかれ。
一つページにアクセスする度にその時間が消費されていくんだ。
ページの平均表示時間が2秒だとしたら、
それはシステムを10％速くすることを意味している。

やってみればわかるよ。
よく使うWebサイトの応答時間が1割アップすることが
どれだけ快適に感じるか。

それによって得られる利益は、2万円を遥かに超えるものであるというのに。
こうしてまた、この会社は純利益を減らし続けるのだ…

さて、今日から新年度です。
現場では朝から長ったらしい朝礼。
いよいよこのプロジェクトも依頼主から「斬られ」ようとしているらしい。
来年度には大幅なコスト削減が行われるとか。
まぁ僕はそのときには既にいないから関係ないけど。

にしても、今日から入社・参入するメンバーもいるってのに
いきなりこんな話するのもどうかと。

とか思っていたら。
一番貢献したチームに国内旅行をプレゼントするとかいう話を始めた。
アホか、そんなエサに食いつく奴いんのかね。

--- 席替え ---
年度が変わるということで、席も替えるらしい。
座席表見る限りじゃ、あんまり良い席ではなさそうだ。

--- 主体 ---
何のためにアプリケーションを開発するのか。
答は簡単、それを使う人のためだ。
そんな簡単なことすらわかってない奴が多すぎる。

つまり「お前らは俺達が作ったものを使え」という態度。
これでは、とてもじゃないが使えるシステムが完成するわけがない。
自分が使う側の立場に立ったらどう思うか、これを考えるだけでいいのだ。
自分にとって使いにくかったら、それが当然相手にとっても使いにくい。
自分が便利だと思う機能は、相手にも喜ばれる。

今のシステムを開発していて、ホント不便だなと思うことが良くある。
インターフェイスの悪さが一番だね。
設計段階からこれだから、この先いくらあがこうが無駄だろう。

--- あれれ… ---
ますますこの現場の技術レベルが怪しくなってきた。
データベース専門に担当してる人がいるんだけど、
その人にカラム追加の依頼を出したら
「今あるデータ全部消してもいいですか？」と聞かれた。

おいおい、カラム追加するだけなのに
何でデータ消す必要があんのよ。
専任置いといてこれじゃ、相当やばいんじゃないの。

--- 激重 ---
ここの現場はときどき、データベースが突然重くなる。
しかも、その状況がしばらく続くので
その間は開発の作業が出来ない。
SQL1件問い合わせるだけで2秒近く掛かるんだぜ？
どう考えてもおかしい。

まぁいいや、この間に日記でも書いとこう(笑)。