123. IT戦記1 (2002/5/1)


戻る前回次回

SAPIO という雑誌で現役の日本人傭兵が連載を持って文章を書いていたのは、私にとってそれなりに興味があった。まさしく、現代の傭兵である。

傭兵というとまず、中世ヨーロッパ(30年戦争など)やそれを元にしたファンタジー世界、あるいはフランスの外人部隊や漫画「エリア88」に出てくる傭兵の戦闘機パイロットたち、またはバチカン市国でいまも法皇に仕えるスイス人傭兵なんかを思い出す。ただ、それらは日常とはかけ離れたところにある一つの物語のような意味しか持たない。

フリーランスや派遣社員というのも一種の傭兵のようなものではないだろうか。武力とは関係ないが、戦争を嗅ぎつけて集まり、戦争が終わると去っていくあたりが、一つの仕事毎に離合集散するフリーランスや派遣社員にも共通する点である。

私も派遣社員のようなこともやってきた。厳密に言うと、私は企業の社員だからいわゆる派遣社員ではない。しかし私のいる部署は、セガの親会社で有名な情報サービス大手 CSK のように、情報システムの構築をやるほかに、技術者を派遣することが多い。

今回は、派遣技術者として関わったプロジェクトについて書くことにする。一応シリーズ化をにらんで番号をつけてみた。最近はみずほ銀行の ATMトラブルがあって、情報システム系の仕事でトラブルが起きるというのはどういうことなのか、興味のある人も多いのではないだろうか。

■会議室で仕事をする人々

私がそこへ行くことになったのは、ゴールデンウィーク直前のことであった。火を吹いているプロジェクトがあり、すぐにでも人員が欲しいらしい。行ってからさっそく告げられたのは、ゴールデンウィーク中も来てくれとのことだった。

仕事場は会議室だった。百貨店の情報システム部の会議室である。部屋が一杯なので仕方なく会議室を作業場にしたらしい。

私は下っぱなので、まずは画面系の仕様変更に対応してコーディングする作業をやってくれと言われた。画面系とは、システムのうちお客さんが直接触る部分である。仕様変更とは、あらかじめこういう風に作ってくれと言われて作ったらやっぱりこうしてくれと言われて変更したり作り直したりすることである。やってきて最初の日だったので、私の実力を見定めるという意味もあり、作業の指示は逐一 Hさんから受けた。

会議室には、三台の液晶モニタつきデスクトップマシンと、現地作業用のノートパソコンがいくつか並んでいた。

後日聞いた話を元にこのときのプロジェクトの状況を説明すると、こういうことである。開発を請け負った会社が、自社のマシン上でシステムを作った。それなりに動くものができたので、お客さんのところに行って本番用のマシン上で試しに動かしてみた。ところが全然動かない。動くことは動くのだが、あまりに処理が遅い。それもそのはず、自社のマシン上でテストしたときには、テスト用のデータがあまりに少なすぎたのだ。本番用マシンの数分の一程度のパワーしかないテスト用マシンでは、データ量も数分の一程度にして開発しておけば、実際に本番用マシンで本番用のデータを使った時にちょうどよくなるわけである。しかしどうやらこのときは、テスト用データの量があまりに少なかったため、作ったシステムのパフォーマンスが低すぎたことに気がつかなかったようなのである。

そこで、あわてた開発会社が、技術者をお客さんのところに半ば常駐させて、本番用マシンでちゃんと動かすにはどうしたらよいのかを調査するとともに、現地にしかない本番用データを使ってシステムのパフォーマンスを上げるために改良することにしたようである。

私はそんな中に要員として送り込まれた。

幸いにして、ゴールデンウィークは最初の一日二日だけ出てきたら、あとはもういいから通常通り休んでいいということになった。

■チーム編成

プロジェクトはそれなりに大きかった。とはいっても大体 20人くらいだろうか。その中にいくつかのチームがあり、それぞれがそれぞれの部分を担当していた。さきほど述べた「画面系」のほかに「バッチ系」「帳票系」と大きく三つのチームがある。ほかに、ハードウェアや OS のセッティングを担当する人や、データベースやその他のミドルウェア担当の技術者、データベース設計者なんかが、プロジェクト外からのサポート要員ということで関わっていた。

