脱エクセル研究所 > 脱Excelのあるべき姿はどう描く?何を残し、何を移し、何をやめるか
2026年4月2日
•約10分で読めます
脱Excelの To-Be で、何を残し、何を移し、何をやめるかをどう決めるかをまとめました。Excelゼロを目標にせず、事故が減る運用を描くための実務ガイドです。
課題整理で、何が本当の問題かはだいぶ見えてきました。でも次に「あるべき姿を描く」と言われると、どこまで移して、何を残すべきかでまた迷います。
そこで大事なのは、全部移すかどうか で考えないことじゃ。To-Beで決めるのは、どんな運用なら事故が減るか なんじゃよ。
脱Excelの To-Be で決めるのは、Excelをゼロにすること ではありません。
先に整理したいのは、次の3つです。
つまり To-Be は、何を残し、何を移し、何をやめるかを決める段階 です。
ここで完成画面を細かく描くより、どう回る状態にしたいか を先に決めた方が後でぶれにくくなります。
全体の流れを先に見直したい場合は、親記事から戻ると整理しやすいです。
To-Be と聞くと、つい
を先に考えたくなります。
でもこの段階で本当に決めたいのは、どういう運用なら無理なく回るか です。
たとえば、
のように、運用の方針 から言える状態が理想です。
ここが曖昧なままツール比較へ進むと、また「今のExcelをそのまま再現する話」に戻りやすいです。
脱Excelの話になると、勢いで「もう全部移そう」となりがちです。
ただ、これは失敗しやすい考え方です。
叩き台、試算、一時的な分析メモのように、変わりやすい作業 まで最初から移すと、運用がかえって窮屈になります。
残した方がよいExcelもある という前提を持っておく方が安全です。
問題が
にあるのに、全部移行だけを目標にすると、何を減らしたいのか がぼやけます。
移行そのものを目的化しない のが大事です。
一気に全部変えると、現場は
となりがちです。
全部変えるより、事故が減る順番で変える 方が定着しやすいです。
「全部変える」が分かりやすく見えて、実は一番危ないんですね。
そうじゃ。To-Beは理想論ではなく、現場で回る形 を描く段階じゃからのう。
To-Be を考えるときは、最初から正解を当てにいくより、仕事を次の3つに分けると整理しやすいです。
Excelのままで問題が小さいものです。
ここは、無理に移さない 方がかえって早いことがあります。
共有、履歴、権限、継続運用が必要で、Excelだけでは回りにくいものです。
ここは、運用の正本をどこに置くか を決める対象です。
今の運用の中で、実はなくしてよいものです。
To-Beでは、今ある作業を全部引き継がない ことも重要です。
増えた経緯があるだけで、今は不要な作業もかなりあります。
脱Excelの記事を書いていると意外に思われますが、残してよいExcel はあります。
たとえば次のようなものです。
こうした仕事は、柔らかさが必要です。
最初からシステム化しすぎると、変更に弱くなります。
ここでの判断軸は、固定運用に乗せる必要があるか です。
固定化する必要がないなら、Excelを残す判断も十分合理的です。
一方で、次のような業務は移行候補になりやすいです。
ここは、便利かどうか より 事故が起きやすいか を軸に見る方がよいです。
共有の正本として持つ業務 は、Excelだけでは限界が出やすいです。
既存の子記事で近いテーマはこのあたりです。
To-Be を考えるときに見落としやすいのが、やめる作業 です。
今ある作業は全部必要だと思い込みやすいですが、実際はそうでもありません。
よくあるのは、
です。
ここは、その作業は本当に残す必要があるか と一度切り直した方がよいです。
「移すか残すか」だけで考えると、不要作業まで新しい運用へ持ち込みやすくなります。
細かく考えすぎる前に、まずは次の4軸で見ると整理しやすいです。
| 判断軸 | 残しやすい | 移しやすい |
|---|---|---|
| 利用人数 | 1〜2人 | 3人以上で継続運用 |
| 更新頻度 | 月1回以下 | 毎日・毎週更新 |
| 正確性要求 | 多少の手直しで済む | ミスが実害に直結する |
| 履歴・権限 | 不要 | 必要 |
この表の見方は単純で、右側に寄るほど移行優先度が上がる です。
逆に左側に寄るなら、最初から無理に移さなくても構いません。
To-Be も課題と同じで、長く話すより 1 文で言える方が強いです。
たとえば、
案件情報の正本は1か所に集め、会議前の別集計をなくし、試算用の個人メモだけはExcelに残す
顧客台帳は共有基盤へ移し、履歴と担当引き継ぎを見えるようにし、個別の補助管理表は減らす
のように、
まで入ると、次の運用設計へ渡しやすい To-Be 文 になります。
To-Be でまだやらなくてよいこともあります。
ここで細かく入りすぎると、また設計が先走ります。
この段階の役割は、どう回る状態を目指すかを決めること です。
実装や詳細設計は次のフェーズで考えれば十分です。
To-Be が一段落したと言えるのは、次の3つを説明できる状態 です。
たとえば、
台帳として共有する情報は1か所へ寄せる
会議前だけの別集計はやめる
試算や検討段階の下書きだけは Excel に残す
くらいまで言えれば、次の業務フロー設計に入りやすいです。
以下は、イメージしやすくするための架空の例 です。
失敗例: 南星設備工業株式会社(従業員52名 / 空調工事の施工管理)
課題整理の結果、案件進捗、原価見込み、現場写真の共有、会議資料づくりがすべてバラバラになっていることが見えました。
ただし To-Be の会議では、「せっかくだから全部システム側へ寄せよう」となり、個人の試算表、現場ごとの仮メモ、会議用のたたき台まで移行対象に入れてしまいました。
その結果、見積の途中で数字を何度も触る営業と、現場ごとにメモの書き方を変えたい施工管理者が使いにくさを感じ、すぐにローカルExcelへ戻りました。
新しい仕組みには正本の台帳だけでなく、柔らかく使うべき下書きまで持ち込んでしまったため、結局「新ツールにも入れるが、最後はExcelで調整する」状態になりました。
失敗の原因は、残す仕事と移す仕事を分けず、今ある作業を全部引き継いだこと でした。
成功例: 山手物流機器株式会社(従業員44名 / 倉庫機器の販売・保守)
この会社では、案件台帳、保守予定、売上見込み、週次会議資料がそれぞれ別で動いていました。
To-Be では最初に「残す」「移す」「やめる」を分けました。
残すのは営業が個人で使う試算メモ、移すのは案件の正本と保守予定、やめるのは週次会議のためだけに作る別集計です。
具体的には、「案件と保守予定の正本は1か所へ集める」「会議はその正本を見る前提にする」「個人の試算だけはExcelでよい」という 3 本柱に整理しました。
この形にしたことで、現場からも「全部奪われる感じがしない」「でも二重入力は減りそう」という納得感が出て、次の運用ルール設計に進みやすくなりました。
うまくいった理由は、Excelゼロではなく、事故が減る運用を目標にしたこと でした。
フェーズ3の記事から続けて整理したい場合は、課題整理の記事も見返す と To-Be がぶれにくくなります。
脱Excelの課題整理はどう進める?症状を本当の問題に言い換える方法
To-Be を考えていると、だんだん「では何を準備すべきか」が気になってきます。
その段階に近づいたら、移行前の記事も先に読む と整理しやすいです。
脱Excelの To-Be で大事なのは、全部移すことではありません。
何を残し、何を移し、何をやめるかを決めること が中心です。
押さえておきたいのは、次の4点です。
ここまで描けると、次のフェーズで 誰がどう使うか を決めやすくなります。
To-Be は理想のツール画面を描くことじゃなくて、仕事がどう回る状態を目指すかを決めることなんですね。
その通りじゃ。そこが決まれば、次の運用設計もかなり現実的になるぞ。
千葉県出身。10歳の頃からプログラミングを始め、ゲーム、Webサイト、ロボット、スマホアプリなどを制作。大阪大学基礎工学部情報科学科で情報工学と統計学を学び、大学時代はAIを研究。大学在学中にWeb広告代理店でのインターンや人材系Webサービスの立ち上げを経験し、卒業後はフリーランスエンジニアとしてGISシステム、データ基盤構築、Webシステムの開発に従事。10年以上のWebアプリ開発・データ分析経験を基に、2023年9月に株式会社ビットライトを設立し、現場業務の仕組み化からデータ基盤構築、データ活用支援までを一気通貫で支援。