## SIerを10年経験した後、2018年から星野リゾートへ

__――まず最初に、簡単なご経歴と現在の役割について教えてください。__

藤井さん：私はSIerに10年ほどいて、Javaメインで受託開発をしていました。その中では、Webシステムや基幹系システムの開発をしたり、最後はコンサルティング的なこともしたりしていました。そこから、家庭の都合もあり転職を考えたときに、仕事で繋がりのあった星野リゾートに声をかけてもらい、2018年に入社しています。

当時はエンジニアがほとんどいない状況でしたが、会社としては内製化を進めたいという話がありました。内製化と言っても、最初はコードの基盤までは社員が担いつつ、パートナーにも協力いただいて開発するといったところから始め、割合をだんだん内部に寄せていったり、開発する範囲を少しずつ広げたりしてきました。

今は社員のエンジニアが18名で、チームが6つほど。私はエンジニアリングマネージャーとして、CIOと共にエンジニアのマネジメントや評価もしています。とはいえ、私自身がプロジェクトに入ることもあり、施設やマーケティング部門からあがる課題や要望に対して、どうしたらいいかといった相談に乗ったり一緒に進めたりもしています。

__――6つほどのチームがあるとのことですが、どのような形でチームが分かれているのでしょうか？__

藤井さん：フロントやサーバーサイドといったチーム分けではなく、顧客に提供する価値をベースにチームを分けています。大きなチームとして、まず1つは今ある予約システムの保守開発をしながら機能追加をしているチーム。もう1つは、数年レベルで行おうとしている基盤システムの入れ替えを担当するチームがあります。

その次に大きいのが、CMSをつくっているチーム。そして、財務や人事、総務などのスタッフが使うシステムの開発をしているバックオフィスチームがあります。また、ここ数年チェックインの自動化を進めており、このような新規プロダクトをつくっているチームもあります。まだ構想を練っている段階ですが、顧客がチェックインしてからチェックアウトするまでの顧客体験価値を高める施策を一緒に考えています。

## 現場のことを知り、手を動かす人も一緒に考える

__――星野リゾートならではの特徴や面白さについて教えてください。__

藤井さん：実際に手を動かす人も一緒に考えるところが、一番の面白さだと思います。システム開発で規模が大きくなると、考える人とつくる人が分かれてしまいがちです。しかし、良いアイデアは、やはりシステムを使う現場にありますから、それでは現場でしか得られないアイデアや情報がフィードバックされなくなってしまいます。

星野リゾートには、フラットな組織文化という考え方があります。年齢や性別、役割に関係なく双方向のコミュニケーションを取ることでひとりひとりのスタッフが自ら考え、アイデアを発信し、議論を重ねる文化で、新しいサービスを生み出す源泉となっています。それは、システム開発においても重要な視点であると意識しており、実際につくる人にも一緒に考えてもらうようにしています。

また、手が足りない部分はパートナーの人たちを含めて仕事をしていますが、そういったパートナーの人たちにも一緒に考えてもらうことを意識しています。

__――開発メンバーが、実際にホテルで働いている方々とコミュニケーションしながら進めていくのでしょうか？__

藤井さん：施設の状況をヒアリングしたり、まとめたり、サポートする部門が社内にあるので、まずはその人たちと話すことが多いですが、システム導入時の大事な場面ではエンジニアも現地に行って、施設に足を運ぶようにしています。

私たちはブライダル事業もやっていて、今そのシステムの置き換えを検討しています。過去に、外部ベンダーに開発をお願いしたシステムを利用していることもあり、言われてもわからないことが多かったんです。そのため、施設ではどういうことをしているのか、実際に見に行ってもらいました。

行ってみると、Excelで運用しているものがたくさんあったり、「システムが老朽化して大変なんです」と言われたものの、そもそもシステム化すらされていなかったり、といったことが多くあったようです。やはり実際の現地の課題を知った上で解決することができるというのは、すごくやりがいがあると思います。

