セルフオーダーシステム開発の完全ガイド

セルフオーダーシステムとは、来店客がスマートフォンや店内端末から注文し、注文データをPOS・厨房・決済へ自動連携する仕組みで、注文受付の省力化と入力ミスの削減を同時に目指す業務システムです。

ただし、注文画面だけを導入しても、売切れ、追加注文、席移動、返金、通信断などの例外処理が現場で止まれば、期待した効果は得られません。本記事では、セルフオーダーシステムの種類、主要機能、導入メリットと注意点、費用相場、開発・導入の進め方、連携・セキュリティ、開発会社/ベンダーの選び方、KPI、FAQまでを2026年時点の情報で解説します。

セルフオーダーシステムとは何ですか？

セルフオーダーシステムは、顧客が自分で商品を選び、注文を確定する入口と、店舗が注文を処理・提供・会計する業務基盤をつなぐシステムです。単なるデジタルメニューではなく、注文情報を一度入力すれば、POS、キッチンプリンターまたはキッチンディスプレイ、決済、売上分析へ引き継げることが重要です。

注文受付だけでなく店舗業務全体をつなぐ仕組みです

顧客側では、カテゴリ検索、写真付きメニュー、サイズやトッピングの選択、アレルゲン表示、言語切り替え、追加注文、注文内容の確認、呼び出し、オンライン決済などを扱います。店舗側では、商品・価格・税率・提供時間・売切れ・テーブル・権限のマスタを管理し、注文を調理場の担当ごとに振り分けます。さらに、注文点数や時間帯別売上を蓄積すれば、メニュー改善や人員配置にも使えます。

セルフオーダーとセルフレジは同じものではありません。前者は注文を顧客自身に入力してもらう機能で、後者は会計・精算を顧客自身に操作してもらう機能です。また、店内の席から注文する仕組みは、持ち帰りや事前注文を含むモバイルオーダーの一部として設計される場合もあります。目的が「聞き取りを減らす」のか「会計待ちを減らす」のかを分けて定義すると、必要な機能が明確になります。

最低限必要な機能は注文・マスタ・厨房・会計の連携です

最小構成は、顧客が注文する画面、店舗が商品を登録する管理画面、POSへ取引を送る連携、厨房へ注文を伝える仕組みです。実運用では、売切れを即時に反映する機能、オプションの選択制御、同一テーブルの追加注文、注文の取消・訂正、会計前の仮注文、食べ放題やコース料理の提供タイミングも必要になります。注文完了画面だけを見て判断せず、厨房で「何を、いつ、どの担当が作るか」まで確認してください。

多店舗展開を想定する場合は、本部でメニューを一括更新しながら、店舗ごとの価格、営業時間、売切れ、税率を上書きできる構造が有効です。店舗が独自に変更した情報を本部更新で消してしまう事故を防ぐため、マスタの所有者と反映ルールを先に決めます。注文データの所有権、CSVなどでの出力可否、解約後のデータ返却も、導入前に確認しておくべき項目です。

店舗に合うセルフオーダー方式はどれですか？

方式の選択は、端末価格だけでなく、顧客の年齢層、席数、注文頻度、前会計か後会計か、スタッフが例外対応できる人数で決めます。スマートフォン型は初期費用を抑えやすく、タブレット型は画面の見やすさと操作の統一に優れます。券売機・縦型端末型は前払いと受け渡しを短くしやすい一方、端末の設置場所と保守が必要です。

スマートフォン型は低負担で始めやすい方式です

テーブルのQRコードを顧客のスマートフォンで読み取り、ブラウザやWebアプリから注文する方式です。店が端末を人数分用意しなくてよいため、席数が多い店舗や、注文が集中する時間帯だけセルフ化したい店舗に向きます。メニュー変更もクラウド側で反映しやすく、多言語表示や追加注文との相性も良い方式です。

一方で、スマートフォンを持っていない人、充電が切れている人、画面操作に不慣れな人への代替導線が欠かせません。スタッフ用ハンディ、紙メニューからの代理入力、卓上タブレットの一部設置などを残すと、顧客体験を損ねにくくなります。QRコードの貼り替え、席番号の取り違え、悪意ある注文のなりすましも、現場テストで確認してください。

タブレット型は操作性と注文体験をそろえやすい方式です

