プロダクトをつくるのに必要なものとは何でしょうか。要件定義書でしょうか、ユーザーストーリーでしょうか、会話でしょうか。どれも状況に応じてそうだと言える一方で、どれもある意味では同じものでしかなく、それらだけでは、想定範囲のアウトプットを越えることは難しいと思っています。
いずれも、 「自分の外側から与えられたもの」 という意味で同じだと捉えています。要件定義書も、ユーザーストーリーも、量の違いはあれ、記述した何かであるには違いありません。ユーザーストーリーに基づいた会話はどうでしょう。会話も、プロダクトオーナーからただただ情報を引き出すだけであれば、言語化された情報を受け取っている点で、やはり外側から与えられているという見方ができます。
もちろんただ聞いただけではなく、自身の経験や想像からの補完も行っていることでしょう。ただ、チームや関係者の想像を超えるようなモノが生まれることをどれほど期待できるかというと…経験云々を持ち出している以上、人に依りますよね。現実的には、情報の受け渡しを行う前提を置いた開発で、共通理解をはるかに超えてしまうようなものを唐突につくって良いのか、という観点も出てきそうです。
予定調和的なアウトプットを超えていくためには、私は 「イメージでつくる」 が必要ではないかと考えています。外部から受け渡される情報に過度に依存するのではなくて、つくり手の自分の中に「イメージ」を宿して、モノづくりを行う、ということです。
自分の中に、対象テーマに対するイメージが無いままつくろうとしても、やはり頼りになるのは自分の外側から入っていくる情報になってしまいます。ではイメージを宿すためにはどうしたら良いでしょうか?
「体験する」 ことです。先に述べたように「自身の経験や想像から補完」してつくっているならば、より豊かな経験があればあるほど様々なイメージが自分の中に生まれるはず。ですから、想定するユーザーの現状の活動現場、プロトタイプを利用する実験には、検証者(プロダクトオーナー)だけではなく、つくり手も居合わせる方が良いと考えています。自分の目と、耳と、肌で、感じ取らなければ、イメージは宿らない。
ただし、ただ居合わせていれば良いというわけではありません。現場では、 「解釈」 が重要です。目にしたもの、耳にしたことがどういう意味を持つモノなのか、解釈ができなければ、自分の中を通り過ぎるだけでしょう。解釈する力を高めるためには、様々なモノの見方を得るように努める必要があるでしょう。はじめて現場に行ったら、「解釈のふりかえり」を行いましょう。何を見て、どう思ったのか?他の人の意見に耳を傾け、自分にはないモノの見方を集め、自分自身の見方を鍛えていきましょう。
眼力の強い人達が集まり、チームを組んで、プロダクトをつくれたら。きっと面白いものが出来る予感がしませんか。
※以下の発表では、魚市場での観察の例を載せました。
この記事もどうですか?
-
市谷と中村洋の2人が、毎回テーマを決めて語り合う場を始めました。
「月と、人狼」と題して、「仮説検証によるサービス・事業の立ち上げ」や「開発現場・組織カイゼンに取り組む」 市谷と中村洋の2人が、毎回テーマを決めて語り合う場を始めてみました。 第1回のテーマは 「ギルドワークスとアジャイル」 でした。 Wh…
- 正しいものを正しくつくる
-
if文の条件式の書き方
ギルドワークスの増田です。 (前回書いた リファクタリングのエッセンス の続編です) if文のちょっとしたの書き方の違いは、ソフトウェアの変更のやりやすさに大きく影響します。前回のサンプルコードから、if文の条件式部分だけ抜き出してみます。…
-
クラス名の探し方
ギルドワークスの増田です。 最近、ある分野(株価)に特化した SNS サービスのドメインモデルを設計する機会がありました。設計で悩ましいのはクラス名やパッケージ名に良い「名前」を見つけることです。 今回は、モデリングの初期の段階で、私がどの…