エンジニアが色んな人と仕事をしていく中で、エンジニア泣かせのことを言われたり、「わかってくれよ」と思う場面に出くわすことはよくあります。
こういうのはその立場ごとに考え方が違うので、当然エンジニアと仕事をしていたらこういうところにイラっとくると思うことはあるんでしょうけど、ここではエンジニア視点で非エンジニアと仕事をするときにこういうところに気を回して欲しいと思うことをまとめてみたいと思います。
技術的なことを任せっきりにしない
技術的なプロとしてエンジニアを見てもらうことは結構ですが、その全てを押し付けられるとモチベーションが下がることはあったりします。
技術的な詳細は、非エンジニアの人にとっては未知なところもあるんでしょうけど、あまりにそれを任せっきりにされ「あとはいいようにしといて。細かいところは空気読んで作って」という雰囲気が出ていたりして、エスパーでもない我々にとっては頭が痛くなることばかりです。
例えば、テストであっても単体・結合テストレベルであればエンジニアしか対応できませんが、運用・受け入れテストにもろくに参加せず、リリース直前または直後にシステムを見て意見を言われたりすると「その機会はあったんだからもっと先に言ってよ」ということになるでしょう。
そういったフィードバックというのはおおかた当初に決めた仕様とは異なる意見であったりして、そもそもが仕様と違うこと言ってるじゃねぇかという気分にもなりますし、プロジェクト参加者の権威によって一気に覆ったりする（現場でまとめた仕様をPJリーダーが覆し、PJリーダーが言ったことを部長が覆し、それを役員が覆すとか）から収拾がつかなくなるケースもあったりします。
また、開発というのは結構孤独であったり重圧を受けることもあります。
上流工程が終わればあとは開発を待つだけとエンジニアだけが取り残されたりしますし（そしてお上は終わった気分になってたり）、納期のプレッシャーだけでなく技術的に実装可能かという課題にも苛まれます。
よくありがちなのが、「このサイトと同じような機能を作って」というもので、よくあるものだったらいいのですが、技術的にどう実装しているのかよくわからない場合であったり、何を使えば作れるのかがわかってもそのライブラリやツールを使った経験が無いことから納期内にうまくそれを取り込めるかやってみないとわからないということも多々あります。
このサイトと同じという「このサイト」がGoogleだったりして、これを作れるのはGoogleのエンジニアの能力や規模感や資金があるからできるわけであって、うちのこの小さなチーム（または個人）でそれをやるのにどんだけの工数かかると思ってるんだと、そのサラッと言われたことにイラっときたりするわけです。
プロジェクトの運営までを押し付けない
いざ開発が始まっても、それにどれだけの工数がかかり何時ぐらいに何ができるかというスケジュール（そして、それが可能かどうか）はエンジニア側の言い分によってある程度決まってきたりします。
ただ、そのスケジュールというのはあくまで仕様どおりの構築をするための線表であって、こちらとしては作る側で手一杯の状態であるのに、プロジェクト運営の課題やリリース前後の運用にまで仕事を回されることがあったりします。
例えば、構築するシステムに対する運用の組み立てができてなかったり（それによって仕様の変更に影響する恐れがあったり）、マイルストンがブレブレであったり（フェーズをわける考えが無くて全てをリリース時に盛り込もうとしたり）、現場への説得や説明にまわされたり（それによってタスクには含まれない成果物を求められたり）。
確かに技術的な要素については不明点も多いのかもしれませんが、そもそも作りたいと提案してきた側が明らかにそれをコントロールするイメージをもてておらず、想定のシステムができたら全てがうまく回ると思っていたりして、こちらとしてはそれをどう使っていくのかというその後が全く想定できていない現状を垣間見ると不安と心配が錯綜し、余計なところまで手を出さざるを得ない状況になったりします。
まぁ、こういうことはプロマネであったりプロジェクト運用担当者の能力に依存する部分なんでしょうけど、明らかにエンジニアとしての仕事ではない部分まで対応する羽目になったりするとイラっときたりするわけです。
エンジニアの美学を尊重する
こういうのは個人差があったりそもそもそういったことにこだわらない人もいるのですが、エンジニア独自の美学というのを持っている人もいたりして、それを否定することを嫌う人も多かったりします。
例えば、保守性を高めようとコードを綺麗に書いたりリファクタリングすることを理解できずに時間の無駄と捉えられたり、十分なテストをクリアしていないものをリリースさせたくないと思っているエンジニアもいる中で納期優先で「とりあえずリリースして」といってくる人もいたりします。
やはり目に見える画面だけでなくその裏のロジックもきっちりしたいと思っているエンジニアもいますし、取りあえずで作ったものが本格運用され規模が大きくなるにつれて手を加えることが難しくなり果てには自分たちを苦しめる結果になることをよく知っている人もいますし、品質が保証されてないものをリリースしバグが出ることで自分たちの能力を計られたりその改修で多くの工数を保守で費やす羽目になることを経験している人たちもいます。
自分はB型の割りに結構まめな方かなと思ったりしているんですが、結構システムの構成要素の作る順番とか決めているのを崩されたりするのが嫌だったり（もちろんそのマイルストンは事前に承諾を貰っているのに度外視されたり飛込みだったりして）、先に書いた取りあえずリリースしてと言われるのが嫌だったり（スモールスタートという意味ではなく取りあえず使いたいという意見だったり）、そもそも自分たちで物づくりすることに否定的だったりする（外注頼り）意見を言われるのが嫌だったりします。
まぁ、何れにせよエンジニア視点でよいものにしたいという考えがあるわけで、それを否定されることがあったら身構えちゃうわけです。
そういったものへの防衛本能や、コードそのものをある種芸術作品のように捉えているエンジニアもいて、自分が納得するまで妥協したくないと思っている人もいる中でそれを否定されるとイラっときたりするわけです。
まとめ
最初に書いたように逆の立場からエンジニアに言いたいことも多々あるでしょうから、双方で考え方の歩みよりは必要なのでしょう。
ただ、エンジニア独自の考えに配慮することでプロジェクト運営もスムーズに運べるようにはなるのではないかと思ったりするわけです。
エンジニアへのプレッシャーや役割への理解やそもそも言い分として矛盾している点がないかとか、よく考えるとエンジニア云々の話でもない点も多々あるわけで、やっぱり参加する人をきちんと見てその人に応じた対処や配慮をすることは大事なんじゃないかなと思うわけです。
[PR]
[PR]
