マネジメントで意識していたことを書いた

ここ半年くらいはAmebaで一兵卒としてチョロチョロしてる自分ですが、最近色んなプロジェクトのアレコレを見ていて色々と思うところがあります。 半年くらい前までは自分もサービスを持ってたので、マネジメント・ディレクション周りで意識していたことを書きます。

教育と裁量

自分のチームには12新卒が2名いたんですが、全てを与えず、とにかく課題を与えて常に思考する癖をつけさせるようにしました。一人にはリリースコントロール(機能開発の主導、ブランチの運用、リリース作業)を、もう一人にはサービス間連携(関係者との調整含む)をと、割と重要なミッションを課しました。とにかく自己学習ではなかなか経験できない仕事は任せた方が良いかなと。

健康管理

風邪ひいてる、その兆候があるメンバーは基本的にさっさと帰らせました。あと、ちゃんとマスクしろと。 「風邪をスケールさせるな」

〜時までにリリースするルール、金曜日はリリースしないルール

これはリリース直後はさすがにそうはいきませんでしたが、リリース1・2ヶ月くらいでだいたい定着していきました。 その日リリースする成果物が前日までにプランナー含めて確認OKになっていなければ基本的に負けです。 金曜日リリースは、金曜夜の飲み会中に何か起きたり、土曜日とかも若干気になったりするので極力避ける派です。 日本国民は健康で文化的な最低限度の生活を営む権利を有しますので、良いメンタルで長く仕事を続けていくためにこのルールを守っていくことは一定の効果が得られると思います。 単純にこれを実現しようとすると、逆算して色々と考えなくてはならなくなり、結構キツめのスケジュールになりかねないですが、だからこそサービスにとって今何が重要で、何がそれほど優先度が高くないかをしっかり考える癖がつくので、リリース成果物の調整がリソースの最適化は割と自然に機能するという印象です。

トラブルシューティング

機能実装を積み重ねればコーディングのスキルはたいていある程度のレベルまで行きます。ただ、運用中だからこそのインシデントというのは実際に運用の最前線に居なければなかなか経験することが難しいものです。しかも経験が乏しい場合、実際にそのような事態に遭遇した場合何をやってよいかわからずデッドロックしてしまうものです。 ある日サーバでとあるオペレーションを指示したのですが、わざとEC2のSecurity Groupを絞ってSSHできないようにしたり、あらかじめ色々なトラップを仕掛けました。 何故そのようになっているのか、どうやったら解決できるのか。行き当たりばったりで対応に当たっていないか、どのような意図があってその対応を試みたのか等、ひとつひとつの思考のプロセスを紐解いていくと問題解決能力も向上していきます。

ONとOFF

僕は基本的に「いつも仲良しクラブ」が反吐が出るほど嫌いなので、業務時間内に謎の社内イベントとかに巻き込まれるのが嫌いです。まず目の前の重要ミッションをちゃんと片付けてからにすべきです。これをちゃんと統率する人間がいないプロジェクトはだいたいダラダラやってるなぁという印象です。 ただ、基本的にやることをしっかりやっていて、業務時間外であって他人に迷惑をかけないのであれば別に好きにやってくれてOKだと思います。

チームビルド

自分が入社したときには既にこのプロジェクトは走っていたので、当然ながら編成権とか無いわけです。 しかし、プロジェクト遂行のために足かせになったりリスクになるようなメンバーや体制をそのまま放置していいわけがありません。というわけで自分の動ける色々と動いてみました。 「今いるメンバーでリリースまでやらなければならない」という考えは美徳かもしれないですが、これに拘って全員が不幸になるようなことは避けるべきです。

技術的負債のコントロール

これは負債として既に表面化しているものは当然ですが、思いつきベースで近い将来負債になるであろうことや、リスクについてひたすらチケットしてました。 たまに自分でも論点おかしかったり、後から見返すと?な感じのチケットもあったりしますがとりあえずチケットしとけばその是非については後からいくらでも議論できるので変に制限しない方が良いと思います。

関心範囲を狭めるな

進捗や問題点、リスクを共有するために夕会をやってました。タスクに関しては当時はRedmineで集約していたので、直近のマイルストーンを優先的に見てました。 自分のチームはサーバサイドチームという体でしたが、サーバサイドとフロントエンドでチームを分けるのはあんまり良いとは思ってなくって、フロントエンドやマスタ(パラメータ等)のタスクについても一通りなめていました。それぞれの専門性によってサーバサイドとフロントエンドを分業することはまったく否定する気はないですが、システムはサーバサイド・フロント・インフラ・運用を全て包含するものであると考えていますし、Backbone.jsのようなクライアントサイドMVCによりアーキテクチャレベルでサーバサイド・フロントエンドが疎結合になったとしても、サーバサイドエンジニアがフロントエンドに感心が薄いというのはシステムレベルで全体最適を保つためにはあってはならないことです。

予定調和を壊せ

成長を鈍化させたり、ミスを起こしてしまう要因の一つに「慣れ」があると思います。特に新卒1,2年目がちょっと「こなれた感じ」になってくると要注意なので、突発的に無茶ぶりを言ってみたりして日々の仕事がただのルーチン化しないようにしています。当然無茶ぶりなので、できてなかったからといってダメというわけじゃないです。 とはいえ、求められるレベルは上げていかないとそこそこのスキルで終わってしまうので、定期的に少し高めの目標を設定させることが重要じゃないかなと思います。目線を上げろってやつですかね。

と、まあこんな感じで書いてみましたが、基本的に自分はマネジメント寄りの人間じゃなく技術寄りの人間なので、今の業務はようやく本業に戻ってきたなーという感じなのですが、プロジェクトをうまくコントロールしていくという意味では重要な要素であり続けると思ってるので、これからも試行錯誤していきたいなーと考えております。はい。