2008_04_21－仕様変更は、減らせるか。

２００８年４月２１日発行

分割ラインです

　《　工程管理編　》

　　
　仕様変更は、減らせる？
　　
　　
　　難しい長い間の課題なのです。
　　　　　設計工程完了後・製造工程完了後、試験工程完了後、
　　　　　　　　変更発生時期はいろいろです。
　　
　　
　　仕様変更は小さいものも含めるとかなり多く発生しています。
　　目に見える建築物とは異なり、システムは
　　　　　知っている人でないと見た目には、わからないものなのです。
　　　　　屋根裏の柱の長さが違っていて応急処置をしたようなものです。
　　これが仕様変更を受け入れている大きな要因なのです。
　　　　当然ながら、処置の仕方によって品質にも影響してきます。
　　
　　
　　
　　
　　オフショア開発や外国のシステム開発においては、
　　　　　　　仕様変更は大きく減少します。
　　　　　　　　　　　　まったく無いことは、ありえませんが。
　　
　　日本は、海外とは異なり仕様変更に対して柔軟に対応しようと努力します。
　　仕事のやり方が大きく異なる点です。
　　
　　
　　
　　
　　仕様変更の原因はいろいろあります。
　　
　　　・お客様との意識の相違
　　　・設計工程完了時点に解決していない先送り事項
　　　・仕様の予算超過又は確定済み予算の減少
　　　・お客様や開発側の政治的理由
　　
　　などです。これを努力する側別に分けると
　　
　　
　　
　　受注者側の努力によるもの
　　　　基礎知識の習得（システム知識／業務知識）
　　　　お客様固有の常識の習得
　　　　機能と予算のすり合わせモレ
　　　　
　　　　知識不足は、
　　　　　　お客様に「何回同じこと言わせるの。」という
　　　　　　　　ジレンマに陥いらさせるのです。
　　
　　
　　発注者側の努力によるもの
　　　　意思決定の遅れによる手戻り
　　　　仕様の伝えモレ
　　　　予算の減少
　　
　　　レビューにおける意識のズレは、文書のみによるレビューを
　　　もっと五感に訴えるように変更する余地があると思っています。
　　　もっとも予算との兼ね合いにもなりますが。
　　
　　　スパイラル開発方式による
　　　　　サンプル開発の繰り返しレビューも一つです。
　　　（但し、全ての場合に有効ではありません）
　　
　　
　　双方の努力によるもの
　　　　政治的理由のよる変更
　　
　　
　　
　　
　　仕様確認レビュー時における、双方の忘れが最も多いようですが。
　　
　　仕様書に記述してあれば故障扱い、
　　　　　　記述していなければ仕様変更扱い。　なんて単純に分けらません。
　　
　　そこには「記述していなくても常識でしょ」と
　　　　　　　　　　　　　　　力関係が働いて変更扱いになります。
　　よほど、大きな変更工数でない限り。
　　
　　
　　
　　むしろ減る傾向にはないように思えます。
　　　　　　時代の変化が早く、開発している間にも変わっていくからです。
　　
　　
　　
　　仕様変更を減らすのではなく、
　　　　　仕様変更を積極的に受け入れる方向にあるように思えます。
　　最終成果物に海外にはない行き届いた気配りがあり、
　　　　　　　　海外との競争格差になっているのも事実なんです。
　　
　　
　　
　　仕様変更が受け入れやすい仕組み作りが、
　　　　　　今後、ますます密接になる世界との競争に
　　　　　　　　　　勝っていく一つの要素になると考えます。