大学院卒業後、新卒でニフティ株式会社に入社。ブログサービス「ココログ」を立ち上げる。2004年、株式会社はてなに入社。CTO就任し、「はてなブックマーク」などの開発を主導。2010年、グリー株式会社ではソーシャルメディア統括部長として組織拡大へ貢献。2016年4月、株式会社一休に入社。執行役員CTOに就任。
株式会社一休について
当社は、「こころに贅沢させよう」をコンセプトに、ラグジュアリーホテル、高級旅館の予約サイト『一休.com』や厳選されたレストランの予約サービス『一休レストラン』を運営するほか、ギフトチケットの販売サービスなどを展開しています。
2000年より開始した同サービスは、2021年10月時点の会員数が1,300万人を突破するまでに成長。こころに贅沢な時間を世に増やすことを目指してます。
幼少期、ゲーム目当てに始めたプログラミング。大学生になると、職業としてその道を志すようになった。
幼少期、電気メーカーに勤めていた父が8ビットのパソコンを買ってきたことがきっかけです。まだ世の中にコンピュータが普及していない時代でしたので、当時の家庭では珍しかったかと思います。
また、最初にプログラミングを書いたのもその時期でした。当時はまだファミコンを買ってもらえていなかったので、ゲームをしたい一心で、パソコンで自らプログラムを書き写してゲームを動かして遊んでいました。
当時は、本屋さんに、ゲームを動かすためのソースコードが掲載されている雑誌が売っていて、その本のソースコードを写していくだけでしたので、特別、難しいものではありませんでした。もちろん、プログラミングの意味は、理解していませんでしたよ(笑)
大学1年生の頃です。自分用に発売されたばかりの Windows 95 のパソコンを買って、インターネットをしたり、趣味でプログラムを書くようになり、漠然とプログラマーになりたいと思うようになりました。
大学院の専攻は物理学でしたが、少しでも計算機に関わることができる研究室を選び、ネットワークや UNIX に触れる機会を作り、卒業後は、インターネット関連の仕事に携わることができるニフティ株式会社へ入社しました。
ニフティ→はてな→グリー。急成長の波に乗り、駆け抜けた会社員時代。休息もつかの間、複数の企業の技術顧問を請け負う中で、一休と出会った。
最初は、ホームページサービスのインフラの担当からスタートし、徐々にプログラミングの仕事をするようになっていきました。
ある時、部長に「米国でブログというものが話題になってるらしいけど、知ってる？」と聞かれて、「知ってますよ。最近聞くようになってきましたよね」と雑談をしていたら、なかなか勢いのある部長さんで、あれよあれよと会社でブログサービスを立ち上げることになりまして。その開発に携わるようになりました。
サービスを運営していく中で、他社のブログサービス関係の方との知り合いが増え、「はてなダイアリー」というサービスを運営していた株式会社はてなに誘われ入社しました。
当時は、社長と自分含めてソフトウェエアエンジニアは4名程度の組織で、僕は、取締役CTOを務めていました。6年間在籍した中で、会社も順調に成長し、組織は50名程度の規模、開発メンバーも自走していけるようになっていました。対する自分は、自身にすこし行き詰まりを感じるようになっていました。「今の自分には、これ以上この会社の成長に対してできることがない」と感じるようになり、思い切ってグリー株式会社へ転職しました。
在籍期間は2年ほどでしたが、その間で会社の規模は200人弱から2000人まで拡大しましたので、猛スピードで駆け抜けた2年でした。採用活動に関わる時間がとても多かったと記憶しています。
「フリーランスになろう」と思ってなったわけではありませんでした。それまで全力疾走していたので、少し充電をしようと思い、仕事を辞めました。
すると、知り合いから「暇ならうちの仕事手伝って！」と誘われるようになり、渋っていたら、「週1回でよいから」と提案されて。いつの間にか色々な会社の技術顧問を請け負うことになった、というのが技術顧問を始めた経緯です。
一休も技術顧問をしていた会社の1つで、最初のきっかけは、一休で働いているエンジニアの1人が僕にアドバイザーを依頼してきたことでした。
技術顧問を始めて3年。自らのアドバイスの解像度の低下に危機感を覚え始めた時期、一休社長の言葉に背中を押され、入社を決意
３年程、技術顧問として、自分の経験してきたことを糧に様々な企業にアドバイスをしていました。
しかしながら、技術顧問は、これまでの経験･･･貯金を使う仕事だなと感じていました。自分自身では業務システムを開発しない日々が続いていたので、だんだんいろいろなことに対する理解の解像度が落ちてきて、的確な技術的なアドバイスができなくなっているな、という実感がありました。だからこそ、「そろそろ現場の仕事をしなければいけない」という思いがありました。
ただ、心のどこかで「でも、ここからまたある程度の企業に入ったら、マネジメント仕事で溺れてしまいそうだ」という気持ちもあったので、なかなか就職する企業を決められずにいたんです。
そんな時、榊さん（一休の社長）と２人で飲みに行くことになりました。一休で働かないか、と言う榊さんに対して、色々と入社を決められない理由を並べていたら、榊さんに「なんだか小さいことで悩んでるね」と言われてしまいました。
そのあとすぐ榊さんはトイレに行くと言って席を外したので、僕は、お店で一人になりました。一人で座って考えているうちに「確かに何で僕は、こんな小さな事で悩んでいるんだろう？」と気づきました。
そこからはほとんど勢いでした。席に戻った榊さんに「わかりました。、一休に入ります」とその場で、一休へ入社する意思を伝えました。
技術顧問をしていた時、散々周りのエンジニアに「僕は一休には入らない」と言っていましたから、次の日社長が、社員の皆に、僕が入社することになったという話をしても、信じてくれなかったと言っていました(笑)
一休へCTOとして入社するも、現場の真ん中に飛び込めずに2年が経過。社長が放った一言が契機となり、ようやく事業と向き合えるようになった
最初から、執行役員CTOという立場で入社しました。ちょうど、会社がヤフーグループ（現・Zホールディングス）に変わり、役員が入れ替わったタイミングで僕も加わりました。
入社する前の2年間、技術顧問として働いていましたが、入社後は予想通りではあったんですが、戸惑うことも多かったです。それが予想できていたから、入社に躊躇していたんですけど。
例えばなんですが、普通はソフトウェアエンジニアとして転職するとオンボーディングの一環として、開発環境の整備や開発フローへの入り方、現行システムの構造なんかについて周りの方々が教えてくれると思いますが、CTOという役職者の立場で入ると一切そのようなことがないんですよね。極端な話、プリンターに紙を印刷する方法も分からないし、目の前でシステム障害が起こったりしても何のことだかさっぱり分からなくて。「CTOだからそんな丁寧な手ほどきは必要ないだろう」みたいな雰囲気だけはあってですね。 役職付きで中途で入ったときのあるあるなんですが、これが実は結構しんどいんです。開発環境やプリンタの話なんかは些細なことなんですが、中枢のシステム開発になかなか着手できないというジレンマを抱えることになります。そうこうしているうちにマネジメント仕事で忙しくなっちゃって、益々悪循環に陥ってしまいました。
最初の頃は、技術基盤やエンジニアのマネジメント業務に特化していましたが、今考えるとこれはベストな選択ではありませんでした。プロダクトのことをやりたいと思っても業務仕様も分からないし、テクノロジースタックも当時は僕が得意とするスキルと合っていないからなかなか思うようにいかない――。つまりは、ソフトウェアエンジニアとしては会社に貢献できていない状況でした。
だから、業務知識がなくてもできる技術基盤の整備やエンジニアの組織マネジメント業務に携わっていました。今思うと、現場に飛び込むことができず、逃げていたな、と感じます。
きっかけは、約2年後の合宿の時、榊さんに「なおやさん（伊藤さん）は業績に貢献していないよね」と言われたことです。事実だったので当時は「言われちゃった・・・」という気持ちでしたね。
榊さんが言う「業績に貢献していない」というのは、何もしていないという意味ではなくて、あくまで「事業への直接的な改善」に貢献していないという意味です。いちソフトウェアエンジニアならともかく、役員なんだから限定された技術領域に留まっていないで事業に貢献して欲しいということですよね。
当時、インフラのクラウド移行やレガシーシステムを作り直すといった開発業務を中心に、会社の大きな課題である技術的負債の返却の道筋を見つけるなど、技術的な改善は、おこなっていました。一方で、事業のことは相変わらず分からないという状態のまま。僕自身、「いつまでもこのままでよいのだろうか」と思っていた矢先に言われた一言だったので、とても重たい一言でした。
分からないというのは、シンプルにやっていないからですよね。だから、「どのプロジェクトに取り組めば、事業そのものに携わることに繋がるだろう」と考え、ちょうど「一休レストランの基幹システムがいまいちだから改善したい」というプロジェクトの話が上がってたので、「これをやってみようか」と思い、率先して取り組むことにしました。さすがにこの頃には、周辺システムのことは分かっていたし、テクノロジースタックも刷新してきていたので、業務に飛び込める状態になっていたのもあります。
そこで初めて、レストラン予約や宿泊予約という事業と向き合うことになりました。
一休の開発組織は「鎖国状態」。閉ざされた組織をユーザーファーストな組織へ変えるのは容易じゃなかった
もともとエンジニア組織は、他部署からみたら「鎖国状態」「受発注の関係」という印象を持たれていたようです。ひどい話ですよね(笑) とはいえ、そういう印象を持たれていたこと自体は事実のようなので、きちんと受け止めるべきだと思いました。
状況の改善には一人一人にオーナーシップを感じてもらう必要があると思いました。
オーナーシップは「みんな経営者目線を持とう！ユーザーファーストが大切だ！」と言いきかせて高まるような単純なものではありません。ものごとを自分たちで決め、自分たちのやり方で開発をして、自分たちでリリースするという経験を何度も繰り返すことで、徐々に芽生えてくるものです。
そのため、まずは、オーナーシップの意識が芽生えやすくなるように横串の職能別組織からビジネスドメインごとに独立した組織体制へ変えました。
職能別組織の場合は、組織のミッションが「開発」みたいに広くなりがちで、結果交通整理のためにマネージャーがタスクを振る構造になりやすいと思います。基本的には上から振ってきたものをこなしていく形になり、一人一人がオーナーシップを持ちにくくなります。
そうではなく、あなたのチームは宿泊事業のUIの改善、あなたのチームはインフラの改善、あなたのチームは、ホテル施設側の改善というようにミッションごとにチームを分けていきました。そのミッションの中には、エンジニアだけでなく、デザイナーやマーケの人がいて、他職種の人と一緒に働く中でエンジニアとしてのバリューを出してもらうことにしました。
これらを繰り返していくことで、徐々に一人一人にオーナーシップの意識が芽生えていきました。
はい。しかし、これまで自分で決めてこなかったチームが自分たちで決められる状態にならなければいけないわけですから、組織以外にも細部の調整は必要でした。
例えば、システムの作り直しです。ソフトウェアエンジニアリングにおいては、自分が作ったシステムでないと、なかなかそれを自分ごととして捉えることが難しいんですよね。結果オーナーシップを持たせることを目的に、システムの作り直しをおこなうこともありました。「ここの作り直しはあなたがやったから、あなたが面倒見てくださいね」と。色々なシステムを作り直して、その度に一人一人にオーナーシップが生まれて、決めることができるようになっていきました。
1つのチームを長く存続させることも意識していました。プロジェクトが終わったらすぐチームを解散するというのを頻繁にやっていると、その人は、短期で違う仕事を行うことになり、1つの領域にオーナーシップを持ちにくくなります。だから、なるべく1つのチームに長く在籍できるよう配置していきました。
『チームトポロジー』という本がありますが、今思うと、その本に書かれたことを実践していたな、と感じます。本の中には、「ビジネスを技術的に支援する独立したチーム」がプロジェクトチームと別にあり、そのチームが各プロジェクトチームとうまく組み合わさった時に、パフォーマンスが最大化すると書かれています。
私たちも偶然それと同じ構造になっていて、CTO室が、「ビジネスを技術的に支援する独立したチーム」にあたり、社内のエンジニア（各プロジェクトチーム）がCTO室からみたユーザーという構図です。社内のエンジニアが開発しやすいように、困っている時に助けるような役割を担っています。
例えば、CTO室は、技術的に秀でている人が多いので、各部署から相談がきて、自然と技術選定を行う機会が多いです。また、技術基盤を入れ替えるときなどは、ビジネスと時間軸が違いますので、ここもCTO室が担うことが多いですね。どうしてもプロジェクトチーム内で動いていると、早い時間軸の方に引っ張られてしまい、中長期的な足まわりの改善に時間を割くことができない、という状況が生まれてしまうので、広い視野を持って状況を俯瞰する意味でも大きな役割を果たしています。
なお CTO室以外にも、複雑なシステムコンポーネントの開発を担うチームとしてデータサイエンス部があります。こちらは社長の榊がリードしています。
基本、プロジェクトの方針はそれぞれのチームが自分たちで決めているのですが、不思議と、皆、口を揃えて、「伊藤さん、うちの会社はトップダウンですよね。でも別にそれが悪いとは言ってないですよ」と言うんですよね。
そう感じる理由の1つは、経営陣が各事業、何にフォーカスするかを定めているからだと思います。
例えば、「これから半年、Go To トラベルがあります。これは10年に1回のチャンスだからこの時期はホテルのユーザー向けの機能の開発が優先度が高いよね」と、経営陣から、一段掘り下げた内容が共有されます。このように目指すべき方向性や大きなゴールは経営陣が引いているからこそ、トップダウンという印象を持つのかと思います。方向性やゴールにお互い合意できた以降は、自分たちでやり方含めて決めて進めてくださいね、という方針です。いくらオーナーシップが大事といっても個々人が好き勝手なことをやっても事業としてはうまくいかないので、それは大事なことだと思います。
EMへマネジメント権限を譲渡し、CTO自らは開発の時間を取る。組織の未来のためには必要な選択だった。
今年の春先までは、僕がマネジメント業務に従事していました。しかし、開発組織も大きくなってきているし、そろそろCTOを中心としたトップダウン組織は少しきついなと思って、今年の9月頃から明確にエンジニアリングマネージャー（以下、EM）に僕の代わってマネジメントの役割を担ってもらうことにしました。
EMの4人には、「事業部ごとに、全てのマネジメントを巻き取って欲しい」という風に伝えていまして、一方の僕はというと、空いた時間を開発に費やしています。ここ3か月位、これまでの人生で一番プログラミングを書いているんじゃないでしょうか。
僕はもうすぐ45歳になります。今後、このままマネジメント権限を握り続けたまま、 50歳になったときのことを想像すると、なんだか初老の強い権力者がトップに君臨している組織になっちゃうなと思って、自分のイメージする活発な開発組織と合わないな、と感じたんですよね。そもそも自分自身、強い権限が欲しいと思っているタイプの人間でもないですし。
やっぱり若い人が会社の運営を行って新しいやり方や技術を継続的に取り込んで新陳代謝をしていくのがいいなあ、と。かつては自分がそういうのを先導してきていたわけですが、そろそろ世代交代だと思いました。その傍らで、僕らのような年長者も一緒に新しい技術をキャッチアップしていくという組織が、全体として良い組織ではないかと思っています。
自分が若かった頃、会社の上長が開発のことを分からないという状況が少し窮屈だったんですよね。
ソフトウェアエンジニアとして働くなら、そうじゃない会社がいいなとシンプルに思っていたので、それが1つの理由です。
もう１つは、トップマネジメントとして技術的に正しい意思決定をしようとすると、その時代の技術をある程度解像度高く理解していかなければいけません。それができないと、結局自分ではない後輩へ技術的な部分も含めて任せなければいけなくなる。権限をもった人は技術的なジャッジができず、技術的なことがわかっている人は組織を動かす力を持っていない。これだと組織として膠着して不健全な状態に陥ってしまうと思います。
選考は、【カジュアル面談→1次面接→最終面接】というエンジニアだけで完結するフローになっていて、基本、僕は最終面接だけ対応しています。
また、EMにマネジメントをお願いしてからは、面接に対応するEMに採用に関する意思決定も行ってもらっていて「皆さんが採用したいと思った人は基本採用するよ」と伝えています。ここで僕がああでもないこうでもないと口を出してしまうと「やっぱり、伊藤さんに聞かなきゃ」という風になってしまうと思うので、僕はプロセスには口を出さないようにしていて、採用基準についてもEMの皆に決めてもらっています。
もちろん、悩んでいる時には僕が判断するなどサポートはしていますけどね。
見ていると、「一休らしい人」という価値観に照らし合わせている感じがします。サービスが面白そうだから、ユーザーに役に立つサービスを作りたいからなど、自分のことを最優先にしないで、ベクトルが外に向いている人が多いですね。
緩い連帯で組織が繋がっているのが当社の特徴かもしれません。
個々人で特に秩序もなくコミュニケーションを取っていると、話に行き違いが生まれたりして組織が混乱しますよね。一方、マネージャーが中心となって、コミュニケーションを集約していると、情報量や熱量に差ができてしまって、その他の人たちのオーナーシップが失われます。広すぎても狭すぎてもだめなんです。だから当社の場合は、そのちょうどその真ん中位のコミュニケーションに収まっています。
例えば「クーポンはあの人が担当」ときっちり決まっているわけではなく、「クーポンはあの人が知っているよ、あの人に相談すればいいよね。」というように、プロダクトごとに、なんとなくで担当がいるという感じです。
当社が取り扱っている飲食（レストラン）業界は、宿泊業界に比べてデジタル化がまだまだ進んでいません。今の時代、ホテルを取るのに電話で予約する方はほとんどいらっしゃらないと思いますが、レストランはいまだに電話で予約することが多いですよね。
その背景には、お店のオペレーションのペーパーレス化が進んでいないという現状があります。そこを一気通貫でデジタル化していかないと、全てインターネットで完結するような世界はやってきません。
この「飲食業界のインターネットへのシフト」という大きな課題に対して、僕自身が開発者としてその中心となり取り組んでいきたいと強く思っています。
そして、いつかそれを成し遂げた日には、皆さんに「このシステム作ったのは僕なんです！」って自慢したいですね。やっぱり、自分の作ったシステムで世の中が動いているというのはソフトウェアエンジニアとしての醍醐味ですからね(笑)
▶ 参考：IT未経験者におすすめの転職エージェント13選｜転職成功のコツも解説【エンジニア転職術】
