GTD について理解するのに苦労したので、「こう書いたら（たぶんエンジニア的には）理解しやすいはず」という視点で GTD についてざっくり解説してみた。

==== はじめに ====

本記事は筆者のざっくりとした理解、かつざっくりした解説である
- 取り上げるのは How to がメイン
- 背景、思想などは取り上げない
- 他にも色々端折っている

==== Part1. GTD の概要、リストの概要 ====

GTD とは

頭の中にある「気になること」を全部リスト化し、このリストたちをこまめにメンテすること。

効用は 2 つ。

(1)：目の前のタスクに集中できる
- 気になることは外に出してるので、脳内で「そういえばあれしなきゃ」「あれどうしよっかなー」等が発生しない）
(2)：気になることを忘れない、失わない
- リストに突っ込んでいる＆あとでメンテする時に目を通すので失われない
- リスト駆動生活やリマインダーを使うので「目を通すのが遅すぎた」という手遅れも生じない

GTD とはどういう意味？何の略？

正式には Getting Things Done で、これは「仕事を成し遂げる」くらいの意味しかないので気にしなくてもいい。GTD という名前から、何らかの仕組みやコンセプトを推し量ることはできない。（~~もうちょっと良いネーミングは無かったのだろうか~~）

リストとは

GTD が扱うリストについて簡単にまとめておく。

まずリストとは 一行に一つの項目が並んだ箇条書き のこと。

リストが持つ設定

各リストは以下の設定（使い方などのルールを定めた設定）を持つ。

Write Timing …… いつ書き込むか。書き込む頻度はどの程度か。
Write Content …… どんな内容を書き込むか。
Review Timing …… いつ見直すか。見直す頻度はどの程度か。
Review Action …… 見直しとして具体的に何を行うか。

要するに「いつ、何を書き込むの？」と「いつ読み返すの？読み返して何をするの？」を定める。

各設定について

各設定について概要や具体的な値などを簡単にまとめておく。

Timing

Write Timing にせよ、Review Timing にせよ、実施する Timing(タイミング)としては、たとえば以下がある。

高頻度（一日複数回以上）
毎日（一日一回ペース）
数日おき（数日に一回くらい）
週一（週に一回ペース）
月一（月に一回ペース）

Write Content

Write Content(どんな内容を書き込むか) の設定としては、以下二つを定める。

フォーマット
各項目が持つべき情報

フォーマットとは、たとえば「歯ブラシ買う」なのか「2019/01/11 歯ブラシ買う」なのかということ。

各項目が持つべき情報とは、たとえば「歯ブラシ買う」で言えば「項目の内容」一つだし、「2019/01/11 歯ブラシ買う」で言えば「項目の内容」と「実行する日付」の二つがある。

Review Action

Review Action(見直しとして具体的に何を行うか) については、以下がある。いずれも項目一つに対する操作である。

追加(Add) …… 新たな項目が必要なので、このリストに追加する。
更新(Update) …… 状況が変わったので、その旨を、この項目に反映する。
移動(Move) …… この項目を別のリストに移す。
削除(Delete) …… この項目は不要になったので消す。
無視(Ignore) …… 状況に変化がないため放置する（読み飛ばす）。

主に使うのは移動と削除。というのも、GTD は結局のところリスト内の項目をゼロにするのが目的であり、作業として頻出するのが移動（この項目はこのように対処しよう → その対処を行う役割を持つリストに移す）と削除（この項目はやらなくていいな or 対処できたぞ → 消す）だから。

7 つのリスト

GTD ではリストを 7 つほど使う。この 7 つのリストについて解説する。

7 つもあるの？

7 つというと多そうだが、「気になること」およびそこから派生するタスクには色々性質があり、ちゃんと運用したいなら役割分担がどうしても必要になる。GTD では「こんなリストがあったら便利だよね」という発想で、異なる役割を持つリストをつくって厳選した結果、7 つほどになった。

プログラミングでも神クラスをつくったりはせず役割ごとにクラスを分けたりするが、発想としては同じである。

以下、GTD で使う 7 つのリストについて詳しく見ていく。

各リストについて、名前だけ

インボックス(Inbox)
いつかやる(Someday)
資料(Pointer)
カレンダー(Calendar)
連絡待ち(Waiting)
プロジェクト(Project)
次に取るべきアクション(NextAction)

各リストについて、一言で

