システム開発こそストリーボードが必要

• ツイート

Storyboard（ストーリーボード）とは

ストーリーボードはテレビ広告表現のストーリーと場面を示す草稿の事で、場面の絵とせりふがコマ割りで描かれています。マンガのようなものとイメージするとわかりやすいですね。

もともとは映画のストーリーを効率的に考えるためにウォルト・ディズニーが考え出したものだそうです。ストーリーを練る会議に参加しているアニメーターの方々が自分の頭の中にあるイメージをうまく伝えるために、ラフスケッチをしたりその場で絵を描いたり、映画としての一連の流れが見えづらかったので、ウォルトが一枚の板にアニメーターのスケッチをストーリー順にピン留めしたところ、会議の参加者全員がストーリを視覚的に把握することがでました。さらに、足りないシーンや不必要なシーン、置き換えが必要なシーンがわかるようになった’のがはじまりだそうです。

Storyboard（ストーリーボード）の利点ってなに？

アプリケーション開発やウェブサイト制作では個々の機能や個々の画面に固執してしまいがちです。せっかく頑張って実装しても、そもそもの機能や画面が実はユーザにとって不要なものだったり、ユーザが欲しいものではなかったりしたら非常にもったいないです。ユーザが満たしたいことと実際の画面や機能にズレが生じていると、このようなことが起きてしまいます。

アプリケーション開発やウェブサイト制作の発注元が、必ずしもユーザに対して実現したいことを機能や画面に落とし込めているとも限りません。発注元に言われた通りにしたのに、ユーザーは満足しなかった。。ということはよくありがちです。

過去に「他の人が投稿した内容（内容に関わらず）をスマホアプリの通知機能でお知らせする機能をつけてください。」と依頼されたことがありました。自分が興味を持っている人の投稿なら通知されてもいいかもしれないですが、何の関心を持たない人の投稿内容が通知されても迷惑なだけです。

発注元によくよく聞いてみると、「他のアプリも通知機能を使っているから自分のアプリにも使ってみたい」というだけだったのです。お知らせする機能がユーザーに対して何をもたらすのかということが考えられていなかったわけです。

ストーリーボードではユーザに対して何を実現したいのか、何を体験してもらいたいのかということをストーリー仕立てで1シーンごとに組み立てていきます。実際にストーリーとして落とし込むことで、不足しているシーンや不必要なシーンを洗い出すことができます。

本当にユーザーが体験したいことは何なのかをアプリケーション開発やウェブサイト制作の発注者とすり合わせ、情報を整理することでユーザに隠されたニーズを探し出せたら、発注元からも感謝されるかもしれないです。

参加にあたって

現在私は、企業に常駐してアプリ開発や受託でのシステム開発をしています。受託案件は、基本的には発注元から依頼された通りに開発するのですが、実際に開発した機能がユーザにとって満足のいくものではないことがあります。そのような案件は、発注元に確認してみると、ユーザに何を体験してもらいたいのかのイメージがはっきり落とし込めていないことが多いです。このような失敗がないためには、ユーザーのコンテキストなどを含めたイメージを落とし込むのにストーリーボードは有効なのではと考えています。

昨年もUXdays tokyoに参加させていただきました。Arron Walter氏のワークショップではユーザーにインタビューを行うことでニーズを引き出す方法を学び、Josh Clerk氏のワークショップではタッチスクリーンにおけるUIについて学ぶことができました。具体的な内容はこの記事では記載しませんが、現場で生せているので非常に満足しています。

今回参加するワークショップでは、ストーリーボードの活用方法について実践的に学ぶことができます。エンドユーザーにとって本当に必要なものを発注元やクライアントに提案するための手段として有効に活用できたらと考えています。