ユーザーストーリーマッピング

ユーザーストーリーマッピング

読了した。

会社で、というかぼくのプロジェクトの進め方やヒアリングの仕方などに問題があって渡された感じ。

「課題図書じゃん！ｗ」って言ってたけど本当に課題がてんこ盛りって感じで学びがあった…。 俺はなにもわかってなかった…みたいな気持ちといままでどうやればいいのか取っ掛かりがなくて途方にくれていたけどこうすればいいのかーという気づきを得られた。

感想

属人性がはっきり分かれそうな本なのでおすすめしにくい。

ただいまの時点のぼくにはいろいろな手法や考え方、プロジェクトの進め方なんかを学ぶところが多くて割と良かった。 章立てのサイズがいい感じなので夜寝る前にちょっと読む…みたいな感じでもスラスラ読めていった。

ただ後半が少しなんというかいまいち得心がいかないというかスッキリしないものを感じていたので多分これは自分の中に違和感があったからだろうと思う。 そういう意味では前提となる知識や経験がまだ必要とする水準に達していないか、そもそもぼくにはその手法はあわない…みたいなところじゃないかと想像している。 半年後くらいに読み直したらスッキリしなかった部分が解消するかも？くらいに考えている。

目的:

今回、課題図書として渡されたと書いたんだけどもこの本を読むことで解決したい目的が大きく3つあったと考えている。

• ヒアリングすることの意図を理解すること
• 何故それをするのか？を考えること
• 大まかに全体像を把握すること

実際には渡した側はこれよりももっと大きくて多いことを期待していると思うのだが直近で自分自身でもうまくできていないなと感じたのが↑の3つだったことと本著でそれらを解決するための手法を紹介していてそれが絶妙にマッチしたので多分そういうことなんじゃないかなーと思ってる。

ヒアリングすることの意図を理解する

よく居酒屋などで話されることだが「ヒアリングするのは伝言ゲームじゃない」というやつ。

まさしくぼくはこの伝言ゲームをしてしまっていてどうすればいいのか少し困っていた。

プロジェクトに対する理解が深まれば自然と解消するだろうくらいに当初考えていたのだが、結局それでは駄目できちんとロジカルに解決していくためになにをどう考えていけばいいのか？という話しをここ1ヶ月2ヶ月よくしていたように思う。

ぼくらの会社はスタートアップなので当然人の数が限られている。 なので、「この機能がほしい」「あの機能をこうしてほしい」と言われてもすぐに対応できない、というかどうしてもやらないといけないものがいっぱいある状態だった。

そこでぼくがヒアリングすることで「この機能を追加実装しなくてもここをこうすれば代用できますよ」とか「この機能は本当に使うんですか？それはどれくらい使うのですか？」みたいなことを確認したり、提案することを期待されていたと思う。 思うというか間違いなくされていたわけだがうまくこの期待ぼくは応えることができなかった。

期待されていることがわかっているのに自分がうまく応えられていないというのが歯痒く、正直この時期はちょっとつらかった。

• これはぼくがいままでこういったことに不慣れだったこと。
• そういうのを専門で行ってくれるレイヤー、営業職とかプランナーとかが存在していたのでその人達に多くの部分をおまかせしていたこと。
• そのような経緯があった上での経験値が低かったこと。

そしてあまりそういうのが得意でなかったためこれらの学習を避けていたという問題がある。

本を読んだだけで改善するわけではないが意識することで少しだけ良くなったように思う。 もちろん、聞き手側が配慮してくれた面がかなりあるのは間違いないｗ

ただ少しマシにはなったかなと自分でも思っているので読んだ甲斐はあったのかなという気持ちがある。

何故それをするのか？を考えること

ヒアリングとかぶる要素があるんだけどもやはり機能というのは追加するのは簡単だけど一度追加してしまうと削除するのはその3倍以上苦労する。 まして人数がいない状態で「言われたから作りますね！」ということをしてしまうと際限なくタスクが増えてしまい、毎日徹夜しても終わらなくなってしまう。

なのでここの部分は上司にすごく指摘された。 本著でもこの点はしつこいくらいに書かれていて、ことあるごとにこれは何故やるのだろう？という問いかけがなされていた。

いわゆるMVPという考えなんだけども、どうやらぼくは少し思い違いをしていたことを理解した。

この例えは本著内でもされていたのだがいままでのぼくは「早く走るものを作って欲しい」と要望を受けたとき、まず最初に車を作ろうと考える。 そして車を作るためにはタイヤが必要でハンドルが必要だからブレーキとアクセルも必要で……etcetcと実装してきたわけだ。 そしてこの車が走るために必要なパーツこそがMVPだと思っていた。

ところがどうやら本著を読む限りにおいてそうではなかったということに気づく。 ここではいきなり車を作るのではなくまずは三輪車を作る、当然クライアントは怒るが次は自転車を作る、バイクを作る…ここまで来たらクライアントは少しだけ機嫌を直す。 そして、ここから車を作り始めるというのだ。

