かっこいいと思う企業名

世の中にはいろいろな会社が星の数ほどある。その中でかっこいいと思うものとそうでもない社名があるなぁ、と個人的に思うところをダラダラと・・・。ちなみに私は元々情報業界の人間なので、そっち業界に偏っている。

例えば、有名だけど、かっこよくない代表をあげるとしたらIBMだろう。略さなければInternational Business Machines Corporationである。和訳してみるなら国際業務機器てな具合か。かっこいいとか悪いとかそういう以前の問題で、そのまんま。社長や起業者の名前が会社名になってるところなんかも、同様にかっこいい以前の問題かもしれない。IntelとかもIntegrated Electronicsの略だから、かっこよくない部類か。インテルに触れたらMotorolaということで、モトローラはMotorのAuraからの造語。モーターがオーラを発している・・・非常に微妙。CPUに縁ある会社が続いたので、ZiLOGも検証しよう。ZiLOG・・・何だろう。語源を知らないが、ZやXから始まる単語は少し厳めしい感じ。かっこ悪くはないが、かっこいいわけでもない。ところで、Xから始まる社名ですぐに出てくるのはXilinxか。まあ、かっこよくない社名の方が多いのでこの辺で終わり。

一方、かっこいいと思うのはApple Inc.だろうか。和訳すると、小学生でもわかるかもしれないが、リンゴだ。リンゴのどこがかっこいいのか？リンゴといえば・・・聖書を連想する。すなわち禁断の果実、知恵の実。聖書の物語で、人間が人間らしい生物になったきっかけであろう。まあ、聖書に禁断の果実がリンゴであると明確な記述があるわけでもないし、「イチジクなんじゃないの」的な突っ込みもあるようだ。が、私の知ったことではないので、ここではリンゴということにしておく。禁断の果実＝コンピュータを手にした人類みたいな連想がとてもかっこいいと思うわけだ。

他には・・・Oracle Corporationとか？神の声を聞き預言を行う預言者。この会社名でデータベースをメインの製品に据えているってところが何となく意味ありげで、ちょっとかっこいい？

ちなみに私のところの社名は某アダルトビデオメーカーと同じで、どうなんだよ・・・とかｗまあ、店舗の名前は全然違うけど。

中古PCにWindows XPの正規ライセンス！

Yahoo!ニュースを見ていると・・・

再生PC向けにWindows正規ライセンス　MSの新プログラムにヤマダ電機など参加

なるほど。いい試みだと思う。世に出回る中古PCは、中古とはいえ十分以上のスペックを有している。OSのライセンスがPC本体と一体になって付属しOSのライセンスも気にしなくてケースも最近では多いけれど、そうでないケースもまた多い。Windows XPを入手する方法みたいなエントリを先日musictrackで見かけてコメントなどしてみたいのだが、中古PCとセットで入手できる方法も提供され始めたようだ。これなら長い間運用された後で中古として出回ることに起因するハードウェア故障によるデータロストの問題さえ何とかできれば、とりあえずVista対応の心配なしにDTM専用機としてXPマシンを手に入れることもできる。

XPはエディションによってはVistaと同じぐらいは長く、少なくとも後五年以上は修正のみのサポートフェイズを残している。パソコンは消耗品なのでどんなにがんばっても十年程度で乗り換えることになるだろう。XPがVistaに比べて安定しているという感じはしないが、過去にさかのぼって対応ソフトやハードが充実しているというのも事実だ。

Windows 7にはXP互換モードを載せてくると発表があった。Virtual PCベースの技術みたいなので、互換性は完全であろう。欲を言えば、DirectXフル対応を期待している。いずれにせよ、Windows 7に修正が出そろい安定するのを待って、XP環境のまま引っ越しするなんて選択肢もいいのかもしれない。さらにM$に要求するとしたらDOS(3、4、5、6は必須か)からWindows 3.1、そして、95、98、OS/2、Me、NT、2000とそれぞれの互換モードも提供してほしい。それらが提供されるなら、私はWindwos信者になる。

私はWindowsユーザだが好きだから使っているのではない。ゲームもやりたいし、高いPhotoshopのWin版を持って日常的に使っている。パソコン教室で人にパソコンも教えるし、どうしてもWindowsを使わざるを得ない。何度か、慣れ親しんだUNIXモドキなLinuxに引っ越ししてみたのだが、ゲームのたびに再起動とかそういうのが面倒で結局Windowsになってしまうのだった。

まあ、たぶん無駄だと思うけど、期待しているぜM$さん。

今後四年の情報業界?

「破壊的な影響力を持つ技術」ランキング、1位はマルチコアCPUという記事があった。すごく違和感がある。

私ならユーザインタフェースとネットワーク技術とクラウドの三つぐらいだけにして、それ以外の技術についてはこの三つに関係あるものとして言及する。

