1998年8月6日にそのプロトタイプ（原型）を必要に迫られる形で作り始めたタスクシュート（当時はまだこの名前はありませんでしたが）と、現在のタスクシュートとではツールとしての機能はもちろん、その位置づけも大きく異なっています。
言い方を変えれば、タスクシュートツールそれぞれに異なる「OS」が搭載されているのではないか、ということです。
あるいは、ツールごとではなくその使われ方に応じて異なる「OS」が暗黙のうちに適用されている、と表現する方が正確かもしれません。
以下、タスクシュートツールの一覧です（カッコ内はリリース年、現存しないものも含む）。
- TaskChute-1.0（1998年＝プロトタイプ）
- TaskChute0（2006年）
- TaskChute1（2012年）
- TaskChute2（2012年）
- たすくま（2013年）
- TaskChute Cloud 1（2016年）
- TaskChute Cloud 2β（2024年）
- タスクシュート手帳β（2024年）
タスクシュートの「OS」という概念は昨日ふと思いついたものですが、その片鱗はここ数年ほどの間に見え隠れするようになっていました。
26年以上タスクシュートを使い続ける中で、まずもって僕自身のタスクシュートの認識が少しずつ変化しており、これに伴い使い方も様々に変化してきました。
僕以外のユーザーの方々についても、その使われ方を見ていると僕とはまた違った認識でタスクシュートに向き合っていることが窺われます。
ツールの「使い方」は必然的に何らかのルールに沿って組み立てられているはずです。
明確に言語化できるルールもあれば、無意識に従っている規範のようなものもあるでしょう。
タスクシュートの「OS」というものを考えるとき、それは、ある特定の使い方についてその根底にあるルールや規範を集めたもの、と表現することができそうです。
ということで、改めてこれまでのタスクシュートツールとその使い方を振り返りながら、タスクシュートの「OS」に迫っていきます。
まずは、プロトタイプである「TaskChute-1.0」から。
TaskChute-1.0（1998年＝プロトタイプ）
当時はまだ「タスクシュート」という名前も概念もなかったため「-1.0」と命名しています。
この時点において最も切実だったことは、「今日は定時に退社しても大丈夫なのか」でした。
「定時に退社できるか」ではありません。
1998年8月6日(木)の朝、出社早々に直属の上司に呼ばれ、8月19日(水)が期限のまとまった仕事に取り組むことになったことがすべての始まりでした。
その瞬間から残り10営業日のカウントダウンがスタートし、
- 期日までに終えることができるのか？
- そのために毎日何をどこまで進めればいいのか？
- 現在抱えている仕事はどうするのか？
といった不安に次々と襲われます。
幸い、3つ目の不安については「いったん保留にしてもよい」という上司からの回答により、まずは8月19日(水)までの仕事に全力投球できることになりました。
あとは簡単で、この仕事を10日に分けて少しずつ進めればいいだけです。
とはいえ、ここで新たな不安が生まれます。
- 単純に10分割するだけでいいのか？
- 目に見える分量だけを基準に分割しても、その中身はまちまちではないか？
- 今日の分を終えても念のため翌日以降の分も前倒しで進めた方がいいのではないか？
これらの不安を一つひとつ解消するために、結果としてプロトタイプが作られることになります。
このときの仕事は、全体の分量が明確に把握できるものであったため、おのずと逆算的にプランを立てることになりました。
つまり、「1分着手」を駆使しなくても、例えば「3日間でここまで進められれば、同じペースを維持できる限りは期限に間に合う」という確度の高い見通しが得られる状況だったのです。
従って、プロトタイプに求められる機能としては、
- 1．一日あたりのタスク一覧（作業量）が把握できること
- 2．それぞれのタスクごとにかかる時間（見積もり時間）が設定できること
- 3．その日の全タスクの見積もり時間の合計が稼動時間（8時間）内に収まっていることを確認できること
という3つでした。
これらの機能はExcelを使えば簡単に実現できます。
1のみであれば、ExcelでなくともWordでも、何なら紙の手帳でも十分でしょう。
でも、2と3については、集計機能を必要とするためExcelが適しています。
さっそくExcel上にタスクを書き出し、見積もり時間の列を追加し、分単位で見積もり時間を入れていきます。
一番上の行に合計欄を追加し、見出し行とともに行を2行を固定表示させることで、タスクの数が増えて一画面に収まらなくなっても、常にその日の合計時間が分かるようにしました。
これで作業の準備は完了です。
あとは、一番上のタスクから順に取りかかっていきます。
最初のタスクを完了したとき、ふと気づきます。
見積もり時間より短く済んだのか、長くかかったのか、すなわち見積もり時間との差分を把握しておくことで、見積もり時間の精度を上げることができるのではないか、と。
見積もり時間の精度が上がれば、一日の最初の時点で
- このペースでいけば、今日の割り当て分を定時までに終えることができる
という確度の高い見通しが得られるようになります。
安心して最初のタスクに取りかかることができるのです。
そんなわけで「今日は何時に帰れるか？」をリアルタイムに把握するための「終了予定時刻」のセルを追加するまでにさほどの時間は要しませんでした。
では、実際にかかった時間をどのように残せばいいか？
開始時刻と終了時刻を入力し、その差分を取ればいい。
Excelですから、「実績時間」の列を追加し、数式を設定すれば自動化できます。
さらに、「予実差」という列を追加し、見積もり時間と実績時間の差分を計算する数式を設定。
こうして、
- タスク名を確認する
- 開始時刻を入力する
- そのタスクに取りかかる → 終える
- 終了時刻を入力する
- 実績時間が算出される → 確認する
- 見積もり時間との差分が算出される → 確認する
- 差分が大きければ以降のタスクの見積もり時間を修正する
というワークフローが確立しました。
セクションもプロジェクトもモードもリピートタスクもタスク実行後のコメントもない、「素うどん」のような状態ですが、これがタスクシュートの始まりでした。
ルールは実にシンプルで、
- その日に取り組むタスクを取りかかる順番に並べ、それぞれに見積もり時間を設定すること
- その日の全タスクの見積もり時間の合計が稼動時間（8時間）内に収まっていること
- タスクに取りかかるときに開始時刻を入力し、終了したら終了時刻を入力すること
- 見積もり時間と実績時間の差異が大きい場合は、以降のタスクの見積もり時間を修正すること
という4つだけです。
幸いにして、10日間はこの仕事のみに集中することができたため、結果として今で言うタスクシュート的な仕事の進め方（上記4つのルール）を自然と身につけることができました。
いま振り返ってみると、この10日間は偶然与えられた「実験室」のようなものでした。
