こんにちは！
システム開発部でプロダクトマネージャーをしているべったけ(@gb_pdm)です。
この記事はSEN Advent Calendar 2025 の22日目の記事になります
はじめに
弊社の基幹事業でもあるスクールフォト事業は会社創業初期から続く事業でありプロダクトの稼働年数も15年を超えています。
事業拡大していく中でビジネス要求にスピード感をもって対応しなければならない場面も多く、元々のプロダクト設計で考慮していなかった部分に対して無理をした運用や追加開発も行ってきました。
部分的にマイクロサービス化させていたり、技術スタックをアップデートしている部分もあります。 しかし根幹となるデータモデルやアーキテクチャについてはサービスイン当時の構成をそのまま踏襲しており大きな課題となっています。
こういった背景もあり会社として大規模なシステム改修の機運が高まってきており、今後の事業計画を踏まえてあるべきプロダクトの状態を改めて定義していくことが決まりました。
あるべきプロダクトの状態を定義するにあたってまずはAs-Isの整理から始めましたがこのAs-Isの整理がすでにとても大変でした。。。
本記事はこのAs-Isの整理の部分の紹介になります。
As-Isを整理していくうえでの課題
事業規模が大きく全体像が見えない
スクールフォト事業は先生撮影プラン / カメラマン撮影プラン / パートナー撮影プランに分かれているのですがドメインが混じり合っています。
プロダクトチームも細分化しており事業全体の業務や構造を把握するのが困難な状態でした。
そういった状態のため、事業全体を俯瞰して理解できるドキュメントも存在していませんでした。 もちろん業務チームも開発チームもチーム内では業務マニュアルの作成や開発ドキュメントは作成していたのですが部分的なものであったり記載フォーマットが異なっている状態でした。
As-Is整理のプロセス
[STEP1]既存業務の洗い出し
業務マニュアルの収集
まず、各業務チームに依頼をして存在している全ての業務関連資料を洗い出してもらいインデックス化しました。
この作業により、250以上の業務関連資料が集まりました。
イベントストーミング(ビッグピクチャ)によるドメインイベントの洗い出し
次にドメイン駆動設計におけるモデリング技法で良く採用されているイベントストーミング(ビッグピクチャ)を行いイベントの洗い出しを行いました。
イベントストーミングとは複雑なビジネスプロセスやドメインの知識を共有、可視化、そして理解するための協同作業ベースのモデリング手法です。
業務に詳しいメンバーにも参加してもらいオンラインでのワークショップ形式で実施しました。
本記事ではイベントストーミングの詳細については触れませんが、CTOのytakeさん(@ex_takezawa)の手ほどきを受けつつ、以下の記事を参考にして進めていきました。
■参考記事
実践！モノリスからマイクロサービス！Event Stormingによるドメイン駆動設計から実装まで / AWS_Dev_Day_2023_E_3 - Speaker Deck
イベントストーミングのはじめかた / Getting Started with Event Storming - Speaker Deck
イベントストーミングは一般的に、『ビッグピクチャ』『ビジネスプロセス・モデリング』、『ソフトウェア・デザイン』の3つのフェーズで進めていき、最終的に実装可能な状態まで落とし込んでいきます。
しかし今回は全体把握に重点を置きたく、スケジュールの都合もありビッグピクチャのみの実施としました。
本当は『ビジネスプロセス・モデリング』も実施したかったのですが代わりにRDRAの『業務フロー』のフォーマットでまとめていくことにしました。(後述)
理由は業務チームにもフロー整理をしてほしく『ビジネスプロセス・モデリング』のフォーマットよりもRDRAの『業務フロー』のほうが書きやすそうだったかったからです。 ただしビッグピクチャのみの実施にしたことで今後システム設計のタイミングで追加の検討事項が出てくる可能性はあると思います。
■ビッグピクチャの実施手順
- 業務チームにドメインイベントを付箋で書き出してもらう
- ドメインイベントは過去形で表現する
- 時系列で並び替える
- 業務プロセスの中で重要で、後戻りしにくいイベントをピボタルイベントとしてマークしておく
点在していた用語集を集約しユビキタス言語（マスター）を作成
次に各チームに点在していた用語集を集約し事業全体のユビキタス言語一覧を作成しました。
本来は同じ言葉であってもコンテキストによって違う意味を持つ場合があるので、その使い分けまで含めてこのユビキタス言語で定義するべきなのですが、まずはその言葉のゆらぎが存在するかどうかを議論できるようにするために、素早くざっくりと一覧でまとめました。
まとめたユビキタス言語は業務チームにもレビューをしてもらい、最終的に350語以上洗い出されました。
■フォーマット
- 呼称
- 社内で実際に使われている言い方でまとめる。俗称、略称も認める
- 読み方
- ひらがな読みでどう読むかを記載
- 意味
- その言葉の意味、定義を記載
- 類似語・同一語
- 同じ意味で他の言い方をしているものや、似ている言葉をまとめる。正式名称もこちらに記載する
- 補足文章
この後紹介する業務フローの可視化やオブジェクトモデリング作成工程においても新しい単語が出て来るので都度ここに追加しコンテキストの違いや定義も追記していきました。
[STEP2]As-Isの全体像をモデリングする
[STEP2]では[STEP1]で収集した情報を元にモデリング作業を行いました。 モデリング作業を進めていくに当たりベースとなるモデリング手法はRDRAを活用しました。
RDRAでは抽象度の異なる4つのレイヤーで各要素をモデリングしていく手法です。
イベントストーミングはよりシステム設計に寄ったモデリング手法だと個人的には理解しており、要求整理・業務要件整理の目的ではRDRAでの整理の方が整理しやすそうだったため、RDRAを採用しました。
その他下記も魅力的に感じた部分です。
- アジャイル / ウォーターフォールどちらにも適用可能なモデリング技法
- 「作るもの」だけでなく「なぜ必要なのか？」も表現できる
- 少ない文章量でステークホルダーと共通認識を得やすい
- AI / ドメイン駆動設計とも相性が良い
ビジネスコンテキストマップの作成
まずはドメインモデリングの最上位概念としてRDRAで定義されている成果物の1つであるビジネスコンテキストマップを作成しました。
ここではスクールフォト事業を構成する業務と、それらの業務に登場する人物（アクター）を関連付けています。
この整理を行っていく中で、「誰が」「どの業務」に関与しているかが明確になりました。
実際に業務チームの方と整理を進めていく中で、「○○業務ってこれまで○○チームがやっていましたが、目的としては『マーケティング』、『カスタマーサクセス』に近いので、本来は○○チームが行うのが良さそうですね」という会話が生まれました。
また、明確にこのプロダクトの責務であるという判断ができない業務も存在し、そういった曖昧さはあえて残したまま表現しました。 こういった業務が境界づけられたコンテキストを明らかにしていくうえで重要なものになってきます。
ビジネスユースケースの洗い出し
次にビジネスコンテキストで洗い出した業務の中から、より細かな業務（ビジネスユースケース）がいくつあるか洗い出しました。
ビジネスユースケースは業務として価値のある単位で分解していきます。
同じ価値でもアクターや条件によって業務が大きく異なるものは、異なるビジネスユースケースとして整理していきます。
「手配業務」というビジネスコンテキストにおけるビジネスユースケースの例
○○チームが撮影依頼に対して個別にカメラマンの手配を行う
○○チームが撮影依頼に対してまとめてカメラマンの手配を行う
○○チームが繁忙期の撮影依頼に対してカメラマンの手配を行う
この時点で150ケース以上のビジネスユースケースが洗い出されました。 この作業により、業務の粒度が明確になり、後続の業務フロー可視化の基礎となりました。
[STEP3]モデリングした全体像の解像度を上げる
業務フローの可視化
ここがもっともタフな作業で、洗い出された150ケース以上のビジネスユースケースを業務フローとして可視化する作業を現在も進めています。
この作業を進めるにあたって、『[STEP1]既存業務の洗い出し』で洗い出した『業務関連資料』『ユビキタス言語』をNotebookLMに読み込ませ、AI活用&人海戦術でフロー化を行っています。
開発側で業務フローの叩きを作成して業務チームにレビューしてもらうプロセスで進めているのですが、そもそも開発側での業務解像度が足りず業務チームにヒアリングするか業務マニュアルを読み込まないと叩きの作成もできかったのがNotebookLMと対話しながら業務チームへのヒアリング不要で業務フローの叩きが作成できるようになり大幅な効率化につながりました。
かなり大変な作業であるものの、この作業を通することで業務解像度が大幅に向上し、業務チーム、開発チームどちらも理解できる事業全体を俯瞰したドキュメントが出来上がってきています。
フォーマットについてはRDRAのフォーマットを基本にしつつ、アクターとシステムの関連もスイムレーンで表現しています。
オブジェクトモデリングの整理
業務フローの可視化と並行してUI設計の基本構造をモデリングするためにオブジェクト指向UIデザインに登場するオブジェクトモデリングも進めています。
オブジェクト指向UIデザインは『アクション選択→オブジェクト選択』ではなく『オブジェクト選択→アクション選択』という操作順序を意識したUIにすることで直感的で拡張性のあるUIが実現できるという設計手法です。
■オブジェクトモデリングの手順
- 『イベントストーミング』で洗い出されたイベントや業務フローから名詞を抜き出す
- 名詞を汎化させ概念や対象物として扱える表現に変えオブジェクトを抽出する
- オブジェクト同士の関係性を整理しメインオブジェクトとプロパティ(メインオブジェクトに付随するオブジェクト)に分ける
- メインオブジェクトの多重関係を特定する
オブジェクトモデリングにより、ユーザーが操作する対象（オブジェクト）を明確にし、UI設計の際に直感的で使いやすいインターフェースを設計しやすくなります。
あるべき姿を実現するために
ここまではAs-Isの整理が中心でしたがオブジェクトモデリング、業務フローの可視化はTo-Beバージョンも作成予定です。
また現在の粒度は開発Readyな状態ではないため、優先度整理やスコープを定めてより要件を具体化していく必要があります。
そのために下記を引き続き全力でやっていく予定です。
- 業務フローの中に登場するユースケースの仕様詳細を詰めていく
- (今回紹介できませんでしたが)概念データモデルをベースにER図を設計していく
- オブジェクトモデリングをベースにデザインにおけるインタラクション設計、プレゼンテーション設計をしていく
以上、基幹システムのリプレイスに向けた壮大な取り組みの紹介でした！
こういった大規模な取り組みは巻き込む人も多く、膨大な時間がかかるため、1プロダクトマネージャーの思いつきだけでは進めることができません。
会社全体として「やっていき！」が合意されていることが必須になってきます。
今回は全社方針としてやることが決まったため業務チームの方を含め多くの人を巻き込んで進めていくことが出来ました。
協力いただいた皆さんには本当に感謝です。
SEN Advent Calendar 2025 23日目となる明日はえだまめさんになります！ アドベントカレンダーも残すところ後3日！
千株式会社では共に幼保業界や写真業界のDXを進めていく仲間を募集しています！
📋 採用情報
