計画とは
計画とはよくPDCAというマネジメントサイクルと呼ばれる言葉がありますが、そのPの部分であります。
タスクの進め方でも計画は出てきていますので、そちらも参照ください。ただ、タスクとしての計画は計画を策定する行動のことを言っており、ここでの計画はタスクをマネジメントしていくための計画ですので、言葉は同じでも、紛らわしいですがやや領域は異なります。
計画は、実行する前にまずはどのように実行するかを決めることになります。マネジメントとしてはやはり最初にすべきなのは計画であり、実行すべきことも計画する必要がありますが、どのようにマネジメントしていくかも含めて計画することになります。
計画により解決できることとは
計画することは、これからやろうとしていることの見えていない部分を見えるようにしていく段階化の方法となります。
計画が出来上がると、皆計画に従って進めていくわけですから、実行の場づくりと言えます。場を作ったということは、協業の場を作ったことになりますし、行動の習慣化に対しての土台を作ることにもなります。
その効果は、IT現場での停滞行動に対する対策そのものの土台になるということです。よって計画ありきで、計画ファーストで考えるようにしていきたいものです。
計画の手順
計画と一言で言ってもこれから実施することは様々な領域があり、進め方に関する観点も各場面によって様々あります。
ここでは、計画全般として最も重要な観点をまずは説明します。
手順としては、このとおりです。
- 1やることを漏れなく挙げる
- 2タスクを見出す
- 3タスクの順序をつける
- 4マネジメントするタスクを挙げる（計測方法と評価方法、変更ルールなど）
- 5スケジュールを立てる
- 6重要な日付をプロットする（承認イベント、資材納品日、ここでしかできない作業日など）
- 7チームや担当などをタスクに割り当てる
- 8タスクの開始条件・完了条件を決める
- 9ここが遅れたら全体が遅れるタスクや日付を認識する（クリティカルパス）
やることを漏れなく挙げる
計画の基本は、やるべきことを漏れなく挙げることから始まります。
この時点では、大中小のカテゴリであれば大と中くらいとなります。直近については小カテゴリまで掘り下げたほうがいいです。
漏れないようにするには、現状と将来像を形式化します。そして、その間にあるものがやるべきことですので、洗い出します。やるべきことは段階化されて実行されるはずですので、時系列を意識してさらにやるべきことを洗い出します。
ITプロジェクトであれば、機能面、業務面、非機能面、マネジメント面といった多面的な観点で挙げていきます。
タスクを見出す
やるべきことは比較的大括りですが、それをタスクとして詳細化して認識していきます。
タスクの順序をつける
タスクは順序性のあるものについては、順序をつけます。
マネジメントするタスクを挙げる（計測方法と評価方法、変更ルールなど）
構築を実行していくタスクと並行してマネジメントしていくタスクも存在します。
契約などの行為も含まれると思っておいたほうがいいでしょう。マネジメントは準備しておかないと実行タスクのほうが動かない場面もありますから、立ち上げ時は特にいち早くタスクが必要であることを認識しておかないといけません。
スケジュールを立てる
タスクの順序をつけただけではまだ具体的な日付に対応していません。
タスクの長さと順序を考慮して、具体的な日付と対応していきます。そして開始日と終了日が明確となります。
日付を入れると矛盾点が出てくることもあるので、調整していきます。
重要な日付をプロットする（承認イベント、資材納品日、ここでしかできない作業日など）
タスクを進めていく上で、日付として重要なポイントが存在します。
承認イベントはその日までに途中工程を終わらせて、次の工程の認可を受けるなどの日付です。
その他、資材が納品される日などはそれ以降でしかできないタスクの起点日になるため、スケジュールに入れます。
チームや担当などをタスクに割り当てる
実行するチーム作りを行い、タスクに割り当てます。
チームや人のタスクの重なり具合や、他の仕事をしていることを考慮し、スケジュールにはまらなければ調整します。
タスクの開始条件・完了条件を決める
各タスクには開始の条件と終了の条件が存在するはずです。
前のタスクが完了していることが開始の条件になっているケースがあります。開始にあたっては開始条件が揃っていることを確認するところからスタートします。完了においても、あくまでも終わることが条件となり、後続のタスクがあれば、その開始条件にもなってきますので、影響を考慮して進めることになります。
ここが遅れたら全体が遅れるタスクや日付を認識する（クリティカルパス）
タスクの前後関係として集約する点が発生したら、その日がズレると全体的にスケジュールがズレてくる可能性があります。クリティカルパスとなります。
タスクが大カテゴリの段階だと、クリティカルパスは見えにくいです。大工程がずれ込んでも、実際は進められる部分があり、遅れた部分だけ回復すれば、後から合流できるということはよくあります。詳細化すれば本当のクリティカルパスは見えますので、実行段階においては少なくともクリティカルパスは見えるようにしたほうがよいでしょう。
このように決められた計画は、ただ工程のスケジュールが引かれたものではなく、人が割り当てられた立体的で連鎖的、そしてマネジメント可能なものとして出来上がります。
ありがちな問題
計画については、理想的にはそれに従って進められれば、予定どおり完了できるというものになっているはずです。
ところが、誰もが理想的な計画を立てられるわけではないです。ITの構築といったものであれば、なおさら見えていないものが多くあり、一旦立てた計画も一週間もすれば役に立たなくなってしまうこともあります。
ありがちな問題を見てみましょう。
タスクが洗い出されない
計画は完璧であれば、あとはただそれを実行するだけなので、実行する側の苦労はありません。ただ、ITの構築のようなタスクであれば、必ずと言っていいほど漏れはあります。
少なくとも、漏れと言うかは微妙だが大括りすぎて、完成の精度がわからない、というものはあります。
タスクが始められない
タスクを洗い出したつもりでも、そのタスクはいったい何から始めれば進められるのかがわからないものがあります。
あるいは、他のタスクと関係しているが、どっちから始めればいいのかわからないようなタスクもあります。明らかに2つの領域の仕事であるにも関わらず、どっちかが始めないと、始まらないというものです。
ITの基盤設計について業務量がわからないと決められないと思いきや、業務量は決まっていないので、基盤設計で上限を決めて欲しい、というようなことはありがちです。
タスクのボリュームが間違っている
一見きれいに計画が整ったかに見えることがありますが、ボリュームが間違っていたということは往々にしてあります。
関わる人が多く、スケジュール調整などを考えるだけでも期間が合っていないことがあります。
あるいは、一人の人で実施する予定にしていましたが、一つ当たりの調査時間が必要であり、全然足りなかったということもあります。
仕上げタスクが見込まれていない
タスクの種類として、実行や作成の後に仕上げや受け入れがあると言いました。
実行するタスクは考えていても、仕上げを考えていないことはよくあります。それにより何が起きるかといいますと、確認したら不完全さがみつかり、手前のタスクまで手戻りしてしまうということになります。
完全と思い込んで進めてしまうことが一番大きなロスです。
マネジメントや承認タスクがない
仕上げにも通じるものがありますが、マネジメント上のタスクや承認タスクは、実行そのものから見ると付帯的な行為に見えます。
完成すればいいじゃないか、という環境になってしまうと皆順応してしまいます。
そのままで済むのはほんの些細な仕事であって、ITでの一定規模の仕事となるとそうはいきません。
実行するメンバの稼働が考えられていない
タスクに人が割り当てられ、日数が割り当てられたとします。5日かかりそうなタスクを1週間で実行する計画にしておきました。
結果1週間どころか、2週間でも終わっていません。
などということはよくあります。
これは、実行するメンバの稼働が考えられていないからです。
1日を丸々そのタスクに費やせるわけではないのに、割り当ててしまったということになります。
そんなことは当たり前じゃないかと思われるかもしれませんが、ITスタッフは複数の仕事や突発的なタスクを持っている可能性があり、うまく考慮できないことも多々おきます。
外の世界が配慮されていない
あるタスクの範囲内においては計画として完璧だ、ということはあっても、進めていたら思わぬ外部要因で止まってしまったということはよくあります。
ITは外の世界と連動することがあります。外の人はこちらの都合とは無関係で動いています。計画時点ではこのくらいの期間内であれば、連動のテストもできると思いきや、外の相手はまったく理解していなかったということもあり得るわけです。
本当にすべきこと
ここで紹介したありがちな問題は少なくとも考慮したうえで、計画に漏れがないようにしなければなりません。
また、タスクの進め方の基本で紹介した、各ステップがタスクの計画として盛り込まれているかも確認しましょう。
特に重要なのは、2割は見えていないと想定して計画するというステップです。
すべてとは言いませんが、各タスクの計画は完全ではありません。完全ではないにも関わらず、出来上がった工程表だけを見て、進捗の良し悪しを語っても意味がありません。
しかし、多くの場面では完全ではないものを拠り所にしてマネジメントが行われています。
本当にすべき重要なことは、完全ではないことを前提として備える、ということも計画しておくということです。
計画の保険とは
計画の保険という耳慣れない言葉をいきなり使いましたが、これは計画がなんらかの理由でうまくいかない時の保険を用意しておくということです。
プランAが途中で頓挫したらプランBに切り替えると言った時の、プランBが保険計画となります。
ただこの場合の保険は、誰かにお願いしておけばいいというものではなく、自ら準備しておく必要があります。
保険計画は、元々の工程表には現れないですが、保険としての計画が実は用意されていて、保険への切り替え発動時に表に出てきます。
例えば、あるITシステムの切り替えがうまくいくことを前提に、別なITの導入を開始するという計画になっていたとします。
しかし、あるITシステムの切り替えがうまくいかなかったら、次のIT導入もNGになってしまい、2つのプロジェクトが連鎖破綻となってしまいます。
そこで、次のIT導入についてだけは救いたいとすれば、うまくいなかったら別な手段を講じる、例えばExcelシートでの運用だけ用意しておくなどの準備をすることになります。
ここでも重要なのは、あくまでも保険は予め準備しなければならないことで、その時になって考えては遅いです。
とはいうものの、うまくいかない想定をして両プランをある程度進めるわけですから、負担は増加します。
負担と可能性と効果を推し量って、やるかやらないかの判断をして進めるということになってきます。
計画時には、計画の保険は必要ないか、すべてうまくいくことが前提となっていないか、という問いかけを行うことを忘れないようにしていきましょう。
コストの計画
タスクの計画に対するコストとは
コストの計画とは、タスクと人とスケジュールが組み合わさることで確定する今後のコストの予定です。
タスクによっては人のコストだけでなく、外注や資材調達のようなものもあると思います。
期末までに用意する必要がある調達や期間が必要な調達は、スケジュールを加味したうえでタスクを計画するとともに、コストについても発生時期を計画しておくことで、資金繰りにも問題が出ないよう配慮します。
計画の保険に関するコスト
タスクがうまくいかなかった時の保険としての代替策についても、コストとして見込んでおかないといけません。
どっちに転んでも準備しておくところまでのコストは、予めのコスト計画に盛り込んでおく必要があります。いざその時が来て計画を切り替えた後のコストは、シナリオによって変わってきますので、コストは見込んでおかないといけませんが、どのように準備しておくかは発生確率と影響規模によります。
プランBの確率が高いのであれば、やはりコストとしても見込んでおかないとならないでしょう。
まとめ
計画は、マネジメント手法の中でも最も重要で、真っ先に実施すべきことです。
タスクをマネジメントするタスク（計測方法と評価方法、変更ルールなど）も含めて挙げ、人に割り振り、実行していきます。
計画が出来上がってしまえば、その通り実行すればいいだけですから、苦労はありませんが、実際完璧であるとは限りません。
実行実績が計画とぶれてきた時に、原因として実行パフォーマンスが悪いからと計画がそもそも違っていたからということがあるので、どちらもあり得るという前提で考えておきたいです。
コメント