デモだけのベンダーを見抜く質問例｜ログ・権限・エラー時の挙動を確認する

ITシステムやSaaSの導入検討において、営業担当者が披露する「デモ」は常に美しく、完璧に動作します。しかし、デモで提示されるのは「ハッピーパス」と呼ばれる、一切の例外が発生しない理想的なフローに過ぎません。

実務で本当に重要なのは、「データが消えたとき」「API連携が失敗したとき」「組織改編で権限が複雑化したとき」に、システムがどう振る舞い、管理者がどう対処できるかという泥臭い部分です。これらを確認せずに契約すると、導入後に「運用でカバー」という名の膨大な手作業が発生することになります。

本記事では、システム選定の最終段階でベンダーにぶつけるべき、ログ・権限・エラーハンドリングに関する具体的な質問例と、その回答から読み解くべき技術的リスクを解説します。

デモの「華やかさ」に騙されないためのシステム選定基準

ベンダーのデモは、UX（ユーザー体験）の良さや、主要な機能の利便性を強調するように設計されています。しかし、IT実務担当者が注視すべきは、画面の表側ではなく「裏側」の作り込みです。

特に、以下の3つの観点が欠落しているシステムは、導入後に管理コストが急増します。

• 可視性（Observability）：何が起きているか、管理者が把握できるか。
• 堅牢性（Robustness）：例外的な操作やシステム負荷に対して、データ整合性を保てるか。
• 柔軟性（Flexibility）：企業の成長に伴う組織変更やルール変更に、コードを書かずに対応できるか。

これらを見極めるためには、ベンダーに対して「もし〜が起きたらどうなりますか？」という、ネガティブシナリオに基づく質問を投げることが不可欠です。

ログ・監査対応：実務で「犯人探し」をさせないための質問

トラブルが発生した際、最も重要なのは「誰が犯人か」を見つけることではなく、「何が、いつ、どう変わったか」の履歴を正確に追跡し、復旧の足がかりを得ることです。

操作ログ：変更前後の「値」まで記録されているか

多くのツールが「ログ出力対応」を謳っていますが、その粒度は千差万別です。

ベンダーへの質問例：

「ある社員がマスタ情報を書き換えた際、ログには『誰が更新したか』だけでなく、『どの項目を、何から何へ書き換えたか』の差分まで記録されますか？」

単に「〇〇さんがマスタを更新しました」というログだけでは、実務上の調査には役立ちません。特に、freee会計導入マニュアル｜旧ソフト移行ガイドでも触れているような、会計データや顧客情報の移行・更新においては、差分ログ（Before/After）の有無が、内部統制の有効性を左右します。

API連携ログ：エンジニアがいなくても「原因」を特定できるか

現代のシステム運用は、SaaS間の連携が前提です。連携が止まった際、「ベンダーに問い合わせないと原因がわからない」状態は、実務者にとって致命的です。

• HTTPステータスコードの表示：401（認証エラー）、403（権限エラー）、429（レート制限）などが管理画面で即座に判別できるか。
• リクエスト/レスポンスボディの確認：具体的にどのデータがバリデーションに引っかかったのか、JSONの中身を管理者が確認できるか。

保存期間とエクスポート機能：外部ストレージへの保管が可能か

標準のログ保存期間が「30日間」や「90日間」に制限されているケースは珍しくありません。上場準備（IPO）や監査対応が必要な場合、最低でも1年〜数年のログ保持が求められます。

確認ポイント：

ログの保存期間を延長できるか（追加費用の有無）。

S3やGoogle Cloud Storageなど、外部ストレージへ自動的にログを転送（エクスポート）する機能があるか。

権限管理・セキュリティ：統制崩壊を防ぐための質問

「権限設定は自由に行えます」という言葉を鵜呑みにしてはいけません。組織が100人、500人と増えた際、その「自由な設定」が管理の地獄を生みます。

階層構造と共有設定：兼務や組織変更に耐えられるか

日本の組織構造は「兼務」や「プロジェクト単位の横串組織」が頻発します。

ベンダーへの質問例：

「一人のユーザーに複数のロール（役割）を割り当てた場合、権限は『和集合（強い方が優先）』になりますか、それとも制限が加わりますか？」

また、部署異動の際に「ユーザーの部署属性を書き換えるだけで、アクセスできるフォルダやデータが自動的に切り替わるか」も重要です。手動で一つずつ権限を剥がしていく運用は、必ず設定漏れを招きます。これは、SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐアーキテクチャで論じている通り、ID管理（IdP）との連携親和性にも直結します。

項目レベルのアクセス制御：閲覧制限は「ページ」か「項目」か

