COUNTIFとCOUNTIFSで条件付き個数を賢く集計！複数条件ANDやORも自在に使いこなすエラー解消術

締切が近いのに、COUNTIFやCOUNTIFSで思った件数が出ず、同じ検索を何度も繰り返していませんか。単一条件を数えるのがCOUNTIF、複数の条件をすべて満たす件数を一気に集計するのがCOUNTIFSという機能レベルの違いは、すでに多くの解説で語られています。しかし実務で詰まる本質は、関数そのものではなく「どの条件をどう組み合わせて数えるか」という設計と、ANDとORの扱い、型ズレや範囲不一致といった静かなミスです。

本記事では、COUNTIFとCOUNTIFSの守備範囲をまず整理し、以上・以下・空白以外・文字列・日付といった現場頻出パターンをそのまま使える形で提示します。そのうえで、売上や成績、勤怠、アンケートを題材に、複数条件のANDを安全に設計し、OR条件や複数範囲を合算で捉える実務ロジックまで踏み込んで解説します。さらに「うまくいかない」原因を潰すチェックリストと、COUNTAやSUMIFS、FILTERとの役割分担、スプレッドシートやAIツールへの展開まで一気通貫で押さえます。

この数十分を投資すれば、今日の集計が片付くだけでなく、明日以降「COUNTIFで迷子になる時間」そのものを削減できます。条件付き個数の扱い方をここで固めておかないことが、これからの業務効率にとって最大の損失になります。

もう迷わないCOUNTIFとCOUNTIFSの違いと条件付き個数の“守備範囲”を一気に整理しよう

締切前に「どっちの関数だったっけ…」と検索ループにハマると、一気に仕事のリズムが崩れます。ここでは、現場で迷いをゼロにするために、条件付きカウントの守備範囲を一気に整理します。

COUNTIFとCOUNTIFSの構文と特徴をサクッと整理して、モヤモヤを一掃しよう

まずは、現場で本当に使うポイントだけを押さえます。

数式の見た目より大事なのは、「この集計は、条件が1つなのか、複数を同時に絞り込むのか」を先に決めることです。ここを曖昧にしたまま関数を選ぶと、あとからロジックの説明ができなくなります。

どの条件でどちらを使うか迷わない現場ルール

営業企画やバックオフィスで迷いやすい場面は、次の3パターンに集約できます。

• 単発条件ならCOUNTIF

  • 例：売上金額が10万円以上の件数
  • 例：評価が「A」の人数

• 複数条件のANDならCOUNTIFS

  • 例：「東京支店」かつ「担当A」かつ「受注」の件数
  • 例：「60点以上かつ80点未満」の人数

• OR条件が混ざるときは分解して設計

  • 例：「東京または大阪」の件数
    • COUNTIFを2本足して合計、もしくは条件列を作ってからCOUNTIFS

ポイントは、最初に「ANDで絞るのか」「ORで足すのか」を紙に書き出すことです。関数を書く前にロジックを書ける人は、残業の量が目に見えて減ります。

COUNTAやCOUNTBLANKとの違いも押さえてカウント関数をまるごと武器にしよう

条件付きカウントを正しく選ぶためには、「そもそも条件がいらないカウント関数」との違いも押さえておく必要があります。

現場で多いトラブルは、本当は「未入力だけ」を数えたいのに、なんとなくCOUNTAを使ってしまうパターンです。
「何を条件にして数えるのか」を決めると、選ぶべき関数は自然と決まります。

• 「入力されているかどうか」だけ見たい → COUNTA / COUNTBLANK

• 「入力内容が条件を満たすか」まで見たい → COUNTIF / COUNTIFS

数字に振り回される表から、条件を意図的に設計した“しゃべる表”に変えられるかどうかは、この線引きができるかにかかっています。ここが整理できると、複数条件やOR条件の応用も一気にラクになります。

まずは単発条件を極めよう COUNTIFで「以上・以下・空白以外・文字列」を自在に数えるコツ

締切前に一発で“欲しい件数”を出せるかどうかは、この単発条件をどこまで体に染み込ませているかで決まります。ここを押さえれば、複数条件やAND・ORに進んだときの迷いが一気に減ります。

数値条件の基本「以上・以下・範囲指定」をCOUNTIFで書ければ集計が一気に楽になる

売上件数やテスト点数など、まず押さえたいのは数値条件です。よく使うパターンを整理すると、頭がスッキリします。

