基本設計書の承認後

投稿者

投稿内容

yangjiayi: ベテラン; 会議室デビュー日: 2007/10/04; 投稿数: 59

投稿日時: 2009-04-08 22:50

お世話になります。
基本設計書はお客様に承認をもらいました。
その後、詳細設計書を落とそうと思った時に、基本設計書の中に不適なロジックがありました。

その時、
詳細設計書の作成側として、不適なロジックのところを補完し（ある程度ロジック追加）、作っていくのですか。

それとも、

基本設計書はすでに承認済みのもので、不備なロジックのまま、詳細設計書に落とすのでしょうか。

先日、私が「承認済みのものですから、間違っても、詳細設計に落とすのだ」と現場の方に言われて、本当、これっていいのですか？

Gio: ぬし; 会議室デビュー日: 2003/11/28; 投稿数: 350; お住まい・勤務地: 都内から横浜の間に少量発生中

投稿日時: 2009-04-08 23:25

プロジェクト毎に異なり、一般的な答はないと思いますが、私見を述べます。

お客様に基本設計の不備を説明し、修正した上で再度承認をいただくのが最善と考えます。

承認済みのものだからと言って間違ったまま詳細設計に落とすと、間違ったプログラムが作成されます。
テスト仕様は正しいシステム仕様から作成されると考えますが、もしそうであれば上記のプログラムは確実にテストで不合格となります。
そこから手戻りでプログラム、詳細設計、基本設計と修正した時のコストは、現在の段階で基本設計を修正しておく方法よりも高くなります。
（アラン・デービス著「ソフトウェア開発201の鉄則」（日経BP社）の原理 41 をご覧ください）

もしも yangjiayi さんがいらっしゃるプロジェクトで、一旦お客様に承認いただいた基本設計は絶対である、その結果手戻りが発生してコストが増大してプロジェクト予算に赤字が出ても良い（もしくはお客様が負担する了承を得ている）のであれば、この限りではありません。

yangjiayi: ベテラン; 会議室デビュー日: 2007/10/04; 投稿数: 59

投稿日時: 2009-04-09 07:27

引用:

Gioさんの書き込み (2009-04-08 23:25) より:
プロジェクト毎に異なり、一般的な答はないと思いますが、私見を述べます。

お客様に基本設計の不備を説明し、修正した上で再度承認をいただくのが最善と考えます。

承認済みのものだからと言って間違ったまま詳細設計に落とすと、間違ったプログラムが作成されます。
テスト仕様は正しいシステム仕様から作成されると考えますが、もしそうであれば上記のプログラムは確実にテストで不合格となります。
そこから手戻りでプログラム、詳細設計、基本設計と修正した時のコストは、現在の段階で基本設計を修正しておく方法よりも高くなります。
（アラン・デービス著「ソフトウェア開発201の鉄則」（日経BP社）の原理 41 をご覧ください）

もしも yangjiayi さんがいらっしゃるプロジェクトで、一旦お客様に承認いただいた基本設計は絶対である、その結果手戻りが発生してコストが増大してプロジェクト予算に赤字が出ても良い（もしくはお客様が負担する了承を得ている）のであれば、この限りではありません。

Gioさん

コメントありがとうございます。
私は再度上司に相談してみます。
上司に「くどい」いわれていますが、やるべきだと思った以上、何度も相談するべきだと思いますね。
_________________
yangjiayi

あじぇ: 会議室デビュー日: 2006/11/28; 投稿数: 5

投稿日時: 2009-04-09 09:53

PL法（製造物責任法）はご存知でしょうか。
私はその方面は明るくないので適切かどうかは断言できませんが、
設計上の欠陥を知りながらリリースしてユーザーに損害を与えた場合、
上記の法に抵触して損害賠償責任が発生する気がします。

ユーザーが承認してるんだから責任ないでしょ、って話になるのかどうかも含めて、
詳細はよく分かりません(^^

が、説得する材料に使えるかも知れませんので、
よろしければ調べてみてはいかがでしょう。
識者のフォローがあれば幸いです。

BR6: 常連さん; 会議室デビュー日: 2009/03/04; 投稿数: 33; お住まい・勤務地: 東京

投稿日時: 2009-04-09 10:06

PL法は「有形物(不動産を除く)」を対象にしたものであって、
データやプログラムのような「無形物」は、PL法の対象にはなりません。

但し、組み込みソフトについては、機器に組み込まれた「部品」とみなされる為、
PL法の対象となります。

turutosiya: 常連さん; 会議室デビュー日: 2003/06/10; 投稿数: 49; お住まい・勤務地: 東京都

投稿日時: 2009-04-09 11:41

yangjiayiさんの

引用:
客様に基本設計の不備を説明し、修正した上で再度承認をいただくのが最善と考えます。

に賛成です。

引用:
基本設計書はすでに承認済みのもので、不備なロジックのまま、詳細設計書に落とす

って「どんだけ～」って思いました！

_________________
Toshiya Tsuru
http://d.hatena.ne.jp/turutosiya/

[ メッセージ編集済み編集者: turutosiya 編集日時 2009-04-09 11:46 ]

jun: ベテラン; 会議室デビュー日: 2003/01/07; 投稿数: 80; お住まい・勤務地: 愛知県

投稿日時: 2009-04-09 12:17

JUNといいます。
こんにちわ。

いわゆる「変更管理」というやつですかね。。

プロジェクトととしての手順を確立しておいて、
証跡を残すようにするのが基本かと。

ユーザ起因であれば、営業の出番となる根拠となります。

はにまる: ぬし; 会議室デビュー日: 2003/12/19; 投稿数: 969; お住まい・勤務地: 誤字脱字の国

投稿日時: 2009-04-10 01:45

引用:
yangjiayiさんの書き込み (2009-04-08 22:50) より: 先日、私が「承認済みのものですから、間違っても、詳細設計に落とすのだ」と現場の方に言われて、本当、これっていいのですか？

本当に良いか判断できるものではありませんし、この手の話は組織活動では、よくある話です。

多くの場合”理不尽”と表現されますが、個人で判断できる情報限界に起因するものです。私達がテレパシーで意思疎通が出来ない以上、仕方の無いことなのです。

組織活動で利用するシステムを組織活動で構築する場合、個人で判断できる情報限界に度々出会います。そして情報限界に出会った時、どの様に対処するのか基本設計者としての道が大きく分かれると思います。

詳細設計と基本設計は言葉や行為が似ていますが、担当者として求められる振舞は全く別ものです。

詳細設計は基本設計を元に正しいか評価できますが、基本設計は正しいか評価できません。

基本設計では、いくら正しいと判断してユーザの一言で覆ったり、逆に間違いと思っていもユーザが了承すればそれが妥当と評価される事は多々あります。そのユーザの一言が単なる思い付きの様に見えても限られた情報の中で理に適った判断をしているものです。

適切なシステム構築には、まず適切な組織運営が必要です。そしてその適切な組織運営は常に”正しい”と評価できる事は案外少ないものです。

自分の思いの正当性を主張する前に、まずは周囲への理解から初めては如何でしょうか？そちらの方がシステム設計のあるべき論よりも基本設計担当者には重要な事と思います。理解しようと努めない者に周囲は情報を提供してくれません。

所詮”システム設計のあるべき論”も現場で繰り返し発生する問題から生まれた理論なのですから。

[ メッセージ編集済み編集者: はにまる編集日時 2009-04-10 01:48 ]

1|2 次のページへ»

基本設計書の承認後

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