## 2人のこれまでの経歴と主な業務内容
__──最初に、お二方のこれまでの簡単なご経歴と、現在の主な業務内容を教えてください。__

田中：大学在学中に起業した会社に5年勤めた後に、ワンキャリアに入社しています。起業した会社では、P2Pの技術を応用してWebコンテンツの発信を最適化するソリューションを作っていました。コアの技術を開発して3年で買収された後は、アドウェイズのグループ傘下で、いろいろなチームと共同でサービス開発をしていました。

その後、ワンキャリアに1人目の正社員エンジニアとして入社し、現在4年目になります。仕事内容として、これまで一貫して行ってきたのは、開発を内製化するための体制づくり。エンジニア組織の設計や採用はもちろんのこと、フリーランスのエンジニアと一緒に開発を進めるためSESの商談に出たりしながら、社内のリソースを調達してきました。

最近はコードを書くエンジニアが増えてきたので、自分でコードを書くというよりも、プルリクエストのレビューや、開発計画を立てて予算を策定するなど、経営寄りの仕事の比重が大きくなってきています。

宇田川：私は大学で土木を専攻していて、新卒で県庁に入り、土木系の公務員職に就きました。その後、エンジニアになるべくスクールに通い、2020年9月にワンキャリアにジョインしました。入社して1年半になります。

業務に関しては大きく2つで、1つ目は開発業務。バックエンドを中心に、フロントエンドの繋ぎ込みなどをしています。プロジェクトとしては、社内システムのリプレイスにも携わっています。

2つ目が組織づくりで、エンジニアの生産性向上に関するところを、私がリーダーとして進めています。例えば、エンジニアの生産性について定義した上で、それをエンジニアの評価制度に組み込むといった取り組みをさせていただきました。

## エンジニアが増え、体制が変化した2021年を振り返る
__──まずは2021年の振り返りについてお聞きしたいと思います。チームで変化があった部分など、いかがでしょうか？__

田中：いろいろありますが、1つは正社員エンジニアの数が増えたことが大きかったと思います。人数が増えたことで、今までは後回しになっていた評価やパフォーマンスのチェックを、しっかりと体制を整えてやっていく必要が出てきました。

__──具体的な人数としては、どれぐらいの変化がありましたか？__

田中：2021年1月時点では自分を含めてエンジニアは4人でしたが、2022年1月時点では7人になっています。自分含めて4人の時は、マネジメントの対象が3人なので何かあってもサポートできていました。ところが、対象が6人になってくると、自分の業務もある中では、サポートしきれない部分が出てきたという感じですね。

__──宇田川さんはいかがでしょうか？__

宇田川：2021年はエンジニアの人数もチーム数も増えたので、チーム運用のルールが整ってきたと思います。ドキュメントの残し方やレビュー方法などがルール化されて、田中さんがマイクロマネジメントをしなくても、各チームで運用できる状態になってきました。

__──それでは、実際にFindy Teamsのデータで変化を見ていければと思います。棒グラフがプルリク作成数、折れ線グラフがリードタイムを示しています。2月のリードタイムが大きく伸びていますが、これはどういった理由が考えられますか？__

<figure>
<img src="//images.ctfassets.net/ngrpflsbp3rq/2y7j6JcP0tT9wBg1OHVhPi/86b1e0eae69debf118becbf709061de2/____________________________2022-04-12_19.12.34.png"/>
<figcaption>【組織全体のFindy Teamsチームサマリーデータ（2021年1月～12月）】</figcaption>
<figcaption>※棒グラフはアクティビティ量を示しているため高いほど良く、折れ線グラフはリードタイムを示しているため低いほど良い</figcaption>

田中：開発プロジェクトが増えてきたり、進捗が伸びてきたりして、エンジニアリングマネージャーが見切れなくなっていた部分が多少あったかなと。結構細かくプルリクのレビューをしていたのですが、プルリク作成数にレビュアーが追いつかないということが起きていたように思います。

