## 開発組織の初期メンバーとして、グロービスへ入社

__ーーまず最初に、お二方のこれまでの主な経歴を教えていただけますか？__

末永さん：前職では、教育系のスタートアップにいました。実力不足もありますが小さい組織で世の中に与えれる影響力をあまり高くできなかったことに課題を感じて、大きな会社でスタートアップに近い動きができれば、もっと大きなことが実現できるのではないかという思いから、グロービスに入社しました。

入社したのは、2016年。当時のグロービスにはエンジニアがおらず、1人目のエンジニアとして入社しました。「GLOBIS 学び放題」というプロダクトの開発から、徐々にマネジメントの役割に移り、現在はVPoEとして開発組織全体のマネジメントを担っています。

大沼さん：もともといくつかのベンチャーで働いていて、その中で課題に感じていた効果検証や技術負債の解消に課題を感じていました。組織拡大するためにはどのような問題を解決すべきかを知りたいと思い、グロービスにジョインしました。入社したのは、組織が拡大していくタイミングの2017年で、エンジニアとしては5～6人目でした。

__ーー御社の開発チームの特徴について教えてください。__

末永さん：事業会社として、ユーザーとしっかり向き合ってプロダクトを開発しているところが特徴です。開発チームとユーザーの皆さんとのユーザーコミュニティがあるので、ユーザーの声を聞きながら近い距離で開発ができるのは、すごく面白いと思っています。

開発のスタイルとしては、スクラムを全般的に導入しています。スクラムチームの数は、現在6チームほど。スクラムは1チームごとの運用になるので、組織全体としては、Scrum@Scaleという大規模スクラムのフレームワークも取り入れています。

大沼さん：組織全体をメトリクスで見て、早期に課題発見する取り組みを大事にしています。「Findy Teams」導入のきっかけにも関わるところですが、組織全体でDevOps指標などを見える化していく動きがあります。

## 0人から120人へ、6年で大きく拡大してきた組織

__ーーここ数年で大きく組織が拡大されたと思いますが、現在の規模はどれくらいですか？__

末永さん：僕が入社した6年前、エンジニアは0人でしたが、今はデザイナーなどを含めたテクノロジー職全体で、120人くらいになっています。拡大していく中で、いわゆる30人の壁、50人分の壁を感じる場面もありました。

__ーー現在の120人という規模の組織で、意識して取り組まれていることはありますか？__

末永さん：今感じているのは、100人の壁です。チームに分かれていくほど、その中で起きている問題に気づきにくくなるので、いかに早く問題を発見するかが肝になります。
各チームが改善に向けて動くだけでなく、大規模スクラムのフレームワークの中で、そのナレッジを横に伝播させていけるような情報共有の仕組みも大事だと思っています。

大沼さん：組織が拡大していくと、2～3人の規模でやっていた開発スタイルとは大きく変わってきました。2～3人で開発しているときは絶対に1日に数回はデプロイしていましたね。

ところが規模が大きくなってくると、リリース当番ができたりする。リリース当番ができるとリリース頻度が週に1回以下になり、リリース作業自体の負荷・リリースへの心理的障壁が上がってしまうためエンジニアとしては自分のプロダクトをコントロールできないような印象を持ってしまいます。

そうした方向性に行かないように、スタートアップのような開発スタイルを、今の規模に適応していくことを意識しています。

## デプロイ頻度を上げることで、精神的な負荷を下げる

__ーー開発チームにおける課題や、それに対する取り組みについて教えてください。__

大沼さん：一番大きな課題だったのは、デプロイが週に1回だったことです。それが約2年前で、例えばお正月明けになると、休み前にコードフリーズしていたこともあり1回のデプロイでFile Changedが300オーバーのリリースPRがデプロイされていたんです。そうなるとエラーが起きても何が原因かわかりづらいですし、デプロイするときに胃が痛くなるんですよね。なので、都度デプロイにしていくための取り組みを始めました。

ただ、中にはQAプロセスをしっかりと通して、週に1回デプロイした方が良いと考える人もある程度いたんです。なので、しんどい作業ほど多くこなし、負荷を分散していくというDevOpsの考え方を言語化して、もし問題が起きたらロールバックして、その影響を最小限にすべきだということを伝えていきました。

