CLOSE

株式会社一休、田中健介氏、浅野慧氏インタビュー(全1記事)

2020.01.24

Brand Topics

PR

一休のマネージャーは、コードを書く––EMが語る、マネジメントと組織文化

提供:株式会社一休

高級ホテル・高級旅館専門予約サイト「一休.com」をはじめ、高級レストラン予約サイト「一休.comレストラン」など、様々なサービスを運営する、株式会社一休。一休のサービス開発を支えるエンジニア組織はどのような文化なのか? 株式会社一休 レストラン事業本部 プロダクト開発部部長の田中健介氏と、浅野慧氏に、一休の開発文化と組織づくりの裏側について語っていただきました。

一休のEMが語る、マネージャーの仕事

――それでは、お二人のポジションと、どんな仕事をしているのかを教えて下さい。

田中健介氏(以下、田中):田中健介と申します。一休には宿泊予約とレストラン予約のサービスがあり、私はレストラン予約サービスの開発の責任者をしています。

レストラン予約サービスのプロダクト開発部には大きくユーザー側の画面を作るチームと、一休に掲載いただいている店舗様が使う管理画面を作るチームの2つに分かれており、そのうちのユーザー側の画面を開発するチームのリーダーも兼務しています。

もともと私は宿泊サービスの開発チームに長くいて、昨年の春からレストラン予約の開発チームに移動してきたので、今のチームにはだいたい1年弱在籍しています。

宿泊予約チームでも同じようにユーザー画面の改善をずっとやっていて、そちらでも開発責任者をしていたので、2〜3年ほどマネジメントの役割を続けています。

浅野慧氏(以下、浅野):私は田中が言っていたレストラン予約サービスの、店舗様が使う画面を現在リニューアルしていまして、そこでフロントエンドエンジニアとしてコードを書いているという立場です。

少し前までは店舗側の画面を作るチームのマネジメントを1年弱ぐらいやりながら、カード決済の機能を作っていました。さらにその前はiOSネイティブアプリの開発チームのマネジメントをしていました。

――それでは、お二人が一休に入社するまでの経歴を教えて下さい。

田中:私は入社したのが2006年なので、だいぶ前です。私は一休が2社目なのですが、1社目はいわゆるシステムの下請け会社にいて、NTT系の会社が請けたシステム開発の一部を請け負う、2次請け3次請けのような会社で開発の仕事をしていました。

その会社で仕事をしていた後半に、今で言うB2CのWebサービスの開発に一部携わった時期がありまして、自社でWebサービスを開発している会社に行きたいと思ったので、いくつか会社を探して入社したのが一休でした。

浅野:私は今の会社は3社目で、最初に新卒で大学院を出てから京都にあるはてなという会社に入り、そこで5年弱ぐらい働きました。その後、もう楽天に買収されたのでなくなってしまいましたが、Fablicというフリマアプリの「FRIL(フリル)」を作っている会社に入社し、そこで3年ぐらい働いて、買収のタイミングで転職しました。

一休に入社したきっかけは、はてな時代にCTOだった現一休CTOの伊藤に声をかけてもらいまして、その縁で入社しました。

――田中さんは宿泊事業からレストラン事業に移ってきたとのことでしたが、なにかきっかけがあったのでしょうか?

田中:ぶっちゃけて言うと、もともと宿泊をやっていたときに私の事業部のビジネスのボスとずっと一緒に仕事をしてきたのですが、彼が宿泊事業からレストラン事業に移ることが今年の年初に決まり、その流れで「一緒にレストランやりましょう」というお話をいただいたのでレストラン事業に移ってきた感じです。

浅野:田中はその事業部長からの信頼が厚かったので、彼が「レストランに移るなら、田中さんも一緒に欲しい」と言って、それで一緒に異動したという感じです。

ビジネスとエンジニアのつながり

――ビジネス側とエンジニア側の結びつきが強いのでしょうか?

