『ユーザーエクスペリエンスのためのストーリーテリング』を使った効果的な伝え方

感想おまちしてます!

ユーザエクスペリエンスのためのストーリーテリング

UXTOKYOさんから献本いただいた『ユーザーエクスペリエンスのためのストーリーテリング』を読了しました。

UXといわれると「デザインの話かな?」と思うところがありますが、この本を呼んでみるとプログラマでもマネージャでも、もしかするとソフトウェア開発に関係ない人でも「相手に考えや思いを伝える」という基本的なスキルを再考できる気がします。

スポンサーリンク

要件、要求、ニーズ、ウォンツっていうのは簡単ですけど

UXというとアジャイルと同じくモヤっとしてしまいますが、エンジニアとして働いていると、頭の中にあるアイデアや考えを、言葉やソフトウェアに変換する機会はきっと多いはずです。

task0-1

現在作成中の「ソフトウェア開発でありがちなタスクマネジメント勉強会」資料

上の図は「ソフトウェア開発でありがちなタスクマネジメント」という作りかけの資料です。若者向けの勉強会で使おうかなと思ってまして、タスクを管理する方法だけでなく、要望をタスクに変換する過程についてまとめているんですが、こうやってみると開発の中でタスク発生や分割は頻繁にあるため、定義や分割に苦労することが多く、伝言ゲームみたいに徐々にずれることもよくあります。

この「伝える技術」に関しては、要求を高いレベルで定義したストーリーカード、一般的なインタビューなどいろいろな手法がありますが、ストーリーテリングは、「話すこと」だけではなく「聞くこと」「観察すること」も抱擁し、物語にすることで、想像力を拡大させたり、行間に潜む問題を浮き彫りにしたりする効果があり、実際の開発で活用を試みています。

想像力をかきたてるスプリングボードストーリー

本書の中で、スティーブ・デニング氏が名付けた「スプリングボードストーリー」という方法が紹介されています。個人的には一番面白いと感じた部分なのですが、以下の紹介されているストーリーを読んでみてください。

  • 古い二階建てに住んでいます
  • パーティーをするときは2フロア利用しています
  • パーティーでは2フロアに同じ音楽を流したいです
  • 大きな音を鳴らしたくはないです
  • 配線を張り巡らせるのは嫌です
  • 私はレシーバーを購入し、スピーカーを各部屋に設置して解決することができました

ここには技術的な話は書かれていませんが、解決する方法(レシーバとスピーカー)は書かれています。物語とソリューションを述べることで、その間にある技術的解決を想像してしまうのがスプリングボードストーリーです。RxTstudyでもちょっぴり紹介させていただいたんですが(あまりいい例じゃないかも・・・)、

「リリースを自動化してください」ではなく
「リリースを1日10回行いたい」と伝えた

のように、単純な結末ではなく、想像力が試される物語を語るように練習しています。

最後に

UXに関しては「多分、こんな感じ」ぐらいの知識しかありませんが、とても面白い本でした。

ユーザの行動分析や効果測定などは、「継続的インテグレーション」「ペアプログラミング」よりもビジネス側に近い手段だと思います。よって、開発サイドからアジャイルな開発を目指すよりも、UXからアプローチすれば、ビジネスサイドを巻き込みやすいのではないか?と最近思いました。

ただ、単純に「UXからビジネス」ではなく、効果測定に必要な機能実装は開発とも連携が必要なので、職能横断的な形でアプローチが必要になってくるでしょう。DevOpsもしかり。DevAndDesignerもしかり。