「この画面は見せたいが、その中の『単価』や『給与』という項目だけは隠したい」というニーズに対し、ページごと非表示にするしかないシステムは実務に耐えません。フィールドレベル（項目単位）のセキュリティ設定が可能かを確認してください。

シングルサインオン（SSO）とプロビジョニングの仕様

SSO（SAML 2.0等）に対応しているのは当然として、**SCIM（System for Cross-domain Identity Management）**によるプロビジョニングに対応しているかを確認しましょう。IdP側でユーザーを作成・削除した際、対象のシステム側のアカウントが自動で同期されないと、退職者のアカウントが残り続けるリスク（ゴーストアカウント）が発生します。

エラー時の挙動とデータ整合性：運用が止まるリスクを暴く質問

システムが正常に動いている時間は、誰が管理しても同じです。管理者の腕が問われるのは「異常系」が発生した時です。

同期失敗時の「再試行」と「通知」の仕組み

外部システムとの連携エラーが起きた際、システムが自動で再試行（リトライ）を行うのか、それとも管理者がボタンを押す必要があるのか。また、エラーの通知はメールだけでなく、SlackやTeams、あるいはWebhookで飛ばせるかを確認します。

不整合データのクレンジングと手動修正の可否

例えば、SFAから会計ソフトへデータを飛ばす際、マスタの不一致でエラーになったとします。このとき、「SFA側のデータを修正して再送」するしかないのか、あるいは「中間データとしてシステム内に保持し、システム上で微修正して投入」できるのか。後者の機能がない場合、一度エラーになるとワークフロー全体を差し戻す必要があり、現場に大きな負荷がかかります。

こうした複雑な連携については、【図解】SFA・CRM・MA・Webの違いとデータ連携の全体設計図を参考に、各システムの責務を明確にしておくことが重要です。

一括更新（インポート）のバリデーション仕様

CSVで1,000件のデータをインポートした際、999件目がエラーだった場合の挙動を確認してください。

• 全件ロールバック：1件でもエラーがあれば、1件も取り込まない（整合性が保ちやすい）。
• 部分取り込み：エラー以外は取り込み、エラー行だけがログに残る（スピード重視だが、二重登録のリスクがある）。

ベンダーの「実力」を見抜く5つのキラー質問リスト

商談の終盤、以下の質問を投げてみてください。回答が曖昧だったり、「エンジニアに確認します」を繰り返したり、あるいは「それは将来的なロードマップに含まれています」という回答ばかりであれば、そのベンダーの実務理解度は低いと判断できます。

【比較表】主要SaaS・パッケージの「運用管理機能」仕様比較

実務でよく比較される3つのカテゴリにおける、管理機能の標準的な仕様を比較します。※各製品のプランにより異なりますので、詳細は公式ドキュメント（例：Salesforce価格・仕様ページ、freee人事労務価格ページ等）を確認してください。

導入後に後悔しないためのステップバイステップ確認手順

選定の最終段階で、以下のステップを踏むことを推奨します。

ステップ1：テストデータの準備

ベンダーに用意されたきれいなデータではなく、自社で過去に発生した「汚いデータ」（住所が長い、記号が含まれる、空白がある等）を数件用意します。

ステップ2：サンドボックスでの「破壊テスト」

契約前に検証環境を借り、以下の操作を試します。

• 意図的にエラーが起きるデータをインポートし、エラーログがどう出るか見る。
• 一つのアカウントで同時ログインし、排他制御（後から書き換えた方が勝つのか、エラーになるのか）を確認する。
• 管理者権限を削除しようとしてみる（セルフロックアウト防止策の有無）。

ステップ3：公式ドキュメントの「制限事項」を読み込む

営業資料には「できること」しか書いてありません。公式ヘルプセンターや開発者ドキュメント（API Reference）の「制限（Limits）」や「注意点」のセクションを熟読してください。そこに、将来的な拡張性の限界が隠されています。

まとめ：実務に耐えうる「本物のシステム」を選ぶために

デモで感動した機能は、導入して3ヶ月もすれば「当たり前」になります。しかし、ログが不親切なことや権限設定が不自由な不満は、システムをリプレースするまで、毎日管理者を苦しめ続けます。

「このシステムは、私たちがミスをしたときに助けてくれるか？」

この視点を持ってベンダーと向き合うことが、失敗しないIT導入の第一歩です。もし、現在導入済みのシステムが「ログも出ない、連携も手動」という状態で限界を迎えているのであれば、SaaSコストとオンプレ負債を断つ「標的」と現実的剥がし方で解説しているような、アーキテクチャの根本的な見直しを検討すべき時期かもしれません。