自分戦略研究所 | 自分戦略研究室 | キャリア実現研究室 | スキル創造研究室 | コミュニティ活動支援室 | エンジニアライフ | ITトレメ | 転職サーチ | 派遣Plus |

リーダー

第7回 mixiの若きリーダーが語る「価値観をまとめる」大切さ


岑康貴(@IT自分戦略研究所)
赤司聡(撮影)
2010/5/24

井上洋平氏
井上洋平(いのうえようへい) ミクシィ mixi事業本部 コアサービス部 開発グループ コミュニケーション開発チーム リーダー 1979年9月、京都府出身。舞鶴高専卒業後、家電メーカーにて社内システム開発を経験。より大規模かつ高可用な開発現場を求めWebポータル企業に転職。その後、サービスの発展の可能性や業務の幅広さに魅力を感じミクシィに入社。

■Webエンジニアが企画に携わって得た「広い視野」

 高専を卒業したあと、家電メーカー、Webポータル企業を経て、現在のミクシィで3社目です。1社目の家電メーカーでは社内SEのような業務に携わっていました。最初は要件定義から仕様書を書くところまでの仕事だったのですが、学生時代からプログラミングが好きだったので、自分でコードも書きたいなと思っていました。そこで、DB構築や実装ができることをアピールした結果、外注していたものを、社内開発のスタイルに切り替えてもらうことに成功しました

 2社目ではWebエンジニアとして、地域系のサービスや、求人系のサービス開発に携わりました。このとき、求人系サービスの開発で「企画業務」にも携わったことが、エンジニアとしての1つの転換点になったと感じています。ちょうど地図系のWebサービスが流行し始めたころで、地図と求人情報を組み合わせたサービスを作ったら面白いんじゃないかとプロトタイプを作っていたら、新規事業企画室と兼務で企画にも携わることになりました。当時、その会社ではエンジニアが企画職を兼務するのは珍しいことでした。

 企画業務は初めてだったのですが、そのとき新しく見えたものがありました。それは、「サービスをどうやってビジネスに落とし込んでいくか」という視点です。それまでは、往々にして「エッジの効いたWebサービス」を作りがちでした。でも、より多くの人に使ってもらい、ビジネスとして成立させるためには、エッジが効いているだけでは駄目なんだ、それでは広く受け入れてもらえなかったり、長く使い続けてもらえないんだ、ということを学びました。

 この経験を通じて、エンジニアとして視野が広がったと感じています。AとBを比較するとき、よくエンジニアは「Aの方が便利だ」「Bの方が効率がよい」という理由で選択します。でも、広く使ってもらうのが重要なコミュニケーション系のWebサービスの場合は、「便利」や「効率」が最重要な判断基準でいいのか、という問題があります。「かわいい」とか「かっこいい」「うれしい」「悲しい」などが、もしかすると重要かもしれない。常に「ほかに判断基準はないだろうか」と考えるようにしています。これは企画業務を経験しなければ得られなかっただろうな、と感じています。

■リーダーを任された当初は戸惑うことも

 ミクシィはエンジニアが関われる領域が大きいと聞いていましたし、mixi自体、まだユーザーが3万人くらいのころから利用しており、サービスにも魅力を感じていたので、ぜひ働いてみたいと考え、転職しました。入社して2年半ほどになります。当初は「いちWebエンジニア」として入ったのですが、入社数カ月後、思いがけず「リーダーをやってみないか」といわれました。

エンジニアライフ
コラムニスト募集中!
あなたも@ITでコラムを書いてみないか

自分のスキル・キャリアの棚卸し、勉強会のレポート、 プロとしてのアドバイス……書くことは無限にある!

コードもコラムも書けるエンジニアになりたい挑戦者からの応募、絶賛受付中

 当時、社内で大きな体制変更があり、2〜3人の小さな開発チームがたくさんできました。それに伴い、リーダーが必要になったのです。上司のニール部長に、ある日「リーダーをやってみないか」といわれて、驚きました。「リーダーって、何をするんだろう?」と悩みましたね。ミクシィでは「開発のリーダーは何をするのか?」が厳密には定められていません。各リーダーがそれぞれ、自分で考えて、リーダーとしてのミッションを達成しなければなりません。ですので、できるかできないか、というより、そもそも何をするのかすら漠然としていましたし、不安も多々ありました。しかし、自分の視野を広げることにつながるだろうと思い、挑戦してみることにしました。

 リーダーになって最初のプロジェクトは「mixiエコー(現 mixiボイス)」の立ち上げでした。mixiエコーのプロトタイプは別のエンジニアがODF制度(One Day Free制度。週5日のうち1日、自分の通常の業務とは別の開発にあてられるミクシィの社内制度)を利用して開発しました。可能性を感じるサービスでしたので、本サービスにしようということで、わたしのチームが担当することになりました。

 現在、わたしのチームは自分を含めて8人ですが、最初は自分を含めてたった2人でした。だからリーダーといっても、あんまりリーダーらしいことはせず、わたしもバリバリとアーキテクチャ検討からDB設計、コーディングまでやっていました。

