読者です 読者をやめる 読者になる 読者になる

yashigani?.days

週刊少年ジャンプについてだらだら書きます

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

こんにちは、新米ディレクターの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を紹介します

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

明日は金曜日

IMO

東京へ日帰り出張、疲れた体を新幹線のシートに預ける。「帰りの新幹線ではビールを飲むんだ」チーフエンジニアの教えである。共に帰ることになった同僚と弁当の封を開け、缶ビールのプルタブを引く。東京は何度行っても疲れるけれど、帰りの新幹線の雰囲気は嫌いではない。そこかしらで私たちと同じように弁当を広げ、缶ビールの栓を抜く。車内は小さな幸せと笑顔で溢れている。そんなことを感じながら京都までの2時間半を過ごした。明日は金曜日だ。

人の挨拶を嗤うな

IMO

挨拶がないことや挨拶もできないのかと怒る人がたまにいる。けど、そういう人に限って自分から挨拶しないという経験則があって、挨拶する側じゃなくて挨拶される側の理論だなと耳にするたびにおもう。唯一例外は学校の先生で、彼らは挨拶しろと怒鳴りつけて、実際に挨拶してる。これは信条の話だが、コミュニケーション不全の原因を相手に押しつけるべきではない。挨拶されないのはされない側にされないなりの理由があるわけで、怒るくらい気に入らないなら人を変える前に自分を変えるべき。平たく言うと、挨拶しない側にとって存在感が無い。挨拶されるために自分を変えるのはいかにもコスパが悪いと感じるかもしれないが、気になるあの子に声かけられるために自分を変える、と言いかえるとなんか尊い感じがする。そういう感じ。

挨拶されないことに怒るより、自分から挨拶したほうが生まれる不幸は少ない。とやかく怒らずに普通に挨拶をすればよい。それを踏まえて私がどう振る舞いたいかというと、自分から挨拶したがらない人間に対して大声で挨拶する、そういう人間でありたい。

てんとまる

IMO

Twitterやめたら、インターネットに発信する機会がなくなってさみしいので久しぶりにブログを書くことにした。ちなみに、やめたというのは読んだり投稿したりするのをやめただけで、セルフブランディングを大きく毀損するのでアカウントは残していて、アカウントを削除して黒歴史を封印!みたいな根性めいたものではない。

5、6年前くらいから自分の書く文章では特に縛りがない限り句読点にカンマとピリオドを使っていた。たしかMacを買ったのがきっかけだったとおもう。なぜカンマとピリオドを使っていたかというと、シュッとしていてかっこいいからで、それ以上もそれ以下の理由もなかった。 Macでカンマとピリオドを使うのは簡単で、ことえりなりIMEの設定を変えればよい。しかし、問題なのはiPhoneで、iPhoneはそういう痒いところに手が届く設定が存在しないので、毎度変換するという苦行とポリシーを選ぶかポリシーを棄てるかという選択を迫られる。そこで私がどうしていたかというと、シュッとしているからという理由でカンマとピリオドを使う人間である。当然のごとくポリシーを貫くことを選び、甘んじて苦行を受け入れていた。インスタントメッセージでさえ、句読点を打つたびに変換する。渋さというのはこういったたゆまぬ努力から生まれるものだと自分に言い聞かせていた。

しかし、数週間前にこのポリシーにまったく意味がないことに気づいた。気づきは本当に急におとずれ、カンマとピリオドに変換する作業がまったくばかばかしくおもえてしかたなくなった。あまりにばかばかしいので、一度やめてみるとどうだろう。今まで息の詰まっていたような感覚からスーッとなくなった。これはすごい!とあまりに感動し、気付いたらMacの設定も変えカンマとピリオドをやめてしまった自分がいた。

この話にとくにオチはなくて、ただの日記なんだが、そういうなんかやめにくい習慣や決めごとってよくあるとおもう。やめてみるのはすごく簡単なのでちょっと距離を置いてみるっていうのもよいのかもしれない。冒頭に戻るけど、そういうおもいでTwitterをやめた。やめるのは簡単でiPhoneからクライアントを消すだけで完了した。もともとかじりついていたようなものでも無いので、通勤電車が少し手持ち無沙汰になるだけだった。