チームで輪読会を開催しました【ユーザーストーリーマッピング】
いよいよ年の瀬ですね〜!お仕事は納まりましたか?
今日はあすみ(@asumikam)がお送りします!🙌
私たちのチームではユーザーストーリーマッピングという本の輪読会をしました。
この記事では決め方→実行→どうだったか、までを紹介していきたいと思います!
なぜ輪読会をやろうとなったのか
輪読会は私が「やろう!」と提案しました。
私たちは先月(11月半ば)から発足した新チームで、初めて一緒に仕事をする人もいました。
チーム発足し、とりあえず目の前の課題を解決していく中で「プロダクトに向き合う上での"チーム"で共通認識を築きたい」と思ったのがきっかけです。
また年明けから本格始動するようなチーム状況でもあったため、「隙間時間(?)の12月にチームの結束力を底上げしたい」という気持ちもありました。
提案したところチームでも「やりたい」となったので、12月初旬頃にやることを決定しました💪
本を決めよう
候補を挙げる
読みたい本を以下のフォーマットで挙げました。
- 本のタイトル
-
採用したい理由・何を高めるために読みたいか
- 大目的「プロダクトに向き合う上での"チーム"で共通認識を築きたい」に沿っているか
-
ページ数
- 小目的「隙間時間(?)の12月にチームの結束力を底上げしたい」に沿っているか
1人1〜2冊出し、このタイミングでは以下のような本が挙がっていました。
- 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について
- 単体テストの考え方/使い方
- ユーザーストーリーマッピング
- レガシーコード改善ガイド
- プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで
- アジャイルサムライ
- プロダクトマネジメント―ビルドトラップを避け顧客に価値を届ける
仮投票→実際に少し読む→ガチ投票
今回、輪読会を決める上で「良いやり方だったなー」と思う部分です🤩
本のタイトルだけ見て、中身のニュアンス合わなかったわ...みたいなタイミングって...ないですか?
私は結構あるんですが、「期待してたんと違ったかも...」となり、途中で読書モチベが下がっちゃうんですよね。
このチームでは12月中にガツガツ読むことを目指していたため、そのような文脈違いが起こるのは避けたいことでした。そのため、まずは1人2票で"仮投票"をし、票が集まった本について"実際に少し読んでみる"事をしました。
仮投票→ガチ投票で以下のような票の推移をしました。
- 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について
- 仮: 3票
- ユーザーストーリーマッピング
- 仮: 3票
- ガチ: 5票
- アジャイルサムライ
- 仮: 1票
- プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
- 仮: 5票
- ガチ: 1票
決まったのは「ユーザーストーリーマッピング」
はい。実はこの本、私が出した本の1冊です📕
今年読んだ本で1番感動した本で、実際、エンジニアのミートアップ(全体会)でも「わたしたちのリリースは誰かを喜ばせているのだろうか?」という発表で紹介した本でもありました。
面白いのは、仮投票の時は3票だったのが、読んでみてほぼ全員がそちらに寄った、という点です。
本の内容を読んでみてチームの大目的「プロダクトに向き合う上での"チーム"で共通認識を築きたい」にしっくりきてたのがこの本だったみたいです。
この経験から見るに、やはり"実際に少し読んでみる"という過程はめちゃくちゃ良かったなあ、という感じ。
実際のやり方
さて...この本は368ページ、全19章+αあります。
決まった段階で、残りの12月は2週間とちょっとしかありませんでした。
目的「隙間時間(?)の12月にチームの結束力を底上げしたい」を叶えるために、少しタイトめなスケジュール感で走りました。
- 開催
- 週2,3回
- 1時間とちょっと
- 予習
- 2章分もくもく読む
- (書ける人は)感想記事を書く
- 実際の輪読会
- 2章分もくもく読む
- 議論をする
- (書ける人は)感想記事を書く
- 他の人の記事を回遊する
今回この輪読会で大事にしたポイントは以下の3つです。
1つめ: 議論をする
1番大事ですね〜。
本を読んでみてどこが響いたか、わからなかったところはどこか、ここについてどのような解釈をする?、の様なことを話しました。
今回、「解釈ができなかった部分」について各々で知識を補填していくことが多かったな〜と思っています。割とタイトで進めているので・・・!響いたところが違うというか。すっ飛ばして入ってないところもあるはずです。他の人はちゃんと読んでいる部分だったりするので、まさにチームで"埋め合う"ことができました。
2つめ: 感想記事を書く
これは急に現れたあすみのエゴなのですが「アウトプットをめっちゃしてもらう、慣れてもらう」をこの輪読会で同時に叶えたいな、と思いました。この"あすみ目的"を叶えるため各章に関して感想記事を書いてもらうことにしました。
というのも、うちのエンジニアにはアウトプットを出す、もっと言うなら「パッケージ化された文章を書く」のにもっともっと慣れてほしいな〜と常日頃思っているからです。
私自身の経験になるのですが、毎年アドカレを書くのに加えて、アドカレの本数を増やす、というのをここ数年やっており自分の文章を書く速さが上がってきているな、というのを感じています。
以前は本の感想を書くのがめちゃくちゃ遅く、かなりの時間をかけてようやく"それなり"が完成する、といった感じだったのですが、今年は特に"それなり"のアウトプットであればスラスラ書けるようになっているな、と感じています。
ハードル低いところから始めるのが良いだろう、と思ったので、練習も兼ねて、各章に関して「400〜1,000文字でパッケージ化された文章」を書いてもらうこととしました。
3つめ: タイトだが、完璧を目指さない
今回、頻度も多い・時間も短い・予習もある・12月中に読み切る(・さらに記事も書く・・・)、ということで割とタイトめなスケジュールで輪読会を組んだ印象があります。
目的はブラさず大事なことは「読み切ること」とし、「予習部分は最大20ページ前後までにする」「感想記事は歯抜けでOK」「議論部分はピザたべたり寿司たべたり(リアル開催の時は)」というゆるい感じで進めました。
本の感想
実際に各メンバーの一部の記事をご紹介していきます🙌
0章「まず最初に読んでください」
感想: CHANGE THE WORLD
0章 まず最初に読んでください
言われた通り最初に読んだ(言われなくても飛ばさないが)時、それぞれの節の文量は少ないのに述べている内容がそれぞれ濃いなと感じた。また最後まで一通り読んだあとに振り返ってみると、本書のエッセンスは全てこの0章で述べられることに気づいた。「全体像を把握しましょう」という言説を、この本自体が体現していて面白いなと思った。あと章の名前がこの上なく分かりやすい。
本当は、あなたの仕事は世界を変えることだ
(0.5 正しいことについて話そう)
たしかに言葉としては大げさだが、筆者の目論見通りここが一番印象に残った。後の章で述べている会話や学習などといった様々な重要なことを行うのは何故?という問いの答えがこの1文であるように感じた。
わたしの全体感想
まず序文の掴みが100点満点だと感じた。「ストーリー」や「ストーリーマップ」がどういうものか知らないまま序文を読んだ感想、風呂敷を広げてるというか伏線を張ってるというかそんな印象を受けた。良いプロダクトの開発における様々な難しい点を述べたうえで、「ストーリーをうまく使えばうまくいく!(意訳)」と三者口を揃えて言って、期待感を高めている。
本文では、理想を語るだけでなく、どう現実に落とし込んでいくかまでしっかり言及しているのが良いと思った。(マップを作ったはいいが作るべきものが多すぎる場合にどのように作るものを減らすかの話や、プランニングにやる気のない人がいる場合は対応としてこうすると良い、といった話など)
それから、この本の内容をチームメンバーの共通理解として持てたのが大きなプラスだと思う(本の内容自体の感想ではないが)。
こんなタイトルで各記事書いてたよ!
5章「あなたはもうやり方を知っている」
感想: ユーザーに対しての本当の理解がなければ作るのは難しい
ユーザーの視点が考える必要があるのに今まで開発者・サービス提供者の視点で考えて開発をすることがほとんどで自分達が何を知らないかを炙りだすかだけで開発をしてリリースをしまっていたことが認識できました。この本の中では朝目覚めた後にやることのように自分も実際にやっていることに対して1度考えてみるという練習がありそこで作ってみたユーザーストーリーを整理していくことを実際にやってみることでユーザーの視点に立って考えることの重要性を強く感じることができました。ユーザーの痛みを直接的に感じれていない自分たちがストーリーを作っていくといいものができてないなという感覚を味わうことができました。
わたしの全体感想
今まで我々がやっていた開発からリリースまでリリースすることが開発者・システム提供者の自己満足に特化したものになってしまっていたというのを実感することができました。ユーザーは何に困っているのか考えてリリースした上でそれが使っているかを本気で追って振り返りながら学習し続けないといいものはできないなと強く感じることができました。この本で得た考え方を参考にしていいプロダクトを作っていきたい。
こんなタイトルで各記事書いてたよ!
9章「カードは始まりにすぎない」
感想: ドキュメントよりも一緒にストーリーを作ることを
ドキュメントは自分にとっては明確で、この章を読むまでは、他者に共有するにはそのドキュメントを見せるしかないと思っていた。さらに、そのドキュメントをわかりやすくなるように書き方を工夫することが共通理解に繋がると思っていた。
この章を読んで、ドキュメントでは決定事項はわかるが、共通理解をしたという風には思ってはいけないなと気づいた。多くの立場の人と共通理解を作るためのやり方や動き方に工夫をすべきだと認識した。
まきまきの全体感想
そのプロダクトに関わっている人たちと共通理解を作りながらプロダクトを生み出し、リリースしたものを喜ぶのではなく、成果を確認して学習するというところが印象的だった。確かに、私たちはリリースすることが目的ではなく、ユーザーに価値を感じてもらうことが目的であり、それで世に貢献するし生計を立ててるんだった…とハッとした。
あと、自分はECサイト運営等をやったことがないため、ストーリーを作るにしても悩むところが多いと思う。ユーザーともっと接点を持ちたいと思ったし、自分もEC事業を経験したいと思った。
ユーザーストーリーをみんなで作りながら課題や改善点を見つけて開発し、ユーザーの反応を確認して学習していくことで、よりよいプロダクトにしていきたい。
こんなタイトルで各記事書いてたよ!
12章「岩を砕く人」
感想: プロダクトオーナーってプロデューサーだったんだな。
他のステークホルダーが出したアイディアのために、プロダクトオーナーの任にあたるときは、彼らが成功を収められるように手伝うプロデューサーの役割を果たそう。
(12章 岩を砕く人)
プロダクトオーナーは、音楽プロデューサーとバンドの関係に似ているという例があり、だいぶプロダクトオーナーというロールの認識がアップデートされた。本当にプロダクトそのものの責任を負う立場であり、たしかに、他の業務の片手間でできる仕事ではないだろうとこの章を読み終わった今では思う。
まさき。の全体感想
この本では一貫して、我々が考えたことは全て仮説に過ぎず、その仮説は間違えることが多いんだから、素早く仮説を検証するために実験的なリリースを重ねようって述べているのが印象的だった。完璧じゃなくても間違える前提で、ユーザーから学ぶためにリリースしていいんだ!ってなったのは大きい。
また、リリースなどのoutputではなく、ユーザーはどうなるはずか?というoutcomeを重視するべきであるというのは本当にその通りだと思うし、チーム全体としてその認識が揃ったのはものすごく価値のあることだと思う。
こんなタイトルで各記事書いてたよ!
16章「リファイン・定義・構築」
感想: 「開発タスク」は本当に最後の最後で良い、"会話"をいっぱいする
これは会議ではなくワークショップである。会議という言葉は、今や非生産的なコラボレーションを表す婉曲語になっている。
(16章 リファイン・定義・構築)
「ワークショップであって、会議ではない」、ここに真意が表現されていると思う。
ストーリーを最終的な"角のとれたストーリー"にするには、カード-会話-確認(3C)の確認作業が大事である。
ここで大事なのは本当に"最良の会話"。インタラクティブに進めていく必要がある、ということがめちゃくちゃ伝わる。
一時期、効果的なプロダクトバックログアイテムとかを調べていた時期があるが、その行為自体が間違っていたんだな、と思う。大事なのは"話すこと"だから、フォーマットなんて存在しなくて、みんなで共通理解が築けるのが大事なんだな、と。
それにしても、この章にはその「ワークショップ」にを実際に進める上での進め方や存在しうる課題感・解決方法なども載っていて、自分たちでも試す上で指標になる。最高。
その中でも「フィッシュボウル・コラボレーション」は独特で面白い。
興味ある人全員でミーティングを行い、円の中に入る人数を制限しその人だけが喋れる、というもの。
たしかに長いミーティングの中で、興味のない会話と興味のある会話、みたいなのが存在することがあって、一部のためにフルで誘うことがある。これ使えば回避できるのか?まあ...実際やったら集中できなさそうだが。
ただ、面白いやり方だな〜と視野が広がった。
asumikamの全体感想
2周目だったが、やはりこの本は最高...。
「ユーザー・チームメンバー・ステークホルダー、全ての人と"対話"をしよう」と強く思えます。
この本を、これから仕事するこのチームで読めたこともめちゃくちゃ嬉しい。
本の全体的な感想は個人ブログにも書いてるので、是非みていってください😗
こんなタイトルで各記事書いてたよ!
やってみてどうだったか
みんなから上がった感想
- チームでやったことについて
- 一人で読んでいたら理解できないこともあったので、輪読会で感想を言い合う・分からないことを聞けたのは良かった
- 考えの共有ができるのが良い
- チームでの開発のやり方はこれで良いんだっけと気付けるきっかけになった
- 逆に「このやり方で良かったんだ」と嬉しくなる部分もあった
- 期間について
- 年内というちょうどよい区切りもありハイペースだったが短期集中って感じで良かった
- とはいえあくまで短期、このペースずっとは負荷が高いので時と場合を選びそう
- 読書苦手寄りの人なので「本って2週間で読み終わるもんなんだ」と思った(達成感あり)
- 当初の期待通り、チームの動き方の元になっている部分を、1月から本格始動する前に吸収できてよかった
- 年内というちょうどよい区切りもありハイペースだったが短期集中って感じで良かった
- 記事について
- 感想をふくらませるのむずかしい。普段使っていない頭を使う。
- 感想をパッケージ化する作業は負荷があって頑張らなきゃ要素ではあったが、文章書くトレーニングになった
大目的「プロダクトに向き合う上での"チーム"で共通認識を築きたい」
小目的「隙間時間(?)の12月にチームの結束力を底上げしたい」
あすみ目的「アウトプットをめっちゃしてもらう、慣れてもらう」
当初のこの辺の目的たちは...かなり達成できたように思えます!👌
「やるぜ!」ってなったらぐわしっ!って気合い入って走り抜けることができるこのチームが好きです!
どんどんプロダクト良くしていきっ!
NE株式会社のエンジニアを中心に更新していくPublicationです。 NEでは、「コマースに熱狂を。」をパーパスに掲げ、ECやその周辺領域の事業に取り組んでいます。 Homepage: ne-inc.jp/
Discussion