社内IT満足度調査の実施と活用法

社内ヘルプデスクのログを横断集計すると、パスワードやSaaSアクセスの小障害が全体の問い合わせの2〜3割、1件あたり十数分のロスに至ると報告されるケースは珍しくありません。現場の観察でも、日次の“デジタル摩擦”が月間でまとまった生産性損失につながる構図はよく見られます。規模が大きい組織ほどコストインパクトは無視できません。それでも、IT部門の意思決定が一次のチケットデータに偏り、従業員の体感品質が定性的な声に留まりがちなのはよくあることです。だからこそ、社内IT満足度調査を定常化し、定量と定性を結合した運用に変えることは、業務改善とシステム効率化を同時に前進させる実装テーマになります。ここでは、調査の設計から配信・収集、分析、そしてアクション接続までを、CTOやエンジニアリーダーの視点で具体的に解説します。¹

調査設計の要点：何を測り、どう短く正確に測るか

最初に決めるべきは指標のスコープと測定負荷です。全社向けの年次深掘りと、継続改善のための四半期ライト版を併用すると、長期トレンドと短期改善の両輪を回しやすくなります。スコアは、体感満足度を測るCSAT（Customer Satisfaction）²、IT起因の業務負荷を測るCES（Customer Effort Score）³、主要システムの使いやすさを測るSUS（System Usability Scale）⁴を押さえ、さらにITサポートの応答性やリモート環境の安定性といった運用品質のドライバー設問を数問添えて、回答時間を3分以内に制御します。尺度は5件法または7件法のリッカート（段階評価）を用い、アンカー文言は一貫させます。⁵ 信頼性はパイロットでCronbach’s α（質問同士の一貫性を示す指標）が0.7以上を目標に内的整合性を確認し、冗長な質問が見つかれば削除して最小設問数に絞り込みます。⁶ サンプルは全員配信を軸にしつつ、部門や雇用形態で層化して偏りを評価します。匿名化は率直さを高めますが、改善フォローのために任意の連絡可否トグルを最後に置くと、深掘りが必要なケースだけ同意の上で接続できます。

システム観点では、スキーマ設計が肝です。設問は安定ID、型、設問文、スケール、重みを持たせ、配信時にバージョンを凍結して再現性を担保します。スコアは0〜100に正規化し、可視化・比較を容易にします。以下は設問スキーマの最小例です。

{
  "id": "q_csat_overall",
  "text": "IT環境全体にどの程度満足していますか？",
  "scale": {"min": 1, "max": 5, "anchors": ["不満","やや不満","どちらでもない","やや満足","満足"]},
  "weight": 1.0,
  "category": "outcome"
}

計算はクライアントでもサーバでも構いませんが、計算式はリポジトリで管理し、データパイプラインのバージョニングに含めます。正規化のサンプルを示します。

from typing import List, Dict

def normalize_likert(value: int, min_v: int = 1, max_v: int = 5) -> float:
    return (value - min_v) * 100.0 / (max_v - min_v)

def composite_score(answers: Dict[str, int], schema: List[Dict]) -> float:
    total, weight = 0.0, 0.0
    for q in schema:
        v = answers.get(q["id"])  # Noneはスキップ
        if v is None: continue
        total += normalize_likert(v, q["scale"]["min"], q["scale"]["max"]) * q.get("weight", 1.0)
        weight += q.get("weight", 1.0)
    return total / weight if weight else 0.0

設問例とドライバー仮説：少数精鋭で因果に迫る

アウトカムは「全体満足」「業務の進めやすさ」「主要システムの使いやすさ」の三本柱に集約し、ドライバーには「障害の頻度」「ヘルプデスクの初動時間」「SaaSアクセスの安定性」「ノートPCの起動時間」など運用が直接制御可能な要因を配置します。自由記述は1問だけ残し、名詞密度の高いコメントを集めるために「最近最も作業を止めたITの出来事」を尋ねると、具体的な改善起点を得やすくなります。仮説は既存のメトリクスから先に置きます。例えば、月次のWindowsパッチ適用直後にSUSが低下しているなら、パッチメンテナンスのウィンドウと事前告知を検証項目に入れる、といった具合です。

配信と収集：SSO・トークン・リマインドを設計する

