gists

Kolfschoten & de Vreede (2007) 読解メモ

論文: The Collaboration Engineering Approach for Designing Collaboration Processes
出典: CRIWG 2007, LNCS 4715, pp. 95–110

1. 論文の概要

Collaboration Engineering（CE）は、専門ファシリテーターなしで実務者が自力で繰り返し実行できるコラボレーションプロセスを設計・展開するアプローチである。本論文はCEの「Way of Working」、すなわちプロセス設計の手順を5ステップで体系化し、計40名による反復評価でその有用性を確認した。

背景にある課題

GSS（グループ支援システム）やファシリテーションは組織の協働を改善できるが、コアビジネスプロセスを直接支援しにくい、収益が不確実、必要なスキルの習得・移転が困難、といった理由で組織への定着が難しい。CEはこれらの課題に対し、プロセスを標準化・スクリプト化して実務者に移転するという方法で対処する。

設計アプローチ（5ステップ＋継続的文書化）

Task Diagnosis（課題診断） — 目標・成果物、ステークホルダー、リソース、実務者の要件と制約を明確化
Task Decomposition（タスク分解） — プロセス分解（6つの協働パターン: Generate, Reduce, Clarify, Organize, Evaluate, Build Consensus）と成果物分解（Input, Structure, Focus, Shared Understanding, Commitment, Empathy）の2軸で活動単位に分解
ThinkLet Choice（ThinkLet選択） — タスク適合性・グループ受容性・リソース再利用性・実務者移転可能性の4軸でトレードオフを判断し、分類マップと組合せマップを活用して選択
Agenda Building（アジェンダ構築） — ThinkLet列にイントロ・休憩・意思決定ポイント等を加え、アジェンダ表とFPM（Facilitation Process Model）を作成
Design Validation（設計検証） — パイロットテスト、ウォークスルー、シミュレーション、専門家評価の4手法

Documentation（文書化）は全ステップと並行して継続的に実施。

2. CEで何から何がつくれるのか

入力: 繰り返し発生する高価値な協働タスクとその周辺情報（目標、ステークホルダー、リソース、実務者のスキル等）
出力: 実務者が自力で実行できるプロセス設計一式（アジェンダ表、FPM、設計テンプレート／スクリプト）
実例: 論文図5の「協働コードインスペクション」プロセス。DirectedBrainstormで欠陥洗い出し → ChauffeurSortで分類 → 重複除去 → 結果提出、という流れをThinkLetで構成

3. ThinkLetとは何か

ThinkLetは「名前がついた、スクリプト化された、再利用・移転可能な協働活動」であり、特定のコラボレーションパターンを再現的に引き起こすための標準化された”技”。ソフトウェア工学のデザインパターンと同じ発想で、ライブラリとして蓄積される。

DirectedBrainstorm（Generate系）: 特定の問いで方向づけたブレインストーミング
ChauffeurSort（Organize系）: ファシリテーター（実務者）が”運転手”役としてグループの指示を受けながら分類

ThinkLetは自由に作れるものではなく、繰り返しの実践と検証を経て「このパターンを再現的に引き起こせる」と示す必要がある。ただし既存ThinkLetの修正やインスタンス化は設計ステップ内で認められている。

4. 使い手の構造：二層モデルとその含意

CEは使い手を明確に二層に分けている。

	Collaboration Engineer（設計者）	Practitioner（実務者）
役割	ThinkLetを選び、組み合わせ、プロセスを設計	完成したプロセスを現場で繰り返し実行
ThinkLetへの関与	ライブラリ全体を扱う	直接触れない（完成レシピを受け取る）
必要スキル	CE設計手法＋ThinkLet知識	ドメイン専門性＋短期訓練

実務者にとっては「決まり切ったプロセス」として整備されている。これがCEの強み（導入容易・持続可能）であると同時に、現場適応性の面では限界にもなりうる。実務者が状況に合わないと感じた際の裁量や即興については深く論じられておらず、設計の「ロバストさ」でカバーするという思想が読み取れる。

5. ThinkLetのライフサイクルに関する議論

本論文のスコープの確認

本論文はCEの「プロセス設計の手順」に集中しており、ThinkLetの作り方・いじり方は守備範囲外である。ただし、これはCE研究全体で未整備という意味ではない。

本論文の時点で整備済みの関連研究

ThinkLetの概念的基盤 → 参考文献16（Kolfschoten et al. 2006）
パターン言語としての体系 → 参考文献19（de Vreede et al. 2006）
スクリプトのテンプレートと文書化 → 参考文献18
ルールベースの介入による予測可能なパターン → 参考文献17

本論文はこれらを前提として「部品をどう組み合わせてプロセスを設計するか」に特化している。

本論文が今後の課題として示唆するもの

ThinkLetの代替案とその品質影響の文書化
設計ガイドラインに基づく自動検証
設計文書の自動生成
コンピュータ支援設計ツール（CACE）の開発

これらは、ThinkLetライブラリの進化的管理やフィードバックの蓄積・反映が必要だという認識を暗に示している。ただし、実務者→設計者のフィードバックループ、設計者→ライブラリへの還元ループ、ThinkLetの品質管理ガバナンスといった運用面は、本論文では具体的に論じられていない。

6. 全体を通じた所感

本論文はCEの設計手法を「手順として使える形」に体系化した貢献がある。一方で、論文自身が位置づけを明確にしている通り、これはCE研究の一部分（Way of Working の中のプロセス設計）であり、ThinkLetの構築・検証・保守、実務者からのフィードバック反映、ライブラリのガバナンスといった周辺の問いは、別の論文群や今後の研究に委ねられている。

This site is open source. Improve this page.