さて、イーストが隠岐会長の手に移ってからの長井部長チームはどうなったであろうか？
まず、Drawingの開発は、私こと和田の手に戻ってきた。会社再生のために協力してくれっていうわけだ。
行うべき開発は、
１．現行ユーザーのサポート（出力装置の充実等）。
２．現行Drawingの安定化（ソースの洗い出し）。
３．新規Drawing開発（Windows版）
というような優先順位がある。
長井部長チームは、イースト救済のために鈴木建設が発注した１億円の仕事を行うこととなった。内容は、Drawingの鈴木建設バージョンという名目だ。
対外的に見ると、鈴木建設から開発費をもらい仕事をしているように見えるが、実は鈴木建設がイースト救済のために発注した仕事である。
この仕事のために鈴木建設は、１年間ちょっとでイーストのために１億円の開発費を捻出してくれた。開発の内容は、Drawingのメニューを鈴木建設仕様にするという単純作業がメインだった。
鈴木建設が同情で仕事を発注した事実は、現在一部の人しか知らない。しかも、長井チームの技術力は鈴木建設にも知られていたので、鈴木建設では開発依頼要求をわざわざ簡単にしてくれた。
私は鈴木建設と懇意な関係にあったので事実を知っていたが、鈴木建設の担当者には、「長井部長チームのプライドを傷つけたくないから内緒にしておいてくれ」と言われていた。
この話を聞いた私の心境はどうだったろう…。
情けないという気持ちがふつふつと沸いてきたことを今でも覚えている。しかし、鈴木建設は単純な同情からイーストを救済をしてくれたわけではない。
１．Drawingは鈴木建設が開発元となっているため、イーストが崩壊したのでは社会的責任に支障がでる。（鈴木建設内部でもDrawingは使用されていた）
２．鈴木建設の本音はDrawingを他の会社に委託したかったが、技術的ノウハウの難解さから、委託までに要する時間を考えるとイーストの自助努力に期待する。
３．DrawingのWindows版を期待したい。
以上の事情があって、イーストに資金を投入したのだ。
そのためイーストと鈴木建設は話し合いを持って、繰り返し記述すると、以下の線で同意したのである。
これらは隠岐会長の手腕ではない事をことわっておく。あくまで自然な流れとして出てきた合意事項だ。強いて言えば木藤専務がおぜんたてをした。
１．長井部長チームに仕事を振り出す（１億円程度）。
あくまで、鈴木建設発注という内容にしておくが、出来を期待しない。
２．Drawingの商品開発を和田に移管する。
その際、長井チームがDrawingに封印したバグを洗い出すこと。
３．DrawingのWindows版を開発して欲しい。
イーストにとっても、Drawingは商品になるのだから開発費はイーストで持つこと（１億円の救済でどうにかなるだろう）。
これらの件は内密に私にも伝えられたという事だ。
さて、長井部長チームは無事に鈴木建設の仕事を１年後に終了させた。そして、その仕事の終了をもって長井部長チームは解散となった。
まず、長井部長チームに所属していた若手の社員の一部と市原課長は技術部に配属となり、出向に向かった。
彼らは今までパソコンの開発（しかもDrawingだけ）にしか携わってこなかったが、出向は汎用機がメインだ。
しかし、市原課長は「出向のほうが気が楽だよ」と言い、むしろDrawingを離れることが楽しげだった。
Drawingの担当は少なくとも創造性が要求される。しかし、創造性を持ち得ない彼には今までの作業が苦痛だったのだろう。
でも私は言いたい。出向の作業も創造性を必要だ。適切な顧客への提言や新しい技術の導入が不可欠なのだ。
ただ、出向は自分がメインではないだけで、与えられた仕事をこなしていくだけに安住すれば結局はそれだけの人になる。
技術者は慢心してもいけないが、安住してもいけない（そういう人もいないと各人で差がでないから、いても良いのだが…）。
出向の責任者は、長年イーストのために出向のみをメインで行っていた加藤課長だ。
彼は私が知る限り、イーストにおいてずっと出向に行っていた。主にインターグラフ関係の出向だ。
この時期、加藤課長は不動産関係を主に扱っている帝都建託に出向に行っていた。
業務内容は、帝都建託のOA化に伴うアウトソーシングで、顧客に対して適切な提言をしたり、足りないシステムを追加したりする重要な仕事に就いていた。
当時のイーストにとって、この出向の仕事が唯一の生命線となっていた。そこでイーストでは、何とかもっと多くの出向者を受け入れてくれないか？とか、派生する受注が無いだろうか？とか皮算用を始めていた。
現在、イーストの技術部にとって安定した収入を得られる仕事は、この出向にかかっていた。
そういった理由で出向経験豊富な加藤課長が担当する事になったが、この仕事を逃さないために契約当初は吉田専務と大谷課長がフォローをした。
技術部精鋭そろい踏みだ。
しかし次第に長井部長チームの解散に伴って、順調にいきはじめた帝都建託の出向に長井部長チームの人間をまわし始めた。
１回実績を作って信用させたら、能力単価の安い社員に入れ換えるという巧妙な作戦だ。結果的に苦労するのは加藤課長なんだが、イーストにとっては図に乗った。
もとDrawingの市原課長達も出向によって、なんとか首が繋がった。
ここでDrawingを渡された私は彼らに言いたい…。いったいどうしたら、このようなシステムになるんだ？
まず仕様書が存在していないので、「仕様書は？」と聞くと、「あぁこれ」と手渡されたのが「懺悔の書」という大型ファイル3冊。
この懺悔の書なるものは、ユーザーからクレームのあったバグを書きとめて、しかるのち修正した部分のソースを挟み込んであるドキュメントだ。
聞こえは良いが、単なるソースリストに赤いペンで修正内容が書いてあるメモといったほうがピンと来ると思う。そのソースリストが延々3冊。
どのソースファイルのどの部分か？なんてこともわからない。おそらく担当した人にはわかるのだろうが、第３者が見たら断片的なソース集でしかない。
つまり、全く使い物にならない…。しかたがないので、彼らの作成した新機能と封印したバグの洗い出しには電子的に残っている最新のソースに頼るしかないのだ。
機会があったら、彼らの行った作業を技術的に検証したいと思うが、気になった部分を幾つか紹介する。
１．湯川の報告にもあったが、流行のように"printf"というおまじないがソースの各所に存在してバグを封印してある。つまり、バグの発生個所が安定せず、バグの修正をグルグル先に延ばしている。またシステムのタイミングを取る場面にも"printf"が使われている。（筆者注：おそらく、スタック領域の破壊が安定しないバグを生むのだが、"printf"を入れるとスタック領域にゆとりが出てバグを吸収する。全体を一括してDebugする方法に問題があり、通常は分解クリーニングが有効である。リンクの順序を変えたらバグが無くなったというのも根本は同じである）
２．明らかにシステム設計がなされておらず、各人の意思の疎通が無かったと容易に想像できる。設計が存在しないシステムの典型的な例。
(1)新機能のメニューから処理に至る部分に一貫性が無く、メニューごとに担当が勝手にソースを製作してあるので、その都度ソースの解析が必要。
(2)新機能の各部分を各人が勝手に製作しているため、システムが巨大化しており、共通モジュールなんて存在しない。
(3)資源（メモリ）の使用も各部分で勝手に領域確保しているので、機能ごとに専用のメモリワークが切られている。
(4)各人が思いついたときにグローバル領域を使用しているので、うかつにソースに触れられない個所がある。
(5)ソースだけでなく、ユーザーインターフェイスに一貫性が無い（極端には、YESがスペースキーだったり、Yキーだったりする）。
(6)決められた通りの操作をしないと処理が進まなかったり、開発者とマニュアルを良く読んだ人にしか理解できない操作法がある。
３．コメントとソースの内容が一致していなかったり、"a"とか"b"とかわけのわからない変数があるかと思えば、"shori_no_seigyo_wo_bunkatu"なんていう変数やモジュールが存在する。
４．根拠の無いツジツマ合わせのループ回数とか初期値が存在しており、理解に苦しむ。また、「ここをコメントにしないと落ちる」なんていうコメント文が入っている。
まだまだ言いたいことは山のようにあるが、話を本筋に戻すことにする。
しかし、ソースの内容を開発したであろう担当者に電話で質問したときに、もう覚えていないとか、自分がやったんじゃないとか、今忙しいと逃げる態度は許せない。責任者である市原課長や長井部長も、ユーザーがそうしろと言ったとか、もう覚えていないとか、…以下同文…で逃げる。
私はDrawingをこんな風に設計した覚えは無い…しかも、何年もかけて追加された新機能はこれだけ？こんな発想？…逆に壊れている…。
ええい、話を本筋に戻す。
一方の長井部長は、木藤専務がパソコン上での開発の仕事を請け負ってきた。
ガス管を既にある３次元ソフトで簡単に作図できるっていう、某大手ガス会社からの依頼だ。
それは３人月（３００万円。イーストの部長職が仕事を受けるからだ）ぐらいの分量だった。これは工程的にも余裕のある線だ。何故なら、既存のシステムが存在しているので、基本の部品がそろっているはずなのだ。
新規に作成する部分は、アイソメ・グリッド上に配管設置とガス用部品の作成ぐらいしかないだろう。
しかし、設計も開発もできない長井部長は、彼自身困り果てて社内の誰もに質問をしまくりながら開発を進めた。
結局、自身ではどうにもならない仕事を抱えた長井部長は納期を大幅に遅らせて、予定システムの半分にも満たないシステムを顧客に見せた。痺れを切らしたユーザーが、「とにかくできた部分だけでも見せてよ」という事だったからだ。
結果は想像の通り…。「どうなっているの？何なのこれは？」という反応だ。
しかし、幸運な事にもう一度チャンスをもらった（普通は無い）長井部長は納期から遅れること４ヵ月以上で納品した。
通常、プログラムを納品したら顧客は検収を行い、ユーザーの要求を満たしているかチェックする。この検収が無事に通ったら、プログラムを納めた事になり、契約を果たした事になる。
だが、長井部長の検収は悲惨だったらしい。ユーザーの目の前で検収を行っていると、落ちる、機能もれ、仕様違いのオンパレード。
こんな事も普通無い。何故なら打ち合わせをきちんと行ったり、社内での意思の疎通をきちんとしておけば、素人でもなんとかなるからだ。おそらく彼自身が同僚に質問したのは、当たり障りの無い部分なのだろう。彼自身のプライドが素人になりきる事を邪魔した。
さすがにユーザーも、もういいですってことになり、木藤専務を呼びつけ、50万円渡すから引き取ってくださいという事になった。
どうやら50万円分はプログラムを満たしていたのだろう。Drawingを通して培ってきたユーザーが一つ消えた…。
なにより、７ヵ月かかって長井部長の得た売上は50万円という事だ。
さすがに木藤専務も困り、対応策を隠岐会長に相談した。お得意の、自分で決定するのが嫌だから人に相談するという作戦だ。
隠岐会長は社員のことなどに無関心だが、木藤専務が相談してきたので、降格すれば良いだろ？と答えた。
おそらく、酒の席で木藤専務が、「長井部長どうしますかね？」なんて自分の考えている方向に隠岐会長の考えをリードしたのだろう。
木藤専務は隠岐会長がいるから降格人事ができるのだ。今までのイーストでは所詮、私達が木藤専務に直訴したところで何にもならなかった。
まぁ、とにかく長井部長はイーストで初めての降格人事となった。長井課長が彼の新しい役職だ。
後任は、大谷課長が部長職に昇進した。
もうこうなると長井課長に誰も仕事も任せられない…。次第に長井課長は何も仕事をしない窓際族に追いやられた。
そして１年後、とどめの給与カットと主任扱いだ。
こうなると長井課長は会社にいられない。そして終に辞表を提出したのだった。
彼の話は時系列が走りすぎてしまったが、ここで物語から退場する事にする…。