続きを読む "今後四年の情報業界?"

Yahoo!の勧誘

某R市場で商品を取り扱うようになったのだが、今日Y社からうちとも契約してくれという電話がかかってきた。この電話が問題で、まず、誰か名乗らない。いきなり某R社で通販をやっているのを見たといって、うちでもやってくれといいだした。オマエは誰だと確認してようやく名乗る勧誘員。某Y社の勧誘員らしい。しかし、某R社は契約で同時に他社の類似サービスと契約することを禁じている。そう答えると、いくらでもやってるから大丈夫だし、契約しろと繰り返す。よそは関係ないし、契約はしないと再度いうといきなり叩き付けるように電話を切った。いやー、某Y社、なかなかイイ連中使って勧誘してるな。

ダメダメR社Webアプリ

R社と契約して、いろいろ商売の方をアレしている。まあ、売り上げ拡大をねらってのことなのだ。第一次の審査が通って、今日からシステムにログインできるようになった。早速ログインしてみる。一見まともそうなのだが、現在新旧のシステムが稼働しているという。もう、それを聞いただけで絶望感がヒシヒシと・・・。もう、確信と言っていいぐらいだ。新システムが稼働してから日が浅く、さらに未実装機能があるという話なので、迷うことなく旧システムを選択。ところが、うち担当のお姉さんは新システムばかり勧めてくる。お勧めにしては、普及率は二割らしい。最悪な予感がするも、お姉さんは新システムを推して推して推しまくる。後で移行に手間がかかるというし、効率は新システムの方がいいし、大きな未実装機能はトップページ作成機能ぐらいで、問題も発生していないということなので、最後には口説き落とされてしまった。結局、新システムを使うことに・・・。八時間後・・・。なあ、R社さんよ。本気で、これで商売してるの?ユーザーナメちゃだめだぜ。お姉さんは新システムで使えないのはトップページの作成ぐらいだといっていたのに、いざ作成を開始したら必要なページの作成機能の多くが旧システムの設定を使用していて、ダミーページを作って、システム設定を変更して、新システムの穴を埋めるみたいな裏技的テクニックが要求される。おまけにFTPサーバが利用可能になったというので、接続してみたら全然つながらない。おまけにマニュアルページはパスワードが不明で読めない。メールで何回も裏技の確認とか、パスワードとか、いろいろなことを質問しなければ先に進めない。挙げ句の果てに、利用可能になったというのは嘘で明日の朝にならないとFTPサーバにユーザが登録されないらしい。夜間バッチかよ。さっきのメールは嘘か!!というわけで、業界大手のはずだが、R社のシステムは最悪である。なんというか、使ってるだけで、裏側でどんな状態なのか見えてくるってもんだ。嫌すぎだ。だから、私は反対だったんだ。でも、私は文句ばっかりいうという烙印を押されているから、私の意見は通らない。あーあ・・・。

SCO対NOVELL

とりあえず裁判の判決ではUNIXの著作権はNOVELLが所有、らしい。NOVELLのblogにもNovell statement on today’s SCO rulingという記事が出ている。超絶長引くんだろうなぁ・・・。

情報屋名言集

某所の名言。ここではPHPを用いて障害発生時の通知システムを製造していた。当然ながらログファイルのダウンロードをしたり、ユーザの利用状況や時間帯による利用者数の増減のグラフ等いろいろなデータのダウンロードをする機能がついていた。ダウンロードはダウンロード用のPHPスクリプトにダウンロードしたいファイルを喰わせて行うようになっていた。このシステムは結構長時間運用されているらしかったのだが、恐ろしい事実が判明した。開発が一区切りして、試験に入ったときのことだった。自由な操作でバグを発見してみよう的なスケジュールが割り振られていたので、ブラウザからダウンロード用PHPをアドレス直接指定で実行してみた。ファイルが指定されていないのでエラーが出るが、動く。何となく不安になった私は、ファイルを指定して直接実行。ダウンロード成功。ログインしてないのにダウンロードできるんですが・・・。さらにヤバいことにダウンロードすべきファイル以外のダウンロードまでできてしまうことが判明。たとえば、ファイルシステム上のファイルをフルパスで指定すれば、Apaheの実行ユーザがアクセスできるファイルは何でもゲット可能。/etc/usersとかもダウンロードできてしまった。はっきり言って超級のバグである。コレをバグ票に書かずして何を書くというのか。早速、バグ票を起票した。ところが、すぐにPMがやってきて「ヤバ過ぎるバグなので、お客さんに知れたら問題になります。すぐにバグ票を削除して、なかったことにしてください。」・・・。はっきり言って、名言ではなかろうか。

Apache大丈夫か・・・

