| title | free |
|---|---|
PBLのポストモーテム |
false |
概要：今までの文献レビューへのフィードバックと、相互の批評・議論。課題：年明けの次回までに改善案を提案するPT を選定し、ポストモーテムを行ってくる。
フィードバックが一通り終わり次第、以下にあげる「吟味することの例リスト」を参考に、穴埋めのように、授業時間中に少しでも進めてもらう。本学のPBLの提案において、DTの３条件、もしくは濱口の３条件に叶うような提案は残念ながらあっても少ない。一体どこで失敗したのか？ どこでプロジェクトはつまづいてしまったのか、死んでしまったのか？を顧みる。
なるべく客観的に根拠を述べつつ、かつ最大限まで主観的に主張する。なぜあなたはこれが面白いと思ったのか、なぜあなたはこれが面白くないと思ったのかにも言及する。主観を排して客観を追求するのも重要、客観を排して主観を述べるのももちろん重要だ。しかしこれらは必ずしも相互に排他的ではない。特に、デザインでは一見矛盾するような主観と客観の両方の品質を追求すべきだと思う。このタスクでもそれを狙う。
ねらい
アウトプットの品質は清潔さに似る。AND, AND, AND, ...で連鎖するブール掛け算だ。スプーンで卵運ぶ競走ともえいえる。問題設定でつまづけば卵は割れる。問題設定でうまくいってもコンセプトでつまづけば卵は割れる、以下同様。
以下の論理の連鎖＝ナラティブを、以下では連鎖と呼ぶことにする。
[大問題設定]→風呂敷・ホラ・お気持ち・飛躍→[小問題設定]→HMW/Actionable Problem Statement→[発想]→コンセプト→[実装]→プロトタイプ→[検証]
プレゼンはいかに提案する人工物がすぐれているかを説得する行為だ。PBLの最終プレゼンや中間プレゼンでするべきことは、この連鎖を説明するだけだ。人工物を見せれば何も弁護せずとも何もかも納得できるようなものであればよいのだが、ほとんどのものはそうではない（iPhoneですら登場時はジョブズがみんなの前で長々と価値を説明した！）から弁護する必要がある。つくったものをなんの説明もなしに見せれば見る者の頭にはハテナが生まれる。なんだこれ。それを、なるほどという共感、ビックリマークに変えていくのがプレゼンで行う説明、説得だ。
- あるものを提案します（ハテナ、これはなんだろう？なんのために？どんな価値が？）
- こういうことができます（なるほど）
- こういうふうに実現します（たしかにできているな、なるほど）
- これのためにつくります（なるほどね、全部つながった！）
- こんな効果があります（すごい！）
しかししばしばこの鎖のうちの重要な輪っかがわかりにくかったり、最悪の場合あるべき輪っかがなかったりする。理詰めの論理の連鎖が説得力を、共感が納得感（なるほど！）を、納得感が
どこでコケたかをなんとかしてエイヤで特定し、それが死因ではないかという作業仮説をたて(#9)、作業仮説をもとにそこからやり直す（#10-#11）。さらに、こうやれば改善できるのではないか、という仮説を用意する。それをさまざまな方法で実行可能な計画に落とし込めないかを模索する(#12-#14)。それを文書（プロジェクト計画書）としてまとめ、#15に発表する。
ポストモーテムはリバースエンジニアリングだ：といってもよくわからないので、以下の各プロセス＝輪っかに分割して、それぞれをリバースエンジニアリングする。これからやること：ナラティブ、ストーリー、理論の筋道を調べる。どういう理詰めでその結論（〜ゆえにこれをつくることにしました）にたどり着いたのか？リバースエンジニアリング^[cf. 生物学はリバースエンジニアリングである (Dennett 1995)]をやる。目的と手段の入れ子状態を説明する。作業としては、スタートからゴールに＝このリストの下から上にむかうもの（彼らがやっていることから始めていくのでわかりやすい。彼らのナラティブの風呂敷の広げ方を明らかにしていく）と、ゴールから逆にたどってスタートに＝このリストの上から下にむかうものがある（風呂敷をどう収束させていったか）。
エンジニアリングなら：左の方はなくても・薄くてもいいが、右の方はユニークで濃くないといけない。誰もが同意できるような欲、問題設定を、すごい貢献で解決する。 デザインなら：左の方、とくに小問題設定はユニークで濃くないといけない。右の方は絵に描いた餅でも最悪いい(コンサルのいうrecommendation)。ほぼほぼ実現可能なフィクションをつくる仕事。
（なぜなぜ分析とは少し違い、**なぜ(4 whys)**の説明：（省略）を考える。４つのなぜが↓にはでてくる）
- 大問題設定: 最終的な錦の御旗（桶屋が儲かる）はなにか？^[4つのなぜ的には：適応主義的なアプローチ、静的究極要因…か…？inclusive fitness的な]s
- 最終的なご利益。〜につながって嬉しい、の形。直接的にはどうやったって実現できないが、寄与できると嬉しい究極の目論見だったり、個人的な幸せだったり。なくてもよい。人の幸せとは。ドグマ。錦の御旗。金科玉条。厄介な問題。
- what for: WHAT is it ultimately designed FOR?
- 例：温暖化抑制？少子高齢化解決？人種差別解消？ステータス向上？楽しい？幸せ？不快でない≒人間中心？桶屋が儲かる？
- 間をつなぐ中問題設定、飛躍の例：
- Xをつくることで→{技術Aが進展することで}→厄介な問題の解決に貢献するかもね、とか
- ユーザーのなんらかの美徳をみせびらかせそう→購入者のステータス向上するかもね、とか
- 間をつなぐ中問題設定、飛躍の例：
- 主な吟味：ナラティブの説得力。錦の御旗へと連綿と続く
連鎖の飛躍が受け入れられるか。 - なくたっていい。iPhoneの登場時のWWDCでジョブズは錦の御旗など説明しなかった。説明しなくても十分に価値が伝わった。
- 小問題設定: 提案物の直接的なご利益、コンピテンシー（砂を舞わせる）はなにか？^[4つのなぜ的には：適応主義的なアプローチ、静的究極要因…か…？]
- 直接のご利益。目的の品質。〜できる。の形。competency
- why / fit: WHY is it a good idea?
- what: WHAT does it enable us?
- 例：Bをするときのカーボンフットプリントがx％減る？A地点からB地点に楽しく移動できる？儲かる🤑、効率のよさ、
- 主な吟味：できるようになることのおもしろさ。コンピテンシーに需要があるのか。できるようになることの新規性、有用さ、特筆性。
- ないとダメなのだが、訓練していないとろくでもないコンピテンシーを追求しがち。
- 発想: 提案物の直接的なメカニズム（風が吹く）はなにか？^[4つのなぜ的には：機構、静的至近要因]
- モノの品質。手段の品質。新結合。既存のなにを新奇に組み合わせたのか。どう組み合わせたのか。エンドユーザーとどう相互作用するのか。モノヅクリの最下流、川（人工物）と海（ユーザー）が交わる河口。
- what it does: WHAT does it actually do?
- how it works: HOW does it actually work? HOW does user use it?
- 主な吟味：解き方のおもしろさ。おもしろコンピテンシーをどんなおもしろアイディアで実現するのか。絵に描いた餅の魅力度。
- ないとダメなのだが、訓練していないと試行錯誤が足らず、ここの品質がおろそかに→おもしろくなくなりがち。
- 実装: 提案物をどう（風を生じさせる）実現しようとしたのか？^[4つのなぜ的には：発達、動的至近要因]
- モノヅクリの品質。どう製造するのか、どんな技術を組み合わせるのか…。ものづくり的には上流、
連鎖的には左端。comprehension - how: HOW is it realized? HOW did they realize it?
- 主な吟味：おもしろアイディアをどんな現実的な技術の組み合わせで実装するのか。技術的実現性＝フィージビリティがあるのか。ビジネス的なうまみ＝ヴァイアビリティがあるのか。絵に描いたおいしそうな餅を、どれくらい実際においしい餅にできているか。
- コンセプトデザインなど、限られた実装でもいい場合もあるが、たいてい高品質のものがあったほうがよい。
- モノヅクリの品質。どう製造するのか、どんな技術を組み合わせるのか…。ものづくり的には上流、
- 検証: ^[無理やり適応主義っぽくいうと：適応度の測定。適応度地形上の高度と、移動距離/既存変異体からの距離の測定。]
- おいしさをどう測ったか。どれくらい他の餅と違うのかをどう測ったか。いくつになったか。
- なくたっていい。iPhoneのよさを測定などしなくてもわかるひとにはわかり、わからないひとは「こんなものはおもちゃである」というだけ。
注意：これらがすべて揃っている必要は必ずしもない。詳しい理由は後述するが、どれかの制限を緩めることによって発想の幅が広がるから。実現不可能でも面白い発想はありうる。錦の御旗がなくても面白い実装はありうる。それらもそこそこの貢献になる。しかし小問題設定と発想は必須、実装もほぼ必須だ。問題→解決の最小限の１セットがわかりやすく、おもしろく、幸せにつながりそうと思わせることが必須だ。しかも、できればMVPが実装・提供できていることが重要だ。 さらにどうでもいい注意：砂が舞う→失明者が増える→三味線需要うｐ→猫が減る→ねずみが増える→穴が開く→（桶屋が儲かる）の部分は常識的につながりそう、連想できそうなら問題ないが、提案によっては何段もの、やることA（手段）、Aの目的はBという手段、Bの目的はCの実現、Cの目的はDの実現…DはZという究極の目的に
#9にむけた主な年越し宿題は、
- 吟味するPTを決め、（対象特定）
- 当該PTの最終発表をみたり、現在進行中のプロジェクトなら教員や所属学生に話をきいたり資料をもらったりし、（死体入手）
- すべてのプロセスについてざっと到達点を整理し、（死体吟味）
連鎖がどこで途切れたのか、最も重要なつまづきポイントを特定し、（死因特定）- そこを重点的に吟味してプロセス上の問題点を推察する（死因推定：ポストモーテム）
そのため、すべてのプロセスについてポストモーテムをする必要はない。連鎖が切れたポイントについて特に重点的にやること。#10以降はこのポストモーテムに基づいて以下のように吟味を続ける：
連鎖が切れたポイントよりも右には問題がない（＝よく実装している）が、そのポイントによってそれ以前＝左側が腐っていると判断したなら、それより左について、つまりどのように発想すべきだったかについて#10-#11で定義し#12以降で発想しなおす。AIITのPBLではほとんどのPTはこちらに該当するだろう。連鎖が切れたポイントよりも左（より大風呂敷）には問題がない（＝おもしろく発想している）が、つまづきポイントによってそのポイント以降＝右側が腐ったと判断したなら、それより右について、つまりどのように実装すべきだったかなどについて#10-#11で問題定義し#12以降で実装方法を計画しなおす。AIITのPBLではほとんどないかも…。
つまりポストモーテムでコケるとそれ以降の再吟味がコケる！
以下では連鎖上の各プロセスについて、どのような点に着目していけばいいかのヒントを述べる。
-
誰のために(for whom)*
-
何を問題だと思って(what for)*
-
何をしているのか(what)*
-
HMW：一体何を解いていたのか？*(プロセスの便宜上、文法的にはHOW（どうやったら実現できる？）を聞いているが、実際には最終的に生成されるものはwhat（どんな人工物をつくれば実現できます）.HMW A?のAにはコンピテンシーが入る。what for, for whomが解決しているからこそ聞けるため、そのあたりを間接的に含む)
ナラティブの説得力。錦の御旗へと連綿と続く連鎖の飛躍が受け入れられるか。どうやって特定してもよいが、たとえばやること、考えることの候補：
- 解いて欲しいのか
- 例：これこれの理由から、この問題を解く意義は薄い。
- 例：どんな競合がいると調べていたのか。
- 彼らが調べていた競合についてに加え、他の競合も調べてみる。
- 例：すでにAという製品があるのにどうしてこの問題を解いたんだろう？これが敗因である
- デザインなら、人の幸せが特化しているか（ある人には💯、ある人には🤢）
- デザインエンジニアリングなら、
- 誰にとっても使いやすくて幸せ（人間中心）、もしくは
- 技術のおもしろい応用の模索（テクノロジードリブン。HCIなど） が実現できているか。
- エンジニアリングなら、錦の御旗だけ掲げていて
連鎖がブチ切れていないか。
- デザインエンジニアリングなら、
- 問題設定には問題がないと感じるなら、それでも問題ない（まだ卵は割れていない）
できるようになることのおもしろさ。コンピテンシーに需要があるのか。できるようになることの新規性、有用さ、特筆性。
（問題設定よりも先にやったほうがいいかも。たいていはPBLで設定されているためにわかりやすいので）プロジェクトの初期には：
- 何を実現する計画で、(what)、
- どう実現する計画で、(how)*
- それを実現するとどう嬉しいと皮算用していたのか
素人発想Think like an amateurできていたのか？を考える。たとえば：
- どんな個人的な欲求をエンジンに（what for）しているのか？「これ欲しいわ」と共感できるか？
- 誰のためになるというのか？
- 発想には問題がないと感じるなら、それでも問題ない（まだ卵は割れていない）
- feasibility: どんな技術を使って発想を実現可能にしようとしていたのか
- 何と比較して、どれくらい自分たちの提案のほうが優れていると、何を根拠に主張していたのか？
- 効果のほどはどう測定している？プロトタイプはどういうものを作成し、どうユーザーに使ってもらっている？
- 何と比較して、どれくらい自分たちの提案のほうが優れていると、何を根拠に主張していたのか？
-
- virtuous cycleを書けるか？
玄人実装do as an expertできていたのか？を考える。
- feasibility: 実現可能性はあったのか？
- なかったとしたら一体どうすればよかったのか？
- 彼らは実現可能性をどう高めたのか？（これが直接の貢献のはず。あるアイディアでできなかったことができるようになる）
- ちゃんと必要な技術を習得したのか？手を動かしたのか？
- 高度な技術を使いこなしているのか？「すごい実装だな」と思われる品質になっているのか？別に全く必須ではないが…
- なっていないとしたら何が問題で何をすればよかったのか？
- viability:
年明けまでにまずは簡易なレポートをまとめてもらう。