優要件定義と外部設計は時間との勝負

優要件定義と外部設計は時間との勝負

　時間をかければかけるほど、優れた要件定義と外部設計はできる。だが、「もうこれでよい」という限度は誰にもわからない。むしろスケジュールを先に設定し、それぞれの機能を時間を限って検討していくほうが合理的である。このとき、全体機能から重要な機能を20％選び出し、その設計に80％の時間をかける計画にする。これはシステムでは、20％の機能が全体の仕事の80％を処理している「2・8（にっぱち）の法則」によるものである。スケジュールを守ることを重視し、細かいところにこだわってはならない。めったに使わない機能に時間をかけたり、時間切れで吟味しない機能を残すようなチグハグは避けよう。

苦渋の決断 -3

パンドラの箱

　協力会社の役員の話は、悲鳴に近かった。「『プロジェクトの内部は大混乱。これではITのプロとしての仕事を果たせない』とリーダーが泣きついてきた」と言う。

　社長室との確執以来、意識的にプロジェクトから距離を置いていた金山だったが、旧知の役員からの訴えとあっては無視できない。早速、プロジェクト・メンバーを水面下で呼び出して、事情聴取を始めた。

　事態は、金山が想像した以上にひどかった。ビジネス・ロジックが比較的簡単なサブシステムは、実際のコーディング作業が始まっている。だが、独自開発する最難関の生産管理システムは、まだ内部設計が終わっていない。角川が協力会社のエンジニアのマネジメントに忙殺されているのが、影響している。

　残る中核システムである会計システムと販売管理システムはパッケージを使うのだが、実業務とのフィット・アンド・ギャップ分析に手間取っていた。現行の会計システムや販売管理システムは、創業当時から使い続け、拡張に拡張を続けてきただけに、全体像を理解している者がいない。それだけに作業は手間取った。

　木下ら社長室が最初に提出したプランでは、現行システムの機能の整理をしたあと、汎用性のある業務パッケージに置き換えることになっていた。「世界を相手にしたグローバル経営の時代には、同じ道具を使い、同じ方法で“違う”戦い方をしなければならない。情報システムも経営を支える道具として、間接コストを切り詰めるため、他社と同じ道具と方法で戦うべきだ」と木下は、盛んに主張していた。

　だが、現実は違った。戦い方以前の問題として、道具によって業務が縛られそうになっていた。例えば、会計システムへの採用が決まった「リアルタイム会計 PLUS」で経理部門が期待していた機能を実現しようとすると、昨年出荷が始まった「Ver.5」を使う必要がある。だが、「Ver.5」は最新版のOS でしか動かない。一方、販売管理システムに使う「CSS販売システム」は、一つ前のバージョンのOSしかサポートしていない。異なるバージョンのOSを入れることは、運用面からもあり得ない。「業務システムは企業の戦略そのもの。安易にパッケージに頼っては、競争優位は実現できない」と日ごろから考えていた金山は頭を抱えた。

　金山の調査で、もう一つ難問が発覚した。購買システムと他システムの連携である。「なに、システムがつながらないとは、どういうことだ」。担当のメンバーからのヒアリングの最中、金山は思わず叫んだ。「購買システムはほとんど変更しないんだろう。新システムにリアルタイムでデータを渡すだけじゃないか。いったい何が問題なんだ」。担当メンバーへの質問もつい語気が荒くなる。

　「いや、私も最初はそう思ったのですが…」。担当メンバーは焦って説明を始めた。

　説明によると、この購買システムは、もともとデータ連携をほとんど考慮しないで作られたもの。夜間のFTP（ファイル転送プログラム）から日中のリアルタイム転送に変えるとなると、システムの処理形態自体をバッチからオンラインに替える必要がある。

　「どの程度影響がでそうだ」。金山の問いに、担当メンバーは答えた。「総プログラム200本の約3割、58本です。今の見積もりでは、32人月はかかる計算です」。

　「32人月か。1人月100万円として、3200万円か。そんな追加予算は、申請されていないよな」。金山は嘆く。

　追い打ちをかけるように、担当メンバーは言った。「もちろんです。しかも、新システムが要求する形式でデータを用意するには、同じぐらいの工数が別にかかるはずです」。

　「すると合計で64人月、6400万円が別途必要というわけだな」。金山の表情がますます暗くなった。

　「社長室の木下君はこの件を認識しているのかね」。金山の問いかけに、担当メンバーは「はい、ご存知です」と即答する。

　“パンドラの箱”が徐々に開きつつあった。

苦渋の決断 -2

続く予算消化

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

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

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

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

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

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

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

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


先行開発の罠

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

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

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

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

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

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

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