■「エンジニアとしての達成感」はメンバーに

 最初は2人だったチームにも、新卒や他部署からの異動など、段々と人が増えていきました。それに伴い、「リーダー」としての自分を、より意識するようになっていきました。

 自分がリーダー業務を遂行するうえで大切にしているのは、「自分の経験」に従う、ということです。社内のリーダーシップやマネジメントの研修を受けつつ、いろいろ考えた結果、やっぱり「自分がメンバーだったとき、やりやすかったリーダーのやり方」が一番いいな、という結論に至ったんです。自分がやりやすかったのなら、きっといまのメンバーもやりやすいだろう。自分が嫌だなと思うようなことは、きっといまのメンバーも嫌なんじゃないか。自分の経験が判断基準なんです。

 現在は「メンバーの裁量になるべく任せる」というスタンスを取っています。もちろん、わたし自身がいちメンバーのとき、そういうリーダーだと働きやすかったからです。なるべく任せて、若手の成長をフォローするのが自分の役割だと思っています。スキルのあるベテランの場合は、完全にお任せする形です。細かいコミュニケーションの問題などを調整するときに、自分が出ていく、というくらいですね。

 基本的に、「エンジニアとして達成感が感じられる部分」はメンバーにやってもらいたい。とはいえ、最初は苦労しました。開発でうまくいかない部分を、我慢できずに自分でやっちゃう、ということがたくさんありました。いまでも、「リーダー業務」が完璧にできているとは思っていません。課題はとても多いですね。

■エンジニアの気持ちが分かるリーダーであり続けたい

 一方で、やっぱり自分は「エンジニア」なので、コードを書きたいという気持ちもあります。でも、大きなプロジェクトにいちメンバーとして入ってしまうと、視野が狭くなってしまいます。それはまずい。だから、全体としてはメンバーに任せつつ、細かい部分は自分でコードを書く、というふうにバランスを取っています。

 「リーダーの自分」と「エンジニアの自分」とでは、明確に意識を切り替えています。エンジニアは「没頭」が重要だけど、リーダーは「没頭」していたら仕事になりません。ですので、「いまから没頭する」と自分の頭の中で宣言して、コードを書き始める。

 正直、やっていて楽しいのはエンジニアです。それに、コードを書いていないと、エンジニアの気持ちが分からなくなってしまうんじゃないか、それでは良いリーダーになれないんじゃないか、と思います。

 ちなみに、ミクシィの開発リーダーが全員、同じスタンスというわけではありません。管理業務に徹するリーダーもいれば、わたし以上にバリバリとコードを書くリーダーもいます。前者にはリーダーとして学ぶところがとても多いですし、後者に対しては「うらやましい」と思うこともありますね。

■価値観が1つでなくなる

 リーダーになるというのは、「価値観が1つでなくなる」ということだと思います。いちメンバーの時は、自分の価値観だけ。でもリーダーになると、さまざまな価値観を持っているメンバーを束ねなくてはなりません。だから、常に視野を広く持っていないといけません。

 特に自社でWebサービスを提供している会社であれば、それぞれのメンバーがサービスに対して熱い思いを持っているものです。でも、それらがすべて同じ方向を向いているとは限りません。会社の方向と同じかどうかも分からない。そんなとき、リーダーの役割は何か。みんなの方向性をうまく1つにして、会社の方向性と合わせていくことではないでしょうか。

 そのために、なるべくミーティングに参加したり、こまめにコミュニケーションをとったりして、みんなの方向性が一致しているかどうかに気を配っています。チーム外で決まった施策をチームメンバーにフィードバックするときは、「なぜそう決まったのか」を含めてしっかり情報を共有する、ということも意識しています。

 コミュニケーションについては、折に触れて声をかけたり、IRCで会話したり。チケット駆動で開発している部分もあるのですが、チケットはすべて見逃さず、その中から進ちょくや課題、みんなの考えていることなどに気を配って見ています。

 ただし、あえて朝礼はやっていません。よくコミュニケーションの機会を増やすために朝礼をやるという話を聞くのですが、わたし自身がメンバーだったころ、朝礼はあまり好きではなかったので。その時間を使って開発したい、とよく思っていました。

 ミーティングもなるべく減らしています。ミーティングを減らすと、その分、みんなの考えていることに気を配るのが大変になります。それでも、「自分がメンバーだったとき、やりやすいと思ったリーダー像」を重視したいと思います。

自分戦略研究所、フォーラム化のお知らせ

@IT自分戦略研究所は2014年2月、@ITのフォーラムになりました。

現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。

これからも、@IT自分戦略研究所をよろしくお願いいたします。