rakuten-recruit_event_2024/05/08_fv

大規模組織における開発生産性向上へのアプローチ

data_engineer_org

株式会社ニューズピックスの高山温さんと、株式会社PR TIMESの金子達哉さんをお招きし、「Findy Teams」を活用して、2021年の開発組織のパフォーマンスを振り返りつつ、具体的な取り組みの内容や今後の展望についてお話しいただきました。

データで振り返るエンジニア組織の生産性向上 〜NewsPicks & PR TIMESの事例、DevOpsの取り組みからデプロイ頻度の計測まで〜

eventreport ikyu stafes

「CTOが語るエンジニア組織づくり最前線vol.3」では、株式会社一休の伊藤直也さんと、スターフェスティバル株式会社の柄沢聡太郎さんにご登壇いただき、CTOとしての取り組みんでいる組織づくり等について伺いました。

事業で勝つためのマネジメントとは。エンジニア組織づくりの裏側を一休伊藤氏とスタフェス柄沢氏に聞いてみた

andpad podcast

ANDPAD TECH TALK 第11回 - 開発チームの生産性向上に取り組むスペシャリスト対談！後編 可視化ツールを導入してみて分かったこと、そして今後の展望

## エンジニア組織の生産性はどう測る？

本記事では、ソフトウェアサービスを展開するIT企業を中心に、エンジニア組織の生産性を向上させるために見るべき指標について書いていきます。

結論から言うと、素早く、動くソフトウェアを顧客へ届けるために、エンジニア組織の生産性を測る要素としては以下の2点に集約されます。
 
- **ソフトウェアデリバリの速度**
- **ソフトウェアデリバリの安定性**

それぞれ解説していきますと、**1つ目のソフトウェアデリバリの速度は、ソフトウェアが顧客のもとへ届くまでの時間であり、プロダクトの企画〜運用までのプロセスを速く実行すること**が重要です（今回はプロダクトの企画・仕様作成の時間は除き、エンジニアがコードコミットしてから本番環境へデプロイされるまでの時間として言及いたします）。**2つ目のソフトウェアデリバリの安定性は、コードコミット〜デプロイするまでの障害および障害に対する復旧の時間であり、顧客へきちんと動くソフトウェアを届けること**が重要です。

これら2つの要素は、以下の指標として数値化し、定点観測することが可能です。
 
- **ソフトウェアデリバリの速度**
 - デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
 - 変更のリードタイム - commit から本番環境稼働までの所要時間
- **ソフトウェアデリバリの安定性**
 - 平均復旧時間（MTTR：Mean Time To Restore） - 組織が本番環境での障害から回復するのにかかる時間
 - 変更失敗率 - デプロイが原因で本番環境で障害が発生する割合（%）

上記は、<a href="https://www.amazon.co.jp/Lean%E3%81%A8DevOps%E3%81%AE%E7%A7%91%E5%AD%A6-Accelerate-%E3%83%86%E3%82%AF%E3%83%8E%E3%83%AD%E3%82%B8%E3%83%BC%E3%81%AE%E6%88%A6%E7%95%A5%E7%9A%84%E6%B4%BB%E7%94%A8%E3%81%8C%E7%B5%84%E7%B9%94%E5%A4%89%E9%9D%A9%E3%82%92%E5%8A%A0%E9%80%9F%E3%81%99%E3%82%8B-impress-gear/dp/4295004901" target="_blank" rel="noopener noreferrer">『LeanとDevOpsの科学』</a>という書籍からの引用となりますが、これらソフトウェアデリバリの指標(Four Keys：4つのキーメトリクスとして紹介)は、組織全体のパフォーマンスおよび企業の業績に好影響を与える、という科学的な根拠をもって実証されています。

また、このソフトウェアの速度と安定性は互いにトレードオフの関係性ではなく、両立しうるものである(ソフトウェアデリバリのプロセスの質を上げれば、速度も安定性も向上する)と本書では紹介されています。

実際に、パフォーマンスが良好な組織とそうでない組織では、
 
- **ソフトウェアデリバリの速度**
 - コードでのデプロイ頻度は46倍
 - コミットからのデプロイまでのリードタイムは1/440