今月に入ってからApache関連のML に変なメールが混じってきている。大丈夫なんかなぁ・・・。MLなんだから送信者は登録ユーザーだ。変なメールを撒いている送信者をさっさと抹消すればい いのに。こういうことを野放しにしてるというのは団体としての機能がちゃんと動いているのか不安になってしまう。Apache大丈夫か???

天下り+仕事=古いシステム?

年金の管理システムが古いコンピュータ動き古いシステムで入力ミスも検出できない機能程度しか持っていないにも関わらず、それをいつまでも運用しているのはメンテナンスをしている会社が天下り企業だからだとニュースで解説していた。これはどうなのだろう。新たに新しいシステムを構築し、利用者を再教育し、新規システムに発生するであろう既存バグを上回る数のバグを修正し、安定して業務が行えるようにするまでいったいどれだけのコストがかかるのだろうか。途方もない数字に違いない。古いコンピュータが問題の一端であるならば、その入れ替えコストもかかるだろう。さらに機能追加によってサーバの処理能力も増強しなければならない。当然ながら不完全なデータで運用されている現在のシステムで使用しているデータを新しいシステムに移し替えなければならない。この際にさらなる間違いも混入するだろう。これらをすべて行うコストは先ほど言った途方もない数字をさらに上回る。ニュースでは新しい高機能なシステムを何で導入しないんだと簡単に言っていたが、非常に素人くさい意見でしかないとも思える。一方、要求を満たせていないシステムはやはり更新されるべきであるという考えもまた正しいものである。どちらにせよ、天下り企業を優遇するためだけに既存システムのメンテナンスをダラダラと続けているわけではないはずだ。

情報屋名言集

　もうどうしようもない「いっせーのーっで!!」と同じ現場の名言である。ここの現場はうちの会社と現場の間に五社ぐらい挟まっていた。丸投げ丸投げで中間マージンを搾取するパターンだ。で、それぞれの会社に残業時間の上限が定められていた。各社間の契約もそうなっていたはずだし、私の契約もそうなっていた。問題なのはこれが書類上のものであること。私は月に平均九十時間?百時間の残業だった。他のメンバーはもっと多かった。私は工数を多く見積もったりして、仕事の量を制御していたからこれですんでいたのだ。で、早くできたらそのまま帰るという(笑)。こうでもしないと死んでしまうだろ。しかし、これだと"問題"になる。契約違反というわけだ。そこで現場の営業の人が一言「ちょっと残業多いので、20時間までに調整しておいてください。」。他の営業の人は「昼休みは休んでください。認められません。仕事をしてもしなくても休憩時間に計上しておかないと問題になります。」てなもんだ。労働基準法というのは現場では平気で無視される。問題も発覚しない。なぜなら、このように現場からの報告が改ざんされるからだ。営業の人が一括してデータを調整する現場もあった。

プログラムにバグ

　よくニュースで「プログラムに誤りがあり・・・」みたいな言い回しを見かける。世間一般ではプログラムには誤りがないという認識があるようだ。これは間違いである。誤りのことを専門用語でバグと呼ぶ。どんなプログラムにもバグはあるのだ。バグが発見されていないというケースはあるだろうが、まったくバグのない実用的なプログラムというのは存在しないといってもいいだろう。問題なのはバグの性質である。いきなりOSやそのプログラムが停止するようなバグは放置されるべきではない。しかし、表示がずれるだけのバグなど実質的な被害がなかったり、ほとんど利用されることのない機能におけるバグなどは放置されていることも多い。メンテナンスをするというのは長期にわたって運用されるプログラムでは重要だ。理想ならばバグは発見され次第修正されるべきものだ。しかし、バグの原因究明や修正を行うには人員を配置しなければならない。システムを停止させる必要もあるかもしれない。人員を配置したり、システムを停止するということは直接金銭的・時間的コストが発生する。そのコストを別のところに回せばもっと優先度の高いバグの修正や新規機能の開発が行える。桜の開花予想のプログラムにバグがあったというニュースが流れているが、開花予想がずれたからといって人は死なない。もし、開花予想プログラムの開発チームが別の仕事で人死がでるようなバグを抱えていたとしよう。この場合、桜の開花予想に関するバグは放置されるだろう。どちらが得か。結局のところ損得勘定でプログラム開発は進むのだ。場合によっては、深刻すぎるバグすらも放置される。これが現場というものである。ちなみにバグにはいろいろと種類があって、プログラムの記述ミスだけでなく、プログラムの仕様に関する記述漏れ・ミス、データの間違いなどもバグとして扱われる。

情報屋名言集

　最近、女性は産む機械発言で大人気の産ませる機械・柳沢厚生労働大臣だが、「いっせーので!」と同じ現場でもこんな名言があった。飲み会が大々的に催された時のことだった。お酒がテーブルに並べられるとPMが女性社員を呼び集めてこういった。「よし、女の子は酌をしろ。」と。その後、ことあるごとに酒をついで回る女性陣。女性陣が男性陣からお酒をついでもらうという光景は最後まで見なかった。大きな会社の男性と女性の立場の違いというのは、こうなんだろうか。いいとこない現場だなぁ・・・。

