エンジニア数が3倍になる過程でのエンジニア組織の段階的育成アプローチ

Copyright coconala Inc. All Rights Reserved.
Developers Summit 2023
エンジニア数が3倍になる過程での
エンジニア組織の段階的育成アプローチ
2023.2.9
株式会社ココナラ
村上正敏

View Slide

2
村上正敏
株式会社ココナラ
執⾏役員開発担当
Web系スタートアップにて、toC
向けプロダクト開発を複数経験し
た後、2019年にココナラに参画
現在は、技術⾯〜組織⾯まで開発
全般の⽅針策定・推進を担当

View Slide

ココナラの事業紹介 / サービス⼀覧（⼦会社除く）
3
「知識・スキル・経験」
を売り買いできるスキル
マーケット
「ココナラ」
ITフリーランス向け
業務委託案件紹介サービス
「ココナラエージェント」
ビジネス向けに特化した
スキルマーケット
「ココナラビジネス」
⼀⼈ひとりにあった弁護⼠
が⾒つかる検索メディア
「ココナラ法律相談」

View Slide

ココナラの事業紹介 / ココナラの概要
4
知識・スキル・経験を商品化し、ECのように売り買い

View Slide

5
Agenda
フェーズ０︓取り組み前の状態
フェーズ１︓技術施策の推進
フェーズ２︓エンジニア評価・育成
フェーズ３︓技術広報
まとめ
1
2
3
３
4
5

View Slide

Chapter 1
6

View Slide

数年前の状況
7
事業拡⼤に合わせて3年で約3倍の組織規模に成⻑
2020年 2023年
フェーズ上場前上場後
エンジニア数 20⼈強 60⼈強
リポジトリ数 45 146
1

View Slide

Q. 技術負債解消できてますか︖
8
ところで質問です

View Slide

1
技術負債の対応状況
9
A. 数年前は技術負債に⼿が回らない状況でした
● 具体な技術負債例
● 各種バージョンアップ対応︓なし
● レガシーコードの単体テスト︓なし
● スロークエリ等の対応︓なし
● 軽微な障害対応︓なし
事業成⻑にコミットした結果

View Slide

10
1
変わろうとしたきっかけ
⻑年蓄積した負債が、障害という形で顕在化し、
ユーザー様にご迷惑をかけることが増えてきた。
⼀⽅、社内から開発に関する不満の声もあがっていた。
この状況を問題視し、状況の打破に向けて動き出した。

View Slide

フェーズ1︓技術施策の推進
Chapter 2
11

View Slide

Chapter 02
12
2.1. できない理由の解消
2.2. 運⽤ラインの導⼊
2.3. 技術ロードマップの導⼊
2.4. 開発委員会の導⼊

View Slide

2
すぐに技術課題に取り組んだほうが良いのか︖
13
すぐに技術課題に取り組む
まずはできない理由と向き合う
継続できない

View Slide

2
過去の振り返り
14
⼀般的になぜ技術負債は後回しにされるのか
● 理由の⼀例
● 他に優先度が⾼いものがある
● リソース上の余裕がない
● 難易度が⾼すぎて⼿に負えない
● ⾯倒くさい、楽しくない

View Slide

2
できない理由の深堀り例
15
なぜ「優先度が上がらない」のか
優先度の認識が関係者間ですり合っていない
⾔いたいことが相⼿に⼗分伝わってない
相⼿の視座に⽴った会話ができていない

View Slide

2
認識がすり合っていない例（実際の例ではないです︕）
16
サポート期限が切れる
のでバージョンアップ
すべき
売上貢献度的にもっと
優先度⾼い施策がある
のでは︖
VS
脆弱性を攻撃されると、損害や機会損失などの経営上マイナス
インパクトが⼤きいため、バージョンアップを優先すべき
（根拠となるデータを⾒せながら）
こういう翻訳があると伝わりやすい

View Slide

2
認識すり合わせの重要性
17
相⼿の視座に合わせて会話すると、
関係者間で認識がすり合ってくる。
その結果、優先度設定が適切になり、
同時に納得感ももてるようになる。

View Slide

2
できない理由の解消
18
何かできない理由がある場合は
まずそれを取り除いていくことが⼤事

View Slide

Chapter 02
19

View Slide

20
⽇々蓄積していく⼩さいタスクの消化が課題
● 具体なタスク例
● 軽微な不具合・障害対応
● 社内からの調査依頼への対応
● 問い合わせ内容個別対応
● 軽微なSEO対策等
⼩規模な技術課題の例
2

View Slide

Q. 20％ルールってやってますか︖😇
21
※業務時間の20％を好きなことに使っていいルールで、Googleが実践

View Slide

Q. 合計120%になってませんか︖😭
22
やってる⽅に追加で質問
※ 80%+20%のはずが 100%+20%

View Slide

23
メイン業務中の合間に気合でやる(120%)
計画的に作業タイムを作る(100%)
リソースの確保をどうするか
2

View Slide