卓上タブレットを設置し、顧客が写真や説明を見ながら注文する方式です。大きなボタン、カテゴリー別の導線、アレルゲンや辛さの表示を統一できるため、メニュー数が多い店舗や、追加注文を促したい店舗に適しています。端末に席をひも付ければ、後会計やテーブルごとの追加注文も管理しやすくなります。

端末代、ケース、充電場所、盗難対策、故障時の交換、OS更新を含めると、スマートフォン型より総額が上がりやすくなります。画面を見続けることによる顧客の疲れや、端末が汚れたときの清掃手順も運用設計に入れます。3〜10台程度の小規模導入でも、予備端末を1台用意するか、スタッフの代理注文で継続できるようにすると安心です。

券売機・縦型端末と併用方式は前会計に強いです

券売機や縦型の大画面端末は、入口で注文と決済を済ませ、番号呼び出しで商品を受け取る業態に適しています。2026年2月に公表された飲食店向け縦型セルフ端末の例では、注文だけ、会計だけ、注文と会計の両方という運用が想定され、27インチ画面の端末が2026年7月発売予定とされていました。このように、同じ端末でも業態と会計方式を選べる設計が増えています。

フードコート、テイクアウト、回転の速い飲食店では、前会計型が待ち行列の整理に役立ちます。反対に、席で料理を追加し、食べ放題やコースの進行を管理する店舗では、テーブル注文型とスタッフ対応を組み合わせる方が自然です。実際には、ランチだけ券売機、ディナーは卓上端末という時間帯別のハイブリッドも選択肢になります。

導入メリットと注意点をどう見極めますか？

導入効果は「スタッフを減らせるか」だけで評価しないことが大切です。注文を聞き取る時間、聞き間違いの訂正、レジ入力、厨房への伝達を減らし、その時間を料理提供や顧客フォローへ再配置できるかが本当の論点です。セルフ化によって接客を失うのではなく、必要な接客へ人を振り向ける設計にします。

注文ミスと聞き取り時間を減らしやすい点がメリットです

顧客がトッピングや数量を画面で選び、厨房へ構造化されたデータが届けば、口頭伝達と手入力の回数が減ります。注文履歴をもとに、追加注文の多い商品、提供に時間がかかる商品、時間帯ごとのピークも把握できます。写真やおすすめ表示を改善すれば、注文単価や注文点数を伸ばせる可能性もあります。

ただし、システム導入直後は質問対応が増えます。顧客が操作に迷う画面や、注文完了と決済完了を混同する表示があると、スタッフの確認作業が増えてしまいます。導入前後で、注文対応時間、訂正件数、会計待ち時間、客単価を同じ定義で測り、効果が見えない場合は画面や業務フローを修正してください。

顧客体験を損なわない代替導線が必要です

すべての顧客が同じ端末を使えるとは限りません。高齢者、子ども連れ、視力に不安のある人、外国語を必要とする人、スマートフォンを使いたくない人がいるため、スタッフ注文や紙の案内を完全に廃止しない方がよい場合があります。端末を置くだけでなく、入口での案内、席での声かけ、困ったときの呼び出しボタンを設計すると、セルフ化が拒絶されにくくなります。

多言語対応も、単純な自動翻訳だけでは不十分です。アレルゲン、辛さ、量、提供時間など誤解が事故につながる情報は、人が確認した文言を登録します。決済が失敗した場合に二重注文にならないか、戻るボタンで注文が重複しないかを、実際の顧客に近い条件でテストしてください。

例外処理を決めない導入は現場の負担を増やします

失敗しやすいのは、通常の注文が通ることだけを確認して公開するケースです。売切れ商品の注文、席移動、同席者による追加注文、注文後の数量変更、取消、返金、クーポン適用、食べ放題のラストオーダー、テイクアウトの受取時間変更を、誰がどの画面で処理するか決めます。返金権限を全員に与えず、履歴と理由を残すことも不正防止に有効です。

通信断や端末故障が起きたときに、紙伝票やスタッフのハンディへ切り替える手順も用意します。復旧後に二重送信が起きないよう、注文番号、送信時刻、同期状態を確認できる仕組みが必要です。障害時の代替手段を一度も訓練していない店舗は、ピーク時間にトラブルが起きると、システムがあるのに営業を止めることになります。