情報屋名言集

　「いっせーので!」と同じ現場の名言。いよいよ残業がきつくなってきたときの、朝のミーティングでのリーダーの一言である。「えー、そろそろ限界を感じるような状況になってきましたが、みなさん逃げないでください。」。ここは社会人が仕事をする場であって強制労働な収容所ではないのだが・・・。まあ、はっきり言って似たようなものだった。恐ろしいことである。

情報屋名言集

　「いっせーのーっで!!」と同じ現場の名言である。まあ、ここはメンバーの多くが激しい残業にさらされて、電車に乗っているか、寝ているか、食べているか、トイレにいるか、シャワーを浴びているか以外の生活が仕事しか残っていないという現場だった。夢の中でもソースコードをスクロールさせてバグをとっている夢を見るという状態。挙げ句の果てに夢の中のソースで見つけたバグが実際のソースにもあるという・・・。というか、夢の中に担当のソースが寸分違わず出てくるのだった。こういう夢が私だけではないことがすぐに判明。ある日の朝、ミーティングでメンバーの一人が「夢の中で気がついたんですが・・・。」と発言。それに対するリーダーの発言は「君もイヤな夢見てるな・・・。」であった。恐ろしいところであった。

情報屋名言集

　私が就職した会社の社長の名言である。ある日、新入社員が入ってきた。私より何歳も若い人だったのだが、専門学校を首席で卒業し、仕事も早くて正確かつユーモアも忘れないといういわゆる"使える人材"であった。某人材派遣会社のシステムで一緒の現場になるまで、彼が入社してから一年ほどは間があったのだろうか。その間、彼は本社持ち帰りの開発プロジェクトに所属していた。うちの会社は本来ならば派遣ではないのだが、派遣っぽく他所のプロジェクトの増援として本社とまったく別の場所で、まったく別の会社に所属しているように見せかけたりして働くことが主流であった。業界でよくある多層構造が以下のような流れなのだ。システムを作ろうと考えた会社Aが、大きな会社Bに開発を依頼する。大きな会社Bは仕事を別の会社Cにそのまま渡して開発させる。Cの指揮を執るためにBの社員が派遣されることもあるし、Cにすべてが完全に一任されることもある。AはBの社員が開発していると思っているのだが、そうではない。ここで問題なのは、Cかというとそうでもない点だ。CはCで別の会社五社C?Gに仕事を分割したりして、仕事を投げてしまうのだ。むろん、それぞれの会社は中間でAから出ている予算の中から、自分の取り分をとっている。仕事を丸投げすることによって、自らの社員を働かせることなく、自ら大量の社員を抱えることなくある程度の利益をたたき出せるのだ。この例ではC?Gが最下層ということになる。この多層構造が多いときには十段構造とかになっている。当然、トップに君臨するお客様から出たお金は、最下層に行き着く頃にはとんでもない金額になっている。実際の開発現場とお客様の距離が離れているために、中間の会社を経由してお客様のシステムに対する要求などの情報が伝わってくるのに時間がかかったり、一部欠落したりする。こうなると当然恐ろしい結末が待っている。そうなる前に中間の会社がスポッと抜けたりする。問題が起こる前に契約切れなどを理由にして逃げてしまうのだ。そうなると、新たな会社が間に入ったり、抜けたところに関係していた会社が調整に追われたりしてますます情報は劣化する。こうやってピラミッドは、最後にはガタガタと崩れるのだ。まさに件の彼、いや私の就職した会社がいたのはこの最下層だったのだろう。詳しくは聞いていないので実際にどうだったかは知らない。彼と一緒に働いていたチームの二名は体調不良でリタイア。最後には彼だけになっていた。彼がずっと徹夜して働いてくれたら納期を延ばしてもいいというような話もあったようだ。意味がわからない。兎も角、彼は会社に何ヶ月も泊まり込んで仕事をした。最大で六百時間を超える時間働いた月もあったらしい。一月が三十一日で、一日が二十四時間だ。ということは、一月は二百四十四時間しかない。六百時間は割合して八割に相当する。異常だ。すべてが無茶苦茶で残業代は鰻登りに上昇。ついに最下層に流れてくるお金よりも、彼の残業代の方が高くなってしまった。で、プロジェクトが崩壊して地獄は終了した。その時に社長は彼にこういったらしい。「赤字になって給料が払えない。残業代を有給で立て替える。」。彼はその後更に一年ほど会社にとどまっていた。が、あまりの環境の悪さに退社した。その時、何十日もある有給休暇の残りを消化してから、やめようとした。が、「そんな休暇の取り方は容認できない。」というありがたい社長のお言葉によって、彼はただ働きで会社での一生を終えた。恐ろしいことである。

