ドメイン駆動設計なエンジニアの育成プログラムを作った
この記事は Engineering Manager vol.2 Advent Calendar 2018 - Qiita の16日目の記事です。
今の会社にはチームにジョインした方に対してドメイン駆動設計での開発ができるように育成するプログラムがあります。
「プログラムがある」と言っても有志で持ち回りでやってるちょっと真面目な勉強会のようなものです。
それを私がやることになったので、今日はその時に考えたことを書きます。
身の回りに勉強会等開いてくれる人がいたら「あの人はこんな感じのことを考えてるのかー」と思ってもらえたら幸いです。
誰？
- 名前: なおしむ
- 某ISPでエンジニアをしている
- 最近は新しく来た人の育成もしている
背景
- 現在のプロジェクトはビジネスの特性上、市場変化に対応しつつバグのない開発が求められている
- そのために内製 + ドメイン駆動設計(DDD)で開発している
- リンクいろいろ
- 「内製xDDD」の規模は5人x10チームで50人くらい
- エンジニアは随時募集しているがDDDを経験済みのエンジニアは少ないため、メンバーがジョインしてから育成している
- メンバーがジョインしたときにやる育成プログラムが本題の「DDDスタート塾」です
DDDスタート塾とは？
- 新しく来た人が最初に入る塾
- 塾の講師は「塾長」と呼ばれる
- チャットルームのアイコンはこれ
- 塾の期間はだいたい4週間
- 塾の受講者はだいたい4人くらい
- 塾自体はずっと前からあったが、私は塾長をやったことがなかったので今回引き受けてみた
計画
塾名の改名
過去の塾は塾長から名前をとって、例えば「鈴木塾」とか「佐藤塾」とか呼ばれてました。
塾に名前が入ってると属人化しそうだったので(してたので)今回「DDDスタート塾」に改名しました。
ゴールの定義「DDDスタート塾のゴールはなんだろう？」
まずはチームメンバーに相談しつつ塾のゴールを定義しました。
塾の期間だけでドメイン駆動設計がカンペキにわかるわけがないので、塾のゴールを「チームに入ってDDDなコードを読み、理解し、書くことができる」としました。
育成コンセプト「箸の持ち方から教える」
ジョインされる方はだいたい事前に面談をしています。そこでjava経験アリ・Spring経験アリと言ってても、実際はできない方もいます。
たとえばjavaはできるが設計はできないとか。
ただ面談時に「この人はいける！」と思って採用した方なので「できないのは経験がないだけ、教えればできるようになる」と考えています。
なので必要なスキルがすべて身につくようにプログラムを設計しました。
ゴールに対して必要なスキルに細分化する
DDDは色々は技術を積み上げたようなものなので、DDDを細分化しました。
余談ですがPlantUMLがあるのはExcelじゃない感を出したいだけです。
ざっくりスケジュールと学ぶこと
全体の進め方
毎日1時間は勉強会形式の集合研修をやり、そのほかの時間は研修で出た宿題をやってもらいました。
集合研修の内容はメンバーの進捗に各種説明、ハンズオン、宿題のレビューです。
計画を練りすぎてもしょうがない
ここから先は、行き当たりばったりです。都度メンバーの状態を見ながら説明したりハンズオンをしたりして進めました。
塾を2回やった結果
上記の計画でプログラムを2回やりました。
期間でいうと4週間x2回で約2ヶ月です。
FAN DONE LEARNでまとめてみます。(←最近流行ってる)
DONE
4週間になんとか収まった
ギリギリ間に合った感が否めない。 SQL文とか細かいところが伝えきれてない。
LEARN
2ヶ月間、毎日勉強会をやり続けるのは大変
毎日どんな質問がくるかわからない中で塾を進めるのは大変でした。質問内容とかは形式知にしないとなーと思った。(やってない)
とりあえず説明するときに使った資料はこちらです。
www.itsenka.com
「なぜDDDをやるのか」をうまく伝えることができない
オブジェクト指向とかイベントソーシングとかいろんな要素から生まれていたり、そもそもDDDを実験的にやってみてるところもあるので、DDDをやる理由をシンプルに説明するのが難しかった。
ハンズオンをたくさんやるべき
HelloWorldでも意外にみんなハマる。原因は、サイトの内容を理解せずにコピペしてたり、3ステップくらい必要な機能を一気に実装しようとしてわけわかんなくなったりいろいろ。そうゆうのをひとつひとつ指摘していくことに意義があるとおもった。
FAN
中間テストをやると緊張感と達成感があって良い
オニオンアーキテクチャのお題が終わったタイミングで中間テストをやってみました。
もちろん事前に告知して。
そしたら程よい緊張感で結構楽しかったです。
ちなみに問題はこん感じ。
- intelljでプロジェクトを作ってspockでテストを動かすまでをググらずにやりなさい ※ただしdependencesに書く内容とか暗記できないようなものは提示する
- 真っ白な紙にオニオンアーキテクチャの図を書きなさい
既に業務をやってる人が「入門したい！」と言ってきた
既に案件をガッツリやってる方なので「チームで時間が取れるように調整できるならイイよー」ってことにした。
私としてもある程度知識がある人がいた方が質問が活発になってやりやすかった。
こうゆう広がりすごく嬉しい。
今後のトライ
形式知化する
行き当たりばったりで資料を作成したりネットの資料を使ったりしてたので、そうゆうのはまとめようと思う。最悪資料読めば講師がいなくてもメンバーが進めれるようにしたい。(緊急の用事が入ったりもするし)
講師役を増やす
形式知を増やせばある程度誰でも講師役ができるようになると思う。講師役をやることで理解が深まることもあるので、入門→業務遂行→講師→より深い知識って感じのパスを作りたい。
まとめ
ダラダラとたくさん書きましたが、講師をすることでみんながつまずくポイントが分かって勉強になった。課題はたくさんあるけど、いろんなやり方を試しつつ続けていきたいと思いました。
