2015.09.02

「ユーザーストーリーマッピング」を読んで

Pocket

user_story_mapping
こんにちは。次世代システム研究室の A.F. です。

以前、リーンスタートアップ導入への取り組みで紹介しましたが、次世代システム研究室では新規開発をする際に”ユーザーストーリーマッピング“という手法を使っています。
先日、その手法の作者であるジェフ・パットン氏自らが書き下ろした書籍、「ユーザーストーリーマッピング」の翻訳版が発売されました。
著者のジェフ・パットン氏は私が受講した認定スクラムプロダクトオーナー(CSPO)研修の講師であり、また監訳者の川口氏には日頃から大変お世話になっていたこともあって、発売日に即購入したのですが、この書籍の内容があまりに良かったのでご紹介したいと思います。

※認定スクラムプロダクトオーナー(CSPO)研修については以下のスライドにまとめてます。
著者は冒頭で以下のように書いてます。

実際、この本を読んでたった2つのことが読者のなかに残りさえすれば、私は満足だ。そして、その2つはこの章のここに書いてある。
・ストーリーを使う目的は、良いストーリーを書くことではない
・製品開発の目標は、製品を作ることではない

この2つのことの意味が分かりますでしょうか。

1点目(ストーリーを使う目的は、良いストーリーを書くことではない)については、「ストーリー」を「ドキュメント」に書き換えてみても良いかもしれません。
未だに長時間かけて「良いドキュメント」を書くことが常に正しいと考えるエンジニアがいますが、そういった方々は今一度ドキュメントを書く目的について考えなおしてほしいです。
「ドキュメントを書く」ということは、一つの手段であって目的では無いはずです。
では「ドキュメントを書く」目的は何でしょうか。当たり前ですが「情報を伝える」ということです。
「情報を伝える」ための手段は数多くあり、その手段として「ドキュメントを書く」ことが最善策だと考えた場合はもちろん書くべきですが、目的が「ドキュメントを書く」ことになっちゃってる人がいたら、今すぐ考えを改めるべきです。
この書籍にも、以下の記述があります。

従来の開発プロセスでは、要件を知っている人の目標は、それを正しく書き出すことであり、ソフトウェアを開発する人の目標は、それを正しく理解することだった。

今でも当たり前に行われているプロセスだと感じてます。
より細かいドキュメントを書く人が誉めたたえられ、質問するとドキュメント読んでくださいとドヤ顔で言われるような現場が生産的な現場だとはどうしても思えません。
一生懸命書いたんだから読んでほしいという気持ちも分かりますが、いかに非効率なことに時間を費やしてるか気付いてほしいと切に願ってます。

話しを「ストーリー」に戻します。
「ストーリー」を書く目的も「ドキュメント」と同様、「良いストーリーを書くこと」ではありません。
著者の答えを以下に記します。

・ストーリーは、要件を形式に落とし込むためのものではない。言葉と絵を使いながらストーリーを話すのは、共通理解を築くためのメカニズムだ。
・ストーリーは要件ではない。会社、顧客、ユーザーが抱える問題の解決についての議論であり、何を作るかについての意見を一致に導くものだ。

著者の考えをもっと詳しく知りたいと考えた人はぜひこの本を買って読んでみてください。本当にオススメの本です。

私が考えた「ストーリー」を書く目的は、より良い会話を交わすことでした。
プランニングやふりかえりが形骸化してきてしまい、その結果プラクティスの実施や成果物を出すこと自体が目的になってしまった経験が多々あります。
ユーザーストーリーもストーリーマッピングも会話のきっかけに過ぎず、ユーザーストーリーを書いたり、ストーリーマッピングを実施すること自体が重要なわけではないという事を再認識することができました。

