なぜ、WorkFlowyという道具は、「やりたい」のつまみ食いの集積を完成文書へ統合することを可能にするのか？

1．はじめに

昨日、これを書きました。

• そのときどきの「やりたい」のつまみ食いを、文書の完成へと統合できる_文書作成ツールWorkFlowyの可能性(2)

今、私は、「WorkFlowyによる文書作成は、実に楽しい。」という主観的な経験を観察することを通じて、文書作成ツールとしてのWorkFlowyの可能性を考察することに取り組んでいます。この記事では、この考察の一環として、「やりたい」をつまみ食いしているうちに、いつの間にか文書の完成へと近づいている、ということを検討したのでした。

●

ところで、「やりたい」のつまみ食いを完成文書へ統合する、という文書作成方法は、何もWorkFlowyでしかできない方法ではありません。他の道具であっても、「やりたい」のつまみ食いを積み重ねて文書を完成させることは、理屈上、可能だと思います。

他方で、私自身は、WorkFlowyという道具を使い始めるまでは、「やりたい」のつまみ食いを完成文書へ統合する、という文書作成方法を、うまく進めることができずにいました。理屈としては可能だし、合理的な方法だということもわかっていたのですが、具体的な文書を実際に作成するときに、この方法をうまく活かすことができていませんでした。

つまり、「やりたい」のつまみ食いによって文書を完成させる、という文書作成方法は、少なくとも私自身にとっては、WorkFlowyという道具を使うことによって、はじめて現実的に可能な方法となったのです。

そこで、今回は、「なぜ、WorkFlowyという道具は、「やりたい」のつまみ食いの集積を完成文書へ統合することを可能にするのか？」という問いを検討します。

さらに、この問いの検討を通して、「「やりたい」のつまみ食いの集積を完成文書へ統合する」という文書作成方法を可能にしてくれる道具の条件を、多少なりとも浮かび上がらせてみたいと思います。

2．なぜ、WorkFlowyという道具は、「やりたい」のつまみ食いの集積を完成文書に統合することを可能にするのか？

(1)　文書完成のためのタスクの管理とタスクの実行の両方をうまく担ってくれる

まず、WorkFlowyという道具は、文書完成のためのタスクを管理してくれます。

●

どのような方法で文書を作成するにせよ、ひとつの文書を完成させるには、それなりのタスク管理が求められます。ですが、どのような文書作成方法をとるかによって、タスク管理を必要とする程度には、差があります。

では、「やりたい」作業をつまみ食いすることによって文書を作成するという方法は、どうでしょうか。

ものすごく程度の高いタスク管理が求められるような気がします。「やりたい」だけをつまみ食いし続けた結果の集積を、ひとつの完成文書に統合することは、（少なくとも私の場合、）高度なタスク管理なくして、不可能です。

●

WorkFlowyは、文書作成のためのタスクを、うまく管理してくれます。トピック階層構造やWorkFlowyのURL、優れた検索機能やタグ、StarページにCompleteなど、WorkFlowyには、タスクを管理するための優れた機能が備わっているからです。

でも、それだけではありません。WorkFlowyは、優れた文書作成ツールでもあります。特に、文章を書くツールとして優れています。

そのため、WorkFlowyによる文書作成のためのタスク管理の特徴は、タスクの管理とタスクの実行の両方をうまく担ってくれる点にあります。タスクを管理しながら、同時に、タスクをどんどん実行していくことができるのです。

文書完成までのタスクの全体を、トピック階層構造という形で具体的に認識しながら、同じトピックを使って、実際に文書完成のために必要な作業をすすめることができます。WorkFlowyは、こんな特徴を持つ道具です。

(2)　性質の異なる複数の作業を、互いに独立に、並行して進めることができる

次に、WorkFlowyという道具を使えば、文書作成における性質の異なる複数の作業を、互いに独立に、並行して進めることができます。

●

文書は、いろんな種類のたくさん部品を組み立てて作る機械のようなものです。

ひとつの文書を完成させるには、いろいろな種類の部品が、たくさん必要です。また、こんないろいろな種類のたくさんの部品を、しかるべき手順で、しかるべき位置に組み立てなければ、文書は完成しません。