項目	内容
インボックス(Inbox)	気になることを一行一つでつっこんでおく。
いつかやる(Someday)	いつかやることを一行一つでつっこんでおく。
資料(Pointer)	URL、ファイルパス、その他資料の所在をコピペしとく。
カレンダー(Calendar)	カレンダー。
連絡待ち(Waiting)	「この件でこの人待ち」なネタを一行一つでまとめとく。
プロジェクト(Project)	「今抱えている仕事」を一行一つでまとめとく。
次に取るべきアクション(NextAction)	普段見る場所。次に何すればいいかの TODO リスト。一行に一つの TODO。

各リストについて、全体の流れを

GTD のワークフローは三つある。

収集 …… 気になることをインボックスにつっこむ
配分 …… インボックスから他のリストに振り分ける
運用 …… 他のリストを定期的に読み返す、メンテする、行動する

GTD をゼロからはじめる場合、以下のような流れになる。

事前準備 1 をする
事前準備 2 をする
運用する

最初に必要な事前準備1は以下のとおり。

(1) 頭の中の気になることを収集しきる
- 2～3 時間くらいかけてじっくりと
(2) 配分する先のリスト（記入先）を準備する
- とりあえずテキストファイルで良い
(3) 各リストについて、運用の設定（Write Timing/Write Content/Review Timing/Review Action）を行う
- 例1. インボックスは3日に1回はチェックしよう(Review Timing = 3日に1回)
- 例2. 連絡待ちは1日に1回チェックしよう(Review Timing = 1日に1回)
- 各リストの設定目安については後述

事前準備1ができたら、ある程度データを流しておく（事前準備2）。

(1) 配分作業を行い、インボックスの内容を他のリストに配分する
- いつかやる、連絡待ち、カレンダー、プロジェクトあたりが太っていくはず
(2) 他のリストも一通り読み返して、（当該リスト及び他のリストの）加筆修正を行う
- 特に「次に取るべきアクション」が太っていくはず

これで準備完了。日々 7 つのリストを運用していく。

スタート地点（エントリーポイント）は「次に取るべきアクション」リスト
ここから一つ取り出して消化して（この過程で他リストの読み書きも発生する）、消化し終えたらまたここに戻ってきて、次を消化して……というふうに行動していく
逆を言えば 「次に取るべきアクション」リストに従うだけで仕事や生活がまわるような項目(TODO)を書く
もっと言えば 自分自身に対する「指示」 を上手いこと書くイメージ
- そしてこの指示の中に「他のリストを操作する」指示も入れる

各リストについて、全体の流れを、もう少し詳しく

(1) インボックス

GTD のはじまりはインボックスから。

インボックスには「気になること」が一行一つで並んでいる。ここには「やらないといけないこと」「できればやっておきたいこと」「いつかやりたいこと」「なんか気になってること」など、とにかく全部並ぶ。というか書く。GTD をはじめる際は、まず最初に数時間かけてこれを洗い出すし、その後も随時（あるいは特定のタイミングで）気になることはどんどん書いていく。

さて、インボックスリストが完成した。最悪このインボックスリストだけでも日常はまわせる。だって、必要なことはこの中に全部書いてあるのだから。はい、GTD おわり……というと、そうではない。リストの中身は何十何百何千と長大になる。リスト一つだけでは到底扱いきれない。

そこで GTD では インボックスリスト（中の各項目）を定期的に読み返して、別の用途を持つリストに分ける アイデアを採用する。つまりインボックス自体は空にすることを目指す。

適当に貯めといて、定期的に振り分けてゼロにする

それがインボックスの肝。

(2) インボックスの振り分け先

では振り分け先のリストとして何があるのだろう？また、インボックス中の各項目はどうやって（どんなルールや基準に従って）振り分けるのだろう？

まずは前者に応えたい。GTD では振り分け先リストとして、以下を採用した。

「いつかやる」的な、とりあえず放り込んどく先は欲しいよね(いつかやる)
情報の所在は一箇所にまとめておくと便利そうやん(資料)
カレンダーはやっぱり必要だ(カレンダー)
誰かが動かないと進まないやつは、別に管理した方がいいね(連絡待ち)
今抱えてる仕事も、別に管理して一覧にしときたいかな(プロジェクト)
次何やればいいかも、やっぱり別にまとめよう。ここをエントリーポイントにすれば行動がシンプルになる(次に取るべきアクション)

