Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
襲来する課題の山に立ち向かう開発体制づくり
Search
yasudatoshiyuki
November 17, 2021
Technology
0
180
襲来する課題の山に立ち向かう開発体制づくり
急成長の中で開発組織の規模が50名に迫ろうとするiCAREの課題を赤裸々に語ります。
開発組織の全体像の把握はマネジメント以外の人にも大切なので、全ての開発者に聞いてほしい!
yasudatoshiyuki
November 17, 2021
Tweet
Share
More Decks by yasudatoshiyuki
See All by yasudatoshiyuki
エンジニア採用戦略で変わったこと、変わらないこと
yasudatoshiyuki
1
2k
エンジニアリングマネジメントでいかに事業をドライブするか?
yasudatoshiyuki
0
120
iCAREという組織にVPoEが必要になった理由とVPoEが果たす役割
yasudatoshiyuki
0
56
Rails開発者向けGraphQL入門
yasudatoshiyuki
0
37
CarelyでBuefy使ってみてどうだった?
yasudatoshiyuki
0
73
Kubernetesでの環境構築および運用フロー構築のはなし
yasudatoshiyuki
0
86
GraphQLを導入してよかったこと大変だったこと
yasudatoshiyuki
0
99
Other Decks in Technology
See All in Technology
FlutterアプリにおけるSLI/SLOを用いたユーザー体験の可視化と計測基盤構築
ostk0069
0
110
DynamoDB でスロットリングが発生したとき_大盛りver/when_throttling_occurs_in_dynamodb_long
emiki
1
440
AGIについてChatGPTに聞いてみた
blueb
0
130
AI前提のサービス運用ってなんだろう?
ryuichi1208
8
1.4k
IBC 2024 動画技術関連レポート / IBC 2024 Report
cyberagentdevelopers
PRO
1
120
【Pycon mini 東海 2024】Google Colaboratoryで試すVLM
kazuhitotakahashi
2
560
生成AIが変えるデータ分析の全体像
ishikawa_satoru
0
170
組織成長を加速させるオンボーディングの取り組み
sudoakiy
2
220
オープンソースAIとは何か? --「オープンソースAIの定義 v1.0」詳細解説
shujisado
10
1.3k
これまでの計測・開発・デプロイ方法全部見せます! / Findy ISUCON 2024-11-14
tohutohu
3
370
DynamoDB でスロットリングが発生したとき/when_throttling_occurs_in_dynamodb_short
emiki
0
270
Security-JAWS【第35回】勉強会クラウドにおけるマルウェアやコンテンツ改ざんへの対策
4su_para
0
180
Featured
See All Featured
BBQ
matthewcrist
85
9.3k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
1.9k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
24k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Navigating Team Friction
lara
183
14k
Designing the Hi-DPI Web
ddemaree
280
34k
The Cost Of JavaScript in 2023
addyosmani
45
6.8k
Intergalactic Javascript Robots from Outer Space
tanoku
269
27k
Documentation Writing (for coders)
carmenintech
65
4.4k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.7k
A Philosophy of Restraint
colly
203
16k
Transcript
©iCARE Co., Ltd All rights reserved 1 襲来する課題の山に立ち向かう 開発体制づくり 2021年11月17日
株式会社iCARE VPoE 安田俊之
©iCARE Co., Ltd All rights reserved ここにタイトルが入ります 2 ここに本文が入ります ここに本文が入ります
ここに本文が入ります 自己紹介
©iCARE Co., Ltd All rights reserved 自己紹介 3 安田俊之 Twitter:
@TakataNoToshi iCAREにて2020年7月よりVPoE 関わってきた技術 Ruby on Rails, Vue.js, AngularJS PHP, Java, Perl その他: Terraform, Ansible, Chef, AWS, etc.
©iCARE Co., Ltd All rights reserved ここにタイトルが入ります 4 ここに本文が入ります ここに本文が入ります
ここに本文が入ります なぜこのテーマについて話すのか?
©iCARE Co., Ltd All rights reserved 5 2019年10月時点(資料) 正社員約10名、パートナー6名 2021年11月現在(資料)
正社員30名、パートナー15名 2年間で 急増 開発チーム規模は急拡大
©iCARE Co., Ltd All rights reserved 6 それを超える サービス拡大 組織拡大しても課題の山
課題の襲来
©iCARE Co., Ltd All rights reserved 7 これに立ち向かうために開発体制作りで格闘しているという話
©iCARE Co., Ltd All rights reserved 有益かつ応募があるかも 8 この手の格闘は業界や会社固有の問題というよりはス タートアップに共通の課題
・スタートアップ企業の開発者にとって有益 ・課題解決が面白そう、取り組みたい、 と考える方がiCAREに応募してくれるかも 課題の共有
©iCARE Co., Ltd All rights reserved ここにタイトルが入ります 9 ここに本文が入ります ここに本文が入ります
ここに本文が入ります iCARE開発チームを取り巻く状況
©iCARE Co., Ltd All rights reserved 10 iCAREおよびCarelyの歴史 2011年(10年前) 創業
2016年(5年前) Carelyローンチ 2021年 導入社数:470社(10月時点) 日本の人事部「HRアワード2021」人事労 務管理部門 最優秀賞受賞
©iCARE Co., Ltd All rights reserved チャットによる 相談・アドバイス 従業員向け
一元管理で 圧倒的に効率化 人事・産業医向け 企業の健康を トータルサポート 従業員 メディカルスタッフ 人事・産業医 チャット クラウド 健康診断 ストレス チェック 残業時間 01 サービス概要
©iCARE Co., Ltd All rights reserved 12 課題への直面 順調に成長をしてはいるが、 急激な成長の中で
様々な課題にも直面し始めている・・・
©iCARE Co., Ltd All rights reserved 顕在化してきている開発課題 13 顧客の増加や顧客層の変化 特に大手企業
の増加 過去に比べて 多様で複雑な要望を 受ける機会が急増
©iCARE Co., Ltd All rights reserved 主な要望の変化 14 1. 多様な機能
2. 多様なユーザー権限体系 3. 多様な他システムとの連携(SSO IdP、API) 4. より高いセキュリティ基準 5. より安定したサービス提供 実現 システムが複雑化
©iCARE Co., Ltd All rights reserved システムの複雑化 15 1. 思わぬところで不具合が出る
テストコードや動作確認で防止しても、事前予測が難し い依存関係により不具合が発生 2. システム全体を把握することが困難 不具合が発生した時に原因の特定に時間がかかった り、問題解決の難易度が上がる
©iCARE Co., Ltd All rights reserved 高くなる専門性 16 フロントエンド サーバーサイド
インフラ それぞれ高い専門性が必要になるため、それぞれの領 域の壁を超えて作業する難易度が高くなる それぞれの領域の間にある問題が置き去りになる
©iCARE Co., Ltd All rights reserved 開発体制として求められている点 17 問題の解決難易度が上がる中で、多様な課題を 最速で、かつ並行して解決していく必要がある
チャレンジングですねー
©iCARE Co., Ltd All rights reserved ここにタイトルが入ります 18 ここに本文が入ります ここに本文が入ります
ここに本文が入ります これらの問題を解決するための 開発体制
©iCARE Co., Ltd All rights reserved 開発体制として求められている点 19 1. 開発要員の増員
2. 多様な要求に応えるチーム構成 3. 管理可能なチームサイズ 4. チームごとのマネージャー・リーダー 5. 領域の間問題を最速で解決するフィーチャーチーム制 6. 領域の間を埋める多様な開発ロール (具体的には、QAE、セールスエンジニア、 プロジェクトマネージャなど)や各種委員会の設置
©iCARE Co., Ltd All rights reserved フォーカスする話題 20 1. 開発要員の増員
2. 多様な要求に応えるチーム構成 3. 管理可能なチームサイズ 4. チームごとのマネージャー・リーダー 5. 領域の間問題を最速で解決するフィーチャーチーム制 6. 領域の間を埋める多様な開発ロール (具体的には、QAE、セールスエンジニア、 プロジェクトマネージャなど)や各種委員会の設置
©iCARE Co., Ltd All rights reserved チーム構成の前提条件 21 昨今エンジニア採用の競争はとても熾烈 潤沢ではない開発リソースの中でなんとか開
発体制をを作らなければならない
©iCARE Co., Ltd All rights reserved 開発チーム構成詳細 22 COO CTO
シニアマネージャー キャプテン チーム CTO VPoE 健診 QAE CTO室 基盤技術 CTO 応用技術 パートナー 技術顧問 デザイ ン SRE 現状はこんな感じです
©iCARE Co., Ltd All rights reserved チーム構成の説明 23 健診 基盤技術
チーム チーム 応用技術 3つのフィーチャーチーム(フロントエンド・バックエンド) ファンクションチーム デザイン QAE 技術 顧問 パートナー SRE CTO室
©iCARE Co., Ltd All rights reserved チーム構成の意図 24 アプリケーションエンジニアが3つの フィーチャーチームに分かれている理由
1. Carelyの中で健診関連開発は機能的な独立性を持っており、他 機能よりもドメイン知識が必要。そのため、チームとして独立したほ うが開発効率が良い 2. 健診関連開発以外の開発は、機能で分割するのは難しい。た だ、一つのチームを構成するにはメンバーが多く、メンバー管理が 難しい。→2つのチームに。
©iCARE Co., Ltd All rights reserved ここにタイトルが入ります 25 ここに本文が入ります ここに本文が入ります
ここに本文が入ります 開発チーム体制が抱える課題
©iCARE Co., Ltd All rights reserved チーム構成の意図 26 アプリケーションエンジニアが3つの フィーチャーチームに分かれている理由
1. Carelyの中で健診関連開発は機能的な独立性を持っており、他 機能よりもドメイン知識が必要。そのため、チームとして独立したほ うが開発効率が良い 2. 健診関連開発以外の開発は、機能で分割するのは難しい。た だ、一つのチームを構成するにはメンバーが多く、メンバー管理が 難しい。→2つのチームに。 責務の境界が曖昧
©iCARE Co., Ltd All rights reserved オペレーションチームの不在とチームの責務の曖昧さ 27 顧客増加により、調査やGUIから操作できないデータ操 作オペレーションが増加
現状はそれぞれのフィーチャーチームの誰かが開発を 止めて対応 リリースが近かったり、スケジュールが厳しかったりする と自発的に拾いに行けない やりくり
©iCARE Co., Ltd All rights reserved サーバーサイド、フロントエンドの業務量のアンバランス 28 フロントエンド Vue.js
サーバーサイド Ruby on Rails ひとりひとりのメンバーは、基本的にどちらかの役割を 担っており、状況に応じてスイッチしていない 業務量は、現状の人員構成 にあわせて発生するわけではない 言語が異なり、かつ高い専門性 が必要が必要なためスイッチが 難しい やりくり
©iCARE Co., Ltd All rights reserved 体制変更の連続によるメンバーへの精神的負担 29 人数の増加に伴う度重なる体制の変化 ・対人関係が苦手な人は、チーム構成が変わることによって関わる
人が変わり、心理的に負担がかかる ・本人が希望しない役割を求められる フラストレーション ストレス ケア・ 個別対応
©iCARE Co., Ltd All rights reserved リーダー・マネージャー不足 30 これらの問題に対応するために リーダー・マネージャーが必要
採用/育成 志望するエンジニアが少ない 経験・スキルが足りない
©iCARE Co., Ltd All rights reserved 開発チーム構成詳細 31 COO CTO
シニアマネージャー キャプテン チーム CTO VPoE 健診 QAE CTO室 基盤技術 CTO 応用技術 パートナー 技術顧問 デザイ ン SRE 様々な課題を解決するために 作られた体制。でもこの体制も またいろいろな課題を抱えてい る。しかも来月も5人ジョイン ・・・。
©iCARE Co., Ltd All rights reserved 課題はチーム構成以外にも山ほどある・・・ 32 ・難易度の高い問題を解決できるメンバーが一部のメンバー に限られる
・エンジニアが開発と採用活動を並行しなければいけない ・プロダクトの成熟の中で、軒並み課題の難易度が高くジュ ニアエンジニアのオンボーディングが難しい ・様々なエンジニアの志向性にあわせたキャリアパスの用意 などなど、この他にもたくさん・・・
©iCARE Co., Ltd All rights reserved ご応募お待ちしています 33 こうした課題解決が面白そう/取り組みたいと考える勇者! いらっしゃいましたらぜひiCAREにご応募ください!
©iCARE Co., Ltd All rights reserved 実は最高のチーム! 34 テーマがテーマだったので、ネガティブな話が多くなってしまいましたが、 実は最高のメンバーが集まる、最高のチームです!
©iCARE Co., Ltd All rights reserved iCAREでは 35 課題と伸びしろとドラマがあ なたを待っています
©iCARE Co., Ltd All rights reserved ここにタイトルが入ります 36 ここに本文が入ります ここに本文が入ります
ここに本文が入ります ご清聴ありがとうございました