さて、ここは私こと和田信也に代わって、湯川祐次が事情を話す事にする。
「おーい湯川君、営業の話を頼むよ…」
「わかりました。お任せを…」
と言うわけで、ここは私こと湯川がイーストの内情を語ろう。
（ここから『私』は湯川である）
さて、物語を続けよう。
イーストでは、Drawingの販売開始から４年が過ぎ、バブルの波にも乗って、販売台数も順調に伸びていった。
そして、Drawingはユーザーの要望にも応え、年１回のペースでバージョンアップもこなし、徐々に機能の充実を図ってきた。
しかし、ここへきて大きな問題が表面化してきた。それが「バグ」である。
どんなシステムにも、バグ（不具合）が存在することは経験上知っている。
ただそれがハードウエアの障害なのか、ソフトウエアが原因なのかを見極めるセンスとその対応努力があるからこそ、メーカーはユーザーからの信頼を得ることできる。
大手ソフトメーカーには、デバッガーと呼ばれる不具合発見を専門としたテスト部隊が存在する。
１日中自社のソフトを過酷なまでにテストし、あらゆる条件下にも耐えうるソフトを提供するためだ。
これがメーカーとしての努めであり、商品を提供する側の責任だ。
だが、イーストにそんな気の利いた部隊があろうハズはない。
特に担当である開発部の長井部長チームは認識が欠如しているとしか思えない。
従って、いかにデバッグ作業が重要であり、後々この問題で営業部全員がユーザーに頭を下げて回ることになろうとは、この時点で開発チームの誰１人気づいていなかった。
いや、更に言うと後々まで対処をしてくれなかった。
店頭や一般流通で販売されているワープロソフトなどのサポートセンターへ電話したことがある人はわかると思うが、当時ではまだ、メーカーの力が強くて、「そんな不具合の報告はでていません、とにかくパソコンをリセットしてください」とあっさり電話を切られてしまったものだ。
いかにも、「安いソフトを買ったんだから文句を言うな」という態度がまかり通っていたが、Drawingのように、１台１台ユーザーの顔を見ながら販売するシステムの場合はそういうわけにもいかない。
代理店にもサポート費用として、当初２０万から３０万というお金を頂いているのだから、バグが発生すれば当然イーストに文句を言ってくる。
ほとんど平謝りしか方法はないが、急いで修正するという約束でその場は許してもらう。
Drawingは以前からバグが存在していた。
しかし、それはユーザーが導入してからすぐに発生するというものではなく、例えば４８時間連続で操作し続けないと発生しないといったかなり根が深いものであった。
なかなか発生しないからと言って許される問題ではないが、その対処方法がわかっていればユーザーへ説明しやすい。
開発チームへは、「２ヶ月以内に修正版をリリースしなければいけないので、そこのところヨロシク」と報告すれば速やかに対応し、無事修正版をリリースすることができた。
これは和田部長が関与していた間だけだったが…。
ところが、長井部長が開発チームを仕切るようになった頃から事情がかわった。
Drawingのユーザー数も５００人を越え、裾野が広がったのか、またはパソコンの処理速度が向上したことで、システムがさらに使いやすくなったのか、やたらとバグが目立ちはじめた。
ユーザーや代理店からバグの報告があるとすぐに長井部長に報告し、対処するよう依頼する。
余談だが、こういう時長井部長はすぐに報告用の書式を作成してくる。
長井部長はこういった報告用フォーマットを作成するのは日本一早い…しかし、その報告に基づいて対応するのは日本一遅い…。
話を元に戻すが、ユーザーは「Drawing使用中に突然パソコンが動かなくなった」と連絡してくることが多いのだが、それをそのまま長井部長に伝えると、「どういう手順で止まったのかここで再現させろ」というのである。
手順を聞くのは当たり前だが、「ここでパソコンが止まる場面を再現しろ」というのはどう考えてもおかしい。
「それをやるのが開発チームの仕事だろ！」と、私は何度も長井部長に文句を言ったが聞き入れない。つまり、長井部長の目の前で、バグの状況を再現しない限り修正作業をしようとしないのだ。
ようするに「ユーザーの使い方が悪い」という良くわからない言い訳を平然と言ってのけるのだった。
私が強固にデバッグするよう求めると渋々作業を始めるのだが、修正が完了するまでには非常に時間がかかった。
営業の私が言うのも変だが、長井部長率いる開発チームのデバッグ作業というのは論理的でない。
いきなりパソコンに向かってプログラムのソースを見始める。
おそらく自分の作ったソースに自信がないのだろう（和田さんの弁）。
何か考えがあってソースを見ているのではなく、ユーザーの操作手順そのままソースで追いかけるのだ。これじゃ時間がかかって当たり前。
結局、怪しそうなところに、「printf("");という一行を加えたら、正しく動作したから」という理由で修正作業を終了する。
まったくバカげた話だが、新たなバグが見つかるとこういうごまかしを繰り返し、その場しのぎをやってきた。
ユーザーは根拠の無いprintfというオマジナイによってかろうじて動作している製品を購入させられるのだ。
こうしてどんどんバグを封じ込めていったため、バージョンアップで一つ機能を追加するだけでも大変な時間がかかった。つまり、別な場所にプログラムのしわ寄せが来るのだ。
まるで腫れ物に触るようにソースをいじくり、最終的には何か不具合が起きると、ドコが悪いのかまったくわからなくなっている。私が考えても、当たり前だろ！と思える。
ユーザーからの電話は朝から晩まで続いた。
もちろん、パソコンが動かなくなったというクレームだ。
私はユーザーに謝るために北は北海道の旭川、南は九州の福岡まで日帰りで行くこともあった。
「うらやましいだろう」って…。
とんでもない、我々営業部には私を含めて４人いたが、でたらめな開発チームの姿勢とユーザーからのクレームの多さを見ていると誰でもイヤになる。
なかには営業マンという肩書きで中途採用された人もいるのだが、ユーザーにただ謝るしかない商品を目の前にして、これを売ろうとは思わないだろう。
代理店もこうした体質に気がついてきたのか、徐々に販売台数が減ってきた。
納品したは良いが、直ぐにバグが見つかり、そのままお金がもらえないというケースも増えてきた。
バグから注意を逸らすために、バージョンアップ（機能追加）し、またバグがでるとバージョンアップ…。
最後には長井部長も開き直り、「湯川に任す」といって私が開発チームに細かな指示を出したぐらいだ。
営業部の売上が減りつつあるなかで、社長や吉田部長率いる受託チーム（技術部）からは、営業部はお荷物だという意見が目立ち始めた。
だが実はDrawingの売上そのものは減っていたが、営業部はまだ赤字を出すまでには至ってない。
実際は、バブルにかげりが見え始めたため、技術部の受託単価が安くなったことで売上が減ったのだ。
そこでその減った分を営業部の売上目標に加算されたのが実情だ。
だから表向きは、売上目標に達してない営業部が目の敵にされたのだ。
技術部はあいてる人がいなければ仕事を取ってくることができないが、営業は売ればお金になるという単純な発想からだろう…。
こうして営業部と受託チーム（技術部）との傷口は、悪化の一途を辿ることになる。
