kamatimaru’s 勉強日記

技術トピック専用のブログです。自分用のメモ書きの投稿が多いです。あくまで「勉強日記」なので記事の内容は鵜呑みにしないでください。

『ユーザーストーリーマッピング』の感想 (0章〜4章)

『ユーザーストーリーマッピング』を読んでいるので感想を書いていく。

www.amazon.co.jp

目的

見積もり・計画づくりについて勉強する。

→ 見積もり・計画づくりについて勉強したいと思い、本棚を見たところ、以下の2冊が積読になっていた。

www.amazon.co.jp

2冊の中身を流し読みしたところ、『ユーザーストーリーマッピング』の方が以下の理由から取っ付きやすそうだった。

  • 字が大きい。
  • 文体が軽い感じで読みやすそう。
  • 間に写真やコラムが入っている。
  • 本書の大元のテーマは「ストーリーマッピング」というアジャイルの技法についてであり、今回勉強したい「見積もり・計画づくり」以外の内容も結構書かれているので、今回はそこは流し読みすればよい。

従って、『ユーザーストーリーマッピング』の方から読むことにした。

感想(章ごと)

・0章 まず最初に読んでください

「アウトプット」より「成果(outcome)」が大事

「アウトプット」・「成果(outcome)」という2つの言葉は本書では以下のように定義されている。

・アウトプット : アイデアとデリバリーの間の全て
・成果(outcome) : アウトプットの後に結果として現れるもの
p11

アウトプットについては、「アイデアとデリバリーの間の全て」というやや凝った定義が使われているが、プロダクトそのものくらいに理解しておけばよいのかなと思っている。

最初に読んだときは、この2つの言葉は違いが分かりにくかったが、例えば以下のような2つの例を考えてみると、この2つが別の概念であり、両立しない場合があることが分かる。

①「スケジュール通りに要件を満たしたシステムをリリースできたが、新しいシステムがユーザーに使われず、半年でサービス廃止した」という場合。
→「アウトプット」は良かったが「成果(outcome)」はよくなかったということになる。

②スケジュールが遅延してしまい、システムの機能を当初の予定からいくつか削ることになったが、リリースしたシステムがユーザーに使われており、サービスの伸びも順調であるという場合。
→ 「アウトプット」は計画通りにはいかなかったが、「成果(outcome)」は良かったということになる。

そして、本書では、本当に重要なのは「成果(outcome)」の方であると主張している。

結局のところ、あなたがしなければならないのは、アウトプットを最小限に抑え最大限の成果とインパクトを獲得することだ。
p14

「アウトプット」と「成果(outcome)」という概念は、後の章で、「作るもの」の優先順位を決める際に重要になってくる。

・より少なく作る。

いつも私たちが持っている時間とリソース以上に、作るべきものが存在する。
p14

この言葉は本書の中に繰り返し登場する。
これは、多くのソフトウェアエンジニアが感じることだろう。

この問題に対する本書の回答は「より少なく作る」ことである。

ソフトウェア開発でよく見られる勘違いのひとつは、より多くのアウトプットをより早く得ようと努力することだ。(中略)しかし、ゲームを正しく理解すれば、あなたがすべきことはより多く作ることではないと気づくだろう。答えはより少なく作ることだ。
p14

どうやって少なくするかという手法については後の章に書かれている。

1章 全体像

概要

1章ではゲイリーというミュージシャン且つビジネスマンの方のソフトウェア開発を著者がサポートした事例を元に、ストーリーマッピングのやり方について説明している。

まずは全体像を把握する。

ストーリーマッピングの初期段階では、全体像を掴もうとするべきであり、細部に立ち入るべきではないと、本書には書かれている。

私はエンジニアということもあり、どうやったらこの機能を実現できるかなどと考えていると、つい技術的な細部について考えてしまうが、まずは深掘りせずに全体像を把握するべきなんだなと思った。

本書の中でも、ゲイリーが「フライヤーを作成する」というストーリーに関して、つい熱が入って詳細を語り始めたときに、著者が「細部はあとでやりましょう」とまずはストーリーの全体像を把握することを優先するように促すシーンがある。

全体像をつかもうとしているときには、細部をすべて書き留める前に、ストーリーを最後まで進めることが大切だ。
p32

ストーリーを詳細に分割する。

ユーザーストーリーを詳細に分割した結果の個々の行動のことを、本書では「ステップ」と呼んでいる。
本書では「チラシをカスタマイズする」というようストーリーを、ステップを精査して詳細に分割した例を説明している。

「チラシをカスタマイズする」のようなストーリーのステップを精査すると、次のような詳細部分が明らかになる。


・画像をアップロードする
・音声ファイルを添付する
・動画を埋め込む
・テキストを追加する
・レイアウトを変更する
・以前に使用したプロモーションを再利用して作業を始める


これら細部のステップでも、実際にソフトウェアの形にするためにはもっと議論を重ねる必要があることがわかるだろう。しかし、これで少なくとも全ての細部に名前を与え始めることはできた。
p35