2点目(製品開発の目標は、製品を作ることではない)についてはどうでしょうか。「何を言っているんだ?意味が分からない!」と思う人もいるかもしれません。
私自身も、作るものは決まった、さてどうやって作ろうか、というような段階からプロジェクトに参画することが多かったため、プロとしていかに正しく作るかだけを考え、学び、実践していた時期がありました。そして無事にリリースしたらそこで乾杯!完全に「製品を作ること」が目的になってしまってました。
このような進め方で、開発した製品開発自体が成功することは滅多にありません。
自分が開発した製品の売上が目標に対して未達な状況を見ても、まるで他人事のように、こっちはプロとしてちゃんと作ったんだから、企画側もプロとしてしっかりしてくれよなんて思ってました。本当に馬鹿でした…。
この本にも以下のような記述があります。

「優れたチームは、重要な顧客のことで悩む。ダメなチームは、競合他社のことで悩む。」
「優れたチームは、ビジネスKPIに大きなインパクトを与えられたときに祝杯をあげる。ダメなチームは、何かをリリースできたときに祝杯をあげる。」

まさにダメなチーム!

要件を理解することだけを考えればよかった古きよき時代に戻りたくなるかもしれない。あなたの仕事が本当に問題を解決することではなかった時代、指示されたものを作っていればよく、それを作るのが正しいことだと確認するのは他の誰かの仕事だった時代だ。
しかし、あなた、そしてほとんどの人々は、問題を解決することが好きだと私は信じている。だから、今はあなたにとってチャンスなのだ。

ある意味前者の時代の方が楽でしょうし、楽な働き方をしたいという考えを否定するつもりもありません。
しかしながら、後者の時代の方が圧倒的に楽しいだろうし、そういった人達に囲まれて働けたらどんなに幸せだろうなと考えています。

2点目についての著者の答えを以下に記します。

・あなたがしなければならないことは、より早くより多くのソフトウェアを作ることではない。作ると決めたものから最大限の成果とインパクトを生み出すことだ。

アウトプットを最小限に抑え、最大限の成果とインパクトを獲得しよう。

私がジェフ・パットン氏のCSPO研修で一番印象に残ってる言葉がこれでした。
なぜアウトプットを最小限に抑えるべきなのか、成果とインパクトとは何なのかなどをもっと詳しく知りたい人は、ぜひこの本を読むかCSPO研修を受講してみてください。どちらも本当にオススメです。

また以下の記述もありました。

このクライアントは典型的なアジャイルプロセスを使ってきており、非常に良い実践をしていた。「良い」というのは、定期的に品質の高いデリバリーをしているという意味だ。しかし、そのクライアントは、早くゴミをデリバリーすればするほど、多くのゴミが溜まっていくことを学んだ。

私自身もある時から、正しくないものをいくら正しく作っても意味が無い!と考え、どうやって作るかよりも何を作るのかにより興味を持つようになりました。
この本にも何を作るのかについて、リーン・スタートアップやデザイン思考についての考え方が書かれており、そういった意味でも大変勉強になります。

もう一点、この書籍を通して感じたことは、認定スクラムトレーナーである著者自らが、スクラムをそのまま実践することにかなり懐疑的だということでした。
そのような記述をいくつかピックアップします。

すべてのストーリーを書き、ストーリーについてのすべての会話に参加する、ひとりのプロダクトオーナーを設けても破綻する。

よく見かける悪質なアンチパターンにひっかからないように。チームに属する人間なら誰もがストーリーを拾い上げ、そのための仕事をする可能性があるので、チームに属する全員をすべての会話に参加させるべきだと考える人がいるのだ。おそらく、あなたの働く会社もそうだろう。
そこで、意思決定は少人数のグループで行い、それ以外の人々には別に会話をする機会を設けて、決定を共有するようにするといい。

拷問のようなスプリントプランニングは問題になる。多くのチームは賢明にもミーティングよりも前の別の日に、ストーリーの議論をするようになった。
しかし、実際に起きたことは、プランニングミーティング中の拷問が単純に別の日に移っただけであることが多い。
会話に参加するかどうかについて、チームメンバーにオプトインを認めよう。

これらを読んで、素直に納得することができませんでした。
同じような感覚を、「スクラム実践入門」の以下の記述を読んだ時も感じた覚えがあります。

スクラムの奴隷

