• 顧客開発モデル。
• 投資家や起業家ではなく、ユーザーに受け入れられるサービスを提供する。
• 消費者と話して解決すべき課題を見つける。
• 投資家と起業家が多数いる事が前提になっている。
• ホントにいいものを作ってるなら投資されるはずという前提。
• もっとも早く調査・可視化できる方法を使う。
• システムじゃなくメールや人と話すことで調査。
• プロトタイプはコミュニケーションできるなら醜くてもいい。
• 自分のゴールを実現できているか少数のKPIを設定して検証する。
• 可視化
• • KPIは3〜5：見る範囲を絞る事による可視化
  • デイリーメール：アクセス性を高める可視化
  • 重要な変化は自動Alert：見るタイミングを絞る事による可視化
• 可視化は忙しくなるローンチより前に用意。
• 定量的に評価できるようにする。
• 自分のゴールを明文化する。
• 問題を乗り越えてまで使っているものには強力なゴールがあるはず。
• クレジットカード購入の手間。
• ユーザー層に合わせた場所でプロモーションする。
• tech crunchなど大手15媒体よりユーザーに合った1ブログの方が効果的。
• 自分が学びたいことを設定する。
• 言い換えると、自分がわかってないことを明確にする。
• サービスは自動であっても人間味のあるコミュニケーションをとる。
• 自動メールも個人名でやりとり。
• ユーザーのアクションに対応して自動メールが送信され、FBを得る。
• わざとスペルミスしたりする。
• 無形のものをインセンティブにする。
• リファラルマーケティングをする時もウェイティングリストの優先権とか。
• 実現してから評価してもらう。
• ちゃんと自分のしたいことをできてから。じゃないとアイディアに正当な価値がつかない。
• ストーリーで伝える。（Whyの話。）
• 残るのは感情。
• 最後に紹介されたTropicanaのCM：http://www.youtube.com/watch?v=7whANIzid-8

やはり、課題（ブレイクダウン）から攻めていくのは定石みたいですね。

具体的な部分で取り入れられることが多かったので、早速試してみます。

※インデントしたコメントはブログ記事にする際につけたもの。ブレイクダウンの先にあるゴールを探る練習。

1. 会社の電話の保留機能である「パーク」は、受話器を置いた後の数秒間でちゃんと表示を確認しないと8つくらいある保留枠のどこに入れたかわからなくなる。
• 確認できなかった時は「諦める」ということになってしまいがち。
• ファンクショナルゴール「電話を回す」が無視されている。
2. レインブーツの中で靴下が脱げる。
• 靴下選ぶ時に靴までイメージしてないとダメなんですよね。
• レインブーツの密閉性や歩きやすさが快適性の邪魔になっている。
3. 会社の会議室によってWi-Fiがつながらない。
• これは困る！今後はとらないようにしよう。
• ラップトップで全員で資料を見るというファンクショナルゴール。
4. pathでライブラリから写真を選ぶ時、拡大してキャンセルするとタイムラインにまで戻ってしまう。（@7gano氏曰く「まずカメラが起動するのはライブなモーメントを切り取る設計だから」）
• 解決方法はありそう。
• いい写真をピックアップして共有したいというファンクショナルゴール。
5. マスクをしている時にガムを噛むと、マスクがあご髭に引っかかって猫じゃらし的に降りてしまう。
• 花粉症になっちゃったもので・・・
• 鼻と口を覆うというファンクショナルゴール。ガムは口を閉じたまま噛み続けるというレアケース。
6. 密閉度の高いマスクをしてるとクシャミの前の吸気で口に張りつく。
• 恐怖！
• 生存欲求。
7. Bloggerのアプリで画像の挿入位置を指定できない。
• 文章の流れに沿った記事が書けない。BlogPressならできる。
• 自由に「記事」を書けるというファンクショナルゴール。
8. Facebookアプリでは通知設定ができない。スマホWebならできる。
• あった。「Facebookからのお知らせ」というラベリング。これはわからん…どちらにせよアプリ単体のNotification設定は欲しい。(隠れてるかも？)
• スマホアプリで通知が出るのを種類別で分けたい。
• FB Messengerと使い分けをしたい。
9. 電通サイトが下にしかスクロールできない。
• いつもどおりにスクロールしたい。
10. Evernoteアプリは＋の背景がデフォルトでブルーなのでフォーカスしてるように見える。それになれるとDefaultPNGの罠。
• これが採用されたアップデートはホント改悪だった。
• 自分のいる位置がわかるというファンクショナルゴール
11. Evernoteアプリは起動時の画像にタブバーが含まれてるので＋を無意味に押してしまう。（タブバーにアクションボタンがあるから混乱するのか。 ）
• 起動時の画像がスプラッシュだと起きない。下手にUIを使うとこうなる。
• 使えるならすぐにつかいたいというファンクショナルゴール。
12. トイレのドアの鍵が閉まっている状態が垂直だと感覚と違って不安を感じる事がある。
• これはさらにノブがドアの左右どちらについているかにも関係してそう。
• コンテキストだけではなく形態でロック状態がわかるというファンクショナルゴール。
13. MacではFirefoxのHtml Validatorが使えない。
• かなりちゃんとしたツールなので使えないのは困る。
• と思ってたらHtml ValidatorのMac版あった！ブレイクダウンリストのおかげ！
• Validateを満足できるクオリティでしたい。
14. 足の小指をぶつける。（子ども用の椅子、作りつけのドアストッパー）
1. 特にドアストッパー！固定されるとね・・・スリッパを履く習慣がつかないので困ってたけど、しばらくすると自然に避けるようになってた。
2. ドアを止めるには安定性が高いけど・・・
15. メイプルシロップのビンの外側にシロップがつく。
1. これはなんか解決した商品ありそう。
2. 甘さのせいで粘度が高い。

