## レビュー滞留による停滞感、結果指標のなさが課題に
__――まず最初に、お二人の主なご経歴や現在の業務について教えてください。__

__松山__：2014年に新卒で株式会社リクルートに入社し、ずっとソフトウェアエンジニアとして働いてきました。2019年11月にmentoに入社し、CTOをしています。ロール的には、経営とエンジニアリングのマネージャーですが、チームが小さいのでコードも書いています。

割合としては、経営を2割、マネジメントを4割くらいやりつつ、残りの4割はコードを書いているようなイメージですね。あとは、コーポレートのエンジニアリングのところも、僕が見ています。

__吉谷__：2017年に新卒で株式会社FiNC Technologiesに入り、3年前にmentoに入社しました。エンジニアとして、スクラムチームのなかでコードを書きつつ、より生産的に活動できるようにチームを改善していくところを主に担っています。

__――開発組織の規模や体制、掲げているミッションについて教えていただけますか？__

__松山__：全社の組織規模としては今、正社員が17人。シリーズBの資金調達に向けて動いているところで、ラウンドでいうとシリーズAなので、まだまだアーリーステージのスタートアップです。

開発組織の体制は小さく、正社員は僕と吉谷の2人のみ。プロダクトチームとしては、業務委託で複数名に手伝っていただいている状況で、デザイナーやPdM、データサイエンティストがおり、スクラムチームとしては7人くらいです。

開発組織のミッションは、「Findy Team+」を使って開発のリードタイムを追っていくことと、もう1つは採用ですね。組織で内定承諾の数を採用KPIとして持っているので、今はその2つを組織のミッションとしています。