現場でミスしがちなのは、「80以上」と「80より大きい」を混同することです。社内で“80点ライン”という言葉が出たら、「80を含めるのか」を必ず確認し、関数の条件にそのまま反映させる意識が重要です。

空白と空白以外や「0ではない」「未入力だけ」など現場あるある条件のスマートな書き方

勤怠表やタスク管理では、数値よりも「入っているか・いないか」の判定が主役になります。

• 空白だけ数えたい: 未入力の案件数や、未対応チケットの把握

• 空白以外を数えたい: 申請済み・回答済みの件数

• 0ではない数だけ数えたい: 売上0円を除いた“動いた”案件数

ここで大事なのは、「空白」と「0」を別物として扱うことです。多くの現場で、0は「データはあるが結果がゼロ」、空白は「そもそも未集計・未対応」という意味を持ちます。この違いを意識せずにカウントすると、営業会議で「件数が合わない」原因になりやすいと感じています。

特定の文字を含む・含まない、複数の文字列パターンを拾い上げる実践テク

顧客属性やステータス管理では、文字列条件が主役になります。営業リストで「東京エリアだけ」「キャンペーン対象だけ」といった抽出を一瞬で行うには、次の3パターンを押さえておくと便利です。

• 特定の文字を含む: 住所に「東京」を含む顧客

• 特定の文字を含まない: ステータスが「解約」以外

• 複数パターンを拾う: 「Aプラン」と「Bプラン」の両方を合算

複数パターンを扱うときは、1つの関数で無理に全部を表現しようとせず、「Aプラン用」と「Bプラン用」を別々に作って合計する方が安全です。無理な一行完結を目指した数式ほど、引き継ぎ時にブラックボックス化しやすくなります。

条件セル参照や条件付き書式をCOUNTIFと組み合わせて“生きた表”を作ろう

単発条件をさらに使い回しやすくするコツが、条件セル参照と条件付き書式です。

• 条件を直接数式に書かず、「基準点」「締切日」「ターゲットエリア」などを別セルに置く

• そのセルを条件として参照し、数字や文字を変えるだけで集計結果が自動で変わる設計にする

• 条件を満たした行に色を付ける条件付き書式と連動させ、「どれがカウント対象か」を視覚的に確認する

この組み合わせを使うと、「今月だけ基準を70点から75点に上げたい」「来期は対象エリアを首都圏に広げたい」といった方針変更にも、数式を壊さず対応できます。単に個数を求める関数から、「チームで共有できるルールを埋め込んだツール」へ格上げする感覚で設計してみてください。

複数条件のANDを制する者が集計を制す COUNTIFSで売上・成績・勤怠を一発集計

「条件が3つを超えた瞬間に、急に自信がなくなる」──多くの人がここでつまずきます。ですが、複数条件のANDをパターンで押さえてしまえば、どんな業務データでも怖くありません。

COUNTIFS複数条件の書き方と「3つ以上・4つ以上」でも崩れないコツ

COUNTIFSの基本形は、条件範囲と条件のペアを縦に積み上げるだけです。

• =COUNTIFS(範囲1,条件1,範囲2,条件2,範囲3,条件3,…)

崩れないためのキモは、次の3点だけです。

• すべての条件範囲を同じ行数にする

• 条件を「1行1ルール」と決めて、紙に書き出してから数式にする

• 演算子とセル参照は & で結合する（例: “>=”&F2）

特に「3つ以上・4つ以上」の時は、数式をいきなり書かず、まずはこのような設計表を作るとミスが激減します。

この表を左から順にCOUNTIFSの引数にしていけば、条件が4つでも5つでも設計が崩れません。

営業や販売データをAND条件で絞り込む“現場のあるあるパターン”

営業・販売管理で実際に多いのは、次のような組み合わせです。

• 担当者別に「成約」だけをカウント

• エリアと商品カテゴリを同時に絞り込む

• 月次の新規契約で、特定単価以上だけ拾う

代表的なパターンを表にまとめると、ロジックが整理しやすくなります。

ここで重要なのは、「何を数えるか」を業務側で決めきってから関数に落とすことです。営業と経理で「売上件数」の定義が違うと、同じ関数でも数字がかみ合いません。

成績管理やアンケート結果で「60点以上かつ70点未満」だけを正確にカウントしよう

点数レンジを扱うとき、よくあるミスが「60〜69点」と「60〜70点」の境目の取り違えです。ここをあいまいにすると、ボーダーラインの人が毎回どちらかに消えます。

