Webデザイナーや、HTMLコーダー、フロントエンドエンジニアによくありがちなのが、

という悩みだ。
今回は、個人的な経験、事例をもとにその背景と対策についてお伝えする。

一向に減らない「手戻り」

エンジニアやデザイナーなら、一度は経験したことがある「手戻り」
手を動かす職種、特にエンジニアからすれば、想定外のコストが発生することになり、あまり歓迎できないのが正直なところである。
ところが、実際の現場に行くと、顧客からの要望によりしばしば「手戻り」といわれるデザインの変更や仕様変更が発生する。
その原因は、どこにあるのだろうか？

「手戻り」が発生する原因

「手戻り」は、主に以下の様な要因で発生することが多い。

顧客を取り巻くビジネス環境の変化

システム開発を長年やっていると、しばしばこの問題にぶつかることがある。
システム開発は、最低でも２－３か月。長い時は1年近く開発を続けることがある。
ところが、発注時に定めた要件定義の時と、現時点におけるビジネス環境（求められるビジネスモデル、競合等）が大きく変わってしまっていることが多い。
そのため、発注したときの仕様では顧客側で使えないと判断した場合、顧客としては仕様変更をお願いせざるを得ないのだ。

顧客と発注先（エンジニア、デザイナー）の間で発生するコミュニケーションミス

次に考えられるのが、顧客側から発注先へ仕様を伝え忘れたり、発注先がヒアリングできていなかったりするような場合だ。
顧客や発注先はも人間である以上、当然仕様の伝達漏れやコミュニケーションミスが発生することが大いにある。
寧ろ、ないケースは珍しいかもしれない。

発注先（エンジニア、デザイナー）都合のデザインや仕様変更

最後に、発注先都合でデザインや仕様変更が発生する場合だ。
デザイナーだとあまり考えられないが、システム開発だと大いにありうる話だ。
例えば、当初想定していたクライアントOSのサポートが突然打ち切られたり、想定していたサーバーやネットワーク環境が使えなかったりする場合だ。
特にプログラミングは、開発環境と本番環境の差異が発生してしまうと動作確認した際に本番環境だと動かなくなってしまうケースもあるので、このようなケースが全くないとは言い切れない。

「手戻り」を減らすための対策

では、手戻りを減らすためにはどうすればよいのだろうか？主に、以下の対策が考えられる。

開発スコープ（範囲）やデザイン作成ボリュームをできるだけ細分化する

一番重要な対策が、このスコープ分割だ。特に開発現場においてはほぼ必須といってもいい対策である。
極論を言えば、開発スコープをできるだけ細かくし、１機能ごとにリリースして顧客に使ってもらうくらいがちょうどいい。
そのほうが、顧客のビジネスの成長や変化に応じて、要件定義を繰り返しながら開発を継続することができる。
いわゆるアジャイル型の開発モデルだ。

完成形のイメージを顧客と発注先の間で詳細まで認識し、仕様変更には別途費用と時間が発生する旨を予め伝えておく

次に、比較的お勧めなのが、ドキュメントだけではなく、ワイヤーフレームやモックアップを用いて、デザインやシステムの完成形を見積時にあわせて共有する方法だ。
顧客も実物を元に機能やデザインの確認ができるので、設計書や要件定義書ベースのレビューと比べて、確認ミスが起こりずらい。
加えて、完成形から変更があった場合は、別途費用と時間が発生することを発注前に伝えておけば、仕様変更時の費用要求等でトラブルことは少ない。
ただし、コミュニケーションミスは減らせても、顧客を取り巻くビジネスの変化には対応できないので、スコープの細分化と併用するほうが望ましい。

（非推奨）顧客が理解できる仕様書をしっかり書く

最後に、あまりお勧めできないのが、ドキュメントの充実を対策とする場合だ。
さらに言えば、

といった抽象的な対策案だ。
ドキュメント充実系は、真の意味で顧客目線とはいいがたい。どちらかというと、顧客から自社を守るためのアリバイ作りに近い。
その時は、発注先の利益になるかもしれないが、顧客側からすればほとんど読まないドキュメントの読み合わせをされて、その時はわかったつもりになってしまう。
ところが、いざ納品された際に、

といわれるのがオチだ。
本当に顧客に喜ばれるシステム開発やデザイン作成を目指すならば、自分を守るための中間生成物に力を注ぐのではなく、仕様変更が発生しても顧客が喜んでお金を出してくれるような関係の構築を目指すべきだろう。