エンジニアさんが毎回「変えた箇所」や「その理由」を聞いてきて怖い。

今回の状況【WEB】リリース直前の微修正。
ステージング(テスト環境)のHTMLやCSSに修正を加えたら、
変更箇所について超細かく聞かれる。

…これは、デザイナーとコーダーさんが分業制の現場だったり、動的なシステムを組み込んだWEB制作の現場で起こりがちな問題です。

Kai

結論から言うね。怖がることはないよ。エンジニアさんが変更箇所や変更理由を聞くのは「仕事のため」なの!!

「は…?」って思った方。ご安心ください。ちゃんとご説明します…!

どういう状況かを解説しましょう。

多分これ、エンジニアさんが見たらほとんどの方が「???」ってなるエントリーなんじゃないでしょうか(笑)

 

「仕事のため以外に何があるんだ?」と思った方。後ほどきちんとご説明します。

 

「差分を聞かれるのが怖いの?じゃあエンジニア側がDiffでも使って勝手に差分を確認すればいいんじゃないの?」と思った方。

 

そういうことじゃないんです!

 

まずこのケースの場合では、エンジニアさんが自分で差分を確認してくれたとしても、「それが本当に最終のものか」を確認するためにデザイナーに対して「変更箇所はこことここでいいですか?」ってやり取りは発生すると思うんですよね。

 

で、「それを聞かれるのがめんどくさい」って話ならそれで解決するんですが、問題は「それを聞かれるのが怖い」ってところなんです。気持ちの問題です!今日はその「気持ち」を解決したいと思います。

デザイナーは何を怖がっているのか?

この状況、何が起きているかというと、

Kai

デザイナーとエンジニアさんの脳内で認識齟齬が起きている
んです。

 

段階的に説明しますね。

常日頃のデザイナー-クライアント間のやり取り

デザイナーは通常企画やクライアントとエンジニアさんの板挟みになって、連携係を兼ねることが多いです。

 

エンジニアさんに対しては、設計図を渡して実装してもらうコミュニケーションが大半ですが、企画の人とは質疑応答やヒアリング、説得などを試みる時間が長い。

 

つまり関係性はこんな感じ。

 

 

クライアントとのやり取りの中では、クライアントの要望を

ヒアリングして
→ 整理・整形して
→ デザインとして最適なカタチにアウトプットする

というフローを行なうため、最終形が原型(要望)から大きく変化することが多いです。

 

その場合は当然クライアント側に、
・「変化した箇所」と
・「それをするに足る十分な理由」
の説明責任が発生します。

 

逆に言うと、これがうまく説明できないと「説得力のないデザイン」になってしまってうまくプロジェクトが進行しないんですよね。

デザイナー-エンジニアさん間のやりとり

進め方に関する合意形成などはともかくとして、デザイナー-エンジニア間では常日頃、あまり複雑なやり取りは発生しません。

 

大抵のケースでは、こちら側がよっぽど特殊な(あるいはおかしな)UIを指定しない限りは設計図通りに「黙って実装」スタイルの方が多いと認識しています。

 

一方、問題のケースでは例外的にエンジニアさんが「変更箇所」とその「理由」について質問してきています。
しかも、こんなデザインfix後の、リリース直前段階で、です。

 

ここでデザイナーは、「それを問われている真の理由」がわからなくて混乱する=「怖い」となってしまっているのですね。

エンジニアさんは本当に”ただ聞いている”だけ!

デザイナー側の心理状況はおわかりいただけましたでしょうか?
では次に、エンジニアさん事情についてです。

エンジニアさんはなにがしたいのか?

えっとですね、直前までクライアントとやり取りをしていたデザイナー目線だと、コンテクスト的になかなか気付けないことなんですが、今回のケースで言うとエンジニアさん(主にサーバーサイドと呼ばれる人)の直近のお仕事は「ステージング(テスト環境)の実装内容を本番環境に反映する」ことなんです。

 

