maximum80のブログ

彼らのオフィスはSlackにあった ~非エンジニアでも、開発者達が「一生懸命働いている風」に見える方法~

どうも新田です。
前回のエントリ
エンジニア社員「今月から週3回、昼過ぎに仕事抜けてジムに行きたいんだけど。」 僕「」
を自分が思った以上の沢山の方々に読んでいただき、Twitterやはてブに沢山コメントをよせていただきました。本当にありがとうございます。
その中でブコメにこのような興味深いコメントをしていただいておりましたので、ご紹介させていただきます。

エンジニア社員「今月から週3回、昼過ぎに仕事抜けてジムに行きたいんだけど。」 僕「」 | maximum80のブログ

成果を測る基準の中で労働時間を重要視しないってことだよね。ここの職場では時間以外のチェックポイントがあって、きちんと機能しているのだろう。ゆるくする部分を真似するだけでは痛い目に会うかもね。

2015/11/14 07:25

確かに、おっしゃるとおり、何もしていないわけでなく、かといってガッチガチに「成果」にこだわっている、というわけでもありません。今日はこの「成果」についての考え方と、僕自身がおこなっている“時間以外のチェックポイント”について、具体的に何をしているのか、少しHowTo的な形でご紹介してみたいと思います。

前提状況

  • このエントリは弊社内で開発チームの評価をプロセスで測っているという話ではありません
  • また、「プロセスを評価すべきだ!」という主張でもありません
  • 他人の努力を理解することで、互いの尊重を促進しようという取り組みのご紹介です
  • SlackやGitHubを少し紹介しますが、ツールによる成果の可視化の方法とは多少異なるのでご了承ください

はじめに:「エンジニアは成果主義だ」と言うけれど

残業など「一生懸命働いている雰囲気」は評価すべきではないという風潮

日本ならではの「空気読み」の文化によって、残業して「一生懸命働いている風」に見える人を評価することに対する賛否の記事を散見します。

確かに日本では、結果が出ていなかったとしても「あいつ頑張ってるよな〜。給料あげたろ!」と情に厚くなってしまったり、結果が出ていたとしても仕事を淡々とこなす人に対しては「あいつ仕事やる気ないよな〜。給料さげたろ!」と嫉妬心のようなものが湧いてしまう
…という心理を理解できる方が多いのではないかと思います。
Why Japanese People!!と言われてしまっても仕方がないぐらい、実際どこよりもそんな文化があるのではないかと思います。

とはいえ、「成果至上主義」にも限界がある

それに対して、「エンジニアは成果至上主義」的な言葉や「基本的にエンジニアはパフォーマンスが全てだ」という話もよく聞きます。

確かに、受注して売上を伸ばすのが営業のコミットメントなら、開発者達はプログラムを書いて機能を追加したり、プロジェクトにコントリビュートするのがコミットです。

しかしながら、この「成果」に落とし穴があるのではないかと思います。

なぜなら、自分がその職種に関する深い知識や経験を持っていなければ、何が本当の「成果」なのかが分からないかもしれないと僕自身思っているからです。

具体的な例をあげてみます。

一見成果になりそうな事

  • 書かれたコードが正しく動いている
  • 非常に見た目が良く、ユーザビリティに優れている

一見成果にならなそうな事

  • 特に機能の変化がみられない
  • 想定外の障害が発生してしまった

例えばこのように、エンジニアのアウトプットを定性的に自分の中で成果と考えられるかどうかを整理してみます。
しかし、これらに補足の()をつけて少し視点を変えてみると、たちまちどちらがエンジニアとしての成果なのか、わからなくなります。

一見成果になりそうな事(?)

  • (誰がみても読めないけど一応)書かれたコードが正しく動いている
  • (明らかに他社からの拾いもんだけど)非常に見た目が良く、ユーザビリティに優れている

一見成果にならなそうな事(?)

  • 特に機能の変化がみられない(が、汎用的にいつでも使いまわせるようになった)
  • (他のエンジニアの負担を減らすため、新しいインフラの自動化に挑戦した結果、)想定外の障害が発生してしまった