続いて後者、インボックスリスト中の各項目をどんなルールや基準で振り分けるかだが、これはフローチャートを使う。項目一件一件に対して、以下フローチャートを手動で流す（ ただし意味的な判断が必要なので自動化はできないと思う）。

……と言いたいところだが、画像をつくるのはだるかったのでテキストで妥協。後述する「インボックス用フローチャート」の項をどうぞ。

フローチャートというとひるみがちになるが、イメージとして以下のとおり、ただの条件分岐の列挙なのでひるむことはない。

def proceed_inbox(list_inbox, list_itukayaritai, list_siryo, ...):
  for kininaru_koto in list_inbox:
    if kininaru_koto means 'いつかやりたい':
      list_itukayaritai.append(kininaru_koto)
      continue
    if kininaru_koto means 'あ、これ改めて見たら不要だわ':
      continue
    if kininaru_koto means 'これってただの情報源だよね':
      list_siryo.append(kininaru_koto)
      continue
    ...
  # 全部処理したのでインボックスを空にする
  list_inbox = []

(3) 振り分け先の各リスト

インボックスから各リストに振り分けていくと、各リストはぶくぶく太っていく。これで GTD をまわせるかというと、まだ足りない。具体的には以下が不明だ。

使い方 …… 各リストについて、いつ読み返すか、読み返して何をするか等がわからない
使用の忘却防止 …… いつ読み返すかがわかっていても、 読み返す事自体を忘れてしまっては意味がない ので、忘れないようにする仕組みが必要

まず前者の使い方だが、（またまた後回しで申し訳ないが）後述の「各リストの設定値」を参照のこと。ここでは後者、使用の忘却防止のみ取り上げる。

結論を言えば二つある。

リマインダー
次に取るべきアクションリストを用いた リスト駆動生活

以下詳しく見ていく。

忘却防止その1: リマインダー

リマインダーとは 指定日時に指定アラートを発生する仕組み のこと。最も身近なのは目覚まし時計だろうが、ポップアップでメッセージを表示したり、ケータイだとバイブで知らせたりなど色んな手段がある。

忘れたくない予定はリマインダーを仕込むと良い。

たとえば今日の 16 時から打ち合わせがあるとしたら、15:45 くらいに「16時から打ち合わせ！作業中断してトイレ行って準備しよう！」的なリマインダーを入れておく。そうすれば、たとえ 作業に夢中になっていたとしても（リマインダーによるリマインド内容に気付ければ）気付ける。忘れることなく対処できる。

もちろん、パソコンの前にいない時に「画面に表示するタイプのリマインド」が意味をなさないように、リマインダーも万能ではないので、運用には工夫が必要。私の場合、普段は自作のツール（画面いっぱいにメッセージを出すだけ）を使っているが、席を外している可能性が高い場合はケータイのアラーム機能を使う。

忘却防止その2: リスト駆動生活

リスト駆動生活とは、リストを中心に生活を回すこと。具体的には

朝起きたらリストを見る
やることが書いてあるので、一つ選んで消化する
リストに戻ってきて、次のやることを選ぶ
...

こんな生活。窮屈そうだが、リストにさえ書いておけば忘れない という状態を手に入れることができるため、ほぼ必須の概念である。

GTD では、「次に取るべきアクション」リストがこれに相当する。

さて、そもそもの問題は「各リストを読み返す、という作業自体を忘れてしまう」ことであり、これを防ぎたいのが本項の意図であるが、手段は整った。あとは運用方法だけだ。

アイデアとしては、「次に取るべきアクション」リストに （何をすればいいかという）指示を書く となる。

指示としては、たとえば以下があるだろう。

「インボックス」リストを読み返して配分(別リストに振り分け)する
「プロジェクト」リストを読み返して状況を更新する
「連絡待ち」リストを読み返して状況を更新し、催促が必要なものは「次に取るべきアクション」リストにタスクとして入れておく
……

仮にこのような指示をすべて「次に取るべきアクション」リストに書いておき、かつ 各指示が適切な頻度で表示（3日に1回やればいいものは3日に1回だけ登場するなど）される としたら、どうだろう。私たちは 「次に取るべきアクション」リストの指示に従うだけで GTD を、ひいては日常を回せる ことになる。

これがリスト駆動生活である。

