仕様の詰め込み過ぎ

投稿者

投稿内容

ゆうた: 会議室デビュー日: 2005/08/23; 投稿数: 6

投稿日時: 2006-01-19 12:56

現在担当しているプロジェクトで、仕様の詰め込み過ぎが原因と思われるスケジュールの遅れ、品質の低下が発生しています。
全体の体制としてはアーキテクト担当の会社とその下に製造を担当するオフショア先の会社があるという感じです。
アーキテクトチームはお客の要求を直接き仕様に落す仕様担当のSEが一名、それとその仕様を製造担当の会社に落すブリッジSEが複数名います。
私自身は後者のブリッジSEを担当しております。
今はプロジェクトのスケジュールで言うとオフショア先で単体テストがちょうど終わるころです。
そういった状況で上記のようなスケージュールの遅れ、品質の低下が
①仕様の詰め込み過ぎ
②最初にオフショア先に提示した仕様書間の整合性がとれておらず、後から（オフショア先の製造が始まってから）修正する必要があったり仕様を追加してあげる必要があった
などの原因によるものだということに気づきました。
②に関しては、製造に入らない限り予測不可能な矛盾点があるということは良くあることだと思うのですが、
①と相まって修正箇所が大量になってしまったことが今の問題の起因と思われます。
今になって思えば、もっと早い段階で気づくべきだったと思いますが、はたしてオフショアという形態でなく自社で開発をしていたら問題が表面化していたか疑問です。
それはそうとして、現在の状況をどうにか立て直したいと思っています。

・プロジェクトの真っ最中に自分の側（アーキテクト側）が遅れの原因になっていることに気づいた場合、皆さんはどのように対処されていますか？
ご教授ください。

[ メッセージ編集済み編集者: ゆうた編集日時 2006-01-20 00:30 ]

せん: ぬし; 会議室デビュー日: 2002/03/04; 投稿数: 397

投稿日時: 2006-01-19 22:40

すいません、具体的に何処で遅れているのか文章ではわからないのですが、
とりあえず、スケジュールに遅延が発生していると。

で、対応としては、お客さんに事情を説明し、詫びをいれ、

　スケジュールの切り直し
　機能の削除、もしくは機能の分割リリースにより作業量を減らす

を提案する、ぐらいでしょうかね。

気になる点として、

引用:
②に関しては、製造に入らない限り予測不可能な矛盾点があるということは良くあることだと思うのですが、

いや、良くあったら困るんですけど。
今回の場合のようなオフショア形態の場合、これは致命的かと。
仕様作成というものに対する考えが「甘過ぎ」なのです。
この考え方は改めたほうがよろしいかと思います。

仕様の詰め込み過ぎ

スキルアップ／キャリアアップ（JOB@IT）