会社員時代に、ある開発プロジェクトで仕事をしていたときのことを折に触れて思い出します。
僕の担当は「データ移行」でした。
「データ移行」とは簡単に言えばデータの引っ越しです。
開発中のシステムが完成し、クライアントがこのシステムを使い始める第1日目に、あたかも昨日もそのシステムを使っていたかのように、前日までの取引データがそこにある状態を実現する。
これが僕のミッションでした。
クライアントが現在使っているシステム（旧システム）から開発中のシステム（新システム）にデータを載せ替える仕事と言えます。
ちょうどスマホを買い換えたときの、バックアップと復元のイメージに近いでしょう。
多くの場合、旧システムから新システムの切り替えは週末に行われます。
金曜日の終業後の時点で旧システムの全データをバックアップし、土日の時間を使ってこれを新システムに流し込む。
とはいえ、企業のシステムが扱うデータ量は膨大であり、土日をフルに使っても足りないかもしれません。
それよりも、一気に流し込むということはリスクを短期間に集中させるやり方であり、そこで何か問題が起きればクライアントに約束している新システム稼働日を厳守できなくなります。
そこで、頻繁に使うデータとたまにしか使わないデータの2種類に分け、流し込むタイミングを2回に分けるようにします。
スマホで言えば、毎日使うタスク管理のアプリや連絡先のデータだけを先に新しいスマホに流し込み、たまにしか起動しない電子書籍や辞書アプリのデータは後回しにする、ように。
あるいは、逆にたまにしか使わないデータは旧システム上で書き換えが行われないデータということになりますから、システムの切り替え日のずっと前から少しずつ新システムに流し込み始める方法も考えられます。
たまにしか使わないデータの方が量が多いため、むしろこの方法を採る方が合理的と言えます。
実際、当時のプロジェクトでは10万件を超える取引先のデータがあったのですが、このデータから最初に移行し始めました。
長々と書いてきましたが、この「データ移行」は実に難易度が高い仕事だと当時から感じていました。
AndroidからiPhoneに機種変更するようなもので、引き継げるデータと引き継げないデータが出てきます。
引き継げないデータについては、別途何らかの形で用意して、別ルートで新システムに書き込む必要があります。
加えて、新システムは開発途上であるため、仕様が変われば必要なデータも変わるため、常に臨機応変な対応が求められます。
そのようなわけで、当時の僕は慎重にこの仕事に取り組んでいました。
言い換えれば、「もっとも手間の少ないベストな方法」を探し続けていたのです。
方法を探している間は当然、仕事は前に進みません。
その結果、使える時間はどんどん減っていき、可能性も限られたものになっていきました。
翌年4月1日のシステム切り替え日を目前に控えた、12月のある日のこと、見かねた上司から詰め寄られることになります。
「間に合うのか？ 何か秘策でもあるのか？」
と。
このひと言をきっかけに、尻に火がつき、最終的には間に合わせることができました。
もしこのひと言がなかったら、その後もえんえんと「もっとも手間の少ないベストな方法」を探し続けていたかもしれません。
上司としては、このひと言を発すれば大橋を動かすことができるはずだ、という確信があったのかもしれません。
あるいは、居ても立っても居られず「とにかく何とかしろ！」という不安しかなかった可能性もあります。
今となっては確かめようはありませんが、とりわけ「何か秘策でもあるのか？」という問いは、僕にとっては折に触れて思い出す魔法の言葉なのです。
問題は、「何か秘策でもあるのか？」と詰め寄ってくれる上司が常にそばにいるとは限らないこと。
実は今ではタスクシュートがその上司の役割を担ってくれています。
躊躇なく取りかかれるタスクの3つの条件
タスクシュートを使い続けていると、見えてくることがあります。
それは、タスクシュート上で躊躇なく取りかかれるタスクと、取りかかれずに先送りをしてしまうタスクの2種類があること。
躊躇なく取りかかれるタスクは、次の3つの条件を満たしたものです。