つまり、ステージング(テスト環境)から本番環境に全データを滞りなくアップロードするために、変更ファイルと最新データの状況を確認したい、というのがエンジニアさん側から見た時の状況なんですね。

 

…そろそろ気づきましたか?あなたの大きな誤解に。

 

そう。エンジニアさんは、デザイン(見た目)がどう変わったかやその理由(そのデザインになることによるメリット)についてなんか興味はないし、その過程でデザイナーとクライアント間にどんな攻防(やりとり)が発生したかについてなんて聞いてないんです…!!!(白目)

 

 

本当にただただ、「変えたファイルの名前」「変更件数」「(ディレクトリ構成を変更するべきかなどの判断基準としての)変更理由」を尋ねているだけなんです!!!(白目)

ナイショ話

私がまだルーキーだった頃。

 

同様の状況下で「変更したデザイン箇所(変更箇所)」と「それにともなうデザイン的メリット(変更理由)」について、エンジニアさんに一生懸命お話したことがあります。。

ええ、それはもう、誠意を込めて…。

 

そのエンジニアさんからは途中で

エンジニアさん

あ、いや、デザインはこれでよくてですね。
ただ、あの、コードの変更箇所と、その理由…えっと、経緯を知りたいだけで…

とツッコミが入り、後にdiffを開かれ、

エンジニアさん

変更したのはここのコードですかね。
あ、ここの名前も変更しました?ほかに更新ファイルは?

と逐一質問されるという、なんだかとてつもなく恥ずかしい状況に陥ったことがありましたww

まとめ

結論

タイトルに戻りますが、結論としてはエンジニアさんは

自分のお仕事(プッシュ作業)のため

に「変更箇所」と「理由」を尋ねているだけです。

 

そこにエンジニアさん自身の興味・関心や心理的な裏はありません。

ただただ、淡々と粛々と、変更ファイル名やコードや行について伝えましょう。

 

おわかりですかデザイナーのみなさん。

もう一度いいますよ。恐れることはありません。

 

エンジニアさんが知りたいのは、
デザインに関する説明、ではない!!!(白目)

余談

ちなみに私の場合この認識齟齬に気付いてから、エンジニアさんに無駄に怯えていた日々がウソのように改善されましたw

変更箇所がわかる時

エンジニアさん「何箇所くらい変えました?」
Kai「えっと、3つ!このファイルの126行目と、このファイルの名前と、この画像を差し替えた!」
エンジニアさん「OK、反映完了!」

変更箇所が(たくさんありすぎて)わからない時

エンジニアさん「何箇所くらい変えました?」
Kai「んー…忘れちゃった!たくさん!」
エンジニアさん「OK、diffで差分比較します。(差分画面を見せてくれながら)これが最新で間違いないですか?」
Kai「はいっ」

理由がわかる時

エンジニアさん「これってなんで名前変えたんです?」
Kai「これは最初、この画面に属してるからと思ってこの名前にしてたけど、実際はこのパーツと連動して動くやつなので(云々)」
エンジニアさん「OK、じゃあちょっとディレクトリ構成変えてこういう形式で管理しましょう」

理由がわからない時

エンジニアさん「これってなんでファイル変更したんでしたっけ?」
Kai「え、よくわらん。。。でも企画の人が、ここに1項目追加したいとか言ってたような…」
エンジニアさん「ふむ…(考え中)」
Kai「あ、もしかしてそれによってなんか構成変わりそうです??もし工数負担出るようなら企画の人に相談してみますけど…」

リアルな現場ではこんなやり取りがなされます。

 

ね。なんか、歩み寄れた感すごいでしょ?笑

…それにしても、あんな恥をかくくらいだったら、事前に模範解答を教えといてほしかったなぁ。(遠い目)

Kai

みなさんはくれぐれも私と同じ過ちを侵しませぬよう。
エンジニアさんとはよーく対話することが大切です!

 

そしてもしもこの記事を読んでくださっているエンジニアさんがいらっしゃったら、
デザイナーになにか尋ねる時は、一言でいいのでその意図(目的)を教えてあげてくださいねw