ＷＥＢシステムの不具合修正などの無償保守期間の長さ

IT化支援ラボ 濱田です。こんにちは。

軸さんの仰るとおり問題になる点は「?不具合対応」「?仕様との違い」
の２点ですね。

?不具合の対応については、本来は瑕疵対応(無料保守)可能期間を
設定し、双方合意の上で開発契約を結ばなければなりませんがこの点は
如何でしょうか？(一般的に1年が多いですが、2百万円規模ですと
半年も有り得ます)

経緯や現場を見ない限り判断できないのですが、話しが行き詰って
しまっているようでしたら、保守対象に優先順位をつけ相談しながら
要求する形が良いかと思います。
要求にメリハリをつけることで合意を頂ける可能性が高くなり
ます。その際に優先度の低いものもリストには加えておいて下さい。

?仕様の認識違いについてはグレーゾーンが多く必ず問題になる
ところです。こちらも泥沼化しそうでしたら早めに優先順位を
つけ相談する形を取ってみて下さい。


また保守金額についてですが、相当な仕様変更を予想しない限り
一年で開発費の50%は高額だと思います。
業者様の言う「保守契約」には恐らく「仕様変更」も想定されて
いるのだと思います。

今後保守契約をご検討の際には、「具合対応」と「仕様変更」を
切り離して見積りを請求してみて下さい。
?不具合対応は期間を決めた定額制にするか、スポット対応
(都度支払)にするかがありますが、開発側の体制により何れかは
不可能な場合もあります。

?仕様変更については開発の延長ですので、定額は無く変更内容に
応じた人工計算が一般的です。


本題とずれますが納品前の検収(仕様書と見比べながらのチェック)は
甘くなりがちですので次回からの重要点としてください(詳細な要求仕様書
の作成が前提となりますが)。

http://labo.itsl.jp/

アトラスの高橋と申します。

瑕疵とは、隠れた不具合のことで、これを修正する期間を瑕疵担保期間といいますが、官公庁の場合、通常１年と契約で定めるケースが大半です。
無期限にわたって保証することは、フェアな契約ではないというのが、通産省や情報処理の振興協会が出しているガイドラインです
尚、官公庁が１年なのは、１年あれば、不具合が全て洗い出せているだろうとの判断からの慣習だと思います。

仕様書の読み違えですが、民事裁判になった際は、これを不具合と見なし瑕疵担保で保証するかどうかは、厳しい話になるかと思います。結局、仕様書がどちらにでもとれる書き方であれば、言った言わないの議論にしかなりません。

一般的には、検収期間を定めます。２週間なら２週間で、すべての機能を試して下さい。受け入れ試験をやって下さいという期間です。規模によっては１ヶ月をとります。

業者の仕事の進め方、説明に問題があったと考えます。
プロジェクトは、発注、受注側の双方で、役割と責任を明確にしたうえで、協力して進めるものだと思いますが、そのあたりをアイマイにしたまま走った悪例であるように思えます。

保守契約の値段のつけたかは、たしかに相場では考えられない金額です。
考えられるのは、
１）取引が切れてもヨイと思っての値段のつけ方
２）仕様解釈違いへのここ半年の実績からの算出

さて、現実に今後どうしたらよいかということですが、その業者とは、かなりこじれているように思えます。現状、現システムを確認しないと、なんとも言えませんが、今後のことを考えて、他社への依頼も検討の価値はあろうかと思います。

有限会社アスタウンディングの田苗と申します。

納入にあたり、以下のような流れで試験と保証を行うことが多いです。
業者側試験→発注者側受入試験→検収→保証期間
業者側で納品が終わったときに、受け入れ試験はなされましたでしょうか？ここで、受け
入れ試験を行っていないと「受け入れたじゃないか」と水掛け論になることがあります。

大部分の場合、受け入れ試験で大小の不具合・認識違いが見つかり修正を行います。
それでも、見つからないような、あるパタンでないと出現しない障害の場合は、瑕疵期間（または保証期間）に発生したら、修正を行います。
瑕疵期間が過ぎたものは、「改修」という考えになっていると思います。

