取引先にどこまで説明すればよいか。

投稿者

投稿内容

xhikko: 会議室デビュー日: 2008/01/02; 投稿数: 10

投稿日時: 2008-01-06 18:04

先日から参照元記事URLの「引継ぎ資料作成について」についてご意見を頂いている者です。

システム設計に当たり合意を取るに当たって
どこのレベルまで取引先に説明すればよいでしょうか？

現在の取引先は「これこれこういう理由でこういう設計にした」を強く求められる。
情報処理系の勉強をしていれば当たり前のようなことでも例外ではないので労力がかかります。

たとえば、ハッシュを用いたデータ構造を設計したときの出来事。
取引先は「データは先頭から順番に読む」というのが絶対的なやり方と思っていたため、ハッシュとは何かを説明して納得してもらわなければならなかった。

取引先はプログラミングしません。また技術も持ち合わせていないように思えます。
こういう状況で内部設計も取引先に承認をもらう意味はありますか？

marun: 常連さん; 会議室デビュー日: 2007/07/19; 投稿数: 22

投稿日時: 2008-01-06 19:02

どこまでも作ろうとすると、いくらでも作ることができると思います。

参照先の書き込みも見て、自分ならどうするかなぁと考えました。
自分たちがその作業に見積もりした時の前提を、見直しします。
そして、その前提の内容ををお客様に説明します。
その前提で、どこまでもやると考えていたのなら、やることになると思います。
そうではないのなら、その内容を伝えます。

xhikkoさんの今回の書き込みは、その見積もりの際にどこまで見積もるべきか
一般的な意見を知りたいということでしょうか。

自分の担当したシステム＝偏ったシステムでの
一般的な場合の回答しかできませんが
私の担当システムでは内部設計書の提出もしていません。
もちろん契約によってはお客様への教育も含めて実施する場合もあると思います。
そういうのは見たことは無いですね。

既に見積もった前提がどうなっているかということは
xhikkoさんのアタマのなかにあるか見積もった人に聞けばいいと思います。
その前提は、見積書に書いてなくてもいいと個人的には思います。
（本当は、書いてあればいいのでしょうけどね）

たとえば、”内部設計レベルの引継ぎの相手をプログラミングのできる
Ｊａｖａプログラマーの前提にしていた。”
”内部設計は引継ぎの対象外”
”こちらが作成した資料をお客様にお読みいただき、
２，３回の質疑応答で完了するレベル”など。
どれでしょう？ほかにもいろんなパターンがあるとおもいますけど。

そして、それ以上を要望されたら、それにはいくらお金がかかると
ご説明するか、あるいは営業に相談しますの２種類の対応になると思います。
今の金額でできることとできないことがあり、
それをタダで受けるかどうかは、
プロマネやもっと上の人、営業を含めて判断してもらいたいですね。

Ｐ．Ｓ．ハッシュの説明の部分だけだとそういうのもアリかなと思います。
時には詳細に内容を説明するのもＳＥの作業だと思いますし。

unibon: ぬし; 会議室デビュー日: 2002/08/22; 投稿数: 1532; お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)

投稿日時: 2008-01-06 20:41

引用:
xhikkoさんの書き込み (2008-01-06 18:04) より: たとえば、ハッシュを用いたデータ構造を設計したときの出来事。取引先は「データは先頭から順番に読む」というのが絶対的なやり方と思っていたため、ハッシュとは何かを説明して納得してもらわなければならなかった。

これはまだ良いパターンだと思いますが、この逆に、取引先が「ハッシュが速いと聞いたのでハッシュを使ってほしい」と言ってきた場合で、かつ、開発者がハッシュを使いたくない場合に、とくに困ります。
また、どちらのパターンにしろ、取引先主導で、仕様ではなく実装を指示されるということが、もう、まずい予感が漂っています。もっとも、取引先が「○○という実装を使え」と指示する(そうすると○○が使えないことを証明しなければいけなくなる)よりは、「○○という実装使う理由を説明しろ」と言うほうがまだマシといえばマシですね。
実装を指定されるからには、それは実装ではなく仕様に昇格している、という認識を相互に持つべきでしょう。