配信チャネルはSlackやTeams、メールの三点で重層化します。SSO（シングルサインオン）連携で本人性を確保しつつ、回答データから個人識別子を切り離す設計にすると、匿名性と重複排除を両立できます。クリック一発で回答が始まるマジックリンクを用い、トークンは一度きり有効、期限つき、かつ権限のない第三者には無意味な署名付きにします。リマインドは行動科学の定石に沿って48時間後と締切前日の二回に抑え、配信負荷を最小化します。Slack配信の最小実装は以下の通りです。

import os, time, requests

def post_slack(token: str, channel: str, text: str):
    url = "https://slack.com/api/chat.postMessage"
    for _ in range(3):
        r = requests.post(url, headers={"Authorization": f"Bearer {token}"}, json={"channel": channel, "text": text})
        if r.status_code == 429:
            time.sleep(int(r.headers.get("Retry-After", "1")))
            continue
        r.raise_for_status(); break

token = os.getenv("SLACK_BOT_TOKEN")
post_slack(token, "#company-all", "3分で完了：IT体験アンケート → https://survey.example.com/t/{token}")

重複排除はトークンの状態遷移をNotUsed、Opened、Submittedの三段で管理し、Submitted以外は期限後に失効させます。回答時間は中央値で120秒前後が目安で、これを超える場合は設問が多すぎるかUIが複雑である可能性があります。回答率は社内平均で40〜60%が現実的なレンジで、エグゼクティブがメッセージを添えるとプラス10ポイント程度の押上げが期待できます。⁷ 部門別の回答率をモニタし、偏りが大きい部門にはローカルリマインドを依頼します。ダッシュボードは日次更新で十分ですが、締切前日は1時間更新に切り替えると取りこぼしを防げます。

回答率のヘルスチェックとKPI

KPIは回答率だけでなく、自由記述率、中央値回答時間、無回答率、モバイル比率を併せて追います。無回答や極端な同一選択が多い場合はサーベイ疲れが疑われるため、休止期間の挿入や設問の入替で介入します。データ基盤にはイベントログと調査結果をスキーマレベルで分離し、ビューで結合して可視化します。回答率の簡単な集計は次のSQLで十分です。

SELECT dept, COUNT(*) FILTER (WHERE submitted_at IS NOT NULL)::float / COUNT(*) AS response_rate
FROM survey_audience
GROUP BY dept
ORDER BY response_rate ASC;

分析と意思決定：スコアの“原因”に踏み込む

ダッシュボードでは全社・部門・職種・拠点の順でドリルダウンし、経時変化とイベントをタイムラインで重ねます。ヒートマップでドライバー設問とアウトカムの相関を視覚化し、相関に留まらず多変量で寄与度を推定します。重回帰や木ベースのモデルで標準化係数やShapley値（要因ごとの貢献度を公平に割り振る考え方）を算出すれば、どの運用施策が効率化と満足度向上に効いているかを示せます。次の例はPythonでドライバー分析を走らせ、寄与度を求めるミニマムなコードです。

import pandas as pd
from sklearn.preprocessing import StandardScaler
from sklearn.ensemble import RandomForestRegressor
from sklearn.inspection import permutation_importance

# df: 各設問の数値化列、target: overall_score(0-100)
X = df[["helpdesk_sla", "login_stability", "pc_boot", "net_latency"]]
y = df["overall_score"]
X = pd.DataFrame(StandardScaler().fit_transform(X), columns=X.columns)
model = RandomForestRegressor(n_estimators=200, random_state=42).fit(X, y)
imp = permutation_importance(model, X, y, n_repeats=10, random_state=42)
print(sorted(zip(X.columns, imp.importances_mean), key=lambda x: -x[1]))

自由記述は日本語の形態素解析で名詞と動詞を抽出し、ドメイン固有語彙は辞書に追加します。頻出語の単純カウントより、共起でテーマを把握すると改善の粒度が揃います。以下のサンプルはJanomeを使った軽量な前処理です。⁸

from janome.tokenizer import Tokenizer

def extract_terms(text: str):
    t = Tokenizer()
    return [token.base_form for token in t.tokenize(text) if token.part_of_speech.split(',')[0] in ("名詞","動詞")]

