(57)【要約】      （修正有）【課題】計画した仕事またはプロジェクトをより適切に実行して、当初の目的をできるだけ確実に達成できるよう、目標達成に最適なスケジュール管理をすることのできる手帳の提供。【解決手段】カレンダー表示を時の流れと逆として、スケジュールを表示し、未来の終了日（目標達成日）が目標達成のための仕事の開始日よりも手前にくるように日時が設定されるようにした、リバース・スケジュールの手帳及びコンピュータ上で実現される電子手帳とした。【選択図】図１
2007140653.tif 000002
【特許請求の範囲】
【請求項１】
目標達成の予定日である終了日を設定する終了日設定手段と、
この終了日設定手段で設定した終了日に所定の計画が完了するように所定の必要時間を想定して開始日を設定する開始日設定手段と、
上記終了日設定手段で設定された終了日を開始日設定手段により設定した開始日より、時の流れ方向とは逆方向の時系列で表示するカレンダー表示手段と、
カレンダーのスケジュール欄にタスクを入力するタスク入力手段と、
を備えたことを特徴とするリバース・スケジュール・システム。
【請求項２】
前記終了日設定手段は、未来の任意に選択した所定の期日から所定の緩衝期間を遡った日を終了日として設定することを特徴とする請求項１記載のリバース・スケジュール・システム。
【請求項３】
前記開始日設定手段は、当該プロジェクトに要する時間を推定し、当該推定時間を基に終了日から開始日を逆算して設定することを特徴とする請求項１記載のリバース・スケジュール・システム。
【請求項４】
設定した終了日と開始日との間に、達成の目安となるマイルストーンを設定するマイルストーン設定手段を備え、前記カレンダー表示手段は、当該マイルストーンをカレンダー上に表示することを特徴とする請求項１から３いずれかに記載のリバース・スケジュール・システム。
【請求項５】
マイルストーン設定手段で設定したマイルストーンに対応して、当該マイルストーンが設定された日付で、開始日からの出来高もしくは目標達成率を入力したとき、当該出来高もしくは目標達成率と、終了日までの予定日数との関係から予測終了日を推定し、予測終了日と設定終了日との差を表示することを特徴とする請求項４記載のリバース・スケジュール・システム。
【請求項６】
毎日、毎週、毎月の少なくともいずれかにおいて、達成した出来高もしくは達成率を入力する、達成率入力手段と、
この達成率入力手段で入力された出来高もしくは達成率により、達成した仕事量を、毎日、毎週、毎月の少なくともいずれかの目標仕事量に対比して表示する達成仕事量表示手段と、
を備えた請求項１から５いずれかに記載のリバース・スケジュール・システム。
【請求項７】
インターネットまたはイントラネット上に配置されるサーバにインストールされて実現されるスケジュール管理システムであり、
Webブラウザの登録画面を通じて、インターネット端末から利用ユーザの情報を登録す
るユーザ登録手段と、
ユーザ登録手段で登録されたユーザ毎にスケジュール手段を形成するスケジュール形成手段と、
ユーザ毎に形成したスケジュールをユーザ端末に配信してブラウザに表示する配信・表示手段と、
を備え、
前記ユーザ毎のスケジュール手段は、それぞれが、請求項１から６のいずれかに記載の機能実現手段を有することを特徴とする、リバース・スケジュール・システム。
【請求項８】
多数のタスクから成る一つのプロジェクトを実行するにあたって、各タスクを複数の担当者に割り当てるとともに、
ネット上に配置されるサーバにインストールされて実現されるスケジュール管理システムとして構成され、
前記担当者の端末からアクセス可能であるとともに、タスク毎にスケジュール手段を形成するスケジュール形成手段と、
タスク毎に形成したスケジュールを当該タスクの担当者端末に配信して表示する配信・表示手段と、
を備え、
前記タスク毎のスケジュール手段は、それぞれが、請求項１から６のいずれかに記載の機能実現手段を有することを特徴とする、リバース・スケジュール・システム。
【請求項９】
計画を実行するために遂行する各タスクにおいて、
スケジュールに各タスクを構成するプロセスを登録するプロセス登録手段と、
当該プロセスにつき、前記タスクを遂行する上で、必須なものとそうでないものとを特定する必須プロセス特定手段と、
必須でないプロセスについて、遂行の優先順位を特定する優先順位特定手段と、
を備え、
タスクの出来高に従って、遅延が予想されるとき、タスクの内の優先順位の低いプロセスにつき、そのプロセス遂行の中止を促してタスクの遂行計画を見直す、スケジュール修正手段をさらに有する請求項１から８のいずれかに記載のリバース・スケジュール・システム。
【請求項１０】
タスクの遂行計画を見直すスケジュール修正手段として、don't to do listを有し、このdon't to do listにプロジェクト遂行上やってはいけないプロセスあるいはプロジェクト遂行に関係のないプロセスを登録することを特徴とする請求項１から８のいずれかに記載のリバース・スケジュール・システム。
【請求項１１】
カレンダー表示を有し、カレンダーで示される年月日において、毎月、毎週、毎日の内のいずれか毎にスケジュールを書き込む、毎月、毎週、毎日のいずれかのスケジュール欄を有し、当該スケジュール欄を有するカレンダー表示が、時の流れ方向とは逆方向の時系列で表示されていることを特徴とするリバース・スケジュール手帳。
【請求項１２】
毎日のスケジュール欄が、２４時間の時間割表示を有し、この２４時間の時間割表示が、時の流れ方向とは逆方向の時系列で表示されていることを特徴とする請求項１１記載のリバース・スケジュール手帳。
【請求項１３】
タスクの遂行計画を見直すために、スケジュール修正手段として、don't to do list欄を有し、このdon't to do list欄にプロジェクト遂行上やってはいけないプロセスあるいはプロジェクト遂行に関係のないプロセスを登録することを特徴とする請求項１１、１２のいずれかに記載のリバース・スケジュール手帳。
【請求項１４】
プロジェクト・マネジメント用のリバース・スケジュール手帳であり、複数の担当者振り分けられるタスクのリストを記載するタスクリスト欄と、
当該タスクリストに対応して、スケジュール欄を有するカレンダー表示を有することを特徴とする請求項１１から１３のいずれかに記載のリバース・スケジュール手帳。
【請求項１５】
ダイエット用のリバース・スケジュール手帳であり、スケジュール欄に、目標体重への減量を達成すべき予定日を終了日として設定するとともに、ダイエット開始日を設定し、ダイエット開始日から、ダイエット終了日までの間に、ダイエットに必要なメニューを記載してあるとともに、当該メニューの達成・非達成を記載する達成度記載欄を有することを特徴とする請求項１１から１４のいずれかに記載のリバース・スケジュール手帳。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、スケジュール管理により、所定の目標を達成するに資する、スケジュール・システムに係るもので、プログラムにより、コンピュータで実現されるシステム、及び、アナログ手帳において実現されるスケジュール手帳に関する。
【背景技術】
【０００２】
毎年の如く、用途に応じて新たに編集された手帳が発行されている。また、コンピュータ上でスケジュール管理をするためのソフトウェアは、マイクロソフトアウトルック（登録商標）他、数多く提供されている。そして、それらは、当然ながら、時系列に従って表示されるカレンダーを前提としている（特許文献１）。この点は、電子手帳においても同様である（特許文献２）。
【特許文献１】特開２００３−６３１７２号公報
【特許文献２】特開２００４−５４７９９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで、これらの手帳や電子手帳でのスケジュール管理は、ただ単に、仕事上の予定などを、登録して、スケジュールを管理するためであるが、より積極的な活用方法としては、プロジェクト管理がある。すなわち、予め、なにがしかのプロジェクトを遂行するために予め計画を建て、その計画通りにプロジェクトを進めていくためのスケジュール管理である。
【０００４】
本発明で課題とするところは、上記のうち、後者に関することである。計画の実行は「言うはやすし行うは難し」がまさに当てはまる分野である。「予定は未定」とよく言われるが、予定通りに計画が進むことはまずない。
【０００５】
本発明は、このような観点からなされたもので、計画した仕事またはプロジェクトをより適切に実行して、当初の目的をできるだけ確実に達成できるように支援することを目的とする。
【課題を解決するための手段】
【０００６】
本発明は、上記課題を達成するためになされたもので、本発明は、次の手段を採用した。
【０００７】
すなわち、本発明は、目標を立てて、そこから逆算して計画を立てると、目標を達成しやすいということに加え、カレンダーは、時の流れに沿って、順方向に表示されるものだとの、きわめてあたりまえの常識を完全に無視し、カレンダーの表示を時の流れと全く逆にすることで、画期的な効率を達成できる、との知見に基づくもので、まさにコロンブスの卵的発想に基づくものである。ここでは、カレンダーの表示を時の流れと逆にした上でスケジュールを立てるという意味で、リバース・スケジュールという。
【０００８】
以下、その発明思想を発明するに至った背景も含めて説明する。
【０００９】
リバース・スケジュールは、タイム・マネジメントの本質的なアプローチの「シンボル（象徴）」である。重要なのは、リバース・スケジュールの使い方そのものではなく、リバース・スケジュールをとおして身に着けるプロアクティブ・アプローチである。
【００１０】
本発明では、このリバース・スケジュール（の考え方）を使い、「未来を切り開く能力を身につける」こと、そして「仕事や社会活動を思い通りにして成果を上げ、さらに人間らしいゆとりを楽しむ」ことを可能とする。これが、リバース・スケジュールにおける「成功」の定義である。
【００１１】
ほんとうにそんなことが、単純にスケジュール帳を使うことで実現できるのであろうか。システム手帳のリフィルを幾種類もどっさり買い込み、最初は何でもできる気になって勢い込んでも、だんだんと面倒になってしまうことも多い。結局、シンプルなものに落ち着く。「たかが手帳」である。使う人の工夫こそ尊重されるべきものである。手帳自体に万能性を求めるのは徒労に終わると言ってよい。
【００１２】
しかし手帳は、毎日使うものであり、使うひとに何らかの影響を与えないわけがない。そして、単に予定を書き込むというような使い方としてではなく、予定をどう立てるかという「考える」プロセスまで影響の範囲だとすると、手帳にはとんでもなく重要な役割がある。「されど手帳」ということである。
【００１３】
リバース・スケジュールは、この「されど手帳」という立場で、使う人の「考える」プロセスに画期的な変革をもたらすことを意図した思想である。
【００１４】
リバース・スケジュールは、普通のスケジュールとは、時間の順序が逆に設定・表示される。
【００１５】
つまり、基本的には、図１〜図４に示すようなものである。図１は、Yearly版で、ここでは、１月から６月を省略してあるが、12月から逆に月を表示し、また、各月の日付も上から下へと時の流れと逆に日付を表示してある。図２は、12月31日から1月1日までをカレンダー表示したMonthly版であり、図ではその12月分のみを示してある。図３は、日曜日
から月曜日までを表示したWeekly版で、ここでは、2006年12月25日から31日を、上から下へと時の流れとは逆方向に表示してある。図４は、2006年12月31日の24時間の内、６時から24時までを、上から下へと時の流れとは逆方向に表示したDaily版である。
【００１６】
紙の手帳においても、電子手帳においても、基本はこの時の流れ方向とは逆方向の時系列で表示するリバース表示のスケジュール用カレンダーである。
【００１７】
なお、電子手帳は、電子手帳専用のデバイスを開発してもよいが、パーソナル・コンピュータや、インターネットまたはイントラネット上のサーバで稼働するものであってもよいことはもちろんである。その具体例は後述する。
【００１８】
なぜ、こんな天の邪鬼のようなスケジュール帳が必要なのだろうか。
【００１９】
私たちは、マネジメントと管理を混同しがちで、どちらかというと管理的で、過去に目を向けてしまう。これは、手帳を使うときにも起こっている。
【００２０】
例えば、スケジュール帳に、○月×日に会議がある、締め切りが△月○日、というようにいろいろなイベントを備忘録的に記入するのが一般的である。
【００２１】
○月×日に会議があるという場合、スケジュール帳をパラパラめくって、その日の予定が空いていれば、（あまり考えもせずに、）会議の予定を記入してスケジュールの作業は終わり。スケジュール帳も立派に役目を果たしたことになる。ここで、会議の予定は未来のことであるが、この予定が最も顧みられるのは、会議が終わった後、「予定通り終了」などとチェックする時である。もう予定ではなく、過去になってからである。時々、期日
の前に予定を確認することもあるが、それは、現時点においての（まだ期日が到来していないことを）確認をしているだけで、積極的に未来に目が向いているわけではない。あくまでも、現在中心で考えているものである。このような「管理」の仕方であると、他の予定で忙しく、たまに、期日を忘れてしまうことさえある。ビジネス・パーソンとしてあるまじき行為だが、現実には、結構ある話である。
【００２２】
これらは、やはり管理的でリアクティブな発想からくるものである。例えば、この期日忘れのリスクについて、デジタル的に解決を図ろうとすることも考えられる。期日前にアラーム音を鳴らすなどである。単純なケアレス・ミスを防ぐ効果はあろうが、アラームが鳴ったときには、もう作業時間が足りないとか、優先度の変化でアラーム自体の意味がなくなったとか、根本的なアプローチを変えなければ、デジタル・ツールのみで解決はできないであろう。
【００２３】
リバース・スケジュールでは、意図的にプロアクティブな発想を起こすために、未来の予定が常に現在よりも前になるように、時間の設定を逆転して作ってある。そこで、○月×日の会議の予定日は、（予定を記入している）現時点よりも「後ろ」に表示されるのではなく、「前に」表示される。
【００２４】
よって、最初に予定日を記入してから、今日現在に戻るためにページをパラパラめくっていく必要がある。このとき時の流れは未来から現在へと逆行であるが、行為としては順々にページを繰っていくために、素直にこの時間の逆行を扱えるようになるところがポイントである。
【００２５】
つまり、予定日から今日現在への逆の時の流れの中で、「必要な準備期間が確保されているのか」、「準備には何にいちばん時間がかかるか」、「他の予定より優先すべきものか」、「いつから開始すればよいか」を考えやすくなる。
【００２６】
このような考え方は、できるひと（ハイ・パフォーマー）に共通に見られる。
【００２７】
ハイ・パフォーマーたちは、時間が制約であることを知っているために、期日など逆から遡って考えることを習慣化し、その中で困難なことを見つけてから、仕事のスケジュールを決定しているという事実である。考えることなく仕事を始めたり、いきなり計画を立てたりということでは効果は出せないのである。
【００２８】
リバース・スケジュールは、私たちが陥りがちな習慣に決別し、このハイ・パフォーマーと同様の思考プロセスを実現することを目指すものである。
【００２９】
しかし、このようにハイ・パフォーマー達の考えを体系立てて解析しそれをスケジュールに役立てた例は見あたらない。特に、カレンダーは時の流れ通りに表示されるのが一般的で、それがあまりにも当たり前すぎる常識であるため、それを逆にすることが、上記ハイ・パフォーマー達の考えにマッチングするなど、誰も考えたことがないことであった。
【００３０】
では、時間の順序を逆にすることで、私たちの中に何が起こるのであろうか。さらに詳しく、その仕組みを考察してみる。
【００３１】
小説「クリティカル・チェーン―なぜプロジェクトは予定どおりに進まないのか？」（エリヤフ・ゴールドラット著、ダイヤモンド社）で紹介されている人間の行動特性に関する興味深い観察として、「学生症候群（Student syndrome）」といわれるものがある。
【００３２】
図５のように、私たちは、「期日の直前にならないと本気で仕事を始めない」。これは
、学生が宿題を提出期限の直前にしか始めないのと同じようなものだというのだ。ほとんどの人は、苦笑しつつ認めざるを得ないのではないかと思う。「学生症候群」とは、云い得て妙だ。また、わかっていても、このような行動特性を変えるのは難しい。
【００３３】
TOC（Theory of Constraints； 制約条件の理論）は、ならば、学生症候群などの行動
特性を前提としようとしている。リバース・スケジュールは、このTOCの考え方と共通す
る。
【００３４】
これからリバース・スケジュールによる計画の考え方のイメージを示す。
【００３５】
まず、従来型の、時の流れに沿ったスケジュール法では、作業の開始から完了までを図６のように均等に達成率が増えていくことを（無意識にも）前提にしているはずである。もちろん、人間は機械ではないから、実際には、このように達成率がきれいな直線にはならないことも知っている。ここでは、私たちがスケジュール（予定を立てる）をするときに、作業達成のイメージを、あたかも自分を機械のように考えているという事実に注目されたい。
【００３６】
ここで、先の学生症候群の図５と、この図６（計画）を比較されたい。どちらが作業効率（時間当たりの成果）として良いだろうか。もちろん、学生症候群の例では、期日に遅れて完了期間が長くなっているため、結果としてスケジュール（期間）効率は悪くなっている。注目して欲しいのは、それぞれの達成率を示すグラフの下の部分（それぞれ、[１]と[２]で示す領域）の面積の大きさである。
【００３７】
明らかに、学生症候群の例の方が小さいことがわかるはずである。これは、何を示しているのだろうか。期日間際に頑張って成果を出した、そう、この部分が作業効率を示すのである。単純に考えると面積が小さいと作業効率が良い（集中して成果を出した）ということである。あらためて、２つの図を重ねてみよう（図７）。
【００３８】
この図７からわかる問題は、従来のスケジュールでは、仮に計画どおりに実行したとしても作業効率が悪いという事実、そもそも作業効率（集中して頑張る）を意識していないということである。私たちは計画段階で多くの余裕をとっているのであるが、実際には、学生症候群のために、この余裕は「ゆとり」ではなく「ムダ」になって、結局ある時期に苦しい思い（「ムリ」）をすることを繰り返している。
【００３９】
計画のムダは、このままでは決して改善されることはない。ムダはムダと認識されず必ず使い尽くされるものである。（これを、「パーキンソンの法則」という。）
そこで、いよいよ、リバース・スケジュールの考え方である。
【００４０】
図８に示すように、リバース・スケジュールでは、未来の予定である「期日」が、その予定を立てている「現在」よりも手前にくるように日時が設定される。つまり、普通の順序とは逆になる。これが「リバース（reverse）」ということである。
【００４１】
まず、図８から明かなように、「期日」から時間を遡って（リバース・スケジュールでは、手帳の順序どおりに）、その仕事の「終了日」を設定する。「期日」＝「終了日」としないのは、様々なリスクの影響を軽減するためである。仕事の内容や期日の重要性に応じてこの「緩衝期間」は考えればよいと思うが、重要なのは、「まず、終了日を設定する」というアクションそのものである。自らが考えてゴールを設定しなければならない。自分で目標を決めるということである。これは、紙の手帳でも、電子手帳でも同様である。電子手帳の場合、終了日設定手段が、未来の任意に選択した所定の期日から所定の緩衝期間を遡った日を終了日として設定する。
【００４２】
次に、この終了日からさらに時間を遡って「開始日」を設定する。このとき、「頑張ればできる」という「開始日」を目標として設定することが重要である。ここで「作業効率」（仕事の効率）が決まる。むしろ、開始日を決めることは「作業効率を決める」といったほうようがよいかもしれない。
【００４３】
図８の[３]で示す部分の面積は、先の学生症候群の例の図５の[１]の面積（作業効率）と同じ程度の設定になっている。頑張ればできるはずの開始日である。さらに、期日までの余裕期間はとってあるから、安心して厳しいくらいの「開始日」が設定できるはずである。
【００４４】
このように「開始日」を設定すると、「現在」から「開始日」までの間に、相当の期間ができたことに驚くはずである。ここでもう一度、従来のスケジュール計画に潜む「ムダな余裕」と学生症候群の「作業効率」を思いおこしたい。ここで、この「現在」から「開始日」までの期間のことを「本来のゆとり」と呼ぶこととする。むしろ、「作業効率」よりもこの「本来のゆとり」を創ることが重要である。これが、ハイ・パフォーマーの必要条件である。この「本来のゆとり」は、別の仕事のために有効に使うことができるし、何も仕事に限らず、自分と社会にとって意義のある活動に積極的に使っても良い。この「本来のゆとり」をコントロールすることが「成功」の秘訣である。
【００４５】
なお、先に「緩衝期間」といったが、クリティカル・チェーン法ではこれを「バッファー」という。AGI（アブラハム・ゴールドラット・インスティチュート）では、「HP(Highly Possible);まず大丈夫」（図９の墨を入れた領域）から、「ABP（Aggressive But Possible）；頑張ればできる（やればできる）」を引いた残りの50%が妥当という経験則がある。そして、ABPをベータ分布上確率50%の期間としている（図１０を参照）。本発明では、開始日を設定するにあたり、この確率期間を利用することができる。
【００４６】
リバース・スケジュールでは、図１〜図４のように、Yearly版、Monthly版、Weekly版
、Daily版があるが、そのそれぞれに目標設定をする。Yearly版では、「年間目標シート
」（図１１）、Monthly版では、「月間目標シート」（図１２）、Weekly版とDaily版は、「To Do ストラクチャー・リスト」（TDSリスト）（図１３）の項目が目標の設定対象と
なる。また、目標設定だけではなく、目標達成評価（出来高・達成率）をあわせて表示・記入する。
【００４７】
リバース・スケジュールの目的は、「未来を切り開いていく能力（コンピテンシー）」の開発であり、目標設定能力はその源ともいえる重要な能力である。
あらためて目標というものを考えるとき、目標にはいろいろあることを思いつく。人生の目標という大きくて長い期間の目標、会社の中長期計画などに基づいた自分の仕事の目標、プロジェクトというまとまった仕事単位の目標、どれも目標である。
【００４８】
リバース・スケジュールでは、スケジュール帳というものをベースにして、ハイ・パフォーマーになるための能力開発という点に焦点をあてており、目標設定については、年間の目標から考える。もちろん、よりハイレベルな目標、中長期の目標が必要ないということではなく、このような目標は「必ず持つべきである」という前提である。
【００４９】
既に世の中には、このレベルの目標設定に適した手帳が市販されている。例えば、フランクリン・プランナー、熊谷式夢手帳などである。また、自分に合うように工夫して作っている人も多いだろう。さらには、会社や組織の中で目標管理制度に基づいて作成していたり、プロジェクトでは、プロジェクト目標を設定した所定の文書があろう。例えば、プロジェクト・スコープ記述書、プロジェクト憲章などである。
【００５０】
図１４を参照すると明かなように、リバース・スケジュールは、これらを受けて、実際に年間の目標を設定するところから始めるのが好ましい。何から何までリバース・スケジュールを使うのではなく、既に実績のあるものをそのまま活用するという考え方である。ただし、準備編で触れたハイ・パフォーマーの目標設定の３つのルールに基づいて、ハイレベルの目標自体の見直しが必要な場合もある。
【００５１】
ハイレベル目標を受けて、年間目標と月間目標は、それぞれ「年間目標シート」（図１１）と「月間目標シート」（図１２）に記入する。週間目標と1日の目標については、「To Do ストラクチャー・リスト」（TDSリスト）（図１３）を利用する。TDSリストについ
ては、後述する。
【００５２】
ここでは、年間目標と月間目標についての方法を例示する。
年間目標「セミナー開催20回」→月間目標「セミナー開催2回」（図１１）
年間目標「セミナー準備平均期間14日」→月間目標「セミナー準備期間10日」（図１２）
目標達成評価として、年間の場合は各月、月間の場合は各週ごとに実績を記入して評価する。
＜全体スケジュールと部分の区別−戦略的思考＞
リバース・スケジュールでは、Yearly版、Monthly版、Weekly版、Daily版があるが、この時間単位の違いを利用して、仕事の全体と部分を把握する。
【００５３】
目標設定と同じように、スケジュールを作成するときも「年間→月間→週間→日」というように、大きな単位から小さな単位に落とし込んでいく。自分の担当部分の仕事（作業）が、１週間とか２週間というもので、月単位ましてや年単位とは無縁のものだと思いがちだが、この点はよく考える必要がある。
【００５４】
例えば、他人との共同作業に関連する場合であっても、とにかく自分の担当の部分だけわかればよいということで済ませがちである。その仕事の依頼者（顧客や上司など）の立場でみると、仕事の目的を達成するためには、自身の担当する部分以外の仕事はないだろうか。それらの仕事との関係は理解しているだろうか。例えば、自分の担当する作業を受けて、他人の仕事が始まるという関係はないか。これらのことがわからない場合は、依頼者に確認することができる。本来は、仕事を引き受けるときに依頼者に確認しておくものである。このような関係を図１５に示す。
【００５５】
このように自分の担当する仕事を全体のスケジュール中で示すようにすることで、仕事や活動の全体目的と自分が担当する作業の目的との関係が把握できるようになる。
【００５６】
９つのドットを四角形状に配置し、それらドットを一筆書きで結びなさいとする、いわゆる「ナイン・ドット問題」のように、「自分の仕事」という見えない枠を勝手に作ってしまい、大きな仕事の目的が見えないと、些細なことに捉われて右往左往してしまうものである。全体を見ることで、高い効率で仕事をすることがきるようになる。これが、ハイ・パフォーマーの思考プロセスである。
【００５７】
リバース・スケジュールでは、Weekly版やDaily版で、プロセスを時間ブロック（囲み
）表示し、特に重要なプロセスの終わり（区切り）を「マイルストーン」として明示していく。
【００５８】
ブロックは色分けや、斜線などの模様のパターンで区別する（図１６参照）。また、バッファー（緩衝期間）も同様にブロックとして表示するが、プロセスのブロックとは区別しておく。
【００５９】
「仕事（タスク）はプロセスの集まり」と考えて、プロセスに分けることにより、コントロールしやすくなる。ただし、あまりにプロセスを「論理的に」分けることばかりに捉われると、これがたいへんな労力になる。このため、実務的には、プロセスを時間単位で分けることは簡単で効果のある方法といえる。
【００６０】
30分や45分、60分など先に適当な（自分に合った）時間単位を決めて、この時間単位の中で、インプットとアウトプットを考えるというやり方である。発明者が調査したところによれば、ハイ・パフォーマーは、「自分に適した」時間単位を明確に把握している。30分、45分という単位が多いが、意外にも60分は少なく、15分や90分という人もいる。90分という人も、実は、コントロールの単位としては、30分という単位を意識していることが判明した。
【００６１】
この癖がつくとあらゆるプロセスが、30分や45分の倍数で自然に処理できるようになる。気持ちにハリ（緊張感）ができ、集中力も向上する。「頑張ればできる」という達成感を実感することにもなる。つまり、時間単位を決めることが好循環をつくりだすきっかけになる。これを、リバース・スケジュールに時間ブロック（囲み）として表示するわけである。
【００６２】
次に、特に重要なプロセスの終わり（区切り）を「マイルストーン」と呼んで、重点的にチェックするようにする。
【００６３】
マイルストーンの意義は、３つの重要なポイントがある。
（１） 目標や成果（中間目標や中間成果物など）を評価、確認する。
（２） 他の仕事との連携をとる、確認する。
（３） 仕事の依頼者から、次に進めるための承認を得る。
の３つである。
【００６４】
このマイルストーンを順々にクリアしていくことで、目標を達成できる。
【００６５】
これは、スケジュールを何でもかんでも全て計画通りに管理しようとするのは「労多くして実り少なし」という考え方に基づいている。計画はあくまでも計画。その通りにいくことは稀であるし、完璧な計画を作ることは不可能である。プロジェクト・マネジメントでは、スケジュールを「変更管理」の仕組みを前提とする。変更のコントロールが重要だと考えており、計画を絶対のものとはみていない。現実には予測不可能なことが飛び込みで入るからである。そのために、リバース・スケジュールでは、まず、マイルストーンを厳守することに重点をおく。そして、必ず、マイルストーンの前にバッファー（緩衝期間、緩衝時間）を設けて、これを管理する。
【００６６】
マイルストーンの達成が危うくなるケースでも、バッファーが使われていく状況を見ていれば、事前に対処できる。リバース・スケジュールでは、このバッファーも、時間ブロックとして明確に表示する。緩衝期間や緩衝時間をコソコソと作業のプロセスの中に入れて、プロセスの時間ブロックを大きくするのではなく、安全余裕として堂々とバッファーとして示す。
【００６７】
このため、バッファーはプロセスの時間ブロックとは区別できるようにしておく。また、バッファーが消費されていく状況を色付けなどで示していくと良い。
マイルストーンについて、さらに述べると、「他の仕事との連携」や、「依頼者の承認を得る」場合は、マイルストーン自体の予定が、キーパーソンなど忙しいひとの予定により、左右されることも多い。このような変更リスクを想定し、先手を打って予定の確認や、
調整をする必要がある。例えば、マイルストーンの表記（一般には▲などの記号を用いる）を、○の中に十字で切って、マイルストーンの確度をチェックし、確度があがると塗りつぶしていく。チェックの回数は重要度によるが、図１６に示したように、最大で４回チェックする。★（ただし、４回でなくとも、それ以上でもよいことはもちろんである）。
【００６８】
リバース・スケジュールには、「アウトプット−インプット−プロセス・リスト（OIP
リスト）」がある（図１７）。これは、プロセス思考で考えるためのものであるが、スケジュール自体にこのような情報を書き込むと煩雑になるために、リスト化したものを活用する。これは、「仕事（作業）の棚卸し」リストとしても意義がある。
【００６９】
プロセスは、「インプットには何が必要か、誰がインプットを提供するのか。」、「アウトプットは何か。誰にアウトプットを提供するのか。」ということを明らかにすることを考える。
【００７０】
例えば、自分の担当する仕事について、その仕事に取り掛かる前の準備のために何が必要なのか。頭の中で押さえているつもりでも、それを紙などに書いてみると、思ったより多くのことをしなければならない事に気づくことがある。
このようなことを体系的におこなうために「アウトプット−インプット−プロセス・リスト（OIPリスト）」（仕事の棚卸しリスト）がある。
【００７１】
ここで、重要なのは、時の流れに逆行して「リバース」で考えることである。最終アウトプットから、その最終アウトプットに必要なインプットおよびプロセス、そのインプットを作るためにさらに必要なプロセスという逆順で考えていく。
【００７２】
まず、その仕事の最終アウトプットは何かということから、書き出していく。「仕事を引き受けているんだから、何をつくるかは知っている。そんなことあたりまえ。」だと思っていても、意外に、本当に求められているアウトプットは何かということが曖昧な場合も多い。これは、実は、依頼者側にも問題がある。依頼者自身が要求事項を明確に整理することができない場合も多い。（なお、依頼者自身の要求事項を調達マネジメントの専門用語では、RFP（Request For Proposal;提案依頼書）という。）ただ、相手の弱点を指摘するばかりでは意味がないので、仕事の成功のためにお互いに智恵を出し合うことが重要である。
【００７３】
このために、プロセス思考で考え、文書で示すのがたいへん意義のあることである。「アウトプット−インプット−プロセス・リスト（OIPリスト）」は、その準備としても活
用できる。
【００７４】
その名前のとおり、アウトプット→インプット→プロセス名の順で考えると良い。最後の、プロセス名を考えることは、普段は意識していないかもしれない。プロセス名などなくても、仕事をするのに困らないわけであるが、自分が具体的にどういう仕事（作業）をしているのか、これからしていくのか、プロセスに名前をつける過程ではっきりと認識できるようになる。このためにも、アウトプットから考えることは意味がある。これは「仕事（作業）の棚卸し」リストとして考えても、自分の仕事を見直し、仕事の効率を求めるうえでの出発点である。
【００７５】
リバース・スケジュールでは、図１８のような「To Do ストラクチャー・リスト」（TDSリスト）を活用して、仕事（作業）のヌケやモレを防ぐ。一般のTo Do リストと違うの
は、構造（Structure）を意識して作るという点である。
【００７６】
To Doリストの効用は、誰もが認めることとなろう。やるべきことをリスト化しておく
というのは、仕事の基本である。ただし、これは、「やるべきこと」にヌケやモレがないことが大前提である。あるいは、リスト化した項目に、よく考えると同じことを、やっていたという重複の問題もある。そして、MECE思考として、ロジカルにこの問題を考える方法がある。ポイントは構造化して考えるということである。「To Do ストラクチャー（Structure）リスト」（TDSリスト）は、そのためにある。
【００７７】
「構造化」というといかにも難しそうであるが、「型」について練習すれば、必ず要領をつかむことができる。「型」というのは、武道などの「型」のことである。ロジカルな考え方は、理屈はわかっても最初は難しい。そこで、「型」から入る。はじめから、ヌケやモレを恐れるあまり、闇雲に思いつくものを列挙していくのは、無手勝流である。まずは２つに分解し、次は３つに分解してというように、予め決めた数にしたがって、その数の分だけ考えていけば良い。型に慣れたところで、予め決めた数にとらわれない応用が利くようになるであろう。心に留める空手の師の教えに『型は美、技は心』というものがある。物事の本質を求める考え方に相通じるものを感じたのである。MECE思考も型から入るということをここでは試してみる。
【００７８】
仕事の構造化ができれば、次に仕事（作業）間の関連付けを考える。時間軸で考えると、論理的に次の４つのパターンがある。
仕事（作業）間の関係
(1) FS（終了−開始）
先行作業が終了したら開始する。最も一般的。
(2) SS（開始−開始）
先行作業が開始したら開始する。開始日をずらすようなケースもある。
(3) FF（終了−終了）
先行作業が終了したら終了する。あまり使わない。
(4) SF（開始−終了）
先行作業が開始したら終了する。ほとんど使わない。
【００７９】
リバース・スケジュールでは、通常の時間軸とは逆に考えるのが基本であるが、この仕事（作業）間の関連付けを考える際は、素直に通常の時の流れに沿って考える。これは、逆ということにこだわり過ぎて、本来の時の流れで考えると作業間の関係に不備や矛盾が出てしまわないように、行うことを意味する。
【００８０】
さて、FSというのは、ある作業が終わったら次の作業を開始することができるという最も一般的な関係である。
【００８１】
また、SSというのは、ある作業の開始をきっかけとして、別の作業を開始する場合である。例えば、何かの受付作業が開始されたら、申し込み作業をするなどである。作業間の関係は、この２つのパターンでほとんど事足りるであろう。
【００８２】
ちなみに、FFというのは、ある作業が終了すると、別の作業も終わることができる場合で、お店などで現金の勘定を突合する作業が終わると1日の締めの処理が終わるという例
がある。
【００８３】
SFは、比較的稀なパターンであるが、ある作業が開始したら、別の作業が終了するという場合である。例えば、システムの移行作業は、本番作業が開始したら終了するというようなケースである。
【００８４】
要するに、何らかの作業間の関係を明らかにした上で、リバース・スケジュールでは、
「FSのパターン」を最後の作業から逆に、「先行する作業は何か」ということを順々に考えていけばよいのである。
【００８５】
リバース・スケジュールには、「Don't To Doリスト（DTDリスト）」というものがある。これは、一般に知られている「To Doリスト」とは逆の発想で、「〜しないこと」のリ
ストである。この「Don't To Doリスト（DTDリスト）」を活用して、目標の達成を妨げる制約を明らかにする。
制約とは、何もおおげさなものばかりではなく、日常の中に見えなくなってしまっていることが多いものである。これを高い視点から見直すことで、「何だ。（時間がないと悩んでいたのは）簡単なことだったのだ。」ということに気づくことがある。1日は24時間し
かない。これは変えられない。したがって、「使える時間をつくる」には、「あれか、これか」の選択をするしかない。しかし、頭でわかっていても、実際に行動している人は稀である。
【００８６】
そこで、全体の目的達成のために、「Don't To Doリスト（DTDリスト）」を作るのである。「〜しないこと」のリストである。もう日常化してしまったこと、例えば、eメール
の処理、新聞を読む、パソコンを使うことさえも見直してみるのである。「ナイン・ドット問題」を想いだしてみよう。日常の中で無意識に作り出した制約が至るところに存在するのである。
【００８７】
例えば、Daily版の「Don't To Do」に「今日は、eメールの処理をしない」という項目
を書いて、「やらないことを実行」してみよう。当然、その分の時間は、本来やらなければならないことに使うことができる。反論もあるだろう。「結局、後で処理が増えるだけ。」「重要なメールがあったらどうするのか。」というものである。これは、全体の視点（高いところからの視点）でみることができていないのである。「すべてのメールを処理しなければならない。」という制約を自分に課していることに気づくであろう。また、見逃して困るような重要な事柄のコミュニケーションをeメールという手段のみに頼ってい
ることがリスクである。普段から情報の重要度や優先度に応じたコミュニケーション方法の確立をすることが、より本質的な問題であろう。
【００８８】
ある会社では、組織のルールとして1週間に1日メールを禁止しているところがある。その会社では、eメールが社内に浸透するにつれ、コミュニケーションの問題によるトラブ
ルが顕在化してき。そこで、思い切って1日禁止をルール化し、eメールに頼らないコミュニケーションが活性化するという効果を上げたのである。
【００８９】
さて、職場において、残業は日常化しているであろうか。これは、毎日の残業時間を取ってみればわかる。「残業をしない。」というのも実行するとメリットが大きいものである。残業のうち、いわゆる「つきあい残業」は論外であるが、「目いっぱいやっている」というひとでも、本来の通常勤務時間での効率を見直す余地のある場合が多い。人間は、そんなに長時間集中できない。これは、人間だから仕方のないことである。無理をすると体を壊す。時間の量ではなく、効率（スピード）にこそ、優先すべきことである。このためには、戦略的に考えることが必要である。最近は、水曜日を「ノー残業デイ」として早帰りをする会社も増えてきたが、何か効果を上げたという話は聞かない。かえって他の日の残業が増えたというのが実態ではないだろうか。
【００９０】
このような中で、営業日全ての残業禁止をルール化して、社員の勤務時間が減っているにもかかわらず、増収増益を達成している会社がある。これは、全  体の視点から目標達成に「必要なこと必要でないこと」を戦略に考えての「残業禁止」であり、社員全員にこのような戦略的発想が浸透しているのである。この会社でも「残業をしなければ仕事は終わらないものだ。」という既成概念から反発があったと聞く。それを克服して、増収増益
を続ける会社になったのである。このように戦略的発想を持たない形だけの「残業禁止」を実施しても効果は期待できない、ということである。
【００９１】
リバース・スケジュールを使うときも同じことが言える。「Don't To Doリスト（DTDリスト）」は、全体の目的達成のためのツールである。Weekly版のDTDリストに「水曜日は
、残業をしない。」として、効果が出るかでないかは、使用者の戦略的発想次第なのである。
＜本発明の具体的機能実現手段＞
以上は、リバース・スケジュールの基本的考え方である。本発明では、上記のような考え方をベースに、以下のような手段を実現する。すなわち、上記考え方を基に、アナログ的な手帳の構成を設計し、また、ソフトウェア利用発明として、パーソナル・コンピュータや専用のPDA (Personal Digital Assistance)で実行可能なリバース・スケジュール・
システムを提供する。
【００９２】
まずは、コンピュータで実行可能なソフトウェアとして、本発明のリバース・スケジュール・システムは、目標達成の予定日である終了日を設定する終了日設定手段と、この終了日設定手段で設定した終了日に所定の計画が完了するように所定の必要時間を想定して開始日を設定する開始日設定手段と、上記終了日設定手段で設定された終了日を開始日設定手段により設定した開始日より、時の流れ方向とは逆方向の時系列で表示するカレンダー表示手段と、カレンダーのスケジュール欄にタスクを入力するタスク入力手段と、をコンピュータ上で実現することを特徴とする。
【００９３】
カレンダー表示が時の流れとは逆方向で年月日を表示するように制御されるため、目的達成の予定日たる終了日や、の終了日から逆算して設定されたプロジェクトの開始日は、カレンダー表示において、終了日が先に示され、開始日は後に表示される。
【００９４】
ここで、前記終了日設定手段は、未来の任意に選択した所定の期日から所定の緩衝期間を遡った日を終了日として設定する。この緩衝期間はゼロであってもよいが、プロジェクトの特性や内容に応じて、一般的には数週間から数ヶ月となろう。
【００９５】
また、前記開始日設定手段は、当該プロジェクトに要する時間を推定し、当該推定時間を基に終了日から開始日を逆算して設定することが可能である。しかし、そのように自動計算せずに、ユーザが自身の経験則に従い、おおよその目安をもって、当該期間を想定して任意に開始日を設定するようにしてもよい。すなわち、開始日設定手段としては、自動設定とマニュアル設定の２つの場合があるということである。
【００９６】
プロジェクトは、複数の仕事（タスク）の実行により完成されると考えるとき、終了日と開始日との間に、タスク入力手段で遂行すべき仕事（タスク）を入力する。すなわち、所定の日にどのようなタスクを実行するのかを予定としてスケジュール欄に入力するのである。
【００９７】
そして、遂行すべき仕事（タスク）をそのプロセスに分けて配分するプロセス配分手段を備えるとよい。そのプロセス配分手段は、プロセスの遂行時間として、例えば、30分から90分の間の任意の時間を割り当てる。これにより仕事の遂行をよりコントロールしやすくなる。このため、プロセス入力手段と、プロセス遂行時間指定手段を備える。
【００９８】
さらに、設定した終了日と開始日との間に、達成の目安となるマイルストーンを設定するマイルストーン設定手段を備え、前記カレンダー表示手段は、当該マイルストーンをカレンダー上に表示することができる。
【００９９】
マイルストーンは、プロジェクト遂行の中間地点であり、中間的な目標としての意義を有する。その設定は、何らかのマークをカレンダー上に表示するだけでよい。ただし、上記のように、プロセス配分手段で、複数のプロセスに配分した場合、その中の指定したプロセスの終わりにマイルストーンを設定するとよい。
【０１００】
さらに、マイルストーンの前にバッファー（緩衝期間、緩衝時間）を設定するバッファー設定手段を備えることができる。緩衝期間あるいは緩衝時間としては、予め所定時間値を与えておく。
【０１０１】
そして、マイルストーン設定手段で設定したマイルストーンに対応して、当該マイルストーンが設定された日付で、開始日からの出来高もしくは目標達成率を入力したとき、当該出来高もしくは目標達成率と、終了日までの予定日数との関係から予測終了日を推定し、予測終了日と設定終了日との差を表示するようにすると、予定の終了日まで余裕があるのかないのかがわかる。これによって、スケジュールを修正することもできる。そして、その差に応じて、自動的に終了日修正手段で設定終了日を修正してもよい。特に、予定より遅くなっているときは、予定の遅延量を推定し、その遅延量に応じて、終了日の遅延日数を計算して、修正終了日を示すことが望ましい。
【０１０２】
そして、設定した開始日から、毎日、毎週、毎月の少なくともいずれかにおいて、達成した出来高もしくは達成率を入力する、達成率入力手段と、この達成率入力手段で入力された出来高もしくは達成率により、達成した仕事量を、毎日、毎週、毎月の少なくともいずれかの目標仕事量に対比して表示する達成仕事量表示手段と、を備えることもできる。
【０１０３】
さらに、プロジェクトを構成する仕事をプロセスに分けるとき、そのプロセス毎にアウトプット−インプット−プロセス・リストを作成するOIPリスト生成手段を備えるとよい
。すなわち、最終目標達成のための最終プロセス名対応でその目標成果（アウトプット）を入力するアウトプット入力手段を備え、そのアウトプットを得るためにすべきこと、すなわち、インプットを入力するインプット設定手段を備えるとともに、さらに、当該インプットを作るために必要となる前提のプロセスを設定する、前提プロセス設定手段を備えるとよい。
【０１０４】
以上のシステムは、スタンドアローンのローカルなコンピュータ上、あるいは、独立した電子手帳装置で実施されるものであるが、インターネットまたはイントラネット上のサーバにプログラムをインストールして、ネット上で、複数の者が端末を介して利用できるようにしてもよい。
【０１０５】
すなわち、インターネット上に配置されるサーバにインストールされて実現されるスケジュール管理システムであり、
Webブラウザの登録画面を通じて、インターネット端末から利用ユーザの情報を登録
するユーザ登録手段と、
ユーザ登録手段で登録されたユーザ毎にスケジュール手段を形成するスケジュール形成手段と、
ユーザ毎に形成したスケジュールをユーザ端末に配信してブラウザに表示する配信・表示手段と、
を備え、
前記ユーザ毎のスケジュール手段は、それぞれが、上記のような種々の機能実現手段を有することを特徴とする、リバース・スケジュール・システムである。
【０１０６】
次に、プロジェクト・マネジメント用に本システムを利用することもできる。この場合、多数のタスクから成る一つのプロジェクトを実行するにあたって、各タスクを複数の担
当者に割り当てるとともに、
ネット上に配置されるサーバにインストールされて実現されるスケジュール管理システムとして構成され、
前記担当者の端末からアクセス可能であるとともに、タスク毎にスケジュール手段を形成するスケジュール形成手段と、
タスク毎に形成したスケジュールを当該タスクの担当者端末に配信して表示する配信・表示手段と、
を備え、
前記タスク毎のスケジュール手段は、それぞれが、上記した種々の機能実現手段を有することを特徴とする、リバース・スケジュール・システムとする。
【０１０７】
ここで、プロジェクトの完了日を設定するプロジェクト完了日設定手段と、
このプロジェクト完了日設定手段で設定した、プロジェクト完了日から、プロジェクト完了までの必要時間を想定して開始日を設定するプロジェクト開始日設定手段と、
を備え、
前記タスク毎のスケジュール手段は、プロジェクト完了日設定手段により設定されたプロジェクト完了日とプロジェクト開始日設定手段により設定されたプロジェクト開始日との間において、前記タスク毎のスケジュールを設定するものであり、
各タスク毎のスケジュールの関連付けをするとともに、進捗状況を監視して、一つのタスクの終了日が遅延するおそれがあるとき、それに関連するタスクのスケジュールにその旨を通知する、遅延影響通知手段を有し、
さらに、プロジェクトの遂行にボトルネックとなるタスクを特定し、当該ボトルネックのタスクの進捗状況を他のタスクのスケジュールに通知するボトルネック通知手段を備えるようにすることもできる。
【０１０８】
ボトルネック通知手段は、全体プロジェクトの中のボトルネックをシミュレーションで見つけ出すために、各タスク毎のスケジュールにおいて、始まってからの出来高をみて、ネックとなりそうなタスクを特定するボトルネックタスクの洗い出し手段を備えるとよい。
【０１０９】
さらに、計画を実行するために遂行する各タスクにおいて、
スケジュールに各タスクを構成するプロセスを登録するプロセス登録手段と、
当該プロセスにつき、前記タスクを遂行する上で、必須なものとそうでないものとを特定する必須プロセス特定手段と、
必須でないプロセスについて、遂行の優先順位を特定する優先順位特定手段と、
を備え、
タスクの出来高に従って、遅延が予想されるとき、タスクの内の優先順位の低いプロセスにつき、そのプロセス遂行の中止を促してタスクの遂行計画を見直す、スケジュール修正手段をさらに有するようにしてもよい。
【０１１０】
タスクの遂行計画を見直すスケジュール修正手段として、don't to do listを有し、このdon't to do listにプロジェクト遂行上やってはいけないプロセスあるいはプロジェクト遂行に関係のないプロセスを登録するようにもできる。
【０１１１】
以上は、プログラムによって実現されるものであるが、紙の手帳により、本発明のリバース・スケジュールを構成することも可能である。
【０１１２】
すなわち、カレンダー表示を有し、カレンダーで示される年月日において、毎月、毎週、毎日の内のいずれか毎にスケジュールを書き込む、毎月、毎週、毎日のいずれかのスケジュール欄を有し、当該スケジュール欄を有するカレンダー表示が、時の流れ方向とは逆
方向の時系列で表示されていることを特徴とするリバース・スケジュール手帳である。毎月、毎週、毎日のいずれかのスケジュール欄があればよいが、一般の使用のためには、年間スケジュール欄が望ましく、12ヶ月表示、毎月の週表示、週における7日間表示がなさ
れ、それらに所定の予定を書き込む欄が設けられる。この点は通常の手帳と同じであるが、最大の特徴は、それらが、時の流れとは逆方向に並ぶことである。これにより、毎日、毎週、毎月のリバース・スケジュールが形成される。
【０１１３】
そして、毎日のスケジュール欄に、２４時間の時間割表示を有し、この２４時間の時間割表示が、時の流れ方向とは逆方向の時系列で表示されるようにすることも可能である。
【０１１４】
さらに、30分から90分の間の所定時間でタスクを実行するためのプロセスを配分するプロセス記載欄を設けることも可能である。
【０１１５】
そして、スケジュール欄に、目標達成の予定日である終了日を設定するともに、その終了日までに目標を達成するためのタスクを実行するために要する時間を考慮して、タスク開始日を設定したとき、当該タスクの進捗状況を示す出来高もしくは達成率を記載する達成率記載欄を各スケジュール欄に有するようにすることも可能である。
【０１１６】
そして、プロセス対応で、目標成果（アウトプット）−そのためのインプット−その前提となるプロセスを記載するアウトプット−インプット−プロセス・リストを備える。
【０１１７】
ここには、まず、アウトプット記載欄に、最終目標達成のための最終プロセス名対応でその目標成果（アウトプット）を記載する。さらに、インプット記載欄に、前記アウトプットを得るためにすべきこと、すなわち、インプットを記載する。そしてさらに、当該インプットを作るために必要となる前提のプロセスを前提プロセス設定欄に記載する。これを順次繰り返すと、プロジェクト達成に必要なプロセスを逆にたどることができる。
【０１１８】
また、タスクの遂行計画を見直すために、スケジュール修正手段として、don't to do list欄を有し、このdon't to do list欄にプロジェクト遂行上やってはいけないプロセスあるいはプロジェクト遂行に関係のないプロセスを登録することで、スケジュール管理をより確実にできる。
【０１１９】
そして、スケジュールの開始日から予定終了日までの間に、マイルストーンを置くためのマイルストーン記載欄を有し、マイルストーンを設置した日時において、スケジュールを守れたか守れなかったかを記載するようにする。
【０１２０】
さらに、プロジェクト・マネジメント用のリバース・スケジュール手帳であり、複数の担当者に振り分けられるタスクのリストを記載するタスクリスト欄と、当該タスクリストに対応して、スケジュール欄を有するカレンダー表示を有するようにすることができる。
【０１２１】
このようなシステム及び手帳は様々な目標達成のために利用できる。
【０１２２】
例えば、ダイエット用のリバース・スケジュールである。この場合、スケジュール欄に、目標体重への減量を達成すべき予定日を終了日として設定するとともに、ダイエット開始日を設定し、ダイエット開始日から、ダイエット終了日までの間に、ダイエットに必要なメニューを記載してあるとともに、当該メニューの達成・非達成を記載する達成度記載欄を有する。
【０１２３】
また、園芸のためのスケジュール管理にも利用できる。例えば、春先にある特定の花を咲かせるための手入れとして、どのようなことを、どのような時期にすべきかを決めるた
めに利用できる。
【発明の効果】
【０１２４】
以上のように、カレンダー表示を、時の流れとは逆方法の並びで表示し、そこに、プロジェクト達成の予定終了日と、そのプロジェクトの開始日を記載し、それが、予定日側から逆に示される。
【０１２５】
よって、手帳の使用者は、常に、目標達成日を認識することになり、スケジュールの達成をコントロールしやすくなる。
【発明を実施するための最良の形態】
【０１２６】
以下、本発明の最良の実施形態を、図面を参照して説明する。
【０１２７】
まずは、基本となる手帳による実施形態を説明した後、その手帳での管理を電子手帳やパーソナル・コンピュータでの管理に置き換えた例、さらには、会社内でのイントラネット、また、インターネットを利用したＡＳＰサービスなどでの利用形態について説明する。
【０１２８】
＜システム手帳としての実施例＞
図1から図４では、Yearly版、Monthly版、Weekly版、Daily版のリバース手帳であり、
このシステム手帳では、これらをすべて手帳用バインダに組み込んである。
【０１２９】
年、月、週、日、時間等、単位こそ異なるものの、いずれにも共通するのは、時の流れとは逆の方向で、カレンダー表示をし、スケジュール欄を設けた点である。
【０１３０】
図１９は、MS Project（登録商標）のガントチャート図であり、そのカレンダー表記を時の流れと逆方向にしたリバース・ガントチャートである。
【０１３１】
以下、これらを使用したリバース・スケジュールによるプロジェクトの遂行について説明する。
＜年末第九演奏会のためのリバース・スケジュール＞
ここでは、例えば、アマチュア演奏家によるベートーベンの第九番交響曲の演奏会を2006年12月31日に開催するものとする。
【０１３２】
この手帳を使うと、未来の予定が常に現在よりも前に表示されるので、意図的にプロアクティブな発想が起きる。12月31日から現在を振り返るとき、現時点は2005年11月10日であるから１年強の余裕がある。
【０１３３】
そして、終了日から今日現在への逆の時の流れの中で、「必要な準備期間が確保されているのか」、「プロジェクト達成にはどんなタスクを実行する必要があるか」「準備にはどのタスクにいちばん時間がかかるか」、「他のタスクより優先すべきものか」、「それぞれのタスクはいつまでに終了しなければならないか」「そのためタスクはいつから開始すればよいか」を考えやすくなる。
【０１３４】
すなわち、プロジェクトを構成するタスクもそれぞれ、終了日と開始日を有し、それらをコントロールしなければならない。そこで、約１年弱の期間があれば、準備としてなんとか実現できそうだと判断し、開始日を2006年1月20日の土曜とする。土曜としたのは、
アマチュアは土日が集まりやすいからである。ここで、終了日と開始日が決まった。同じように、プロジェクトを構成する、タスクも上記のようにそれぞれ終了日と開始日を設定していく。
【０１３５】
ここで、終了日を決定するにあたっては、「期日」との関係を理解しておく必要がある。「期日」は未来の特定の日ではあるが、終了日ではない。まず、期日を決定して、「期日」から時間を遡って（リバース・スケジュールでは、手帳の順序どおりに）、その仕事の「終了日」を設定する。「期日」＝「終了日」としないのは、様々なリスクの影響を軽減するためである。仕事の内容や期日の重要性に応じてこの「緩衝期間」は考えればよいと思うが、重要なのは、「まず、終了日を設定する」というアクションそのものである。自らが考えてゴールを設定しなければならない。よって、場合によっては「緩衝期間」＝無し、すなわち「期日」＝「終了日」としてもよいのである。このオーケストラのような場合、演奏会の開催日が終了日であるなら、期日＝終了日となる。しかし、演奏会のための万全な準備完了日を「終了日」とするのであれば、期日を12月31日とし、終了日をその一週間前に設定してもよい。
【０１３６】
次に、この終了日からさらに時間を遡って「開始日」を設定する。このとき、「頑張ればできる」という「開始日」を目標として設定することが重要である。ここで「作業効率」（仕事の効率）が決まる。むしろ、開始日を決めることは「作業効率を決める」といったほうようがよいかもしれない。
【０１３７】
このように「開始日」を設定すると、「現在」である2005年11月10日から「開始日」である2006年1月21日までの間に、相当の期間ができたことに驚くはずである。そこで、こ
の「現在」から「開始日」までの期間からなる「本来のゆとり」をどのように使うかを再度考える。この「本来のゆとり」は、別の仕事のために有効に使うことができるし、何も仕事に限らず、自由に利用できるのであるが、上記のプロジェクト達成のために必要なタスクを前倒しで準備する期間として利用してもよいことはもちろんである。例えば、演奏会場、練習会場の手配などである。先に、図１０を参照して、「本発明では、開始日を設定するにあたり、この確率期間を利用することができる。」と述べたのはこのことである。
【０１３８】
次いで、Yearly版の「年間目標シート」を利用し、1月21日から12月31日に至るまでの
間の練習日、練習内容を設定する。月1度の練習日を決定し、それを割り振っていく。但
し、最後の12月だけは、月前半の土日と、演奏会開催日の一週間前に練習日を入れ、29日、30日に最終練習日を入れることとする。
【０１３９】
終了日が、12月24日に設定されているなら、29日、30日は余裕をもって練習することができよう。ただし、12月31日を終了日としてもそれまでのスケジュールにより十分な成果は得られよう。
【０１４０】
さらに、Monthly版の「月間目標シート」を利用して、月1回の練習日を目標に毎月の個人練習日、練習内容、あるいは、パート別練習日、練習内容を決める。すなわち、1ヶ月
単位での、終了日と開始日の設定である。オーケストラの演奏のタスクとして、弦楽器奏者、金管楽器奏者、打楽器奏者、コーラスなど曲目の演奏パート・グループ毎の練習をタスクとして分け、それぞれが、月の合同練習に向けて毎週練習日を設定してもよいわけであるし、各演奏者が自主的に自分のパートを練習するスケジュールを決めてもよい。そのスケジューリングもリバース・スケジュールを使う。
【０１４１】
サラリーマンのオーケストラであるから、毎日の練習は不可能かもしれないが、それでもなお、Weekly版とDaily版を使って、練習項目を、「To Do ストラクチャー・リスト」
（TDSリスト）に設定し、毎日あるいは毎週の達成目標を設定していくことが好ましい。
【０１４２】
そして、以上の各練習日毎に、目標達成評価（出来高・達成率）をあわせて表示・記入
する。
【０１４３】
このように、「年間→月間→週間→日」というように、大きな単位から小さな単位に落とし込んでいく。オーケストラは、自分一人だけで完成するものではないので、これは全体をプロデュースする者が、各メンバーの意見を聞きながら決めていく必要があろう。各メンバーは、自分の担当部分の練習に専念しつつも、他のメンバーの仕上がり具合を気にしながら練習を進める必要がある。それらの相互コミュニケーションの仕事はプロデューサー（オーケストラでは指揮者がこれを兼ねても良い）の仕事である。
【０１４４】
各メンバーは、自分の仕事の目的を達成するためには、自身の担当する部分以外の仕事はないだろうか。それらの仕事との関係は理解しているだろうか。例えば、自分の担当する作業を受けて、他人の仕事が始まるという関係はないか。これらのことを理解できるような連絡をプロデューサーが行うとよい。
【０１４５】
これが、図１１に示したことである。
【０１４６】
次いで、リバース・スケジュールでは、Weekly版やDaily版で、プロセスを時間ブロッ
ク（囲み）表示し、特に重要なプロセスの終わり（区切り）を「マイルストーン」として明示していく。上記の例では、演奏パート・グループ毎の練習において、その目標が達成できているかを、マイルストーンを利用するが、さらに、Yearly版、Monthly版でも、マ
イルストーンを利用する。むしろ、このような年間に渡るプロジェクトでは、毎月の目標達成率を確認するためのマイルストーンが重要かもしれない。
【０１４７】
そこで、練習日となる予定日には、マイルストーンを設定し、そのマイルストーンに達成率を記入していく。マイルストーンは手帳のスケジュール欄に予めマイルストーン欄としての色分けのできる欄を印刷しておいてもよいが、粘着性を有するシールを該当箇所に貼り付けるようにしてもよい。
【０１４８】
ここで、マイルストーンは、一つのタスク（練習課題）を複数のプロセスに分け、最後のプロセスにマイルストーンを割り付けるとよい。上記例では、各パートを担当するメンバー個人の練習、その最後のプロセスとしての演奏パート・グループ毎の練習にマイルストーンを割り付ける。そこで、練習の成果を問う。
【０１４９】
その達成の程度は常に12月31日、あるいは、12月24日の終了日を、毎月の目標（全体の合同練習）の時点で意識させるので、マイルストーンでの達成率が低いときは、その後の練習はより意識的に集中したものとなろう。
【０１５０】
ここで、30分や45分、60分など先に適当な（自分に合った）時間単位を決めて、この時間単位の中で、インプットとアウトプットを考えるというやり方を取り入れて練習をする。特に、時間のないビジネス・パーソンは、昼休みにおいても楽器を使用せず、イメージで暗譜等の作業をすることができる。30分という単位は昼休み練習に最適である。
【０１５１】
マイルストーンにより、(1)練習の成果をその都度評価、確認し、(2)他のメンバーの仕上がり具合との連携をとり、確認することができ、(3)指揮者あるいはプロデューサーか
ら、次に進めるための承認を得ることができる。そして、このマイルストーンを順々にクリアしていくことで、練習の成果を徐々に上げていき目標を達成できる。完璧な計画の遂行は不可能である。プロジェクト・マネジメントにおける「変更管理」を前提とし、メンバーの不意の休みなどで、練習ができなくなった場合などに対処し、変更のコントロールをマイルストーンのタイミングで行う。マイルストーンの前にバッファー（緩衝期間、緩衝時間）を設けておくと、これが容易に行える。緩衝期間や緩衝時間を安全余裕として堂
々とバッファーとして示しておく。
【０１５２】
このため、バッファーはプロセスの時間ブロックとは区別し、バッファーが消費されていく状況を色付けなどで示す。多くのメンバーが集まる集合練習では、このようなバッファーは有効である。練習に遅刻してはならない、というストーリーは、仕事や家庭を持つアマチュア演奏家にとって現実的ではない。
【０１５３】
マイルストーンのチェックの回数は、図１３に示したように、最大で４回チェックする。
【０１５４】
大晦日での第九演奏会のプロジェクトの計画にあたってのリバース・スケジュールには、「アウトプット−インプット−プロセス・リスト（OIPリスト）」を用いるが、これは
、プロデューサーの役割であろう。
【０１５５】
演奏会を成功させるためには、種々のタスクを実行しなければならない。当日の会場や練習会場の手配、メンバーの募集、パート毎のメンバーによるチーム分け、指揮者の依頼、練習内容の決定（これは指揮者、各チームのトレーナーの役割）などが必要である。
【０１５６】
これによりメンバーは何をしなければならないのかが明かになる。そして、これらアウトプットのためにどのようなインプットが必要か、誰がインプットを提供するのかを考えることとなる。この思考も時の流れに逆行して「リバース」で考える。最終アウトプットから、その最終アウトプットに必要なインプットおよびプロセス、そのインプットを作るためにさらに必要なプロセスという逆順で考えていく。最終アウトプットはここでは、十分な練習成果であり、観客を感動させるに足る演奏である。
【０１５７】
リバース・スケジュールでは、さらに「To Do ストラクチャー・リスト」（TDSリスト
）を活用する。上記のOIPリストで、やるべきタスクは理解できた。目標設定も完了した
。そこで、仕事（作業）のヌケやモレを防ぐために、タスクの構造化を図る。タスクを構造化する。すなわち、弦楽器チームの練習は、どういうプロセスに分けられて成り立つのか。それぞれを構造化する。
【０１５８】
仕事の構造化ができれば、次に仕事（作業）間の関連付けを考える。練習会場の手配が完了して初めて練習が開始できる。これはFS（終了−開始）の関係である。各チーム毎の練習成果の確認と他のチームとの連携。これは合同練習の場で確認できる。各チーム同士の関係は、SS（開始−開始）の関係かもしれない。同時並行で実行できる関係である。
さらに、リバース・スケジュールにおける「Don't To Doリスト（DTDリスト）」に、制約をリストアップする。「〜しないこと」のリストである。練習時間を捻出するために「ネットサーフィンをしない」、演奏会の当日に風邪で休まないようにするために、「プロジェクト期間中には、仕事の夜の飲み会は出ない」などをリストアップしておく。
【０１５９】
なお、この例は、複数のメンバーによるプロジェクト・マネジメントである。よって、図１９で示したような、MS Project（登録商標）のガントチャート上でリバース・スケジュールを組んで、上記計画を立てるのが好ましい。
＜ゴルフのシングルプレーヤになるためのリバース・スケジュール＞
上記例は、複数のメンバーによるプロジェクトのスケジュールであったが、一人で実行するプロジェクトのためのリバース・スケジュールを説明する。
【０１６０】
ハンディキャップ１２のアマチュアゴルフプレーヤーが、現時点である2005年11月からゴルフの来シーズンである2006年5月までに、シングルプレーヤとなるためのリバース・
スケジュールを組む。
【０１６１】
まず、「期日」として2006年4月30日を選択する。その期日から余裕をもって逆算し、3月31日を終了日として設定する。
【０１６２】
そして、終了日から今日現在への逆の時の流れの中で、前記の例と同様に「必要な準備期間が確保されているのか」、「プロジェクト達成にはどんなタスクを実行する必要があるか」「準備にはどのタスクにいちばん時間がかかるか」、「他のタスクより優先すべきものか」、「それぞれのタスクはいつまでに終了しなければならないか」「そのためタスクはいつから開始すればよいか」を考える。
【０１６３】
ここで、ゴルフの練習方法には様々なものがあるが、レッスンプロなどのコーチ、トレーナーと相談して、メニューすなわちタスクを決定する。
【０１６４】
そして、約半年の期間があれば、準備としてなんとか実現できそうだと判断し、開始日を2005年12月１日とする。
【０１６５】
ここで、期日と終了日との間を1ヶ月とったのは、ゴルフの技能のレベルアップは思う
ほど容易ではなく、終了日とした時点で満足いかない結果だった場合、それをリカバーするには1ヶ月の余裕は必要と考えたからである。
【０１６６】
次いで、Yearly版の「年間目標シート」、Monthly版の「月間目標シート」を利用し、12月１日から３月31日に至るまでの間の練習日、練習内容を設定する。毎週土曜日の練習
ラウンド、毎週日曜のレッスンプロによるレッスン、毎朝のランニング、毎夜の自主練習の日程を入れるとともに、練習の種類をタスクとして割り当て、それらをさらにプロセスに区分して、カレンダーの逆方向から割り振っていく。タスクとしては、基本スイング練習、バンカー・アプローチ練習、ドライバーの練習、方向性の練習など様々なものがある。
【０１６７】
さらに、Daily版を使って、練習項目を、「To Do ストラクチャー・リスト」（TDSリスト）に設定し、毎日あるいは毎週の達成目標を設定する。
【０１６８】
そして、以上の各練習日毎に、目標達成評価（出来高・達成率）をあわせて表示・記入する。
【０１６９】
次いで、リバース・スケジュールでは、Monthly版、Weekly版で、プロセスを時間ブロ
ック（囲み）表示し、特に重要なプロセスの終わり（区切り）を「マイルストーン」として明示していく。そして、30分や45分、60分など先に適当な（自分に合った）練習時間単位を決めて、この時間単位の中で、インプットとアウトプットを考える。ここでは、アウトプットとして、目標地点に正確にボールを打つという成果を目指す。
【０１７０】
リバース・スケジュールでは、さらに「To Do ストラクチャー・リスト」（TDSリスト
）を活用する。アプローチの練習が意外にもドライバーの練習につながることも認識できよう。すなわち、アプローチの練習によりボールを捕まえることができるようになると、ドライバーの飛距離があがるのであり、タスクとしてアプローチ練習とドライバーの練習は、FS関係にあることが理解される。
【０１７１】
さらに、リバース・スケジュールにおける「Don't To Doリスト（DTDリスト）」に、制約をリストアップする。「〜しないこと」のリストである。ゴルフ練習を休まないようにするために、「会社の残業はしない」ことをリストの最上段に書いておく。
＜ダイエットのためのリバース・スケジュール＞
リバース・スケジュールは、途中で挫折しやすいダイエット・プログラムの実行にも効果的である。
【０１７２】
ここでは、ダイエット終了日とダイエット開始日を設定し、ダイエット開始日から、ダイエット終了日までの間に、ダイエットに必要なメニューを記載し、毎日のスケジュール欄に当該メニューの達成・非達成を記載する達成度記載欄を有する。
【０１７３】
例えば、身長160cmで体重70kgの女性が50kgまで減量することを目的とし、現時点であ
る2005年11月から来シーズンの海の季節2006年6月までに、目標を達成することとする。
【０１７４】
まず、「期日」として2006年６月30日を選択する。その期日から余裕をもって逆算し、５月31日を終了日として設定する。
【０１７５】
そして、終了日から今日現在への逆の時の流れの中で、前記の例と同様に「必要な準備期間が確保されているのか」、「プロジェクト達成にはどんなタスクを実行する必要があるか」「準備にはどのタスクにいちばん時間がかかるか」、「他のタスクより優先すべきものか」、「それぞれのタスクはいつまでに終了しなければならないか」「そのためタスクはいつから開始すればよいか」を考える。
【０１７６】
ここで、ダイエットの手法には様々なものがあるが、基本的には、取り入れるカロリーを減らすか、カロリー消費量を多くするかの少なくともいずれか一方を実践しなければならない。専門的なプログラムは、医師や栄養士、トレーナーなど専門家によるアドバイスを受けることが重要であるが、適切な指導マニュアルに沿う方法もある。
【０１７７】
そして、約半年の期間があれば、準備としてなんとか実現できそうだと判断し、開始日を2006年1月１日とする。
【０１７８】
ここで、期日と終了日との間を1ヶ月とったのは、終了日とした時点で目標の減量効果
がなかったとき、それをリカバーするには1ヶ月の余裕は必要と考えたからである。
【０１７９】
次いで、Yearly版の「年間目標シート」、Monthly版の「月間目標シート」を利用し、1月１日から５月31日に至るまでの間の食事メニュー、運動メニューなどのタスクを各日に設定する。さらに、Daily版を使って、食事と行動メニューを「To Do ストラクチャー・
リスト」（TDSリスト）に設定し、毎日あるいは毎週の達成目標を設定する。そして、以
上の各練習日毎に、目標達成評価（出来高・達成率）としての達成度を、達成度記載欄に記載し表示する。
【０１８０】
次いで、リバース・スケジュールでは、Monthly版、Weekly版で、プロセスを時間ブロ
ック（囲み）表示し、特に重要なプロセスの終わり（区切り）を「マイルストーン」として明示していく。「To Do ストラクチャー・リスト」（TDSリスト）では、食事と運動が
階層構造をもって、関連づけられ、ダイエットに効果的であることを理解する。
【０１８１】
さらに、リバース・スケジュールにおける「Don't To Doリスト（DTDリスト）」に、制約をリストアップする。「食べてはいけないもの」のリストである。ダイエットではきわめて重要である。
＜ソフトウェアによるシステムとしての実施例＞
次に、ソフトウェア利用発明として、パーソナル・コンピュータや専用のPDA (Personal Digital Assistance)で実行可能なリバース・スケジュール・システムを提供する。
＜スタンドアローン版＞
まずは、リバース・スケジュール・システムはコンピュータで実行されることで、以下
の機能実現手段をコンピュータ・ハードウェア上に実現する（図２０参照）。
【０１８２】
(1)目標達成の予定日である終了日を設定する終了日設定手段
この終了日設定手段は、未来の任意に選択した所定の期日から所定の緩衝期間を遡った日を終了日として設定する。すなわち、終了日設定手段は、任意に決定した将来の「期日」を入力する期日入力欄と、この期日入力欄に入力した期日から過去に遡って緩衝期間を設定する緩衝期間設定手段とを有し、終了日は、当該緩衝期間を勘案して期日から過去に遡った日に設定される。なお、緩衝期間はデフォルトとして1週間に設定されるが、これ
は、ゼロから最大例えば２ヶ月に変更可能とする。なお、プロジェクトの種類を入力することで、その性質を判断し、自動的に緩衝期間を設定してもよい。
【０１８３】
(2)終了日設定手段で設定した終了日に所定の計画が完了するように所定の必要時間を
想定して開始日を設定する開始日設定手段
開始日設定手段は、現時点から終了日の間の期間で、当該プロジェクトに要すると思われる時間を入力する期間入力欄を有する。
【０１８４】
なお、ユーザが自身の経験則に従い、おおよその目安をもって、当該期間を想定して任意に開始日を入力する。すなわち、もちろん、所定の条件からこの期間を自動設定するようにしてもよい。予め、デフォルト値として、プロジェクト期間を半年、１年等にしておいてもよい。
【０１８５】
(3)上記終了日設定手段で設定された終了日を開始日設定手段により設定した開始日よ
り、時の流れ方向とは逆方向の時系列で表示するカレンダー表示手段
前記した各手段で入力された、期日・終了日・開始日は、カレンダー表示上に表示されるが、当該カレンダー表示は時の流れとは逆方向で年月日を表示するように制御されている。よって、そのカレンダー表示において、期日・終了日・開始日の順で表示される。
【０１８６】
（4）カレンダーのスケジュール欄にタスクを入力するタスク入力手段
プロジェクトは、複数の仕事（タスク）の実行により完成されると考えるとき、終了日と開始日との間に、遂行すべき仕事（タスク）を割り振る。すなわち、所定の日にどのようなタスクを実行するのかを予定としてスケジュール欄に入力するのである。タスクの割り振りは、年、月、週のスケジュール表での割り振りとなろう。
【０１８７】
さらに、遂行すべき仕事（タスク）をそのプロセスに分けて配分するプロセス配分手段を備える。そのプロセス配分手段は、プロセスの遂行時間として、例えば、30分から90分の間の任意の時間を割り当てるものとする。このため、プロセス入力手段と、プロセス遂行時間指定手段を備える。
【０１８８】
(5)設定した終了日と開始日との間に、達成の目安となるマイルストーンを設定するマ
イルストーン設定手段
このマイルストーンは、前記カレンダー表示手段により、動物や植物の絵、○や△などの図形をスケジュール欄に表示するものである。
【０１８９】
そして、プロセス配分手段で、複数のプロセスに配分した場合、その中の指定したプロセスの終わりにマイルストーンを自動設定するようにしてある。
また、マイルストーンの前にバッファー（緩衝期間、緩衝時間）を設定するバッファー設定手段を有し、そのデフォルト値として、予め所定時間値を与えておく。
【０１９０】
そして、マイルストーン設定手段で設定したマイルストーンに対応して、当該マイルストーンが設定された日付で、タスクの出来高・達成率、開始日からの出来高もしくは目標
達成率を入力する達成率入力手段が設けられている。
【０１９１】
これら、当該出来高もしくは目標達成率と、終了日までの予定日数との関係から予測終了日を推定し、予測終了日と設定終了日との差を表示する手段も備える。
(6)アウトプット−インプット−プロセス・リストを作成するOIPリスト生成手段
これは、最終目標達成のための最終プロセス名対応でその目標成果（アウトプット）を入力するアウトプット入力手段を備え、そのアウトプットを得るためにすべきこと、すなわち、インプットを入力するインプット設定手段を備えるとともに、さらに、当該インプットを作るために必要となる前提のプロセスを設定する、前提プロセス設定手段からなる。
【０１９２】
(7)「To Do ストラクチャー・リスト」（TDSリスト）生成手段
タスクの構造化を図るために、タスクがどういうプロセスで構造化されているかを入力する。
【０１９３】
(8)「Don't To Doリスト（DTDリスト）」生成手段
タスク遂行の妨げとなる、してはいけないことを登録する手段である。
【０１９４】
次に、このシステムによる、リバース・スケジュールの使用法を説明する（図２１を参照）。
【０１９５】
まず、システムを起動する。初期画面では、計画するプロジェクト名、実行者の氏名を入力する。すると、年間計画カレンダー（Yearly版）が表示される。その表示は、図１のものがパソコン画面に表示される。なお、ここでは、初期設定として、Yearly版が表示されるよう設定してあるが、図２〜図４のようなMonthly版、Weekly版、Daily版のいずれかが最初に表示されるようにしてもよい。なお、起動後、いずれかを選択して表示させることもできる。
【０１９６】
次に、任意に決定した将来の「期日」を入力する期日入力欄から、特定の期日を入力する。すると、終了日設定手段の緩衝期間設定手段が、緩衝期間を過去に遡った日を終了日として特定するので、これを、終了日として設定する。
【０１９７】
さらに、開始日設定手段の期間入力欄に、当該プロジェクトの遂行に必要であろうと思われる大まかな期間を入力する。これにより、当該期間を終了日から過去に遡って開始日が設定される。
【０１９８】
これら、期日・終了日・開始日は、時の流れ方向とは逆方向の時系列で表示するカレンダー表示手段で、図１から図４における対応する日付の欄に、その旨の表示がなされる。その表示は、文字でもよいし、特定のキャラクタでもよい。
【０１９９】
次いで、プロジェクトで実行するタスクをカレンダーのスケジュール欄に記入する。プロジェクトは、通常、複数の仕事（タスク）の実行により完成されるので、終了日と開始日との間に、遂行すべき仕事（タスク）を割り振る。個々のタスクについても、上記と同様に、終了日、開始日を設定するようにしてもよい。例えば、タスク１を3月31日から2月1日の間で実行し、タスク２を5月31日から4月1日の間で実行し、タスク３を7月31日から6月1日の間に実行する。というようにする。
【０２００】
タスクは、日々これを実行していなかければならないものであるが、各タスクをプロセス配分手段で小単位のプロセスに分けて毎日のスケジュールに配分する。プロセスの遂行時間は、プロセス遂行時間指定手段で、30分から90分の間の任意の時間を割り当てる。
そして、タスク１〜３の実施にあたり、各タスクにつき、その終了日と開始日との間に、達成の目安となるマイルストーンをマイルストーン設定手段で設定する。マイルストーンは、ユーザが好きなキャラクタを選択でき、前記カレンダー表示手段により、選択した動物や植物の絵、○や△などの図形をスケジュール欄に表示する。
【０２０１】
マイルストーンの設定は、ユーザ自身が適度な位置に配置するが、期間の半分の位置、あるいは、3分の１の位置、3分の２の位置等、均等に分けるのであれば、自動的に位置づけしてもよい。また、特定の意義を有するプロセスを指定し、当該プロセスの終わりにマイルストーンを自動設定するようにしてもよい。
【０２０２】
その際、バッファー設定手段で、マイルストーンの前にバッファー（緩衝期間、緩衝時間）を設定する。その緩衝期間は、タスクやプロセスの内容によって、長短決めるが、ユーザ自身が予め所定時間値を与えておく。
【０２０３】
タスクの実行にあたり、ユーザは、毎日のスケジュール欄に、その日の達成状況を記録していく。そして、マイルストーンが設定された日付で、それまでのタスクの出来高・達成率、開始日からの出来高もしくは目標達成率を達成率入力手段で入力する。
【０２０４】
単にこれらの入力だけでも、ユーザは自身の計画が順調に実行されるつつあるのか、そうでないのかを確認できるが、さらに、システム側で、終了日修正手段が、当該出来高もしくは目標達成率と、終了日までの予定日数との関係から予測終了日を推定し、予測終了日と設定終了日との差を表示すると、ユーザにとって、タスクがどの程度進んでいるのか、容易に理解できる。特に、差によって、予定の遅延量を推定し、その遅延量に応じて、終了日の遅延日数を計算して、修正終了日を示すようにし、それでよければそれを確定して、予定を修正するようにしてもよい。
【０２０５】
なお、タスクの設定にあたっては、OIPリスト生成手段で、アウトプット−インプット
−プロセス・リストを作成する。タスクの最終目標達成のための最終プロセス名対応でその目標成果（アウトプット）を入力し、そのアウトプットを得るためにすべきこと、すなわち、インプットを考えて、これを入力し、当該インプットを作るために必要となる前提のプロセスを設定する。これにより、ユーザは自身が何をすべきかが理解できるようになる。必要なプロセスが理解されたら、さらに、「To Do ストラクチャー・リスト」（TDS
リスト）生成手段で、タスクがどういうプロセスで構造化されているかを入力する。
【０２０６】
そして、今度は、タスク遂行に必要でないことも考える。これを「Don't To Doリスト
（DTDリスト）」生成手段にてリスト化する。
【０２０７】
後は、常に目標の終了日をにらんで、その日に向かってカウントダウンをしながら、日々やるべきことをひたすら実行していけば、自ずと目標が達成される。リバース・スケジュールは、カウントダウン・スケジュールとも言うことができる。
＜インターネット版＞
以上のシステムは、スタンドアローンのローカルなコンピュータ上、あるいは、独立した電子手帳装置で実施されるものであるが、インターネット上のサーバにプログラムをインストールして、ネット上で、複数の者が端末を介して利用できるようにした例を説明する（図２２）。
【０２０８】
これは、インターネット上に配置されるサーバにインストールされて実現されるスケジュール管理システムであり、以下の機能実現手段からなる。
(1)Webブラウザの登録画面を通じて、インターネット端末から利用ユーザの情報を登録するユーザ登録手段
(2)ユーザ登録手段で登録されたユーザ毎にスケジュール手段を形成するスケジュール形
成手段
(3)ユーザ毎に形成したスケジュールをユーザ端末に配信してブラウザに表示する配信・
表示手段
(4)前記ユーザ毎のスケジュール手段にそれぞれ、設けられた、上記したスタンドアロー
ン版におけるのと同様な種々の機能実現手段群
すなわち、終了日設定手段、開始日設定手段、カレンダー表示手段、タスク入力手段、プロセス配分手段、マイルストーン設定手段、バッファー設定手段、達成率入力手段、終了日修正手段、OIPリスト生成手段、「To Do ストラクチャー・リスト」（TDSリスト）生成手段、「Don't To Doリスト（DTDリスト）」生成手段などである。
【０２０９】
これにより、ＡＳＰサービスとして当該スケジュールをユーザに提供することができる。
【０２１０】
その操作は、Ｗｅｂにアクセスし、自身にリバース・スケジュールを割り当ててもらう以外は、スケジュールを使用する上において、上記のスタンドアローン版と同じである。<インターネットでの共用版＞
これは、プロジェクト・マネジメントを遂行する場合に本システムを利用する場合で、上記インターネット版を複数の者が共用して、相互に連携をとって利用する。システム的には図２３と同様であるが、ソフト的にリバース表示のカレンダーに従ったプロジェクト・マネジメントトを実現する。
【０２１１】
この場合、多数のタスクから成る一つのプロジェクトを実行するにあたって、各タスクを複数の担当者に割り当てる。そして、それらを各人毎に割り当てられたリバース・スケジュールを使って遂行する。
【０２１２】
よって、以下の機能実現手段をサーバに有する。
(1)タスク担当者の端末からアクセス可能であるとともに、タスク毎にスケジュール手段
を形成するスケジュール形成手段
(2)タスク毎に形成したスケジュールを当該タスクの担当者端末に配信して表示する配信
・表示手段
(3)上記例と同様、前記ユーザ毎のスケジュール手段にそれぞれ設けられた、上記したス
タンドアローン版におけるのと同様な種々の機能実現手段群。
【０２１３】
ここで、プロジェクトの完了日を設定するプロジェクト完了日設定手段と、
このプロジェクト完了日設定手段で設定した、プロジェクト完了日から、プロジェクト完了までの必要時間を想定して開始日を設定するプロジェクト開始日設定手段と、を備える。
【０２１４】
そして、前記タスク毎のスケジュール手段は、プロジェクト完了日設定手段により設定されたプロジェクト完了日とプロジェクト開始日設定手段により設定されたプロジェクト開始日との間において、前記タスク毎のスケジュールを設定する。
【０２１５】
さらに、タスク毎のスケジュールの関連付けをするとともに、進捗状況を監視して、一つのタスクの終了日が遅延するおそれがあるとき、それに関連するタスクのスケジュールにその旨を通知する、遅延影響通知手段を有する。
【０２１６】
さらに、プロジェクトの遂行にボトルネックとなるタスクを特定し、当該ボトルネックのタスクの進捗状況を他のタスクのスケジュールに通知するボトルネック通知手段を備える。
【０２１７】
ボトルネック通知手段は、全体プロジェクトの中のボトルネックをシミュレーションで見つけ出すために、各タスク毎のスケジュールにおいて、始まってからの出来高をみて、ネックとなりそうなタスクを特定するボトルネックタスクの洗い出し手段を備える。
【０２１８】
さらに、タスクの遂行計画を見直すスケジュール修正手段として、don't to do listを有し、このdon't to do listにプロジェクト遂行上やってはいけないプロセスあるいはプロジェクト遂行に関係のないプロセスを登録する。
【０２１９】
図２３に、このシステムの運用フローチャートを示すが、個々人が行うことは先のスタンドアローン版とほぼ同様である。このシステムでは、プロジェクトを複数人で実行するため、管理の中心者を決め、その者が、全体を統括する必要がある。基本的には先の例と同様に、スケジュールを入れるが、管理者が、タスク毎のスケジュールの関連付けをすることが必要である。そして、遅延影響通知手段が、タスクの進捗状況を監視して、一つのタスクの終了日が遅延するおそれがあるとき、それに関連するタスクのスケジュールにその旨を通知する。
【０２２０】
そして、ボトルネック通知手段が、プロジェクトの遂行にボトルネックとなるタスクを特定し、当該ボトルネックのタスクの進捗状況を他のタスクのスケジュールに通知する。ボトルネック通知手段は、洗い出し手段が、各人のタスクの進捗状況（現時点での出来高）を常時監視して、全体プロジェクトの今後の進行具合をシミュレーションして、全体が遅延することとなったとき、どのタスクの遅延が全体の遅延に最も大きな影響を与えているのかを推定し、当該最も遅延影響の大きいタスクをボトルネックタスクとして特定する。
【０２２１】
なお、インターネットでプロジェクト・マネジメントを遂行するこの例では、図１９に示したリバース・スケジュール表示のガントチャートを共用するようにする。
【０２２２】
＜付加的な機能＞
なお、上記例において、毎日、毎週、毎月の少なくともいずれかにおいて、達成した出来高もしくは達成率を入力する、達成率入力手段と、この達成率入力手段で入力された出来高もしくは達成率により、達成した仕事量を、毎日、毎週、毎月の少なくともいずれかの目標仕事量に対比して表示する達成仕事量表示手段と、を備えることもできる。これは、マイルストーン毎に達成率を入れる場合と、重複するが、この機能と併存させてもよい。
【０２２３】
なお、達成率としては、当該仕事を実行したか、しなかったかだけのチェックだけでもよく、また、主観的な達成率であってもよい。
【０２２４】
なお、上記例で、キーボード等から入力されるデータ、自動生成されるデータは、コンピュータのメモリに格納され、ハードディスクなどの外部記憶装置の保存されること。また、図１〜図４のカレンダーの表記、図１９のガントチャート、各リストの表記などは、テンプレートとして予め設定され、記憶装置に格納されている。
＜ブログとの協働＞
ところで、今日、インターネットの世界では、ウェブログ（以下、ブログという）という形式のホームページが盛んである。このブログを本件リバース・スケジュール・システムと組み合わせることで、リバース・スケジュールを効果的に活用できる。
【０２２５】
すなわち、ブログでは、毎日自動的に日付つきで、日記風にデータを記録できる。その記録は、時の流れにそったものであるから、毎日の仕事の出来高や達成率を記録するには
好適である。
【０２２６】
そこで、このブログを達成率入力手段として利用する。上記したリバース・スケジュールと連携した個人のブログを設定する。当該ブログには、日単位で、リバース・スケジュールに登録したやるべきタスク（プロセス）を実行したか、どの程度進んだかなどを記録する。出来高には☆印や●印など、適当な識別用キャラクター（あるいはキーワード）でテキストデータの前後を囲んでおく。なお、当然であるが、このブログは非公開扱いとする。
【０２２７】
リバース・スケジュールには、ブログのＵＲＬを登録しておき、リバース・スケジュールから当該ブログにアクセスすると、ブログに載せた記事と、日付を参照し、その中から識別用キャラクタで前後を囲まれた部分をコピーして、リバース・スケジュールの当該日付の出来高記載欄に貼り付ける。
【０２２８】
これにより、自動的に、出来高や達成率がリバース・スケジュールの達成率記載欄に入力される。
【０２２９】
このように、リバース・スケジュールルは、非公開ブログと連携して、ブログに記載された記事を解析し、毎日のスケジュール欄に、出来高・達成率を移載するので、いちいちリバース・スケジュールの毎日の記載欄を開いて出来高を記入するより簡便に出来高を入力できる。
【図面の簡単な説明】
【０２３０】
【図１】リバース表示されたYearly版カレンダーを示す図
【図２】リバース表示されたMonthly版カレンダーを示す図
【図３】リバース表示されたWeekly版カレンダーを示す図
【図４】リバース表示されたDaily版カレンダーを示す図
【図５】「学生症候群」のイメージ図
【図６】従来型のスケジュール法による作業達成イメージ図
【図７】図５，図６を重ねた図
【図８】本発明のリバース・スケジュール法を端的に示す図
【図９】「HP(Highly Possible);まず大丈夫」を示す図
【図１０】５０％の確率で作業が完成することを示す図
【図１１】「年間目標シート」を示す図
【図１２】「月間目標シート」を示す図
【図１３】「To Do ストラクチャー・リスト」を示す図
【図１４】リバース・スケジュールでの目標とハイレベル目標との関係を示す図
【図１５】他人の仕事と自分の仕事との関係を示す図
【図１６】マイルストーンでの作業達成率をチェックする様子を示す図
【図１７】「アウトプット−インプット−プロセス・リスト」を示す図
【図１８】「To Do ストラクチャー・リスト」を示す図
【図１９】プロジェクト・マネジメント用のリバース・ガントチャート図
【図２０】スタンドアローン版のリバース・スケジュール・システム図
【図２１】リバース・スケジュール・システムのフローチャート図
【図２２】インターネット版のリバース・スケジュール・システム図
【図２３】リバース・プロジェクトマネジメントの運用フローチャート図
【図１】
2007140653.tif 000003
【図２】
2007140653.tif 000004
【図３】
2007140653.tif 000005
【図４】
2007140653.tif 000006
【図５】
2007140653.tif 000007
【図６】
2007140653.tif 000008
【図７】
2007140653.tif 000009
【図８】
2007140653.tif 000010
【図９】
2007140653.tif 000011
【図１０】
2007140653.tif 000012
【図１１】
2007140653.tif 000013
【図１２】
2007140653.tif 000014
【図１３】
2007140653.tif 000015
【図１４】
2007140653.tif 000016
【図１５】
2007140653.tif 000017
【図１６】
2007140653.tif 000018
【図１７】
2007140653.tif 000019
【図１８】
2007140653.tif 000020
【図１９】
2007140653.tif 000021
【図２０】
2007140653.tif 000022
【図２１】
2007140653.tif 000023
【図２２】
2007140653.tif 000024
【図２３】
2007140653.tif 000025