株式会社Septeni-OriginalにおけるDDDを新人教育をやったレシピの共有と新人の学びの共有資料です。

1. DDD × 新人が学んでみた
レシピ共有
DDDを新人になんとなくでもわかってもら
うためにやってきたこと

2. アジェンダ
1. アイスブレイク ＋ 自己紹介
2. 弊社新人教育の黒歴史
3. では今年からどう教育をしたの？
4. まとめ
教育の結果は2年目がプレゼンしてくれます！

4. 新人教育とは、
新人に教養を与えることです。

5. つまり

6. 新人教育とは、
新人に今日、用を与えることです。

7. いえいえ、コレが今回の目的
教育担当者は、忙しく新人を放置してしまうことが多い
その中で、今回の勉強会の内容が一つの「用」になって貰える
そういうご提案になれば、幸いです。

8. 1.自己紹介
名前：原田侑亮
（まぐろ（鮪）みたいな字の人で覚えてください）
仕事：
コード書く。たまに、ビジネスやる。教育する。
あとは、DDDとかをおもしろ可笑しくやってます。

9. 2. 弊社新人教育の黒歴史
結局、教えれてないじゃん

10. 2. 弊社新人教育の黒歴史
2012年
サービスを企画して、作れ！
コードレビューはもちろんない。
⇒強い人材は育った。けれども…

11. 2. 弊社新人教育の黒歴史
・2013年
新人教育：PHPをやってOJT
プロジェクト：
PHPでソーシャルゲーム開発受託
Railsで自社サービス
TDDやら、チケット駆動はまだ曖昧

12. 2. 弊社新人教育の黒歴史
・201４年
新人教育：PHPをやってOJT
プロジェクト：
PHPでソーシャルゲーム開発受託
Railsで自社サービス
TDDやら、チケット駆動はまだ曖昧

13. いかん！革命じゃー！
３．では今年からどう教育をしたの？

14. ３．では今年からどう教育したの？
ゴール設定（今回の施策一部抽出版）
● ScalaでWeb開発ができる
o PlayFrameworkで簡単なWeb開発ができる
o Scalaで開発できる
● DDDを理解できる
o DDDのワードが分かる
o DDDでユビキタス言語が定義できる
o ドメイン層の実装ができる

15. ３．では今年からどう教育したの？
ScalaでWeb開発ができる
⇒ 何かいいお題は？
⇒ 掲示板（PlayFramework）
⇒ 拡張性が高い（個人に合わせたフレキシブルな
対応可能）
⇒ どこにでもある（伝えやすい）
⇒ スモールな機能なので、コードレビューしやす
い
⇒ 実は中途向けにGanmaでやってた

16. ３．では今年からどう教育したの？
DDD理解
⇒ どうやって理解してもらう？
⇒ 読書会をやって理解してもらう。
⇒ どうやって実践してもらおう？
⇒ PO（トレーナー）を立てて、ドメインをつくりあげてもらう
⇒ ユビキタス言語構築実践
⇒ 自ら作り上げたドメインをコードに落とす
⇒ ドメイン駆動設計をコードで実践
⇒ レイヤードアーキテクチャ

17. ３．では今年からどう教育したの？
大まかな流れ
1. 好き勝手に作ってもらう
2. domain-driven-design-quickly読書会をする
3. DDDでリビルドしてもらう

18. ３．では今年からどう教育したの？
お題
掲示板のストーリーを出す
⇒ できるだけ曖昧に。嫌らしく
⇒ 掲示板ドメインはこうですよね？の提案を誘う
1 ユーザーは掲示板の投稿を一覧できる。
2 投稿者のメアドと投稿内容が閲覧できる。
3 ユーザーは掲示板に文字列を投稿できる。
4 ユーザーは、メアドとパスワードを入力することでログインできる。
5 ログイン後であればユーザーは自分のメアドを入力せずに投稿できる。
6 新規ユーザー登録を行うことが出来る。

19. ３．では今年からどう教育したの？
1. 好き勝手に掲示板を作ってもらう
目的：トレーナーのための試金石
⇒ Frameworkとか言語理解度をみる
やり方：
⇒ DDDを意識させずに好き勝手に作ってもら
う
⇒ その時点での君の最強のコードを見せてみくれ
っ
⇒ Scalaやテストコードに対する指摘のみ
⇒ OOPの指摘をしておくと次の工程が楽

20. ３．では今年からどう教育したの？
2. domain-driven-design-quickly読書会
目的：DDDを理解してもらう
本はこちら
http://www.infoq.com/jp/minibooks/domain-driven-design-quickly
やり方：
通しで読んでもらって、1章～4章までを解説

21. ３．では今年からどう教育したの？
3. DDDでリビルドしてもらう
目的：DDDを実践してもらう

22. ４．まとめ
1. 新人には教養（今日、用）が必要です。
OJTに任せるだけではだめっ！きっちり育てたい！
2. しっかりと、現場にあったものを伝える。
JavaやScalaのプロジェクトの中PHP教えても…
3. 変化を見て、体験して、考えてもらう。
自分だけのコードとDDDの知識を学んだあとのコードの比較
自分だけのコードとDDDの知識を学んだあとのコードに受けた指摘の比較
などなど…

23. ４. まとめ
次は、
これらの教育を受けた２年目からの学びです。
一旦、原田からのプレゼンは終わりです。
ご清聴ありがとうございました。

