「エンジニアは成果主義だ」と言うけれど
どうも新田です。 前回のエントリ エンジニア社員「今月から週3回、昼過ぎに仕事抜けてジムに行きたいんだけど。」 僕「」 を自分が思った以上の沢山の方々に読んでいただき、Twitterやはてブに沢山コメントをよせていただきました。本当にありがとうございます。 その中でブコメにこのような興味深いコメントをしていただいておりましたので、ご紹介させていただきます。
エンジニア社員「今月から週3回、昼過ぎに仕事抜けてジムに行きたいんだけど。」 僕「」 | maximum80のブログ成果を測る基準の中で労働時間を重要視しないってことだよね。ここの職場では時間以外のチェックポイントがあって、きちんと機能しているのだろう。ゆるくする部分を真似するだけでは痛い目に会うかもね。
2015/11/14 07:25
確かに、おっしゃっていただいたとおり、何もしていないわけでなく、かといってガッチガチに「成果」にこだわっている、というわけでもありません。今日はこの「成果」についての考え方と、僕自身がおこなっている"時間以外のチェックポイントがあって、きちんと機能している"の部分について、具体的に何をしているのかについて、少しHowTo的な形でご紹介してみたいと思います。
前提状況
- このエントリは弊社内で開発チームの評価をプロセスで測っているという話ではありません
- また、「プロセスを評価すべきだ！」という主張でもありません
- 他人の努力を理解することで、互いの尊重を促進しようという取り組みのご紹介です
- SlackやGitHubを少し紹介しますが、ツールによる成果の可視化の方法とは多少異なるのでご了承ください
はじめに：「エンジニアは成果主義だ」と言うけれど
残業など「一生懸命働いている雰囲気」は評価すべきではないという風潮
日本ならではの「空気読み」の文化によって、残業して「一生懸命働いている風」に見える人を評価することに対する賛否の記事を散見します。
確かに日本では、結果が出ていなかったとしても「あいつ頑張ってるよな〜。給料あげたろ！」と情に厚くなってしまったり、結果が出ていたとしても仕事を淡々とこなす人に対しては「あいつ仕事やる気ないよな〜。給料さげたろ！」と嫉妬心のようなものが湧いてしまう、という心理を理解できる方が多いのではないかと思います。 Why Japanese People!!と言われてしまっても仕方がないぐらい、実際どこよりもそんな文化があるのではないかと思います。
とはいえ、「成果至上主義」にも限界がある
それに対して、「エンジニアは成果至上主義」的な言葉や「基本的にエンジニアはパフォーマンスが全てだ」という話もよく聞きます。
確かに、受注して売上を伸ばすのが営業のコミットメントなら、開発者達はプログラムを書いて機能を追加したり、プロジェクトにコントリビュートするのがコミットです。
しかしながら、この「成果」に落とし穴があるのではないかと思います。
なぜなら、自分がその職種に関する深い知識や経験を持っていなければ、何が本当の「成果」なのかが分からないかもしれないと僕自身思っているからです。
具体的な例をあげてみます。
一見成果になりそうな事
- 書かれたコードが正しく動いている
- 非常に見た目が良く、ユーザビリティに優れている
一見成果にならなそうな事
- 特に機能の変化がみられない
- 想定外の障害が発生してしまった
例えばこのように、エンジニアのアウトプットを定性的に自分の中で成果と考えられるかどうかを整理してみます。 しかし、これらに補足の（）をつけて少し視点を変えてみると、たちまちどちらがエンジニアとしての成果なのか、わからなくなります。
一見成果になりそうな事（？）
- （誰がみても読めないけど一応）書かれたコードが正しく動いている
- （明らかに他社からの拾いもんだけど）非常に見た目が良く、ユーザビリティに優れている
一見成果にならなそうな事（？）
- 特に機能の変化がみられない（が、汎用的にいつでも使いまわせるようになった）
- （他のエンジニアの負担を減らすため、新しいインフラの自動化に挑戦した結果、）想定外の障害が発生してしまった
何が正解かなんてたちまちわからなくなりますよね。
中途半端な成果主義は、もしかしたら、良くないものを成果として評価し、本来評価すべきものを見落とす可能性もあるのではないかと思います。
エンジニアの完全な成果至上主義なんて不可能な気がする（銀の弾丸なんて存在しない）
これは僕自身が無知なだけなのかもしれませんが、エンジニアだって沢山失敗するし、技術がどんどん新しくなっている中で常に戦い続けなければいけない。 そんな中で一部の成果しか評価されなかったり、正しく評価されなかったりしたら、
- 失敗を恐れる
- 新しいことに悩み、挑戦しようとしない
ような文化になってしまうのではないかと思うのです。
開発者達の「一生懸命さ」も理解して、応援してみよう
そういった経緯もあり、マネージャーは開発者達が「一生懸命」あれこれ試行錯誤、努力する姿を見ることも大事であって、彼らの成長支援になると思いました。
開発者達が「一生懸命働いている風」なところを覗く超簡単な方法（非エンジニア向け）
一応ここからが本題なのですが、オフィスで働いている社員の「一生懸命働いている風」の姿を覗こうと思っても、オフィスでは見ることはできませんでした。
しかし、Slackを覗くだけで、簡単に開発者たちの新しいことに対する積極果敢な姿に気づくことが出来ました。
もし、プロジェクトのマネージャーや開発者と関わる仕事をしている人で、開発者との関係がうまく構築できてない場合は、同じ取り組みを実施してみると良いかもしれません。
1. Slackの分報を導入する
簡単にまとめると、Slackの分報というのは
- 「今やっている作業」や「今困っていること」を書く
- 感情的なこと、プライベートなことも自由に書いていい
- 他のメンバーが分報に困ってることを書いていたら助け合う
というものです。エンジニアが「今何をしているのか」を文字で、Twitter的に伝え合う仕組みです。
詳しくは以下の記事を参照してください。 - Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜 Problemが10分で解決するチャットを作ろう - slack分報を導入してみた
2. GitHubとSlackを連携させる
GitHubと連携して、commitやPull Requestがあるたびに、とにかくSlackに通知するチャンネルをつくります。
参考記事 - slackとgithubを連携させる
3. 自分のモバイル端末へのプッシュ通知をONにする
そして、普段手元に持ち歩いているモバイル端末にSlackをダウンロードして、通知設定をONにします。 たったこれだけです。
その結果
1. とにかく嫌がらせのように通知が来る
「スマホやタブレットのNotification（プッシュ通知）」＝「開発者達が努力している姿」
に変換することで、これでもかって程、彼らが一生懸命働いている風な姿をなんとなく見ることが出来ます。
2. 誰がいつ何をしてくれているのかがわかる！
また、別にSlack自体は開かなくても、通知画面を見るだけで
- [いつ] ○○:○○AM
- [何をした] Pull request submitted
- [誰が] by ○○
が一目瞭然になります。 その中で、もし何か気になることがあれば、GitHubを見にいけばすぐに何をしているかがわかるようになります。
3. 「いつも何してんだよ、あいつ」→「なんだかいつも夜遅くまでありがとう」になる
いろんな事に試行錯誤してくれてることがログを見るだけで理解できるので、 具体的な成果まではわかりませんが、なんとなく 「夜遅くまでいつも頑張ってくれてるな〜」という気分になることが出来ました。
でもやっぱり何だかんだHRT（謙虚・尊敬・信頼）
HowToのような形でのご紹介でしたが、なんでも全てにおいてHRT（謙虚・尊敬・信頼）が欠かせないと思います。 例え同じ方法をとったとしても、すべての人への尊重や信頼、想いがないと上手く機能はしないのではないかと思います。
HRTについては、以下の書籍を参考にしています。
[amazonjs asin="4873116309" locale="JP" title="Team Geek ―Googleのギークたちはいかにしてチームを作るのか"]
それでも、弊社の活動の発信やHowToの紹介がヒントになることで、少しでも多くの企業の開発チームとそれ以外の方々の良質な関係構築、改善に繋がり、もっとエンジニアの方々が活躍できる環境の構築に少しでも貢献できれば幸いです。