あとは、社内システムのリプレイスですね。既存のシステムへの影響が大きなものだったので、ある日に一気に切り替えるような、リリーススケジュールのコントロールが必要でした。それに向けて、プルリクエストが溜まっていた時期だったので、そういった要因が重なってリードタイムが長くなっていたと思います。

__──6月末から7月にかけては、リードタイムを抑えながらも、プルリク作成数が最大化されています。この理由として思い当たることはありますか？__

田中：中途向けサービス「ONE CAREER PLUS」の、β版リリース直前の時期に当たります。リリース前の追い込みで、バグフィックスのプルリクをたくさん作っていくのですが、完全にゼロから作ったプロジェクトだったので、コードレビューはあまり複雑なところがなくスムーズに進みました。つまり、リリース直前の案件によるものです。

__──先ほど触れた2月以降は、リードタイムが200時間を下回る状態がキープできています。リードタイムを少なく安定させられている理由として、考えられることはありますか？__

田中：体制面で言うと、経験のあるエンジニアが途中でジョインしたことによって、レビューの負担が分散しました。加えて、チーム内での相互レビューも活性化したので、それによって効率が上がったのではないかと思っています。

宇田川：相互レビューについては、一部のチームでやっていたものを2021年の後半にはルール化し、複数人で相互レビューすることをマストにしました。それから、プルリクエストを出したらSlackで通知することもルール化して、レビューまでの時間を抑えられるようになったと思います。

## チーム間の比較データから、指標ごとの差をチェック
__──続いて、こちらは御社のデータをチームごとに比較した表になります。各項目ごとに、緑色が濃いほど過大な可能性があることを示しています。こちらからはOCチーム（就活サイトONE CAREERの開発チーム）のリードタイムが短いことが読み取れますが、何か具体的な取り組みはされていますか？__

<figure>
<img src="//images.ctfassets.net/ngrpflsbp3rq/5LwTitLSEl7uvVVOaGrTt7/b4e1922c5888c193822210e597a4d5ff/____________________________________________________.jpg" />
<figcaption>【チーム間の比較データ】</figcaption>
<figcaption>※組織全体を1としたときの比で表現、21年11月のデータを12/29時点で取得して活用</figcaption>

田中：OCチームのリードタイムが短いというのは、あまり実感はなかったですね。もともとOCチームは外注が多かったチームで、直近半年はそこから内製化に振り切ってきたので、それに伴ってプルリクを作る人とレビューする人の連携がよりスムーズになったことが影響しているかなと思います。

宇田川：OCチームは私が属しているチームで、率先してレビューをすぐ見るようにしています。同じチームのエンジニアマネージャーも、すぐにレビューするような取り組みをしているので、それがリードタイムの短さに繋がっていると思います。

__──一方でOCチームのネガティブな部分として、レビューされずにマージされた割合が高くなっています。このあたりについてはいかがでしょうか？__

田中：弊社ではステージング環境で動作確認した後に、本番環境へのマージを行っています。ステージングで確認した後、本番に移すためのプルリクを作るのですが、それはすでにチェックが終わっているので、そのままマージしたりしています。そういった数も含まれていますか？

__──その通りです。なので、その影響から数値が高く出ている可能性がありますね。__

田中：そういった数は他のチームに比べて多いと思うので、そこも影響しているように思います。

__──ちなみに、上記の表で御社内の定例で確認されている指標の中に、プルリクあたりの平均コメント数が入っていましたが、これはどういった理由から見られているのでしょうか？__

宇田川：プルリクあたりの平均コメント数は、チームの中でコミュニケーションコストが上がっていないかどうかを見ています。ただ、そこに対して具体的なアクションが決められているわけではないので、今後検討が必要な部分だと考えています。

## Findy Teamsの導入後、リードタイムへの意識が変化
__──OCチームは宇田川さんが属されているチームということで、さらに深堀りしてお伺いできればと思います。OCチームの2021年のデータを見ると、2月にプルリク作成数が大きく伸びていますが、このあたりに何か変化はありましたか？__

