Hacobu井田様

今回は、Hacobuでエンジニアマネージャーを務める、井田さんにインタビュー。「Findy Team+」を活用して開発生産性の計測に取り組んだ背景や、どのようにチームを巻き込んでいったかなどについてお話をうかがいました。

定量化でメンバー自走のふりかえりを実現。開発生産性向上を目指すHacobuの組織づくり

DMM androidインタビューカバーイメージ

今回は、DMMブックスアプリを手掛けるebook-native-androidチームのエンジニア、佐藤さんと柴田さんにインタビュー。開発チームにおける課題と取り組みについて、「Findy Team+」のデータを踏まえながらお話を伺っていきます。

定量指標をもとにした開発プロセスの体質改善。量・スピード・質の最大化を目指すDMM.comのAndroid開発組織

yahoo

開発生産性向上の先進的な事例として、ヤフー株式会社の技術支援本部にて、開発生産性向上のためのデータ可視化と分析を務める安永さんにインタビューしました。大規模な開発組織において、どのようにFour Keys指標を横断して可視化し、いかに開発生産性向上への取り組みを推進していったかなどについて伺いました。

480プロダクトで"Four Keys"を計測。「型化」にこだわるヤフーの開発生産性マネジメントとは？

画像-20230209T034834Z-001

DMM.comを支えるプラットフォーム全体の開発生産性を向上させる、というミッションに取り組む木村様が、どのように変革を起こしていったのか、具体的な取り組みや苦労についてインタビューさせていただきました。

プルリクのリードタイムを5分の1に劇的改善。科学的思考とオーナーシップで変革するDMM.comのエンジニア組織

バイセルテクノロジーズ様 バナー画像

エンジニア組織の開発生産性を向上させるために、BuySell Technologiesが挑戦した取り組みについて、EM渡邉様と赤川様にインタビューさせていただきました

「プルリク作成数がセンターピン」BuySell Technologiesの仮説思考が生んだ圧倒的生産性向上と課題解決

朝日新聞（第一弾インタビュー）_バナー画像

朝日新聞社の社外CTOを務める広木大地さんと、朝デジ事業センター カスタマーエクスペリエンス部で次長を務める西島寛さんにインタビュー。システム刷新プロジェクト「Plasma」のお話を中心に、「Findy Team+」のデータを踏まえながら、開発チームにおけるこれまでの歩みや今後の取り組みについて伺っていきます。

テンポ良く・心地良い開発環境を実現した朝日新聞のモダンなエンジニア組織とは？

22/10_ココナラ様インタビューのヘッダー画像

ココナラで執行役員/開発担当を務める村上さんにインタビュー。開発チームにおける課題や取り組み、「Findy Team+」導入のきっかけなどについて伺っていきます。

技術負債解消とオンボーディング設計が秘訣？ココナラが目指す開発生産性向上と組織拡大の両立

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

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

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

入社したのは、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 _8

グロービスで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」導入のきっかけなどについて伺っていきます。

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