## パネリスト
### 米山 諒さん/株式会社アンドパッド [[@yulii]](https://twitter.com/yulii)
![andpad-yoneyamasan](//images.ctfassets.net/ngrpflsbp3rq/6JBZbzfs9Nk6ezD9TNXfVQ/e28002bb1169e42680f29a35995420bd/andpad_yoneyamasan.jpeg)
早稲田大学大学院在学中、創業期のビズリーチにインターンとして参加。2011年4月、リクルートに入社し、プロデューサーとして新規事業の立ち上げ、事業運営責任者を務める。フリーランスとして複数社のスタートアップを支援後、株式会社LiBを創業し取締役CTOに。現在はアンドパッドの組織戦略部の部長として、開発本部の組織戦略にコミットしている。

### 柴山 嶺さん/株式会社LayerX [[@serima]](https://twitter.com/serima)
![layerx-shibayamasan](//images.ctfassets.net/ngrpflsbp3rq/544b0eTxUkG1rhlNvdCPy1/e785037efa70fbe10fe260d001107302/layerx_shibayamasan.jpeg)
東京高専を卒業後、国立大学に3年次編入するが、スタートアップを創業するため中退。 その後、複数の事業会社にてサーバサイドエンジニアとしてジョイン。株式会社GameWith にてプロダクト開発組織のマネージャー(Engineering Manager/VP of Engineering)を経験したのち、現在は株式会社LayerXのHRBPとしてエンジニア採用や開発組織づくりのサポートをしている。

## 採用や組織づくりにエンジニアが関わる意義とは？
冒頭では二人が採用や組織づくりに関わるようになった経緯について伺いました。
米山さんは、自身が起業した経験もあり、「技術とビジネスの両立」を常にテーマとして意識されてきたそうです。

米山さん：「『良いプロダクトには組織づくりが大事』というのは、多くの方が体感されていると思います。ですが、私は自分で起業するまで、あまり理解できていませんでした。『やる気のある人たちが集まれば、うまくいくんだろう』くらいの気持ちで、1on1でメンバーに怒られた苦い経験や反省を経て、その重要性に気づいていきました。

その後、本を読んだり他社の話を聞いたりして、試行錯誤を重ねるなか、組織づくりを人事や経営者だけではなく、エンジニアが主体となって担う意義を感じるようになりました。

プロダクトに関わるメンバーの組織づくりを専門に行うチームがあってもいいのではないかという想いから、アンドパッドにジョインしたタイミングで、『組織戦略部』を立ち上げました」

LayerXの柴山さんは、複数の会社を経験するなか、人や組織と向き合う楽しさ、発揮できる価値を実感し、採用や組織づくりに関わるようになったそうです。

柴山さん：「元々は、ユーザーにどのような価値を届けるかを考えるのが好きで、開発に携わってきました。ただ、開発の経験を重ねるなかで、人や組織に向き合ったほうが、自分はよりバリューが出しやすいのではと考えるようになったんです。そこからEMやVPoEとして、組織づくりや採用にも関わるようになりました」

LayerXの現職を選んだ背景には「プロダクト開発をやりながら採用にフルコミットするのは難しい」という実感もあったと言います。

柴山さん：「エンジニアの採用は厳しい状況が続いています。ですが、EMやVPoEだと開発にも一定のリソースを割く必要がある。採用にフルコミットできれば、もっといい人を採用できるのではないか、より良い候補者体験を設計できるのではという葛藤は常にありました。

異なるポジションがないかと模索していたところ、LayerXの人事である石黒さんに悩みをお話しさせていただいて。[人事としてエンジニア採用にコミットする現在のポジションにたどり着きました](https://note.com/serima/n/naede81a30f8f)」

![event1](//images.ctfassets.net/ngrpflsbp3rq/2IYlxl9F9cXDG9gLq1Cu4R/95b20f59081e940de61d151156dad519/event1.png)

## 候補者と丁寧に向き合うことと組織のスケール

続いて両者のエンジニア採用における課題、中長期的な取り組みについて共有いただきました。

柴山さんは、一人ひとりの候補者と丁寧に向き合うこと、会社やHRとしての組織のスケールなどを挙げます。

柴山さん：「今は、候補者に丁寧かつ真摯に向き合っていかないと、採用できない環境だと思います。中長期でも、短期でも、一人ひとりの候補者体験を良いものにする意識は大事にしたいと思っています。

一方、会社としてはいかにスケールできる組織にしていくかをテーマに据え、オペレーションの効率化、行動指針の『Bet Technology』が指す自動化などに取り組んでいます。

現状、アトラクトもクロージングも、かなり属人化していますし、自分自身かなり『ハイタッチなリクルーター』だと思います。ここからどれだけHRとしてスケールできる状態を目指すか、実現していくかは重要なテーマです」

米山さんも柴山さんと同じく「一人ひとりの採用体験をどうより良いものにしていくのか」を考え、取り組んできたと言います。

米山さん：「数字を追っていると、つい『何人採用しなきゃいけない』という話になってしまうのですが、その数字の奥には一人ひとりのキャリアや人生がある。アンドパッドの選考を進めていただくなかで、なぜ今入社するのがいいのかといった意味づけや入った後の活躍プランなどのすり合わせは、非常に大切だと感じます。

現状の課題としては、組織が拡大し、面接官の数が増加するなか、採用から入社後の活躍までどのように一貫した体験を届けていくのか。対応する人によって体験に齟齬が出ないよう、全体としての認識を揃えつつ、いかにチームでうまくバトンを渡していくのかなどですね」

![event2](//images.ctfassets.net/ngrpflsbp3rq/5vhKN3aWOLb7J3hoh9xrn/42205e962d05b0d61da822f712658e55/event2.png)

加えて、柴山さんはBtoB SaaS自体に興味を持ってもらうための取り組みも強化していきたいと語ります。

柴山さん：「BtoB SaaSというビジネスモデル自体に足を踏み入れようと思ってもらうためのストーリー作り、トレンドの促進は、注力したいと思っています。最近始めたものですが、[『SaaS.tech』](https://saas-tech.connpass.com/)というSaaSに関わるエンジニアやプロダクトマネージャーが集まる勉強会を主催しています。」

![event3](//images.ctfassets.net/ngrpflsbp3rq/2sceFquyR1Opj2LFOgq9cs/155dfc5ddabaf47d680267d0d3585322/event3.png)

## エンジニア自ら「一緒に働くメンバーを選ぶ」ことの意義

続いて佐藤が「エンジニア経験がどのように採用に活きているか」を尋ねます。両者が挙げたのは、技術的な背景知識や文脈を理解して面接できる点、現場で開発に取り組むエンジニアの面接負担を減らせる点でした。

さらに米山さんは「採用においても新たな技術トレンドへのキャッチアップは重要。エンジニア経験があると、最新の技術トレンドなども、既存の文脈や経緯と関連づけて、概要を素早く掴める」とエンジニア経験が活きる点を挙げました。

次に話題に上ったのは「現場のエンジニアが、どのように採用に関わると良いと思うか」について。

米山さんは「自分で一緒に働きたい人を見つける」気持ちで「たった一つのアクションでも関わってみる」意義を語ります。

米山さん：「エンジニアは自分自身で勉強することも大事ですが、周囲のチームメンバーから教わったり、逆に教えたりして、新たな発見や知識を得ることが多々あると思います。

ですので、共に働く人がどういう人かはとても重要。チームとして楽しく働く、 モチベーション高く働くためのメンバーを選ぶという意識で、採用に関わってほしいなと思います。

もちろん関わり方は様々あると思います。面接に出て、技術的な質問やディスカッションを楽しみ、『この人と一緒に働いたらどうだろう』を確かめるのもそうですし、テックブログを書く、今日のようなイベントに登壇するなども、採用活動の一環だと思います。

さらに小さいアクションとして、SNSで求人をシェアするとかでも良い。たった一つのアクションでも関わってみると、採用やチームづくりが自分ごと化されやすいのではと思っています。

『この人来月から来るから』と人事が連れてくる形だと、入社する側も緊張するし、受け入れる側もジャッジするような態度になってしまいやすいです。業務の中で面接してしまうわけですね。そうすると、やはり入社した人の活躍の可能性は減ってしまうと思います。

ですので、何かしらの形で採用の一部を担っていただいた方が、入社する側、受け入れる側、双方にとってハッピーなのではと思います」

柴山さんも米山さんの話に頷きつつ、LayerXの「自分たちで自分たちの仲間を集める」カルチャーを紹介します。

柴山さん：「求人のツイートだけでも、採用活動に関わっているというお話は非常に共感します。LayerXには、自発的にnoteを書いたり、Meetyで人と話したり、自分から発信する方が多く、手前味噌ながらとても良い組織だなと思います。[アドベントカレンダー](https://note.layerx.co.jp/m/mebf18e08f6a8)の投稿を呼びかけると一瞬で枠が埋まるほどです」

<figure>
 <img src="//images.ctfassets.net/ngrpflsbp3rq/6PMVB8CQA4ZflC2HJiW5Mh/66fa9b7c00019d1c2cde96baf2fe2569/event4.png" alt="キャプション文字" />
 <figcaption>“なぜかよくわからない季節にやっている”というLayerXのアドベントカレンダー</figcaption>
</figure>

加えて『紹介したくなる組織になっているかどうか』という検討も大事なのではと、柴山さんは付け加えます。

柴山さん：「例えば『求人公開しました。シェアしてください』と言ったときに、シェアしてくれない人が多い場合、なぜシェアしないかなどは、丁寧にヒアリングして、現状を把握できるといいと思います。一見遠回りのようですが、なぜ自分たちが今のチーム、組織で働いているのかの意味づけや紹介したくなる理由、したくない理由などは、深掘りしていくと、採用に必ず活きてくるはずです」

## カジュアル面談の質担保や型化、見るべきポイントは？
イベント後半では、両者が今後形にしたいエンジニア組織の形について聞きました。

米山さん：「チームづくりや組織づくりは、決してマネージャーや経営者だけの仕事ではないと思っています。エンジニアのメンバーも、チームづくりや組織づくりに貢献できる、コントロールできるという手応えを作っていきたいと思っています。

皆さんご存知だと思うのですが、『コンウェイの法則』という考え方では、ソフトウェアのアーキテクチャと組織の設計は連動するものと捉えます。そのため両方をちゃんと磨いていくことが大事だと思っています。

磨いていくにあたって、組織づくりに詳しい人がゼロからエンジニアリングやコンピューターサイエンスを学ぶのは、なかなかハードルが高いと思います。もちろん、どちらも大変なのですが、エンジニアリングを知っている人が、少しずつ組織づくりを実践しながら学んでいく意義は、労力に対してとても大きいと思っています」

柴山さんは「カルチャーや思想、考え方の密度や濃度を保ったまま、組織をスケールさせること」と語ります。

柴山さん：「冒頭でお話しした通り、いかにスケールできる組織にするかは、肝だと思います。一方、カルチャーの濃度や密度を保てることは大前提です。特にLayerXは顧客の課題解決に向き合っているエンジニアばかりですので。そういうカルチャーを維持しながらどうスケールするかが、1年くらいの大きなチャレンジになっていくと思います。

加えて、属人的にやってきたことを、どれだけ型化やデリゲーションしていけるのか。基本的なところですが、今まさに取り組んでいるところです。

あとは、顧客のペインをいかに自分ごと化してもらうのか。LayerXの場合、お客様が結構近い距離にいることもあって、開発した機能について、お客様から喜びの声がほぼ直接届く環境です。小さな成功体験を通して、これは自分が解くべき問題なのだと、少しずつ理解いただいていると感じています」

![event5](//images.ctfassets.net/ngrpflsbp3rq/7d60J4DJgg63eaiZ0K7HIZ/2bc09b7080a34fc359db7f774d4f585c/event5.png)

イベント終盤では、採用や組織づくりについてより具体的な困りごとや質問が上がりました。

一つ目は「カジュアル面談を担当するメンバーが増えても、質を担保するため、どのように型化しているのか」というもの。米山さんは「あまり型化は強く意識していないが、ナレッジやテクニックは積極的にシェアしている」と回答します。

米山さん：「会社の説明や資料などは共有のものがありますが、基本的には各々オリジナルにやってもらってます。ある程度のストーリーラインは決めておいて、そこからぶれるのは仕方ないというか、むしろ活かしていくイメージです。

一方で、EM同士で勉強会を開き、うまくいった質問や面接の流れをシェアすることは多々あります。どのように会社を説明すると上手く興味を示していただけたかなど、具体的なテクニックベースで聞いて、お互い取り入れています。綺麗に整理しているというより、お互いにシェアして、質を相互に高めている感じですね。」

さらに「担当者間でどのように採用基準を揃えているか？」「エンジニア採用において特にみるべきポイント」についても柴山さんが回答します。

柴山さん：「採用基準を明確に言語化はできていないのですが、『この候補者の、この部分はGood、この部分はMore』といった申し送りを共有していくなかで、少しずつ揃えていけるといいのかなと思っています。LayerXもここは手探り状態で、『何か一つでも迷ったらお見送り』といった基準はあるのですが、キレイな言語化はまだまだこれからですね」

最後に、採用や組織づくりにおいて、二人が参考にしている参考文献も紹介いただきました。

米山さんが挙げたのは 『[チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計](https://www.amazon.co.jp/%E3%83%81%E3%83%BC%E3%83%A0%E3%83%88%E3%83%9D%E3%83%AD%E3%82%B8%E3%83%BC-%E4%BE%A1%E5%80%A4%E3%81%82%E3%82%8B%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%82%92%E3%81%99%E3%81%B0%E3%82%84%E3%81%8F%E5%B1%8A%E3%81%91%E3%82%8B%E9%81%A9%E5%BF%9C%E5%9E%8B%E7%B5%84%E7%B9%94%E8%A8%AD%E8%A8%88-%E3%83%9E%E3%82%B7%E3%83%A5%E3%83%BC%E3%83%BB%E3%82%B9%E3%82%B1%E3%83%AB%E3%83%88%E3%83%B3/dp/4820729632)』です。

米山さん：「最近出版された書籍で、用語も独特。一人で読むより何人かでディスカッションしながら読み進めると、理解が進むかと思います。アンドパッドでも有志で集まり、書籍で紹介されている基本的なチームタイプについて『私たちの組織で言うとこんな感じかな？』など、実例と紐付けて理解を深めています」

柴山さんが挙げたのは『[エンプロイーエクスペリエンス](https://www.amazon.co.jp/%E3%82%A8%E3%83%B3%E3%83%97%E3%83%AD%E3%82%A4%E3%83%BC%E3%83%BB%E3%82%A8%E3%82%AF%E3%82%B9%E3%83%9A%E3%83%AA%E3%82%A8%E3%83%B3%E3%82%B9-%E3%83%88%E3%83%AC%E3%82%A4%E3%82%B7%E3%83%BC%E3%83%BB%E3%83%A1%E3%82%A4%E3%83%AC%E3%83%83%E3%83%88-%E3%83%9E%E3%82%B7%E3%83%A5%E3%83%BC%E3%83%BB%E3%83%A9%E3%82%A4%E3%83%89/dp/4909689435)』です。

柴山さん：「エンプロイーエクスペリエンスは、前職のエンジニア時代に読んで、一つのブレイクスルーになりました。要は候補者体験と従業員体験は繋がっていて、それはサイクルになっているといった、基本的な考え方が紹介されています。良い従業員体験が生まれたら自然とリファラルも発生するなど、全部繋がっている。その循環のどこにフォーカスを当てるべきか、戦略を立てるにあたって、ヒントになるのかなと思いました」

個の候補者体験と丁寧に向き合う重要性や採用にエンジニアが関わる意義、“自分ごと化”するための小さなアクション、面談の質向上やナレッジシェアの取り組みなど、現場のリアルな課題とともに共有されたイベント。お二人は「採用や組織づくりは非常に難しい領域」と前置きしつつ、柴山さんは「挑みがいがある、うまくいったときに発揮できる価値、インパクトは大きい」と、米山さんは「今後もこうした機会でナレッジをシェアし、よりよいIT業界、世界を目指していきたい」と語ってくださいました。

Findyでは「挑戦するエンジニアのプラットフォームをつくる。」というビジョンのもと、引き続きエンジニアの組織づくりにまつわるイベントを定期的に開催しています。
ぜひイベント情報をチェックしてみてください。
https://findy.connpass.com

バナー v3

株式会社アンドパッドの米山諒さん、株式会社LayerXの柴山嶺さんをお招きし、両者の採用や組織づくりの課題、エンジニアが採用に関わる意義、面談の型化や質向上など、多岐にわたるトピックを語っていただきました。

エンジニア自ら「一緒に働きたいメンバー探し」を。 アンドパッドとLayerXが取り組むエンジニア採用と組織づくり

## 事業を加速させる成熟した技術組織へ、二社のマネジメントが担う役割
冒頭では、はてなとChatworkそれぞれのエンジニア組織の構成、お二人が今の役割を担うまでの経緯を紹介していただきました。

onkさんの所属するはてなでは、プロダクトごとのチームと、それらのチームに横串で関わるチームからなるマトリクス組織の形態を採っているそうです。onkさんは横串のエンジニアチームにてシニアエンジニアを務めています。

マネジメントに携わるきっかけについて、onkさんは「元々知らない情報のある状態が気に入らない性格」であり、社内で行動や提言を続けるうちに「シニアエンジニア」や「チーフエンジニア」などの役職を任されるようになったと振り返ります。

onkさん：「元々、会社のSlackのチャンネルはほとんど入っていて、知らない情報があったらどんどん掘っていく性格です。各メンバーがどういう目標を持っているか、何を考えているのかを日常的にウォッチし、意思決定の上流を遡るなどしていました。そのうち、リソース調整の会議に参加するようになり、目標設定や評価にも関わるようになった流れです」

![event-shot2](//images.ctfassets.net/ngrpflsbp3rq/64Ag8F31xszvF86uzEImTF/14ebc7e7071d9549a6cdbfc9ca0b6274/event-shot2.png)

だいくしーさんの所属するChatworkでは、バックエンドやフロントエンドなどの職種、料金プランを専門に扱うチームなどの機能でチームを分け、開発を行っています。並行して、現在はアーキテクチャや組織構造の刷新も進行中。だいくしーさんはこの刷新プロジェクトにエンジニアリングマネージャーとして携わっています。

だいくしーさんは、当初からマネジメントに関心があったわけではなく「コードを書き続けられないなら転職する」と考えていた時期もあったそうです。

だいくしーさん：「元々はコードを書き続けたいと思っていたのですが、周りからリーダー的な役割を勧めていただくことが多くて。『周りが言うなら』とトライしてみると、チームにレバレッジをかけて、一人では達成できない成果を出すのが楽しくなってきたんです。

加えて、今後のキャリアを考えると、一つのチームやプロダクトではなく、複数のチームやプロダクト、ひいては会社全体を俯瞰して動く経験やスキルがあったほうが、事業や組織に対して出せる影響力も広がるだろうと考えるようになりました」

![event-shot1](//images.ctfassets.net/ngrpflsbp3rq/4yyjlwo6ECLlEOIeY3H3N7/59e2ed6a56fd054fa4d5aae4ea73ed60/event-shot1.png)

それぞれの立場で達成したいミッションをたずねると、共通していたのは「開発」と「事業」をつなぎ、ビジネスや顧客への価値を生み出していくことでした。

onkさん：「開発が事業のボトルネックにならない状態を作りたいと思っています。大きな目標としてはスループットの向上ですね。デリバリーとディスカバリーの両輪を回していますが、特に前者の回転数を上げていきたいです」

だいくしーさんも、技術や組織の刷新と、顧客への価値提供を両立しようと試みています。

だいくしーさん：「ChatWorkは、開発から10年以上経ち、アクティブユーザーも多い。アーキテクチャの刷新には、一定の期間が必要になります。

ですが、ただチマチマと作り続けるだけではなく、部分的には、お客様に価値が届くところまで作り切って提供したい。そのうえで次のフェーズに進む、という流れを進められるよう、試行錯誤しています」
## サイロ化を防ぐのではなく、サイロ化しても回る仕組みを作る
イベント中盤では、リモートワーク化でのマネジメントが話題に上がりました。意識していることについて、だいくしーさんは「サイロ化しても回る仕組みを作ること」について語ります。

だいくしーさん：「リモートだと、オフィスで他の人の声が聞こえることがないので、どうしても組織がサイロ化しやすい。それはやむを得ない部分ですし、一定は受け入れるようにしています。

それに、サイロ化しても機能単位で組織がきちんと分けられていれば、うまく回ることもある。逆に、バックエンドとフロントエンドでサイロ化してしまうと、本来は2チームが協働したほうがお客様に価値を届けられるのに、チーム単位で完結する作業を選んでしまったりする。

サイロ化を避けるのではなく、サイロ化を前提に、構造やコミュニケーションをいかに綺麗に作るかが大事なのだと思います」

サイロ化しても成り立つよう組織やチームを設計するという点に加え、だいくしーさんは「サイロ化したチームがバラバラに動かないよう、会社のビジョンやミッションを共有する」重要性も指摘しました。実際にChatworkでは、月に一度ほどYouTube番組を通して社長や経営陣のメッセージを伝えているそうです。

はてなのonkさんも、サイロ化を不可避と捉え「分割統治」を意識してきたそうです。

onkさん：「今まで70人ぐらいの技術組織のなかには『全員仲間じゃん』という雰囲気が一定共有されていました。ですが、リモートワークになって各メンバーの認識できる範囲が狭まった結果、その雰囲気を共有するのは難しくなっています。

だいくしーさんも言う通り、その現象自体はどうしようもない部分がある。ですので、今は分割統治を進めています。各開発グループごとにエンジニアリングマネージャーを置き、15人～30人ぐらいで同期してもらう。各リーダーが横のつながりを持って、方向性をぶれないようにする形です。

加えて、お互いの状況を共有する場や仕組みを意識的に増やしています。詳しい内容は『[YAPC::Japan::Online 2022](https://www.slideshare.net/takafumionaka/ss-251290030)』のスライドで紹介しているので、興味のある方はよかったら見てみてください」

イベントでは参加者からの質問も多く挙がりました。サイロ化を前提に分割された組織で「ジュニアメンバーの育成をどのように進めているのか」という質問に、だいくしーさんは『組織パターン チームの成長によりアジャイルソフトウェア開発の変革を促す』の『託児所パターン』を参考にしたと紹介しました。

だいくしーさん：「『託児所パターン』ではチームを進捗組と育成組に分けます。前者は、難易度の高い仕事を進める。後者は、進捗組が進めた仕事の最後の作り込み部分などを、ベテランメンバーがジュニアメンバーに付きっきりで取り組みます。育成組では、リモートでのペアプログラミングや細かいレビューを入れて、ジュニアメンバーを育てていきます」

onkさんも「育成するメンバーがいるチームには『アウトプットが少し落ちてもいいから、チームで成果を出すことに気を払ってほしい』と声をかけることがよくある」そうです。
## 人材配置と育成の面白さ、組織に適切なパッチを当てる難しさ
イベント後半ではお二人の考えるマネジメントの面白さや悩みも共有していただきました。

onkさんは、メンバーの配置をパズル的に捉え、解く面白さと難しさを語ります。

onkさん：「育成を考える際は、それぞれのメンバーについて『このグレードのエンジニアとして活躍する』をObjectiveとして考えたときに、Key Resultが何になるか、計測可能な数値に落とし込めるかなどを整理していきます。

配置をエンジニアリング的に考えると、最終責任時点をどれだけ後ろに持っていけるかによって、柔軟性が変わる。例えば、障害対応時には何方面かに人を配置しなければいけない。その際に『このジャンルがわかるのは、この人しかいないから配置できない』といった状況が起きるのは避けたいわけです。

ですから、なるべく柔軟に対応できるように、メンバーのスキルマップを描く。なるべく広い選択肢を採れるよう、組織も人もコードベースも設計する。それは難しさであり、パズル的な面白さでもありますね」

![event-shot4](//images.ctfassets.net/ngrpflsbp3rq/4oquYg4Pa6tSU5tG0r86no/719bcbe7ca92789f366020e21bf7d9bd/event-shot4.png)

だいくしーさんからは、マネジメントの難しさとして「仕事の成果がすぐに見えない」点も指摘。現職にマネージメント職として転職した際は「こまめに1on1などのコミュニケーションを重ね、期待値を揃えること」を意識されたそうです。

また、onkさんの回答を受け、だいくしーさんは「組織に対して適切にパッチを当てていく」ことに難しさを感じると語ります。

だいくしーさん：「マネジメントをしていると『組織にパッチを当てているみたいだな』と感じることがあります。エンジニアリングと同じで、そのビッグバンマージは駄目だよねとか、ダブルライトしながらの移行期間を設けるとか。運用しながら適切にパッチを当てていく必要がある。

さらにパッチを当てられる量は筋肉のようなもの。普段から組織の変化量が多いと、大きな変化でも受け入れやすくなります。その変化に耐えうるバジェットをどれぐらい大きくしていけるのか、現状のバジェットを使いきっていないかなど、合わせて検討していくのは、なかなか難しいなと感じます」

マネジメントの面白さや難しさを語った二人に、参加者からは「マネージャーと同時にプレイヤーでもあり続けるコツは？」という質問も挙がりました。

onkさん：「結構ハードワークをしないと無理では？」が一番最初に考えたことなんですけど（笑）それ以外だと、自分のおもちゃを持っておくこと。何かしらいじり続けられる盆栽のようなサービスを持っているといいと思います。

アプリケーションのインフラをAWS CDKで管理したり、GraphQL導入してみたり。アーキテクチャをどんどん変えて遊んで、その遊びを業務にも生かす。

はてなには『はてラボ』という仕組みがあって、誰でもラボサービスを作れるんです。そこで私は「Hatena::Let」というブックマークレットを共有するサービスのメンテナーとなり、インフラを変えたりして遊んでいます」

だいくしーさんは「一つの期間ではどちらかに振り切る」ようにしているそう。

だいくしーさん：「僕個人としては、プレイヤーと両立するのは諦めています。ただ、ずっとマネージャーをやり続けると、現場感覚が損なわれ、現場と距離が離れるという問題もある。なので、個人的には時期を決めて行ったり来たりするのもいいのではと思っています。

日本の会社だと、管理職やマネージャーになるのは『昇格』で、プレイヤーに戻るのは『降格』みたいなイメージは根強いと思いますが、最近はいずれも単なる役割で上下はないという考え方が、広まりつつあると感じます。

Chatworkでも、副本部長だった人が現場に戻って仕事をするといった配置転換の事例も実際にあります。降格ではなく、別に給料も変わりません。そうやって行き来する人が増えると、個人としても現場感を持った管理職や、管理職の目線を持ったプレーヤーとして活躍できるし、組織も良くなっていく感覚があります」

![event-shot3](//images.ctfassets.net/ngrpflsbp3rq/5z0ma2pDKXCIL1jnogyFKW/a24ce3c5db812f837f870685fd958a04/event-shot3.png)

技術や組織の刷新と価値創出の両立、サイロ化を前提とした組織づくりや育成の仕組み、自分なりの遊びを持つことやマネージャーとプレイヤーの行き来をする意義など、多岐にわたるトピックが語られたイベント。一定規模の組織でエンジニアリングマネージャーとして働く面白さが伝わるとともに、最後にだいくしーさんは「マネージャーは孤独な仕事。マネージャー同士のコミュニティなども作っていけたらと思います」と語ってくださいました。

Findyは「挑戦するエンジニアのプラットフォームをつくる。」というビジョンのもと、引き続きエンジニアの組織づくりにまつわるイベントを定期的に開催しています。ぜひイベント情報をチェックしてみてください！
https://findy.connpass.com/

hatena_chatwork_eventreport

2022年3月24日に開催した『onkさんとだいくしーさんに聞くエンジニア組織づくり最前線vol.5』では、株式会社はてなの大仲能史さん、Chatwork株式会社の粕谷大輔さんをお招きし、マネージャーとしてのミッションやリモートワークにおける「サイロ化」との向き合い方、マネジメントの面白さと難しさ、プレイヤーとの両立など多岐にわたるトピックを語っていただきました。

組織のサイロ化を前提としたチーム構成、育成の仕組みとは？はてなとChatworkのエンジニアマネージャーがリモートワーク下のマネジメントを語る

eventreport-220224

株式会社マネーフォワードと株式会社アンドパッドでエンジニアリングマネージャーやテックリードとして事業や組織の成長を率いるお二人に、現在の役割に至った経緯やデータを活用した開発生産性向上のための取り組みなどを伺いました。

エンジニア組織の開発生産性を いかに定量化し、改善する？〜マネーフォワードとアンドパッドの EM・テックリードによる実践〜

data_engineer_org

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

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

eventreport ikyu stafes

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

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

vpoereport

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

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

## 登壇者プロフィール

### 下司 宜治さん/(株式会社アンドパッド)[[@gessy0129]](https://twitter.com/gessy0129?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor)

<div class="is-left"><img src="//images.contentful.com/ngrpflsbp3rq/2aNY6g7e7ldGx9E2MO340n/233e664d05094c833fb4c0463529761d/andpad_geshisan1.jpg" width="200" />
</div>

新卒でヤフーに入社。2、3度の転職を経た後、VOYAGE GROUPやサイバーエージェントにも所属。エンジニアとしての方向性をB向け領域に定める。曽祖父や姉、義理の兄が建築関係の職に就いていたこともあり、アンドパッドにジョイン。VPoEに就任し、現在に至る。

### 北野 勝久さん/(株式会社スタディスト)[[@katsuhisa__]](https://twitter.com/katsuhisa__)

<div class="is-left"><img src="//images.contentful.com/ngrpflsbp3rq/1P5LlDg13TnKAbdPotOlOA/1d1e4a7df3909ab5926906c47865e842/katsuhisasan_studist.jpg" width="200" />
</div>

日本タタ・コンサルタンシー・サービシズ株式会社にて、ERPシステムの開発・導入等のプロジェクトに携わった後、2016年8月に株式会社スタディストに入社。Teachme Bizの新規機能開発等を担当した後、2018年9月よりSREグループマネージャーとしてプロダクトの信頼性に関わる業務を担当。開発部副部長として開発組織の採用や組織づくりに携わり、2021年3月に執行役員VPoEに就任。

## エンジニア組織づくりにおける「埋もれた課題発見力」の重要性

イベント前半では、二人が日々向き合っている組織づくりの課題や取り組みについて語られました。
アンドパッドの下司さんが挙げたのは「統制整備と品質の向上」です。

__下司さん：__「『ANDPAD』は建築業界のバーティカルSaaSであり、顧客の企業活動と密接に紐づくため、より厳密なセキュリティやリリースマネジメントが問われます。一方で、ベンチャー企業としてスピード感をもってリリースをしたい気持ちもある。統制とスピード感の間で良い落としどころをどう見つけるかは模索し続けています。

統制の整備に関連してで言うと、CircleCIやAutifyなどを活用して、一部のテストを自動化しつつ、いかに品質を高めていくかも大きな課題ですね」
![vpoe1](//images.contentful.com/ngrpflsbp3rq/6wZSwxqYDLqRW3n7q41ca0/22f4e970fe4dd45562fc29f407992cd9/vpoe1.png)

スタディストの北野さんは一番の課題として「マネジメント体制をどのようにスケールさせていくか」に言及します。

__北野さん：__「どのようにマネジメントを人に任せていくか、任せられる人をいかに採用・育成していくかは常に考えています。今までは任せてみて邪魔をしない、必要な支援を必要なときだけするスタイルを採ってきましたが、もう少し選択肢の幅を広げていけるのかなと思っています。

具体的に今取り組んでいるのは、自分が注力してきた仕事や領域の言語化です。マネージャーの業務をバックログで管理し、マネジメント領域の仕事にチーム全体で向き合えるような体制への移行を進めています」

チームでマネジメント業務と向き合うという点に関連して、北野さんは「課題発見の難しさ」に触れました。「遂行する段階まで進めば、一緒に取り組める人は多い気がするのですが『これが問題だ』と認識するフェーズが難しいように感じている」と課題を共有します。

下司さんも「社内で埋もれている課題をどう発見するか、発見力を磨こうと話している」そうです。

__下司さん：__「どう課題を見つけるのか、見つけるために何をする必要があるのか、議論を重ねています。また『今誰がどのような課題を持っているのか』を日々蓄積し、アプローチ方法や関連してどのような負債があるかなどは話し合うようにしています。

北野さんと同じく、言語化して残すというのも意識してきました。Design Docにまとめたり、『プレモータム』という形で、起きてほしくない最悪のケースをまとめ、チームの意識を高めるなど行っています。」

## 情報をオープンに共有し、期間を区切り、メンバーで課題に取り組む

課題発見力に続いて話題にのぼったのは「車輪の再発明」を防ぐ方法について。二人とも積極的に情報を共有しているようでした。

__下司さん：__「もちろん内容によってオープンに残せるもの、残せないものはありますが、なるべくマネジメントや組織づくりにまつわる思考や業務は、抽象化し、残すようにしています。基本的に自分が業務で考えたこと、やろうとしていることはDesign Docに載っている状態です」

__北野さん：__「同じく残せる範囲で残すのを意識しています。あと具体の課題解決については、Slackで一時的なチャンネルを設けて話題を集約させ、ログを追いやすくすることもありますね」

こうした情報共有によって組織の課題解決にチームで取り組みやすくなるのではと北野さん。

「なるべくオープンなチャンネルに情報集約し、色んな人を巻き込むよう心掛けている」とのこと。下司さんも「興味がある人がいたら参加していいよ」というスタンスだと話します。
と同時に「メンバーが集まりすぎて、議論がダラダラと続く状態に陥るのを防ぐ」ために、区切りをつけることも決まりにしているそうです

__下司さん：__「なるべく1つの課題に対して数ヶ月単位で解決しよう、目処をつけましょうと話しています。それでも解決できなければ違うメンバーがやってみる、やり方を変えるなどアクションをしよう、と定期的な見直しも行っています。
エンジニアは発散が得意なので、一つ何かが気になると、あれもこれもやりたくなると思っていて。もちろんゴールをガチガチに固めるわけではないのですが、目安を決めてやっていこうと呼びかけています。」

## プロダクト理解や横のつながりを深めるためのオンボーディング

イベントの後半では、採用や育成、オンボーディングなどの取り組みのなかで、特に力を入れている領域について語り合いました。

二人とも「全部」と即答しつつも、最も優先しているのは採用であると話します。北野さんは元Googleの人事責任者の著書『ワーク・ルールズ! ―君の生き方とリーダーシップを変える』から、最高の人材を雇う「ニューヨーク・ヤンキース」戦略と平均的な人材を育て上げる「がんばれ！ベアーズ」戦略を引用し、「スタディストでは前者に取り組んでいる」と語りました。

オンボーディングについては両者の特色が見られました。ANDPADでは5日にわたり建設/建築業界やプロダクト理解を深める研修を実施すると下司さんが紹介します。

__下司さん：__「エンジニアが入社しても最初の5日間はほとんどコードを書きません。建設/建築業界のペインや検討されている解決策などを、部門長や代表、CFOなどに、熱く語ってもらうことで業界・プロダクト理解を深めています。

その後、各プロダクトチームにアサインする中で、より深堀ったプロダクト研修をどうしていくかを今考えているところですね。プロダクト理解をいかにするか？にかなり注力しているところはアンドパッドの特色かなと思います」

スタディストでは「全社と個別チームの二階層」でオンボーディングを捉え、取り組んでいました。

__北野さん：__「全社のオンボーディングでは、各部門の責任者が自らのチームについて話します。
『NETFLIXの最強人事戦略 自由と責任の文化を築く』で紹介されている『新入社員大学』を参考にしています。個別のチームに入ってからは、1on1に加え、他チームのリーダーやメンバーと話す機会を設けています。

また、入社後すぐに自身の経歴をチームに共有し、一緒に今後スタディストで何をやっていきたいかを発散的に話す機会もあります。その人の活躍をみんなで応援できるのに加え、入社理由を知ることで採用のアピールポイントへの理解も深められます」

![vpoe2](//images.contentful.com/ngrpflsbp3rq/3xHSh2Q7SHyhhjeCYM2RWr/c7616d1f115629e07e1dce2d7c0a3a21/vpoe2.png)

## VPoEとEMの視野の違い、VPoEの動き出しはどこから？

イベント後の質疑応答では、VPoEとして働いている、あるいは働くことに関心のある参加者から質問が沢山集まりました。

まずは「VPoEとEMの違いをどう捉えているか」について。下司さんは「VPoEとEMでは情報の集まる量が違うため、結果的に視野の違いが生まれるのではないか」と視点を示します。

__下司さん：__「EMは基本的に担当している組織と隣の組織の情報のみ、執行役員やVPoEはそれに加えて他部署の情報も集まってくる。アンドパッドでは経営会議の情報などは積極的にマネージャーにも共有し、最終的な意思決定はともかく、同じ情報、同じ示唆を得られるような環境を整えています。それが育成につながるのではと思います」

北野さんは下司さんの話に頷きつつ、別の違いを加えました。

__北野さん：__「VPoEは経営陣から経営リソースを確保する権限と責任を持っているのも違いの一つかもしれません。
あとは『マネージャーのマネージャー』として組織に向き合うことです。例えば、隣接する二つのチームで発言が食い違っているとき。VPoEがバランサーとして動く場面もあるように感じます」

続いて、1週間前にVPoEに就任したという参加者から「最初はどこから手をつけたのか」と質問がありました。

北野さんは、まずは大切にしたいことの言語化や採用にまつわる課題など、基盤の整理を進めていったと共有。下司さんは担当するチーム全員の困りごとや課題をヒアリングしていったと言います。

__下司さん：__「僕の場合、外部から転職してきたのもあり、まずは全員の話を聞いていったんですよね。そうすると、環境改善や採用など、VPoEという立場の方が解決に動きやすい課題が出てきたので、VPoEになったという順番でした。
なので、少し抽象化していうと、信頼を勝ち得るために、まずはみんなの解決したい課題に取り組んだ感じですね」

![vpoe3](//images.contentful.com/ngrpflsbp3rq/63MBv0izyLDjEZ5JLjYekE/bbdb539d6aac6579b6596f3eb98d9d03/vpoe3.png)

最後にVPoEとして今後どのように動いていきたいかを二人が共有しました。共通するのはあくまで「組織中で最適な動きをした結果、今はVPoEをやっている」という点です。

__下司さん：__「元々『組織の一番弱そうな部分の仕事をやる』ということをポリシーにしています。前職で技術部門の部門長になったのも、アンドパットでVPoEになったのも、その領域が、もっとも弱い部分だと考えたからでした。組織づくりが落ち着いたら、また別の弱い部分に力を注ぐのだと思います。
なので、今後も技術力も絶えず磨き、常に組織のどこが弱いかを見つけ、強くするために力を注げる状態の自分でいたいですね」

北野さん： 「私も良いチームで良い物作りをすることにずっと向き合いたいと思っています。
最近ではCTOのような役職にいた人がいちエンジニアに戻る例などありますし、私自身も今はVPoEですが、今後変わることは十分あり得ると考えています。これからも良いチームで良い物作りのために最適な場所にいられるようにしたいです」

今後もFindyではエンジニアのキャリアや働き方に関連するイベントを開催予定です。興味のある方はぜひこちらをフォローいただけたら嬉しいです！
https://findy.connpass.com/

また、イベント当日に株式会社アンドパッド・下司さんに言及いただいたFindy Teamsの事例記事はこちらになります！
[「エンジニア個人の振り返りや組織の課題発見に活用」株式会社アンドパッド様-Findy Teams活用事例インタビュー](https://engineering-org.findy-teams.com/posts/andpad-interview/)

vpoe-vol1

『VPoEが語るエンジニア組織づくり最前線vol.1』では、急拡大するスタートアップで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の実態、業務の面白さについてお伺いしました。

イベント

イベントレポート

エンジニア自ら「一緒に働きたいメンバー探し」を。アンドパッドとLayerXが取り組むエンジニア採用と組織づくり

組織のサイロ化を前提としたチーム構成、育成の仕組みとは？はてなとChatworkのエンジニアマネージャーがリモートワーク下のマネジメントを語る

エンジニア組織の開発生産性をいかに定量化し、改善する？〜マネーフォワードとアンドパッドの EM・テックリードによる実践〜

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

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

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

エンジニア全員の話を聞くところから始まるVPoEの仕事。求められる「課題発見力」や「オンボーディングの仕組みづくり」

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

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

イベント

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

エンジニア自ら「一緒に働きたいメンバー探し」を。 アンドパッドとLayerXが取り組むエンジニア採用と組織づくり

組織のサイロ化を前提としたチーム構成、育成の仕組みとは？はてなとChatworkのエンジニアマネージャーがリモートワーク下のマネジメントを語る

エンジニア組織の開発生産性を いかに定量化し、改善する？〜マネーフォワードとアンドパッドの EM・テックリードによる実践〜

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

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

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

エンジニア全員の話を聞くところから始まるVPoEの仕事。求められる「課題発見力」や「オンボーディングの仕組みづくり」

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

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

イベントレポート

エンジニア自ら「一緒に働きたいメンバー探し」を。アンドパッドとLayerXが取り組むエンジニア採用と組織づくり

エンジニア組織の開発生産性をいかに定量化し、改善する？〜マネーフォワードとアンドパッドの EM・テックリードによる実践〜

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