ここで、「実際にソフトウェアの形にするためにはもっと議論を重ねる必要がある」とただし書きをつけているのが重要だと思った。

これはあくまでユーザー視点でのステップであって、これをこのままソフトウェアの要件としてしまうと、性能要件やセキュリティ要件が完全に漏れてしまうし、機能要件としても十分ではない。

実際にソフトウェアを作り始めるためには、例えば以下のような要件を定義しておく必要がある。

  • 画像をアップロードする
    • ドラッグ&ドロップでアップロードできるようにするか?
    • 一度にアップロードできるファイル数はいくつか?
    • 許可するファイル形式は何するか?

これは、顧客との共通理解を深めるための手法であり、ソフトウェア自体の要件とは異なるものである(もちろん重なる部分も多々ある)ということは念頭においておきたい。

実現可能性のあるところまで製品のアイデアを縮小する

ゲーリーと著者がバンドマネージャーのユーザーストーリーについて話終わったあと、著者は、いったんここまでに挙げた機能でプロダクトにすることを提案する。

イデアは出そうと思えばどんどん出てくるが、それを実現しようとするとたくさんのリソースが必要になってしまうので、むしろ実現可能なところまでアイデアを縮小することの方が重要ということなのだろう。

彼はまず、実現可能性があるところまで製品のアイデアを縮小するために一生懸命取り組む必要があった。
p37

2章 作るものを減らすためのプラン

概要

2章では「Globo.com」というブラジル最大のメディア企業での開発を著者がサポートした事例についてである。

「Globo.com」での開発において、デッドラインは絶対に動かすことはできないものとして存在する。なぜなら、デッドラインは「ワールドカップ」だったり「オリンピック」だったりするからだ。ソフトウェア開発が間に合わないからといって「ワールドカップ」や「オリンピック」の日程を後ろ倒すことはもちろんできない。

このように、デッドラインが絶対的な状況かつ、作りたい物を全部作ろうとしたら期限に間に合わないという場合に、いかにして作るものを減らすかということについて、この章では書かれている。

システムの外側で起きて欲しいことを考えると、優先すべきことが分かる。

Globoのチームはストーリーマッピングを実施したところ、すべてのことを実現するためには、1年以上かかるということが判明し、困っていた。このときに著者は

「ブラジル総選挙までにこれを全部動かす必要がありますか?」
p50

とGloboのチームに問いかけている。
結果的にGloboのチームはブラジル総選挙における成果を最優先して、ニュースサイトに全力を注ぐことに決めた。

このように、何を優先すべきかわからなくなったら、システムの外側に目を向けようということが本書には書かれている。

システム内部の機能を決めるためには、まずシステムの外側で起きて欲しいことを考えよ。
p50

システムの外側 = 「ビジネス上の/社会的な制約」と理解した。

初めてやることにかかる時間の推計は甘くなる

マップに載せたすべてのことを実現するためには、1年以上かかるというのである。そして、読者はすでにお気づきのように、開発者が何かを完成させるために1年かかると言うときには、実際には2年かかるのだ。それは、彼らが無能だからではなく、カレンダーがないからでもない。今までしたことがないことをするためにかかる時間の推計は、甘くなってしまうだけだ。なにしろ私たち人間は、もともと楽観的な動物である。
p49

これもソフトウェアエンジニアであれば心あたりがある人が多いのではないかと思う。

「初めてやること」=「どんなリスクが存在するか見通しが立ちにくい状態」であり、事前に考慮できるリスクに限界があるので、見積もりが甘くなってしまうのは当然だと思う。(開発に着手してから想定していなかったリスクに直面する。)

また、この場合は、GloboのCEOが数ヶ月後には成果を見たがる性格の人であると書かれていることから、「デリバリーまで1年かかるというだけでも大ごとなのに、まさかそれ以上かかるとは言えない」という心理が働き、無意識のうちに楽観的な見積もりの方を口にしてしまっているのではないかとも思った。

喜ばせる人=成果に優先順位をつける。

Globoは、ブラジル最大のメディア企業であり、多種多様なコンテンツを扱っている。
従って、「ブラジル総選挙に的を絞る」ということは、選挙に関心のあるユーザーを喜ばせることにリソースを割く代わりに、例えばテレビドラマやスポーツに関心のあるユーザーを喜ばせることを後回しにしているということになる。

このように、すべてのユーザーを一度に喜ばせることはできないのだから、喜ばせる人=成果に優先順位を付けようということが本書には書かれている。

Globoは、近く行われるブラジル総選挙に的を絞ることによって、ニュース、とりわけ選挙についての最新の詳細情報を探している人々のために重点的にサービスを強化している。しかし、それらの人々へのサービスを強化する代償として、テレビドラマが好きな人、スポーツが好きな人、その他さまざまなタイプのユーザーへのサービスは放置される。(省略)一度にすべての人々を喜ばせることはできないことを覚えておこう。
p53

3章 より早く学ぶためプラン

この章は「見積もり・計画づくり」に直接関わる内容ではなかったので、今回は割愛する。

4章 時間どおりに終わらせるためのプラン

概要