- **ソフトウェアデリバリの安定性**
 - 平均復旧時間(稼働停止からの復旧に要する時間)は1/170
 - 変更失敗率は1/5

というほどの差分があり、**パフォーマンスが良好な組織は指標すべてにおいてハイパフォーマンスな成果を上げている**ことが見てとれます。

以下<a href="https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance" target="_blank" rel="noopener noreferrer">Googleが投稿した記事内</a>におけるソフトウェアデリバリのパフォーマンスを分類した表も自社のエンジニア組織の生産性を測る指標として参考になるかと思います。

![Calculating the metrics.max-2800x2800][1]

## エンジニア組織の開発アクティビティを把握しよう

エンジニア組織における生産性指標は理解できた一方で、それらを指標として定量化/可視化する仕組みがない、という企業様は少なくありません。

そのようなケースにおける解決策の一つとして、GitHubのようなソースコード管理ツールによって、まずはソースコードベースでエンジニアの開発アクティビティをログとして残せる仕組みを取り入れる方法があります。

**ソースコード管理ツールを活用することで、エンジニアの開発アクティビティが履歴化されるとともに、共同での開発作業が円滑になり、チームでの開発効率はよくなります**。

## エンジニア組織のソフトウェアデリバリを可視化しよう

次に、Four Keysに関連する指標を定量化する必要があります。

Findy Teamsでは、GitHubやGitLab、Jiraなどのエンジニア向けツールのデータを取得し、エンジニア組織のパフォーマンスを可視化することが可能です（Findy Teamsのサービスに関しては<a href="https://findy-teams.com/service_introduction" target="_blank" rel="noopener noreferrer">こちら</a>をご覧ください）。

お客様からのご要望が強かったこともあり、現在Findy Teamsでは『DevOps指標』として、Four Keysに関連する指標をご覧いただけるようになっておりますので、最後にそちらをご紹介したいと思います。

## Findy Teamsの『DevOps指標』を活用しよう

Findy Teamsでは、『DevOps指標』として、以下の指標を見ることができます。
 
- **デプロイ頻度** - デプロイ設定に応じて算出した期間内のデプロイ回数
- **変更のリードタイム** - 期間内にメインブランチへマージされたプルリクにひもづくcommitからマージまでの所要時間
- **変更障害率** - 期間内にメインブランチにマージされたプルリクのうち、hotfixブランチからのプルリクが占める割合
- **平均修復時間** - 期間内にメインブランチにマージされたプルリクのうち、hotfixブランチまたは、revertブランチに紐づくコミットの最初のコミットからメインブランチへのマージまでの平均時間

