脱Excelの判断フロー: サインが出た後、何をシステム化して何を残すか

「Excel台帳の限界サイン」をチェックしてみたら、7つのうち5つも当てはまってしまった。もう様子見できる段階ではなさそうだ。そこまでは分かった。ですが次に頭をよぎるのは、「では全部の台帳をシステム化するのか」という問いです。経理も、在庫も、案件管理も、備品台帳も、社内にあるExcelファイルを一つずつ思い浮かべると、その数の多さに気が遠くなります。予算も時間も限られている中で、本当にすべてをシステムに置き換える必要があるのか。かといって、危険度が高いと分かった台帳を放置しておくわけにもいかない。「何から手をつければいいのか分からない」という新しい迷いが生まれている状態ではないでしょうか。

この記事は、危険度チェックによって「自社は脱Excelに動くべき段階にある」と判断できたものの、社内にある業務すべてを一気にシステム化するのは現実的ではないと感じており、何をシステム化し、何をExcelのまま残すのかを判断するための具体的な手順がほしい担当者に向けて書きました。情報システム部門の専門教育を受けておらず、総務や経理と兼任でシステム管理を担っている方を想定しています。専門用語は初出時に言い換え、判断の順番を中心に整理します。

この記事で分かること

結論を先に言うと、脱Excelは「全部システム化する」か「全部Excelのまま残す」かの二択ではありません。社内にある業務・台帳を洗い出したうえで、影響度とリスクの2つの軸で優先順位をつけ、システム化する範囲・当面Excelのまま残す範囲・様子を見ながら決める範囲の3つに仕分けていく作業です。

この記事では、次の流れで解説します。

• なぜ「全部システム化」を目指すと途中で止まるのか
• 判断フローの全体像(4つのステップ)
• ステップ1: 社内の台帳・業務を洗い出す
• ステップ2: 影響度とリスクの2軸で仕分ける
• ステップ3: システム化する範囲を決める判断基準
• ステップ4: Excelのまま残す範囲を決める判断基準
• グレーゾーンの扱い方と、判断に迷ったときの考え方
• 実際にどこから着手すればよいか

それぞれについて、順を追って見ていきます。

なぜ「全部システム化」を目指すと途中で止まるのか

結論から言うと、社内のExcel業務をすべて一度にシステム化しようとする計画は、実務ではほぼ確実に途中で止まります。理由は単純で、対象範囲を広げるほど、必要な予算・時間・関係部署の合意形成の負担が線形以上に膨らんでいくからです。

危険度チェックで複数のサインに当てはまった担当者ほど、「これを機に社内のExcelを全部見直そう」という意欲を持ちやすくなります。その意欲自体は正しい方向を向いています。ただし、意欲のまま「全社の台帳を棚卸しして、全部を新しいシステムに移行する」という計画を立ててしまうと、次のような壁にぶつかりやすくなります。

• 予算の壁: 対象範囲が広がるほど見積もりも大きくなり、稟議で承認を得るハードルが上がる
• 要件整理の壁: 部署ごとに業務のやり方が微妙に異なり、全部を1つのシステムに合わせようとすると要件が発散する
• 合意形成の壁: 関係部署が増えるほど、それぞれの都合や優先順位の違いを調整する時間が必要になる
• 並行運用の壁: 移行期間中は旧Excelと新システムを並行して使う必要があり、対象が多いほど混乱の期間が長引く

ある小売業の総務担当者は、危険度チェックで在庫・案件・経費精算の3つの台帳がいずれも危険水域だと分かり、「まとめて新しい基幹システムに移行しよう」と計画を立てました。しかし部署ごとの要件のすり合わせに半年以上かかり、途中で予算超過が発覚してプロジェクトが凍結してしまいました。結果として、最も危険度が高かった在庫台帳の改善すら手つかずのまま、元のExcel運用に逆戻りしています。

この失敗パターンに共通するのは、「危険度が高いと分かった台帳が複数ある」という事実と、「それらを同時に、同じ方法で解決すべきだ」という判断を、無意識に結びつけてしまっている点です。危険度が高い台帳が複数あっても、それぞれの性質が違えば、システム化すべきタイミングも、システム化の方法も異なります。この記事で扱う判断フローは、この結びつきを一度切り離し、台帳ごとに個別の判断を下していくための手順です。

