ベテランならホントに安心なのか?開発現場の天国と地獄(3)(2/3 ページ)

» 2005年02月04日 12時00分 公開
[佐藤大輔(オープントーン),@IT]

プロローグ:納品不能は天災か?

 ここからは、納期になって発覚した納品不能の状態を何とか立て直し、完成させるまでのプロジェクトの記録(事例)です。もちろん、納品不能という事態は納品日に天災のようにやって来るわけではありません。このプロジェクトは当初から納品不能な方向に向かって時を費やし続けていました。前任の担当者はいくつかの問題をあげつらいましたが、もはや個々の仕様や、技術の問題ではなく、チームの向かう方向や要件の確立方法、仕様の洗い出し方法、開発効率、……、そういった複数の要素が大きく不足していました。

 丸投げで受けた外注先にしてみれば「できない」といってしまえばお金がもらえないこととイコールです。社内のプロジェクトの場合、「できない」と上司に訴え出ることで給料がもらえないことはあり得ません。しかし、外注先にとっては多くの場合死活問題です。ですから、外注先自身も可能な限り進ちょくに問題がないかのように隠蔽(いんぺい)しようとします。受けた以上は能力以上の仕事であれ、納品日まであがこうとします。そのため昨今にかかわらず、元請け会社にとっては、進ちょく管理と品質管理は重要な命題なのです。

 一方、同じ外注先でも自信にあふれた小さな開発会社にとって、大手元請けの担当者を介した顧客との伝言ゲームは頭の痛い問題です。そういった会社にとって、メールを転送する係としての元請けは「いっそいない方が……」と思う気持ちもわいてきます。しかし顧客にしてみれば、大手SIの技術者を集める能力と進ちょくや品質を管理してくれる部分に、高い費用を払っているともいえます。

 では、その記録をひもといていきましょう。

(1) 納期1カ月以上前

顧客からアラートが

 顧客からも何度もアラートが上がっていました。「どうもチームとリーダーにシステムを作る・仕様をまとめる能力があるとは思えない」というアラートでした。実はそのときのチームとは、実装経験のない新人、2?3年目の若手、数十年目のベテランという構成のチームでした。ここで、鍵になるのが数十年目のベテランです。私もこの業界で仕事をしていて、顧客の年配の決裁者に「きみの推す人は5年目にしては高過ぎる」というクレームに驚いたことがあります。能力もあり、信頼もでき、自信にあふれ、何よりともに踏んだ現場での目覚ましい実績から推しているにもかかわらず、やはり「業界20年目とかでないと……」といわれたのです。そのとき「では御社の高い報酬の基準は高い年齢ですね?」と切り返さざるを得ませんでした。

経験年数の示すもの

 今回取り上げる事例ではなかったのですが、結局その案件では「大規模な汎用機のシステムを20年にわたって見てきた方」が「その経験」を武器にプロジェクトを仕切ることになりました。もちろん、その方は元請け会社のお偉いさんと現場を踏んだことがあり、決裁権を持つ偉い人にとって「信頼できる人」でした。

 当初、私はこのプロジェクトにかかわっていなかったのですが「外部からのレビュー」を頼まれて設計書や何かを見て唖然(あぜん)とした覚えがあります。まず、マイクロソフトのVisualBasicとストアドプロシージャで構成されているシステムなのに、「なるべく開発ツールを使わない方針」を打ち立てていました。昨今、システムの開発期間やコスト(価格)はひたすら下がり続けています。その要因の1つは技術革新であり、その中の大きな部分を占めるのがIDEなどによる開発の効率化なのです。

 そのベテラン技術者はずっとテキストエディタでの仕事が中心で、コーディングシートも書かず、机上デバッグをしないプロジェクトは考えられなかったのです。私が行っていた、IDEで動かしながらデバッグする手法は「若造の暴走」とさえ思われていました。

 いまでも時折耳にするのは、「言語は末端の問題で、論理設計は技術の根幹が分かっていれば大丈夫」という神話です。そんなことはありません。論理設計と実装は両輪なのです。可能な限り実装を効率よくするために、実装のしやすいように設計をするのは当然で、そのためには実装技術に精通している必要があります。

 例えば、論理設計を1つ誤ればパフォーマンスが大幅に落ちたりもします。オブジェクト指向言語など、その時代の技術同士であれば、上記の「神話」は成立することでしょう。しかし、汎用機のハードコーディング・センスを持ち込んで、「言語は末端の問題……」というわけにはいきません。両者の距離はあまりにも離れ過ぎてしまったのです。

 唖然(あぜん)とした設計の1つにリレーショナルDBの概念がないことが挙げられます。すべてが1行で「ムーブ処理」し、システムが稼働するようになっていたのです。

