## 開発者体験の改善

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

- <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倍の成果になったのですが、そこから得られた話を書いてみます。

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

## 前提: 営業ほど簡単に決められない、測りにくい

営業の目標設定ってわりと「売上:XX万円達成」で計測しやすいですよね。

一方で管理部門やデザイナー、そしてエンジニアは目標設定がなかなか難しい職種ではあります。

エンジニアですと、「1行のコードを書いた＝売上XX円」が分かるのであれば簡単なのですが、世の中そんなうまくいきません。

だからこそエンジニアの成長度合いを、目標設定と振り返りを常に実施することで可視化し、「過去の自分と比べてどのくらい成長できたか？」を確認することが大事だと思っています。

今回はプロダクト開発において、[Findy Teams](https://findy-teams.com/dashboard)を活用してどのように目標設計をして、どんな振り返りをやっているのかについてまとめてみました。

※Findy Teamsサービスの詳細は以下よりご覧いただけます。
https://findy-teams.com/service_introduction

※Findy Teamsのサービス画面は以下よりご覧いただけます。
https://findy-teams.com/dashboard

## やったこと① Findy Teamsで可能な限り計測できる指標を追う

例えば、「バックエンド開発を頑張る」という一言だけでは、何をどう頑張ったらリーダー・メンバーの双方が納得のいく「頑張り」になるのかが分かりません。

特に良いコードを書いたり、チーム開発ができてる場合に、[Findy Teams](https://findy-teams.com/dashboard)で追うと良さそうな指標としては以下が挙げられます。

### アクティビティ量
  - **プルリク作成数**
      - どれだけ変更提案したか？の数
      - 変更提案数が多ければ多いほど進化している、という前提
      - 1日1プルリクを追うであったり、定常的に毎日コード書けてるかを確認
  - **自分がレビューしたプルリク数**
      - 人のコードをどれくらい読んだか？の数
      - 読めば読むほど時間はかかるが学びにつながる、という前提
  - **1プルリクに対する平均コメント数**
      - 他の人からどれだけツッコミが入るか？の数
      - 提案に対して意見がなければ、コメント数も少なくなりやすい
      - 逆にジュニアなメンバーだとコメント数が多くなりやすい

### リードタイム
  - **1プルリクあたりの平均マージ・クローズ時間**
      - 変更提案してから提案が受け入れられるまでの時間
      - 変更提案したものに物議を醸す場合や修正に手間取る場合、この時間が遅くなる事が多い
      - 優秀な人ほど端的に狭い範囲で良いコードを書くため、この時間が短い傾向にある
  - **最初のコミットからプルリク作成までの平均時間**
      - コードを書き始めてから変更提案するまでの時間
      - 変更提案したいものを作るまでにどれくらいの時間を要しているかが分かるので、力量が把握しやすい
      - 同様に優秀な人はこの時間が短い傾向にある
  - **プルリク作成からレビューまでの平均時間**
      - 他人のレビューをすっぽかして他人の待ち時間を増やしていないか？かが分かる
      - この数値が遅い要因は、①レビュー依頼をできていないか、②依頼はしたがレビュワーが気づいていないのか、③レビュワーは気づいているものの手元のタスク消化等を優先して着手してくれていないのか、のいずれか
      - 爆速でレビューする体制になっているチームほど健全

もっとありますが、ベーシックなところはこんな感じです。

メンバーは、この指標のいずれかで課題がありそうなものや定点観測すべきものをリーダーと相談して選び、自分の目標を作ります。（=メンバーとリーダーの期待値の目線合わせ）

### 目標設計のサンプル
- 目標の方向性:高速開発を実現し、顧客への価値提供スピードを上げる
- 観測する指標: **一ヶ月あたりのプルリク作成数**
- 目標値: 半期終了時点で現状の2倍が最大目標。最低でも1.5倍

- 月別の目標(最小-最大、一ヶ月あたりのプルリク作成数)
  - 1月（前期初）: 40 - 50
  - 2月: 50 - 65
  - 3月: 55 - 70
  - 4月: 65 - 80
  - 5月（前期末）: 70 - 85

- ※昨年参考
  - 9月: 40(リリース込45)
  - 10月: 35(リリース込40)
  - 11月: 45(リリース込50)
  - 12月: 60(リリース込90)

- 評価点（評価分類は各社によって異なりますが､､､）
  - 7:120プルリク以上
  - 6:90プルリク〜120プルリク未満
  - 5:72プルリク〜90プルリク未満
  - 4:60プルリク〜72プルリク未満
  - 3:42プルリク〜60プルリク未満
  - 2:30プルリク〜42プルリク未満
  - 1:30プルリク未満

※数値化しやすいものは定量評価にて数値化し、定性的なもの（新技術提案や外部発信の影響力を上げる、計測が難しいマインド等）は定性評価にするなど、評価方法を分けていました。

※Findy Teamsサービスの詳細は以下よりご覧いただけます。
https://findy-teams.com/service_introduction

※Findy Teamsのサービス画面は以下よりご覧いただけます。
https://findy-teams.com/dashboard

## やったこと② 毎月の1on1で定点観測してメンバー自身に振り返ってもらう

メンバーとの1on1は毎週行っていましたが、月初の1on1だけは目標の振り返りを行っていました。

【4月時点での振り返りイメージ】
- 1月: 47　→お問い合わせ対応が多く想定よりプルリク作成数を増やせなかったので、△
- 2月: 62　→細かい改修が多く対応した数が多かったので、◯
- 3月: 59　→差し込みの調査が多い中で、ギリギリ◯
- 4月: 54　→チャレンジしたことないタスクを実施したため、下がった△
- 5月:
- 6月:

【考察】
- 2月の増加要因
  -  確認や調整などが少なかったため
  - 　企画A → マーケ/フロントエンドとの調整を先に実施できたため
  - 　メールの改修 → 想定より簡単に切り出して開発できたため

- 3-4月の減少傾向の要因
  - 　新規のタスクや差し込みが多く開発時間の確保が難しかった
  - 　チャレンジタスクが多かったので難易度が上がった
  - 　一方で不具合対応などによる修正対応PRの増加もあり、極端に減少はしなかった

上記のようにまとめておくと、最後に総括がしやすくなります。

※Findy Teamsサービスの詳細は以下よりご覧いただけます。
https://findy-teams.com/service_introduction

※Findy Teamsのサービス画面は以下よりご覧いただけます。
https://findy-teams.com/dashboard

## やったこと③ 振り返って目標を変更・追加する

目標設定から何ヶ月か経過すると、「 <span class="cyan">目標が無謀すぎる</span> 」「 <span class="cyan">一瞬であのタスクやらなくなった</span> 」等が発生し、目標が意味を成さなくなる事もあるかと思います。

なので、最初に2つか3つくらいの目標にしておきながら、

1. 既存の目標の100%達成の目標値を上方・下方修正する（下方したら新しい目標を置くことをセットにしていました）
2. やらなくなったタスクの代わりに、3つ目や4つ目の目標として新しく目標を作る

等の運用にすることで、目標を常にアップデートできるようになります。

例えば、「1月にプルリク作成数の目標を60と設定したにもかかわらず、3月にはお問い合わせがチームで課題になり、対応を率先してやっていきたいと思う」となった時に、

- お問い合わせにかかる工数は毎日1時間〜2時間程度
- 現状のプルリク作成1つに対して2時間程度かかるものが多いので、1日1つ減らす
- 期中の4月以降以降は平均40プルリク作成に落とす

と目標をアップデートして、1on1でメンバー・リーダーで目線合わせをすると良いのかなと思っています。

すると期末には以下の様な状況になります。

- 目標は実態に応じて毎月すり合わせてるので、目標と実態のブレとしては最大1ヶ月程度
- メンバーは結果を毎月振り返って記載しているので、半年前の状況を思い出す必要がない（思い出すのは結構大変）
- メンバーは自分の推移がわかるので、次期に向けて目標を定量的に考えやすい
- リーダーは過程を見ているので直近のパフォーマンスだけを見て評価することを回避できる（評価は、往々にして直近のパフォーマンスに引っ張られがちかなと思います）
- リーダーは他の部署とのすり合わせ時に、メンバーの評価結果の妥当性を伝えやすくなる（チームによって、タスク難易度や繁閑度合いは変化するものの、[Findy Teams](https://findy-teams.com/dashboard)の指標を統一指標として用いることができるため）

など。

逆にこのすり合わせを適当に行っているとコミュニケーションに差が出て「リーダーは分かってくれない」「メンバーが頑張ってくれない」という、<span class="cyan">認識ギャップ</span>が減るのではないかなと思います。

※Findy Teamsサービスの詳細は以下よりご覧いただけます。
https://findy-teams.com/service_introduction

※Findy Teamsのサービス画面は以下よりご覧いただけます。
https://findy-teams.com/dashboard

## まとめ

過去に様々なCTOの方と話してきましたが、この目標設定と振り返りの過程でいちばん大事なのは「 <span class="cyan">お互いの納得感</span> 」ということであるのがわかったのが2020年で、そこから2021年はどう納得感を作るかにトライしてきました。

これはエンジニアであってもなくても変わらなくて、お互いの期待値を何度もすり合わせ続ける（=期待値合わせ）ことが大事なのではないかと思っています。
この期待値合わせのための定量的な指標として[Findy Teams](https://findy-teams.com/dashboard)をお使いいただくと、客観的な視点で議論してすり合わせができるため、良いのではないかと思います。

- リーダーはどんなことを期待するのかを明確にして伝える
    - ex. まずはこの半年でバックエンド開発においてどんなタスクがきても一定こなせる状況を期待する、等
- メンバーは
    1. 半年後、一年後どうなりたいのかを考える
        - ex. テックリード？新しい領域としてフロントエンド？EM？…
    2. 半年後、一年後になりたい自分になるためにクリアしなきゃいけない課題は何かを考え続ける
        - ex. 簡単な改修含めてレビューの件数を減らしていく
        - ex. アウトプット量（プルリク作成数等）を増やしていく
        - ex. 安定して高パフォーマンスを発揮できるようになる

これをやり続けることで、期末にリーダーから「全然やれてないよね？」vsメンバーの「やってって言われたことやったんだけど全然認識違う」という<span class="cyan">認識ギャップ</span>が発生しにくくなります。

常に自分のなりたい像をリーダーに伝え続けて、どうすべきかを真剣に考えて、それをアップデートし続ける状態がいいなと思っています。

人間だし、特にスタートアップに来てる人なんてやりたいことが変わったりしやすいと思います。

変わった瞬間や変わりそうな瞬間や悩んだ瞬間にリーダーと話したり、周りの信頼できるメンバーと話して常に悩みを解決できる状態を作っていきたいですし、そのための定量的な指標として[Findy Teams](https://findy-teams.com/dashboard)を使ってみてはいかがでしょうか！

※Findy Teamsに関するお問合せはこちら
https://findy-teams.com/contact_teams

※Findy Teamsサービスの詳細は以下よりご覧いただけます。
https://findy-teams.com/service_introduction

※Findy Teamsのサービス画面は以下よりご覧いただけます。
https://findy-teams.com/dashboard

FindyTeams_MBO_2021振り返り

こんにちは、Findy CTO の @ma3tk です。 FindyではFindy Teamsを活用したエンジニアの目標設定に取り組み始めましたので、具体的な活用方法にも触れつつ、お話したいと思います。

データを活用した目標設計と運用にトライした1年間を振り返ってみた

## パネリスト
### 川口 賢太郎さん
三菱重工業株式会社 成長推進室　デジタルエクスペリエンス推進室　室長
大学・大学院で建築デザインを専攻、三菱重工業入社後は建築デザイナーとしてさいたまスーパーアリーナなどを担当。その後、MBAにてアントレプレナーシップファイナンスを専攻、製品開発・事業開発に担当業務を移行する。現在はジェネラルマネージャーとしてデジタルエクスペリエンスデザインに取り組んでいる。趣味は忌野清志郎。
[参考記事](https://findy-code.io/pick-up/interviews/MHI-engineer)
<div class="is-left">
<img src="//images.ctfassets.net/ngrpflsbp3rq/506ri12VOVmOnSnwYiRmdM/bd31edd5bb440a1b93a317e93f62c418/_________________________.jpg" width="200" />
</div>

---

### 廣政 貴一さん
三菱重工業株式会社 共通基盤領域エンジニア
新卒でメーカーに入社し、エンジニアとして主にソフトウェア開発環境の構築・運用に従事。2020年11月に三菱重工入社。現在は共通基盤領域のエンジニアとしてインフラ構築等に従事。趣味はF1観戦。
<div class="is-left">
<img src="//images.ctfassets.net/ngrpflsbp3rq/5nCkzRuhaxQ8kqyuj6PVQJ/c570f89665f5cc7987747aa4ea3bd0c3/________________________________.png" width="200" />
</div>

---

### 森岡 周平さん
三菱重工業株式会社 サーバーサイドエンジニア
いくつかのベンチャー企業を経て2020年7月 三菱重工入社。 現在はIoTシステムのテックリードを務める。
<div class="is-left">
<img src="//images.ctfassets.net/ngrpflsbp3rq/16VLIsqkFtfS8I8iybzBi5/714a8b18080716d0594ed5ec40d914e8/___________________________.png" width="200" />
</div>

---

### 山田 悠太さん
三菱重工業株式会社 サーバーサイドエンジニア
SIer、Web系のパッケージソフトの会社を経て、2020年8月に三菱重工に入社。 現在はCRMチームで、リードエンジニアとスクラムマスターを兼務し、とある事業部と共に社外へ公開するシステムを構築中。 最近、[社外発表](https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15358)をしたりもしていた。
<div class="is-left">
<img src="//images.ctfassets.net/ngrpflsbp3rq/45MgEmaxD7vNJyQYI1SxQs/c90fa3894fb77b8aa60b08e9dd2585e8/_________________________.jpg" width="200" />
</div>

## モデレーター
### 山田 裕一朗
同志社大学経済学部卒業後、三菱重工業、ボストン コンサルティング グループを経て2010年、創業期のレアジョブ入社。 レアジョブでは執行役員として人事、マーケティング、ブラジル事業、三井物産との資本業務提携等を担当。 その後、ファインディ株式会社を創業。求人票の解析とアルゴリズムづくりが趣味。
[参考記事](https://www.nikkei.com/article/DGKKZO68009840Y1A100C2FFT000/?fbclid=IwAR012ABUDo6MF43Y9N-1UvFXWfqQMDnE2_MJM_ntiVvZb38cZLIhcQYKwcM) 

## “カタカナ”は使わない？重工流スクラム運用法とは

イベントでは、スクラムマスターの山田さんを筆頭に三菱重工で行われているスクラムについて語っていただきました。ここからは、参加者から届いた質問をご紹介しながら、三菱重工のスクラムについて深堀りしていきます。

### Q1.1週間でスプリントを回すのは大変では？期間を1週間にした理由は？

__山田さん__：開発初期の段階では方向性が明確に定まっていないところがあり、可能な限り細かくフィードバックを入れる必要があったからです。あとは企業コミュニケーションを増やしたいという目的もあったので、1週間で回すことにしました。

__廣政さん__：共通基盤領域でいうと1週間はやはり大変でした。日々の運用もあるので、取り組みに完全に集中するというのがなかなか難しくて……。そのため、共通基盤領域では運用のバッファリングを見ながら2週間で回しています。領域ごとに柔軟に対応を変えられるのもDEDの魅力だと思います。

__山田さん__：領域ごとに対応を変えているという話でいくと、ハードウェアは完全に別で、スクラムではなくウォーターフォールで回しています。

__森岡さん__：ハードウェアとソフトウェアの繋ぎどころであるIoTシステムなどに関しては、まずはシステムを作って、分析を深めるためにデータが必要だとなった時に、ハードウェアでデータを取れるように修正をしていただくこともあります。

毎週更新があるというわけではないのですが、月1ほどの単位でデータ周りの変更ができるような状態になっているかなと思っています。

### Q2.スクラムマスターやプロダクトオーナーの社内での立ち位置は？
__山田さん__：まず、プロダクトオーナーはソフトウェアエンジニア出身ではなく、基本的に事業部から来た人が担当しています。IT用語を知るところから始まるので、事業部から来ている方々は苦労していそうだなと感じています。また、POの振る舞いを覚えていくために、業務委託で入っていただいているアジャイルコーチに支援を受けながら進めています。

スクラムマスターの社内での立ち位置でいうと、事業部側からはエンジニアやプロジェクトマネージャーだと認識されています。スクラムについては、できるだけ“カタカナ”を使用しないようにしているので、スクラム用語などは特に伝えずに、これまでの仕事の進め方から違和感のない表現、活動として伝えています。

__──“わからないカタカナ”が出てくると、途端に苦手意識が出てくるという意見もあるので、そういった気遣いは重要なポイントですよね。__

__山田さん__：はい。こちらのやり方を押し付けすぎると事業部側は辟易してしまうかもしれませんし、お互いに歩み寄ることが大切だと思っています。

### Q3.スクラムチームの人数は？参加する事業部側の人はどうやって選ばれるのか？
__川口さん__：人選ルールが明確に決まっているというよりは、自ら手を挙げてくださっている感じです。あとは、事業部側のDXを将来的に主導して欲しいと期待されている若手社員がスクラムチームに参加することもあります。

事業部門側のビジネスリーダーが解決したい問題を抱えていて、かつ解決方法がわからなくなっているところに私達がジョインをする。解決をするために事業部と私たちが手を取り合って走り出す中で、各部署のメンバーが参画してくるという流れだと認識しています。

人数でいうと1チームに5～6人。メンバー構成としてはプロダクトオーナーと開発スクラムマスターは必ず入るようにしていて、それ以外のメンバーについては明確なルールは決めていません。

### Q4.いろんな人が関わっていくなかで、うまくスプリントを回していくコツは？
__山田さん__：うまく回していくコツとしては、週1のスプリントレビューなどを通して、事業部側の意見を頻繁に吸い上げていくことが重要だと考えています。

### Q5.スクラム間の人員移動はある？
__山田さん__：スクラムはプロジェクト単位でチームを組んでいて、横の移動は現状ありません。今後はあるかもしれませんが。

“横のつながり”という観点でいうと「スクラムマスター相談会」を開催していて、毎週1時間スクラムマスター同士で集まって情報共有しています。

最近は隔週で『[SCRUM MASTER THE BOOK](https://www.shoeisha.co.jp/book/detail/9784798166858)』の輪読会もしていて、こちらに関してはアジャイルコーチも一緒に混ざって行っていますね。

## サービスを作ることに集中すべく、社内手続きを経てクラウドサービスを選定
DEDで採用されている技術に関しても詳細にご説明いただきました。それを受けて参加者からいただいた質問とその回答をご紹介します。
### Q6.GitHubあるいはGitHub Actionsをコード管理に選択した背景は？
__川口さん__：GitLabも選択肢にあったのですが、当時マネージドで利用できるということから選びました。

大企業だとオンプレでコード管理したいという傾向が強いのかなと思うのですが、私たちは基本的にクラウドを採用しています。GitHubだけではなく、Terraformに関しても全てマネージド版、クラウドサービス版を使っています。サーバー管理にできるだけ工数を使いたくないので。

__──三菱重工ほど伝統的な大企業では、そのような場合、情シスから反対されるというケースもあると思うのですが、その辺はどうだったのでしょう？__

__川口さん__：反対意見があって説得したというよりは、社内手続きを粛々とこなしているというイメージです。「開発環境を安く済ませる代わりに手を動かす」か、「そこに手をかけずサービスを作ることに集中する」という二つを比較した際、私たちの組織が今注力すべきところは後者だったので、クラウドサービスを利用しているという形です。
### Q7.エッジ側の取得データの見極めは？どういった基準があるの？
__森岡さん__：今の開発でフォーカスしていることは「故障の迅速な発見と対応」です。そのため「弊社のアフターサービス部門や、お客様が、機械が故障した際に見ているデータは何か？」というのをヒアリングしていて、まずはそれをIoTシステムでも見られるようにするというところに取り組んでいます。

### Q8.VueとReactの使い分けは？
__森岡さん__：ここは僕と山田さんが両方触ってから決めました。
理由が二つあって、一つはVercelを利用すると簡単にホスティングできるからです。
Vercel を使う場合は、やはり React の利用が前提になると思います。

二つ目は、三菱重工でシステムを作る人には Node.js でLambda等も開発できるようになって欲しいと考えています。その場合、これは完全に個人的な意見なのですが、Reactから入った方が抵抗感が小さいのではないかなと考えました。Reactではコンポーネントを作る際に、表示と処理を分けることがよく行われます。その処理部分の作り方、テストの仕方は、Lambdaで使うようなプログラムと大きく変わらないと考えたからです。

Vueでも  (React開発者の１人 である) Dan Abramov さんの設計を参考に表示と処理を分けておられる方をよく見かけますが、であれば最初から React を学んだ方が、そういった設計を実感を持って理解しやすいし、参考にできる実装や書籍が豊富なのではないかと。
他にも TypeScript での書きやすさとか小さいものがポロポロあります。とはいえVueは最初のハードルがかなり低いので、プログラム初心者が多くジョインするような我々の組織ではどっちが良かったんだろうと考えることはあります。
## 一人ひとりがリーダーとして大企業の変革に挑戦できる
イベントの最後には、パネリスト4名から、参加者に向けてメッセージをいただきました。

__廣政さん__：私自身も転職してきて、過去の経験とは全く違うことに挑戦できています。必ずしも経験が必要なわけではなく、チャレンジするという思考が非常に大事だと思っています。DEDはチャレンジすることを推奨している組織です。失敗から学んでスキルアップして、良いものを三菱重工の中に広げて、お客様にも届けていく。そのためには勉強し、かつアウトプットし続けることが重要だと思ってます。そういった思いのある方と一緒に働けると嬉しいです。

__森岡さん__：これまでずっとベンチャー企業で働いていて、現在は三菱重工という大きな会社で働いているのですが、今までとあまり変わらないなというのが正直な感想です。DEDではベンチャーと同じような環境で働くことができるので、ベンチャーで働きたいと考えているような人と一緒に働きたいですね。転職を検討される際は選択肢として入れていただければと思います。

__山田さん__：スクラムをしたい方は是非一緒にやりましょう（笑）。三菱重工は大きな会社なので、スピードが遅い事業部があるのも事実です。しかし、DEDはかなりスピード感がありますし、森岡さんがおっしゃるようにベンチャーにいた方でも違和感なく働くことができると思っています。今回のイベントで興味を持っていただけたなら、ぜひお話だけでもできると嬉しいです。

__川口さん__：今日はたくさんの方にご参加頂きありがとうございます。最後に、DEDが大切にしていることについてお話しさせてください。![dx-design](//images.contentful.com/ngrpflsbp3rq/LE2nMSVSljXaxNlGyPVOg/787ccb48c47840b0ea48f76bf206a390/dx-design.png)
私たちは事業部門やお客様に見える成果をお届けしていこうということを一番大切しています。SoEの領域でこうすれば間違いなく成功するといった方法は明確にはないと思うので、どうすれば成功する可能性が高くなるか、学び続けることが重要だと考えています。

私たちの組織ではうまくいきそうな方法が5割ぐらい見えたらまずやってみる。うまくいけばグロースさせるし、ダメだったら改善して、それでもダメなら止めるという判断をすることもあります。そのため、定常業務を繰り返すという仕事はあまりないです。悪く言うと、ザルの網からこぼれおちてくるタスクもあります。

こぼれ落ちたものを無視してしまうと最終的な成果が出てこないので、タスクを押し付け合うのではなく、一人ひとりがリーダーとしてタスクを引っ張り、組織を引っ張っていこうとしています。
そしてそこで学んだことは、社内外にどんどん見せていくようにしています。それにより自分たちがやってることは本当に価値のあることなのか内省するいい機会になりますし、フィードバックもいただけます。見せていくことは、学んでいくことと同じだと考えています。

今回のイベントでは私たちの取り組みについてご紹介させていただきましたが、関心を持っていただけたなら、お話しする機会をいただけると幸いです。

思いっきりトライできる、活躍できる環境を整備することをお約束するので、ぜひご応募いただけると嬉しく思います。

本日はこのような機会をいただき誠にありがとうございました。

__──ありがとうございました。お話をお伺いして、大企業の変革に挑戦するのはとても面白いことなんだなと改めて感じました。モダンな開発環境を採用されていることに加えて、産業機械という珍しい領域に触れられるのも魅力ですね。__

また、グローバル製品を作っている会社のため、プロダクトも英語で作るのが当たり前であり、グローバル×ソフトウェア×ビッグデータという文脈で考えると、さらに面白いことができるのではないかと思いました。

今回のイベントを通して三菱重工に興味を持っていただけた方は、ぜひ門を叩いてみてください。

本日はありがとうございました！

mhi-report2

「日本のデジタル化最前線 Vol.4」と題し、三菱重工業株式会社のDXを推進する組織・DEDのゼネラルマネージャーである川口さんと、Findy経由で同社に入社された廣政さん、森岡さん、山田さんの計4名をお招きした際に頂いた質問へ回答しています。

“カタカナ“は使わない？重工流スクラム運用法とは

mhi-report-1

「日本のデジタル化最前線 Vol.4」と題し、三菱重工業株式会社のDXを推進する組織・DEDのゼネラルマネージャーである川口さんと、Findy経由で同社に入社された廣政さん、森岡さん、山田さんの計4名をお招きし、同社が取り組んでいる開発内製化、DXの実態、業務の面白さについてお伺いしました。

大企業でアジャイル・スクラム・クラウドネイティブをどう実現しているのか。三菱重工のエンジニアが語る

## 技術レベルが高い⇨テックリードのスキル偏差値が高い

エンジニアの多くはハイスキルなエンジニアと働きたいと思っています。すでにハイスキルの人であれば近いレベルの人と一緒に働いた方が共通言語で語り易いですし、まだジュニアやミドル層であればレベルの高い人と一緒に働くことが成長に繋がります。

Findyの転職サービスではGitHub上でのOSS活動をスキル偏差値として算出しています。もちろんOSS活動を一部評価、可視化しているに過ぎないのでこれが全てではありませんが、一方でOSSを真剣に取り組んでいる人でスキルが低い人は少ないのではないでしょうか。

シンプルに先日お話しさせていただいたテックリードのスキル偏差値は高くってOSSに積極的なメンバーですよとお伝えすると刺さります。

![スキル偏差値](//images.contentful.com/ngrpflsbp3rq/4i1RCwfKzrncgG3NfBpWxT/cb85579493a4d8d02f0c3d298630fe64/______________________________UI-1536x738.png)

## 開発プロセスにストレスが少ない→開発リードタイムが短い

次に、「平均プルリク クローズ時間」や「最初のコメントまでの平均時間」（レビューまでの時間）などが早いことをアピールしています。これはエンジニア組織支援クラウドFindy Teamsで見える数字を活用しています。

以下の画像の通りでFindyは一つのプルリクがほとんど当日、また遅くとも翌日にはクローズされる、また毎日リリースできる体制をとっています。

![リードタイム直近](//images.contentful.com/ngrpflsbp3rq/2WGSEu4Wot3q9ydC9IzYPp/e7aa7e31a9919b9f9352462aba3ebaaf/____________________________2021-09-23_11.01.47.png)

また、レビューまでの時間も3〜4時間以内で必ずくる体制を構築しており、プルリクを出したらす半日以内に誰かがレビューをくれるような感覚です。せっかく開発したのにレビューを待たされる、あるいはレビューが遅いので並行で複数のプルリクを対応していたらミスが起こりやすくなるなどを防いでいます。

他にレビューを早くするために、テキストで解決できない場合はすぐにオンラインで話すというスタイルをとっています。そうすることでストレスなく開発を進められる環境を実現しています。

## 改善意欲が高い→リードタイムが1年半で4倍のスピードに

Findyの開発効率は1年でリードタイムで見ると4倍に加速しています。この間、プルリク作成数も増加しているので、もちろんメンバーは増えていますが体感値でも月間の開発ボリュームが数倍になっている感覚です。

これはプルリクを細かくして数を増やし、レビュースピードをあげたり、テスト自動化やマイクロサービス化などを早期にトライしてきた結果です。

詳しくはグラフを見ていただけると幸いです。

2020年1月〜3月だと平均プルリククローズ時間に84.3時間かかっています。

![リードタイム2020/1/1-3/31](//images.contentful.com/ngrpflsbp3rq/3e5zJzk8dJeImW8fIWqtri/9e1f584fc28fd2314f257ce0e4148064/____________________________2021-09-23_11.10.23.png)

それが、2021年4月〜6月だと17.1時間まで下がってきています。スピードアップですね！

![リードタイム2021/4/1-6/30](//images.contentful.com/ngrpflsbp3rq/5gDhmvyEDTuWU8tyXs8k7k/e0c3cc5002e5039594f735cdf67194f8/____________________________2021-09-23_11.10.44.png)

また、同期間に以下の通り1日あたりのプルリク作成数も大幅に増えており、1日数件から30~40件くらいまで実に10倍くらいに増加しています

![タイムライン2020/1/1~2021/6/30](//images.contentful.com/ngrpflsbp3rq/3D3GtM9xctXT6No06wKjnF/9e4484b91d8eb3b155275b79aaec91e9/____________________________2021-09-23_11.11.33.png)

もちろん、プルリクの粒度の問題もありますし、プルリクの数だけで判断できない部分はあると思いますが、改善という意味では確実に進んでいます。

## エンジニア組織のMIPもデータで見える化→エンジニアの頑張りを全社で賞賛

会社表彰やMVPといえば「営業成績No.1」の人が獲得することが多いのではないでしょうか。エンジニア個人の価値はなかなか見える化しにくいため、全社でMVPと言われてもなかなかビジネスサイドまで理解されにくいことが多いのではないかと思います。

ちなみにFindyでは2020年下期の全社MVPはテックリードで、上記の開発リードタイム4倍を推進したメンバーですし、2021年上期もMIP（最も成長した人）という位置付けでエンジニアメンバーが全社表彰されています。

以下がMIPを取ったメンバーの活躍を時系列で現したグラフです。イシュー作成、プルリク作成、レビュー数など全てのアクティビティが大幅に増加しています。本人もFindy Teamsを実際に見ながら、改善を進めてきた結果とのことで、活動量だけではなくアウトカムも増えてますし、本人の自信を持って仕事に取り組んでくれるようになりました。

![メンバー詳細](//images.contentful.com/ngrpflsbp3rq/3MAjeQ0cxUD41lQUifOX0g/eaa49eae439d4ba62bdf7c7eaa5aa1da/_____________________.png)

以上、データで口説くエンジニアの最終面接、いかがでしたでしょうか？
ぜひぜひ、試してみたい企業様がいらっしゃいましたら、[こちら](https://findy-teams.com/service_introduction)問い合わせいただければ幸いです。


data-interview

エンジニアを採用したいけど、内定は出しているけど、なかなか承諾まで進まない。そんなエンジニア採用の悩みは抱えている企業は多いのではないでしょうか。FindyではFindy Teamsのデータを活用して口説くエンジニアの最終面接にチャレンジしており、その事例について書きました。

データで口説くエンジニアの最終面接。ハイスキルな人ほど効率良い組織で集中して働きたい？！

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

僕ら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社全体として大事にしているいちばん大事な開発指標として、プルリクエストの作成数があり、プルリクエスト作成数をベースに開発がうまくいっているかを議論し続けています。  プルリクエストの作成数とそれに紐づく議論について書いてみようと思います。

記事一覧