田中:一休って開発のディレクターや企画をやる部門がないんです。開発ディレクターみたいなロールは開発組織の中に存在していますが、ごく一部のメンバーです。企画やディレクションだけをやっている部門はないので、ビジネスのイシューをどのようにサービスに落としこむかという部分は、エンジニアとマーケティング、セールスも含めて話をしながら進めていく文化があります。

その過程では、ディレクションが得意なタイプのエンジニアがオーバーラップして企画や開発のディレクションをするケースが多いんです。なので、その意味では結びつきが強いと言えるかもしれません。

――浅野さんはWebサービスを開発している企業での開発経験を踏まえて、一休のエンジニアサイドとビジネスサイドの結びつきについて他社と比較して違いを感じられたりしましたか?

浅野:今までの会社も比較的結びつきが強いほうだったのですが、一休では現場の開発メンバーも毎週経営メンバーと普通にミーティングしていて、経営メンバーから直接「こういうことを考えている」という話を聞いて、それをそのままリーダーが自分の言葉で現場に話しているので、開発と経営が近くなる機会は多いと思います。

――なるほど。以前、榊社長にインタビューをさせていただいたのですが、社長のデスクがオフィスのど真ん中にあって、コミュニケーションが取りやすい環境が意図的に作られているなと感じました。

田中:そうですね。席配置はかなり気を使っています。私と、一緒にやってる事業責任者の栗山と、ユーザー画面を開発するチームは榊の近くにいて、そのあたりで話をして「じゃあ、こんな感じで」という話をして進めてしまうことがよくあります。

浅野:榊がずっとプロダクトのことを考えているというのもありますよね。

田中:そうですね。座席のレイアウトは基本的に職能ごとに並ぶのですが、例外的な部分もあって、プロダクトごとに会話量が多くなるように席を配置しています。

あとは、フリーデスクも多いので、そこで話していると周囲の人間がそこに自然に入ってくることもけっこうあります。それはビジネスの会話をしているときもそうですし、開発側にもフリーデスクがあるので、CTOが話している内容が耳に入ってくる状況もあります。

浅野:ビジネス側からのオーダーもスッと来るので、コミュニケーションは透明だと思います。

田中:そうですね。透明ですね。

一休の組織における開発チームの位置づけ

――それでは、一休の組織についておうかがいしたいのですが、開発組織の位置づけについて教えて下さい。

田中:宿泊とレストランのそれぞれの事業部は似たような構造をしているのですが、大きく分けて営業部門とマーケティングとプロダクト開発の3つの部門があります。

マーケティングは最近、宿泊・レストラン横断のチームになったので、厳密には事業部ごとにマーケティングチームはいないのですが、レストランのことを主にやっているマーケティングのメンバーがいます。営業は人数が多いので、営業の部門の中で細かいチームに分かれています。

開発は、先ほどもお話ししましたが、主にユーザーが触る画面を作るチームと店舗向け画面を作っていくチームに分かれています。宿泊事業もほとんど同じ構造になっています。プロダクト開発チームの中には、エンジニアとデザイナーが入っているので、私のチームにはエンジニアもデザイナーもいる構成になっています。

浅野:あとは、事業部に属していない、CTO室所属のエンジニアもいますね。

田中:CTO室は、開発の支援やインフラ、今だとSREといった領域を担当している部署です。事業部で大きなプロジェクトがあると、CTO室メンバーも一緒に進めたりもします。

店舗向け画面をリニューアルするに至った経緯

――先ほどレストラン側が使う画面のリニューアルを進めているというお話がありましたが、こちらはどんな経緯でリニューアルをすることになったのでしょうか?

浅野:けっこう話がややこしいですよね。

田中:ややこしいですね。

(一同笑)

浅野:まず、シンプルに今までのUIがかなり古くて使いづらいというのはあります。