判断フローの全体像

脱Excelの判断は、次の4つのステップで進めます。全体像を先に示すと、次のような流れです。

1. 洗い出す: 社内にあるExcel台帳・業務を一覧化する
2. 仕分ける: 影響度とリスクの2軸で、それぞれの台帳を4つの領域に分類する
3. システム化の判断: 優先度が高い領域から、システム化するかどうかを判断する
4. 残す判断: システム化しないと決めた領域を、どう安全に運用し続けるかを決める

重要なのは、このフローが「1回きりの意思決定」ではなく、「対象ごとに繰り返す作業」だという点です。台帳Aについてはシステム化、台帳Bについては当面Excelのまま安全運用、台帳Cについては半年後に再判断、というように、台帳ごとに異なる結論が出ることが正常な結果です。すべての台帳に同じ結論を出そうとすると、かえって判断を誤ります。

以下、各ステップを順に見ていきます。

ステップ1: 社内の台帳・業務を洗い出す

判断の出発点は、対象を漏れなく洗い出すことです。危険度チェックは特定の1台帳を想定して作られていますが、実際には部署ごとに複数の台帳が存在しているケースがほとんどです。まずは次の観点で、社内にあるExcelベースの業務を書き出してください。

• 経理・財務系: 請求書管理、経費精算、支払管理、予算実績管理
• 人事・労務系: 勤怠集計の補助、有給休暇管理、備品貸与台帳
• 営業・案件系: 顧客リスト、案件進捗管理、見積・受注管理
• 在庫・購買系: 在庫台帳、発注管理、仕入先マスタ
• 総務・情報システム系: システム管理台帳、資産台帳、契約更新管理

この段階では、危険度の高低は気にせず、まず「存在する」という事実だけを列挙することが重要です。危険度が低そうだからと最初から除外してしまうと、後のステップで見落としが発生します。書き出す際は、Excelファイルそのものだけでなく、それを操作する業務プロセス(誰が、いつ、何のために触っているか)まで含めて把握しておくと、後の判断がしやすくなります。

洗い出しがひとりでは難しい場合は、各部署に「日常的に使っているExcelファイルを教えてほしい」と簡単なヒアリングをかけるだけでも、かなりの数が集まります。総務や経理と兼任している担当者であれば、自分の管轄範囲だけでも構いません。全社を一度にカバーしようとせず、自分の目が届く範囲から始めることをおすすめします。

洗い出しの粒度にも注意が必要です。「営業部の顧客管理」のように大きな単位でまとめてしまうと、実際には性質の異なる複数の台帳(見込み客リスト、既存顧客の契約情報、クレーム対応履歴など)が1つに混ざったまま次のステップに進んでしまい、後の仕分けが不正確になります。ファイル単位、あるいは「同じ人が同じ目的で更新している一かたまりのデータ」を基準に分けて書き出すと、次のステップでの評価がしやすくなります。

• 良い粒度の例: 「見込み客リスト.xlsx」「既存顧客契約管理.xlsx」「クレーム対応履歴.xlsx」と分けて洗い出す
• 粗すぎる粒度の例: 「営業部の顧客管理まわり」とひとまとめにしてしまう

粒度を分けて書き出す作業自体に時間がかかる場合は、まず粗い単位でリストアップしておき、次のステップで評価に迷った項目だけを後から分解する、という進め方でも構いません。完璧な粒度分けを最初から目指す必要はなく、判断に支障が出ない程度に分かれていれば十分です。

ステップ2: 影響度とリスクの2軸で仕分ける

洗い出した台帳・業務を、次の2つの軸で評価します。

• 影響度: その台帳に問題が起きたとき、業務や経営にどれだけの影響が出るか(金額の大きさ、関係する取引先の数、法令・契約上の重要性など)
• リスク: 危険度チェックで確認したような、属人化・同時編集事故・データ破損といった「事故が起きる可能性」の高さ

