出張によるオーバーヘッドをどうにかリカバリーしたい。

先日のシンガポールに続き今日は静岡への中距離（？）出張。午後からのプログラムですが往復の時間や新幹線等交通機関利用のオーバーヘッド（無駄な時間）が発生するので帰社できず。今日は昼から何でもリモートで対応しなければなりません。

クライアントがいつでも近距離在京なんてわけもなく、時々こういうことは起きるわけですが、オーバーヘッドをどうにか少しでも軽減したい、というのが正直な気持ち。

新幹線の社内や待合室でできるだけPCワークをするように、またその時間範囲と環境下で作業できる内容になるように、TODOを調整してはおきます。とはいっても、普通にデスクワークするよりも効率的かというとさすがにそこまでは難しい。

新幹線の場合、飛行機と違ってPCをリモートアクセスさせることが可能です。ですが移動速度の問題もあって、接続環境はそう良くもない。Pocket WiFiやEMのUSBドライブを使いますがなかなか実質の「バリ５」にはならないしトンネルもあるので、「サクサク」とはいかない。それでも、作業できるからマシではあります。

今回、タクシー→駅待合室→新幹線→タクシー→クライアント先、そしてその復路、という流れでしたが、そのどれもが15分～30分くらいということで、刻みが大きくないためそこにどういう作業を詰め込むかの計画がなかなかに難儀ですね。さらに「→」の部分も歩いてはいても電話くらいはできるからとそういう会話機会を予定しておくんだけど、とはいってもちょっと会話が長引くと次の乗車機会になってしまって途中で会話終了・・・なんてことも起きるわけですね。

とにかく。少しでも効率的に仕事がたまらないよう片付けたいわけですから、なんとか小刻みな仕事をその移動時間の各作業枠に詰め込んでみるわけです。ある意味刻みの短い仕事は、比較的士気は維持しやすいので片っ端から片付けていく流れはまあまあ気分もいい。とりあえず「てきぱき」に徹してみる。

しかし。移動による切れ目がない「普通の作業環境」での効率に勝ち目があるわけでもありません。所詮オーバーヘッドは、完全リカバリーはできない。

とはいっても、少しでもリカバリーもしたい。

前職では移動時間を勤務実績（システム）に計上するアカウントがありました。その名も「In Transit」。つまり「移動中の時間」です。当然クライアントに請求しない非稼動時間です。当時・・・

でも、今や「In Transit」は昔と違ってリモートアクセス＋モバイル機器によって立派な作業時間になりえます。「普通の作業環境」と同じ評価をするのはまだ課題が多いけど、その「In Transit」を最大限活用して少しでも進捗させようとする姿勢を評価する仕組みは重要といえます。