要求分析とアジャイル開発を小さく反復しよう　実装後の“悲しいズレ”を起こさないために「ドメインモデルで対話」する

プラットフォーム開発の悲しい現実

岩佐幸翠氏：「大規模SaaSにおけるプラットフォーム開発」と題して、株式会社カケハシの岩佐が発表したいと思います。

まずは簡単に自己紹介をさせてください。私、岩佐と言います。2019年にソーシャルゲームの会社に入社して、認証システムの開発を行っていました。その後、2022年にカケハシに入社して、現在は組織管理サービスという社内プラットフォームのテックリードを行っています。

さて、いきなりですが、プラットフォーム開発の悲しい現実を見ていきましょう。多くの社内プラットフォーム、よく言われる共通基盤というものは、プロダクト開発チームの期待からズレてしまうことがしばしばあります。

例えば、権限管理プラットフォームを作っていくとしましょう。プロダクトAの開発チームは「権限をリアルタイムに同期してほしい」。プロダクトBの開発チームは、「じゃあ、一緒にプロダクト独自のロールも定義できるようにしてほしい」。「わかりました」「さっそく開発に着手していきましょう」と、プラットフォーム開発チームが数ヶ月かけて開発します。

「できました」「さっそく乗り換えていきましょう」。しかし、実際乗り換えをやってみると、「あれ？　確かにリアルタイムに権限を同期してほしいって言ったけど、重複して通知されちゃうんだけど」とか。あとは「いや、プロダクト独自のロールを定義したいとは言ったけど、そのロールを割り当てられるかどうかというのは、あくまでプロダクト側で握っておきたかった」みたいなズレが起きてしまいますと。

悲しいズレが起きてしまう2つの原因

なんでこんな悲しいズレが起きてしまうのか。私は原因が2つあると考えています。1つは要求分析が不足しているということです。例えば「プロダクト独自のロールを定義したい」「わかりました」と。「リアルタイムに権限を同期したい」「わかりました」と。こういうふうに表層的な要望をそのまま受け入れてしまっている。

ではなくて、潜在的な要求というのは、「それを使ってなにをやりたいのか」「プロダクト独自のロールを定義してどうしたいのか」「リアルタイムに権限を同期してどうしたいのか」を深掘る必要があるわけです。

そしてもう1つは、デリバリーがシンプルに遅くなってしまうということです。社内プラットフォームというのは、「じゃあ、あれもやってくれ」「これもやってくれ」と、いろいろな機能要件がどうしてもどんどん入ってきます。

そうすると、デリバリーがどんどん遅くなってくるわけですね。要求とのズレに早く気づくために、本来は早く小さくデリバリーして、早めにフィードバックを得る必要があります。つまり、社内プラットフォームのズレを防ぐためには、深い要求分析と高速なデリバリーの両立が必要です。

プラットフォーム開発こそ、要求分析とアジャイル開発を小さく反復しよう

「そんなことできるのか？」ということですが、ここで私が提案したいのは、プラットフォーム開発こそ、要求分析とアジャイル開発を小さく反復しようという話です。深く要求を分析して、この時にスコープをきちんと絞っていく。「本当に今取り組むべき問題というのは何なのか？」を絞った上で開発に入っていく。

絞ったスコープの中で、開発されたスコープの要求を満たす機能を迅速に開発してデリバリーするというものを提案したいと思っています。「言ってみるだけだったら簡単だけど、どうやって実現するんだ？」という話になってくると思います。

ここで本発表の狙いです。この発表では、プラットフォーム開発で要求分析とアジャイル開発を小さく反復する方法を紹介していきます。

要求分析をする前に、「なんで社内プラットフォームを開発するのか？」というのをおさらいした上で、プラットフォーム開発の要求分析とアジャイル開発について、それぞれ私が得た考察を共有できればと思います。

プラットフォーム開発の目的としてよくある誤解

要求を分析する前に、あらためて「なんで社内プラットフォームを開発するのか？」をおさらいしていきましょう。

プラットフォーム開発の目的としてよくある誤解があります。プラットフォーム開発の目的といえば、開発工数削減ですよね。「プロダクト開発チームのなんとかかんとか」を共通化して、プロダクト開発チームの開発工数を削減する。これは、私は実は誤解であると考えています。

「いやいやいや、なにが間違っているんだ？」「各プロダクトにあった機能をこのように共通化してあげることで工数が減っているじゃないか」と。これ（開発工数削減）が目的だと、なにが誤解なのかという話ですね。

確かに開発工数は削減できるかもしれません。しかしそれは本当の目的でしょうか？　プロダクト開発チームのミッションにまず立ち返ってみましょう。

プロダクト開発チームは、プロダクトを顧客に提供して、その対価を得ることがミッションです。企業なので当然対価を得る必要があるという話ですね。そのプロダクトにとっての価値、顧客に提供する価値は、常に変化していきます。

例えばカケハシだと、今の日本の医療業界はかなり激動の時期に来ているというのもあるし、カケハシ自体も1つのプロダクトを提供するSaaSからマルチプロダクトSaaSになり、そこからさらにエコシステムへと変化しています。

このように、プロダクトが向き合うべき顧客も、その顧客が求めている価値も常に変化していきます。そしてプロダクト開発チームは、この顧客の価値に集中したいわけですね。