この2軸を掛け合わせると、次の4つの領域に分類できます。

危険度チェックで「危険水域」と判定された台帳の多くは、このA領域かC領域に該当します。同じ「危険」という判定であっても、影響度が高いA領域と、影響度が相対的に低いC領域とでは、次に取るべき対応が変わってきます。A領域は本格的なシステム化の検討対象になりますが、C領域は必ずしもシステム化を急ぐ必要はなく、まずは運用ルールの見直しで対応できる場合が多くあります。

実務上の視点: 影響度とリスクを評価する際、システム担当者ひとりの感覚だけで点数をつけると、自分がよく知っている業務の影響度を過大評価し、逆に馴染みのない部署の業務を過小評価してしまうことがあります。可能であれば、各部署の担当者に「この台帳が使えなくなったら、どれくらい困るか」を簡単にヒアリングし、その回答を踏まえて評価することをおすすめします。

ステップ3: システム化する範囲を決める判断基準

A領域(影響度・リスクともに高い)に分類された台帳は、システム化の検討対象になります。ただし、A領域に入ったからといって、即座に大規模なシステム開発に踏み切る必要はありません。次の基準で、システム化の必要性と緊急度をさらに絞り込みます。

システム化を優先すべきサイン

• 複数人・複数部署が同じデータを参照・更新する必要がある(同時編集の需要が構造的にある)
• 金額や個人情報など、誤りが直接の損失や法令違反につながるデータを扱っている
• 属人化が進んでおり、担当者の異動・退職が具体的に予定されている、あるいはすでに発生している
• 取引先や顧客など、社外に影響が及ぶ業務である

これらのサインに複数当てはまる台帳は、優先的にシステム化を検討すべき対象です。一方で、システム化の方法についても選択肢を検討する余地があります。すべてをベンダーロックインのリスクを抱えるフルスクラッチ開発に頼る必要はなく、ノーコード・ローコードツールで十分に要件を満たせる場合も少なくありません。業務の複雑さや将来の拡張性の見込みに応じて、この記事の関連記事で扱っているノーコードツールとフルスクラッチ開発のどちらが適しているかを、次の段階で個別に判断してください。

大切なのは、「システム化する」という決定と「どうシステム化するか」という決定を分けて考えることです。前者はこの記事で扱う判断フローの範囲、後者はツール選定や外注の話になります。この2つを一度に決めようとすると、検討が重くなり、着手そのものが遅れる原因になります。

システム化の緊急度を判断する目安

すべてのA領域が同じ緊急度とは限りません。次の表は、緊急度を大まかに見積もる際の目安です。

緊急度が高いと分かった台帳については、本格的なシステム開発を待つ余裕がない場合もあります。その際は、次のステップで紹介する軽量な対策(共同編集機能への切り替えなど)を先に実施し、時間を稼ぎながら本格的な検討を並行して進めるという順番も現実的な選択肢です。

システム化にかかる費用感の目安

システム化を検討する段階になると、必ず出てくるのが「結局いくらかかるのか」という疑問です。ここでは方式ごとの大まかな費用レンジを示しますが、実際の金額は台帳の複雑さ・連携先の有無・利用人数によって大きく変わるため、あくまで検討の出発点としてご覧ください。

A領域(影響度・リスクともに高い)に分類された台帳であっても、この3方式のどれを選ぶかによって、必要な予算は一桁以上変わってきます。ノーコードツールで解決できる範囲を見極められれば、限られた予算の中でA領域の複数の台帳に対応できる可能性が広がります。kintoneでの置き換えを具体的に検討する場合の手順・費用感はkintoneでExcel台帳を置き換える手順と費用感、より本格的なWebシステム化を検討する場合はExcel台帳をそのままWebシステム化するといくらかかる？で詳しく解説しています。

ステップ4: Excelのまま残す範囲を決める判断基準

B・C・D領域に分類された台帳は、当面Excelのまま運用を続ける選択肢が現実的です。ただし、「システム化しない」という判断は「何もしない」という判断とは異なります。特にC領域(影響度は低いがリスクは高い)については、システム化はせずとも、運用面での対策でリスクを下げておく必要があります。