セルフオーダーシステム開発・導入はどう進めますか？

開発は、いきなり画面を作るのではなく、店舗の業務フローとデータの流れを固めてから進めます。最初に「どの注文を、誰が、どの端末で入力し、どのシステムへ渡すか」を図にし、標準機能で足りる部分と、追加開発が必要な部分を分けます。1店舗での検証を挟んでから全店へ展開すると、想定外の運用差を抑えられます。

要件定義では注文方式より先に業務フローを描きます

要件定義では、店舗数、席数、営業時間、ピークの注文数、メニュー数、商品変更の頻度を整理します。さらに、前会計か後会計か、席を移動できるか、食べ放題・コースを扱うか、テイクアウトやデリバリーを受けるか、予約と注文を統合するかを決めます。商品、税率、オプション、アレルゲン、売切れを誰が管理するかも、機能要件と同じくらい重要です。

成果指標は導入前に計測します。たとえば、スタッフが注文に費やす時間、注文訂正件数、注文完了率、追加注文率、会計待ち時間、客単価、注文から提供までの時間を、曜日と時間帯をそろえて記録します。人件費だけでなく、注文ミスによる作り直しや、レジ待ちによる機会損失も対象にすると、投資判断が現実に近づきます。

設計・開発では店舗と厨房の操作を同時に検証します

画面設計は顧客向けだけでなく、店舗管理、厨房、会計、サポートの各画面を含めて行います。顧客画面では、人気商品やおすすめを目立たせながら、必須選択と任意選択を区別します。厨房画面では、調理順、提供希望時間、アレルギー注意、品切れ、同時提供のまとまりが見える必要があります。画面上の文言と実際の伝票が一致しているかを、厨房担当者と一緒に確認してください。

連携開発では、POSへ同じ注文を二重登録しないこと、税率や値引きを一致させること、取消・返金の結果を双方へ返すことを確認します。APIが用意されていても、すべてのデータが同期できるとは限りません。商品マスタだけ連携するのか、在庫・顧客・ポイント・予約・売上分析まで連携するのかを項目単位で定義し、責任分界を文書化します。

テスト導入と教育で本番の混乱を減らします

リリース前には、通常注文だけでなく、売切れ、取消、返金、席移動、決済失敗、通信断、端末交換、閉店処理までをテストします。可能なら、客層やピーク時間が異なる1店舗で試験運用し、注文完了率とスタッフの対応時間を確認します。機能が動くことと、現場が迷わず使えることは別なので、現場の合格基準を決めてください。

教育では、操作マニュアルだけでなく「困ったときの判断」を示します。たとえば、二重注文の疑いがあるときは厨房へ確認してから取消する、通信が切れたら紙伝票へ切り替える、返金は責任者が履歴を確認するというルールです。公開後は、初週の問い合わせと訂正内容を毎日見直し、1か月後にKPIと現場の声をまとめて追加改善を行います。

セルフオーダーシステムの費用相場はいくらですか？

費用は、注文方式、店舗数、テーブル数、端末台数、POSや厨房機器との連携、決済方法、カスタマイズの範囲で大きく変わります。「初期費用0円」だけで判断せず、POS基本料、注文機能、端末、設置設定、メニュー登録、通信、プリンター、KDS、決済手数料、保守、解約時のデータ出力まで含む1店舗3年の総保有コストで比べます。

▶ 詳細はこちら：セルフオーダーシステム開発の見積相場や費用/コスト/値段について

クラウド型の小規模導入は月額と初期設定を分けて見ます

クラウド型のQR・スマートフォン注文を1店舗で始める場合、目安は初期0万〜10万円程度、月額1万〜5万円程度です。POSを含むか、テーブル数、決済、サポート、メニュー登録代行が含まれるかで変わるため、あくまで概算として扱います。公開料金の一例では、2026年3月版の規約に、マスタ登録費1万5,000円、設置設定費2万円、10テーブルまで月額6,000円、11テーブル以降は1テーブルごとに月額500円という記載があります（出典: 公開料金規約、2026年3月版）。

別の公開アプリ料金一覧では、店内モバイルオーダーに月額1,100円から、5,500円から、1万1,000円といった複数の価格帯が確認できます（出典: 公開アプリ料金一覧、2026年8月確認）。ただし、これらは注文機能の料金であり、POS本体、決済、通信、端末、厨房機器が別になる場合があります。見積書では「月額」の対象範囲を確認し、3年分に換算してください。

