yashiganiの英傑になるまで死ねない日記

週末はマスターバイクでハイラルを走り回ります

これからマネージャーになるエンジニアのあなたへ

こんにちは、新米ディレクターのid:yashigani_wです。 この記事ははてなディレクターアドベントカレンダー2日目の記事です。昨日はid:moretのそろそろ5年生なので右も左もわからない新卒のころの自分にアドバイスする - el cineでした。

私は8月にアプリケーションエンジニアからディレクターになりました。 はてなではディレクター職には担当するサービスの成長に責任を持つプロダクトオーナーとしての役割と、担当するチームの成果を最大化するマネージャーとしての役割が求められます。 マネージャーというと、多くのエンジニアはあまりなりたがらないとおもいますが、それはマネージャーに求められる責任を具体的にイメージできないことや未知の仕事に対する不安からではないでしょうか？ この記事は私の経験から、これからマネージャーになるエンジニアに向けてマネージャーがまず意識すべきことと、最初に陥るであろう不安を解消するためのアドバイスです。

自分で手を動かさずに任せる

マネージャーになったらメンバーを困らせないように具体的に企画して細かく仕様を決めよう、なんてそういう気持ちを持っていないでしょうか。 特にエンジニア上がりでマネージャーになると、過去に困ったことがある経験から企画や仕様を細かく噛み砕いてからメンバーに任せようとしてしまいます。 本来それはマネージャーがすべきことだったのでしょうか？

確かに、メンバーが意識すべきことに集中できるように情報をまとめたり適切な粒度で仕事を任せる能力は、マネージャーに求められる資質です。 一方で、過度に踏み込むことはメンバーに対する信頼の無さの裏返しと取ることもできます。 メンバーは任された作業を黙々とこなすだけの機械でなく、問題を自ら考え解決することができます。 これは当たり前のことですが、エンジニア上がりのマネージャーは自分でも問題を解決することができるため、意外とそのことに気が付きません。

さらに、自分のマネージャーとしての経験の無さを補おうと自分の慣れた仕事でカバーしようとしがちです。 開発もマネジメントも卒なくこなすイケてるマネージャーはわかりやすい理想像なのでそれに引っ張られてしまいますが、ただでさえ初めての働き方をしているのですから気持ちをぐっと抑えて一旦はマネージャーに集中すべきです。 担当するメンバーより詳しいことを把握できっこありませんし、細かく指示することは本人の成長にもつながりません。 事前に障害を取り除いてから渡すのではなく、問題が起きたら手助けするくらいの気持ちで仕事を任せたほうが結果的にうまくいくことが多いです。 まずは自ら手を動かさずに仕事を任せ、一歩引いた状態で関わる勇気を持ちましょう。

自分が裸の王様だと感じたら

現場の仕事から離れてしばらく経つと、自分はまったく価値を生み出しておらずチームにとって必要の無い人間である、このようなゴミクズは必要とすらされておらず自分はマネージャーにふさわしくないいう気持ちで頭がいっぱいになることがあります。 これはインポスター症候群と呼ばれ、一般的に見られる心理状態のようです。 褒められても褒められた気がしないと感じた経験がないでしょうか？ 他人の評価を素直に受け入れることができず、著しく低い自己評価をしてしまうのがインポスター症候群の症状です。 これは孤立を感じるときなどに起きやすいそうです。 特にエンジニアはコードレビューなどで承認される機会が多いですが、チームから少し距離を置きマネージャーになるとそういったフィードバックの機会がなくなり良くない心理状況に陥りやすくなります。

そういうときは、チームのメンバーと会話する機会を増やしましょう。 例えば、チームで問題と感じていることを聞き出してみても良いです。 メンバーが問題だと感じていることが自分が感じている問題と一致しなければ、自分の働き方は間違っていない証明になります。 同じ問題意識を持っているならば、問題をあぶり出すことができたので対策ができます。 逆に、自分だけで抱え込むのではなく素直に自分の気持ちをメンバーに相談してみるのも効果的です。 人に相談するには自分の中で問題や気持ちを整理する必要があるため、その過程で不安が解消されるかもしれません。 また、それを耳にしたメンバーはきっと協力的な態度をとってくれます。

どちらにせよ、マネージャーが感じる不安を取り除く手助けになることは間違いありません。 大事なのは、自分とチームの距離を近づけお互いに協力し合える関係を作り、チームに自分の居場所を作ることです。

振り返ると、私が「うまくできている」と感じるときはチームとのコミュニケーションが十分にとれているときが多いです。

さいごに

エンジニアにとってマネジメントはそれまでと全く異なる仕事で、正直面倒事も多いです。 しかし、マネージャーは関わるチームの規模と同じだけ自身が影響できる成果が大きく、チームと共にうまくやれたと感じるときは今まで感じていた達成感とはまた違ったうれしさがあり、やりがいがあります。 新たな領域にチャレンジするには大きな不安がつきまとうことになるとおもいますが、恐れずに挑戦してほしいです。 この記事がこれからマネージャーになるエンジニアにとって少しでも助けになることを祈っています。

明日は、id:chris4403です。お楽しみに！

ルールを作るアイツと破壊する私

IMO

個人的に、ルールは少なければ少ないほどよいと考えていて、必要があるときにだけ最低限のルールを設定すべきだとおもう。 なぜなら、多くのルールには必ず抜け道があって、全てのパターンで上手くいくようにルールを作ったところでどうせ運用でカバーみたいな世界観になる。 そこで起きるのは配慮の強制だとおもっていて、ホスピタリティが高いみたいに片付けると美談っぽいけど、本質的には無視できることに躍起にならざるを得ない状況に陥るという印象がある。 加えて一度作ったルールを変えたりなくしたりするのは倍くらいのエネルギーが必要ということも忘れてはならない。

