30年間、事業を支えてきた業務システムをDDDで刷新する。 そのためには、組織的、エンジニアのレベルなど多くの問題があります。 その壁をどう乗り越えたのか？ そして、壁の向こうで得た恩恵とは何のか？ 5年という期間を経て、得ることのできた気づきや組織的な変化をお伝えしたいです。

1. © BIGLOBE Inc.
西 秀和
レガシーなコードに
ドメイン駆動設計で立ち向かった
5年間の軌跡
DDD Alliance
5年間のDDDの取り組みと
今後について

2. 2 © BIGLOBE Inc.
アジェンダ
第１章．DDD導入に至るまで
第２章．導入時の苦労
第３章．導入による効果
第４章. 今後の目標

3. 3 © BIGLOBE Inc.
第１章. DDD導入に至るまで

4. 4 © BIGLOBE Inc.
BIGLOBE
ポータル
BIGLOBEカスタマーサポート
BIGLOBE販売システムとは？
エンドユーザ
が見やすい
データへ加工 オペレーターが
見やすい
データへ加工
キャリア毎の
データ差異を
吸収
固定回線キャリア
N
固定回線キャリア
K
モバイル回線キャリア
D
モバイル回線キャリア
A
webページ
コールセンター
回線業者
(キャリア)
↓本日、お話する範囲
販売システム

5. 5 © BIGLOBE Inc.
販売システムの規模感
API・バッチ本数
6500本

6. 6 © BIGLOBE Inc.
この販売システムへ
５年かけてDDD
を適用した話をします

7. 7 © BIGLOBE Inc.
適用を始めた当時(２０１０年頃)の開発の環境
・外注依存
・開発言語が独自言語
・テストは全て手動
・開発はサーバ上でvi ※viはdisってません
・開発用PCがWindows ※商用サーバはLinux

8. 8 © BIGLOBE Inc.
適用を始めた当時(２０１０年頃)の開発の環境
〇外注依存
→システム毎に別会社の別チームへ発注する
→設計を上位のSlerが実装は下請けが行うため、設計と実装が乖離する
→社内にエンジニアが育たない
〇開発言語が独自言語
→ググっても調べられない
→他社では絶対に使えないので、エンジニアのキャリアにならない。
〇テストは全て手動
→仕様の確認のために簡単に動かせないので、挙動をテスト報告書で調べる
→そもそもテストデータを作るのも熟練の技が必要
〇開発はサーバ上でvi
→IDEのサポートがないため、ヒューマンエラーによる記述ミスが多い。
→サーバが飛んだら、終わり。
〇開発用PCがWindows
→そもそも、独自言語がWindowsでは動かない

9. 9 © BIGLOBE Inc.
何が起きたのか？
webページ
A
コールセンター
α
回線業者１
(キャリア)
販売システム
回線業者２
(キャリア)
webページ
B
コールセンター
β
開発会社A
チームa
開発会社A
チームb
開発会社B
チームc
開発会社C
チームd
開発会社A
チームb
開発会社D
チームe
会社ごとの流派で
個別にシステムが作られる
システム1
システム2 システム3 システム4 システム5
システム6
開発者１

10. 10 © BIGLOBE Inc.
何が起きたのか？
webページ
A
コールセンター
α
回線業者１
(キャリア)
販売システム
回線業者２
(キャリア)
webページ
B
コールセンター
β
開発会社A
チームa
開発会社A
チームb
開発会社B
チームc
開発会社C
チームd
開発会社A
チームb
開発会社D
チームe
販売システム全体ではどうなるの？
システム1
システム2 システム3 システム4 システム5
システム6
わかりません
わかりません
わかりません
わかりません
わかりません わかりません

11. 11 © BIGLOBE Inc.
つまり、カオス
何が起きたのか？

12. 12 © BIGLOBE Inc.
何が起きたのか？
詳細な仕様の把握や影響調査が一
部の熟練者にしかできない
機能の追加/変更の影響調査に
時間がかかる
→ 変更が困難
→ 属人性が高い(神格化)

13. 13 © BIGLOBE Inc.
ここで大きな舵が切られた
アジャイル開発
（スクラム）
索引：https://www.ipa.go.jp/files/000004853.pdf

14. 14 © BIGLOBE Inc.
ここで大きな舵が切られた
アジャイル（スクラム）による
開発プロセス改革へ
↓
プロダクトを中心とした
チーム開発へ

