icare-kakehashi_event_2024/04/24_fv

Well-beingと生産性の関係性 - 指標にとらわれない心地よい環境づくり

> ## エンジニアリング組織として大事にしたいこと

僕らFindyの開発チームは大きく2つありますが、その中でも開発チームで大事にしたいことは、「爆速顧客価値提供」です。

いかに早く課題を見つけ、その課題を爆速で解決していくか、ということを念頭に置きながら開発業務を行っています。

こちらは7月から変わらず、継続の方針です。

大前提として、数値が全てではありませんが、振り返る上で大きな参考材料となります。数値を見てどう降り返るかを大事にしています。

## 2021年8月の実績

おおまかに、8月は21営業日あった中で、週5稼働しているメンバーは8名でした。
この状況下で、以下のような状態でした。

- リリース頻度 23.75回/month
- 1日あたり週5稼働メンバーで合計30プルリク、1人平均3.75プルリク/day
- 1日あたり週5稼働メンバーで合計117コミット、1人平均14.625コミット/day
- 平均プルリククローズ時間10.5時間
- 最初のコメントまでの平均時間3.2時間
- レビュー後クローズまでの平均時間5.2時間

それぞれいくつかのまとまりで振り返ってみます。

## リリース頻度 23.75回/月

- 開発Aチーム
  - バックエンド: 17リリース
  - フロントエンド: 30リリース
- 開発Bチーム
  - バックエンド: 25リリース
  - フロントエンド: 23リリース

ほぼほぼ毎日リリースできていたかと思います。

リリース自動化なども進めており、日々のQAコストも下がってきている成果が出ているように感じます。
今の所大きな課題もなく順調です。

## 1人 平均3.75プルリク/day、平均14.625コミット/day

7月と比べると、今月はプルリクの作成数とコミット数が少し減少しました。(とはいっても一定数あるので十分な量ではありますが…！)

8月は体調不良のメンバーがいたり、大きめの課題が多発し、課題解決まで時間がかかったケースが多かったと感じています。

体調不良の部分は各自体調を整えていくことが大事ではありますが、今月もワクチン接種などで休む予定のメンバーも居るため7月以上の平均の数を増やしていくのは難しそうです。

また、ユーザ数の増加によりお問い合わせの数も増え、開発メンバーが多少時間を取られたりすることもありました。こちらは企画側でもう少し対応できないかなど方法を検討中です。

課題が大きいものに関しては想定していたものでしたが、会社の成長を進めていく以上、すぐに取り組むべき課題となったので少ないメンバー数の中で対応することにしました。重いタスクをやっているとメンタル的にも苦しくなることがあるため、メンバーに負荷がかかりすぎないか9月は注視していきたいと思います。

## 平均プルリククローズ時間10.5時間、最初のコメントまでの平均時間3.2時間

先月と比べると、プルリクを出してから1.1時間ほど早くなりました。

プルリク作ってから10時間でマージまでいくとなると、月曜朝にプルリクを出して火曜にはマージされている状況です。あくまで平均になるため、ものすごく早いものと、日中の遅い夕方・夜の時間にプルリクを出して次の日にレビューされたり修正されたりなどするとこれくらいの時間がかかってくるのかなと思います。

1on1している限り、全体のレビューまでのスピードも十分なスピードで着手できており、着手後にもコメントを残すところまで行われている体制になっています。

## 総じて大きく変えなくてはいけない状況ではない

どの指標を見てもそこまで大きく課題はなく、十分いいサイクルで回せていると思います。

そこまで課題感のある時間ではないので、このまま継続して高スピードで開発サイクルを回せればと思います。

またメンバーが入ったタイミングなどで課題がまた可視化されるかと思うので、それまでは日々の1on1でメンバーと感覚をシェアしながら、数値ベースでも振り返っていければと思います。

## あなたのチームの平均プルリク作成数はどれくらいですか？

ここまでの情報は、<a href="https://findy-teams.com" target="_blank" rel="noopener noreferrer">Findy Teams</a>で開発をしている部分もあり、簡単にデータが取得できます。継続的に測定できるため、自分の指定する期間でデータが取れるようになっています。

もしご興味があれば、<a href="https://findy-teams.com" target="_blank" rel="noopener noreferrer">こちら</a>までお問い合わせください！！

## 圧倒的なスピードで開発できるFindyで働いてみませんか？

もしここまで読んでいただいて、少しでも話してみたいという方は是非一度カジュアル面談しませんか？

まだやりたいことがある中でまだまだ成長できる組織です！上記以外にも課題もあります！

是非興味があれば <a href="https://twitter.com/ma3tk" target="_blank" rel="noopener noreferrer">Twitter</a> でご連絡いただいたり、以下より直接ご応募いただいても大丈夫です👍

<a href="https://meety.net/ma/matches/MvtiQWbHRQsx" target="_blank" rel="noopener noreferrer">Meetyでのカジュアル面談はこちら</a>

エンジニアだけでも20人規模で募集しています。是非お気軽にどうぞ〜！

#### 【エンジニア組織全体】
- <a href="https://herp.careers/v1/findy/MH-u5skw__Ed" target="_blank" rel="noopener noreferrer">CTO候補</a>