情報屋名言集

　「いっせーのーっで!!」と同じ現場の名言である。この現場はCVSなどの頭のいい方法でソースを管理するということを放棄していた。ソースの管理はファイルサーバに手動で修正したソースを丸ままコピーするという原始的な方法だった。連日連夜、残業に次ぐ残業で判断力の鈍ったメンバーばかりが惰性で開発を進めているため、ファイルの削除や上書きでソースがロストするのは日常茶飯事であった。その場合は全員が持っているソースの日付を確認して一番新しい日付のものを書き戻すという恐ろしい解決方法をとっていた。日付が新しいからといって最新ではないという問題についてはつっこんではいけないというのは、暗黙の了解だ。何も修正していないソースをただ単に保存すれば、当然日付だけは最新になる・・・。そういう場合はバグ表をさかのぼって、再発生したバグをまた修正するという作業が遠からず発生するのだった。ソースの中に過去に修正した箇所はすべてコメントで残してあるのだ。バグ表で解決されているのにソースにコメントがなかったらロストした箇所だと判断できる!頭いい!!最高!!!ソース全体が過去の修正箇所の残骸で埋め尽くされている!!!!死んでしまえ!!!!!ソースは通常一つのシステムに一セットだと思うのだが、テストサーバが五台あって、そのそれぞれにソースがあり、同じ修正を修正担当者がすべてのサーバのソースを修正することになっていた。オリジナルが一セットあって、さらにテストサーバの数だけソースがあったのだ。誰かが修正していたら、自分の修正は後にしなければならない。修正するファイルは大きな声で「今から＊＊＊を修正します!よろしいですね!!」と確認。こんなことを毎日繰り返し、合計六セットのソースは日を重ねるごとに微妙に食い違い、半年後には全く別物が六本あるという状態となった。あまりのひどさに何度もPMに「ソース管理のシステムを導入してください。このままだと終わるものも終わらない。」と提言したが、「不注意をなくせば問題ない。CVSの設定をする?そんな時間はありません。CVSなんて、みんな使ったことがないからますます遅れます。」という返答。
確かに、あのプロジェクトは百名以上のエンジニアをキープするためだけでも、月に少なくとも一千万円はかかっていただろうと思う。そんなところで、本来の作業以外の工数を取れという要求を受け入れるのは受け入れがたいものだったに違いない。しかし、それをしないことによって、少なくとも半年延びた。私が抜けた後どうなったのかは知らないが、続行していただろう。一年延びたら桁が繰り上がってしまうわけで・・・。上層部の人間は恐ろしい決断をあえて下すときというのがあるはずで、それはプロジェクトの崩壊時か、立て直しの時か・・・。いずれにせよ、恐ろしいところであった。

情報屋名言集

　とある現場に途中から参加した時のことだった。スケジュールが遅れていて、エンジニアの数を今の倍にすれば元通りのスケジュールに戻るという判断の下、私を含めて五名のエンジニアがその現場に投入された。我々が現場に入る前にPMからの状況説明があった。「フレームワークは完成しています。仕様書もすべてお客様のレビューを通過して完全なものになっています。今回の増員でスケジュールも問題なくなるので、皆さん定時に帰れます。」という非常にすばらしい状況だ。後は作るだけ。まあ、知的欲求を満たすには多少物足りないところもあるけれど、作業がコーディングだけだったとしても、それでも現場ごとに違う思想があったりしてそれなりに楽しめるものだ。で、早速各種資料やフレームワークのソースをもらって検分。・・・これ・・・日本語通る?本当に?試してみた。ダメだった。日本語はすべて文字化け。挙げ句の果てに、ちょっと動かすだけで頻繁にNullPointerExceptionがでてアプリケーションサーバごと死ぬ。そうでなくても、セッション情報の管理周りの処理でメモリリークして、しばらく動いてても死ぬ。どこが「フレームワークは完成しています。」だ!!そして、仕様書も同じような調子であった。画面の見てくれだけ決まっていて、中身の仕様がない画面があったりする。開いたら大きく「仕様問い合わせ中」とか書いてある仕様書もある。翌日から定時帰りのはずの現場は消滅し、地獄のような場所に変化した。

情報屋名言集

　例の人に関する追加名言である。まあ、今回は例の人本人の名言ではないのだが。あまりに居眠りをするので、例の人の会社組織としての上司に注意してもらうようにねじ込んだときのことだ。上司の人は、居眠りを続ける例の人を起こしてこう言い放った。「船は進んだか?」、と。・・・あのなぁ、この人が仕事を遅らせている原因の一つなんだぞ。それを船が進んだかって・・・。例の人みたいなのには、もっときちんとした処分を希望する。