何が正解かなんてたちまちわからなくなりますよね。

中途半端な成果主義は、もしかしたら、良くないものを成果として評価し、本来評価すべきものを見落とす可能性もあるのではないかと思います。

エンジニアの完全な成果至上主義なんて不可能な気がする(銀の弾丸なんて存在しない)

これは僕自身が無知なだけなのかもしれませんが、エンジニアだって沢山失敗するし、技術がどんどん新しくなっている中で常に戦い続けなければいけない。
そんな中で一部の成果しか評価されなかったり、正しく評価されなかったりしたら、

  • 失敗を恐れる
  • 新しいことに悩み、挑戦しようとしない

ような文化になってしまうのではないかと思うのです。

開発者達の「一生懸命さ」も理解して、応援してみよう

そういった経緯もあり、マネージャーは開発者達が「一生懸命」あれこれ試行錯誤、努力する姿を見ることも大事であって、彼らの成長支援になると思いました。

でもオフィスを見渡しても一生懸命さゼロな社員たち

tak
※注:社員です

oda
※注:社員です

shen2
※注:社員です

boss
※注:インターン生です

誰がどう見てもインターンが一番本気で働いているではないか。
どうなっているんだうちの社員たちは!!!

開発者達が「一生懸命働いている風」なところを覗く超簡単な方法(非エンジニア向け)

一応ここからが本題なのですが、エンジニアの「一生懸命働いている風」の姿を覗こうと思っても、オフィスでは見ることはできませんでした。

実際、営業の方が一生懸命働いている姿は「必死に電話をかけている」「一日に何回も外出する」「受注する」といった部分から感じることができると思いますが、オフィスにいてコードを書いているエンジニアの場合はなかなか一生懸命さに気づけないかもしれません。

しかし、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. とにかく嫌がらせのように通知が来る

真夜中にベッドの中にいても

Photo 1-27-16, 3 47 33 PM

出先にいたとしても

Photo 2-18-16, 2 26 15 PM

このように、
「スマホやタブレットのNotification(プッシュ通知)」=「開発者達が努力している姿」
に変換することで、これでもかって程、彼らが一生懸命働いている風な姿をなんとなく見ることが出来ます。

2. 誰がいつ何をしてくれているのかがわかる!

また、別にSlack自体は開かなくても、通知画面を見るだけで

  • [いつ] ○○:○○AM
  • [何をした] Pull request submitted
  • [誰が] by ○○

が一目瞭然になります。
その中で、もし何か気になることがあれば、GitHubを見にいけばすぐに何をしているかがわかるようになります。

3. 「いつも何してんだよ、あいつ」→「なんだかいつも夜遅くまでありがとう」になる

いろんな事に試行錯誤してくれてることがログを見るだけで理解できるので、
具体的な成果まではわかりませんが、なんとなく
「夜遅くまでいつも頑張ってくれてるな〜」という気分になることが出来ました。

Screen Shot 0028-02-18 at 8.52.22 PM

room内で疲れてそうなエンジニアにはたまに小粋なGif画像を。
まさに疲れた営業社員にコーヒーを差し入れするような気分になります。

でもやっぱり何だかんだでHRT(謙虚・尊敬・信頼)

HowToのような形でのご紹介でしたが、なんでも全てにおいてHRT(謙虚・尊敬・信頼)が欠かせないと思います。
例え同じ方法をとったとしても、すべての人への尊重や信頼、想いがないと上手く機能はしないのではないかと思います。

どんな制度や仕組みよりも「謙虚・尊敬・信頼」の想いが重要

であることに尽きるのではないかと思います。
HRTについては、以下の書籍を参考にしています。名著ですので、是非一読をオススメします。

それでも、弊社の活動の発信やHowToの紹介がヒントになることで、少しでも多くの企業の開発チームとそれ以外の方々の良質な関係構築、改善に繋がり、もっとエンジニアの方々が活躍できる環境の構築に少しでも貢献できれば幸いです。

エンジニア社員「今月から週3回、昼過ぎに仕事抜けてジムに行きたいんだけど。」 僕「」

新田です。

