rakuten-recruit_event_2024/05/08_fv

大規模組織における開発生産性向上へのアプローチ

NewsPicks_Findy Teamsブログ画像

2022年における開発組織のパフォーマンス計測とNewsPicksの取り組みについて

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

営業の目標設定ってわりと「売上: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年間を振り返ってみた

20220105192203

Findy Teamsの指標を使ってチームの生産性を改善しよう

20220104014836 2

Findy Teamsで2021年をふりかえってみた。

pr times visualization

開発チームの成果をFindy Teamsで可視化したグラフを公開します！

一休伊藤さん事例記事

リモートでむしろ生産性が上がったエンジニア組織の作り方を一休 CTOの伊藤さんに聞いてみた

## 登壇者プロフィール

### 下司 宜治さん/(株式会社アンドパッド)[[@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に就任。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<span class="nile-blue">北野さん：</span> 「私も良いチームで良い物作りをすることにずっと向き合いたいと思っています。
最近では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の仕事。求められる「課題発見力」や「オンボーディングの仕組みづくり」

星野リゾート_Findy Teamsブログ画像

Findy Teamsを導入してみた

rectangle large type 2 a1dda3fcd0baa0778f6a5f19be427db9 2

正式リリースされた Findy Teams で dinii のエンジニアリングチームの生産性を可視化してみた

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

記事一覧

2022年における開発組織のパフォーマンス計測とNewsPicksの取り組みについて - NewsPicks, Inc.

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

Findy Teamsの指標を使ってチームの生産性を改善しよう - 株式会社アンドパッド

Findy Teamsで2021年をふりかえってみた。 - 株式会社星野リゾート

開発チームの成果をFindy Teamsで可視化したグラフを公開します！ - 株式会社PR TIMES

リモートでむしろ生産性が上がったエンジニア組織の作り方を一休 CTOの伊藤さんに聞いてみた - 株式会社一休

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

Findy Teamsを導入してみた - 株式会社星野リゾート

正式リリースされた Findy Teams で dinii のエンジニアリングチームの生産性を可視化してみた - dinii

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