仕事の基本ルール
業務をする上で、計画(スケジュール)は必須です。
ところが、この計画、
たてた途端に遅れ始める
のが困りものですね。
全く不思議でなりませんが、そうなるものは仕方がない。
本日は効率的な計画の建て方。
■計画の建て方のクセ
計画をたてるときに、どんな計画を書くかは、人によってパターンがありそうです。
もちろん、会社の社風やそのプロジェクトの重要度にもよって変わってくるでしょうけど、普段の自分自身の計画の建て方が、大勢で計画を立てている時も同じようにクセとして現れます。
A) 全く計画を建てない
B) 自分に関係する人の計画に「合わせます」しか言わない
C) 「いつまでに完了させます」しか言わない。途中の計画がない
D) 文章で「あれをやって、これをやって」は言えるけど、ガントチャートが書けない
E) やたら詳細な計画を立てる(1年先の日付まで書いてある)
F) やたらアバウトな計画を立てる(来週「くらい」に××をやって、今月「くらい」に○○をして……)
G) 「多分、××日には構成管理機能仕様ができあがります」と成果物が？？なものを計画に入れる
どれも業務を依頼したり、一緒にやったりする上で、すごく不安になる計画の立てかた。
■ベストな計画
じゃぁ、どんな計画の立て方がいいのかというと、世の中のスタンダードは、PNBOKでしょね。
もし詳しくない方は、ぜひ勉強してください。
WIKIPEDIAのページだけ紹介しておきます。
http://ja.wikipedia.org/wiki/PMBOK
できたら、これについて半日くらいは語れる(講習会の講師ができる)程度には勉強しておくと、仕事にすごく役立ちます。
単純に言えば、タスクにブレイクダウンをして、そのタスクの難易度と過去の経験からタスクの長さ(必要時間)を決め、タスクの前後関係からこれをガントチャートに配置することです。
ところが、なかなかそんなのできないんですよね。
だいたい、最後までやり切るのに、どんな問題が出るかなんて分からない。やってみないとわからないことも多いので、そのやり方で最後までやれるのか、あるいは何らかの方針を決める必要があるのかどうかがわからなければ、あらゆる可能性を書き出していく事になるけど、詳細に分析してみないと(実際にやってみないと)本当のリスクは抽出できるものでもありません。
■現実的な計画
管理人オススメのやり方は、「再帰分割計画法」。
私が勝手に名前をつけただけなので、ググっても出てきませんよ。
どうやるかというと、
１．いつまでに結果がを出すか(プロジェクトのゴールはいつか？)を決める
２．大体7〜8割できている成果物・状態は何か、を決める
３．それをゴールの日付とスタートの日付の中間点に置く
４．その中間点の成果物をゴールとした時に、大体7〜8割の成果物・状態を決め、また中間点に置く。
５．４を繰り返す。中間点が、来週になったら終わり。
ここでのポイントは、
・全体半分に分けて、前半だけを詳細化する
・さらにその前半の半分をより詳細化する
ということです。
「成果物・状態」と言うのは「こんなイメージのものや状態」があれば、ゴールに辿り着けるかな？と思えれるものすべて。
多分、これが複数個できるでしょう。
それが直近になるほど詳細化されます。
もし、あなたがソフトウエアアルゴリズムの勉強をしたことがあれば気がつくかもしれませんが、これは、多数のデータをソートする再帰アルゴリズムのひとつをプロジェクト管理の方法に展開したもので、着眼するのは、「半分にする」という作業だけです。
ただ、成果物が半分できた状態というのは、定義しにくいのと、「業務が半分出来た」と思うと大体残り時間は今までの２倍位かかるという経験則から、「7〜8割完了」を半分においてます。
こうやって計画を作ると、直近の計画はやたら詳細で、未来になればなるほど大雑把な計画が出来上がります。
明日やることははっきりしているけれど、来月やることは、1ヶ月スパンで割合いい加減に書いてある計画書です。
これが意外とうまくいきます。
今週もし遅れが出たとしても、来週は2週間先の計画なので、若干の補正を入れるのはそれほど難しくありません。そこに収まらなければ、2ヶ月先の計画を補正すればいいでしょう。これだけ大きなスパンだと、多少の誤差には揺らぎません。
もしやってみて、疑問があったら是非メール下さい。
私も考えてみたいと思います。