<figure>
<img src="//images.ctfassets.net/ngrpflsbp3rq/3V9oiVm5od6CbuzxOYtAEO/1153d686e3dcda3a954246ce34b48c1a/____________________________2022-04-12_19.44.52.png"/>
<figcaption>【OCチームのFindy Teamsチームサマリーデータ（2021年1月～12月）】</figcaption>
<figcaption>※棒グラフはアクティビティ量を示しているため高いほど良く、折れ線グラフはリードタイムを示しているため低いほど良い</figcaption>

宇田川：先ほどお話ししていた、一気にリリースする必要があったプロジェクトのプルリクがOCチームの中にもあったので、その影響だと思います。

__──11月以降にも、プルリク作成数が2倍近く伸びているように見えます。このあたりで思いあたることはありますか？__

宇田川：リプレイスのプロジェクトを進めていて、そのバグフィックスをしていました。なので、小さめのプルリクがたくさん増えていた期間だと思います。

__──この期間は、リードタイムが最も低い水準にありますが、これについても小さいプルリクが多かったことが理由になりそうでしょうか？__

宇田川：そうですね。バグフィックスのために、すぐにレビューしてステージングで確かめるということを繰り返していました。

__──グラフ全体を見ると、年末にかけてリードタイムがピークの2分の1ほどに短縮されています。宇田川さんの目線で、こうした数値を振り返っていかがでしょうか？__

宇田川：2021年9月頃からFindy Teamsを利用させていただくようになって、それ以降リードタイムに関しては、意識するよう各チームに繰り返し伝えていました。

このチームだけを見ても、上半期と比べるとかなり下がっているので、その成果が出ていると感じます。やはりこうして定量化されると、目に見えて変化がわかりやすいので、周囲の意識も変わったと思います。

## 指標を評価制度にも活用、さらなる改善へ活かす
__──今後も生産性の高い組織であり続けるために、取り組んでいきたいと考えていることはありますか？__

宇田川：すでに取り組み始めているのが、評価制度に関してです。今期から評価において、プルリクをいくつ出しているか、レビューを何回しているかなど、さまざまな指標を見るようにしていて、その時にFindy Teamsを活用させていただいています。

__──目標設定はメンバーごとやチーム全体など、どういった方法で設定をされていますか？__

宇田川：各個人の目標に組み込んでいます。あとは、業務委託の方も多いので、評価には関わらないのですが、チームで目標とする数値を設定したりもしていますね。

__──田中さんからも、目標設定などの部分で考えられていることがあればお願いします。__

田中：Findy Teamsで見ている指標が経営にどうインパクトがあるのかは、これから整理していかなければならないところだと思っています。経営陣にとっても、開発組織の状態やパフォーマンスを見るための良いツールになるように、どういう見方をしていくべきかをちゃんとディスカッションしながら、経営に役立てていきたいと考えています。

__──組織全体として、今後目指していきたいと考えられているチーム像はありますか？__

田中：より速く作って速くデリバリーするという意識は、プロフェッショナルなエンジニアとして持つべきものだと思いますが、全員がそうした意識をしっかりと持って、より速くユーザーに価値を届けられるようなチームを目指していきたいと考えています。

Findy Teamsのように可視化できるツールがあるおかげで、みんながより洗練されたプロフェッショナルになる手助けになっていると感じます。しっかり指標を見ながら日々ディスカッションして、改善し続けていきたいですね。

__──今後、御社ではどういったエンジニアの方に来てほしいと考えているか、期待するエンジニア像があれば教えてください。__

田中：リーダー層とメンバー、それぞれにあります。リーダー層で言うと、こうした事業の状態が評価できるツールを活用しながら、技術開発部全体の業務設計をして、みんなの興味やパフォーマンスの方向性を揃えていけるエンジニアリングマネージャーを求めています。

メンバーで言うと、ダッシュボードで見える指標をどんどん引き上げてくれるような、実装力があるスペシャリスト。もしくは、ディスカッションしながら改善のPDCAを回して、組織全体の生産性を底上げしてくれるようなエンジニアですね。