15. 15 © BIGLOBE Inc.
アジャイル（スクラム）導入による限界
開発プロセスは良くなった。
でも、独自言語では
開発の生産性があがらない
世の中の技術（OSS等）の
恩恵を受けられない
↓

16. 16 © BIGLOBE Inc.
開発のやり方を全てを見直し
・外注依存 → アジャイル化
・開発言語が独自言語 → Java/Spring
・テストは全て手動 → テストコード & CI
・開発はサーバ上でvim → IDE(Intellj)
・開発用PCがWindowｓ → MacBook

17. 17 © BIGLOBE Inc.
当時の課題感
開発プロセスを変えても、
設計・実装のやり方を変えなければ、
システムはよくならない。

18. 18 © BIGLOBE Inc.
当時の課題感
webページ
A
コールセンター
α
回線業者１
(キャリア)
販売システム
回線業者２
(キャリア)
webページ
B
コールセンター
β
意味とデータと業務ロジックが散らばっていて、
整理の仕方が分からない
ex )電話番号
システム1
システム2
システム3 システム4
システム5
システム6
電話番号
日中の連絡
に使っても
いいんだっけ？
ハイフンの加工
が必要なんだっけ？
電話番号 電話番号
自宅と日中の連絡用の
電話番号をもらう
(ハイフンなし)
携帯の
電話番号をもらう
(ハイフンあり)
お客様の
電話番号をもらう
(ハイフンあり)
回線先の
電話番号をもらう
(ハイフンなし)
DB
意味の喪失
業務ロジックが
散らばっている
↓
ユビキタス言語
↓
ドメイン設計

19. 19 © BIGLOBE Inc.
当時の課題感
これは、
DDDでいけるかも！！

20. 20 © BIGLOBE Inc.
第２章. 導入時の苦労

21. 21 © BIGLOBE Inc.
導入における壁
１．DDDやり方
２．ドメイン層以外の雑音
３．実プロジェクトへの適用
４．組織への展開
５．エンジニアの育成

22. 22 © BIGLOBE Inc.
１．DDDのやり方
やり方とは？
・ドメインモデルの考え方
・それぞれのレイヤーの責務の考え方
・業務ロジックの閉じ込め方
・依存関係の考え方
これらの考え方や手法を、
コードの表現方法まで含めて理解すること

23. 23 © BIGLOBE Inc.
【壁の超え方】１．DDDのやり方
独学でがんばるより、先駆者に教えてもらおう
先駆者に毎週、来てもらった（半年ぐらい）
→ 一緒にドメインモデルを作る
→ 書いてみたコードをレビューしてもらう
〇手段
ドメインの切り方、メソッドの置き場所などの考え方の
根幹・根拠を理解しないと意味がない。
独学だとコーディングルールの適用で満足してしまう。

24. 24 © BIGLOBE Inc.
・ログ設計
ドメイン層以外の雑音とは？
・トランザクション管理
・文字コードへの対応
・例外・アラーム設計
・レガシー領域とのインターフェース(腐敗防止層)
・共通パラメータの設計
・システム監視のための仕組み
２．ドメイン層以外の雑音
：

25. 25 © BIGLOBE Inc.
ドメインに集中したいのに！！
Domain
Model
Application
InfrastructureUser Interface
プロダクト外の世界
いつも渡されるパラメータ
例外・アラーム設計
システム監視設計
トランザクション管理
ログ出力
レガシー領域との接点
文字コード対応（古いDB）
気になっちゃう雑音 気になっちゃう雑音
２．ドメイン層以外の雑音
ココに集中したい！！

26. 26 © BIGLOBE Inc.
【壁の超え方】２．ドメイン層以外の雑音
Interface/Infrastructure層の「共通の関心事」を集めた独自ラ
イブラリを整備する。
※ドメイン層のユーティリティ用のライブラリは優先順位は後
〇手段
プロダクト外との接点は雑音が多い。
雑音に惑わされずに、
ドメインへ集中できる環境を整備していく。
そのために、サービスに依存しない「共通の関心事」を
ライブラリ化してしまう。

27. 27 © BIGLOBE Inc.
パイロット（初期）プロジェクトは
リスクだらけ
・誰もやった事がない。
見積もりがあてにならない
３．実プロジェクトへの適用
・失敗すると取り組み自体が批判される
・担当でないサービスの案件を突然やるため、
業務知識も浅い

