私が志村部長から指示されたのは、セールスマンと商品の関係、商品と客との関係から、セールスマンと客との関係を作り出す方法について検討することだった。これらは一対一の関係ではなく、多対一や多対多になっているため、一筋縄ではいかない。そのうえ理屈ではうまくいっても、実際にデータベースを更新したり検索を掛けたりしたときに十分な速度で動いてくれないと使い物にならないのだ。
私はまずデータモデルを精査してみた。データモデルが本当に要件つまり客の要望通りなのかどうかを確かめるところから始めたのだ。でなければ、必要ないものをデータモデルに盛り込んでしまい処理が複雑になる可能性があるからだ。たとえば、なぜここを一対一ではなく一対多にしなければならないのかとか、このフラグをここに持たせなければならない理由はどうなっているのかなどを、要件に詳しい人に聞いて一つ一つ確かめていった。
そうしているうちに私は、このデータモデルを一体誰がどういう意図で作ったのかを知りたくなったので志村部長に訊いてみたところ、最初志村部長は自分が作ったと言った。そこで私は失礼ながらも、志村部長はデータベースに詳しいのかどうか聞いてみたところ、少し間をおいてから「詳しい」と断言した。そこで私は仕切りなおして、ではどういう意図で作ったのかさらに聞いたところ、実はそれは客である源さんが直々に示したものだと言った。私たちは源さんが作ったものをそのまま受け入れていたのだ。客でしかもキーマンである源さんが作ったのだからこれで決まりなのだという。
志村部長のデータベースに関する知識には、大きな疑いがある。後日初期移行のときに、数百万件のデータの整合性を調べるために自己結合して確かめることになったのだが、数百万件を自己結合すると大変なことになると言い出した。たかだかテーブルを二つ結合するのに数時間ぐらい掛かるのではないかという。ちゃんとインデックスを張っていればテーブル二つぐらい大丈夫だと私は言ったのだが、聞く耳を持たなかった。ちゃんと理論が分かっていれば、データ件数の定数倍の計算で処理可能だということが分かる。
当時の検討段階で、源さんのデータモデルより良いモデルがあれば代案として示すという動きを私は聞かなかったし、志村部長もまあやっかいだとは考えていただろうがそんなに大きい問題として考えてはいなかったようだった。仕方なく私はそのデータモデルを受け入れて仕事を進めることにした。このデータモデルの問題はその後プロジェクトに大きく暗い影を落とすことになる。
データモデルというのは難しいもので、ちゃんと理論化されてコンピュータサイエンスで研究されている。ただし、一番整合性の取れたデータモデルにすると、データ変更は楽だが検索がしんどくなるため、わざと冗長にするテクニックが使われる。冗長にすると検索は早くなるが、その分更新に手間と時間が掛かるようになる。源さんが提示したデータモデルは、あとで考えてみると中途半端に冗長化されたモデルだった。本来三角形の関係はAとB、BとCの関係さえ保持していればAとCの関係は保持しなくても導き出せる。しかしAからCまたはその逆を検索する需要もあったため、わざわざAとCの関係も維持しなくてはいけないようにしたのだ。
たとえば誰かがデータを変更しているときに、また別の誰かがそのデータを読み込もうとすると、データが変更し終わるまで読むのを待たなければならない。ちょっとデータを読み込んだり変更したりするだけなら良いが、沢山のデータを時間を掛けて変更する場合はどうかとか、全部のデータに対して検索を掛ける場合はどうなるかとか、最悪の場合を想定して考えなければならない。下手をすると、検索がいつまでたっても終わらなかったり、データの修正に待ち時間が発生しすぎて失敗することが考えられた。
現在圧倒的なシェアを持っているOracleというデータベースソフトの場合、あるデータを変更中にそのデータを読もうとすると、特に何も指定しなければ自動的に古いデータを読みに行くため、待ち時間が発生しないようになっている。ところが我々が使うことになるIBMのDB2にはそのような機能がない。そんなわけでOracleに詳しい矢作さんは、DB2つかえねー、と散々文句を言い立てた。
しかし調べてみると、DB2のほうがデータベースの国際規格に従っていて、Oracleのほうは国際規格を一部しか実装しておらず、先に述べた変則的な機能を使って実用性を追求しているのだという。データベースに詳しい人間からすると、どちらの方法も一長一短らしいが、DB2が理論的で複雑な方法をとっているのに対して、Oracleがシンプルで合理的な方法（悪く言えば安易な方法）をとっているため、矢作さんのようにOracleのほうが優れているかのように思ってしまう人が多いのだろう。
というようなことを私は矢作さんに力説したところ、じゃあ詳しく調査して顧客を説得するための資料を作ってくれと言われたので作ることになった。資料はそれなりの時間を掛けて完成し、その出来に私はそれなりの満足をしていた。しかし矢作さんに見せたところこれではまだ不十分だという。矢作さんはこのあと私の代わりにクラブ通いの無口な長身男モコメチ君に任せた。彼は私が作った資料を部分的に利用しつつさらに補強して体裁を整えて資料を仕上げた。それを矢作さんが顧客に見せて一生懸命説明したのだそうだが、結局大した成果は上がらず顧客を説得することができずロックの問題は解決しなかった。
あとで分かったことだが、顧客の方針としてデータベースにアクセスするときに、国際規格では四種類あるアクセス方法のうち一つだけしか使わないことが社内ルールとして強く推奨されていたのだった。しかも信じられないことに、説明しても大して意味がないので専門的な言葉をいちいち解説しないが、どんなに短時間でもテーブル全体をロックしてはいけないこと、一度のトランザクションでの更新は千行以内に収めること、というのが社内ルールとして定められていた。そのうえ要件として、24時間運営で夜間バッチなし、データの整合性は絶対、という要求が突きつけられて、一体どうしろというのだろうか。
いったん棚上げになったロック問題は、その後再び今度はバッチの再設計時に持ち上がることになる。
アクタチームは非常に陰鬱なチームだった。メーカー系のソフトハウスで主に開発をやってきた人が、初めての要件定義でどうやったらいいのか分からないので見栄春さんが教えていたのだが、物覚えが悪い、といつも怒っていた。その怒り方が陰険で、見栄春さんは「俺が間違ってるの？」「どうすれば分かってくれるのかな」などと言うので、周囲の人間がそのたびに心を寒くしていた。もう一人のメンバーである新人さんは、新人だからという理由もあってまだ扱いがマシだったが、やはり厳しい指導を受けていた。
その中へ私が入っていった。私は以前から見栄春さんと仲が良かった。よく分からないが見栄春さんは私のことをそれなりに認めていたようだった。見栄春さんは忙しいみたいだったので、私が先の二人を代わりにみて資料の精度を上げてくれと言われた。だから私は見栄春さんの側に立って二人を指導すれば良かったのだが、私は納得できないものを感じていた。彼の指導自体に無理があるように思え、彼の気分だとか好みにひどく左右されているようにしか思えなかったからだろう。それでもこの二人のために私が彼との間に入ることでなんとか二人の扱いがよくなればと引き受けた。
ところがほどなくしてその体制がほころんだ。私がレビューして通した新人さんの資料に対して、本当に大したことのない理由としか思えないところで見栄春さんが注文をつけだした。データ操作をケースごとに分けて説明する資料を何枚か書いていたのだが、見栄春さんはそのケースの分け方が足りないと言い出したのだ。新人さんは、はいわかりましたとすぐ直す気配だったので、私も黙っていればよかったのかもしれないが、新人さんの資料は私がみてOKを出したものなのだから、このままだと私の落ち度だということになる。そこで私が代わりに彼の資料を弁護していくつかのことを主張した。場はたちまち険悪になった。後日その書き直した資料を客先に持っていったところ、源さんから「こういうのはもっと一般化しないとダメだ」とそのままズバリ言われていてウケた。
決定的となったのは議事録起こしのときだ。私もこの頃アクタチームの一員としてお客さんとの打ち合わせに参加しており、議事録を起こして書いていた。彼は私が起こした議事録に赤をびっしり入れていた。正直どれも大した指摘事項だと思わなかったので私はおとなしく彼の書いたとおりに修正していたのだが、何度目かの頃に彼が急にキレた。何度言っても直らないじゃん、と。言い方が例によって陰険で、「どうしたら分かってくれるの？」というものだったので、私もキレてこう言った。「そんなことを、言っても分からないやつとやらに訊いてどうするんですか」と。
以前、志村部長と見栄春さんと私の三人で、私の書き起こした議事録を確認したことがあった。多くの点において三人が三人とも理解が大なり小なり違っていたことに驚いた。顧客との打ち合わせで特に源さんの話が速くてしかも一つ一つ確認せずに進んでしまうので、話がどうなったのか分からないのだ。さすがに新参の私が一番理解が足りなかったのは明らかだったが、私と志村部長が同じ理解をしていて見栄春さんだけ違うことを言っていたり、私と見栄春さんが同じ受け取り方をしたので志村部長が首を傾げたりすることもあった。それなのに一体どうして私と見栄春さんの二人だけの確認で見栄春さんが私にケチをつけるのだろうか。
根本的な原因として、客先での打ち合わせのとき、源さんの話などを聞いて分からないことが多くても、私たちのうち誰か（多くの場合志村部長）が理解できたらその話は終わってしまうのだ。あとは自社に持ち帰ってから分かった人がみんなに説明することになる。だからその場で全員で理解を確認することができないし、ましてそこから検討することも出来ない。その結果ますます顧客とくに源さんの考え方でロクに検討されないまま進んでしまうという悪循環になった。一番よく分かっているはずの志村部長がなんとかしてくれないといけなかったのだが、志村部長は極論すると源さんの言うことに「そうですねそうですね」と言うことで信頼を得てきていたので、下手なことを言ったり話の流れを止めて私たち全体の理解が足りないのではないかと源さんの信頼を損ねるのを避けていたのではないかと思う。それも作戦といえば作戦だったかもしれないが、いま考えると裏目に出ていたとしか思えない。
見栄春さんも同様で、元々営業をやっていた人なためか、源さんの言うことにウンウンうなずくことしかしてこなかった。このころ見栄春さんは要件定義書を書いて源さんに見せていたのだが、たった3ページほどの要件定義書を何週にもわたって見せ続け、そのたびに毎回一時間近く掛けて源さんからこまごまとした指摘を受けて修正を繰り返していた。このようなことが続いているうちに、成果物の精度を上げなければとあせっていたところまでは理解できるが、自分が源さんと同じようにメンバーに対して自分の好みに近いようなこまごまとした指摘をするのは我慢ならなかった。
要件定義書はその後志村部長から、私が書いたらどうかとも言われたが遠慮した。見栄春さんのレビューを受けることを考えたら書く気ゼロになったからだ。私はその頃は主に補足資料を書いており、その補足資料も一応要件定義書本体に組み入れられるような体裁を整えてあった。私が書いた形式は、最初に業務要件（業務を行うために何が必要か）、次に機能要件（要件を満たすためにどのような機能が必要か）、最後に機能の具体的なイメージとして絵を張るというものだった。志村部長から最後の絵はいらんと言われたが、その後に全チームが形式を合わせて要件定義書を書くようになったときに大体似たような形になった。見栄春さんはその後基本的に一人で要件定義書を書き続けたが、殊勝なことにレビューや校正を新人さんに頼むようになった。
私と見栄春さんとの仲は実は私が悪くしてしまった可能性がある。私がアクタチームにきて間もない頃に飲み会があったのだが、散々自分がいままでしてきた仕事を自慢していた見栄春さんが、急に今回の仕事は難しいと弱音を吐いているのを聞いて、正直私はなんだそりゃと思って「そんなことを言うんだったら、見栄春さんから学べることはないなぁ」と言ったのだ。私はこの言葉を悪意から言ったのではなく、後輩にいいところを見せようとする彼のような人間を発奮させるために言ったのだが、これが裏目に出てしまったのかもしれない。また、彼は自分の意見を強く言って人を従わせるところがあったが、反対意見に耳を傾けて取り入れる面もあった。一方私は当時、おおむね問題ないときや角を立てたくないときは黙って彼の意見を肯定していたので、それで私のことを低く扱うようになったのかもしれなかった。
私が客先に持っていく必要をしきりに訴えた資料を見栄春さんが却下し、あとになって同じような資料を客の方から求められるということがあったのに、それでも彼は私のことを評価できなかったようだった。結局それについては日ハムさんが私の作った資料を掘り起こし、あえて私の名を作成者として残しておいて最新の状態にアップデートし体裁を整えて持っていってくれた。
私はもういい加減見栄春さんが嫌になっていたので、黒タイさんにサブリーダーを譲って自分はなるべく後ろに引っ込もうとした。アクタチームの中にはさらにコールセンター関係をやる使命があって、そこが全体から見て小さかった。見栄春さんはアクタチームを本流と傍流の二つに分けて責任分担をしたがっていたので、私はコールセンター関係のとりまとめを志願して本流から手を引こうとした。
その頃私は外部設計のスケジュールを作っており、いよいよ担当分けが明確になるという時だった。なんとなく私が画面系で黒タイさんがバッチ系をやるという分担にしていたが、黒タイさんがどちらかというと画面系をやりたいというので交換した。見栄春さんは黒タイさんを気に入ったようで、すぐに信頼して色々と任せるようになった。結局以前と同じ図式で、私がアクタチームに入った直後は私を信頼して新人さんや中途さんをいじめ、黒タイさんが入ったら私を本格的に貶めてきた。
五人体制になってもう大丈夫かと思ったら、要件定義に時間が掛かりすぎてタイムリミットが迫っていてとても外部設計を終わらせられないということで、さらにもう一人追加された。野球大好きで日ハムファンなので投げやりだが日ハムさんと呼ぶことにする。スポーツマンだからという理由ではないだろうがさっぱりとしてシャレの効いた性格と髪型をしている男で、外大卒だというからデータベースのカラム名を英語でつけるときに色々訊いた。彼は最近子供が生まれたそうなのだが、早くも奥さんの尻に敷かれつつあるみたいで、一度奥さんのことを「おかあさん」と言ったところ、「私はあんたのおかあさんじゃないんだからね！」と怒られたそうだ。
ちなみにうちの会社は学歴優先で人を採っているせいか、このプロジェクトのメンバーはワン田君を含めほぼ全員が国立大か一流私大卒だった。それでこれだけうまくいっていないというのはまあ学歴があまり役に立っていないことになるのだろう。
アクタチームはリーダー＋サブリーダー二人＋メンバー三人という体制だったので、私がそれに合わせてメンバーのアサイン（割り当て）を決めた。見栄春さんは一見ワンマンな人だったが、こういうことは下の人間に任せていた。普通は見積もりまでをメンバーがやり、スケジュールの作成以降はリーダーがやるものなのだが、メンバーに任せること自体は（まあ面倒くさいけど）悪くないことだと思う。
何故か見栄春さんはこのとき日ハムさんを私の下につけるという前提で最初話をしていたが、その後これまた理由不明だが私と日ハムさんを分けてもいいということになったので、このとき私は思い切って日ハムさんに部品全部を割り当てた。画面系を黒タイさん、バッチ系を私、そしてある程度要件が固まったような気がしていた部品系を日ハムさんに全部押し付けた。見積もった工数からしても部品系の量が一番多かったが、画面とバッチはこのあと苦労するだろうからと言ったらすんなり受け入れられた。
ただしここまで来るのに一悶着あった。サブリーダー同士の責任分担をどうするかということで、見栄春さんは要件の大分類ごとに分けることを主張した。先に述べたようにアクタ本流とコールセンター関係に分けるやり方だ。見栄春さんがそう言うなら私は別にそれで悪くなかった。特に不満はなかったのでそのまま言うことに従ったと思う。しかし見栄春さんは妙なところで律儀なので、何故か私にこの分け方でいいかどうか訊いてくるのだった。律儀というか単に自分の意見に納得した上でついてきて欲しかっただけなのかもしれない。しかし私はこの分け方よりも、画面とバッチと部品に分けるべきだと主張した。というのは、お客さんもまた担当者が画面系の人とバッチ系＋部品系の人に分かれており、技術的にもそれぞれ全然違ってくるので、各個に専念したほうが良いと思ったからである。それに、このプロジェクトはただでさえアクタやカスタマなどのチームに細分化されてしまっており、粒度の問題で効率が悪かった。事実、後日になってチーム縦断的に画面やバッチの担当者間で打ち合わせをすることになった。なので、私は自分の意見を通したいとは少しも思わなかったが、見栄春さんに言われて仕方なく画面やバッチなどで分けることを主張した。これも見栄春さんが私にやる気を出させるための一つのやり方だったのかもしれない。結局私の方針でアサインが決まり、チームは外部設計書を仕上げるために動き始めた。
ところがその後、他のチームで戦力不足になっているということで、中途さんがアクタチームから脱退した。見栄春さんから逃れられて心底ほっとしただろうと私は彼をねぎらった。しかし彼は殊勝なことに自分の経験不足を強く認識しており、見栄春さんのことをまったく悪く言わなかった。よっぽど人がいいのか単におとなしいだけな人なのか知らないが、見方が変われば違ってくるらしい。
源さんは社内の人間にもいつも強気の態度をとっていたらしくて、客先のトイレで歳のいった紳士たちが三人ぐらい連れ立って小便をしながら源さんの陰口を言っていたのを聞いた。例の調子で大声で相手をやりこめていたらしい。因果関係は不明だが、後日源さんは本部長から部長に降格になったそうだ。
私たちアクタチームが外部設計に取り掛かった時点で、他のチームはまだ要件定義にハマっていた。本来アクタチームはそんなに難しい機能を受け持っておらず、一番大変なのは納期の点からいってもカスタマチームだった。他のロジやクレームは、要件が漠然としていたという難点こそあったものの、納期がまだ先なのでそれほど切羽詰ってはいなかった。
外部設計書の雛形は、私が最初に作ったものがいくつかの人を経て、矢作さんがお客さんと調整して完成させたものを使うこととなった。矢作さんは最初カスタマチームのリーダーだったが、カスタマチームはミドルウェアに詳しい若健さんに任せて、自分は新たに作ったインフラチームのリーダーにおさまった。インフラチームはハードやソフトや人員の手配から納品物や成果物の決定まで、要件とは関係ないものすべてを取りまとめる役目を負っていた。大型プロジェクトならではの存在である。ワン田君もこのチームに入った。
矢作さんがインフラチームで一生懸命調整して時間を掛けてお客さんと合意に至った外部設計書の雛形が、私たちとは違うベンダの出してきたUMLという規格をベースにした一本の外部設計書のサンプルによりあっさりくつがえったらしい。いままで詰めてきた話はなんだったんだと矢作さんは不満を漏らしていた。その後の粘り強い交渉によりなんとかこのままで良いということになったらしいが、そんな経緯を知らない我々は、せっかく決まった外部設計書の雛形への文句を思い出したように言い出したので、矢作さんは憮然とした様子で淡々と雛形についての説明をしていた。
ちなみにUMLについてはワン田君が初期の頃から積極的に推進していた。ところが私が外部設計書の雛形を作るにあたって、他のプロジェクトを参考にしろと言われて、他のプロジェクトでUMLを使った設計書がまったくなかったので結局立ち消えていた。
インフラチームの客先での打ち合わせで矢作さんは苦労していたようで、こっちが決めたいことがなかなか決まらず、いつもやきもきしていたようだった。一つ決まらないとそのあとの作業が止まってしまったりするのだが、決めるためには客のそれぞれの部署での責任者や物知りや末端ユーザなどから話を聞く必要がありなかなか決まらないのだ。決めておいてくれといっても途中のどこかで話が止まっていたりするのでしょっちゅう催促しなければならなかった。どのプロジェクトでも大なり小なりこういうのは当たり前である。アクタチームの打ち合わせに出てきたホスト担当の人なんか、自分が調べなきゃいけないことを忘れたので改めてタスクリストにまとめて欲しいと言っていたことがあった。あつかましいにも程がある。こいつは打ち合わせ中に居眠りしたり、もう自分がいる必要はないからと理由をつけて途中で帰ったりしていた。
決まらないことが多い一方で、勝手にしてくれと言われることもある。しかし本当に自由にやっても必ずあとで何か注文が来てしまう。言質をとれば良いという問題ではない。たとえば、まあどうでもいいことでログファイルの文体について社内ルールがあればそれに基づいて決めると訊いてみたことがあったそうなのだが、特にルールはないので好きにやってくれと言われたそうだ。じゃあとツンデレ風に「システムエラーなんだからねっ。もう知らない！」みたいにしたらどうかと飲みの席で言ったらウケた。
そんなこんなで結局私の作った外部設計書が最初にお客さんとのレビューに引き出されることとなった。まず問題となったのは記述レベルだった。前述したように外部設計書は詳細なレベルにまで立ち入るようになっていた。そこで、ホストで普段使われるJCL（Job Control Language）と呼ばれるファイルに書かれるレベルまでを設計書に記載することになった。このようになった経緯は、ホストに慣れている人の意見を取り入れたからである。しかしホストについてあまり理解していなかった私たちは、結果としてかなりちぐはぐな設計書をお客さんに見せることとなった。外部設計にしては細かすぎ、細かい設計にしてはJCLレベルの考慮が足りない、というような当然の指摘が入った。ホストを知らない外部設計要員である私に細かいことが分かるはずはないのだが、外部設計書の雛形のレベルに合わせて仕上げざるをえなかったのだ。というかそもそもバッチはJavaでやることになっていたはずなのだが、途中であっさりCOBOLになった経緯を含めて、ここに至るまでの道があまりにいい加減だった。しかもお客さんの多くは総大将の源さんを始めCOBOLのキャリア持ちばかりである。Javaのままだった部品の設計書が比較的すんなり通ったのに比べて、COBOLで実装する機能の設計書は細かいことまでお客さんの突込みが入った。
ここで改めて考え直して再編成すればよかったのかもしれないが、私たちにそれを出来る時間は無かった。とりあえずCOBOLに詳しい人が講師となってレクチャーをしてもらうことまではやったが、外部設計は年内までのスケジュールで組んであったので、バッチの全機能と画面補助のオンラインバッチの設計書を書き上げる計画は変わらなかった。しかも駆け込みで初期移行の計画書まで書かされ、こちらのほうもひと悶着あった。年末にわざわざ会社に出てきて設計書なんて書きたくないので、私は大急ぎで設計書を修正して見栄春さんとの一対一の社内レビューを嫌々終えて、年明けの社外レビューに備えた。
客は本来要件を出すのが役目で、その要件を元に我々が設計して客に見せ、客がそれを確認してダメ出しするうちに承認することで先に進む。今回のプロジェクトでは、客が要件よりも設計に走ってしまっていた。データモデルの項でも書いたように、プロジェクトの総元締めまでもがデータモデルを自ら示し、我々に押し付けてきた。押し付けたというと語弊があるが、一度客から何か示されればそれを検討し、もし違う方式にしたいならちゃんとした理由を示さなければならない。つまり、客の案のデメリットを挙げた上で、自分たちの案を作り、その説明資料まで用意しなければならない。まともにやるとなると余計な手間が掛かりすぎてしまう。そこで我々は面倒を避けて工数を抑えるために、客の出してきたアイデアに多少問題があっても客の言うことを聞くことにしようと決めた。
私はこの問題を事あるごとに上に言ってきたのだが、改善される見込みはまったくなかった。そこで私の担当部分の設計が客先でレビューに掛かったとき、客から方式の変更を求められても食い下がってみることにした。焦点はなんてことはない、データの持ち方についてだった。本来客の確認が必要なのは主に入出力のことで、内部での処理の細かいやり方が問題となることはほとんどない。私は入力されたデータ一件一件をなるべくそのままの形で保持するような設計をしたのだが、客はもっと汎用性を持たせろと言ってきた。汎用性を持たせたからと言って今回のシステムで何かあるわけではない。むしろそのために余計な時間が掛かるだけだし、データ処理の単位が一つだったのが複数に分かれてしまうというはっきりしたデメリットもあった。特にこの部分は大事なデータなので、源さんからわざわざ一件ずつデータを処理してコミットを掛けろと注文をうけていたところだった。ところがこの日、源さんは多忙で欠席していた。私が源さんの言葉を引用して頑なになっていると、見栄春さんまでもが静かにこう言った。「なにか設計を変えたくない理由があるのかな」それをさっきから説明しているというのに届いていないのだろうか。するとついにお客さんの一人がキレてこう言った。「客の言っていることを聞かないのですか」私はすぐさまこう返した。「まず要件から言ってください」と。危なくなった空気を察してとりあえず再検討すると言って収めて別の話題に入った。別の話題の検討が進んだあとで、別の客が突然ボソリとこう言った。「さっきの件の答えなんだけど、要件は保守性かな。将来的に別のシステムが出来たときに、途中からデータを入れることが出来るから」もう別の話題に入っていたのに、この人はずっとそのことを考え続けていたのか、それともふと思い立って言いたくなったのだろうか。私は彼に合わせて「そういうことでしたら分かりました」と言って一応納得し、持ち帰って設計を変更した。これ以上この件でもめるのは危険だと判断したのもあった。
翌日私は見栄春さんとサシの話し合いを求められる。もうあのお客さんと私とは修復不可能な関係になったかもしれない、と。こういうことは絶対に避けなければならないことであり、もう手遅れかもしれないが、今後こういうことは無いようにしてくれと言われた。一方で、あの場にいながら途中で静止しなかった自身の非も認めた。私がお客さんを説得することも一応期待していたらしい。自分は客の側に立っていい顔をしていたにも関わらずである。私はもうちょっと見栄春さんから何かサインがあれば止めたかもしれないと言い、今度からもしそういうことがあって私が空気を読めていないようだったら強引に止めてくれと頼んだ。
次の打ち合わせで我々は修正した設計を持って、今度は源さんがいる場で設計を説明することになった。今回修正した点に差し掛かったとき、源さんが例の調子で突然怒り出した。俺はここでデータを一件一件確実に処理しろと言ったのになんでこういう設計になっているんだと。シーンと静まりかえるその場で、私の隣に座っていた黒タイさんが周りに聞こえるように私にこう耳打ちした。「これって結局変更前のやり方だよね」私はびっくりして「うーん、まあでも、要は処理単位の問題だから…」と口を濁した。向こうにも向こうの立場があるからこういうことであまり角を立てたくなかったし、私は自分が正しいということをことさらに言いたいわけではなく、今後お客さんがあまり設計に口を出さなくなってくれればいいかなというぐらいに考えていた。その場は結局、前回急にボソリと「要件は保守性」と言った人がホワイトボードの前に出てきてこの人にしては珍しく力の入った説明をして、源さんもその勢いに押されてか欠席した会での結論に話をあわせるためかいつになくおとなしく納得した様子で聞いていた。
この件はこれで終わりだとこのとき私は思った。だがそれは楽観的すぎた。いつまでも外部設計のレビューのために打ち合わせで全員で検討するのは時間の無駄だからと、前回私にキレた客と見栄春さんと私とで個別に外部設計書のレビューをすることになった。日をあらためて客の会社に出向いていったその場で、彼は私が書いた設計書の細かい誤字脱字を指摘し、こんなのはレビュー以前の問題だと言い出した。普段は落ち着いた物腰で丁寧語をしゃべっていた彼が、急に私に対してため口になり私を罵倒した。そして見栄春さんに向かって「もっと叱ってやらないとダメですよ」と言った。私は唖然としたが、その場ではずっと謝った。どうやら彼は見栄春さんを味方だと思っていて、見栄春さんが私を制御できていないと思ったらしいのだった。ヘンなところで客に媚びているからこういうことになるのである。
レビューが終わったあと、自社に帰る前に喫茶店でちょっと話していこうということになり、私と見栄春さんと、あとカスタマチームで何か要件を確認したいということでついてきていた若健さんの三人でコーヒーを飲んだ。一息つくと、おもむろに見栄春さんは私を説教しだした。私はそれを最初黙って聞いていた。彼の話が、社会人としての何たるかということに及ぶにいたり、私はキレた。私は会社を代表して謝ったつもりなのに、なぜそんなことを社内の人間に言われなければいけないのか。だいたい今日の設計書だってあんたが社内レビューの責任者として通したものだろうと。そりゃ確かに設計書の誤字脱字は小さくはない問題だけど、この段階での設計書のレビューはそんなことより設計内容を見るものなんじゃないのか。
あえて口にはしなかったが、私は見栄春さんのことが嫌いなのにも関わらず、彼が客から問い詰められていて困っていたときは仕事だから横から代わりに釈明したりしたのに、本当に裏切られた気分だった。私と見栄春さんとのやりとりを黙ってみていた若健さんが気の毒に思えたので、適当に切り上げてその場は解散したが、見栄春さんは私の迫力に押されたのか、自分の非も一応認めたようだった。
その日を境に、見栄春さんが冷却期間と称して、私は客先に出向くことをしなくなった。そうなると設計書のレビューが進まないため、社内では私が設計書を書き、社外では私の代わりに黒タイさんが設計書を客に説明することになった。黒タイさんによれば、私が出向かなくなっても、その担当者は設計書にある私の名前を見つつ、よくわからない部分で私の名を出してダメ出ししていたらしい。
この事件が起きた背景には既に説明したとおりいくつかの問題があるが、一番根本的な問題は、源さんの言うことが絶対だったことである。私はプロジェクトの体制についての問題を何度か見栄春さんに言った。「見栄春さんのカウンターパートは誰ですか」アクタチームの客側の担当者は、私にキレた例の客だった。だからアクタチームのリーダーである見栄春さんのカウンターパートはその人であり、見栄春さんはその人のほうを向いて折衝しなければならなかったはずだった。しかし見栄春さんは、実質なんでも決めてしまう源さんの方向ばかり向き、担当者を軽んじた。それは現実問題仕方のなかったことなのかもしれない。しかし、このような体制にしてしまったプロジェクトマネージャレベルの問題をどれだけ認識していただろうか。図らずも源さんがいない場で首を縦に振らず源さんの言葉を引用して主張した私に、担当者は自分が軽んじられているという思いがあったのではないだろうか。
こうして年明けに崩壊したアクタチームの外部設計は、順調に遅延していたカスタマチームと共に遅れに遅れ、本来ならば年度末までに機能限定で稼動するはずだったシステムが、年度末時点で外部設計すら終わらない状態で抜本的な再スケジュールを迫られた。