田中:もともと2006年からやっているので、10年以上も前のシステムが大きくリプレイスをすることなく今まで運用されてきています。いまのシステムのままでは、今後新しい商品を作ったり掲載レストランを増やすところがボトルネックになってしまうので、リニューアルをしました。

また、開発の生産性というか、コアなロジックに対して手を入れていくような開発をするときに、素早く変更ができるようにするという目的もあります。

浅野:そうですね。UIのリニューアルに加えてコードベース自体も古いコードベースからPythonの新しいコードベースに移行して開発しているので、生産性の向上というのもあります。

――ちなみに、2006年のシステムはどんな技術を採用していたのですか?

浅野:Classic ASPという……おそらくあまりご存じないと思います。私も入社する前は知りませんでした。VBScriptというMicrosoftのかなり古い言語を使ってWebサービスが作られていて。プログラマの方なら「素のPHPに近い」と言えばなんとなくニュアンスが伝わるんですけど。

田中:そうですね(笑)。

浅野:とにかく古くてあまりモダンな機能は入っていないけれど愚直な言語で作られていて、先に田中が触っているユーザー側からPythonで書き直したのですが、そのシステムに我々が作っている管理画面にも移行し始めたという、そんな経緯です。

――Pythonを選ばれた理由は?

浅野:Pythonを選んだのは私ではなくてCTOなのですが、もともと「Light Weight Language (以下、LL)がいいね」という話がありました。

もともとのVBScriptはテンプレートを書き換えたら画面がダイナミックに変わるような言語で、一休にはデザイナーも直接画面をいじってコーディングしてデザインを変えたり動きを作るカルチャーがあったので、デザイナーも一緒に触れることが大事でした。

なので、テンプレートエンジンという仕組みでダイナミックに画面を変えられるものがよかったので、そうなると必然的にLLがターゲットになります。

そうなったときに「LL、今は何だろう?」ということを考えると、やはり機械学習の恩恵もあってPythonがすごく盛り上がっているので、Pythonがけっこういいんじゃないかという話になりました。言語の進化が今でも進んでいて、ユーザーもこれから増える見込みがあるので、Pythonを選択しています。

マネージャーも、コードを書く

――では、組織づくりについておうかがいしていきます。一休の組織づくりにおける特徴や、独自の取り組みはありますか?

浅野:自分が特徴的だと思うのは、マネージャーも全員コードを書いているところだと思います。これはCTOの伊藤の意向が強いのですが、一休にはマネジメントに専念している人はいません。プレイヤーをしながらマネジメントもするというスタイルを全員が目指しています。

田中:私自身がやっていて思うのは、私も自分の時間を100パーセントコードを書く時間に充てているわけではありませんが、リプレイスやリニューアルのことも含めて考えると、新しいコードベースがどのように作られているか、新しい機能を出すときにどんなことをやればいいのか、自分の肌感としてわかっていなければ、メンバーが困っているときに「じゃあ、がんばってね」と言って応援するだけの人になってしまいます。それだと組織のマネジメントがうまくいかないシーンが出てくると思います。

あとは、現場感を持っていれば、スケジュールが厳しそうだったらプレイヤーとして入ったり、スケジュールが妥当なのかどうかの見積もりを自分で精度高くできるようになったり、いろんな面で開発組織を引っ張るときに良いことがたくさんあると思っています。

もう1つは、単純に「両方できたほうがかっこいいよね」ってCTOも含めて話していて。

浅野:それはありますね。かっこよさみたいな話はありますね(笑)。「コードを書かなくなるマネージャーってちょっとダサいよね」みたいな、雰囲気がなんとなくあるんですよ。これは雰囲気と言っていいですよね?

田中:そうですね。ですが、やはり前者の「現場感を持ち続ける」ことは大事だと思いますね。

浅野:そうですね。

田中:今は新しいレストランのコードベースにそこまで深くコミットできていないので、自分自身の課題だと思っていますが、ある程度そこを判断できるようになると、最終的には「じゃあ私やるよ」ということが言えますよね。それができるかどうかはけっこう重要なのではないかと思います。CTOは実際そういう振る舞いをしていますからね。