__――実際入社される方々は、どのような部分にモチベーションを持っていらっしゃる方が多いんでしょうか？__

藤井さん：単純に技術を使ってものをつくりたいという人は、どれだけ技術力があったとしても採用には至っていないケースが多いです。そういう人は他でも活躍できますし、技術力に強みを持っていても、私たちの会社に愛着を持って長くいてくれると思っていません。

私たちが提供できる価値は、現地で得られた情報や課題などに対して、自分たちで考えて行動できるところです。なので、事業自体に興味がある方もいますが、それ以上に、施設のスタッフが困っていることを、自分たちの技術力を使って解決していく。そういうところにモチベーションを持っているメンバーが多いです。

## 圧倒的な成長スピードと変化の中で、ニーズに応える

__――開発チームとして今感じている課題や、それに対する取り組みについて教えてください。__

藤井さん：課題は言い出したらきりがないですね（笑）。まず大きな背景として、私が入社したときよりも、会社が圧倒的に速いスピードで成長しています。当時は、1年に1、2施設くらいのペースだったのが、今はもう1年に5施設も6施設も増えているんですよ。

単に施設数が増えているだけでなく、会社は新たな挑戦をしています。その1つは、海外への展開。今後海外にも施設が増えていく中で、私たちはグローバルに通用するシステムをつくっていく必要があります。

また、コロナ禍で経営が困難になった施設の運営を任していただくことが多くなったのですが、施設やバリエーション、新規案件なども増える中で、コモディティ化しないホテル運営を見出すために、「新しい宿泊とは何か」を考えなければならない。今までやっていたやり方を、大きく変えながら増やしていく、ということが1つのポイントになっています。

基本的には1年間でリソースを検討しますが、最近はもう半年経ったらガラッと変わっていて。会社の方針が変われば優先度も変わりますし、特に最近はGoToトラベルのような国の施策もあったり、チェックインを例にとっても新型コロナとの生活で非接触が当たり前になったなど、本当に大きく変わってきました。増えるスピードも変わるスピードも速くなっているので、事業変化のニーズに素早く応えることは1つの課題になっています。そして更に海外での施設運営やチャレンジも増えています。

__――グローバルに対応したシステムをつくるにあたって、言語以外には例えばどういったところが課題になるのでしょうか？__

藤井さん：基盤になっているPMSというホテル管理システムがあるんですが、その施設で使われるPMSとなかなか繋ぎ込めなかったりとか。あとは、日本とは異なる税制度やチップ文化への対応、時差の問題などもありますし、課題は多岐に渡りますね。

## 急拡大する組織の可視化に「Findy Teams」を活用

__――「Findy Teams」を導入いただいたきっかけや、それまでに感じられていた組織の課題があれば教えてください。__

藤井さん：情報システムの組織は急激に拡大していて、2015年は4名だったのが、私が入社したときは20名くらい、今はもう60名くらいになっています。

組織全体が大きくなって、エンジニアとPO、運用保守、インフラなどのエンジニアでない人たちを1チームにして協働しています。そのなかで、エンジニアメンバーは社内だけで18名、外部のパートナーさんを含めると30～40名になります。少し前までは私1人で全部見れていましたが、この規模になると難しくなってくるんですよね。

加えて、働く拠点が分かれていることもあり、コミュニケーションも難しくなってきます。そのためスクラムを導入したり、さらにそれをスケールする形として、Scrum@Scaleのノウハウを取り入れたりして、コミュニケーションを取るようにしてきましたが、細かい部分は見れませんし、何よりも開発組織の生産性が気になるんですよね。

「Findy Teams」を導入したきっかけは、まさに生産性の可視化にありました。やはり進捗とかって、どうしても人の感覚が入ってしまうものですから、人の感覚が入っていない実際の数値が取れるのは重要ですね。スクラムでは、安定しているかどうかを重視しているのですが、「Findy Teams」を入れることで、その数字も取れるようになりました。

