手戻りコストはかけたくない！・・けど、どこまでだったら変更しても大丈夫？

Webサイト制作の流れとしては大きく分けて５つのフェーズに分けられます。

■各フェーズの説明

各フェーズの概要図はこちら

一般的には、システム開発においての口出し(仕様の変更、追加など)は基本設計が終わるまでと言われています。
フェーズでいうと２ですね。しかし、実際に行われる開発方法によっても若干、差があります。

「仕様は変更するもの」が前提となる開発方法とは？

ウォーターフォール開発とよばれる古典的？でポピュラーな開発方法があります。
これはその名の通り、滝が上から下まで流れ落ちる様に、要求定義(上)からシステムが完成するまで(下)の工程を後戻りする事なく進めていくやり方です。

この方法は、前工程が終わるまで、次の工程には進めません。そして、前の工程が間違っていないという前提で開発を進めます。
そのため、仕様が間違っていたからといって前には戻るのは容易ではないという特徴があります。
実際には、仕様変更は付きものですし、全くミスなしに工程を進めるのは難しいので、後戻りはするものですが、この開発モデルでは出来るだけそんな事にならないようにしよう！後戻りしないようにやろう！という開発方法です。

この開発方法は「発注者からの要求は確定した後は変化しない」という前提があるため、成り立つものです。
しかし最近、特にWebの世界では、ビジネスモデルとしてのシステム開発が行われ、刻一刻ととりまく状況が変わっていく中、柔軟に仕様を変更していく必要が出てきました。

「3日前まではこれで行こう！と思ったけれど、競合が○○したので、仕様を大幅に変更したい。」
といった事が増えてきたのです。

そこで、仕様の変更に柔軟に対応する開発方法が考えられました。

最近では、アジャイルソフトウェア開発などのいわゆる、全部の機能を小さく分割し、ひとつのサイクル(計画、要求分析、設計、実装、テスト、文書化)でひとつの機能を開発する手法もあります。
ビジネス計画が変更されるという事を前提にしているため、変化が激しいシステム開発に向いていると言えます。また、ひとつひとつのサイクルで、テストや要求分析をやるので発注側がシステムを動作確認をする機会も増え、システムに関わる機会が多く持てる開発方法です。

また、実際に出来上がるシステムのデモ版(不完全なモデル)を使って、要件を煮詰めていくソフトウェアプロトタイピングという開発手法もあります。

こういった開発方法を取り入れる事で、仕様の変更にも柔軟に対処できるよう努力はされてきましたが、いずれの場合も、実際にプログラミングが始まる設計段階までに、仕様を凍結しなければ開発には入れません。これ以降に変更・追加を申し出るとコストに跳ね返ります。

発注者側が口出し出来るのは、

第2フェーズの基本設計終了時まで。柔軟に仕様の変更に対応してくれるシステム制作会社でも、第3フェーズのシステム設計終了時まで。実際のプログラミング作業に入る前には必ず仕様を凍結する必要がある。

という事です。

それでもやりたい事は変わる！

しかし、それでも仕様を追加・変更したい時はどうすれば良いでしょうか。
お客様からの貴重なご意見を頂き、ピン！とアイデアが閃いた。スピード勝負のこの世界、これを是非実装したい！なんていう事はあると思います。

そのために、第2フェーズで、「仕様変更に関する取り決め」を行っておきましょう。
具体的には、仕様変更用の予算を予め取っておき、

• 仕様変更が起こったら、制作側が要求を実現する場合のシステム全体への影響度、工数などを調査、文書化。
• 制作側がその文書を元に発注者に説明を行う。発注者が実際に変更を行うかどうか決定。行う場合は承認し、文書にサインする。
• 実際の作業が終わったらその変更部分だけの検収を行い、文書にサインする。

言った言わないを防ぐためにも、こういった対処をしておくと良いかと思います。
ほとんどの場合、追加仕様、変更は起こるものです。事前の対策をお勧めします。

トラックバックURL