平成のうちに公開しようと書いていたが、間に合わなかった…
移転やらなにやらで滞っていたので再開する。
元号越しに会社ブログを書くことになるとは思ってもいなかったが令和最初の記事を書き上げた。
よく「複雑なドメイン」と開発日誌ブログでは書いているが、その複雑性にどのように向き合っているのかということを書く。
サービスを01で立ち上げる経験はあまりないという話はよくあるが、0から作るにもチームの状態でいくつか種類があると考えている。ドメインの理解度と人数で以下のように分けられる。
- チームの「全員 or 数名 or 誰も」ドメインについて知っている(いない)
- ドメインについて「完全に or ある程度 or 全く」理解している(いない)
ここでいうドメインとは、ドメイン駆動設計(以下DDD)におけるドメインと同じだ。僕らがビジネスにしたい対象領域だと思って欲しい。上の図はDDDの言葉で言い換えればどれくらいチームにドメインエキスパートがいるかということである。DDDにおいて重要なのは「現実世界をドメインモデルにどれほど正確に落とし込むか」だ。僕らはそれぞれがイメージしている「同じもの」でも完全に共有することはできない。共有が曖昧な状態でのシステム開発の失敗をみなさんも見てきたと思う。それをできるだけチーム全員で正確にコードに落とし込み、人に説明し、価値を提供できなければいけない。そしてこれがとてもむずかしい。
アルプでも他のチームと同様に日々あれこれ言いながらドメインモデルを磨き上げていっている。僕個人の経験はAndroidをメインにクライアントサイドの開発だった。その中でドメインについて考えながら作ったこともあるが、今ほど正確さを求めたことはなかった。クライアントではサーバーから受け取ったデータを破綻しない程度に「自分たちの都合のいいように」変換することで使えればいいからである。そういったクライアント特有の問題はここでは取り上げないが、可能な限りチーム全体で使いやすいモデルを作る必要があると思う。
どのようにしてモデリングしていくか？という方法論については、僕が書くよりも経験豊富な人の記事が参考になると思うので下にリンクを載せておく。アルプでの進め方やその苦労について紹介する。
アルプでは「チームの数名がドメインについてある程度知っている」という状態からスタートした。上の図を例にするとこんな感じだった。
僕が参加したときにチームが持っていた手札は、
- 競合サービスの情報
- 競合の情報を踏まえてある程度まとめた概念図
だった。説明時に使えるシステム全体の抽象化した概念図はシンプルだった。
しかし、個々を詰めていくと概念図は膨大なスケールになっていった。(一部抜粋)
これをオンボーディングで説明し理解するのに相当時間がかかっていたが、いざ実装をしてみようとなると「あれ？なんだったかな？」ということになる。自分で作っていないので当然だと思う。ここがアルプでドメインモデリングについて考えていくきっかけになった。
初期の問題
1. メンバー全員の理解度が違う
最初に概念図を考えたメンバーの理解度に比べて、数ヶ月あとに入るメンバーのドメイン知識は明らかに少ない。この状態ではタスクを分担したりすることが難しいので、全体として会社が進んでいない感覚になった。これを脱するためにいろいろ対策をした。
- ユビキタス言語表の作成（みんなで同じ言葉を使う）
- 全員でドメインモデリングを行う
- 可能な限りラフや図を作成する
これらにより、全員の理解がある程度のレベルまで近づきつつ、全員の理解度が高まった。
2. 概念図のみが頼れる情報源
概念図のいいところは、
- 概念と概念の関係性を把握できる
- 全体像の理解を助け、ドメインの境界のようなものが薄っすらと見えてくる
ことである。しかし、どのように概念同士がコラボレーションするのか、どのような関係なのかなど不足している情報も多い。また、更新がめちゃくちゃ大変である。初期はCacooを用いていたが、再利用性やメンテナンス難易度の高さから今は使っていない。それ以外にも、どうやって決まった情報をまとめておくのか、最新に保つのかという点が考えられていなかった。
そこで、
- まずは網羅的にユースケースを作成する
- 各ユースケースをドメイン理解の深いメンバーが順に詰めいていく
という方法で、実際の利用シーンを思い浮かべることで概念の整理やドメインへの理解をさらに深めることにした。
次の問題
ユースケースが網羅的に完成したが、それだけではうまくいかなかった。総じて言えたのは、全体の開発スピードは上がっていないことだった。作業の並列性が高くなかったのだ。他にも問題は多かった。
1. 今後どうやって他のメンバーに共有するのか
今いるメンバーは一人一人に手厚く説明したり、実装やモデリングを一緒に進めたのでなんとかなってきた。が、今後入るメンバーにも毎度この進め方では、スピードが命のスタートアップでは望ましくない。そのために次の手も打った。
- ドキュメントの整備を小さく始めた
- 図をUMLにしてエンジニアに伝わりやすくした＆バージョン管理を始めた
これらによってある程度オンボーディングしやすい環境ができてきたが、メンテナンスコストがどうしても高くなった。また、実際にサービス導入するときに使えるようなものではなく、エンジニア以外のメンバーにとって有用なものとは言えなかった。
2. 外部サービスとの連携はエンジニアリングに近すぎる
各ユースケースはドメインへの理解が進んでいるメンバーが担当していたが、それでも個人の担当範囲には限界があった。顕著に現れたのは外部サービス連携の部分だった。今のプロダクトはいくつもの連携機能を持つことを想定しているため、それぞれのサービス仕様について把握しながら個人で全て詳細を詰めるのは実質不可能だった。また、連携はほとんどエンジニアリングに近い内容のため、エンジニアが進めるほうが良いだろうとなった。そこから転じて、
- 開発を担当するエンジニアやデザイナーがヒアリングしながら詳細を詰める
- 業務知識やドメイン知識のあるメンバーがチェック
という流れで進めていくことにした。
改善後の流れ
いろいろあって、今はこの流れに落ち着きつつある。
- 全員の理解が浅い部分はドメインモデリングを短めに行う
- 議事録からまとめ記事や図を作成する
- 実装者や担当者がユースケース概要を更新する
- UMLやラフ図などに起こす
- 実装者や担当者がユースケース詳細を詰める
- ドメイン知識のあるメンバーで相互チェック
これである程度全体の速度を上げつつ、並列化、分担などいろいろな状況を打破できてきた。
今後の問題
しかし、まだまだまだ、問題は減らない。
1. 並列すぎる
すべての作業が少しずつ進み、全員が違う部分を担当できるようになったので、全体としては進んでいるようには感じる。が、個々のスピードが出なかったり、並列作業が多すぎて、In Progressな状態がいくつも存在する。これを全体把握することが難しかったり、情報共有のコストが高くなったりするので、バランスがとりにくくなった。
2. スピード
とにかくモデリングに時間がかかってしまう。これを効率化＆並列化しないといけない。今は小さいチームなので全員で合意を取りつつ進められているし、ドメインへの理解度も深まってきたが、本当は一部のメンバーでモデリングできることが望ましい。そうして決まった内容をスムーズに共有できる環境を整える必要もある。
3. 専門知識
ドメインの範囲に法律や会計といった異なる専門知識にも影響することが多く、ある程度調べられるが本当の正しさや素早い意思決定を今のメンバーだけで行うことは難しい。とはいえ、専門知識を持つメンバーを受け入れて設計していけるほどチームの器用さも無いので、どのように手伝ってもらえるのかみんなで考えている状況だ。
4. ドメインオブジェクトの局所解
エンジニアリングの観点から、何度も話し合って洗練されたモデルでも局所解にとどまっていないか、実装やリファクタリングを通してチェックが必要だと感じている。
5. 外部向けドキュメント
サービス導入をするシーンに必要なドキュメントなどは揃っていないので、自分たち用にもなる対外向けのドキュメント管理方法を考えていく必要もある。
やればやるほど問題が出てくる。これがスタートアップのリアルなのだ。
ドメインモデリングや参考
ドメイン駆動設計について
そもそもDDDってのがわかってないという人はまず読んでみて欲しい。僕もまだまだだけど、DDDの概要とその必要性、本の読み進め方など丁寧に紹介されており、僕も何度も見返して人に紹介したりしている。発表内容の本流ではないので、ドメインモデリングについてはあまり書かれていない。
ドメインモデリングの始め方
ドメインオブジェクトの作り方にとどまらず、網羅的にモデリングの戦略が紹介されている。ドメインモデル貧血症のような、DDDで取り上げられる問題へのアプローチが勉強になる。実装時の戦術なども豊富すぎてすべてを取り入れるのは大変かも。チームの状況に合わせて、必要な手法を取り入れていくのが良いと思う。
要点で学ぶ、リサーチ＆デザインの手法100
ドメインモデリングだけが問題の解決策ではない。様々なリサーチ手法やビジュアライズについて概要を紹介している本で僕が好きなもの。
- ブログのALPタグで開発日誌公開中
サブスクリプション管理SaaSの事業ドメインや開発に興味のある方はご連絡ください。どの職種の方も絶賛募集中です！
