企業の業務系システム開発を担当している人々にとって、発注者や業務担当の仕様変更の要求は悩みの種だと思う。
業務担当者から見れば、IT担当者の作る基本設計書の画面レイアウトや業務フローを見ただけでは、具体的なシステムのイメージが分からず、開発前の段階で、システム要件を固め凍結するのは難しいだろう。
しかし、法的な「請負契約」上は、発注者は開発を委託した相手に、最初に具体的な「要件」を文書で提示する事が義務づけられている。
これを知らないバカな発注者も多いが、公正取引委員会や裁判などに訴えられれば有罪になる行為だ。
また、「要件定義書」は「何を依頼するか」を定義した契約書でもあるため、発注前に凍結する事が必要だ。
仕様変更は法的に見ても「追加依頼」として有償で追加の対価を払い、スケジュール延長をしなければならない行為である。
本来、開発前に「要件定義書」を発注者が書かなければならないのだが、これが出来ない発注者は ITコンサルタントにコンサル契約を結んで貰い、どのようなシステム化を行えば良いか、どんな要件定義書を作成すれば良いか指導提案して貰うのが、正しいシステム発注のやり方である。
SIerの中には営業目的で、要件定義書を無料で書いてあげる業者も多いが、「ただより高いモノは無い」の法則の通り、このケースは後で多くの追加料金を取られるのが常である。
詳しい事は省略するが、安く済む実装方法を選択しないで、高価な実装を選択されたり、あとで過剰なサポート料金を請求されたり、悪意は無くても仕様変更に対応できず、品質が悪くてデバッグに長く時間がかかり余計にコストが掛かったりする。
発注者が正しいシステム発注のやり方で発注しないから、損害が生じるのだ。
自業自得である。
仕様変更が避けられないならアジャイル開発するのが常識
システム開発がどうしても試行錯誤を必要とするなら、アジャイル開発するのが開発の常識である。
アジャイル開発とは、例えば1ヶ月ごとに簡単な要件定義書作成し、動くシステムを納品する。
毎月、簡単な要件定義書作成し、動くシステムを納品することを、繰り返すことにより、発注者が動くシステムを実際に使いながら「試行錯誤」する事ができる開発手法だ。
開発手法は厳格な方法論に基づいて作られており、適当なオリジナル手法などでシステム開発はできない。
失敗するケースは開発手法で、いい加減な計画と管理で開発を進めるから失敗するのがほとんどだ。
そして、そのいい加減な計画を選択しているのが「発注者」や業務担当の「依頼者」なのだ。
アジャイル開発については以前書いたし、検索すればいくらでも出てくるので自分で調べて欲しい。
ウォーターフォールの開発を三回に分ける
しかし、アジャイル開発の場合は「準委任」契約になってしまい、瑕疵担保責任が問えなかったり、開発が細切れになって発注者がコントロールができないケースもあるだろう。
そこで、ウォーターフォールとアジャイル開発の中間的な開発方法がある。
「開発手法」と呼ぶほどではないが、既存のウォーターフォール開発を時系列に三つに分けるのである。
これを暫定的に「ウォーターフォールの三次開発」と呼ぶ。
ウォーターフォール開発は最初に要件定義を凍結しなければ、開発できない。
世の SIer は安易に発注者の要件変更を受け入れるが、これは後で追加案件などが生じたときに、費用を上乗せして回収しているので、発注者は長期的には損をしている。
「ただより高いモノは無い」のだ。
業務の都合で、どうしても最初に要件定義を固定できない。
試行錯誤が必要になるのなら、ウォーターフォール開発を一次開発、二次開発、三次開発の三フェーズに分けて、それぞれ単独の「請負契約」で開発すると良い。
やり方を説明する。
ウォーターフォールの三次開発
仮に一度のウォーターフォール開発で一年かかるシステム開発案件があったとする。
この開発は、一度に開発しないで、重要な機能だけを半分選び要件定義書に記載する。
この時は、最初の時点で明らかになっている要件だけを記載する。
この最初の要件定義書で一次開発を依頼し請負契約する。
最初は時間が掛かるので、六ヶ月の納期契約にする。
受託者は、この六ヶ月間は仕様変更は一切しない。
最初の要件定義書だけに従って一次システムを開発する。
一次開発六ヶ月の開発期間に、発注者は色々不明確な部分が明らかになり、仕様変更が必要だと気がつき始める。
しかし、一次開発六ヶ月間は受託者は仕様変更を受け付けない。
一次開発六ヶ月間は発注者は「仕様変更の要望書」を文書に書き溜め、保存しておく。
これは受託者に見せても良いが、基本的に六ヶ月間は発注者が「仕様変更の要望書」の中身を管理する。
「仕様変更の要望書」は六ヶ月の間に沢山蓄積する。
その内容は発注者側で内容に矛盾がないか常に精査しておく、六ヶ月目に一気に精査しても良いが、随時やった方が楽だと思う。
六ヶ月目に沢山蓄積した「仕様変更の要望書」を元に二次開発の「要件定義書」を作成する。
一次開発六ヶ月が経ち、一次システムが納品される。
受託者は発注者から渡された「二次開発の要件定義書」を元に、二次システムの開発、つまり「一次システムの改造」を行う。
二次システムの開発は、仕様変更と追加案件を、一次システムに反映するだけなので、一次システムの開発ほど時間が掛からない。
二次システムの開発期間は三ヶ月とする。
納期が決まるのは要件定義書を受け取ったあとである。
この二次開発の三ヶ月の間に、再び発注者は仕様変更が必要だと気がつく。
二次開発三ヶ月間は発注者は「仕様変更の要望書」を文書に書き溜め、保存しておく。
一次開発のときと同じだ。
「仕様変更の要望書」は三ヶ月の間に沢山蓄積する。
その内容は発注者側で内容に矛盾がないか常に精査しておく。
三ヶ月目に沢山蓄積した「仕様変更の要望書」を元に三次開発の「要件定義書」を作成する。
二次開発三ヶ月が経ち、二次システムが納品される。
受託者は発注者から渡された「三次開発の要件定義書」を元に、三次システムの開発、つまり「二次システムの改造」を行う。
ここまで来ると「仕様変更の要望書」自体が少なくなる。
三次システムの開発期間は三ヶ月とする。
繰り返すが、納期が決まるのは要件定義書を受け取ったあとである。
三次開発三ヶ月が経ち、三次システムが納品されて最後の納品が完了する。
要するに細かい仕様変更を随時対応すると無駄に計画的に作業が進められなくなり、品質が悪くなったり、計画が遅れたりするので、仕様変更は二回に纏めて行うことで、計画的に開発を進められるようにするということだ。
これだと発注者の側も「仕様変更の要望書」の内容に矛盾が無いか確認する時間が取れる。
矛盾する要望を次々出して開発を破綻させる発注者はとても多い。
ほとんどの発注者が該当する。
発注者が仕様変更の要望を精査するのは重要な仕事だ。
ウォーターフォールの三次開発のメリット
・事実上、仕様変更が無い
受託者側から見ると、ウォーターフォールの三次開発は事実上仕様変更が存在しない。
一次開発中の仕様変更の要望は、二次開発の要件定義になるだけなので、一次開発には影響しない。
二次開発中の仕様変更の要望は、三次開発の要件定義になるだけなので、二次開発には影響しない。
開発フェーズを三回ではなく、四回・五回にしても同じ理屈が成り立つ。
システム開発が遅れたり、品質が悪くなったり、計画が破綻したりする原因はほとんど、発注者による要件変更が無秩序に繰り返し行われる事により起きる。
仕様変更がなくなれば、計画変更も無くなり、品質も納期もコストも安定する。
破綻リスクも減る。
・発注者は要件を変更する事が容易にできる
発注者側から見ると、初めから二次開発と三次開発の二回の時点での仕様変更が最初の計画の段階で、組み込まれている。
「もし仕様変更があったら」という従来のウォーターフォールと違い、仕様変更が計画に含まれている。
それも明確な形で。
「仕様変更の要望書」の矛盾を精査する担当者を置く必要があるが、現場の業務担当者は精査する担当者に仕様変更の要望を送るだけである。
・瑕疵担保責任を要求できる
発注者は受託者にシステムの品質や機能について、瑕疵担保責任を要求できる。
アジャイル開発だと準委任契約になってしまうので、瑕疵担保責任を要求するのが難しい。
仕様変更の回数が多ければ尚更、瑕疵担保責任を要求できないだろう。
ウォーターフォールの三次開発なら、一次・二次・三次開発はそれぞれ請負契約なので、それぞれ独立した瑕疵担保責任を要求できる。
・一次納品から使って試す事ができる
一次システムが六ヶ月後に納品されたら、そのシステムを実際に使って試す事ができる。
品質や機能もゆっくり時間をかけて検収する事ができる。
このメリットは発注者には大きいと思う。
一回のウォーターフォールで開発するのは不可能
経験的に一回のウォーターフォールでシステム開発が成功した例を見たことが無い。
成功するのは、何度が纏まった時間をかけて改修を何度か繰り返すケースだ。
だから、初めから仕様変更と、改修や追加案件を計画しておけば良いのだ。
一回のウォーターフォールで開発するのは、初めから失敗する事を計画しているようなものだと思う。
アジャイル開発を採用できない発注者は、ウォーターフォールの三次開発を試して見て欲しい。