最近渋谷区の条例で同性パートナーシップの証明書が発行が話題になったり、各所で 多様性 という言葉が注目を集めてますよね。

「指示待ち人間」はなぜ生まれるのか?
有能な人たちが「働きたくない」と嫌がる会社の特徴。

また最近Facebookで上記のような記事をよくみかけまして、ダイバーシティ・マネジメントについて自分でも考えていることや、同じような壁にぶつかった経験があるので久しぶりに投稿してみようと思います。

エンジニア社員「これから週3回、昼過ぎに仕事抜けてジムに行きたいんだけど。」 僕「」

タイトルにしてみましたが、今からちょうど一年前ぐらいに実際に社内であった出来事です。弊社で働いているカナダ出身のエンジニアの社員から、或る日突然このような提案を受けました。

会社の業態、職種にもよるとおもうのですが、殆どの場合

「え、ちょっと何言ってるかわからないんですが。。」

となってしまうのではないかな、とおもいます。

もちろん僕も同様で、今まで弊社は9時〜18時出勤、勤務中は営業外出時以外は基本的にお昼の12時〜13時を除き席に着席して働く、というのが当時会社として “常識” だったので、その提案を初めて聞いた時は相当戸惑いました。

エンジニア社員「多分外出が3時間程度になると思うから、その代わり、ジムに行った日は6時までのところを9時まで働こうと思うんだ。」

僕「ah hah?(あ、なるほど。もしかしたら彼は自分とは違った自己管理方法を提案しているのでは?)」

その社員はとても真面目で、熱心に働くことで有名な社員だったですし、その時のあまりにも真剣な顔つきで彼からの提案を受けたので、

僕「お、オッケーオッケ!(とりあえずやってみるか。)」

といった流れで、正直上手くいくかはこの時全くわかりませんでしたが、とりあえず社内で調整を進め、まずはトライをしてみることにしました。

ある意味ここが組織のターニングポイントだったのかも?と今となっては思っています。

人の意見を許可ばかりしてたら、組織を管理できないのでは? → 驚くほどチームが活性化

1. そもそも管理など不要だった

初めは 多様性を受け入れること=マネージャーとしての自覚がなく人をついてかせることが出来ない

と捉えていました。
そのため、正直いろいろな意見に耳を傾けるのが怖かったところもありました。

しかし驚くべきことに、こちらが相手の考えを理解し、受け入れることができると、自然と相手も自分自身の考えを理解しようとしてくれました。

なのでこちらからわざわざ「管理をしよう!」などせずにも、自分の考えを汲みとってくれて自発的に行動してくれるようになりました。

2. 自分の力では絶対に気づくことの出来ない正解を知れた

ジムに通うことを許可したことは、結果としてエンジニア達が常にパフォーマンスを発揮し続けることや、リフレッシュして問題解決に結びつける事を促進する良い結果となりました。

今では
「彼はジムを週3回欠かさず通っていて、自己管理ができていて素晴らしい」
と、周りからも更に信頼されるようになりました。

その他にも、周りの価値観を理解し受け入れるようにするだけで

  • リモートワークで効率よく働けるようになる
  • 家族との時間やプライベートの時間を大切にしようと思うようになる

などなど、外部に公開できるほどの知見やノウハウ、独自のやり方が構築されていたり、自分自身ももっと改めなければならない視点に沢山気づくことが出来ました。

その中で 僕自身が組織づくりで実際に何をしたかというと、具体的な施策や提案などはこちらからは何もせず、相手からの提案をオッケーして、何をしたのかを理解するよう努めただけでした。

多様性を受け入れるために意識している考え方

もちろん僕は普通の日本人で、かつある程度凝り固まった価値観、バックグラウンドの中で生活しているので、いついかなる時も仏のように多様性を受け入れるスタンスでいつづけられるわけではありません。
(基本的には頭の固い人間だと思っています。)

しかし、今のメンバーと仕事をしていく中で、「海外出身者だから」とか「日本人だから」とかではなく、純粋に一人一人が「自分とは違った正解(個性)をもった仲間」と捉えることで、うまく自分自身に落としこむことができています。