このシステムの全容について詳しく説明するのはまずいのだが、このシステムの特徴は、とあるミドルウェアを使って大量のデータを簡単に多角的に分析できるということにあった。分析は各々のパソコンの画面上でおこなうことができるので、このミドルウェアによって作られる画面系の部分の比重が大きかった。ミドルウェアとは、OS ほど基本的なソフトウェアではないが、それに準ずるほど基本的な機能を提供するソフトウェアのことである。ミドルウェアは OS たとえば Windows のように、それ自体が何かできるわけではなく、あくまで他のソフトウェアに使われるための機能を提供する。

画面系の開発にあたっては、下請けの小さな会社が取締役をリーダーとして請け負っていた。そもそもこのプロジェクトは、そのミドルウェアを売るために提案されたものであり、今回うまく成功したら次々に他の会社に売り込んでいって、この会社もサポートとして密接に関わっていくことになるとのことであった。今回のプロジェクトにおいて、比較的安定して成果を残していたのはこのチームである。

その画面系を補助するものとして、バッチ系と帳票系を含めたトータルな設計と実装を担当したのが、沖縄出身の三人組のチームである。ここは厳密には一人と二人に分かれていて、実は二つのグループになっており、それぞれ別のとある会社から仕事を受けてやってきたいわば孫請けの会社二つである。この二つの会社は、それぞれ社長がやってきて仕事をしているから、本当に小さな会社である。

ほかに、また別の小さな会社から二人、設計を担当していたという二人がいた。そのうちの一人が、私の初日での仕事を指示した Hさんである。私が来たときには、システムが泥沼にはまっていたので、画面系の手伝いをしていた。聞いた話によると、彼が当初はデータベース設計をしたのだが、どうしてもパフォーマンスが出ないので、結局データベース製品売り込み担当の技術者を読んでその人に設計をやりなおさせたそうである。

まさに多国籍軍である。

私も今に至るまで結局よく分かっていない面があるのだが、このプロジェクトはまず百貨店から技術商社が受注するという形で始まっている。技術商社とは、要するにマシンやソフトを売るところである。ただし、マシンやソフトはそれだけでは使えないので、使えるようにセッティングしたり、マシンとソフトを使ったシステムをお客さんごとに構築することで、高額なマシンやソフトを売ろうという方針なのである。

その技術商社の下には、直属の開発子会社があり、技術商社の販売するマシンやソフトを使ってシステムの設計・開発を全面的におこなう。さらにその下に、下請けの開発会社がぶらさがっているのである。私の会社は、というか私の所属する部署は、そんな下請けの開発会社の一つの位置づけである。

だからプロジェクトのトップは、技術商社の営業になる。その営業の下に、開発子会社の部課長がいて、その下に下請け会社のリーダーがいる。私は一人で来たので、いまから考えればプロジェクト的には下請け会社のリーダーだったようなのだが、仕事は各チームの下でやった。営業、それも技術商社内の位置づけでは課長より下の、ヒラに近い営業がリーダーというのには違和感があるかもしれない。しかし、技術商社がお客さんから仕事を取ってきた以上は、彼ら営業がリーダーであるというのは当然である。私は、このようなことになったのには歪みを感じるし、そう思うのは私だけではないのだが、それについては業界の持つ根深い問題があるので後述する。

さすがに営業も、システムに関する知識がなければシステムを売ることができない。そこで、営業サイドにも技術者がいるのだ。営業サイドの技術者は、営業サイドだけあって一つ一つの商品を専門に扱っている。たとえば、Oracle というデータベース製品なら Oracle だけを専門に扱い、このデータベース製品がこのくらいの性能のマシン上ならこれくらいの性能を発揮するということを熟知している。この営業サイドの技術者の仕事は基本的にデータベース製品を売ることである。だから、営業マンでもあり技術者でもあるという微妙な位置にある。ただ、データベース製品などの製品は、単体では絶対に売れないので、システム全体を売りにかかる営業専門の人の補助として活動している。

■チーム間の力学

チームに分かれていたことにより、それぞれのチームの間には、友好から行き違いまで色々とあった。

まず、営業と開発の間には、基本的にあまり良い関係はなかった。開発は営業から、無理な要求とスケジュールを押しつけられて、文句を言いながら仕事をしていた。システムを作るのは開発だが、システムを提案するのもシステムを動かすマシンを決めるのも営業である。こんなシステムをこんな貧弱なマシン環境で作れるわけがない、と言ったところで通らないのだ。営業は、開発が山場に掛かると、差し入れを持ってきて開発陣をねぎらったりもするのだが、基本的には尻を叩くのが彼らの仕事である。

