intereview_moneyforward　

「Findy Team+」の数値はフルオープン。チーム全員でFour Keys向上へ取り組むマネーフォワードの開発生産性活動  個人向け・法人向けに金融系ウェブサービスを提供する株式会社マネーフォワードでは、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。

「Findy Team+」の数値はフルオープン。マネーフォワードによるチームと個人の課題発見を促進する開発生産性への取り組みとは？

## クリエイター支援プラットフォーム「Ci-en」を運営
__――まず最初に、これまでの簡単なご経歴と現在の役割について教えてください。__

__松永__：新卒でSIerの会社に入り、その後1年ほどで株式会社エイシスに入社しました。エイシスではさまざまなサービスの保守運用や新規開発に携わり、2021年に行われたグループ組織再編のタイミングで、新設されたviviONに転籍しました。2022年4月から「Ci-en」というサービスに携わり、現在チームのリーダーを務めています。

組織の構成としては、Webサービスを担当するWebユニットがあり、そのなかに「Ci-en」のチームがあります。そのWebユニットのリーダーとして、「Ci-en」のサービス運営におけるエンジニアのピープルマネジメントを担いつつ、コードを書いたりコードレビューをしたりといった現場的な作業もしています。

__――開発組織全体の規模や、「Ci-en」のチーム体制について教えていただけますか？__

__松永__：組織全体では、60名くらいのエンジニアがいます。「Ci-en」のエンジニアチームは、リーダーの私とメンバーの3名で、合わせて4名。これとは別にデザイナーや、ディレクションチームに属しているPdMを含むディレクターが関わっています。

__――現在チームでは、どのようなミッションを掲げていますか？__

__松永__：「Ci-en」というプロジェクト全体としては、クリエイターが自分のやりたいことを実現できるようにしていくという目標を掲げています。そのなかでエンジニアチームとしては、PdMが求めている機能のリリースや改善に、常に満足のいくスピードとクオリティで応えていくことを目指しています。

__――それに対して、チームで課題になっていた部分はありますか？__

__松永__：もともと「Ci-en」というサービスが始まったときは、別のリーダーがいて、私がメンバーとしてメインの出力になっていました。ですが、自分がリーダーになったことで、現場業務以外の仕事が増えて、なかなか機能開発ができなくなってしまいました。その影響で、チームとしての出力が落ちている期間が続いていて、そこを改善しようと、まさに今取り組んでいるところです。

__――チームで設定されているOKRやKPIはありますか？__

__松永__：「Ci-en」のエンジニアチームとしてはOKRを掲げておらず、事業部全体のOKRに対してアプローチする形をとっています。事業部のOKRでは、Objectivesに「クリエイターが実現したい世界をCi-enでなら叶えられる」というプロダクトのビジョンを掲げています。

Key Resultsに設定されているのは、「このジャンルで活動するならCi-en登録必須と呼ばれるジャンルをつくる」、「ファンを獲得し、クリエイター活動が続けられるサービスになる」、「Ci-enにしかない体験を提供し、新規ユーザーを獲得してクリエイターに還元する」の3つ。そして、この各Key Resultsに対して、それぞれKPIが設定される形になっています。

## 課題だったレビューの滞りを「Findy Team+」で可視化

__――現在チームでは、どのような開発手法をとられていますか？__

__松永__：もともとずっとウォーターフォールで開発していたのですが、ある時期に全社的にアジャイル開発をやっていこうという波がありました。そのときから、「Ci-en」のチームでもスプリントを設定して、2週間ごとにタスクの整理をしながら進めています。
ただ、厳密に決まったスプリントのなかでリリースするわけではなく、ウォーターフォールとアジャイルが混ざっているような形ですね。「Ci-en」のなかで締め切りなどの融通がきくため、必ずしもスピード感が大事ではない部分もあり、ウォーターフォールの名残も強いです。

__――開発生産性の計測に取り組み始めたきっかけを教えてください。__

