リモートでむしろ生産性が上がったエンジニア組織の作り方を一休 CTOの伊藤さんに聞いてみた
宿泊予約事業やレストラン予約事業などを手掛ける、株式会社一休。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Teams」を活用いただいています。
今回は、執行役員CTOを務める伊藤直也さんにインタビュー。実際に「Findy Teams」上でのデータを参照しながら、エンジニア組織における生産性についての考え方などを伺っていきます。
■プロフィール
伊藤 直也
株式会社 一休 執行役員 CTO
青山学院大学大学院博士課程前期修了後、新卒でニフティ株式会社に入社し、ブログサービス「ココログ」を開発。その後、株式会社はてなの取締役CTOに就き、はてなブックマークの開発などを主導した。フリーランスでの活動などを経て、2016年4月、一休の執行役員CTOに就任。
コロナ禍における開発を、Findy Teamsで振り返る
──こちらが御社の2020年1月から直近までのデータになります。プルリク作成数はだいたい平均値を超えていて、件数としては2020年7月と2020年10月に大きな山があります。今年は5月頃から全体的に伸びている傾向にありますが、これらの要因として考えられる部分はありますか？
伊藤：2つ山ができている理由は明確で、2020年7月はGo To トラベルが始まるタイミング、2020年10月は東京のGo To トラベル始まるタイミングです。その2つの時期は、大変だったんですよ（笑）。とにかく世の中の状況も、仕様も毎日変わるような状況で。
もう1つ、今年のここ半年くらいが高かったのは、Yahoo!トラベルのシステム統合プロジェクトがあったからですね。こちらは大変というよりは、半年間くらいかけて良い調子にパフォームして、スケジュール通り終わりました。
──なるほど、そういった状況から高い数値が出ていたのですね。
伊藤：これを生産性と見るかどうかは議論の余地があると思いますが、仮にプルリク数が多いことが生産性が高いことだとするじゃないですか。そうした時に、生産性を上げるために開発のプロセス改善をする方向性もあると思いますが、弊社の場合は「大義名分のある重要なプロジェクトが走っているか」が大きく影響すると考えているんです。
例えば、Yahoo!トラベルのように半年かけて50人で取り組む大きなプロジェクトで、上流を整理してきちんとロードマップを引いて、チームや個々人の役割が明確になった状態でスタートすると、50人が一気に動くので、当然ながら高い生産性が出るんですよ。逆に、そういう大きなプロジェクトで上流が整理されていなければ、混乱して生産性は下がります。
Go To トラベルのような場合も、大変ではあるけれどやることに大きな意味があって皆が全力疾走しているから生産性が高くなる。でも、ビジネスインパクトが大きくなかったら、皆そんなに走れないですよね。なので、重要なプロジェクトがきちんと整理されて進んでいて、かつインパクトが大きいことが大事。どちらかだけではダメで、その2つが噛み合っている時に生産性が高くなるんです。
一方で、プロジェクトが忙しくてあまり先のことが考えれない時期があると、そのプロジェクトが終わった後にガクッとパフォーマンスが下がる。結局やることがはっきりしていて、目標がきちんと決まっていれば走れるけど、「何やっててもいいよ」と言われると、少しパフォーマンスが下がる感じですね。
──データを見ると、2021年1月～3月頃は少し落ちついているように見えますね。
伊藤：そこはまさに、Go To トラベルが大変だったので、その後の一息ついたタイミングです。Go To トラベルが停止して、運用モードに入っていたので、その間に次に備えて直すべきところを直しておこうという時期でした。ユーザーに新しい価値を提供できていた感覚は、確かにその時期はあまりなかったです。
──プルリク数に関するところでは全体的に、頑張り時に踏ん張れる方が多そうだなと、データを見ても感じました。
伊藤：別に皆すごく残業しているとか、そういうことではないですからね。リモートワークに移行した時に、生産性が下がるとか上がるとか、そういう議論は社内でもあったのですが、結局あまりそこは要因ではなかったなと。
プロジェクトがきちんと定義できていて、皆に仕事が上手くアサインされていれば、オフィスでも家でも、ちゃんとアウトプットが出るということは、この数字を見てもよくわかりました。
リードタイムの大幅な短縮、その背景にあったのは？
──続いて、時間についても触れていきたいと思います。データを見ると、2020年3月あたりでプルリクのリードタイムが長くなっている印象です。コロナの影響でリモートワークへの移行が必要だったタイミングかと思いますが、いかがでしょうか？
伊藤：あまり意識していなかったので、今聞いて初めて「そうなんだ」と思いました。ここは原因がよくわからないですね。リモートワークに移行したばかりで、コミュニケーションの取り方に慣れていなかったとかでしょうか。プルリク数にしか着目していなくて、クローズまでの時間はあまり気にしていなかったです。
──一方で、2021年はリードタイムがかなり短くなり、プルリク1つあたりに対しての時間が半分以下になってきています。
伊藤：Yahoo!トラベルとのシステム統合をするタイミングで、レガシーなところを作り直したんですよ。「一休.com」の一部に少し古いアーキテクチャが残っていて、サーバーサイドが.NETだったんですね。
弊社の一番新しいアーキテクチャは、フロントがNuxtでサーバーサイドがGoなので、それに全部移し替えたんです。当然レビューの時間も早くなるし、開発に時間をかけなくてもよくなる。推測ではありますが、それが効いているような気がしますね。
──技術選定によってパフォーマンスが良くなった可能性があるということですね。
伊藤：実際に入れ替えてから、フロントエンドをやっているチームの開発スピードは明らかに上がっています。そのチームのあるメンバーのグラフを見てみると、システムが新しくなると同時にその人の数字が上がっていて、皆が「上がってる！」と面白がっていたので（笑）。それが全部ではないと思うのですが、多少はあると思います。
他社との比較で顕著に現れる、開発スピードの早さ
──弊社でいろいろな会社のリードタイムを見させていただいていますが、他社のデータのと比べて、御社はかなり開発スピードが早いという特徴があります。
伊藤：それは言われるまで、まったく気付いていなかったです。こう見るとすばらしいですね。自分たちの生産性が高いのか低いのかは、よくわかっていませんでした。極端に悪いとは思ってなかったですし、昔よりは良くなっているだろうという感覚は、なんとなくありましたけど。
──開発リードタイムを短くするために、意識されていたことはありますか？
伊藤：それが実はあまりないんですよ。7～8年前、一休は開発が、あまりうまくやれていない時期があってですね。それで僕がこの会社に呼ばれることになったのですが。、当時はもうGitHubでの開発が普及し始める頃合いだったんですけど、一休はまだSubversionで開発していて、デプロイも自動化されていなかったし、テストも手でやっていました。だから、週1回しかデプロイできないみたいな、そういう時代があったんです。
それでここから変えていかなきゃいけないね、というので当時まず、GitHubを入れるところから始めて、コードレビューしましょうと。その時に、例えばプルリクは大きすぎると読む側がつらいとか、そういう話はしていました。でも、あれから7～8年経って、そういうことをずっと言い続けているわけではなくて。だから、どういうプルリクが良いかとか、そういう議論も今はそんなにしていないですね。習慣化されて、自然に行われていると思います。
あと、組織の在り方として、うちは横串の開発チームがないんですよ。事業部に紐づいていて、ユニットごとにいろいろな機能がまとまっている。その中でのやり方は、自由になっているんですよね。プログラミング言語やGitHubなど、揃えるべきところは揃えていますが、基本的な開発の進め方はそれぞれに完全に任せてあります。
なので、開発組織横断でプロセスやルールを作って何か取り組もうとするのは、案外やりづらい。そういう背景もあって、あまりこれといった取り組みはしていませんが、上手くまわっているという感じです。
──リプレイスが必要になった時は、現場のメンバーが行うのか、それとも特定のチームが行うのか、どういった進め方をされているのでしょうか？
伊藤：この体制は、事業にコミットするという意味ではすごく強いんです。小さなチームで自分たちだけで意思決定してリリースできるから、良かったかどうかのフィードバックも直接手に入る。その領域は自分たちがやったんだというオーナーシップがあって、責任感が強くなります。
その反面、やはり何かを統一してやる必要が出てきて、お互いチームのことを気にしなきゃいけなくなった瞬間に、少しオーバーヘッドがあるんですよね。普段あまりコラボレーションしていないチーム同士だと特に。だから、そこはある程度トップダウンでやります。
僕のチームとしてCTO室というのがあって、技術的なアーキテクチャを入れ替える時は、そこである程度決めています。アプリケーション開発チームのベースを見て･･･例えばReactが良いかNuxtが良いかを決めて、CTO室で基盤を作る。それが出来てきたら、各チームにCTO室の人が入って広めていくという感じでアプローチとしてはトップダウンに近いです。
──なるほど。そこが伊藤さん及びCTO室の仕事として、今年にかけてやってこられたことの1つであると。
伊藤：そうですね。なので、ユーザーへの機能提供とか、そういう日々の開発は各チームで進めてもらって、横串で統一しなければいけないことは、CTO室が旗を振って進めています。
僕たちの仕事は、”生産性を上げること”ではない
──生産性の高い組織であり続けるために、今後取り組んでいきたいと考えていらっしゃることはありますか？
伊藤：生産性を上げるというよりは事業やサービスが一番だと考えています。事業やサービスとして取り組むことに皆がきちんと納得していて、「これは大事だ」と思っている状態が作れるかどうか。それがモチベーションや開発スピードに繋がると思っているんです。
そもそも自分のやっていることが、社会にとってどんな意味を持つのか、そこに納得できているかどうかが圧倒的に大きい。どんなにプロセスが美しくても、社会に良い影響があるとは思えないことを、進んでやれる人って多くないですよね。
なので、生産性を上げるためのプロジェクトとか、新しい手法の導入とか、そういうことを常時やっていたりはしません。だけど、もしサービスやプロダクトを作っていくために、必要なのであればやりましょうと。その順番を間違えてはいけないという話はずっとしています。
よくある手段の目的化みたいな話ですが、生産性を上げることが僕たちの仕事なのではなくて、ユーザーに価値を提供したり、事業を伸ばしたりするのが僕たちの仕事。そのために必要なのであれば、やるべきだという話をしていますね。バランスが重要だと思います。
──これからFindy Teamsを使っていただく方にも、単に生産性だけを見るのではなく、最終的にはより良いプロダクトをより早く作るために活かしてほしいと、僕らも強く思っています。
伊藤：先ほどお話ししたGo To トラベルの時に、すごく象徴的な出来事があったんですよ。あるチームのパフォーマンスが、リーダーの退職があったりしてあまり良くなかったんですね。それを本人たちも自覚していて、チーム内で1on1やKPTをやってみたり、スクラムを取り入れてみたりと、いろいろ試してみたものの、大きな改善には至らなかった。
でも、そうしているうちにGo To トラベルが始まってしまって、否が応でもやらなければならない状態になったわけです。その時点の自分たちのキャパシティを超えるレベルのプロジェクトだったから、なりふり構っていられないし、皆で歯を食いしばって取り組むような状況になっちゃったんですね。
当時、チームの皆が「この人がリーダーをやればいいのに」と思っていた人がいたのですが、本人はそれまで遠慮していたんです。でも、誰かが切り盛りしないといけない状況になって、その人が「やります」と言ってリーダーシップを取り始めた。そのチームが変わり始めたのは、そこからですね。
やっていくうちにそのチームはどんどん成長して、チームとしての活動が目に見えて改善されていきました。つまり、チームビルディングをしたことによってビルドされたのではなく、チームとして取り組まなければならない問題に直面したからビルドされた。これは「そりゃそうだよね」と、その時に思ったんです。
本人たちは決してチームビルディングを目的にしていたつもりはなく、上手くまわっていないからプロセスをどうにかしようといろいろ試していたんだけど、問題はそこではなかったと。結果として、そのチームは今もずっと生産性が高くて、本当に活躍してくれています。あの時は大変だったけど、皆「あれで一皮剥けました」と言っていますね。
──すごく素敵なエピソードをありがとうございます。伊藤さん、本日はありがとうございました！