## 2022年1月、海外の開発拠点としてベトナムに法人を設立
__――まず最初に、お二人のこれまでの簡単な経歴と現在の役割を教えてください。__

__野田__：現在、アンドパッドベトナム代表を務めています。以前は、アンドパッドの営業部や社長室、新規プロジェクトの立ち上げなどに携わっていました。昨年1月ベトナムに法人ができ、そのタイミングからベトナムに赴任しています。

__山下__：僕は2016年からアンドパッドにジョインし、モバイルアプリの開発をはじめとして、バックエンドやフロントエンドなど、ひと通りの開発をしてきました。そして、昨年ベトナム拠点の立ち上げが始まってからは、その開発組織作り、ベトナム拠点とのプロダクト開発まわりに携わっています。

当初、ベトナム拠点にまだあまり人がいなかったころは、自分自身も一緒に開発しながら、チームをつくっていました。少しずつ開発から手を離していって、マネジメント寄りの立場になり、現在はアンドパッドベトナムのCTOをしています。

__――現在のアンドパッドベトナムの体制を教えてください。__

__野田__：立ち上げから1年以上が経ち、複数のプロダクト開発が同時進行で進んでいます。
チームの分け方としては、プロジェクトごとの軸が1つ。それから、QC/QAやモバイル、バックエンド、フロントエンドといった機能ごとの軸があります。横と縦の軸があるイメージですね。

__――ホーチミンにオフィスがあるそうですが、出社に関するルールはどのようにされていますか？__

__野田__：今はハイブリッドな体制をとっています。毎日出社しているメンバーもいれば、週に1回、月に1回のメンバーもいます。特に、必ず出社する日を決めたりもしていません。直接のコミュニケーションを好むところもあると感じており、金曜日はエンジニアの出社が多い印象があります。

__――オフショア拠点にもいろいろな候補があると思いますが、なぜベトナムでの立ち上げを選んだのでしょうか？__

__野田__：開発拠点立ち上げという観点だけであれば様々な候補があったと思いますが、建設業とのシナジーという観点も含めベトナムに決定しました。建築・建設業界には、BIM（Building Information Modeling）と呼ばれるモデリング手法があります。簡単に言うと、建物をコンピューター上で、形状や属性を持たせる形で3次元で表現することができます。設計時、施工時、完成後などの建物のライフサイクルにあった形で活用することが可能になります。

このBIMは、アメリカやシンガポール、カナダ、イギリスなど、世界で多く導入されていて、BIMモデリング作成のオフショア先としてベトナムが活用されています。アンドパッドとしては、日本でもBIMがもっと広がる支援ができればと考えていて、BIMを現場で活用できるプロダクトもリリースしています。なので、そういったビジネス的な観点が背景にあります。

__山下__：結果論ではありますが、ベトナムの人たちは日本人と感覚が近い印象がありますね。オフショアであまり良くない経験を持っている人の話も聞くので、やる前は漠然とした不安があったのですが、実際にやってみると、文化的にも性格的にも真面目な人が多い印象です。それほど日本人と変わらないなという感じがあって、そのあたりのギャップの少なさが良いなと思います。

__――立ち上げ時のチームづくりにおいて、難しかった部分があれば教えてください。__

__山下__：自分も一緒にプロジェクトに入りながら進めていたので、初期段階からチームメンバーの能力などもよく見えていました。なので、日本人と一緒にやっているのとあまり変わらなかったですね。

