急拡大する大規模スクラムチームでドメインモデルの共通理解を醸成

PROFILE

川並 裕

・ラクス100%出資米国子会社の開発部や、楽楽精算iOSアプリ開発チームリーダーなどを経て、楽楽労務のテックリードを務める。社外イベント登壇も活発に行っている。
・応募を考えている方へ「アーキテクチャやドメインモデルに対する深い考察を、開発メンバーに取り組んでもらうための啓蒙活動や技術者育成に対する取り組みを一緒に進めていきたいです」

テックリード、技術スペシャリストへのインタビューを通じて、ラクスの日々の技術との向き合い方や、最近注力している実務について知っていただくシリーズです。今回は、楽楽労務のテックリードとして活躍中の川並さんにインタビューしました!

現在の組織内でのミッションを教えてください。

 テックリードとして、大きく二つの役割があります。一つはテクノロジーマネジメント。楽楽労務のアーキテクトとして、サービス開発における内部仕様・品質の責任者をしています。もう一つは育成やオンボーディングなどのピープルマネジメントです。

複雑な業務フローのモデリングから、メンバーのメンタリングまで幅広く対応

開発チーム体制内でのテックリードの役割・動き方について教えていただけますか?

 楽楽労務はいわゆるLeSS体制での大規模スクラム開発を行っています。全体の開発体制があり、傘下に複数のスクラム開発チームを置く形で、各リーダーが集まって開発を進めています。私自身は特定の機能開発はやっていませんが、コードレビューをしたり、各チームにアサインする前の高難易度な開発の内部設計検討や、プロトタイプ開発などを行っています。

高難易度な開発とはどのようなものでしょうか?

 例えば楽楽労務に承認フローという機能があります。この後のドメイン駆動開発(以下DDD)の話にもつながりますが、業務フローや登場するヒト・モノ・コトの複雑な関係を整理しながら設計を行う必要があります。それらコアドメイン部分をモデリングし、ベース実装を作って、チームが参考にできるようにしました。

ピープルマネジメントについても教えてください。

 育成関連だと1on1を実施しています。チームの状況を聞いて課題解決を一緒に考えたり、キャリアや志向について聞いてアドバイスしたりしています。
 いま楽楽労務の開発体制は、5年目くらいの中堅メンバーに個々のスクラム開発チームのリーダーを任せながらスケールを模索している最中です。そんな中で、リーダーとしてどう動いていくかのメンタリングが重要になってきていますね。今後は技術的な話もできればよいと思っていますが、今はチームがスケールしていますので、どうチームを機能させていくかに注力しています。

純粋に技術だけではなく、チームリーダーとしての引き上げの要素もあるんですね。リリース後2年、スケールの勢いがすごいですが、LeSSを選んだのもそれが理由でしょうか。

 もともと楽楽労務開発プロジェクト立ち上げ時は4,5名のベテランメンバーだけだったのですが、開発スピードを上げるために社内外から参画いただきました。1チーム15人くらいになった時期もありましたが、そうなると一つのチームではまとまらなくなってきます。そこで内部的に分割した方がよいと判断し、移行コストが小さいLeSSに移行しました。

ドメインモデルの文書化で、急拡大するチームの開発品質を維持

最近の取り組みについて『文書化』を挙げていただいていますが、確かにその必要性も感じられます。

 アプリケーションアーキテクチャとか、コードレビューの文書を初期に作りました。メンバーが増えてくる中で、チームの規約として作り、認識合わせに活用しています。
 あとはサーバ構成をまとめた資料。新メンバーのオンボーディングを去年くらいから担当してきたのですが、私以外の人が担当しても抜け漏れがないように作成しました。
 あとはドメインモデルを可視化する資料です。チームが拡大してもドメインに対するコンテキスト理解を揃えておくのが目的です。実装時にJavaのパッケージ構成や依存関係を考えるのが複雑化してきたり、ルールから外れたりするケースも見られ、これを整理する意味もありました。

文書化においてどんなところが工夫点ですか?

 DDDを意識することは前提として、労務業務の中でもマスタの扱いや情報管理、ワークフローなど、コンテキストが分かれる業務領域があります。こういったものをそれぞれ1枚のスライドで一目でわかるようにしています。
 あとは開発者に分かりやすいように、DB設計するときの概念データモデルの書き方を参考にしています。例えば、Javaのクラス図をUMLで書く時の記号を使ったりしています。

現状の浸透状況や今後の課題について教えてください。

 業務ドメインを意識することについては根付いてきたと思います。日常の開発にしみこませていくのはこれからですね。ドメインモデルの更新など開発プロセスに組み込んではいますが、図で整理するのはまだ慣れない部分もあります。フォーマットも概念データモデルやアクターモデルなどいろいろありますが、まだベストプラクティスはないので手探りですね。
 エンジニアのだれもがアーキテクチャやドメインモデルについてしっかり考え、質の高いサービスを開発できるようにしていきたいです。

ありがとうございました!また今後も新しい展開がありましたら教えてください。

Back to list