そう捉えるために、特に以下の様な教訓を日々意識して仲間と向き合うように注意しています。

1. メンバーはみんな、自分がまだ知らないやり方・意見・正解を必ず持っている

相手を受け入れられない時は基本的に
「こいつ何考えてんだよ?」
と、相手に対して懐疑的になってしまうのが原因だと思っています。
そのため、人に対して不安に思った時は
「まだ自分が相手の正解を理解できてない」
と考える事で、
「相手は自分に何を伝えようとしてくれているのか」
と捉えることが出来るのではないかと思います。

2.言うことを聞いてくれない、のではなく、聞きたくないと思わせてしまっている

「どうして自分自身がこれをやれって言ってるのに、思ったようにやってくれないんだ!」

という時も結構ありましたが、こういったケースは大概

「お前に言われていることはやりたくない」

と思われてしまっているのが事実だと思います。自分としては腹ただしい事かもしれませんが、第三者からの視点でとらえた時に、”聞きたくないと思わせてしまっている自分”ってマネージャーとしては純粋にスキル不足なのではないかと。
そこを

「自分が相手の中での正解を理解できてないから、相手に自分の正解を理解してもらえてない」

と考えられるようになると、「自分自身が周りを巻き込めるように成長しなくては!」と、成長意欲も増すのではないかと思います。

3.「この人に話しても無駄」って思われたらマネージャー失格

周りから何かアドバイスや指摘をもらった時、上下関係であったり、個人のプライドが邪魔して、相手からの意見を素直に聞こうとせず、
「いやいや、違うから。こうだから」
と、言ってしまって相手の意見を遮ってしまうことがあります。或いは何か悪い報告をされた時に、頭ごなしに相手のせいにしてしまうことがあります。
このような相手の意見を遮断したり、否定することで、
自分の視野でしか物事を判断できなくなってしまう ので、失敗する確立が高くなってしまうのではないかと思います。なので
「あ、この人に話しても無駄だな」
とか
「この人に言って怒られるの嫌だから言わないでおこう」

と思われた瞬間が、ある意味マネージャーとして終わりの瞬間なのではないかと思っています。

さいごに

「新しい価値観に触れることを恐れずに楽しみましょう」

とある別の社員からも勧めがあり、最近少しずつではあるのですがコーチングについて勉強し始めました。

前述してきた考え方は、ある意味コーチングにもとづいているものなのではないかと思います。また多様性を受け入れるためにコーチングを学ぶことはとても良い方法なのではないかと思います。

人の気持ちがわかる人、わからない人~アドラー流 8つの感情整理術~

こちらは非常におすすめの書籍です。自分自身が本当にいろんな事を理解する上で、コーチングのやり方にはお世話になっております。もし良かったら購入してみてください。(特にアフィとかではないのでご安心を)

またベンチャーの環境で共に働いてくれている仲間同士なのですから、どうせ働くなら啀み合ったり罵ったりするのではなく、

「新しい価値観を受け入れることを恐れずに楽しむ!!」

というスタンスで仕事できるのが理想なのではないかな?と思います。

弊社を例にしても、以前までは様々な働き方や価値観を受け入れられず、ギクシャクした時もありました。しかし、今となっては社内では

時間や場所にかかわらず、開発チームが会社の為を考えて本気で働いてくれている
と他の職種の方々も思ってくださっているし、

アポを獲得したり契約を獲得した営業マンに対して、開発のスタッフも全員が拍手を送る(感謝を伝える)

というのが自然発生するようになりました。
ここまで異なるバックグラウンドを持った人達が集まり、事業を推進している会社というのは割りと珍しいし、面白いのではないかと思っています。

そんなわけでちょっとだけ宣伝

そんは弊社でプロジェクトマネージャーとして働いてくれませんか?

ちょっと宣伝となってしまいますが、そんなGiveryという会社では多様性をもっとも尊重しながらプロダクトを創ることに挑戦し続けています。

正直まだ僕自身も正解はわかっていません。