運⽤ラインにおける時間確保のやり⽅
24
施策間に隙間時間を活⽤し、持ち回り制で運⽤
施策推進
ライン
運⽤
ライン
施策A
タスク
タスクタスク
施策B
施策C
施策D
X
Y
Z
2
・・・・・・
※必ず誰かがアサインされている状況にする事が⼤事

View Slide

運⽤ラインにおけるタスク管理
25
実施する施策は、部署毎に優先順位付けして管理
2
Githubなどの
ツールで
チケット管理
部署別バックログ

View Slide

⾒積もり会を通じたタスクの精査
26
⾒積もり会で⼯数⾒積もりと優先度判断を実施
2
各種改善要望
（不具合等）
毎週の
⾒積もり会
フロントエンドの
バックログ追加
バックエンドの
アプリの
PdM、FE、BE、APPなど
関係者が参加

View Slide

27
⼩規模施策を優先度管理し、
新規導⼊した運⽤ラインによって、
持ち回り制で推進できるようになった。
運⽤ラインまとめ
2

View Slide

Chapter 02
28

View Slide

あまり技術負債解消されてなくない︖😵💫
29
運⽤ライン導⼊したけども・・・

View Slide

30
技術施策の⼤きさと対応状況
2
分類規模感対応状況
⼩規模施策 1週間程度 OK
中規模施策数週間〜１ヶ⽉程度 NG
⼤規模施策数ヶ⽉〜 NG
中〜⼤規模の技術施策は取り組めていなかった
←運⽤ラインの
スコープ

View Slide

31
中規模施策は、複数部署横断の内容が多く、
部署毎の施策管理では限界がある。
中規模技術施策の課題
2
部署横断の共通的な施策管理が必要

View Slide

32
技術ロードマップの整理
2
中〜⼤規模の技術施策は部署横断でリストアップ
技術ロードマップ

View Slide

33
技術ロードマップの施策の⼯数確保
2
隙間時間ではなく、１施策として関係者のリソースを確保
施策推進
ライン
技術
ライン
運⽤
ライン
施策A
タスク
タスクタスク
施策B
施策C
施策D（技術）
X
Y
Z
・・・・・・

View Slide

Chapter 02
34

View Slide

難易度⾼い問題は相変わらず残ってるよね😵
35
ある程度は負債解消進んでいるけども

View Slide

難易度⾼い課題が着⼿できない理由
36
なぜ「難易度が⾼いと⼿に負えない」のか
課題が抽象的すぎてどこから着⼿すればいいかわからない
課題が実施可能な粒度までブレイクダウンされていない
2

View Slide

課題をブレイクダウンした例（実際の例ではないです︕）
37
サービスが重いのを解消したい
⼤きすぎるのでブレイクダウンする
アプリ側とインフラ側でわけて負荷対策を実施する
アプリ側で負荷軽減インフラ側でスケーラビリティ向上
まだ曖昧なのでさらにブレイクダウンする
スロークエリを
個別で対策
⼀部データを
⾮RDB化
サーバーの
台数追加
Aurora
への移⾏
・・・・・・
2

View Slide

課題をブレイクダウンする重要性
38
⼤きな課題は、適切にブレイクダウンすれば、
計画も⽴てやすくなり、施策は推進しやすくなる
2
関係者で集まって定期的に議論する場が必要と考え
テーマ毎に開発委員会を設置
でも上記は誰でも簡単にできるわけではない

View Slide

各開発委員会のテーマ
39
2
委員会名⽬的
QA開発委員会品質向上およびQA⾃動化推進
開発環境改善委員会開発環境刷新および開発スピードの向上
SLO委員会可⽤性向上、負荷軽減
パフォーマンス委員会パフォーマンス、スケーラビリティ向上
インフラ改善委員会保守運⽤の効率化、セルフサービス化
プロダクト改善委員会バージョンアップ対応
情報セキュリティ向上委員会各種情報セキュリティ対策

View Slide

開発委員会の位置づけ
40
2
部署定例での
議論内容
各プロジェクト
の振り返り
各種
ポストモーテム
テーマ毎の
開発委員会
テーマ毎の
開発委員会
テーマ毎の
開発委員会
技術ロードマップ
に登録し推進
さまざまな技術課題を持ち寄り開発委員会で討論
・課題提起とブレイクダウン
・各課題の優先度判断と⽅針議論
・施策の進捗モニタリング
参加は⾃由

View Slide

ここからは開発委員会施策の例を３つ紹介します
41

View Slide

施策の⼀例︓各種バージョンアップ対応（期間︓各1ヶ⽉程度）
42
2
リポジトリ対象サポート期限 1Q 2Q 3Q 4Q
repo_A Ruby / 2.7.7 2023/03/31 ◯
repo_B
Vue.js /
2.6.14
2023/09/23 ◯
repo_C
Ubuntu /
22.10
2023/07/20 ◯
対象物のEOLをリストアップし、期限に応じて計画作成
ソリューションマップ（現在︓約200件）

View Slide

施策の⼀例︓Web/APPのE2Eテスト⾃動化（期間︓半年以上）
43
2
Playwright
Appium
APP
WEB
QA⼯程におけるE2Eテストの⼀部を⾃動化
ReportPortal
E2Eテストツールテスト実⾏結果
独⾃のCI環境