このように、ひとつの文書を完成させるためには、様々な性質を持つ膨大な数の作業が必要なのですが、これらたくさんの作業の多くは、互いに絡み合っていて、独立していません。つまり、「この作業は、あの作業の後にやらなければいけない」とか、「この作業とあの作業の間に、その作業を入れなければいけない」とか、「この作業はすごくくたびれるので、あの作業とは別の日にやりたい」というように、複数の作業を行う順序や段取りに、それなりの制約があります。

そのため、全然別の作業をてんでバラバラに並行して進める、という方法で文書を作成するのは、普通に考えると、わりと難しそうな気がします。

●

しかし、やってやれないことはありません。

機械の比喩でいえば、これは、「未完成の部品を組み立てに使ってしまい、全体を組み立ててから、未完成の部品を完成させる」とか、「最終的には遠く離れた場所に組み込まれる複数の部品を、ひとつの場所で同時に作る」といった製造方法です。

物理的な機械を組み立てるなら、こんなことはできません。でも、文書は物理的な機械ではないので、やりようによっては、不可能ではないのです。

とりわけ、WorkFlowyを使えば、かなり現実的になります。WorkFlowyの基本的な枠組みや機能自体が、性質の異なる複数の作業を互いに独立に並行して進めることと、とても相性がよいためです。

WorkFlowyの基本的な枠組みは、

• テキストをトピックに格納する
• トピックを階層構造に組み立てる

という2段階です（WorkFlowyがテキストを管理する枠組みは、「テキストをトピックに格納する」と「トピックを階層構造で管理する」の2段階）。

これを文書作成に対応させるなら、

• テキストをトピックに格納する＝文書を構成する部品を作る
  • 例
    • 資料を集める
    • 本文の文章を書く
    • 具体例を説明する
• トピックを階層構造に組み立てる＝コンテンツを配置し、ひとつの文書へと組み立てる
  • 例
    • 集めた資料を並べる
    • 書いた文章の断片を組み立てる
    • 抽象的な理屈に対応させる形で具体例を配置する

という感じになります。

さらに、トピック移動機能やZoom、折りたたみといったWorkFlowyの基本的な機能が、これを強力にサポートしてくれます。

• トピック移動機能
  • トピックの中身をいじることなく、トピックの位置づけを自由に試行錯誤できる
  • （部品自体をいじることなく、部品の組み立てを気軽に試行錯誤できる）
• Zoom
  • そのトピックがどこに存在していようと、そのトピックだけを独立した存在であるかのように扱うことができる
  • （部品が現時点でどんなところに組み込まれていようと、その部品だけを作り直したりつくり込んだりできる）
• 折りたたみ
  • その瞬間に必要のない細部を隠して、文書の大筋を組み立てることに集中できる
  • （部品を組み立てている最中に、まちがえて部品の内部をいじってしまうことのないようにしておける）

そのため、WorkFlowyを使えば、こんな文書作成のプロセスが可能になります。

• 文書全体の骨子を組み立てる作業を進めながら、ピンときた一部分だけを完成品レベルに仕上げる
• 抽象的な説明を書く作業と、具体例をあげる作業を、別々に行う
• 文章のリズムや流れは気にせずに論理だけをつなげていって、後で、接続詞や語尾を推敲して、文章のリズムや流れを作る

このように、WorkFlowyで文書を作成するなら、文書を完成させるまでに必要なたくさんの作業を、ある程度、互いに独立に、並行して進めることができます。このことが、「やりたい」作業のつまみ食いを同時並行で進めることを可能にしています。

(3)　「やりたい」をつまみ食いした成果のすべてが、ひとつの場所に集まっている（ポケット一つ原則）

WorkFlowy最大の特徴は、「アウトラインをひとつしか作れないこと」です。「ワンライブラリ指向」「シングルライブラリアプリ」ともいいます。

WorkFlowyにはファイル概念がありません。WorkFlowyで扱うすべてのデータは、ただひとつのアウトラインの中に蓄積されています。

アウトラインをひとつしか作れないことは、一見、不便です。しかし、この枠組みは、うまくハマると、大きな価値を生み出します。この理由のひとつは、いわゆる「ポケット一つ原則」を、ごく自然に実現してくれるためです。

●

「ポケット一つ原則」とは、『「超」整理法』において野口悠紀雄氏が提唱する原則です。置き場所をひとつに定めることによって、情報の散逸を防ぎます。

