joinsure recordチームの開発体制

こんにちは。

justInCaseTechnologies の web frontend engineer の kondei です。

当社は今 "joinsure" という SaaS 型保険システムを開発中です。

チームは Systems of Record, Systems of Engagement という区分を参考にして大きく "record" と "engagement" に区分しています。

そのうちの契約管理などの部分を担当する record チームの最近の開発体制についてご紹介します。

アジャイル × スクラム開発

導入まで

joinsure 以前の開発はハッキリ言って「なんちゃってアジャイル」な部分があり、明確なフレームワークに沿っていませんでした。

それによってミーティングが少なかったり機動力があったりするというメリットはありましたが、感じていたデメリットとしては、以下のようなものがあります。

  • タスクを頼んだと思っていた人と、頼まれたと思っていない人の認識の齟齬があることがある
  • しばらく経つと、誰がボールを持っているのか、何によって待ち状態になっているのか分からないことがある
  • 期間も進捗も分からないことがある
  • ゴールが明確でないときがある

joinsure プロジェクトが明確に立ち上がるとき、開発体制をどうするかコアメンバーで議論しました。

そのとき草案としては既存のオリジナル体制の発展型が提案されており、ウォーターフォール型となんちゃってアジャイルの混ざりあったような状態が想定に入っていましたが、 「既知のプラクティスであるアジャイル × スクラム開発手法に従った方が良い」という議論の結果、導入が決定されました。

他の手法ではなくこれを選んだ理由としては、以下の通りです。

導入にあたって

導入にあたっては、まず

をチームメンバー全員で読むことでマインドセットと方法の認識合わせをしました。

ツールは BizDev, PdM, designer, engineer全員で YouTrack を使用しています。

また、アジャイルの流儀の 1 つである、インセプションデッキを作成しました。

最近では「何を諦めるのかはっきりさせる」ページの優先度調整が現実に合わせて更新されたりして、全員の方向合わせに有効活用されています。

インセプションデッキ

実践してみての工夫

  • プロジェクト状況に応じて適宜イベントのタイムボックスを調整しています（スプリント期間を 2 週間 → 1 週間 → 2 週間で調整したり、内容が減ってきたらミーティングを短くしたり）
  • スプリントレトロスペクティブは KPT 法で実施しており、なるべく改善案・next action を決めるようにしています
  • 社内ドキュメントに「スクラムを始めるときに読んでおくと良いもの」というページを作って、参考文献をまとめています
  • Slack にアジャイルスクラムの話をするためのチャンネルを作っています

効果

導入によって、以下の効果があったと感じています。

  • スプリントの導入によってゴールが明確に共有されるようになった
  • 誰が何をしているのかわかるようになった
  • 短い締切の繰り返しが生まれることによって、意欲が向上した
  • デイリーやスプリントプランニングによって、計画の見直しがしやすくなった
  • engagement チームの開発にも導入されて、会社全体として IT 開発の素地が整った
  • 良い開発体制を持ったことで、採用上も訴求力が上がった
  • 各チームを超えた会社全体の体制として「大規模スクラム(LeSS )」を見据えることができるようになった

DDD

ドメインコンテキストマップ

ドメインコンテキストマップ

幅広い保険業務を扱う SaaS の開発のために、BizDev がドメインコンテキストマップを作成して、大まかな区分けと依存関係を認識共有しています。

また、個人的に良いと思うところは、このマップに対し、バックエンドのサービス区分・フロントエンドの機能区分をほぼ一致させることができていることです。

ドメインモデル図

ドメインモデル図

ドメインモデル図をクラス図の形式で書き、ドメイン知識のメモ書きを付記して、PdM とエンジニアで共同管理しています。

目的としては、全員のビジネスの想定を揃えることと、バックエンドのドメイン層実装のために使います。

変更があるときは随時議論したり、スプリントレビューで全員に共有されています。

アクティビティ図

アクティビティ図

同様にPdMがアクティビティ図を使ってシステム間に跨ったビジネスのフローを定義・管理しています。

状態遷移図

状態遷移図

「契約」「請求」など、状態がある概念に対しては状態遷移図を作って状態とイベントを定義しています。

