· シン · column · 8 min read
システムの集計結果が合わない!原因を特定する「分解思考」の3ステップ
新システム導入直後のトラブルシューティング。システム出力と手計算の差異を見つけるための「入力・処理・出力」に分解するアプローチについて解説します。

こんにちは、e-Shikumi-Laboの シン です。 このブログでは、ツールの使い方といった自動化のTipsだけでなく、日々の現場での気づきから得た「仕組み化思考」についても公開しています。
最近、外部から業務のサポートとして関わっている現場で、新しく導入されたシステムの運用が始まりました。導入直後ということもあり、出力される結果を慎重に検証するフェーズにあります。
そんな中、システムの出力した集計結果と、検証用にExcelで手計算した結果との間に差異が確認されました。新システムの導入直後に、このようにシステム出力と手計算の結果を突き合わせて差を確認することは、運用の安定性を担保するために必須のプロセスです。
実はこの現場で、私はシステム導入に伴う各種設定作業を一手に引き受けていました。さらに、検証用のExcel集計ツールの整備も自分で行っていたため、そのシステムがどんな「入力」と「処理」を経て「出力」されるのか、構造はすべて把握している状態でした。
しかし、それでも原因を特定して一致させるまでに、出力結果を突き合わせながら2時間弱の試行錯誤を要することになりました。
今回は、このようにシステムやツールでエラーが発生した際、どのように原因を特定していくべきか、その確認手順を整理してお話しします。
原因を絞り込むための3つのステップ
結果が合わないとき、漠然とデータを見つめていても解決には向かいません。業務をシンプルに切り分ける「仕組み化思考」を使って、以下の順序でアプローチしていきます。
① エラー箇所をできるだけ細かい粒度で見つける
「集計結果が合わない」という事実だけで思考を止めてしまっては、何も前に進みません。まずは、集計結果のどの部分で計算が狂っているのかを特定します。
切り分けられる最小の単位(日付、拠点、担当者など)まで分解し、どこまでは合っていて、どこからがおかしいのかを確認します。この粒度が細かければ細かいほど、その後の確認作業の手数を減らすことができます。
② その出力を作るための「処理」を確認する
エラーの発生箇所が絞り込めたら、次はそこに至る計算プロセス(処理)を検証します。
- どのような計算式が裏で動いているか
- どのような条件分岐(ルール)が適用されているか
システムの挙動をただ眺めるのではなく、必要に応じてExcelやスプレッドシートで同じ処理を手計算し、ロジックに破綻がないかを確認します。
③ その処理を行うための「入力」を確認する
処理のロジックに問題がなければ、最後に元データ(入力)を疑います。
- 使用している入力データそのものは正しいか
- システム側に設定されている「固定値(定数)」などに誤りはないか
- 入力された値にエラーや不備が含まれていないか
原因の特定と「仕組みを把握していること」の意義
今回のトラブルでも、この手順に沿って原因を調査しました。その結果、原因は「入力」フェーズにおける、とある項目の設定間違いによる集計エラーだと判明しました。
システムの構造(入力・処理・出力)をすべて理解している私であっても、原因の特定には2時間弱の試行錯誤が必要でした。しかし、この試行錯誤を成立させ、最終的に自己解決できたのは、事前に「処理内容を完全に把握し、手計算で検証できる状態」を作っていたからです。もし中身が分からないブラックボックスのシステムであれば、原因にすら辿り着けなかったはずです。
今回のシステムは、複数の社員の方々が利用するものです。どんなに優れたシステムであっても、人間の手による入力には、どうしてもミスやばらつきがつきものです。理想を言えば、おかしなデータが入力された時点でシステム側でエラーを弾く仕組み(入力チェック)がガチガチに組まれているべきですが、運用の初期フェーズや予算・リソースの兼ね合いから、そこまで手が回らないケースも少なくありません。
だからこそ、現場の運用でトラブルが起きたとき、システムに振り回されるのではなく、自ら「入力・処理・出力」に分解して原因を突き止められる実力を持っておくことが重要なのだと改めて感じます。
みなさんも、手元のツールやシステムで「計算が合わない」という事態に直面した際は、ぜひ一度、限界まで粒度を細かくして「入力」と「処理」を切り分けるアプローチを試してみてください。



