maximum80の日記

「Empowering Engineers!! 世界中を楽しく働くエンジニアで満たす」を実現するための事業を展開しています。

エンジニアが技術面接に臨む上で意識すべき3つのポイント

技術選考の導入と種別

新田です。 皆さんも聞き慣れているかもしれませんが、 エンジニアとして就職活動を展開しているのであれば、 ほとんどのケースで訪れるのが、近年多くの会社で取り入れられている 「技術選考」 です。

日本企業で導入が進む技術選考

Googleなどの海外のIT企業がエンジニアの採用に際に導入をしていた 「テクニカルインタビュー」というものが、日本企業にも近年導入され始めています。

背景としては、倫理憲章に伴う就職活動時期の「遅延化・短期化」が進んでくる中で、 企業においては選考の効率化がテーマとなってきています。

その中で、ことエンジニア採用における企業が最も効率化すべき点が「スキルマッチ」となっています。 そうして、多くの企業が近年様々な方法で導入しているのが、この技術選考です。

技術選考の内容

技術選考にはいくつかの種類や方法がありますが、 大きく分けると以下の4種類に区別されます。

形式 \ 選考フェーズ 課題 面接
コーディング codecheck ホワイトボードコーディング
成果物提出 GitHub採用 技術面接(これまでの開発物の発表・説明)

それぞれの技術選考についての具体的な内容や特徴については、別エントリにて説明します。 今日お話する点は 技術面接 です。

技術選考とは、選考過程において面接時に、これまでの開発成果物(GitHubリポジトリ等)を用いて、 成果物における説明や質問に回答する形式の面接を実施する選考のことです。

選考フェーズが進んでいる方も多くいる中で、 この技術面接における質問をよくされるようになりましたので、 今日はこの技術面接で意識すべき3つのポイントについて紹介したいと思います。

技術面接で意識すべき3つのポイント

1,成果物そのものではなく成果物を作った”あなた”自身を知りたい

成果物の説明を要求されると、エンジニアである皆さんは 手間ひまかけて制作した成果物を熱心に説明したくなるでしょう。

しかし、今自分自身が置かれている場所は、 成果物発表の場ではなく技術面接である、ということを念頭に置きましょう。

端的にいうと、企業の人達は「成果物そのものには興味がない」ということです。 (※目的が違うよ、という意味で)

企業の人達が知りたい事は成果物を作ったあなた自身です。

例えば、JPHACKSとか何かしらのハッカソンでチーム開発したものを成果物として発表するとします。

コンテストやハッカソン内でプレゼンしたように、プロダクトそのものについてを説明したくなってしまいがちですが、 企業の人達が最も気にしているのは「それで、あなたはどこの役割を担当して、どのような貢献をしたのか」という部分です。

成果物プレゼンではなく、自分プレゼンであることを忘れないように、意識してみてください。

2, 何の技術を使ったかよりも、なぜその技術を使ったのかを知りたい

成果物のプレゼンでは、「どのような技術を使ったか」というような技術スペックについても聞かれると思います。

もし、新しい技術や挑戦していたりするのであれば、 Docker、AWS、Reactなど、近年モダンとされている技術スペックを並べたくなるかと思います。

ここで企業が気になっているのが、「なぜそれを利用しようと思ったのか」です。

会社でプロダクトを開発する場面においても 技術革新やプロダクト成長に伴う技術アップデートは必ずおこります。

  • 機能拡張に耐えうる用に、また一から設計し直して、新しい言語やフレームワークで作り直そう
  • 言語やフレームワーク自体のバージョンアップデートがあったから、自社のプロダクトも更新しよう

などなど、エンジニアは日々技術進化と向き合うのも仕事の一つです。

自社で活躍することができるエンジニアかどうかという点においては、 技術者としての嗅覚・センスが問われています。

なぜなら、会社は 技術負債をつくりたくないから です。

実際にその技術を使ってみてどう感じたのか。

言語特性やフレームワークの利便性をどう感じたか、また他のフレームワークと比較すると利点や欠点は何か。

誠実にその技術と向き合って感じたことを伝えるように意識してみてください。

理由なく「とりあえず友人におすすめされた」とか「聞いてみたからやってみたかった」 のであれば、変に知ったかぶりをするのではなく、素直にそれを伝えるのが良いかと思います。

3, 今の技術スキルではなく、技術ポテンシャルを知りたい

これが最も抑えておくべき視点です。

