TeamPageの企画書「チームの問題を解決するソフトウェア」を公開！
当社の製品「TeamPage」の企画書（当時は「Traction」という名前で呼んでいましたが）は、今から約18年前の1997年の10月に作成されました。この頃の構想の多くは2002年7月に初の商用バージョンとしてリリースされるまでにTeamPageに組み込まれました。そして、その後、当社は市場やお客様から学んだ多くのことをTeamPageに組み込み、改良を重ねてきました。
この企画書は長らく社外秘扱いになっていましたが、この度封印が解かれ、CC BY-NC 4.0 ライセンスの下に公開されました。企画書のPDFファイルを閲覧・ダウンロードするには、ここをクリックしてください。
下図は、当社のグレッグ＝ロイド (Greg Lloyd) が提案書の作成当時に描いた構想図です。Lotus Notesのように制限的にハイパーテキストを使ってサイロ内の蓄積情報を利用するのではなく、Webをプラットフォームとして使うことでビジネスに必要な情報を壁や垣根を越えてリンクさせる様子が描かれています。
2002年にTeamPageを初めて世に送り出したとき、「ブログとは、誰か一人 (a person) の生の声のことだ」としばしば独断的に定義されることがありました。一般人が加工（検閲）なしに自分の意見を表明できる場所としてブログは注目されていましたが、「あるひとりの人が自分の記事を投稿しているサイトは『ブログ』だが、複数の人が集まって色々な記事を投稿しているサイトは『ブログ』ではない」という意見があったのです。
そんな論争がある中だったので、「一人ではなくチームのメンバーが『スペース』に集まり、作成されたコンテンツが時系列で並び、チーム内の情報共有が進む」というTeamPageのコンセプトはなかなか理解されませんでした。今では多くの人々が「ああ、それってつまり、FacebookのタイムラインやSlackのチャンネルみたいなものだよね」とすぐにわかると思いますが、当時の状況は今とは違っていたのです。
ただし、TeamPageの「時系列に並んだ記事」は、FacebookのタイムラインやSlackのチャンネルとは次の点で異なります。
- 記事一件一件が編集可能で、Wikiの履歴のような過去情報を完全に保持していて、いつでも元に戻せる。
- 記事には「タスク」「プロジェクト」「近況」のような「種類」を持たせたり、「コメントしている」「タスクを追加している」などの関係性情報を持たせて他の記事と紐付けたりできる。
- いろいろな条件で時系列のフローの中から記事を取り出し、ダッシュボードやコレクターなどに別の順序でストックしておくことができる。
- 統合された権限設定により、スペースの垣根を越えて記事を集めたり、検索したり、タグで集めたりすることをシンプルに実現できる。
TeamPageのコンセプトを理解してレビュー記事として紹介してくれたもののひとつに、クレイ＝サーキー (Clay Shirky) 氏による2003年の「ソーシャル ソフトウェア 〜 新世代のツールたち」(PDF) の「Traction: Weblogs grow up (14ページ)」があります。また、ジョン＝ウデル (Jon Udel) 氏も、2002年のInfoWorldで「Getting Traction 〜 トラクション社のエンタープライズ向けウェブログのシステムは、企業におけるナレッジ・マネジメントに求められるものを備えている」というレビュー記事として紹介してくれました。
このコンセプトの中心的な内容は、米国特許 7,593,954 として認定されています。
TeamPageの開発目的や構想を一言で表すと「Team Problem Solving」、つまり「チームの問題を解決すること」です。その「チームの問題」とは何でしょう？ 長くなりますが、その答えを企画書の「Team Problem Solving」のページから引用します。
Lotus Notesで「ある返信に対する返信の30番目の返信」を読むとき、あなたは「この議論全体の要旨はどこにあるんだ？」と疑問に思うことでしょう。また、注釈や黄色の蛍光ペンマークが付いた文書を上から下まで5回繰り返し読んだとき、「メンバーが付けたこれらの注釈やマーカーが果たして本当に重要な箇所なのだろうか？」と疑問に思うことでしょう。チームにとって重要なことは、人々が集まることによってもたらされる「チームワークの力＝集合知」が得られるかどうかであり、それによって素早い意思決定ができるかどうかです。つまり、チームを支えるためのツールで重要なことは、製品に搭載されている機能の数ではなく、人々の力を集合知としてまとめられるかどうかです。
文書を共有する機能や、いくつもの掲示板スレッドを立てられる機能、そしてチーム全体のプロジェクトを作成できる機能は便利なものですが、チームワークを支えるツールで最も大切なことは、仕事の成果物をチームの思考プロセスで分けて管理できるかどうかでしょう。
（以上は、1996年7月1日に刊行された「グループウェアPCウィーク」誌でエリック＝ランドクウィスト (Eric Lundquist) 氏が述べていたものの引用）
（中略）
チームメンバー間で電子技術コミュケーション（つまりメール）による情報共有を図ることは、毎朝見出しのない300個の封筒からニューヨーク・タイムズ誌を取り出して読むようなものだと言えます。メールは、メッセージを安くすぐに相手へ届けられる便利なツールです。しかし、迷惑メールをゴミ箱に捨てた後でもなお、受信箱は大量のメールであふれています。一部は返信の必要のあるメールですが、大部分は返信する必要はないがフォローしておきたいメールです。チームの誰かがCCから漏れていてメールが届いていなかったとき、あるいは紛失・削除してしまったとき、あなたが（またはチームメンバーの全員が）過去のメールを掘り返し、目的のメールを見つけてまた転送する…ということがしばしば起こります。
チームのディスカッションの場（返信を付けていく、いわゆる「掲示板」機能のこと）で共有されるのは「思考」ではなく「会話」です。あなたが何か意見を投稿し、他の誰かコメントし、さらに誰かがコメントし…と「会話」が弾むことはよくありますが、スレッド全体を眺めると、それはまるでラジオ番組の台本のように見えます。結論やテーマを探している読者（視聴者）は、その長い台本を端から端まで注意深く読まなくてはなりません。
インターネット世界 (Web) は市場のようなものです。有名な商人のおもてなしを受けても、案内人を頼んでも、自分で散策しても構いません。あなたがインターネットで何を見つけるかなんて誰にもわかりませんからね。検索エンジン、Yahoo (色々なサイトを紹介した、電話帳のような目録のこと)、RSSのようなプッシュ型通知システムを使って、役立つ「可能性を秘めている」膨大な情報を得られます。けれども、自分の目的にとって何が役立つ情報で何が役立たない情報なのかを選別しなければなりません。厳選された情報だけに絞って配信し、チームメンバーがパンクしないようにする方法を見つけなければなりません。
以上の「チームの問題」が描かれたのは今から18年前のことですが、これらの問題は今でも多くの場面で見られます。
最初のTeamPageの導入事例では、TeamPageはプロジェクト活動を行う場所として使われました。この事例では、従業員の行動記録、会話、共同作業によって作成されたものなどへ簡単にリンクできることが高い評価を受けました。TeamPage内の記事やTeamPage外部のページにタスクを登録したり、登録されたタスクを確認したりできることにより、チームの状況を眺め渡し、ユーザーごと、チャンネルごと、そして特定のスペースごとなどの切り口で把握することが簡単にできます。
当社は、権限設定の仕組みを社内だけでなく社外のグループ（例えばコンサル会社の顧客、製造業のサプライヤーや取引先など）どのように適用したら良いのかも学びました。複数の権限設定がサポートされたスペースの仕組みは、1997年の初めの提案書を作成したすぐ後にTeamPageに組み込まれました。TeamPageでは、読み取り権限のある特定のスペースに注目することもでき、また、読み取り権限のあるすべてのスペースを横断して検索したり閲覧したりできます。
アクセス・コントロール・リスト (ACL) と呼ばれる、スペース毎のユーザーとグループの権限設定モデルを用いることで、社内と社外のグループが同じTeamPageを共有しつつ、それぞれのユーザーに適切なプロジェクトに参加したりアクティビティを閲覧したりできるようになりました。スペースの垣根を越えてコメントやタスクを登録したりタグを追加したりすることも可能で、例えば社外グループのメンバーが投稿した質問の特定の段落事項に関して、元の質問投稿との関連付けを保持したまま社内メンバーだけでより深いディスカッションができます。業務の内容に基いて権限を設定すれば、その権限設定は、アクティビティ一覧（タイムライン）、通知、ダイジェスト、検索など、TeamPage全体に適用されます。
チームワークを支えるコラボレーションツールがメールを駆逐するためのツールなのかについては以前のブログ記事で触れましたが、1997年の提案書では、TeamPageはメールに代わるものとして描かれると同時に、メールは情報を記録したり配信したりするための重要な手段であるとも認めていました。
そのメール機能のひとつであるダイジェストは、ベータ版段階のTeamPageを使ったお客様からのリクエストに応じて搭載された機能のひとつです。ダイジェストは、前配信時からの間に投稿された新着のタイトルリンクや本文の要約が含まれた「まとめのメール」で、購読ユーザー（配信先ユーザー）の読み取り権限によってフィルタリングされます。つまり、配信先ユーザーによって配信内容は異なります。（全員同じ読み取り権限が設定されていれば全員に同じ内容のダイジェストが配信されます）
今日のTeamPageには、新着や編集などを一件ごとにお知らせするメール通知機能がありますが、ダイジェストは今日でもよく使われています。一件ずつのメール通知機能には「メールで返信したら元記事にコメントとして投稿機能」があるので便利なのですが、すべての新着や編集などの通知を受けるとメールの数が増えて煩わしくなるので、重要な案件については一件ごとのメール通知を利用し、他のことに関してはダイジェストでまとめて読むのがオススメです。ダイジェストは、いわば「メールで読むタイムライン」ですね。ちなみに、この「通知メールに返信して元記事にコメント投稿」機能は、ある大きなコンサルティング会社からの要望に基いて開発されました。
これらの「機能」は単体で使われるだけのものではありません。「機能」を組み合わせてそれぞれの業務用の「アプリ」としてより活用できるようになります。品質管理、製品開発、製品サポート、コンサルティング、競合情報調査など、チームワークが必要な業務にピッタリなTeamPageにしてみましょう。詳しくはソリューション紹介ページをご覧ください。ご相談はいつでもお気軽にどうぞ。
関連記事
リンクや編集の仕組みからハイパーテキストとジャーナルの設計を解く
I18N ERROR: @tsiskin#footer_RSS_Feed