浅野:そうですね。

田中:CTOもCEOもコードを書いていますからね。CEOが「じゃあ私がやる」って言うこともあります

浅野:そうですね。やっぱりそういう人には反論しづらい。

(一同笑)

なので、リーダーシップとしても意味があるのではないかと思います。やはりリーダーシップと意思決定の精度という2つの軸で、コードを書いている意味はかなりあると思っています。「マネジメントだけやってる人ってあんまりいらなくない?」みたいな話はよくしていますね。

田中:そうですね。実際いないですからね。

浅野:いないですね。それで組織のスピードはかなり速くなっているところがあると思います。

上手な時間の使い方を求められる

浅野:一方で、マネージャーは時間の使い方がすごく難しくなるので、その葛藤は常にあります。

田中:自分の時間をどう作るか、ミーティングに出る・出ないというところも含めて、自分の時間をどうするかという裁量がマネージャーにはあるので、「ほかのことが忙しくてそれができないのは、あなたの選択の結果だよね」という話にはなりますね。

浅野:時間の使い方と向き合うのはけっこうしんどいんですけどね。

田中:そうですね(笑)。

浅野:でも、一休のマネージャーは全員それで1回怒られます。

田中:だいたいそこは通る道みたいな感じはありますね(笑)。

浅野:マネージャーになって、ミーティングばかりやってしまって「開発の時間がない。コードが書けない」と言ってると、「それはお前の時間の使い方の問題だろ?」と言われて「あっ」ってなるって道を通ります。

田中:一休の場合、面倒な根回しにあまり時間がかからなくて、ステークホルダーのところに直接話に行くのが一番早いので、カスタマーサービスのメンバーと直接話したり、事業責任者と話したり社長と話したり、コミュニケーションパスがシンプルなので、頭を使えば時間はかからないという環境もありますね。

――なるほど。そういう環境があるからこそ、ミーティングをたくさん入れてコミュニケーションにコストかけるのではなく「工夫すればできるでしょ?」と言われるということですね

田中:そうですね。

浅野:おっしゃるとおりです。

――ちなみに、プレイヤーだったときと比較して、マネージャーをやってる今は、業務時間のうちどのくらいコードに触れていますか?

田中:どうなんだろう? 半分ぐらいですかね、半分ぐらいを意識していますね。

浅野:私がマネジメントしたときは、それほどメンバーが多くなかったので、6、7割ぐらいはコードを触る時間が取れていましたね。

マネージャーとして意識していること

――マネージャーとしてチームメンバーを見るに当たって、どんなことを意識してマネジメントをしていますか?

田中:事業としては大きい数字の目標があって、そこに結びつく数字的なKPIをチームとして持っているので、その目標を達成するために、各メンバーのタスクに落とし込んで、それぞれのメンバーは別々のことをやっている状態です。

彼らがやっていることが成果に結びつくかどうかの部分の責任を私が背負っているので、開発をしやすい環境をつくるというよりも、どうやって成果を出すかという文脈でチームのメンバーを支援する動き方を意識しています。

――ちなみに、どういったKPIを持たれているのでしょうか?

田中:私たちのサービスは大きく括るとECのシステムなので、物を売るわけではありませんが、検索されて、レストランが予約されることが最初のゴールになります。ですので、一休に来たお客様がどれぐらいの割合で予約をしているかというCVR(コンバージョンレート)がチームのKPIになっています。

――なるほど。では、店舗向けシステムの開発チームではどのようなKPIがありますか?

浅野:こちらにはKPIらしいKPIは、明確な数値目標としてはありません。もちろん全体の売上は我々の責任ではありますが、なにかやれば上がるという個別の要素はあまりないので、そこがリンクしていないというのが実態ですね。

