またお客さんに仕様変更頼まれたよ～
ボランティアじゃないんだから断ればいいじゃん。
いざ頼まれると引き受けちゃうよね…。
まあね…。
顧客とエンジニアは表面上は良い感じでも、裏ではいかに自分たちの要求を通すかを考えていて、ドロドロしています。
今回は顧客とエンジニアの駆け引きについてお話します。
「何時間くらいかかるか」を想像して費用が決まる
システム開発の費用の算出方法の闇は以下で説明しています。
まあ、適当なんですけどね。
例えばあるシステム開発をするときに、「400時間くらいかかるな～1時間あたり5000円くらいほしいな」となれば、システム開発費用は「200万円」になります。
お客様の希望で納期は1か月だとしましょう。1か月160時間稼働とすると、プロジェクトメンバー3人くらいで回していけば終わる計算になります。
こうして予算400時間で1か月で終わらせるプロジェクトが立ち上がります。
作業が増えたけどお金はもらえるケース
400時間という時間は顧客から聞いた話を元に算出しています。
つまり、やらなくてはいけない作業が後から増えれば当然400時間を超える時間が必要になってきます。
これが、エンジニアが嫌いな言葉上位にランクインするであろう「仕様変更」です。
やってきたことのやりなおしならまだいいですが、やってきたことをなかったことにして、別のことをやるのが仕様変更です。恐ろしいですよね。
例えば20時間分の作業が増えた場合、1時間5000円なので10万円を追加でもらえるとしましょう。
売り上げ的には問題ありませんね。
ただし、それでも別の問題は残ります。納期が延びなければ残業や休出、要員の追加でカバーしなくていけません。
納期が延びた場合も、元々1か月で終わっているはずのプロジェクトなので、すでに次のプロジェクトの参加を予定しているケースも多いので、調整が必要になってきます。
お金をもらえば良いというわけではないのです。
作業が増えたけどお金がもらえないケース
400時間の作業で200万円なのに、20時間の作業が増えて420時間分の作業になっても、追加で費用がもらえず、200万円のままのケースもあります。
1時間あたり5000円稼ぎたいのに、数字が目減りしてしまいますよね。つまり、20時間分はボランティアってことですね。
場合によっては、失敗プロジェクトとして、上層部から低評価をつけられる可能性だってあります。
エンジニア側にはいいことはなにひとつありません。
エンジニアの思考のたどり着く先
そんなわけで、お金をもらえようと、もらえまいと当初の予定より作業が増えることをエンジニアはすごく嫌がります。
そんなエンジニアは「作業を増やさないようにする」ことになります。
いかに仕様変更を受けないかを考えるようになるのです。
お客さんもお客さんで言い分はあります。
「これくらいやってくれると思ってた」
「ちょっと言い忘れてただけじゃん」
「予算が決まってるから費用は払えない」
「これやってもらわないとシステム化する意味がない」
「指摘しなかったそちらにも非はあるのでは？」
エンジニアからするとどれも理不尽なんですけどね（笑）
単純に拒むことが難しい
お客さんが予定外の作業を言ってきても、単純に断れば良いのでは？と思うかもしれませんが、そう簡単でもありません。
お客さんがミスするようにエンジニアもミスはします。
適当に作業しているのでなおさらですね。
平気でバグを潜ませたまま納品してしまうこともたくさんあります。
もちろん悪いのはエンジニアです。謝るしかありません。
厳しいお客さんだと是正処置を提出しろと言ってくる場合もあります。
あたりまえですよね。高いお金だしているのですから。
既にエンジニアにミスが発覚している場合はもちろん、していない場合もこれからしてしまうリスクはあります。
こうなってくると強気に出ることができません。
理不尽な要求でも受け入れなくてはいけない状況もどうしても出てきてしまいます。
関係性を良好に保ちたなくてはいけません。
それでもちょっとだけ抵抗するエンジニア
ハッキリとは断らなくてもエンジニアは作業が増えなくても済むようにちょっとだけ抵抗します。
例１）
あれ～？この動作で合っているんだっけ？
はい、仕様です。
たとえバグの可能性があっても「仕様」ということにしてしまいます。
「仕様です。」はエンジニアの口癖ですね（笑）
例２）
あれ～？ここどうなってるんだっけ…
……………………。
お客さんから独り言のように困っているときは聞いていないふりをします。
例３）
ここ、こういう風にすることできる？
はい、技術的には可能です。
エンジニアがこう言うと「できるけど、お金頂戴ね」や「できるけど、今の時間内では無理」という意味になります。
ポジティブなお客さんだと「可能ならやって！」と言われることもありますが…。
私はよく「やれるかやれないかで言うとやれます。でも今回の範囲外なので費用が…。」と言っています。
例４）
こういうことできる？？
すみません、製品自体の仕様なので難しいですね。
既に完成している市販のソフトやクラウドサービスのカスタマイズ開発等をしている場合もあります。
この場合に困ったときにすることは「製品のせいにする」です。
自社で作ったシステムではない部分なので、どうすることもできないのでお客さんも結構諦めてくれます。
まとめ
このように、エンジニアは少しでもやることが増えないようにしています。
ぶっちゃけ、「お客様第一」より「プロジェクト第一」です。
色々抵抗しても、結局は今後の付き合いとか自分たちのミスとか考えると、受け入れることも多いですが…。
私はキッパリ断る派です。
プロジェクトの利益が減って、会社に責められるの嫌ですもん（笑）
ーーーーーーーーーーー
いかがでしたでしょうか？
お客さんの立場で考えてみると、もちろん言い分はわかります。
でも正直エンジニアは自分を守ることでいっぱいいっぱいなんです。
以上、最後までご覧いただきありがとうございました。