「忙しすぎて改善できない」現場が最初にやるべきこと
「業務改善が必要なのは、全員が分かっています。ただ、その時間がどこにもないんです」。旅行会社の部門責任者と話していると、この一言に行き着くことが少なくありません。ツールの資料は集めてあり、社内で問題意識も共有されている。それでも着手できないまま、また繁忙期がやってきます。
この状態は、意志の弱さでも優先順位のつけ方の失敗でもありません。「改善」という言葉に、無意識のうちに大きすぎる単位が結びついてしまっていることが原因です。本記事では、忙しさを理由に改善が止まっている現場が、日常業務を止めずに動き出すための最初の一手を、具体的な手順として示します。
この記事の要点
- 「改善する時間がない」の正体は時間不足ではなく、改善の単位が大きすぎることにあります。
- 直近1件を15分で棚卸しする3つの観点と、変える工程を1つに絞る考え方を手順として示します。
- 手作業での改善が限界を迎えたとき、業務基盤に何を求めるべきかの判断軸が手に入ります。
目次
この記事の要点
「落ち着いたら改善する」が続く理由
止まっているのは時間ではなく単位
最初の15分：3つの観点で棚卸し
変えるのは1工程だけにする
小さな改善が業務基盤の要件になる
まとめ：改善は時間ができてから始めない
「落ち着いたら改善する」が何年も続いてしまう理由
繁忙期の一日を追ってみます。朝いちばんの仕事は、前夜に届いた変更依頼への対応です。宿泊人数が2名増えたという連絡が入り、ホテルへの追加手配、見積の修正、旅程書の差し替えが同時に発生します。見積を直すには、社内用の原価表とお客様向けの提案書の両方に手を入れる必要があります。旅程書はレイアウトを崩さないように差し替えて、PDFを作り直します。ここまでで1時間近くが消えます。
その間に、別案件のガイドから当日の集合場所について連絡が入ります。過去のやり取りを探そうとメールを遡り、担当者に口頭で確認し、ようやく回答します。午後には新規の見積依頼が届き、似た内容の案件が過去にあったはずだと記憶を頼りに共有フォルダを探します。見つからないので、結局ゼロから作り始めます。
一日が終わるころ、手元に残っているのは「処理した案件の数」だけです。何をどう改善すればいいかを考える余白は、どこにもありません。
この状態で「業務改善のプロジェクトを立ち上げよう」と言われても、動けないのは当然です。プロジェクトという言葉には、要件定義、ツール選定、比較検討、社内稟議、データ移行、操作研修といった工程が付いてきます。合計すれば数か月単位の仕事です。それを、いまの業務を回しながら進めろというのは、無理な相談に聞こえます。
だから「閑散期に落ち着いてやろう」という結論になります。ところが閑散期に入ると、今度は営業活動や来期の商品企画が入ってきます。そして次の繁忙期に同じ問題が再発し、また「落ち着いたらやろう」に戻ります。この往復が、何年も続いてしまいます。
止まっているのは時間ではなく、改善の単位です
ここで視点を変える必要があります。改善が進まないのは時間がないからではなく、改善の単位が大きすぎるからです。
「業務改善」と聞いたときに多くの人が思い浮かべるのは、業務フロー全体を書き出し、あるべき姿を設計し、システムを入れ替えるという一連の作業です。この単位で考える限り、着手には数十時間のまとまった時間が必要になります。そして旅行業の現場に、数十時間の空白は基本的に存在しません。
一方で、「今日対応した1件の案件について、どこで時間を失ったかを書き出す」であれば15分で終わります。「見積のテンプレートを3パターン用意する」なら1時間です。この単位であれば、繁忙期の合間にも入り込めます。
重要なのは、小さい単位から始めることが妥協ではないという点です。むしろ、大きな単位から始めるほうが失敗しやすいという構造があります。業務の実態を数字で把握しないままツール選定に入ると、「多機能そうだから」「他社も使っているから」という基準で選ぶことになり、導入後に「うちの業務には合わなかった」という結論に至りやすくなります。
自社の課題が具体的な言葉になっていない状態での検討は、精度が上がりません。だからこそ、最初にやるべきなのは選定ではなく観測です。
最初の15分：直近1件の案件を3つの観点で棚卸しする
具体的な手順を示します。特別な準備はいりません。直近で対応した案件を1件だけ選び、次の3つを紙かメモアプリに書き出します。所要時間は15分です。
観点1：どの作業に最も時間がかかったか
案件の開始から納品までを工程に分け、それぞれに要した時間を思い出せる範囲で書きます。正確な計測は不要です。「見積の修正に1時間」「旅程書の作成に2時間」という粒度で十分です。
観点2：同じ情報を何回入力したか
顧客名、日程、人数、単価といった情報を、何か所に入力したかを数えます。予約システム、見積書、旅程書、社内の管理表と、同じ内容を4回書いていることは珍しくありません。
観点3：誰の確認待ちで、何時間止まったか
自分の作業ではなく、他者の返答を待っていた時間を書き出します。上長の承認、仕入先からの回答、顧客からの確認など、止まっていた時間は意外と長く残っています。
この3つを書き出すと、改善の優先順位が自動的に見えてきます。「見積の修正に毎回1時間」「顧客情報を4回入力している」「承認待ちで平均半日止まる」といった具体的な事実が並んだとき、どこから手をつけるべきかを議論する必要はほとんどありません。一番大きな数字が、そのまま最初の対象になります。
さらに、この書き出しには副次的な効果があります。改善の話が「なんとなく忙しい」という感覚論から、共有できる事実に変わります。上長に相談するときも、他部署に協力を仰ぐときも、数字があるかないかで話の通りやすさが変わります。
変えるのは1工程だけにする
棚卸しで最も負荷が大きい工程が見えたら、次はそこだけを変えます。全体を一度に変えようとしないことが、続けるための条件です。
見積の修正に時間がかかっているなら、まず単価表を1枚にまとめ、よく使う構成を3パターンだけテンプレート化します。旅程書の作成が重いなら、頻出のホテル・レストラン・アクティビティの説明文を10件だけテキストファイルに整理します。確認待ちが長いなら、承認が必要な金額の基準を決めて、それ未満は事後報告にする運用に切り替えます。
どれも、システムを導入しなくても今週中に着手できる内容です。
こうした変更の効果は、時間の削減だけではありません。作業が中断されにくくなることで、案件全体を見渡す余裕が生まれます。「この案件、もう少し提案を足せそうだ」という発想は、目の前の転記作業に追われている状態からは出てきません。
一方で、この段階の改善には限界もあります。テンプレートはファイルとして散らばりますし、更新した人としていない人が出てきます。整理したコンテンツは、担当者が変わると置き場所が分からなくなります。手作業で維持できる範囲を超えると、管理そのものが新しい負荷になります。
この限界に到達したことは、失敗ではありません。次の段階に進む条件が揃ったという合図です。
小さな改善が続くと、業務基盤に何を求めるべきかが分かる
1つの工程を変えると、次の要望が自然に出てきます。見積テンプレートを作った人は、次に「単価を1か所直したら全部に反映されてほしい」と考えます。コンテンツを整理した人は、「条件で検索して呼び出したい」と考えます。手配の進捗をスプレッドシートで管理し始めた人は、「案件の画面から状況が見えてほしい」と考えます。
この時点で出てくる要望は、ツール比較の記事から得た知識ではなく、自社の業務から出てきた要件です。だからこそ、ツール選定の精度が上がります。デモを見るときも、「この機能があるか」ではなく「うちのこの作業がどう変わるか」で判断できるようになります。
TRAVESENSは、旅程と見積が連動し、一度登録したコンテンツを検索して再利用でき、手配のステータスを案件単位で一元的に確認できる業務基盤です。開発元のTOKI自身がインバウンドのラグジュアリートラベルを手がける旅行会社であり、30社以上の旅行会社へのヒアリングを経てプロダクト化されています。設計の出発点が実際の業務であるため、「テンプレートを配ったのに使われない」「管理表を作ったのに更新されない」といった、手作業の延長で起きがちな問題を構造的に減らせます。
ただし、こうした業務基盤が有効に働くのは、自社の課題が言葉になっている会社です。棚卸しをしないまま導入すると、機能の多さに圧倒されて設定が止まります。順番としては、15分の棚卸し、1工程の改善、そのうえでの基盤検討です。この順番を守るほうが、結果的に早く進みます。
まとめ：改善は、時間ができてから始めるものではありません
「忙しすぎて改善できない」という状態は、多くの現場で実際に起きています。それは事実です。ただ、その状態を抜け出す方法は、時間を確保することではありません。
やるべきことは3つです。直近1件の案件を3つの観点で棚卸しすること。最も重い1工程だけを選んで変えること。手作業での維持が難しくなった時点で、業務基盤の検討に進むこと。
最初の一歩は15分です。次の繁忙期を同じ状態で迎えないために、今日対応した案件を1件、思い出すところから始めてみてください。
小さな改善が、続く仕組みへ。
テンプレートやフォルダ整理が限界を迎えたら、次は基盤の検討です。TRAVESENSは旅程と見積を連動させ、一度登録したコンテンツを検索して再利用できます。
まずは、実際の画面でご体験ください
無料デモを申し込む