• クラウドと「ポケット一つ原則」は、相性抜群。文章とメールとタスク、3つの「ポケット一つ原則」
• 文章を書くツールとしてEvernoteを使うことのメリット　テキストデータのポケットひとつ原則

「ポケット一つ原則」は、情報管理一般に広く妥当する原則なので、文書作成のためにも大切です。どのような方法で文書を作成するとしても、「ポケット一つ原則」を気をつければ、必ず実益があります。

ですが、「やりたい」のつまみ食いの集積を統合して文書を作成する、という方法で文書を作成するなら、とりわけ、「ポケット一つ原則」が大切です。「ポケット一つ原則」なしには、「やりたい」のつまみ食いの集積を統合して文書を作成する、という方法は成り立たない、といっても過言ではないと思います。

なぜなら、つまみ食いされた「やりたい」の成果は、ものすごく散逸しやすいためです。何らかの対処を取っておかないと、どれだけたくさんの「やりたい」をつまみ食いしても、その成果がいろいろな場所に散逸し、埋没し、結局何も進みません。

「やりたい」のつまみ食いを完成品としての文書に結実させるためには、「ポケット一つ原則」の助けを借りることが、絶対に必要なのです。

●

そこで、WorkFlowyです。

WorkFlowyなら、自然と、「ポケット一つ原則」が実現されます。ことテキストデータに関して言えば、これ以上ないほど理想的な「ポケット一つ原則」を実現するツールが、WorkFlowyです。

ですから、WorkFlowyで「やりたい」をつまみ食いしていけば、つまみ食いの成果は決して散逸せず、埋没もしません。つまみ食いをしているうちに、いつの間にか、文書を完成させるための作業の大半が終わっている、ということだって、珍しくありません。

だからこそ、WorkFlowyを使えば、「やりたい」のつまみ食いの集積を文書の完成へ統合する、とう文書作成方法が可能になります。

(4)　ある作業から別の作業へ切り替える際のロスが少ない

ある作業から別の作業へ切り替える際のロスが少ないことも大切です。

●

そのときそのときの「やりたい」に従って作業をつまみ食いするためには、取り組む対象の作業を切り替える機会が増えます。

文書Aのための作業aを「やりたい」と感じ、作業aをつまみ食いしているうちに、だんだんやりたい気持ちが減ってきて、文書Bの作業bを「やりたい」と感じたら、作業bに切り替えます。作業bをつまみ食いしているうちに、文書Cの作業cを「やりたい」と感じたら、作業cに切り替えます。私の場合、1時間で5,6回切り替えることも、普通です（多すぎかもしれませんが。。。）。

でも、取り組む対象の作業を切り替えるためには、切り替えること自体に、時間や手間がかかります。気持ちを切り替えるとか、頭の中を整理するといった内面的なものだけでなく、パソコンの画面をどうするかとか、どんな紙を用意するか、といった、即物的で具体的なものも、軽視できません。短い時間で何度も何度も切り替えるなら、切り替えのたびに書類を準備したりファイルを探したりといったロスが発生していては、どの作業もなかなか進まないためです。

だから、「やりたい」のつまみ食いを文書作成に活用するには、ひとつの作業から別の作業へと切り替えるためのロスが少ないことが大切です。

●

WorkFlowyはどうかといえば、ある「やりたい」作業から別の「やりたい」作業に切り替えることがとても得意です。文書Aのための作業a1から作業a2に切り替えるだけでなく、文書Aのための作業aから文書Bのための作業bに切り替えることも得意です。

なぜかといえば、まず、WorkFlowyが「ただひとつのアウトライン」だからです。WorkFlowyにおいて作成中の文書は、すべてWorkFlowyの「ただひとつのアウトライン」の中に存在しているため、文書Aのための作業a1と作業a2はもちろん、文書Bのための作業bも、文書Cのための作業cも、すべて同じアウトラインの中での切り替えだからです。

そして、WorkFlowyにおける作業の切り替えは、具体的には、表示するトピックを切り替えることによってなされます。この表示するトピックの切り替えとは、すなわちZoomなのですが（続・WorkFlowyのZoomの基本「Zoomの本質と4つのZoom」）、WorkFlowyのZoomは、とても優れた機能です。

とりわけ、「WorkFlowyのURL」によるJumpとアドオン「ShortcutKey2URL」を組み合わせれば、キーボードの上を10本の指を動かすだけで、アウトラインの中のどこだって、一瞬で表示を切り替えることができます。