また、私が外部のパートナーさんの状況まで把握しきれない部分のアクティビティを定量化したことで、面談で反映できるようになりました。そういった面で、簡単に可視化できるところがすごく役に立っていますね。

__――「Findy Teams」で見られるアクティビティの活用についてはいかがですか？__

藤井さん：「Findy Teams」のアクティビティは、すごく役に立っています。みんな安定していないことを感じていても、その原因をつかむのが難しく、なんとなく「タスクが難しかったから」となりがちでした。

ところが、アクティビティが見られると、「コミット単位がもっと小さい方がいいんじゃないか」というような仮説が立てられる。その仮説を検証して改善のアクションを取ると、数値として実感できることが、アクティビティを見るメリットなのかなと思います。

あとはチーム・個人としてどこを目指せばいいか、わかりやすいのもいいですよね。「Findy Teams」のアクティビティの数字が上がって、「でも何か自分たちうまくいってないな」と感じたら意味がないですが、不思議なことに、あの通りにやって数字が良くなると、なんだか気持ちよく開発できているんですよね。

もう1つ、「Findy Teams」を導入した副次的な効果ですが、「Findy Teams」を使っている人たちの事例を見ることで、他社がどういう取り組みをしているかに目が向くようになりました。

ANDPADさんやNewsPicksさんの事例を見て、「やっぱりみんなFour Keysに注目してるよね」とか「SREって重要だよね」とか。それを見て、「だから私たちもちゃんとやろう」となるので助かっています。

__――開発生産性等を数字で見ることに対する抵抗感のようなものはなかったのでしょうか？__

藤井さん：オープンであるべきだし、情報共有することに抵抗はなかったですね。それに、私たちは数字を評価と紐付けていないんです。そこがうまくいくポイントなのかなと思います。星野リゾートの評価制度はもともと、目標に向かって行動する姿やアクションを評価する文化が根付いていることもあります。

私自身、スキルマップもそうですが、何かの指標を評価に繋げた瞬間、うまくいかなくなると思っています。その数字を上げるために無茶をするから。これは昔から代表の星野も言っていて、そういう指標を必達目標にしたり、評価に紐付けたりしないように気をつけています。

## ”世界で通用するホテル運営会社”に合う開発チームに
__――今後目指していきたい事業や開発チームの姿について教えてください。__

藤井さん：私たちはまず第一に、「世界で通用するホテル運営会社になる」というビジョンがあります。なので、当然そこに合うような開発チームを作りたい。宿泊業は基盤が老朽化しているために、現地のオペレーションが非生産的になっている場合もあり、それを解決できるチームをつくりたいと思っています。

宿泊業といっても、私たちが扱っている分野は幅広く、予約や現地の体験から、財務などの裏側まであるので、それらすべてをつくりたいと思っています。

そのためには、たくさんあるチームとコミュニケーションを取りながら、お互いに価値を高めるために切磋琢磨していきたい。さらには、その中でエンジニアだけでなく、施設の最前線にいる人たちを巻き込んでいって、壁のない世界をつくっていきたいですね。

__――御社には、どういったエンジニアの方がマッチすると思いますか？__

藤井さん：言われたものをつくるのではなく、いろんな人の話を聞いて、自分から考えて提案できる人が向いていると思います。私たちの会社にはいろんな立場の人がいて、エンジニアではない人たちもたくさんいます。なので、多様性を重視している方も合うと思いますね。

__――それでは最後に、星野リゾートに興味を持つ方に一言メッセージをお願いします。__

藤井さん：私たちの会社は大きくはなってきましたが、世界レベルで見れば、まだまだすごく小さな企業です。そういったところに挑戦していきたい人たちに、ぜひ入社してほしいと思っています。経験よりもマインドが重要だと思っているので、そういう方にぜひ挑戦していただきたいです。

__――藤井さん、本日はありがとうございました！__

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

