◆仕様変更を考慮した契約での注意事項は?

システム開発

◆仕様変更
 契約後に、実際に仕事が始まるとすぐに問題になるのが、この仕様変更である。どんなに最初に要件定義や仕様書に時間を掛けても「業務」という形の無いものを、想定して仕様を決めなければならないのがシステム構築の難しいところである。システム構築は、建築とかなり似たところがあるが、建築の場合、最近では3次元ソフトで、完成した時の家の概観や、内装、実際の内部の動線などを、かなりリアルに事前検証できる。著者も、建売ではなかったが、この3次元ソフトを活用したので、完成後には、ほとんど違和感が無く、思っていたとおりのイメージになった。ところが、システム構築では、こうはいかない。そもそも「業務」というものが、人の思考活動であるので、形としてとらえることができないのである。したがって、いくら要件定義や仕様書作成に時間を掛けても100点をとることは不可能であり、仕様変更は決して無くならない。

 契約においては、仕様変更は必ず発生するものという前提で、業者と十分に調整しておくことが必要である。いざ、仕事が始まってしまうと、自社の担当者と業者の担当者の間で、口頭ベースで仕様変更を指示し、実施されてしまい、後から多額の請求書が出てくるということも少なくない。担当者間では、仕事をスムーズに進めたい、人間関係を良くしたという心理から、なんでも口頭で「よっしゃ、よっしゃ」で進んでしまう。特に、業者側の担当者は、委託先の担当者から頼まれた場合、なかなか断りにくいようだ。委託側である自社の担当者に、コスト意識を持ってもらい、安易に仕様変更を口頭でしないように釘をさしておくことも必要である。どんな契約にせよ、口頭で指示して、費用が発生するとは思わなかったというのは、企業間取引では、法律上でも認められないであろう。具体的には、契約の際に次のような取り決めをしておくと良い。

・仕様変更は、どの段階まで受け入れられるのか。
 その場合、仕様凍結宣言をして関係者に周知する。それ以降の仕様変更は、後でまとめて、追加契約とする。

 仕様変更を依頼する側からすれば、「これくらい大したこと無いだろう」と思い、プログラム製作段階になっても、仕様変更を出したりする。実際、文字の大きさや色など、作業としては大したことがないものもある。しかし、ソフトウェアの開発というのは、人手作業であるので、精神的なものが、生産性や品質への影響が大きい。そうした細かい変更が頻発すれば、当然、士気モチベーションに悪影響がでる。仕様変更を頻発すれば、結局、最後に割をくうのは自分たちであり「天つば」になるということも認識しておくべきであろう。お金さえ払えば、いいだろう、業者は、言うとおりにプログラムを作ればよいといった考えは危険である。業者の士気にも配慮し、生産性や品質を統制するのが、委託側のプロジェクトリーダの責務である。

・仕様変更が、発生した場合には、どのような手順で行うのか。
 原則は、文書にて仕様変更依頼を出し、それに対して、業者側で有償・無償の判断をして有償の場合は、見積りを行い文書にて回答する。その内容を確認し合意を文書にて通知することにより、契約内容を変更し、はじめて作業に着手する。この合意通知前に、作業に着手、完了しても無効とする。

 ただし、仕様変更依頼が随時発生すると、この作業に追われて、本体の作業に支障が出る恐れがあるので、通常は2週間に1回とし、緊急の変更依頼だけを随時対応するというように取り決めておくほうが良い。

 また、業者からの仕様変更に対する回答には、担当者だけで判断するのではなく、納期やコストへの影響を、プロジェクト全体の観点からチェックできるような社内体制やルールを決めておくべきである。担当者は、「良いシステム、使いやすいシステム」を作りたい一心で、仕様変更を依頼することが多い。それは、一概に悪いことではないが、やはり、最小の投資で最大の効果を生むシステムを構築するという観点からは、オーバースペックであり、必要以上の投資となる傾向にもある。

 とかく、仕様変更というのは、担当者の思惑と、本来の目的や要件とが一致しないところで、発生することが少なくない。先に述べたように「無くてはならない機能、あったらいいな機能」をしっかり識別し、それが投資に値するものか、どうかを経営的な観点で判断しなければならない。その上で、担当者に理解し納得させ、やる気を失わないように配慮することも必要である。社内業務システムは、あくまで儲けるための道具であり、それ自体で儲けを生むものではない。必要以上に、「見栄え」や「使いやすさ」にお金を掛けないようにしたい。   

■目次:システム開発する前に知っておくべきこと83項目

コメント

タイトルとURLをコピーしました