加えて、どのポジションにも共通して言えることとして、「変化を楽しめる」エンジニアは大歓迎です。事業も組織も、今後引き続き変化していくので、そのときどきの状況に応じて必要なプロダクトや体制を整えていけるような方を探しています。

そういう方に入っていただけると、自走しながら改善していけるチームになると思うので、ぜひ弊社に興味を持っていただけるとありがたいです。

__──田中さん、宇田川さん、本日はありがとうございました！__

※Findy Teamsのサービス詳細は以下よりご覧いただけます。
https://findy-teams.com/service_introduction

ワンキャリア様インタビュー_バナー画像

はじめてのキャリアを選ぶ、就活サイト「ONE CAREER」を運営する株式会社ワンキャリア。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Teams」を活用いただいています。  今回は、CTOを務める田中さんと、エンジニア組織づくりのリーダーを務める宇田川さんにインタビュー。実際に「Findy Teams」上でのデータを参照しながら、エンジニア組織における生産性向上への取り組みなどを伺っていきます。

定量目標を設定してスピード感のあるユーザー価値提供を目指す取り組みについてワンキャリアさんに聞いてみた

## コロナ禍における開発を、Findy Teamsで振り返る

__──こちらが御社の2020年1月から直近までのデータになります。プルリク作成数はだいたい平均値を超えていて、件数としては2020年7月と2020年10月に大きな山があります。今年は5月頃から全体的に伸びている傾向にありますが、これらの要因として考えられる部分はありますか？__

<figure>
<img src="//images.contentful.com/ngrpflsbp3rq/1jX5nYPOqdvJy5Ebz8jZ3q/e150d76d91cd01d53b2931bc391e07be/_______________________________pic___________________.png" />
<figcaption>Findy Teamsのチームコンディション画面</figcaption>
<figcaption>※棒グラフはアクティビティ量を示しているため高いほど良く、折れ線グラフはリードタイムを示しているため低いほど良い</figcaption>

伊藤さん：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月あたりでプルリクのリードタイムが長くなっている印象です。コロナの影響でリモートワークへの移行が必要だったタイミングかと思いますが、いかがでしょうか？__

<figure>
<img src="//images.contentful.com/ngrpflsbp3rq/1jX5nYPOqdvJy5Ebz8jZ3q/e150d76d91cd01d53b2931bc391e07be/_______________________________pic___________________.png" />
<figcaption>Findy Teamsのチームコンディション画面</figcaption>
<figcaption>※棒グラフはアクティビティ量を示しているため高いほど良く、折れ線グラフはリードタイムを示しているため低いほど良い</figcaption>

伊藤さん：あまり意識していなかったので、今聞いて初めて「そうなんだ」と思いました。ここは原因がよくわからないですね。リモートワークに移行したばかりで、コミュニケーションの取り方に慣れていなかったとかでしょうか。プルリク数にしか着目していなくて、クローズまでの時間はあまり気にしていなかったです。

__──一方で、2021年はリードタイムがかなり短くなり、プルリク1つあたりに対しての時間が半分以下になってきています。__

伊藤さん：Yahoo!トラベルとのシステム統合をするタイミングで、レガシーなところを作り直したんですよ。「一休.com」の一部に少し古いアーキテクチャが残っていて、サーバーサイドが.NETだったんですね。

弊社の一番新しいアーキテクチャは、フロントがNuxtでサーバーサイドがGoなので、それに全部移し替えたんです。当然レビューの時間も早くなるし、開発に時間をかけなくてもよくなる。推測ではありますが、それが効いているような気がしますね。

__──技術選定によってパフォーマンスが良くなった可能性があるということですね。__

伊藤さん：実際に入れ替えてから、フロントエンドをやっているチームの開発スピードは明らかに上がっています。そのチームのあるメンバーのグラフを見てみると、システムが新しくなると同時にその人の数字が上がっていて、皆が「上がってる！」と面白がっていたので（笑）。それが全部ではないと思うのですが、多少はあると思います。