田中:そうですね。そこは若干間接的になってしまいますが、レストランのサービスというのは、結局はレストランに商品を掲載していただかないと私たちは売るものがなくなってしまうので、掲載レストラン数が事業のKPIを分解した1つとしては存在しています。

なので、掲載店舗をどうやって増やしていくか。あるいは売っている商品がちゃんと良いものになっているか、商品力があるかどうかというところは、店舗側のオペレーションに沿ったかたちで機能が作られている必要があるので、そこをどれだけ加速させられているかは見ています。

――なるほど。

ビジネスへのコミットを測るための評価制度

――それでは、評価制度についてお聞きしたいと思います。マネージャーとして、チームのメンバーをどのように評価していますか?

田中:評価はすごくシンプルで、個人で目標を立てつつ、年2回で事業への貢献度を評価しています。半年を振り返ったときにどれぐらいの貢献度があったかは、3つの軸で見ています。

1つは業績貢献です。私たちは事業会社なので、事業の成長にどれだけコミットしたのか。次に、組織革新にどれだけ貢献したか。例えば「チームの生産性が上げるためにこんなことをしたほうがよい」など、なにかそこでexecuteしたことがあれば、それを評価します。

もう1つが人材育成貢献です。これはジュニアよりも上以上のメンバーに求められるのですが、新しいメンバーのオンボーディングや、若手のエンジニアと話をしながらそのメンバー能力を引き出すといった分野で貢献度が高ければそこを評価します。

これらの評価軸は、エンジニアにかかわらず、会社全体でその評価軸がある感じです。

もう1つ、これらの3つの軸に加えて、エンジニアにはエンジニアとしての行動評価という項目が存在しています。エンジニアの仕事の中には、定量的に評価が難しい仕事も存在しているので「技術的にこんなすばらしい貢献をしてくれた」とか「この人が作ったこの機能によってみんなの生産性が上がった」みたいなことがあったら、そこは別軸で評価を補正して、最終的な評価を決めています。

事業としての評価とは別軸でエンジニア横断的に最終的な評価をCTOと話す場があって、そこにマネージャー全員出るんですけど、そこでエンジニアリングの文脈での議論をしています。

浅野:あとは360度評価も存在していて、一緒に働いているチームメンバーや間接的に働いている人からの評価もあります。最終的にマネージャーがまとめて評価をつけるのですが、そこで判断材料の1つになります。

――3つの指標と別にエンジニアとしての評価があるとのことでしたが、どの評価項目に最も重きを置いているのですか?

田中:評価のウェイトは公開できませんが、私たちは事業の成長を大きな目標としているので、そこでの貢献度が高いことを最も重視していることは間違いありません。なので、技術的にイケている取り組みをしていたとしても、それが事業にとってどのくらい影響があったのかは見ています。

――評価制度からビジネスにコミットすることを目的とした設計になっているということですね。

田中:そうですね。マネージャーと1on1で自分の目標を立てるのですが、そこで握っています。「チームとしての目標はこうです。事業としての目標はこうです。あなたはどうするの?」という話をしながら、その人がやることだったり「ここで自分は貢献したい」ということを決めています。必ずしもチームの目標に沿った目標を立てるわけではありませんが、最低1個はそれを入れているという感じですね。

SIerでの経験が活きる理由

――採用についてお聞きしたいのですが、お二人は面接に出られることはありますか?

浅野:そうですね。2人ともだいぶ出てます。

田中:採用にはけっこう関わっていますね。

――面接に来る人に傾向はありますか?

田中:比較的候補者の方は多様だと思います。バックグラウンドも、事業会社にいた方やSIerの方、メーカーにいた方など、かなり多様です。

ただ、面接に来る人の志向としては、やはり自社で事業をやってるところでエンジニアの仕事がしたいと思って応募してくださる方が多いです。

浅野:「ユーザーにダイレクトに届くモノづくりがしたい」みたいなことはみなさん仰る気がします。