スクラムマスターがスクラムを実践している目的を忘れ、スクラムを実践することそのものが目的化してしまうことがあります。スクラムコミュニティの界隈では、スクラムを扱う主人(マスター)であるべきスクラムマスターがスクラムに使われている奴隷(スレーブ)のような状態になっていることから、「スクラムの奴隷」(スクラムスレーブ)と揶揄されることもあります。スクラムマスターの次のような発言が増えてきたら、スクラムの奴隷になりつつある兆候と判断してもよいでしょう。
・○○をしたらスクラムではなくなってしまうのでダメだ
・スクラム的には○○であるべきだ

少しスクラムのプラクティスを実践しただけで、その背景や原則を理解しないまま「私達スクラムやってます!」と言うようになり、スクラムのルールをなし崩し的に変えていく事により本来のスクラムの効果を十分に出せていないような現場をいくつか見てきた経験から「守破離」の考えを強く意識するようになり、まずはスクラムガイドに書いてある通り一切改変すること無く実施すべき(守)だと考え、そのように主張してきました。
ジェフ・パットン氏や、スクラム実践入門の著者の方が言っているのは、守破離でいう破のフェーズ(もしくは、守のフェーズを経なくても本質を理解できる人向け)のことで、その段階に至っていない人達がこれらを読むことにより、現場を改善する努力をせずに単に楽な方に変えちゃって良いんだと思ってしまうことを危惧していたからです。

※守破離については以下のスライドにまとめてます

しかしながら、今回この書籍を読んで、少し考えを変えました。

スクラムを使う目的は、正しいスクラムを実践することではない。

まさにこれだなと。
スクラムを使う目的とはなんでしょうか。
スクラムガイドのスクラムの定義には、以下のように記述されてます。

スクラム(名詞):複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り
価値の高いプロダクトを生産的かつ創造的に届けるためのものである。

変化の激しい今の時代において可能な限り価値の高いプロダクトを構築するための手段(方法論)はいくつかあると思います。
その中でもスクラムを実践することが最善の手段だと考えた場合はスクラムを実践するべきであり、スクラムガイドに

スクラムの役割・作成物・イベント・ルールは不変である。スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。すべてをまとめたものがスクラムであり、その他の技法・方法論・プラクティスのコンテナとして機能する。

と書かれている以上、ルールを厳守する必要があります。

可能な限り価値の高いプロダクトを生産的かつ創造的に届けるために正しいスクラムを実践する

書いてしまえば当たり前の事ですが、この考えを忘れずに取り組んでいきたいと考えております。

この書籍を読むことで、ここでは書ききれないほど多くのことについて考えさせられました。
その都度メモ代わりにFacebookに投稿していたので、最後にいくつかピックアップさせて頂きます。

「もし、全員が会議室テーブルを囲んで座り、担当者ひとりが全員の発言をストーリー管理システムに入力しているようなら、おそらくやり方を間違えている。」
会社でよく見る光景でやばい。

インクリメンタルな描き方のモナリザも、イテレーティブな描き方のモナリザもイメージはつくけど、イテレーティブにしてインクリメンタルなモナリザの描き方がイマイチ想像つかない。
イテレーティブな描き方したモナリザのまわりに絵が広がっていくようなイメージなんだろうか。

現在のストーリーマップ(現在マップ)≒ジャーニーマップだったか。何か新しい既存プロダクトに携わるときは、まずは現在マップを作るようにしてみる。

「ストーリーという名前は、どのように書くべきかではなく、どのように使われるかについて付けられた名前だ。」
POが事前にストーリーを書いてくるのはどうなんだろう。
一枚一枚マッピングしながら話し合い、抜けに気付いたらその場で追加するようなやり方なら有りかな。
一方で事前に書いてきたストーリーがバックログに既に積まれてて、不明点があったら聞いてくれみたいなやり方は無しだな。違う理解が生じる。

「壁を情報ラジエターと呼ぶなら、ツールは情報冷凍庫だ」
やっぱり Trello でやるふりかえりがイケてるとは思えない。
TryをTodoに落とし込んで満足し、次にそのボードを開くのは次回のふりかえりの時だったりするのは本当に意味が無い。
常に見えるところに貼っておき、最低でも1日1回、朝会の時に確認するようにしたい。

