「プロジェクト」とは、PMIの定義では、
「独自の製品、サービス、所産を創造するために
実施される有期性の業務である」とされている。
有期性＝つまり期限が決まっているわけだ。
その期限はどうやって決めるのでしょうか。
経験則上、プロジェクトより上位概念である会社の
事業計画で目標期限が決まっており、その目標内に
収まるようにスケジュールを立てることが多い。
つまり、バックワード（逆算）でスケジュールを立てる。
個人の作業においても、期限を切って、それに収まるように
計画立てて作業を遂行する。むしろそうするからこそ、
質とスピードの両立が出来ると考える人は多い。
間違いではない。むしろ個人の場合はそうするべきだと思う。
だがバックワードには大きなリスクもある。
期限に間に合わせる事を重視し、根拠ある作業工数の
見積もり作業を手放してしまうことがあるからです。
（間に合わない可能性を感じていても目をつぶる）
よって、法的な要因でどうしても期限が決まってしまうケース
（消費税対応など）ではない限り、市場の素早い変化に
対応しないと会社が傾く危機であっても、失敗すれば仕事の
全てが止まってしまうような会社の基幹業務システム改修や
入れ替えでは、逆算はリスクが高すぎます。
そういったケースは、フォーワード（タスクの積み上げ）で期間を
見積もることを薦めている。
基幹業務などで、外部の取引先や顧客との連携が無い限り、
その変更は誰からも求められているワケではない。
なので、期限を切ってスピード導入する必要はなく、確実かつ高品質に
リリース出来る時期をしっかり見積もって実施するべきだと思います。
お金は？と思うかもしれないですが、2年で導入するより、3年で
導入した方が、じつは10億円くらい安かったなんてケースが多い。
根拠無く期限を切ってしまうと、低品質のシステムが出来上がり、
大量の障害が発生して改修費用がかかったり、使えないから
追加開発になるケース、間に合わせるために大量増員など、
結局、余計なお金を払う事になる。
多くは、年度、もしくは中期計画の期間内に結果を残したいから
何かしらの施策をやりきろうと考える上層部の思惑が逆算させるのだが、
（予算を使い切りたいからなんてとんでもないケースもある）
長い目で結果を出す事ことも時には必要だと思います。
「独自の製品、サービス、所産を創造するために
実施される有期性の業務である」とされている。
有期性＝つまり期限が決まっているわけだ。
その期限はどうやって決めるのでしょうか。
経験則上、プロジェクトより上位概念である会社の
事業計画で目標期限が決まっており、その目標内に
収まるようにスケジュールを立てることが多い。
つまり、バックワード（逆算）でスケジュールを立てる。
個人の作業においても、期限を切って、それに収まるように
計画立てて作業を遂行する。むしろそうするからこそ、
質とスピードの両立が出来ると考える人は多い。
間違いではない。むしろ個人の場合はそうするべきだと思う。
だがバックワードには大きなリスクもある。
期限に間に合わせる事を重視し、根拠ある作業工数の
見積もり作業を手放してしまうことがあるからです。
（間に合わない可能性を感じていても目をつぶる）
よって、法的な要因でどうしても期限が決まってしまうケース
（消費税対応など）ではない限り、市場の素早い変化に
対応しないと会社が傾く危機であっても、失敗すれば仕事の
全てが止まってしまうような会社の基幹業務システム改修や
入れ替えでは、逆算はリスクが高すぎます。
そういったケースは、フォーワード（タスクの積み上げ）で期間を
見積もることを薦めている。
基幹業務などで、外部の取引先や顧客との連携が無い限り、
その変更は誰からも求められているワケではない。
なので、期限を切ってスピード導入する必要はなく、確実かつ高品質に
リリース出来る時期をしっかり見積もって実施するべきだと思います。
お金は？と思うかもしれないですが、2年で導入するより、3年で
導入した方が、じつは10億円くらい安かったなんてケースが多い。
根拠無く期限を切ってしまうと、低品質のシステムが出来上がり、
大量の障害が発生して改修費用がかかったり、使えないから
追加開発になるケース、間に合わせるために大量増員など、
結局、余計なお金を払う事になる。
多くは、年度、もしくは中期計画の期間内に結果を残したいから
何かしらの施策をやりきろうと考える上層部の思惑が逆算させるのだが、
（予算を使い切りたいからなんてとんでもないケースもある）
長い目で結果を出す事ことも時には必要だと思います。