要件定義や設計を行うのは、人間ですから、間違いや漏れがあるのは、当然です。そのため、仕様変更というのは、必要なプロセスです。しかし、多くのITプロジェクトで、仕様変更の発生がなかなか止まらずに、期間が延びたり、コストが増大する場面をよく見かけます。

仕様変更の判定会を設けることは、数十年前から、重要だと言われています。そのため、仕様変更を抑制するための教科書はたくさんあります。しかし、有効に機能していないというのが、現状ではないでしょうか。今回は、なぜ有効に機能しないのか、どうすれば、機能させられるのかについて、お話していきます。

---

仕様変更の実施可否を判断する理由

ウォーターフォールでITプロジェクトを進める場合、要件定義で作成した要件定義書をもとに、後続の設計を。設計で作成した設計書をもとに、後続の開発を行います。そのため、設計中に、参照している要件定義書が変更になったり、開発中に、参照している設計書が変更になると、やり直しや修正作業が発生してしまいます。

もちろん、要件定義中や設計中に、気付けなかったこともありますので、途中での変更ができないと困ります。しかし、あれもこれも変更になってしまうと、現場は混乱してしまいます。加えて、やり直しや修正作業が多発すると、コスト的にも悪い影響が出てきます。

そのため、仕様変更を実施しても良いかどうか、都度、判断をするようにしているのです。

---

一般的な仕様変更判定会議が、機能しない理由

下記は、一般的な仕様変更判定会議のガイドラインです。

ユーザビリティの向上に関するものは、優先順位が低く、基本的には認められないことになっています。加えて、費用対効果も確認して、追加改修に掛かる工数を投下するだけのリターンが得られるのかも確認することになっています。

一見、よく考えられたガイドラインのように見えます。実際に、多くのプロジェクトで、似たようなガイドラインを設けています。そして、仕様変更判定会にて、仕様変更の申請者が、資料を準備して説明しています。

しかし、仕様変更判定会議が有名無実化して、申請された仕様変更のほとんどが承認されてしまうプロジェクトが少なからずあるのが現実です。なぜか。

「その機能が無いと、業務が回らない」と押し切られてしまう

この現象は、IT主導で進んでいるプロジェクトでは、より頻繁に見られます。業務の現場に関して、仕様変更の申請者ほどには、情報を持っていませんので、「業務が回らない」と言われてしまうと、それ以上に強く言えなくなってしまうのです。

では、どうするか。

---

業務側のマネジメントを巻き込む

ひとつの有効な方法は、仕様変更の判断者に、業務側のマネジメントを巻き込むことです。

IT主導でプロジェクトが進んでいる場合、仕様変更の判断では、以下の構図になっていることが多いです。

業務マネジメントが、申請者側に立ってしまう場合

先ほどお話したように、IT側のマネジメントは、ただでさえ、業務メンバが言う「これがないと、業務が回りません」という言葉に、なかなか反論できません。そのうえ、業務側のマネジメントは、プロジェクト側の立場に立ってくれていないことがあります。場合によっては、仕様変更する側の立場に立って、仕様変更を押し込んでくるときもあります。

IT主導になっているときは、業務側のマネジメントの発想は、「まず、自部門の業務が回ることが大事」だからです。

解決方法は、簡単。プロジェクト側、つまり、仕様変更判定者として、業務側のマネジメントを呼ぶのです。

業務マネジメントが、判定者側に立つ場合

もちろん、業務側マネジメントに対する、入念な事前説明が前提です。仕様変更の発生を抑制しなければならないことや、そもそも、業務標準化をすることが、会社にとって大事な取り組みであることなどを説明し、業務側マネジメントと一枚岩になっておくことが肝になります。

そうすることで、プロジェクトの趣旨と、業務の現場の両方を理解したうえで、妥当な判断をしてもらうことが可能になります。

こういった形で、現場の業務も理解したうえでの判断・助言は、業務側のマネジメントにしかできません。

しかし、業務側のマネジメントも、忙しい方々が多いので、きちんと、プロジェクトのなかに位置付けないと、プロジェクトの意向を汲んだ動きをして貰うことは難しいです。

そのため、建付けとして、きちんとプロジェクトの枠内に入ってきてもらうことが重要です。

---

最後は、枠で落す

業務側のマネジメントに入って貰って、妥当な判断を促すことは非常に有効ですが、それでも、仕様変更は積み上がりがちです。

特に、業務メンバは、ITプロジェクトに慣れていないため、要件定義や設計のときには気付けなかったが、よくよく調べると必要というものは、それなりのボリューム出てきます。

また、ITパートナ側の人材不足などもあり、検討会が十分に機能せず、十分に要件や仕様を確認し切れないといったプロジェクトも少なくありません。

結果として、仕様変更の申請が増えて、予め決めていた仕様変更枠を超えてしまうことは、多いです。

皆、もっともらしい申請理由を考える能力が高い

そして、厄介なことに、ユーザ企業の人達は、皆、秀逸な申請理由を考えるのが大変得意です。会社の命運を握るプロジェクトであれば、優秀な人材がアサインされています。そういった人達が、プロジェクトのマネジメントも唸る理由を考えてくるのです。

そうした場合、個別の仕様変更の申請内容を見て、何かを落とすということは至難の業です。

ちなみに、仕様変更の申請のなかには「本当は無くても、何とかなるもの」が多く含まれています。実際、却下されたまま、本番稼働になっても、特に困っていないケースがよく見られます。

業務メンバは、ITプロジェクトに慣れていないことが多いですので、「これも入れおかないと心配」「いま入れておかないと、本番稼働したら、入れて貰えない」などと、つい多めに申請してしまうことが多いように思います。

ただ、困ったことに、そういった諸々の仕様変更の多くが、その業務に精通していない人達から見ると、”一見”絶対必須だと思わせる理由を伴って申請されてくるのです。

枠を理由にして納得して貰うのが、一番効果的

そういった時に、有効なのは、個別に議論することは止めて、枠を理由にして「これ以上は、お金がないからできません」と言うことです。業務側に、仕様変更の優先順位を付けて貰い、優先順位の高いものから順に承認し、枠を超えたら、それ以上は却下するのです。

「必要なものは必要」「お金が足りないなら、追加予算を取れ」など、現場の反発もあるので、そんなに簡単ではありません。

しかし、枠の議論とすることで、個別の議論を回避して、大きな視点の議論にすることができます。また、申請者側で、仕様変更の優先順位を考えて貰うことで、「これは絶対に必須だが、これは却下されてもやむを得ない」という思考も生まれてきます。

特に、業務側のマネジメントに、お金の意識・予算の意識を持って貰うことは非常に重要です。他人のお金だと、できるだけ使った方良いと考えてしまいがちです。しかし、自部門に与えられた枠に限りがあると分かると、自然と行動原理が変わってきます。

こういった構図を整えることが、非常に重要です。

---

仕様変更は、必要なものです。しかし、多くのプロジェクトでは、仕様変更が積み上がり、コスト的にも、期間的にも、大きな悪影響を与えています。そのため、どう仕様変更を抑制するかが重要です。

しかし、これまでお話したように、個別の議論によって、仕様変更を却下することは至難の業です。そのため、大きな構図に持ち込むことが重要です。

最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。

ITプロジェクト研究会

---