上流設計といってもいろいろあるけど、一旦事業領域はすでに決まってるところから、メインとなるユーザー体験を固めるところまでとしてみます。
事業領域の話が入ると、かなりビジネス視点が必要になって、広域デザイナーの枠さえ超えていく気がするので...

今までの経験で毎回やってること

1. 手持ちの情報で「アタリ」をつける
2. 「アタリ」を確認するための調査や評価をする
3. 結果を確認する

このグルグルを、大小様々なサイズ感で無限にやっているイメージ

「アタリ」が仮説思考と呼ばれるものだと思う。アブダクションともいうやつ？
アブダクション結局良くわかっていない…

アタリの決め方

• 類型化（近いものでまとめる）→グループ内の共通する点を考える
• すでに持っていたアタリをもとに軸を決めて、各情報を一覧できるようにする→全体の傾向をみる
• よくある要素（時間、金、感情などなど）について、各情報を参照してみる→要素間の関係性を見たり、情報ごとの差分を見たり
• 情報を集めるときの所感（デブリーフィングなどで意見交換した内容）を切り口として、各情報を眺めてみる→違う発見があれば、新規性のあるアタリとして使える
• 各要素の関係性を繋ぐ→どういうストーリーになっているかをみる

定石になりそう（とりあえず打てる手）だけでも複数ある
多分この複数の中から、暗黙的にどの方法でやるか選んでいる。もしくは、軽く頭の中でシミュレーションしてみて、ありきたりでなさそうなアタリが出そうなのを選んでる。

正直、このアタリがどれだけの精度で出せてるかで、そのあとの調査や評価の計画の精度がほぼ決まる気がする。アタリなくやるときは、出たとこ勝負の調査や評価になるので、全体を舐めるような調べ方しかできず、大した発見はない。アタリの解像度が高いほうが、今まで誰も調べたことのないような調査や評価ができるし、そこからの発見は有意義になる気がする。
ただし、アタリが細かすぎて、大外しした場合、その後に何も使えない情報しか得られないので、どれくらいの細かさで行くか難しい。このアタリの細かさとか、予防線のはりかた（外した場合も使える情報を得られるようにしておく）とか、がシニアコンサルレベルになると、自然とできるようになっているんだと思う。

よくある要素（時間、金、感情などなど）について、各情報を参照してみる

これは、サービスデザインとかビジネスデザインとかで使われるフレームをたくさん知っている方が、カードが沢山引けて良い。記憶出来てればよいので、勉強すればある程度増える。ただ、どのカードで今回行くと良さそうか、というのは、実際に使ってみた経験がないと判断できなさそう。

フレームワークは、いろんな偉い人が「いいこと思いついちゃった」で本にして、声たかだかに宣伝し、広めようとするが、今のところ万物に有効なものは見つかっていないと思う。

例

• デザイン思考（デザイナー自身の共感でアタリを探す）
• 人間中心設計（ユーザーニーズからアタリを探す）
• ビジネスモデルキャンバス（ビジネス上の強みから探す）
• システムシンキング（各事実の関係性から探す）

↑要再検討

つまるところ、アタリつけるところで、スキルがあるかを確認するには

1. どういう方法を選んだか
2. なぜその方法を選んだか（言語化難しい）
3. どんなアタリが見つかったか

が確認できれば良さそう。1-3が論理的に理解できて、アタリ自体も新規性を感じられれば、上出来と言えるような気がする。

「アタリ」を確認するための調査や評価をする

これは、テクニカルに、調査や評価の種類をたくさん知っている、その上で実行できる環境にあり、運営できるかどうかにかかっている。一瞬では育たない。いろんな調査や評価の経験を積んでいくしかない。しかも、どんなにやりたくても、例えば自社内にABテストをやるためのモニターがいなければ、なかなかABテストは出来ない、みたいな、開発環境的に実行が大変なものもある。

活動自体のゴールを、どこまで把握できてるかというのも重要な気がする。

• 何を達成したいのか、どういう効果測定方法を考えているのか（KPI的なもの）
• 達成すると企業にどんなメリットがあるのか（ビジネス知見が必要）
• 顧客にどうなってほしいのか

このあたりを解像度高く理解して、プロジェクトの全体計画を練られる必要があると思う。
そうでないと、アタリを付けるときに経営の視野の範囲外になってしまって、たしかにいいものだけどうちでリリースするものではないわね、となってしまう。人間中心設計ばっかりしてきた私の弱いところ。

やはり、ビジネス知見はある程度必要になる。
では逆にエンジニア知見はどれくらいいるのか。

上流設計やります案件で、やってること

1. 組織の経営方針
2. 今回のPJのスコープ
3. 今回のPJのゴール、KPI
4. （調査や評価など判断材料集め）時間ある範囲で、なければ手持ちの情報で
5. アタリをつけて、試せる形にする
6. 試す、フィードバックを得る

4-6は時間とお金のある限り繰り返す

1-2はビジネス知見が結構いる。スコープを絞り切れるようになるには経験もいるし、経営層と密にコミュニケーションが取れるかも重要になる。
5-6あたりが、実装コストを意識しながら試行錯誤する部分で、エンジニアリングの知見も必要になる。が、エンジニアリングのほうは、他に開発者がいて細かくやり取りできるのであれば、自分自身に力がなくてもいいかもしれない。ビジネス知見は、スコープを絞り切る力がデザイナーにも問われる（スコープを絞るところもふくめて支援して欲しい企業が多い）が、エンジニアリングの方は、デザイナーがいくつか案をまとめていって、エンジニアのほうが、それぞれどれくらい実装にコストがかかるかを伝えてくれれば、一緒に判断していける。エンジニアリングの部分を社外に発注するとかで、仕様書に詳細にまとめないといけないとかになると、自分で実装コストを判断していけるくらいにスキルがないといけないが、社内でやりとりできるのであればそれほど問題なさそう。しいていうのであれば、エンジニアとコミュニケーションを取れるように、ある程度コードが読めるとか、よくあるコンポーネントやパッケージをなんとなく知ってるとかで、ある程度共通言語があるとスムーズに話ができそう。