28. 28 © BIGLOBE Inc.
【壁の超え方】 ３．実プロジェクトへの適用
パイロット（初期）プロジェクトの条件に合う案件を
探す、融通してもらう（社内政治も大切）
・納期がゆるい
・影響が少ない(他システムとの依存度)
・新規サービス(小さい)
〇手段

29. 29 © BIGLOBE Inc.
・ノウハウの蓄積。
(やり方、考え方、ハマりポイントなど)
・今後、組織へ展開する時にサンプルコードとなる
・ドメイン層は何度も作り直した方がいい
【壁の超え方】 ３．実プロジェクトへの適用
リリースする事と共に以下の目的が大切

30. 30 © BIGLOBE Inc.
ところがどっこい

31. 31 © BIGLOBE Inc.
全く納期に間に合わず
プロジェクト失敗

32. 32 © BIGLOBE Inc.
【壁の超え方】 ３．実プロジェクトへの適用
←原因

33. 33 © BIGLOBE Inc.
プロジェクト失敗で、このリスクが顕著化
・他の案件をやっているエンジニアから批判され
てへこむ・・・
壁を乗り越えられませんでした・・・
・失敗すると取り組み自体を批判される
・自分たちの取り組みへの自信の喪失

34. 34 © BIGLOBE Inc.
・社内（上司）は不安に対する答えを知っている人、
経験した人はいない
・新しいことへの挑戦は常に不安と隣合わせ
３．実プロジェクトへの適用(メンタル編)
・この先に良い未来があるのか不安
パイロット（初期）プロジェクトは
リスクだらけ（メンタル編）

35. 35 © BIGLOBE Inc.
既に実践して成功している人、経験している人の話は素直に
受け入れられる。
(同じ話でも実践していない人の話だと受け入れられない。)
改めて自分たちの取り組みの価値を聞く事でモチベーションを
取り戻せる。
【壁の超え方】 ３．実プロジェクトへの適用(メンタル編)
メンターの重要性
外部の先駆者の話を聞きましょう
(励ましてもらう)
〇手段

36. 36 © BIGLOBE Inc.
４．組織への展開
無事にパイロットプロジェクトが完了したので、
次は組織へ展開が必要
・現場のエンジニアの説得
→DDDしろと命令するとDDDをする事が目標になる
→学びが必要になるため、モチベーションが必要
・上司の説得
→アジャイル化の流れで説得がほぼいらなかった
(ラッキー♪)

37. 37 © BIGLOBE Inc.
【壁の超え方】 ４．組織への展開
DDDを実践する理由を
ビジョンを描いて布教する
〇手段
・共感できるビジョンが必要
・モチベーションを上げるためにはメリットが必要
※お給料は無理なので、
仕事が楽になるとかキャリアにつながるとか

38. 38 © BIGLOBE Inc.
では、
BIGLOBEの現場で布教する時に
どんなビジョンを描いたのか？

39. 39 © BIGLOBE Inc.
【壁の超え方】 ４．組織への展開（BIGLOBE版）
そもそも、
現場が抱えていた課題とは？

40. 40 © BIGLOBE Inc.
【壁の超え方】 ４．組織への展開（BIGLOBE版）
〇変更が容易になる
〇属人性が低くなる
・コンテキストごとに責務が分かれている
・レイヤーを分けてドメイン層を守るため、プロダクト外の変更
から影響を受けづらい
・データとロジックが同じ場所にあるため、影響箇所の特定が
容易
・コードが業務用語で書かれるため、仕様と実装が乖離せず
理解しやすい
・ドメインモデルはみんなで作るため知識の偏りが起きない

41. 41 © BIGLOBE Inc.
【壁の超え方】 ４．組織への展開（BIGLOBE版）
サービス開発の
トータルコストを下げる
変更が容易 属人性が低減する
BIGLOBEが提供しているサービスの特性
・提供するサービスのライフサイクルが長い（10～20年）
・初期導入コストではなく、維持、機能拡張のコスト削減の方が効果が大きい
・サービスの終わりまで同じエンジニアがメンテナンスし続けるのは難しい

42. 42 © BIGLOBE Inc.
５．エンジニアの育成
・Javaを書いた事がない
・オブジェクト指向も分からない
・テストコードも書いた事ない
展開したエンジニアの出発地点
Javaギルドの設立
・業務時間内/外で少しづつ勉強
・Javaの構文から覚える
・動くコードでリファクタリングを体験
・テストコードは必要性から説く