ここで、私が今担当している組織管理プラットフォームが生まれた背景を見ていきます。

カケハシでは、薬の在庫管理サービスと薬局向けのBIツール、「Redash」みたいなイメージ……。要は、薬局の経営指標を可視化するようなツールを提供しています。

これら2つのプロダクトに対して大手法人への導入を視野に入れて、例えばエリアや支社ごとに閲覧スコープを限定したり、あとはエリアマネージャーだけに操作を許可したいといったような複雑な権限管理のニーズが高まっていきました。

これらは確かに非常に重要です。大手法人ともなれば、法人の中にさらにいろいろな支社があって、そのほかにもかなりいろいろなエリアがある。これらの権限管理も大事ですが、これは本来各プロダクトが向き合いたい価値ではないと思います。

例えば在庫管理であれば、在庫とか需要予測とか発注というところの体験を当然良くしていきたいわけですね。決して権限管理をするためのサービスではありません。

つまり、プラットフォーム開発の目的というのは、本質的な価値提供に集中させることにあります。プラットフォーム開発チームは、プロダクト開発チームが本質的な価値提供に集中できる状態を目指すのが目的になっているわけですね。

先ほどの例だと、認可とか、権限、組織管理というものからそれぞれのプロダクト開発チームを解放することで、各プロダクトチームが、自分たちが本来向き合いたかったコアドメイン、本質的な価値を提供する領域に集中できるようになるというのがプラットフォーム開発の目的です。

プラットフォーム開発の要求分析はなぜ難しいのか

ここで「じゃあ、プラットフォーム開発の要求分析をどうやってやっていくんだ？」という話に入っていきたいと思います。

その前に「そもそもプラットフォーム開発では要求分析が浅くなるというようなふうに言ったけど、なんで浅くなってしまうのか？　なんで難しいのか？」という話をしていきたいと思います。

まず、一般的なプロダクト開発の要求分析と要件定義を見ていきましょう。例えば、顧客がおいしいコーヒー豆をネットで注文したいというニーズがあったとしましょう。この要望を要求にするために、モックアップを描きながら、クリックした時とか検索窓に入力した時にどんなアクションを顧客が期待しているかという挙動を書き出していく。そこからさらに、顧客から見たプロダクトへの期待を書き出していくわけですね。「顧客はここをクリックしたらコーヒー豆の一覧を取得できる」とか。

それらをさらに要件にしていくには、主語を顧客からシステムに変えていきます。今まで「顧客は、うんにゃらかんにゃら」だったものが、「システムは、データベースから50件のうんにゃらかんにゃら」というような。これが要求と要件の違いですね。

では、プラットフォーム開発の場合を見ていきましょう。プラットフォーム開発には、難しくしている原因が2つあると思っています。

まず1つは、社内プラットフォームには画面が存在しません。APIとかメッセージキューが利用者とのインターフェイスです。これを各プロダクト開発チームのプロダクトマネージャーに見せてみましょう。

OpenAPIのYAMLファイルを見せてみる。「これ、どうですか？」「これで満たしていますか？」と言われても、そんなものを見てもわからないわけですね。エンジニア以外を巻き込んだ対話ができないわけです。「仮にその要望を表現できたとして、その要望は本当に価値をもたらすのか？」ということもまた難しい話になってくるわけです。

先ほどお話ししたように、プロダクト開発チームはコアドメインに集中したいわけですね。「じゃあ、この要望を満たせば本当にコアドメインに集中できるのか？」と。むしろコアドメインの一部だけ巻き取って分断しちゃったりとか、サブドメインを一切楽にできていないということが後からわかったりします。

プラットフォーム開発の要求分析はドメインモデルで対話する

「じゃあ、どうやって要求を分析するか？」という話をしていきたいと思います。ここで私が提案したいのは、プラットフォーム開発の要求分析はドメインモデルで対話するものです。先ほど言ったようなBIツールだと、薬剤師が服薬指導や薬歴記入をした結果を管理職が閲覧したいわけですね。

「この薬剤師はどこの薬局に所属している？」「どの法人に所属している？」というものを持っているわけです。管理職もまたどこかに所属していて、ロール閲覧権限を持っていて、それぞれの薬局や法人全体にアクセスできる流れになっている。

このようにドメインモデルというのは、システムに関連するさまざまなオブジェクト、つまり登場人物と、その関係を示したものです。

要望や要件をドメインモデルで表現することで、2つの良いことがあります。先ほど述べたコアドメインとサブドメインという概念があったと思います。コアドメインというのが、顧客に価値を提供するための本質的なエリアです。

服薬指導とか薬歴を記入した結果を、BIツールとして「どれぐらい時間がかかった」みたいなところを表示する。ここがコアになっています。それ以外の、例えば権限管理の部分。薬局とかロールとかの権限管理の部分は本質的な価値に結びついていないわけなので、サブドメインとして切り出されるわけです。

こんなふうに、なにがコアドメインで、なにがサブドメインかを可視化することで、その要望が本当に価値を生むかを検査できます。また、取っつきやすいかというと正直わからないんですが、APIとかデータベースのスキーマに比べて、ドメインモデルというかたちで図式化することで、各プロダクト開発チーム、PdMや非エンジニア職も含めて議論に参加できるようになるわけです。