私のルールに対するスタンスはそんな感じなのだが、一方現実問題として同意できないルールに対しどう向き合うかというものがある。 これに対してとりうるアクションは、基本的にルールを変えるか自分を変えるかのふたつしか無いようにおもう。 であるが、私は性善説的な事なかれ主義なので、自分に害のないルールに関しては運用でカバー的な振る舞いをすることに決めている。 しかし、害のあるものに対してはどう振る舞うべきなのだろうか。 ルールを変えようとするのは簡単だが、それができた背景にはそれなりの理由があるはずで、事情通に対してのリスペクトが足りず、結果的に自分の立場を悪くするのではないかという懸念がある。 実際、好き好んでルールを作りたがる人はいないだろうし、作った側からすると止むに止まれず作ったものに対して敵意を示されるときついというのは想像に難くない。 とはいえ、自分にとっては承服しかねるものなので放置するのは難しい。 結局のところ、ステークホルダーにご意見を伺いつつ、対案を提起するのが最低限建設的なラインなのではないのだろうか。

シン・ゴジラと4DX

シン・ゴジラを二条のTOHOシネマズで観てきた。ゴジラについては他にも良いエントリーが多くあり、ネタバレはしたくないので何も言うまい(ちなみに良い感想エントリーを探すにははてなブックマークの検索機能が便利である。iOSアプリを入れている方はアイコンを押し込んでクイックアクションを起動すると良い)。最高の映画なのでとにかく観に行って欲しい。シン・ゴジラについてひとつ言うとすれば、庵野監督が褒められてるのが最高。日本の映画ってどうしても出演者が褒められがちだけど、そうじゃなくて監督が褒められてるのがとにかくいい。劇中でもそうだけど、とにかくぶっ壊してる感がある。

ゴジラの内容についてはなにも触れないことにしたが、4DXについては言いたいことがある。4DXというのは、簡単に言うとバックトゥーザフューチャー・ザ・ライドが映画館で楽しめるようなもので、映画に連動して座席が傾いたり、振動したり、水しぶきがとんできたりする。実際、その大きなリアクションは迫力があり大いに楽しめた。振動の演出が違和感があったという感想もいくつか目についたが、それは特に気にならなかった。シン・ゴジラはめちゃめちゃにぶっ壊れるのをワハハーって言って眺めるのが良い映画なのだから派手であればあるほど良い決まってる。ムズカシーこと考えずに楽しめば良い。

しかしながら、4DXをリピートするかと言われると悩む。そもそも120分の映画を見るだけでも疲れるのに四六時中ガタガタされるととても疲れるし、眼鏡をかけている私にとって水しぶきは必ずしも楽しいだけの体験ではない。総じて良い体験だった、とは感じるけれども本当にいい映画だったのもあって、もう少し落ち着いて観てみたいというのが正直なところだ。なのでシン・ゴジラを4DXで観るなら2回目以降をオススメする。座席からの演出はどれも予想可能であるものが多いこともあって、リピートの場合は特に楽しめるところが増えるとおもう。

最後に、シン・ゴジラの4DX演出において決定的に許せないところについて書いておく。それはFogの演出だ。シン・ゴジラはあるギミックのおかげでどうしても画面の下半分に異様なまでに執着してしまう。Fogはスクリーン両端と中央の下段から発煙されるため、これが隠れてしまうのだ。特にクライマックスのあるシーンではこの演出のせいでとても難儀した。なので特に初見の場合は通常上映を勧めたい。これを読んだ人は諦めて通常上映で観てから4DXを観に行って欲しい。

筋の悪いコードレビュー

IMO

たまにコードレビューのしかたを紹介するエントリーを目にすることがある。その中でも反響があるものは実際によくまとまっており、なるほどと感心することもよくある。しかし、中にはコーディングスタイルやイディオム、ちょっとしたテクニックを使うように目を光らせるように助言されているものがある。誤解を恐れずに書くと、それらのトピックは無視できるようなものばかりであり、そのような指摘ばかりつけるのはあまり褒められたものではないなと感じる。これは私自身にも言えることだが、瑣末ことを指摘しすぎてしまうあまり、本質的な議論が霞んでしまうことがままある。レビュイーにとって、指摘が学びになることは確かに存在するのだが、コードレビューの目的はあるべき実装を議論するものであり、老婆心からそれを繰り返すことは必ずしも良いレビューとは言えない。

では、本当に良いコードレビューとはなにか。それは、コーディングスタイルのような事項の指摘ではなく、アプリケーションにとってその実装が好ましいかどうかを議論するものだろう。実際、私がもらった良いレビューを思い返すと、そういうものばかりが思い出される。つまり、良いコードレビューはプロダクトのドメインに深く根ざしているため、おいそれと具体的なケースを公開できることはないはずなのである。

iOSDCにCFPを出しました

昨晩、同僚とiOSDCのCFPソンをしていたら盛り上がって2本応募しました。よかったら投票してください。

ここ半年くらい、はてなブックマークのチームでスクラムマスターをやっているんですが、このチームでは高速にチームビルディング、カイゼン、リリースを並行させることができました。 そこで得た知見について話します。

Dependency Injectionは依存の注入だけでなく、ユニットテストや依存関係の整理にも有効な手法です。 過去関モバで2回LTしているんですが、短い尺だとエッセンスがあまり伝わりづらかったようなので長めの尺でトライします。

同僚のCFPを紹介します

どれもおもしろそうなトークです。気になるものがあれば是非投票してください。