一番いい立場にいたのが、営業サイドの技術者たちである。彼らは、営業と開発の両方を支えている。彼らがいなければ、営業は自分たちがお客さんに売り込むためのシステムを用意することができない。一方、開発からすれば、システムの開発に使うデータベース製品などのミドルウェアについて、営業サイドの技術者たちは製品ごとの細かな知識を持っており、さらに製品の製造元の会社ともパイプを持っているので、非常に重宝する存在である。

開発陣の中では、システム全体の設計を担当した沖縄チームが嫌われていた。沖縄チームのリーダーの Mさんは、おそらくシステム全体の設計責任者で、技術商社が売りたい製品をからめた中心的な部分を除いた周辺部を含めた全体のプランを立てた人だと思う。私がこのプロジェクトに来て問題を起こしていたのは、その周辺部が大きかったようなので、それで嫌われていたのだと思う。このあたりに私の想像が入るのは、誰も本音を明かそうとしなかったからである。

画面系を担当した会社のグループはとても仲が良かった。このグループは、別会社から来た二人とも仲がよく、ほぼ一つのグループを構成していた。彼らと沖縄グループとの間に溝があった。沖縄グループのリーダー Mさんの設計が失敗したことにより、画面系の方はそんなに巻き添えを食わなかったのだが、別会社から来た二人が割りを食ったので、それで全体としてこのグループが沖縄グループに対して反感を持つようになったようである。

基本的には上記のメンバーで開発が進んでいたのだが、それに私と、開発子会社から二人の救援が来て、プロジェクトを建て直しにかかった。開発子会社の二人は、一人が二年目で、もう一人が私の大学の先輩だったので、ちょうど途中参加で主に沖縄チームの建て直しに動員されたりしたことから、割と冷静にチーム間で仕事をした。

開発子会社には責任者が三人いた。部長と課長とヒラである。部長は大手企業出身の年配の女性で、実質取締役クラスだと言われていた。そんなわけで重要な局面でしか顔を出さず、私が印象に残っているのは、飲み会で開発陣を労って一人一人お酌をして回ったことや、社内で私にも会釈だけでなく挨拶をしてくれたことである。パンチカードでコンピュータを操ったことがある人らしい。課長の方は、プロジェクト半ばで部長に昇進し、実質的にプロジェクトを統括した人である。こちらはうってかわってムチを操るタイプで、割と子供っぽい顔つきだが大阪弁で容赦なく開発陣の尻を叩く人だった。

この部長と課長が、アメとムチの両輪となってプロジェクトを操っている、との説を私に話してくれたのが最後のヒラの責任者の Oさんで、彼はメチャメチャになったプロジェクトの責任者を最後に引き受けた人である。あまりにプロジェクトがひどくなったので、営業が言い訳に苦しんだあげく、大阪弁の課長(そのとき部長)を死んだことにしたらしい。本当に営業がお客さんに対してそんな言い訳をしたのかどうか、真偽のほどは定かではない。このヒラの責任者は、もとは課長だったらしいのだが、組織改編でヒラになったらしい。もともとは外資系にいたらしいが、そこで稼いだ金をはたいて買った愛車のカマロが、プロジェクト期間中に起きた大雨で地下駐車場の中で水没して廃車になったというかわいそうな人である。管理職ではなくなったのだが残業代は出ず、愛車の不運にも我々に「冗談じゃないよ〜」とそんなに深刻にならずにぼやいていたのが懐かしい。

■沖縄チーム

私はプロジェクトの形が固まったあとでやってきたので、各チームの各成員とはなんの因果関係もなかった。一緒に仕事をしている時間が長いと、あそこであいつが足を引っ張っているだとか、このチームのやっている部分がヤバいからこっちまで遅れてしまう、などということが起きて、平静ではいられなくなる。私がこのプロジェクトにやってきたときは、そんなに険悪にはなっていなかったが、はっきりと壁があるのを感じた。特に昼食のときは、仲の良いグループで昼食をとるので分かりやすい。

私は最初、沖縄グループの人たちと仲良くなった。それはまず、一番遅れていた帳票にまわされたからである。帳票はプロジェクトの中でも一番ひどく、後日私のほかにプロパーの先輩が関わったり、大阪の別動隊に投げられたりと、散々なことになっていくからである。それを当初は、たった一人、しかも沖縄チームの妙齢の女性一人がやることになっていた。彼女は、見るからにも、そして実際にも、作業がおそかった。