#### 【Findy 転職】
- <a href="https://herp.careers/v1/findy/eRbKaEKEE6D6" target="_blank" rel="noopener noreferrer">エンジニアマネージャー</a>
- <a href="https://herp.careers/v1/findy/MgtDp5Eh2cYC" target="_blank" rel="noopener noreferrer">バックエンドエンジニア</a>
- <a href="https://herp.careers/v1/findy/H5DgEiQpboQ1" target="_blank" rel="noopener noreferrer">フロントエンドエンジニア</a>
- <a href="https://herp.careers/v1/findy/orzBujKLKmq2" target="_blank" rel="noopener noreferrer">プロダクトマネージャー</a>

#### 【Findy Teams】
- <a href="https://herp.careers/v1/findy/ypgJQ5_ObYex" target="_blank" rel="noopener noreferrer">エンジニアマネージャー</a>
- <a href="https://herp.careers/v1/findy/xOHUsVQEBA9R" target="_blank" rel="noopener noreferrer">バックエンドエンジニア</a>
- <a href="https://herp.careers/v1/findy/n3GYFS0yUnAH" target="_blank" rel="noopener noreferrer">フロントエンドエンジニア</a>


august

こんにちは、Findy CTO の @ma3tk です。 Findy Teams を使ったエンジニアリング組織の分析を8月も実施してみようと思います。

2021年8月 Findy エンジニアリング組織の振り返り

## エンジニアリングマネージャーの不足
エンジニア組織における最大の課題はそもそもマネージャー不足しているということです。
エンジニアとビジネスサイドの差分は何か、それはマネージャーになりたい人の割合が違うということではないでしょうか？

以下の表の通り、Findyのアンケート調査でもエンジニアの将来という意味では約半分がテックリード、スペシャリスト思考であり、マネジメント思考の人は15%弱と少ない結果になりました。
また、データを持っているわけではないですが、ビジネスサイドは専門性というよりは事業数字でコミットする仕事が多いため、結果的にマネージャーを目指す人が多いようです。