――SIer出身の方も比較的多く在籍しているという話をお聞きしたのですが、それはどうしてでしょうか?

田中:それはSIerのスキルが一休のプロダクトを開発していくときに活かせるシーンがあるからですね。

私たちが開発しているのはECのシステムなので、自社のWebサービスという括りで言えば、アジャイルにモノづくりをしてお客様の行動を見ながらブラッシュアップを続けていく、いわゆるWebっぽい開発の仕方がフィットするシーンと、予約や決済などの認証も扱うシステムなので、そこはどちらかというとしっかりモノづくりをするやり方のほうがフィットしますね。

なので、トランザクションが発生するようなシステムを扱った経験や、金融などのシステムの経験が活きます。その両面あるので、それぞれの専門性がどちらでも活かせるということですね。

――なるほど。つまり、一休ではSIer経験が活きて、かつ、来てくれる人は事業会社でお客さんが触れるサービスがやりたいということで、結果的にSIer出身の方が多くなっているということでしょうか?

田中:そうだと思いますね。

求めるスキルとリーダーシップ

――SIer経験が活きるという話もありましたが、一休で開発を行う上で「こういうスキルがあるといいよね」であるとか、「こういうスキルを求めています」ということはありますか?

浅野:これはどちらかというとマインドみたいなところですが、なんらかのかたちでリーダーシップを発揮してくれるかどうかはけっこう見ていますね。

自分である技術を導入して開発の生産性が上がった、ユーザーの体験が良くなったり、そういうことはすごく評価されます。例えばほかの部署とのコミュニケーションでリーダーシップを発揮して、その人がすごく重要なハブになって、全体のスピードが上がったり意思決定のスピードが上がったりといったことも評価されますし。

そういったいろいろなケースがありますが、なんらかの分野でリーダーシップを発揮してほしいという期待があるので、そんな経験やマインドを持っている人はすごく評価しています。

――開発にまつわるスキルについてはいかがでしょうか?

浅野:中途入社の場合は、ある程度ジュニアなメンバーとシニアなメンバーで見方を変えているのですが、そこそこシニアであれば、Ruby on RailsでパッとWebサービスを普通に作れるくらいのスキルはベースとしてあります。それに加えて、今はフロントエンドも大事なので、フロントエンドも書けるとさらに良いですね。

田中:Webサービスの開発や運用をしていると、そこで必要なノウハウというのは「この言語をやったことがある」とか「このフレームワークを触ったことがある」ということではなく、Webアプリケーションはこんな仕組みで動いていて、裏側のHTTPの通信の中身はこういうものがあって、データベースに問い合わせるときにはこういうお作法があってとか、そういった一般的な知識を面接で聞いたりしています。

あるいは、どこに強みがあるのかを面接の中で見ています。それが先ほど言ったリーダーシップだったりするのかもしれません。

面接で見ているポイント

浅野:面接では簡単なコンピュータサイエンスっぽい質問をしたりすることもありますね。例えばデータベースのチューニングなど、日常的な業務の中で使う最適化がちゃんとできるかどうか、ある程度基礎知識を知ってるかどうかは見ています。

なので、めちゃくちゃ高度な質問をするわけではないのですが、ある程度の基礎を勉強しているかどうかは見ていますね。

田中:技術的なところ以外だと、宿泊予約やレストラン予約というプロダクトのどこに関心があるのか、実際の画面を見せながら「例えばこの画面にとある課題があったとします。あなたはどうしますか?」みたいな話をしたり、「私たちは現在ネイティブアプリの開発を積極的にはやっていない状態なのですが、それは何でだと思いますか?」とか。

プロダクトやビジネスに対する関心度合いや観点がどこにあるのかを聞いたりしています。

――面接ではホワイトボードテストをやられたりすることはありますか?

