プロダクトをつくるのに必要なものとは何でしょうか。要件定義書でしょうか、ユーザーストーリーでしょうか、会話でしょうか。どれも状況に応じてそうだと言える一方で、どれもある意味では同じものでしかなく、それらだけでは、想定範囲のアウトプットを越えることは難しいと思っています。
いずれも、 「自分の外側から与えられたもの」 という意味で同じだと捉えています。要件定義書も、ユーザーストーリーも、量の違いはあれ、記述した何かであるには違いありません。ユーザーストーリーに基づいた会話はどうでしょう。会話も、プロダクトオーナーからただただ情報を引き出すだけであれば、言語化された情報を受け取っている点で、やはり外側から与えられているという見方ができます。
もちろんただ聞いただけではなく、自身の経験や想像からの補完も行っていることでしょう。ただ、チームや関係者の想像を超えるようなモノが生まれることをどれほど期待できるかというと…経験云々を持ち出している以上、人に依りますよね。現実的には、情報の受け渡しを行う前提を置いた開発で、共通理解をはるかに超えてしまうようなものを唐突につくって良いのか、という観点も出てきそうです。
予定調和的なアウトプットを超えていくためには、私は 「イメージでつくる」 が必要ではないかと考えています。外部から受け渡される情報に過度に依存するのではなくて、つくり手の自分の中に「イメージ」を宿して、モノづくりを行う、ということです。
自分の中に、対象テーマに対するイメージが無いままつくろうとしても、やはり頼りになるのは自分の外側から入っていくる情報になってしまいます。ではイメージを宿すためにはどうしたら良いでしょうか?
「体験する」 ことです。先に述べたように「自身の経験や想像から補完」してつくっているならば、より豊かな経験があればあるほど様々なイメージが自分の中に生まれるはず。ですから、想定するユーザーの現状の活動現場、プロトタイプを利用する実験には、検証者(プロダクトオーナー)だけではなく、つくり手も居合わせる方が良いと考えています。自分の目と、耳と、肌で、感じ取らなければ、イメージは宿らない。
ただし、ただ居合わせていれば良いというわけではありません。現場では、 「解釈」 が重要です。目にしたもの、耳にしたことがどういう意味を持つモノなのか、解釈ができなければ、自分の中を通り過ぎるだけでしょう。解釈する力を高めるためには、様々なモノの見方を得るように努める必要があるでしょう。はじめて現場に行ったら、「解釈のふりかえり」を行いましょう。何を見て、どう思ったのか?他の人の意見に耳を傾け、自分にはないモノの見方を集め、自分自身の見方を鍛えていきましょう。
眼力の強い人達が集まり、チームを組んで、プロダクトをつくれたら。きっと面白いものが出来る予感がしませんか。
※以下の発表では、魚市場での観察の例を載せました。
この記事もどうですか?
-
Ruby on Railsのgem「Active Interaction」でコードの見通しをよくする
本記事は ギルドワークスAdvent Calendar 10日目の記事です。 はじめに ギルドワークスでは、Ruby on Railsで記述したプロジェクトが多く存在します。 その中で定番のGemfile構成(ライブラリ構成)があります。毎…
-
ブラウザ操作のキャプチャができる Puppeteer recorder を試してみる
Chromeの自動操作ツール Puppeteer みなさん、 Puppeteer はご存知でしょうか?Googleが開発している、Chromeの自動操作ツールです。 ブラウザの自動化ツールと言えば Selenium ですが、それと比べると …
-
isNotSummer()よりisSummer()だよね
ギルドワークスの増田です。 前回 if文の条件式の書き方あれこれ に書いた内容の続編です。 if文の条件式で論理演算式をべた書きしていた部分を、メソッドに抽出し、さらに、そのメソッドを、演算対象のデータを持つServiceDateクラスに移…