□------------------------------------------------------------------□
□　論文テーマ：Ａ社ＰＯＳデータ分析システムにおける費用管理
□------------------------------------------------------------------□

---------------------------------------------------------------------
（設問ア）
----
　私は現在システムインテグレータであるＥ社に勤務し
ており、３年前にＡ社の依頼を受け、ＰＯＳデータ分析
システムの開発を指揮した。
---------------------------------------------------------------------
1.プロジェクトの概要
----
1.1.イントラネット採用の意味
----
　Ａ社は関東地方を中心に５０店舗を展開する中堅クラ
スのスーパーである。従来のＰＯＳデータ分析はホスト
計算機の機能として提供されていたが、利便性と単品管
理の強化を目的に、再構築が企画された。
　一方で、各拠点にパソコンは分散配置され、その数は
６００台を超えており、システム導入による新たな
ＴＣＯの増加は避けなければならなかった。
　私はＡ社のニーズを実現するために、イントラネット
システムでの構築を提案し、更にイントラネットの採用
は、ＴＣＯの削減だけで無く、将来的にメーカー・仕入
先との情報共有の基盤造りに結びつくことを説明し、受
注に到った。
　システムは、ＤＢサーバー・ＡＰサーバー・ブラウザ
から構成されており、ＡＰサーバーにはトランザクショ
ン管理機能を持つ市販のミドルソフトを導入した。
----
1.2.自社内におけるプロジェクトの位置付け
----
　当時はイントラネットシステムの構築事例が少なく技
術獲得の格好の場であることから、社内の戦略プロジェ
クトとして位置付けられた。これは、イントラネット構
築に関する開発標準の作成や社内教育等、プロジェクト
の知見をフィードバックすることが目的である。
　具体的には、Ａ社に提出した見積り金額＋αとして、
社内の基盤整備費から１千万（１０人月相当）をプロ
ジェクトに割り当てて頂いた。尚、プロジェクトは６名
から構成され、私は営業・提案活動を経てＰＭとして指
揮する事となった。
---------------------------------------------------------------------
 （設問イ）
---------------------------------------------------------------------
2.プロジェクトに発生した課題と対策
----
2.1.ミドルソフトの不具合
----
　本番カットオーバーを目前にした運用テストにおいて、
ミドルソフトがダウンする現象が多発した。過負荷をか
けた場合に発生し易い傾向にはあったが、現象はランダ
ムに発生しており、Ａ社に本番カットオーバーを躊躇さ
せるには充分過ぎる不具合であった。
----
2.2.カットオーバーの遅れによるコスト増
----
　プロジェクトには６人を配置しており、カットオーバ
ーを１ヶ月伸ばす毎に６００万を超えるコストが発生す
る事になる。これはプロジェクトとしては、絶対に許さ
れ無い事であり、ミドルソフトの不具合を回避しながら
システムを本番稼働させ、プロジェクトをクロージング
に結びつける事が私の責務であった。
----
2.3.不具合の原因究明と対策
----
　一方で技術的な知見の少ないイントラネットシステム
では、ミドルソフトを含めシステム全体に何等かの不具
合が発生するであろう事は私も予想していた。基盤整備
として用意された工数１０人月は、プロジェクト開始時
点で４人月を技術検証に費やし、残り６人月を不慮の事
態に備え確保していた。従って、この６人月を財源とし
て、原因究明・対策に取り組む事が可能であった。
　しかしながら原因は、ミドルソフトの使い方にあるの
か、ミドルソフトそのものにあるのか見当もつかず、
６人月で収める事は困難が予想された。
---------------------------------------------------------------------
3.課題解決に向けて
----
3.1.現象の整理とカットオーバーの決断
----
　原因究明を進める一方で様々なケースでのテストを繰
り返す事により、以下の結論を得た。
(1) ピーク時の運用において発生頻度が５％以下であり、
　平均的な負荷では、発生確率は１％に満たない。
(2) ミドルソフトは自動回復処理を行っており、不具合
　発生時にはもう一度リクエストを上げる事で業務が再
　開可能である。
　以上２点をＡ社に説明し、本番カットオーバーを強く
申し入れた。Ａ社としても、不具合に対する不安はある
ものの、一刻も早くシステムを利用したいとの考えから、
利用者を限定しながら部分的にカットオーバーを開始し
て頂いた。
　これにより、アプリケーション機能としての評価・小
規模改善・不具合への対応を当初スケジュール通り、
２ヶ月のフォロー期間で達成する事ができた。結果、
プロジェクトにはミドルソフトの不具合対応として技術
ＳＥのみを残し、アプリケーションＳＥは順次配置を解
くことが出来た。
----
3.2.メーカへの協力要請
----
　ミドルソフトを作成したメーカには当初電話でしか対
応をして貰う事が出来なかった。しかしながら技術ＳＥ
とメーカのやり取りを見ていると要領を得ず、私はこれ
では６人月以内には原因究明・対策を施すことは不可能
であると判断し、メーカに強く協力を要請した。
　イントラネットのミドルソフトはまだ数が無く、メー
カとしてもシェア拡大に向けて、事例の確保と品質の安
定は喫緊の課題であるはずだと説得し、最終的には現地
にまで足を運んで対応させる事に成功した。
　結果的には、ミドルソフトのバグである事が判り、
パッチの提供により不具合は解決した。当時、もしも電
話対応だけで原因究明を行っていたならば、とても６人
月以内では解決出来なかったと判断している。
---------------------------------------------------------------------
 （設問ウ）