情報屋名言集

　どこの現場だったかなぁ・・・。忘れた。深夜二時。我々のチームは仕様バグの改修に追われていた。まあ、お客さんの考えているものと作ってるものが違ってしまうのはよくあることだ。・・・あってはダメなんだけど・・・。まあ、それで深夜の二時・三時までの仕事になった。とある人が、トイレに行って帰ってきた時の台詞。「トイレに血溜まりありましたよ。」「え?」「いや、吐血だか痔だか知りませんが、個室の中に・・・。」。過労とかで、吐血したんじゃないことを祈るばかりであった。汚い話だが、他の現場ではトイレから汚物が飛び散って天井まで汚れていたことがあった。トイレの中は一面水浸し。所々に汚物が混じっている。あの個室の中で爆発を引き起こした人物はどんな姿で個室から出てきたのだろうか・・・。謎。

情報屋名言集

　某社の予約・発券業務システムを作成していたときの名言である。お客さんが作ってほしいものと実際に作っているものにミゾがあるようなシステムだった。原因は要求の分析後に、できた仕様書をお客さんとしっかりレビューするという手間を「納期が間に合わない。」という理由から、かなり省いてしまったためである。実際に文章にしたものとお客さんがこうだと思っていたものに食い違いが発生していることに気がつかなかった。私は基本設計から実装までを行うということで現場に入った。まあ、基本設計はほとんどできていた(お客さんと食い違いはあるにせよ、文書としてはそろっていた。)ので、作業はそれの手直しからだった。開発が進み、実装も佳境という段階で、基本設計をはじめに書き起こしたグループが軒並み契約切れ。延長を受け入れなかったため、離脱。そのため、実際に実装作業を行っていた人間が繰り上がりでそれぞれのサブシステムの責任者となった。私は同じ会社の人と予約サブシステム全体を担当することになった。私が画面側を、もう一人が既存の基幹システムとのインタフェース部分を担当することになった。一応、私たちの配下には三名のプログラマが配属された。二人のところに三人増員し、スケジュールの遅れを取り戻そうという計算らしい。まあ、毎度のことながら増員された三名は素人だった。二年間研修を受けてきたというのでそれなりに使えるはずという話。現に二人は人並みに仕事をしてくれて、細かなバグの修正などを積極的にこなしてくれた。うん、二年間のうちにため込んだ知識はムダではない。的確な判断と技術、それに初の現場で張り切って仕事をしてくれた。が、残り一名が大問題だった。三名のうち二名は一人前の仕事をしてくれる。ところが、最後の一人はすべてを台無しにするぐらいひどかった。某巨大企業の研修は高品質なので有名なのだが、それを二年も受けて、ここまでひどいというのはどういうことだ。一から十までバグの説明をして、修正箇所と修正方法まで教えて、数時間たってもできていない。試験をさせればまったく違う箇所を試験していたりする。バグ修正にしても試験にしても、仕様書の改訂にしても任せた仕事がすべて期待通りの成果として現れてこない。ある時は二時間かおきに進捗を確認してそのときは「問題ありません。」と答える。わからないならすぐに報告するように念を押す。しかし、十分な時間が経っても完了の報告がこない。「できてますよね?」と聞いたところ、「できていると言えばできているし、できていないと言えばできていない。」と答えやがった!意味が不明!!なんだそれは!!!馬鹿にしているのか!!!!結論としては、まったく進んでいなかった。いくら手間取っても、調査から何から全部含めて二時間あれば終わる作業だ。自分でやったら一時間以内でできるだろう。しかし、私には他の作業がある。だから、彼に仕事を任せたのだ。頼れる二名も別の作業をしている。彼に頼まなければ遅れが発生してしまう。頼みたくないけれど、頼まざるを得ない。だから、こまめに進捗を聞いて疑問があったらその場で解決して作業を続行できるように配慮していたのに・・・。結局、彼から仕事を取り上げ、自分で作業を完了させた。他の人にも無理を言って作業を手伝ってもらい、何とか許容範囲内の遅れですんだ。彼にはバグ修正の再確認作業を与えて放置。しかし、彼はその後、仕事をせずに居眠りをしていた。彼はその状態で私よりも遅く帰る。何時間も残業するのだ。残業代のタダ取りだ。上層部に報告しても苦笑が帰ってくるだけ。何なんだろう・・・幹部の息子とかそんなのかもしれない。いずれにせよ、地獄の住人に違いない。

情報屋名言集