しかし実現は容易ではない。いわゆるタスク管理ツールという専用ツールが必要になる。このようなツールは、タスクリストの各タスクに「このタスクの繰り返し頻度はどのくらいですか？」を指定できるようになっている。これを使って、各タスクが最低限必要な頻度で登場するように仕込むのだ。

別の言い方をすれば、リスト駆動生活とは 自分の行動を自然言語とリスト構造でプログラミングする とでも言えようか。興味ある方は自分用のツールを自作してみてもいいかもしれない。というか私はつくった。

==== Part2. リファレンス ====

用語

ここで GTD に関する用語を簡単に整理しておく。

以降ではこれら用語を普通に使う。

レビュー

リストを読み返すこと。リストをメンテする作業も含む。

リストの設定として取り上げたが、もう一度取り上げておくと、以下二つのパラメーターがある。

Review Timing …… いつ見直すか。見直す頻度はどの程度か。
Review Action …… 見直しとして具体的に何を行うか。

ちなみにGTD 界隈では「週次レビュー」「月次レビュー」「年次レビュー」といった言葉が登場するが、これは単に Review Timing が週一、月一、年一というだけの話である。

※厳密に言えば GTD には己の価値観を定義したシートが存在し、これもレビュー対象となるのだが、説明の単純化のため本記事では取り上げていない。

コンテキスト

タグのこと。

インボックスリスト、いつかやるリスト、次やるべきアクションリストは長大化することが多く、いちいち全部を眺めていては時間がかかる。そこで、各項目にタグをつけておき、タグで検索して「～～に絡む項目だけ抽出」みたいな使い方をすれば、眺める時間を短縮できる。

つまりは各項目にタグをつけておいて後で grep しやすくする、とでも言えようか。

以下は私が使っている例。

@buy 買う
@blog ブログネタ
@novel 小説ネタ
@business ビジネスネタ（金儲けやキャリアアップなど）
@omoi 思いや想い

たとえば「次書くブログネタ決めるか」と思ったら @blog で grep する、みたいな使い方。

各リストの設定値

本項はいわゆるリファレンスになる。各リストの設定および所感（使い方のイメージや運用のポイントなど）について一通りまとめておく。

注意事項:

設定（特に Timing）は人次第であるため、運用しながら適宜自分に合った値に変えていくことも大事
Timing については「次に取るべきアクションリスト内のタスクとして行動する時」が存在するが、本項では記載しない

インボックス(Inbox)

「気になること」をとりあえず貯めておくリスト。

設定	値
Write Timing	気になることが思いついたら or 月一くらいで数時間取ってがっつり(収集)
Write Content	一行に一つの「気になること」を、フリーフォーマットで
Review Timing	数日に一回 or 週一 or 二週に一回
Review Action	移動、削除

「気になること」をいつ書くか
- 随時派（思いついた時に都度書く）
- 収集派（たまに数十分～数時間確保してガッツリ洗い出す）
読み返すタイミング
- 短い → 読み返すのが面倒くさい
- 長い → 気になることが貯まりすぎてて処理（振り分け）するのが面倒くさい
運用について
- 定期的に中身を空にすることを目指す
- もし空にならない場合は、読み返す頻度を増やす
- 無理に一度に全部空にしなくてもいいが、無視（これはまた今度考えよう）は無しで
大体は「やっぱやめた」で消す or「いつかやろう」にとりあえずぶっこんでおく、になる

いつかやる(Someday)

いつかやることを貯めておくリスト。

設定	値
Write Timing	インボックスのレビュー時
Write Content	一行に一つの「いつかやること」。最悪「気になること」のコピペでいい
Review Timing	一月に一回より低頻度で
Review Action	更新、移動、削除、無視

最も肥大化するリスト
- 何百、何千と項目が並ぶことも珍しくない
- 基本的に貯める一方
- たまに見返して刺激を得たり、「これやってみるか」と行動に移したりする程度
書く時に律儀にコンテキストをつけるか、つけないか
- つける → 面倒くさいが、後で探しやすくなる
- つけない → リスト溜まってきたら地獄やぞ
「保留リスト」という名前で言及されることもある

資料(Pointer)

情報の所在についてのメモを貯めるリスト。

設定	値
Write Timing	所在をメモしたくなったら or インボックスのレビュー時
Write Content	所在のメモ(URL、ファイルパス、その他格納場所や取り出し手順など)
Review Timing	無し
Review Action	無し