---------------------------------------------------------------------
4.評価
----
4.1.プロジェクトの売上高利益率
----
　前述の施策を実行しながらも、結果的にはプロジェク
トとしては、２人月分の工数を追加して終了する事と
なった。売上高利益率としては、プロジェクトの実績は
７％となり、社内目標値である１０％を達成する事は出
来なかった。
　しかしながら、安全策を取り、ミドルソフトの原因究
明・対策の完了を待ち本番化を行った場合には、２ヶ月
の遅れにより１７％の赤字となっていたはずである。
従って、やや強引ではあったが本番化を押し進めた事は、
Ａ社にとっても自社にとっても正しい方向であったと評
価している。
----
4.2.戦略プロジェクトとしての評価
----
　私は当プロジェクトに営業段階から参加しており、
ＴＣＯの削減等、Ａ社のイントラネットシステムに対す
る期待は充分に理解していた。一方で、業界にもまだ例
が少なく、技術的な不安要素が多くあったことから、受
注の見通しが立つ頃から、上司をはじめとする社内関係
部署を説得し、戦略プロジェクトに位置付る事に成功し
た。
　これは、プロジェクトとして見た場合、赤字を回避す
る効果的な手段であった。勿論、社として評価した場合
にも、ミドルソフト選定のガイドライン・プログラムパ
ターン等、得られたノウハウと再利用可能な技術は１０
人月以上のものがある。
　今日のイントラネット・インターネットビジネスの市
場性を考えると、当時チャレンジ精神を持って取り組ん
だことが、足元の売上に繋がっており、１０人月の投資
は充分に実を結んでいると判断している。
----
4.3.費用管理におけるＰＭの役割
----
　プロジェクトの費用が計画内に収まるようにプロジェ
クトを運用することは、足元のスケジュール管理はもと
より、品質・生産性・仕様確認等なすべき作業は多い。
加えて特に技術革新が激しい今日では、リスク管理が重
要なポイントとなると考える。
　今回のプロジェクトではリスクを全て自社が抱える形
での運用を行った。しかしながら、今後は高いレベルの
ＩＴを要するニーズがある場合、顧客自身にも取り組み
に対するリスクを理解して頂き、双方でリスクを持ち合
い、管理する様にプロジェクトを進めて行きたいと考え
ている。
　当然、理解して頂く為の道は険しいが、我々システム
インテグレーターと顧客が良好な関係を保つ理想の姿で
あり、実現に向けて努力する事がＰＭである私の責務で
あると考えている。