　都内某所の現場であった。現場では某大手通信企業のシステムを開発していた。前日にISO14001の監査が予定されているというメールがビジネスパートナー(早い話が外注社員。)全員に流れていた。まあ、それはいい。問題はそのメールの最後の方に「ビジネスパートナーの皆様は監査員の到着する午前**時の十五分前にトイレまたは会議室で待機してください。万一、監査員に何か聞かれた場合には「環境問題に取り組むために社内では様々な取り決めがあり、私自身も環境のために使い終わった会議資料などをリサイクルボックス等に入れるなどしております。」などと答えてください。他の質問には急ぎの用を理由に会議室やトイレなどに待避してください。このメールは読んだら即破棄してください。破棄した後、リーダーがチェックを行います。」とか書いてある。・・・「なお、このテープは自動的に消滅する。成功を祈る。」ぐらいにしたらおもしろかったのに。で、当日。監査員が来る時間の十五分前のことだった。いきなり放送が始まった。「時間になりましたビジネスパートナーの皆様はトイレや会議室に待避願います。時間になりましたビジネスパートナーの皆様はトイレや会議室に待避願います。」・・・。をい!我々は普段そんなに何かまずいことやってるのか!!意味不明であった。

情報屋名言集

　「いっせーのーっで!!」と同じ現場の名言である。その日は朝から仕様変更が行われた。仕様書の変更はすでに行われなくなって久しく、実装と曖昧な表記の仕様書を各人が「こうだ!」と思いこんだものが仕様となっていた。我々の担当するサブシステムは端数処理はすべて四捨五入するようになっていた。これは仕様書に明記されていたので、まさかここが問題になるとは思ってもいなかった。PMが我々のサブシステムを動かしていたときに、金額を入力するところで1円を入力したのが事の発端だった。PMは意味のある値や文字列を入力するのが面倒になっていて、画面中の入力項目を1、2、3・・・と適当に埋めていった。えいやとばかりに入力確認画面へ。各種数値が計算されて表示された。そこでPMはみてしまった。金額を入れたのにゼロ円と表示されていたのだ。PMは考えた。金額を入れているのにゼロ円ということはない。これはバグだ。無論、仕様書は単に納品するためだけに存在する無用の長物と化していることをPMは誰よりも知っていたので、仕様の確認はしなかった。ということで、突貫工事を任せたらどんな無理難題も高速に処理するという評価を受けている私に直接指示がきた。すべてのソースを修正し、四捨五入を切り上げにせよ。私は一日がかりですべて修正した。システム全体を通しての決まり切った処理なので共通処理が用意されているのだが、それぞれの局面で微妙に数値の扱いが変わるため共通処理を使えない箇所が多いのだ。結局、誰も共通処理を使わないという文化ができてしまっていた。おまけにソース管理はファイルサーバにの担当者が手動でコピーするという方法であり、CVSなどは使われていない。誰がどのソースを修正しているのか予測不能だ。スケジュールも担当者もぐちゃぐちゃになっているのだ。CVS使ってたらガツガツ修正作業もできるのだが・・・。誰がどのソースを修正しているのかチーム全員と連絡を取り合いながら、それぞれの端末まで出向いてちょっと修正させてもらったり、全員に大声で修正するファイルをいったん書き戻してもらうように指示したりして、何とか日付が変わる二時間前に終了。PMに確認してもらった。PMは再びなんちゃってテストに突入。一時間後。何があったのかは知らないが、気に入らなかったらしい。私のところへきて「やっぱり元に戻してください。徹夜してもかまいませんから。」。まて!!今日の作業は何だったんだ!!!今日の予定は朝言われた仕様変更で一個も消化できていない(私が今日行う予定だった本来の作業は、誰かがやってくれているらしい。その人は複雑な処理の実装で苦戦を強いられていたようだ。いまだ作業中。)んだぞ!!!!何度も言うが、ソース管理は手動である。念のため作業前のファイルを自分でコピーして持ってはいるが、いろんな人が入り乱れて作業しているから下記戻すことはできない。ファイルサイズ軽減と様々な理由のために改行コードを削除してからファイルサーバに置くというルールも存在(コメントもファイルサイズを圧迫するという理由から書かないように指示されている。あと、十行で一テスト行わなければならないというルールもある。100行のソースなら、どんなソースでも十個テスト項目を作らなければならないのだ。例え、コメントが十行あって、よくあるインタフェースの定義だけしか書かれていないクラスであっても、だ。一行にしてしまえば本当に必要なテストだけで済む。すばらしい。理論的だ!!げふっ(吐血)。)していて、単純に行比較で差分をとるということもできない。結局、一日かけた作業をまったく同じ手順で再度行うしかないのである。再び、全員に声をかけながら作業に入る。深夜だというのに、誰も帰る気配すら見せない。二度目の作業だから効率は上がっている。地獄のような場所であった。

情報屋名言集

