----------------------------------------------------------------------

（開発システムの本稼働移行について）

----------------------------------------------------------------------


----------------------------------------------------------------------
（設問ア）
----------------------------------------------------------------------
１．プロジェクトの概要と本稼動移行を妨げる問題
----------------------------------------------------------------------
１．１．プロジェクトの概要
----
　今回、私が携わったプロジェクトは、中堅自動車部品
製造業Ａ社のインターネットを活用したＷＥＢ型ＥＤＩ
部品発注システムの開発である。Ａ社では、部品在庫の
３０％削減を目標に購買系システムの大幅な改革を実施
中で、現行のバッチ型ＥＤＩに、今回開発するＷＥＢ型
ＥＤＩを併用することで、ＥＤＩ対象購買先を拡大し、
短納期での部品発注を目的としていた。

　購買先を集めて、ＷＥＢ型ＥＤＩシステムの導入説明
会を実施済みで、２００６年５月よりの本稼動は必須で
あり、本稼動時期の延期は困難な状況であった。

　当該ＷＥＢ型ＥＤＩシステムの開発は、６ヵ月間とい
った短期間での開発であった。上位の購買系システムと
のインターフェースは、既存のバッチ型ＥＤＩシステム
と共用し、購買先とのデータ授受部分のみをＷＥＢサー
バ上に新規に構築するものであった。

----
１．２．本稼動を妨げる問題
----
　システム開発が完了し、結合テストとして、Ａ社購買
部門が選定した購買先５社の実務担当者による操作テス
トを実施した。テスト結果から、現在の仕様では、本稼
動時には、購買先の実務担当者のちょっとした操作ミス
による部品発注漏れが発生するリスクが大きいことが判
明した。

　具体的には、購買先でのデータ受信保管完了の確認方
法に問題があり、購買先が発注情報を自社パソコンに保
管していない状況でも、Ａ社ＷＥＢサーバ上の配信制御
テーブルには、配信完了となってしまう点であった。

　テスト結果評価会では、ＷＥＢ型ＥＤＩシステムの利
用者は情報システムに精通していない一般利用者を想定
しており、データ受信操作に関してフールプリーフの設
計が不可欠であるが、新システムでは不十分と判断した。


----------------------------------------------------------------------
（設問イ）
----------------------------------------------------------------------
２．本稼動移行を妨げる問題への対処方法と工夫
----------------------------------------------------------------------
２．１．問題の分析
----
　テスト結果評価会の結論をＷＥＢ技術に精通している
技術担当者に分析を指示した。技術担当者の報告では、
今回採用したＷＥＢサーバの技術的な特性で、購買先担
当者が、Ａ社ＷＥＢサーバよりデータを受信して、確実
にローカルディスクにデータ保管が完了したかは確認で
きず、単に画面表示しただけかも知れないということで
あった。購買先で画面表示しただけでも、Ａ社ＷＥＢ
サーバ上では、配信完了と判断していた。

----
２．２．対処方法と工夫
----
　私は、この問題を業務上では、注文洩れリスクと認識
し、プロジェクトオーナであるＡ社購買部長に状況を報
告し、関係者を集めての緊急対策会議の開催を提案し承
認を得た。対策会議には、業務側として、購買部門の発
注責任者、経理部門からは、法律上の扱いについて助言
を得るために法務担当者及びシステム開発を担当する当
社の開発チームのリーダが参加した。

　購買部門から、既に購買先には導入説明会を実施して
おり、当初の予定通りの稼動を強く要請された。開発
チームのリーダより直面する問題を解決するには、
ＷＥＢ型ＥＤＩのミドルウェアの変更が必要となり、
ＷＥＢサーバとの整合性の確認など、全ての検証がやり
直しとなり、とうてい納期に間に合わないと報告があっ
た。

　緊急対策会議の席上では、運用主体であるＡ社購買部
門と開発主体である当社開発チームの意見が対立し結論
はでなかった。プロジェクトマネジャとしての私は、購
買先での運用性を損なわず、システム技術面で対処する
には、ミドルウェアを高機能なものに変更して再開発す
るか、購買先での受信確認のための複雑な造り込み制御
を実装するしかないと判断した。開発チームリーダに、
各々の実現可能性と概略工数を調査するように指示をし
た。また、その一方で、システム開発を通じて既知であ
るＡ社営業部長にＷＥＢ型ＥＤＩを採用する顧客に関し
て、配信データの管理方法について調査協力を依頼し快
諾を得た。

　Ａ社営業部長からの調査によると、ある中堅顧客の
ＷＥＢ型ＥＤＩシステムでは、データ受信し、納入伝票
を印刷しデータ保管後に、ＷＥＢ画面より、受信処理完
了ボタンを押下することが要請されていた。このボタン
を押下することで、配信データが未受信領域から受信済
み領域に移動する仕組みとなっていた。この事例にヒン
トを得て、Ａ社のＷＥＢ型ＥＤＩシステムにおいても、
購買先のデータ受信完了をシステム上で自動認識する方
法を廃止して、受信完了ボタンを押下にて配信管理テー
ブルの制御に方針転換した。開発チームのリーダに、受
信完了ボタン押下画面の新設と配信制御システムの改訂
の検討を追加指示した。

　チームリーダから、３種類の対処方法について、実現
可能性と概略工数の報告があり、この結果をもって、第
２回目の対策会議を開催した。ミドルウェアの変考案は
費用及び納期面で採用不可となり、造り込み制御案は、
納期及び保守性と拡張性に問題な残すことになり、採用
不可となった。購買先の操作性に若干の懸念があるが、
受信完了ボタン新設案が進めることに決定した。もちろ
ん、この案についても、２人月の追加開発工数が必要で
あるが、新規の追加画面のため、既存開発完了部分の影
響範囲も限定されており、手戻りも最小限に抑制されて
いる。

　また、Ａ社顧客の事例を参考にしたので、受信完了ボ
タンの概念がビジネス特許などに抵触しないか、Ａ社購
買部長経由にて、Ａ社の法務担当者に確認を依頼した。
ビジネス特許などへの抵触もなく、追加開発に必要な要
員も確保でき、受信完了ボタン新設案で順調に開発が進
捗し、当初予定通り、本稼動移行が可能となった。

　今回の工夫した点は、Ａ社の顧客のＷＥＢ型ＥＤＩを
調査したことである。Ａ社自身の顧客が採用している方
法なので、Ａ社の購買部門でも、大きな抵抗なく採用が
可能になったと考えている。


----------------------------------------------------------------------
（設問ウ）
----------------------------------------------------------------------
３．対策の評価と今後の課題
----------------------------------------------------------------------
　期限内での新部品発注システムの開発が完了し、当初
予定通り、本稼動移行ができた点については、プロジェ
クトオーナであるＡ購買部長より評価されている。

　今回の対処方法は、受信完了ボタンを新設し購買先か
ら受信完了の連絡を貰うという単純なものであるが故に、
短期間で確実に実装できた。このような単純な実装によ
り、納期だけでなく、目標とする品質及び性能要件も同
時に確保できた。

　また、業務面においても、ＷＥＢ型ＥＤＩシステムの
採用により、ＥＤＩ採用購買先が３０社から１５０社強
に拡大し、発注リードタイム短縮だけでなく、注文書の
発送工数と費用とも大幅に削減可能となった。この点に
ついても、購買部門の実務担当者から大きく評価された。

　今後の課題として、新技術を採用する場合には、予期
しない技術トラブルに対処するために、技術検証に必要
な専門技術を持った要員と検証期間と工数に十分考慮し
て、プロジェクト計画を策定したいと考えている。