仕事における時間的バッファーの重要性
では、CS Harmony Radioの番外編を始めていきたいと思います。
よろしくお願いします。
今日はですね、前回マルチタスクの話をしたんですけど、
ちょっとそれに関連して、仕事に余白みたいなものって大事ですよねって話をしたいかなと。
なるほど。
今回、仕事の余白って言ってるのは、時間のバッファーのことを言ってます。
特に時間的なバッファーですね。
時間的バッファーってどういうものかっていうと、
例えば、なんかある仕事がありますって言ったときに、
見積もり的に言うと、急いでやれば3日でできそうだと言ってる仕事があったときに、
お客さんの会社、上司とかから言われた仕事を依頼してきた人に対して、
5日くらいですかねっていうやつ。
2日間ってバッファー。
急いでやれば3日くらいなんだけど、何か起こったら、もしかするともうちょっと超えちゃうかもしれないって思うと、
ちょっとかさ増ししとこうかって、さばい思うかみたいなやつがバッファーですね。
2日分が時間的なバッファー。
安全余裕って言ったりもしますけど、
仕事の納期を守るために、大体ちゃんと守れる日を言うっていう感じのものが時間のバッファーですというところで、
これって多分当たり前にみんなやってるじゃないですか。
当たり前にやってると思います。
快速で急いだ納期なんて客に答えたり絶対しないはずで、
お客さんじゃなくてもいいですけど、他の人に約束するときに、
まあまあ守れる日を言うじゃないですか。
まあまあ守れるってことは最速じゃないわけですよ。
最速もうちょっと早いはずだって。
ある程度確実に仕事をこなそうっていう意識から、このバッファーってものを作業見積もりの中に入れ込んでいくっていうのが一般的ですし、
普通なんで大事なんですけど。
仕事の納期守るためには絶対するので必要なんですけど。
複数人でのプロジェクトにおけるバッファーの調整
ことこれが、例えばプロジェクトみたいに複数の人を仕事が渡り歩くみたいなときに、結構悪さをする場合があります。
一人で全部仕上げるんじゃなくて、何人かが携わりながら一つのものを仕事として仕上げていくようなイメージ。
イメージ的にいいかどうかわからないですけど、家作るみたいなのがこんな感じで建築士が設計して、それに基づいて大工さんが家を建てます。
内装する人とか水回り配管する人とか電気系をやる人とか分かれるじゃないですか。
分かれますね。
そういう人たちが連携して家ってものを最終的に作ると。
家を作るプロジェクトっていう風になっていて、それって基本的には担当者が違うんで、ある仕事が完了したら次の人に引き渡していくっていう作業になるという形になるんで。
ある意味、自分の持ってる仕事がちゃんと完遂します。自分の範囲はいついつまでにっていうのをちゃんと約束しながら進んでいくことになると思うんですけど。
そうすると実は安全余裕が多すぎる場合が結構出たりします。家の場合だとだいたい三つ盛りよりいったりするんで、そこまで安全余裕。バカみたいに多くないんですけど。
特に作ってみなきゃわからないタイプのやつ、具体的に言うとソフトウェア開発みたいなやつだと、本当にやってみないとわからないので、すごい差が出ます。
あと人によっても差が出るのもあるんで、三つ盛って積み上げて、コースとかを積み上げてみたら、全然お客さんの求めているような期間に入りませんとか。
それって実際に本当にそこまでかかるかって言うと、そうでもないのに、安全余裕が大きすぎるんで。各タスクって進む場合もあるはずなんですよ。
遅れる場合ももちろんあって、三つ盛った日数よりも。先ほどで言うと最速なら3日なんだけど、いつかって約束しても実は5日から遅れることもあって、いやいやちょっとすごく大変で実は6日かかりますってこともあるし。
実際3日って言ってる3日でできることもあって、最速で他の仕事があんまりなくて、前回の話マルチタスクみたいなのもないので、集中してやると3日ぐらいで終わって、あと2日間は出来上がったけど余ってますみたいなこともあるはず。
なので基本的に複数のタスクが絡んでると、遅れと進みを吸収し合うんですよ。
ちゃんと繋がってると。なんですけど、担当者が分かれてると、多くの場合早く終わったらそれを報告しないです。早く終わったんで渡しますってことをあんまりしない、する場合もあるんですけど。
なんでかっていうと、例えば3日でできたやつを、次回の3日でできるでしょって言われちゃう可能性があるので、基本的には宣言した納期を使い切っちゃうっていうのがあって、これパーキンソンの法則って平均値的な法則で言われていて、バファーは見込んでも必ず使っちゃう。
そうかもしれないですね。
基本的には遅れだけ伝わっちゃうんですよ。さっきの話だと、進みと遅れがだいたい1対1とは限らないけど、食い合うのでそんなに変なこと起こらない。そのまま進めば。
実際は5日ってやつを5日目に出すことになるんで、早くなった分が伝わらないじゃないですか。3日で終わったから4日目から次の人作業できるのに、5日まで待っちゃうから6日目からしか作業できないんで。
一方で5日って言ったけど6日かかっちゃう場合があるんで、遅れだけは伝わっちゃいます。この場合6日、7日から始めたら終わりなんですね。そうすると、基本遅れだけザーって蓄積されるっていうのがプロジェクトの特徴です。
なるほど。
これと関連するかどうかは分からないんですけど、具体的に言うと。ITプロジェクトの70%は失敗してるっていうデータがあったりもします。
遅延も含まれてるんですけど、失敗なんでよく分かんないです。もともとのスコープを減らして納期を間に合わせたのかもしれないですけど、見積もり通りちゃんと終わらなかったやつが70%って見てもらえばいいかなと。
計画通りいきませんでしたってやつですね。
基本的にプロジェクト型みたいになってくるほど、それぞれバッファー見込んでたとしても食いつぶしちゃうし、遅れちゃうみたいなのが起こってきます。というところかなと。プロジェクトってこんな感じかなというふうに思うんですけど。
そうですね。ちょっと考え方によるとは思いますけど、同じような条件でまた同じような仕事が来るっていうのが想定できてたら、無理に縮めたりはしないだろうなと思いますけど。
競争激しくて、より良い条件で応じないと死んでしまうとかなったら、縮めたりすることもあるのかなと思ったりはしたんで、その辺りは仕事とか環境の条件にもよるかなっていう気は感じたっていうところがありますね。
特にソフトウェア開発とかもそうだと思うんですけど、多分これって完成する品質要求が高いというか、アジャイルっぽくしっかり完全に動くわけじゃないけど、それを見てもらって評価するみたいな考え方で言うとそんなこと気にしなかったりするだろうなというところで。
そうですね。その通りですね。
完全に動くものを作らなきゃいけない、かつある程度長期的に繰り返されることが見込まれてるみたいな状況だと、そういう考えになるのもわかるなと思って聞いてました。
ありがとうございます。
共用することでバッファーを効果的に活用する方法
じゃあこのバファーをどういうふうに扱えばいいかみたいな話をちょっと後半だけしていきたいなと思っていて。
結論的なんですけど、それぞれ担当者がバファーを持ってるじゃないですか。さっき私の例で言うと、かつてののが5日って言ってる2日ってやつ。それぞれコマ切れになってるからいかんのであって、集めたらいいんですよ。
集めるってどういうことかというと、みんなの地産にしたらよくて、誰でもそれを使える状態、日本語にすると共用するっていう感じですね。共有じゃなくて共用です。みんなで活用できる状態にすればいいです。
プロジェクトだと各タスクに含まれているバファーを全部集めて、一箇所に集めます。それはどこかっていうとプロジェクトのケツ、脳機があるんで、脳機を守るためにそれの守るためのバファーをそこに配置して、各タスクはなるべくバファーがない状態にして、後ろに全体のほぼバファーがあるから、それをみんなで共用しましょうよという形にするんですけど、
って言われてるんですけど、めっちゃ難しいです。
難しいでしょうね。だって最初に食い潰したらどうするんだみたいな話も。
そうそう。みんなが共用してるんだけど、あいつが食いすぎるとか、そういうことがあったりするっていうのと、あとこれ日本特有なのかもしれないですけど、約束した日って守ろうとするんですよ。
さっきの例で言うと3日って最速3日だなと思ったら、しかもそれ3日って言って、2日分のバファーをプロジェクトのほうに共用しますというふうにある意味召し上げられるんで、召し上げられたときに自分に残るのは3日っていう数字だけ残るじゃないですか。
そうすると3日をなんとか守ろうとするんですよ。でも最速でやったらなんで、あんまり確率論的に3日で終われることってないはずなんですけど、それを守ろうとしちゃうっていうのがあって、みんな辛くなるっていうのが起こって。
逆に追い詰められちゃうとか、こういうのもある。
そうなんですよ。
ちょっと気になったんですけど、これって共用するっていうことは理解関係的なとこどうなんですか。要はいろんな人たちが入って立場とか違うと、このバッファー自体を共用するっていうことすら難しかったりするかなと思うんですけど。
なので、たぶんプロジェクトを同じ3日にいて、基本プロジェクト完遂というところを同じ目標に置かなきゃいけない。もし、例えばさっきの家建てる例だと、そういう目でプロジェクトの例としては不適切かもしれないですけど、あれってたぶん役割分担ごとに契約が分かれてるかもしれない。
そうですね。法人格としても違うから、共用するってあんまりピンとこなかったです。
ここは共用できないと思います。
イメージでいうと、社内の中の複数部門またがって仕事するようなものがあったときに、その社内の中の全体のバッファーを共用するとか、そういうことですよね。
そういうことですね。
なるほど。
森さんが言ってもらった、アジャイル開発もある意味そういう関係だと思います。現状に溜まってるタスクがこれぐらいあって、徐々に作っていこうねっていう話っていうのと、対策でやろうとなってる。
多くの場合はチームをちっちゃめに作る。顔が分かっているチームをチームビルドの下上で作る形になるんで、共用するごとのハードルが下がってる状態。
要はあいつがめっちゃ食うみたいなことがない状態してるので、あれはそういう意味合いでうまく回るのかなとは思いますね。
ちょっと戻しますけど、難しいですっていうのと。
ただ、共用したほうが良いというのがあるので、イメージでいうと、見積もりの話をした回があったと思うんですけど、そのときに規模見積もりと時間見積もりの話をしたと思うんですけど、規模見積もりは積み上げたほうがいいです。
どれぐらいの量っていう話なので、積み上げたほうがいいんですけど、時間見積もりをなるべく共用できる範囲である程度マージした状態でやったほうがいいかもしれないなと。
ちょっと答えがないかもしれない。
難しさだけ今日はお話してきた。
なるほど。
論理的にはそういう手段があるにしても、できるかどうかは全然別問題と同じですよね。
別問題ですよ。
これのコンサルをやってたこともあるんですけど、まあ難しいですね。
まず啓蒙が必要ですと。
まあそうでしょうね。
みんな基本的に手の内素直に明かさないと成立しないですけど。
そうなんですよ。
ちょっと思ったのは、3日でやりますって言ったところにまた個別バッファーを入れるんじゃないかな。
そうそう、それもある。隠れバッファーみたいなのがめっちゃ入ったりする。
本当だったら最短だったら2日でできるけど、いや最短3日ですって言いがちみたいな。
言いがち言いがち。
そうなると、これ2日でできるよねとかって言えるような人がいないと難しいなって話もあったりしますかね。
その通りです。
そこの精密性はいいんですよ。最短2日だよねって言ってもしょうがないんで。
余白とバッファーのマネジメント
集まってきた全体のバッファーをどういうふうに配分していっていくかっていう話で基本的には。
残りどれくらいだからもう危ねえと。
その辺のバッファーのマネジメントみたいなところが重要なのかなっていうふうに思いますけど、また難しいですよ。
実際私がやったときも難しくて、たぶん私がいなくなった次のプロジェクトからは使ってないと思う。同じやり方は。
それはソリューションとしてうまく機能してるかっていう話になっちゃいますね。
使えてるところはあるんですよ、世の中。
それが圧倒的に差になってるんだとしたら強力な武器ですよね。逆に言うと。
どうなんでしょうね、この話は。むちゃくちゃ難しいなと思っちゃいましたけど。
あと、強要するメリットってどの辺にあるんですかね。っていうのがちょっといまいち見失いつつあるんですけど。
なんか縮めることができるんですか。それとも遅れなくなるんですか。
縮めることもできるんですけど、パーキンソンの補足がまず働きづらくなる。
早くなったやつは早く伝わる状況になるので、遅れなくなりますっていうのがあって、
遅れなくなるということは全体が短くできる可能性があるんで、それかどう設計するかによりますけど。
あとは全体強要しているバッファーだけ管理できればいいので、管理がしやすい。
各タスクにどれぐらい有力があるかって一個一個見に行かなくて済むので。
その意味だと、理解した功用は基本的に遅れづらくなるっていうのが大きいですよね。
頑張れば縮めることもできるけど、基本的に遅れづらくなるっていうことだと思います。
あと管理が楽になるは、さっき言ったようにある程度ちゃんとその辺りの手の内見せて、
強要するっていうところが合意形成できればいけるっていうことですよね。
そういう感じです。
そこが大変だから思ったりはしました。
全然別観点ですっこみというか質問してもいいですか。
どうぞ。
僕の中のイメージのアジャイル開発って、機関的なところの制約をある種決めて、
品質とか仕上げみたいなところを犠牲にしてるんだと思ってるんですよ。
はいはい。
捉え方が正しいかどうかはあれなんですけど、例えば5日で作るっていうときに、
5日で予定してた進捗100%のところが時間がかかって80%のものしかできませんでしたとしても、
80%の品質で出してしまうみたいなことをしてるのかなと。
はいはい。そうだと思います。
そうなったときにこのバッファーみたいな考え方とは一緒じゃないというか、
結構別の考え方で捉えてるのかなっていう気もしたんですけど。
ちょっと半分イエスで半分ノーなんですけど。
半分イエスなところは、そもそも時間は固定ですよね。
タイムボックス決まってるんで、例えばいつかって言ったらいつかっていうタイムボックスの中でやりますと。
何を変動要素としてるかっていうと仕様なんですよね。
仕事量でもいいんですけど、積まれてるタスクを変動化させてるんですよ。
5日のうちに5つのタスクをやろうと思っていた。
実は5つのうちの4つしかできなかった。
ってなったのがたぶん88割の品質ですっていう話だと思うんですけど。
逆もあって、たぶん5日あったときに、5じゃなくて6とか7できなかった。
って話になっても、6とか7やるんですよ、アジャイルの場合って。
基本的に先食いできるんで、積まれてる作業なんで。
そういう意味合いで半分ノーですっていう意味合い。
ちょっと見方は違います。
時間のバッファーの考え方じゃなくて、
仕様とか作業量っていうのの積み上げで見てるというのはありますけど、
似た感じかなとは思います。
運用的にはありますよね。
ありえますね。
バッファーの話の時間っていうのは、
基本的にやる作業を必ず決めちゃってるから、
変動要素が時間になってるって話で。
逆の話になってるんだと思う。
アジャイルはその変動要素の時間を決めてるんですけど、
アジャイルは時間を決める。
時間を決める。
時間を決める。
時間を決める。
時間を決める。
仕様と作業量の関係性
アジャイルはその変動要素の時間を決めてるから、
作業量が変動するってことですよね。
そういうことです。
ってなると、時間のバッファーのコントロールと
作業量のバッファーのコントロールは、
実は同じ問題を払っているような気もする。
そうですね。
同じだと思いますけど。
なるほど。
余白って話で言うと非常に大事だとは思うんですけど、
余白になったときにちゃんと詰めれるかとかっていうところを
どう作るかが大きい課題だなって思いました。
余白を認めるということは結構課題ですよね。
そうですね。
いつかにできるって言ったときには、
いつかカツカツなんですよっていうのがあるじゃないですか。
大体会話する。
あれは割れるかみたいな。
そうですよね。
遅れるのはよろしくないですけど、
巻いたときに、巻いた分で早く終わりました。
ついでにこれもやっときますねみたいなことが、
普通に言えるかどうかっていうところが難しいかったりしますよね。
そうですね。
関係性によると思いますけどね。
関係性にはよると思います。
やっぱりいい関係性を作るっていうのは、
逆に言うとそういうところでも大事なんだろうなって思いました。
やっぱりチームワークが悪いと遅れてくっていうのは、
自己防衛による作業量の固定、
もしくは時間の固定に対する抗いがないかどうかが
大きいのかなって話してて思いましたけどね。
特にプロジェクトとかで納期だけ決まってて、
作るスペックも決まってるパターンがあるじゃないですか。
変動要素その場合基本あんまないんですけど、
人を増やしたりとかっていうのも限度があるんで、
そのとき何が起こるかっていうと、
隣の担当者から時間を奪うっていう。
自分の作業がしっかり終わらせて、他は知らないっていう。
ギスギスした感じになっていく感じ。
そうですよね。
なんか自分だけのところやればいいとかっていう
個別最適しちゃうと、
全体の話見なくなるとやっぱり今言ったような
関係性悪いとかよろしくないとチームでやらないから。
チームとして成果物出さなきゃいけないときに
足りてないピースのことを知りませんっていう話は
具合が悪いですよね。
よくわかりました。
そんな余白というかバッファーの話を出してもらいました。
またちょっと小難しいシリーズに戻ってきた感じがありますが。
CHIPSシリーズと小難しいシリーズどっちのほうが視聴率がいいかで
比べてみたら小難しいシリーズのほうが良かったので
ちょっと戻してみました。
新たな気づきですね。
タギさん小難しい話のほうが好きじゃないですか。
気にせずそっちを話せるようになったっていう。
大腕を振って小難しい話をしていこうと思いますけど。
わかりました。
というところで以上にしたいと思います。
ありがとうございます。
ありがとうございました。
