thinkLetを一つ完成させるために何を書くか
根拠論文: de Vreede, Kolfschoten & Briggs (2006) “ThinkLets: A Collaboration Engineering Pattern Language”, IJCAT, Vol.25, Nos.2/3, pp.140–154
実例: Appendix A — LeafHopperのフルドキュメント
書くべき内容
thinkLetのドキュメントは3つの大区分から成る。
1. Identification（識別）
- Name：キャッチーで覚えやすく、そのthinkLetが引き起こすグループダイナミクスを連想させる名前
- Picture：記憶と想起を助けるための絵
- What’s in a name?：名前とメタファーの関係の説明。例：LeafHopperは「葉から葉へ飛び移る小さな虫」→ 参加者がトピックからトピックへ自由に飛び移る様子を表す
2. Script（実行の核）
- Overview：thinkLet全体の短い説明（何が起こるかを1段落で）
- Recommended Script Elements：ファシリテーターが行うこと（Do this）と言うこと（Say this）の具体例
- Rules：役割（Role）ごとに、制約つきの行為を列挙したリスト。例：「任意のページに任意の数の投稿を追加せよ」「ページトピックに関連する投稿のみ追加せよ」
- Parameters：
- 入力パラメータ：実行時に具体化すべき変数（例：Topic_List、Contribution_Prompt）
- 出力パラメータ：このthinkLetが生み出す成果物の記述（例：トピック別に整理された未フィルタのコメント集）
- Required Capabilities：参加者に提供すべき機能的条件。技術は指定せず条件だけ記述する（例：「トピックごとのページがあり、参加者が任意のページを閲覧・書き込みできること」）
- Actions：参加者が行う操作の列挙（例：add ideas、read ideas、choose topics）
3. Selection Guidance（選択指針）
- Patterns of Collaboration：このthinkLetが引き起こす協働パターン。Primary（主）とSecondary（副）を指定（例：Primary = Generate、Secondary = Organise）
- Choice Guidance：
- 「このthinkLetを選べ」条件（例：「事前に複数トピックでのブレストが必要とわかっている場合」）
- 「このthinkLetを選ぶな」条件＋代替thinkLet（例：「トピックを特定の順序で扱いたいならDealersChoiceを検討せよ」）
- Insights：使い方のコツ、注意点、比較知見（例：「3つの質問を同時に出すLeafHopperのほうが、1つの複合質問より多くのアイデアが出た」）
- Success Story：実際の適用事例の物語的記述
- Combinations：推奨される前後のthinkLet（Successors / Predecessors）
書く順番（論文の規定ではなく、構造からの推測）
論文はドキュメントの構造を示しているだけで、書く順番は規定していない。ただし、内容間の論理的な依存関係から、以下の順が妥当と考えられる。
Step 1：核を決める — Rule・Action・Capability
「このthinkLetは何をするものか」を定義する。どんな行為を、どんな制約のもとで、どんな機能的条件を使って行うか。ここがthinkLetの本質であり、他のすべてがこれに依存する。
Step 2：パラメータとスクリプトを書く
Ruleが決まれば、実行時に何を具体化する必要があるか（Parameter）が見え、それを参加者にどう伝えるか（Script Elements）が書ける。
Step 3：選択指針と事例を書く — Selection Guidance
Choice Guidance（いつ使い、いつ使わないか）、Insights（コツ）、Success Story（実績）は、実際に使ってみた経験や、他のthinkLetとの比較がなければ書けない。したがって最後に近い段階になる。CombinationsもSuccess Storyも同様。
Step 4：名前とメタファーを付ける — Identification
中身が固まってから、そのダイナミクスを的確に連想させる名前・絵・メタファーを選ぶほうが精度が高い。
補足：thinkLetの出自と未整備の課題
thinkLetはどこから来たか
本論文によれば、初期のthinkLetは「熟練ファシリテーターがフィールドで繰り返し成功させた実践」を体系化したもの。その後「新たに設計されたもの」や「繰り返しの実践から自然発生したもの」が加わった。つまり出自は職人的な暗黙知の抽出であり、体系的な設計手順ではなかった。
未整備と明言されている課題
論文の結論部で、以下が今後の研究課題として挙げられている：
- thinkLetが引き起こす各協働パターンの理論的基盤の確立
- thinkLetの選択・組合せに関する設計ガイドラインとヒューリスティクスの確立
- thinkLetを公認コレクションに登録するための基準とプロセスの開発
3点目が示す通り、2006年時点で「thinkLetをどう作り、どう検証し、どうライブラリに登録するか」は明文化されていない。