「要件定義フェーズ」は多少のペンディング事項を残しはしたが一旦終了し、「システム設計フェーズ」に移行した。
池田達は森山から「システム設計」について以下のことを聞いていた。
・システム設計方式には「ウォーターフォールモデル」や「アジャイル開発手法」等があるが、今回は基幹系システムであり計画重視型の「ウオーターフォールモデル」で開発を実施する。
・システム設計フェーズで実施すること
*ベンダーによって切り口や設計書の様式は多少異なる。
①外部設計（機能設計、基本設計等）
②内部設計（方式設計等）
③DB設計
④移行設計
⑤運用設計
⑥構成設計 等
・システム設計は要件定義の結果およびパッケージ機能等を鑑みてベンダー
が実施する。その内容をプロジェクトメンバーがレビューする。必要に応じて分科会等を開催する。最終的には「ステアリングコミッティ」の承認を受ける。
T工業において「システム設計」フェーズをしっかりと体験しているのは長野だけである。「要件定義」フェーズにおける長野の活躍を見て河合は彼に情報管理を一任しようと考えた。河合は現場に根差した製品企画・営業企画に専念しようと思う。
一方の池田も、長野の力は認めているが、まだ地に付いていないのではとの
印象は拭えない。池田は「システム設計フェーズ」における長野の言動をじっくり見ていくつもりである。
「おはようございます！」長野は快活な声で皆に挨拶をした。
今日は、第2回外部設計レビューミーティングである。
テーマ：生産計画（アップロード）～所要量展開～発注データ作成・集約、参加者：【T工業】池田社長室長、田部生産管理課長、沢田資材課長河合営業部次長、羽田彩香（議事録担当）、長野情報管理担当、
安田専務オブザーバ）、渡辺製造部長（オブザーバ）【D社】岩見プロジェクトマネージャ、鈴木アシスタントスタッフ、上田パッケージ・スペシャリスト【M社】コンサルタント 森山 良、木本 健アシスタント 西野ほのか
D社の岩見が生産計画～発注までのシステムフローを提示し、各機能の概要を分かり易く説明した。続いてスタッフの鈴木が画面・帳表設計を主とした外部設計の内容を説明した。
その後、岩見によるデータベースの連携説明が続いた。
一連の説明は約1時間ほどで終了し、質疑応答の時間となった。上野はそろそろ自らの喫煙タイマーが赤く点滅をするのを感じていたが、誰一人休憩時間にしたいと考えている人はいないようだった。
沢田課長がおもむろに発言を求めた。彼女は寡黙であるが、重要な点については決して妥協はしない。また、T工業の数少ない古くからのメンバーであり安田専務や山田常務も頭が上がらないことがあった。
「発注機能関係に関して3点確認させてください。」
岩見が静かにうなずいた。
「1点目です。」
「発注データが正式なデータになった後に、生産計画の修正が発生した場合その影響は、発注データへどのように反映されるかです。月次の生産計画データは数度変更されます。それがどのように影響・表現されるかについて詳しく説明願います。」
「2点目は、1点目と似ているのですが、複数製造場所で同一部品が必要な場合のデータの扱いについてお教えください。」
「3点目は、今回の要件に入ってはいませんが一種類の部品が複数仕入先から購入する場合、効率的な入力対応についてお教えください。」
「1点目と2点目は今回は簡単にご説明しただけなので分かりにくいかと思います。正直を言いますと、データ確定後の修正に関してどのように表現をしたらよいかについて、今日までにまとめきれていません。本日3案をお持ちしていますので実際にお使いになる方のご意見をいただきたいと思います。」
「ただ、基本的な考え方は『確定データ』を直接修正はせず赤黒のデータを発生させます。それらのデータをどのようにお見せしたら良いかを検討中です。」
「分かりました。後程3案をお見せ下さい。」沢田が答えた。
「3点目は、確かに今回の要件外ですが他社さんでも同様な事例があり、その中のメジャーなものはパッケージのオプション機能に組み込まれています。もし、その範囲内であれば、開発費の上乗せは些少です。」
「了解です。別途検討させてください。」
「ただ、導入後の改善案件として位置付けることをお勧めします。」
「了解です。」ここで沢田課長の質問に対する対応は終了した。
ここで出席者の大半は、緊張を解こうとした。閉会を予期して筆記用具を片付けるものもいた。しかし、その期待は裏切られた。
「一点良いですか？」オブザーバの渡辺部長が手を挙げて言った。
この物語はフィクションであり登場する企業・人物は架空のものです。
第20章 完 高石 貢（著）
第2１章 －システム導入(2)－ 8月30日頃 アップの予定です。