次のように分けて考えると安全です。

アンケートの5段階評価でも同じ考え方を使います。「4と5だけ」を高評価と定義するなら、「評価>=4」の1条件で済みますが、「真ん中の3は含めない」とチームで明文化しておくことが、数式よりも大事な作業です。

勤怠や労務データで「特定部署かつ残業○時間以上」もれなく数える設計術

勤怠管理は、条件漏れがそのまま残業代の支払い漏れにつながる領域です。現場では、次のような複数条件がよく使われます。

• 部署が「開発」かつ 残業時間が20時間以上

• 雇用区分が「アルバイト」かつ 出勤日数が10日未満

• 出勤区分が「休出」かつ 日付が当月

安全に設計するためのチェックポイントを整理します。

• 部署コードと部署名が混在していないか（”001″と「開発部」が同じ列にないか）

• 残業時間が「数値」か「文字列」かを事前に確認

• 休日出勤の判定を、フラグ列に統一してから条件にする

特に、残業時間が「10:00」のような時刻形式で入力されている表では、単純な>=20では判定できません。業務では、あらかじめ「残業時間(小数時間)」列を作成しておき、そこで20以上を判定する形に正規化しておくと、COUNTIFSだけでシンプルに集計できます。

データの正規化と条件設計をセットで考えると、数式は驚くほど短くなります。集計で迷子になるチームほど、関数を複雑にする前に「どの列をどんな形式で持つか」を決めるステップを飛ばしている印象があります。業務データを扱う現場ほど、ここを一度立ち止まって整える価値があります。

OR条件や複数範囲でつまずかないために COUNTIFとCOUNTIFSの正しいコンビネーション技

「ANDはできたのに、ORを書いた瞬間に一気に迷子」になっているなら、ここを押さえるだけで一段上の集計ができるようになります。

COUNTIFで複数条件のORを正しく使いこなす 合算の考え方が鍵！

OR条件は「足し算で考える」と一気にシンプルになります。

• 例: A列の支店名が東京または大阪の件数

=COUNTIF(A:A,”東京”)+COUNTIF(A:A,”大阪”)

ポイントは次の2つです。

• ORは1本の関数で頑張らず、条件ごとに分けて合計する

• 重複カウントがあり得る場合は、ID列で一意に管理しておく

よくある誤りは、AND専用のCOUNTIFSにそのままORを押し込もうとすることです。ORは「列をまたぐ条件」より「同じ列の別パターン」を数えたいケースが多いので、まずはCOUNTIFの合算で組み立てた方が安全です。

COUNTIFSとOR関数やSUMPRODUCTの組み合わせ方と避けたい落とし穴

ANDとORを同時に扱いたい場面では、次の2パターンに整理すると迷いません。

• パターン1: ANDの中に少数のORがある

  例: 支店が東京または大阪 かつ 商品A

=COUNTIFS(支店列,”東京”,商品列,”A”)+COUNTIFS(支店列,”大阪”,商品列,”A”)

• パターン2: 条件が複雑で列も多い

  この場合だけ、SUMPRODUCTやOR関数を検討します。

=SUMPRODUCT((支店列=”東京”+支店列=”大阪”)*(商品列=”A”))

避けたい落とし穴は次の通りです。

• OR関数だけで書き、結果がTRUEかFALSEかを意識していない

• SUMPRODUCTで参照範囲が行方向にずれている

• 集計ロジックが読めず、担当交代と同時に誰も触れない

現場では「読めない1式」より「少し長くても意味が読み取れる複数式」の方が、運用の事故は圧倒的に減ります。

複数範囲や飛び飛び範囲を扱うときの“数式設計図”の描き方

飛び飛び範囲で迷う最大の理由は、「頭の中でだけ設計して、紙に出していない」ことです。次のような簡単な表を書いてから数式を組むと、ミスが激減します。

この「設計図」で
1 どの列をANDで縛るか
2 どの列をORで合算するか
3 飛び飛び列は別式にして後で足すか
を明確にしておくと、あとから見返してもロジックを追いやすくなります。

スプレッドシートでのCOUNTIFとORの書き方とExcelとの微妙な違い

スプレッドシートでも基本の考え方は同じですが、次の点だけ意識しておくとハマりにくくなります。

