マイノリティ（少人数）な内製エンジニア組織の生存・成長戦略

マイノリティ（少⼈数）な
内製エンジニア組織の⽣存・成⻑戦略
Developers Summit 2021
2021/02/18 18-C-5

2
© 2020 DENTSU DIGITAL Inc.
⾃⼰紹介︓河内修
• Role
• 電通デジタル＞事業戦略室＞開発部
• 事業部⻑／スクラムマスター
• Experience
• ソフトハウスベンチャー＠9年
• ソフトウェアエンジニア︓実装ゴリゴリ
• 営業部⽴ち上げて部⻑23年やってた。
• ソフトウェア開発会社起業・代表取締役＠6年
• 画像解析／⾃然⾔語処理のプロダクト企画・実装
→ 機械学習に傾倒
• 資⾦繰り、税務、労務ちょっと分かる
• Spec
• Coding
• Production
• C# : 5+ years(.Net1.0-2.0)
• JAVA : 1+ years(slave of Batch-app)
• Objective-C : 2+ years
• PHP /w cake : 2+ years
• Python /w ﬂask : 1+ years
• Data Science & Analytics
• Python : 3+ years
• Certiﬁcations
• Licensed Scrum Product Owner(LSPO)
• Licensed Scrum Master(LSM)

© 2019 DENTSU DIGITAL Inc. 3
電通グループにおける役割
電通グループにおけるデジタルマーケティングの中核企業の役割を担っています
国内ネットワーク Dentsu Aegis Network
電通グループ
（純粋持株会社）
・・・
東日本
西日本
北海道
九州
電通グループ全体構造

３つのサービス領域と開発組織の関係
デジタルエージェンシー機能に加え、コンサルティングファームやSIerの機能も併せ持ち、
デジタルマーケティング促進に向け企業が求める機能をワンストップで提供します
マーケティングプラット
フォーム設計･開発
マーケティング施策
企画･実⾏
デジタル変⾰
コンサルティング

３つのサービス領域と開発組織の関係
デジタルエージェンシー機能に加え、コンサルティングファームやSIerの機能も併せ持ち、
デジタルマーケティング促進に向け企業が求める機能をワンストップで提供します
マーケティングプラット
フォーム設計･開発
マーケティング施策
企画･実⾏
デジタル変⾰
コンサルティング
技術者組織
クライアントデータ基盤開発
運用支援ツール開発
技術検証

ソフトウェア開発をメインとしていない企業が
内製開発組織を組成したときの⽣存・成⻑戦略
今⽇のテーマ

7
お話しの内容
1．組成前の状態と課題
- 内製開発組織、誕⽣前夜の状態
2．組成後のハードル⾛
- 組成してからの数々の課題とその対処
3．共通して⼀番重要だと痛感したこと
- ちょっとポエムになります。
4．取り組んだプラクティス
- 重要と痛感したことの背景となるプラクティスをご紹介
- その反動として⼤きな課題
5．まとめ
6．さいごに

8
5．まとめ
6．さいごに

9
5．まとめ
6．さいごに

10
組成前のエンジニア⼈数（2018年当時）
広告系プロダクトベンダーからの転職者が数名。
その他は別職種の部署で別の業務を⾏っていた状態。
コンサルタント系広告系
バックオフィス系
2,3名
コンサル業務
2,3名
ベンダーコントロール
⼀部⾃作
全社員
当時約900名ほど

11
組成前のエンジニア⼈数（2018年当時）
広告系プロダクトベンダーからの転職者が数名。
その他は別職種の部署で別の業務を⾏っていた状態。
2,3名
コンサル業務
2,3名
⼀部⾃作
全社員

12
当時やっていたこと
広告配信実績データの可視化基盤を作ることが主な⽣業
データソースデータ統合視覚化
連携
基盤DB
広告媒体
広告外
社内のマスタ達

13
組成前の技術スタック
現場要望に応えることで精⼀杯で、技術スタックに関する戦略は特になかった。
外部パートナー様の得意とする技術などをそのまま採⽤。
当社の技術スタック＝パートナー様の技術スタック

14
⽣まれる課題①
パートナー様に全依存だと、初期の設計がそのまま変わること無くデリバリーされる。
＝パートナー様にはオーダー通りのシステムを作って頂いている
→システム間の依存を⾒落としていることも。
何故か不定期に落ちる
バッチ『Aちゃん』
社内エンジニア
Aちゃんが落ちると
不定期に落ちる
遠くバッチ『Bくん』
え、なん
で︖︖