__松永__：結果的に計測が始まった、という表現が正しいかなと思っています。「Findy Team+」を知ったのは、昨年の「Findy Team+ Award」の記事を見かけたことがきっかけでした。それを別のリーダーに共有した結果、気付いたら話が進んでいて、導入してみることになったという経緯があります。

それに加えて、私がリーダーになってから、レビューが滞りがちになっていることがチームのなかで課題になっていました。なので、その部分が数字として見えるのはいいなと思い、計測を始めました。

__――そうした課題に対して、計測を始める前に行っていたアプローチはありましたか？__

__松永__：計測前にしていたのは、レビューであまり細かいところまで指摘しすぎないようにすることと、レビューコメントにラベルをつけて、どういう意図の指摘かを明示することくらいでした。

__――計測を始めたタイミングで、どういったゴールを設定されていましたか？__

__松永__：ゴールについては、今も明確には決めていない状態です。数字が良くないことはわかっていて、できる限り改善していこうと半年ほど取り組んできましたが、社内の事情もあり、まだ数字が安定しているとは言えません。なので、もう少し期間を見て現実的な良い数字を把握し、それを維持することを目標にしようと今のところは考えています。

__――社内の他チームでも、開発生産性の可視化に取り組まれていますか？__

__松永__：他のチームでも、もともと開発生産性に興味があって自発的に取り組んでいるチームもあれば、「Ci-en」で成果が出始めたときに、それを共有したことがきっかけで導入を決めたチームもあります。取り組み方については、各々のチームリーダーが個別に設定して決めています。

__――取り組み事例の共有も積極的に行われているのでしょうか？__