• 関数名や使い方はほぼ同じだが、配列計算が標準で強い

  OR条件を扱うとき、{条件1,条件2}のような配列指定で一気にカウントする書き方が増えがちです。便利な一方で、Excelに持ち帰ったとき互換性が落ちます。

• クラウド共有前提なので、「読める数式」であることがより重要

  チームで同じファイルを同時編集するため、ロジックをコメントや別シートで文章化しておくと、引き継ぎのストレスが大きく下がります。

• フィルタビューやQUERY関数と役割分担する

  「まずはQUERYで対象行を絞る」「最終的な件数だけをCOUNTIFやCOUNTIFSで持つ」という分担にすると、複雑なOR条件も見通しよく管理できます。

営業企画やバックオフィスの現場では、1回きりの集計ではなく、毎月同じロジックを回すことがほとんどです。OR条件と複数範囲を「一発芸の数式」で片付けず、設計図から組み立てる習慣が、数字で迷子にならない一番の近道だと感じています。

COUNTIFとCOUNTIFSがうまくいかない本当の理由 プロが教えるチェックリストで解決！

期限直前の集計で、関数が0ばかり返してきた瞬間の冷や汗は、多くの現場で共有されている光景です。関数そのものより、「どこでつまずきやすいか」を知っておくと、一気に現場対応力が上がります。

0や極端に少ない数字しか返らない時に最初に疑うべき3つのポイント

まずは「パニックにならないための3点チェック」です。

1. 条件の書き方が違う
2. 対象データの範囲がずれている
3. そもそも条件を満たすデータが存在しない

特に1と2は、次のようなクセがあります。

• 演算子を入れ忘れている

  • NG: =COUNTIF(A:A, 80)
  • OK: =COUNTIF(A:A, “>=80”)

• 絶対参照を忘れてコピー時に範囲がずれる

  • $A$2:$A$100 に固定しているかを確認します。

すぐに確認したい場合は、「条件をゆるめる→件数が増えるか」を試すと早いです。例えば「東京都」だけで0なら、「都」を含むで一度カウントしてみる、という発想です。

文字列・日付・数値の「型ズレ」バグを一撃で見抜くカンタン技

関数が動かない原因のかなりの割合を占めるのが、型ズレです。見た目は同じでも、Excelやスプレッドシート上では別物として扱われています。

よくある型ズレの例を整理すると、次のようになります。

一撃で見抜くための手順はシンプルです。

• ISNUMBER関数で判定

  • =ISNUMBER(A2) が TRUE なら数値・日付、FALSE なら文字列

• 日付列を「短い日付」→「標準」に書式変更し、シリアル値が出るか確認

• 文字列列を「左寄せ」「トリム処理」で整える

  • =TRIM(A2) で前後の余計な空白を削れます。

集計前に、型の混在を洗い出す小さな検査用列を1列用意しておくと、後からのやり直しコストが激減します。

条件範囲のサイズ不一致や演算子・セル参照ミスを素早く洗い出そう

COUNTIFSで「なんか変だな」と感じたら、まず疑うべきは範囲のサイズと演算子の結合ミスです。

代表的なチェックポイントをまとめます。

• 条件範囲のサイズ不一致

  • A2:A100 と B2:B99 のように行数が違う
  • 行数は必ず同じにそろえる

• 演算子とセル参照の結合ミス

  • NG: “>”&B2&””
  • OK: “>”&B2

• 別シート参照の$固定忘れ

  • コピーした瞬間に検索条件が別のセルを向いてしまうことがあります。

疑わしい式を見つけたら、一度だけ手入力で作り直し、正しいものと比較すると原因を特定しやすくなります。現場では、「一番上の1行だけを検証用として徹底的に確認し、それをコピーベースにする」運用が安定します。

「OR条件のつもりがAND条件だった」失敗集計を防ぐコツ

最も危険なのが、ORのつもりでANDになっているパターンです。数字は出ているので異常に気づきにくく、会議で判断を誤る原因になります。

押さえておきたい考え方はこれだけです。

• COUNTIFSはすべてAND条件（全部満たした行だけをカウント）

• OR条件にしたいときは、COUNTIFの合計か、COUNTIFSを分けて足す

たとえば「東京または大阪の件数」を数えたい場合、

• AND誤りの例

  • =COUNTIFS(都市範囲,”東京”,都市範囲,”大阪”) → 常に0

• 正しいORの例

  • =COUNTIF(都市範囲,”東京”)+COUNTIF(都市範囲,”大阪”)

