仕事が早い遅いと期日とスケジュールと結果について
仕事が早い人がいる。
仕事が遅い人がいる。
早くても品質に問題がある場合もあるし、
とにかく、スピード最優先の場合もある。
それらの一般的なことは、多くの書籍に書かれている。
仕事の基本的なやり方、技術、時間管理などは、
ここでは書かない。
そういう努力と学習をしている前提で、
でもなかなかうまくかない、という若手の人に、
あと一工夫するにはどうしたらいいのか？
ということを、
私なりの経験から思うことを書きたい。
1.仕事が遅いか早いか。
私は、仕事は早くはない。やや遅い方だ。
でも仕事は単純なスピードだけではない。
やり方しだいで、早くも遅くも見える。
仕事が遅くても、期日を守ることができる。
仕事が遅くても、周りから見ると、
どんどん早く仕事をこなしているように、
見えるように仕事は進められる。
それが分かれば、スケジュールの考え方が、
変わってくると思う。
(ごく当たり前のことが、分かるだけなのだけど。
ごく当たり前のことを
本当の意味で理解することが難しい)
ここで少し、別の話を。
小学生の頃、体育でサッカーの授業があったとき、
体育の先生が言っていた、
足が速くないのなら、足を早く見せればいい。
とのこと。
先生の言った本当の意味は分からない。
サッカーにも精通してもいないけど。
でも、こんな意味だと勝手に解釈してる。
ボールが出てから、足が早い子と同じ位置から
ボールに向かって走って競争しても、足の速い子には
追いつけない。
ゲームの流れや全体を見て、
ボールが出そうなところ(パス、または偶発的にこぼれたりで)に、先回りしてポジションをとることで、
足は早くなくても、いつもボールが出てくるところに先にいることができ、足が早いように見せることができる。
というような意味ではないかと。
(小学生の頃の体育の授業の話なので、
一般的なサッカーとして正しくはないのかもだけど。)
仕事についても同じようなことが言える。
仕事が早くないのであれば、
仕事を早く見えるように仕事をすればいい。
別に難しいことではない。
全体を見て、だいたいどうなりそうかを
考えながら仕事に取り組み、
常に一歩二歩、先手先手で、
先回りをして仕事をすればいい、ということになる。
2.先回るをするとは
先回りするといっても、どうすればいいかを考える。
こういう検討あるかもね、と思って資料準備したり仮検討を進めておいたけど、実際には検討不要になることもある。それに使ってた時間は通常の仕事を削ってになるし、仕事は逆に遅くなるかもしれない。
密かに検討下調べを進めておいて、
ドンピシャでそれが課題にあがり、
普通に1週間以上かかりそうな資料が数日ででてくれば、
(しかもよく検討された資料であれば)
すばらしく仕事早いね、となるが、
ヤマをはるみたいやり方は、無駄も多い。
(リスク回避としてやることはあるけど。)
だから、無駄にはならない先回りがよい。
ウォーターフォールで進める
開発プロジェクトを例にする。
要件定義のとき、顧客の要求内容を落とし込んでいく。
どうしても、そのフェーズの課題や検討事項だけに全ての時間を使いがちだ。
そして時間はあればあるだけ、費やされる。
先回りして検討する時、
次の工程で実施することをやることが、
一番有用で無駄が少ないと思う。
例えば、要件定義が2ヶ月で、
次の工程が基本設計3ヶ月だとすれば、
要件定義が1ヶ月程度進み、
ある程度のヒアリングや要件を入手できたところで、
先回りして基本設計のドラフトも、検討してみる。
目次レベルをまず考えて、
(担当なら自分の担当する部分、PMなら全体の目次)
それぞれで、どんな設計にしていこうかなど。
できれば、ドラフトで設計を書いてみると良い。
ここは、まだ誰も設計書を書いてないのに、
今の要件定義だけでも手一杯なのに、
そんな時間ないよ、と思うかもしれない。
きちんとした設計検討は、この時点ではいらない。
ドラフト的に全体を見て、
メモ書きや箇条書きでもいいので書き出す。
時間を短縮するために、他の図や設計書から、
パーツとしてはコピーして作ってもいい。
大枠として前検討できればいい。
これには2つの利点がある。
・基本設計のフェーズに入ったときに、ドラフトがあるので、他の人より早くアウトプットが進むし、常に先手先手、先を見ながら仕事を進められる。
・基本設計のことを検討することで、直近実施している要件定義の課題や検討不足に気づくことがあり、よりよい要件定義にできる。
また設計フェーズの場合でも同様だ。
設計を進めながら、開発計画(コーディングやサーバ構築)、テスト計画も進めるが、
そのときに、どう開発(詳細設計、クラス設計、DB設計など)するか、どのようなテストをするかをより具体的に先に考えながら、
設計を進めると、設計にとってもメリットがあり、
先取りで次の工程も進められて次の工程も楽になるし、
いろいろな相乗効果がある。
課題山積、人も時間が足りず、スケジュールはぎりぎり、
とても余裕がないプロジェクトは多い。
だからどうしても各工程では、直近の工程ばかりに頭がいっぱいで、そもそもマスタスケジュールにある期間では終わらないくらいのに、押し込まれていることも多い。
これは前回書いた、もともとの提案内容、契約時の見積もりの甘さからの場合も多い。
だからできない、と言うのは、それは正しい。
悲しいけれど、だからできないが、現場では通らない。
つまり、
設計の前に先にもっと設計のことを
先取り検討するしかない。
先回りすることは、先に初めることができ
工程にかける期間を長くできるメリットもある。
これついても次に書きます。
3.先にはじめれば、遅くても早くなる。
5日間程度かかるタスクをWBSで、
8/5(月)着手で8/9(金)まで
スケジュールしたとする。
このタスクを8/1(木)に着手して
6営業日(想定より1日長い)で終わると
8/8(木)となる。
期日8/9(金)より1日早くできたことになる。
このタスクを8/7(水)に着手して、
4営業日(想定より1日短い)で終わると
8/13(月)となる。
期日8/9(金)より1日遅れになってしまう。
仕事が早くなくても、
早めに始めれば、早く終わる。
着手が遅ければ、
タスクをより短い日数で終わらせても、
遅れてしまう。
当たり前のことだけど。
しかもこれは連鎖的に発生する。
遅れる人は全て仕事を早くこなしているのに、
全て遅れる結果にもなる。
以下例(日付は営業日と考えてください。)
・タスクA→タスクB→タスクCの仕事とする。
[Aさんの結果]
タスクA
予定:開始1日-終了5日(5日間)
結果:開始3日ー終了7日(5日間) 期日2日遅れ
タスクB
予定:開始6日-終了12日(7日間)
結果:開始8日-終了13日(6日間) 期日1日遅れ。
タスクC
予定:開始13日-終了18日(6日間)
結果:開始14日-終了19日(6日間) 期日1日遅れ。
結果は、タスクABCの3つともに
期日の遅れが出ている。
タスクAの着手が遅かったことが、
それが、そのまま、タスクB 、タスクCに
スライドされてしまい、すべてのタスクが、
遅れになっている。
実際に仕事にかけた日数は、
予定通りだし、仕事は遅くはない。
タスクBについては、
予定より短い日数で終わらせているのに、
この結果から、何も知らない人から見れば、
仕事がいつも遅れぎみ、にも見える。
早めに着手することで、
仕事が遅いことをカバーできる。
同じ例だと以下。
[Bさんの結果]
タスクA
予定:開始1日-終了5日(5日間)
結果:開始-2日ー終了3日(5日間) 期日2日早い
タスクB
予定:開始6日-終了12日(7日間)
結果:開始4日-終了11日(8日間) 期日1日早い
タスクC
予定:開始13日-終了18日(6日間)
結果:開始12日-終了18日(7日間) 期日通り
タスクAを予定より2日早く着手。
これにより、タスクA、タスクBは期日より早く、
タスクCは、期日通りにできた。
作業にかけた日数は、タスクB、タスクCでは、
予定より1日長い結果なのに、
期日からみると良い結果になる。
Aさんのが仕事が早いのに、遅れてて、
Bさんのが仕事に時間がかかるのに、
期日通りか早くできている。
どうせ同じ仕事をするのだ。
どちらがいいかは明白だ。
同じ日数頑張って作業するのに、
毎回遅れ遅れで、すみませんと言うのは、
良い気分ではない。
逆に、早め早めに進めて、終わりました
と言えれば、良い評価となる。
同じように苦労して、頑張って、
作業したのに、期日遅れになるのはあんまり、
イメージ良くない。
どちらにしたって、仕事はしないといけないのだ。
作業にかける期間も変わらないし、
内容も変わらない。楽をしたわけでもない。
ならば、早め早めに進めた方がいいし、
それで、評価ちがうのならば、そうした方がいい。
4.PMとしての考え方。
PMとしてなら、チームメンバーよりも、
さらに先を見越していく必要がある。
チームの状況を見極めながら、
先手先手で、メンバーに検討を進めていく
ようにリードしていく必要がある。
プロジェクトによっては、工程により内容と期間のバランスがうまくできていず、余裕がありすぎる工程と、すごく期間に余裕のない工程とかが混ざってるときがある。
人は、楽な時間は、楽をしてしまうものだ。
それで、次の工程がめちゃタイトってこともある。
PMは、それを見越して、楽な時に、次の工程を前倒したり、事前検討をしたりで、あまりメンバーに楽をさせすぎてはいけない。
これはメンバーを楽をさせないで、仕事をつめこむのが、
リーダーの仕事だ、と勘違いしてはいけないと思う。
チーム全体のためでもあるのだ。
どうしても人は直近に与えられたタスクしかやらないし、
タスクが早く終われば、それ以上にはなかなかやれない。
でもそのツケが、プロジェクト全体で見ると、
あとでまわってきて、あの工程で楽をしすぎた、
余裕でやりぎたって、あとで後悔することも多い。
だいたい工程が先に進むにつれてタイトになることも多いし。
だからPMは全体を見越して言わないといけない。
みんなが大変にならないためにだけ言う。
もし最後まで、楽をできるプロジェクトであったなら、
そのままでいいし、急がせる必要もない。
(そんな楽なプロジェクトもないとはいえない。
最近はあんまりないと思うけど)
でも、この後の工程で足りたいとか、困難な課題があるとか、わかっていて、今が楽なだけなら、早めにそれに取り組んだ方がトータルとして、一人一人の負荷を分散できて、仕事として全体と見ると、楽をできる。
追われて追い込まれてやば仕事が一番きついから。
そうなる前に、チームメンバーを即して、
課題の目をつぶしたり、前倒して進めることで、
楽な期間であれば、ある程度余裕のある気持ちで、
それを進められる。
みんな仕事は、余裕を持って、
追い詰められないでしたい。
継続的に仕事を楽しくするには、
そのために過度に楽をしないで、
適度に適切に進めていくことで、
いい仕事が、そこまで大変にならずに
できると思う。
つまりこれば、チームメンバーにとっても、
メリットが大きい。
(楽をしたいのに、作業をつめこまれていやと
思うかもしれないけど)
だからPMは、常に先を見て、予測して、先手先手で、
手を打ち、チーム内でも先回りしていくように導いていく必要があると思う。
またWBSのタスクの作業期間を決める時は、
バッファを設けること。
例えば、タスクA-B-Cの後に
3日間バッファを設けて、そらから、
タスクDとするWBSにしておけば、
タスクA-B-Cで発生した遅延を吸収できる。
それは計画時、見積もり時にしておく必要がある。
前回書いた
スケジュールや期日の見積もりの甘さが、
問題を起こす点
今回書いた、そのスケジュールを
進行していく中でも、先手先手で、
先回りして作業を進めることで、
仕事は早くなくても、早く見えるように
仕事ができる、という点。
仕事の早い遅いと、スケジュール、
進め方についての工夫として、
それを意識して、進めることで、
余裕もって仕事ができるし、
日々の仕事もすこしは楽になり、
かつ、評価も得られるではないか、
と思う。