２年目エンジニアがエンジニアリーダーをやってみた話

これは 【その1】ドリコム Advent Calendar 2015 - Adventar 5日目の記事です。

4日目は JunJunHiroi さんの Ruby+Mechanizeによるファイル送信方法 です。

 【その2】ドリコム Advent Calendar 2015 - Adventar その2もあります。

自己紹介

はじめまして、係長ともうします（「係長」というのはアダ名であり、弊社に係長という役職はありません）。

新卒でドリコムに入り2年目に突入しました。

某老舗ブラウザゲームのサーバサイドエンジニアをやっております。

最近のマイブームは かりゆし58 です。

去年のドリコムアドベントカレンダーにも参加していました。

1年目と2年目の対比として読んでいただくと面白みがますかもしれません。

AdventCalendar - 僕とドリコムの260日 - Qiita

（内定者・就活生に対して爆釣記事だったらしいです）

はじめに

なんと今年の8月ごろからチームでエンジニアリーダーを担当することになりました。

この記事ではエンジニアリーダーとはなんぞや、何をやっているのか、

エンジニアリーダーをやってみて思ったことを書いていきます。

エンジニアリーダーとは？

僕が現在所属しているゲームアプリチームでは、チーム内での役割ごとにリーダーがいます。

プランナーのリーダー、デザイナーのリーダーみたいな感じです。

今回は某ブラウザゲームチームのエンジニアリーダーの話をしようと思います。

当然ですが、エンジニアリーダーと一括りで言っても、チームごとで、どのような仕事をしているかは、大きく違うようです。

他チームのリーダーと話しているとその違いが分かって楽しいです。

本記事もエンジニアリーダーの一例だと受け取ってください。 

エンジニアリーダーのつとめ

僕がエンジニアリーダーとして特に意識していることは以下の3つです。

• 正常にサービスを提供し続けることの保証
• 無理なく開発を続けるためのリリースの調整
• サービス・メンバーの社内レピュテーションの維持・向上

正常にサービスを提供し続けることの保証

こちらは当然ですが、リーダーになってより重く感じているところです。

エンジニアがサービス提供の最後の砦にならなければいけません。

ユーザーに不利益を与えてはいけません。

プランナーの意図を正しく・誠意をもってユーザーまで届けなければいけません。

そのために何をしているか。

とにかくチェック・チェック・チェック。

• バギーなコードが混入していないか
• 正しいデータが設定されているか
• 正しくユーザに届いたか（リリース確認・ゲームを実際にプレイ）

一人で、メンバーの書いたコード、投入されるデータをすべて確認することはできていませんが、特に改善系の部分は厚くチェックをするように心がけています。

チームメンバーにも口をうるさくして安全リリースを心がけてもらっています。

無理なく開発を続けるためのリリースの調整

こちらは次に大事にしていることです。

プランナーからの無邪気な「あれがやりたい」「これもやりたい」を聞きつつ、

一方でエンジニアからの「ここを改善したい」「すぐリリースしたい」を聞きつつ、

安全なリリース・健全な仕事量などを考え調整をする必要があります。

つまり、NOと言える力、大事！

プランナーの意図を最大限実現させるのがエンジニアの一責務だと思っているので、基本的にやりたいことはやらせてあげたいですが、

健全な時間に帰れるように仕事をすすめないといけません。

健全化のために、エンジニアの手による開発手順の簡略化・効率化に向けた改善をすすめることも重要で、

その結果、新しい施策などに着手できる余裕を産みたいと考えています。

最近の改善系の大きいところで言うと「イベント終了時のメンテナンスの不要化」があります。

ノーメンテ化は、僕がリーダーではなかった1年前から個人的にもずっと言い続けてきた事で、1年越しに実現できたので、大感動でした。

これで今までクローズ時に待機していたメンバーの稼働分を空けることができました。

とはいえ、思った以上に時間がかかってしまったため、今度はうまくまわして素早く展開するように努めています。

サービス・メンバーの社内レピュテーションの維持・向上

最後に大事だと思っていることは宣伝です。

全社に向けて、アプリが何をやっているのか・どのような状況なのかを積極的に丁寧に共有するようにしています。

どうしたって、新規のイケイケネイティブアプリに比べると社内での露出は少なくなりますし、地味なことに間違いありません。

ただただ目立ちたいというわけではなく、ちゃんとしたメリットがあります。

先に書いたように、 正常なサービスの提供が第一です。

今いるメンバーのみでは対応できないような異常な事態が起きた時、手伝って頂くという状態になったとき、

チームやエンジニアとしての信頼感を相手に持ってもらっているかどうかは、重要なことだと思っています。

異常時でなくても、「こんな話があるんだけどやってみない？」という風に相手から思わぬ良い提案をうけることもあります。

また、「こんな風に改善してこんなに良くなったよ」というふうに共有をすることで、

自分も含めメンバーエンジニアの評価が上がって欲しいとも思っています。

評価が上がって、やる気になって、改善が進み、運用コストが下がり、新規施策がうてるようになれば、みんながHappyですね。

やってみてどうだった？

前節では大事だと思うことを書きましたが、

エンジニアリーダーになって気持ちはどうなのよ？というところを書きたいと思います。

愛

アプリへの愛がより一層深くなりました。これに尽きます。

愛とはすべてを受け入れることではありません。

愛が故につらくあたったりすることもあります。

そこは許してほしい。

1年前を思い浮かべると、

当時のリーダーだった人に対して、助けたい、お役に立ちたい！

とかいうよくわからないモチベーションで働いていたように思います。

今では純粋にアプリへの愛がモチベーションになっています。

さいごに

この記事では、僕がエンジニアリーダーとして感じたことをまとめました。

まだまだ数ヶ月しか経っていないなかで、偉そうなことをつらつらと書いてしまいました。

エンジニアを中心に、周りのメンバーには助けていただくことばかりです。

立場が人を育てるとはよく言ったもので、

こんなペーペーをエンジニアリーダーに置く判断を許した会社にも感謝をしています。

まだまだ目の前のことで精一杯なので、来年にはもう少し余裕のある状態になれるよう

努力していきたいと思っています。

アドベントカレンダー6日目は keiichironagano さんです。