浅野:面接の中ではやることもあります。私はとくにやってるかもしれませんね。いくつか観点があるのですが、明らかにコードが書けそうな人に対してはやりません。でも、履歴書だけではスキルがわからない人もいるので、そういう場合にはホワイトボードテストをしたりします。

先ほど言ったコンピュータサイエンスっぽいところを見るには、書いてもらって「これをもうちょっと速くするにはどうしたらいいですか?」という聞き方をするとやりやすいのでそういうときに出したりとかします。

田中:それに回答できるかどうかが重要なのではなく、その思考に基づいているバックグラウンドの知識があるかどうかを見ています。会話によって正解を導いたり、ディスカッションができるかどうかみたいなことも含まれていますね。

浅野:そうですね。正解する必要はないので、こっちからヒント出すこともありますしね。

一休に向いている人、向いていない人

――一休に向いている人、逆に向いていない人はどんな人でしょうか?

浅野:ユーザーのためにモノづくりをしたい人はすごく向いてますね。あとは、自分の成果をダイレクトに感じたい人も向いてます。他には、ちゃんとやったことで会社が成長すること。簡単に言うと儲かるということですが、そういうことを感じたい人にも向いています。世の中にそうでないサービスはいっぱいあるので、なので、そういった応募意向がけっこうある人もいますね。

田中:そうですね。

浅野:「ちゃんと儲かるのがいいですね」って言って来られる方もいるので、そういう人は向いていると思います。

田中:実際に入社したエンジニアの中にも、「儲かってる会社に行きたい」「一休はそこをすごくがんばっているので」というふうに言って入社したケースもあります。その時はちょっと珍しいなと思ったんですけど。

浅野:儲からない会社にいた人ほどそういう傾向がありますね。私はすごくわかります。

一方の向いていない人ですが、技術志向100パーセントみたいな人はけっこうしんどいですね。

田中:そうですね。やっぱりビジネス的な価値あっての技術なので。実現したいことに対してオーバーエンジニアリングにやり過ぎてしまったり、アーキテクチャを作り込み過ぎてほかの人がわからないという状態になったりすると、結局「何のためにそれをやってたんだっけ?」という話になります。私たちは手段と目的をはっきりした上で技術を正しく使えるかどうかを見ているので、技術に振り切っている人はやりづらいと感じる部分があるかもしれません。

浅野:かといって技術志向がいらないわけではまったくなくて。やはりバランスなので、プロダクト志向と技術志向がバランスよくある人にきてほしいですね。それが技術に振り切れていると、おそらくそういう人がなにか技術的にすごいことをやったとしても、あまり評価されないところはあります。

田中:一方で、ある程度組織は多様でいいと思っています。バランス型人材が50人中50人だと組織としては弱いと思うので、そのあたりの濃淡をつけて「技術に志向があるんだけど、よくよく話をしてみるとプロダクトのことを考えている」みたいな人は採用するケースもあります。

セグメントの中で一番を獲りたい

――では、今後取り組んでいきたいと思っていること、取り組むためにどんな人を求めているか、メッセージをお願いします。

田中:レストランは、オンラインで予約する方向にどんどん進んでいます。ほかにもさまざまな飲食系サービスもあるなかで、私たちはFine Diningと呼ばれているちょっといいレストランを扱っているサービスとしてポジションを取っているのですが、ちょっといい時に使うのであれば、自然と一休が選んでもらえるという世界を当たり前にしたい、いいレストランのセグメントの中では一番を獲りたいと思っています。

そのためには、プロダクト開発をして事業の成果を目指すことに共感をしてくれる方。技術的な専門性がどこかしらにあって、その専門性をうまく事業の成果にコミットさせられるタイプの方とぜひ一緒にやりたいですね。

浅野:私の視点ですと、一休は今はプロダクトのほうが強くて、逆に技術のほうがまだ弱いなと思っています。

なので、技術にすごく強みがありつつ、それをビジネスに役立てたいという人がいると、もっと組織が強くなるのではないかと思います。さっきは「技術100パーセントみたいな人は向かないです」みたいな話をしたんですけどね……。

