第10回 原因追求と復旧のバランス――運用リーダーの難しさ
岑康貴（＠IT自分戦略研究所）
赤司聡（撮影）
2010/8/17
 |
| 磯野千晴（いそのちはる） 楽天 グループプラットフォーム開発・運用1課 サーチプラットフォーム開発グループ 運用チーム リーダー 1970年2月生まれ、宮城県出身。専門学校卒業後、ソフトウェア会社にて主に官公庁向けのシステムを開発。その後、一般ユーザーが使用するシステムの開発に携わりたいと考え、2000年に楽天に入社。 |
■楽天で10年、さまざまなサービスを渡り歩く
前職では、官公庁向けのパッケージソフト開発に従事していました。でも、これからはWebだろうし、Webの仕事をしたいと思い、また「世間の人に使ってもらえる仕事がしたい」と考え、楽天に転職しました。2001年に入社したのですが、当時楽天はまだ社員が200人くらいで、中目黒の小さなビルに入っている、小さな会社でした。現在の楽天の中では古株の部類に入ると思います。
入社して2〜3カ月した段階で、リーダーとしてのポジションに就きました。当時は1つのサービスを担当したら、開発から保守・運用まで全部面倒を見る、という状況でしたね。初めて担当したのは楽天フリマ（現 楽天オークション）でした。
それ以降、1〜2年ごとに担当するサービスが移り変わっていきました。R-Mail、楽天スーパーポイント、みんなのお買い物レビュー（現 みんなのレビュー）、すすメール、楽天ブログ、みんなの就職活動日記、楽天仕事市場、楽天オークション……。別のサービスを新たに担当するたびに、ソースコードを見て、勉強になることがたくさんあります。
■アプリ開発者が欲しいものを提供する
今年からは、楽天の各種サービスで使用しているサーチエンジンの運用を担当しています。これは、社内の各サービス向けにプラットフォームとして提供しているもので、そういう意味では現在の直接のユーザーは社内のWebアプリケーションエンジニアということになりますね。
| エンジニアライフ コラムニスト募集中！ |
あなたも＠ITでコラムを書いてみないか 自分のスキル・キャリアの棚卸し、勉強会のレポート、 プロとしてのアドバイス……書くことは無限にある！ コードもコラムも書けるエンジニアになりたい挑戦者からの応募、絶賛受付中 |
プラットフォームサービスは特定のサービス向けにアプリケーションを書いてはいけない、という点が、個人向けのサービスとの大きな違いです。さまざまなサービスで使えるように作らなければなりません。ユーザー、つまり各サービスのWebアプリケーションエンジニアのことを考えて作る必要があります。
その点、わたしはいろいろなサービスの開発や運用を担当してきましたから、勘所が多少は分かっているつもりです。どういうふうに使いたいのか、トラブル時には何が求められるのか、などは、経験していないとなかなか分かりません。
現在のメンバーの中には、社歴が浅く、個人向けサービスの経験が十分ではないエンジニアもいます。そういう状況では「使う人のことを考えて作る」という意識が薄れがちなので、チームとして気をつけています。
ユーザーの声を聞く、ということも大切です。個人向けWebサービス開発は、ユーザーの声が大量に届くので、サービスにフィードバックしやすいという利点があります。一方、社内のエンジニアが相手だと人数は少なくなりますが、その分、直接フィードバックを得ることができますし、相手もエンジニアなので、「ユーザーの声を聞く」という点では聞きやすいですね。
■トラブル時は、まず復旧させることが重要
リーダーとしては、「メンバーの話を聞くこと」が最も重要だと考えています。相手が論理的に正しいことをいっているのであれば、それを尊重するのがリーダーの役目でしょう。もっとも、現在わたしのチームは20人を超えているので、全員の話を常に聞いて、把握しておくのはちょっと厳しい規模になってきました。そこで、サブリーダーを何人か置いて、全体を把握するようにしています。
プラットフォームサービスという特性上、社内のほかのチームとの調整が多いのですが、こうしたエンジニアがちょっと苦手な仕事も、基本的にはメンバーに任せています。どうしても、らちが明かないときだけ、自分が出ていきます。
「運用」という点で、チームリーダーとして苦労することもあります。現在のチームには若いエンジニアが多いですし、新卒も入ってきます。そういう人たちに「運用」とはどういう仕事なのかを教えるのは、結構難しいんです。負荷をどうするか、トラブル時にはどう動けばいいか……などは、まだまだ形式知として確立できていないんです。特にトラブル対応は、どうしても経験がものをいうので、難しいですね。
また、エンジニアにありがちなのが、トラブル時に「原因追究をし過ぎてしまう」という落とし穴です。サービスが止まったら、まずは復旧させなければなりません。もちろん、復旧させるためには、原因の追究は必要です。でも、止まっているその瞬間は、原因の追究が目的化してはならない。素早く復旧させることが目的なわけですから。詳細な原因の追究はその後。両方大事なのですが、このバランスは非常に難しい。
■アプリとインフラ、両方見られるエンジニアになろう
新卒で入ってくる学生に多いのですが、Web企業のエンジニアというと、個人向けのサービスの開発者、というイメージが強いようです。でも、サービスが大きくなってくると、必ず負荷の問題にぶつかります。Webアプリケーションエンジニアは、常に負荷のことを考えて設計・開発しなければなりません。ただ、ここは運用を経験しないと分からないことも少なくありません。
現在、楽天ではアプリケーション開発とインフラは職種もチームも分かれていて、それぞれスペシャリストとして仕事をしています。でも、エンジニアとしては、どちらかに軸足を置きつつも、トータルで見られた方がよい。どちらか一方だけ、という人は、機会があればもう一方のスペシャリストたちの中に飛び込んで仕事をしてみるのもよいと思います。
わたし自身、現在は運用チームのリーダーですが、本音では一エンジニアとしてアプリケーションを書きたいなあ、と思っています。エンジニアですから。アプリケーション開発の経験を運用で生かしたように、今度は運用で得た経験をアプリケーション開発の現場で生かしたいと思っています。楽天ではそういうキャリアパスの選択が可能なんです。
一方で、現在担当しているサーチエンジンをより良いものにしていきたい、という思いもあります。各サービスの中でも、特に楽天市場のサーチエンジンはどんどん巨大になってきています。さまざまなデータがサーチエンジンに集まってきているため、リスクが高い状態になっているのも事実です。これをどう解決し、良いサービスにしていくか、今後も挑戦していきたいと思います。
＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、＠IT自分戦略研究所をよろしくお願いいたします。
