スケジュール表は、今後の日程的な予定と、進捗を測る上で重要な役割となります。
スケジュール表は1年以上にわたるような大きな流れであれば、マスタスケジュールという主要タスクと日付を示したものに始めとして、中日程スケジュール、詳細日程スケジュールと段階的に示したほうが分かり易いです。
今後の予定について段階化されていることで、今いる位置を知ることができるのと同時に、今後やるべきこともわかりますので、仕事を積極的に進めることができます。
スケジュールとは
日付を決める意味とは
スケジュールとは、タスクがいつからいつまで実施されるという具体的な日付がきまったものになります。
計画段階では、タスクを見出し、そのボリュームを加味して並べますが、途中段階では日付は相対的なものになっていることが多いです。
開始と終了の日付が決まってから、スケジュールとして確定したことになります。
もし相対的な日付になっている場合、つまり今から3か月後等の表現になっている場合は、スケジュール確定時には日付を埋めましょう。
日付はある意味覚悟になります。
日付とタスクが決まったことにより仕事の拘束が決まったことになり、もう逃げられない状態となります。
例え数か月先であっても具体的な日付が決まっていることで、そこに向かうというスイッチが入ります。
工程表とは
スケジュールは段階的に作成されている場合は、一番大きなものは工程表ともいえるものになっています。
工程は大きなタスクの括りと言えるでしょう。
システム開発であれば、要件定義、設計、開発、テスト、受け入れテスト、などの工程がいつからいつまでと決められたもので、大きな視点での進捗確認ができる土台となります。
また日付としての工程のつながりは、前後関係があるため崩せません。基本的な考え方は、あくまでも工程順に進んでいくというものです。
WBSとは
工程表は工程ごとに並んでいます。基本的には前工程が終わったら後工程が進んでいくことになります。
一方でWBSと呼ばれるものがあります。難しいのですべてタスクでいいとは思うのですが、よく使われてはいます。
WBSと呼ばれるレベルはかなり細かい単位でのタスクとなります。
人とタスクと日程を決めた最低単位のタスクになります。この積み上げが全体工程の進捗になるといことです。
工程表とWBSの違いとは
WBSは工程を進めるために実際にやることをすべて挙げます。
工程はその作業ができる状態になっていることで、終わったら次の工程ができるという目印になります。
工程はやることすべてを示しているわけではありません。よって例えば8月1日から工程が始まるとなっていたとしても、関連する作業はその前から始まっています。
これは基本的なことなのですが、多くの人が関わると勘違いしてしまう人が出てきます。
工事の例で言うと、4階建ての建物に対して、１階の建物部分が建ってから1階の内装工事が始められるという工程表だったとします。
1階の内装工事は1階の建物がないと物理的にできません。しかし、建物が建つのを待ってから内装工事の作業者や資材の調達を始めるでしょうか。
工程の切れ目というのはこのようなことが起きます。工程は順次実施されますが、実際はその前から動いているWBSはあるということです。
大きなスケジュールを見るときには、実際は裏で動いているタスクが多くあり、その進捗も見ないと工程前提の進捗は見えないということになります。
スケジュールの策定手順
具体的な日付を持った期間の設定
計画時にタスクを見出し、人を割り当て、規模から期間を想定しています。そして前後関係などを明確にしているはずです。
そこでできているタスクの計画に対し、実際の日付を割り当てます。
タスクのスケジュールは期間を持ったスケジュールとなります。基本的には進捗を測る基礎となります。
イベント・マイルストンの設定
次に期間を持たない、正確には1日しか実施しないタスクがあります。イベントやマイルストンと呼ばれるものです。
定期的に経営者に報告するなどのイベントもそうですし、ある日でないと作業ができないという日があればそれも該当します。
報告日はずらせるかもしれませんが、ずらせない予定も存在します。ITを止められる日が1年に一度しかない、といこともあり得ます。
そのような日は大きな制約となりますので、スケジュールにプロットされ、無事通過することをマネジメントすることが必要となります。
スケジュール上の進捗計測
立てられたスケジュール表は、進捗状況の確認の基礎となります。
スケジュール表どおり進んでいるかが、この仕事の成否を表します。当然進捗に問題があれば、テコ入れとなります。
カミナリ線とは
スケジュール表に対する進捗を表すのは、カミナリ線というものがよく使われます。カミナリ線は、計測時点で予定どおりであれば、真っすぐとなっており、進んでいれば未来方向に出っ張っているカミナリ、遅れていれば過去方向に凹んだカミナリとなります。
視覚的に遅れが見えてしまうことになります。
カミナリ線の本当の意味を知る
カミナリ線で凹んでいるのはわかるのですが、へこみはどのような基準で凹ませているでしょうか。この考え方は人の解釈で統一されないケースも出てきますので注意が必要です。
ある人は、1週間分くらいの遅れにしていたとしても、またある人は終わっていないので1か月くらい遅れにしていることもあります。
人によって違うのであれば、視覚的に進捗を表しても、意味を持たなくなってしまいます。
遅れ度合の認識により、対策の大きさも変わってきます。
カミナリ線の基準は計測基準による
カミナリ線をどのくらい凹ませるかというのは、タスクの線に対してどのくらいの出来高かによります。その割合により予定のスケジュールから凹ませることとなります。進んでいる場合も同様です。
では出来高をどのように測りますでしょうか。これこそ人によって解釈が異なってしまうのではないでしょうか。
そのようなことがないように予め基準は決めておきたいところです。
タスクは、様々な種類があり、単純に数が比例的に上がってくるものであれば、数でカウントすればよいです。
しかしそのような単純なタスクはむしろ少なく、考えて、作って、検証・確認して、という段取りを踏みます。
タスクの種類でも紹介した、認知するタスク、計画するタスク、定義するタスク、仕上げのタスクなど、特性を考えたうえで何か最終的な進捗評価となるのかを決めるべきです。
多くの場合、終わっても確認を2回ぐらいやらないと実際の終わりにならなかったりします。
そうであれば進捗計測において、一旦終わったと思ってもまだ50%くらいしか終わっていないものと認識して進捗報告できるようにしてみましょう。
スケジュール表でのありがちな問題
未知な仕事に対するスケジュール表の策定にあたっては、簡単なようでもやってみるとある程度の熟練が必要とわかります。
一見線が引かれていますが、見る人が見ればまったく成り立っていないこともあります。
ありがちな問題について見ていきたいと思います。
何らかの事情で無理なスケジュールとなっている
年度末までに完成し検収しないといけないといった要求はよくあることです。あるいは、何か別なイベントがあり、絶対に間に合わせろといった指令が出ることもあります。
そのように終わりが決められている場合、それに合わせて線を引きます。
うまくはまればいいですが、得てしてそのようなケースでは無理なスケジュールとなっています。どこかの工程が極端に短くなっていたりします。
ITは全体整合が取れていないと動きませんので、極端に短いスケジュールで実施するのは危険です。一時的な人の投入でできることは限られています。
既に間に合わないスケジュールとなっている
年度末検収のような決まられた最終納期があったら、今時点から間に合うようにスケジュールの線を引くしかありません。しかし、実態として既に間に合わなくなってしまっていることが残念ながらあります。
そのようなケース以外にも、工程を進めている途中で、既に間に合わないと発覚することもあります。
スケジュールを粗く決めておいて、進めていくうちに詳細化していくということは実務上よく実行されます。ただしこの方法は既に間に合わないことが発覚するリスクがあります。
詳細化していないと、ざっくり２カ月などのスケジュールが引かれていることになります。詳細化してみたら、詳細化したタスクに前後関係があり、実は２カ月をはみ出してしまうということはあり得ます。
既に遅れが大きすぎて比較にならない
カミナリ線で後れを認識するという話をしましたが、現在位置との比較においてコントロール可能な範囲でのみ、カミナリ線のマネジメントは有効と言えます。
つまり、カミナリ線がすべて大幅な遅れになってしまった時は、予定線との比較をしても意味がなくなってしまいます。
これは予定が実態と乖離していた場合が多いです。
実態と合っていないのであれば、いつまで経っても遅れのままとなり、解消する意欲も出てきません。よって遅れが遅れを呼ぶ負のサイクルに陥ってしまいます。
総論はOKだったが各論でNGなスケジュールとなっている
全体として例えば１年で終わるだろうというスケジュールはよくあります。そして過去の事例などから１年あればまず大丈夫だろうというなんとなくの合意もよくあります。
そのようなやり方も間違ってはいませんが、実は各論を見ると１年で収まらないケースも出てきます。
一部は専門知識のある人が実施しないといけないタスクがあったとして、その部分が他の仕事と折り合いがつかないといったケースです。
各論はすべて詳細化して検討できればいいですが、時間ばかりがかかるので、ある程度は見切り発車せざるを得ないこともあります。ただし、各論の中で、特に注視すべきタスクがあるはずです。
あるいはタスクが雑にまとまりすぎている可能性もあります。
注視すべきタスクについては、全体スケジュールに及ぼす影響があるかもしれませんので、注意しなければなりません。
今既に終わっていないといけなかったタスクがある
スケジュール表は具体的に日付が決まっていますから、やるべきことは漏れなく表現されていないといけません。しかし、きれいに決まっていればもちろんいいのですが、タスクに漏れが発覚するのは通例です。
課題として認識すれば、新たなタスクとして実行するよう追加しないといけません。
その追加されたタスクが他のタスクと融合して実行されていればいいですが、うまくいっていないことがよくあります。
追加されたがゆえに、誰がやるべきか決まっていません。すぐに決まればいいですが、最悪は決まらないまましばらく経ってしまいます。
いつのまにか気づいたらそのタスクは既に終わっていないといけないタイミングになってしまったなんてこともあります。
もちろんそのようなときは、落ち着いて影響を見極めないといけません。
工程が重なっているが根拠がない
無理にスケジュールを組んだ時などによく見受けられるのは、工程を重ねることです。
工程が重なってタスクを進めることは可能なことです。
工程は、普通は前工程が終わってから次工程ができるということが基本です。ではなぜ重ねることができるのでしょうか。
それは、工程を細分化してみると、部分的には次工程に進めることができるからです。
依存関係がないのであれば、ある部分は他の部分の完了を待つことなく、次の工程を進めることができます。
そのようなからくりはわかるのですが、やはり無理やり日程を収めるために、ただ重ねているというスケジュール表も存在します。
細分化したタスクにより次工程も重ねられるという根拠が実は不明確だったということです。
次工程認可が予定されていない
大きな工程間を進めるにあたり、中間で検収することもありますし、そうでなくても正式な認可の上次を進めるということを取り決めることは多いです。
前工程が不完全なまま次を進めることは、手戻りのリスクを多くは抱えていることになります。
認可により次を進めることは、当たり前のようですが、そうでもないこともあります。よって始めにきちんと取り決めたほうがよいです。
よくあるのは、認可のイベントが予定されていないということです。
5月末が工程の終わりで6月から次の工程が始まるとします。5月末ギリギリまで作業をしていて、5月末日にできましたと持ってきたとします。
本人は間に合ってよかったぐらいの気持ちだったかもしれませんが、正式認可がされていません。
ギリギリの仕事は得てして不具合があります。結果的に6月に食い込んでしまうことになります。
このようなことは日常的に起きていて、超一流と思われている大手ITベンダーでもやってしまっています。
スケジュール表において本当にすべきこと
現実的なスケジュールかの検証
スケジュール表は、あるタスクを確定した日付で実行するというものです。
日付が決まっていない段階では5日で終わる仕事であったとしても、日付を考慮したら、別にやることがあったので10日かかるというようなことも当然起こります。
そのような日付の制約を踏まえて、一旦出来上がったら検証してみないといけません。
また、終わりの日付が決まっているタスクについては特に注意が必要です。そこまでにやらないといけないというだけで、やれる根拠がないなんてことがないように気を付けないといけません。
実際にはスケジュール表が絵に描いた餅になっていることがよく起きています。
実行可能なスケジュールになっていて、実際に実施する人がいるということが基本です。
途中でスケジュールが破綻していたら
仮に絵に描いた餅で始めてしまった場合、タスクの進行が立ち上がらず、遅れすぎて話にならないという状況となります。
遅れ前提になっていると今やっていることがどの位置にあるのかが、わからなくなってしまいます。
途中で誤りが発覚したら、その時点からでもあるべきスケジュール表に書き換えて、きちんとマネジメントされるべきです。
期間制約の重さに対応するために
終了期日については、予定どおりタスクを進める9つのステップでも説明したとおり、見えない部分を埋める期間を持っておくことをお勧めします。
予備期間を持つことが可能であれば、それは持っておいたほうがいいです。期間の制約はとても大きく、取り戻すのがかなり困難だからです。
全体の計画として、前倒し気味にするとともに、予備期間を隠し持っておくというのも一つの手段です。
コメント