仕様変更を管理する | NORE（ノア：ノー・リタイアメント）

💡 要求そのものが変わったり、業務の実態に適応させるために仕様変更は発生します。そのとき、仕様変更をきちんと管理して、なぜ・どう変わったのかを記録することは大事な仕事です。

仕様変更とは、もともと「こういう動作にしよう」と決めていたものをある理由によって変更しなければならなくなることを言います。

ところが、仕様変更をきちんと管理して関係者に共有しておかないと、例えば次のような問題が起こりえます。

仕様変更を例えばメールや会議などで連絡しても、周知されないことも発生します。

特に開発途中の場合、あとでまた変わるでしょ」と思われてあまり真剣に受け取られなかったりすることもあるからです。

テストを担当する人から見れば、「どのバージョンからその仕様変更がされたか」ということも大事になります。

ですから、後できちんと追跡できるように、開発チームとして仕様変更をきちんと管理し、履歴を残しておくことはとても重要な仕事になります。

そもそも仕様変更はどうして起きてしまうのでしょうか？

ありがちなのが、要求そのものが変わったり、あっちとこっちで仕様の矛盾が発覚したり、いざできあがってみると使い勝手が悪かったりということを解消するために起こります。

要求の変更とは、「こういう風にしてほしい」と要望を出した側が変更することです。

開発に入って仕様を詳細にするために話を聞いていくと、そもそも考えていたことに間違いがあることに気づき、そのまま作っても問題があるので、要求を変更することになった。
納期に間に合わないなどの理由で、影響のない部分の仕様を初期段階ではカットしようと考え、それに伴い仕様が変更なった。

などがあります。

仕様の矛盾とは、

というような場合に起こります。

他にも、

などもあります。

仕様変更しよう！と要求されたときに、「はいわかりました」と安易に引き受けてはいけません。

あなたがプロジェクトマネージャーやチームリーダーであればなおさらです。

というのは、要求というのは常に「ある切り口から見たときに改善したいこと」でありますが、別の局面から見ると、改悪になるようなこともあります。

そういうことは、違う部門で目線が全く異なる人から出ることが多いからです。

例えば、

こういう操作にした方が使いやすい、このような表現がわかりやすい、と思っていたが、全く別の使い方を考えたらかえって使い勝手が悪くなったり、ユーザーに誤解を与えることがわかった
期間短縮しようと機能を落とそうとしたら、かえって修正に時間がかかり納期が遅れる
ユーザーの利便性は上がる機能だが、セキュリティリスクが上がるため情報システム部から反対された

などです。

一面だけしか見ずに仕様変更を判断していたら、後々大きな問題になることもあります。

仕様変更は、当初に仕様を決めたときより重い判断が求められることがあります。

上に書いた例のように、納期に間に合わなくなるとか、セキュリティリスクが新たに発覚するとなると、かえって問題が大きくなるからです。

その割に緊急度が高く、すぐに判断しなければならないことがあるとなおさらです。

開発の側から見れば小さな変更にしか見えないことも、別の立場から見れば大きいものですし、小さな変更と思われるような機能が実装上は大きな変更を伴うこともあります。

そんなことがありますので、仕様変更をするかどうかを考えるときは、関係する部門の人を集めて協議するなど、広い視点で確認することが欠かせません。

そういう多方面の分野の人の目で判断することが確実な商品開発につながります。

仕様変更はいろいろなタイミングで要望されます。

要求するつもりだったが入れ忘れた、仕様の問題点に気づいたなど、仕様変更したい理由はさまざまでしょうが、安易な思いで受け入れた結果、納期が遅れたり、別の問題を生むことがあります。

「このくらいの変更ならたいしたことないだろうし、何とかしてあげたい」

そういう技術者の良心もあって受け入れてしまいがちですが、グッと踏みとどまり広い視点で見ることが大事と思います。