Programmingモチベーションの高いエンジニア...ガンガン働いてくれそうで、放っておいても安心でしょうか?安心してください。ディスプレイを小さくするエンジニアの仕事の多くはパソコンの中にあります。そのパソコンの中を覗く唯一の手段はディスプレイです。そんな狭い中で、色々な資料をみながら、プログラミングをしていきます。ドキュメント資料を開きながら、エディターで実装する。それがスムーズにできればできるほど効率良く、ストレスも少ないです。小さいディスプレイを支給すれば、モチベーションは下げられます。優秀なエンジニアほど効率を求めるので、下がり具合は大きいものです。小さなディスプレイでも二台あればエンジニアはうまく使いこなして作業効率を上げます。一台取り上げてしまえば、気分は最悪に。大きなディスプレイが支給されている場合は、ガムテープで3割くらいの表示領域を塞いでしまえば、同じ効果があります。それどころか、全画面表示が役立たずになるので、プラスアルファの効果が期待できます。毎日スーツを着させるエンジニアは多くの時間、オフィスで座って仕事をします。肉体的には、逆にけっこうつらいものです。あまりにクタクタな感じのを着たいわけではないですが、ある程度リラックスできる格好でいたいものです。毎日スーツを強制させれば、モチベーションは下げられます。「エンジニアがスーツを着てる会社には行かない」とか言ってるエンジニアもいますから、リクルーティング的にも、スーツを着たエンジニアを前面に押し出せば、応募すらしてこないので、最初からミスマッチも防ぐことができます。これは個人差が激しいので、ちょっと該当しない人もいるかもですが...。椅子を固くして、机を狭くするエンジニアはオフィスで長い時間座りますから、椅子が人体に与える効果をもろに受けとります。良い椅子であればあるほど、体のリラックスを長い時間キープできるので、集中力の持続もしやすくなってしまいます。長時間座るのには向いてない「固い椅子」を与えればモチベーションを下げられます。良い椅子が支給されている場合は、クッション部分に鉄板でも挟んであげれば、同じ効果を得ることができます。机の広さも同様ですね。広ければその分、色々な資料や本を並べて仕事ができるし、他のエンジニアとコミュニケーションも取りやすいので、すでに支給されている机が広いのであれば、ノコギリやチェーンソーで切り取れば台無しにできます。簡単に作れるでしょ?って上から目線で言うIT系のエンジニアは、なかなか世間一般の方々から、やっていることを理解されにくいものです。何が簡単で、何が難しいのか、なかなかわからないもの。思われていることを、エンジニア自身よくわかっていて、それがコンプレックスでもあったりします。開発しようとしている画面があったとして、画面の見た目から来るイメージと、実際のプログラミングの難しさはなかなか比例しません。簡単そうな画面でも作るのは難しい、よくあることです。わかってないフリして、「えっ、こんなの簡単に作れるでしょ?」って言ってあげると、大抵「はぁ!?」って表情をします。納得がいかないだけなら、モチベーションを下げたことにならないですが、そういうことを何度も何度も言い続けることで、「難しいことを実現しても評価されないのでは...」って気持ちになるので、しっかりモチベーションを下げられます。実際に、難しい画面を頑張って速く作り上げたエンジニアに、「あー簡単そうな画面だったもんね、じゃあすぐ次これ作って」と、軽くあしらってあげると効果が相当高いです。打ち合わせ一杯で連続した集中時間を与えないエンジニアの仕事は、もの作りです。プログラミングしている最中は、脳の中でたくさんの情報を扱います。その状態はすぐにできあがるものではありません。要は、スポーツするときのウォーミングアップと同じで、ある程度ホットな状態に持っていくまで時間がかかります。優秀なエンジニアほど、そのホットな状態での作業効率を重視しています。その連続した集中時間を途切れさせるように、中途半端に間をあけて打ち合わせをたくさん入れてしまえば、モチベーションを下げられます。いえエンジニアも、打ち合わせが必要なことはわかってますから、別に重要な打ち合わせであれば、しっかりその辺をセルフコントロールします。なんだか無意味そうな打ち合わせや、ダラダラして間延びした打ち合わせ、本人には関係なさそうな打ち合わせを入れてあげれば、イライラしてセルフコントロールを崩すことができます。情報共有しづらい、風通しの悪い現場に大抵は、エンジニアはチームで仕事をします。一人でもの作っておしまい、って思われるような仕事でも、会社にいる限りは何かしら他人の情報に依存しています。「必要な情報」というのは共有されないようにして、エンジニアの成果物が的外れになるようにしてあげれば、モチベーションを下げられます。「いや、それ聞いてないよ」ってセリフを出させることがポイントです。エンジニアの中には、そういった情報を自らの行動で、積極的に取りにいく方もいらっしゃいます。情報を阻止することができます。いわゆる「風通しの悪い現場」にすればいいのです。良いコミュニケーションは、気の利いたプラスアルファの情報のやり取りが発生し、エンジニア同士のスキルの相乗効果を生んでしまいますし、そういった技術交換が楽しくてスキルアップにつながり、モチベーションが下げるどころか上がってしまいます。「何か困っていることに気付いても聞かれるまで教えない」これらをテーマにしたムード作りをしていけば、だんだん質問自体がしづらくなってきます。「えっ、なんでそれ教えてくれなかったの!?だってさっきそういう話してたじゃん、なんかひとこと言ってくれても...」って言葉が出てくれば、「風通しの悪い現場」の完成です。引き継ぎなしで人をどんどん入れ替えるエンジニアのやる仕事は色々と入れ替わるものです。エンジニアの中で色々な仕事があるため、あれできる人、これできる人と都合があるため、すぐにチームを移動したりってのは日常茶飯事です。人が入れ替われば、そこに「引き継ぎ業務」というものが発生します。エンジニアのやっている作業は、人によって随分とバラバラであり、かつ、パソコンの中に閉じ込められているため、引き継ぎなしで新しい人がスムーズに作業を開始するというのはまずありません。仕事内容が定型的にならないため、他人の作った環境や成果物を完全に把握するのには時間がかかるし、ストレスのかかるものです。そこで、引き継ぎ業務は直接的なビジネス業務ではない、という名目で、引き継ぎ期間を設けず、引き継ぎ業務をさせずにどんどん人を入れ替えれば、モチベーションを下げられます。背景わきまえず、コード汚い、仕組みひどいと言う特に事業会社でのスタートアップは、ジャングルの中でプログラミングしているようなもの。会社も立ち上がったばかりなら給料も低いし、次から次へとプログラムを作らなければなりません。サバイバルコードもたくさん生まれます。気の利いた仕組みを構築しようにも、それを整備する時間もなければお金もありません。(アーキテクトを連れてくるお金はありません)それがわかった上で、現場のエンジニアは戦います。単なるスキル不足のケースもあるかもしれませんが、高いスキルがあってもサバイバルコードは生まれます。ジャングルで突然、蛇に襲われたときに、「正座して一礼をしてから刀を構える」なんてしてられないのです。その後、成長した事業の中で、スタートアップのときのサバイバルコードを、そういった背景もわきまえず、汚いだとか仕組みがひどいだとか言えば、モチベーションは下げられます。「同じ状況でおまえやってみろよ」と思わせれば達成です。いう背景をよくわかった上で、サバイバルコードに敬意を表しながら、役割を終えたコードを次のフェーズに向けて淡々と直す、そういうエンジニアもいらっしゃいます。いうエンジニアには、「へぇ、そういうコード、好きなんだ、君も書くんでしょ」と、価値観を疑ってあげれば、そのエンジニア自体のモチベーションが下がり、スタートアップ時の背景を伝える人もいなくなり、誰もスタートアップしたくなくなるでしょう。スタートアップを例にしましたが、似たような状況は他でも発生しますので、応用はいくらでも効くと思います。仕事を突然終了させて無意味感を与える一生懸命モノづくりをしてきて、さあ、さらに作るぞー、リリースするぞー、というときに、その仕事が突然中断おしまい。つらいことではありますよね。いえ、それがアクシデントだと確かに悲しいですが、会社の方針とか合理性から来るものであれば、エンジニアもよく理解していますから、気持ちの整理して前向きに考えるようにします。仕事の先にある仕事は明るいなので、そのこと自体よりも、ポイントは「伝える言葉やニュアンス」です。それまでそのエンジニアがやってきたことがまったく意味の無かったことであるってのを強調して伝えてあげれば、モチベーションを下げられます。具体的にどう言うか?はお任せします。できるだけ軽率な言葉を選びましょう。「一生懸命やってきたことの無意味感」を与えることで、受けたショックを前向きな方向ではなく、会社に対する不信感に変化させることができます。その仕事に対してどのくらい情熱を燃やしてきたかどうか?情熱があればあるほど、その落差が激しいもの。今後、そのエンジニアはその会社の仕事で、身を削ってプラスアルファの成果を上げようとは思わないでしょう。エンジニアの仕事柄、そういう場面が多いということです。モチベーションを下げられるタイミングがたくさんやってくるというところです。本質的でないことに時間を取らせる仕組みよーし、がんばるぞー、と意気込むエンジニア。成果を出してくれます。なんとかして成果を出さないようにするためには、本質的でないことに時間を使ってもらいましょう。Aさんが、プログラミングする前に、どうしても「ハサミ」が必要だったとします。ハサミを探しています。誰か戻してないかも」A「じゃあ、大声で聞いてみればいいかな?」C「いやぁ、迷惑かかるから全社メールで聞いたら?」A「でも、メールもそんなしょうもないことで出すと言われそう。いいやもう、買ってきちゃおう」C「じゃあ、会社の備品として申請するのでこれ書いて承認を...」A「いや、もう個人のものとして買おうかと」C「個人のハサミを持ち込んじゃいけないことになってるので」A「なんでピンポイントでハサミだけ!?いいや、カッターで...」C「ハサミで切ったものじゃないと成果として認めないらしいよ」A「むっきゃー、しごと進まねー」まあその後、幸いハサミは見つかりました。今度は「ノリ」が必要で...「ホッチキス」も...A「ふー、やっとプログラム書けるよ...ってもう17時じゃーん(><」ちょと大げさですかね?でも、こういったちょっとしたコスト、当たり前ですが「チリも積もれば」理論が効きます。「テストデータが間違ってて、バグなのかデータ悪いのか判断に時間がかかる...」いくらでもあります。ケースバイケースでたくさんあるでしょうし、別に開発環境だけの話ではないでしょう。