エンジニアはどうしてそんなに「それは仕様変更だ!」と騒ぐのか。
制作会社に勤めていると、エンジニアが社内で「それは仕様変更じゃないですか!」と大声出しちゃっているのを見かけたことのある方が多いのではないでしょうか。
小さな制作会社で一人二人くらいいるエンジニアは、たいていぶっきらぼうで、仕様変更とかがあると必ずと言って良いほど騒ぎ出します。非エンジニアからすると、関わりにくい、面倒臭い人というイメージがあるかもしれません。
しかし、僕もエンジニア歴は長いので分かるのですが、仕様変更を主張するのには訳があるんです。制作の工程の中でエンジニアしか分からないもやもやがあったりするのです。そんな気持ちを紐解いてみたいと思います。
仕様変更は俺たちの正当性を主張するための唯一の呪文。
「これは仕様変更じゃないですか!」
エンジニアがそう叫ぶとき、バグや勘違いではないことの主張をしていることがかなりの割合を占めます。自分は仕様書通りにちゃんと作っている、指摘を受けた部分については仕様書にはないしこちらのミスでもない、そう言っているのです。
4文字でいうと「仕様変更」自分の正当性を主張するための呪文みたいなものです。
では、大人にもなってどうしてそんなに夢中になって騒ぐのでしょうか。
作っていたブロックを横から来て崩されてしまったかのような怒り。
何の制作でもそうですが、作っている途中段階でやっぱりこうしたい、というのが出てくると最悪作り直しになります。システム設計という言葉があるくらいで、システムはきちんと設計して作る必要があります。
建築物を立てる時に、骨組みと内装がほぼ終わった時に「やっぱりキッチンをこっちの部屋に置きたい」と言っても無理なのは素人目にも分かりますよね。
システムだと割と平気でそのレベルのオーダーがあったりします。
時間をかけて作ったものを壊して作り変えるというのは結構しんどいですし、せっかくきっちり設計していたシステムが継ぎ接ぎだらけの不格好なものになっていくのはエンジニアにとって感情的にも耐えがたいものがあります。
その変更は外から見ているほど単純ではないし、だったらお前がやれよ。
よく「○○するだけでそんなに大変?そんなに時間かかるの???」と言う方がいらっしゃいますが、同じエンジニアでもない限り、こういう問い方はご法度です。
エンジニアの大多数は「じゃあお前がやれよ!」と思っているでしょう。
思っててもお前がやれよ、とまではなかなか言えません。そこで仕様変更がいかに大変かということを主張しているうちに感情的になってしまう部分もあるのです。
一見簡単そうに見える変更であっても、作っている人間以外に気が付かない影響範囲というものがあります。結局そういう部分を理解してもらえなくて、感情的になって騒ぎ出すエンジニアも少なくありません。
企画はエンジニアを置き去りに、面白さありきで進んでいく。
プロジェクトによっては企画の面白さを中心に話が進んでいく場合があります。
システムの実現可否は別として、まずは面白いことをやりたい、今までにないようなことをしたい、企画側は開発にかかる時間や難易度とは別に、自由な発想で楽しさを追及していきます。
で、出てきた企画内容と実現する機能を見せられたエンジニアの顔は企画の楽しさとは反比例してみるもり赤く憤怒の表情をあらわにしていきます。そんな話は今初めて聞いた!どうして最初に出来るかどうか相談してくれなかったのか!となるわけです。
確かにエンジニア個人の技術を慮って企画を練っていては先に進みません。ある程度技術的な解決はその道のプロであるエンジニアに頑張ってもらいたい、という気持ちは分かります。
しかし、存在をないがしろにされたうえで、突き付けられた企画をみて心情的に面白いわけがありません。一旦こうなってしまうと、エンジニアも頑固な方が多いですから、些細な仕様書誤記などを完璧に誤記のまま作り上げて、仕様変更を主張してくるでしょう。
プロジェクトのしわ寄せ俺たちに、納期(時)は待ってはくれない。
作っている最中に仕様変更があった場合であっても、たいていは納期がそのままだったりします。仕様変更としてきちんと費用と期間をみて貰える場合もありますが、納期優先のことの方が多いでしょう。
例えばWebサービスを制作する際の工程は企画があって、デザイン⇒HTMLコーディング(画面作り)で最後にエンジニアがプログラムを埋め込んでいきます。
エンジニアの作業はいつでも最後なのです。
ということは上流工程の進行が遅れると、納期に向かってしわ寄せがくるのは誰でしょうか?そうです、エンジニアなのです。
ですからエンジニアは納期にピリピリ来ています。
ただでさえピリピリしているところに仕様書にない変更を言われると、一気に導火線に火が付きます。
正直面倒臭い。
エンジニアは得意なことは本当に出来るのか?と思うくらい少ない工数を出してきますが、ちょっと面倒臭い、やったことないからわかんない、という場合はびっくりするくらい多めの工数を主張してきます。
多めに工数を取ることは決して悪いことではないのですが、見積りを作成する方にとってはお客様の予算と比べても現実的な金額にはならないので頭を抱えてしまいます。
では、多めの工数があまった場合は他の仕事をするのでしょうか?正解はNOです。
開発は非常にストレスが溜まりますので、エンジニアの皆さんは仕事中であっても気分転換にSNSや巨大掲示板などへの書き込みや仕事以外の情報収集にかなりの時間を割きます。
ですから、出来れば多少多めに開発工数を出しておいて余った時間は遊んで情報収集やSNSでのコミュニケ―ションに使いたいと思うのです。
仕様変更があることでせっかく前倒しで終わらせたのに、、となると面倒臭いという感情が表に出てきます。
スポンサーリンク
柔軟性をもった仕組みというが、発注者が求めるほどの柔軟性などシステムにはない。
よく最初に作る際に「追加機能とか色々後から出来るように柔軟性を持ってほしい」ということを言われます。後からこれをやるには作り変えないといけない、工数が凄くかかってしまう、ということを回避するための保険のように言われるのですが、その時点で予測できない機能に対して柔軟性を持つことは困難です。
実際に柔軟性を持つとしたら、ある程度将来何をやりたいか、どんな項目を増やしたいか、その個数はなど、ある程度予測しておく必要があります。
オーダーの内容によっては作り変えが発生したり大幅な改造になるでしょう。制作会社のいうところの柔軟性とは、対応という意味の柔軟性であって、システム自体の柔軟性ではないことが多いです。
システムの開発現場では仕様変更をめぐる攻防が必ず出てきます。
エンジニアを制する者はシステムを制する、と言われているかは分かりませんが、ディレクターなんかはエンジニアの気持ちも吸収しつつ、うまいことエンジニアを手玉に出来ると円滑にプロジェクトが進められるのではないかと思います。