EventStormingとUserStoryMapping、どう役立ってる？
「10X アドベントカレンダー2022」の12/11担当 @tae124m です🎄。
この記事では、EventStormingとUserStoryMappingをどのように開発現場で利用しているか？について書きます。これらは比較して語られることがあると思いますが、それぞれのどのように役に立ったのかを語ってみます。
なお、EventStormingやUserStoryMapping自体の説明はしません。この記事最後に参考文献を添付しておきます。
LIFE大好き。推しはBIO-RALごはん
本編に入る前に、10Xアドベントカレンダー2022のお作法に則って、私の推しをお伝えします。
前日のエントリーMikityと同じく、私もLIFE好きです。6年以上毎日の食卓はLIFEにお世話になっています。どれをオススメするか迷ったのですが、今回は我が家のロングBUYであるBIO-RALごはんを選びました。健康志向に目覚めた面倒くさがり屋さんも、玄米を手軽に美味しく食べれます。ちなみに私は玄米ごはん派で、夫と息子は玄米と十六穀ごはん派です。
20年運用したネットスーパーシステムをStailerにリプレイスしたい
本題に戻ります。今年の春から、とある企業様のネットスーパーシステムを、Stailerに移行するプロジェクトをPdMとして担当しています。現行システムは既に20年運用している実績があり（凄いです）、リプレイスの面白さと同時に難しさを感じています。
- Stailerと現行システムの差分が大きく、追加開発する機能がめっちゃある
- 中でも、Stailerが提供してきた物流と違う仕組みを提供する必要がある
- 事業上の課題解決するために移行するので、現在と変える必要があるが、変え過ぎる失敗リスクや開発コストと天秤にかける必要がある
共通認識を持つことが大事であり、難しい
リプレイスに向けて、様々な組織やチームを巻き込みながら進めています。
現行事業に詳しい人、Stailerに詳しい人、物流に詳しい人、ネットスーパー事業に詳しい人など、知識と関心事が異なるメンバーが集まる中で、何のために、何を、どう作るか？について、必要な共通理解を持った上で議論されることが大切になってきます。が、難しい（笑）。
UserStoryMappingで俯瞰的に捉えられた
PJメンバー内で共通認識を持ち議論するため、As is調査を一通り終えた段階で、パートナー企業様と一緒にUserStoryMappingを作成しました。
ユーザー視点での全体可視化に役立った。Gap多いよ〜！
開発初期の計画づくりの段階でユーザー視点で全体感を把握し、ユーザー視点で何を変えて何を変えないのか？何をどのぐらい開発する必要があるのか？優先順位は？を検討する材料としてこのマップが役立ちました。UserStoryMappingの見方自体はシンプルです。ユーザーストーリーは左から右に流れていき、上の方が優先度が高いというルールさえ押さえておけば、システム開発に関わるのが初めてという方にも内容を把握頂けるようでした。
また、このUserStoryMappingのアウトプット副産物として、チームのOnboardingにも役立ちました。この記事執筆時点で、このプロジェクトで開発するアプリケーション仕様書が30以上あります（汗）。開発途中でJOINした方に、仕様書で全体像をお伝えするのは難しく、UserStoryMapが役立ちました。
EventStormingで知を集結する
Stailerは金銭に関わる機能、業務システムとしての機能を提供します。そのため、システムの振る舞いも含めた詳細なイベントの整理が必要であり、UserStoryMappingで全て表現するのは困難です。これら詳細分析にはEventStormingを活用しています。
まずは、PdMがヒアリング内容を元に大まかにイベント（オレンジ色）をマッピング。現行業務に詳しい方、現行事業に詳しい方、配送ドメインに詳しい方、Stailerに詳しい方が集まり、認識合わせをしながら、イベントを追加、修正して作成しています。EventStormingは、今回が要件定義に関わるのが初めてという方も参加可能で、詳細も含めてWhy, What, Howをクリアにすることに役立ちました。
Tipsを１つ紹介させてください。チームのローカルルールで、開発側の観点で知りたいことを紫色で添付し、解決したら赤色に変えるという運用をしています。数多い論点を確実に潰し、記録に残す作業にとても役立っています（発案したishida-sanに感謝！）。
As is&To be整理の両方に適用した
EventStormingとUserStoryMappingは以下のような流れで適用しました。
- As is整理でEventStorming
- 1のInputを元にTo beをUserStoryMapping
- 1, 2をInputとして、仕様書にUserStory（テキスト）形式にまとめる
- 1, 3をInputとして、To beのEventStormingを行う
現場での運用上大事なことは、EventStormingやUserStoryMappingのお作法・ルールに拘り過ぎず、達成したいことを満たせれば良いという姿勢で、参加者の経験・リソース・物理的な制約等に合わせて柔軟に対処することだと感じました。
（もちろん原理原則を理解しておくことは超大事で、リスペクトしている前提です！）
最後に
30個の仕様書について絶賛開発中で、まだ要件定義フェーズです。他チーム含めて10Xは一緒に働く方を求めています。
少しでも興味があったら採用ページを見てみて頂けると嬉しいです！
明日12/12のアドベントカレンダー担当はMurai-sanです。お楽しみに！
参考ブログ、書籍
-
新しいモデリング手法: EventStorming (イベントストーミング) をはじめるための準備 - yoskhdia’s diary
- Amazon: User Story Mapping: Discover the Whole Story, Build the Right Product
10Xに入社しました
こんにちは、@tae124m 松本です。7月1日から株式会社に10Xに入社しました。
今回転職したらブログを始めようと決めていました。このブログ初投稿で10X入社に至った経緯について書きたいと思います。
全力で走っていたけれど一度立ち止まることにした
新卒で製造業を経験し、その後IT業界に転職してきて6年ちょっと経ちました。その間多くの仕事を任せて頂きました。特に前職ではFundsの開発初期から携わり、バックエンド開発、運用業務全般、組織づくりまで幅広く担当してきました。充実した仕事時間を過ごしてきた一方で、子供が小学校入学してこれまでと質が違うサポートが必要になったことをきっかけに、ワークライフバランスや今後のキャリアについて一度立ち止まって考え直したいと強く思うようになり、退職することを決めました。
長期的にコミットできそうな会社について考えた
上に書いたような経緯なので急いで転職とは考えていなかったものの、組織で働く方がパフォーマンスを出せるタイプなので、縁がある会社があれば入社しようと考えていました。
自分が長期的にコミットできそうな会社を探すということを念頭においた結果、私の転職軸はこんな感じでした。
- 会社のバリューに共感できる
- 技術トップが経営に参画していて、方針に違和感ない
- 事業に関心が持てる＆自分が貢献できそう
- 採用・選考プロセスに力を入れている
- サスティナブルに働けそう
選考プロセスに力を入れている＝選考受ける側の負担感あるケースもあると思います。ただ、入社後に発覚する「こんなはずじゃなかった」感は個人も会社も不幸せで、選考プロセスでそれを出来る限り減らすことは大事だと思っていたので、私はポジティブに捕らえていました。
10Xとの出会い
きっかけは前職同僚で、先に10Xに入社していた元同僚のsuuminから「もしファンズを卒業することがあれば10Xを検討してほしい」と連絡を貰ったことです。既に退職予定も確定していたので「是非お話聞かせてください」という回答をしつつ、10Xの公開情報を調べてみたところ「自分が貢献できそうか？」という点以外は満たしていそうな事に気が付き、業務委託契約を結びトライアルを受けることにしました。
【エンジニア編】カジュアル面談でよく聞かれる質問にお答えします | 10X, Inc.
ちなみに、漠然と「10X怖そう」というイメージを持っていたのでトライアルを受けるかどうか迷っていた時期があったのですが、オフィスにお邪魔して皆さんの生のやり取りを見る機会を得まして、怖くないと分かりました（笑）
10Xに決めた理由
バリューがあらゆるところで体現されている
10Xで定められているバリューは、トライアルで関わった皆さんがバリューを高いレベルで実行していることに加えて、組織上の諸制度にまで浸透していることを感じました。皆さん10xから逆算したアクションに対して自律的に動き、スピード感もって物事が進んでいく様が頼もしく、そして自分にも合っていそうだなと思えました。コミュニケーション面ではテキストだけに頼らず、直接話をした方が早いときは気軽にMeetsで話して解決というのが日々のカルチャーなのですが、コロナという状況下で入社するという視点からも有り難い環境だなーと感じました。
未完成なところも多く貢献できる余地が大きく、これから面白いフェーズを迎える
Stailerがローンチされて既に1年が経過しており、0→1の経験が多かった私がモチベーション含めて貢献できるか？というのは懸念点の１つでした。Stailerは既に複数企業にサービス提供開始していますが、ここからの展開を考えるとまだ入り口段階であり、事業としても組織として今後大きくスケールしていく最初のフェーズにあることが分かりました。裁量を持ってサービス・プロダクト・組織を作っていきたいという人には面白い時期だと思います。また、自分が未経験な採用技術がほとんどだったことも懸念点だったのですが、複雑なドメインを扱う・業務設計・要件定義や仕様作成・BizDevチームとの連携など、これまでの経験を活かしつつ10Xに合った形で自分らしく貢献していくことはできそうと判断しました。
ワークライフバランスを大事にしてパフォーマンスを出す
今回の転職の発端となったのは、ワークライフバランスとキャリア見直しでした。自分は家族との時間を大事にしながらも、仕事においてハイパフォーマーで有り続けたいと願っていました。そして、10Xではこれを体現しているメンバーが多いと感じました。会社としてプライベート優先を掲げていることは勿論のこと、各々が自律的に動き、一人で悩まずクイックに必要な人にアクセスして相談して解決することが実現しているファクターの１つかなと思いました。今後組織が大きくなる中で新たな課題も出てくると思うのですが、状況に合わせた取り組みで解決していけるのではないかと思える現場でした。
※このブログを書いている今、入社1週間経過したのですが、物理出社した日にオフィス見渡すと17時にサクッと帰る人が多いです。
プロダクトマネージャーとして働きます
私は前職、前々職ともにエンジニアロールで入社しましたが、必要に応じてプロジェクトマネジメント・プロダクトマネジメント領域の業務も兼任していました。10Xではプロダクトマネジメントでのオファーを貰いました。
プライベートを基盤としながら、エンジニアのバックグラウンドを活かしつつPMとしてパフォーマンス出していきたいと思います。今後やっていきたいことはもう少し状況把握が進んでから書きたいと思います。ちなみにコードを書いちゃダメとも言われていないので、必要に応じてPR作るかもしれませんｗ
興味があったら気軽に連絡ください！
今10Xでは多くのポジションで絶賛採用中です。少しでも興味を持って頂けた方は是非コンタクトください。私個人宛も大歓迎です！