ただ、面接の段階で正確にジャッジするのは難しく、なかにはマッチしなかったり、スキルが見極められなかったりするケースもあり、そこは大変でした。これに関しては、今でも難しい部分かもしれません。
![202309 ベトナム 山下さん-1091](//images.ctfassets.net/ngrpflsbp3rq/E0G0SI85HmH8UwIeOjnLJ/0ac061092ce0cf7b49051af7ba83b236/202309___________-1091.jpg)
## 定量面では、チームのプルリクエスト数とレビュー数をチェック
__――続いて、ベトナムチームのミッションについてお聞きしたいと思います。__

__山下__：建築・建設業界にプロダクトで貢献するという根底の部分は、日本もベトナムも違いはありません。ただ、拠点を立ち上げるからには、日本の拠点よりもアウトプットが出ている状況に持っていきたい。なので、ベトナムのメンバーには、日本の拠点を超えようという熱量を持ってもらいたいと考えています。

__――進め方としては、ベトナムのみで作るプロダクトがあるのでしょうか。それとも、日本で作っているプロダクトの一部機能をベトナムで作っているのでしょうか？__

__山下__：両方あります。ベトナムだけで進めるプロジェクトもいくつかありますし、日本とハイブリッドで進めることにもトライしています。ただ、やはりハイブリッドにするとコミュニケーションコストがかかるので、その点で負荷が高くなりやすいですね。

__――ブリッジSEの方がいらっしゃるとのことでしたが、それでもやはり一定の負荷はあると。__

__山下__：そうですね。ドキュメントは基本的に日本語なので、伝言ゲームになってしまって、上手く伝わっていないとか、伝わっていないように感じるとか、そういったところはお互いにあるように感じます。

ただ、一部のプロジェクトでは、ベトナムと日本のエンジニア同士が直接英語で会話したり、日本のPMの方が英語で直接伝えることにトライしていたりと、いろいろな工夫もされています。

__――チームのKPIとして追っているものがあれば教えてください。__

__山下__：定量的には、プルリクエストの数やレビューの数を追っています。昨年、チームで上手くタスクが振られておらず、待ちの状態が生まれてしまっていた時期があったので、最初はそうした状況をなくす目的で見始めました。それ以降も毎月動きを追って、明らかにプルリクエスト数やレビュー数が減っていたら、ヒアリングするようにしています。

逆に、すごく頑張ってくれているメンバーもいるので、そういうアウトプットを出しているメンバーを称賛することにも活かしています。ただ、定量的な部分を追っていると、質より量が大事だと思ってしまう人が、一定数出てくるところが難しいですね。

もちろん質も量も両方大事なのですが、質の部分は定量的に追いにくい。定性的な部分については、まわりの人から評価をもらうようにしたり、もともとプルリクエストの粒度も大きかったので、どのようなプルリクエストだと質が高いのかを共有したりして、現時点ではバランスを取っています。

## チームの根底にある、日本側の開発に対するリスペクト
__――生産性を可視化して、プルリクエストの粒度を小さくしていくような考え方について、ベトナムのエンジニアの方々はどのように捉えていますか？__

__山下__：最初は伝えても、意味がわからないという顔をしていましたね（笑）。ベトナムでは、大きなフィーチャーブランチを作って、言われた機能をマージして完了というケースが多いようです。レビューしやすいようにプルリクエストを分ける文化もないので、ほとんどのメンバーが他の会社で経験してきていません。

ですが、やってもらうように伝えれば、徐々に浸透していきます。彼らも日本側での開発に関する情報をインプットしていて、優れている点を全力で吸収しようとしてくれている部分もあると思いますね。なので、日本側がしっかり開発していることも大事な要素です。

__野田__：それはすごく大きいですね。ベトナム拠点に携わっていると、みんな日本のメンバーが作るソースコードを見て、リスペクトを持っていることを感じます。

__山下__：リスペクトできる部分が日本側にあるから、「こうやったらもっと良くなる」というところを学んでくれています。

__――さまざまなハードルから、海外での開発拠点の立ち上げに踏み出せない企業も多いと思いますが、実際に取り組まれてみてどう感じていますか？__

__山下__：ひたすら採用してプロジェクトに放り込んでいくようなやり方では、失敗しそうだなと思います。一緒にやりながら、ちゃんとレベル感が上がってきたかを確認しつつ、人を入れていくことができれば、それほど難しいことではないように感じます。

__――日本側とのコミュニケーションに、「Findy Team+」を活用されている場面があれば教えてください。__

__野田__：アウトプットの総量という観点で、1人当たりのプルリクエスト数とレビュー数を「Findy Team+」の詳細比較で、アンドパッド全体とベトナム全体を並べて見ています。直近半年でいうと、ベトナムの方が数字が出ている状況ですね。

この図 1 と 図 2 を、月1の会議で見せています。会議にはCEOの稲田、CFOの荻野、山下、私の4人が出席していて、アウトプットや経営に関してなどさまざまな話が上がりますが、そのなかの1つの項目として扱っています。

![アンドパッドベトナム インタビュー記事内画像](//images.ctfassets.net/ngrpflsbp3rq/3vYIYL47EDC91R3bI3Y19b/f99cb421f985d02449879b986ce2bb96/image4.png)

　　　　　図 1 アンドパッド全体        　　　　      図 2 ベトナム全体
## 「Findy Team+」の活用を始め、プルリクエスト数は約3倍に
__――開発生産性の可視化に関して、「Findy Team+」を導入する前は別の方法で見られていましたか？__

__山下__：GitHubのAPIは使っていましたが、使いにくくてだんだん使わなくなりました。自分はツールがなくても、ワークしているかどうかプルリクエストを見にいくこともできるのですが、全体を通して見るにはツールで数値化された方がわかりやすいなと思います。

__――「Findy Team+」は、ベトナム拠点に行く前からお使いいただいていましたか？__

__山下__：日本側でもたまに見ていましたが、本格的に使い始めたのは、ベトナム拠点の立ち上げからですね。ベトナムでは当初から、「Findy Team+」で数字を見ているということを、メンバーに対して伝えていたことも大きいです。

__――計測のゴールとしては、チームが継続的に開発できているかを見ていただいているイメージでしょうか？__

__山下__：そうですね。やはり文化や言葉が違うので、数字以外で伝えようとするとミスコミュニケーションが生まれる可能性が高くなります。実際には、ベトナムのメンバーとそういったミスコミュニケーションが起きたことはあまりないですが、毎月改善されているかどうかを数字で議論できた方が、お互いにとって良いと考えています。

あまり細かく比較しすぎるのも良くないですが、例えば月のプルリクエスト数が1～2だったら、何か起こっているだろうなとわかります。状況によっては、調査系のタスクが多いケースもあるので、見方が難しいところもあるのですが。

合わせて、日本チームへのヒアリングも月1で実施して、定性的な状況を聞くようにしています。なので、定量と定性の両方で、例えば日本側から動きが良くないと評価を受けていて、かつ数字も出ていないとなれば、対応が必要だと判断できるような形になっています。

__――計測することに対するネガティブな反応はありましたか？__

__山下__：人によっては、多少あるかもしれないですね。量と質の問題で、計測するとどうしても量の話が多くなります。なので、量ばかりを見ていると、焦ってプルリクエストを作るから質が悪くなるのではないか、といった意見が出ることもあります。

でも、わかりやすいから量のことを言っているだけで、質も量も両方見ていると都度説明していて、それが理解してもらえないということはないですね。量に意識が傾いてきたときに、質についての意見が出てくることは、考えとしてずれていないので、むしろいいことだと思います。

__――「Findy Team+」でベトナムの数字を見てみると、リードタイム（折れ線グラフ）が延びることなく、2022年夏ごろと比べてプルリクエスト数（棒グラフ）が約3倍に増えていることがわかります。__
![アンドパッドベトナム インタビュー記事内画像②](//images.ctfassets.net/ngrpflsbp3rq/5KtizWr1KFRNEXILt7tIab/4607c0ff89a0b5b6b468659122343b11/____________________________.png)
図 3 プルリクエスト数とマージまでのリードタイム

__山下__：年明けくらいから数字を見ていることを伝え始めたので、そのあたりから動き的に変わった部分がありますね。リーダーがベストプラクティスをつくってくれて、例えば大きすぎるプルリクエストはレビューしやすいように分けようとか。そういった形で、ベトナムのメンバーが自主的に改善に向けて動いてくれました。

それから、プルリクエスト数が少なすぎると、動きが見えにくくなってしまうので、1日1個くらい作ってほしいと伝えています。例えば月に4個だと、週に1回くらいしか接点がなくなってしまい、チーム開発がしにくくなるためです。

__――山下さんがよく見られている「Findy Team+」のページがあれば教えてください。__

__山下__：チームコンディション（図 4 ）をよく見ています。特に今はインドの新卒メンバーもトレーニングで入れているので、このページでベトナムチームにインドのメンバーを加えた内容を見ています。

![アンドパッドベトナム インタビュー記事内画像③](//images.ctfassets.net/ngrpflsbp3rq/72WsE3qDK3dKevttrcwab4/cb410e66ca4d6fa177e0c7095d7a8ce3/____________________________.jpeg)
図 4 チーム内のアクティビティ

## 文化的な背景によらず、数字で齟齬なく伝えられることがメリット
__――開発生産性を計測することによるベネフィットは、どういった部分で感じられていますか？__

__山下__：やはり文化的な背景に影響されず、数字で伝えられるところが一番じゃないでしょうか。グローバルだと、定性的なコミュニケーションは受け取り方がそれぞれに変わってしまいますが、数字はわかりやすく伝わるので、そこがすごく大きいと思います。

__――開発生産性の可視化による、メンバーの意識や行動の変化はいかがですか？__

__山下__：可視化によって、チームメンバーそれぞれが周りを意識して活動するようになったと思います。特にプルリクエスト数は、手を動かさないと出ないものなので。アウトプットを意識するという感覚が生まれたことは、チームに影響を与えたと思います。

__――可視化にあたって、ツールにコストがかかる部分もありますが、そのあたりはいかがでしたか？__

__山下__：「Findy Team+」は、それほど学習コストがかかるようなツールではないので、そういったところは特に問題ないですね。

__野田__：むしろ、逆に「Findy Team+」がなかったら、大きなコストがかかっていたかもしれません。社内でたくさんのヒアリングが必要だったり、説明のためにあれこれ文章を作らなければならなかったり、そういうことが起きていたかもしれないなと思います。
![202309 ベトナム 野田さん-1120](//images.ctfassets.net/ngrpflsbp3rq/2CXqpchRQ9IAI7pgACMlZJ/98085cd0875a9ee50f56a9129e855d53/202309___________-1120.jpg)

__――今後の取り組みとして、可視化していきたい部分などはありますか？__

__山下__：Four Keysは、取り組もうとしたことがあるのですが、なかなか数字を集めていくのが大変で、今のところできていません。理想としては、Four Keysで言われているような内容が、全部取れた方がいいのかなとはっ

品質面の可視化も、できればやりたいですね。デプロイして障害がどれくらい発生したかなど、数値化できたら質が測れると思うので、やっていきたいとは考えています。

__――野田さん、山下さん、ありがとうございました！__

※アンドパッドでは横断的に開発効率を上げるエンジニアも募集しています。
[エンジニア採用サイト | アンドパッド](https://engineer.andpad.co.jp/)

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

1200x628 アンドパッドベトナム

クラウド型の建設プロジェクト管理サービス「ANDPAD」を提供する、株式会社アンドパッドの初の海外開発拠点アンドパッドベトナム。 エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」をご活用いただいています。

海外拠点でプルリクエスト数が3倍に。アンドパッドベトナムの定量×定性コミュニケーションを通じた開発生産性向上へのトライ

SAISON 1200x630 10031

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

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

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

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

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

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

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

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