リスケの是非。

まいど。
ってことで、昨日の続きをなんとなく書いてみようかな。って。

プロジェクト、プロジェクト、プロジェクト…。

ってことで、取りあえず基本的な図はこんな感じですよね。

---

でも、まあこんなのは皆さんご存知の話でして。
そして実際の仕事場ってのは、だいたい複数のプロジェクトが動いている訳です。
ざっくりですが、こんな感じ。

---

そのときtodoはどうなっているか。

まあ、こんな感じになってますね。
一日に色んなプロジェクトのtodoを作業者はこなすわけですね。
まあ、これも当たり前。

---

で、ここでピンクのスケジュールに
「一日の遅れ」
がでたとします。すると、こんな風になるわけです。

---

このtodoを一日ずらすぞ、と。
でもそののまま動かしてもうまくはいきません。

---

じゃあ、どうするか。
ここで実はやり方は色々あると思うのですが、普通にこのスケジュールになんとか入れ込もうとすると、

他の「特に遅れのないプロジェクト」を動かし調整してtodoを入れ込む

ってやり方がまあ、考えつく一つなのかなーと。
ってことでなんとか調整していれましたってのが以下の図です。（ざっくり図です）

---

リスケ、リスケ、リスケ…。

プロジェクトは基本的に予定外のこともおこるし、そもそも予定通りにいかないのが当たり前、と思います。
だからこそスケジュールをたてることで「全体の流れを仮組して、無理や無駄をなくす」のが大事だと思います。

また、そのあともスケジュールを「遅れるのが当たり前」と思わず、参加者が尊重して作業を進めるのも大事だと思います。

そのときどうするか。どうやるのが一番いいか。
正論はあるでしょうが、これって「状況」によって異なりますね。
うちの場合は、そんなに外部にあれこれお願いできるパイプが豊富ではないので。
自分のところでなんとかするケースが割合多いです。
そうなると

・リスケ（スケジュールの組み直し）
・残業

がうちでは主な選択肢になりがちです。

全体の管理はコスト高

実際問題リスケできるだけでも「まだありがたい」という場合も多いのですが。
とはいえリスケって「関係者全部に承認、連絡」をとってスケジュールを動かす事になります。
まあ実際は他のスケジュールに多少の余裕があって「全部に連絡確認」はしなくても何とかなる事も多いのですが。

とはいえ、それでもリスケしている間はほかの作業が進まないし。
そればっかやってると締めや入金にも影響がでてきます。
そう考えるとリスケってあんまり良いものでもないし。
「リスケし続ける」のがディレクターの仕事ではないなぁって思ったりしてます。

やっぱそうなったら他の作業力を頼って、できるだけリスケの幅を小さくするのが大事なのかなーと。
そうなったときに

「他の方に仕事をすぐに依頼できる準備ができているか」って部分、つまり
「仕事の仕様や流れが明文化されているかどうか」

って問題にぶちあたるなぁ、って、この頃思っています。


このあたり、わたしもまだまだなので（ホントにそう思う）今後も粘り強くやっていこうかと思います。
うちの場合はFileMakerと共に。

---