私は昨年７月からサンフランシスコにあるAsanaという会社でエンジニアをしています。アメリカの大学でComputer Scienceを専攻し、昨年卒業しました。
エンジニアを指導する立場の人こそ読んでほしい、新卒エンジニアが1年間で上司に感じた５つのことの著者と私は新卒エンジニアで１年経ったところという境遇が似ている一方で、私は上述の記事に書かれているような不満を一度たりとも感じたことがありません。
この記事では、H_Craneさんの５つの上司に対する不満点と対比して、私がこの１年間で感じたAsanaの良い点を５つ列挙することで、どういった環境下だと新卒エンジニアはやりやすいと感じるのかの一例をご紹介します。
#1、「本当にそれググった？」って聞き返さないで欲しい
#1、部下がイラッとしない指導の仕方を上司が心得ている
私の憶測ですが、「本当にそれググった？」と聞かれてイラッとしてしまう原因は、その指導の内容自体にあるわけではなく、その上司の言い方にあるのではないでしょうか。私自身は「本当にそれググった？」と言われた事はありませんが、仮に僕の上司が同じ事を伝えようとしたならば、
- その質問はググれば答えが出てきそうだから一緒に調べてみようか。なんて調べたの？
- なるほど。確かにそれだと出てこないね。他に何かキーワード思いつく？
- （彼の誘導の末私が正解を出せなかったら）○○で調べてみたらどうだろう
- 出たね！
- 今後同じような問題があった時に、どうすれば僕の助け無しで自分で解決できるだろう？
- そうか、確かに△△の基礎知識がないとキーワードを思いつくのもきついね。その知識をつけるためにはどうすれば良いだろう？
- ・・・
といった流れになるだろうと思います。
決して部下を非難せず、あくまで問題を根本から解決することに集中し、互いに納得が行くまで問いかけを続ける彼の姿勢からは学ぶべき事が大いにあると感じています。
#2、やたら「同じミスはするな」って言わないで欲しい
#2、似たミスが続いたら、上司が一緒にその原因を考えてくれる
私の上司は毎日13時半からの1時間を、部下とのペアリングの時間として予定を空けており、日頃私たちのコードを読んでいて気になった点などがあればそれを取り上げて、どうすれば改善できるかのフィードバックをくれます。
このフィードバックの時間はけして一方的な知識の伝達ではなく、むしろディベートを彷彿とさせる様相で、なぜミスが起きてしまったのか、どうすれば防げるのか、代わりにどのようなアプローチがとれるのか、各アプローチにどのようなトレードオフがあるのか等をじっくり話し合ってくれます。入社して二日目の私に「自分の言う事に反論してくれた方が圧倒的にやりやすい」と言ったりと、安心して議論に集中できる雰囲気を彼が整えているのもポイントでしょう。
こうして考え抜いて辿り着いたノウハウは忘れにくく、私個人の、そしてチーム全体のコードクオリティの向上に大いに役立っています。
#3、意見やツールの押し付けをしないで欲しい
#3、アドバイスは豊富にくれるが、最終的な決断は自分で下す事を求められる
入社して数週間経った頃、とあるプロジェクトで考えられるアプローチが二つあり、甲乙つけ難かったので上司に助言を求めたら「僕は君にアドバイスはできるけど、君の代わりに判断を下す事はできない」と言われました。Asanaでは極端に早い段階から自立した人材になる事が求められます。
自己責任を重んじる社風が現れているのか、Asanaでは上司や同僚のチェック無しでブランチをマージし、後からコードレビューをしてもらうPost Commit Reviewという手法で開発を行っています。コードレビューはマージの許可をもらうプロセスでは無く、あくまでアドバイスを貰う機会に過ぎないという事でしょうか。事前のチェックが入らない分、自分のコードに対する責任感も増します。
ツールに関しても同様で、会社が推奨する環境はありますが、それ以外の環境で開発をしても特に何も言われません。当然自分の好きなツールに不具合が生じた場合は、それによる遅れなどに対する責任を負う事を要求されます。
自分で決断しその責任を負うのは最初は大変なストレスでしたが、それが自然にできるようになった今では、仕事に満足して自分に自信を持って働ける事に繋がっています。
#4、もっと褒めて！
#4、めっちゃ褒めてくれる
部下を褒めない指導者の方や、互いを褒めあうカルチャーを構築できていない会社があるのだとしたら、本当に勿体ない事だと思います。Harvard Business Reviewの記事によれば、最もパフォーマンスが高いチーム内ではポジティブなフィードバックとネガティブなフィードバックの比率は5.6:1であるという研究結果が出ています。
言い換えるならば、9褒めて1𠮟れなどと昔から言いますが、最近の研究結果では5.6褒めて1叱るべきだという事です。これを踏まえて、Asanaでは半年に一回の勤務評定なども含めて、社員を大いに褒めるカルチャーが徹底されています。
また、Asanaには”Traveling Narwhal”と呼ばれる変なぬいぐるみが数体おり、これを受け取った社員は２週間後に、自分が最もお世話になった相手にこれを渡すというルールがあります。なんだかこっぱずかしいしいなあと最初は思っていたのですが、貰ってみると大変嬉しく、モチベーションもあがります。また、日々お世話になっている人に改めて感謝の気持ちを伝えるのも気分が良いものです。
変なぬいぐるみ
#5、「わからないことはすぐ聞いて」という人ほど聞くと怒る
#5、忙しい人は忙しいって言ってくれる
一ヶ月程前に全く新しい部分のコードを触る機会があり、その導入としてマネージャークラスの人に助けを求めた事がありました。20分程かけてざっと説明をしてくれた後、「何か質問があればもちろんしてもらって構わないけど、あんまり聞かれすぎると邪魔かもしれない」と面と向かって言われました。文字に起こすとなんだか酷い事を言われているようですが、あまりにはっきりと言ってくれたからか、私は全く気分を害しませんでした。その後他のエンジニアの方が質問に応じてくれ、プロジェクトに支障は出ませんでした。
#あとがき
いかがでしょうか。私の今の職場では
1、部下がイラッとしない指導の仕方を上司が心得ている
2、似たミスが続いたら、上司が一緒にその原因を考えてくれる
3、アドバイスは豊富にくれるが、最終的な決断は自分で下す事を求められる
4、めっちゃ褒めてくれる
5、忙しい人は忙しいって言ってくれる
ので日々仕事がとてもやりやすいと感じています。少しでもエンジニアを指導する立場の方々の参考になれたならばら幸いです！