仕様変更の発生パターン、あるいは発注者と請負者の責任分界点について
プログラマー、SEであれば、「仕様変更」という言葉には嫌な思い出しかないはずだ。
自分がプログラマーなら、一回作ったものを「仕様変更になったので、作り直して」と言われるのは嫌なものだ。
しかも1回だけならまだしも、やばいプロジェクトに配属されると、何度も何度も変更が入る。賽の河原ってありますよね。石を積み上げても積み上げても、鬼が崩してしまい、最初からやり直しになる地獄。アレと全く同じことがプロジェクトでも起こりうるのだ。
その気持がわかるので、仕様変更を言い渡す側ももちろん気が滅入る。しょうがないんだ。別にオレのワガママでコロコロ仕様を変えている訳じゃないんだ。分かってくれ・・。
仕様変更は気分が悪いだけではなく、お金の問題が絡むのでさらに厄介だ。プログラマーからすると、直すのはいいけど、修正にかかった工数分だけ、お金がもらえるのか心配だ。仕様変更を言い渡す側からすると、もう予算枠に余裕はないので、あまりお金は払いたくない。それにほんのちょっと変えるだけじゃないか・・。
仕様変更にまつわる、こういった気分の悪さとお金の割り切れなさが、ウォーターフォール型開発からアジャイル的な開発にシフトしていった大きな理由の一つだろう。
僕らケンブリッジはシステムを作る側になる場合もあるし、お客さんの代理としてベンダーに作ってもらう側にもなるのだが、どちらにせよ契約条件を工夫して、仕様変更があるたびに毎回カネの話をしなくて済むようにしている。
そもそも仕様変更とは何か？
システム開発は、最初は漠然とした要求（例えば、顧客情報を管理したい）から、徐々に具体的な要件（請求書送付先住所と納品先住所は異なることがあるので、別々に管理する必要がある）までブレイクダウンしていく工程だが、仕様変更とは「前の工程で決めたことが、後の工程でひっくり返ること」である。
仕様変更が起きてしまう原因はいくつかに分類できるので、この記事ではそれを整理しておこう。
★パターンA：やりたいことが変わる
プロジェクトの最中で顧客の要求が変わることがある。
例えば僕らがGROOVE Xさんとやったプロジェクト。開発中のペット型ロボットを顧客に届け、メンテナンスする業務と、それを支えるシステムを作るプロジェクトだ。
事例記事⇒https://www.ctp.co.jp/case_study/case397/
当然、ロボットができてくるに従い、そしてプロトタイプを市場に見せたときの反応が集まるに連れ、ビジネスモデルの想定は変わっていく。そもそも最初から決まっていないことばかり。
こういうケースでは、システムを作っている最中にやりたいことが変わるのは当たり前だ。
仕様変更上等！
もちろんシステムを作ってくれるベンダーさんたちとも、変更を前提とした契約を結んでいるし、プロジェクトスケジュールも同様。（それでも大きな変更が入ると、最後は気合と根性の世界になってしまうのだが・・）
だが、これは極端なケース。
企業で行うほとんどのプロジェクトでは、実は「やりたいことが変わったので仕様を変えます」の割合はごく少ない。そうではなく、仕様変更は主にそれ以外のパターンが原因で起きている。
なお、このパターンAが起きた時、変更の費用は発注者が負担する。これはほとんど議論の余地がない。家の壁を白く塗った後に施主が「やっぱ赤がいいなー」と言い出したら、塗り直しの費用は、ワガママを言った施主が払いますよね。それと同じだ。
★パターンB：組織合意ができていなかった
担当者が「壁は白く塗ってくれ」と言ったので、白く塗った。それをあとから見た担当者の上司が「いやいや、壁は赤に限るでしょ」と言い出した。そういうケース。
家の例で説明すると馬鹿げているが、システム開発は壁の色より複雑だし、目で確認できないから、頻繁に起こります。
前職でプログラマーをやっていた時、お客さんの担当者が変わったので画面のレイアウトを全部作り直したことがあった。
元の画面だって、「このレイアウトで業務が回るか？使いやすいか？」という観点でプロとしてチェックしていたので、問題はなかったのだ。なのに変更させられたのは、完全に後任の方の趣味だ。
もちろんその分のお金は払ってくれたのでまだマシだが、プログラマーとしては気分が悪い。これも、組織合意ができていなかった例だ。「組織としてこういう仕様にする」ではなく「俺様はこうしたい」だったのだから。
このパターンは、意思決定さえきちんとデザインしてあれば、防げる仕様変更だ。
僕が転職後、「組織として、ちゃぶ台返しが起こらない硬い意思決定をしてもらうべく、ファシリテーションすること」にこだわったのは、やりようがあるからだ。
関連する過去ブログ：https://blogs.itmedia.co.jp/magic/2011/06/2-c62c.html
★パターンC：見落とし、書き漏らし
やりたいことは前から変わっていないのだが、単に前に作ったドキュメントにモレがあり、後からそれを見つけたパターン。これが割合としてはすごく多い。
そして、このパターンの修正費用をどちらが負担するかで、発注者と請負業者（ITベンダー）が揉めることになる。
・発注者がもれなく要件を伝えなかったので、発注者が負担すべき
・この要件は半ば常識であり、伝えなくても実装すべき。改修費用は請負者が負担すべき
・伝えてあれば、元々の見積はもっと高くなった。後から言ってゼロ円になるのは意味不明だ
・そもそもシステムのプロである請負者には、素人である発注者から要件を漏れなく引き出す責任があるはず。それを果たしていないのが悪い・・。
・要件定義書にハンコ押してあるでしょ！
などなど。
僕は両方の立場になるので、どちらの言い分もわかる。こういう議論を延々として責任をなすりつけ合うのは不毛だし、全員で一つのゴールを目指すプロジェクトカルチャーを破壊する。
だから僕はそもそも請負でのシステム開発は好きではなく、準委任での契約をおすすめすることが多い。
せめて、契約を結ぶ前に両者でこの手の見落としは絶対にあることを確認し、対応用のバッファ予算や協議方法を決めておくべきだ。
本質的に双方に責任があるものなので、落とし所は痛み分けにならざるを得ない。
「契約後は絶対に費用を膨らませたくない！」と発注者がこだわる場合は、請負者の方で盛大にバッファを積むことになる。
★パターンD：そこまで詳細に元々書くつもりなかった
これはパターンCの変形なのだが、こちらもCと同じくらいは多い。
例えば「顧客情報を登録する」という要件だけがあらかじめ合意されている場合。
「新規登録する時に、同じ顧客名の顧客情報が既に登録されていたら、警告を出す」というニーズがあるとする。
設計段階でこれが発覚した場合、
・うっかり忘れて漏らしていた
or
・要求定義は元々そこまで詳細なニーズを書くためのドキュメントではなく、このタイミングでニーズを伝えるのは想定通り
など、またまた揉めることになる。
パターンCもパターンDも、ソフトウェアという複雑なものを人間が作る以上、どうしても発生してしまう。だからそれを前提にプロセスを組み立て、契約を結ぶべきだ。
僕が大事にしているのは、この手の詳細要件を網羅的に検討するための資料（キーチャートと呼んでいる）を要求定義の後に作成し、業務担当者とITエンジニアが共同で要件定義をする方法だ。
この手の仕様変更はゼロにはできない。だがやり方しだいで極小化はできる。
それにはかなりのスキルが必要だが、逆に言うと適切なキーチャートを活用すれば、アジャイル的に試行錯誤するよりもずっと効率がよく緻密な要件定義は出来る。
これについては随分前にブログに書いた。
業務と要件のミッシングリンク、あるいは仕様変更が永遠に繰り返される訳
仕様変更に苦しんでいる人は、ぜひこの記事を読んで欲しい。文章のなかで「業務パターン」と呼んでいる表こそが、パターンCやDのモレを防ぐための決定打になる。
★パターンE：仕方ないヤツ
パッケージの設定を進めていくと、以前決めたことを改めるべき瞬間がやってくる。以前のようにすべて手作りでシステムを作っていた場合は、このパターンEは起こらない。
分かりづらいだろうから、人事システムを例に説明しよう。
・最初に人事マスターを決定する
・人事マスターに基づいて、他システムとのインターフェースプログラムの開発に着手
・同様に、給与計算の設計を進める
・給与計算の設計上、人事マスターに項目を追加すべきことが分かる
（例えば、家族と別居しているか否かを判定するフラグが必要！など）
・人事マスターが変更されたので、インターフェースプログラムの改修が必要
（インターフェース担当者にとっては仕様変更となる）
みたいなケースだ。
よくやっている人は同意してくれると思うのだが、パッケージを使った開発って、要求・要件をブレイクダウンしていく作業ではなく、業務とパッケージをすり合わせていく作業だ。
・今まで手で対処していた別居手当を自動化したい。
・人事マスターにフラグさえ持てば自動化できて、ミスが減るし楽になる。
・ではそうしよう！
みたいなことを、開発に着する前に全部見通しておくのはほぼ不可能だ。業務をどこまで変えられるか？業務効率化にどこまでチャレンジするか？は、やりながらの手探りの部分が大きいから。
こういった経緯で発生する仕様変更は、パターンAの「やりたいことが変わる」とも少し違う。業務担当者は「なるべく自動化して」という漠然とした要望があるし、それは一切かわっていないのだから。
これは誰のせいでもない。仕様変更がいやだからといって、せっかく自動化できるのをやらずに、手作業が残り続けるのもバカバカしい。（でも、そうしちゃうITエンジニアが多いんですよね。仕様変更が嫌すぎて）
これも特効薬はない。
身も蓋もない言い方すると、すり合わせであるパッケージ開発と、ウォーターフォール的に「前のフェーズで決めたことが絶対」という考え方はとことん相性が悪い。
なのにウォーターフォールでパッケージ開発をやろうとする企業（ITベンダーはもちろん、発注企業側もそう）が多すぎる。それだと、「パッケージの良さをとことん活かして・・」とはならなず、ここに書いたパターンEのような仕様変更が続発する。
こういう「設定していくなかで、良い使い方が分かった」を悪だとみなす、プロジェクトのススメ方がイケてないことにみんな気づいているだろうから、そろそろ行動も変えようよ・・。
以上、仕様変更が発生する原因をパターン化してみた。
どのパターンなのかによって、仕様変更に対応する費用を誰が負担するのかは変わってくる。事前にこれらを両者で整理しておくことをおすすめしたい。
*********関係記事*********
要件定義は誰の責任か？あるいはプロとアマの分岐点
https://blogs.itmedia.co.jp/magic/2013/01/post-82b7.html