仕様変更を受け入れる話

先日某所で行われた合宿勉強会で盛り上がったネタを整理してみるものです。

さて、ここで言う仕様変更とはITシステムの開発期間における「仕様(設計)の変更(修正)」の事を指しています。
一般的には仕様変更が発生すると、手戻り作業が発生し、スケジュールやコストが変化します。というわけで、ITシステム開発では忌み嫌われるのが普通ではないでしょうか。
(このへんのニュアンスが分かりにくければ、404 Blog Not Found : 惰訳 - 建築士がプログラマーのごとく働かねばならぬとしたら をご覧になることをお勧めします。全プログラマーが泣いた。私も泣いた。)

特に日本では多いウォーターフォール型の開発では、中盤から終盤にかけてこの「仕様変更」の扱いが非常に重要な問題となっています。特に日本型開発ではシステム開発プロジェクトの序盤で予算が確定(固定)しており、話がややこしくなります。

立場別に、言いたい事を整理してみます。

• ユーザ / 発注者
• 今の設計(仕様)では使えない。使いにくい。IT化の効果がでない。
• その設計(仕様)は誤っている。誤りの原因は開発者側にある。修正してもらわないと困る。
• その設計(仕様)は誤っている。当初レビューした時には気づかなかったけれど、我々はシステム開発のプロフェッショナルではない。あなた方が気づくべき誤りなんだから、修正してもらわないと困る。
  
• 新しいアイデアを思いついた。簡単な変更なので取り込んで、よりよいシステムにしたい。
• 追加のコストや、スケジュールの変更は受け入れたくない。
  
• 開発者 / 受注者
• 設計(仕様)を新しく追加するのであれば、期間もコストもいただかないと出来ない。
  
• これは設計(仕様)の誤りかもしれないが、きちんとレビューも実施したし、誤りの責任は開発者だけではなく、ユーザにある。
• 変更は、見かけより大きな影響を引き起こす。とても予定コストとスケジュール内ではおさまらない。
• 新たな機能を追加するにしても、まずは現在開発しているプロジェクトを完了させて、そこに機能を追加しなければ全体が台無しになるリスクがある。

書いているだけでも悲しくなるくらい、ネガティブな内容が並んでしまいます。
まぁ、実際にはここまで酷くはないかもしれませんが、全体的に仕様変更は悪という雰囲気であることは確かです。

この仕様変更の問題対策としては、そもそもの開発方法を見直して「アジャイル開発」を取り入れるという方法があります。しかし、実際にはこれまでの作業の進め方を大きく見直さなければいけないことも多い為、なかなか定着しない/適用に踏み切れないのが実状です。

ところで、そもそも「仕様変更は悪」というのは本当なのでしょうか？

• 設計(仕様)決定時点では発見できなかった誤りを、カットオーバー前に発見できた！
• システムの価値を、格段に向上させるアイデアを新たに発明した！

と考えれば、むしろ仕様変更は宝である可能性もあります。実際に、仕様変更によって引き起こされるスケジュールやコストの問題が全てクリアされれば、その瞬間にネガティブがポジティブに大きく変換される。Negative Changing から Positive Changingへ。
というわけで、このネガポジ変換を実現するために、こんな戦略を考えてみました。

『仕様変更は全部受け入れる戦略』(Accept All Specification Changes Strategy : AASCS)

• 基本戦略
• 仕様変更は無制限に受け入れる。バグと区別はしない。
• 「このプロジェクトでは仕様変更を無制限に受け入れます」と宣言する。
• 仕様変更をやる、やらないの議論を禁止する。
  
• むしろ、仕様変更は喜びである。もっと仕様変更をしてほしいと思う(ただし、無意味な変更は除く)
• 対スケジュール戦術
• それが仕様変更なのか、バグなのかといった議論を一切しない。交渉スケジュールを短縮できる。
• 仕様変更によって引き起こされる作業の一部を、ユーザ(発注者)と共有する。
• 設計書の修正
• 結合テスト・受入テストのやり直し (極端な話、ユーザサイドで実施してもらう)
• 仕様変更によって引き起こされる作業の一部を、軽減する。
• 最低限のドキュメント以外の修正をやめさせてもらう。(ただし、出来る限りやったほうがよい)
  
• 単体テストのレベル(カバレッジ)を下げる。結合テスト/受入テストで担保する。(ただし、出来る限りやったほうがよい)
• 対コスト戦術
• それが仕様変更なのか、バグなのかといった議論を一切しない。交渉コストをゼロにする。
• 効果
• 仕様変更によって、ユーザと開発者双方のシステムへの理解度が上がることにより、品質が上がる。
• 仕様変更への後ろめたさが無くなり、ユーザが積極的に「使えるシステム」について考えるようになる。
• 仕様変更への後ろめたさが無くなり、開発者も仕様変更を提言できるようになる。「イケてるシステム」を作ることに参加できる。
• 発注者 vs 受注者、ユーザ vs 開発者ではなく、問題 vs 私たち になる。
• こんな気持ち
• すがすがしい。仕様変更に関連するネガティブなコミュニケーションはしなくてよいので、ストレスが減る。
• システムを開発することに集中できる。

こういうやり方も、アリだと思う今日この頃です。

Blogged with Flock