__松永__：そうですね。一定のタイミングで部署ごとの発表や開発部内の共有会があるので、そういった場で取り組みの成果を共有しています。そのほかにも、「Findy Team+ Award」に選出されたことを、会社の週報に載せてもらうなどして広めていっています。
![松永様画像①](//downloads.ctfassets.net/ngrpflsbp3rq/5i8SSO1XXB3vNke7v9cYF9/bbd729cbce23bb41cc5cba021a5e61e6/_____________DSC07780_re.png)
## 取り組みにより、レビューへの意識がポジティブに変化

__――チームで見るべき数字として設定された指標や、その指標に決められた背景を教えてください。__

__松永__：レビューの時間に関するところが課題になっていたので、まず最初に変更行数を小さくすることを目標としました。それから、レビューからアプルーブまでの時間を短くすることと、プルリクのオープンからレビューまでの時間を短くすること。この3つを見るべき指標として設定しました。

これは「Findy Team+」のカスタマーサクセスの方に、レビューに時間がかかっている課題について相談した際に、どの指標から見ていくといいかアドバイスをいただき、それをもとに設定しています。

__――可視化していくことに対する、チームメンバーの反応はいかがでしたか？__

__松永__：変更行数を小さくしてプルリクが見やすくなったことや、数字として見えるようになったことで、レビューに対する積極性が出てきて、ポジティブな意識の変化があったと感じます。週次で行っている振り返りでも、数字が良くなっていれば喜び、悪くなっていればへこむという感じで、楽しみながらやれている面もあると思います。

__――生産性に関連する振り返りは、「Findy Team+」を導入する以前からされていましたか？__

__松永__：導入前は、まったくしていませんでした。これに関しても、カスタマーサクセスの方とのやり取りのなかで、他社での事例を教えていただいて、うちでもやってみようと始めた取り組みです。

__――振り返りで数字を見るようになって、難しかったことがあれば教えてください。__

__松永__：影響範囲が広いタスクが発生しているときに、どうしても時間がかかるプルリクがあり、それが如実に数字に出てしまうことがあります。それは仕方がないことなのですが、メンバーがその数字に慣れてしまうと良くないなという危機感はありますね。

一方で、該当するタスクをこなしているメンバーにとっては、数字を悪化させているとプレッシャーに感じてしまう可能性があるので、そこも気にする必要があると思っています。

__――そういった場合、メンバーの方にはどのようなフォローをされていますか？__

__松永__：振り返りの場では、そういう性質のものだということを、チーム全体に伝えています。加えて、各メンバーとの1on1でも、個人の責任だと思いすぎないように、頼れる部分は頼ってほしいと、いつも伝えるようにしています。

__――振り返りで数字が悪化している傾向が見られたとき、どういったコミュニケーションをされていますか？__

__松永__：該当のプルリクを見て、なぜ時間がかかっていたのか、曖昧にしないようにチームメンバー全員で認識を合わせるようにしています。もしそれが決済のような機能的に重要な部分であれば、時間がかかっても仕方ないものだと確認することもあります。

__――週次の振り返り以外でも、「Findy Team+」を見ているタイミングはありますか？__

__松永__：見たいとは思っているのですが、なかなか頻繁に細かいところまではチェックできていません。まだ見れていないページも多いので、今追っている3つの数字がある程度安定してきたら、もっといろいろなところを活用していきたいと思っています。

## 各メンバーが課題を意識し、自走できるチームを目指す

__――開発生産性を可視化することによって、どのようなベネフィットを感じられていますか？__

__松永__：やはりメンバーのレビューに対する姿勢が変化したところが、良かったと思うことの1つですね。それから、数字として見えるようになったことで、常に意識するようになったことも大きいと感じます。

私自身も、リーダー業務が忙しくてレビューを後回しにしがちなところがあったのですが、常に数字を意識するようになったので、それが改善につながっている部分が少なからずあるなと思います。

__――取り組みを進めるなかで、メンバーから上がった声があれば教えてください。__

__松永__：導入初期のころ、メンバーからは「小さいプルリクとはどれくらいなのか」といった声がありました。そこを具体的な数字にするのは難しいと思っているので、まずは各々が思う単位でやってもらうようにしました。

厳密に決めていないので、それほど負担にはなっていないだろうと思いつつ、逆に明確な目標がないからこそ難しいと感じる部分もあったかもしれません。

良い反応としては、やはり数字が目に見えて改善されていくことに対する達成感ですね。そういったところは、メンバーからも実際に良い声をもらっています。

![viviON_matunaga_Findy_Team+](//downloads.ctfassets.net/ngrpflsbp3rq/25YxeuDVQrZ02TDTnlgwm6/3021c62a3e08ae1824eaf10c51f5b77e/_________DSC07649_re.png)

__――レビューのリードタイムを改善していくにあたって、難しいと感じたポイントはありますか？__

__松永__：まずは、どうしても時間がかかるレビューが存在してしまうことですね。やはり決済関連などのコアな部分は、メンバーだけでなく、リーダーのレビューも通しておきたいと考えています。そのため、重要度が高い部分はレビューに時間が長くかかる状況が続いていて、ここをいかにメンバーで完結できるようにするかは、考えていきたいことの1つです。

また、数字だけを見ていると、すごく改善しているように見えても、実は障害対応でたくさんリリースしているだけだったというケースがあります。そういう数字だけでは見えない実態も、ちゃんと認識して取り組んでいかなければならないなと感じます。

あとは、プルリクを小さくして、複数のプルリクで一連の機能になるときに、小さくしすぎたがゆえにバグが発生してしまったこともありました。単体で見ると問題なさそうに見えたのに、つなげてみたら問題があったというケースで、そういったさじ加減も難しいなと思っています。

__――今後のトライについて、現在考えられていることがあれば教えてください。__

__松永__：今お話した課題に関連するところでは、障害対応にチームがかかりっきりになってしまうことがあったので、障害対応とは別にデリバリーラインを確保することを考えています。
また、プルリクを小さくしすぎることを防ぐ観点で、最近は設計段階で一度レビューを挟むように取り組み始めています。あとは、テストをちゃんと書くというところにも取り組んでいこうとしていますね。

__――取り組みを通じて、今後目指していきたいチームのイメージがあれば教えてください。__

__松永__：理想としては、各々のメンバーが課題を意識して自走できるようなチームになってほしいと思っています。「Findy Team+」を見て課題を特定し、その改善のためにどういった動きをしていくか、みんなから意見が出てくるようになったらいいですね。

私自身も開発生産性についてはあまりくわしくない状態から始めて、メンバーと近い目線で取り組んできました。あまりあれこれ押し付ける形にならないように進めてきたつもりなので、そこは今後も変わらずにやっていきたいと思っています。

__――それでは最後に、組織のアピールポイントや一緒に働きたいエンジニア像を教えてください。__

__松永__：エンジニアだからといって開発業務のみを行っているわけではなく、新機能や改善の提案、新しい取り組みへのチャレンジを全社として推奨しています。自身が担当するプロダクトでゼロからアイディアを出し、実装し、それを数百万人のユーザーに届けられるというのは、非常にやりがいのある仕事だと思います。

アイディアを形にしたい、新しい価値をユーザーに届けたい、とにかくオタク文化が大好き、そういった前向きなマインドを持ったエンジニアの方は、ぜひ一度採用ページを御覧ください！

__――松永さん、ありがとうございました！__

※viviONでは、エンジニアをはじめとした様々な職種を募集しています。
https://hrmos.co/pages/vivion/jobs

※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
https://findy-team.io/service_introduction

Team+Lab viviOn

総合二次元コンテンツサービスを展開する株式会社viviONでは、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。

ウォーターフォール開発から開発生産性向上へ取り組む。レビュータイムの可視化で自走チームを目指すviviONの開発組織

1200x628 モリサワ

デジタルフォントの開発・販売・ライセンス事業を中心に展開する、国内トップシェアのフォントベンダー、株式会社モリサワ。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。

プルリク数・デプロイ頻度をチーム目標に設定。DevOpsを推進するモリサワの開発生産性向上への取り組み

Saison Technology_fv

データ管理製品やITサービス、および金融や流通業をはじめとする多種多様な業種向けのシステム開発・運用をグローバルに展開する、株式会社セゾン情報システムズ。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。

パッケージ開発における開発生産性向上のデファクトスタンダードへ。セゾンテクノロジーのアジャイルシフトへの挑戦。

## 2つのスクラムチームで、社内向けのプロダクトを開発
__――まず最初に、お二人のご経歴や現在の役割を教えてください。__

__笹原__：ダイキン工業に新卒で入社し、現在5年目となります。役割は開発者兼スクラムマスターです。

__平松__：笹原と同期で、入社5年目になります。現在は、開発者兼スクラムマスターを担っております。

__――所属しているチームの規模や体制について教えていただけますか？__

__笹原__：私たちは、空調データを活用したEneFocus αというプロダクトの開発を行っています。開発は2つのスクラムチームで行っており、両チームそれぞれプロダクトオーナーが1人、スクラムマスターが1人、開発が4人という、6人チーム体制です。これに加えて、両チームを見るアジャイルコーチが1人います。

__平松__：各スクラムチーム間では課題や良かった取り組みを共有し合っています。

__――スクラムチームを立ち上げられたのは、どういった背景があったのでしょうか？__

__平松__：チーム内で課題の改善が中々進まなかったという背景があります。属人化により、担当者がいなくなったら誰もわからなくなる機能がいくつもある、といった状況をチームとして改善していきたいと考え、スクラムを始めました。

__――チームの特徴を教えていただけますか？__

__笹原__：チーム全員がプロダクト価値に本気で向き合っているという特徴があります。プロダクトオーナーだけでなく、開発者もプロダクト価値を高めることに対して強い意識を持っており、実際に、ステークホルダーと開発者が頻繁に会話したり、開発者からプロダクトの今後に関する意見が出たりすることも多くあります。

__――チームでそういった意識を持つために、どのような工夫をされたのでしょうか？__

__平松__：ステークホルダーと密に関わるようにする、スプリントゴールをプロダクト価値を意識・検査しやすいような文言に変えるなど、各チームで開発者がプロダクト価値にコミットしやすくなるような仕組みを整えていきました。
また、それらの施策を毎週のスクラムマスターどうしの相談会で共有し、別のチームの効果的な取り組みを即座に取り入れていきました。

__――両チームが開発しているプロダクトや、それによって実現しようとしていることを教えてください。__

__平松__：弊社には、空調機の運用方法について改善提案・運用するEneFocus αというサービスがあり、そのサービスを手助けするためのプロダクトを作っています。プロダクトを通じて、EneFocus αの契約数を増やしていくことを目的としています。

__――社内向けのプロダクトで、社内の方々がエンドユーザーということでしょうか。__

__平松__：はい、そうです。
![会話風 (1)](//images.ctfassets.net/ngrpflsbp3rq/3w12fzyVS678Y7W6rQyQfI/be8c8f094de252e77d42c8a839169474/_____1_.png)
## 「Findy Team+」の導入で、より具体的な議論＆改善へ
__――「Findy Team+」を導入いただいた背景や、開発生産性の計測に取り組む前にあった課題について教えてください。__

__笹原__：私たちのチームでは「Findy Team+」を導入する前からスクラムを始めており、ふりかえりを非常に大切にしてきました。しかし、ふりかえりで開発プロセスについて議論する際、どうしても感覚ベースでの話になってしまい、実際の改善につなげるのが難しいという状況がありました。

例えば、プルリクエストのレビュー依頼を出してから、しばらくレビューされなかった気がするとか。このチームって、どれくらいの速度でリリースできているんだろうとか。課題や疑問に感じたことが実際に起こっていることなのかわからない、といった話が何度か出てきていたのです。

そのため、定量的なメトリクスを可視化することで、確実なボトルネックを見つけやすくしたいという思いがあり、事実ベースで議論することにより、より具体的な改善につなげられることを期待して、「Findy Team+」を導入しました。

__――開発生産性の計測を通じて、どういったゴールを設定されていますか？__

__笹原__：結局、事業部門にいかに価値を出せたか、ということが真のゴールだと考えており、それはスクラムのプロダクトゴールとして設定しています。その価値を出すための大切な要素の1つに、ソフトウェアをいかに迅速かつ確実にデリバリーできるか、という点があると思います。開発生産性の計測は、実装した機能をいかに迅速かつ確実にデリバリーできているかを確認するために行っており、開発生産性の観点でのゴールはそこだと考えております。

__――「Findy Team+」の導入後、現場の皆さんの理解はすぐに得られましたか？__

__平松__：すぐには得られませんでした。単に「Four Keysの値を上げていこう」と提案するだけでは、なぜそれを上げなければならないかが伝わりません。他社での事例を伝えても、「自分たちのチーム状況とは違うのに、それを真似したところで本当に意味があるのか？」など、スムーズに理解を得られない部分も多くありました。

__――そういったところは、どのようなアプローチで解決していきましたか？__

__平松__：Four Keysの値を見てというよりは、実際の開発プロセスで起きていることをベースに改善していきました。

例えば、メインブランチのマージが大きくなってしまい、それが理由で修正に大量の時間がかかってしまうことが何度かありました。これはデプロイ頻度を上げて、変更差分を小さくすることによって解決でき、チームとしてメリットを実体験として感じることができました。

このようにチームの課題を解決した結果としてFour Keysの値が上がっていく、という流れに持っていけたことが良かったと思います。
![会話風笑顔 (1)](//images.ctfassets.net/ngrpflsbp3rq/F1d6zRQUfdbcZ0g1lVRN7/02f2183ab564c908e6e28e9f255118c4/_______1_.png)
## 特に注目するのは、デプロイ頻度と変更のリードタイム
__――現在、「Findy Team+」をどういった形で活用いただいていますか？__

__笹原__：毎週のチームのふりかえりで、「Findy Team+」を使って指標を確認しています。具体的には、まずFour Keysの確認をして、現状の共有をします。Four Keysのなかでも、特にデプロイ頻度と変更のリードタイムに注目して、それぞれの増減の原因を見るようにしています。

デプロイ頻度に関してはプルリクエストの数、変更のリードタイムに関してはサイクルタイムを参照し、さらにそこから詳細なプルリクエストまで追っていくようにしています。Four Keysの目標としては「Elite」ランクで、デプロイ頻度が2件、変更のリードタイムが24時間以内を目指しています。

__――プルリクエストの作成数にも、具体的な目標を設定されていますか？__

__笹原__：設定しています。最初はFour Keysの目標だけを設定していたのですが、開発メンバーにとってはイメージが湧きづらかったようでした。デプロイ頻度2件と言われても、実際に1日1人当たりどれくらいのプルリクエストを作ったらいいのかわからないという声が、ふりかえりであがっていました。

そこで、目標のデプロイ頻度と現状のプルリクエストの粒度から逆算して、現在は1日1人あたり3プルリクエスト作成するという目標を立てています。

__――デプロイ頻度とリードタイム以外に、例えば変更障害率や平均修復時間などにも目標を設定されていますか？__

__笹原__：もちろん安定性に関する指標にも目標を設定しております。ただし、変更障害率と平均修復時間に関してはすでに目標を達成できているので、現在は達成できていないスピードに関する指標に注目しています。

__平松__：変更障害率と平均修復時間は現在「Elite」の状態ではあるのですが、スピードを上げることによって下がらないかは見ています。速度と安定性は、どちらかを上げてどちらかが下がってしまうと意味がないので、意識するようにしています。

__――そのほかにも、Four Keysを向上するために注目している観点はありますか？__

__平松__：私のチームでは、デプロイ頻度が低いことが課題になっています。今の開発方法では、プルリクエスト数を増やすだけではデプロイ頻度は向上しないと考え、1日でデプロイできる単位をより細かく分けていくことに意識して取り組んでいます。

これまでは機能としてまとまった単位でデプロイしていたのですが、さらに分割してデプロイできないかをチームで話し合うようにしました。

例えば、クラスが複数あった場合に、それらが全て完成しないとデプロイできないのか、といったことを突き詰めていくイメージです。
## デプロイ頻度は、「Findy Team+」導入時から2倍以上に
__――「Findy Team+」の活用を通じて、改善された結果について教えてください。__

__笹原__：プルリクエストの作成数が上がりました。その一方で、スクラムにおけるベロシティは変わっていないので、プルリクエストをより細分化できていると思います。それがFour Keysの値や、レビュー精度の向上にもつながっています。

__――実際に「Findy Team+」上で、直近半年の1人当たりのプルリクエスト作成数（棒グラフ）を見てみると、導入時は1人当たり約1件だったのが、最近では1.8件～1.9件と継続的に向上できていることがわかります。__
![ダイキン インタビュー内画像 アクティブメンバーサマリ](//images.ctfassets.net/ngrpflsbp3rq/5WrfBw8glXH421Xv3ABcIK/826a8e4f96035511b50222b01d2b4f8e/_______________________________.png)

__――続いてデプロイ頻度を見ると、導入時は1日当たり0.6件ほどでしたが、直近では2件を超え、3倍以上のデプロイ頻度が実現できています。ここまでにお話いただいた以外にも、デプロイ頻度が上がった理由として考えられる要素はありますか？__
![ダイキン＿インタビュー内画像 デプロイ頻度(移動平均推移)](//images.ctfassets.net/ngrpflsbp3rq/Cm6DpD6nNNYLLOjh5tJ33/f5302aee8ac96998408faf534f4c3c0d/_________________________________.png)

__平松__：開発チームでデプロイ権限を持てるようにユーザーと交渉したことが大きな要因だったと思います。以前までは、2週間に1回のスプリントレビュー後に機能をまとめてデプロイするルールとなっており、それ以上はデプロイ頻度が上がらないという状況でした。

__――ユーザーとの交渉はスムーズに進みましたか？__

__平松__：このルールだと何が良くないのかを明確に説明できたので、特に苦戦はしませんでした。

2週間かけて作った機能すべてがデプロイされ、そこで初めてバグに気づいた場合、手戻りは大きく、修正には大量の時間がかかってしまいます。しかし、より早い段階でデプロイできれば、その時点でのフィードバックを得ることができ、進路変更を早期に行えます。その結果、全体のリードタイムが大きく短縮されるということを伝えました。
## 今後のトライは、可視化する文化を社内で広げていくこと
__――開発生産性向上のための取り組みのなかで、難しかったことはありましたか？__

__平松__：デプロイ頻度が上がらない要因に中々気づけなかった点です。開発者個人の能力に目が向きがちになってしまい、開発プロセスやデプロイ方法といった本質的な問題にフォーカスできるようになるまでに時間がかかりました。

__――どういったきっかけで、開発プロセスやデプロイ方法に目線を合わせられたのでしょうか？__

__平松__：スクラムマスターとして、開発者の頑張りを間近で見ていた一方で、チームのデプロイ頻度が0.6件である事実を目の当たりにした時に、個人の能力の問題ではないと推測しました。
その後、チームでふりかえりをしたことで、根本的な開発プロセスやデプロイ方法に目を向けることができました。

__――今後さらにトライしていきたいと考えていることがあれば教えてください。__

__笹原__：現状、FindyTeam+を利用する前提となる文化が社内に浸透していません。まずは「実装した機能を迅速かつ確実にデリバリーできているかを計測して可視化する」というDevOpsの文化そのものを、社内で広めていくことにトライしていきたいです。

__――そのために今必要だと感じることや、ハードルになっていることはありますか？__

__笹原__：内製化しているチームが少ないという構造的なハードルと、DevOpsやアジャイルの考え方が根付いていないというマインドセットのハードルがあります。前者に関しては、すぐに変えることは難しいので、現在は後者のマインドセットの転換に取り組んでおります。具体的には、社内コミュニティを立ち上げ、毎週1時間、チーム開発で得た知見や文化を共有・議論するイベントを開催しております。

__――最後に、御社のアピールポイントがありましたらお願いします。__

__平松__：開発チームができたのは3年ほど前なのですが、ソフトウェア開発をしたことがないメンバーの集まりで、試行錯誤しながらスクラム体制をつくってきました。自分たちで考えたり調べたりして、今の体制をつくり上げてきたという自負があります。

__笹原__：自由度がとても高く、自律性を感じられる環境です。マイクロマネジメントされるようなことはなく、意思決定がチームに委ねられており、働きやすい環境が整っています。

__平松__：ダイキンはデジタル分野に関わる重要テーマを推進する人材を募集しております。技術の力で組織を変えたいエンジニアやマネージャーの方には、ぜひ応募の検討をしてほしいと思っております。

__――笹原さん、平松さん、ありがとうございました！__
![写真受付前 (1)](//images.ctfassets.net/ngrpflsbp3rq/3ZDISZsr9pkRnVtWCZi95F/183b3e3b1d5ab7a8423c9a9201493656/_______1_.png)

※ダイキン工業の採用ページでは技術の力で組織を変えたいエンジニアを募集しています。
https://www.daikin.co.jp/recruit

※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
https://findy-team.io/service_introduction

1200 630 daikin (1)

世界170ヵ国以上で事業を展開するグローバル空調総合メーカー、ダイキン工業株式会社。その中でもR&Dの最前線であるテクノロジーイノベーションセンター（TIC）において、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。

プロダクト価値を最大化するスクラムチームの組織づくりに迫る。Four Keys向上を目指すダイキン工業の取り組み

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渡邉様と赤川様にインタビューさせていただきました

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