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