○個人システム開発の支援
2018/04/02 WRM390号 より
○「システムの構築」
前回は、システム論について考えてみました。
少し振り返っておきましょう。
まずタスク管理システムを一つの系と捉えます。薄い膜で覆われた球体をイメージするとよいかもしれません。「やるべきこと」はその外側で発生して、膜の内側に取り込まれ、何らかの処理を経て「行動」として排出される。そのような見方が一つできます。
これは「言われたことをきちんとこなす。それ以上はしない」という、仕事のやり方に対応していると言えるでしょう。「仕事」が何であるかは自分は（つまりシステム）は関与しない。外部的に発生した「やるべきこと」をいかにうまくこなすかだけ考える。それが上記のような見方におけるタスク管理です。
これは業務を覚え立てで裁量が少ないときか、あまり仕事にコミットしようとしていないときに有効なタスク管理の視点です。仕事時間外の趣味に全精力を注ぎたいので、仕事は文句を言われない程度にこなせばOKと考えているならば、このような捉え方で大丈夫でしょう。
しかし、裁量が増えたり、私のようなフリーランスだとこの視点のタスク管理だけでは仕事は回りません。「やるべきこと」を決めるのは、システムの外側ではなく内側だからです。
こうなると急に話がややこしくなるのですが、それを掘り下げるのはいったん止めにして、今回は別のアプローチを用います。
〜〜〜
多かれ少なかれ、仕事を行い継続的に成果を生み出している人は何らかの「システム」を持っていると考えてよいでしょう。
そのようなシステムがまったくなければ、毎回毎回場当たり的に処理することになりますし、それで継続的な（一定の評価を定期的に受ける）成果を生み出せるとは考えにくいものです。完全にシステマティックなものでなくても、何かしらの様式・方式は開発されているはずです。
しかし、仕事を始める前には、そのようなシステムは持っていなかったでしょう。つまり、どこかの時点でそうしたシステムが開発されたことになります。
さて、「システム開発」と聞いて真っ先に思い出すのが、ソフトウェア開発です。簡単に言えば、プログラミングですね。
システム開発にも、ウォーターフォールやアジャイルなどさまざまなアプローチがあるのですが、それとは別にもっと基本的・技術的な話があります。
フレームワークとライブラリです。
〜〜〜
何かをプログラミングするとき、まったくゼロから構築することは稀でしょう。多くは、既存の知識・情報を再利用します。また、再利用のためにパッケージングされた情報もあります。
たとえば、私は最近自作のWebツールを作っていますが、その際はjQueryを利用しています。これはJavaScriptのライブラリです。
このjQueryを使えば、長々しいコードを書かないと実現できないようなことが、たった数行のコードで実現できてしまいます。このような情報パッケージは、ソフトウェア開発において強力なエンハンスとなりえます。
しかし、ライブラリだけあっても、何かの機能が実現できるわけではありません。それらは、言ってみれば「部品」のようなものです。どこかに組み込まれることで、はじめて効果を発揮するのです。
そのようなライブラリに対して、全体像の雛形を提供してくれるのがフレームワークです。フレームワークはすでに何か動くものがあり、開発者はそれを上書きしたり、部品を追加するだけで、プロダクトを開発することができます。
もし、WordPressを使ったことがあるならば、「テーマ」がフレームワークで、「プラグイン」がライブラリだと捉えればわかりやすいかもしれません。
〜〜〜
この「フレームワーク」と「ライブラリ」という二つの捉え方で、既存のタスク管理の知見が整理できるのではないかと私は考えています。
そして、そのように整理しておけば、それぞれの人が自分なりのシステムを構築する際にもきっと役立つでしょう。
というわけで、ここから数回かけて、この「フレームワーク」と「ライブラリ」という見方をベースにしたタスク管理の方法論について考察してみます。
2018/04/09 WRM391号 より
○「フレームワークとライブラリ」
前回は、仕事術（タスク管理）の知見をフレームワークとライブラリとして捉えることを書きました。
そうして捉えることで、既存の知見をベースにしつつ、自分なりのシステムが組み上げやすくなるのではないかと想定したわけです。
今回はそれを掘り下げてみましょう。
〜〜〜
まず最初にお断りしておくと、仕事術に関する情報すべてが、フレームワークとライブラリの二つにうまく分類できるわけではありません。
そもそもそうした情報は、一つの完結したパッケージとして提示されているので、うまく腑分けできないこともあります。
もともとそうした情報は、フレームワークやライブラリとして使われるようにデザインされているので、限界があることは間違いありません。それでも、多くの知見がうまく分類できるはずです。
〜〜〜
では、どのようなものがフレームワーク、あるいはライブラリと言えるでしょうか。
たとえば、GTDはフレームワークと言えるでしょう。仕事を進めるための大きな枠組みが始めから提示されています。実践者≒利用者は、その通りに進めるだけで、GTDできるのです。
逆に、5分間ダッシュ法などのタスク実行法は、フレームワークとは言えません。ライブラリ的です。
つまり、「一連の流れ」が想定されているものがフレームワークで、そうでないものがライブラリです。
〜〜〜
私はこれまで、GTDを「システム」だと捉えていました。その見方は間違いとは言えませんが、誤解を生じさせやすいものだったのではないかと反省しています。
なぜかと言えば、「システム」だと捉えると、GTD教本が指示する通りにやらなければいけない、という感覚が生じるからです。なにせ「システム」はそこに、完璧に、できあがっているのですから。
しかしこれを、「GTDはシステムのフレームワークを提供してくれるものだ」と捉え直せばどうなるでしょうか。
その捉え方であれば、情報の受け手は、フレームワークをインストールした上で、必要な箇所を自分の手で書き換える必要を感じるはずです。なにせそれはまだ「フレームワーク」であり、実際に動く「システム」にするには、足りない部分があるからです。
自分なりのシステムを作る上で、必要なのはまさにそのような行動でしょう。
もちろん、教本の著者たちは、純然たる気持ちで、「この通りやればいい」と思って本を書いていますし、おそらくそう書くことで本が持つ説得力も上昇するのでしょう。
ただ、それを額面通り受け取ると、「システム」的に捉えてしまい、「そのとおりやればOK、そうでなければダメ」という極端な思考（白黒思考と呼びましょう）が顔を出してしまいます。
その白黒思考が頭を支配している間は、「不都合のある点は、多少アレンジして実行する」といった対応は出てこないでしょう。カチカチに真面目に実行するか、あっさりすべて捨ててしまうかのどちらかとなります。
その点、GTD教本をうまく「使えている」人は、それをフレームワーク的に捉えて、細かい改良（≒カスタマイズ）をしている印象を受けます。
そうした人は口を揃えて「我流のGTDなんです」とか「本に書いてある通りにはやっていないのですが」とおっしゃいますが、まさにそれが教本をフレームワークとして利用している証左でしょう。
仕事術の知見とは、できればそのように付き合いたいものです。少なくとも、著者を「教祖化」して、その通りにさえやっていればすべてがうまくいくと考えている間は、カスタマイズも工夫も生まれません。
「システム」として提供されている情報を、いったん相対化して、「システムの雛形となるフレームワーク」として捉え直すこと。それが、仕事術の知見との新しい付き合い方です。
〜〜〜
では、フレームワークに分類できる知見にはどのようなものがあるでしょうか。いくつか見ていきましょう。
まず、先ほどあげたGTDは、フレームワークとして利用できます。さらに、『ポモドーロテクニック入門』で提示されているタスク処理の流れもフレームワークとして使えるでしょう。
一見わかりにくいですが、『マニャーナの法則』もフレームワークですし、いくつかの書籍で言及されている「トレーシステム」（三つのトレーを使う情報整理術）も簡素ながらフレームワークと言えるでしょう。
このように見ていくと、フレームワークにも規模があることがわかります。複雑で大規模なフレームワークと、簡素で小規模なフレームワークです。
前者はカバーしている範囲が広いものの、全体を習得するためのコストが高く、また細かい箇所の変更がシステム全体に与える影響を考慮しなければなりません。
たとえば、GTDにおける「週次レビュー」を「1.5週次レビュー」や「2週次レビュー」に変更したら、その他のリストなどにどのような変更が生じるでしょうか。
まったく変わらないかもしれませんし、微妙な食い違いが生じるかもしれません。どちらにせよ、システムをうまく回していくためには、それぞれの要素がどのように関係しているのかを理解しておく必要があります。
つまり、大規模なフレームワークは構成するパーツが多く、カバーできる範囲は広いもののの、それをアレンジするにはシステムの熟知が必須です。
逆に、トレーを三つ使うだけのトレーシステムは、そもそも構成するパーツが少ないので変更できる余地も少ないですが、アレンジは簡単できます。後述するライブラリをいくらでも追加できるでしょう。
とりあえず、大規模であれ小規模であれ、その中間であれ、「仕事の進め方」（あるいは情報の流れ）が想定されていて、その手順が仕事術の中に埋め込まれているものは、「フレームワーク」に分類できます。
〜〜〜
では、「ライブラリ」は何かと言えば、フレームワークに分類されるもの以外すべて、という大雑把なくくりになります。
別に精緻な情報分類をやることが目的ではありません。どのように仕事術の情報を摂取すればいいのかを考えられればそれで問題ありません。
よって、フレームワーク以外の知見を「ライブラリ」と呼ぶことにしましょう。
もちろん、この「ライブラリ」には（その定義から言って）多様なものが含まれます。
5分間ダッシュ法、時間割方式、Doingリスト、ゴールデンタイム、カエルを最初に食べる、エトセトラ、エトセトラ。
以上のものは、何かしらの機能（効能）を持っているにせよ、それだけで仕事が「回る」わけでないのがポイントです。逆に言えば、仕事を「回す」ための基盤がフレームワークであるとも言えます。
〜〜〜
まとめておきましょう。
まず、フレームワークを導入して仕事を回す流れを確立する。その上で、必要に応じてライブラリを加えることで、必要な機能を追加して、「仕事システム」を作っていく、というのが本連載での「見立て方」です。
では、このような見立て方に立つことで露呈する問題について、次回は考えてみましょう。
2018/04/16 WRM第392号 より
「フレームワークとライブラリの問題点」
前回は、仕事術の知見をフレームワークとライブラリで捉える話を掘り下げました。
今回はこの捉え方で見えてくる、不都合や障害について考えてみましょう。
■フレームワークの問題点
フレームワークは、一つの流れを提供してくれます。そして、流れとは始まりがあり、終わりがある、一続きの流れです。その点を考えると、二つ以上のフレームワークを同時にインストールするのは相当に困難だということがわかります。
たとえば、GTDを実践しつつ、ポモドーロテクニックも一緒に実践するのは、だいたい無理です。ポモドーロテクニックの25分集中→休憩、というテクニックならばGTDをやりながらでも導入可能ですが、それ以外のアクティビティ管理とGTDは、やることがかなり違っているので、並行で走らせることができません。そうしようと思えば、混乱が生じるでしょう。
よって、ひとつのフレームワークを選択したら、基本的にはそれだけを骨子にすることが必要です。
ただし、例外もあります。一つは、区分けすること。会社にいるときは○○フレームワークを使い、家に帰ったら▽▽フレームワークを使う、ということは可能でしょう。仕事の日と休みの日のフレームワークを切り分けるやり方もあります。
ただし、その場合でも、「発生したタスクをどのようにキャッチするのか」については注意を払わなければいけません。仕事中にプライベートの用事を思いついたり、その逆だったりは頻繁にあります。フレームワークが違っていると、その思いつきを掴まえる保存場所も違ってくる可能性があるので、混乱が生じないようにしなければいけません。
もう一つの例外が、二つ以上のフレームワークから、まったく新しいフレームワークを構築してしまうことです。つまり二つの別々の流れをいったん解体し、そこから新しい一つの流れを構築してしまえば、流れの干渉は起きません。
ただし、それを実施するためには個々のフレームワークについての詳細な理解が必要です。どんな要素があり、それぞれがどう機能して、どんな効果をもたらすのか。そうした知識があって、はじめて新しいフレームワークが構築できます。これは一朝一夕ではまず不可能でしょう。
この点は「本の読み方」に深く関わってくるので、それは後の連載で書いてみることにして、とりあえず新フレームワークの構築に至るには、まずどちらか一つのフレームワークに習熟した上で、別のフレームワークを試し、そちらも習熟するという二段階のステップが必要になる点を確認しておきましょう。
■ライブラリの問題点
次に、ライブラリについて考えましょう。フレームワークに追加して使うライブラリにもいくつか問題があります。
まず、フレームワークとの相性が問題です。フレームワークAでは「○○については深く考えずさらっと流す」ことが想定されているのに、ライブラリBでは「○○について深く考えて、それが決まる前では先に進まないようにしましょう」と想定されていると、見事に流れが止まります。
また、フレームワークAでは「○○についてはメソッドCでやります」となっているのに、フレームワークBでは「○○についてはメソッドDでやります」となっていると、一体どっちをやっていいのかわかりません。これもエラーの原因になります。
さらに、上記の重複と似た話ですが、名前の衝突問題も起こります。どういうことでしょうか。
ライブラリは部品なので、一つのフレームワークの上に複数のライブラリを乗せることができます。が、それぞれの知見は、プログラミング言語的に「ライブラリ」として作られているわけではなく、その中で閉じたパッケージコンテンツとして提供されています。よって、違うライブラリに、同じ名前のものが存在することがあるのです。
たとえば、「レビュー」という言葉は、GTDではっきり定義された意味を（つまり機能と役割を）持ちます。しかし、別の仕事術でも「レビュー」という言葉が使われているかもしれません。しかし、その中身はGTDのレビューとは違っているのです。
もしそのような状況で、「さあ、レビューをしよう」となったとしたら、その「レビュー」がどちらを指しているのかわからなくなります。混乱が生じるわけです。
上記の記述は、プログラミング言語処理を念頭において書いていますが、実際のところは、自分の脳内でレビューというものが一体何なのかがわからなくなることが起こりえる、という話です。
プログラミング風に名前空間を設定し、GTD.レビュー()と、ふり返り仕事術.レビュー()と明確に切り分けて理解できていればいいのですが、そうでなければ、レビューという概念はひどく多義的で、境界線が曖昧になってしまいます。この状況で、自分なりのシステムを構築していくのはなかなか難しいでしょう。
〜〜〜
上記の考察から、二つのことが導けます。
まず、仕事術の知見を一つしか知らないと応用は効かないが、逆にたくさん知ってしまうと今回考察したような知見の混乱が生じうること。
次に、そうした混乱を避けるためには、読者の懸命な努力に頼るのではなく、既存の知識を整理し、インストール時に衝突や重複が起きないようにすることが必要だ、ということです。
たぶん、この話は仕事術の知見だけに限ったものではないでしょう。浅く広く情報を摂取していると、簡単に起こりうる事態です。が、この話は下の連載でもう一度取り上げるので、ここでは「本連載の目標は、そうした知識の整理の仕方を目指すことである」とだけ確認して、次回に向かいましょう。