※Qiita：[胃が痛いビッグバンリリースはもう嫌なので、デプロイを日常にする](https://qiita.com/technuma/items/eae37b75e3aa5530d319)

__ーー現在のデプロイ頻度はどれくらいですか？__

大沼さん：指標としては、1日あたりのデプロイ回数を開発者数で割った「d/d/d」（deploys / a day / a developer）を1ヶ月単位で追っていて、その数値が0.1から0.2あたりになっています。0.1以上で健全と言われているので、今はこれをキープしていきたいですね。

__ーー週に1回のデプロイが良いと考えるメンバーもいた中で、どのように取り組みを進めていったのでしょうか？__

大沼さん：リポジトリを触っているチームは2～3チームありますが、いきなり全体に適用せず、まずは自分チーム内から進めました。そして、実際に運用が回ってきたところで、他チームの人と今起きている問題について話し、復元力の高いシステムを作っていく方向で認識を揃えていきました。

あと、スプリントレビューが週に1回あるんですが、スプリントレビューで通らないとリリースしにくい雰囲気だったんです。この条件があると週に1回でデプロイが固定されてしまうので、POレビューでOKだったらリリースするフローに変えていきました。

__ーーデプロイ頻度が高くなったことで、組織的に変わったと感じる部分はありますか？__

末永さん：デプロイ頻度が高まったことで、開発が活性化している雰囲気がすごく出たと思います。リリースの通知が日常的にSlackに流れてきて、開発がどんどん進んでいることが見えるようになりました。

やはり組織が大きくなるほど、何かを変えようとする動きがなかなか取りにくくなります。でも、小さなチームで意思決定して、それが良い形に進めば、横のチームに広がっていく。大沼さんにファーストペンギン的に飛び込んでもらったおかげで、他のチームも動いていく流れができたのは、組織としてすごく良いことだと思っています。

## 生産性を可視化し、ビジネスサイドや経営陣にも共有

__ーー取り組みを進めたことで、ビジネスサイドとの関係性が変化した部分はありましたか？__

大沼さん：半年から1年くらい前までは、仕様は詰まっているのに、開発が追いつかない状況がありました。ところが最近は、要求定義や要件定義が間に合わないことが増えてきています。グロービスはステークホルダーが多く、いろいろな意見を集めて仕様を決めるのは大変な作業なのですが、そこにボトルネックが移動してきたんですね。

僕としては、それはすごく良いことだと思っています。そこにボトルネックが移動したのであれば、今後もっとエンジニアだけで仕様が決められる領域を増やすとか、ふわっとした要望から仕様に落とす仕組みを作っていくことなどを検討していけると考えています。

末永さん：とはいえ、エンジニアの生産性に対する疑問も、出てくることはあります。やはり組織が大きくなってきたときに、少し離れたチームから眺めると、なかなか動きが見えづらかったりするものなんですよね。

ただ、開発スピードが速いか遅いかというのは感覚論で、人によって基準が違います。ここをしっかり可視化して共通認識を持つことがすごく大事だと思っていて、「Findy Teams」の数値は今かなり活用させてもらっています。

例えば、月に1回ある部門全体の共有会で、開発のリードタイムがどれくらい短くなったかを報告したり。大沼さんのチームでは、この間5倍くらい短くなったという話もありました。そうやって、しっかり可視化して伝えていくことが重要だと思っています。

__ーー経営陣の方々に、数字で伝えやすくなった部分もありますか？__

末永さん：そうですね。先日、「Findy Teams」の勉強会を開いていただいて、その場に経営チームの方々にも出席してもらったんです。経営チームからも、いろいろなコメントが出てきて非常に良かったです。

## 「Findy Teams」を活用し、良い取り組みを横へ広げていく

__ーー「Findy Teams」を導入いただいた、きっかけを教えてください。__

末永さん：指標としてd/d/dを追っていましたが、ウォッチはできても、具体的な改善に繋げるのが難しくて。大沼さんのチームでは、d/d/dを上げることができていましたが、他のチームは十分に上がりきっていない状態でした。
そこで、もっと使いやすく改善に繋げやすいサービスがあればと思っていたところ、既にサービスを使っている会社さんの話を聞く機会があり、無料トライアルを経て導入することを決めました。

__ーー「Findy Teams」の主な活用方法について教えてください。__

末永さん：週次の開発マネージャーが集まる場などで、「Findy Teams」のスコアを見ています。最近面白かったのは、サイクルタイム分析で、全チームをプロットすると、チームの特色が出てくるんですよ。

例えば、新規事業のチームはPOの意識決定が速いので、そのプロセスが速かったりとか。安定的なチームやスピードを大事にするチームなど、さまざまな比較が出るので、そういった部分も見ながら、マネージャーの方々と改善を進めていこうとしています。

大沼さん：「何をやったら、どれくらい良くなった」という内容を、共有していくことが大事だと思っています。DevOpsのベストプラクティスを見ると、レビューを出したらすぐに見るようにするといった文化的なことが7割くらい、CI/CD関連が3割くらいだと思います。

そういった内容を、SoS（スクラムオブスクラム）、SoSoS（スクラムオブスクラムオブスクラム）の場（大規模スクラムにおけるスクラムマスターの横連携の場）や全体会議などで共有することで、どんどん横へ広げていきたいと考えています。

顕著だった例でいうと、ペアプロをやっているチームは、レビュータイムがかなり速いということが明確に見えたりしていましたね。

## チームが自ら課題を発見・改善するために活かしたい

__ーー今後の「Findy Teams」の活用イメージがあれば教えてください。__

末永さん：「Findy Teams」を導入したとき、最初は3チームで導入しました。そこから使っているチームがかなり増えてきている状況です。導入する際は、使いたいチームから声が上がってくる流れの方がより使い込んでくれると思っています。

もし全チームが使う状態になれば、「Findy Teams」を中心にいろいろなコミュニケーションが進んでいくと思いますし、数値的にも良い取り組みだとわかってくると思うので、今後より横に広がっていったら良いなと思っています。

大沼さん：健康診断のような感じで、「Findy Teams」を使って、チームが課題を発見していけると理想ですね。そうすると、チームで自ら改善していけると思うので。ボトルネックが何なのかを、自分たちで把握することに活用できると良いと思っています。

__ーー今後の「Findy Teams」に期待することはありますか？__

末永さん：僕らが導入した当初は、Four Keysもサイクルタイムもありませんでしたが、今ではそのあたりが網羅できているので、本当にリリース頻度が高くてすごいなと思います。

今後は他社のデータとの比較が、より見えてくると良いですね。僕らは強い開発組織をつくっていきたいので、世の中の平均よりも、Four Keysのエリートやハイパフォーマーくらいのトップ層と比較したいと思っています。

また、メンバーの自発性を大事にしたい僕らとしては、トップダウンで目指す数値を決めたり、それを評価に繋げたりもあまりしたくありません。なので、そういう比較できるものがあって、それぞれに自分たちで目指すところを決められるサービスになると理想的です。

## 日本発、世界をリードするEdtechカンパニーになる

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

末永さん：僕らは「日本発、世界をリードするEdtechカンパニーになる」というビジョンを掲げています。なので、世界クラスのテックカンパニーに相応しい開発力を持つチームをつくっていきたいと考えています。

今年は採用にもかなり力を入れているので、規模もさらに拡大していく見込みです。規模を拡大するとアジリティが落ちてしまうという課題感はよく聞きます。規模を拡大しつつも、生産性を維持できる組織を「Findy Teams」も活用しながら考えていきたいですね。

大沼さん：よくスクラムで「スケールする前に、まずは2つ良いチームをつくる」と言われますが、中途半端な状態で拡大するとパワーが低いまま、それが横展開されてしまいます。そうすると、規模が大きくなっても十分な効果が出ないので、採用で人を増やすことと両軸で、もっとチームを良い状態にしていくことが大事だと考えています。

そのためには、DevOpsを当たり前にしていくことが重要で、健全な状態として目指すべき指標の認識を合わせながら横展開していきたい。それによって、人が増えても生産性を維持できる組織を実現していきたいと考えています。

__ーー末永さん、大沼さん、ありがとうございました！__

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

globis_interview _2

グロービスでVPoEを務める末永さんと、エンジニアリングマネージャーを務める大沼さんにインタビュー。開発チームにおける課題や取り組み、「Findy Teams」導入のきっかけなどについて伺っていきます。

Scrum@Scaleを導入し、チームの横連携を強化。デプロイ頻度を保ちながら組織拡大を目指すグロービスの取り組み

## 限られたリソースで、いかに速くお客様へ価値を届けられるか

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

嶋田さん：我々は創業から3年目のベンチャーで、プロダクトマーケットフィットを目指し、日々模索しているフェーズです。開発チームは現在3名、業務委託の方を入れて4名。人数が少なく限られたリソースの中で、お客様にいかに価値のあるものを提供できるか、いかに速く価値を届けられるかといったことにチャレンジしています。

プロダクトマーケットフィットを模索していくにあたって、機能の要望やニーズが変わることもあります。そうした環境でも、できるだけ手戻りを少なく、継続して高速にお客様に価値を届け続けることが、我々のミッションだと考えています。

__──御社ならではの開発チームの特徴について教えてください。__

嶋田さん：弊社サービスである「チームステッカー」というソリューションをつくっている身として、私たち自身も日々感謝を伝えることを重要視しています。また、人数の少ない組織体制ということもあり、私が直接お客様とのミーティングに参加しています。お客様との距離がとても近く、いただいた要望や不具合報告を、クイックに開発の現場に落とし込めるところが特徴だと思います。

竹田さん：チームの特徴は、人数が少なく経験者が多いことですね。基本的にほぼ経験者で、スキルレベルは高いと思います。それから、ビジネス側との接点も多く、ビジネス側と開発側でお互い積極的にコミュニケーションを取ることを意識しています。

例えば、営業と開発の間に溝があると、お客様の声がダイレクトに伝わってこなかったり、営業が無理な要望を拾ってきてしまったり、といったことが不満に繋がりがちです。ですが、僕らはそういったことはほとんどありません。

むしろ、お客様から出てきた要望に対して、どうやったら叶えられるのか、できる方法をみんなで考える。もしそれが叶えられないとしても、本当にやりたいことが何なのかという真の価値を考えながら、建設的に議論していきます。これは、ビジネス側のメンバーとの関係性からくる特徴だと思います。

## 「Findy Teams」の導入で、組織の課題がデータとして可視化

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

嶋田さん：以前まで、少人数であることやスピード感を重視することを建前に、レビューをおろそかにしてしまっていました。それによって、リリース後に不具合が発覚するようなことが、だんだん増えてきてしまったんですね。そうした課題が顕在化してきたタイミングで、「Findy Teams」の存在を知り、反省の意味も込めて、自分たちの組織のスコアリングを見てみようと思ったんです。

そして、実際に「Findy Teams」を導入してみたところ、レビューされておらず、ほとんどセルフマージになっていることがデータとしてわかって、「これはまずいよね」となりました。みんな体感としてはわかっていたのですが、データで見ることによりチームとして改善の意識が生まれました。

__──改善に向けて、具体的にどのような取り組みをされましたか？__

嶋田さん：最初は、プルリク作成からレビューまでのリードタイムを追いかけていたのですが、なかなか改善しませんでした。GitHub上でレビュアーにアサインしても、アサインされた人が気づかなかったり、後でレビューしようと思って忘れてしまったり、といったことが多発していました。

これに対して、GitHubのAPIを使って今あるプルリクの一覧を、朝と夕方にSlackでレビュアーに通知するようにしたんです。これはレビューの意識付けにかなり効果的で、次第に随時レビューする習慣ができていきました。

竹田さん：この仕組みはすごく良かったですね。それから、「Findy Teams」のおかげで、追うべき目標が数値化できました。やはり数値化されると目標が立てやすくなるので、その点もすごく良かったと思います。

__──「Findy Teams」の中で、特に意識して見られている数値はありますか？__

竹田さん：プルリク作成数やコミット数を主に見ています。具体的な目標は立てておらず、いつもと比べて数値が大きく外れたときや、コミットが全然できていないときなど、何かありそうだなと思うタイミングで確認するようにしています。

嶋田さん：私自身がよくセルフマージしてしまうので、レビューされずにマージされた割合が、どのくらいを推移しているのかを見ています。あとは、プルリクごとの平均変更ファイルや変更行数が跳ね上がっていないかなどを、自身の振り返りとしても見ていますね。

## 新メンバーのオンボーディングにも「Findy Teams」を活用

__──「Findy Teams」を最初に知っていただいたのは、どのようなきっかけでしたか？__

嶋田さん：開発組織に関するオンラインイベントがきっかけですね。そのときに登壇されていた方がサラッと「Findy Teamsを組織づくりに役立てています」とお話しされていて、サービスを調べてみたら良さそうだなと。まずは無料でトライアルが体験できるということだったので、試してみることにしました。

__──「Findy Teams」導入企業の中で、御社は最も小さなエンジニア組織規模にあたります。そうした中でも、ご導入いただけた理由があれば教えてください。__

嶋田さん：「人数が少ないから、まだ大丈夫」と思い続けてきた結果、そろそろこのままではいけないという感覚が強くなってきたことが、導入のきっかけです。

竹田さん：これからメンバーが増えていくと考えたときに、何かしらの指標が欲しいという気持ちもありました。長く一緒にやっているメンバーのことはよくわかりますが、新しい人が入ってきたときに、どれくらいできているかを測る術がない。なので、そういった指標を自分たちで持っておきたいという思いもありました。

__──「Findy Teams」の導入後、新しいメンバーを迎え入れるにあたって活用いただいたケースはありますか？__

嶋田さん：「Findy Teams」を使い始めてから、契約社員を含めると新たに2名入っていて、オンボーディングで早速活用しています。私が各メンバーと定期的に1on1を行っているので、そのタイミングで注視するポイントを伝えています。例えば、プルリクの作成数やコミット数などですね。

入ったばかりだと、まだ知識がないからコミットができないとか、プルリクをどういう単位でつくっていいかわからないとか、そもそも流れがよくわからないとか、そういったことが最初の壁になってしまいます。なので、新しく入ったメンバーもスムーズに開発できるようお困りごとを解消できるようにフォローしています。

__──「Findy Teams」のCSによるサポートはいかがでしたか？__

嶋田さん：「Findy Teams」は、普段どおりに開発しているだけでデータが取れて、設定がほとんどいらないところが魅力です。ただ、その取れたデータをどう見ていくかが最初わからなくて。担当者の方に、データの見方をいろいろと教えていただいて、すごく助かりました。

また、「一般的な数値はこうですが、御社の場合ここのパフォーマンスが高いですね」といった感じで、データを用いながら分析してくださったんですね。実際のところは、セルフマージが多いためにリードタイムが短いということだったのですが、そのお話を聞いて、ちゃんとレビューをしつつも、いかにリードタイムが短い状態を保つか、という発想になりました。さまざまな会社を見ているファインディさんが、他社と比べて分析してくださるおかげで、次の動きが考えやすくなるのでありがたいです。

## 人数が増えても、スピードを落とさず価値提供できる体制を

__──「Findy Teams」を今後どのように活用していきたいか、イメージがあれば教えてください。__

嶋田さん：今後メンバーが増えていくにつれ、生産性が下がりやすくなってしまう面もあると思います。ですが、生産性をなるべく落とさないように、スピード感を持って価値提供できる開発体制を維持することに役立てたいですね。

また今後は、障害発生率や障害からの平均復旧時間などをKPIとして、プロダクトやサービスのヘルスチェックに活かしていけると、より安定化にも近づくと考えています。

__──それでは最後に、開発チームとして今後目指していきたい姿について教えてください。__

嶋田さん：1年後には、開発チームを今の倍の6～7人にしたいと思っています。その上で、今と変わらないアウトプットを出し続けていきたいです。

竹田さん：お客様に速く価値を提供するというミッションを掲げる開発チームとして、今後人数が増えても、開発の質とスピードを両立できるチームをつくっていきたいと思います。

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

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

communitio_interview

今回は、コミュニティオでCTOを務める嶋田さんと、システムアーキテクトを務める竹田さんにインタビュー。本インタビューでは開発チームにおける課題や取り組み、「Findy Teams」導入のきっかけなどについて伺っています。

組織拡大を見据えて開発組織の改善意識を醸成。コミュニティオによる定量指標の活用

## 入社4～5年目、初期から開発組織を支えてきた2人

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

高橋さん：主な経歴としては、Web制作会社やデザイン会社などを経て、前職はWebサービス系のクラウドソーシングやポイントサービスをやっている会社で、エンジニア技術統括やCTOをしておりました。センシンロボティクスには、2017年に入社し、僕が実質1人目のエンジニアとしてプロダクトをつくり始めた経緯があります。

これまで部長として開発部の組織をつくってきましたが、今年の春に組織の体制が変わり、現在は品質向上を担うサービスクオリティという役割で、運用設計やQA、チーム立ち上げなどを担当しております。

中山さん：私はずっとソフトウェアの開発をやってきていて、メインフレームの端末エミュレータやグループウェア、エンタープライズサーチと言われる領域の製品をつくったりしていました。

センシンロボティクスに入ったのは2018年。エンジニアが5～6人の頃でした。入社からエンジニアとしてやってきて、今年春からはテクノロジーグループのマネージャーをしています。

## 現場にも足を運ぶ、オフィスだけでは完結しない仕事

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

高橋さん：僕らのプロダクトやサービスでは、データの取得から分析、そして利活用まで、一気通貫で提供しています。データ取得はドローンやロボットを使って自動化や効率化を行い、AIを使って分析します。そして、Webアプリケーションやモバイルアプリケーションなどを提供して、お客さまに活用いただいております。

社内には、Webエンジニア、モバイルエンジニア、AIエンジニア、ロボットエンジニアがいまして、幅広い技術を使って開発をしています。さまざまな技術を持った人が力を合わせて、ソリューションを提供している組織ですね。

開発部のミッションは、今作っている複数の新しいプロダクトをしっかりリリースしていくことと、すでにリリースしたプロダクトのグロースや安定稼働になります。そして、お客様の課題解決のための新しい技術の研究もミッションになります。

__──御社ならではの面白さを感じるポイントがあれば教えてください。__

中山さん：私は今までずっとオフィスで完結するものをつくってきたので、自分のつくったソフトを使ってドローンが飛ぶとか、そういったところは他ではなかなか経験できない面白さがありますね。

高橋さん：テストもWebだけでは完結しないことが多いので、みんなでテストフィールドまでドローンを飛ばしに行ったり。お客さまへのヒアリングや現場検証のために現場に行くことも多いです。

中山さん：オフィスだけでは終わらないのが我々の仕事です。そこは大変な部分でもあり、面白い部分でもありますね。

## プロダクトの安定稼働やグロースに、より注力していく

__──開発チームにおける直近の課題や、それに対する取り組みについて教えてください。__

中山さん：プロジェクトやプロダクトが多く、本当は開発メンバーをプロダクトに固定してグロースさせたいのですが、それが難しくて苦労しています。4月に新しくリリースしたプロダクトでは、メンバーを固定して、残りのメンバーで新しいプロジェクトをこなしていますが、どうしても手が足りなくなってしまいます。

以前から「SENSYN CORE」というプラットフォームの上に業務特化のアプリを作ることで機能の重複を減らし、少ない人数でも高速に開発できることを目指しています。ただ、これは一部は上手くいっているのですが、もっと上手く使い回すために再設計しているところです。

高橋さん：今後はプロダクトをグロースさせていくところに、より注力していこうと考えています。ただ、お客さまに使っていただいているプロダクトを安定稼働させていくにあたって、まだまだ足りていないことも多いなと。

今まではとにかくたくさんプロダクトをつくっていくフェーズだったので、今後しっかりと運用していくにあたって、開発のスタイルや考え方も変わってくると考えています。なので、僕がサービスの品質やセキュリティ、運用設計、仕組みづくりといった部分の整備を進めています。

## プログラムを自作するも難航し、「Findy Teams」の導入へ

__──「Findy Teams」を知ったきっかけや、導入を決めたポイントについて教えてください。__

高橋さん：もともとは、僕が何年か前に『[LeanとDevOpsの科学](https://www.amazon.co.jp/dp/B07L2R3LTN/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1)』という本を読んで、パフォーマンスの可視化がすごく重要だなと思ったんですね。当時GitLabを使っていたんですが、Four Keysを可視化しようと、集計するプログラムを自作してみたんです。

ところが、GitLabからGitHubに移行することになり、GitHubのAPIに対応させるのが大変だなと。しかも、途中1年くらいGitLabとGitHubを併用していたので、マージするのも面倒で、あまり使えずフェードアウトしてしまい、「これは片手間で自作するものじゃないな」と思ったんです。

それで、同じようなサービスを海外も含めて調べたり、検証していたのですが、あまりうまくマッチするものがなくて。どうしようかなと悩んだときに、ファインディさんから「Findy Teams」を紹介していただいたんです。「Findy Teams」は、欲しい情報がまさに全部取れるし、UI/UXもすごくわかりやすい。実際に無料トライアルの期間を経て、使いやすかったので、導入することにしました。

## オンボーディングや課題の可視化に「Findy Teams」を活用

__──現在、「Findy Teams」をどのようにご活用いただいていますか？__

中山さん：最近チームに新しく入った人のパフォーマンスを見て、オンボーディングに役立てています。例えば、チームに馴染めていない段階だと、なかなかレビューしづらいと思いますが、だんだんレビュー数が増えていくのが見えたり。何かフォローした後に、パフォーマンスが上がったかどうかもわかるので、そういう面で活かしています。

高橋さん：活動が可視化されるのは大きいですね。意外と夜中に働いているんだなとか、今まであまり把握できていなかったところが見えるようになりました。負荷についても、具体的にどう忙しいのかが見て取れます。急にすごく稼働が増えたり、プルリクが増えているとなれば、明らかに負荷が偏っているとわかりますし、そういったヘルスチェックはマネジメントの観点ですごく大切ですよね。

また、開発の進捗が遅れてしまっている時に「開発パフォーマンスが良くないから」と一言で収めてしまうのではなく、「Findy Teams」を活用することで詳しい状況をチェックできます。例えば、レビューが偏っているとか、プルリクのサイズが大きくなりすぎているとか。そういう具体的な課題が可視化できるところが良いなと思っています。

__──今後、「Findy Teams」に期待する機能などがあれば教えてください。__

中山さん：「この人の負荷が高くなっています」といったサジェストがあると嬉しいですね。今も急に負荷が上がった人は表示されますが、期間を柔軟にできるとよりありがたいなと。あとは、プルリクの平均サイズですね。プルリクのサイズが大きすぎるプロジェクトは、やはり品質に問題を抱えている可能性が高いので、そこがアラートを介してわかるとありがたいです。

高橋さん：Four Keysについては、もうほぼ網羅されていると思いますし、すごい勢いで機能追加されているので、欲しいと思ったものは、だいたい追加されているという印象です。

あとは、サービスの品質に関するところで、エラーの発生率なども紐付けて見られたらいいですね。
今後は安定したパフォーマンスのためにSLOやSLIも見ていきたいと思っており、エラー発生率などとも紐付けられると良いなと思っています。

__──マネジメントへの活用にあたって、「Findy Teams」に期待する機能はありますか？__

中山さん：今までは、それぞれの人のパフォーマンスを定性的に把握できていましたが、人数が増えてきたので、徐々にこの先見えづらくなるのではないかと思っています。なので、「最近このチームはパフォーマンスがあまり良くないですよ」というのを通知してくれる機能があると、すごくありがたいですね。基本機能は今もあると思うので、期間や対象を調整していただけると、より役立つと思います。

## 安全に失敗できる組織、かつ高信頼性組織を目指す

__──それでは最後に、今後どのような開発組織を作っていきたいかについて教えてください。__

中山さん：安全に失敗ができる組織を目指しています。人間は失敗から学ぶことがたくさんありますから、どんどん失敗してほしいのですが、事業に大きなダメージがあると困ってしまいますよね。なので、安全に失敗できるような環境をつくっていきたい。そうすると、学びもより早くなりますし、チーム全体の実力も上がっていくと考えています。

例えば、ブルーグリーンデプロイメントやカナリアリリースなど、少しずつリリースしていく方法であれば、失敗しても事業へのダメージが少なくなります。センシンロボティクスの場合は、カナリアリリースはあまり適合しないのですが、そういった失敗のダメージを最小化できるやり方を考えていきたいと思っています。

高橋さん：社内で1つのキーワードとして、高信頼性組織というものを掲げています。高信頼性組織とは、原子力発電所や航空管制システムといった、失敗が許されない環境において、高い成果をあげている組織のことを指す言葉です。

僕らも、社会インフラをメンテナンスする会社など、非常に機密性の高い情報を扱う会社にシステムを提供しています。他にも、例えば僕らがつくったドローンを制御するシステムにミスがあって、もしドローンがどこかに飛んでいってしまったら、物理的な被害を及ぼす可能性もあります。

なので、やはり品質はとても大切ですし、トラブルや障害に敏感な組織でありたいなと。失敗一つひとつをちゃんとみんなで振り返りながら、品質や安全、危機管理をしっかりと意識した組織にしていきたいと思っています。

──高橋さん、中山さん、本日はありがとうございました！

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

sensyn-interview

今回は、サービスクオリティディレクターを務める高橋和也さんと、開発チームのマネジメントを務める中山淳さんにインタビュー。開発チームにおける課題や取り組み、「Findy Teams」導入のきっかけなどについて伺っていきます。

Four Keysの自前取得からサービス導入で自動化。高信頼性組織を目指すセンシンロボティクスの取り組み

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