スポンサーリンク

◆必ず発生する仕様変更への対策は?

システム開発

◆仕様変更対策
 システム構築において、仕様変更は必ずあると考えたほうが良い。特に、既存の業務プロセスを自働化するレベルではなく、新たに業務設計から始めた、いわゆる業務改革型創造型のシステム構築、デジタルイノベーションでは、実際の仕事に沿ってシステムを動かすリハーサルをやるまでは、想像の域を出ない。これは、どんなモデル化手法を用いても、業務プロセスという目に見えないものを扱う以上しかたのないことである。

 したがって、仕様変更を避けるのではなく、仕様変更をうまくかわすことを考えたほうが良い。「切り結ぶ太刀の下こそ地獄なれ、たんだ踏み込め、そこは極楽」。うまくかわすには、仕様変更から逃げずに、前に一歩出て相手の懐に飛び込んでみれば良い。そして、その仕様変更が、何故出てきたのかをしっかりと聞いてみることだ。

 その結果、ビジョンや要件を実現するために必須の要求事項が漏れていたものか、それとも、あったらいいな程度の改善要望か、はたまた、単なる思い付き・勘違いの類か。必須の機能であれば、盛り込まなくてはならないが、「必須」にもいろいろある。システムとは、前述したように「人間系+機械系」である。機械にできなくても、人間ならうまく生活の知恵を働かせて、問題を解決できる場合もある。

 そもそも、そのような必須の機能で漏れていたというのは、往々にして例外的な処置に対する要求事項であることが多い。そのような例外事項を全て、機械系に「必須」として持ち込んでは、それこそシステムが混迷を極め、何が本流かさえ分からなくなる。「自働化の落とし穴」で述べたように、そういった例外をなんでも、かんでも自働化するのは、かえって人の柔軟性を阻害する。

 さて、仕様変更を識別し優先順位をつけたならば、いつの段階で盛り込むかというのが問題になる。できれば、第一次開発が完了し、運用試験を一巡した後に盛り込むのが良い。開発途中の仕様変更は、開発チームの士気やモラルの低下を招き、コスト・納期・品質、全てに悪影響が出る。あいまいな仕様書で、開発を始めておいて、途中から変更を好き放題に詰め込めばプロジェクトが、どのような状態になるか、システム構築でなくても想像に難しくない。ただでさえ、ソフトウェア開発は超労働集約産業であるから、人のメンタルな面が、製品に現れやすい。

 ただし、変更がマスタ・データベースの重要項目に及ぶような場合は、かならずしも後回しにすることが得策とならないこともある。多くのプログラムで共通的に参照されるマスタ・データベースの重要項目に変更や追加があると、これを後から改修するのは非常に労力がかかる。そのような致命的な仕様変更は、極力避けたいが、万一発生した場合は、その重要度や影響範囲、コスト・納期・品質に対する影響などを判断し、途中で盛り込むことも検討が必要である。

 なお、仕様変更を随時盛り込まないのは、追加請求回避策でもある。好き勝手に仕様変更を要望しておいて、後から多額の追加請求を突きつけられてビックリすることのないようにしたい。仕様変更は、全て案件毎に見積もりを取り、全てを並べてみて費用対効果から優先順位を付け、新たな追加契約を交わすほうが良い。実際に、担当者同士が口頭で仕様変更を随時盛り込んでしまい、後から多額の追加請求を受けると言うケースも少なくない。担当者は、サイフの紐を握っていないので、結構、気楽に仕様変更を要望するものである。

 当初の契約書にも、仕様変更は随時盛り込まず、全て仕様変更管理文書にて、見積もり・合意の上、追加契約あるいは、契約内容・金額の変更を行うとし、これに反した仕様変更は、例え対応しても追加請求には応じないということを明記しておくべきである。さらには、最初から仕様変更のリスクをある程度見込んだ上で、当初の契約金額にxx%を上乗せ契約するか、あるいは、どこまで無償で盛込んでもらえるか確認しておくと良い。自社の開発生産性やプロジェクト管理能力に自身のある業者は、契約金額に応じて、ある程度融通してくれるかもしれない。 

コメント

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