読者です 読者をやめる 読者になる 読者になる

キノコの自省録

テクノロジーとコンテンツの融合を目指して

ユーザーストーリーマッピング - Jeff Patton

今年読んだ本の紹介その2。
ユーザーストーリーマッピング - Jeff Patton
https://www.amazon.co.jp/dp/4873117321
素晴らしい本です。超おすすめしておきます。


これは、アジャイル開発手法である、”スクラム”の最初に行う「ユーザストーリー(マッピング)」の解説です。
スクラムのわずか1プロセスについて、なんと1冊の本にしたということです。


基本哲学 - 完璧なドキュメント(要件定義など)は存在しない

0章ではっきり書いています。かなり痛快に。
ソフトウェア開発に携わったことがある人なら、要求とか要件とかという名の妖怪について、みんな一言あるでしょう。
要件定義書というのは、作るべきものが書いてあるものの、本当に作るべきものが十分書かれてはいません。
しかし、間違えたものを作ったら、誰かのせいになります。
それは仕様屋さんだったり、今までの慣習を知らないプログラマーだったり。


語りえぬものについては、沈黙しなければならない

そもそも論として、必要なもの全てが言語化できるわけではありません。
「可愛いキャラクター」がなぜ可愛いか、を言葉で説明できないように、言語化には限界があります
言外の意味に重要なファクターが多分に含まれることは、なんとなくイメージつくと思います。
しかし、言語化したときに、ごっそり抜け落ちます。
論理の外にあるものは、言語化できません。

※この辺りはamazon:リファクタリング ウェットウェアを読むと良いでしょう。


非言語要素をドキュメントで書き表せないのであれば、別の方法を取る必要があります。
それは、「共通理解を作る」ことです。
共通理解=共有ドキュメントではありません。
共通理解とは、関係者みんなが頭の中に思い描く完成図です。


では、共通理解とは、どのように構築すればよいのでしょうか?
その手法の一つが、本書のタイトルである「ユーザーストーリーマッピング」です。


本書のカバー範囲

ユーザーストーリーとは、簡単に言うと、
「プロダクトが描き出すストーリーを語ること」です。
ユーザーストーリーマッピングとは、
「ユーザーストーリーをポストイットでマップ化すること」です。
どんどん会話して、一緒にストーリーマップを作りましょう、というのがコンセプトです。
あくまでも主役はストーリーです。ポストイットマッピングのための補助ツールです。
ポストイットは言語化されたものなので、その段階で情報が落ちます。)
作られたマップは、プロダクトのバックログとして活用されます。


ストーリーを語れといっても、様々な切り口があったり、その成果物の使い方があったりします。
また、良いストーリーとは、という側面でも考えるべきところがあります。
このようなストーリーにかかわる諸々が、300ページの本の中身となっています。
僅かアジャイル開発の前段階の1プロセスで300ページです。
ちなみに、「スクラム実践入門」という本では、
関連しそうなページを足しても、ユーザーストーリーについての説明は5ページくらいです。


逆に、ユーザーストーリーマッピングにはポストイットを使用しますが、
それ以外の点については、betterは説明していますが、mustにはしていないような印象を受けます。
(極端な悪手にはNoを出していますが)
メソッドにとらわれるより、ストーリーを語りましょう。


最後に

感銘を受けた言葉を。

私はスコープ(仕事の範囲)がクリープ(知らない間にふくらむ)することはないと思っている。単に理解が進んだだけだ。

その通りだと思います。