Excelのまま残すと判断した台帳については、次のような軽量な対策を検討してください。

• 同時編集事故が起きているなら: OneDriveやSharePointの共同編集機能への切り替えで、大きな投資なしに解消できる場合がある
• 属人化した関数・マクロがあるなら: 中身を解読して文書化し、担当者が変わっても引き継げる状態にしておく
• 表記ゆれ・重複が心配なら: 定期的なデータクレンジングのルールを決めておく
• 管理台帳自体の存在を忘れないように: システム管理台帳に台帳の名前・用途・管理者を記録しておく

これらの対策は、いずれもシステム開発のような大きな予算を必要とせず、比較的短期間で実行できます。B・C・D領域の台帳にまで手を広げてシステム化しようとすると、冒頭で述べた「全部システム化しようとして途中で止まる」失敗パターンに逆戻りしてしまいます。優先度の低い領域は、優先度の高い領域のシステム化にリソースを集中させるためにも、意識的に「今はこのままでよい」と判断することが大切です。

ある製造業の情報システム担当者は、危険度チェックで危険水域と判定された5つの台帳のうち、影響度が特に高い受注管理台帳1つだけをシステム化の対象に選びました。残り4つについては、共同編集機能への切り替えと管理台帳への記録のみで当面をしのぐ方針にしたところ、限られた予算と時間を1つの案件に集中させることができ、半年後には受注管理のシステム化を完了できたといいます。

一方で、「残す」という判断を軽視した結果、後になって困るケースもあります。ある卸売業の担当者は、影響度が低いと判断して備品貸与台帳をExcelのまま放置していましたが、その台帳を管理していた担当者が突然退職し、誰がどの備品を借りているのか分からなくなってしまいました。金額的な影響度は小さくても、「担当者が急にいなくなる」というリスクだけは事前に手当てしておくべきだった、という反省が残ったといいます。この例が示すとおり、「残す」と決めた台帳であっても、システム管理台帳への記録と、最低限の引き継ぎ情報の整備は省略しないことをおすすめします。影響度の低さは「何もしなくてよい」ことを意味せず、「大きな投資はしなくてよい」ことを意味するに過ぎません。

グレーゾーンの扱い方と、判断に迷ったときの考え方

実際にステップ2の仕分けを行うと、A領域ともB・C領域とも言い切れない、判断に迷う台帳が必ず出てきます。ここでは、そうしたグレーゾーンをどう扱うかを整理します。

迷ったときの原則

1. 今すぐ結論を出さず、期限付きで「保留」にする: 3ヶ月後・半年後など具体的な再検討時期を決め、それまでは様子見にする
2. 小さく試してから判断する: いきなり本格的なシステム化を決めず、PoC（概念実証）的に無料のノーコードツールで一部業務だけを試してみる
3. 影響度を過大評価していないか疑う: 「もし何か起きたら大変だ」という不安だけで影響度を高く見積もっていないか、具体的な発生確率や過去の事故実績と照らし合わせる
4. リスクを過小評価していないか疑う: 「今のところ問題は起きていない」という現状維持バイアスに引きずられていないか、担当者の異動予定など将来のリスクも含めて再確認する

判断に迷う最大の原因は、多くの場合、影響度とリスクの評価に使える情報が不足していることです。情報が足りないまま無理に白黒つけようとせず、「今は保留にして、次の四半期にもう一度評価する」という選択肢を積極的に使ってください。脱Excelの判断は一度きりのイベントではなく、定期的に見直す前提の継続的なプロセスです。

また、社内の合意形成という観点では、判断の根拠を数字や表で残しておくことも重要です。「なんとなくこっちを優先した」という説明では、後から予算の承認を求める際や、他の担当者に引き継ぐ際に、判断の妥当性を説明できません。ステップ2で作成した影響度・リスクの表は、そのまま社内説明の資料としても使えます。

実際にどこから着手すればよいか

判断フローの全体像を理解したところで、実際の着手順序を整理します。次の順番で進めることをおすすめします。

