「叩かれ台」を使うとフィードバックが早い

「叩かれ台」って言葉使いますかね。ワタシは割と使うのです。私案でもドラフトでもいいのですが、大体、案を出すと参加するみなさんは好き勝手いうものですが、そうした意見を拾いたいので叩かれ台を作っています。

いや、好き勝手言ってもらうのが目的なのでそれで目的を果たしているのでその意味では大成功なのですが。あまりに完成度が高いとあまり意見も出なくて後で「ちゃぶ台返しされるのでは」と不安が１ミリほど感じてしまいます。はい。

叩かれ台は概念である

例えばシステム方式の構成はいきなり詳細な物理で絵を描かないものです。書いてもいいですが、方式が決まるまでは何度も書き直すわけです。機能要件でも非機能要件でも指摘はつくものです。

だったら、論理構成で、それもサーバなどはクリップアートのようなアイコンなんて使わずに白地に黒線だけの枠を描いてあればいいのです。

描く意味は、方式を決めたいだけですから。

方式を決めるとうことは、それを描いている設計者の設計思想を概念化したものを表している必要があります。そこには見栄えのいいアイコンは必要ありません。

大事なことは、書き手の思考を概念化して表現できているか、です。

「資料名（叩かれ台）」とするだけでフィードバックが早くなる

何かしらアイデアを描くにしても、割とシステムエンジニアは完璧を目指して書き切ろうとする傾向があります。

＃観測範囲の中で

でも、ファイル名や資料のタイトルの後ろにカッコ書きで「（叩かれ台」」と入れておくと、あら不思議。

ミーティングに参加するメンバは偉い人も含め、

「叩かれ台なら考え方だけ見ておけばいいな」

と思ってくれるので設計レビューのように注意して描く必要なくなるんです。

その分、早く作って早く叩かれ台を見せて、早くフィードバックを得ましょう。

叩かれ台は抜けているところを見つけるために描く 

つまり、叩かれ台は概念を描いて、早いフィードバックをもらって、しっかりと本来のアウトプットにつなげるための手段なんですね。

後ですね、叩かれ台を揉む場でわかることがあるんです。参加した人がその叩かれ台に対して

「どんな前提条件を持っているか」

 がわかります。「それじゃ○○と矛盾する」とか「アレに間に合わなない」とか、そうした個々のメンバが気にしていることを引き出せる場を作れるんですね。

そうでないと、一生懸命作り込んだ資料に対して後出しジャンケンを食らった気分を味わうことになりますから。