プロジェクト当初のリーダーであり沖縄チームのリーダーである Mさんは、なかなか面白い人だった。沖縄系の大柄の 30歳の男性で、なかなかのハンサムだった。その上、笑った顔はとても子供っぽくて魅力的だった。彼はなんと、20歳のときに会計を習い始め、22歳で自分の会社を起こしたそうだ。いや、正確に言うと違うらしいのだが、いわゆる青年実業家とは違い、自分の力で会社を作ったといってもいい。事業はそれなりに軌道にのっているらしく、仕事中に先物取引の報告を携帯で受けていた。あるときは、二百万損した、と子供っぽい笑いを見せながら机に突っ伏したりしていて、またあるときはアメックスのゴールドの申請が通ったと喜んでいた。

この二人と私は昼食をよく食べに行った。沖縄チームのもう一人もたまに来た。昼食の場は、リーダーの Mさんの話を私たちが聞くという感じになった。特に私は新参者なので、仕事か私事に関わらず Mさんに色々と訊いてみた。仕事に関しては、やはり Mさんが、プロジェクトがなぜいまこんな状態になっているのかを説明する形になった。内心では、どこかにやはり Mさんたちの落ち度があるんだろう、と思いながら、私は基本的に相槌をうちつつ、細かいことまで訊いていった。

面白いことに、話を聞いているうちに、沖縄チームの落ち度はそんなにあるのかと思うようになっていった。どこかでやはり行き違いがあって、それで沖縄チームだけ孤立しているような気がした。ただし、プロジェクト全体の実行部隊のリーダー、つまり愛車カマロが水難にあった Oさんは、元リーダーの Mさんとはそんなに感情的なしこりがないようであった。というのは多分、Oさんも私と同じような時期にやってきて引き継いだからだろう。大変なプロジェクトを引き受けなければならなくなった、といううらみもあるとは思うのだが、直接因果があったわけではない。それどころか、私から見ると奇妙な友情関係が成立しているようにも見えたから不思議なものである。特に、当時の私は新人をやっと脱したところだったので、私にモノを教えるという点では特に一致した点があって、業界とはそういうものなのだよ、みたいなことを口を揃えて言っていた。

この沖縄チームは、システムが見切り発車で動きだすときに、結局切られてしまった。普通この業界では、トラブルが収まらないとズルズルと仕事を続けなければならないのだが、どうしようもないと判断されると切られることもある。

沖縄チームの仕事のうち、私は帳票を引き継いだ。帳票は大体、形としては出来ていたのだが、性能のことをあまり考えずに作っていたらしく、処理に異様に時間が掛かっていたらしかった。時間が掛かる、というとまだマシな表現で、正確に言うと、処理が終わるかどうかすら分からない、というレベルの話であった。それこそ何年たっても終わらないようなものができてしまうこともあるのだから笑えない話である。それを、ちんたら作業しているように見える妙齢の女性 Gさんが一人でやっていたのだから、ここをちゃんとできる人間に割り当てないとダメだと上が判断したのだろう。私がのんびりと Gさんから仕事を引き継いでいると、それを見た上の人に呼ばれて、君はできるんだから早く引き継いでこれ以上 Gさんに何もやらせないでくれ、と言われた。

沖縄チームがいなくなる間際、私はこの Gさんから今回のプロジェクトについて、帰りの電車の中で色々話を聞くことができた。彼女はあまりキビキビと話をしないのだが、自分でそれを分かっているようだった。私っておそいでしょ、と言ってきたのにはおせじにも何も言葉を返せなかったが、それでも仕事がいい加減だということはなかった。彼女がいなくなったあと、私の大学の先輩らと共に仕切り直しをしてプログラムを作り直したのだが、のちにやはり難事業だったということが分かった。その先輩は社内で高い評価を得ている優れた技術者なのだが、それでもギリギリのコーディングでしのいだのだ。私もこの仕事でかなり技術力が上がった。リレーショナルデータベースで大量のデータをさばくノウハウを身をもって経験した。

■画面系チーム

一方の画面系のチームは本当に楽しそうに仕事をしていた。

リーダーは小さい会社の取締役開発部長と名乗る Nさんだった。この Nさんも出身が沖縄だったと思う。名字がまさに沖縄の地名なのだからほぼ確実だろう。ただし、関西方面に長くいたために、いかさま関西弁をしゃべる。いかさま関西弁というのは、同じチーム内の同僚が私に言った言葉そのままなのだが、確かに微妙に関西弁があやしい。しかも彼はかなり容姿が南国風で、私なんかは彼がたまたまいなかった会食の場で「Nさんって日本人ですか?」という失礼極まりない質問をして、その場にいる人々の爆笑を誘ってしまった。いまで言えば、彼は仏ルノーから来た日産の社長カルロス・ゴーンのような顔をしていたのだから無理はない。