1. 洗い出しは1〜2週間で終わらせる: 完璧な一覧を目指さず、まず把握できる範囲から着手する
2. 仕分けはひとりで完結させず、各部署の意見を聞く: 特に影響度の評価は、システム担当者だけでは判断がつかないことが多い
3. A領域から着手し、B・C・D領域は並行して軽量な対策を進める: 全部を同時に進めようとしない
4. システム化する台帳が決まったら、方法(ノーコードかフルスクラッチか)を個別に検討する: この段階で初めてツール選定や外注の話に入る
5. 3ヶ月〜半年ごとに、この仕分けを見直す: 業務の変化や担当者の異動によって、領域の判定は変わっていく

最初のステップである「洗い出し」だけでも、社内のExcel運用の全体像が可視化され、それ自体が大きな一歩になります。危険度チェックで自社の危険度に気づいた今のタイミングは、この洗い出しに着手する良い機会です。すべてを一度に解決しようとせず、まずは対象を把握し、優先順位をつけるところから始めてください。

判断結果を記録するシートの項目例

判断フローを実行した結果は、口頭やメモだけで終わらせず、表の形で残しておくと、後から見直す際にも、社内で説明する際にも役立ちます。新しくツールを用意する必要はなく、Excel1枚で次のような項目を管理すれば十分です。

• 台帳名・業務名: ステップ1で洗い出した名称
• 管理部署・主担当者: 誰が日常的に更新しているか
• 影響度(高・中・低): ステップ2の評価結果
• リスク(高・中・低): ステップ2の評価結果
• 分類領域(A〜D): 2軸を掛け合わせた結果
• 結論: システム化を検討する/当面Excelのまま残す/保留(次回見直し)
• 次回見直し時期: 保留にした場合の再評価タイミング
• 備考: 判断の根拠となった具体的な事実(事故の発生頻度、異動予定など)

この記録は、システム管理台帳と役割が近いようで、実は少し目的が異なります。管理台帳が「何が存在するか」を記録するものであるのに対し、この記録シートは「それぞれについて、どう判断し、なぜその結論に至ったか」という意思決定の履歴を残すものです。両方を整備しておくと、担当者が交代した場合でも、後任者が過去の判断の経緯を追いやすくなります。

費用感だけを見て判断を誤った例

ある卸売業の担当者は、A領域に分類した在庫台帳について、ノーコードツールなら数万円で済むという情報だけを頼りに、詳細な要件確認をせずに契約を進めました。ところが実際には、既存の販売管理システムとの連携や、複数拠点間での在庫数のリアルタイム同期という要件があり、標準的なノーコードツールの機能だけでは対応しきれないことが契約後に判明。結局、追加のカスタム開発費用が発生し、最終的な総額は当初想定していたスクラッチ開発の見積もりとほぼ同水準になってしまいました。

この事例が示すのは、「費用レンジの安さ」だけで方式を選ぶのではなく、まず自社の台帳が持つ要件(連携先の有無、リアルタイム性の要否、利用人数など)を洗い出したうえで、その要件を満たせる方式の中から費用を比較する、という順番の大切さです。安さを最初の判断基準にしてしまうと、この卸売業の例のように、結果的に遠回りになることがあります。

まとめ

脱Excelは「全部システム化する」か「全部残す」かの二択ではなく、社内の台帳・業務を洗い出し、影響度とリスクの2軸で仕分けたうえで、対象ごとに個別の判断を下していく作業です。危険度チェックで「動くべきだ」と分かった今だからこそ、意欲のままに全範囲を一度に動かそうとせず、この記事の4ステップに沿って優先順位をつけてください。影響度・リスクともに高い領域から着手し、それ以外の領域は軽量な運用対策でリスクを抑えながら、次の見直しのタイミングを待つ。この進め方が、限られた予算と時間の中で、脱Excelを最後までやり切るための現実的な道筋です。

システム化する範囲が決まったら、次はその実現方法を検討する段階に進みます。フルスクラッチ開発ほどの予算や時間をかけられない場合は、ノーコードツールでの置き換えが選択肢になります。関連記事では、主要ノーコードツールの性質比較と選び方を扱っていますので、あわせて参考にしてください。