いよいよ上場準備段階に入った頃、僕はシステム事業部門の責任者の肩書のまま、ある巨大プ
ロジェクトのPMとして参加していた。現在はあまり考えられる状況ではないと思うが、当時
は平気でそのようなことが行われた。そのプロジェクトはコンピュータマシンをIBMから富士
通へリプレースするという案件で、メーカーからすると赤字を出してもその顧客を獲得したい
という、一大プロジェクトだった。
僕たちの会社は商社全般のシステム構築に精通しており、その手の業種の仕事があった場合、
必ずメーカーから声がかかるまでのブランド価値を持っていた。そのプロジェクトも富士通か
ら声がかかり、要件分析から参画し、全体で数千人月という大きなサイズだったが、どれだけ
持っていっても構わないというメーカーからのオファーであった。上場を控えた長門さんは
売上欲しさに、出来るだけ規模を獲得してほしいという意向だった。
「もちろん、もっと行けるでしょ」
そのプロジェクトは会社を設立したとき受注した、古巣のシステム規模より大きく、それをす
べて獲得するのはあまりにリスクが大きく、獲得サイズを抑えるべきだ。またプロジェクトが
破綻すると進言した。どんな仕事でも、どんな局面でも、一歩引いた方がいいと発言するのは
正しくても気が引けるものだ。
「真田なら大丈夫だよ」
と長門さんは軽く言う。
「頑張りますが、これ以上は無理です」
もっと規模を落としたかったが、2000人月ほどの規模を獲得する方向に決まった。ただこの規
模はみるみる大幅に膨らんでいくのだった。
プロジェクトは混迷を極めた。顧客は大阪のコテコテの商社で、
「お宅のスキルをもってすれば、簡単に出来るレベルですよ」
「似ている画面やシステムはコピーしてもらえばいいので、そこはタダでお願いします」
といった感じで、生産性の話が通じない人という体を貫くのだった。本来は富士通がこの辺り
の制御をしてしかるべきだが、交渉でことごとく負けていた。
1つのUI（画面）でいくつもの機能をてんこ盛りする設計思想なので、プログラム単体が大き
くなり、システムが複雑になった。高いスキルを持つエンジニアが1人で対応しなければなら
ない、難しい構造になってしまっていた。結果、人員を集めても遊ばせる結果となり、開発
計画は次第に遅れていった。またさらに、商品コードが複雑な体系をしており、それをすべて
のシステムで機能させるには、システム負荷が高すぎて、レスポンスを適度に返すにはサーバ
の性能を一気に何段階も上位機種へレベルアップさせないと耐えられない設計となっていた。
これが致命的となり、富士通は赤字でもOKと言っていた案件ながら、10億の赤字は許される
が数倍の赤字は許されないと、お偉いさんが大挙してやってきた。僕は、眼光鋭いお偉いさん
のひとりに、穴が開くほど、睨まれた。
「設計をやったことがあるのか？」
「こんな子供じみた設計があるか！」
