第18回 「それはエンジニアの仕事じゃない」なんて壁をつくるな
岑康貴（＠IT自分戦略研究所）
赤司聡（撮影）
2009/6/8
 |
| 長友肇（ながともはじめ） リクルート メディアテクノロジーラボ チーフビジネスプロデューサー 1975年10月2日、神奈川県出身。早稲田大学商学部卒業。リクルートに新卒入社し、情報システム部を経てHR部門にて「リクナビ」の企画業務に携わる。同部門の新規事業開発を手掛けた後、メディアテクノロジーラボの立ち上げに従事。2007年4月に同組織を立ち上げ現在に至る。 |
■「システムと企画の現場はもっと近づくべき」
1999年にリクルートに新卒で入社して、今年で11年目になります。最初の2年半は情報システム部で社内SEをやっていました。「リクナビNEXT」の構築などを手掛けました。
その後、人材系サービスの部署に志願異動します。「リクナビ」の商品企画やWebサイトの編集、広告の取りまとめなどいわゆる「企画屋さん」として働くようになったんですね。これが4年間くらい。さらにその後、新規事業開発の部署に1年ほど。
もともとテクノロジ側にいたのですが、「システムと企画の現場はもっと近づくべき」と考えていました。企画業務にシフトしたのは、システムをやっていた人間が企画の現場に入ることで、それを実現しようという理由です。ところが企画業務を5年間やった結果、「やっぱりもう1度、テクノロジ側に戻らなきゃ」となった。そっちからの歩み寄りもやっぱり必要だと思いまして。志願して、情報システム部に舞い戻りました。
時代は変わりました。変化のスピードが上がり、わたしたちのような広告メディア業は、テクノロジ側からのアプローチが欠かせないものになったのです。
「R＆Dのようなことができる機関が必要だ」と声を上げていたところ、テクノロジ側の役員が賛同してくれまして、「BIコラボレーション委員会」という組織を立ち上げることができました。ビジネスとITのコラボレーションから生まれる新しい可能性を、テクノロジ側から社内に向けて提案していく、という組織です。
この組織とは別に、関連会社のリクルートメディアコミュニケーションズが「たたみラボ」という社外向けの実験的なサービス開発機関を持っていました。2年ほどBIコラボレーション委員会を続けた後、たたみラボと融合してメディアテクノロジーラボを設立しました。
わたしは「いい出しっぺ」ということもあって、組織の全体設計から実際のチーム作り、どういう目的でどんなアウトプットを出すのかまで……要するに、設立にかかわることを全部やりました。メディアテクノロジーラボはこのような背景があるので、現在もATNDなど外部向けのWebサービス開発だけでなく、社内向けのサービス開発や提案も行っています。
■サービスオリエンテッドな事業開発組織
| エンジニアライフ コラムニスト募集中！ |
あなたも＠ITでコラムを書いてみないか 自分のスキル・キャリアの棚卸し、勉強会のレポート、 プロとしてのアドバイス……書くことは無限にある！ コードもコラムも書けるエンジニアになりたい挑戦者からの応募、絶賛受付中 |
メディアテクノロジーラボは「ラボ」といいつつ、実際は新規事業開発、インキュベーションのような役割を担っています。
旧来のメディア開発というのは、マーケティングを通じてニーズを分析して……というウォーターフォール型でした。でも近年のWebの世界では、まずサービスやプロダクトがあって、はやったものをビジネスにしていくというサービスオリエンテッドな考え方が主流になりつつありますよね。
リクルートはそういうやり方で事業開発をしたことがありませんでした。でも時代は変わりました。実は従来のようなウォーターフォール型の新規事業開発の部署もあるんです。それももちろん大事。メディアテクノロジーラボはそのカウンターとして、まずは素早く多くのサービスをどんどん自分たちで作って公開し、芽の出ないものは手早く畳み、受けたものをビジネスにしていくという手法を採っています。
最初は15人くらいで、前身の2つの組織のメンバーが中心でした。現在は約30人が所属しています。なぜ「約」なのかというと、元リクルートの業務委託の人とか、完全に社外の人とか、社内でも半分兼務の人とかがいるので、明確に何人といいづらいんですよね。非常に流動的です。わたしが社内外で「おいでよ」と誘った人も結構います。
■コードも書くし、損益計算書も書く
メディアテクノロジーラボの事業開発は3段階。最初に「α」があって、この段階はメンバー各自が自由にサービスを作ります。本当に「なんでもアリ」で、その代わりお金も時間もかけずに作ることが求められます。αの中でも面白いものは「昇格会議」にかけて、審査に通ると「αプロジェクト」に昇格します。この段階になると、多少予算が付いて、「価値のあるものを作る」というモードに移行します。さらにこれが発展すると「βサービス」となり、いよいよ事業として準備する段階に入ります。この段階ではビジネスモデルの構築が求められます。
この組織には、あえて分けるとプランナーとデザイナーとエンジニアがそれぞれ3分の1ずつ所属しています。でも、はっきりいって3者に垣根はありません。ごちゃ混ぜです。パパッとサービスを作ってくるエンジニアがいれば、企画書から入ってくるプランナーもいます。同時に、エンジニアもビジネスモデルを考えますし、プランナーでもコードを書く人もいます。
わたし自身、「何屋さんか」と聞かれたら「企画屋さんです」と答えますが、コードも書きますし、損益計算書も書きます。また、リーダー的な側面としては、最終的にビジネスにするというところを中心に、全体を見ています。
「エンジニアだから」とか「プランナーだから」とかの垣根はもう存在しないんですよ。結局、目指すゴールは1つですから。
■エンジニアとプランナーは融合する
テクノロジと企画の現場は近づくべきだし、エンジニアとプランナーはそれぞれ垣根をつくるべきじゃない。これはずっと思っていたことです。
エンジニアを見ていて思うのは「もったいない」ということです。ものを作る力はあるけど、いわれたものを作るだけの人が多過ぎる。一番大事なのは「何を作るか」じゃないですか。エンジニアが企画も考えて、ビジネスのところまで考えたっていいはずなんですよ。でも壁をつくっちゃう。それはエンジニアの仕事じゃない、って。
逆に、プランナーや営業の人だってテクノロジのことを考えるべきです。サービスの開発は昔よりやりやすくなっているはずですから。ところが「バッチって何？」というレベルのプランナーがいたりする。
これは私見ですが、プランナーや営業がテクノロジを後から学ぶのと、エンジニアが後からビジネスを学ぶのだと、最終的に両方できるようになるのが早いのは後者なんじゃないかな、と思います。いずれにせよ、最終的には融合していくと思いますよ。たまたま職種として分かれているだけで。
■壁の位置を広げるのがリーダーの役目
エンジニアのする仕事はクリエイティブであってほしいと思います。ものを作る人なんですから。わたしは、どうすればそういう人の集団が作れるか、ということを考えています。
エンジニアは自分で壁をつくりやすいんですよね。エンジニアだからやるのはここまで、というように。この壁は創造性を阻害する可能性があります。
壁を越えるためのポイントは2つあると思います。1つ目は「成功体験」。自分のやったことが評判になるとか、小さなことでもちゃんと褒められるとか。「今週はユーザーが1000人増えた。よくやった！」みたいな。さらにいえば、エンジニアでも自分の作ったサービスにアフィリエイトなどを組み込んで、自分の技術がお金に変換されるという成功体験を積むといいでしょう。小さな成功体験からでいいんです。
2つ目は「壁の設定」です。自分で「この辺りでいいや」と設定する壁の位置を、もうちょっとだけ広げてあげる。これがわたしの仕事だと思っています。あえてエンジニアにお金を稼がせる。あえてプランナーに最初は自分でサービスを作らせる。どちらも同じことです。
ラボというのはなんでもありなので、なんでもありであるが故の不自由さが存在します。羊の群れに関する面白い話があるんですよ。羊は草原に放り出すと、大きな木の近くに固まってしまいます。ところが柵を作ると、柵のぎりぎりまで動くようになるんです。
わたしの仕事は、この「柵」の設定だと思っています。これをみんな「この辺りでいいや」と置くので、わたしがそれをちょっと広げたり、時にはその中に川を流してみたり。そうやって挑戦させて、成功体験を積ませるのが重要です。実はこれ、リクルートの昔からのマネジメント手法なんですけどね。
これからITの世界でやっていくのなら、いろいろなことができる人になってほしい。自分ができると思ったことは、ある程度までとにかくやってみること。それが結果的には、自分の仕事の幅を広げることにつながるはずです。
| » ＠IT自分戦略研究所 トップページへ |
＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、＠IT自分戦略研究所をよろしくお願いいたします。