## 他社との比較で顕著に現れる、開発スピードの早さ
__──弊社で色々な会社のリードタイムを見させていただいていますが、他社のデータと比べて、御社はかなり開発スピードが早いという特徴があります。__

<figure>
<img src="//images.contentful.com/ngrpflsbp3rq/5L3uELTR8ni5leLtwq6TxX/68d2a8307865b790f6031febc76a1462/____________________________.png" />
<figcaption>Findy Teams導入企業と一休様データの比較</figcaption>
</figure>

伊藤さん：それは言われるまで、まったく気付いていなかったです。こう見るとすばらしいですね。自分たちの生産性が高いのか低いのかは、よくわかっていませんでした。極端に悪いとは思ってなかったですし、昔よりは良くなっているだろうという感覚は、なんとなくありましたけど。

__──開発リードタイムを短くするために、意識されていたことはありますか？__

伊藤さん：それが実はあまりないんですよ。7～8年前、一休は開発が、あまりうまくやれていない時期があってですね。それで僕がこの会社に呼ばれることになったのですが。当時はもうGitHubでの開発が普及し始める頃合いだったんですけど、一休はまだSubversionで開発していて、デプロイも自動化されていなかったし、テストも手でやっていました。だから、週1回しかデプロイできないみたいな、そういう時代があったんです。

それでここから変えていかなきゃいけないね、というので当時まず、GitHubを入れるところから始めて、コードレビューしましょうと。その時に、例えばプルリクは大きすぎると読む側がつらいとか、そういう話はしていました。でも、あれから7～8年経って、そういうことをずっと言い続けているわけではなくて。だから、どういうプルリクが良いかとか、そういう議論も今はそんなにしていないですね。習慣化されて、自然に行われていると思います。

あと、組織の在り方として、うちは横串の開発チームがないんですよ。事業部に紐づいていて、ユニットごとにいろいろな機能がまとまっている。その中でのやり方は、自由になっているんですよね。プログラミング言語やGitHubなど、揃えるべきところは揃えていますが、基本的な開発の進め方はそれぞれに完全に任せてあります。

なので、開発組織横断でプロセスやルールを作って何か取り組もうとするのは、案外やりづらい。そういう背景もあって、あまりこれといった取り組みはしていませんが、上手くまわっているという感じです。

__──リプレイスが必要になった時は、現場のメンバーが行うのか、それとも特定のチームが行うのか、どういった進め方をされているのでしょうか？__

伊藤さん：この体制は、事業にコミットするという意味ではすごく強いんです。小さなチームで自分たちだけで意思決定してリリースできるから、良かったかどうかのフィードバックも直接手に入る。その領域は自分たちがやったんだというオーナーシップがあって、責任感が強くなります。

その反面、やはり何かを統一してやる必要が出てきて、お互いチームのことを気にしなきゃいけなくなった瞬間に、少しオーバーヘッドがあるんですよね。普段あまりコラボレーションしていないチーム同士だと特に。だから、そこはある程度トップダウンでやります。

僕のチームとしてCTO室というのがあって、技術的なアーキテクチャを入れ替える時は、そこである程度決めています。アプリケーション開発チームのベースを見て･･･例えばReactが良いかNuxtが良いかを決めて、CTO室で基盤を作る。それが出来てきたら、各チームにCTO室の人が入って広めていくという感じでアプローチとしてはトップダウンに近いです。

__──なるほど。そこが伊藤さん及びCTO室の仕事として、今年にかけてやってこられたことの1つであると。__

伊藤さん：そうですね。なので、ユーザーへの機能提供とか、そういう日々の開発は各チームで進めてもらって、横串で統一しなければいけないことは、CTO室が旗を振って進めています。

## 僕たちの仕事は、”生産性を上げること”ではない
__──生産性の高い組織であり続けるために、今後取り組んでいきたいと考えていらっしゃることはありますか？__