もう一歩踏み込んだ現場ルールとしては、

• 「条件の数が増えたら、とりあえず分解して足す」

• 「ORなのかANDなのかを、数式を書く前に紙に書き出す」

このひと手間で、「なんとなく書いてみた複雑な数式」が「誰が見ても意味が分かる集計ロジック」に変わります。業務の引き継ぎやクラウド共有を前提にすると、この読みやすさが、結果的に一番の効率化になります。

現場シナリオで学ぶCOUNTIFとCOUNTIFS活用術 売上・成績・勤怠・アンケート編

会議のたびに「その件数、うちの集計と違うんだけど？」と噛み合わないなら、関数ではなく条件の設計でつまずいています。ここでは、現場で本当に揉める4つのデータを題材に、迷わない条件の決め方を整理します。

営業や経理で定義がズレがちな「売上件数」をどの条件でカウントするか決める視点

売上件数は、同じ表でも部門ごとに解釈が違う典型例です。

まず、会議前に次を必ず決めます。

• どの列を「売上の基準」とするか

• ステータスのどの値をカウント対象にするか

• 未請求・キャンセル・テストデータを含めるか除くか

そのうえで、件数だけ欲しいなら条件付き個数の関数、金額も見たいならSUMIFSとセットにします。
ポイントは、数式より先にルールを書き出しておくことです。これをサボると、同じ表で3種類の売上件数が走り出し、経営数字が信用されなくなります。

学校や研修の成績データをCOUNTIFSで安全集計するためのチェックポイント

成績表で多いのは「80点以上90点未満」「合格ライン以上」などの範囲条件の抜け漏れです。
見落としを防ぐために、次の3点をチェックします。

• 境界値を先に決める

  79.5をどう扱うか、四捨五入の前か後かを合意します。

• 上限と下限を明示する

  例: 80点以上90点未満なら

  • 点数範囲, “>=80”
  • 点数範囲, “<90”
    と2条件で固定します。

• 教科・クラスとのANDを整理する

  教科列、クラス列、点数列の3つ以上を同時に指定しても、行数と範囲サイズが完全一致しているかを必ず確認します。

成績集計は「1点違いで合否が変わる」領域なので、関数の正しさ以上に、どの条件なら学生に説明できるかを基準にしておくと、後から揉めません。

総務・人事・労務で押さえたい勤怠データの条件付き個数の賢い設計方法

勤怠は、残業や欠勤がそのままコストとリスクになるため、条件設計を誤るとマネジメント判断を誤ります。最低限、次の3種類を分けてカウントします。

• 遅刻・早退などの状態の回数

• 所定時間を超える残業発生回数

• 法定基準を超える要注意ケース

例えば「特定部署で残業2時間以上の日数」を数えたい場合は、

• 部署列: “営業一課”

• 残業時間列: “>=2”

• ステータス列: “出勤”

のように部署×時間×出勤日のAND条件にします。
ここでありがちなミスが、「有給」や「特別休暇」が同じ列に混在していて、欠勤扱いにしてはいけない日まで含めてしまうケースです。
最初に、勤怠コードごとの意味をテーブルに整理しておくと、関数より前に制度としての整合性をチェックできます。

アンケートやNPSで「高評価だけ」抜き出す条件設定の黄金パターン

アンケートやNPSは、平均値よりも高評価の割合が意思決定に効きます。そこで、まずスコアの帯を定義します。

このうえで、次のような粒度で条件を足していきます。

• 高評価の件数だけ

  • スコア列, “>=9”

• 高評価かつ特定商品に対する回答だけ

  • スコア列, “>=9”
  • 商品列, “Aプラン”

• 高評価かつリピーターだけ

  • スコア列, “>=9”
  • 購入回数列, “>=2”

重要なのは、「高評価」の定義をマーケティング、現場、経営で共有しておくことです。
ここがあいまいなまま関数だけ複雑になると、数字は出ているのに、誰も意思決定に使えない“ノイズ指標”になります。

データ支援の現場を見てきた立場から言えば、関数の巧拙よりも、どの条件をチームの共通言語にするかを決めた瞬間に、会議の質とスピードは一段上がります。

COUNTIFSだけに頼りすぎない！SUMIFSやFILTERと役割分担して効率アップ

「全部COUNTIFSで数えておけば安心」そんな運用を続けると、数か月後には誰も触れない“関数ブラックボックス”が完成します。件数も合計も平均も、適材適所で関数を分担したほうが、表は軽くなり、ロジックも読みやすくなります。