分析の目的はレポートではなくアクションです。寄与度の高い要因に対して、ITSMやJiraのバックログに自動で起票し、担当と期限を設定します。重複や既知の既存課題と突合するために正規化キーを用い、変更要求、根本原因分析、コミュニケーション改善などに分類します。以下はJira REST APIで課題を作成する最小例です。

import requests, os
JIRA = os.getenv("JIRA_URL"); AUTH = (os.getenv("JIRA_USER"), os.getenv("JIRA_TOKEN"))
payload = {"fields": {"project": {"key": "IT"}, "summary": "PC起動時間の改善(四半期アンケート)", "issuetype": {"name": "Task"}}}
requests.post(f"{JIRA}/rest/api/2/issue", json=payload, auth=AUTH).raise_for_status()

ROI設計：改善量をコストと時間に翻訳する

意思決定は投資対効果で語る必要があります。例えば、PC起動時間の自己申告スコアが10ポイント改善し、実測でも平均30秒短縮したとします。1日3回の起動で1人あたり1.5分の削減、1,000名で年間約6,000時間の短縮です。平均人件費を仮に時給3,000円とすれば約1,800万円相当の価値で、展開コストが800万円なら初年度でも差引1,000万円の便益になります。チケット件数が12%減る、初動SLA内率が8ポイント上がる、といった運用KPIの改善と合わせて、業務改善の実効性を可視化します。ABテストが可能な変更なら、拠点や部門をブロックランダム化し、2〜4週間で差分効果を推定します。必要サンプルは効果量と分散から算出し、回答率を見込んだ配信母数に逆算します。

運用に組み込む：ガバナンス、頻度、透明性

四半期のライト調査を定例化し、年次の深掘りで設問の棚卸しと基準改定を行うのが現実的です。変更ログはバージョンとして公開し、スコアの連続性が途切れた場合は断層を注記します。データの取り扱いは最小特権で、回答データと社員マスタは論理的に分離し、集計ビューでのみ結合します。匿名性の説明は配信前に明確化し、自由記述の引用は個人が特定されない形に要約して共有します。結果は社内ポータルで全社共有し、IT部門だけで完結させないことが信頼の前提になります。あわせて、OKRやロードマップとリンクさせ、スコアの改善がどのイニシアチブで達成されたのかをトレーサブルにします。参考として、関連する実装ガイドや運用設計の記事も公開されています。

まとめ：データで“感じ”を動かし、行動につなげる

社内IT満足度調査は、運用現場の肌感を裏づけるだけの儀式ではありません。標準化したスキーマ、短時間で答えやすい設計、SSOと署名トークンによるセキュアな配信、そしてドライバー分析と自由記述のテーマ抽出を組み合わせることで、意思決定の質を引き上げ、業務改善とシステムの効率化を一体で前進させられます。次の四半期に向けて、小さなパイロットから始めても十分です。設問を10問以内に整理し、Slackで配信し、ダッシュボードで寄与度を眺め、Jiraに自動起票するところまでを一気通貫で作ってみませんか。あなたの組織にとって、まず測るべき体験の痛点はどこにありますか。今日の一歩が、来期の数字と現場の笑顔の両方を変えていきます。

参考文献

Forbes Councils. Aligning Technology With Improved Employee Experience. https://councils.forbes.com/blog/aligning-technology-with-improved-employee-experience
moin.ai. Customer Satisfaction Score (CSAT). https://www.moin.ai/en/chatbot-wiki/customer-satisfaction-score-csat
TechTarget. Customer Effort Score (CES). https://www.techtarget.com/searchcustomerexperience/definition/customer-effort-score-CES
Interaction Design Foundation. System Usability Scale (SUS). https://www.interaction-design.org/literature/article/system-usability-scale
TASO. Designing Likert scales. https://taso.org.uk/libraryitem/designing-likert-scales/
GMO Research. 信頼性と妥当性（Cronbachのα係数の概説を含む）. https://gmo-research.ai/research-column/reliability-and-validity
Culture Amp. What is a good survey response rate? https://www.cultureamp.com/blog/what-is-a-good-survey-response-rate
ITトレンド. テキストマイニングとは？形態素解析の基本も解説. https://it-trend.jp/textmining/article/124-0032