現場のExcelから、全社の管理システムを作り直す

全社システムを作っても、なぜExcelが残るのか

全社で共通のシステムを導入しても、担当者は手元のExcelで計算し、出来上がった数字だけを入力する。その使い方では、本社が期待した作業の効率化や計算の統一が進まないことがあります。

この論文が注目するのは、現場の担当者が自分たちの仕事のために作る会計・管理の仕組み（vernacular accounting systems：VAS）です。そこには、どの情報を使い、どの例外を調整し、どんな前提で数字を作るかという業務の知識が入っています。

問われるのは、そうした仕組みが残る理由と、その知識を全社の仕組みの設計にどう生かせるかです。事例では、現場のExcelを実際に見せて比較することが、開発側の理解と設計の変更につながりました。

著者らがいう現場を支える仕組み（enabling system）は、担当者が仕事の論理を理解し、状況に応じて修正しながら課題へ対処できる仕組みです。全社共通であることと、現場で役立つことを両立させるために、何を共通化し、何を現場で変えられるようにするかが問題になります。

財務予測システムの開発を27か月追った研究

対象は、多国籍ソフトウェア企業ToolCoです。社名は仮名で、販売部門は国・地域ごと、開発部門は製品分野ごとに仕事を組み立てています。約500人の管理会計担当者が、四半期と年間の財務見通しを作る業務に関わっていました。

研究者は2012–2014年の27か月間、全社共通の予測システムを開発する過程を調べました。予備調査に続く本調査では、開発チームと各地域・部門の担当者32人を対象に、聞き取り、仕事をそばで追う観察、試作品のテストや会議、内部資料を組み合わせています。

研究の焦点は、完成後のシステムの優劣を比較することではありません。提案、試用、不満の表明、設計変更がどう連なったかを、開発側と利用側の両方から追うことにあります。

最初の話し合いでは、仕事の違いが小さく見えた

本社は、各拠点が個別に計算する負担を減らし、予測を集める作業を速くしたいと考えていました。費用や売上の予測式を標準化すれば、結果だけでなく計算の論理も共通のデータベースに入り、拠点間の比較や経営の分析にも使えます。

開発チームは当初から現場参加を重視していました。ただし、最初のワークショップに集めたのは、主に本社に近い地域の担当者でした。人員数と売上のどちらを費用予測の基礎にするか、といった抽象的な水準で議論したため、仕事にはかなり共通点があるように見えました。

その時点では、算式の細かな指定や、事業の変化に合わせてどれほど頻繁に式を変えるかは十分に話し合われていません。会議で合意できたことと、仕事を同じ方法で再現できることの間に差が残っていました。

本物のデータを入れると、裁量の必要性が見えた

次の試用では、より広い地域の担当者が、動く試作品を使って直近の予測を再現しました。技術的な不具合に加え、計算できた部分でも、自分たちのExcelと値が大きく違うことが分かります。

例えば、過去の値の引継ぎや一定期間の平均では、季節性や組織再編の影響を十分に取り込めません。出張費を人数から予測するのが合う職場もあれば、売上との関係から考える職場もあります。同じソフトウェア販売でも、国ごとに異なるロイヤルティ率を算式へ入れる必要がありました。

担当者にとって、計算式を作る仕事は、事業の変化を理解する過程でもありました。実績との差を見て営業や開発の同僚に理由を聞き、見通しを直します。計算を自動化する際、何を考え直す機会と権限が残るかが、システムへの評価を左右したのです。

また、予測精度は正式な業績指標ではなくても、現場の上司からの信用に関わっていました。結果には責任を持つのに、その数字の作り方を修正できないことへの懸念がありました。

現場の計算表が果たした三つの役割

著者らは、Excelが開発過程で果たした働きを三つに整理しています。単にファイルを回収するだけでなく、誰が何を説明するために使ったかが重要です。

開発側は、計算表を見ながら説明を受けることで、それまで一般的な要望と受け取っていた話が、業務上の条件に根差していると理解しました。現場の知識は、説明されるだけでなく、一部が新機能の具体的なひな型にもなっています。

共通の枠の中で、算式を組み合わせられるようにする

開発側が取り組んだのは、標準化と裁量の折り合いです。一つの式を全社に強制すると適合しない場面が残り、何でも自由にすると仕組みが複雑になります。両極のどちらでも、使われない可能性がありました。

そこで、現場の提案を受け、費用や売上の変化を説明する要因、計算の基になる期間、増加率などを選んで組み合わせる方向へ進みました。共通の部品を使いながら、各担当者が自分の業務に合う算式を作り、事業の変化に応じて修正できるようにする考え方です。

この変更を後押ししたのは、本社側の依存関係でした。現場がExcelで計算を続け、結果だけを入力すれば、計算の論理まで統合する目的は達成できません。現場の協力が必要だったからこそ、異論が設計を変える力になったと読めます。

本社も、現場の事情を知る利益を得ます。最終的な金額だけでは分からない前提や変化の要因が、共通の枠に入るためです。この事例では、現場の裁量を認めることと、全社から計算の論理を把握しやすくすることを、同時に目指していました。

サステナビリティの情報整備へ、どう応用するか

ここからは本記事による応用です。環境データや資源循環の情報を全社で集める際も、入力欄の統一だけでは、数値の作り方まで共有できるとは限りません。現場の管理表には、工程変更、計量の条件、例外処理などの知識が残っている可能性があります。

試すなら、担当者に完成形の要望を聞くだけでなく、直近の一か月など、実際に処理した仕事を新旧の仕組みで再現してもらいます。どの情報を探し、どこで計算を直し、誰に理由を尋ねたかを一緒に確認します。

そのうえで、全社でそろえる定義と、事情に応じて修正する項目を区別できます。担当者が持つ修正権限と、変更理由を他者へ説明する仕組みも検討対象です。入力できるかに加え、その情報を使って仕事を判断できるかを見ることが、論文から得られる視点です。

現場参加だけで成功した、と読まない

この研究は、一つの企業の開発過程を追ったものです。開発側が現場の知識を取り込もうとしており、現場にはExcelを使い続ける選択肢がありました。こうした条件がない場面でも、同じ交渉が成立するとはいえません。

さらに、著者らは、新システムが実際の仕事でどう使われたかまでは観察できなかったと明記しています。協力者が役立ちそうだと評価したことと、導入後に精度や効率が改善し、利用が定着したことは区別する必要があります。

現場の表をすべて残すべきだという結論でもありません。論文が示すのは、既存の仕事の知識を見える形で持ち寄り、新しい仕組みの条件を交渉できる可能性です。

原著は、試作品の前後を比べて読む

まず研究方法で企業の構造と協力者の範囲を確認し、結果の冒頭にある全社側と現場側の期待を比べます。次に、抽象的なワークショップ、実データによる試用、算式の修正という順番を追うと、意見が変わった理由が分かります。

三つの役割を詳しく論じる部分では、Excelを見せる行為が、説明の具体化と交渉力の両方に働いたことに注目してください。WoutersとWilderomの指標開発の論文と合わせると、現場参加を、参加者の人数に加え、何の知識が設計へ移ったかから評価できます。