前回の記事の続きです。
以下の記事に触発される形で「重要」について掘り下げました。
この記事では「米国資本の某ハンバーガーチェーン」におけるオペレーションが題材になっています。
同社では、以前は来店客数を予測した上でハンバーガーを作りおきしていたのが、現在では注文を受けてから作るようにシステムが変更されています。
僕自身、大学時代に同チェーンでハンバーガーを作るアルバイトに勤しんでおり、当時はまだ「作りおき」の時代でした。
店内ではいろいろな仕事がありましたが、とりわけP/C（プロダクション・コーラー）というポジションが花形。
厨房とカウンターの両方に目が届く位置に立ち、厨房に対してハンバーガーやフィレオフィッシュをそれぞれいくつ作るのかの指示を出す、言わば司令塔のような役割です。
いくつ作るのかは、その時点のハンバーガーのストックやカウンターに並ぶお客さんの数、さらには過去の曜日別時間帯別の注文実績データも加味した上で予測します。
売れないまま一定時間が経過すると廃棄されるため、この予測はお店の利益を左右する重要な意志決定と言えます。
データの解釈と経験の蓄積の両方が求められる仕事です。
一方、現在はオーダーメイドに切り替わっており、求められる条件も変わっているはずです。
それは、オーダーに対していかに短時間でメイドできるか。
準備（ストック）の質ではなく、対応（リアクション）の質が要求されるわけです。
この2つの違いをタスクシュートに当てはめてみます。
- 作りおきのタスクシュート
- オーダーメイドのタスクシュート
作りおきのタスクシュート
作りおきのタスクシュートとは、その日に実行予定のタスクが予めタスクシュート上に実行する順番に整然と配備されている状態と言えます。
初めてタスクシュートに取り組む人にとってはゼロから始まるため、この状態は言わば「最終形態」であり、まずはここを目指すことになります。
日々、実際に実行したタスクのいくつかをリピートタスク化していくことで、少しずつこの最終形態に近づいていきます。
来店客を待たせる時間が減っていき、評価も高まっていくでしょう。
「オーダー」されるであろうタスクはたいていすでにタスクシュート上に控えているため、つまり予測の精度が極めて高いため、もれなく実行することができます。
一方で、せっかく準備したのに実行されずに終わるタスクも出てきます。
ハンバーガーで言えば廃棄です。
とはいえ、ハンバーガーと違ってタスクの準備には実質的にはコストはかかりませんから「廃棄」（＝実行されずにその日のタスクシュートから削除）されたとしても、特にダメージはありません。
ダメージは別のところに生じます。