15
⽣まれる課題②
技術者からの「あるべき姿」の提案などはしづらく、将来を⾒据えた設計にはなりづらい
・運⽤していくと想定される現場のリクエストを加味しきれない
・無意味にブラックボックスのように⾒えてしまう（だって⾃分たちで作ってないから）
詳細の設計に
噛んでいれば別
あの外部システム
のデータを取り込
みたいです
分かりました︕
どんな使われ
⽅するんだろ
う
外部システムの仕
様を把握しないと
使えない
別の技術者
パートナー様
そのまま取り込
まれた外部シス
テムデータ
社内エンジニア

16
⽣まれる課題③
外部システムの障害は天災として崇める。
ソフトウェアの知⾒が溜まらないので全てが天災となる。
もう、怒らないでね。
外部システム⼤明神
外部システム障害

17
⽣まれる課題③
⾃分たちでシステムを⼿の内としていれば、
次の「天災」への技術的備えは、「天災」が起きれば起きるほど強固となる。
外部システム障害ありたき姿

18
内製開発組織として発⾜
当時、エンジニアが分散して存在していたが、
この様な課題を解決すべく内製開発組織として組成されました。
2,3名
コンサル業務
2,3名
⼀部⾃作
全社員

19
内製開発組織として発⾜
当時、エンジニアが分散して存在していたが、
この様な課題を解決すべく内製開発組織として組成されました。
全社員
開発部
（5名前後）
合流
中途⼊社

20
5．まとめ
6．さいごに

そのまえに。
あらゆる課題に向き合うとき、
常に必要なことがあります。

「俺達って何でここでエンジニアしてるの？」

23
内製開発組織の存在意義の共有
何故内製の開発組織が必要なのかを、定期的に話し共有した
• コアメンバーで意⾒のぶつけ合い
• メンバー全員で働きたい組織像をイメージ→ブレスト
• 重要な事ほどIMP（インプレッション、露出回数）を意図して出さないとイケない
↓開発部メンバーが毎⽇
メンテナンスするハンドブック（後述）
↓メンバー全員でブレスト ↓期初の活動計画発表で部内外にメッセージング

24
存在意義の共通認識が無いと地獄
• 全ての業務プラクティスや課題への向き合い⽅に影響する
• これが無いと各所から来る開発依頼を優先度も考えずに脳死の⽣産⼯場と化す。
• 最近では⾮エンジニアを巻き込み始めた（上司）
こーゆーのほしーつくったよー
要求
システム

25
存在意義の共通認識が無いと地獄
• 全ての業務プラクティスや課題への向き合い⽅に影響する
• これが無いと各所から来る開発依頼を優先度も考えずに脳死の⽣産⼯場と化す。
• 最近では⾮エンジニアを巻き込み始めた（上司）
こーゆーのほしーつくったよー
本当は作らなくても済んでたやつ
前に似たような作ってるやつ

26
5．まとめ
6．さいごに

27
第１ハードル︓合意形成の場が圧倒的に少ない
l 依頼者、ユーザーは要望だけ伝えて終わる。
l 作ったあとのプロダクトのビジョンは無く、その場で「欲しいな」で着⼿
l 作ったあとの運⽤は興味なし＝運⽤は分からない＝運⽤業務設計は後回し
開発チーム
依頼者／ユーザ
開発チームの外にユーザがいる

28
第１ハードル越え
ちょっとしたヒアリングシートを作る
• プロダクトのビジネスインパクト
• 事業（プロダクト）のEXITプラン
• 改廃判断（継続可否判断）責任者
が明確では無い案件は開発しない⽅針と決めた。
＝⼀緒に考えて明確にならなかったらやめよう︕

29
第２ハードル︓ガントチャートの呪縛
ü スケジュールは夜更け過ぎにノルマに変わる。
（不確実性が⼗分に除去された状況に於けるスケジュールは別）
ü ビジネスサイドはガントチャートによる情報が最も分かり易いし、慣れている。
機能A
機能B
テスト
※やむを得ずビックリリースをする際、
佳境に⼊った⽇単位でメンバー連携する場⾯ではガントチャートは良いツール

30
第２ハードル越え
ガントがコミュニケーションツールであればそれは維持。
「機能」毎ではなく「事業価値・解決する課題」毎に粒度を変える
新しい提供価値A
解決したい課題A
解決したい課題B
機能A
機能B
テスト

31
第３ハードル︓優先度が決まらない
ステークホルダーが多いので、「なんで⾃分のオーダーはそんなに時間がかかるの︖」
それぞれの事情があり、
お互いの事情が分からない
多⽅⾯から
様々な相談

