Clear Collaboration とは プリジェクト（Preject） の手法である。
プロジェクトとは、正式に前に進める活動と言える。前に進むためにはマネジメントが必要であり、マネジメントとはギャップのモニタリングであるから「理想の定義」と「現状の計測」が必要となる。この性質上、統一性を優先した上で、強い規律をもってチーム全体を推進せねばならず、ハードスキル以前にソフトスキルが要求される。それもプロジェクトが想定した型に適応できるかどうかという適応性が最重視される。過激にたとえるならカルトのようなもの だ。特に人気のある信仰の一つは「ハードワーク」であり、この高負荷なあり方を正当化するためにリーダーはビジョンと報酬を使う。現代人も無知ではなく、このようなカルト的なあり方に懐疑的な視線を向け始めている。静かな退職は現状最も有名なカウンターカルチャーの一つだろう。
対して、プリジェクト（Preject）とは、プロジェクトの前段階で行う探索的な活動である。本書でもソフトスキル開発手法としてエクスプロラトリとクリエイティブ・シンキングを紹介したが、これらはまさにプリジェクト的だ。マネジメントを行わず、最低限の制約だけ決めて、あとは自由に行動して、しかし個人個人が深く集中して収集と統合を行い、何らかの結論を提示する。
無論、プリジェクトだけではビジネスは成立しない。しかしプロジェクトだけではカルトの信者しか生き永らえることができず格差が生じてしまう。このような構造に抗うには、プロジェクト以外のあり方を開拓せねばならない。プリジェクトはその一つである。プロジェクトに不向きな者であっても、プリジェクトであればこなせるかもしれない。逆にプロジェクトに向いている者は、プロジェクトに専念すればいい。役割分担である。これにより多様性が増加し、VUCA な現代であってもビジネスの推進と従業員の尊重を両取りできるようになる。
プリジェクトを非同期的に推進するための手法である。
全体の流れ:
つまりテーマに関することを何でも書き込んで、会話や議論を行う。観点は 3T に従い、各ページは Talk → Topic → Task と推移していく。まずは Talk から始めつつ、次第に Topic や Task が生まれていくイメージだ。そうしてページを増やしながら、最終的に提出したい本質的なページを決める（あるいはつくる）。これを ブースター と呼ぶ。後でプロジェクトを始める際に持ち込む燃料だと思っていただければ良い。
3T について述べよう。
Talk
Talk とはページの初期状態であり、雑談的なページを表す。誰が何を書いてもいいし、何の分担や制約もない。何ならテーマに関係しない内容でも良い。それこそ「欲しいものリスト」ページをつくって、各自欲しいものを書き込んでも良い。誰がどういうものを欲しがっているか知れて、ちょっとした息抜きになるだろう。仕事とは無関係だが、このような雑談的なやりとりは重要である。いわば 非同期的に雑談をしている。
Topic
次に Topic とは Talk の次に至る状態であり、Topic ページには 当事者 が一人存在する。当事者とはそのページを盛り上げる者を指し、自ら積極的に深堀りをしたり、他ページから言及してメンバー達に存在を知らせたりする。担当者というほど重たいものではないが、Talk ほど何も決まっていないわけではない。つまり Talk ページに対して誰かが当事者になると、そのページは Topic になる。Topic は Talk よりも積極的に盛り上がるはずだ。
なお、当事者の表明はキューとして行う。当事者は最初に表明をした者となるが、それ以外の者も表明できる。最初の当事者が立ち行かなくなった場合は、次の者が代理的に推進する。ただし、これはバックアップ的な措置であり、当事者自体は常に一人であることに注意したい。つまり Topic をどう進めるかは一人の当事者が自由に決めていい。当事者は Topic の意思決定権を持つ。スムーズに意思決定させるため、当事者は一人でなくてはならないのだ。
もちろん、Clear Collaboration では誰でもページをつくれるため、ある Topic が気に入らないのなら、単にそれを複製して別バージョンをつくればいい。
Task
Topic の次に至る状態が Task である。これは当事者の存在に加えて、具体的な「タスクリスト」が追加されたものである。タスクリストは当事者がつくるべきだが、他メンバーも提案できる。
この時点ではタスクを実際にやらなくてもよい。すぐに終われるものならやってもいい（やった結果や得られた知見も 3T で別途ページ化する）が、そもそも Clear Collaboration ではタスクの実行や管理は想定していない。Clear Collaboration はプリジェクトであり、思考や検討を行う段階なのだ。
どちらかと言えば、Task では「今後このテーマをプロジェクトとして推進する際に必要なタスク」を事前に調べて整理しておくものである。
開発者であれば馴染み深いだろうが、関数、クラス、モジュール、コンポーネントといった部品的な概念はシンプルである。単一の機能や意味を表現できている。KISS 原則といったりもするが、シンプルな部品を組み合わせることで複雑性を実現するのである。この方が応用が利きやすいし、メンテナンスもしやすい。
同様に、Clear Collaboration でも ページは単一性を意識してつくるべきだ。もしページ内に複数の話題が混在するようなら、意識的に分けるべきである。典型的には Talk ページにて複数の話題が生えてくるので、それを別ページに移す。この単一化作業は Clear Collaboration の肝であり、ソフトウェア開発で言えばリファクタリング、あるいは技術的負債をつくらないためのクリーンなコーディングに相当する。手を抜いてはならない。
もちろん、ページを識別するものはページ名であるため、ページ名も徹底的にわかりやすい内容でなくてはならない。文章的でも良いし、結論をページ名にしたっていい。むしろ一目見て何を言っているかがわかると認知コストも減る。ソフトウェア開発で言えばリーダブルコードのようなものだ。
ブースターとは、Clear Collaboration において最終的に提出するページを指す。
できれば Task ページが良いが、Topic や Talk でも良い。また何ページ指定するかは自由である。たとえば Clear Collaboration により 1000 ページをつくって、そのうちブースターは 20 ページかもしれないし、もっと多いか、少ないかもしれない。小さなプリジェクトだと 200 ページつくって、そのうちブースターは 10 ページくらいかもしれない。
Clear Collaboration は QWINCS のうち、ウィキ・Issues・Notes のいずれかを使うことを推奨する。要件で言えば、次のとおり。
ウィキの場合は Cosense が良いだろう。他のウィキ、特に歴史の古いウィキは要件を満たせるほどのポテンシャルがない。
Issues の場合は GitHub Issues または Discussions で事足りるが、過去の Issue が埋もれる可能性が高い。たとえば 1000 件以上書いた後、過去の Issue を素早く探して関連付けることができるだろうか。私は正直厳しいと思っている。生成 AI を絡めた検索や発見のシステムを自製せねばならないだろう。これができないなら、Issues は諦めた方が良い。
Notes のツールは色々あるが、おそらく厳しい。上記の要件は満たせないと思う。自分一人で使うならまだしも、Clear Collaboration では複数人が好き勝手に書き込みまくる。Notes のポテンシャルでは、よほどルールを統一しなければ厳しいだろうし、そのようなルールは人間にとって煩雑すぎる可能性が高い。少なくとも私は Clear Collaboration が成立するイメージを描けない。
そういうわけで私は Cosense をおすすめする。
最後にチャットやホワイトボードでは難しい理由も述べておく。Clear Collaboration ではトピック指向――一つの話題を一つのページで表現することが最重要である。ある話題 A はページ A に書いてある、という状態を維持したいのだ。それも各自が好き勝手に書き込んで 3T を増やしていきたいわけで、ページの追加やリネームも自由に行えねばならない。Slack や Teams のようなビジネスチャット、あるいは Miro のようなデジタルホワイトボードでは到底及ばない。