以前より国内トップクラスのWebエンジニアとして名を馳せていた伊藤直也氏。一休の執行役員CTOに就任することが発表されてから、約3年半が経過した。CTOのキャリアとしては「はてなブックマーク」の開発を手掛けたはてなに次いで一休が2社目となる。

7人目のメンバーとして参画したはてな時代とは異なり、ビジネスモデルがある程度確立している一休の組織で経験を積んでいくなかで、伊藤氏は事業会社のCTOとしてあるべき姿に気付いたという。

同氏は現在、CTOの役割をどう考えているのだろうか。外部技術顧問時代から関わってきた一休の5年間を振り返りながら、明らかにしていく。

一休 執行役員 CTOの伊藤直也氏

問題を「解決する」のではなく、問題を「理解する」サポートをしていた技術顧問時代

――はてな時代と現在の一休とで、CTOとしての役割に違いはありますか。

はてな入社時はエンジニアが3人しかいなかったので、CTOというよりはリーダーのような役割でしたね。

エンジニアが少しずつ増えていく状況でそれぞれが仕事をしていると、「なんかボールがたくさん三遊間を抜けていくぞ」みたいな感じで、明確な担当者がいない領域の問題が放置されて状況が悪化してくじゃないですか。

当時はチームビルディングをしながら、そうした”ボール”をひとつずつ拾っていくような仕事をしていました。小さい会社が大きくなっていく過程でリーダーシップをとっていたというのが、はてな時代です。

一方で一休は、入社した時点で従業員数200人、宿泊・レストラン予約事業の流通額が数千億という大きなビジネスを手掛けている会社でした。現在はそこに対して技術的な戦略性をもって意思決定しています。

どちらかというと今の一休での役割のほうが世の中のCTOのイメージに近いかもしれませんね。

――そもそも一休との出会いは何がきっかけだったのでしょうか。

僕が関わる以前の一休のシステムは、古くなったレガシーシステムに苦労している状況でした。エンジニアの体制もできておらず、いろんなことが硬直化している状態で、経営陣も現場も「開発をなんとかしなければ」という意識があったようです。

そうしたなか、現在開発部長を務めている社員が「伊藤さんのブログを読んでいると自分たちの会社とはぜんぜん違う。やり方を教えてください」と、僕のところへ相談にきました。僕は当時、フリーランスでいろんな会社の技術顧問を担当していたので、自然なかたちでクライアントのひとつに一休が加わりました。

――技術顧問時代には各社とどのような関わり方をされていたのですか。

もともとフリーランスになって技術顧問を始めた当初は、技術顧問という仕事に意味があるのかどうか、自分でも疑問に思っていたのですが、意外にも1週間に1-2時間ミーティングするだけで開発組織は結構変わっていくものなんですよ。

一休も最初のころは2週間に1回くらいしか直接話す場はありませんでしたが、それでもそれなりにいろんな問題が解決していったんです。特別な技術や開発の進め方を伝えていたわけではなく、相談相手になっていたという感じでしたね。当時顧問を務めていた会社はどこも同じかたちです。

――実際に伊藤さんが手を動かされていたわけではないんですね。

ミーティングで現場の人たちが僕に対して状況を説明していくうちに、自分たちの抱えている問題を理解していくようになるんですよね。

僕は問題を解決するのではなく、問題を理解することの手伝いをしていたという感覚です。解決しなければならない問題を明らかにして、まずは簡単な問題から着手していきます。

一休ではGitHubやチャットツールの導入からはじめて、デプロイの自動化などにも取り組んでいきました。硬直化した状況が少しずつほぐれていくのを実感できました。

――技術顧問として苦労されたことはありましたか。

あえて挙げるなら、変えていきたいメンバーと、まだそういう気持ちになっていないメンバーとの温度差でしょうか。

外部の人間をすぐには信用できない人も、当たり前なんですがいるんですよね。それは、どこの会社に行っても同じです。そういう状況で人を動かすのはマイナスからのスタートなので、結構大変です。

しかも、多くの場合「問題が解決されはじめたな」と実感できるのは、改善をはじめて半年くらい経過してからになるんです。この期間は、「これ意味あるのかな」という声が挙がることもあるんですが、そこは歯を食いしばって乗り越えなきゃいけない。

例えば、一休では、コミュニケーションツールを導入したものの、当初は何を共有すべきかがわからなくて、推進メンバーの一人が「日報を送ってみるのもいいんじゃないですか」と案を出そうとしたところが、つい「日報を送ってください」と命令調で告知してしまったんです。そしたら、みんながただ日報を送るだけのツールになってしまったということがありました(笑)。

また、デプロイを自動化してみたはいいけれど、自動化のプログラムにバグがあって、リリースできなくなるという不幸もありましたね(笑)。

何かを大きく変えようとすると、不慣れが原因で噛み合わないフェーズがどうしても出てきます。

――そういう「つらい状況」はなんとかなっていくものなのですか?

なりますね!

続けているとノウハウが溜まっていきますし、改善が習慣化してくれば、それまで遠慮してしまって言えなかったことが議論できるようになってきます。

本音で要望を出せるようになれば、意思決定が正しく行えるようになります。「こういうことをやってみようよ」とか「ここは自動化したほうがいいよ」とか。そうすると、だんだんとチームが強くなっていくんです。

自分たちのやり方が改善されて、チームが強くなっていっている実感をひとりひとりが感じられるようになると、雰囲気も一転して良くなります。