Q&A
契約書等に記載はないのでしょうか？
タグとはまったく関係ない内容です。
自社で開発・納品したシステムの不具合について「瑕疵対応」として、半年や１年の期間対応受付しているのですが、その納入済みシステムに対してユーザー企業内部で機能追加などを行っている場合の対応に苦慮しております。
開発側としては他社で手を入れているプログラムに対しては、不具合・追加拡張などいずれの依頼でも受けたくはありません。が、ユーザーに対してどのように話をしていくべきか悩んでおります。
同様の経験をされている方がいらっしゃれば助言いただきたいです。
納品した時点でのプログラムで確認してパッチ対応でいいんじゃね
「開発側としては」ということですが、営業なり経営者の方はどのように言われているのでしょうか?
teratailで聞くことじゃないと思います。基本的に無責任なので、確かにお人好しな人がしっかりとした回答をつける可能性もあるのですが、然るべきところに相談されるべき内容です。
CHERRYさん > 残念ながらないんです・・・
ockeghemさん > 自分がPM的な立場で、営業は本件には介していないです。経営層も方針を決めかねています・・・
mts10806 > そうですよね。わかってはいるのですが、身近で頼れるところもなくて・・・
あっ書いてないのか・・
相手が有利だな・・・
回答6件
0
ベストアンサー
その納品したバージョンでの事象確認した上での連絡にしてもらえばどうですか。
「企業内部で機能追加」しているならそれなりの部署があるんでしょうから、そこを一時受付にしてもらって、御社にエスカレーションするかどうかは納品したバージョンで確認した上で行ってもらう。
投稿2018/06/02 10:04
総合スコア25206
回答ありがとうございます。確かにそうですね。話が通じるかは別として筋は通ると思いますので、一度その方針は打ち出してみようと思います。
違うソースの確認をしろというのであれば、普通に無理難題を押し付けていると思います。
それでも、一時受付を行ってくれないのであれば、ソースやデータの同期を前提とすることで、相手側のコスト負荷に訴えることでしょうか。
後は、一時受付との２択として、瑕疵担保責任の期間が終了するまではソースの変更はしないこととするか。
そもそも瑕疵とは納入したものに対する責務であり、改修されたものに対してではありませんので、その点を主張すれば良いのではないかと思います。
> 瑕疵とは納入したものに対する責務であり、改修されたものに対してではありません
ですよね。私もその認識なのですが、それが明記されているものってなにかありませんでしょうか？
契約書などには瑕疵担保期間は書かれていますが、それ以上は明示されてない状態です。
法的なもので根拠になるものが無いか、探してみましたが見つけきれませんでした。
仮に根拠はなくとも、先ずは、その点についての合意を明らかにした上で調整しないと、繰り返すことになりかねません。
契約書には、ほぼ”何かあれば協議の上調整する”という文言が記載されていると思いますので、協議すること自体は問題ないと思います。
自分たちで機能追加するということが、新たな発注による費用を発生させたくないということであれば、現状のままの運用とする場合には、「調査の結果が機能追加による影響であった場合には費用請求する」というカードも調整には有効かもしれません。
調べていただきありがとうございます。
でもやはり無いんですかね？ 実は勝手にそう思ってる（誰かから伝え聞いた）だけで根拠のないものなのかも・・・ とも思っています。
まずは「調査の結果が機能追加による影響であった場合には費用請求する」ところまで約束させていただくですかね。
出来れば法律を持ち出してまで出来ません・やれませんという話は避けたいところですので、根気強く話し合いしかないかな・・・
tkandaさんの回答へのコメントを見ましたが、開発で機能追加を行っている状態で、エンドユーザーが機能追加するっていったいどういう状態なんでしょう？
そのような状態なら、現状の機能追加分のリソースを受領したものをベースにするとともに、エンドユーザーの機能追加は止めてもらうのが一番な気がします。
「不具合修正」「機能追加」「ユーザー側での機能追加」この３つが同時平行になりつつあります。
「ユーザー側での機能追加」はまだごく一部なので、修正したソースをこちらで受け取りマージしている状態です。
最終的には全部を自社で面倒みたいようです（それはもちろんよいのですが）。
機能追加は止めてもらいたいのですが、それをお願いするための材料がなにか無いと難しい状態でもあります。
てっきりFIXしたものに対しての機能追加だと思って回答しましたが、状況的にはマネージメントの不備ですね。
ユーザーでのカスタマイズを許すなら、機能追加の全貌がはっきりしていて、他の機能に影響がない部分に限定すべきです。
ただそれすら、どんな変更になるかをレビューしないかぎり影響が無いとは言い切れません。
基本的に、開発中の「ユーザー側での機能追加」を許すべきではないと思います。
それをお願いする理由は明らかで、探す必要があるとは思えません。
ユーザー側での機能追加の責任はどうなっているのでしょう?
その検証コストは考慮されている? のでしょうか。
あー。。。
> 「ユーザー側での機能追加」はまだごく一部なので、修正したソースをこちらで受け取りマージしている状態です。
もう事実上、対応しますていってしまったあとのきがするな
> てっきりFIXしたものに対しての機能追加だと思って回答しましたが、状況的にはマネージメントの不備ですね。
おっしゃるとおりですね。前任がどうしようも無い状況を生み出し、本来入るはずじゃなかった経営層の人間が現場までおりて収集に務め、多少は落ち着いた状態になったところで私が引き継ぎました（なので私は三代目PM）
細かな対応が優先で、基本設計レベルの情報すら未だ把握出来ない状態です・・・
> ユーザーでのカスタマイズを許すなら、機能追加の全貌がはっきりしていて、他の機能に影響がない部分に限定すべきです。
まずは、そこを落とし所にして話を持って行こうと思います
> ユーザー側での機能追加の責任はどうなっているのでしょう?
どうにもなってません。無法地帯ですね。
> その検証コストは考慮されている? のでしょうか。
残念ながら考慮されていません。現在はごく限定的な範囲なので特に問題視されていませんが、確実に負荷となる部分ですのでなんとかしたいところです。
0
感情を排除して考えると、考慮すべき項目は2点です。
・法的な瑕疵の解釈に従って、瑕疵なのかどうか？
・経営的判断として、顧客要求に従うか、突っぱねるか。
どちらにしても、事実確認を正しく行い、交渉前に落とし所を想定し、関係者と内部的に足並みを揃えておかないと、まともな決着はできないです。
逆に言うと、事実確認が正しく行われ、方向性がきちんと共有されていれば、それほど難しいケースではないです。
まぁ、事実確認は検証不能の言った言わない闘争があるし、実務としては感情も入ってくるので、方向性の共有のハードルが結構高くなるのも現実ですけどｗ
投稿2018/06/03 05:11
退会済みユーザー
総合スコア0
0
とりあえずはその思ってることを相手に伝え、
元のコードに修正を加えたものを納品する、とか、有償対応にする、と言う方向で話をする、でしょうかねえ
＃そんでもたいてい泣く泣く瑕疵対応させられるということに
投稿2018/06/02 08:30
総合スコア87784
んだね・・・ LIMIT取得 できないような 簡易開発ソフトウェア基盤で制限できないなら1件ずつ取れとかいうファッティのもいることだし
私怨？
0
１．前任者がなぁなぁで、納品先のカスタマイズ分もマージしたものを再度納品している。
２．瑕疵対応の記載は期間のみの記載である
ことからかんがえるに
契約更新時に営業等を巻き込んで契約書に何らかの追記する必要があるでしょう
今契約時は「いままでは～」で押し通されるだけですね。
なので今期またはその客先はあきらめて前任者通りの対応をしてください。
投稿2018/06/03 09:07
退会済みユーザー
総合スコア0
0
saziさんと同じですが納品したバージョン（客先で改変される前のオリジナル版）で同様の現象が発生するかどうかが問題切り分けの目安になると思います。
客先へは不具合を指摘する前に納品版でも動作確認してもらえるように交渉するのが一般的じゃないでしょうか。
ご参考になれば。
投稿2018/06/02 12:36
総合スコア2425
回答ありがとうございます。おっしゃるとおりですね。
ただ、現実問題として残念ながら納品物の品質が悪く、あきらかな不具合対応が多発しておりその対応に追われている状態です。
そのほか、追加機能の開発を細切れで行っていることもあり（こちらはもちろん費用はいただいてます）、納品したバージョンが都度新しくなっていってます。
さらに外部連携も多く、事象の再現には手間がかかるためきちんとした検証環境を用意する（人や時間的な）コストが捻出できない状態です。
0
残念ながら同様の経験をされている方とは、出会えませんでしたが現状できる範囲で少しずつ落としどころを見つけて行こうと思います。
みなさま、回答・コメントありがとうございました。
また、この件に関連してもうひとつ気になるところがあるので改めて質問させていただこうと思います。
投稿2018/06/03 11:03
総合スコア81
契約条項失敗案件なんて 当事者は恥だから出さないと思うよ
あと守秘義務違反にかかる可能性があるので
あなたの回答
tips
プレビュー