売り上げコード 商品コード 1月売上 2月売上 12月売上
0001 ABC001 123,400 157,300 109,800
すべてが1行に詰め込まれたテーブル設計

 必然的に、データベースのテーブル数は極端に少なく巨大な1行にすべてが集約されています。そのため、n月売り上げとn+1月売り上げをSQL文で合計することができません。いちいち2つのカラムを明示的に取り出して、プログラムの中で合計せざるを得なかったのです。もちろん、パフォーマンスは極端に落ちました。

 また、何よりそのベテラン技術者の実装技術が現場の状況にまったく対処できていないことが問題でした。コーディングシート上のテキストファイルはたまっていきますが、一度も動かしたことのないプログラムやテキストの山を抱えてうろうろするありさまでした。さらに悪いことに、「決裁者」はその状態でも彼を信じていました。当時の内部レビューで激しくプロジェクトに問題があることを追及されたにもかかわらずです。

 実は、この光景もよくあることなのかもしれません。決裁者にとっても、自分の推薦した人物(会社)が結果を残せないのは、直接的ではないにせよダメージ(責任)となります。またすでに終了してしまった作業の「価値」に目をつぶり、捨ててしまうのも容易ではありません。ですからその人物なり会社なりを簡単に「切る」わけにはいかず、対策は「ハッパをかける」にとどまってしまうのです。顧客も異変には気付いていました。顧客が営業に強い不満を漏らしたこともありました。その際には「営業」は彼の「黄金のスキルシート」を片手に取りあえず「その場だけ」は、事態を収めたのです。

 ベテラン技術者がすべて彼のようだというわけではありません。このケースはあくまで、過去の遺産をよりどころにしていた技術者と、それを信じていた決裁者の起こした悲劇でした。

(2) 納期1カ月前から1カ月後へ

 さて、今回の事例に戻りましょう。

 いよいよ納期が迫ってきました。しかし、当時まだ別プロジェクトの担当者だった私は平和に過ごしていました。プロジェクトの危険性を訴えた会議も「現メンバーは気合を入れて頑張れ」という結論に達していました。

納品日

 ついに納品日の金曜の夜。その日は、自分の担当プロジェクトの作業は無事終わり、自宅に戻ってくつろいでいました。そんな中、不吉に鳴る部長からの携帯電話。もちろん(電話を)取るのをちゅうちょしました。納品日のことは知っていましたし、少し放っておきましたが、電話は依然として鳴り続けます……。机の上には、ちょうど開けようとしていたビール缶が汗をかいています。時間は金曜の23時。電話に出たとしても、アドバイス程度か、悪くても月曜から手伝いをする(???)くらいに思いながら電話を取ったのが運の尽きでした……。

 それから延々1時間、私が「うん」というまで部長の説得が続きました。納品作業はまだ行われていたのです。

現場の惨状

 その顧客は運送関係で、いわゆる“運送団地” の中にあるため駅からは不便な場所にありました。現場に行ってみると、運送業務が終了し、トラックをすべて出した後のせいか辺りは暗く、その事務所だけぽつんと明かりがついていました。いまさらながら帰りたい気持ちが私の胸の中にわき起こりましたが、すでにタクシーは返してしまいました。暗闇の中から、私は明かりがともる事務所を見つめました。かなり渋々と事務所の扉を開けると、顧客のシステム部門の人だけが全員残っています。自社チームの姿は見えません。おそらく奥のサーバルームにいるのでしょう。

 顧客の人々が私に会うのは初めてです。名刺交換もそこそこに奥に通されました。そこには半泣きのチームメンバーがいました。顧客がいうには「稼働はおろか、状況説明も要領を得ない。どうなっているんだ?」ということでした。私は怒りつつも、ある指示をチームに出しました。それは「これ以上プログラムを触ろうとするな」「パニックにならず、問題点の序列や整理などは不要だから、ただ書き出しなさい」という内容でした。これは、レビュー以上にシステムの中身を知らない門外漢の私が、事態の収拾に向けて状況を掌握するために、最低限必要な情報を効率よく得るために効果があると考えた方法でした。

 しかし……、その書き出したメモを見た私は問題の粒度の粗さと量の多さにがくぜんとしました。これらのメモは要するに「今日は納品日だが、まだほとんどできていない」と語っているようなものでした。夜中の0時を回ってもなお顧客のシステム部員は全員残って待っています。私は彼らにこれからそれを説明しなければなりませんでした。

 もちろん、顧客の怒りはすさまじいものでした。とはいえ、まったくそれは理にかなっており、反論はできませんでした。むしろ、顧客の対応にこそ誠意がありました。ごまかし続けた開発側に対して、顧客のシステム部員は全員で、求められるものを即座に与えられるように待機していました。稼働テスト要員、シナリオ・スケジュール、……。それに対し、こちらはほとんど手ぶらでした。

 思想の間違った設計書、動いたことのない紙上のコード……。顧客の怒りにも恐れ入りましたが、私は何より顧客の誠意に応えるために対応を決意しました。逃げ出そうにも、逃げ出しようもない場所でしたし。その日から、記憶がありません。……というほどひどいプロジェクトになりました。

Copyright © ITmedia, Inc. All Rights Reserved.