## パネリスト
### 川口 賢太郎さん
三菱重工業株式会社 成長推進室　デジタルエクスペリエンス推進室　室長
大学・大学院で建築デザインを専攻、三菱重工業入社後は建築デザイナーとしてさいたまスーパーアリーナなどを担当。その後、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 Teams活用事例インタビュー

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

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

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のアンケート調査でもエンジニアの将来という意味では約半分がテックリード、スペシャリスト思考であり、マネジメント思考の人は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というサービスを提供する中で、エンジニアリングマネージャーとお話をする機会が多くなっています。その中で、エンジニアリングマネージャーの悩みあるあるを書いてみようと思います。

記事一覧

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

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

「エンジニア個人の振り返りや組織の課題発見に活用」株式会社アンドパッド様-Findy Teams活用事例インタビュー - 株式会社アンドパッド

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

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