「これはバグか仕様か」の決め方｜判断が割れたときの合意の取り方
「これ、バグですよね？」
問い合わせのメールにその一行があると、少し身構えてしまいませんか。 調べてみると、確かに使いにくい。でも、たぶん最初からそういう作りになっている。仕様書を探しても、その部分だけ書かれていない。
直すべきなのか。直すなら無償なのか、改修依頼として見積もりを出すのか。 相手は「バグだから直してほしい」と思っていて、自分は「これは仕様のはず」と思っている。この状態のまま話し合うと、たいてい平行線になります。
これは、あなたの調査が足りないからでも、相手が理不尽だからでもありません。「バグか仕様か」は、多くの場合、その場で決着がつく問いではないからです。この記事では、決着をつけようとする代わりに、事実を分けて仕分けていく手順を一緒に整理します。
結論：バグか仕様かを頭の中で決めようとしないでください。やることは3つです。①「期待した動き」「実際の動き」「根拠（どこにそう書いてあるか）」の3つを分けて書き出す、②根拠があるか・困っているかで4つに仕分ける（バグ／仕様／決めごと／保留）、③自分は判定者ではなく、選択肢と影響を出す係だと決める。まずは①の3行を書くところからで十分です。
なぜ「バグか仕様か」でもめるのか
技術的な難しさよりも、話がこじれる理由は別のところにあります。
- 仕様の根拠が残っていない：仕様書がない、あっても実装と食い違っている、当時の判断がメールや口頭にしか残っていない。作った人がもういないことも珍しくありません。
- 言葉の裏に、お金と責任の話がある：「バグ」なら無償で直す、「仕様」なら有償の改修依頼になる——多くの現場でこの前提が共有されています。つまり議論の中身は技術判定でも、実際に決めているのは費用と責任の話です。ここがすれ違うと、事実の確認より主張のぶつけ合いになります。
- 一人保守だと、自分が裁定者にされる：本来は依頼者・利用部門・開発元で決めることでも、「詳しい人が決めて」と丸投げされがちです。決めた結果を後から責められるのは、かなりしんどい役回りです。
だから、最初にやることは判定ではありません。もめている中身を、事実と判断に切り分けることです。切り分けるだけで、話せる相手と話せる材料がはっきりします。
ステップ1：期待・実際・根拠の3行に分ける
調査に入る前に、たった3行のメモを作ります。長い調査報告より、この3行のほうが先に効きます。
- 期待：相手はどう動くと思っていたか（相手の言葉のまま書く）
- 実際：いま何が起きているか（自分が確認した事実だけ）
- 根拠：「そう動くはず」と言える材料が、どこかにあるか
大事なのは、根拠の欄を空欄のままにしておけることです。ここを埋められないと分かった時点で、もう半分は答えが出ています。「仕様だと言い切れる材料が、いまは無い」という事実が確定するからです。
「期待」と「実際」の聞き出し方が定まらないときは、「動きがおかしい」の切り分け｜最初に聞く7つの質問リストの質問をそのまま使えます。
根拠を探す場所（この5か所で見つからなければ、無いものとして進める）
根拠探しは、いくらでも時間を溶かせてしまいます。次の5か所を見て出てこなければ、いったん「根拠なし」として次に進んで大丈夫です。
- 仕様書・設計書・画面定義（該当機能の項だけ見る）
- 過去のメール・チケット・議事録（機能名や画面名で検索）
- テスト仕様書・検収時の確認資料（期待値が書かれていることがあります）
- コード内のコメントと、その行の変更履歴（
git blameや変更日時から、いつ・なぜ入ったかをたどる） - リリース記録・変更管理の台帳（変更管理台帳のつけ方）
コードそのものは「今こう動いている」の証拠にはなりますが、「こう動くべき」の根拠にはなりません。ここは混ざりやすいので、分けて考えると迷いにくくなります。
ステップ2：4つに仕分ける
3行が書けたら、次の4つのどれかに置きます。頭の中で「バグか、仕様か」の二択にしないのが、いちばんのコツです。
- バグ：根拠がある。そして、実際の動きがその根拠と違う。→ 直す対象です。影響範囲を確認して、修正の段取りに入ります。
- 仕様：根拠がある。そして、実際の動きは根拠どおり。→ 今の作りは間違っていません。それでも困るなら「不具合対応」ではなく「改修依頼」として、あらためて優先順位と見積もりの話に移します。
- 決めごと：根拠がない。でも、実際に業務が困っている。→ ここが一番多いところです。誰かが悪いのではなく、単に決まっていなかった。だから今回、決めます。
- 保留：根拠がない。そして、いま実際には困っていない（気になるだけ、見た目の問題など）。→ 記録だけ残して、様子を見ます。判断しないことも、立派な判断です。
「決めごと」に入った時点で、話し方が変わります。「これはバグでしょうか」ではなく、「ここは決まっていなかったので、どちらの動きにするか決めさせてください」と言えるようになる。犯人探しから、これからの相談に切り替わります。
なお、「バグなら無償・仕様なら有償」という線引きは、社内システムか受託開発かで前提が変わります。請負契約であれば、直す義務がどこまであるかは最終的に契約書の記載によります（2020年4月施行の改正民法では、以前の「瑕疵担保責任」が「契約不適合責任」という枠組みに整理されています）。この判断は現場の技術者が一人で背負う話ではありません。 費用が絡みそうなら、早い段階で契約を確認できる人に一言つないでおくと安心です。
具体例：判断が割れやすい3つのパターン
実際の現場では、こんな形で割れます。仕分け先とセットで見てみましょう。
- 「半角カナを入力すると登録できない」：調べると、入力チェックで弾く実装が最初から入っている。でも仕様書には書かれていない。→ 根拠なし・実務で困っている＝決めごと。「弾く仕様を維持する／全角に自動変換する／許可する」の3案と、それぞれの影響（既存データ・帳票・連携先）を出して選んでもらいます。
- 「一覧が途中で切れて、それ以上表示されない」：設計書に表示上限の記載があった。実装もそのとおり。→ 根拠あり・実際も根拠どおり＝仕様。ただしデータが増えて実務が変わったのは事実なので、そのまま「使いにくいですね」で終わらせず、上限を広げる改修依頼として起票します。仕分けはあくまで手続きの整理で、相手の困りごとを退けるためのものではありません。
- 「合計金額が1円合わない」：金額の丸め処理が絡む話です。端数処理の取り決め（切り捨て・四捨五入・どの単位で丸めるか）が資料や過去の合意に残っているなら、その通りかどうかでバグ／仕様が決まります。残っていなければ決めごとです。ここは推測で「たぶんこうだったはず」と埋めないでください。お金に関わる部分は、必ず決めた記録を残してから直します。
影響：仕分けの型を持つと、何が変わるか
判定を早く出せるようになる、という話ではありません。変わるのは、その先です。
- 対立が減る：「バグだ／仕様だ」の主張合戦ではなく、「根拠があるか」という共通の事実を見る話になります。
- 同じ議論を繰り返さなくなる：決めごととして決めた内容を残せば、次に同じ質問が来たとき「根拠あり」で答えられます。仕様の空白が、1件ずつ埋まっていきます。
- 見積もりの説明が通りやすくなる：「仕様どおりだが、変更するとここに影響が出るので工数はこれくらい」と、根拠つきで話せます。
- 自分ひとりで背負わなくてよくなる：選択肢と影響を出す係に回れば、決めるのは決められる人の仕事だと、無理なく線を引けます。
決めた記録の残し方は、問い合わせ対応を「調査ログ」として資産にする方法や、仕様書がないシステムの仕様を現状から起こす進め方が土台になります。今回の1件を、そのまま仕様の1行にしてしまうのが一番近道です。
そのまま使える：合意を取る連絡の文面
「決めごと」に仕分けたときの返信例です。責める言葉も、謝りすぎる言葉も入れないのがポイントです。
お世話になっております。ご連絡いただいた件、確認しました。
■ ご報告いただいた動き
（相手の言葉のまま：例）半角カナで登録するとエラーになる
■ 現在の動作（確認結果）
入力チェックで半角カナを受け付けない実装になっています。
■ 確認できた根拠
仕様書・過去の経緯を確認しましたが、この点の取り決めは
見つかりませんでした。当時決めきれていなかった箇所と思われます。
■ ご相談したいこと
今回あらためて、どの動作にするか決めさせていただければと思います。
A案：現状のまま（変更なし）
→ 影響：現在の運用は変わりません
B案：全角カナへ自動変換して登録
→ 影響：既存データとの表記ゆれ確認が必要／作業◯日程度
C案：半角カナをそのまま許可
→ 影響：帳票・連携先での表示崩れの確認が必要／作業◯日程度
ご希望と、業務上の優先度をお聞かせいただけますでしょうか。
決まりましたら、仕様として記録に残しておきます。「バグではありません」とは書かないほうが伝わります。相手が本当に言いたいのは分類ではなく「困っている」なので、そこを受け止めたうえで選択肢を出すと、話がまっすぐ進みます。
明日やること：3行だけ書いてみる
今ちょうど、判断が止まっている案件がありませんか。その1件で試してみてください。
- 紙でもメモアプリでもいいので、期待・実際・根拠の3行を書く。
- 根拠の欄を埋めるために、前述の5か所だけ探す。時間を決めて、出てこなければ空欄のままにする。
- 4つ（バグ／仕様／決めごと／保留）のどれに置くかを決める。
- 「決めごと」なら、選択肢を2〜3案と、それぞれの影響を書き出す。工数は概算で構いません。
- 相手に返す前に、上の文面の形に当てはめてみる。
全部やらなくても大丈夫です。3行を書いた時点で、たいてい「自分が悩んでいたのは技術の話ではなかった」と分かります。それだけでも、肩の力は少し抜けます。
「バグか仕様か」判断チェックリスト
判断に迷ったとき、上から順に見てください。
- 相手の「期待した動き」を、相手の言葉のまま書き留めたか
- 「実際の動き」を、自分の目で確認した事実だけで書いたか（推測と分けたか）
- 根拠を探す場所を決めて、時間を区切って探したか
- コードの実装を「根拠」として扱っていないか（現状の証拠であって、あるべき姿の根拠ではない）
- 根拠が見つからなかったことを、「分からない」ではなく「決まっていなかった」と書けているか
- 「仕様」に仕分けたとき、相手の困りごとを改修依頼として受け止め直したか
- 費用や契約が絡みそうなとき、自分ひとりで結論を出さずに済む形にしたか
- 決まった内容を、次に同じ質問が来たときに引ける場所へ残したか
全部そろわなくても構いません。1件でも「決めごと」として決着させられたら、その分だけ仕様の空白は減っています。
よければ、こちらも
判断のあとには、直す作業と、記録する作業が続きます。次の一歩に使えるものを置いておきます。
- 「動きがおかしい」の切り分け｜最初に聞く7つの質問リスト：期待と実際を、相手から正確に聞き出すための質問です。
- 仕様書がないシステムの仕様を現状から起こす進め方：「決めごと」で決めた内容を、仕様として残していくために。
- 同時に来た改修依頼をさばく｜一人保守の優先順位のつけ方：「仕様」に仕分けた要望を、改修依頼として並べ直すときに。
「バグか仕様か」で悩む時間は、外から見えにくい仕事です。誰にも褒められないし、調べても答えが出ないことすらある。それでも、あなたがその1件を放り出さずに確かめようとしたおかげで、決まっていなかった仕様がひとつ決まります。
明日は、3行のメモからで十分です。判定を出すのではなく、事実を並べるだけ。それだけで、止まっていた話は動き出します。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。