引用:
xhikkoさんの書き込み (2008-01-06 18:04) より: 取引先はプログラミングしません。また技術も持ち合わせていないように思えます。こういう状況で内部設計も取引先に承認をもらう意味はありますか？

取引先が指定してきた実装を使ってうまくいかなかくても、開発側は責任は持てない、という意味での承認はもらったほうが良いでしょう。

unibon: ぬし; 会議室デビュー日: 2002/08/22; 投稿数: 1532; お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)

投稿日時: 2008-01-06 20:57

さきほどは、取引先が実装を指定してくる場合も含めて広く書いてしまったのですが、以下は、取引先が説明を求めてくる場合のみについて書きます。

引用:
xhikkoさんの書き込み (2008-01-06 18:04) より: 取引先はプログラミングしません。また技術も持ち合わせていないように思えます。こういう状況で内部設計も取引先に承認をもらう意味はありますか？

設計はあくまでも仕様レベルで承認されるべきです。ハッシュを使う実装を参考資料として説明するのは、悪くはないとは思いますが、「こういう仕様ではおそらくこの実装になる予定です(あくまでも予定です)。この実装の仕組みはこうです(仮にこの実装を使うと仮定しての説明です)。」というべきであり、使う実装を約束してしまうのはまずいでしょう。

Error401: 常連さん; 会議室デビュー日: 2007/03/12; 投稿数: 39

投稿日時: 2008-01-06 20:58

引用:
取引先はプログラミングしません。また技術も持ち合わせていないように思えます。

こういう状況なのに、なぜハッシュに関して説明を求められるような状況になるのか理解できません。

お互いに、成果物の品質を保証するプロセスが抜けてるのではないでしょうか。
また、何を持って「検収」が行われるのかが明確になっていますか？

[ メッセージ編集済み編集者: Error401 編集日時 2008-01-06 21:02 ]

Anthyhime: ぬし; 会議室デビュー日: 2002/09/10; 投稿数: 437

投稿日時: 2008-01-07 07:47

　顧客がそれを望むのであれば、できるだけ詳しく引き継ぎ資料を作成すべきでしょう。
　その分の追加コストを顧客に説明し、請求すればいいだけの話です。
　コストが受け入れられないのであれば、常識的な範囲内での引き継ぎ資料を残せばいいと思います。
　ちなみに個人的にはハッシュについては基本情報処理技術者試験に出てくるあまりにも常識的な話なので、書かなくてもいいと思います。が、私なら、顧客を否定しないようにその旨を説明した上で、顧客がハッシュの設計書を望むのであれば、作ってしまいます。

xhikko: 会議室デビュー日: 2008/01/02; 投稿数: 10

投稿日時: 2008-01-08 20:10

取引先が言うには、
説明できない物を作っている＝＝仕事を理解していない
説明できない物を納品してもらっても困る。
そうなので追加料金を請求できる空気ではありません。

取引先事業所では、見える化が柱にありその影響だと思います。

取り上げたハッシュに関しても最初は詳細なフローチャートで渡されました。
頭から舐めて処理、頭から舐めて処理をウン千万回繰り返す処理でした。
なぜこれではだめなのか納得していただけず今に至ります。
ハッシュ値＝＝WINNY（笑）で話が進まず。

基礎理論は一般化されているので参照してください。というと角が立ちそうですかね。

Error401: 常連さん; 会議室デビュー日: 2007/03/12; 投稿数: 39

投稿日時: 2008-01-08 20:59

引用:
取り上げたハッシュに関しても最初は詳細なフローチャートで渡されました。頭から舐めて処理、頭から舐めて処理をウン千万回繰り返す処理でした。なぜこれではだめなのか納得していただけず今に至ります。

そういうことだったら、その通り実装したものと、ハッシュを使ったもののベンチを示して終わりじゃないですか？

1|2 次のページへ»

取引先にどこまで説明すればよいか。

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