情報の所在をひたすら貯める感じ
- 「あ、あれどこにあったっけな」という時にこのファイルを検索してヒットさせたい
情報の所在
- URL
- ファイルパス
- 「XXサーバはi階、YYサーバーはj階」 ← こういう感じのメモ
- ipconfig の結果（自マシンのネットワーク変えることになったので一応前のをメモっとく）
- ……
レビューを行わないリストでもある
- 気になるなら適当に整理してもいい
- 例: 一月単位で区切り線と日付文字列を入れる
というか無理にリスト（一行一項目）にしなくてもいい
Q: このリスト必要？
- Ans: 最悪無くてもいいが、あとでチャットだのメールだのから探すことになって死ぬ
- 日頃から資料リストにポイポイしておけば、この中を検索するだけで見つかる
- ジレンマ: 後の便宜のために一手間背負うか、楽してひと手間惜しむか
  - GTD のリスト運用は割とこのジレンマとの戦い
筆者の運用例
- pointer.md というファイルを用意して、ファイルパスや URL をポイポイしている
- パスをコピーするタイミングで、大体 pointer.md にもコピペしとく
- 自宅よりも会社で重宝（色んな場所の色んなパスが登場するから）

カレンダー(Calendar)

その名のとおりカレンダー。未来日に何があるかの網羅および視認用。

設定	値
Write Timing	インボックスのレビュー時 or 何らかの予定が発生した時 or 随時
Write Content	何年何月何日に、何時から、どこで、何が
Review Timing	一日に一回以上 or 予定に変更が入った時
Review Action	更新、削除、無視

実はリストじゃない。ただのカレンダー。紙でもアプリでも好きなものを使う
一日最低一回はレビューする
一日のレビューで、直近数日くらいはチェックする
特に直近の予定はリマインダーを仕込んでおくと忘れない
実はリストとして使うこともできる
- 一行一予定で列挙する感じ
- 私は plain text 好きなのでこのやり方にしている

以下は私が使っているもののサンプル。

calendar.md

# calendar
- mm/dd dow hhmm-hhmm  予定
- mm/dd dow            予定
- mm/dd dow hh-hh      予定
- ...

連絡待ち(Waiting)

「誰かがやるまで待つ必要があるもの」をまとめて可視化しておく。

設定	値
Write Timing	インボックスのレビュー時 or 何らかの待ちが発生した時
Write Content	一行に一つの「連絡待ち内容(発生日時、関係者、概要、デッドライン等)」
Review Timing	一日に一回以上
Review Action	更新、移動、削除、無視

いくつか例を
- 2018/12/03- 3/1 XXX出張だけどまだ正式展開来とらんぞ
- 2019/01/11- 2/14で休暇申請した
- 2018/01/15- Slackに問い合わせ投げた
レビューは一日一回以上くらい
- そうすれば最低一日一回はすべての連絡待ちを確認できる
- 「そろそろ催促するか」 → 催促する or 催促するタスクを「次に取るべきアクション」リストへ
- 「まだ余裕があるな」 → いったん無視
自分がわかるならキーワードだけでもいい
- 「2018/01/15- Slackに問い合わせ投げた」→「2019/01/15 slack」など
発生日時は見栄えにも良い(発生日順に並べやすいなど)のでなるべく記入したい
- 私は Text Expansion で一発で現在日時を打てるようにしている

プロジェクト(Project)

自分が抱えている仕事や雑務や用事などをまとめて可視化しておく。

設定	値
Write Timing	インボックスのレビュー時 or プロジェクトのレビュー時
Write Content	一行に一つの「プロジェクト内容（詳細は後述）」
Review Timing	週に一度
Review Action	追加、更新、移動、削除、無視

プロジェクトとは「一年以内に達成できそうで、かつ達成に複数のアクションを要すること」全般。
- 例1. L字デスク買う
- 例2. 大阪旅行したい
- 例3. ～～本を買う
- 例4. 新しく出来た店～～に行ってみる
- Issue や Ticket 一件分、と言えばわかりやすいかもしれない
プロジェクト内容として書くもの
- 概要
- 現状況や進捗
- 次何をやればいいか
- ここまでに済ませないとやばいというデッドライン
レビューは週一が鉄板（GTD では「週次レビュー」と呼んでいる）
- ある程度は頭に入っているので、レビューはたまにでいい
- 個人的感触では1日、2日ごとだとやりすぎ。2週間だとちょっと足りない(状況が変化しすぎててレビューがしんどい)
いつかやるリストとの使い分けに注意
- プロジェクト → 少なくとも一週間に一度は何らかのアクションをする
- いつかやる → いつかやるかもしれないってだけ。一年以上放っておくこともありえる
- アクションしてないものはいつかやるリストに移す