その下にシステムエンジニアの Xさんがいた。彼はとても愛嬌があり、冗談を言うのが好きで、よく話をした。歳は三十代後半で、リーダーの Nさんより年上だった。沖縄出身の Nさんは年齢の上下関係を重視するらしく、仕事を頼むときに頼みづらそうにしているのが分かる、と Xさんが言っていた。仕事では上なんだから遠慮することないのに、と言っていたのが印象に残っている。が、Xさんは Nさんが好きみたいで、Nさんは社内でも結構ネタにされているようなのだが、そのネタの数々を Xさんから聞くことができた。なんでも Nさんには彼とそっくりの妹さんがいるそうだ。あるときは私に「年収650万くれるならゴミさん(私)の会社に行くよ」と言ってきてドキリとさせられた。私も彼の写真をデジカメに撮って、作業用マシンの壁紙に設定しておいて、彼をびっくりさせてみた。

最年少は Yさんで、小柄で痩せたアトピー気味の子供っぽい顔に茶色の髪で、つい一カ月ほど前に偶然再会した。彼はとてもきちんとしていて、社外の人間である私と会話するときは、Nさんや Xさんのこともちゃんと呼び捨てにしてビジネスマナーを守っていた。やはり外見からナメられることを恐れているというのもあるのだろうと思う。かといってよそよそしいということはなく、私は途中から画面系チームと昼食に行くようになっていたのだが、色々と仕事に私事に話をした。このまえ再会したときは、後輩らしい人も連れていて、はたからみて面倒見のよさそうな先輩をやっているようだった。

このチームは実は、今回の百貨店だけでなく、他の企業にもこのシステムを売り込むためのカスタマイズ部隊らしかった。カスタマイズとはつまり企業ごとに最適にシステムを調整することである。その第一回目のこの百貨店のシステムでつまずいたことから、ズルズルとこの場所にとどまってプログラムをいじりつづけていたらしい。だから、このチームは元請けの技術商社にかなり近い位置で仕事をしていたのだ。この技術商社から遠ければ遠いほど、どうやら立場が弱くなっていくようである。それは技術商社の開発子会社にも言えて、開発子会社は子会社でありながら、技術商社本体の技術者よりも立場が弱いようであった。ちなみに私はこの開発子会社に派遣で行っていたのでさらにその下ということになる。

■開発子会社プロパー

その開発子会社というのがまた面白くて、自社の社員つまりプロパーが少なく、外注ばかり雇っている会社なのである。私が前に違うプロジェクトでこの開発子会社に行っていたときには、やはり七社ぐらいから人が集まっていた。20人に満たないチームなのに、プロパーはリーダーが一人だけ、それに社長が二人もいた。現地作業で時間があくと、ときどき高層ビルの窓から夜景を見ながら、互いの出身やキャリアを語り合うというムードのある状況ができあがる。ただしムードうんぬんは回想だから感じるのであって、そのときはただ早く家に帰りたいという想いをおそらく全員が持っていた。

今回のプロジェクトには、プロパーは三人いた。愛車水難の Oさんに、大学の先輩の Miさん、それに新人の Iさんである。

Oさんについては前に言ったが、プロジェクトの後片付けとして私と同時期にやってきてリーダーにさせられた、かわいそうな人である。正確は基本的に温厚で、ときどき昼食に行った。あるときは二人だけで昼食に行き、仕事以外の話もしたので、それなりに親しかった。歳は確か三十代後半だったが、外見は非常に若々しい。容姿はあの戦前の首相、近衛文麿の、教科書とかに乗っている写真にそっくりである。だから一見すると固い感じがし、ぴっしりとスーツを着て髪をぺったりなでつけると銀行員のようなイメージがあるのだが、基本的に面白い人で、ぼやきながらも笑顔が浮きでる。

一度だけ Oさんは、トラブルが起きたときに真面目な口調で「なにやってんだ馬鹿やろう」と私に言ったことがある。私もキレて「あー?」と不機嫌な声を出すと、「あーちょっと気が立ったね」と収まったので良かったが、本当にあのときは雰囲気が悪かった。ただ、ほとんど仲はよかった。私が最後にプロジェクトを抜けるときも、プロパー三人組と一緒に飲みに行った。

