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

身近な人に使ってもらいFeedbackをもらうのが好きなWebエンジニアにマッチする、コーポレートエンジニアというキャリアがあるのはご存知でしょうか？
toB向けプロダクトを開発していたWebエンジニアがDeNAのコーポレートエンジニアに転職し、感じたことを率直にお話します。
また、特に課題と感じた入社当時のチーム状況や新規エンジニアの受け入れ体制について、スクラムなどを活用しチームメンバーと、この半年で行ってきた取り組みを紹介します。

Transcript

1. toBのWebエンジニアから DeNAのコーポレートエンジ ニアへ 小山　達也
2. 自己紹介 株式会社ディー・エヌ・エー システム本部IT統括部IT戦略部システム開発グループ 小山 達也｜Tatsuya Koyama • 2013/4 ~ 会計システムを開発する会社に就職（アーキテクト） • 2021/5 ~ 株式会社ディー・エヌ・エー 　IT戦略部システム開発グループ コーポレートエンジニアとして、会計業務の効率化を目的とする システム開発チーム『Rome』にJoin
3. 今日お話したいこと • 導入 ◦ 自己紹介 ◦ システム開発グループの紹介 • 転職前のイメージと入社してから感じた良かった点 • 入社してから感じた課題とその対応 • まとめ • 最後に...
4. DeNA IT戦略部システム開発グループとは？ DeNAでは様々なアプリケーションを利用しています ⇒ しかし、それだけでは色々足りない...(あれしたい.これしたい.） ⇒ そもそも、そんなシステム売ってない... そのシステム我々が作ります！
5. システム開発Gのアプリケーションとチーム規模 • 作業時間集計（工数管理） • 経理業務サポート ◦ 一括登録 ◦ 原価計算 ◦ 費用振替ツール ◦ NetSuite用のアドオン ...etc • マッサージ予約システム • 携帯電話の管理システム などなど 約６０システム ８人
6. システム開発チーム『ROME』 • 作業時間集計（工数管理） • 経理業務サポート ◦ 一括登録 ◦ 原価計算 ◦ 費用振替ツール ◦ NetSuite用のアドオン ...etc • マッサージ予約システム • 携帯電話の管理システム などなど メンバー • システム開発 ⇒ 4名（ココ！） • 業務改革推進 ⇒ 4名
7. 今日お話したいこと • 導入 ◦ 自己紹介 ◦ システム開発Gの紹介 • 転職前のイメージと入社してから感じた良かった点 • 入社してから感じた課題とその対応 • まとめ • 最後に...
8. 皆さん情シスってどんなイメージですか？ 1. システム開発はSIerへ発注！ 2. いわゆる『上流工程』しかやらなそう（提案依頼書や要 件定義など） 3. インフラ（社内ネットワークとか）や社内システムの運 用がメイン？ （DeNAは） 違います！
9. DeNAのコーポレートエンジニアでは 1. システム開発はSIerへ発注！ ⇒ 現在は完全に社内開発 Rome開発メンバー Sさん 入社14年の大ベテラン 気さくで優しい Kさん インフラはお任せ お酒大好き Kさん 作業時間管理マスター 素直な若者 私 まだまだ勉強中
10. DeNAのコーポレートエンジニアでは 2. いわゆる『上流工程』しかやらなそう（提案依頼書や要 件定義など） ⇒ 開発チーム全員がコーディングも行います。
11. DeNAのコーポレートエンジニアでは 3. インフラ（社内ネットワークとか）や社内システムの運 用がメイン？ ⇒ インフラやサポートは専用のチームが行います システム本部IT統括部 IT基盤部 ⇒社内システムのインフラチーム IT戦略部 業務改革推進グループ　 ⇒　規模の大きい案件のユーザー調整やユーザーサポート システム開発グループ ⇒　システムの開発！
12. 入社してから感じた良い点 1. 良い意味で、前職のtoB向けWebアプリ開発と同じレベルの開発体験 CI/CD • 自動テスト（カバレッジ70％） • GitHubにマージされたら自動Deploy • モニタリング（エラー発生時に自動でメール・Slack通知） ⇒社内システムだが、昨今の一般的なWebアプリと同レベルの開発体験 コスト意識 • ストレージやインスタンスタイプは運用可能な最低限にカスタマイ ズ • ユーザー要望であっても対応効果をしっかり吟味する（場合によっ ては「対応しない」選択も）
13. 入社してから感じた良い点 2. ユーザーとの距離が非常に近い • 対応完了したらすぐにフィードバック 実装⇒テスト⇒ソースレビュー⇒検証環境でユーザーテスト ユーザーと一緒にシステムを作り上げる • 利害関係の一致 コーポレート業務をより低コストで効率化したい
14. 入社してから感じた良い点 3. より上流のシステム設計へ挑戦 • １つのプロダクトだけでは なく、様々サービスやアプ リケーションを組みあわせ て全社に最適なシステムを デザインする
15. 今日お話したいこと • 導入 ◦ 自己紹介 ◦ システム開発Gの紹介 • 転職前のイメージと入社してから感じた良かった点 • 入社してから感じた課題とその対応 • まとめ • 最後に...
16. 入社してから感じた課題 2. ソースコードの品質やアーキテクチャなどは改善の余地あり • 手続き的なソース 複雑なドメインでは、ドメインオブジェクトを活用 したい。よりOOPに沿ったコードにしたい。 • よりクラウドネイティブなアーキテクチャへ 2020年にオンプレからAWSへ移行。 ただし、現在はEC2上での動作となっている。
17. 入社してから感じた課題 3. 新規メンバーの受け入れ体制 • 開発環境を作れない × 複雑 × 構築手順書がない 改善済み！（私の初めての仕事でした）
18. 開発環境構築の改善 Visual Studio Code Remote - Containers Extension Docker Compose - Develop - Database - Batch 3. 新規メンバーの受け入れ体制 A. 開発環境のDockerコンテナ化
19. 開発環境構築の改善 B. テストデータの流し込み 予めテストデータを作成し、Dumpしたものを共有 ⇒ 上記データをインポートするスクリプトを作成し、コマンド一つで データまで作成 Day 1から活躍 3. 新規メンバーの受け入れ体制
20. 入社してから感じた課題 4. チーム状況 • 属人化 • 優先順位が見えない システムB担当 システムA担当 システムC担当 システムBを早 く改修してほし いのに... ユーザー部門 開発部門
21. 入社してから感じた課題 4. チーム状況 私の入社前からチーム内で課題を感じていた。 そこで、スクラムの導入までは決まっていた。 5月 6月 7月 8月 スクラム開始 入社 スクラムマスター
22. スクラム定着までの流れ 1. フレームワークの理解 各スクラムイベント毎にド キュメントを作成。 そのイベントで各自がどの ような役割を担っている か？打ち合わせ中はつねに その資料を見ながら進め た。
23. スクラム定着までの流れ 2. チーム意識の醸成（そして自己組織化へ...）
24. スクラム定着までの流れ 2. チーム意識の醸成（そして自己組織化へ...） A. ソースレビューの時間を毎日確保。全員でレビュー。 B. レトロスペクティブでベロシティ向上を本気で議論。 5月 7月 9月 6月 8月 スクラムスタート A B
25. スクラム定着までの流れ 2. チーム意識の醸成（そして自己組織化へ...） 5月 7月 9月 6月 8月 スクラムスタート A B C A. ソースレビューの時間を毎日確保。全員でレビュー。 B. レトロスペクティブでベロシティ向上を本気で議論。 C. デイリースクラムで各自の進捗を全員が把握している。
26. スクラム定着までの流れ 2. チーム意識の醸成（そして自己組織化へ...） 5月 7月 9月 6月 8月 スクラムスタート A B C A. ソースレビューの時間を毎日確保。全員でレビュー。 B. レトロスペクティブでベロシティ向上を本気で議論。 C. 朝のデイリースクラムで各自の進捗を全員が把握している。 D. ペアプロ・モブプロの導入 （毎スプリントで最低１案件とルール化。平均３件くらい） D
27. スクラム定着までの流れ 2. チーム意識の醸成（そして自己組織化へ...） 5月 7月 9月 6月 8月 スクラムスタート A B C A. ソースレビューの時間を毎日確保。全員でレビュー。 B. レトロスペクティブでベロシティ向上を本気で議論。 C. 朝のデイリースクラムで各自の進捗を全員が把握している。 D. ペアプロ・モブプロの導入 （毎スプリントで最低１案件とルール化。平均３件くらい） E. タスクのアサインを徐々に各自に委ねる。 D E
28. スクラム定着までの流れ 2. チーム意識の醸成（そして自己組織化へ...） 5月 7月 9月 6月 8月 スクラムスタート A B C A. ソースレビューの時間を毎日確保。全員でレビュー。 B. レトロスペクティブでベロシティ向上を本気で議論。 C. 朝のデイリースクラムで各自の進捗を全員が把握している。 D. ペアプロ・モブプロの導入 （毎スプリントで最低１案件とルール化。平均３件くらい） E. タスクのアサインを徐々に各自に委ねる。 D E
29. スクラム導入の結果（導入５ヶ月） 1. 属人化の解消 どうしても複雑なドメイン知識が必要なので、システム全体は 難しい。⇒ 引き続き取り組む ただ、新規案件については、全員が保守できる状態！ 2. 明確な優先順位 これは完全に達成された。 今は優先順位が高いものをチーム全員で取り組む体制になって いる。 3. Romeシステム全体に対する当事者意識 「このシステムは〇〇さん担当」という認識は完全になくなっ た。各自がより効率的にタスクを消化するために声をかけあ い、融通しあっている。 4. 開発が楽しい やっぱりチームで、あーだこーだ言いながら開発は楽しい
30. 今日お話したいこと • 導入 ◦ 自己紹介 ◦ システム開発Gの紹介 • 転職前のイメージと入社してから感じた良かった点 • 入社してから感じた課題とその対応 • まとめ • 最後に...
31. まとめ アーキテクチャ 新規メンバーの 受け入れ体制 チーム状況 Dockerを使った開発 環境構築の自動化 スクラムの導入 たくさんコード書け る時間と環境 toB向けのプ ロダクト開発 と同レベルの 開発体験 ユーザーとの 距離が非常に 近い 良い点 課題
32. 最後に... DeNAのコーポレートエンジニアは本当の意味で”エンジニア集 団”です。 社内業務効率化のためにユーザーと協力して、自分たちで手を動 かしながらシステムで解決します。 そしてDeNAでは社歴などによるヒエラルキーがまったくありま せん。 合理性があれば、自分でどんどん改善していけます。 DeNAのコーポレートシステムをより良くしていくために、様々 な視点を持ったエンジニアを募集しています。