タブレット導入は端末と周辺機器で20万〜100万円程度を見込みます

タブレットを3〜10台導入する場合は、端末、ケース、充電、ネットワーク、設置設定、キッチンプリンターなどを含めて、初期20万〜100万円程度を見込むと計画しやすくなります。端末を既に持っていても、業務用の固定、キオスクモード、予備端末、故障交換費を忘れてはいけません。店舗の席数だけでなく、ピーク時に同時注文する台数と、故障時の最低稼働台数で調達台数を考えます。

POS、会計、KDS、予約、デリバリーなどとの連携開発は、既存APIと要件によって数十万円から100万円程度が別途発生する可能性があります。パッケージの設定だけで済むのか、個別の画面・帳票・マスタ同期を作るのかで、同じ「連携」でも工数は変わります。初期費用の比較ではなく、追加開発、保守、バージョンアップの費用も含めて評価します。

スクラッチ開発は機能範囲ごとの推定として扱います

公開定価のないスクラッチ開発は、統計的な相場ではなく、機能範囲から推定します。QR・スマートフォン注文、管理画面、POS・厨房連携を1ブランド向けに開発する小〜中規模なら300万〜800万円程度、端末管理、決済、予約・デリバリー、分析、多言語まで含む中規模なら800万〜2,000万円程度が一つの目安です。多店舗・多ブランド・本部統合・高可用性まで含めると、1,500万〜4,000万円以上になる可能性があります（出典: 類似する店舗業務システムの公開相場を機能範囲へ置き換えた推定、2026年確認）。

パッケージ導入は1〜3か月、画面や帳票のカスタマイズを含めると3〜6か月、複数ブランドや基幹連携を含むスクラッチ開発は6〜12か月以上が目安です。請負か準委任か、要件変更をどこまで許容するか、保守・監視・障害対応を誰が担うかで費用と期間が変わります。RFPには、初期費用だけでなく、月額、決済手数料、端末更新、問い合わせ対応、データ移行、終了時の撤去まで記載してください。

POS・厨房・決済連携とセキュリティで何を確認しますか？

セルフオーダーの品質は、顧客画面の見栄えよりも、注文が正しい状態で厨房と会計へ届くかで決まります。商品マスタ、税率、オプション、売切れ、席、注文状態、決済状態を、どのシステムが正とするか決めます。連携先が増えるほど便利になりますが、障害時にどこまで営業を続けられるかも複雑になります。

POSと厨房は注文の状態を一致させることが重要です

顧客の注文送信、店舗の受付、調理中、提供済み、会計済み、取消という状態を、顧客画面・管理画面・厨房画面・POSで一致させます。厨房では、ドリンクと料理を別担当へ振り分ける、同時提供にまとめる、アレルギー注意を目立たせるなど、店舗固有のルールを表現します。プリンターを使う場合は紙切れ、印字崩れ、再印刷の重複を、KDSを使う場合は停電や通信断時の表示を検証します。

会計では、前会計と後会計で扱うデータが異なります。前会計なら決済成功後だけ厨房へ送るのか、決済失敗時に仮注文を残すのかを決めます。後会計なら、同じ席の注文をまとめ、席移動や分割会計に対応し、途中で追加された注文を取りこぼさない設計が必要です。注文番号と取引番号をひも付け、問い合わせ時に追跡できるようにします。

通信断・端末故障・監視の設計を見積もりに含めます

店舗では、Wi-Fiの一時的な切断、端末の電池切れ、プリンターの紙切れ、クラウド障害が起こり得ます。注文を端末に一時保存して再送するのか、完全にオフラインで受付できるのか、スタッフの手書きへ切り替えるのかを選びます。再送キューがある場合は、同じ注文を二度送らない識別子と、再送済み・未送信の表示を実装します。

導入後は、注文失敗率、同期遅延、決済エラー、端末の稼働状況、プリンターの異常、APIエラーを監視します。店舗スタッフが一次切り分けできるように、端末再起動、ネットワーク確認、代替運用への切り替えを短い手順にします。サポート窓口の受付時間、障害時の連絡方法、復旧目標、代替機の発送条件は、契約前に確認します。