それらは単に無駄を削ぎ落とし質を底上げするための方法に過ぎないから、スタンダードからの正当な逸脱はどんどんしちゃいたい。

そんな枝葉はどうでもよくて、とにかくユーザーのゴールを達成できればいいんです。
デザイナーは、とにかくリアルなユーザーのゴールを達成する責任者であらねばならないと思ってます。
むしろPhotoshopが使える人の他にユーザーのゴール達成の責任者がいるなら、その人がデザイナーと呼ばれるべき。

もちろん我々デザイナーは、ユーザーが直接言ったことじゃなく、その先にある本質的なゴールを見て取らなくちゃいけない。

その上でユーザーモデルの責任者であるデザイナーが、ビジネスモデルやテクノロジモデルの責任者とお互いのモデルを融合させてつくるのがサービスです。

常に絶妙な色・形・配置・大きさ・質感・インタラクションが必要だとは言って無いし、リサーチが無ければプロジェクトは始められないとも言わないです。
それらは単なる方法ですから。

逆にリアルなユーザーのゴールのためにホントに必要なら、ビジネスモデルの責任者やテクノロジモデルの責任者に「そんなの必要無い」とか言われても、そこから話しあえばいいだけ。責任範囲が違うんですから。

でもそのためには根拠が必要です。
彼らはリアルな根拠を持ってますから、同じ土俵で話しあうためには学問としてのデザインセオリーとかじゃなく、リアルなユーザーのゴール仮説としての根拠を持たなくちゃいけません。そのための方法を知っていて、必要と制約に応じて使い分けられるデザイナーが必要です。

数字やシステムが守られるように、僕らデザイナーがユーザーのゴールを守っていきましょう。それがデザインにはその力があるはずです。

@ry_k_n君の答えは、

運転手の後ろに座ったら、「お前の顔写真なんか見たくねぇ！」って思うから助手席の後ろ。

僕の答えは、（言ってないけど）

一対一で運転手と話す可能性があるならば自然に助手席後ろになりそう。道順を伝える役目が助手席後だから上座は運転手席後ろ。

The Designer @memocamera?の答えは

奥だとタクシー代を払わせる感じがするから助手席後ろ。

どれもコレだという確証までいかないものばかり。
その後ググってみても納得のいく答えはなかなか見つかりませんでした。

で、そんな矢先、先日タクシーに乗ったので、そういえばと思い出して運転手さんに聞いたところ、

