苦渋の決断 -2

続く予算消化

　年度が改まった4月。開発現場では、また社長室とシステム企画部が対立していた。生産管理システムは内部設計が始まろうというのに、開発方法論が決まらない。議論を紛糾させたのは、またも社長室長の木下だった。ヤマト事務機器に何かを吹き込まれたのか、唐突に、統一プロセス技法の利用を主張し始めた。

　統一プロセス技法は、反復型による漸次開発の設計技法。その先進性は、IT業界でも折り紙付きだが、いかんせん普及はこれからだ。この技法に習熟したエンジニアの確保も困難なら、ツールのライセンス料も高い。

　「そういえば、統一プロセス技法向けの開発ツールの販売会社をヤマト事務機器が、最近買収したばかりだ」。角川ら、システム企画部のメンバーは皆そう思ったが、表立って言えばけんかになる。統一プロセス技法の利点は認めても、ここは設計の遅れを理由にこれまで使っていた局面化技法（フェーズド・アプローチ）にこだわるしかなかった。

　両者の主張は平行線をたどった。結果は全体を局面化技法で開発するが、一部先行できるものは、統一プロセス技法で開発するという中途半端な折衷案だった。「いつも、もめると折衷案だ」。角川はつぶやいた。折衷案でうまくいったためしはない。

　ゴールデンウイーク前、当初の計画では、開発作業が本格化していなくてはおかしい。だが、実際には、プロジェクト・チーム内に沈滞ムードが漂っていた。特に生産管理システムの外部設計を担当するメンバーは、案の定、統一プロセス技法と局面化技法のはざ間でもがき苦しんでいた。業務単位で見ると、コーディング作業に着手できるモジュールはまったくなかった。

　プロジェクト・リーダーの永山は、頭を抱えた。「おい、どうするんだ」。いらだちをぶつけられた角川に妙案があるはずもない。

　翌朝、永山は言い出した。「角川君、今回のプロジェクトで、『プロトタイプ開発』を試してみようじゃないか」。詳しく聞いてみると、要は「共通部品とフレームワークの先行開発」と称して、ロジックが簡単な周辺システムと、全体から比較的独立している購買部門のシステムを先行開発することらしい。

　「確かに、これなら予算は執行できるな」。角川は舌打ちした。協力会社の要員がスケジュールに合わせて待機しており、進捗が遅れると未稼働要員のコストが発生する。その協力会社のトップから、JUASシステムズ経由で先行開発の提案がなされているとの噂が広まっていた。協力会社の事情は角川もわかる。角川も永山の提案を渋々受け入れた。


先行開発の罠

　「すみません、角川さん。内部設計書を頂戴したいのですが」。ゴールデンウイークが終わるとすぐに、協力会社のリーダーが角川の席にやってきた。このリーダーは、角川が協力会社のエンジニアのまとめ役として期待している一人だ。

　協力会社のエンジニアは皆、若い。経歴書を見る限り、経験不足は否めない。永山は、いつものように「協力会社の管理は任せた」と角川に指示するが、自分が直接一人ひとりを管理すると派遣法に抵触する恐れがある。リーダーの役割は大きい。

　ところが、角川は、やる気にあふれるリーダーの要求にきちんと応えられない。申し訳なく思いながら、「内部設計書はありません」と言った後、あわてて「外部設計書からプログラムを作ってください。そのプログラムからツールで内部設計書を自動生成する方針です」と付け加える。

　「わかりました」と引き上げるリーダーはあきれ顔だ。角川自身も、そんなプロジェクトは聞いたこともない。

　「未決事項が多すぎて、作業を進められません」。そのリーダーが毎週持ってくる報告書は、間もなく、この1文で埋め尽くされた。角川は何一つ反論できない。

　本来は内部設計のスキルしか持たないエンジニアに、外部設計作業を任そうとして、トラブルも起きた。プロジェクト・チーム内では、「少しは自分で考えろよ！」との罵声が出始めた。

　JUAS産業のレガシー・システム刷新プロジェクトが動き出して、ちょうど1年がたった6月のある日、協力会社のリーダーが角川のところにやってきた。「本来、今日は定例の帰社日ではありませんが、会社に戻ります」と言い出す。その翌日、システム企画部長の金山の電話が鳴った。協力会社の役員からだった。