Slide 1

Slide 1 text

MedPeer, Inc. リモートワークがチームを「膨張」させる︖ チームを正しく「成⻑」させるためにやっていること 事業成⻑を加速させたエンジニアリングのウラ側 2021年5⽉28⽇ 保⽴ 馨

Slide 2

Slide 2 text

⾃⼰紹介 2 n 保⽴ 馨 (Kaoru Hotate) @purunkaoru n Rails and Android アプリエンジニア n プライマリケアプラットフォーム事業部のエンジニアの統括をしています 【kakari for Clinic】 2020年9⽉リリース 【kakari】 2019年6⽉リリース この資料は、Twitter #medpeer に載せてます

Slide 3

Slide 3 text

チーム構成 3 n 2020年2⽉末 リモートワーク開始時 PM CS デザイナー エンジニア サーバーサイド フロントエンド モバイルアプリ n 他に、営業の⽅々がいます n SREやコーダーは、社内の組織横断で携わっているので、ここには載せていません n 正社員だけでなく業務委託契約も含めています 6名

Slide 4

Slide 4 text

チーム構成 4 n 2021年5⽉現在 PM CS デザイナー エンジニア サーバーサイド フロントエンド モバイルアプリ n 他に、営業・営業サポート・マーケターなどの⽅々がいます n SREやコーダーは、社内の組織横断で携わっているので、ここには載せていません n 正社員だけでなく業務委託契約も含めています 6名 → 15名

Slide 5

Slide 5 text

チーム構成 5 MTGしかしてない 情報伝達の タスクが多い ⼈が増えても 成果が上がってない!? 開発中に出た疑問点が なかなか解消されない ⾃分がボトルネックに なっている︖

Slide 6

Slide 6 text

本⽇のテーマ 6 1. 膨張するチームと成⻑するチームの⽐較 2. チームが成⻑するためにやった 2つの⽅針と 3つの施策

Slide 7

Slide 7 text

1. 膨張するチームと成⻑するチームの⽐較 7 1. 膨張するチームと成⻑するチームの⽐較 2. チームが成⻑するためにやった 2つの⽅針と 3つの施策

Slide 8

Slide 8 text

膨張するチームと成⻑するチームの⽐較 8 個⼈に依存しない再現性のある仕組みが必要。 n チームの膨張 Ø 与えられたタスクに集中して、⾃発的な課題発⾒が⾏われない Ø 意思決定者がボトルネックになる n チームの拡⼤には、ただ⼈数が増える「膨張」と、 チームとしての質も向上する「成⻑」の2種類がある n チームの成⻑ Ø 各⾃がプロジェクトの⽬的を認識し、⾃ら課題を⾒つけて解決する Ø 適切に権限委譲が⾏われ、決まった意思決定者がボトルネックにならない

Slide 9

Slide 9 text

膨張するチームと成⻑するチームの⽐較 9 膨張するチーム PM ・⼀部のメンバー 課題 発⾒者 マネージャー・リーダー 意思 決定者 成⻑するチーム 全員 普段の業務中に ⾃然と課題を発⾒・共有できる 全員 個⼈・チーム問わず キーマン対その他 コミュニ ケーション 全員対全員 不変 権限 常に最適化

Slide 10

Slide 10 text

リモートワークによる「膨張」の加速 10 n フルリモートワークにおいては、コミュニケーションの機会が限られ、 権限委譲や⾃発的な課題解決が阻まれる n コミュニケーションの⼿間が増加 Ø 情報が局所化 • ⾃発的に課題発⾒・問題解決をしづらい Ø 「⾃分がやった⽅が早い」から脱却できない • 権限委譲をしづらい n リモートワーク環境でチームが拡⼤した時は、 今まで以上に「膨張」を防がないといけない

Slide 11

Slide 11 text

本⽇のテーマ 11 1. 膨張するチームと成⻑するチームの⽐較 2. チームが成⻑するためにやった 2つの⽅針と 3つの施策

Slide 12

Slide 12 text