24. セプテーニ・オリジナル
新人教育 内容

25. 新人教育開始前の状態
言語：
開発経験：
OJT
スクラム・アジャイル

26. トレーニング課題
掲示板

27. トレーニング課題
掲示板
ユーザーストーリー
1 ユーザーは、掲示板に投稿できる
2 ユーザーは、掲示板の投稿を閲覧できる
3 ユーザーは、自分のメールアドレスを入力せずに掲示板に投稿できる。
4 ユーザーはログインして投稿できる

28. 分からないこと
特になかった

29. 使ったもの

30. 分からないこと(Scala)
・どうやって書くの?
・Scalaのメリット、デメリットは？
・ScalaDocの見方がわからない。。。
・「javaではこう書く」javaで置き換えても理解
が難しい。。。

31. 実際やってみた感想
動くものをつくるので精一杯だった、、、、
前提知識がなさすぎて、質問ができな
い

32. できあがったもの

33. Scala、フレームワークについてや、
設計についての指摘をたくさんもらいました。
プルリクエストにて
レビューしてもらったら

34. プルリクエストにて
レビューしてもらったら
Scala、フレームワークについてや、
設計についての指摘をたくさんもらいました。
先輩に質問に行ける
チャンス!!

35. 掲示板リファクタリング
DDD実践

36. DDD講習

37. DDD講習のあと。。
?
?
?
?
?
?
?
??
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?

38. で、DDDの何が良いの?
経験がないから分からない。
汚いコードに頭を悩ませた日々がな
いから。
プログラマ１年目
・ようやく一人でハイハイ

39. DDDの説明を受けての感想
座学だけではいまいち理解できなかった

40. DDD実践

41. 使ったもの

42. ユーザーストーリーをPOに確認して修正する。
その際にユビキタス言語を決定する
細分化以前 細分化後
1 ユーザーは、掲示板に投稿できる
2
ユーザーは、掲示板の投稿を閲覧で
きる
3
ユーザーは、自分のメールアドレス
を入力せずに掲示板に投稿できる。
4 ユーザーはログインして投稿できる

43. 難しかったこと
POとユビキタス言語を決めること
-ログイン中の「ユーザー」って曖昧なので、アカウントとして
ユビキタス言語にしてはどうですか？
-投稿は、作成と保存の２つのことをやるので、複雑だと思います。
ユーザーストーリーを分割して良いですか？
-ログインにはメールアドレスとパスワードが必須ということですので、
ユーザーストーリーを修正しても良いですか？

44. ユーザーストーリーをPOに確認して修正する。
その際にユビキタス言語を決定する
細分化以前 細分化後
1 ユーザーは、掲示板に投稿できる
• アカウントは発言できる
• アカウントは、発言を作成する
• 発言を保存する
2
ユーザーは、掲示板の投稿を閲覧で
きる
• ユーザーは、掲示板の発言を閲覧できる
• 発言をすべて取得する
3
ユーザーは、自分のメールアドレス
を入力せずに掲示板に投稿できる。
• ユーザーはアカウントを作成できる
4 ユーザーはログインして投稿できる
• ユーザーは、メールアドレスとパスワードでアカ
ウントになる

45. コンテキストマップを作成する

46. コンテキストマップ
を決めたメリット
POとの認識の相違による
手戻りの発生リスクをなくす
コンテキストマップに書いたものだけを実
装していくので、
不必要な実装をしなくなる

47. 自分なりDDDでの再構築
アプリケーション層 ドメイン層 インフラ層

48. プルリクエスト
からの学び

49. チームでのGIT運用
マージにはプルリクエストで
全員の承認必要
ツール：
ルール：
運用方法： Git Flow

50. プルリクエストを使った改善サイクル
プルリクエスト
レビュー指摘
リファクタリング
フィードバック
先輩 新人

51. プルリクベースでのコード改善
プルリクの具体的な指摘を紹介しつつ
Scala×DDDの学習の難しさを共有

52. についてScala
問題：nullを使ってしまう
原因：Optionの使い方が理解できていない
解決策：実践を通して先輩社員からナレッジ共有

53. 問題：記述が冗長になる
原因：イディオムを知らないため、自由に書いてしまう
解決策：チームメンバーがチームとしての方針を共有
についてScala

54. についてScala
問題：コンパニオンオブジェクトなのにnewしてる
原因：試しに使っていたけど、よくわかってない
解決策：プルリクのレビューに時間をかけて、
あやしい匂いのところを指摘

55. 問題：フォルダ構成が適当になってる
原因：気付けていない
解決策：コード以外の部分も先輩がチェックする
DDD について

56. DDD について
問題：ドメインが誰が読んでも理解できるものになっていない
原因：ドメインのチームでの運用について知らない
解決策：ドメインの運用方法をチームで共有する

57. DDD について
問題：作成したコンテキストマップと実装がずれてる
原因：実装に合わせてドメイン層を変更してしまっていた
解決策：ドメインの変更をチーム全員が把握できる仕組みを作る

58. まとめ
・DDDもチーム内のコミュニケーションが大事
→ DDDの実現に必要な文化そのものも共有でき
る仕組みが教育には必要

59. まとめ

60. まとめ
・チーム開発ではユビキタス言語の統一が大事
→ チーム内で認識の相違が起きないように
するため