![DevOps分析画面](//images.ctfassets.net/ngrpflsbp3rq/8hEufdU0P48YfKM7Yggai/40e5fdf8327d0dba0904a2df2b32964f/DevOps____________.png)

（Findy Teamsを導入いただいている企業様は<a href="https://findy-teams.com/analytics/teams/?range=last_month" target="_blank" rel="noopener noreferrer">こちら</a>から直接操作画面にアクセスできます）

また、デプロイ頻度の先行指標として、プルリク・レビュー・マージ/クローズごとの開発アクティビティや、開発リードタイムを可視化することができます。

![記事用 スタッツ][3]

自社内でもDevOps指標およびそれに係るプルリクベースでの開発アクティビティや開発リードタイムを把握し、エンジニア組織の生産性改善に繋げています。
結果として、開発効率は3倍上がりました（詳細な取り組みの内容は<a href="https://engineering-org.findy-teams.com/posts/developer-experience-improvement/" target="_blank" rel="noopener noreferrer">こちら</a>からご覧ください）。

そのほか、導入企業様からも<a href="https://engineering-org.findy-teams.com/tech_blog/" target="_blank" rel="noopener noreferrer">Findy Teamsの指標を活用した生産性向上の取り組み</a>は増えてきています。

様々な企業様のエンジニア組織づくりのご支援をさせていただく中で、このようなデータを活用した取り組みには、採用効果があり、改善するエンジニア組織に優秀なエンジニアが集まりやすい、ということもわかりました。

**エンジニアが生産性高く働ける仕組みを取り入れることで、開発者体験の向上および企業業績の向上、また採用効果への影響など、さまざまなメリットがあります**。

貴社は、このようなデータを活用した取り組みはされておりますでしょうか？
この機会に、データを活用したエンジニア組織づくりをしてみてはいかがでしょうか？
本記事が、自社のエンジニア組織改善の参考になりましたら幸いです。

以上、最後までお読みいただき、ありがとうございました！

現在エンジニア組織について悩んでいる、Findy Teamsにご興味があるという方は、<a href="https://findy-teams.com/contact_teams" target="_blank" rel="noopener noreferrer">こちら</a>より資料請求・お問い合わせ頂ければと存じます。
(※2週間の無料トライアルも可能となっております！！)

引き続き、Findy、Findy Teamsをよろしくお願いします！

[1]: //images.ctfassets.net/ngrpflsbp3rq/7nNHkV76CSOnIEV0WRpPFU/fbbe0427b46dadeaa7427393022cbb6f/Calculating_the_metrics.max-2800x2800.jpg
[2]: //images.ctfassets.net/ngrpflsbp3rq/4Orovzob7IX4uArI7Lm7go/4cba0d3db27bf1bf757ee05a1b542a1b/__________devops______.png
[3]: //images.ctfassets.net/ngrpflsbp3rq/1jObvPo1OWN0aLUtFp3pe1/6936428be99a563b1d7e0f1f570af078/______________________.png

devops_metrics

エンジニア組織の生産性の可視化をテーマに、”素早く、動くソフトウェアを顧客へ届けるためには”どのような指標をみればよいのかの一例について書いていこうと思います。

エンジニア組織の生産性の可視化とは？ 〜『DevOps指標』を活用しよう〜

## 開発者体験の改善

Findyでは自社で開発者体験向上クラウドFindy Teamsを開発していたこともあり、数字を見ながら開発組織の改善に取り組んできました。
 

- <a href="https://findy-teams.com/service_introduction" target="_blank" rel="noopener noreferrer">Findyの開発スピードが1年で約3倍になった結果、ユーザからの反応は格段に変わり、未知の課題にぶつかった</a>
- <a href="https://engineering-org.findy-teams.com/posts/mbo-2021/" target="_blank" rel="noopener noreferrer">データを活用した目標設計と運用にトライした1年間を振り返ってみた</a>

なかでも大きくは2つのことに取り組んでおり、**1つ目はエンジニアが快適に開発できるための環境づくりへの投資**、**2つ目はエンジニアメンバーがデータを活用したオブジェクト（目標）設定を行なったり、データを活用した1on1や振り返りを行うこと**です。具体的には以下のような内容に取り組んできました。

### 1.快適な開発環境づくり

- テストのカバレッジを上げる
- フロントエンドとバックエンドの分離
- SentryやDatadogなどエラーや障害監視のツールを積極的に導入
- ReactからTypeScriptへの移管
- GraphQLの導入
- エンジニアのMacを50万円まで購入可に変更

など**機能開発にはすぐには繋がらないものの、開発者の生産性を上げるための取り組みでできることを積極的に取り組み、ストレスなく心理的な不安をできる限り減らした開発環境を作る取り組み**をしています。

最初はフロントエンドとバックエンドの分離をやるので3ヶ月は新規機能開発が止まるかもしれない、といった話を聞くと経営者としては「まじで！？それは厳しい」などと考えるものですが、今は改めて投資を決断してよかったと思っています。

### 2.データを活用したマネジメント

- プルリク作成数などデータをもとにオブジェクトを設定
- データをもとに1on1でマネージャーとメンバーが現状の確認を行う
- 個人の振り返りについてもデータをもとに行う

Findyでは、**プルリク作成数やプルリクの平均クローズ時間などを目安として目標設定したり、振り返りを行うデータを活用したマネジメント**にトライしてきました。これを持って評価するのではなく、あくまで日々の個人や組織の改善や成長にデータを使うスタンスです。

例えば1on1などでは、データを通して現状の確認を行うことで、実はその時間が短くなり、エンジニア個人の将来的な成長に対するディスカッションやプロダクト周りで気になる点など、話題の幅が広がるなどの結果に繋がっています。

結果的には普段行っている社内のサーベイなどの数字も右肩上がりでよくなっています。

## アウトプット量が3倍以上に増加

まずは下表を見ていただければと思いますが、マージ済プルリク数やコミット数が全体でも一人当たりでも見ても大幅に増加しています。2020年上期と2021年下期で比較をすると

- 一人当たりのマージ済プルリク数：3.2倍（開発アクティビティ/量の向上）
- 平均プルリク クローズ時間：5.3倍（開発効率/スピードの向上）

などが起きています。またこの間の1プルリクあたりの平均変更行数はそれほど変わっていないので、大きな改善をしている可能性が高いと言えます。

![工数試算](//images.ctfassets.net/ngrpflsbp3rq/2LTt4xJECps2RBZKd9bsnK/77a9599e0296bd6f00bbf9217461e29b/____________________________2022-02-20_23.53.09_2.png)

実は、2021年上期に関してはリファクタリングなどにも時間を使っていたため、1プルリクあたりの平均変更行数などはむしろ長くなってしまっており、これだけで単純なアウトプット量の増加とは断定しにくい部分はもちろんあります。

ただ、プロダクト企画を担当している自分の感覚としては確実に一人当たりの開発ボリュームは増えてきており、**嬉しい悲鳴ですがイシューを作っても作っても解消されていくので企画やデザインが圧倒的に足りていない状況**になってきています。前職からWebの世界に入ってはや12年以上ですが、こういった状況は初めてかもしれません。

## 金額で計算すると1.8億円のアップサイドの効果

上記のアウトプット量の改善に関して、金額ベースでも換算してみました。
すると、**2020年上期ベースで2021年の開発を行っていた場合と改善後で比較をすると実に「1.8億円分」の追加開発ができていることが計算**できました。あくまで机上の計算ではありますが、我々のような小さいスタートアップでこの差分は非常に大きく、開発者体験向上に力を入れてきた意思決定が間違いない点を強く感じました。

- 1マージ済みプルリクあたりのコスト：2020年上期34,804円→2021年下期14,311円/2.4倍（効率の向上）

**2020年上期の水準で開発をしていたら2021年の開発費が3.2億円かかっていたところが1.4億円ベースで本来取り組みたいことができていた計算**になります。これは単純に採用計画を立てていたものにミートできなかったことが大きいのですが、結果的にはプロダクトの進捗に関してそれほど遅れることなく事業目標も達成できた2021年になりました。

2020年から開発上の課題を地道に解決してきた結果ですし、当然機能開発に繋がらない開発も積極的に取り組んでいるため全てが見た目上のプロダクトに反映されているわけではありません。

ただ、確実なプロダクト開発力の向上と進化を実現できており、手応えを感じています。
ちなみに、2020年上期のFindyの水準はFindy Teamsでみているとトライアル企業を含む全企業のデータの中では真ん中かそれより少し低いくらいの位置付けでした。

つまり、上記のような改善を実現、体感できる会社はまだまだたくさんあるのがデータからもわかってきています。

## テックジャイアントも開発者体験や生産性に注目

開発者の体験や生産性を語る際にあくまでデータはその一部に過ぎないと考えています。
例えば、上記で記載したプルリク作成数が多ければ必ずしも良いというわけではないですし、開発しているプロダクトの種類や開発スタイルによって、注力するべきデータも異なります。

例えばアプリを開発しているチームではまとめてリリースする際にマージを行っており、どうしても最初のコミットからプルリク作成までの平均時間は長くなる傾向があるかもしれん。

ただ、以下のリンク先でもGoogleなどが開発ポリシーとして、レビューを1日以内に行うためにプルリクの数を小さくすることに言及しています。

- <a href="https://google.github.io/eng-practices/review/reviewer/speed.html" target="_blank" rel="noopener noreferrer">Googleエンジニアリングプラクティス[コードレビューの速度]</a>

また、先日ヒアリングした海外の企業に所属するエンジニアの友人はコミット単位でマージまでの時間を測定していると話していました。むしろ高いレベルのエンジニアが集まっており、快適に開発を進めるために開発速度やレビュースピードは前提の条件という話もしていました。

グローバルではデータを活用して開発者体験を向上することで、結果的にアウトプットの量も最大化していくアプローチに注目が集まってきています。

## まだまだこれから！という企業の方はぜひデータの可視化から始めてみませんか？

最後までお読みいただきありがとうございました。

Findyでは、Findy Teamsを通して、エンジニア組織の開発者体験向上、生産性の可視化によるパフォーマンスの最大化を支援いたします。

Findy Teamsにご興味ある方は<a href="https://findy-teams.com/contact_teams" target="_blank" rel="noopener noreferrer">こちら</a>からお問い合わせください。

また、Findy Teamsを活用して、開発者体験向上に積極的な企業様も増えております。こちらもぜひご覧頂ければと思います。
<a href="https://findy-code.io/pick-up/articles/developer-experience" target="_blank" rel="noopener noreferrer">開発者体験（Developer eXperience）向上に積極的な企業特集《「Findy Teams」で組織のパフォーマンス改善に取り組み中》</a>

引き続きよろしくお願いいたします！

Findy Teams_開発者体験向上_Findy取り組み

FindyではFindy Teamsの開発を通して、自社の開発者体験(Developer eXperience)向上にも積極的に取り組んできました。そこで開発者体験向上に取り組んでみえた定量的な改善結果について書いていきたいと思います。

開発者体験(Developer eXperience)向上の最前線〜ストレスなく働ける組織づくりとその結果〜

vpoereport

『VPoEが語るエンジニア組織づくり最前線vol.2』では、メガベンチャーでVPoEとして活躍する、エムスリー株式会社・山崎聡さん・株式会社マネーフォワードの渋谷 亮さんにご登壇いただき、VPoEとしてのミッションや組織づくりについて伺いました。

「リーダー育成は早いうちから」エムスリーとマネーフォワードのVPoEが組織づくりの教訓を語る

## 2021年初頭に起きていたこと
2021年初頭、<a href="https://findy-code.io" target="_blank" rel="noopener noreferrer">Findy</a>、<a href="https://findy-teams.com" target="_blank" rel="noopener noreferrer">Findy Teams</a>の開発プロセスは全体的に課題が多く、無数の課題に悩まされていました。

- リリースが毎週1回
- CIが回るのに30分
- ビルドするのに1時間
- ユニットテストカバレッジ30%
- プルリクがコンフリクトしやすい
- ファーストレビューまで3〜5日かかる
- JavaScript + FlowType
…

どれも課題は大きく、数年かけて直しながらプロダクトを作る必要ある…という状態でした。

## 2021年末の実績

2021年、ここで大きな決断をしました。新機能の開発をなるべく減らして、開発者体験を良くし、圧倒的に爆速で顧客価値提供をできるようにする。開発力2倍。

開発スピードを上げることで全てが解決するわけでもないですが、まずは単純に顧客価値提供が1週間で1回は少ないなというのを解消したい。小さな改善でもいいから秒で出していかないともったいない。初期は1人で作っていたのですぐに出せていた。あの感覚をチームでやりたい。

詳しくは過去の記事に書きましたが、

- リリースはフロントエンドで1日1〜2回、バックエンドも1日1回
- CIはフロントエンド最短30秒、バックエンドも最大10分
- リリースビルドは数分
- ユニットテストカバレッジ90%
- レビューは土日のバッファ入れても5時間
- TypeScript化

様々な課題を潰してきました。

プルリクエストが2021年初頭は1人1日平均0.8件のプルリク数でしたが、現在は1人あたり2.2件まで増えました。月間だと、1人あたり44件ほど作成し、99%が対処され放置されているプルリクがほぼない状態になりました。

## よかったこと: ユーザからの反応が圧倒的に良くなった
この開発者体験の向上を行った結果、2021年前半は特に無風でしたが、後半からは「ツイッターで呟いてからバク対応完了まで5時間は早すぎます(笑)」といった声だとか、「カスタマーサクセスの方にフィードバックするとすぐに実装してくれるのでフィードバックしがいがある」とまで言っていただけるようになりました。圧倒的に反応がよくなったなぁと思うことができるようになり、会社内でも「早いｗ」という声が多数出てくるようになりました。ありがたい。

フィードバックしても変わらない体験があるとどうしてもフィードバックしなくていいなと思っちゃいますが、変わるとわかると少しでも声あげやすくなるのかなと思います。実際に僕も反応が早いサービスなどはよくメッセージ送ったりしています。

その他にも、Findy社の採用も進めている中で、「Findyの開発は爆速って仰ってましたが、実際にお問い合わせ連絡してから爆速で修正完了の連絡が来たので受けに来ました」と仰ってもらうこともありました。

一重に、開発に関わってもらっている全てのメンバーの頑張りに感謝です。改めてありがとうございます。

2021年はスピード感ある開発ができるようになり、当初考えていた開発基盤の改修はできてきた、というところではありましたが、最近起きた課題もあります。

## 課題: 圧倒的に企画の量が足りない
2021年は佐藤の企画と仕様作成で回っていた状況でしたが、

- 開発基盤に関する課題が徐々に減ってきた結果、新規で機能が作れるようになった
- 新規で機能が作れるようになった結果、イシューが消化できるようになってきた
- イシューが消化できるようになってきた結果、企画のサイクルがボトルネックになってきた

という状況になりました。1年前には想像もしていなかったような課題が課題になりました。

- PdMの採用よりもエンジニアメンバーの採用に力を入れていた
- 企画メンバーがそこまで増えていなかった(大きな反省)
- かつ僕や代表の山田が企画も兼務していたが、別課題で時間が取られていた

エンジニアの採用も非常に大変ですが、PdMの採用も困っている方多いんじゃないでしょうか。弊社もやはりここは大変なポジションではあります…！ｗ

2022年の前半は企画スピードを上げるために、

- メンバーを育成して企画力を上げる
- メンバーを採用して企画チームを増やす
- 企画が増えるとデザインできるメンバーも必要になるので採用する

というような動き方が必要になりそうです。

この経験でわかったこととして、エンジニアリングの課題が解決すると、プロダクト開発全体の課題のどこかがボトルネックになっていくのだな、ということを身にしみて感じました。開発スピードがいきなり早くなったという経験が初めてだったので、早期に予見できなかったなぁと改めて反省です。

## 創業メンバーと一緒に企画づくりしたい方、PdMやりませんか？
ここからは宣伝ですが、上記のようなプロダクト開発のスピードを挙げていくために、代表の山田や僕と企画をしたいPdMの方いませんか？

- Findyのビジネスドメイン(エンジニア組織づくり、エンジニアのキャリア)に興味のある方
- 事業全体を見ながら企画し、爆速で意思決定したい方
- ユーザの声を聞きながら数値を見てトライアンドエラーしたい方
- Findyのバリューを体現できる方

是非興味ある方は<a href="https://herp.careers/v1/findy/orzBujKLKmq2" target="_blank" rel="noopener noreferrer">こちら</a>から！

是非お待ちしてます！

## 「開発スピードを上げる」ことは「爆速で顧客価値提供する」ための必要条件

<a href="https://findy-teams.com" target="_blank" rel="noopener noreferrer">Findy Teams</a>などで開発スピードを定期的に観測していくと、「数値を良くしないといけない！」となったりする方もいると思います。

開発スピードは早いに越したことはないですが、開発スピードを早くしようとして「ユーザに向けた機能提供や改善が0」「開発が遅くて開発の遅い人を咎める」などの本質からズレた状況になってしまうといくら開発スピードが早くてもユーザから見て価値はゼロです。何も変わってないサービスですよね。

エンジニアリングの範囲は企業によりますが、開発スピードを意識しながらいかにユーザの価値になっているかを考え続けられる組織が一番強いと思います。また、「開発をしない選択肢を取ることで開発スピードも考えなくて良くなる」のが費用的にもスピード的にも最強ですが…ｗ

エンジニアリングをやっているとユーザのことを棚に上げて自己投資を多くしてしまうこともあるかと思いますが、チームでサービスを提供する以上、様々な要素を考慮してユーザファーストのものを作れることがいいかと思います。それが前提での「開発スピードを上げるのももちろん大事で良いことである」というのが僕の答えです。

開発スピードは上がったことでトータルのユーザへの価値提供スピードも上がったのはとてもいいことではありますが、今の所Findyでは他の工程のスピードがボトルネックになっている状況です。つまりは改善が見込まれてくるなら先手を打って別な箇所の改善/全体最適を行うべき、というのが得られた結論でした。

とはいえ、今回の事象を通じて開発スピードを上げることは、全体最適とは必ずしも言えないが、よくボトルネックになりがちな開発スピードを上げることで価値提供スピードのインパクトを十分に上げることができるというのがわかりました。

開発スピードを上げるには、定量的に分析するのが最良だと思うので、是非<a href="https://findy-teams.com/" target="_blank" rel="noopener noreferrer">Findy Teams</a>を使って現状の自社の開発スピードを可視化していくのがおすすめです！

findy-speed-up-img

Findyで開発力を2倍にしていくぞ！と改善を繰り返した結果3倍の成果になったのですが、そこから得られた話を書いてみます。

記事一覧

データで振り返るエンジニア組織の生産性向上〜NewsPicks & PR TIMESの事例、DevOpsの取り組みからデプロイ頻度の計測まで〜

事業で勝つためのマネジメントとは。エンジニア組織づくりの裏側を一休伊藤氏とスタフェス柄沢氏に聞いてみた

ANDPAD TECH TALK 第11回 - 開発チームの生産性向上に取り組むスペシャリスト対談！後編可視化ツールを導入してみて分かったこと、そして今後の展望 - 株式会社アンドパッド

エンジニア組織の生産性の可視化とは？〜『DevOps指標』を活用しよう〜

開発者体験(Developer eXperience)向上の最前線〜ストレスなく働ける組織づくりとその結果〜

「リーダー育成は早いうちから」エムスリーとマネーフォワードのVPoEが組織づくりの教訓を語る

Findyの開発スピードが1年で約3倍になった結果、ユーザからの反応は格段に変わり、未知の課題にぶつかった

ペアプロでチームが変わった話 - 株式会社星野リゾート

バックオフィスチームにFindy Teamsを渡してみた - 株式会社星野リゾート

【ユニラボ】アイミツ開発チームのパフォーマンスをFindyTeamsで可視化してみた - 株式会社ユニラボ

記事一覧

データで振り返るエンジニア組織の生産性向上 〜NewsPicks & PR TIMESの事例、DevOpsの取り組みからデプロイ頻度の計測まで〜

事業で勝つためのマネジメントとは。エンジニア組織づくりの裏側を一休伊藤氏とスタフェス柄沢氏に聞いてみた

ANDPAD TECH TALK 第11回 - 開発チームの生産性向上に取り組むスペシャリスト対談！後編 可視化ツールを導入してみて分かったこと、そして今後の展望 - 株式会社アンドパッド

エンジニア組織の生産性の可視化とは？ 〜『DevOps指標』を活用しよう〜

開発者体験(Developer eXperience)向上の最前線〜ストレスなく働ける組織づくりとその結果〜

「リーダー育成は早いうちから」エムスリーとマネーフォワードのVPoEが組織づくりの教訓を語る

Findyの開発スピードが1年で約3倍になった結果、ユーザからの反応は格段に変わり、未知の課題にぶつかった

ペアプロでチームが変わった話 - 株式会社星野リゾート

バックオフィスチームにFindy Teamsを渡してみた - 株式会社星野リゾート

【ユニラボ】アイミツ開発チームのパフォーマンスをFindyTeamsで可視化してみた - 株式会社ユニラボ

データで振り返るエンジニア組織の生産性向上〜NewsPicks & PR TIMESの事例、DevOpsの取り組みからデプロイ頻度の計測まで〜

ANDPAD TECH TALK 第11回 - 開発チームの生産性向上に取り組むスペシャリスト対談！後編可視化ツールを導入してみて分かったこと、そして今後の展望 - 株式会社アンドパッド

エンジニア組織の生産性の可視化とは？〜『DevOps指標』を活用しよう〜