伊藤さん：生産性を上げるというよりは事業やサービスが一番だと考えています。事業やサービスとして取り組むことに皆がきちんと納得していて、「これは大事だ」と思っている状態が作れるかどうか。それがモチベーションや開発スピードに繋がると思っているんです。

そもそも自分のやっていることが、社会にとってどんな意味を持つのか、そこに納得できているかどうかが圧倒的に大きい。どんなにプロセスが美しくても、社会に良い影響があると思えないことを、進んでやれる人って多くないですよね。

なので、生産性を上げるためのプロジェクトとか、新しい手法の導入とか、そういうことを常時やっていたりはしません。だけど、もしサービスやプロダクトを作っていくために、必要なのであればやりましょうと。その順番を間違えてはいけないという話はずっとしています。

よくある手段の目的化みたいな話ですが、生産性を上げることが僕たちの仕事なのではなくて、ユーザーに価値を提供したり、事業を伸ばしたりするのが僕たちの仕事。そのために必要なのであれば、やるべきだという話をしていますね。バランスが重要だと思います。

__──これから[Findy Teams](https://findy-teams.com/service_introduction)を使っていただく方にも、単に生産性だけを見るのではなく、最終的にはより良いプロダクトをより早く作るために活かしてほしいと、僕らも強く思っています。__

伊藤さん：先ほどお話ししたGo To トラベルの時に、すごく象徴的な出来事があったんですよ。あるチームのパフォーマンスが、リーダーの退職があったりしてあまり良くなかったんですね。それを本人たちも自覚していて、チーム内で1on1やKPTをやってみたり、スクラムを取り入れてみたりと、いろいろ試してみたものの、大きな改善には至らなかった。

でも、そうしているうちにGo To トラベルが始まってしまって、否が応でもやらなければならない状態になったわけです。その時点の自分たちのキャパシティを超えるレベルのプロジェクトだったから、なりふり構っていられないし、皆で歯を食いしばって取り組むような状況になっちゃったんですね。

当時、チームの皆が「この人がリーダーをやればいいのに」と思っていた人がいたのですが、本人はそれまで遠慮していたんです。でも、誰かが切り盛りしないといけない状況になって、その人が「やります」と言ってリーダーシップを取り始めた。そのチームが変わり始めたのは、そこからですね。

やっていくうちにそのチームはどんどん成長して、チームとしての活動が目に見えて改善されていきました。つまり、チームビルディングをしたことによってビルドされたのではなく、チームとして取り組まなければならない問題に直面したからビルドされた。これは「そりゃそうだよね」と、その時に思ったんです。

本人たちは決してチームビルディングを目的にしていたつもりはなく、上手くまわっていないからプロセスをどうにかしようといろいろ試していたんだけど、問題はそこではなかったと。結果として、そのチームは今もずっと生産性が高くて、本当に活躍してくれています。あの時は大変だったけど、皆「あれで一皮剥けました」と言っていますね。

__──すごく素敵なエピソードをありがとうございます。伊藤さん、本日はありがとうございました！__

※Findy Teamsサービス詳細は以下よりご覧いただけます。
https://findy-teams.com/service_introduction

一休伊藤様と佐藤さんとの対談のpic

20/11_ikyu_taidan

宿泊予約事業やレストラン予約事業などを手掛ける、株式会社一休。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Teams」を活用いただいています。  今回は、執行役員CTOを務める伊藤直也さんにインタビュー。実際に「Findy Teams」上でのデータを参照しながら、エンジニア組織における生産性についての考え方などを伺っていきます。

.css-1uuptc0 svg{width:32px;height:32px;fill:#666666;stroke:#666666;}@media (max-width: 750px){.css-1uuptc0 svg{width:24px;height:24px;}}インタビュー

定量目標を設定してスピード感のあるユーザー価値提供を目指す取り組みについてワンキャリアさんに聞いてみた

リモートでむしろ生産性が上がったエンジニア組織の作り方を一休 CTOの伊藤さんに聞いてみた

インタビュー