この話しのキモは「早く走るもの」という要望を受けたときにまずそれを満たすものこそが作るべきもので、それをいきなり完成図引いてバーン！と開発してしまうとアルファ版としてリリースするときに最初から車を作ろうとしてしまうとタイヤだけが存在するなんだかよくわからないものをリリースしなくてはいけないことになる(イメージの話ね！)

ところが三輪車であれば少なくとも前に進むなにかを作っていることになる、自転車でもそうだ。 期待値には達していないが少なくとも進む方向性があっているかどうか？という確認ができる。

ところが車を最初から作ってしまうと完成したときに「…実は水陸両用車がほしかったんだよね。ごめんね、だから作り直して？」という話しになってしまい大変時間を損してしまう…。

だからこそ最初に作るべきは三輪車であり、これこそがMVPだ！と書かれているのを読んで「なるほど、確かに思い当たるフシがある」と納得した。

つまりぼく、もしくはぼくたちは本当に作らないといけないものの自分たちで思う以上に姿が見えていなかったということだと気づいた。 そうするとつまり「何故それをするのか？」という問いが非常に重要になってくる。

クライアントは作りたいものの存在を理解していない。 そして開発者は作るべきものの形をそれが完成するまで理解できない。

だからこそ、何故それをするのか？という問いを作る前、同僚などからヒアリングするときに行えなくてはいけないのだ。

それが本著で得られた最大の気付きだったんじゃないかと思う。

まだまだできているとは言えないがほんの少しだけマシになったかなと思うところがある。

取っ掛かりは得たのでこのことを忘れずに自然と行えるようになるのがベター、忘れてそうだと思ったらもう一度本著を読んで思い出せばいいかなと楽観的な気持ちになれた。

大まかに全体像を把握すること

これは簡単だ。 そもそも大まかにでも全体像が把握できないとスケジュールが立てられないし、そもそも設計もできない。 全体像がわからなければ、影響範囲もわからない…それぞれが各々「ここが影響範囲だ！」と考えるものが影響範囲になってしまう。これは設計もスケジュールも同じ。

もし把握せずに設計をしたらどうなるか？ 多くの考慮漏れ、不可逆的な変更をしてしまった箇所に対して変更が発生する可能性が高くなるだろうと思われる。

また考慮漏れ自体をなくすことは不可能だがそれが起こったときの影響範囲がわからない、という問題がある。 そして当然これらのタスクを網羅するスケジュールの期限はわからない…ということになってしまう。

そしてぼくはこれらの設計のミス、スケジュールのミス、影響範囲のミスの全てを行ってしまった。

なので「わからない状態で走り出さない」というごく当たり前のことをユーザーストーリーマッピングという手法を介して教えてもらったと思っている。

まとめ:

今回、正直なところ渡された当初はそれほど乗り気でなかったのだが読み始めてみるとなかなかに考えさせられ、反省させられるところが多かった。 特にこのユーザーストーリーマッピングの手法はぼくにあっているように感じたのも大きな点だと思う。 ぼくは優秀な人間ではないので頭の中でこれらのマップを描けない。

そこが優秀な人とぼくとの違いだと思っていたのだが、実はそうではなく脳内で描けないなら付箋紙に書き出して張り出せばいいのだという実に簡単な話だった。

今回本著を読んだことでいままで「なんとなくうまくいかない」と思っていたプロジェクトの進め方のどこに問題があったのか、どのようにアプローチすれば解決に迎えるのか？というのが知れたのは非常によい読書体験だったと思う。

読んだだけでは意味がないが今回は直近の失敗体験と本著内での失敗談が自分に重なるところが多かったのでアプローチの方向性も類似していたのかなと思う。

冒頭で書いたとおりこれらのことが当たり前にできる人は当然世の中にいっぱいいて、その人達には刺さらない本だと思う。 ただぼくは前述している通りさまざまな問題を抱えて、どう解決すればいいのかわからず混乱していたので非常によいガイドブックになったと思っている。

上司がなにを伝えたかったのか、どういうことを行いたいと考えていたのか？を追体験することができて上司に対する理解度が少し深まったし、今後どうしていきたいのか？という考えに対しても理解が深まったのではないかなと思う。

もしぼくと同じような悩みを抱えている人がいれば一度読んでみるともしかすると解決の糸口くらいにはなるかもしれない。

こんなこともやってなかったのかよ！とこのエントリだけを読んだ人は思うかもしれない。

そう、そんなこともやってなかったし、やれていると思っていたことが実は全然やり方を間違えていたのだということを知れたので一度手にとって眺めるくらいはしても良いのではないかと思う。 その上で「こんなの当たり前じゃん！こいつバカじゃねーの？」という方はそのまま閉じていただき、「あー似たようなことしてるぞ？」という人は購入して読んでみるともしかすると苦労しているところが一気に楽になるかもしれない。