現在自身が関わっているプロジェクトのマネージャーを募集しておりますので、もし会社に少しでも興味を持ってくださいましたら、是非気軽に以下よりご応募ください。
これからの働き方について、組織について、事業についてなどなど、直接お話ししましょう!

また、是非応援のほうもよろしくお願いいたいします!

エンジニアを評価しようとして僕が陥った3つの落とし穴

ブログエントリの目的

昨年のブログ炎上も含め、僕はこの一年間で 「どのようにしてエンジニアのパフォーマンスを評価して、エンジニアの方々が働きやすい環境を構築するか」 というのを考えてきました。様々な本をオススメいただいて購読したり、アドバイスをいただいたりしてきました。
そうして、結果としてタイトルのように 自分自身が評価をしようとして、沢山嵌ってしまった落とし穴があったことに気づいた ので、少しでも多くの方が自分とは同じ失敗をしないように、このブログを書きます。(もしかしたらエンジニアだけではなくあらゆる職種に当てはまるかもしれません。)

評価をしようとして僕がやろうとしていたこと

エンジニアを評価をしようとして、以下のような方法を取ります。
(※これは、実際に昨年まで僕がやろうとしていた事をそのまま再現しています。)


1. まずエンジニアのスキルを評価するための試験問題を作成する(検定やアルゴリズムテスト) 2. 社内で一斉にテストを実施(オンラインエディタを使って1時間とかで)して、 社内での平均点や統計データを出す 3. そのデータを元に、求職者や新卒に応用し、相対的にスキルを評価する

このやり方で、

  • 最低限の技術レベルやコードの書き方等を理解できる
  • アルゴリズム等の数学的知識を理解できる
  • 相対的な技術力の差を判定することが出来る(例えば採用時のコーディングテスト等)

といった部分はあったものの、この方法だけに頼ってしまう事によって様々な落とし穴にハマってしまう恐れがあることに気づきました。

試験による評価をしようとして陥った3つの落とし穴

1. クリエイティビティを評価できなかった

ググればいいことを覚えることを助長させてしまう→精密機械で良い

これは、エンジニアに限った話だけではなく、もしかしたら様々な分野にも共通するのかもしれませんが、ある特定の知識を問う問題を作り、試験として実施して人の知識量を測るというのは、ある意味 ググってわかることをとにかく覚えて欲しいと主張していることに繋がっていました。これは、はっきり言って都度調べれば済む話ですし、機械のほうが圧倒的に人間よりも量も質もスピードも優れているので、人に問う意味があるのか、ということに気づきました。
そして結果としてクリエイティブな事を考えるより、既に誰かが知っていることをいちいち覚えなくてはならないため、オリジナリティや課題解決に活かそうとする脳みそがなくなってしまい、機械に近い人達を評価する助長してしまっていました。

2. 新しい技術への柔軟性を評価出来かなった

可変性に対応できない→老朽化した知識や技術を評価

例えば英語等の語学力であればTOEIC等を受けて、ある程度の定量的な語学スキルを評価することは可能だとは思います。しかし、ソフトウェアの場合、語学とは異なり技術は日進月歩で進化しています。昨日までのベストプラクティス(英語で云う汎用句)が今日や明日ベストプラクティスとは限りません。試験化した問題をとくための暗記をすることで、結果として “変化に柔軟に対応することを除外してしまう” という落とし穴に気づきました。

3. 実務パフォーマンスの低下に繋がってしまった

テストの結果で評価をする→実務無視でエンジニアのモチベーション低下

実務でのパフォーマンスは理解しようとせず、テストの結果を評価の主軸にしてしまったので、それは “僕たちはあなた達の実務は理解できないから、テストの結果で評価するよ”と言っているのと同じでした。
もし、そのような事になってしまっては、エンジニアは評価されるために、実務を放棄(或いはテキトーにこなす)して、テストの猛勉強をするか実務が評価される会社を選ぶでしょう。結果として、実務に支障が出てしまうかもしれません。
また、新しい技術に対応させるためには、常に問題をアップデートしていかなければなりません。そうなれば、評価をされるためには 定期的にテストを受け続けなければなりません そうすると、より一層実務よりもテストのためのインプットになってしまい、更に実務に支障をきたす結果になってしまうという負の連鎖に陥ってしまったかもしれません。

