FileMakerエンジニア
FileMaker（ファイルメーカー）で構築した業務システムを長く運用していると、こんなお問い合わせをいただくことがあります。
「請求書の合計金額が、なぜか思っていた数字と違う」
「特定の条件のときだけ、金額がずれているような気がする」
システム自体は問題なく動いているように見えるのに、ある条件のときだけ数字が合わない——。
これは、計算式そのものは正しく組まれていても、ごくわずかな書き方の違いによって意図しない挙動を起こしてしまう、FileMaker特有の落とし穴によるものです。
株式会社ブリエでは、保守運用の中でこうした「見えないバグ」を発見し、原因を突き止めて修正した事例があります。
本記事では、その具体的な調査プロセスをご紹介します。
目次
特定の条件でだけ金額がずれる
今回ご相談いただいたのは、請求書を発行する業務システムをFileMakerで運用しているA社様です。
A社様のシステムは、もともと弊社が新規開発したものではなく、他社が構築したデータベースを保守フェーズから引き継がせていただいたものでした。
こうした「他社構築システムの引き継ぎ保守」では、設計者の意図が資料に残っていないことも多く、計算式の一つひとつを読み解きながら把握していく作業が欠かせません。
今回の不具合も、まさにそうした引き継ぎ後の保守運用の中で発覚したものです。
A社様のシステムでは、取引の内容に応じて「課税」「非課税」など複数の区分を計算式で自動判定し、請求書の合計金額に反映する仕組みになっていました。
通常の取引では特に問題は起きていませんでしたが、「非課税のみの取引」という特定の条件が揃ったときにだけ、本来の金額より大きい金額が請求書に表示されてしまうという現象が報告されました。
例えば、本来であれば非課税分の合計として53万円台の金額が表示されるべきところ、実際には消費税相当額が上乗せされた58万円台の金額になってしまう、といった具合です。
差額自体は一取引あたり数万円程度ですが、非課税取引が発生するたびに同じズレが繰り返し起きてしまう点が問題でした。
厄介なのは、システムの見た目上はどこにもエラーが出ておらず、多くの取引では正しい金額が表示され続けていたことです。
「一部の条件でだけ再現する不具合」は、気づかれにくく、原因の切り分けにも手間がかかります。
原因は「論理演算」の想定が「算術演算」
調査の結果、原因は合計金額を算出する計算式の中にある、ごく小さな判定式の書き方にありました。
この計算式には、「内訳とする項目がすべて空欄かどうか」を判定する部分があり、本来は「すべて空欄であること」をかつ（AND）条件で連結する必要がありました。
ところが実際の式では、連結する記号の一部に、論理演算子のかつ（AND）ではなく算術演算子の＋（プラス）が混入していました。
FileMakerに限らず多くの言語では、算術演算子は論理演算子よりも先に評価される決まりになっています。
そのため、書き手が意図した「すべて空欄なら真」という判定ではなく、「一部の項目の判定結果同士を足し算する」という、まったく別の計算が行われてしまっていたのです。
その結果、「非課税の項目にだけ値が入っている」という、本来は「空欄ではない」と判定されるべきケースでも、内部的には「空欄である」という判定されていました。
これにより、税区分ごとの内訳が存在しなかった頃の、「税込金額をそのまま参照する」という古い仕様にフォールバックしてしまう現象が起きていました。
これが、非課税の取引でだけ消費税相当額が上乗せされた金額が表示されていた真因です。
計算式自体は「一見すると正しく書かれているように見える」ため、目視だけで気づくのは容易ではありません。
実際のデータを使って計算式の評価結果を一つずつ検証することで、この演算子の混入をようやく特定することができました。
他にも潜んでいないか計算式の横断チェック
原因を特定して修正するだけでは、保守運用としては不十分です。
同じ書き方の間違いが、システム内の他の計算式にも紛れ込んでいないとは限らないためです。
そこで、システム全体の計算式・自動入力計算式を横断的に検索し、「複数の空欄判定をかつ（AND）で連結している箇所」を洗い出した上で、今回と同じパターンの誤りがないかを一件ずつ確認しました。
その結果、他の計算式では同様の混入は見つからず、今回の1箇所に限定された問題であることを確認しています。
なお、今回の合計金額を算出する項目は「値を保存しない」設定の計算フィールドでした。
そのため、計算式を修正した時点で、過去に登録されていた取引データの表示金額も自動的に是正されています。
個別のデータ修正やシステムの再構築を行うことなく、根本原因の修正だけで解決できたことも、今回のポイントです。
まとめ
「動いているように見えるのに、特定の条件でだけ数字が合わない」というトラブルは、計算式そのものに明確な誤りがあるとは限らず、演算子の優先順位のようなごく小さな書き方の違いが原因になっていることがあります。
今回の対応で押さえておきたいポイントは、次の3つです。
見えにくい不具合ほど、条件の切り分けが重要
特定の条件でだけ再現する不具合は、多くの取引では正しく動いてしまうため見過ごされがちです。再現条件を一つずつ絞り込む地道な検証が、原因特定の近道になります。
原因は「演算子の優先順位」という、ごく小さな書き方の違い
論理演算子のつもりで書いた記号が算術演算子になっていたことで、判定の意味そのものが変わってしまっていました。計算式は「動いているから正しい」とは限りません。修正後は、同じ間違いが他に潜んでいないか横断チェック
1箇所を直して終わりにせず、システム全体で同様のパターンがないかを確認することが、長く安心して使い続けられるシステムには欠かせません。
特に、他社が構築したシステムを引き継いで保守する場合、設計の意図が資料として残っていないケースも少なくありません。
株式会社ブリエでは、こうした引き継ぎ保守の案件においても、計算式を一つひとつ丁寧に読み解きながら、「気づきにくい不具合」の発見・修正に力を入れています。
「今使っているシステムは他社が作ったものだけれど、保守を任せられる先を探している」「システムは動いているはずなのに、なぜか数字が合わない」といったお悩みがあれば、ぜひお気軽にご相談ください。
株式会社ブリエのプロジェクトマネージャー。将来的な可能性やリスクを考慮した幅広い視野を持ち、最適な選択肢を提案できるプロフェッショナル。FileMakerをはじめとするローコード開発に精通し、豊富な専門知識を活かして顧客に最善のサービスを提供する。常に冷静で的確な判断を下し、複雑な問題に対しても高度な分析力で解決策を導き出す。
