eventreport ikyu stafes

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

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

vpoereport

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

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

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

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

## 登壇者紹介
__澤 円氏（以下、澤）__：株式会社圓窓代表取締役の澤と申します。私は1993年に社会人になり、5年ほど日本企業に勤めた後、1997年からMicrosoftで働いていました。2005-6年の頃にマネージャーへキャリア転換をしまして、最後はMicrosoftテクノロジーセンターのセンター長とサイバークラウドセンターの責任者を務めておりました。
![自己紹介](//images.ctfassets.net/ngrpflsbp3rq/56x9rZhWWtTn8EhvKTvvCk/bc62f21954ddab8c563a88157386f059/____.png)

2020年に独立し、企業向けのコンサルティングや、エバンジェリスト活動、執筆活動、メディア出演などをしております。また、武蔵野大学のアントレプレナーシップ学部で専任教授も務めております。よろしくお願いします。

__内田 博咲也氏（以下、内田）__：ファインディ株式会社でFindy Team+事業部の副事業部長とセールスのマネージャーをしている内田と申します。セールスの中でもフィールドセールスとインサイドセールスを担当しており、現在15人くらいのチームのマネージャーをしております。
![自己紹介2](//images.ctfassets.net/ngrpflsbp3rq/4odJRrgenye98OB88F01K1/a20cb1e79ea3eadc902e127e9f3d90f4/____2.png)

前職はデロイトトーマツコンサルティングという経営コンサルの会社で3年半、全社戦略や長期戦略、ジョイントベンチャーの立ち上げなどの支援をしておりました。本日はよろしくお願いいたします。

## エンジニアの開発生産性とは？
![名称未設定2](//images.ctfassets.net/ngrpflsbp3rq/eOnEs3E6mNIKzYcLBAOHt/939cf4ec089b59dca57efd9383ada24b/_____2.png)
__内田__：開発生産性と言っても、大きく2種類の生産性がございます。

1つ目が開発組織の中でアウトプットをいかに増やしていくかという生産性。2つ目がビジネス価値を増やしていくという方の生産性です。開発組織としてのリソースを投入したものに対してのアウトプット、アウトカムを生産性と言っていて、それが開発現場よりのところのアウトプットになると前者のものになりますし、もう少し経営寄りやビジネス寄りになってくると後者のものになってくる、そんなイメージです。

__澤__：セールスの計測ってすごく簡単じゃないですか。その一方で、エンジニアの生産性の計測というのは、すごく難度が高いと感じませんでした？

__内田__：めちゃくちゃ感じましたね。というのも、コーディングや機能開発をしているところから、いわゆる一般的な生産性として認知されている売上・利益といった指標との接続が、パッと見て遠すぎて見えないというところが最初にありました。

 一昔前だと、書いたコードの行数で測るという話もあったんですが、優秀なエンジニアほど端的なコードで分かりやすい処理を書くということがありますよね。そうなると、行数で見ると生産性が低そうに見えるんですが、その人が出す価値は大きい。じゃあ何で測るのか。

また、開発したものへのレビューが返ってくるまでの速度の早い遅いも人によって異なりますよね。それを客観的に1つの指標で見えるようになると大きいという話もありまして。

__澤__：そこら辺の単位の違いをいかに揃えていくのかというところと、その1時間が本当に価値を生むのかということも証明をしないと納得はできない。
かといってルールばかりで縛ってしまうと、これまた働きづらいということになってきます。
そこで重要になってくるのがマネジメントということなんですかね。

## エンジニアをマネジメントするとは？
![ビジョンをつくる](//images.ctfassets.net/ngrpflsbp3rq/7ul3elROagP3JQj0r0totY/a4688f958a8ef7f7c64039376e442095/__________.png)
__澤__：エンジニアのチームをマネジメントするというのは、いろんなところで悩みの種になっているという印象がありますが、そこについては体験値としていかがでしょうか。

__内田__：クライアントの方からもいただく声として非常に多いですね。今、システム開発・プロダクトが事業の根幹になりつつある中で、エンジニア組織はどんどん急拡大しながら、開発のアウトカム・アウトプットを高い状態で保たなければいけない状況です。
マネージャーは非常に必要なのですが、なりたい人は少なくて、最初に起こるのはマネージャーが足りなくてチームのパフォーマンスを最大化できていないという問題です。 

__澤__：僕はマネージャーの仕事って何ですかと問われた時に、一言で「メンバーが全力疾走できるように前方の道を掃除する人」という言い方をするんです。コンディションを整えて、「はい、どうぞ」と言って走ってもらう。これがマネージャーの仕事だと考えています。

ただ、日本における「マネジメント」や「マネージャー」というところで、非常に気に食わない言葉があって、それは「管理職」という言葉です。管理というのは人間がやらなくてもいい領域なんです。
それに「職」なんてつけちゃうから、管理していることが仕事になってしまっている。これがそもそもおかしいというのが私の持論です。

__内田__：私もいろんなクライアントの方とお話しさせていただいていて、絶対にあるなと思うのが、ゴールをここだよと明確に伝えて、そこに向けてみんながパフォーマンスを最大化して走れるようにすることの重要性です。

みんなが好きな方向に好きなように走ってしまうと、チームのパフォーマンスは最大化されません。そこでゴールを示した上で、走っていく上での障害を事前に取り除いていく。これがマネージャーとして理想の状態なんじゃないかと思います。

__澤__：マネージャーの仕事として最も大事なことは、これはマイクロソフト時代に言われていたことなんですが、「ビジョンを作ること」です。ビジョンというのは、さっきゴールとおっしゃっていましたが、仕事って必ずしもゴールがあるとは限りませんよね。

例えば、運用というオペレーションの部分は、ゴールが曖昧になります。継続していくことが大事になるので。
もっと言うと、アジャイル開発というのは、ずっとサイクルを回していくという感じになるので、ゴールというものがないんです。そんな時にビジョンというものを決めると、何か困った時にその方向を見て走ることができる。

![コンディションを整える](//images.ctfassets.net/ngrpflsbp3rq/7pDNr2qHYDyPahR9iDpfmD/25b069c2513cff91d925eeb2494591df/____________.png)
「北極星」がビジョンだ、という言い方をよくするんですが、北極星は動かないので目印になる。それを中心にしてみんなが船旅をしていた。それによって世界を旅することができるようになったように、マネージャーの仕事はビジョンを決め、そのビジョンに向かってみんなが働けるようにコンディションを整える、この双璧だと思っています。

## 「確認」が開発のボトルネック 
![スムーズに回転](//images.ctfassets.net/ngrpflsbp3rq/2eWBSDkUPTOHQbURNksd3i/caae5744e833bc8d36cefef7cff2058c/________.png)

__澤__：アジャイル開発は、ずっと回していく状態ですから、最も重要なのは、スムーズにその回転ができることです。車のように、すっと回る状態にしなければいけない。そのためには、引っかかりがないようにする必要があります。
その引っかかりって何によって生まれるのかを認識しなければいけないのですが、実は「確認」というのがボトルネックなんです。

確認というキーワードが、いろんなところでボトルネックを引き起こしています。特にウォーターフォールでは、プロセスが分かれていて「確認、確認、確認」という風になっていました。そうする方が精度の高いものが作れるというロジックで、そういう構造になっていたと思うんですが、これはアジャイル開発には非常に相性が悪いんです。

回そうという時に、確認というのは回転を止めることに繋がりかねません。だから、回っている状態を維持するという考え方をしなければいけない。回っているかどうかを止めて調べるというのは、明らかにボトルネックを生んでいる状態なんです。 

__内田__：今のその確認がネックになっているという話と、確認したとして次に繋がらない、改善に繋がっていかないというのは、非常に多く見られる問題ですね。

## 課題を放置することによる悪影響
![可視化されていないと](//images.ctfassets.net/ngrpflsbp3rq/6UsZaZh9GqnUcA9KozxHBm/ac7d6a81a2560d36f003ebd699604148/__________.png)

__澤__：エンジニアの働き方の中でボトルネックがあったり、何か欠けている部分があったりするのを放置することで起きる問題については何かありますか？

__内田__：開発組織としてのパフォーマンスを最大化していく上で、2つあると思っています。

1つ目が技術負債と呼ばれるものが溜まっていってしまうという問題です。これを放置してしまうと大きくなってしまいます。継続的に一定の割合を割いて改善していった時の、トータルで見た時のアウトプット量の増加については、弊社のエンジニアがブログでまとめてくれているのですが、小さな改善を重ねていった方が良いということが示されています。 

もう1つが、先ほどからお話させていただいているマネジメントの部分です。成果を出すための仕組みだったり、そういったものが、人数が少なかったり組織が大きくなる前に発生していた問題をそのまま放置したまま大きくなってしまうケースです。これを放置するのではなく、つぶさに改善を重ねていくことが重要だと思います。

__澤__：可視化されていない状態だと、それが問題だという指摘のしようがないですよね。改善しなければいけないところを指摘すると、エンジニアとしては非常にストレスになると思うんです。「自分が否定された」「人格否定された」「ハラスメントだ」という騒ぎになりかねません。 

でも、そうではなくて、「ここを改善すればパフォーマンスが良くなる」というシンプルな話なんです。それが納得できれば、改善に取り組みやすくなります。人にフォーカスするのではなく、何がいけないのかというプロセスだったり、成果の出し方に課題を見つけて改善していく。これは非常に重要なポイントだと痛感しています。

## エンジニアが働きやすい環境と「採用」の課題
![働きやすい環境](//images.ctfassets.net/ngrpflsbp3rq/4lt07qY56rJiWk5sryQPQl/edb8728b79c7fcca31688368984fc66a/_______.png)

__澤__：実際に「Findy Team+」を使って様々なものが可視化された際にどんなメリットが生まれたか、具体例を教えていただけますか？

__内田__：弊社のサービスを使って様々なものが可視化され、具体的なメリットとしては、アウトプットの生産性が改善したというお声をたくさんいただいています。テックブログなどでも書いていただいていますが、例えば開発し始めてからブランチにマージされるまでの時間が1/10になったとか、定量面での改善が見られます。

また、レビュー待ちの時間がボトルネックになっていたけれど、「これってみんなそうだと思っていたから、あえて言わなかった」というところが、データで可視化されることで、「この人にレビューが溜まっているから時間がかかっていたんだ。じゃあチーム全体で分散させよう」という改善につながり、結果としてみんなの開発スピードが上がって、開発しやすくなったという声もあります。 

__澤__：まず大事なことは、働きやすい状態でエンジニアに働いてもらうことです。そうすると何が起きるかというと、辞めないんですよね。リテンションリスクの軽減につながるんです。これは今、エンジニアの獲得競争が激しい中で、非常に重要です。

__内田__：それこそ、採用広報やIRにもご利用いただいているところがあります。やはり、開発しやすい環境をいかに整備できているか、その中でエンジニアがいかにパフォーマンスを発揮できているかということを広報することで、採用にもつながっています。 

__澤__：今、ありとあらゆる業界の中で最も重要な課題は採用です。少子高齢化で労働人口がどんどん減っていく中、優秀なエンジニアは元々母数が少ないにも関わらず、さらには海外に流出してしまう。そうなると、とにかく定着して働いてくれる人を増やしていかなければいけない。開発生産性が低い現場は、真っ先に淘汰されてしまいます。

## Findy Team+サービス紹介
![Team+サービス紹介](//images.ctfassets.net/ngrpflsbp3rq/6ADwG691SV2L7znU0hINx1/ce0408142fae7765f59f6f416ed581b7/Team________.png)
__内田__：「Findy Team+」では、メインで可視化できるのが冒頭申し上げたアウトプット量の可視化と改善です。トレンドになりつつあるFourKeysの可視化から、開発現場のボトルネックに紐づくところまでが一気通貫でできるのが強みになっています。

今後については、ビジネス価値から逆算した時の開発組織の生産性も見れるようにしていきますし、それこそもっと多面的に見れるフレームワークとしてSPACEフレームワークなどにも対応予定です。ぜひご期待いただければと思います。

本日はご視聴いただきありがとうございました。開発現場の課題から経営レイヤーの課題まで解決できるサービスとなっています。プロダクトだけではなく、カスタマーサクセスというクライアントに伴走しながら一緒に改善をサポートしていくメンバーも揃っていますので、ご不明点・気になるポイントありましたらぜひ気軽にご相談ください。

## AIの進化が後押しする、エンジニア躍進の新時代
__澤__：今、DXというキーワードがあちこちで言われていて、だいぶ手垢が付いた感じがしますが、その一方でエンジニアの人たち、あるいは情報システム部門の人たちの役割の重要性は非常に高まっていると思います。

ただ、その人たちを大事に扱うやり方が、今まで日本は本当に下手だったなと私は肌身で感じています。 でも、今は流れが来ています。もう我々の時代です。エンジニアが今、どんどん注目されているし、そして仕事が面白くなってきています。これからもどんどん面白くなっていくと思うんですね。

生成AIなんかもどんどん発展していって、それとうまく付き合える人間というのは、ビジネスでも成功できる。そういう世界観がもう既に来ていますので、エンジニアの方々には、ぜひ世の中をもっともっと面白くする、そんな仕事をしていきましょう。

__内田__：本日はお時間をいただき、ありがとうございました。 

__澤__：こちらこそ、ありがとうございました。

※[本動画](https://www.youtube.com/watch?v=aHb3wL7tnO0)の撮影日は2024年3月26日です。


cover

今回の対談では、「エンジニア組織のマネジメントと業務の可視化」をテーマに、株式会社圓窓代表取締役の澤氏と、開発組織の生産性可視化ツールを提供するファインディ株式会社の内田が、実践的な改善方法について対談しました！

イベントレポート

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

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

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

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

エンジニア組織の実力を引き出すマネジメントと生産性可視化ー澤円氏×ファインディ対談

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

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

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

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

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

エンジニア組織の実力を引き出すマネジメントと生産性可視化 ー 澤円氏×ファインディ対談

イベントレポート

エンジニア組織の実力を引き出すマネジメントと生産性可視化ー澤円氏×ファインディ対談