Miさんとは大学が同じだけでなく、下車駅も同じだったので、よく一緒に電車で帰宅した。彼の社員証に貼ってある写真は、髪をなでつけて眼鏡を掛けたデブが写っていたのだが、実際の彼はコンタクトで、髪もパーマが掛かっていて、まるで鉄腕アトムのお茶の水博士のようであった。その愛らしい外見は、事務系の女性にも人気があった。

同窓の先輩を持ち上げるわけではないが、とにかくプロジェクトの中でもっとも技術力があり、もっとも信頼されていたのが彼だった。彼がひとたび不可能と言うと、すぐに他の手段を考えるという方向転換が起きる。もちろん、逆に「できるんじゃないか」と言ったらギリギリの線でやることになってしまう。それほどまでに信頼されていた。私の実力がそれなりに高く見られていたのも、私が彼の後輩にあたるから、という理由があったことは確実である。

私は主に彼と一緒に、帳票をちゃんと動くように作り直していった。帳票といっても、実際には夜間に動くのでバッチと同じである。昼間に動かすと日中にシステムを使うことができなくなるので、夜中に時間を掛けて延々と処理をしていくのである。だから、なんとか決められた帳票を朝が来るまでに動かし終えられるように、極力処理を高速化することが必要だった。

最悪なことに、スケジュールが遅れに遅れたため、試験運用期間と断った上で、開発中にも関わらず運用が始まってしまった。そうなると、日中はマシンが重くなってしまうという理由で、本当に夕方以降、夜に掛けて開発とテストをしなければならなくなった。一番忙しいときには、連日 22:30 くらいまで現地の横浜で作業をし、仕事が終わったら二時間かけて家まで電車で帰らなければならなかった。さらに一度だけ、処理が正常に終わったかどうかを、午前四時に現地に入って調べなければならなかったことがあり、このときは横浜駅前のカプセルホテルに泊まった。

それでも私はまだマシな方で、何回もカプセルホテルに泊まった人、連日タクシーで帰った人、休日に女性と車でドライブに出掛けている最中に呼び出されてスカジャンを着たまま現場に駆けつけた人なんかがいたらしい。

■その他

途中で私の会社からも応援が三人来た。ただし、うち二人は完全に仕事が分かれていたので、一カ月間別の仕事をしたらすぐに帰っていってしまった。もう一人の Niさんは、結局私がプロジェクトを去ったあとも少しいたらしい。

Niさんは非常にキッチリした人で、歳は二十代後半だが、二十代前半で結婚して、そのころちょうど奥さんの出産を控えていたらしい。出産にはそれなりにまとまった金が掛かるらしく、月の小遣いが少ないとこぼしていた。昼食はいつもパン二個だけで、毎週の楽しみが週刊少年サンデー一冊という貧乏ぶりである。これまでの私の話にあるように、昼食での会話というのは仕事を円滑にし、興味深い話を聞ける場なのだが、一緒に昼食に行くと大体 700円から千円ぐらい掛かってしまうので彼は行けない。というか、彼自身そんなに外部の人と親しくなろうとは思っていないみたいだった。

データベースにトラブルが起きると Ma さんがやってきた。サッカー選手でゴールキーパーの川口に顔と髪形が似ている。彼は技術商社とフリーで契約していたらしい。専門は、とある会社のデータベース製品である。この製品は特殊な性質を持っているので、一般のデータベースの技能だけでは性能を引き出すことができない。そこで、彼のような専門の技術者が開発者に指導したり、データベース製品の開発元の会社と連絡をとって問題を解決したりするのである。今回のプロジェクトでは、データベース設計に問題があったのでは、ということで彼がデータベースの設計そのものをやりなおしたらしい。普通そんなことをするとあらゆる部分で変更が必要になってどうしようもなくなるのだが、今回はもうこれ以上悪くなりようがないどころか、根本的になんとかしなければならなかったので仕方がない。

Ma さんは実は、もとは私の会社の社員だったらしい。たまたま現地で会ったときに突っ込んで聞いてみたが、あるとき仕事自体が嫌になって、一カ月ほど何もせずに休養したそうだ。だけどさすがにこれ以上働かないのも暇なので、他のところで働くことにしたらしい。ほかに自社で彼を知る人にも聞いてみたが、何か人間関係のトラブルとかがあって辞めたわけではなさそうである。