タクシーの場合、歩道に寄せて「お先にどうぞ。」ってするから奥である運転手の後ろ。

という答えが返って来て目から鱗でした。

目下が先に乗って中から「どうぞ。」ってのはねぇ。

とも。

確かに。

@memocameraが心配してた支払いの件は、停車前に用意してスマートに済ませるらしいです。

もちろん目上の方の要望に臨機応変に応える事は前提ですが、こんな自然な事に考え至っていませんでした。
これは、空間の中での位置ばかり気にしていて、乗り降りのコンテキストに気づいていなかったからです。

こういった事はUIデザインでもよくあることで、検討している画面だけで物事を考えているとコンテキストと分断され、実際の使用に即さないものになってしまいがちです。

Getting Realやプロトタイピングを用いたデザイン・開発手法は、コンテキストを意識したモノづくりの手法ですが、もっと日頃からGetting Realな思考をしなくてはと思わされた一件でした。

※蛇足ですが、ゴールダイレクテッドデザインで考えてみましょう。
もしこれがゴールを目指した現状であるならば、座の上下を決めるのは、空間に入るところのコミュニケーションによって立場を表現することなのかもしれないという仮説が浮かびます。
ここから、目上の方が奥に入ってくれなかったら運転手側に回るという行動もデザインできます。

• 実装モデル：どのような仕組みか。
• 表現モデル：どのように見せるか。
• 脳内モデル：ユーザーがどう捉えるか。

の3つのモデルが存在します。

ジェネシックスでは、ゴールダイレクテッドデザイン（GDD）の導入と共にiOS Human Interface Guidelines（HIG）も取り入れたのですが、これは僕にとって幸運なことでした。GDDには理論が、HIGはAppleの実践があったからです。もちろんその2つは単純にイコールでは結ばれませんが、かなり近い考え方であると思います。

そのHIGには「アプリケーション定義ステートメント」という概念があります。これは、

アプリケーション定義ステートメントは、アプリケーションの主要な目的とその対象を、簡潔かつ具 体的に宣言したものです。

というもので、具体的には

「料理好きでやりくり上手な人のための買い物リスト作成ツール」

のように、誰のためのどんなツールなのかを明文化したものです。

GDDではゴールを発見し、ペルソナとしてユーザーモデル化するのですが、ペルソナを常に念頭に置きながら開発やMTGをすることは現場では困難です。そこで、そのユーザーモデルに対してどのような表現モデルが必要であるかを共有する方法が必要になります。

気づいてみると、とりあえずやってみようということで採用していたこの「アプリケーション定義ステートメント」が表現モデルの仮説として機能していました。
（ジェネシックスではさらにこれをキャスト毎に設定しています。）

また、HIGで紹介されているアプリケーション定義ステートメントを作成する方法は恣意的なので、GDDによってその弱さが補われ、仮説としての信頼性を高めることができています。

これはアプリでなくても問題なく応用できるものなので、GDDは知っているけどHIGは読んだことが無いという方は、ぜひお試しください。

「（ペルソナに対してのアプローチ方法を変えていくのはわかりましたが、）ペルソナ自体を変えることはあるんですか？」

というものがあります。

これに対する答えは「もちろんあります。」です。検証によって間違っているとわかった仮説に固執する理由は何もありません。

ですが、ゴールダイレクテッドデザインでのUXデザインの仮説の検証と再設定についてまとめた事はなかったので、言語化してみようと思います。

仮説の検証と再設定は、バージョンやイテレーションなどの区切りで必ず行うべきですが、事業におけるゴールダイレクテッドデザインでは、大きく分けて3種類の仮説があると考えられます。それは、

1. 事業仮説：事業計画からマーケティングなども含む事業の成功への仮説。
2. ゴール仮説：ペルソナの元になる「ゴール」の仮説。
3. 方法仮説：ゴールに対するアプローチ方法の仮説。

です。

ゴールダイレクテッドデザインの優位性は、ここにもあります。