43. 43 © BIGLOBE Inc.
５．エンジニアの育成
・DDDのノウハウは初期チームにしかない。
・初期チームはリリースまでに1年ぐらいかかった。
・ DDDのノウハウをドキュメント、コードだけで理解するのは
ハードルが高い
・開発案件はたくさんあるため、既存チームからメンバー
を引きはがして、成長するのを待つほど余裕がない。
DDDのノウハウを伝授しないといけない

44. 44 © BIGLOBE Inc.
【壁の超え方】 ５．エンジニアの育成
のれん分け方式〇手段
・ノウハウを理解したメンバーを分けて、
そこへメンバーを追加してチームを立ち上げる
・案件の中で実践しながらDDDのやり方を覚えていく

45. 45 © BIGLOBE Inc.
５年間で
どこまで展開したのか？

46. 46 © BIGLOBE Inc.
展開の状況
DDDを実践しているエンジニア数
チーム数
※販売システムを開発しているエンジニア
５０人
１２チーム
全体の５０％

47. 太陽系戦略
wifi
エンタメ
モバイル
特典
会員
契約管理
トリトン
冥王星
海王星
土星
2014
火星
地球
認証
金星
現状：弊社の現場におけるDDD適用範囲
第二
世代
木星
20152016 20132018 2017
VNE
ビッグローブ光
タイタン
新規サービスレガシーシステム(腐敗層) 既存サービス
セット商品
太陽

48. 48 © BIGLOBE Inc.
プロダクト：１00万行
テスト：１00万行
DDD適用した規模感
全体の20%ぐらい

49. 49 © BIGLOBE Inc.
第３章. 導入による効果

50. 50 © BIGLOBE Inc.
導入による効果
１．リリースサイクルの向上
２．システム設計の戦略の柱ができる
３．メンバー全員が成長する
４．試行錯誤

51. 51 © BIGLOBE Inc.
機能追加のリリースサイクルが向上
１．リリースサイクルの向上
直近、３か月の機能追加
３０件
３営業日に１機能が、
リリースされるペース

52. 52 © BIGLOBE Inc.
webページ
A
コールセンター
α
回線業者１
(キャリア)
販売システム
回線業者２
(キャリア)
webページ
B
コールセンター
β
システム1
システム2
システム3 システム4
システム5
システム6
DB
Domain
Model
Application
InfrastructureUser Interface
業務ロジックはドメインへ集める。
システム上のロジックは境界に閉じ込める
２．システム設計の戦略の柱ができる

53. 53 © BIGLOBE Inc.
２．複雑なシステムを設計するための戦略
複雑なシステムとの闘い方が分からなかった。
・わかりやすい（浸透しやすい）
・現場間としても納得感、手ごたえがある。
・現場が正しいと思える戦略がある事で、前に進
むことに集中できる。
「業務ロジックをドメインへ集める」
↓

54. 54 © BIGLOBE Inc.
３．メンバー全員が成長する
設計・モデルを考えられるエンジニアなる
考えられる＝
複数の選択肢の中から、
サービス・システムに対する最適な選択肢を決断していく。
・設計・モデルを考えるとい事への場数の少なさ
・選択肢の少なさ
・設計・モデルを決断するための根拠
なぜ考えられないのか？

55. 55 © BIGLOBE Inc.
３．メンバー全員が成長する
ドメインモデルを中心にして
チーム全員で設計する
・具体的なモデルがある事と誤解なく分かり合える
・リードエンジニアの考え方、判断基準、リスクへの
考慮などをモデルを見ながら聞ける
・経験せずに設計を支える知識を得る

56. 56 © BIGLOBE Inc.
４．試行錯誤
チームごとに試行錯誤が始まる。
・一人で経験する何倍ものスピードで、ノウハウ
を得ることが出来る。
・勝手に失敗してくれてる(ノーリスク）
・「試してみたかった」 or 「思いつかなかった」
他チームからフィードバックをもらえる。

57. 57 © BIGLOBE Inc.
第４章. 今後の目標

58. 58 © BIGLOBE Inc.
・RDRAによる要件定義との連携
要求・仕様→実装の乖離のないシステム
・マイクロサービス化
・コンテキスト境界の明確化
・腐敗層の駆逐
変更可能な業務システムへ
今後の目標

59. © BIGLOBE Inc.