上記例で記入例を書いてみる。

- L字デスク買う: まずはググる
- 大阪旅行したい: 5日くらい遊びたいんで有給取らな 締切:7月までに(新PJ始まる）
- ～～本を買う: ブクマしてるのでそれ
- 新しく出来た店～～に行ってみる:

こんな感じで。書き方は適当でいい。自分が見てわかればいい。見づらいなら適当にフォーマットをつくる。

次に取るべきアクション(NextAction)

要するに今日の TODO リスト。

設定	値
Write Timing	レビュー時全般
Write Content	一行に一つの「一時間以内に達成できそうで、かつ何すればいいかが明確なほど具体的に記述されたTODO」
Review Timing	一日の最初 or 随時
Review Action	追加、更新、削除、無視

いわゆる TODO リスト
- ここに書かれたものを選んで一つずつ潰していくイメージ
一日の最初にここを見る
- 理想は「ここに書かれたことに従っているだけですべてまわる」
ぶっちゃけここの運用が一番ムズイ
- 一行に一つの TODO を書いただけのリストだと大体破綻する
- ガチるなら「タスク管理」「タスク管理ツール」といった理論や手段が必要に……
- タスク管理マニアになるとルーチンタスク（定期的な行動）も全部ぶっこみ、「今日やるべき "次に取るべきアクション"」がずらりと実行順に並ぶようにしている。「朝起きたら顔洗って、トイレして、歯磨いて、食器片付けて……」のレベル。
他のリストの Timing についても、実はここが基点となることが多い
- ここに「インボックスの収集を行う」「プロジェクトを見直す」といった TODO をぶちこんでおくイメージ
- 出現頻度を制御できると読む、判断する、行動するのがめちゃくそ楽チンになる
  - たとえば月に一度だけ出現、週に一度だけ出現、など
  - 手作業では制御するのはキツイ。タスク管理ツールなどを使うのが吉

この辺の話に興味があれば（拙作で恐縮だが）以下を。

インボックス用フローチャート

インボックスリスト内の「気になること」一件を振り分けるために使うフローチャート（のテキスト版）。

インボックスから一件（以下「気になること」）を取り出し、以下に従って分類する。

※ただし「次へ」とは「次の一件を取り出す」の意。

[1] 「気になること」が「いつかやりたい or 今は無理だからあとで or そのうちやる」 → いつかやるリストに移す。次へ。
[2] 「気になること」が「あ、これ、改めて見たら要らんわ」 → 消す。次へ。
[3] 「気になること」が「これってただの情報源だよね」 → 資料メモにメモしとく。次へ。
[4] 「気になること」が「これは 2 分くらいで終わるぜ」 → 今すぐ対応しちゃう。次へ。
[5] 「気になること」が「これは指定日の指定時間にやらないと（行かないと）いけないやつだわ」 → カレンダーに予定登録する。次へ。
[6] 「気になること」が「これは A さんじゃないと先に進まないよね」 → 連絡待ちリストにメモしとく。次へ。
[7] 「気になること」が「これは近いうちに対応したいけど、やることが色々あるなぁ」 → プロジェクトリストに「これ」をメモしとく(「やること」ではない)。次へ。
[8] 「気になること」 → 次に取るべきアクションリストに入れる。次へ。

※ [4] について説明してなかったのでここで。2分以内に終わるタスクはその場で処理する のは GTD において重要なポイントの一つ。このレベルのタスクをリストに貯めちゃうと、かえってリストのメンテコストの方が高くつくことが多いので、その場でやってしまおうという話。

==== おわりに ====

GTD について長々と書いたが、要するにリスト（一行一つの箇条書き）の使い方、運用、連携フローなどを工夫して上手いこと生活や仕事をまわしていく一手法でしかない。

いや、本当はもっと複雑で、色んな背景やら思想やらもあるみたいだが、そこまで付き合えるほど暇じゃないし、そもそもわかりにくいんだよ。哲学とか言葉遊びとかそういうのはどうでもいい。てっとり早く How to を知りたかった。

そんな思いから、この記事は生まれた。何かしらの参考になれば幸いです。