12 成⻑するチームにするための2つの⽅針 ①⾃発的な 課題解決への 動機付け ②意⾒を 出しやすい 環境の醸成 全メンバーが、サービスに対して当事者意識を持ち、 ⾃発的に課題を発⾒して問題解決する姿勢を保つ 課題を発⾒するための情報提供と、 その課題を共有・議論できる場を⽤意する ⽅針 内容

Slide 13

Slide 13 text

成⻑するチームにするための2つの⽅針 13 ①⾃発的な 課題解決への 動機付け ②意⾒を 出しやすい 環境の醸成 ・⾏動指針の認識合わせと適切な権限委譲 ・意思決定の理由を共有 ・発信できる場の⽤意 ⽅針 施策

Slide 14

Slide 14 text

⾃発的な課題解決への動機付け 14 ①⾃発的な 課題解決への 動機付け ②意⾒を 出しやすい 環境の醸成 ・⾏動指針の認識合わせと適切な権限委譲 ⇨ 1on1で⾏動指針から⽬標を設定する ・意思決定の理由を共有 ・発信できる場の⽤意 ⽅針 施策

Slide 15

Slide 15 text

キャリアプランからの動機付けは有効か 15 ※ ⾃分の⼒不⾜の要因がかなりあるが、棚に上げさせていただく キャリアプランは変わるもの。 より不変で、かつチーム全員が共感できる何かをベースに動機付けをする Ø 会社の⾏動指針 n キャリアプランからの動機付けの失敗 ≈ マネージャーに 俺はなる︕ 1ヶ⽉後 ≈ コード書いて ⾃分のサービス作るぞ ≈ 来⽉までに AとBとCやれるようになる 1ヶ⽉後 ≈ 私、先⽉何か ⾔いましたっけ︖

Slide 16

Slide 16 text

施策1: 会社の⾏動指針からの動機付け 16 1on1や⽬標設定・振り返りでは、 当事者意識を持って課題解決していきましょうということを軸に設定。 そこに、その⼈の得意なこと・興味があること・挑戦したいことを紐づける n メドピアのCredo ⾏動指針

Slide 17

Slide 17 text

意⾒を出しやすい環境の醸成 17 ①⾃発的な 課題解決への 動機付け ②意⾒を 出しやすい 環境の醸成 ・⾏動指針の認識合わせと適切な権限委譲 ⇨ 1on1で⾏動指針から⽬標を設定する ・意思決定の理由を共有 ・発信できる場の⽤意 ⽅針 施策

Slide 18

Slide 18 text

施策2: 意思決定の理由を共有 18 n なぜこの機能を開発するのか、なぜこの実装⽅針をとったのか、 理由が分からないとアイディアの発案や判断ができない。 新しい機能の追加 他の 選択肢 n ⾃サービスの課題 n (可能であれば) ⽬標 対象の 分析 新しいライブラリの導⼊ 市場 n 何をするライブラリなのか n メンテされているのか n 考えた他の選択肢との⽐較 n 競合企業はどうしているのか n 他業種はどうしているのか n 他者の利⽤状況 共有⽅法 n 対⾯: 要件検討MTG n ⽂書: GitHub Issue n Pull Request / Commit Comment n (必要あれば)週次のMTG n 他のライブラリとの⽐較 n ベンチマーク

Slide 19

Slide 19 text

施策3: 課題を発信できる場の⽤意 19 #just_idea 全員 投稿者 n プロダクトに関すること n 機能・デザインなど⾊々 解決したい 課題 #dev_team_kaizen 全員 チケット起票するか悩ましいものを 気軽に相談できる 設置理由 n 専⽤のSlackチャンネルを作成し、ふと発⾒した課題を気軽に発信できる場を⽤意。 n 専⽤のチャンネルにすることで、他の話題で投稿が流れるケースを減らせる。 n 開発フロー改善 n コミュニケーション n 会議体 KPTからの代替。 課題を感じた瞬間に議論できる 問題解決までじっくり議論できる 8〜10くらいのアイディア/⽉ 半分くらいは採⽤ 実績 要件定義のフォーマット作成 新規機能開発の企画〜デザイン〜 開発の流れを修正

Slide 20

Slide 20 text

さいごに 20 ご清聴ありがとうございました よかったら #medpeer でつぶやいてね