![mento_intereview_2024/04/11_h2-1-1](//images.ctfassets.net/ngrpflsbp3rq/2W28atyS7JeDsS9KNK9YFZ/35b889985c118d84c8a159605080787e/unnamed__4_.jpg)

__――「Findy Team+」を導入する前、どのような課題がありましたか？__

__吉谷__：いくつかありましたが、まず1つはチームの形に関する課題です。もともとはスモールチームに、エンジニアやプロダクトマネージャー、Biz側のメンバーもいる構成になっていました。

そのとき、エンジニアのケイパビリティが上手く活きないという課題感があり、それに対してプレッシャーを感じてしまうメンバーもいました。そのため、最終的にはエンジニアチームをつくり、エンジニアリングにフォーカスするという意思決定をしています。

もう1つの課題は、レビューの滞留。レビューする人が属人化してしまっていたり、業務委託の方のプルリクはどうしてもリードタイムがかかってしまったりなど、いくつかの原因からレビューが溜まっていました。それによって、なんとなくの停滞感や上手くいっていない感覚がありました。

__松山__：レビューの課題に関しては、さらに言うと結果指標がなかったんです。レビューが溜まっていることによって、我々の何が良くない状況になっているのかがわからない。どこか気持ち悪いという感覚はあるけれど、どこにどんな不具合が起きているのか共通認識を持てない、というのが大きな課題の1つでした。

__――「Findy Team+」を導入いただいた背景やきっかけについて教えてください。__

__松山__：経緯としては、最初に組織変革の話があり、エンジニアチームを切り出すにあたって、エンジニアチームのKRをどうするか考えていました。アウトプット偏重になりすぎて顧客価値に繋がらないプロダクトを作ってしまうチームにしたくないので、アウトカムの目標を置きたかったのですが、チームを切り出したばかりの状況でいきなりアウトカムまで追おうとすると、チームとして動きづらくなってしまいます。

なので、まずはアウトプットの目標を置こうと考え、そこでグローバルスタンダードな指標であるFour Keysをベースにしようと思ったんですね。ただ、Four Keysを自分たちで可視化するのは大変だと思い、調べてみたところ「Findy Team+」のことを知りました。さらに、イベントでブースが出ていて、実際に「Findy Team+」のデモを見られたので、その次の日に問い合わせました。

![mento_intereview_2024/04/11_h2-1-2](//images.ctfassets.net/ngrpflsbp3rq/1BLgqUluVH5RIwEOXtj2hy/95dcc10c2a921154669fa81f70dbbeaa/DSC03770__1_.jpg)

## 定義の議論に時間をかけずに済むことがメリットの1つ
__――「Findy Team+」を導入する前、開発生産性の計測に関する取り組みはされていましたか？__

__松山__：していなかったです。基本的には「これくらいのものは、これくらいの期間でつくりたいよね」という何となくの合意があって、それをスクラムのイテレーションのなかでやっていました。振り返りで「もうちょっと上手くできたかも」といった話はあったものの、振り返りの頻度もそれほど高くなく、あまり機能はしていませんでした。

__――「Findy Team+」の導入について、どのようにして社内の理解を得ていきましたか？__

__松山__：導入については僕が決める立場にあるので、社長を説得したといったエピソードなどは特にありません。ただ、自分たちでFour Keysを計測するプログラムを書く選択肢もあったなかで、「Findy Team+」を導入することにしたのには理由があります。

KRを決めるとき、そのKRの定義の細かいところを議論したりするじゃないですか。例えば、Four Keysの変更までのリードタイムとは、どこからどこまでなのかとか。でも、その定義を議論している時間は何も価値を生み出していないので、無駄だと思っているんですよ。定義は何でもいいからひとまず決めて、コードを書いていきたいわけです。

「Findy Team+」の場合は、「この項目はこう取っています」と決まっていますよね。なので、まずはそれに全部乗っかって、その数値を良くしていこうと。その改善活動のなかで、指標がイケてないなとか、僕らのプロセスならこういう定義の方がいいなとか、そういうものが出てきたら後から変えていけばいいと考えました。

そうした定義の議論に時間をかけなくて済むところが、「Findy Team+」の良かったポイントの1つ。なので、社内でもその指標に沿ってやっていくことを伝えて、スムーズに導入が進みました。

![mento_intereview_2024/04/11_h2-2-1](//images.ctfassets.net/ngrpflsbp3rq/2lz1Dz3ke9fFifzRx8AWAr/9197ca2532ae56f0b0e0ae21fa5bff38/DSC03942__1_.jpg)

__――導入後に取り組みを進めていくなかで、難しかったポイントはありましたか？__

__吉谷__：「Findy Team+」で見られる指標はたくさんあるので、どの指標をどう見ていけばいいのかという部分が難しかったです。そうしたなか、カスタマーサクセスの方とのミーティングで、「まずはリードタイムから見ていきましょう」とお話いただけたので、そこにフォーカスしていくことができました。

特にリードタイムのなかでも、レビューからアプルーブまで、アプルーブからマージまでを良くしていくといった話ができたことは、すごく良かったと思っています。そこまで決まれば、あとは改善していくだけなので、そこからはスムーズに進んでいきました。

ただ、まだ「Findy Team+」をみんなが主体的に見る状態にはできておらず、僕や松山さんが見てシェアしている状況です。「Findy Team+」はすごく綺麗に可視化されていますし、深堀りがいがあるデータもたくさんあると思うのですが、そこはまだ僕も含めて触りきれていない印象がありますね。

## 週2回のレビュー会を設け、全員のレビュー優先度をアップ
__――レビューの課題については、どのように改善を進めていきましたか？__

__吉谷__：レビューに関しては、特に僕に属人化しているところがあったので、みんなでレビューしていくことと、レビューを優先的にすることをチームで合意しました。具体的には、火曜と木曜に1時間ずつレビュー会を設けて、そこでエンジニア全員でレビューする時間を取っています。

レビュー依頼が来たらすぐにレビューをするのが理想ではあるのですが、コンテキストスイッチもあるので、レビューするタイミングをつくって、レビューが溜まっていたら対応するという意識をつけていきました。

![mento_intereview_2024/04/11_h2-3-3](//images.ctfassets.net/ngrpflsbp3rq/5vwpGgdrmtrcIzxwVX6zRw/0890d11f8b85b3ec5c70718f2c693eb2/unnamed.jpg)
__――レビュー会を設けることに対して、ネガティブな反応などはありませんでしたか？__

__吉谷__：レビュー会を設ける前のことを思い出すと、そこに時間をかけていいのかという不安があったように思いますね。コードを書く方が生産的な感じがして、その時間を使ってどうなるのか、あまりイメージがつかないというか。

__松山__：効率が悪いのではないかという漠然とした不安があるんですよね。それは効率をどう捉えているかだと思っていて、おそらく多くの人が、エンジニアみんなが100%の稼働でコードを書いてるのが効率の良い状態だと思い込んでいるんだと思うんですよ。

それはエンジニアを1つのリソースと捉えたときの効率としては正しくても、ものをデリバリーしていくことを考えたとき、みんながコード書いてるとレビューでスタックしてしまって、デリバリー効率としてはあまり良くなっていないんですよね。

一人ひとりの効率が多少落ちても、レビューしたりQAしたりした方が、世の中に出ていくスピードは上がる。そういう話は、理論的には理解できても、本当に正しいのかという不安がついてまわります。でも、結果指標が可視化されていると、自分たちがやっていることが間違いではなかったとわかるので、そこで自信につながる部分があると思います。

__吉谷__：加えて言うと、僕自身もリソース効率が100％になっていない状態への不安は、まだあります。例えばレビュー会で1時間取って、エンジニア4人でやっていた場合、僕がレビューを3人に分配するんですよ。

そうすると上手くパスできないタイミングがあって、フロントエンドエンジニアの人は今レビューするものがないけど、10分後から動作確認タイムになる、みたいなことが起こるんですね。そうすると、その10分間はどうしても暇になってしまいます。

そういう何かが止まっている時間ができてしまうことが怖くて、もしこれが10人になったら、何もしない時間が結構あるだろうなと。なので、そういう怖さを認識しつつ、何もない時間には他のことをやっていく必要があるのかなと思っています。

## 今後はデリバリー効率の改善やデリバリー品質の計測へ

__――開発生産性を計測することによるベネフィットをどのようなところに感じていますか？__

__吉谷__：やはり目標に数字が置けることと、それが改善しているかどうかが見えることですね。最初の1ヶ月はあまり変わらなかったのですが、それは溜まっていたプルリクを消化するタイミングだからという共通認識がありました。溜まっていたプルリクが消化できてからは早くなっていって、それが可視化できたので良かったです。

実際に導入初期の2023年11月ではサイクルタイムの合計値は94.8時間でしたが、2024年4月には26.1時間と約1/3以下の数値に改善してきています。

![mento_intereview_2024/04/11_h2-4-1 ](//images.ctfassets.net/ngrpflsbp3rq/3PWM7EXxU7h69e9Yyed7hS/adcebf0635cdcf1a429816e7e60be050/__________2024-04-23_16.02.51.png)

![mento_intereview_2024/04/23_h2-4-2](//images.ctfassets.net/ngrpflsbp3rq/4Iz0LdYUfXW61X1OAB1dfn/eb45a62bc83a7cce1baa3a9184b2493d/__________2024-04-23_15.43.20.png)

__――メンバーの方々の意識や行動の変化を感じた部分はありますか？__

__吉谷__：エンジニアのなかで、レビューを最優先にするという意識づけができました。最近は、OKRにプルリクのリードタイムではなく、JIRAのリードタイムを置いています。なので、エンジニアだけでなくプロダクトマネージャーなども同じように、タスクをなるべく滞留させず、早めにDONEするという意識がついています。

プルリクもそうですが、チケットを細かく分割していくところも、意識や行動の変化の1つですね。小さくチケットを切って、小さくリリースすることが意識的になってきたと思います。

基本的にダークローンチというか、ユーザーに影響がない範囲でどんどん出していくことによって、リリースの頻度も上がりますし、一つひとつのプルリクも小さくなります。「Findy Team+」でも見れていますが、変更行数もどんどん小さくなっていて、レビューに時間かかることが減ってきました。そういったところは良い変化だと思っています。

![mento_intereview_2024/04/11_h2-4-2](//images.ctfassets.net/ngrpflsbp3rq/4LHJuYjQX9hPRc8HBS9cfb/7765be4533ab0348f8dc448930f60d78/unnamed__5_.jpg)

__――プルリクを小さくすることについては、特に声掛けをせずとも自然とそうなっていったのでしょうか？__

__吉谷__：そうですね。自然となっていった気がします。どうしてもレビューの頻度が少なくてリードタイムが伸びると、そこにどんどん変更が足されてプルリクが大きくなってしまいます。ですが、少なくとも週に2回のレビュー会がありますし、その前にもレビューされるので、プルリクが大きくなりにくくなったと思います。

__――開発生産性の計測について、今後のトライとして考えていることを教えてください。__

__吉谷__：今はレビュー会を正社員2人、業務委託4人くらいでやっています。今後、エンジニアメンバーが10人、20人と増えていったときにも、これが文化としてキープできているとすごくいいなと思います。

__松山__：デリバリー効率は健康指標だと思っていて、一定水準まで上がったら、もうそれ以上は求めてもきりがありません。例えば、プルリクの変更行数を5行にしましょう、なんて話は起きえないですよね。

なので、一定水準になったらそれを健康指標として、組織のコンディションが悪くなってしまったときに戻す力学が働くことが大事だと思っています。ただ、今はまだ健康指標にもなっていないので、まずはそこを目指していく段階。それができたら、定点観測していかに維持できるかが重要だと考えています。

もう1つ、Four Keysの文脈でいうと、僕らは現状デリバリー品質の部分が見れていません。直近もエラーが多いという課題が上がってきていますが、hotfix運用をしていなかったりリリースに影響がない本番障害があったりして、今はFour Keysの変更失敗率が「Findy Team+」で適切に取れないんですね。

ただ、ゆくゆくはそういった部分もプラットフォーム上ですべて管理して、我々の目標として追っていきたいので、そこは明確に今後の展望の1つだと思っています。

__――それでは最後に、組織のアピールポイントについて教えてください。__

__吉谷__：アピールポイントは、改善活動を気持ち良くできるチームだというところですね。プロダクトやサービスの価値にみんなが向かっていて、そのために改善活動するということを、すごくポジティブに捉えているチームだと思います。

__松山__：組織の小ささとフラットさは、アピールポイントだと思います。今回お話したような、エンジニアチームを切り出したり、KRにアウトプットの目標を置いたりといった話も、僕だけで決めているわけではなく、ヒアリングしながら吉谷と一緒に決めています。

エンジニアリングの枠に閉じずに、組織の目標をどうするか、採用をどう考えるかといったところまで、一人ひとりがやろうと思えばやれる環境があります。まだまだ小さな組織なので、自分をエンジニアという枠に収めたくない人にとっては、何でもできて面白い環境だと思います。

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

![mento_intereview_2024/04/19_h2-4-2](//images.ctfassets.net/ngrpflsbp3rq/MW2MR2NZn0CswoN5ApqJs/6374401ffda2495b68139edbdc5c27b5/DSC04122__1_.jpg)

（※最後はチーム全員で写真撮影をして頂きました。）

※現在mentoでは、エンジニアを募集しています。
[エンジニア求人　| mento](https://herp.careers/v1/mento/bmLBljpda7kA)

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


mento_intereview_2024/04/23_fv

パーソナルコーチングサービス「mento（メント）」の開発・運営などを行う株式会社mentoでは、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。  今回は、mentoのCTOを務める松山さんと、エンジニアの吉谷さんにインタビュー。「Findy Team+」を導入する前にあった組織の課題や導入後の取り組み、開発生産性の計測のベネフィットをどのように感じているかなどについて伺っていきます。

「正社員2名」の開発組織からFourKeys向上へ。事業拡大を目指すmentoにおける開発組織の文化づくりとは？

## 開発組織が拡大するなか、課題が顕在化しない状況に
__――まず最初に、金杉さんの主なご経歴と現在の業務について教えてください。__

__金杉__：新卒でワークスアプリケーションズに入社し、エンジニアとしてのキャリアをスタートしました。その後、スタートアップ企業で開発のマネジメントなどに携わったのち、自分の力試しをする気持ちでフリーランスとして独立。フルスタックエンジニアとして、何社かお手伝いさせていただきました。

そして、もともと正社員時代に働いていたスタートアップ企業で、弊社の創業メンバーである中村と渡部と一緒に仕事をしていた背景から、ともにミチビクを創業。ミチビクではCTOをしています。

__――開発組織の規模や体制について教えていただけますか？__

__金杉__：現在、日本とオフショアに拠点があります。自分が開発チームとデザインチームの2つを持っていて、開発組織の規模としてはオフショアを含めて15～16人。マネジメントしているのは自分のほかに、オフショアをメインでマネジメントしているブリッジエンジニアが1人います。

![michibiku_intereview_2024/04/11_h2-1](//images.ctfassets.net/ngrpflsbp3rq/3eORgPVAiQyx1uVpEY2e7l/b21967b1a6faaa0ee8bd579e30fac5e0/team_m.jpg________1_.jpeg)

__――設立された当初、開発組織は何名でしたか？__

__金杉__：設立した当時は2人でした。

__――開発組織の人数を拡大していくなかで、組織の課題になっていたことがあれば教えてください。__

__金杉__：日本チームでは、人数が拡大してもスピード感を維持するためにどうすればいいかを考えていました。課題は特に顕在化しておらず、課題を見つけようと1on1などで話を聞いても、みんな「このままでいい」と言っていたんですね。他の会社で働いていた経験から比較しても、今のチームはうまく回っているとのことで、困っていることが顕在化していませんでした。

__――「Findy Team+」を導入いただいたのは、どのようなきっかけからでしたか？__

__金杉__：課題がない組織はないだろうと思っていたものの、定性的な情報からは課題を見つけることができなかったわけですね。そうしたとき、ファインディさんはCTOのイベントにたくさんいらっしゃっていたので、「Findy Team+」のことも知っていたんです。CTOの佐藤さんとも知り合いですし、プロダクトマネージャーの方ともお会いしたことがあり、そうしたきっかけで問い合わせさせていただきました。

__――開発生産性の可視化にあたって、設定されたゴールはありましたか__

__金杉__：課題が見えていない状況だったので、まず最初の3ヶ月で課題の特定。その次の3ヶ月で、課題に対する分析や対応を行うことにしました。その次の6ヶ月で、課題すべてに対応し切って「Findy Team+ Award」※の表彰ラインに乗せることを目指しています。

（※「Findy Team+」 利用企業を対象に「エンジニア組織の生産性指標」を算出し、「組織規模、チーム別」および「優れた取り組み」を表彰するアワード）

__――「Findy Team+」導入前は、定量的なデータの計測はされていませんでしたか？__

__金杉__：基本的には、ロードマップに間に合っているかどうかを見ていました。2～3ヶ月のエピック単位で見て、リリースしたいバージョンに間に合っていればOK。それはずっと未達になったことがなく、問題になっていませんでした。

顧客から要望があったさまざまな新機能をつくる必要があるフェーズなのですが、ビジネスサイドと合意を取りながら、「このバージョンに間に合わせます」といった約束に応えるように進めていました。

## 数値の可視化にあたって重要なのは、本質を見誤らないこと

__――KPIとしてチームで設定されている定量的な指標はありますか？__

__金杉__：下記のような形で、目標スコアを表にしています。開発生産性スコアサマリでは、Findy Team+ Awardの表彰ラインを考慮して、ある程度の余裕を持たせた数値を目標スコアとして設定しました。ほかには、主に見たいサイクルタイムやDevOpsの目標スコアを設定して、マンスリーで振り返りをしています。

![michibiku_intereview_2024/04/11_h2-2-1](//images.ctfassets.net/ngrpflsbp3rq/65xkKELaWyj8rnNDK0bXFX/41109c935e51f42c9228073f1cf993bc/__________2024-04-11_14.59.13.png)

__――取り組みによって数値が改善した事例があれば教えてください。__

__金杉__：現時点で数値が改善したのは、リードタイムです。なかでも、大きく改善したのはアプルーブからマージまで。あとは、レビューからアプルーブまでですね。僕らは1ヶ月で間に合わせればよかったので、そのあたりはあまり意識していなかったのですが、可視化されたことによってアプルーブからマージまでは約90％減少、レビューからアプルーブまでは約30％減少と劇的に改善しました。

![michibiku_intereview_2024/04/11_h2-2-2](//images.ctfassets.net/ngrpflsbp3rq/3Q6SI1TeaX9UJhTz6jg1sI/415612d9e3fd8efdc11051aa81a11e3b/__________2024-04-12_14.06.13.png)

![michibiku_intereview_2024/04/11_h2-2-3](//images.ctfassets.net/ngrpflsbp3rq/6G7lSDzgOFbUcz1mrqeFCI/1e9009ca72364c84ad0a5864ae339907/__________2024-04-12_14.06.19.png)

__ーーレビューからアプルーブまでの改善について、金杉さんに偏っている部分があると伺ったのですが、分散していく取り組みを行ったのでしょうか？__

__金杉__：分散についてはまだ移行中で、今レビュアーの育成などに取り組んでいるところです。数値に効いていると思うのは、プルリクのサイズを小さくしていったこと。それによって、レビューのしやすさが向上しました。

それから、やはりレビューの指摘が入ると、アプルーブまでにより時間がかかります。アプルーブまでの速度を意識して、以前あった指摘を繰り返さないような取り組みもしていて、そういったところも効いてきたのかなと思います。

__――「Findy Team+」の活用について、社内で理解を得ていくにあたって難しかったことはありましたか？__

__金杉__：2つに分かれます。費用面を判断するのはCEOなので、まずはそこを口説くのが大変でしたね。ファインディさんと一緒に作戦会議をしながら、「Findy Team+」を導入して生産性が上がれば、顧客にとってもビジネスとしてもメリットがあるんだということを伝えていきました。

もう1つは社内のメンバーで、そちらはトライアルで導入した時点で、みんなから良い反応が返ってきました。特に自分の肌感と違う部分が見られるので、そこが面白いといった声がありました。あと、こうしたツールを使って、どうやってチームをより良くしていくかを考えるのが好きなエンジニアもいるので、そういう面でも良かったです。

__――自分のアクティビティやチームのデータが可視化されることに、抵抗がある人はいませんでしたか？__

__金杉__：そういう人はいないですね。そういった考え方の人は、そもそも弊社のカルチャーとマッチしないと思います。

__――取り組みを進めていくにあたって、難しかったポイントはありましたか？__

__金杉__：数値の改善をするためには、それまでの社内の開発フローを変えなければならず、その意思決定が正しいのかという判断が難しかったです。定量的に可視化して、本当にそのスコアが改善することが良いことだと定義して進めるのか。本質を見誤ってスコアの改善だけに注力してしまわないか、といった部分が難しかったですね。

__――そうした部分に対して、意識したことや心がけたことがあれば教えてください。__

__金杉__：まず1つは、やはり本質を見誤らないところ。結局、もし数値が良くなったとしても、スケジュールに間に合わなくなったら本末転倒じゃないですか。そこは意識して、あくまで数値だからということをメンバーにも伝えていました。

もう1つは、この数値の改善をまず1年間のトライとしたところ。取り組みが上手くいってスコアが改善したら、その結果として、社内で何が変わったのか見えてくると思うんです。僕らは定量的な指標がなく、課題が見えなかったところから始まっていますから、まずはトライして結果を見てみようということですね。

## 良い意味で裏切られた、「Findy Team+」導入後の印象

__――ここまでにお話いただいた以外にも、開発生産性の計測によるベネフィットを感じた部分はありましたか？__

__金杉__：「Findy Team+」の開発生産性スコアは相対比較なので、他の会社と比べてどうなのかわかるところが面白いですね。自分たちのこの数値はイケてるなとか、他社はもっとリードタイムが速いんだなとか、そういった比較ができるのはありがたいです。

あと、予期せぬベネフィットだったのは、日本と比べてオフショアの生産性が良くないと気づけたこと。上手くまわしていくためにさまざまな施策をして、アウトプットは問題ないと思っていたのですが、もっと改善できるところがあると気づきました。そういったオフショアや受託の管理にかなり有用だなと感じます。

![michibiku_intereview_2024/04/11_h2-3-1](//images.ctfassets.net/ngrpflsbp3rq/1wVWV3LmQgrcU4U94M3J12/3202b42583019bf8c00302a36ee6dde3/team_receipt.jpg________1_.jpeg)

__――開発生産性の可視化を通じて、メンバーの意識や行動に変化はありましたか？__

__金杉__：行動や意識の変化は感じています。具体的には、例えばプルリクを小さくするといったチームで決めたトライに対して、今まではただそう言うだけで、なかなか実行できていなかったんですね。そういった部分で、先ほど挙げたようなKPIに向けて、どうすればいいのかを考えて行動してくれるようになりました。

あとは、レビューのスピードがかなり上がりました。今までレビューは間に合えばいいという意識で、少しおざなりになっていた部分があったんです。それが可視化によって、レビュー速度を上げたらどれくらいスコアが上がるかがわかり、即時レビューするという意識につながりました。可視化しなければ、そこまで意識がまわっていなかったと思います。
導入して1ヶ月でリードタイムスコアが改善し、開発生産性スコアも上昇することができました。

![michibiku_intereview_2024/04/11_h2-3-2](//images.ctfassets.net/ngrpflsbp3rq/6FPcEolfWDjvahtvxdnwwf/8b0a0798bbbe46c6db3bf005307202b0/__________2024-04-11_14.56.48.png)

__――金杉さん自身が「Findy Team+」を導入して良かったと感じる部分について教えてください。__

__金杉__：導入してイメージが変わって、かなりポジティブな評価になりました。良い意味で裏切られた感じですね。もともと気になっていたのは、本当にFour Keysが正しいのか、弊社にも当てはまるのだろうかというところ。そこはモヤモヤしながら進めていたのですが、実際はいろいろと可視化できるメリットの方が大きくて、上書きされた感覚があります。

__――Four Keysという指標に対する、今の納得感はいかがですか？__

__金杉__：それについてはまだ50％くらいで、先ほどお話ししたこのあとの1年間のトライで腹落ちさせたいというのが正直なところです。弊社のプロダクトは性質上、toBかつユーザーが月に1回くらい使うもの。Four Keysを提唱したGoogleさんを含む、他のtoBプロダクトは、ユーザーが毎日使うものだったりします。なので、即時リリースすべきかといったところは、まだ腑に落ちていません。

ただ、結局はお客様の声が正義だと思うので、そういったトライをしてみようと、今は即時リリースできるように運用を変えている途中です。それでお客様の声が変われば良かったということだし、逆に不具合が増えてしまったら戻そうと考えていて、今まさに検証中です。

__――お客様の声は何らかの形で計測されていますか？__

__金杉__：NPSのようなアンケートはまだ取れていません。しかも、年契約のサービスのため、今取り組んでいる内容への回答が1年半後などになってしまいます。なので、アップセルや他社への紹介につながることが増えたら、良い反応だと捉えています。

## 新たな気づきを得た、オフショアにおける課題の改善へ

__――開発生産性の可視化に関して、今後のトライとして考えていることはありますか？__

__金杉__：まず1つは、先ほどお話しした即時リリースですね。そして、今ちょうど取り組んでいるのがフィーチャーブランチの撤廃。すべてdevelopのメインブランチに直マージして、フィーチャートグルで機能を管理することにチャレンジしています。

今までフィーチャーブランチに8つくらいのプルリクを入れていたため、これでおそらくプルリクの作成数が一気に上がるだろうと。プルリクの作成数がアウトプットに響いていると推測しているので、特にオフショアでの数値に大きく変化があるのではないかと考えています。

それから、新たな気づきとしてあった、オフショアにおける生産性の課題に関してですね。明らかに日本チームとの差があることに気づけたので、どういったところから日本チームとの差分が生まれているのか、バイネームでデータを見ながら改善を進めています。

オフショアはコストパフォーマンスや採用の観点でメリットがあると考えていましたが、生産性が上がらないのであれば、日本チームだけでやったほうがいいのではないかという話になってきます。改善を進めながら、オフショアの戦略が正しいのかといったところも含めて見ていきたいと思っています。

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

__金杉__：僕らが掲げているコンセプトは、“和製GitLab”。フルリモートで世界中に従業員がいるGitLabと同じように、僕らも国籍や人種や性別に関係なくチャレンジしていきます。開発生産性を意識する文化も根付き始めていますから、フルリモートでも定量的な面からサポートしつつ、ビジネスとして成長させていきます。

会社のカルチャーを大切にしたいので、フルリモートでもコミュニケーションが取れてアウトプットが出せて、チームのことに責任を持てる。そういう方を求めています。弊社では、ただコードを書くだけでなく、フルサイクルエンジニアのような形で、調査やデプロイ、QA、自動テストなどもしてもらっています。なので、そういうエンジニアの方とぜひ一緒に働きたいと考えています。

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

![michibiku_intereview_2024/04/11_h2-4](//downloads.ctfassets.net/ngrpflsbp3rq/olyn8Rajq4KK9IFkibuAh/e1ba209cc65ff20a171f612e5d406952/DSC03016.jpg________2_.jpeg)

※現在ミチビクでは、エンジニアを募集しています。
[エンジニア採用サイト　| ミチビク](https://engineer-recruit.michibiku.jp/index.html)

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


michibiku_intereview_2024/04/12_FV

取締役会運営の効率化を支援するツール「michibiku」を運営するミチビク株式会社では、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。  今回は、ミチビクのCTOを務める金杉さんにインタビュー。開発生産性の可視化における取り組みに「Findy Team+」をどのように活用しているか、導入後に組織やメンバーにどのような変化があったかなどについて伺っていきます。

潜在的な課題を特定し、数値に基づく目標設定へ。設立3年目で開発生産性向上を目指すミチビクの取り組み

tsukuruba_intereview_2024/04/02_FV

中古・リノベーション住宅の流通プラットフォーム「cowcamo（カウカモ）」などを展開する株式会社ツクルバでは、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。

経営と開発をつなぐ架け橋に。事業成長を加速させるツクルバの開発生産性指標の活用方法とは？

ourly_interview_2024/02/21_FV

プルリクオープンオープンまでの時間が9分の1に。15名でFourKeys向上に向き合うourlyの取り組みとは？

プルリクオープンまでの時間が9分の1に。15名でFourKeys向上に向き合うourlyの取り組みとは？

## 組織が立ち上がった2年前から、アジャイル開発を推進
__――まず最初に、皆さんの主なご経歴や現在の役割を教えてください。__

__坂井__：2004年に新卒で入社し、入社時からソフトウェア開発を続けています。2022年から現在の組織のマネージャーになり、現場から管理までプレイングマネージャーとして業務しています。

__古澤__：2000年に新卒で入社しました。入社後の6～7年間は、携帯電話のソフトウェア開発に携わり、その後は、通信キャリアやエンタープライズ向けのソフトウェア開発を行っていました。3年前に自社サービスを開発する現在の組織へ異動してきました。

__山下__：2014年に新卒で入社し、4年ほど開発部門でロボット内部のソフトウェアやタブレットのアプリケーション開発を行いました。その後、別の部門で4年間パブリッククラウドのアーキテクトを経験し、現在は社内のアジャイル推進とスクラムマスターを担当しています。

__――皆さんが所属されている組織について、教えていただけますか？__

__坂井__：私たちはSymphonict事業推進本部の先端技術開発グループに所属しており、グループマネージャーを古澤が務めています。さらに、そのグループ内にあるSymphonictサービス開発チームに坂井と山下が所属しており、私はそこでマネージャーを担当しています。

__――どのような背景から、アジャイルを推進していくことになったのでしょうか？__

__坂井__：2022年に組織が立ち上がった際、このVUCAの時代を生き抜くために、組織のアジリティを上げていかなければならない。そのために、アジャイルな組織になる必要があるという話になりました。

しかしながら、私たちにはその知見がなかったため、まずはコンサルタントの支援を受け、アジャイルの基礎を叩き込んでもらうところからスタートしました。初めの3ヵ月は座学を中心に行い、その後、PoC案件でスクラムチームを1つ立ち上げたのが始まりです。そして、さらに2つ目のチームを立ち上げ、現在も開発を継続しています。

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

__坂井__：部の名前についている「Symphonict」というのは弊社のブランドで、“デジタルでつなぐ”というコンセプトのもとお客様のDXイノベーションをサポートするサービスの総称です。Symphonictを実現するために、「早く、安く、巧く」サービスを提供できるプラットフォームを準備することや、そのプラットフォーム上でサービスを開発することが大きなミッションとなっています。

Symphonictのブランドにはさまざまなサービスがありますが、現在アジャイル開発を行っているサービスは、主にお客様向けのポータルサイトになります。私としては全ての開発をアジャイルでやっていきたいという思いがあるのですが、現状はアジャイルの案件数がそれほど多くないのが実情です。

自社サービスは作ったら終わりではなく、常にフィードバックをもらいながら、より良いものに更新し、価値を高め続けなければならないと思っています。そのためには、やはりアジリティが重要であると考えています。私たちのミッションと照らし合わせても、アジャイルな組織としてリリース頻度を高めていくことが必要だと考えています。

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

__坂井__：リリースするサービス数やアジャイルのスクラムチーム数などはKPIとして設定されています。また、運用フェーズでは、サービス稼働率、インシデント発生数、インシデントの対応にかかる日数などがKPIになっています。

ただし、チーム毎の1日のリリース回数や、プルリクの作成数など、スクラムの活動に特化したKPIはまだ設定されていません。
![【使用①】インタビュー風 DSC07257](//images.ctfassets.net/ngrpflsbp3rq/MRuXbepkf9AF1Ejh8prhf/cf4db525fa868f7f254c23f579088894/______________DSC07257.jpg)
## 開発生産性に関する疑念から、「Findy Team+」の導入へ

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

__坂井__：今年の3月に、社内で「アジャイルの方が、ウォーターフォールよりも生産性が低いのではないか？」という声が上がりました。その時、私は「そんなことはないだろう」と感じたと同時に、生産性を測る指標がコード量だったことにも違和感がありました。

そこから、生産性をどのように測るべきかを調べ始め、『LeanとDevOpsの科学』などを読み、Four Keysのことを知りました。そこで、そもそも本当に生産性が低いかどうか、まずは数字で見える化しなければならないと思ったのがきっかけです。

__――そうした生産性に関する情報を調べるなかで、「Findy Team+」を見つけていただいたのでしょうか。__

__坂井__：最初は私が片手間で、GitHubのAPIを使ってAWSにデータを取り込み、BIツールで可視化しようとしていました。それを作る途中でたまたま「Findy Team+」を発見しました。これを参考に似たものを作ろうと思ったのですが、ものすごく大変で（笑）。「Findy Team+」のサイトを見てみると、とても高機能だったため、これは自分で作るよりも導入した方が良いなと思いました。

__――その後、どのような流れで「Findy Team+」の導入が決まりましたか？__

__坂井__：4月の組織変更で新たな本部長が着任し、そのタイミングで本部長に直接話を聞いてもらえる機会がありました。そこで私は、開発力を高めてリリースを早めていくためには、生産性を計測する必要があるという考えと、Four Keysの導入を提案しました。さらに、そのFour Keysを可視化できる「Findy Team+」というツールがあると伝えたところ、トントン拍子で導入まで進みました。

__――「Findy Team+」の導入前に、懸念されていた部分はありましたか？__

__坂井__：「Findy Team+」では個人の数値が計測されるため、個人の能力面も可視化されてしまいます。その数値だけで100％判断できるわけではないにしても、そういった数値をメンバーに見せて大丈夫なのかという懸念がありました。現在、導入から4ヵ月経ちましたが、そういった懸念に関する声は特に上がってきていません。
![【使用②】坂井さん DSC07240](//images.ctfassets.net/ngrpflsbp3rq/6hIrUVxJ1u4b0aJdAYijv0/aba973965e3451ba6be1cf08de064fb6/__________DSC07240.jpg)
## 経営層まで、Four Keysが浸透したことで意識が変化

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

__坂井__：ウォーターフォールとアジャイルの比較が最初のトリガーにはなったものの、そもそも比較するものではないため、今はそこにはあまりフォーカスしておらず、純粋に私たちのスクラムチームにおけるFour Keysの可視化を目的にしています。最終的には、お客様にどれだけ価値を届けられているかを計測したいのですが、まずは開発のアウトプットとしてFour Keysやプルリク数を向上させていくことを目指しています。

__古澤__：生産性という言葉のイメージから、一般的な「開発コード量」のみを見て、アジャイルは生産性が落ちると思っている人は、社内にもまだ存在します。
ですが、デプロイ頻度、リードタイムまで生産性と考えるような価値観が、ようやく少しずつ浸透してきました。とはいえ、まだまだアジャイルでの開発が軌道に乗っているとは言えず、お客様に価値を提供するところまで持っていくことがゴールだと考えています。
![【使用③】古澤さん DSC07235](//images.ctfassets.net/ngrpflsbp3rq/4py4HsIYASfIIOTt5iVLpH/b390cd94393b28baeefcfab41d4df10a/__________DSC07235.jpg)
__――目標に設定されている、具体的な数値などはありますか？__

__坂井__：私たちのデプロイ頻度は、まだ2ヵ月に1回程度なので、まずは1ヵ月に1回のデプロイを目指しています。また、コミットからマージまでの時間を表すサイクルタイムですが、今は100時間を超えているため、24時間を目指そうと開発チーム内で目標設定しています。ただし、これはまだ明確に決めているわけではなく、現状は可視化してみて、次の段階で具体的な数値目標を設定していきたいと考えています。

__――「Findy Team+」の活用について、スクラムマスターをされている山下さんから見ていかがでしょうか？__

__山下__：チームの活動において、自分たちがどれだけ効率的に開発できているかを可視化できるところが、とても有用だと思っています。スプリントごとの振り返りで、今まではメンバーが感じていることをベースに話すことが多かったのですが、今は「Findy Team+」の数字を見ながら実態に則した話もできているので、振り返りの質が向上しました。

2週間のスプリントの中で、明らかに課題があった場合は別ですが、そうではなく計画通りに開発ができた時、はたして本当に効率が良かったのかどうかは、おそらく数字がないと判断できません。ですので、チームの活動を改善するための取っ掛かりとしても非常に有用なツールだと感じています。

__――スプリントの振り返り以外で、「Findy Team+」を見る場面はありますか？__

__坂井__：振り返り以外では、マネージャーを含めて各個人が自由に見たい時に見ています。また、同じ本部内に品質管理グループという、プロジェクトやアウトプットの品質をチェックするグループがあるのですが、そのグループもプロジェクトの状況を見るために「Findy Team+」の数字を見たいと言っています。

__――ここまでにお話いただいた以外にも、開発生産性を計測することによるベネフィットを感じた部分があれば教えてください。__

__坂井__：「Findy Team+」を導入してから、経営層にもFour Keysが浸透してきた印象があります。以前はコード量をもとに話していた人も、最近ではFour Keysで話すようになり、意識が変化してきた部分があると思います。

マネージャーとしての立場から見ると、「Findy Team+」では活動量が見えるので、プロジェクトの負荷が高くなっている場合や、何らかの問題が生じている場合に気付きやすくなりました。加えて、レビュアーの負担や偏りも可視化されるので、メンバーからもそれを意識するような発言や、改善しようとする動きが出てきています。

__山下__：スクラムマスターとしてチームに改善を促す際に、今までは実際にやってみてどうだったかという体験をもとに話をしていました。ですが、例えばPBI単位でブランチを切るとか、タスクレベルでなるべく細かくプルリクを出すとか、そういったところも数字で見えるようになったので、説得力を持って提言できるようになりました。

__坂井__：課のメンバーが半期ごとに目標を立てるときに、「Findy Team+」の数字を使って目標を立てるようになり、活用されていることを実感しています。具体的な数字で目標を立てられるので、評価もしやすく、成長を促しやすくなったと思います。

__――経営層へのレポーティングなどに、「Findy Team+」を活用いただいている場面はありますか？__

__坂井__：先日、経営層向けにチームの「Findy Team+」の数字を見せながら、開発チームの状況を説明しました。今後も定期的に「Findy Team+」を活用して説明を行っていこうと思っています。

__山下__：その説明の場で印象的だったのが、経営層から「今はこういう指標を見るんだ」、「これはあまり考えたことがなかったな」といったコメントが出たことでした。組織としての振り返りに、今までになかった新しい観点を取り入れられるツールなのかなと思います。

## 開発組織に閉じない生産性まで、可視化していきたい

__――「Findy Team+」で計測するにあたって、難しかったポイントはありましたか？__

__坂井__：「Findy Team+」で計測するためには、Gitのブランチ戦略を適切に合わせる必要があり、私たちの従来のやり方を少し変える必要がありました。例えば、空コミットを実施してからコーディングをスタートさせることや、同じプルリクをマージした時に二重集計されないようにタグ付けするなど、Gitの運用をルール化し、チームに浸透させて上手く使いこなせるようになるまで、ひと手間あったと思います。

__山下__：「Findy Team+」で難しいのは、誰がどこをどう見たら良いかが分かりにくいところでしょうか。データはたくさん取れており、有用な指標もたくさんあるはずなのですが、それを有効活用することは難しいと感じました。

私や坂井は、ファインディの方との定例で、サポートを受ける中で「こういうところを見ればいいんだな」と、徐々に分かってきました。ですが、現場の開発メンバーにはまだあまりノウハウが伝わっていないため、そこを浸透させ、共通認識化させていくことがツールを活用する上での課題だと感じています。

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

__古澤__：ウォーターフォールとアジャイルを両方見ている立場としては、品質の観点では、アジャイルの方が若干良いと感じています。しかし、単純比較はできないな、とも感じています。

その理由として、アジャイルはプロダクトオーナーの判断で、開発機能の優先順位やリリース可否を変更できますが、ウォーターフォールではそうはいきません。

アジャイルが途中で変更されやすいことを踏まえると、計画時点でのPBIがどのくらい守れたのかといった指標も、数値的に見れると良いなと思っています。

__坂井__：ビジネスサイドまで含めた可視化をしていきたいと考えています。開発に閉じた生産性は「Findy Team+」で見えますが、本当に価値が届けられたのかまではわかりません。PBIや要求が生まれてから、リリースまでにどれだけ時間がかかったのかも見えないので、それを見えるようにしたいという思いがあります。

あとは、開発コストも可視化したいと思っています。サービスの収支については別途取り組んでいるのですが、もっとブレイクダウンして機能ごとの開発コストも見えるようにしていきたいと考えています。

価値が届けられているかどうかという部分については、どう計測するべきかがまだはっきりと見出せていません。アクセス数で測るのか、満足度アンケートを取るのか、それとも他にもっといい指標があるのか。これについては私たちの今後の課題だと思っています。

__――それでは最後に、組織のアピールポイントがあれば教えてください。__

__坂井__：開発力の高いチームが立ち上がってきているので、開発するもののビジョンさえ立てば、どんどん良いものを開発していける組織です。また、本部長が新技術の取り込みに積極的で、データ分析やAIをもっと取り入れていこうと掲げており、生成AIのCopilot導入に向けて動いています。私としても開発者の体験を向上させて、みんなが楽しく開発できるようにしたいと思っています。

__――皆さん、本日はありがとうございました！__
![【使用④】2shot DSC07329](//images.ctfassets.net/ngrpflsbp3rq/nroKriCNDCwZtCtznVyAV/c35853e62bea91c159929e3c35d68e18/_____2shot_DSC07329.jpg)

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

nec.netssi_interview_2024/01/16_FV

コミュニケーションに関わるさまざまなサービスを提供し、DX事業のブランド「Symphonict（シンフォニクト）」を展開する、NECネッツエスアイ株式会社。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。

コード量からFour Keysへ。 経営層に新たな視点をもたらしたNECネッツエスアイの取り組み

parsol　FV

転職支援や求人メディアをはじめとした、幅広い人材サービスを展開するパーソルキャリア株式会社。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。 

数値の意味づけや目標設定でメンバーの意識が変化。パーソルキャリアの全社的な開発生産性向上に向けた取り組みとは？

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を推進するモリサワの開発生産性向上への取り組み

## 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+」をご活用いただいています。

インタビュー

「正社員2名」の開発組織からFourKeys向上へ。事業拡大を目指すmentoにおける開発組織の文化づくりとは？

潜在的な課題を特定し、数値に基づく目標設定へ。設立3年目で開発生産性向上を目指すミチビクの取り組み

経営と開発をつなぐ架け橋に。事業成長を加速させるツクルバの開発生産性指標の活用方法とは？

プルリクオープンまでの時間が9分の1に。15名でFourKeys向上に向き合うourlyの取り組みとは？

コード量からFour Keysへ。経営層に新たな視点をもたらしたNECネッツエスアイの取り組み

数値の意味づけや目標設定でメンバーの意識が変化。パーソルキャリアの全社的な開発生産性向上に向けた取り組みとは？

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

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

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

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

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

「正社員2名」の開発組織からFourKeys向上へ。事業拡大を目指すmentoにおける開発組織の文化づくりとは？

潜在的な課題を特定し、数値に基づく目標設定へ。設立3年目で開発生産性向上を目指すミチビクの取り組み

経営と開発をつなぐ架け橋に。事業成長を加速させるツクルバの開発生産性指標の活用方法とは？

プルリクオープンまでの時間が9分の1に。15名でFourKeys向上に向き合うourlyの取り組みとは？

コード量からFour Keysへ。 経営層に新たな視点をもたらしたNECネッツエスアイの取り組み

数値の意味づけや目標設定でメンバーの意識が変化。パーソルキャリアの全社的な開発生産性向上に向けた取り組みとは？

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

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

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

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

インタビュー

コード量からFour Keysへ。経営層に新たな視点をもたらしたNECネッツエスアイの取り組み