田中:(笑)。

浅野:でも、技術に強みがあるけれどビジネスにも興味がある人に、もっと来てほしいというのはありますね。

田中:そうですね。

浅野:一休はそれほどテックな会社とは認知されていないかもしれませんが、そちら側も蔑ろにしていいものではないと思いますし、我々も組織をもっと強くしていかなくちゃいけないと思っているので、「技術ベースだけど、ビジネスに取り組みたい人」みたいな人を今はすごく求めていますね。

サービスが、リアルな世界に影響するおもしろさ

――一休で働く魅力とは、どんなところでしょうか?

浅野:やはり事業自体がおもしろいことですね。自分はもともと食べるのが好きでお店を開拓したり食べに行ったりするのが好きなのですが、一休ですとユーザーとしての視点とお店側の視点の両方を見ることができて、その中に入っていけるのがおもしろいことだと感じています。

飲食店側の課題もわかりますし、ユーザーはこう動くんだ、という発見も毎日あります。飲食シーン全体を見れることはおもしろいところですね。

田中:同じ文脈の話になってしまいますが、私が一休のビジネスでおもしろいと思っているのは、飲食の予約ってまだ電話が多いですよね。でも、宿泊予約を電話でするケースってほとんどありません。

私が入社したのはレストラン予約のサービスが立ち上がるちょっと前なのですが、飲食をネットで予約することなんてほとんどないという状況から、10年以上が経って、飲食をインターネットで予約するのがなんとなく当たり前になりつつある状況です。これはおそらく今後数年で宿泊と同じような状態に近づいていくと思います。

そういった時代の変化の中で、飲食という人の生活にかなり紐づいているドメインのサービスを開発していけるのはすごくおもしろくて、オンラインで完結しないサービス開発のおもしろいところをやっている感覚があります。

――なるほど。リアルな世界が変わっていくことに関与しているおもしろさということですね。

田中:そうですね。その前線にいる感じはすごくあります。おもしろいんですよ。

浅野:おもしろいですよね。

田中:うん。

――では、一休の組織で働く魅力は?

田中:私たちのエンジニア組織は50人ぐらいで全体が見通せるサイズなので、社歴や年齢はあまり関係なくて、能力のある人がシステムのリニューアルやリプレイスに深くコミットしています。組織的に階層がたくさんあるわけではないので、そこはおもしろいところなのではないかと思います。

浅野:何度か出ていますが、ビジネスがすごくソリッドでまっすぐな会社なので、成果も見えやすいですし、私が今までいた組織だと開発が強い組織が多かったのですが、逆にビジネスと開発がすごく直結しているので、自分の成果がわかりやすいところがおもしろいです。

今までの開発文脈の自分にはなかったビジネスの観点であったり、そういったことにダイレクトに触れられる面白さがあります。

田中:私たちのサービスはすごくシンプルなビジネスモデルです。店舗やホテルの方が出してくださった商品をお客様が予約して、来店された予約の金額の一部を手数料としていただくというモデルだけなんですよ。なので、お客さんにとって使いやすいサービスにしていくことにまっすぐ取り組めるので、すごくやりがいがあります。

例えば、メディアのビジネスモデルって広告を張りますよね。その場合の広告って、広告をはらなければサービスの収入が生まれないから広告を張るわけですが、張ることがそのメディアのサービスを使っているお客様のためになるとは限らないですよね。

でも、私たちのサービスは、お客さんにとって使いやすいものや良い商品を届ける、ちゃんと見せてあげることにとことんこだわって、実際にそれをお客様が支持してくだされば、最終的に私たちの利益になるので、そこを磨くことにまっすぐ取り組めるのはおもしろいですね。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

株式会社一休

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • モンスター化したExcelが、ある日突然崩壊 昭和のガス工事会社を生まれ変わらせた、起死回生のノーコード活用術

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!