技術面接において「まだ自分が出来ていないこと」や「自分の技術レベルの低さ」を引け目に感じる必要は一切ありません。

学生であれば、就業経験のないエンジニアが、プロとして現場で5年、10年働いているエンジニアよりもスキルが高いということは殆ど無いと考えて良いと思います。

趣味や学業でエンジニアやるのと、仕事でエンジニアやるのとでは大きく異なります。

なので、企業は今のあなたのスキルではなく、 会社に入社した上で技術を伸ばせていけそうかどうか についてを知りたがっていることを意識しましょう。

そのため自分がどれだけエンジニアとして成長してきたか、していけるかを意識しましょう。

  • この一年間で身につけた技術は何か
  • 今後伸ばしていきたい技術は何か

このように成長性を表す上で時系列で自分のスキルについて話すことができるようになることが良いかと思います。

また、ただなんとなくではなく、何か開発をしてみて自分に足りていないと感じたこと、次に挑戦してみたい技術など、きちんと整理した上で理由を持っておくことが良いでしょう。

技術に対してオープンに

色々とポイントを整理してきましたが、これらに共通しているいちばん重要であることは「技術に対してオープンであること」です。

自分がわからないことや知らないことに対してまっすぐに向き合う

ことができれば、エンジニアとして絶対に成長していけると思いますので、 是非そのような心構えをもって普段からエンジニアリングを楽しんだり、技術面接に望んでもらればと思います。

やりたいことを探すより、やりたいことの種を見つけて行動しよう

  • この記事は一般に現在、あるいは今後就職活動を控えている学生に向けた記事です
  • 学生時代から起業をしていたり、既に事業を立ち上げ特定の目的に向かっている人は対象にはしていません

学生時代にやりたいことは明確であるべきか

就活や転職に悩む若い人たちは「やりたいことの捏造」に時間をかけてはいけない

この記事にとても共感しまして、自分自身が学生時代の頃を振り返り、 学生時代に考えておくべき「やりたいこと」や「目標」について、おもったことを書こうと思います。

学生時代からやりたいことは明確でなくても良いと思う

就職活動をしていると、採用面接において

「将来やりたいこと・実現したいこと、は何ですか?」

という質問をされることがあり

「自分自身は一体将来何をしたいんだろう。。。」

と頭を悩ませていたり、自信をなくしてしまっている学生もいるのではないかと思います。

僕自身も当時を振り返ると、地方大学で普通の学生生活を送っており、いざ、就職活動の局面に立ったとき、同じような悩みを感じていました。

先に結論から申し上げると、あれからおよそ7年ほど経ちましたが、今になって思うこととしては、

「学生時代から、やりたいことなんて明確になくてよい」

と僕は思います。

「どうして自分にはやりたいことが明確ないんだろう」と瞑想を続けるよりも、「明確にない自分を受け入れる」ことのほうが大事だと思います。 ここで重要なこととしては「やりたいことがなくてもよい」ではなく「明確ではなくて良い」という意味です。

これは大きく異なり、とても重要な違いです。

学生生活と企業活動は大きく異る

理由としては、一般的に学生時代の経験というのは、社会人になってみて振り返ってみると、とても一部分の狭い経験であったと感じるからです。

なぜ「狭い」のかというと、学生と企業ではそもそも行動の目的自体が大きく異なるからです。

今まで自分自身のために自己研鑽や経験を積み重ねてきた学生生活が、社会に出ると顧客・ユーザのためにものを作ったり、売ったりするという、目的そものもが大きく変わります。

例えば仮にエンジニアとして就職活動をしている学生であれば、 学生時代に何かしらのアプリケーション等を自分自身やチームで開発した経験はあるかもしれませんが、 「ビジネス」という観点で社会人と比較をすると、できあがったものを販売してユーザから沢山のお金をもらったり、製品に対してフィードバックをうけたり、という企業活動として普段当たり前におこなっているような経験が豊富かというと、そうではないと思うんですよね。

なので、学業生活で培った経験では、僕達みたいな社会人よりも、企業活動におけるやりたいことが明確にないのは当たり前だと思うんです。

そういった意味では、学生時代にその生活の中だけで感じたものや経験でやりたいことを絞ってしまうのは、逆に皆さんの可能性が狭まれてしまうような気もします。

「やりたいことの種」を見つけて行動しよう

そのため結局は現段階では本当にやりたいことを机の上で明確にしていくことは限界があるのではないかと思いますし、もしかしたら時間の浪費になってしまうかもしれません。

