toBのWebエンジニアからDeNAのコーポレートエンジニアへ【DeNA TechCon 2021 Autumn】/techcon2021autumn_10

Slide 1

Slide 1 text

toBのWebエンジニアから DeNAのコーポレートエンジニアへ小山　達也

Slide 2

Slide 2 text

自己紹介株式会社ディー・エヌ・エーシステム本部IT統括部IT戦略部システム開発グループ小山達也｜Tatsuya Koyama ● 2013/4 ~ 会計システムを開発する会社に就職（アーキテクト） ● 2021/5 ~ 株式会社ディー・エヌ・エー　IT戦略部システム開発グループコーポレートエンジニアとして、会計業務の効率化を目的とするシステム開発チーム『Rome』にJoin

Slide 3

Slide 3 text

今日お話したいこと ● 導入 ○ 自己紹介 ○ システム開発グループの紹介 ● 転職前のイメージと入社してから感じた良かった点 ● 入社してから感じた課題とその対応 ● まとめ ● 最後に...

Slide 4

Slide 4 text

DeNA IT戦略部システム開発グループとは？ DeNAでは様々なアプリケーションを利用しています ⇒ しかし、それだけでは色々足りない...(あれしたい.これしたい.） ⇒ そもそも、そんなシステム売ってない... そのシステム我々が作ります！

Slide 5

Slide 5 text

システム開発Gのアプリケーションとチーム規模 ● 作業時間集計（工数管理） ● 経理業務サポート ○ 一括登録 ○ 原価計算 ○ 費用振替ツール ○ NetSuite用のアドオン ...etc ● マッサージ予約システム ● 携帯電話の管理システムなどなど約６０システム８人

Slide 6

Slide 6 text

システム開発チーム『ROME』 ● 作業時間集計（工数管理） ● 経理業務サポート ○ 一括登録 ○ 原価計算 ○ 費用振替ツール ○ NetSuite用のアドオン ...etc ● マッサージ予約システム ● 携帯電話の管理システムなどなどメンバー ● システム開発 ⇒ 4名（ココ！） ● 業務改革推進 ⇒ 4名

Slide 7

Slide 7 text

今日お話したいこと ● 導入 ○ 自己紹介 ○ システム開発Gの紹介 ● 転職前のイメージと入社してから感じた良かった点 ● 入社してから感じた課題とその対応 ● まとめ ● 最後に...

Slide 8

Slide 8 text

皆さん情シスってどんなイメージですか？ 1. システム開発はSIerへ発注！ 2. いわゆる『上流工程』しかやらなそう（提案依頼書や要件定義など） 3. インフラ（社内ネットワークとか）や社内システムの運用がメイン？（DeNAは）違います！

Slide 9

Slide 9 text

DeNAのコーポレートエンジニアでは 1. システム開発はSIerへ発注！ ⇒ 現在は完全に社内開発 Rome開発メンバー Sさん入社14年の大ベテラン気さくで優しい Kさんインフラはお任せお酒大好き Kさん作業時間管理マスター素直な若者私まだまだ勉強中

Slide 10

Slide 10 text

DeNAのコーポレートエンジニアでは 2. いわゆる『上流工程』しかやらなそう（提案依頼書や要件定義など） ⇒ 開発チーム全員がコーディングも行います。

Slide 11

Slide 11 text

DeNAのコーポレートエンジニアでは 3. インフラ（社内ネットワークとか）や社内システムの運用がメイン？ ⇒ インフラやサポートは専用のチームが行いますシステム本部IT統括部 IT基盤部 ⇒社内システムのインフラチーム IT戦略部業務改革推進グループ　 ⇒　規模の大きい案件のユーザー調整やユーザーサポートシステム開発グループ ⇒　システムの開発！

Slide 12

Slide 12 text

入社してから感じた良い点 1. 良い意味で、前職のtoB向けWebアプリ開発と同じレベルの開発体験 CI/CD ● 自動テスト（カバレッジ70％） ● GitHubにマージされたら自動Deploy ● モニタリング（エラー発生時に自動でメール・Slack通知） ⇒社内システムだが、昨今の一般的なWebアプリと同レベルの開発体験コスト意識 ● ストレージやインスタンスタイプは運用可能な最低限にカスタマイズ ● ユーザー要望であっても対応効果をしっかり吟味する（場合によっては「対応しない」選択も）

Slide 13

Slide 13 text

入社してから感じた良い点 2. ユーザーとの距離が非常に近い ● 対応完了したらすぐにフィードバック実装⇒テスト⇒ソースレビュー⇒検証環境でユーザーテストユーザーと一緒にシステムを作り上げる ● 利害関係の一致コーポレート業務をより低コストで効率化したい

Slide 14

Slide 14 text

入社してから感じた良い点 3. より上流のシステム設計へ挑戦 ● １つのプロダクトだけではなく、様々サービスやアプリケーションを組みあわせて全社に最適なシステムをデザインする

Slide 15

Slide 15 text

Slide 16

Slide 16 text

入社してから感じた課題 2. ソースコードの品質やアーキテクチャなどは改善の余地あり ● 手続き的なソース複雑なドメインでは、ドメインオブジェクトを活用したい。よりOOPに沿ったコードにしたい。 ● よりクラウドネイティブなアーキテクチャへ 2020年にオンプレからAWSへ移行。ただし、現在はEC2上での動作となっている。

Slide 17

Slide 17 text

入社してから感じた課題 3. 新規メンバーの受け入れ体制 ● 開発環境を作れない × 複雑 × 構築手順書がない改善済み！（私の初めての仕事でした）

Slide 18

Slide 18 text

開発環境構築の改善 Visual Studio Code Remote - Containers Extension Docker Compose - Develop - Database - Batch 3. 新規メンバーの受け入れ体制 A. 開発環境のDockerコンテナ化

Slide 19

Slide 19 text

開発環境構築の改善 B. テストデータの流し込み予めテストデータを作成し、Dumpしたものを共有 ⇒ 上記データをインポートするスクリプトを作成し、コマンド一つでデータまで作成 Day 1から活躍 3. 新規メンバーの受け入れ体制

Slide 20

Slide 20 text

入社してから感じた課題 4. チーム状況 ● 属人化 ● 優先順位が見えないシステムB担当システムA担当システムC担当システムBを早く改修してほしいのに... ユーザー部門開発部門

Slide 21

Slide 21 text

入社してから感じた課題 4. チーム状況私の入社前からチーム内で課題を感じていた。そこで、スクラムの導入までは決まっていた。 5月 6月 7月 8月スクラム開始入社スクラムマスター

Slide 22

Slide 22 text

スクラム定着までの流れ 1. フレームワークの理解各スクラムイベント毎にドキュメントを作成。そのイベントで各自がどのような役割を担っているか？打ち合わせ中はつねにその資料を見ながら進めた。

Slide 23

Slide 23 text

スクラム定着までの流れ 2. チーム意識の醸成（そして自己組織化へ...）

Slide 24

Slide 24 text

スクラム定着までの流れ 2. チーム意識の醸成（そして自己組織化へ...） A. ソースレビューの時間を毎日確保。全員でレビュー。 B. レトロスペクティブでベロシティ向上を本気で議論。 5月 7月 9月 6月 8月スクラムスタート A B

Slide 25

Slide 25 text

スクラム定着までの流れ 2. チーム意識の醸成（そして自己組織化へ...） 5月 7月 9月 6月 8月スクラムスタート A B C A. ソースレビューの時間を毎日確保。全員でレビュー。 B. レトロスペクティブでベロシティ向上を本気で議論。 C. デイリースクラムで各自の進捗を全員が把握している。

Slide 26

Slide 26 text

スクラム定着までの流れ 2. チーム意識の醸成（そして自己組織化へ...） 5月 7月 9月 6月 8月スクラムスタート A B C A. ソースレビューの時間を毎日確保。全員でレビュー。 B. レトロスペクティブでベロシティ向上を本気で議論。 C. 朝のデイリースクラムで各自の進捗を全員が把握している。 D. ペアプロ・モブプロの導入（毎スプリントで最低１案件とルール化。平均３件くらい） D

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

スクラム導入の結果（導入５ヶ月） 1. 属人化の解消どうしても複雑なドメイン知識が必要なので、システム全体は難しい。⇒ 引き続き取り組むただ、新規案件については、全員が保守できる状態！ 2. 明確な優先順位これは完全に達成された。今は優先順位が高いものをチーム全員で取り組む体制になっている。 3. Romeシステム全体に対する当事者意識「このシステムは〇〇さん担当」という認識は完全になくなった。各自がより効率的にタスクを消化するために声をかけあい、融通しあっている。 4. 開発が楽しいやっぱりチームで、あーだこーだ言いながら開発は楽しい

Slide 30

Slide 30 text

Slide 31

Slide 31 text

まとめアーキテクチャ新規メンバーの受け入れ体制チーム状況 Dockerを使った開発環境構築の自動化スクラムの導入たくさんコード書ける時間と環境 toB向けのプロダクト開発と同レベルの開発体験ユーザーとの距離が非常に近い良い点課題

Slide 32

Slide 32 text

最後に... DeNAのコーポレートエンジニアは本当の意味で”エンジニア集団”です。社内業務効率化のためにユーザーと協力して、自分たちで手を動かしながらシステムで解決します。そしてDeNAでは社歴などによるヒエラルキーがまったくありません。合理性があれば、自分でどんどん改善していけます。 DeNAのコーポレートシステムをより良くしていくために、様々な視点を持ったエンジニアを募集しています。

Slide 33

Slide 33 text

No content