システム開発における

システム開発における
問題点の分析について、アドバイス頂きたい事があり
投稿させていただきました。

<経緯>

現在使用している販売管理業務システムを
現行の業務と乖離してきている為内容を修正することとなった。

販売管理システムは、X業務システム、Y業務システム、Z業務システム
３つのサブシステムで構成されていて
それぞれの業務に精通したメンバーを割り当てる必要があった。

ところが、かつて現有システムの開発に携わった経験を持ち、
各業務に精通しているメンバはわずか３名であり、
一方Ｚ業務管理システムの構築に必要な特別なスキルを
身につけているのも、この３名だけであった。

結果として、Ａ課長はこの３名をＺ業務管理システムの開発に配置し、
Ｘ業務管理システム、Ｙ業務管理システムともに、業務には精通しているが
開発スキルは不十分なメンバと開発スキルは十分だが業務の理解は
不十分なメンバの混成チームを編成し、各チームにリーダを配置し、本プロジェクトを開始した。

結合テストが終盤に差しかかる頃、
バグが多発しテストの進捗に影響を与えている状況が露呈した。

結合テスト工程でのバグ原因分析

サブシステム名設計バグ件数製造バグ件数総バグ発生件数
Ｘ業務　　　　５１　　　　８９　　　　１４０
Ｙ業務　　　　２５　　　　１３７　　　１６２
Ｚ業務　　　　２　　　　　２１　　　　２３
全体　　　　　７５　　　　２５０　　　３２５


結合テスト工程でのバグ原因分析の結果によると、
Ｘ業務システム、Ｙ業務システムについて
それぞれ問題点を認めることができますが

Ｘ業務システム、Ｙ業務システムのリーダの立場として、

(1)表３の分析から、不具合を是正するためにどのようなことを行うか。

(2)プロジェクトの初期の段階でどのようなことをすれば根本的に
　ここで生じている問題を回避することができたと考えられるか。

上記２点に関して、アドバイスを頂けないでしょうか。

以上。

宜しくお願い申し上げます。

No.2 ベストアンサー 回答者： don_go 回答日時： 2010/09/08 00:16

(1)に関しては、No.1さんの回答にある様に、Zシステムを

担当した3人のアドバイスをもらって、バグ潰しをするしか
無いと思います。
「結合テストが終盤に差しかかる頃」と言う事なので、残り
のテストを継続して全てのバグの洗い出しをするか、中断して
テストが終了していないソースを、他のテスト結果のエラーの
傾向から見直す、又は、単体テストからやり直すかは状況次第。
バグ潰しをするの際には、致命的なバグか、軽度のものかに切り
分け、優先順序をつけて作業を行いましょう。

また、どの程度の作業工数が掛かるかを見積もって置きましょう。
でないと、納期がきても客先に「プログラムはできていません。」
「いつ完成するかも判りません。」としか答える事ができなくなって
しまいます。

(2)
ちゃんとレビューをするというのも重要だと思いますが....
Zシステムに3人全てを投入して、開発のみに専念させたという点にも
問題は有った様に思います。
Zシステムに、業務の理解は不十分だが開発スキルの高いメンバを割り
当てて、業務に精通しているメンバの指示で作業をさせるという事は
できなかったんでしょうか？
その3人でなければできない所以外の部分を、極力他のメンバに任し、
一歩引いた所から、X, Y, Zシステム全体を見て指示しながら作業をして
いった方が良かったのでは？
少なくとも、X, Yシステムの設計バグ件数は、もっと少なくできた様に
思います。
＃3人の業務知識及び、特別なスキルを誰にも伝える事ができなかった
＃事で、この3人がいなくなれば、システムの事が解る人が、今渡こそ
＃誰もいなくなってしまう事になったのではと危惧しています....

No.1 回答者： F2-A 回答日時： 2010/09/07 00:46

開発中の工程については何も書かれていないのでアドバイスになるか分かりませんが、

(1)に関してはとにかくＺ業務を担当した３人にアドバイスを貰ってバグをつぶせとしか言えません。
(2)に関しては基本設計書、詳細設計書を作成した時点でこの案件に関わった人物すべてでレビューをしなかったんでしょうか？
どうみてもＸ、Ｙ業務を担当した方が理解していないまま結合テストまで進んでしまったように思えます。
おそらくＸ、Ｙ業務のレビュー時にＺ業務を担当した３人に確認してさえいればこんなことにはならなかったのではないかと考えられます。

がんばって何とか終わらせてください。
以上。