![careerpath](//images.contentful.com/ngrpflsbp3rq/4VyAGCtekROC0ecBG0c83W/e7602dd6d54987283c92a533a5a3f207/careerpath.png)

[平均年収は614万円、35%が副業経験あり！2020年のエンジニア転職・キャリアトレンド最前線](https://engineer-lab.findy-code.io/jobchange_trend_2020sp)

## マネージャーのマネジメント対象人数が増加
マネージャーが少ない結果何が起こってしまうのか。シンプルにマネジメント対象の人数が多くなってしまうことです。
スタートアップにおけるエンジニアリングマネージャーの採用は困難を極めており、結果的に社員15~20人くらいまでCTOがマネジメントや評価をしているというケースもあったりします。加えて、フリーランスエンジニアも数人契約しているというケースも。。。

またもう少し組織規模が大きいスタートアップ、メガベンチャーでも配下メンバーの人数が10人以上の組織はあるようです。

結果的に1週間のうち大半の予定が1on1やビジネスサイドとの調整に時間を使ってしまい、エンジニアリングマネージャーになったらコードを書く機会がなくなってしまったという話もよく聞きますね。
一般的にマネジメントの適正対象者は5~8人で、最大で10人と言われているので、エンジニアリングマネージャーは明確な統計は取れていないですが、マネジメント対象人数が多くなりがちです。

## 一人一人と向き合う時間の不足

また、当然ですがマネジメント対象者が増えると一人一人に向き合う時間は減ってしまいます。1on1が1回30分として、その準備や周辺のコミュニケーションで一人当たりミニマムで週1時間かかるとします。
メンバーが5人だと5時間、10人だと10時間、そして前述のスタートアップCTOだと20人で20時間。ここまで来ると一人当たりのサポートの時間を減らさざる得ないでしょう。
その結果、一人当たりのケアと言いますか、向き合う時間は減ってしまいます。

メンバーが技術で悩んでいるのか、社員との関係性で悩んでいるのか、あるいは家族のことで悩んでいるのかについても人数が少なければ記憶してサポートできますが、多くなるとキャパシティ超えを起こします。（自分も創業期に似た経験をしましたが、限界が5人という感覚で、それ以上は中間にマネージャーが必要でした。）

## リモートでマネジメントをすること難しさ

コロナ渦中でリモートワークが加速しています。Slackを利用したコミュニケーションの活性化や分報チャンネルを作ることで発信など工夫はできるものの、リアルと同じだけの情報量を得るのは難しいのも事実です。
コロナ初期は常時オンラインでつなげるという試みもありましたが、deployするタイミングなど含めて圧倒的に開発効率が落ちるので、非現実的ということも分かってきました。

もちろん、仕事の特性上、集中して作業ができるリモートが決して悪いわけではありません。
一方でマネジメントサイドからすると、オフィスにいると自然と入ってきた情報が敢えて聞かないと分からないということが増えるので、マネジメントの難易度は上がります。

また、エンジニアがフルリモートか一部リモートかはさておきリモートを活用していく流れはアフターコロナの世界でも維持されそうなので、リモートにおけるマネジメントにマネージャーが慣れていく必要がありそうです。

## 十分なサポートができないことによる退職者の増加

一番の懸念が十分なマネジメントや、結果的なサポートができないことによる退職者の増加です。採用競争がとにかく激しい昨今、どの会社もエンジニアに長く在籍してほしいと思っている会社が多い状況です。

以前に他社のエンジニアリングマネージャーの方と話している際にリモートが浸透する中で増えている「サブマリン退職」を防ぎたいという言葉を聞きました。
「サブマリン退職」というのは潜水艦の浮上の如く突然「退職」がやってくるという意味合いだそうです。「退職」という言葉を聞くタイミングですでに退職が決まっており、打てる手がもうないとのこと。

オフィスで接している「なんとなく調子悪そう」とか、「悩んでいそう」というのを発見するのはリモートよりは簡単だったりしますし、すぐにちょっと話そうとかランチ行こうなどと向き合う場を作ることができます。
結果的に回避できていた悩みなどが、リモートだと気づけないままに、進行してしまい、向き合って話すときには「退職」が決まっているというケースが増えているという声です。

以上、いかがでしたでしょうか？
エンジニアリングマネージャーの悩みあるあるのほんの一部をご紹介しました。
<a href="https://findy-teams.com" target="_blank" rel="noopener noreferrer">Findy Teams</a>では直接的に退職を防ぐようなサービスではありませんが、メンバーの日々の活動を可視化することで、早め早めの声がけ、フォローができる機能も実装しています。

ぜひぜひ、ご関心あるCTO、VPoE、エンジニアリングマネージャーの皆様は<a href="https://findy-teams.com" target="_blank" rel="noopener noreferrer">こちら</a>からお問い合わせください。

submarine

Findy Teamsというサービスを提供する中で、エンジニアリングマネージャーとお話をする機会が多くなっています。その中で、エンジニアリングマネージャーの悩みあるあるを書いてみようと思います。

エンジニアリングマネージャーの悩みあるある①〜マネジメント人数過多とサブマリン退職編〜

## プルリク作成数

GitHubベースに開発を進めている方だと当たり前に認識している部分だと思いますが、プルリクエストをどれだけ作るかで、エンジニアとして、チームとしてどれくらい開発が健全に回っているかがある程度見えてきます。

今回の作成数についてはマージされないものやドラフトのもの含めてすべてのプルリクエストを計測しています。

事前にお伝えすると、プルリク作成数などの数値を見てどう改善するかが大事であって、数値は参考にすべきものであるが絶対に達成しないといけない指標ではありません。数値が全てではなく、数値を見てどう動くかを考えたいという話です。

## Findyにおけるプルリク作成数の実績

Findyにおいて2021年8月は一人あたり78.8件のプルリクを作成していました。これは1日あたり3.94件となり、多くのプルリク数を作っていることがわかります。最も多いメンバーだと1日あたり8.45件のプルリクを作成しています。(計測して本当にびっくりですが…！)

いろいろな課題のあるチームだとプルリクがそもそも1日1件も出ずに業務が終了する、というケースがあったりしますが、Findyではなるべく多くのプルリクを出すようにしています。

8時間の稼働のうち2時間に1件くらいは作成するペースです。

## プルリク作成数を向上することによって得られること

プルリク作成数をただ上げるだけではなく、

1. 小さく分割する
2. レビューを全部同プルリクでやりきらない

ということも大事だったりします。

小さく分割されたプルリクを作り、プルリク作成数を最大化することで大きく5つの大きなメリットがあります。

1. 改善や修正などの頻度が増えることで価値提供までのスピードアップにつながる
2. プルリク肥大化を防ぐことでプルリク作成者の負荷を減らす
3. プルリク肥大化を防ぐことでレビュワーの負荷を減らす
4. コンフリクトのリスクを減らす
5. 「あの人何してるんだろう？」を減らす

一方で、

1. レビューの回数が多くなってしまう
2. 完成イメージがわかりにくくなってしまう

というデメリットも生じます。それぞれ解説してみます。

## 改善や修正などの頻度が増えることで価値提供までのスピードアップにつながる

これも毎日リリースなどをこなっているとしたら、プルリクの範囲を小さくしプルリクの作成数を多くすることで、できている範囲までで価値提供することができるようになります。

もちろんできている範囲が中途半端で価値提供にならないのであればそうとは限りませんが小さな修正などはまとめて他のタスクとやらずに個別に対応するなどで限りなく他の影響を減らして対応ができるようになります。

## プルリク肥大化を防ぐことでプルリク作成者の負荷を減らす

一気に大きな対応を行おうとすると、以下のようなことが起こります。

1. プルリクそのものが不要だったり方針が違うのに作りきるまでかかった時間が無駄になる
2. 複数の内容が入っていたりすると全部直したりしないといけない
3. CI/テストの影響範囲が広くなり修正箇所も多くなる
4. 作成する側に差し戻された内容が多いと精神的に重さを感じる
5. 一旦別のタスクをすると範囲が広いので対応している内容を時間の経過とともに忘れがち

プルリクが大きくなると実は作成者の自分にもダメージが出てきたりします。

## プルリク肥大化を防ぐことでレビュワーの負荷を減らす

これはいろんな方が体験したことがあると思いますが、大きすぎるプルリクを上げられると辛くなりますよね。

1. 大きすぎるプルリクが来ると「あとでレビューしよう」で放置されがち
2. 「いざやるか！」と思っても何を見ていいかわかりにくい
3. プルリク全体に関わるような共通化を同時に依頼するとまたレビュー最初からになりがち
4. ずっと同じことをレビューしているという状態が続く
5. 範囲が広いのでブラウザで全然diffが表示されず困る

たぶん優秀な人であっても大きいプルリクのレビューはしたくないはず…！

これが小さな範囲のプルリクであれば上記のような事は起こりにくくなるはずです。

## コンフリクトのリスクを減らす

コンフリクトしていたり、プルリクの滞留時間が伸びることで先にマージされた内容などを取り込みながら再度修正しないといけなかったりしますよね。

ライブラリのlockファイルや共通ファイルなどにも影響がいくとレビューする側も対応する側も「コンフリクト解消お願いします」と結構面倒なコミュニケーションをせざるを得なくなります。

なるべくコンフリクトを減らすことでコンフリクト解消コミット0化による安全な改修が可能になります。

## 「あの人何してるんだろう？」を減らす

これもリモートワークが推進されている環境だと尚更ですが、「あの人は何してるの？」という状態を減らしにいくことができます。

午前中はAの対応、午後はBとCのタスクの対応をしている状態とわかると進捗がはっきりしやすいため「何やってるかわからない」が減らせます。

これはプルリク作成者もそうですし、レビュワーもお互いにキャッチボールしやすい状態を作るとチームとしてストップしにくい状態になります。

## レビューの回数多くなってしまわない？

確かにデメリットとしてレビューの回数が多くなってしまうということです。

ただレビュワーとしては「ここだけ見ればいい」がはっきりしているため、1分あればレビューも大体完了するような状態にできます。

自分のプルリクも小さく回数を増やすことで「せっかくコード書いてるのにレビューばっかり」という状況も減らし、「ここまで書けたしレビュー依頼も来たし対応しよう」という状況を作ることができます。

全員が小さなプルリクをたくさん作ることでスピード感あるレビュー環境が作れます。

## 全体感がわかりにくくなってしまわない？

これはたしかに全体感がわかりにくくなってしまう可能性はありますが、自分が考えるに、プルリクの範囲が小さい状況のほうが相手の思考の過程を辿りやすくなるので背景やどうしてこういうアーキテクチャにしたのかなどを考えすぎなくて済むのかと思います。

## Findyのプルリク作成のベストプラクティス

- タスク着手時に気をつけること
  - GitHubのイシューにチェックボックス形式でタスクを羅列する
  - 羅列したタスクをエンジニアマネージャーやメンバーと合意する
  - チェックボックス1つにつき1プルリクを作る
- プルリク作成する時に気をつけること
  - なるべく粒度は小さくして最小限の範囲にする
  - 最低限のテストが通ることを保証したプルリクにする
  - リファクタや共通化なども別プルリクで対応する
  - 100行を超えるようなプルリク、ファイル数が10以上のプルリクは分割できないか考える
  - レビューすべきポイントをクリアにする
- レビューする時に気をつけること
  - 着手までの時間をボトルネックにしないためになるべく最速でレビューする
  - リファクタや共通化のコメントは行ってもいいが、同プルリクで対応を必須にしない
  - 設計の段階で大きく違いそうな場合はコメントを増やさずオンラインで相談

今のところ大きく思い浮かぶやり方はこのようなやり方です。

## 例: ユーザ一覧APIの新規作成

僕が過去にやっていた手順はこんな感じです。

1. コントローラーやモデル作成でユーザ一覧データが返るようにするプルリクの作成
2. リファクタや効率の悪い部分を同プルリクで修正し完了

これだと合計1プルリクで、上述したように作成する範囲ややるべきことがあっているか合意が取りにくく、割とやり直しリスクがある状態でちょっと改善が必要です。

なるべく小さくプルリクを分割してプルリク作成数を最大化して進めていくことを意識すると、

1. フロントでも使えるようにエンドポイントの設定と適当なjsonレスポンスのmockの作成プルリク+合意を取る
2. ユーザモデルマイグレーションのプルリク
3. ユーザ一覧取得処理のプルリク
4. mockの置き換えプルリク
5. ソート機能追加のプルリク
6. 絞り込み機能追加のプルリク
7. 共通化のプルリク
8. 非効率な部分解消のための効率化のプルリク

これくらい分割してプルリクを上げていくと数は増えますが、レビュー範囲は圧倒的に減りますし、それぞれ作成するまで短時間でdevelopにマージできるようになります。

イメージしていただけたでしょうか！？

## プルリクの分析機能をFindy Teamsで開発しています

ここまでの情報は、<a href="https://findy-teams.com" target="_blank" rel="noopener noreferrer">Findy Teams</a>で開発をしている部分もあり、簡単にデータが取得できます。継続的に測定できるため、自分の指定する期間でデータが取れるようになっています。

もしご興味があれば、<a href="https://findy-teams.com" target="_blank" rel="noopener noreferrer">こちら</a>までお問い合わせください！！

## 爆速顧客価値提供ができるFindyで働いてみませんか？

もしここまで読んでいただいて、少しでも話してみたいという方は是非一度カジュアル面談しませんか？

まだやりたいことがある中でまだまだ成長できる組織です！上記以外にも課題もあります！

是非興味があれば <a href="https://twitter.com/ma3tk" target="_blank" rel="noopener noreferrer">Twitter</a> でご連絡いただいたり、以下より直接ご応募いただいても大丈夫です👍

<a href="https://meety.net/ma/matches/MvtiQWbHRQsx" target="_blank" rel="noopener noreferrer">Meetyでのカジュアル面談はこちら</a>

エンジニアだけでも20人規模で募集しています。是非お気軽にどうぞ〜！

#### 【エンジニア組織全体】
- <a href="https://herp.careers/v1/findy/MH-u5skw__Ed" target="_blank" rel="noopener noreferrer">CTO候補</a>

#### 【Findy 転職】
- <a href="https://herp.careers/v1/findy/eRbKaEKEE6D6" target="_blank" rel="noopener noreferrer">エンジニアマネージャー</a>
- <a href="https://herp.careers/v1/findy/MgtDp5Eh2cYC" target="_blank" rel="noopener noreferrer">バックエンドエンジニア</a>
- <a href="https://herp.careers/v1/findy/H5DgEiQpboQ1" target="_blank" rel="noopener noreferrer">フロントエンドエンジニア</a>
- <a href="https://herp.careers/v1/findy/orzBujKLKmq2" target="_blank" rel="noopener noreferrer">プロダクトマネージャー</a>

#### 【Findy Teams】
- <a href="https://herp.careers/v1/findy/ypgJQ5_ObYex" target="_blank" rel="noopener noreferrer">エンジニアマネージャー</a>
- <a href="https://herp.careers/v1/findy/xOHUsVQEBA9R" target="_blank" rel="noopener noreferrer">バックエンドエンジニア</a>
- <a href="https://herp.careers/v1/findy/n3GYFS0yUnAH" target="_blank" rel="noopener noreferrer">フロントエンドエンジニア</a>


pullrequest

こんにちは、Findy CTO の @ma3tk です。 FindyではFindy社全体として大事にしているいちばん大事な開発指標として、プルリクエストの作成数があり、プルリクエスト作成数をベースに開発がうまくいっているかを議論し続けています。  プルリクエストの作成数とそれに紐づく議論について書いてみようと思います。

プルリクエストを作りまくることで得られたFindyの爆速プロダクト開発術

## エンジニアリング組織として大事にしたいこと

僕らFindyの開発チームは大きく2つありますが、その中でも開発チームで大事にしたいことは、「爆速顧客価値提供」です。

いかに早く課題を見つけ、その課題を爆速で解決していくか、ということを念頭に置きながら開発業務を行っています。

## 大きな指標: リリース頻度とプルリクの数と時間

大前提として、数値が全てではありません。

あくまで定量指標を材料にしながら、振り返りを行うことを一番大事にしています。

Findyで開発に向き合うために、3つの指標を大きな指標として日々追いかけながらタスクをこなしています。

- リリース頻度
- プルリク作成数
- プルリクマージまでの時間

これら以外にも大事な指標はありますが、3つを見るだけで結構わかる状態になっています。

## リリース頻度

リリース頻度がわかると、どれくらいの頻度で課題解決へ向けて進めているのかがわかります。この頻度はなるべく最大化しておきたいと考えています。

大きなリリースを行うと問題解決のために原因特定に時間がかかるため、なるべくリリースを疎な状態にしておくことで因果関係を発見しやすく、もしものときは切り戻しの範囲も少なくて済みます。

具体的に GitHub で以下のようなクエリを書くことで、リリースが行われたプルリク数が確認できます。

`is:pr is:merged "release" in:title created:2021-07-01..2021-07-31`

![backend-release-01](https://images.contentful.com/ngrpflsbp3rq/4uIzM5WoQsuT8p9ri2491z/0b5bbd666978921244232c48d60baa6e/____________________________2021-08-29_23.25.08.png)

弊社の2チームのデータは以下のようになりました。(2021年7月実績、平日数20日)

- 開発Aチーム
  - バックエンド: 26リリース
  - フロントエンド: 22リリース
- 開発Bチーム
  - バックエンド: 20リリース
  - フロントエンド: 23リリース

すべてのチームで1日1リリース以上行えている環境になっており、順調に開発が回っている状態と言っていいかと思います。

## マージされたプルリクの数

リリースの頻度も大事ですが、1回のリリースにどれだけ修正を追加できるかの平均的な指標としてはマージされたプルリク数も大事になります。

![merged-pull-2021-07](//images.contentful.com/ngrpflsbp3rq/2X3I1Kwq5Lz5Z3vQlfxlr3/b71dd0f3f40cc9d2cadd58e44fbcb7c0/____________________________2021-08-30_0.43.08.png)

2021年7月の20営業日の中で、868のマージ済みプルリクがあり、

- 週5稼働メンバー 9人
- 週3以下の稼働メンバー 5人

の7月は、平均すると1日1人平均4プルリクマージされる状態になっています。

1人あたりの平均を考えると相当な数プルリクを作り取り込まれている状態ではないかなと思います。

## プルリククローズまでの時間

リリース回数とマージされたプルリク数がある程度多い状態だと、このプルリククローズまでも時間が結構短い傾向にあると考えています。

Findyでは…

- すべてのエンジニア: 16.1時間
- 週5稼働メンバー: 11.6時間

でした。土日も含んだ状態なので金曜日に出したプルリクなどは2日分レビューされない状態だったりするので、そういった時間も含めたデータが上記になります。

直近6ヶ月のデータも平均10.4時間でプルリククローズまでいくスピード感で開発できています。

もし課題が出てくる場合には、

- そもそもコミット作ってからプルリク作成までの時間が遅い
- プルリク作成からレビューまでの時間が遅い
- レビューから修正までの時間が遅い
- すべてで遅い

などになってきますが、弊社では1on1などで聞く限り、どれも大きな課題にはなっていない状態です。

## これらの機能をFindy Teamsで開発しています

ここまでの情報は、<a href="https://findy-teams.com" target="_blank" rel="noopener noreferrer">Findy Teams</a>で開発をしている部分もあり、簡単にデータが取得できます。継続的に測定できるため、自分の指定する期間でデータが取れるようになっています。

もしご興味があれば、<a href="https://findy-teams.com" target="_blank" rel="noopener noreferrer">こちら</a>までお問い合わせください！！

## 爆速顧客価値提供ができるFindyで働いてみませんか？

もしここまで読んでいただいて、少しでも話してみたいという方は是非一度カジュアル面談しませんか？

まだやりたいことがある中でまだまだ成長できる組織です！上記以外にも課題もあります！

是非興味があれば <a href="https://twitter.com/ma3tk" target="_blank" rel="noopener noreferrer">Twitter</a> でご連絡いただいたり、以下より直接ご応募いただいても大丈夫です👍

<a href="https://meety.net/ma/matches/MvtiQWbHRQsx" target="_blank" rel="noopener noreferrer">Meetyでのカジュアル面談はこちら</a>

エンジニアだけでも20人規模で募集しています。是非お気軽にどうぞ〜！

#### 【エンジニア組織全体】
- <a href="https://herp.careers/v1/findy/MH-u5skw__Ed" target="_blank" rel="noopener noreferrer">CTO候補</a>

#### 【Findy 転職】
- <a href="https://herp.careers/v1/findy/eRbKaEKEE6D6" target="_blank" rel="noopener noreferrer">エンジニアマネージャー</a>
- <a href="https://herp.careers/v1/findy/MgtDp5Eh2cYC" target="_blank" rel="noopener noreferrer">バックエンドエンジニア</a>
- <a href="https://herp.careers/v1/findy/H5DgEiQpboQ1" target="_blank" rel="noopener noreferrer">フロントエンドエンジニア</a>
- <a href="https://herp.careers/v1/findy/orzBujKLKmq2" target="_blank" rel="noopener noreferrer">プロダクトマネージャー</a>

#### 【Findy Teams】
- <a href="https://herp.careers/v1/findy/ypgJQ5_ObYex" target="_blank" rel="noopener noreferrer">エンジニアマネージャー</a>
- <a href="https://herp.careers/v1/findy/xOHUsVQEBA9R" target="_blank" rel="noopener noreferrer">バックエンドエンジニア</a>
- <a href="https://herp.careers/v1/findy/n3GYFS0yUnAH" target="_blank" rel="noopener noreferrer">フロントエンドエンジニア</a>


july

こんにちは、Findy CTO の @ma3tk です。 Findy では Findy Teams を使ったエンジニアリング組織の分析を行っていたりします。  今回はその一部を公開したいと思います。

2021年7月 Findy エンジニアリング組織の振り返り

## エンジニアを20人以上も採用する背景
現在、Findyでは開発メンバーは10人弱ですが、今後サービスの展開で様々な展開が必要になってきます。その背景として、大きくは3つの理由からです。

- サービス利用エンジニアユーザ、企業、そして自社メンバーなど利用者が増えたため
- やりたいことがやるべきことになり、サービスの拡張性が求められているため
- 開発基盤が一定整ってきてはいるが、さらに来年に向けた投資が必要なため

特に1つ目のユーザ数の増加によるデータをいかに爆速で捌いて価値ある情報をすべてのタイプの利用者に提供し続けるかがプロダクト開発視点で求められるようになりました。

コーディングやチーム開発でのエンジニアリングは改善できてきていますが、プロダクト全体の方針などを改めて見直していくと、やるべきことが無限に湧いてきます。

やるべきことが明確にわかっている中で単純に一緒にこの課題を解決してくれるメンバーが足りていない、という状態です。

## そんなFindyで働く魅力とは？

### 1. 圧倒的爆速価値提供が出来る開発者体験
課題が上がってからコードを直してプロダクトリリースを行うまでの速さは会社全体で最短1時間で安全にリリース可能。平均でも3時間〜半日あれば軽微なものなら当日リリースできる状態ですし、かかっても数日で解決というようなスピード感でできます。

- 土日含め、プルリク作って7時間内のdevelopマージ
- レビュー完了まで最速15秒。平均数時間でレビューが完了する体制
- CI環境も10分内で全てのプロダクトのCIがまわる状況

早すぎワロタ、と言ってもらえる体制はまずはできてます。

### 2. 新しい技術への積極的なチャレンジと伸びるサービスでの学べる環境
最近ではGraphQLの利用が当たり前な状況になってきました。FindyでもGraphQLを使いフロントエンドとバックエンドのシームレスな開発も行い始めています。

大規模なデータ量とエンジニア向けサービスに必要なGitHub APIとその制約下でのチャレンジングなバックエンド開発。TypeScript下でのNext.jsやNxでのモノレポ開発。GitHub Actions 100%での作業効率化。

今年も様々なチャレンジを行っていますが、まだまだチャレンジしていきたいと思います。組織やサービスの成長に合わせて、どんな意思決定をすべきかなどが学べる環境です。

### 3. 優秀なメンバーが続々とジョイン中
最近入社したり関わってくれているメンバーのレベルも非常に高いメンバーばかりです。

Nxコントリビュータや他社でCTOをしているメンバー、開発経験10年以上のメンバーも多数在籍しています。レベルの高い議論をしながら自主的にやるべきことを見つけ、進んでプルリクを作って解決をしています。

前向き、誠実、チームワーク、スピード、No.1のFindyの5つのバリューを体現できるメンバーばかりです。

### 4. すぐにフォローしあう体制
分報を利用したメンバー間のコミュニケーションが活発で、詰まった時に即レスしてもらえる環境です。

メンバーが詰まっている時に「あーXXがわからないな、どうなってるんだ」というような投稿をすると修行中のメンバーには積極的に「ここみるといいよ」などフォローしているケースが多いです。

開発に集中しながら他人の悩みにも協力できる相互協力・チームワーク環境が揃っています。

### 5. エンジニアフレンドリーな環境
経営者、他職種ともにエンジニアフレンドリーな環境で社内受託化せずに全員でプロダクトに向き合える環境です。

営業メンバーとエンジニアが対等に話し、対等に意思決定ができます。というのも、Findyのお客様はエンジニアやそれに準ずる職種の方が多いため、エンジニアに対して理解が強い会社です。

https://engineering-org.findy-teams.com/posts/engineer-business-relationship/

詳しくは上記に記載しておりますので見てみてください。

### 6. エンジニア向けのプロダクト = 自分がターゲットユーザー

これはFindyの最大の魅力ですが、エンジニアであればほとんど自分がターゲットユーザーであり、なにか改善する時に「ユーザはどう言っているか」を強く気にしすぎなくても「自分はこう思う、なぜなら自分が転職活動する時にこうだから、エンジニアはこうだから」という理由ででもサービス改善しやすい環境です。

自分がターゲットユーザーでかつ本当にほしいサービスを作れる環境、Findyオリジナルの魅力と言っても過言ではありません。

僕は過去そうやって開発してきましたが、今まで作った中で一番開発しやすいなと思っています。

## 働きがいのあるFindyで働いてみませんか？
もしここまで読んでいただいて、少しでも話してみたいという方は是非一度カジュアル面談しませんか？

まだやりたいことがある中でサービスが育っていっている状況が非常にやりがいがある組織になっています！

是非興味があれば <a href="https://twitter.com/ma3tk" target="_blank" rel="noopener noreferrer">Twitter</a> でご連絡いただいたり、以下より直接ご応募いただいても大丈夫です👍

<a href="https://meety.net/ma/matches/MvtiQWbHRQsx" target="_blank" rel="noopener noreferrer">Meetyでのカジュアル面談はこちら</a>

エンジニアだけでも20人規模で募集しています。是非お気軽にどうぞ〜！

#### 【エンジニア組織全体】
- <a href="https://herp.careers/v1/findy/MH-u5skw__Ed" target="_blank" rel="noopener noreferrer">CTO候補</a>

#### 【Findy 転職】
- <a href="https://herp.careers/v1/findy/eRbKaEKEE6D6" target="_blank" rel="noopener noreferrer">エンジニアマネージャー</a>
- <a href="https://herp.careers/v1/findy/MgtDp5Eh2cYC" target="_blank" rel="noopener noreferrer">バックエンドエンジニア</a>
- <a href="https://herp.careers/v1/findy/H5DgEiQpboQ1" target="_blank" rel="noopener noreferrer">フロントエンドエンジニア</a>
- <a href="https://herp.careers/v1/findy/orzBujKLKmq2" target="_blank" rel="noopener noreferrer">プロダクトマネージャー</a>

#### 【Findy Teams】
- <a href="https://herp.careers/v1/findy/ypgJQ5_ObYex" target="_blank" rel="noopener noreferrer">エンジニアマネージャー</a>
- <a href="https://herp.careers/v1/findy/xOHUsVQEBA9R" target="_blank" rel="noopener noreferrer">バックエンドエンジニア</a>
- <a href="https://herp.careers/v1/findy/n3GYFS0yUnAH" target="_blank" rel="noopener noreferrer">フロントエンドエンジニア</a>


findy-eng

こんにちは、Findy CTO の @ma3tk です。 Findyではエンジニア関連職種を1年で20人以上採用していく予定です。  さて、そんな今のFindyの組織で働く上でどんなメリットがあるのかについて書いてみます。

20人のエンジニアを募集！Findyで働く魅力を洗い出してみた

## Findyの開発組織は大きく2つある

今Findyでは2つの開発組織があり、それぞれフェーズが違う開発を行っています。

- プロダクト開発チーム
- Findy Teams プロダクト開発チーム

それぞれで周りのメンバーとの関わり方が違うのですが、特にプロダクト開発チームの方では複数のチームのビジネスサイドメンバーと開発を進めています。

## 主体的に意思決定しながら施策を進める関係性

主に開発チームは大きく、

- エンジニアユーザのマーケティングのマーケティングチーム
- エンジニアユーザ向き合いのユーザサクセスチーム
- 企業向き合いのカスタマーサクセスチーム

などを中心にコミュニケーションを取りながら開発を進めています。

複数のチームと関わりがあると、

- あんな施策をしたい、こんな施策をしたいという多方面からの要望
- とはいえ開発的にも負債化する前に解消したい技術的課題
- 全部をひっくるめて「どれをやる？」という優先順位の決定

が気になってきます。

しかしながら、弊社のビジネスサイドのチームはどこも **「わかりました、では開発基盤の方を優先しましょう」** と言ってくれたり、  **「モチベーションが上がる状態で開発進めたいですよね」** とエンジニアリングに理解のある中で開発を進められています。

関係性が上手くいっていないとどうしても新規開発の優先度が高いまま開発チームが進めたいリファクタや負債の解消などに時間が取れなかったり、社内受託開発状態になり、言われるがまま作る状態になりかねません。

Findyはエンジニアのサービスやエンジニア採用サービスの側面を持っているため、エンジニアにとっていい環境づくりができている状態です。

## エンジニアファーストではなく、ユーザへの価値提供ファースト

そんな開発の思いもありながら、エンジニアファーストの組織にするとどうしても基盤改修やリファクタなどに時間を使ってしまい、ユーザにとっての価値が提供できないという状態になることもあります。

技術をずっと触っているから良いコードを書き続ける、メンテし続けるのは非常に重要ですが、それ以上にユーザに価値提供するスピードを高速化することが一番大事です。

最初から作りすぎない、ずっと負債を放置しない。どちらにも偏りすぎない絶妙なバランスでサービスを作っていける組織で居続けたいなと思っています。

## ビジネスサイドの技術理解も高いこと

まだまだビジネスサイドがいい関係になっている背景も書いてみたいと思います。

### エンジニアリングの知識をインプットするビジネスサイド

弊社の営業メンバーは相対する顧客がエンジニアもしくはエンジニア採用担当者です。 そのため、ほとんど初期の段階でエンジニアの用語の基礎をインプットした上で業務を進めています。

例えば、

- Dockerとはどんな技術なのかの触りを知っている
- SREってどんな職業なのかを知っている
- フロントエンドの特徴がどんなことなのか知っている

など、もちろんエンジニアほど深い知見を持つわけではないですが、大体どこの事を話しているのか、そのキーワードではどんな採用市場では動向があるのかなどを理解しているため、Findyのエンジニアともよく会話していたりします。

そのため、インプットした上でサービスの施策を議論できるため、どれだけ大きなことをやろうとしているのか理解してもらいやすい状況です。

### 仕様作成もビジネスサイドで行う

エンジニアだけが要件から仕様に落とすのではなく、全社的にビジネスサイドが仕様作成まで行っています。

そのため、初期状態やこんなときにどうなるかなどもエンジニア任せにせず、ユーザの価値提供を最初から最後まで考えた上で企画を練ってくれます。

エンジニア発の企画も今後増やしていきながら、ユーザにとってどんないい価値をすぐに提供できるかを考えながら全社的に仕様を考えていきたいと思います。

## エンジニアも厳しく言わず、ビジネスサイドも時間に余裕をもって進める組織

よく聞くような組織だと、

- ビジネスサイドがエンジニアに相談するとエンジニアがものすごく厳しい言い方で仕様を詰めてきたり、細かいところを指摘して相談しにくい
- ビジネスサイドが主導権を握っていて、期限に余裕がないまま進めたり、想定外の開発業務が発生すると詰められる

などがあったりします。

Findyでは、

- 健全に開発内容を相談しながら開発を進められる組織
- 想定外の開発業務があっても理解してもらえる

状況にあります。プロダクト開発に課題がないわけではないですが、今は技術的な課題に対して真摯に向き合える状況になっています。

## ビジネスサイドとの関係性がいい組織で働きませんか？

もしここまで読んでいただいて、少しでも話してみたいという方は是非一度カジュアル面談しませんか？

まだやりたいことがある中でサービスが育っていっている状況が非常にやりがいがある組織になっています！

是非興味があれば <a href="https://twitter.com/ma3tk" target="_blank" rel="noopener noreferrer">Twitter</a> でご連絡いただいたり、以下より直接ご応募いただいても大丈夫です👍

エンジニアだけでも20人規模で募集しています。是非お気軽にどうぞ〜！

#### 【エンジニア組織全体】
- <a href="https://herp.careers/v1/findy/MH-u5skw__Ed" target="_blank" rel="noopener noreferrer">CTO候補</a>

#### 【Findy 転職】
- <a href="https://herp.careers/v1/findy/eRbKaEKEE6D6" target="_blank" rel="noopener noreferrer">エンジニアマネージャー</a>
- <a href="https://herp.careers/v1/findy/MgtDp5Eh2cYC" target="_blank" rel="noopener noreferrer">バックエンドエンジニア</a>
- <a href="https://herp.careers/v1/findy/H5DgEiQpboQ1" target="_blank" rel="noopener noreferrer">フロントエンドエンジニア</a>
- <a href="https://herp.careers/v1/findy/orzBujKLKmq2" target="_blank" rel="noopener noreferrer">プロダクトマネージャー</a>

#### 【Findy Teams】
- <a href="https://herp.careers/v1/findy/ypgJQ5_ObYex" target="_blank" rel="noopener noreferrer">エンジニアマネージャー</a>
- <a href="https://herp.careers/v1/findy/xOHUsVQEBA9R" target="_blank" rel="noopener noreferrer">バックエンドエンジニア</a>
- <a href="https://herp.careers/v1/findy/n3GYFS0yUnAH" target="_blank" rel="noopener noreferrer">フロントエンドエンジニア</a>


relationship

みなさんの会社ではプロダクト開発どのようにお仕事を進めているでしょうか？ 様々なエンジニア組織があると思いますが、Findyの開発組織とビジネスサイドとの関係性について書いてみます。

記事一覧

2021年8月 Findy エンジニアリング組織の振り返り

エンジニアリングマネージャーの悩みあるある①〜マネジメント人数過多とサブマリン退職編〜

プルリクエストを作りまくることで得られたFindyの爆速プロダクト開発術

2021年7月 Findy エンジニアリング組織の振り返り

20人のエンジニアを募集！Findyで働く魅力を洗い出してみた

Findyのエンジニアとビジネスサイドの良好な関係性