　今回から情報屋の名言集を追加していこうかなぁ、と思い立った。私が情報屋であった頃に遭遇した名言たちに登場してもらいたい。第一回は「いっせーのーっで!!」である。とある、大企業のシステムのサブシステムの開発に携わっていたときだった。プログラミング言語はJava。アプリケーションサーバは、ここで言うと会社がわかってしまうから秘密。DBはオラクル。フレームワークはオリジナル。開発期間は三ヶ月だったが、すでに三ヶ月延びている。クライアントには最終調整中とアナウンスされているが、実際には開発が完了している箇所は皆無。クライアントはシステムテストをしていると思いこんでいる。負荷試験がスケジュールに入っていなかった(なんでだ!!)し、まだそんな段階でもないのだが、クライアントとのミーティングでクライアントからPMに「どれぐらいの人数で使えるのか」と質問があったらしい。そこでPMが帰社してすぐ、急いで実施せよとの命令が・・・。我々のサブシステム開発チームは総勢五名。リーダー一名。SE兼プログラマ四名。はじめは私ともう一人の計二名だったが、スケジュールが遅れまくった。ありとあらゆるバカなことが我々に襲いかかっていた。もう、悪い開発現場コンテストなんてものがあったら、優勝できそうだった。そのため、三ヶ月前に二名増員されていた。ちなみにその二名は専門学校を出たての素人。Javaの開発現場なのにJavaを知らないときたもんだ。でも、PMは増員とスケジュール延長三ヶ月でクライアントの最終期限にギリギリOKと判断している。すでに期限のやってくる六ヶ月目だが、ゴールの目処はつかず。PMは最終期日にどんないいわけをするのだろうか。まあ、それはいいとして。リーダー「では、今日は負荷試験を急遽実施することになったから。いっせーのーっで、で送信ボタンを押しましょう。」全員「はーい。」リーダー「いっせーのーっで!!」外注社員A「あ、すいませんズレました。」リーダー「しっかりしてよー。じゃあ、もう一回。いっせーのーっで!!・・・押したぁ?」全員「押しました・・・。」外注社員A「・・・あ、落ちた。」外注社員B「あれ?」私「・・・変ですよ。」外注社員B「これって・・・Aさんが入力した内容では・・・。」私「こっちもそう見えますね。」。というわけで、ツールも使わずに負荷試験と主張するリーダー。隣では他のサブシステムも同様の負荷試験を実施している。誰もテストツールを使おうなどとは言い出さない。タイミングもマチマチでいい加減な同時処理にも関わらず、最初にボタンを押した人の画面が全員に表示されるというバグを出してくれたフレームワーク。というか、このフレームワーク大丈夫なの?今本当なら今頃、システムテストしてなきゃならないんだよ?いや・・・まあ、負荷試験はシステムテストの範疇だから間違ってはいない。だけど・・・システムテストって、開発が終わってからするよな?開発は元のスケジュールより六ヶ月延長された。が、契約が切れたのを理由に私のいた会社は逃走したため、結末は見なかった。最終的に私が抜ける寸前、チームは八名まで増員され、試験項目を消化するだけの目的(進捗表を見せて、クライアントに進んでることをアピールするのだ!!!!!)で結合テストをしていた。地獄のような場所であった。

プロジェクト発火

　スケジュールが五日遅れになった。まあ、リスケもせずに五日分の追加作業を頼まれたわけで、遅れてるも何もあったモンじゃない。しかし、作業を振ってきた本人から「今週から来週で取り戻せ。」とのお達し。「あんたが遅らせたんだろう。リスケしろよ。」というような意見は当然ながら曖昧に流されてしまう。休出も視野に入れろとのことだが、今週末は某Hとお出かけなので、そういうことになったら風邪を引く予定。幸いなことに休日に休んでも有給は消費しない。で、ここからがアホ。同じフロアにもっともっと大企業相手のシステムがある。私がこの現場にきたときに配属された極秘プロジェクトだ。現場の社内でもっとも重要度が高いプロジェクトの一つで、内部でもかつて関係した人以外は秘密という変なプロジェクトだ。こいつが時を同じく火を噴いた。挙げ句、定時後の数時間手伝えという命令が現場全体に・・・。他プロジェクトは無理をしてでも人間を回せという命令らしい。こっちも遅れてるんだ。勘弁してくれ。そうやって人手を集めて果たしてどれだけ遅れを取り戻せるのか・・・。おまけに私はそのプロジェクトにいたので強制的に時間をとられることになっている模様。それを聞いた途端、作業効率を落としてダラダラ作業に移行。ヘヘヘ、俺に頼んだらもっと遅れるよー。

他プロジェクトヘルプ

　さて、昨日書いた他プロジェクトヘルプだが・・・毎日ヘルプの人は十八時から二十二時まで作業。最大で二十三時って何だ。そのプロジェクトの経験上仕事がなくても待機なんだろうなぁ・・・。土日は十時から二十三時の作業になっているのだが、予定があるので外してもらうように手配。あっちこっちから人を集めて人数で押し切るつもりらしいが・・・。