自分は事業会社に勤めています。 そこで、自社サービスの運用業務に従事しています。 自分の所属する部署で抱えてるサービスは10を越えます。 それぞれ大小はありますが、非常にクリティカルな領域のサービスたちです。 今日も、お盆休み中ですが、ある処理が正しく流れておらず、 会社から支給されたノートPCでサーバに接続して対応しました。 非常にタフで、且つ、なかなかやりがいを見出すのが難しく思われがちな 運用業務ですが、僕は運用チームのリーダーをしています。 運用チームを立ち上げるまでは、開発と運用の区別はありませんでした。 開発者は運用もしながら日々の業務を行っていました。 運用でトラブルが起こった場合、リカバリに平気で半日とか持っていかれます。 しかも、かなりの緊張感の中で行う処理が多かったりするから、 トラブルが解消した後に、ほらプログラミングしなさい、って言われても・・・。 疲弊した状態で開発を行うと、あまり良い方向にはつながりません。 あまり好きな言葉ではないですが、生産性は高くはなりません。 また、組織の人の出入りも激しく、担当するサービスに全く馴染みの無い人が 開発に入っていきなり高い生産性を発揮するのは激しく大変です。 転職してから約半年間、Rubyの開発案件を担当していましたが、 明文化されていない、たくさんの事柄をこなさなければならず、 手戻りも多々発生し、外部の人にも迷惑かけたり。 今振り返っても、よくあの状況でやれたな、って思います。 そこで立ち上げた運用チーム。 自分はそのチームのリーダーを買って出ました。 ・運用の巻き取り →開発プロジェクトの生産性向上
・育成 →担当のサービスの理解を深くするのは運用するのが一番 技術者にとってトラブルシューティングは一番伸びるとこ
・開発⇔運用のローテーション →誰がどのサービスの開発にもスムーズに入っていける 上記を組織立ち上げの拠り所として、人のローテーションの計画も立てて、 社歴の浅い中途社員と、当時の新卒社員中心にチームを立ち上げました。 全てが手探り状態で、立ち上げ当初は非常に苦労しましたが、 自分の中で、ひとつだけ、決めたことがあります。 「絶対、逃げない」 最後は自分がケツを持つから、メンバーに責任を押し付けるようなことはしない。 やれる自信もありました。自分はエンジニアだから。 前の会社でもトラブルシューティングしてたし。 例えば、 A：「いつも手動でやってるXXの処理は 土曜日に動かさなきゃいけないことになったから、 cron起動するようにしといて～」 B：「sudoでスイッチユーザーして叩くと動いたのに、 cronからだと落ちてしまいました。」 sudoでsuするときと、設定されるパスが違うんだ、とか。 言われりゃ、そうかって思うけど、実際に対処したことあるのと ないのとじゃ解決までにかかる時間が全然違う。 そんなトラブルシューティングを来る日も来る日もこなしながら、 目標立てて。月初の週次定例でメンバーに共有して。 毎月、月初に行う席替えは、配置に1時間とか悩みました。 AさんにXXをやってもらえるようになるには、 Bさんの隣の方がいいけど、そうするとCさんは、、、みたいな。 チームが軌道に乗ってきたと思ったら、メンバーのローテーション。 それでも、チームの役割を拡大して、数人日の細かい開発なら請け負うようにしたり。 疲弊してそうなメンバーとは、個別に面談して、 上司にエスカレーションして、できるだけ、やり易い環境を提供したり。 そんなこんなで5ヶ月が経ちました。 最近では、各メンバーが、思いっきり自走してくれるようになりました。 右肩上がりというよりも、垂直に近いような伸び方をしているメンバーもいます。 自分の手持ちタスクはほぼ無くなり、自分抜きでもいろんなことが回っています。
少し寂しいですけど。。
自分は今月いっぱいで運用チームを抜けて、開発プロジェクトに移ります。 この運用の経験は、必ず、開発でも活きると思っています。 そして、"組織"とか、"マネージメント"とか、"リーダーとして"とか。 自社サービスの運用を通して出来たこの経験は、 何事にも変えられないものだと思います。 エンジニアだからって、プログラマだからって、 リーダーやっちゃいけないわけでもないし、 たまには、そういう役回りをやってみてもいいんじゃないかなって思います。 ポジティブに捉えれば、宝の山かも知れないこと。 周りに身近に転がってるかも知れません。