「じゃあ一体どうしたら良いのか?」ですが、僕は

  1. やりたいことの種をみつけてみる
  2. とにかく行動してみる

ことが重要なのではないかと思います。

やりたいことの種をまず見つけてみよう

やりたいことの種とは、自分を動かすモチベーションとなるもの

前述したように、大学や専門学校に進学して、何かの学問に取り組んでいる時点で、学生に皆さんは「やりたいことがない」わけではないと思います。

やりたいことはあるが、ただそれが「明確化されていない」だけ、です。

事実として、これまでの学生生活を通じて、何かしらの物事に取り組むときは、きっと何か皆さんを動かすモチベーションがあると思います。 きっとそのモチベーションは将来やりたいことにつながってきます。即ちそれは「やりたいことの種」です。

この「本当にやりたいことの種」を何かしらの形で就職活動中にに見つけるべきなんじゃないかと思います。

自分を突き動かす「何か」がみつかれば、継続できる

例えばエンジニアとして働くのであれば

  • 誰よりも綺麗なコードを書くこと
  • まだ自分が知らない技術を身に着けること
  • 他人から頼られること、認められること
  • 自分自身が尊敬できる人、目標にできる人と働くこと
  • 自分が共感できるサービス・プロダクトづくりに関わること

など、皆さんを突き動かす動機はそれぞれだと思います。

たとえ明確に自分が開発したもの、携わったもので社会をこうしたい、 XXのようなユーザを◯◯したい、等が明確になかったとしても、これらの動機を満たすようなことが出来れば、きっと開発に携わり続けることができるでしょう。

新卒採用をしている会社に携われば、間接的に社会貢献につながる

一概には言い切れない部分はございますが、学生の皆さんが就活において選考をしている会社は

「ビジネスとして存続している会社、利用者が拡大しているため採用を拡大している」

のであり、それは転じて何かしら社会貢献性があると信じてよいかと思います。

どのような動機であれ皆さんは、入社後にその会社の開発(仕事)に関わること自体で、ある意味社会貢献の手助けをしているといえると思います。

何でも良いので、

  • 皆さんを突き動かす何かをこの就活中に見出す
  • それを最大限発揮できる環境が見つける(共感できるなど)
  • まずは少しずつ貢献してみる

ことができれば良いのではないかと思います。

行動することで「やりたいことの種」に水を撒こう

僕自身、就職活動を続ければ続けるほど、

  • 自分自身のスキルの無さ
  • やりたいことが無いことに対する焦り

だけがどんどん露呈されていきました。

結果として、就職活動をやめ、ご縁があって大学3年生のときから今の会社でインターンをはじめることにしたのが最終的に今の自分に至るキッカケです。

当時明確に「こんな社会に貢献したい」「こういった価値を提供したい」と明確に語れるわけではありませんでした。

当時僕がはじめたのは 「エンジニアのかっこよさや価値をもっと世の中に広げたい」

であり、実際に行動してみた内容が 「世界で活躍する日本のエンジニア達を取材してフリーペーパーを作って学校に営業してばらまく」でした。

がむしゃらでしたが、結果としてそこからは1円もお金を稼いでいませんでした。笑

(※学生時代に作成したフリーペーパー)

やりたいことは突然出会うのではなく、徐々に気付いていく

しかし、そこを起点に、様々なことに挑戦してきたことは今でも覚えています。

  • 企業と動やったら本質的なマッチングに繋がるか
  • そもそもの人材不足の壁をどうやったら解決するか
  • どうやったらいろんな人達がエンジニアの価値を感じてくれるか

などなど、日々向き合っていくうちに、様々な課題に気づいたり、解決策を講じていく上で、その上に今の事業が出来上がっていったような気がします。

なので自分自身にとってはこのフリーペーパーはある意味「やりたいことの種」だったといってもいいかもしれません。

しかし、それもまだ道半ばであり、きっと来年再来年に「やりたいことは何か」と聞かれたら、今年とは少し異なること(軸は同じかもしれないが)を言っているかもしれません。

そうやって、やりたいこととは、何かをキッカケに「徐々に気づいていく」ものだと思うのです。

待っていても、いつまでたっても出会うことなんてありません。 何か自分自身の中に「種」をみつけ、そこから大きな「やりたいこと」につながっていくような起点を就職活動の中に見出すことができれば良いのではないかと思いました。

常に学び続けることが唯一のエンジニアの生存戦略だと思います