個人情報とカード情報は保存範囲を小さくします

会員登録や予約を組み合わせると、氏名、連絡先、来店履歴などの個人情報を扱う場合があります。個人情報保護委員会は、アクセス制御、通信の暗号化、ログの定期分析などを安全管理措置の例として示しています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン」、2026年確認）。管理画面の権限を店舗・本部・サポートで分け、不要な個人情報を注文システムへ取り込まないことが基本です。

カード決済では、カード番号を自社の注文システムに保存せず、決済代行のトークン化やホスト型決済を使う設計が一般的です。PCI DSSは、カード会員データを保存・処理・送信する事業者や、カード会員データ環境の安全性に影響する事業者を対象にしています（出典: PCI Security Standards Council「PCI DSS 日本語版」、2026年確認）。どの情報を誰が保持するか、委託先の準拠状況、事故時の連絡と報告の分担を確認してください。

セルフオーダーシステム開発会社/ベンダーの選び方

選定では、既製クラウドを提供するベンダー、POSや厨房機器まで導入する店舗DX事業者、独自業務を作り込む受託開発会社を分けて比較します。標準機能で早く始めたいのか、独自の席管理や本部統合を実現したいのかで、適した相手は変わります。営業資料の機能数だけでなく、実際の店舗運用、障害時の責任分界、データの持ち出しやすさを確認します。

自店と似た業態の業務実績を確認します

実績を見るときは、導入社数の多さだけで判断しません。自店と似た席数、注文頻度、前後会計、食べ放題、コース、テイクアウト、多言語の条件で、どこまで標準機能で対応したかを聞きます。デモでは、商品を売切れにする、同じ席で追加注文する、注文を取消して返金する、通信を切断して再開するというシナリオを操作し、現場の担当者が理解できるかを確認します。

開発会社を選ぶ場合は、要件定義、UX設計、API連携、端末キッティング、テスト、教育、保守まで誰が担当するかを確認します。サービス提供者と開発担当が別の場合は、障害や仕様変更の問い合わせ先が曖昧になりやすいので、責任分界表を提出してもらいます。店舗展開の経験がある相手ほど、店ごとの差分や、公開後のメニュー更新を含めた提案が期待できます。

同一条件のRFPで3社以上を比較します

見積もりは、店舗数、席数、端末台数、注文方式、前後会計、POS・厨房・決済の連携範囲、メニュー登録件数、導入希望日をそろえて依頼します。初期費用と月額を分け、端末、設置、通信、決済手数料、保守、追加開発、教育、データ移行、解約時の出力費を項目化してもらいます。要件が同じでなければ、安い見積もりが本当に安いとは限りません。

確認する質問は、(1)注文データの所有者、(2)既存POSとの同期項目、(3)売切れと税率の反映時間、(4)席移動・取消・返金への対応、(5)通信断時の営業方法、(6)決済情報の保存範囲、(7)サポート受付時間、(8)障害時の復旧目標、(9)契約終了時のデータ形式、(10)将来の店舗追加費用です。口頭回答ではなく、見積書や仕様書に残します。

▶ 詳細はこちら：セルフオーダーシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：セルフオーダーシステム開発の進め方/やり方/流れや方法/手法/工程/手順

▶ 詳細はこちら：セルフオーダーシステム開発の発注/外注/依頼/委託方法について

導入後のKPIとROIはどう測りますか？

導入効果は、システムが稼働したかではなく、業務と顧客行動がどう変わったかで測ります。導入前の基準値を残し、同じ曜日・時間帯・客数の条件で比較します。1つの数字だけで成功を判断せず、省力化、品質、売上、顧客体験、安定運用の5方向から確認してください。

注文完了率と注文ミスを中心にKPIを設計します

基本KPIは、注文完了率、注文に要する時間、スタッフの代理入力件数、注文訂正件数、売切れ商品の注文発生数、厨房への伝達遅延、会計待ち時間です。売上面では、客単価、追加注文率、注文点数、時間帯別の注文構成を見ます。顧客体験では、操作に関する問い合わせ、呼び出し回数、途中離脱、アンケートの不満内容を確認します。

