長距離仕事、短距離仕事
一番重要なのは、キャッシュフローが安定しないところではないだろうか。
これは同意なのだけど、
後者の受託とサービスの同時開発の問題は、短距離のタスクと長距離のタスクが並行したときに、そのプライオリティ付けは非常に難しいという問題にあらわれる。
これはどうなのかな。
おそらく「コツ」みたいなものはあるけどなんとかなるんじゃないの、って気がする。
短距離タスク vs 長距離のタスクであるならば、「いつでもできますよ」か、もしくは「まったくやらない」かのどちらかしか選択肢がない。少々スケジュールを遅らせたところで長距離タスクのどこかの時間を奪うだけであれば、今やっても１週間後でも全然、関係ないからだ。
企業文化にも関係してくるので一概には言えないが、「では、いつなら、この作業はできますか？」という問いに対し、気のきいたエンジニアであれば、幾つかの回答パターンを持っている（「今日中」「明日の夕方」「今週中」）。
一旦そういったパターンを投げた後、相手の様子を伺って、調整する感じじゃないのかな。
或いは「いつまでにやればいいんですか？」と逆質問で返すとか。
そもそも長距離タスクであってもなんらかのスケジュール的制約は存在しているだろうし、短距離タスクの頻発が長距離タスクに影響を与えているのならば人員の増加は考慮しなくてはならないと思う。
で、これはおそらく同じことを言っている気もするのだけど、長距離タスクについては「空いた時間で進めておいててよ」
では絶対に成立しない。
Googleの２０％ルールを引き合いに出すと、アレは「してもいい」ではなく「しなければならない」という強い制約なのだが、「たとえエンドユーザがいても優先度を下げる」という、そういう覚悟が必要なのかな、とは思う。
その覚悟がどこに起因するかといえば結局キャッシュかなぁって気がするけど。