件数か合計か平均か COUNTA・SUMIFS・AVERAGEIFSとのスッキリ使い分け

まずは「何を知りたいのか」をはっきりさせると、使う関数が自然と決まります。

ポイントは、件数はCOUNTIFS、金額はSUMIFS、スコアはAVERAGEIFSと役割を割り切ることです。件数と合計を同じ関数で無理に出そうとすると、計算式が長くなり、修正のたびに迷子になります。

集計ロジックを見える化するテーブル設計と参照の工夫

どんなに関数を覚えても、「どの条件で集計しているか」が表から読み取れなければ、チームでは使いこなせません。おすすめは、集計条件を別テーブルに書き出す設計です。

このように「どの列を見て」「何を条件にするか」を1行で定義し、そのセルをCOUNTIFSやSUMIFSの引数に参照させます。セル参照でロジックを外出ししておくと、

• 条件を変えるときはテーブルを書き換えるだけ

• 数式を読む人は、テーブルを見るだけで意図が分かる

という状態を作れます。業界人の目線で見ると、この“ロジックの見える化”ができているチームほど、数字の議論が噛み合いやすいです。

大量データでも重くならないために 関数増やしすぎない発想

行数が数万件を超えると、安易に関数をコピーしまくる表は一気に重くなります。ここからは「どう軽く作るか」が勝負です。

意識したいポイントは次の3つです。

• 集計用シートは「関数は1ブロックだけ」に抑える

  同じ計算式を縦横にばらまくのではなく、テーブル形式で1行に1集計、1セルに1関数という構造にします。

• 明細のフィルタはFILTER関数に任せる

  明細データを絞り込みたい場合、COUNTIFSで無理に判定列を増やすより、FILTERで別シートに抽出したほうが読みやすく、後続の分析も楽になります。

• 何でも計算させず、「これは目視で十分」を決める

  すべてを自動化しようとしてAND条件・OR条件を詰め込んだ巨大な式を作るより、「集計のゴール」と照らして、本当に必要な指標だけを関数に任せるほうが結果的に効率的です。

件数はCOUNTIFS、金額はSUMIFS、平均はAVERAGEIFS、明細抽出はFILTER。役割をスパッと分けるだけで、「触るたびに怖いファイル」が「誰でも安心して編集できる管理表」に変わっていきます。

Excelだけで完結しない時代 COUNTIFとCOUNTIFSから始めるデータ活用とAI連携の第一歩

条件付き個数をKPIに設計し、業務プロセスへ落とし込む発想法

同じ関数でも、「どの条件で数えるか」を決めない限り、数字はただの飾りになります。
営業なら「新規問い合わせのうち成約見込みAランク」、人事なら「残業20時間以上かつ評価B以下」の件数など、まず意思決定に直結する問いを1行の日本語で書き出すところから始めます。

その日本語を、順番に条件へ分解します。

• 対象となるデータ範囲はどこか

• どの列をどんな条件で絞り込むか

• 「以上」「未満」「空白以外」など境界条件はどこか

この設計をチームで共有し、関数の上にKPI設計シートを1枚置いておくと、「担当が変わった途端に誰も式を読めない」事故を防げます。

スプレッドシートやクラウドツール、Copilot活用につなぐCOUNTIFSの使いどころ

オンプレのExcelで作った集計ロジックは、そのままクラウド環境の土台になります。
特に複数条件を扱う関数は、スプレッドシートやCopilotに展開しやすい「型」を作る意識が重要です。

代表的な使いどころを整理すると、次のようになります。

ここで意識したいのは、「人が読むための列名」と「ツールが読むための条件」を揃えることです。
列名を日本語で明確にし、条件式もセル参照で外出しにしておくと、AIアシスタントに「この条件を変えて」と指示しやすくなります。

Webマーケや組織運営にも通じる“数字を見る力”を関数で身につけよう

Webマーケの世界では、広告クリックや問い合わせ数を、日付・流入経路・キャンペーンといった条件で分解して見ます。
これは、組織運営で「部署別・雇用形態別・評価別の人数」を数える発想とまったく同じ構造です。

数字を見る力を鍛えるうえで、有効なチェックポイントは次の3つです。

• 「この件数は、誰のどんな行動を数えているか」を言語化できるか

• 「除外したい条件」は何かを必ず書き出してから式に落とすか

