paiza times

paizaがお届けする、テック・キャリア・マネジメント領域における「今必要な情報」を届けるWebメディア

logo

paizaがお届けする、テック・キャリア・マネジメント領域の「今必要な情報」を届けるWebメディア

非エンジニアに多い、エンジニアと開発業務に対する4つの勘違い

f:id:paiza:20191219190539j:plain

f:id:paiza:20140916135428p:plainこんにちは。谷口です。

経営者やディレクター、マネジャーなど、エンジニア以外の職種の人たちとのコミュニケーション時に発生する齟齬について悩んでいるエンジニアの方は多いですよね。paizaを運営していると、実際にそういった悩みを抱えて転職を考えているエンジニアの方からご相談を受けることがよくあります。

開発はサービスやプロダクトの根幹を担う業務ですが、開発部門と大きくかかわる人たちが、その実態や特性についてよく知らないと、コミュニケーションやマネジメントに問題が生じてしまいます。

今回は、転職経験のあるエンジニアたちに聞いた、エンジニア以外の人たちとのギャップが生じがちなポイントをまとめて書きます。

正確な見積もりはかなり難しい

見た目の変化がわずかでも、内部の開発が簡単なわけではない

どんなシステムでも、表面上は簡単に動いているように見えても、コードは内部で複雑に組み合わさって動いています。

エンジニアは、その上で既存のものをどう再利用するか、どう作るとより効率よく動かせるのか、などを考慮しなければなりません。だから一発書きでベストなプログラムができることはなくて、すでにあるものをいろいろと調べたり、新しいやり方を試したりしながら、なるべくベターな作り方を探っていく必要があるわけで、見積もりはあくまでそのアタリをつけているにすぎません。

ついでに言うと、作業工数は作業者やチーム全体の経験や知識レベルに大きく左右されます。人によってはすぐできることもあれば、調べながら少しずつしか進められないこともあるでしょう。

だから、外から見るとボタンをひとつ追加するような一見簡単な作業でも、内部的には全然簡単じゃなかったりします。

ここで適当に「〇日でできます」と言ってしまっては、エンジニアも自分の首を絞めることになってしまいますので、ほとんどの人はリスクヘッジとして工数を多めに見積もって言うでしょう。仕様も決まってない、見積もりとる時間もないなら余計にそうです。

非エンジニアには「え?そんなにかかるの?」と思われがちですが、必要なリスクヘッジです。

「人数を増やせば早くよいものができる」わけではない(むしろ工数が増える場合もある)

開発は、人数さえ増やせば早くできたり、よいものができるわけではありません。

これはよくいろいろなスキルに例えられますが、「ピアノで猫ふんじゃったしか弾けない人を100人集めてもモーツァルトの曲は弾けない」みたいなことですね。

まともなプロダクトを開発するのには、一定レベルの知識やスキルが必要です。手だけ動かせるレベルの人をたくさん集めたところで、根底に必要なスキルが足りていなければうまくいくことはありません。

むしろ、品質の悪いコードが混ざってくることで、システムのパフォーマンスが低下したり、その修正や指導に優秀なエンジニアの工数がとられたりして、マイナスになる可能性のほうが高いと言えるでしょう。

見た目や出力が合っていればシステム的にもOK、ではない

できあがったものの品質がよいかどうかは、外側の見た目や単純な出力結果だけで判断できるものではありません。

継続的に運営・機能改善などがされていく予定のシステムであれば、コードはその保守性や拡張性、可読性などが大切なはずです。

しかし、外側の見た目やインプットに対するアウトプットが正しいかどうか、単純な出力が合っているかどうか(≒外部仕様として想定通りに動いているかどうか)にしか評価が及ばない組織も少なくありません。

このような組織では、エンジニアの考慮やスキルが正しく認められず、「なんでこんなに時間かかるの」みたいな発言が横行して、エンジニアのモチベーションを下げてしまいます。そして最悪の場合、可読性が悪く、コピペや無駄な部分も多く、拡張しようのないコードが残り続ける(技術的な負債が生まれてしまう)ことになってしまいます。

エンジニアにとって大事なのは、どこで作るかではなく何を作るか

非エンジニアのみなさんは、エンジニアにとってのモチベーションがどこにあると思われるでしょうか。

まあ金銭面とか、プロダクト自体が好きだからとか、使っている技術が好きだからとか、人それぞれではありますが、基本的にまともな開発スキルを持ったエンジニアの場合

  • サービスや機能を作る意義や、誰にとってどう役立つかがわかっている
  • その開発に最適な技術を適切に使える

この2つが、モチベーションを保つのに最低限必要なことかと思われます。

黙って言われたものを言われたとおりに作る、見積もりをすれば時間をかけすぎだと言われる、スキルの低い人をたくさん投入されて尻拭いさせられる、という状況ではモチベーションを保つのは難しいでしょう。(実際、このような環境から転職されていく方はたくさんいます)

組織としては、サービスや機能を作る意義や誰にとってどんな役に立つのかを共有すること、エンジニアが適切な技術を適切に導入できる環境を整えることなどが実現できるとよいでしょう。(もちろん、金銭面などの待遇の向上も含めて……)

まとめ

エンジニアと、経営者やディレクター、マネジャーなどは、仕事でもそれぞれ違う部分を気にしているので、ギャップが生じるのは仕方ない面もあります。しかし、事業の根幹がITであるなら、的外れなマネジメントをしたり、無茶な開発を要求したりしている場合ではありません。

エンジニアと非エンジニア職が、いい意味でお互いを巻き込み合える環境を作ることが大事なのだと思います。




paiza転職は、転職時のミスマッチをなくし、エンジニアがより技術面にフォーカスしたやりがいある仕事を探せる転職サービスです。プログラミングスキルチェック(コーディングのテスト)を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。

詳しくはこちら
paiza転職


まずはスキルチェックだけ、という使い方もできます。すぐには転職を考えていない方でも、自分のプログラミングスキルを客観的に知ることができますので、興味がある方はぜひ一度ご覧ください。

詳しくはこちら
paizaのスキルチェック

paizaのおすすめコンテンツ

Webセキュリティ入門 ハッカー入門 Webセキュリティ講座がスタート!CVは内田真礼さん! Python✕AI 機械学習入門講座 CVに上坂すみれさんを起用!人気の機械学習講座を公開中!
paiza転職 paiza新卒 EN:TRY paizaラーニング 記事内に記載している情報は、記事公開時点でのものとなります。 Copyright Paiza, Inc, All rights reserved.