「私は、開発チームのメンバーがビジネスパーソン、プロダクトマネージャー、ユーザー、何か作って欲しいと頼んできた人々に、あなたのストーリーはストーリーじゃなくてエピックだと言ってる人を見かけたことがある。つまり、ストーリーを書いた人に何か問題がありそうなトーンで話されたのだ。言われた側は、開発チームのメンバーに闇討ちを食らわせてやりたいと思うだろう。」
何度も言った覚えが…。気をつける

「クライアント-ベンダーアンチパターン」
「私の頭のなかには、一方の端にはウェイター、もう一方の端には医者という言葉が置いてある連続体のイメージがある。あなたの仕事での関係を、良い医者と患者の関係に近づけ、ウェイターと客との関係から遠ざけるようにしよう。」
この例えはとても分かりやすい!
今の状況は、馴染みの店のウェイターと客の関係に近い気がする。仲は良いけど、真の課題解決に向けて協働できていない。
信頼で結ばれた医者と患者の関係を目指したい

「情報を集めても前進かボツかを判断できない場合には、オポチュニティバックログに戻して後で議論することもできる。これは「延期」と称するもので、私はたびたび行っている。」
ここまでいったら強制的にボツにしちゃっても良いのではないだろうか。
延期したものが後にやることになって、成果が上がるイメージがあまり持てない。

オポチュニティキャンバスのフローの1番目が「問題またはソリューション」なことについて、「理想を言えば、解決しようとしている明確な問題からスタートしたい。しかし、世界が理想的であることはまずない。私たちはよく、先に機能や機能拡張のアイデアを得てから、それが解決する問題に立ち返って理解しなければならなくなることがある。」とあるけど、本当にそれで良いんだろうか。
ソリューション有りきの機能で本当に顧客の問題を解決出来るんだろうか。
個人的にはソリューションドリブンの課題ディスカバリー、顧客ディスカバリーのような事はやらないようにしていきたい。

マンガによるストーリーマップいーなー。
やっぱり時代はマンガ駆動開発だな。画力が欲しい。

「機能の優先順位を考える前に、具体的なビジネスゴール、顧客、ユーザー、次いで彼らの目標の優先順位付けをしよう。」
機能追加の場合、
1.現在マップ(ナラティブ・ジャーニーマップ)作成
2.リーンキャンバス書く(具体的なビジネスゴール、顧客、ユーザー)
3.ユーザーストーリーマッピング実施
4. MVP(MVS)決める
って流れで進めるようにしたい。

「ソフトウェアを開発する人々とそれを必要とする人々の間の架け橋を築くために、ポストイットが貼られた大きな壁はきわめて重要である。開発者の側からいつ何が行われているのかをユーザーに知らせ、ユーザーが判断に積極的に参加するために、この壁が必要だったのである。」
ポストイットを壁に貼ろう貼ろう言ってる自分自身が本当の意味での効果をまだ体感できてないのかもしれない。
だから、うまくメンバーに自分の言葉で説明できてない。
そもそもそれを必要とする人々と同じ場所で働けてないから、壁に貼っとく意義も薄れちゃてる。

「バックログをクリーンにするために小さなストーリーを1つにまとめる」の中の「5.少なくとも最初は、静かにこの作業を始める。作業を遅らせるのはおしゃべりだとわかる。」にあるようなサイレントブレストをCSPOで学んだけど、この進め方はとても役に立ってる。

こうして振り返ってみると、一冊の書籍から数多くのことを学べているなと改めて感じました。
今後何度も読み返していくことになると思います。

次世代システム研究室では、アジャイル開発手法の導入を一緒に推進してくれる方を募集しています。アジャイル開発の経験者の方、経験は無いけれどぜひやってみたいという意欲のある方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ 募集職種一覧 からご応募をお願いいたします。

皆様からのたくさんのご応募、お待ちしてます!