新田です。久しぶりのエントリです。(相当久しぶりすぎる。)

JPHACKS2016を11月に終え、今年の2月にオンラインプログラミング学習サービスCODEPREPをリニューアルリリースしました。わりと鬼のようなスケジュールだったのですが、チームに恵まれて、なんだかんだ一つ一つ事業を進めていくことができています。

そして、こうやってこれらの事業を通じて今日も業界内で課題でもある高度IT人材育成・輩出領域にチャレンジしている定かではあるのですが、やっと少し一息つける(一息つけるとは言っていない)タイミングになったので、当エントリを書きます。

2017年も3月に入り、学校の卒業を控え春から社会人になる人や、これから就職活動をして自分自身が活躍できる環境を探している人も多いのではないでしょうか。

僕は普段の仕事の様々な場面で、そのようなエンジニア志望の学生と話す機会がたくさんあります。 その中で、 彼らによく聞かれる質問に今日は答えたいと思います。7割・8割ぐらいの確率で学生から聞かれる質問があります。こんな質問です。

「僕の今の技術は会社に入って通用するのでしょうか。」 「どのぐらい技術を学んだら、"エンジニアとして一人前"になれるのでしょうか」

きっと、これから社会人になる上で、特に 実力・成果主義がより一層加速するエンジニアという仕事だからこそ、沢山の不安を抱えている人も多いかもしれません。

そんな エンジニアとして一人前になりたい君へ 、僕が常に伝えていることを今日はブログでまとめてみようと思います。

心配しなくても大丈夫。いまの君の技術力はどこにも通用しない。

そもそも会社によって求められる事は異なる

同じエンジニアとしての仕事であったとしても、それぞれの会社のスタイルやビジネスモデル、フェーズ、組織体制など、様々な要因によって求められることは異なります。

また、技術的な側面でも、使用している言語やフレームワーク、社内の開発文化など、働き方は多種多様なので、一概に通用するしないという一次元の軸では判断ができないでしょう。

特定の会社内でも求められる事は常に変化し続ける

さらには、もし仮に同じ会社で働き続けたとしても、特にIT業界では会社や事業の成長に伴って、求められることが異なります。

立ち上げフェーズではとにかく素早い設計や実装力が求められることもあれば、 大きくなるにつれて、自動化や冗長化が求められたり、会社の規則をまもるコードを書くことを求められたり、システムをリニューアルするために一から新しい技術を活用することを求められるケースもあります。

会社で通用するかどうかというよりも、タイミングや状況にも関係するので、一概に今の技術力が通用するか、いつになったら会社で通用するかとは言い切れないのです。

でもそれは学生(未経験)の君だけじゃない

どんなに経験豊富なエンジニアでも、明日通用しなくなる可能性がある

会社のフェーズなどの事業要因だけではなく、技術の変化による要因もあります。そしてそのリスクは未経験者の君だけではなく、既に企業でずっと働いているエンジニアも同じく背負っているリスクです。

ちょっと簡単な例を紹介します。

今でこそ、皆さんはHTML5という言葉は聞き慣れているとおもいます。

しかし今から5〜6年前、当時まだスマートフォンは今ほど普及しておらずガラケーが主流の中、ブラウザ上で動的な画像やアクションを描画するために、ActionScriptを用いたFlashという技術が主流となっており、 Flashエンジニア というエンジニアが存在しました。

Flashは当時のWebをリッチなものにして、ブラウザ内でインタラクティブな表現を可能にしました。 しかし、セキュリティーの脆弱性、ブラウザのクラッシュ、ページのローディング速度など、様々な問題に直面しました。

そんな中、ブラウザの進化に伴いFlashに代わりって登場したのがHTML5です。 簡単なHTMLを記述するだけでビデオ再生、オーディオ再生を可能にし、canvasという技術を用いて沢山の図形やアニメーションなどを手軽に描画出来るようになりました。

そして現在、ほとんどの主流ブラウザではこのHTML5が主流となり、Flashのサポートを終了しています。

[参考] 主要 Web ブラウザーによる Flash の無効化について

そしてHTML5をサポートしているブラウザがどんどん重宝されるようになり、 Mobile HTML(HTML5のブラウザ対応状況をチェックできるサイト) のように、様々な主要な技術がどのブラウザで対応しているのかと、ブラウザは開発者に煽られてばかりです。

今、Flashエンジニアを求めている会社はほとんど無いに等しく、当時ActionScriptを用いて描画をしていたエンジニア達は、HTML5、CSS3、JavaScriptをメインに扱っているのが標準になりました。

