目次
目次
はじめに
マルチプロダクトチームの村中です。
今回、マルチプロダクトチームの活動の一環としてNulab Appsの開発チーム（Appsチーム）とイベントストーミングを実施したので、その模様やそこで得られた知見を共有させてもらいます。
そもそも私たちマルチプロダクトチームとはどういうチームなのかと言いますと、ヌーラボが掲げる「ナレッジプラットフォーム構想」の実現を支援するために組織されたチームです。この「ナレッジプラットフォーム構想」は、ヌーラボの各プロダクトに蓄積されるプロジェクトのナレッジを、新しいプロダクトも含めてつなぎ、AIも活用しながら「チームの仕事を前に進める」ことを目指す構想です。
この構想では既存プロダクトの改善にとどまらず、新しいプロダクトの開発やプロダクト間のコラボレーションによって新たな価値を生み出していくことを目指しています。そして、プロダクトが増えていくほど、それらを分断させず、一つのナレッジ基盤・体験としてつないでいくことが重要になります。
私たちマルチプロダクトチームは、この「つなぐ」を技術面から支える役割を担っています。
具体的には、開発者が各プロダクトの価値(コアバリュー)の開発に集中できるよう、以下のような各プロダクトで共通して使える「アプリケーションプラットフォーム」を提供します。
- Golden Path(プロダクト開発のために推奨される標準的な進め方・規約)の定義・共通基盤の設計原則策定
- 共通ライブラリ・コンポーネントの実装と保守
- 重複実装の共通化リード
ただ、こうした基盤を用意するだけではプロダクトをつないでいく取り組みは進みません。エンジニアやPdM（プロダクトマネージャー）自身が、既存プロダクトに機能を追加するだけでなく、新しいプロダクトの開発やプロダクト間のコラボレーションによって新しい価値を提供することに意識を向けていく必要があります。
そのためには新たな機能を提供する際に、それは既存プロダクトで提供すべきものか、新しいプロダクトとして提供すべきものかを分析したうえで、どのような形で提供すべきかを考える必要があります。そして、こうした分析を行うにはそのプロダクトが担っている機能（ドメイン＝そのシステムが扱う業務領域）を正しく理解していることが前提となります。
そこでマルチプロダクトチームでは前述のような「アプリケーションプラットフォーム」を提供するだけでなく、各プロダクトチーム自身が自律的に自分たちのプロダクトの担うドメインを分析できるようになるための支援も行う予定です。
今回のAppsチームとのイベントストーミングはその最初の実践でもありました。
背景
マルチプロダクトチームの最初の取り組みとして、まずNulab Appsを対象としました。
Nulab Appsとはヌーラボの各プロダクトをまたいでアカウントや組織の管理、認証を行っている共通基盤で、複数のプロダクトが共通で利用する、いわば土台にあたる存在です。一方で、Nulab Appsは長く開発が続いてきたこともあり、担っているドメインが広く、その中には暗黙知も多く存在していました。
プロダクトをつないでいくにあたり、まずはこの共通基盤が具体的にどのような機能を有しており、それに対してマルチプロダクトチームがどのようにアプローチできるか分析するところから着手することになりました。
そのための第一歩として、まず現状のNulab Appsがどんなドメインで成り立っているのかを整理することにしました。
こうして、Nulab Apps全体のドメインを可視化するべく、Nulab Appsの有識者を交えてイベントストーミングを実施してみることになりました。
イベントストーミングとは
イベントストーミングとは複雑なビジネスや業務の仕組みを短時間で可視化、理解するために関係者が集まって進めるワークショップ形式の手法です。
やり方としては、みんなで大きな模造紙などに「アカウントが登録された」といった「起きた出来事」(ドメインイベント)を一斉に付箋で貼りだし、それらの間の時系列(関係性)を整理していきます。
全員が一斉に書き出すことで、個々人の頭の中にある業務知識や人によって微妙に違う暗黙の理解をチーム全員で目に見える形にすることができます。
イベントストーミングの模様
イベントストーミングを実施することに決まり、さっそくAppsチームの参加者を募集して第一回のイベントストーミングを開催しました。
第一回ということで、全員でNulab Appsの持つ機能全体を対象にドメインイベントを洗い出したのですが、付箋の数はかなりの量になりました。
そうして洗い出した各ドメインイベントに対して参加者で内容のすり合わせを行い、様々な暗黙知をあぶり出すことができました。
その中で出てきた暗黙知の例として、例えば「組織に所属していないアカウント」という概念が挙げられます。これはAppsチーム内では当然と捉えていたものの、他のプロダクトの開発者はあまり意識したことがないものでした。こうしたアカウントで何ができるのか、といった暗黙知も可視化することができました。
一方で、洗い出したドメインイベントを掘り下げる際に議論が一部の人に偏りがちで、全員から幅広く意見を引き出すには至りませんでした。また、あまりにも膨大なドメインイベントが出てきたことからAppsチームの参加者から「他のタスクもある中で、この取り組みにいつまで・どれくらいの稼働を求められるのかが見えない」「その状態で、最後までやり切れるのかがわからない」という不安の声も上がりました。
そのため、Appsチームのリーダーたちと改めてイベントストーミングのゴール(目的)や進め方について認識を合わせるための相談会を設けました。
この相談会では次のことを取り決めました。
まず、イベントストーミングのゴールについて、直近のゴールはNulab Appsのドメインの全体像を整理し、今後マルチプロダクトチームがどうアプローチするかを検討するために必要な情報を洗い出すこと、中長期のゴールとして今後の開発に向けてAppsチーム自身が自律的に自分たちのドメインを分析できるようになること、としました。
そして、進め方として週2回、3週間で完了させる短期集中のスケジュールで実施することにしました。
あわせて、今後のイベントストーミングをAppsチームで誰が担当するのかを明確にし、「完璧なものを一度で作り上げる必要はなく、間違っていても構わない」という方針を今後のイベントストーミングを担当することになったメンバーと共有しました。
以降のイベントストーミングは、この相談会で決まったメンバーと進めていくことになりました。
そして以降の回では完璧なものを作ろうとしないこと(不明点があってもそこで悩まず、「分からない」という事実を残す)を意識しながら進めていき、無事、予定通り3週間で一通りのイベントストーミングを完了させることができました。
こうして集中的にドメインイベントの洗い出しを進め、ひととおりの可視化が済んだ後は用語（名称）の精査や気になった部分の深掘りといった作業を別途実施していくことになりました。
まとめ
最後に、Appsチームとのイベントストーミングを通じて得られた学びをまとめておきます。
まず、イベントストーミングを行う前に相手先チームのリーダー(人員配置に責任を持つ人)とイベントストーミングの目的やスケジュールを合意しておくことの重要性です。Appsチームとのイベントストーミングでも、これらを充分に説明せずにいきなり開催してしまったことで参加者にいたずらに不安感を与えてしまったと反省しています。他の業務でも同じことが言えますが、限られた時間で効率的に開催するためにも事前のすり合わせは不可欠であると認識しました。
もうひとつはイベントストーミングにおいて完璧なものを目指さないことです。人間、どうしても資料として「正しいもの」を作ろうとしてしまいがちですが、イベントストーミングにおいては「作り上げる」こともさることながら、それを「育てていく」ことも意識しておくことが大事だと感じました。
「正しいもの」「完璧なもの」を作ろうという意識が強すぎると、どうしても「合ってるか分からないから黙っていよう」「ここの仕様があいまいだから議論して確認しておきたい」という心理が働きがちですが、そうなるといくら時間があっても足りなくなってしまいます。また、いくら「今」完璧なものが出来上がったとしても、いずれ仕様変更で陳腐化していくことは避けられないため、むしろ最初からそのようなあいまいさ、不確実さを許容し、都度、修正していく意識でいた方が、長い目で見れば効率的であると思っています。
今回、初めてイベントストーミングを本格的に実施したのですが、プロダクトのプロセスの可視化やチーム内の認識を揃えるという意味ではかなり有用な取り組みであると感じました。
今後、他のプロダクトでも同様の取り組みを行う際には前述の学びを生かしてより良い場を提供できるように努力していきたいと思います。