エンジニアの真のパフォーマンスや開発力を理解するために必要な前提条件

1.カンニング大歓迎!正しくカンニングできているかのほうが重要

この情報化社会においてはカンニングをせずに自ら全てを暗記するよりも、いかに素早く優れて正しい情報を理解出来るかのほうが重要です。そのため、「何も見ないで暗記をして、知識量を問う」のではなく、「全ての情報にアクセスしてもらい、あらゆる問題を解決してもらう」ほうが重要だと思います。インターネットが常に身近にあって、様々な情報が点在している中で、 正しい情報に素早くアクセスすることが出来るか が実務では求められるかと思います。そのような点で、ソフトウェアの領域においては海外発の技術等を理解するためにも、語学力が求められてくるのではないかと思います。
暗記をして知識を問うような試験では、上記のような実践力まどを測る事は出来ません。

2.正解が常に変わる!!今日のベストプラクティスは明日のそれとは限らない。

「先週使っていたフレームワークがバージョンアップし、全く別の仕様になってしまった。。。」という事はよくあることで、多くのエンジニアが頭を悩ますと思います。ソフトウェアを取り巻く技術は日進月歩で可変性を持っているので、ここで素早く対応できる力が実務では必要になってくるのではないかと思います。 どのようにして進化し続ける技術に対して対応をし続けるか、更には技術を進化させることが出来るか(例えばOSSコントリビューション等) を見極める必要があるのではないかと思います。それにはただカンニングして技術を使いこなすだけではなく、調べた上で技術に対する深堀りや根本を理解をしようと努めること等が必要になってくると思います。
試験のための試験勉強では、このような可変性への対応をすることは難しいでしょう。

3.自前のPCや事前にセッティングした独自環境もエンジニア最大の装備でありスキルの一つ!

試験での課題受験では、例えば提供側が用意をするPCで受験をするのが基本だと思います。
しかし、開発者にとっては、自前の自分オリジナルに設定されているPCも装備であり、最強の武器です。武器を強化するために沢山の時間を費やして研ぎ澄ましているにもかかわらず、試験で何も使えないのはエンジニアにとっては 「あなたの武器を全て捨て、このモンスターを倒しなさい」 と言っているようなものではないかと思います。エンジニアの真の実務を測るのであれば、これら エンジニアが磨いてきた自前のアイテム、武器を含めてソフトウェア開発力 とすべきなのではないかと思います。

まとめ

僕自身がこれまでの経験を元に「陥った落とし穴」と「エンジニアのパフォーマンスを理解するために必要なこと」をまとめてみました。もし、エンジニアが働きやすい環境にするのであれば
1. 前提条件を元に実践力を測る事
2. 実務パフォーマンスを正しく評価出来るように努めること
が大事なのではないかと思います。とにかくエンジニアが働きやすい環境や、成長できる環境を構築して企業の成長を支援するために、このような発信をすることで、多くのITに携わる経営者やマネージャーの方々の力になれれば思っています。
様々な方からのフィードバックやご意見もお待ちしております。

まず「人」として誠実であれ ~”「エンジニアをつくる」という理念掲げていたら、エンジニアが社内からいなくなった件”から一年が経過して学んだたった一つのこと~

背景

「エンジニアをつくる」という理念掲げていたら、エンジニアが社内からいなくなった件というブログを書く

発端は今からちょうど一年前の2014年6月13日。同年の5月末日に、様々な会社の事情・背景から社内の開発を担当するチームが解散しました。そして、それまでエンジニアのキャリア支援事業を担っていた自分ですが、会社の開発体制の文化構築から、開発組織の再構築を一任されました。
意を決し自社のプロモーション目的であるブログエントリを書きました。それがこちらです。

そして炎上

などなど、様々な意見を寄せていただきました。