• WorkFlowyの中核機能「Zoom」の説明（の入口）
• 「WorkFlowy専用Firefox」の中を、キーボードショートカットで動き回る

WorkFlowyなら、作業から作業への切り替えロスを、とても小さく抑えることができます。

だから、WorkFlowyなら、「やりたい」をつまみ食いしても、ロスが問題になりません。

(5)　つまみ食いを完成文書の中に位置づけることを、何度も試行錯誤できる

最後に、WorkFlowyなら、ばらばらにつまみ食いしたたくさんの個別作業を、完成文書という全体の中に位置づけることを、何度も試行錯誤できます。つまみ食いの集積を完成文書に統合するには、つまみ食いした個別作業を全体の中に位置づけることを、何度も実際に試してみることが必要なのですが、WorkFlowyなら、この試行錯誤を簡単に行えるのです。

●

「やりたい」作業を全力でつまみ食いし続け、その成果をひとつの場所に集積し続ければ、文書を完成させるために必要なだけの要素を揃えることは、それほどむずかしいことではありません。「やりたい」には大きな力があります。「やりたい」が生み出すものをひとつの場所へと集約すれば、ひとつの文書が必要とする要素は、あっというまに集まるはずです。

でも、要素を集めるだけでは、文書は完成しません。文書を完成させるには、集めた要素を、完成文書という全体の中に位置づける必要があります。

●

WorkFlowyは、個別の要素を全体に位置づけるのが得意です。

トピックの階層構造自体が、部分と全体の構造を示しているから、という点もあるのですが、トピック移動機能によって、階層構造の組み立てを何度もくり返し試行錯誤できることの方が重要です。

WorkFlowyにおいて、個別の要素の全体への位置づけ作業は、トピックを階層構造に組み立てることによって、なされます。重要なことは、この作業は、何度もくり返し行われることです。

WorkFlowyのトピックは動き続け、WorkFlowyのトピック階層構造は流動的に変化し続けます。トピックが動き、トピック階層構造が変化し続ける中で、個別の要素の全体への位置づけがくり返し試行錯誤され、その結果、個々の要素は、徐々に、全体における然るべき場所に位置づけられていきます。

だから、WorkFlowyを使えば、「やりたい」のつまみ食いを、文書作成全体の中に位置づけることができるのです。

3．おわりに

「なぜ、WorkFlowyという道具は、「やりたい」のつまみ食いの集積を完成文書へ統合することを可能にするのか？」という問いに対する現時点での私の答えは、次の5つです。

• (1)　WorkFlowyは、文書完成のためのタスクの管理とタスクの実行の両方をうまく担ってくれるから
• (2)　WorkFlowyを使えば、性質の異なる複数の作業を、互いに独立に、並行して進めることができるから
• (3)　WorkFlowyなら、「やりたい」をつまみ食いした成果のすべてが、ひとつの場所に自然と集まるから（ポケット一つ原則）
• (4)　WorkFlowyは、ある作業から別の作業へ切り替える際のロスが少ないから
• (5)　WorkFlowyを使えば、つまみ食いを完成文書の中に位置づけることの試行錯誤を、何度もくり返すことができるから

これを少し一般化すると、こうなります。

• (1)　文書作成タスクの管理と文書作成タスクの実行をシームレスに担うツールであること
• (2)　性質の異なる複数の作業を、互いに独立に、並行して進めることができる枠組みと機能を備えていること
• (3)　文書のための情報をワンライブラリで管理し、「ポケット一つ原則」を実現すること
• (4)　ある作業から別の作業への切り替えで、ロスが発生しにくいこと
• (5)　個別の要素を全体の中に位置づける作業を、何度も自由に試行錯誤できること

以上の5つの条件を満たす道具を使えば、WorkFlowyと同じように、「やりたい」のつまみ食いの集積を、ひとつの完成文書へと統合することができるはずです。

しかし、少なくとも私は、これら5つの条件を満たす道具を、WorkFlowy以外に、知りません。

やはり、「「やりたい」のつまみ食いの集積を完成文書に統合する」という文書作成方法は、WorkFlowyによってこそ、誰もが現実に活用できる一般的な手法となったのです。

関連

そのときどきの「やりたい」のつまみ食いを、文書の完成へと統合できる_文書作成ツールWorkFlowyの可能性(2)