仕様変更が起きる原因
SEをやっていると仕様変更等でなかな仕事が進まない時があります。
この仕様変更って本当に嫌ですよね。
せっかく一生懸命仕様どおりに設計してもそれが崩されるのは腹が立ちます。
でもなぜ仕様変更が発生するかその原因ってご存じでしょうか?
仕様変更の発生には色々なパターンがあるかと思いますが、私が経験した中で仕様変更が発生するある1つのパターンがわかりました。
どんなタパーンかというと、まずお客様がシステムを全く理解してない素人の方のパターンです。
お客様がシステムを知らない時の注意点
システムのことを全く知らないお客様は、とりあえず頼めばすぐに修正できると思っています。
この「SEの人であればすぐに修正できる」と思っていることがとてもネックです。
なので、仕様決定の時ほど細かく相手が全て100%理解してもらうことに注力する必要があります。
システムを理解しているお客様であれば、話しが早く進むことがあるでしょう。
しかし、本当にシステムを知らいないお客様はちょっとしたIT用語(サーバ、ドメイン等)のことでも理解できず、ぽかーん・・・としてしまいます。
そうなるともう危険です。
こちらの話を聞いていない可能性があります。
そうすると、お客様はとりあえず仕様から自分のニュアンスが伝わっていれば良しとしてしまうことがあり、十分確認を取らないまま仕様を決定してしまう可能性が有ります。
こうなると設計を確認してもらった時に、「その動きは違うからもう一度やり直して」と言われる可能性が出てきます。
ただ、設計の時であればまだ良いかもしれません。
ほぼほぼプログラムまで構築し単体テストでようやく目に見える動きを確認したところで、「その動きは違うからもう一度やり直して」と仕様変更を余儀なくされるパターンが有ります。
こうなったらもう最悪ですよね・・・
仕様変更を発生させないための方法
仕様変更を発生させないための一つの方法として、問題を明確化させる方法があります。
お客様からの要件定義でお客様が実現させたいシステムでイレギュラーなパターンが発生する箇所がどれだけあるのかを抽出しその問題点を洗い出すのです。
問題さえ出ればもう大丈夫です。
あとはその問題の解決策を出せばOKです。
そしてその問題が起きないように仕様を作っていきます。
なのでイレギュラーパターンを発見しつくし、その解決策を出せば仕様変更というのは基本なくなります。
ただ、この方法は別にシステム開発だけに使える技ではありません。
あなたが興味のある新しい業種にもバッチリ使えます。
問題の洗い出し、そしてその問題に対して解決策を出していく。もし一つの問題に対して3つ以上解決策が出てきたら文句なしです。
その事業は失敗しないでしょう。
もしあなたが異業種に転職したいけどスキルがない・・・
と思っているならば、この問題の洗い出し、そしてその問題に対して解決策を出していく能力を磨いて下さい。
きっと役に立ちます。
コメント