簡単にまとめると、「よし!これから自分が沢山のエンジニアを巻き込んで新しい事業を展開していくぞ!」 っと気合を入れていたのですが、複雑で奥が深いこの業界に対し、自分自身の業界に対する知識の無さ・浅はかさから、楽観的に”釣り”とも取れるようなタイトルとともにただ勢いのみでブログを書いたことによって、この業界で働く様々な方に不快を与えてしまい、こてんぱんに叩き潰されたという話です。

あれからちょうど一年が経ちましたので、この一年間で自分自身が学んだことを改めてブログにまとめてみたいと思います。

何がいけなかったのか

純粋に勉強・知識不足

IT業界を中心としたソフトウェア開発における開発生産性の向上や、開発組織文化の構築という分野においては、海外をはじめとした様々な取り組みがあります。
事業やサービスだけではなく、研究分野としても、ソフトウェア工学・モチベーション理論・オープンイノベーション・メンタルヘルスケアなどなど視点や分野は多種多様です。

自分自身が事業を展開する上で、全く先人の方々の築き上げている業界背景や学問分野を無視し、己の観点のみで事業を展開しようとしてしまった結果、 「何こいつは黙々と銀の弾丸作ろうとしてくれちゃってんの?」 という状態になってしまっていました。

自分の「正しい」を押し付け、周りに対して排他的であった

勉強不足なだけではなく、自分の意見を突き通すために 「理想のエンジニア像」 とかを定性的に掲げていました。もしそうだったとしても、最低限学術的な裏付けや根拠があったり、絶対的なものがあれば良いのかもしれませんが、そうでもないのに 自分自身の価値観を押し付けようとしていた のです。これは、どう考えても危険だとしか言いようがありません。

人の成長を支援する立場の人間として必要であるたった一つの重要なこと

これらの自分自身の未熟さ悔い改め、様々な事を勉強し、事業としてもリスタートしてきました。(具体的にどのような事をしてきたかは今回のメインではないので別エントリで改めてまとめたいと思います)
この一年間を通じて自分自身が学んだたった一つの重要だと思うことは、大前提としてまず

「人」として誠実であれ

という事なのではないかと思います。「自分自身は新しい事業を展開しているから!」とか「ベンチャーだから!」とか「俺はこれまでにこんな経験を積んできたんだから!」とか「エンジニア」だとか役職とか年齢とか全て関係ありません。それ以前の問題です。

またこの一年で、LEAN・MVP・KPT・Scrum・TDD・Hackathonなどなど、様々ないわゆる開発を迅速に進めやすい取り組みを学び、実践してきましたが、それはあくまで 手段にしかすぎません。

僕は 「この手段を取れば、組織や事業は良くなる」 といった勘違いを生むのを避けるために、敢えて本エントリーからは技術的なノウハウは一切書かないようにしたいと思います。その手の内容はQiitaに別途更新していこうと思っています。

「人として誠実である」とは具体的にどのようなことなのか。以下3つに分けてまとめてみたいと思います。

全ての人々にHRT(謙虚・尊敬・信頼)をもって接すること

Team Geek~Googleのギークたちはいかにしてチームを作るのか~

という本にこのHRTという言葉が書かれています。自分はこの本に巡り会えて幸せです。
まず自分自身に大きく欠けているのがこの概念でした。

まず自分に過信せず、常に謙虚な姿勢で物事に取り組めば、自分が間違っていた失敗に直ぐに気づけます。「もっと勉強しなくては!」と気づくことが出来ます。向上しようと思うことが出来ます。

相手への敬意があれば、様々な方と意見を出し合うことが出来ます。自分にはない視点に気づくことにつながります。

そして、相手への信頼の想いがあれば、自分だけの考えに凝固まらず、相手のやり方を重んじる事ができます。そして、それを力に変えることが出来ます。

相手の考え・意見に常に耳を傾けること(価値観の多様性を受け入れること)

HRTの「信頼」ともかぶる部分もあるのですが、相手への接し方に加えて、受け入れることの重要性も誠実さの一つなのではないかと思います。

「価値観の多様性を重んじる」とは、例えば自分のケースに例えると、
誰もがスーパープロフェッショナルのグローバルクリエイティブリーダーなエンジニアを目指し、死に物狂いで働き社会に価値を貢献し続けることを正義としているわけではない

