スケジュールは逆算で
計画の大小はあるものの自らスケジュールを立てる場面が多くあるはずです。
.
そんな時、皆さんはどうされていますか。
一般的にはやるべき事を列挙し、それを今から順に並べてスケジュールを立てられる方がほとんどの様に思います。いや、スケジュール自体をぼやっとしてか考えず、約束もされない人もおられる様です。これは非常に残念な現実です。
.
確かにITの仕事はやってみないとわからない事も多いのはわかりますが、かといってスケジュールを曖昧にすると、ずるずると目標達成が遅延するケースを多く見てきました。
.
システムに限った事ではありませんが、私はスケジュールはゴールからの逆算が基本だと思っています。いつまでにどうあるべきかという目標は必ずあります。それは利用部門の人に言われなくても、あなたが確認しないといけません。利用部門の人からいつでも良いよ。という要求も現実ありますが、それはあなたに遠慮されているだけと考えた方が良いでしょう。
.
例えば、今日が１０月だとして、新しいシステムを来期４月からスタートさせるゴールがあるとします。逆算でスケジュールを立ててみましょう。まず、４月スタートなので、システム完成は３月末と考えがちですが私はそうしません。３月は期末で業務部門も忙しく協力を得られない事を経験から学んでいます。私は更に２月完成もかなり危険とと考えます。システム開発というのは一発でＯＫという事は稀で、大抵の場合、利用部門に見せた後修正がかかる事が多々あるからです。結果、システムを１月末に完成させ、２月にユーザ評価と修正をかける予定にします。
.
システム開発にどの程度の期間を見るかですが、仮に開発に2ヶ月かかるとすると、11月末までに仕様を確定させなければなりません。要件定義～システム設計に1ケ月必要だとすると10月は準備期間に充てられます。途中に開発稟議決裁などが必要になると更に１ケ月必要になります。
.
まとめると
4月：システムスタート
2月：システム評価、修正
12～1月：システム開発
11月：システム設計
と考えます。これでも稟議決裁や何かあった時の為に10月と3月の2ヶ月のバッファがあります。
.
次に行うのは、スケジュールの実現可能性の確認です。
最初は逆算で考えますが、次に今から順を追ってこのスケジュールが実現可能なものかどうか確認します。特に考える事は、他部門や他社の協力を得ないといけない場合の協力の打診です。ユーザ部門だけでなく、開発を社外に委託する場合など、要員の確保や時期を先方に打診します。
.
そして再度微調整をかけた上で、ようやく実現可能性のあるスケジュールが出来あがるのです。
.
最初に目標や時期を明確にしている為、稟議資料も作りやすく、途中のスケジュール遅延が全体にどう影響するかも明確になります。
.
いきなり取り掛かるのではなく、全体を俯瞰した計画立案ができるかどうか。これが目標達成の為の基本のきだと私は思っています。
実現性のあるスケジュールを立てられれば、半分は成功したようなものだと思っています。
.
言うのは簡単ですが、これ以外とできていないIT要員の人多いですよ。
スケジュールは逆算で立てる癖を身につけましょう。
2025年4月21日