これがこのたった5~6年間でおきた変化です。

我々は何度も何度もスタートラインに立たされる

いまご紹介した例は一例にしか過ぎません。

それ以外にも、iOSの開発言語がObjective-CからSwiftに変わったりとか、 VagrantとChefでの仮想環境の構築にハマっていたエンジニア達は、今はDockerに夢中になっています。

何を言いたいかというと、 今日の世界標準が明日も標準であるとは限らない。ということです。

標準が変われば、必要な技術も、知識も、求められることも変わってきますので、エンジニアもある特定の技術だけを身に着けていれば生き残っていけるとは限らないのです。

そうやって、標準が進化したり変わっていくたびに、私たちエンジニアは何度も何度も目まぐるしく振り出しに戻され、スタートラインに再度立たされ続けるのです。

"常に学び続けること"がエンジニアの唯一の生存戦略

スタートラインに立てば経験者も未経験者も状況は変わらない

そのため、冒頭にも言ったように、今もっている技術は十分通用するか、という議論や心配をする必要は全く必要ありません。 気楽に 「どうせいつかいらない技術になるかもしれない」ぐらいに捉えておく方が良いでしょう。

今自分が持っている技術に固執しないでください。いつかまた振り出しに戻ります。

逆に、何かの技術が進化すれば、経験者であろうと未経験者であろうと、また一から同じスタートラインに経つことが出来るのです。

そこから素早く走り出せる”柔軟性”や”応用力”を身につけよう。

そのため、 - 色々な変化に柔軟に対応できるようになること - 常に技術を学び続ける習慣づけをすること

のほうが、圧倒的に大事と言えるでしょう。

この技術柔軟性を得るためには、思想的バックグラウンドを理解することが必要です。

その技術がうまれた目的、どのような課題を解決してくれるのか、また、一体将来的にはどのようなものを目指しているのかを理解しながら習得すること、というような意味合いです。

バックグラウンドを理解できるようになると、道筋を正しく理解しながら習得することができ、道を踏み外す可能性は低くなります。

この直感を研ぎ澄ませるためには、何度も何度もスタートラインから進んでいく経験を積んでいくことしかありません。

経験者のほうが比較的有利なのは、 自分達よりも技術を持っているからではなく、何度も経験を積み重ねたことによって、この柔軟性や応用力を持ち合わせている可能性が高いからです。

とにかく変化を楽しもう!エンジニア人生は常に学習の連続だ。

結論、今の技術力や能力よりも、 常に学び続けることが唯一のエンジニアの生存戦略です。

そのため、スターラインに何度も何度も立たされ、また前進していく事、常に新しい技術を取り入れていくことや日々の技術変化を、本当に楽しめるかどうかが本来エンジニアに最も必要とされる素質なのかもしれません。

昨日までなかったテクノロジーがまたどこかで生まれ、新しいデバイスや概念が普及し、何かの仕様や要件が変わったり、そんなことがあちこちで日々発生しています。

「くそー!せっかく○○が出来るようになったのに!」という気持ちがあるかもしれませんが、これらの変化や課題をチャレンジだと思って楽しみましょう。

今の技術力を心配する時間があったら、一つでも多く昨日できなかったことを今日できるようになりましょう。

そして今日必要な技術を知らなかった過去の自分や、コードをいつも笑えるようになりましょう。

その積み重ねを繰り返していくうちに、気づいたときには周りから「一人前のエンジニア」だと思われているかもしれません。

ちょっとだけCODEPREP(コードプレップ)の宣伝

これまで書いてきたような、沢山の人達が常に 新しい技術を常に学ぶことを楽しみ、活躍できるエンジニアを目指し続けられるように、と想いを込めて、弊社ではCODEPREP(コードプレップ)というオンラインプログラミング学習サービスを提供しています。

CODEPREP(コードプレップ)

CODEPREPでは毎日10分から始められる実践的なブックを幅広く、どんどん提供していく事で、皆さんのエンジニアとしての飽くなき探究心、終わりなき学習をサポートしていければと考えております。

さらに現在は無料で提供しております(今後有料にしていくよ)ので、是非今のうちにたくさんお楽しみいただけると幸いです。 (最後宣伝ですみません。笑)

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

どうも新田です。 前回のエントリ エンジニア社員「今月から週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 GeekGoogleギークたちはいかにしてチームを作るのか"]

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

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

新田です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

さいごに

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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