という事です。1年前のコメントを下さった方の中に、「お前はアマチュアスポーツというものを理解していない」とおっしゃっていただいた方がいました。このコメントにあるように自分自身が多様性を受け入れられてないと、視野が狭くなってしまうのだと思います。

また、だからといって排他的になってはいけません。 自分とは考え方違う=無能 としてはいけません。自分とは違った価値観だったとしても、相手は絶対に組織に対して何か貢献をしてくれているんです。決して成長したくないわけでもないんです。

でも、自分とはペースや優先順位、捉え方が違うだけなんです。それを理解すること、受け入れることが多様的なチームを構築したり、人の成長を支援する上で重要な事なんだと思います。

自分自身の想いを真っ直ぐ伝え続けること

今書いてきたことができていれば、逆に自然と周りの人達も「自分自身の想い」も尊重してくれるようになります。力を貸してくれるのではないかとおもいます。ただ、多様性を受け入れることと「相手の言いなりになること」は違います。

相手からも自分自身が尊敬される存在であり続けるために、
常に曲げない軸を持ち、自分自身が崇高な志を持ち、夢や達成したい目標、成功を伝え先導し続けること

が重要です。そのために先陣を切って自分自身がトライアンドエラーを繰り返していかなくてはなりません。そうすると、見かねた自分よりも、圧倒的に力を持った仲間たちが「ここは俺に任せろ」と手を差し伸べてくれます。

明確なレールは敷くけど、人それぞれのペースや進み方を理解して、皆で前進していく
というようなイメージです。

結果

これまでにない様々な方々との仕事につなげることが出来ました

jphacks
これまでの事業では、主にベンチャー企業の方々のみをメインに仕事をさせていただいていたのですが、例えばJPHACKSでは、国立大学を始めとした公共機関の方々や、国内外大手企業の方々ともお仕事をさせていただけるようになりました。これまでの自分達だけでは絶対に出来なかったような観点やアプローチで、自社のメンバーだけでなく、お客様や関係者の方々と共に「エンジニアの成長エコシステム」の実現に向けた取り組みとして実施させていただいております。

自分よりも圧倒的に優秀な仲間たちに恵まれました

git
一年間で、15人を超える開発の仲間達がジョインしてくれました。インドやアメリカでも仕事をしてくれているスタッフもいます。また、みな十人十色で、様々な自分にはない視点や価値観を持った仲間たちが開発を支えてくれるようになりました。

終わりに・謝辞

伝えたいこと

仕事や自身を通じて、僕は本当にこの業界をとにかく良くしたい。と考えております。
また、この業界を変えていくには、「エンジニアの成長エコシステム」を創造し、テクノロジーを価値に変える事業を世の中に生み出す人々を沢山輩出していくこと、が我々のミッションであるということは全く変わりありません。
ただこのエントリによって、起業をされている方や事業の展開をされている方、読んでいただいた様々な方に
どうか、決して自分とは同じミスをしてほしくない。
と切に願い、少しでも誰かの力になればと思い、正直恐れもある中でブログエントリをすることを決意しました。

謝辞

結果として、一年がたった今でも、この業界で今のような仕事を続けさせていただいているのは沢山の方々の支えがあったからだと思っています。また、炎上を通じて、自分自身白紙に振り返ることができ、上記のように会社としても事業としても躍進をすることが出来ました。

  • 一年前にコメントを寄せてくださった様々な方々
  • 共に会社を支えてくれている全ての従業員
  • お付き合いをしてくださっている沢山のお客様や関係者の方々

全ての方々に感謝を述べたいと思っています。
本当にありがとうございます。

会社や事業としても、個人としても目指すべきところや、やらねばなぬ事は山ほどあり、まだまだ未熟ではございますが、組織としても開発者や事業を推進する上で手本となれるような環境を目指し、そして事業としても全ての人に成長を支援できる価値のある事業を展開してまいりたいと考えております。

皆様引き続き何卒よろしくお願いします。

Copyright © 2016 maximum80のブログ

Theme by Anders NorenUp ↑