32
第３ハードル越え
事案毎のステークホルダーを集めた事務局を作る。
→事案の優先度を仕分ける思考回路は
何が私たちのビジネスにインパクトを与えるのかを考えるきっかけに。
開発チーム
開発チーム
開発チーム
開発チーム
ユーザ代表
ユーザ代表
ユーザ代表
ユーザ代表
開
発
戦
略
会
議
︵
事
務
局
︶

33
第４ハードル︓外部発注と⾦額で⽐較
経済合意理性のみで外部委託と内製開発で⽐べられる時がある。

34
第４ハードル越え
社外発注出来るシステムは内部にノウハウを貯める必要が無いということなので、
パートナー様をお繋ぎします。
社外発注しましょう

ここまでは個別課題に対して
取り組んだ話

36
5．まとめ
6．さいごに

37
エンジニア組織は圧倒的マイノリティ
コンサルタントとエンジニアでは、採⽤・広報・評価など全て少し違いがある。
2%
30名 / 1500名
※駐在パートナー様含む
・採⽤⽅法、導線、⼈材プール
・広報先ターゲット
・評価スキーム

38
⼩さきことを⼤きく⾒せる
⼤きく⾒せる→⼤きくなる為の助⾛を付ける
裾野がしっかりしていると⼭の輪郭がイメージ出来る

39
⼩さきことを⼤きく⾒せる
⼤きく⾒せる→⼤きくなる為の助⾛を付ける
裾野がしっかりしていると⼭の輪郭がイメージ出来る

40
開発チーム内部の⽂化形成
その裾野が組織⽂化であると感じています。
お客様の中でDXを推進しようとして、社内スピンアウトを⾏い、
特命技術チームが組成された例もありますが、兼務である事が多く、
最初の成功事例（⾵⽳を開ける）までに⼼が折れるケースもあります。
組織⽂化

41
壁を作るでは無く、⽂化のトッピング
会社の中でも少し違うエンジニアオリエンテッドな⽂化や取り組みをすることで、
ある種の⼼の拠り所、⼼理的安全性を確保しておく。
全社的な価値観や⽂化
開発者の価値観
⽂化をトッピング

42
会社内異⽂化形成のポイント
前述の存在意義をブレストし、カルチャーステートメントとして明⽂化した上で、
下記のシンプルなパターンを実践する。
1 プラクティスを導⼊すること
例）モブプロ、社内ISUCON、評価スキーム
2 それに違いが存在すること
プラクティスに組織の独⾃性を持つ
3 それは⾃分たちで決めること
1⼈ではない⾃分たちが必要と思って提案実施

43
・「プラクティス」を導⼊すること
・それに「違い」があること
・それは「⾃分たち」で決めること
全社的な活動・取り組み
例）新卒採⽤フロー

44
全社とはちょっと「違う」。

45
全社とはちょっと「違う」。
⾃分たちで決める（提案する）

46
5．まとめ
6．さいごに

47
（組成当初から）スクラム開発を採⽤
我々エンジニアに取ってはもはやNormal
⾮エンジニアにとってはNew Normal
外から⾒れば⽴派な「業務プラクティス」。
内製チーム組成当初から、らしいプラクティスとして⼤きな⽂化形成に寄与。
寄与ポイント
• 顔を合わせる機会の増量
• 機能横断のため、職能毎のサイロ化を防ぐ
• 振り返る（レトロスペクティブ）ことが⽂化にまで昇華

48
レトロスペクティブの効能
レトロスペクティブ
⽬的︓チームのパフォーマンス向上
チームにとって障害となる問題点を何か1つ以上、
次のスプリントで実施することを決め、必ず実施。
バックログ化した⽅が良いものはPO判断のもとバックログ化を⾏う
弊社のレトロスペクティブ
• 1週間おき（1週間スプリント）
• 1時間
• KPTフレームワークを使⽤することが多い
• 個⼈の振り返りにならない様に配慮←難しい。まだまだ出来ていない。

49
レトロスペクティブの効能
レトロスペクティブは参加者全員に気づきや学び、チームの弱みを共有する装置。
ビジネスサイドと⼀緒にやることで
• 相互理解と⼼理的安全性の確保に⼤きく寄与
• エンジニアと⼀緒に作ることによる新鮮な学びを創出
ビジネスサイド＜エンジニア
こんなにしょっちゅう
振り返りを・・・
ビジネスサイドを巻き込んだスクラム勉強会

50
開発者ハンドブック『Grimoire』
h-ps://note.com/dd_techblog/n/n2cﬀ67bd@c3