業者側の保守費用は確かに高額と思われます。
現段階で出来ます助言としましては、
１ 御社内でシステムの不具合を洗い出す
２ 不具合が設計書に書かれている挙動と異なる挙動であるかどうか、項目ごとに確認してください。
（設計書であいまいである場合は、双方の責任と思ってください）
３ 開発会社様と、上記で挙げた不具合について、どちらに責任があるものかを、対面で確認してください。
４ 根本的な対応を行うといくらでどれだけの期間かかるか、確認してください。
場合によっては、保守価格が安価になるかもしれません。
その際、瑕疵期間の確認も行ってください。
５ そこで、新たに発注して修正するか、どうか決めてください。
６ 修正してもらったら検収前に御社内で確認してください。問題がなければ、そこで検収完了してください。
７ その後は、開発会社に新たに保守契約について検討するか、ソースコードを入手して別会社に委託するかを検討してください。

長々と書かせていただきましたが、完了後、単発的に問題修正していてもいいことはあり
ません。
まずは御社内で不具合の一覧を挙げる作業が先決かと思います。

ITコンサルタントの五十嵐です。
今回お悩みを解決できる可能性があるキーワードとして、「瑕疵担保」というモノがありますが、ご存知でしょうか?
すでにご存知だったの場合は、ご容赦下さい。

「瑕疵担保」とは主に契約書上に記載されており、瑕疵担保期間(例:検収後6ヶ月間)を設定するモノです。これがちゃんと締結されていれば、その間の瑕疵(欠点/不具合)はその期間は保証される事になります。
従って、その期間内は、基本的に開発会社の負担で修正しなければなりません。

ただし、仕様か?不具合か?は非常に微妙な問題でございますので、今回のケースが全て不具合にあたるかどうかは分かりませんが、お客様がお困りであれば、瑕疵担保期間内であれば、通常、不具合として開発会社が開発修正すべきだと考えます。

問題解決できず、お困りであれば、再度、ご用命下さい。

大分前のご質問なので、当面の問題には既に決着が付いているかと思います。
私からは、お互いに建設的にやっていくための方法をご提案しますね。

*検収期間と無償瑕疵修正期間は契約で定めます
検収期間と無償瑕疵修正期間は事前の契約で定めておく必要がありましたが、いずれかの契約期間内であっても「これは不具合修正だ」「いや、機能追加/改変だ」という見解の違いでぶつかることがあります。

お互いの主張をし合う限り水掛け論になりますので、早々に「交渉する」という方に頭を切り替えた方が得策です。

*システム改修に関する開発側のコスト
先に、修正に関する開発側の作業をご紹介します。
既に公開したシステムの改修を行う場合、完了するまでには色々なステップを踏む必要があります。

○開発環境を立ち上げ(または保持)
◎開発環境で修正
○修正箇所の動作テスト
○他の箇所に思わぬ不具合が出ていないかのテスト
○本番環境のバックアップ
○本番環境に修正を反映
○本番環境での動作確認

場合により省略するステップもありますが、公開後の修正は、修正自体(◎印)より他の部分の工数の割合が多くなります。

このため、開発側としてはなるべく修正を行う「回数」を減らしたいわけです。

*システム修正要望は「まとめる」「優先順位を付ける」
開発側も不具合対応は工数として見込んでいますが、細かい修正をその都度行っていると、重大な問題が発覚した時に既に見込んだ工数分を消費し切っている場合があり、この場合、どちらに責任があるかはっきりしない部分については「厳しい交渉」となってしまいます。

このため、緊急性の無い修正要望はある程度まとめて優先順位を付けてから修正するようにすれば全体の見通しが良くなりスムースに交渉が進みます。

また、交渉の時に客観的な材料とするため、仕様に関する打合せは電話などによらずに文書にしてもらって確認するか、最低限、メールでの記録は残すようにして下さい。