Min さんが営業で、つまり名目上プロジェクトのトップだった。大柄で血色のよい精力的な外見を持った人だった。私は最初この人が好きだったのだが、途中で疑うようになった。前の仕事で、はじめは、何か困ったことがあったら言ってくれ、と非常に親切な感じだった。ところがあるとき、私が一緒に仕事をしている同じチーム内のある人と喧嘩のような形になったのだが、そのことがいつのまにか私の上司に伝わった。私は派遣先で一人で仕事をしているのだから、誰かが報告したことになる。となると、この Min さんしかいないのではないか。以上は私の推測なので確実なことは言えない。今回のプロジェクトでは、彼がたまたま現地に居合わせた私を含めた開発メンバー何人かを昼食に誘ったのだが、その日は休日だったということもあり、私は断ってやった。伝え聞くところによると、彼は最近出世したらしい。ちなみに、喧嘩をした人とは翌日からは別になんともなかったが、それ以来よそよそしくなった気もする。

もう一人営業がいた。Min さんは途中で抜けて、彼はそのあとを埋める形になった。彼もまたやり手の営業マンっぽく、口も立ち、細かいことに気を配る。開発が佳境のときは、夜食としてコンビニのおでんを買い占めて持ってきたりした。ただ、Min さんがいかにも図太かったのに比べると、多少繊細なところがあったらしく、私がプロジェクトを抜けてからしばらくして、会社をやめたと言っていた。「○○○はメジャーになりすぎた。俺には窮屈だ」みたいなことを多分冗談で言って、他のところに移ったのだろうと言われているが、実は今回のプロジェクトが嫌になって辞めたのだとささやかれている。

というのは、今回のプロジェクトはお客さんの百貨店システム部の中でも大阪の方から仕事を受けていて、そこの課長三人衆がみな関西人でヤクザ顔負けの態度でなじってくるのだという。私の会社の別件のプロジェクトも同じシステムに関わっていて、会議が同じ場で開かれるそうなので、それに出席した人から時々すごい話が伝わってきた。「いやーうちの方は淡々と済んだけど、○○○さんのとこはすごかったよ。見てて気の毒」「今日は(提出した書類をはさんだ)ファイルをぶん投げられてました」。そう教えてくれた Naさんは、多分人間関係のこじれで転職してしまい、もう私の会社にはいない。ちなみに、最近先輩から聞いた話では、その先輩も Naさんとかなり衝突したらしく、その様子を見ていた他の人から「Naさんかわいそう」と言われたそうだ。

プロジェクトが収束に向かいつつあるとき、大阪にいるチームにも帳票の残りが投げられた。その大阪のチームが東京にやってきてテストと微調整をやるときがあったのだが、こちらはうってかわってとても和やかなチームだった。リーダーはおだやかに関西弁を話すおじさんで、ほかに眼鏡を掛けた小柄の妙齢の女性と、明らかに若くて外見が子供っぽい女性がいた。リーダーと眼鏡の女性とは、食事に誘ってもらったので、私のそのころのお気に入りのタイ料理屋に連れていって昼食をとったこともあった。彼らには悪いが、当時東京の我々は、大阪チームは絶対に苦労するだろうなと言い合っていた。私が抜ける間際の時点ではそれほど苦労している感じではなかったが、そのあとどうなったのか私は知らない。

■その後

これだけこじれたプロジェクトなのだが、百貨店の内部では案外評判がいいらしかった。非常に処理に時間が掛かるのだが、大量のデータを分析するシステムはこれしかない。こんなトロいシステムを使う人なんているんだろうかと言っていたのだが、テストしていた Miさんが少し様子を見てみたところ、少なくない人が色々な分析をしようとしていることが分かった。

このプロジェクトには、Sun という会社の当時最速のマシンが使われたのだが、このマシンは CPU の数やメモリの容量がオプションで自由に決めることができた。そこで、開発の最中には、もっと CPU を増やせだのメモリを増やせだの声が上がっていたのだが、結局すでに営業が持ち出ししているほど予算が足りなかったらしく、増えることはなかった。ところが後日聞いた話では、CPU もメモリもだいぶ増えていた。特にメモリは三倍くらいになったと聞いた覚えがある。

この話はもう二年くらい前だったように思うのだが、いまでもまだちょっとした開発が続いているという話を聞く。

一年に一度、新年会の誘いが、画面系のチームの Fさんからくるのだが、結局私はいままで一度も出ていない。なんというか、怖い気がするのだ。あいつは口だけだった、とかなんとか言われていないとも限らない。まあ、多分大丈夫だとは思うのだが、足踏みしてしまうのである。ぶっちゃけると、それほど再会したいとも思っていないというのが大きな理由なのであるが、会えば会ったで楽しいひとときが過ごせるであろうことも予想できる。だがなんとなく面倒なので、やりすごしてしまった。

■専門的な分析

