この名を知らないとしたら、ソフトウェアエンジニア業界ではもぐりだと言えるほど、その名が通った人物だ。ニフティのブログサービス『ココログ』の開発者であり、はてなの元最高技術責任者、GREEでソーシャルメディア開発をしていたと言えば、その華麗な経歴のほどが分かるだろうか。
実際、2016年に一休の執行役員CTO/システム本部長に就任する直前まで、一休をはじめ6社に対して、技術顧問という立場で各社のテクノロジー部門を支援していた。十分に個が際立ち、世の中への影響力も発揮しているにもかかわらず、伊藤はなぜ、いち社員として一休に参画することに決めたのか。
そして、伊藤率いるエンジニア部隊は、一休が実現し続けている非連続の成長に対して、どのように寄与しているのだろうか。
CTO就任後に待ち受けていた、経験したことのない異世界
「冷静に考えると、引き受ける必要なんてなかったんですよ（笑）」
一休から強烈なリクルーティングを受けた当時のことを振り返り、冗談めかして伊藤はそう言った。「時間的拘束は増えるし責任も増える。部下を抱えることになるから当然ストレスも増える」。
しかし、大きな改善やメンバーの成長を実現したとしても、社員ではない自分は、同じように喜べない。いつしか寂しさを感じるようになっていた。同時に、外部からかかわる一休のテクノロジー部隊への責任も芽生えていた。
「一休には当時、CTOがいなかった。これからの一休にCTOのような技術の先導役が必要なのは明らかだった。そんな中でも頑張ってる開発のメンバーたちを見ていて、なんか、そろそろ責任ある立場から逃げてる場合じゃないなと熱くなっちゃったんですよね」。
そして伊藤は決断する。他社の顧問契約を全て終了させ、2016年、一休に正式『入社』。顧問として関わるようになってから、2年後のことだった。
実際に社員となって、何か違いはあったのかと訊ねると、こう答えた。
「顧問として色々と見えていたつもりでしたが、やっぱり大きく違いました。一休は一見IT企業のように見えますけど、あくまでホテル予約やレストラン予約ビジネスの会社なんです。一方で、それまで僕が経験してきたのは、ソフトウェア開発の会社。もちろん一休でも仕事の内容は開発だし、開発組織をマネジメントすることは変わらないんですが、会社の意思決定の優先順位が、結構違いました。経営にかかわる立場になってそれを強く認識するようになりました」。
レストラン予約サイトの改修における、榊（現 代表取締役社長）とのエピソードが象徴的だ。
「改修目処を聞かれて、いつもどおりの見積もりで、来年2月と答えたら、榊さんから言われました。『それは自分たちのペースで仕事をしたら2月になりますっていうことでしょ。そうではなく顧客がいつ欲しいのかで考えて。それがビジネスの考え方だよ』と。あー、確かに。エンジニア視点での見積もり、自分たちの作業を積上げ式で換算していくのが計画を立てる普通の方法だと、当たり前のように思い込んでいました」。
これはあくまでも一例にすぎないが、ただ単に開発のスピードを早めたかった訳ではない。もっともユーザーが欲しい時期に改修が終わらないということは、ユーザーのためでないということ。一休の意思決定が、『ユーザーファースト』であることがよくわかる。しかしこれは、ソフトウェア開発中心の現場に携わってきたエンジニアにとっては異質な世界だ。
例えば、ソフトウェア開発中心の会社においては、プロダクトの品質の高さが、経営の意思決定の最上位に来ることもある。良い商品・サービスを作るためには、相応の時間は必要であり、求めるクオリティに満たなければ、極論、リリースを遅らせるという選択も十分に考えられるからだ。
意思決定の最優先事項は、「ユーザーが求めているかどうか」
「極論いえば、ソフトウェア開発に重きを置く現場では、今いるエンジニアで無理なくやれるかどうかが物事の基準になることもある。でもビジネスの世界ではそんなこと関係ない。ユーザーがそれを求めているかどうか、それが基準です。一休はビジネスの会社。エンジニア基準で“やれるかやれないか”ではなくビジネス基準で“どうやるか”を考える。自分自身をそういう考え方に変えていく必要がありました」。
とはいえ、ハイプレッシャーな状況でもプロダクトのクオリティは絶対に落とさない。そのための方法は、開発チームでずっと思考していますからと力を込めた。その結果、メンバーの多くもこの状況を面白がれるようになったという。
「突きつけられる条件が厳しくても、『おーまじか。やりますか！』と言ってくれるメンバーが増えましたね。頼もしくなりましたよ」。
一休の非連続の成長は、エンジニアたちの変化が支えている部分が大きいのではないか。そう尋ねると、「昔はエンジニアで一つの部署だったんですけど、それをやめて、ビジネスの現場でエンジニアを必要としているところに彼らを配置する、つまりエンジニア組織をばらばらにしたことは、成長に寄与したかもしれない」と明かした。
与えられたタスクをただこなすのではなく、営業やマーケティングと一緒にエンジニアも自らビジネスやユーザー体験にコミットするようになった。「サービスサイトのUIを変えたことで、予約数が上がった」といった自身の成果の話を耳にする機会が増えるにつれ、ビジネスと自身の仕事の連携が気にかかるようになった。
「いま思えば、かつての体制は役所に近かったかもしれない。相談窓口があって、奥に控えるエンジニアリソースが空くのを待っている。ものごとの優先順位はビジネス基準というより、ファーストインファーストアウト。そこからエンジニアが組織全体の中に点在する形に変えたことで、エンジニアとビジネスの現場の関係は近くなり、ビジネス基準の優先順位で物事を進めるようになって課題解決までの時間が短くなりました。エンジニア部隊を束ねる難易度は上がりましたが、ユーザーファーストという意味ではこれが正解だったと思います」。
しかし、営業やマーケティングをはじめとしたビジネス現場の面々とコミュニケーションしながら、達成レベルや納期を調整していかなければいけない状況は、エンジニアにとって不慣れな環境であることは間違いない。エンジニアリングの内容ではなくて、ビジネスってなんでしょうか…と、悩んで相談に来るメンバーも少なくないという。
「難しいことを求めているので、正直なところ、辛いと弱音を吐くメンバーも出てきます。でも、辛いからユーザーファーストをやめるということはないです。ユーザーよりも自分たちを優先するのは、ユーザーファーストではなく、自分たちファーストになっちゃうので。やっぱりユーザーに妥協しないということが、一休という会社の姿勢ですから。ここでやっていくなら自分が変わるしかない」。
一休のエンジニアであれば、エンジニアとしてのクオリティを出すことはもちろんのこと、ビジネスを理解し、ユーザーオリエンテッドで動けなければ価値はない。
伊藤の意識は、社員になって確実に変わっていた。
組織のキャップにならないために。自分が一番苦手なところに飛び込む
ビジネスサイドの高い基準は、経営陣が総出で示してくる。一方で、一休におけるエンジニアサイドの基準を決めるのは、やはりCTOである伊藤になるのだろう。
「ビジネスサイドの考えが強すぎる会社では、エンジニアに圧力をかけすぎてエンジニアリングのあれやこれを毀損するということもよく起こります。一方、エンジニアサイドが強すぎる会社は、ビジネスで成果を出すのを優先できないことも多い。僕たちは、両方取りに行きたい。そこは妥協をしない、僕はユーザーファーストだからといってエンジニアリングの要求水準を下げたりしない」。
自身を含めエンジニアは、常に高みを目指したい人種だということを知っている。この程度でいいとは誰も思っていない、高い基準を知ればそれに向かう。
「僕はもっともっとビジネスにコミットしないといけない。自分たちが苦手なところでも思い切って飛び込むことで、きちんとバランスを取りたい。ビジネスとエンジニアリングを両方高い基準でやれてる会社にできたら、かっこいいなって」。自分の成長がメンバーの、エンジニアリングチームの、そして一休の成長に寄与する。メンバーに高い基準を示すためには、自分自身が高みを目指し続けなければならないと考えている。
「苦手だとか好きじゃないとか、それは誰にでもある。でも、それらから逃げずに取り組まなければと思うタイミングって、あるじゃないですか。ビジネスにコミットしてエンジニアリングにもこだわり抜くことから、逃げない。大変だけど。僕は今そういうタイミングなのかな」と言った後で、笑ってこう続けた。
とか言いながら、毎日釣りしてたいなぁって思うこともありますよ、と。
一休の募集一覧はこちら＞＞