これは以下の役に立っています。

  • PdM とエンジニアで明確に認識を合わせること
  • バックエンドもフロントエンドも状態変更操作や用語を正確に図に従って実装すること
  • 状態遷移に伴う UX や用語の改善議論

また、これを作る文化が根づいたことで、メンバーが仕様定義の時点で「これは状態遷移がある概念かどうか。状態とイベントを定義した方が要件定義しやすいかどうか」という判断ができるようになったと感じています。

bitemporal data model

保険の業務では契約やお金の絡むイベントを厳密に扱う必要があったり、特定の日時のデータを出力する必要があったりします。

つまり「データによっては任意時点のイベント・状態を後から復元できる必要がある。どう保持するか？」という課題があります。

それに対して、チームメンバー主導で bitemporal data (model)というデータモデルの導入が提案され、ハンズオンが開催されてチームで勉強して、バックエンドのデータモデルに導入されました。

参考文献

OpenAPI, スキーマ駆動の API 開発

APIスキーマから自動生成したドキュメント

joinsure 以前の API 開発と利用では以下のペインがありました。

  • API 定義が手動生成になっており、ドキュメントの更新漏れ等が発生する
  • API ドキュメントと実装の差分がわからない、検知できない
  • クライアント側の API モデル（型）とコードが手動生成になっていて乖離やコーディングコストで開発効率が悪いので、自動生成したい
  • API 定義がサーバーサイド主導になっており、クライアントサイドが API に対する議論への参画がしづらいことを、スキーマファーストで解決したい

それに対して OpenAPI のスキーマ駆動開発と、コードとドキュメントの自動生成を導入し、ペインがほぼ解消できました。

参考文献

https://logmi.jp/tech/articles/324190

ADR(Architecture Decision Record)

技術選定の議論と理由を残すため、バックエンド・webフロントエンド共に技術選定ドキュメントに ADR が導入されています。

ADRをレビューフローに乗せることで合意を得る意思決定プロセスが明確になり、リポジトリに残ることで新入社員も経緯を追いやすくなります。

参考文献

デザイン開発における Figma の活用

デザイン面の開発は Figma を活用し、以下の流れとなっています。

  1. BizDev, PdM がワイヤーフレームを作成し、デザイナーとブラッシュアップ（場合によってはエンジニアとも議論）
  2. デザイナーがワイヤーフレームから実装用デザインを作成し、BizDev, PdM, フロントエンドエンジニアとブラッシュアップ
  3. フロントエンドエンジニアが実装

ワイヤーフレーム

実装用デザイン

これによって以下の効果がありました。

  • PdMの意図するUXから乖離しにくい
  • UX改善や変更の議論が活発になった

デザイン開発におけるコンポーネント指向開発

これまでの課題として、複数のプロダクトで同じようなデザイン定義とその実装が再作成されている状態がありました。

それを解決する手法として、デザインの時点でコンポーネント指向で定義し、実装もコンポーネント単位で再利用できるものを作っています。

コンポーネント指向デザイン

また、最近では Chromatic というサービスを導入してコンポーネントのVisual Regression Testで差分の検知をできるようにして、品質を高めています。

チームのエンジニア全員でエンジニア採用に関わる状態

エンジニア採用において、人事メンバー主導で数ヶ月前に「スクラム採用」という手法が導入されました。

エンジニア採用のために「採用 weekly」や「転職ドラフトもくもく会」などの定期イベントが設定され、基本的にエンジニアメンバー全員が候補者を探して判断するようになり、開発上求める人員の話・採用活動上の課題・面談や面接やツール利用方法の改善点などが議論されるようになりました。

これによって採用という業務が「人事や一部の人だけが関わるもの、通常メンバーにとって新入社員はいつの間にか降ってくるもの」というような状況から、「チームで一緒に働きたい人を主体的に見つけて判断し、やり方自体を改善していく」という状況に変わりました。

開発体制がスクラム化したこともあり、人事面もスクラム要素が取り入れられたのは相性がよい体制と感じています。

終わりに

justInCaseTechnologiesでは常に現状の改善を進めており、新たな開発メンバーも募集しています。

この記事で少しでも働くイメージが湧いたら嬉しいです！

ご応募お待ちしています。