hoshinoresorts-interview

今回は、星野リゾートの情報システムグループでエンジニアチームリーダーを務める、藤井崇介さんにインタビュー。開発チームにおける課題や取り組み、「Findy Teams」導入のきっかけなどについて伺っていきます。

急拡大を支えるカギは成長の可視化と現場ニーズのマッチング、組織力を武器に星野リゾートが目指すグローバル展開

## 一度は離れたものの、再び開発組織での仕事へ

__──前島さんのこれまでの主なご経歴と、現在の業務内容を教えてください。__

前島さん：主な経歴としては、新卒で製造業向けのITコンサルタント会社に入り、マスタ管理システムや貿易帳票管理システムのプロジェクトリーダーとして、追加開発や保守運用などを行っていました。

その後は、個人の時間とスキルを売買するCtoCサービスを開発。その次には、クリエイティブに特化したベンチャー企業でシステム部長として、主にエンジニアの採用や開発組織の構築を担当していました。

さらにその後は開発組織から離れ、今まで携わってきたソフトウェア事業とは違う小売事業を行うD2Cに挑戦しました。しかし小売事業ならではの難しさもあり、やはり自分は開発組織の方がよりパフォーマンスが発揮しやすいと感じました。それを再認識したところで、hokanとのご縁があり、入社することになりました。

現在hokanでは、エンジニアリングマネージャーとして、開発組織のマネジメントに携わっています。主に、エンジニアの採用や開発組織のマネジメント、1on1や目標設定、評価、制度づくりなどですね。開発組織のエンゲージメント向上にフォーカスしつつ、幅広く担当しています。

## 日本一安心できる、挑戦する開発組織を目指す

__──御社のビジョンやミッション、開発チームの特徴について教えてください。__

前島さん：弊社の開発組織では、アジリティ・セキュリティ・品質の3つを重視し、「日本一安心できる挑戦する開発組織を目指す」ことをビジョンとして掲げています。