システム面では、注文送信エラー、決済失敗、同期遅延、端末停止、プリンターの再印刷、障害からの復旧時間を記録します。数字は管理者だけでなく現場へ共有し、改善につなげます。注文完了率が低いなら画面導線を直し、注文訂正が多いなら商品説明や選択肢を直し、厨房遅延が多いなら振り分けルールを直すというように、KPIと施策を対応させます。

ROIは削減時間と追加コストを同じ期間で比較します

ROIを考えるときは、削減できた注文受付時間を人件費換算し、注文ミスの作り直し、会計待ちによる離脱、追加注文による売上変化を加味します。一方で、月額料金、端末の減価償却、決済手数料、通信、保守、メニュー更新、教育の時間を差し引きます。たとえば、月間の削減効果が月額と保守費を下回るなら、機能追加よりも対象時間帯を限定する方が適切かもしれません。

投資回収期間は、初期費用を月間の純効果で割って考えます。ただし、客単価の上昇や接客品質はすぐに金額へ換算しにくいため、定性評価も併記します。重要なのは「人員ゼロ」を目指すことではなく、注文受付を減らした人員を料理提供、顧客フォロー、例外対応、清掃へ再配置し、店舗全体の価値を上げることです。

セルフオーダーシステムについてよくある質問

導入前によくある疑問を、方式、費用、開発の観点から回答します。店舗の業態や既存POSによって最適解は変わるため、回答を自店の業務フローに置き換えて判断してください。

小規模店舗でもセルフオーダーシステムを導入できますか？

導入できます。まずはQR・スマートフォン型を1店舗、限定メニュー、限定時間帯で試し、注文完了率やスタッフの対応時間を測る方法が現実的です。端末を多数購入する前に、代替注文と障害時の運用を確認し、月額と決済手数料を含む3年TCOで判断してください。

スマートフォン型とタブレット型はどちらが良いですか？

初期負担を抑え、席数が多く、顧客が自分の端末を使える環境ならスマートフォン型が向きます。操作を統一し、写真や多言語表示を重視し、端末を店舗で管理できるならタブレット型が向きます。どちらか一方に固定せず、スマートフォンを基本に、必要な席だけタブレットやスタッフ注文を残す併用も有効です。

既存POSと連携できるかはどこを確認すればよいですか？

商品・価格・税率・売切れ・注文・取消・返金・会計・売上分析のどこまで同期できるかを項目ごとに確認します。連携できると説明されても、既存POSの契約プランやAPI利用条件、別途の開発費が必要な場合があります。デモで通常注文だけでなく、返金、席移動、通信断からの復旧まで実演してもらい、責任分界を契約書や仕様書へ残してください。

パッケージとスクラッチ開発はどう選びますか？

標準化できる業務で早期導入したい場合は、クラウド型やパッケージが向きます。多ブランド、本部統合、特殊な席・厨房・会計ルールを競争力にしたい場合は、カスタマイズやスクラッチ開発を検討します。ただし、独自機能を増やすほど初期費用だけでなく、テスト、保守、将来の変更費用も増えるため、差別化に直結する機能だけを作り込むことが大切です。

まとめ

セルフオーダーシステムは、顧客が注文する画面だけでなく、POS、厨房、決済、売上分析、店舗運用をつなぐ業務基盤です。スマートフォン型、タブレット型、券売機・縦型端末型にはそれぞれ適性があり、顧客層、席数、会計方式、注文頻度、スタッフ体制で選ぶ必要があります。

安さより業務全体のつながりと3年TCOで選びます

費用は初期0円や月額だけでなく、端末、設置、通信、決済手数料、厨房機器、登録代行、保守、追加開発、教育まで含めて3年TCOで比較します。開発・導入では、要件定義、連携設計、現場テスト、試験導入、教育、障害時の代替手段を一つの計画にまとめます。売切れ、席移動、追加注文、取消・返金、食べ放題、通信断を確認して初めて、現場で使えるシステムになります。

まず1店舗の業務フローと測定指標を固めます

最初の一歩は、注文受付、厨房、会計、顧客対応の現状を図にし、削減したい時間と残すべき接客を決めることです。そのうえで、同一条件のRFPを複数の候補へ渡し、標準機能と追加開発、データの所有権、サポート、セキュリティを比較します。セルフ化すれば必ず人員ゼロになるのではなく、注文受付を減らした人員を店舗価値の高い仕事へ再配置することが、導入を成功させる考え方です。