ゴールダイレクテッドデザインでない場合、事業仮説に対して方法仮説を設定するしか無いのですが、ITベンチャーでは多くの場合、「とにかく走りだそう！」から始まってあとは思いつきの列挙で目的地を目指している状態になりがちです。
なんらかの経験則か多くの時間と資金か幸運があれば目的地に辿りつけますが、無駄が多くなるケースが大半なのではないでしょうか？

ゴールダイレクテッドデザインの場合、ゴール仮説に合わせた方法仮説を仮説検証・再設定していきます。
ユーザーはこのゴールを持っているのだから、この機能をつければこのように反応する筈だ。という仮説に対して検証し、結果が良ければ確信を深め、悪ければ質や方法を変えます。

そして、ペルソナはこの反復の中で検証されます。
ゴールが明確な分、提供したサービスや機能に対するユーザーの反応も予想しやすいので、まったく無反応であったり拒否反応が強かった場合は、十分察知できると考えています。その時は、なんらかの客観的なデータに基づいてゴールを見なおします。

ジェネシックスの場合、完全なる妄想から出たゴール設定というのは無いので、幸いペルソナ自体を否定してつくり直す事態には至っていないのですが、ゴールを修正したことは多々あります。

これについて、個人的には、指向性がある分ピボットしやすいのではないかと考えています。

そしてこれは他のUXデザイン手法に対するゴールダイレクテッドデザインの優位性の一つでもあります。単なるプロフィールのペルソナやストーリーだけのUXデザインでは、原因特定が不明確になりやすいからです。

そういった意味でもゴールダイレクテッドデザインはモノづくりの現場にマッチした手法だと言えるのではないでしょうか。

※現段階ではハイデガーに対する僕の理解が至っていないかもしれません。悪しからず。

前回、ブレイクダウンからゴールを探れるのではないかと問題提起したわけですが、それを考えるためには「ブレイクダウン」についてまとめなければなりません。

ハイデガーによるとブレイクダウンは3種類あり、

1. 【使用不可能】（使えない）→目的にふさわしい道具が壊れていると目的ではなく道具自体が目立ってくる。
• 例：ハンマーが壊れているとハンマー自体が目立ってくる。
2. 【不在】（無い）→目的にふさわしい手元にないものに気づくと、それと対になる手元にあるものが催促がましくなる。
• 例：ハンマーが無いと打ちたいのに打てない釘が目立ってくる。
3. 【不用具】（邪魔）→目的とは関係ないものが目的の過程にあると煩わしくなる。
• 例：食事をするテーブルにハンマーが乗っていると、食事の邪魔になる。

に分けられます。

ここで「目的」と書きましたが、
実際にはブレイクダウンは「配視」に対するものです。
僕の理解では配視は「目的達成の脳内モデル設計しようとする心の働き」で、人間は都度ゴール達成に向けた道具のコンテキストを脳内につくりながら事物を認識しています。

例えば「木材を使って踏み台を作りたい」というゴールを持っている場合、

「木材を切って組み合わせる。」

といったようなゴールを達成するためのイメージを持つわけですが、
目の前に

1. 木材
2. のこぎり
3. 釘
4. ハンマー

があった場合、例えば

1. 「木材を切る」←木材を切れるもの（のこぎり）
2. 「切った木材をつなげる」←木材をつなげるもの（釘←ハンマー）

といったイメージが瞬時にできあがります。

もしかしたらそのイメージは、

1. 「木材を折る」←木材を折れるもの（ハンマー）
2. 「切った木材をつなげる」←木材をつなげるもの（釘←ハンマー）

といった成功しなさそうなものかもしれません。
ただ、実際にゴールできないかもしれないけれど、イメージ自体はできてしまいます。

このイメージをここでは「脳内モデル」と呼び、脳内モデルをつくる心の働きを「配視」と呼びます。

では、順を追って

木材を切り終わり、ハンマーで釘を打ち始めます。
トントントンと気持よく釘を打っている時、ハンマーそれ自体に意識は向けられていません。
しかし、木材に半分まで入ったところで釘が曲がり始め、「まずいな・・」思っているところでハンマーが壊れます。

この時、意識のフォーカスはゴールからハンマーという事物自体に移り、順調に釘を打っていた時とは比べものにならないほど「ハンマー」の存在が大きくなります。