![hokan vision](//images.ctfassets.net/ngrpflsbp3rq/5RY09sx8qy26sU64ABPsG9/e135ade1d21049382d1b5de382788c71/hokan_vision.png)

開発チームの特徴は、3点あります。1点目は、エンジニアに意思決定が託されていることですね。エンジニア自身が、仕様の検討やタスクのブレイクダウンを行っていて、ビジネス側と連携しながら開発しています。自由度が高く、自走できる環境になっていると思います。

2点目は、常に先を読んだ技術選択をしていること。アーキテクチャのリプレイスや、都度行うバージョンアップは当然のことながら、これからお客様が増えていくことを見込んで、拡張性の高いアーキテクチャを構築しています。

そして、3点目は50兆円の保険市場という、非常に大きくかつユニークな特徴を持つ市場に挑戦していることです。巨大でレガシーな産業だからこそ、解決しなければいけない課題も多く、難易度の高い課題に挑戦するのが好きな人が集まっています。

会社の成長にコミットするためには、開発組織として生産性を高めることが、お客様への価値提供に繋がり、そして売り上げの向上に繋がると考えています。それを意識するため、開発組織のミッションとしては、スクラムを改善していくことや、複数の開発ラインを一定のクオリティで作ること、そして新しい技術をどんどん取り入れていくことを掲げています。

![hokan culture](//images.ctfassets.net/ngrpflsbp3rq/JYHmCgBW9qtXxD4E6nUY7/2a57e6149fbc2171d7727145209b2197/hokan_culture.png)

## 品質向上への取り組みから、開発スピードの向上へ

__──直近、開発チームでは改善に取り組まれていたとお聞きしました。現在は、開発チームのOKRをどのように設定されていますか？__

前島さん：昨年はバグによる、お客様からの問い合わせや障害が多くありました。そのため、昨年11月くらいから、どれだけお客様のビジネスに影響が出ているかというインシデントスコアを取り始めたんですが、少しスコアが高かったんですね。スコアが高いと解約にも繋がりますし、障害対応に工数を取られてしまうため、エンジニアが安心して開発することが難しくなる。なので、直近4月までのクォーターは品質向上にフォーカスしていました。

品質向上のため、QAベンダーの方と協力して、テストを意識しながら進めたことで、今はインシデントスコアがかなり落ち着きました。直近では、ひと月に大きな障害が発生することなく、リリース直後の不具合の問い合わせが数件程度になっています。

品質が向上したことで、次はスピードを意識できるようになります。なので、主にプロダクト開発に携わるチームは、今期のOKRのObjectivesが、開発スピードの向上になっています。

Key Resultsに設定しているのは、ストーリーポイントの目標達成率。例えば、チームメンバーのストーリーポイントの目標を40とした場合、週に25や30なら、達成率は何%と週次で追っていく。そこで、もし達成していなければ、なぜ達成できていないのか要素を分解して、PDCAを回していきます。

合わせて、プルリクのマージまでのリードタイムやレビューまでのリードタイムなどの指標を、Findy Teamsを活用してしっかり追っていくことが重要になると考えています。

__──開発チームにおける現状の課題と、それに対する取り組み内容があれば教えてください。__

前島さん：細かく見れば課題はたくさんありますが、やはり直近で最も意識しているのはスピードです。バーティカルSaaSの中で競合も出てきますし、かつてレガシーなプロダクトを作っていた競合もどんどん進化をしてきます。もちろん品質も大事ですが、やはり品質とスピードの両方があってこそ、カテゴリートップに上りつめることができると考えています。

スピード向上のための取り組みとしては、まずはストーリーポイントの達成率を指標としています。ただ仕様の戻りがあったら意味がないので、戻りを防ぐためにPdMやセールスが連携して、ジャーニーマップやストーリー、仕様について、エンジニアと一緒にしっかりと議論する仕様検討会を実施しています。

## 定量化することによって、根拠のある判断に繋がる

__──定量化への取り組みを始められたのは、どのようなきっかけがあったのでしょうか？__

前島さん：開発組織って定量化しにくいですよね。コードを書いたことによって、どうお客様に届いているのか、どう世の中に貢献しているのかが、組織が大きくなるほど見えにくくなってくると思います。

とはいえ、開発組織にどれだけ投資すべきかについて、経営陣の理解や、投資家や株主の方々への説明にあたっては、どうしても定量化が避けられません。CTOもそこを曖昧にすべきではないと考えていて、経営判断として可能な限り定量化しようという方針がありました。

それが結果的に、開発組織にしっかり投資しようという判断に繋がります。「人が足りません」「いや、今の人数で頑張れ」ということにはならず、ちゃんと根拠を持って組織を拡大することができる。しっかりと数値をベースに語るためには、定量化は必須だと思っています。

__──定量化することによって、開発チームとして変化したことはありますか？__

前島さん：定量化していくにあたって、インシデントレポートをしっかり管理することにも取り組んでいます。これをやって良かったのは水掛け論や空中戦にならずに、根拠を持った議論ができることですね。

それから数値が改善されると、モチベーションにも繋がります。数値が下がった時も、下がった原因を分析することができますし、数値が上がったらみんなで褒め合うことができる。そういった文化が醸成されていくメリットもありました。

__──数値をもとに議論できる文化を、社内で浸透させるために工夫したことはありますか？__

前島さん：デイリーミーティングで、インシデントレポートの共有を行っています。また、振り返りの場でも、常に数値をもとに議論するようにしていますね。なにより、きちんとそれをできる人がリーダー層にいることが、組織体制として重要だと思います。

## 思想への共感から、Findy Teamsの導入もスムーズに

__──Findy Teamsを導入いただくにあたって、ポイントとなった部分があれば教えていただけますか？__

前島さん：もともとエンジニアの日々の働きをモニタリングできる体制にすることは、重要だろうという考えがあったので、Findy Teamsの導入については去年の10～11月頃から話に上がっていました。

それに、以前からファインディさんの思想については理解していたんです。日本全体でより開発組織を強くしていこうと考えた時に、まずは人の採用という入口の促進から、マネジメントや文化醸成などと、一貫してやっていくことは必然ですよね。

そこに対してしっかりとプロダクトを作られたことに非常に好感を持っていたので、Findy Teams導入までの意思決定はかなりスムーズでした。

__──ありがとうございます。Findy Teamsの現在の活用方法や、今後の活用イメージがあれば教えてください。__

前島さん：Findy Teamsは、レイヤーによって使い方が違ってくると思います。CTOやマネジメントレイヤーであれば、投資家の方々への説明に使う数値を集めたりする場面で、Findy Teamsのサマリーが活用できると考えています。

リーダークラスになると、チームごとのより細かい数値として、誰がどのようにレビューに工数を割いているのかとか、それぞれのメンバーの活動量とか、そういったところを見ていくことになると思います。

個々のメンバーに関しては、自分がどのぐらいコミットしたのかをチェックして、日々のモチベーションが上がるような活用ができたらいいですね。毎日見たくなるような、ワクワクする見せ方ができたら理想的だと思います。

## 今後は、より自発的に成長機会をつくれる開発組織へ

__──今後、目指していきたい開発チームの姿について教えてください。__

前島さん：開発の品質とスピードが改善されると、やっとグローバルな土台が整ってくると考えています。そうなれば、次は各々が自発的に成長機会をつくれるような開発組織を目指したいですね。社内のエンジニアイベントなどもやっていきたいですし、エンジニアが企画して成長機会を自らつくっていく組織に、直近1〜2年でしていきたいとイメージしています。

やっと組織として一枚岩になり始めてきてるかなと思うので、文化醸成とか、採用などの面で自動的にスケールしていく仕組みっていうのを作っていく。そのためにはスピードと品質という土台を整えることで、みんなが楽しく働ける環境も作っていきたいですね。

__──採用に関して、最近は多くの企業がリーダー層の獲得に苦戦していますが、このあたりについて考えられていることはありますか？__

前島さん：育成できないと、どうしてもリーダー層は枯渇していきますよね。とはいえ、誰にでもマネージャーの適正があるわけではないので、career ladderを定義してあげることと、マネージャーの適正がある人を若手の段階から強化、育成していくことが大切だと思っています。

あと、実現は直近考えてはいませんが、新卒採用も案としてはありますね。優秀かつバランスが整っている、尖りすぎていないエンジニアは、比較的新卒の方が多いです。なので、新卒を幹部候補として、きちんと育成する仕組みが必要だと考えています。

__──最後に、御社に興味を持つエンジニアにメッセージがあればお願いします。__

前島さん：ここまでしっかり考えられている開発組織はあまりないと思いますし、入って絶対に損はさせない自負があります。プロダクト自体も、ものすごくUI/UXを考慮されたものになっています。保険業界というと、あまり馴染みのない分野のプロダクトではあると思いますが、市場規模も大きいので、ぜひ一緒にやっていければと思います。

__──前島さん、本日はありがとうございました！__

hokan-interview

今回は株式会社hokanでエンジニアリングマネージャーを務める前島治樹さんにインタビューし、開発チームにおける定量化への取り組みや、「Findy Teams」導入のきっかけなどについて伺っています。

開発チームの定量化によってスピードと品質の土台を整え、皆が楽しく働ける環境を。レガシー産業の変革に挑むhokanの組織づくり

## 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;}}インタビュー

急拡大を支えるカギは成長の可視化と現場ニーズのマッチング、組織力を武器に星野リゾートが目指すグローバル展開

開発チームの定量化によってスピードと品質の土台を整え、皆が楽しく働ける環境を。レガシー産業の変革に挑むhokanの組織づくり

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

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

インタビュー