以下は技術的な知識が多少なりともあることを前提とするので、分からないかたは飛ばしていただきたい。

このプロジェクトがなぜ失敗したのかを私は色々考えてみたのだが、結局ミドルウェアを中心にしてシステムを売りたがった技術商社が、ミドルウェアの周辺部分の機能を安易に考えすぎたことが原因だと思う。

そのミドルウェアというのは、大量の情報を分析する上での中核となる非常に重要な部品なのだが、かなり重い前処理が必要となる。その前処理というのは、そのミドルウェア独特の形式で保存されるので、他の部品から使用することができない。だから、バッチや帳票は別々に同じような計算をしなくてはならなかった。同じものをわざわざ別々に計算するものだから、当然時間は二倍掛かることになる。つまりそうなると、マシンの性能が二倍必要となるか、あるいはプログラムを二倍の精度で作り上げなければならなくなる。大変な無駄である。そのうえ、別々に計算されたミドルウェア上のデータと帳票のデータの集計方法が微妙に異なるというので、お客さんからクレームが来てしまった。なにしろ、急いで作ったのでろくに仕様書がない。そのうえ、ミドルウェア側の技術者は、こっちの集計方法が正しいのだと譲らないのだから、そのしわ寄せが全部帳票に来た。

私はミドルウェアの前処理のことを、プロジェクトのかなりあとの方で知った。実際に電話で、ミドルウェア側の中心的な技術者と話をした。というのは、そのミドルウェアの前処理があまりに重くて、こちらのテストに大きな差し障りがあるので、こっちの納期の方が近いことだし、向こうから事情を聞いた上でやめてもらえないか交渉するためだった。それから、一体どんな設計になっていてこんな無駄なことをしているのかを聞いてみたくなった。しかし私は下っぱだったし、いまさらというのもあったので、設計についての文句は言わずに、どういう設計になっているのかという質問だけにとどめた。前処理をこっちでも利用できないのか、と聞いたら、何の問題意識もなくあっさりと無理だとの言葉だけが返ってきた。このミドルウェアあってのシステムなので考えられないとのことなのだろう。それなら、前処理のための前々処理を共通に用意して、前処理を軽くする方法もあるだろう、と思ったが言わなかった。だから、その私のプランが可能だったかどうかは今では分からない。

とにかく、基本設計によって、システムに必要な資源つまりマシン性能などのハードウェアから、開発に必要なマンパワーまで、大きく左右されるのがこの業界である。開発をはじめるときには、まさかここまで荒れるとは思わなかったのだろうから、甘く考えていたというのも分かるが、基本設計をやるような人間は高めの給料をもらっているのだから、そのくらいのことはやらなくてはダメである。しかも基本設計をやるような人間は、基本設計だけを終わらせると早々と別のプロジェクトの立ち上げに移ってしまうので、なおさら行く末に無頓着になってしまうのである。

実はこのプロジェクトのほかに、同じミドルウェアを使ったシステムを他の企業に売り込んで開発をおこなっていたようなのだが、そちらのほうはうまくいっていたらしかった。だから、そっちでうまくいっているのになぜこっちではうまくいかないのだ、という問いに対しては、こっちは帳票だのなんだのをゴテゴテつけなければならないし、ケチなのでマシンの性能がよくない、という答えしか持っていないようだった。だから、ミドルウェアの開発者たちは、自分たちに問題があるのだという問題意識はあまり持っていなかったと思う。

■業界の問題

技術商社内では、実際に金になるのはミドルウェアを売ることであって、そのミドルウェア上で開発や調整を行う人間の方が、システム全体をコーディネイトして周辺部分を作成する人間よりも重視されたのだ。これはこの業界の問題そのもので、システムを開発する作業に支払われる金額よりも、マシンやパッケージソフトに支払われる金額の方が、不当に多いのである。だから、マシンやパッケージソフトを売って得た利益で、開発に掛かった費用の赤字を埋めることになる。したがって、システム開発だけを行う会社というのは、非常に儲けが少ないか、赤字を何らかの形で補てんしてもらっているのだ。これは、技術商社による開発者からの搾取とも考えることができるのだが、そもそもの原因は、システム開発という見えないコストに対して顧客が金をあまり支払いたがらないというメンタリティにある。

*

本当は時系列に順をおって語りたかったのだが、書こう書こうと思っているうちに時間がたちすぎて、詳しい内容や順序を忘れてしまった。その分、瑣末なことはほとんど書いていないと思うので、内容は凝縮されただろう。


戻る前回次回
gomi@din.or.jp