4章では、Workivaという大きなSaaS企業で働くアーロンとマイクのプロダクト開発の進め方を参照しながら、開発戦略のあり方について説明している。

見積もる対象を本当に理解する。

「4.2 良い見積もりのための秘訣」という項目の中に、以下の言葉が出てくる。

最良の見積もりは、自分が何を見積もっているのかを本当に理解している開発者から出てくる。
p78

そもそもの前提として見積もりは難しいが、見積もっている対象を理解することなしに見積もろうとしても、的外れな見積もりになってしまうというのはその通りだと思った。

最初に機能を最後まで作る。

最初にとりあえず機能を最後まで作るべきであるということが本書には書かれている。

第一のスライスは、機能の最後まで道をつなげる。ここに含まれている部品を全部組み立てれば、最初から最後まで機能が動くところを見られる。しかし、必要とされるすべての状況で動くわけではないので、ユーザーに出荷すれば、受け取ったユーザーはかんかんになって怒るだろう。

ここで書かれているのは、とりあえず正常系が動く状態に持っていくことを最優先するという意味だと理解した。そうすると、例えば以下のような処理の実装は後回しでよいということになる。

  • エラー処理
  • 異常系
  • 課金ユーザー限定の機能

など

このように、とりあえず正常系が動く状態に持っていくことを最優先することで得られるメリットは「作業の足を引っ張る予想外の難問」を見つけられることであると本書には書かれている。「作業の足を引っ張る予想外の難問」の具体例は本書には書かれていないが、例えば以下のような事などだろうか。

  • 使おうとしていたフレームワークでは実現したい機能を実装できないことに気づく。
  • 使おうとしていたAPIが想定と違うものだったことに気づく。
  • 他の部署と調整が必要な機能があることに気づくことに気づく。

確かに、経験上も実際に作り始めて見ないと気づかないリスクというのはけっこうな確率で存在すると思う。

それゆえ、この「第一のスライス」のことを「歩くスケルトン」とか「スチールスレッド」とか「曳光弾」とか呼んだりするらしい。

「正確な見積もり」という言葉は矛盾している。

開発にどれくらいかかるかを正確に知ることができるなら、決して見積もり(estimate)とは言わないはずではないか。
p81

見積もりよりも測定

これは他のアジャイル開発の本でもよく目にする言葉だと思う。

「測定」 とは「 過去のソフトウェア開発においてどれくらい時間がかかったか」であり、こちらの方が見積もりと比べるとはるかに正確である。
頻繁に測定すればするほど見積もりが上手くなる。

例えば、本書には通勤時間の例が出てくる。毎日通勤していると、自然と通勤にどれくらいの時間がかかるか予測できるようになっているはずである。これは、通勤の際に、意識的か無意識かを問わず、かかる時間を測定しているからである。

従って、測定の機会を増やすという意味でも大きなタスクをスライスすることが重要であると本書には書かれている。

見積もりを「予算」として管理する

彼らは初期の見積もりを予算として扱い、こまめに見積もりを管理している。
何かを少し作るたびに、チームはその部分を作るためにどれだけの時間がかかったかを測定できる。作ったものは、予算に対する支出として扱うことができる。
p81-82

「Time is money」の意識を持つということだろうか。

リスクの高いものから早く取り組む

本章では、リスクの高いものから早く取り組むべきであるということを最も強調している。

彼らは開発戦略をスライスする際に、予算を吹き飛ばしかねない要因に、なるべく早い段階で取り組むよう試みた。リスクの高いものから早く取り組んだのだ。
p82

彼と彼のチームは、リスクの高い部分、すなわち、動くところを少しでも早く確認したい部分を先に手がけ、顧客に見せる前に軌道修正できるようにしたのである。
p90

これは経験上よく理解できた。リスクが高いものを後回しにしてしまうと、リスクが悪い方に出たときのインパクトが大きくなってしまう。意識していないと、ついリスクが低いタスクから着手してしまいがちなので(心理的障壁が小さい)、意識的にならないといけないと思う。

分割するのではなくイテレーティブに開発する。

この項ではモナリザの例が出てくる。仮に期限が5日間で、ダビンチがモナリザを描いたとして、絵を5個の部分に分割して、部分ごとに順番に絵を描いていくということをしただろうか?もちろん違うだろう。

恐らく、まずは全体の下書きをして、徐々に構図や色の変更をしていくという手法をとったはずである。

ソフトウェアも開発も同じで、まずは「製品が最初から最後まで動くことを確かめるために必要な部分」だけを作った上で、イテレーティブに磨いていくべきであると本書には書かれている。

ここまで読んだ感想

見積もり・計画づくりの具体的な手法について書かれているわけではないが、大きな考え方という点ではとても勉強になった。

全体として、ソフトウェアエンジニア側もサービスに対して発言権を持っているということが前提で書かれていると思った。

サービスに近いところで裁量を持って開発する際には、本書の内容で参考にできるところがたくさんある一方で、サービスの判断をする側と開発する側が分離している環境では、参考にできる部分は限られるかなと思った。

www.amazon.co.jp