View Slide

施策の⼀例︓DBスケーラビリティ（期間︓1年以上）
44
2
RDS
（MySQL 5.7）
Aurora
（MySQL8）
RDS
（MySQL 5.7）
Aurora
（MySQL8）
RDS
（MySQL 5.7）
Aurora
（MySQL8.0）
・5.7→8.0、RDS→Auroraへの影響調査
・本番を想定した性能検証、負荷試験
・E2Eテストによる動作確認
・DB毎の⼊念な移⾏計画策定
IOPSの限界やサポート期限を考慮し、Aurora移⾏を実施中

View Slide

技術施策を推進した結果
45
2
頑張った結果、⽣産性が⾼い企業として表彰されました

View Slide

フェーズ１まとめ
46
2
→ 相⼿の視座に⽴った認識のすり合わせ
→ ⼩規模施策を部署別で推進
→ 中規模施策を全社共通で推進
→ ⼤規模施策をブレイクダウンして推進

View Slide

Chapter 3
47

View Slide

「この会社で、今後エンジニアとしての
キャリアがイメージできません😥」
48

View Slide

エンジニア評価に関する課題感
49
3
エンジニアの専⾨能⼒が⼗分評価されていない
キャリアアップの道筋が⾒えない
エンジニアの技術⼒を評価する仕組みが必要
評価制度は全社で共通

View Slide

50
そもそも技術⼒ってなんだろ︖🤔

View Slide

技術⼒の４分類
51
3
「技術⼒＝技術を使って問題解決できる能⼒」として定義
技術⼒
問題発⽣前にどう防ぐか
（システム設計・計画⼒）
問題継続中にどう運⽤改善するか
（運⽤強化⼒）
問題発⽣後にどう応急対処するか
（技術原因解決⼒）
上記対応⼈材をどう確保し育成するか
（採⽤育成⼒）

View Slide

エンジニアグレード表の整備
52
3
グレードを定義し、技術⼒レベルを細かく明⽂化
6~
5~
4~
3~
2~
1~
マネジメント
トラック
エキスパート
トラック
エンジニア共通トラック
技術⼒４分類
エンジニアグレード表

View Slide

53
グレード定義はいいけど、評価どうするの︖

View Slide

技術⼒評価の軸
54
3
技術成果物（FACT）を元に能⼒レベルを評価
グレード定義技術成果物
技術⼒の４分類
・技術原因解決⼒
・システム設計・計画⼒
・運⽤強化⼒
・採⽤育成⼒
・ソースコード
・ドキュメント
・各種対応履歴・ログ
・その他ファクト

View Slide

技術⼒評価委員会
55
3
エンジニア
上⻑評価
技術⼒評価
委員会
最終
評価結果
委員会で第３者視点での客観的かつ公平な評価を実施
エンジニア
上⻑評価
エンジニア
上⻑評価
最終
評価結果
最終
評価結果
エンジニアマネージャー
が複眼で評価

View Slide

エンジニアキックオフによる技術交流
56
3
際⽴つ成果については、定期的なキックオフで全体共有
LT形式で成果を共有
懇親会で横断的に交流

View Slide

フェーズ２まとめ
57
3
技術⼒をエンジニアグレードという形で定義し、
それを⽤いた評価/FBサイクルを設計
その結果、各⼈のキャリアパスが明確になり、
1on1でもキャリアに対する相談が増えた

View Slide

フェーズ３︓技術広報（現在）
Chapter 4
58

View Slide

59
「御社はテックブログとかやってないんですね🥴」

View Slide

外部発信に関する課題感
60
4
エンジニアからの認知度が低く、採⽤時に苦戦
情報発信が⼀切ないため、興味を持てない状況
技術的な外部発信を強化していく必要がある

View Slide

外部発信のコンテンツについて
61
4
採⽤⾯・育成⾯で、技術広報を強化したいが
何を発信すればいい・・・︖
技術ロードマップで推進している内容を
飾らずそのまま発信していけばいいのでは︖

View Slide

現在〜今後の実践
62
4
テックブログの
推進
ITイベント
登壇
外部メディアに
事例掲載
社外勉強会
採⽤ページ
の拡充
カンファレンス
の協賛
以下のようなことを実施してきました＆今後も頑張ります

View Slide

まとめ
Chapter 5
63

View Slide

まとめ
64
5
エンジニア数が３倍になる過程で以下を実施
● ⼤⼩さまざまな技術施策推進体制を構築
● エンジニアに特化したグレード評価制度を整備
● 採⽤⾯・育成⾯で外部情報発信を強化

View Slide

さいごに
65
5
私⾃⾝が現場で課題を感じる中で、
メンバーと共に相談しながら、
現在の状況を作り上げてきました
今後もさらなる成⻑に向けて頑張っていきます

View Slide

ご清聴
ありがとうございました

View Slide

エンジニア数が3倍になる過程でのエンジニア組織の段階的育成アプローチ

エンジニア数が3倍になる過程でのエンジニア組織の段階的育成アプローチ

coconala_engineer

More Decks by coconala_engineer

Other Decks in Technology

Featured

Transcript