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