Click here to visit our sponsor


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

(アプリケーションパッケージの活用について)

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

----------------------------------------------------------------------
(設問ア)
----------------------------------------------------------------------
1.システムの概要及び適用したパッケージ
----------------------------------------------------------------------
1−1.システムの概要
----
 A社は独立系の大手SIベンダーである。メインバン
クのB銀行及びその系列企業向けのシステム開発、運用
を通じて業績を伸ばし、現在の規模にまで成長を遂げた。

 A社は、独立系という特徴を武器に、特定のベンダー
に偏らないSIサービス事業を展開してきた。このこと
はA社の強みである反面、確固たる開発手順が確立され
ておらず、進捗管理、品質管理の手法がまちまちである
という欠点にも繋がっていた。そのため、進捗や品質の
芳しくないプロジェクトの発見が遅れ、納期遅れや赤字
に陥ることがしばしば発生していた。

 そこでA社では2000年度より開発手順や進捗管理、
品質管理の手法を含む社内開発標準を策定し、現場への
定着を図ることにした。また、そのための仕組みとして
プロジェクト管理支援システムを短期間で構築すべく、
アプリケーションパッケージを適用することにした。

 私はA社の社員であり、今回のシステム構築にアプリ
ケーションエンジニアとして要件定義から参画した。

----
1−2.適用したパッケージ
----
 今回のパッケージ適用において、A社の経営層から提
示された選定基準は以下の通りであった。

a.A社の社内開発標準に準拠したプロジェクト管理を
行うことが可能であること。
b.クライアント端末毎の保守を必要としないWebベ
ースのパッケージであること。
c.A社では将来的にCMM取得プロジェクトの拡大を
目指している。そのため、CMM適用支援機能を備え、
かつCMM取得プロジェクトでの利用実績があること。

 私は他のメンバーと協力し、市販パッケージの比較、
検討を行った。その結果、b、cの基準を満たしている
C社製のパッケージを適用することにした。

----------------------------------------------------------------------
(設問イ)
----------------------------------------------------------------------
2.機能分析の結果、存在したギャップ及び解決方法
----------------------------------------------------------------------
2−1.機能分析の結果、存在したギャップ
----
 パッケージを導入してシステムを構築するのに当たっ
ては、パッケージの機能と必要とする機能を評価、比較
し、どの程度適合しているかを見極める必要がある。前
述した通り、今回導入することにしたC社製パッケージ
は前項b、cの基準は満たしていたが、aの基準は必ず
しも満足していない部分があった。そこで、私はその部
分にギャップがあると考え、さらに詳しく機能の評価、
比較を行うことにした。その結果、両者の間には以下に
示すギャップが存在することが明らかになった。

d.進捗率計算方法の相違

 A社の開発標準における進捗管理方式では、WBSで
詳細化した作業毎に進捗率を算出し、上位レベルの作業
については工数による加重平均で進捗率を算出すること
を規定していた。これに対し、C社製パッケージでは、
詳細化した作業毎の進捗率算出機能は備えていたものの、
上位レベル作業の進捗率は単純平均で算出していた。

e.品質計測指標値の不足

 A社の開発標準における品質管理方式では、設計書1
頁当たりのレビューでの指摘件数、テストケース1件当
たりの障害検出数等、10項目の品質計測指標値を算出
することを規定していた。これに対し、C社製パッケー
ジの標準機能で算出できるものは2項目のみであった。

f.管理台帳名の相違

 A社の開発標準とC社製パッケージでは管理台帳の名
称に違いがあった。例えばA社開発標準で開発中に見つ
かった不具合を管理する台帳を”不具合票”と呼んでい
るのに対し、C社製パッケージでは同じ用途に使用する
台帳を”障害票”と呼んでいた。

g.管理台帳への入力項目の相違

 fで挙げた管理台帳を更に詳しく調査、比較した結果、
入力項目にも違いがあることがわかった。

 これらのギャップのうち、gの入力項目の相違につい
ては、C社製パッケージに項目のカスタマイズ機能が付
いていた。そのため、パラメタ設定を行うことでA社開
発標準の管理台帳に合わせることが可能であることが判
明した。そこで、私は他のギャップについて解決方法を
検討した。

----
2−2.ギャップの解決策及びその採用理由
----
 私はd〜fのギャップについて、プロジェクトリーダ
ーはもちろんのこと、標準化の策定を担当する部署の責
任者D氏にも加わってもらい、対応策を検討することに
した。D氏に参画を依頼したのは、A社内部での標準化
推進にあたって、パッケージで実現すべき機能の優先度
をA社の経営計画や施策に照らし合わせて判断してもら
うためである。検討の結果、それぞれのギャップについ
ての対応方法を以下の通りとした。

d’.進捗率計算方法の相違に対する解決方法

 進捗管理方式の統一、定着化はA社にとって開発プロ
ジェクトの状況を可視化するための重点施策である。そ
のため、業務プロセスをパッケージに合わせて変更する
ことは困難であった。そこで、C社製パッケージの進捗
率計算機能を独自開発によりA社開発標準に合ったもの
に変更することにした。

e’.品質計測指標値の不足に対する解決方法

 品質管理方式の統一、定着化も進捗管理と同様、A社
にとって重要な施策であった。しかしながら、10項目
の品質指標のうち、取得必須と定めているのは2項目の
みであり、残りの8項目については任意となっていた。
分析の過程で、必須2項目中1項目はC社製パッケージ
の標準機能で算出可能であることがわかっていた。その
ため、もう1つの必須項目については独自開発により算
出機能を追加することした。また、C社製パッケージで
算出できない任意項目7つについては、パッケージのイ
ンタフェース機能で出力した情報をもとに必要な項目を
算出する外付けプログラムを開発することにした。この
方法を採用した場合、独自開発に比べて、算出の際に情
報出力操作を行わねばならない分、手間がかかる反面、
開発にかかる工数は少なくて済むという特徴があった。

f’.管理台帳名の相違に対する解決方法

 A社の開発標準は既にガイドラインが現場の開発プロ
ジェクトに配布されており、管理台帳の名称をパッケー
ジに合わせて変更することは現場に不信感を与えてしま
う可能性があった。そこで、管理台帳名も独自開発によ
りA社の開発標準で定めたものに変更することにした。

----------------------------------------------------------------------
(設問ウ)
----------------------------------------------------------------------
3.パッケージ活用についての評価及び改善したい点
----------------------------------------------------------------------
3−1.パッケージ活用についての私の評価
----
 今回のパッケージ活用では、A社の開発標準とパッケ
ージの機能の適合性を分析し、業務プロセスの変更の程
度や施策としての優先度を考慮した適切な解決方法を選
択できたと考えている。現在、プロジェクト管理支援シ
ステムは予定通りの納期に構築を終え、開発現場のうち、
いつくかのプロジェクトで試行が始まっているが、評価
は上々である。特にA社の開発標準に準拠した進捗率計
算ができる機能については、標準化の定着に有効である
との評価を方々から頂くことができた。

----
3−2.今後改善したい点
----
 今回のパッケージ活用では、ギャップの分析とその解
決は比較的順調に実施することができた。その反面、現
場の開発プロジェクトでどのようにして利用を開始すれ
ば良いかを記述したドキュメントが不足しており、試行
したユーザが、利用開始時の情報設定操作に戸惑うこと
がしばしば発生した。そのため、利用者視点に立ったド
キュメントを整備し、今後予定されているA社の本格的
利用がスムーズに行えるよう尽力してゆきたいと考えて
いる。
                       
以上





[ 戻る ]