これが【使用不可能】ブレイクダウンによってハンマーが目立った状態です。

ハンマーが壊れている＝使用不可能である事がしっかり認識されると、今度は木材に半分まで入った「釘」（木材もかも？）に意識のフォーカスが移ります。
今まで脳内モデルの中で踏み台の完成に向けての「方法」だったものが急に「課題」となって立ちはだかるわけです。

これがハンマーの【不在】ブレイクダウンによって釘が目立った状態です。

では、どうにかもう一つのハンマーを探し出し、踏み台づくりを再開します。

でも困ったことにさっきまで木材をつなげるための道具だった釘は、曲がってしまい、抜くこともできず、そのまま打ちつけることもできない邪魔な存在になっています。
本来「道具」があるべき位置に役立たずなものが居座っていると、マイナスな意味での「道具」として存在感を増すということです。

これが釘の【不用具】ブレイクダウンによって釘が目立った状態です。

道具は脳内モデルどおりに使用できている時は意識されず、これら「ブレイクダウン」が、「道具」をそれ自体という事物として認識するタイミングになるということになります。

ここで「ブレイクダウンはゴールがあるからこそ発生する」と考えられるのであれば、行動のブレイクダウンからゴールを探り出せるのでないか、というのが僕の仮説です。

次はこの仮説について考えてみます。

そういえばゴールダイレクテッドデザインについて基本的な情報を書いていなかったので、まとめておきます。

Goal Directed Design（ゴールダイレクテッドデザイン）は、Visual Basicの父と言われるAlan Cooper（アラン・クーパー）が提唱した、その名称のままに、ユーザーのゴールに向けてデザインするためのインタラクションデザインの手法です。
プロセスとしては、「リサーチ→モデル化→要件化→フレームワーク設定→精緻化→開発支援」になります。

教科書的な説明は@ITの情報マネジメント用語事典「ゴールダイレクテッドデザイン」の項にお任せします。
また、このページでは、

“インタラクションデザインの方法論の1つ。 “

とされていますが、現状ではUXデザインの手法の一つとして扱われる場合が多いです。
ただし、ゴールダイレクテッドデザインについて書かれた『About Face 3』P.21で、

“それに私たちは、そもそもエクスペリエンスをデザインすることが可能かどうかに疑問を持っている。”

とAlan Cooper自身が言っていることにも留意しなくてはいけないと思います。

この件についての僕の解釈は、「人はゴールを持っている。そのゴールに 対してインタラクションのデザインをすることはできる。しかし、それによって生まれるユーザーの体験はユーザー自身のものなのでデザインしきれるかどうかわからない。」ということだと思っています。

では、なぜUXデザインの文脈で扱われているかというと、それはUXデザインを代表するツール「ペルソナ」がこの手法の一部だからで、近年はAlan CooperもUX系のイベントに参加してますが、「Interaction Design」という用語は使い続けているようです。
個人的には、ペルソナはゴールをモデル化したものであり、それ以外の目的で使うとリスクが高いと考えていますが、それは僕の不勉強のせいかも知れません。（実際ペルソナを別の手法の中で使おうとして混乱していた時期もありました。）

僕は、ゴールダイレクテッドデザインは、一連のプロセスよりも「ゴールに向けてデザインする。」という思想自体に価値があると考えています。自分にとって「Goal Directed Design」がなんであるのかを考え始めたので、この記事に興味を持たれた方には、そちらの記事も面白いかも知れません。

これを真似しようと思ったんですが、そこでこの「バグ」と「ブレイクダウン」が似ていることに気づきました。自分にとっては「”道具”を認識するツール＝ブレイクダウンリスト」の方が意味を持つだろうと考えたので、Evernoteに「brakedown」というタグを作って、EvernoteにサクっとアップロードするiPhone プリ「FastEver」で上げられるようにしました。Evernoteなら写真も上げられますしね。

始めてみると、日常で既に気がついていた「ブレイクダウン」を消化している気分になれて、精神的にも気持ちいいです。

自分のものに出来たらまた記事を書いてみようかと。