• 会議で数字を出すとき、条件メモをセットで共有しているか

経営や現場マネジメントの議論がかみ合わない多くの場面で、問題は関数ではなく「条件の定義」がズレています。
条件付き個数を単なるテクニックで終わらせず、「問いを設計し、条件をそろえ、同じ景色の数字を見るための共通言語」として使い倒していくことが、AIやクラウド時代の一歩目になると実感しています。

宇井和朗が実感した「数字に迷子になる企業」とCOUNTIFとCOUNTIFSとの危うい距離

条件の定義が曖昧なまま数字だけ追うと現場で本当に起こるトラブルとは

私が支援してきた企業で一番多いのは、「同じ売上件数のはずなのに、部署ごとに数字が違う」という相談です。よく見ると、Excelの関数が間違っているのではなく、条件の意味がバラバラになっています。

• 営業A：請求書発行済みをカウント

• 営業B：受注ステータスが「成約」のデータをカウント

• 経理：入金済みだけをカウント

どれも関数としては正しくても、会議で「売上件数」が3種類存在してしまう状態です。
このとき多くの担当者は、COUNTIFやCOUNTIFSを疑いますが、本当の原因は「何を数えるか」の合意が無いまま数式だけ先に作っていることにあります。

日付の条件も危険です。
「今月の新規会員数」を出しているつもりが、片方は登録日でカウント、もう片方は初回購入日でカウントしているケースもあります。どちらも集計は完璧なのに、判断はズレ続ける。これが数字迷子の正体です。

8万社以上支援で見えた「集計が上手いチーム」と「いつも振り回されるチーム」の違い

集計が上手いチームは、関数のテクニックより先にルール表を作ります。

この表を先にチームで共有してから、COUNTIFやCOUNTIFSに落とし込むので、誰が作っても同じ数字になる状態を保てます。

一方、振り回されるチームの特徴は次の通りです。

• 担当者ごとに自前のExcelやスプレッドシートを持っている

• 数式は高度だが、条件の説明が口頭ベース

• 新人が入るたびに「この関数だけコピペして」と引き継いでいる

関数がブラックボックス化し、作った本人以外は触れなくなります。結果として、業務そのものが1人依存になり、異動や退職のたびにデータ分析が止まってしまいます。

関数を覚えただけで終わらず、「自社の数字を自分で読み取る」ためのステップアップ

関数を覚える段階から、「数字を設計する段階」に進むために、私は次の3ステップを必ず提案します。

1. KPIを文章で書き出す
   例「新規問い合わせのうち、今月中に商談化した件数をカウントしたい」
2. 使うデータ列と条件をテーブル化する
   どの列を見て、どんな条件でカウントするのかを明文化します。
3. その後で関数を選ぶ
   単一条件ならCOUNTIF、複数のAND条件ならCOUNTIFS、別条件のORなら合計で、という順番で考えます。

このプロセスを踏めば、CopilotやAIツールに「このKPIをこの表で集計したい」と指示するだけでも、かなり正確な数式が提案されるようになります。
関数の知識と、条件設計の思考がそろった瞬間、Excel上の数字は単なる集計から意思決定に使えるデータへと変わります。業務で振り回される側から、数字で現場をリードする側に回りたいなら、この距離感の見直しから始めてみてください。

この記事を書いた理由

著者 – 宇井 和朗（株式会社アシスト 代表）

本記事は、生成AIで自動生成した文章ではなく、私自身と当社が日々向き合っている業務改善の経験と知見をもとにまとめています。

自分の会社でも、クライアント企業でも、Excelで集計した数字が会議の直前に合わず、原因がわからないまま担当者だけが責められている場面を何度も見てきました。関数の知識はあるのに、COUNTIFとCOUNTIFSの条件設計やAND・ORの整理があいまいなせいで、売上・成績・勤怠・アンケートの「定義ズレ」や判断ミスが起こり、経営判断そのものがぶれてしまうケースも少なくありません。

私が関わってきた8万社以上の支援の中でも、数字で迷子になるチームほど、関数そのものより「どの条件で何を数えるか」を決めきれていないと感じます。本記事では、担当者が締切前に慌てず、経営側も安心して数字を信用できるように、実務でそのまま使えるCOUNTIF／COUNTIFSの考え方とチェックポイントを整理しました。読んだ直後から、今目の前にある表の集計を自分で設計し直せる状態になってほしい、という思いで書いています。