プロジェクトマネジメントについて

まさにXP（エクストリーム・プログラミング）の計画ゲームがそれにあたると思います。

つまり、システムに盛り込む機能（仕様変更含む）を、いつ取り込むかをユーザと一緒に考えるわけですね。

で、ユーザにわかってもらうには、

・今取り込むことによるメリット・デメリット

・次回リリースに取り込むことによるメリット・デメリット

を説明するしかないと思います。

おそらく、今取り込むことによるデメリットが大きいと思いますが、

それでもなお、ユーザが「やれ」と言うならやらざるを得ないでしょうね。。。

ちなみに、仕様凍結はよく聞く単語です。

ただ、最近は上述のXPに代表される開発手法によって、（早期段階で）仕様凍結しないことが良いとされています。（私もそう思っています）

物を作る以上、仕様凍結は必ず必要ですが、問題は凍結するタイミングだろうと思います。

ぎりぎりまでの仕様変更をする事でのデメリットを数値で出してみてはいかがでしょうか？

戻り作業や仕様再確認などで無駄な時間が出ていると思います。

それらはコストとして跳ね返り、現場レベルでOKでも経営者、マネージャーから見れば問題視するでしょう。

具体的な数字などで見せられると結構納得してくれたりします。

また、know94spaceさんが発言力のあるポジションなら、「それは次リリースで」と強い姿勢を取ってはいかがでしょうか？

お客様にはスケジュールとコストの確認はされていますか？

お客様（特に現場担当者など契約に直接関わらない方）は予算やスケジュールなどを意識せず、自分の望む仕様を実現して欲しいと要求を出すのは当然です。

しかし開発側にも当然、守らなければならないスケジュール、予算がありますので、どの程度の仕様変更をした場合に、スケジュールと見積りにどの程度の影響があるのかをきちんと説明して、お客様（に判断して貰う必要があります。

出来れば契約（見積り）時点で事細かに見積り内容を説明した資料があればベストですが、一般的にはある程度曖昧な表現になっていると思いますので、その点でもめる可能性はありますが、代替案（そちらを実現する代わりにこちらの機能は遅らせたいとか）を出すなりしてお客様と調整してみては如何でしょうか。

お初に御目文字いたします。Lucreziaと申します。

お気持ちはわかりますし基本的には「強権を発動してでも」ってのをあたくしもやったりするのですが。

あえてここで逆のお話をさせていただいてもよろしくってかしら？

コーディングをする際に。或いはその手前にある設計の際に。「仕様変更に耐えうる設計やコーディング」をなさっていてかしら？

もっと平たく書くのであれば。

正しく設計されたオブジェクト指向プログラミングであれば、結構な仕様変更にまでは耐えられると思いますわ？

もちろん「オブジェクト指向で設計してなお”根本的に無理な”」変更っていうのもあると思いますの。

でも、ここであえて「逆境を自らを鍛えるために」っていう風な、ちょっと古風でたくましい殿方を気取ってみるっていう視点がほんの少しあってもよろしいんじゃなくってかしら？

状況は変わらなくても、もしかしたら少し精神的に余裕が出るかもしれなくってよ？