51
Gitlab社の『Gitlab Handbook』
会社の運営に必要な⽂書群を全てGitリポジトリで管理
https://about.gitlab.com/handbook/
コンテンツの例として、
■ 社内コミュニケーション指針の章では、
・SlackでDMは使うな。チャンネルを使え。
・Slackは過去90⽇間しか履歴保持されない。
＝ストック型の情報はSlackではなくハンドブックに記載すべき
・Zoomでは⼈が集まるのを待つな、
時間になったらスグに開始し、終わったらぶつ切りで構わない
■ 新規JOINした⼈のオンボーディングプロセス指針の章では、
・⼊社⽇数毎にタスクリストがまとまっていて、
クイズも⽤意されている。
・同僚との計画されたMTG（同僚5⼈×5回×30分）が⽤意され、
組織の⽂化などを語らせる。
（たぶん）会社の上層から上意下達されたのではなく、
現場の集合知として『育て』続けられている。
Gitlab社
• フルリモートワーク
• 社員も世界中に広まっている
• 社員数1000⼈以上

52
参考になったマインド︓ドキュメント駆動業務
テスト駆動開発を通常業務に転⽤
ドキュメントを書いてから業務に着⼿するというワークスタイル
全ての業務が「ここを⾒れば着⼿可能な状態」に
なることを⽬指して全員がメンテナンスを⾏います。
我々で規定した主なコンテンツは、
• 部のビジョン、ミッション
• ⼤事にしている価値観
• メンバー紹介
• チーム紹介
• コミュニケーションルール
（Slack、Web会議がなるべく効率的になるような気づき）
• セキュリティポリシー
• ⼈事評価ポリシー
• オンボーディングプロセス
（チームにJOINしてなるべく迷わず、楽しく、困惑せず
⽴ち上がるための情報群）
→体系立てたチームの青写真のようなものが必要で、
ここを精緻化することはチームの業務を精緻化することに繋がる
プログラム
テストコード
業務
ドキュメント
マニュアル書いてから
業務にかかる

53
技術者⽤のキャリアパスを社の評価ステップにマッピング
全社の評価指標の枠組みの上に、技術者として歩みたいキャリアパスをはめ込み、
各グレードの要件を定義。実際の評価として使⽤。
個⼈の学びや主業務外のアウトプットする場として、
• 個⼈QDR発表会
• ⽉次プロジェクトラップ
• 週次技術共有会
• ⽉次KaizenDay
といった取り組みなど

54
やはり⼈事・広報業務にも積極的に関わっていく
• 採⽤イベントにエンジニアが参加
• 始めての内定前インターンを開始
• ダイレクトリクルーティング
結局、会社をつくることに近い内容を⾏っている。
（もちろん、⼈事や広報、経理の⽅の多⼤な労⼒を頂いていますが）
特に⽂化作りに於いては、周囲の近い距離に既存の⽂化や考え⽅が存在するので
ベンチャーを起業するとき以上の重要性と労⼒がかかる。

55
事業部⾨
とはいえ
あんまり「⽂化、⽂化」⾔っていると、サイロ化の⾜⾳が聞こえてきそうです・・・
事業部⾨の社員とより距離を近くして開発するチーム組成を今年から開始しています。
内製開発組織
チームA チームB
チームC チームD
チームD
ともにつくる

56
5．まとめ
6．さいごに

57
まとめ
• 内製開発組織が無かった会社での多くの業務委託依存による弊害
→天災への祈り
• 組成の中で露⾒した課題と対策
→ガントチャートのチューニングなど
• ⽂化を創ることを第⼀優先と捉えその初⼿
→組織⽂化作りの⼿が動きやすい3ポイント
• ⽂化を創る過程で⽣まれるプラクティスのご紹介
→レトロスペクティブの思わぬ効能
→ドキュメント駆動開発

58
5．まとめ
6．さいごに

59
マーケティングに特化した技術共有コミュニティはじめました
『Tech×Marketing』という名前で4社共催で勉強会などを定期開催しています。
h-ps://techxmarkeFng.connpass.com/

60
電通デジタルでは、
社内ベンチャーを⼀緒にしてくれる仲間を探しています︕
関連資料:
● AWSを活⽤した少⼈数チームのためのコンテナデプロイ戦略 @ DevOps Days Tokyo 2019
● 新⽶Pythonistaが贈るAirﬂow⼊⾨&活⽤事例紹介 @ PyCon JP 2019
● BigQueryで傾向スコア分析 @ DentsuDigital Tech Blog
詳しくは、こちらまで。

マイノリティ（少人数）な内製エンジニア組織の生存・成長戦略

More Related Content

What's hot

Similar to マイノリティ（少人数）な内製エンジニア組織の生存・成長戦略

マイノリティ（少人数）な内製エンジニア組織の生存・成長戦略