社内システムの導入プロジェクトは、稼働日をもって完了と扱われる。しかし、使う人がそれを使いやすいと感じているかは、誰も測っていない。
デジタル庁は、「政府情報システムにおける利用者満足度評価の導入に関する最近の取組」へ、**事業者向け勉強会の実施を追加した。**当該ページおよび同庁のお知らせ一覧とも、2026年8月12日の更新として掲載されている。
同ページによれば、この勉強会は令和8年8月6日（木）に実施され、申込事業者数128、参加者数366名とされている。
政府情報システムの利用者評価の仕組みについては、内閣府の規制改革推進会議に提出された資料（2025年11月7日、デジタル庁 統括監理／サービスデザイン）でも扱われている。同資料等によれば、この仕組みは5段階評価を軸にした簡素な質問設計を特徴とし、申請手続の完了画面への設置が想定されている。また、デジタル庁のウェブサイトでは2024年6月からユーザレビューツールが試験的に導入され、満足度や自由記述による意見の収集が行われてきたとされる。
要点は仕組みの詳細ではない。「行政のシステムが、使った人の評価を集める前提で作られ始めている」という方向性である。
**なお、以下で述べる民間企業への応用は、GXOによる整理である。**行政の仕組みをそのまま社内システムへ持ち込むことを推奨するものではない。**行政手続と社内業務システムでは、利用者の属性、利用の頻度、利用者と提供者の関係がいずれも異なる。**前提の差を調整したうえで、考え方の一部を参考にできる、という位置づけである。
この記事を読むべき人
- 業務システムを導入したが、現場で思ったほど使われていない会社
- システム投資の効果を経営会議で説明できずにいる会社
- 「導入したのに、結局Excelに戻っている」という状態を放置している会社
- これからシステムの発注を予定していて、要件をどう書くか決めかねている会社
- ベンダーからの納品を受け入れる基準が、動作確認だけになっている会社
FREE DOWNLOAD
中小企業のDX推進「失敗を防ぐ5ステップ」ガイドを無料でお送りします
多くの企業がつまずくポイントを着手順に整理した無料ガイド。相談する前に、自社の現在地と進め方を掴めます。
「稼働」と「定着」は別の事象である
多くのシステム導入プロジェクトは、次の形で終わりがちである。以下はGXOが実務で確認してきた典型として整理したものであり、頻度を測定した結果ではない。
要件定義 → 設計 → 開発 → テスト → 本番稼働 → プロジェクト完了
この流れの中に、「使われているか」を確認する工程が存在しない。
稼働は、システムが動く状態になったことを指す。**定着は、対象の業務がそのシステムで回るようになったことを指す。**この2つの間には、しばしば長い距離がある。
そして、**プロジェクトの体制は稼働日で解散する。**ベンダーの契約は納品で終わり、社内のプロジェクトメンバーは元の業務に戻る。定着を見届ける人が、組織上いなくなる。
結果として起きるのが、次の状態である。
- システムは動いているが、一部の担当者しか使っていない
- 入力はされているが、実際の業務判断は別の表計算ファイルで行われている
- 使いにくい箇所を現場が回避策で乗り切っており、誰も報告していない
- 稼働から1年経っても、投資対効果を説明できる材料がない
**この状態は「失敗」として認識されない。**システムは動いているためである。しかし、投資の観点では成果が出ていない。
なぜ満足度を測るのか
「使われているか」を測る方法はいくつかある。ログイン数、機能別の利用回数、処理件数。これらは客観的で、取得も容易である。
一方で、利用状況の数字だけでは分からないことがある。使っているが、不便を我慢しているのか。
行政の取組で採られているような、5段階評価と自由記述を組み合わせる形式には、この点で意味がある。数字で全体の傾向を捉え、自由記述で理由を拾う。
そして重要なのは、聞くタイミングである。申請手続の完了画面に設置するという設計は、「その業務を終えた直後」に聞くという発想である。
この「業務の完了時点で聞く」という考え方は、前提の差を調整すれば社内システムにも参考にできる。**月次のアンケートではなく、業務の完了時点で1問だけ聞く。**回答率も、内容の具体性も変わってくる。ただし、行政手続は不特定多数が一度だけ使うのに対し、社内システムは同じ人が毎日使う。毎回聞くと負担になるため、頻度の設計は社内向けに調整する必要がある。
社内システムで、今日から測れること
大がかりな仕組みは要らない。次の3段階で始められる。
段階1：利用のログを見る。 多くの業務システムは、誰がいつログインしたかの記録を持っている。**まず、対象者のうち何割が直近1か月で使ったかを出す。**この1つの数字だけで、定着の実態がかなり見える。
段階2：使っていない人に理由を聞く。 段階1で使っていない人が特定できる。その人たちに、なぜ使っていないかを聞く。「使い方が分からない」「自分の業務では必要ない」「別の方法のほうが早い」——理由によって、打ち手がまったく違う。
理由が「別の方法のほうが早い」だった場合、それは現場の怠慢ではなく、設計の問題である可能性が高い。
段階3：業務の完了時点で1問聞く仕組みを入れる。 5段階の評価と、自由記述を1つ。質問を増やすと回答率が落ちるため、増やさない。
**段階1と2は、システムに手を入れずに今週できる。**段階3は改修が必要になるが、規模は小さい。
「使われない」の4分類と、それぞれの打ち手
段階2で理由を聞くと、回答はおおむね4つに分かれる。そして、分類を間違えると打ち手を間違える。
分類1：業務の流れと合っていない。 「システムに入力する前に、別の紙を見ないと分からない」「入力の順序が実際の作業順と逆」といった声である。**これが最も多く、最も根が深い。**原因は要件定義の段階で、実際の作業手順まで踏み込まなかったことにある。
打ち手は改修だが、**改修する前に、現場が実際にどういう順で作業しているかを観察する必要がある。**ヒアリングだけでは出てこない。「そう言われればそうしている」という無意識の手順が、たいてい原因である。
分類2：操作が分からない。 研修が稼働直前に1回だけ行われ、その後フォローがない場合に起きる。**打ち手は教育だが、全員向けの再研修は費用対効果が低い。**実際には、特定の数機能でつまずいていることが多いため、つまずいている箇所を特定して、その部分だけの短い手順書を作るほうが効く。
分類3：使う価値が伝わっていない。 「入力しても、自分には何のメリットもない」という声である。入力する人と、その情報で恩恵を受ける人が違う場合に必ず起きる。
打ち手は改修でも教育でもない。**入力した情報がどう使われ、結果として何が良くなったかを、入力する人に返すことである。**これは仕組みではなく運用の話で、費用はほとんどかからない。にもかかわらず、最も実施されていない。
分類4：そもそもその業務に必要がない。 対象者の設定が広すぎた場合である。**打ち手は「対象者を絞る」であって、使わせることではない。**利用率という数字を追うと、この分類に対しても使わせようとしてしまう。必要のない人に使わせるのは、純粋な工数の損失である。
**分類1と3を分類2だと誤認して、研修を繰り返す会社は多い。**研修を増やしても利用率が上がらない場合、分類を疑う価値がある。
稼働後の見直しを、契約と会議体に組み込む
定着を見届ける人がいなくなる問題への対処は、「見る場」を先に予定として入れておくことである。
実務的には、次の形にする。
**稼働1か月後：不具合と操作上の問題の洗い出し。**この時期は使い方の問題が中心になる。まだ効果の話をしても意味がない。
**稼働3か月後：利用状況の確認。**段階1の数字を出す。**ここで見るのは全体の割合ではなく、役割ごとの想定と実績の差である。**毎日使う想定の担当者が使っていないのか、月次でしか使わない役割の人が今月まだ使っていないだけなのかで、意味がまったく違う。役割別に「どのくらいの頻度で使うはずか」を先に置いておくと、この判断ができる。
**稼働6か月後：効果の確認。**導入前に測った数字と比較する。**測っていなければ、ここで何も言えない。**だからこそ、導入前の測定が要る。
**この3回の会議を、稼働前にカレンダーへ入れておく。**プロジェクトが解散した後に「そういえば見直そう」となることは、ほぼない。
そして、**ベンダーとの契約に、少なくとも1回目と2回目への参加を含めておく。**参加してもらえれば、操作面の問題をその場で切り分けられる。含めていなければ、都度の有償対応になる。
発注時に、要件へ入れるべきこと
これから発注する場合、「使われること」を要件に含めることができる。
多くの要件定義書は、機能の一覧で構成されている。「何ができるか」は書かれているが、「どのくらい使われるべきか」は書かれていない。
要件に加えられる項目を挙げる。
項目1：利用状況を取得できること。 誰がどの機能をどのくらい使ったかを、後から確認できる仕組み。これを要件に入れておかないと、後付けの改修になる。
項目2：主要な業務の完了までの操作数・所要時間。 「この作業は何クリック以内で完了できること」という形の要件。機能があることと、使いやすいことは別である。
項目3：稼働後の一定期間、利用状況を確認する場を設けること。 契約上、稼働から数か月後にレビューの場を持つことを定めておく。これがないと、稼働日で関係が終わる。
項目4：受入検査に、実際の利用者による確認を含めること。 情報システム部門の動作確認だけでなく、実際に日常業務で使う担当者が触る工程を入れる。**ここで出てくる指摘は、稼働後に出てくる指摘と同じものである。**先に出しておくほうが安い。
**このうち項目4が、費用対効果が最も高い。**追加費用がほとんどかからず、稼働後の手戻りを大きく減らせる。
経営会議での説明が変わる
利用状況を測っていると、経営への説明の形が変わる。
測っていない場合の説明：「システムは予定どおり稼働しました。」 これに対して経営が判断できることは、ほとんどない。
測っている場合の説明：「対象者50名のうち、直近1か月で使用したのは32名です。使っていない18名のうち、12名は業務上必要がなく、6名は操作に不安があると回答しています。この6名向けに追加の説明を実施します。」
**後者は、次の行動が明確である。**そして、追加投資が必要かどうかの判断もできる。
さらに、次のシステム投資を検討する際、**前回の投資がどう使われたかという実績が判断材料になる。**これがない会社は、毎回ゼロから「今度こそうまくいくはずだ」という前提で投資を決めることになる。
経営者が一度、自分で操作してみる
数字を集める前に、費用ゼロで実行できることがある。経営者自身が、そのシステムで実際の業務を1件、最初から最後までやってみることである。
デモンストレーションを見るのではない。実際の入力を、実際の画面で、手順書を見ずに行う。
これを行うと、報告では上がってこないことが分かる。入力項目の多さ、画面遷移の回数、必須項目の分かりにくさ。現場が「使いにくい」と言うときの具体的な中身が、体感として理解できる。
**そして、現場からの改善要望に対する判断の質が変わる。**体感していない状態では、要望が贅沢なのか切実なのかを判断できない。判断できないと、要望は「予算がついたら」として先送りされる。
所要時間は、多くの場合30分程度である。投資対効果という観点で、これに勝る施策は少ない。
測ることの副作用に注意する
一方で、注意点もある。
注意1：評価が低い担当者を責める材料に使わない。 満足度が低いという結果が、現場への叱責につながると、次から正直な回答が返らなくなる。測定の目的を先に明示しておく必要がある。
注意2：ベンダーの評価と直結させすぎない。 使われない理由が、システムの品質ではなく業務設計にある場合も多い。ベンダーの責任範囲と、自社の責任範囲を分けて考える。
注意3：数字を上げること自体を目的にしない。 利用率を上げるために不要な入力を義務付ける、といった本末転倒が起き得る。業務側の数字と併せて見る。
よくある質問
Q. 小規模なシステムでも測る意味はあるか。 A. ある。**むしろ利用者が少ないほど、1人の回答から得られる情報が具体的である。**10人の利用者なら、全員に直接聞くことも現実的である。
Q. 現場に聞くと、不満ばかり出てくるのではないか。 A. 出てくる。**ただし、不満が出ること自体は問題ではない。**聞かなければ、不満は表に出ないまま回避策として現場に蓄積し、システムが使われない理由になる。表に出たほうが対処できる。
Q. 稼働から数年経ったシステムでも、今から測れるか。 A. 測れる。**ログイン記録が残っていれば、段階1は今日実施できる。**古いシステムほど、実際には使われていない機能が多いことが分かる場合がある。次の刷新の際、その機能を作らなくて済む。
Q. ベンダーに利用状況の取得を頼むと、追加費用がかかると言われた。 A. 既存システムへの後付けであれば費用は発生し得る。**ただし、ログの出力だけであれば大がかりな改修にならないことも多い。**まず、現在どういうログが取得されているかを聞くところから始めたい。
Q. 満足度の目標値はどのくらいに置くべきか。 A. 一律の基準はない。**まず目標を置かずに測り、出た数字を見てから決めるほうが現実的である。**先に他社水準を持ち込むと、届かない数字に見えて取り組み自体が止まりやすい。
Q. 行政の仕組みをそのまま社内に持ち込めるか。 A. 質問設計の考え方——簡素で、業務の完了時点で聞く——は応用できる。**一方、行政の手続きは不特定多数の利用者が一度だけ使う性質があり、毎日使う社内システムとは前提が違う。**社内システムでは、毎回聞くと負担になるため、頻度を調整する必要がある。
Q. 使われていないことが判明した場合、どうすべきか。 A. すぐに改修するのではなく、理由の特定を先に行う。業務に合っていないのか、操作が分からないのか、そもそも必要ないのか。「必要ない」が理由なら、改修ではなく対象者の見直しが正しい対処になる。
Q. 受入検査に現場を入れると、期間が延びないか。 A. 検査期間は延びる。**一方で、稼働後に出る指摘が減るため、全体では短くなることが多い。**稼働後の改修は、体制が解散した後に行うため、単価も期間も不利になりやすい。
導入後に使われる仕組みの設計から相談したいとき
システム投資が成果につながらない原因は、多くの場合、機能の不足ではない。業務の流れに合っていないこと、そして合っていないことに誰も気づかないまま数年が経つことにある。
これから発注するシステムについて、要件の書き方や受入基準の設計から相談したい場合は、要件と受入基準の設計で対応している。既に動いているシステムが使われない原因を突き止め、業務側の設計まで遡って見直すのであれば業務設計から作り直すが該当する。
自社のシステム投資の現在地と、次に着手すべき順序を整理したい場合はシステム投資の現在地を確認する、投資対効果の見立てを整理したい場合は投資対効果を整理するから始められる。ベンダーからの提案や見積もりの内容を第三者の視点で確認したい場合は、提案と見積もりの妥当性を確認するで受け付けている。
なお、業務の流れを可視化する手法は業務フロー図の基本（As-Is/To-Be）、要件定義の進め方は業務システム要件定義書のテンプレートで扱っている。本稿は、稼働後の利用状況をどう測るかに絞っている。
参照した情報
- デジタル庁 お知らせ: https://www.digital.go.jp/news
- 内閣府 規制改革推進会議 提出資料「政府情報システムの利用者評価の仕組みについて」（2025年11月7日、デジタル庁 統括監理／サービスデザイン）: https://www8.cao.go.jp/kisei-kaikaku/kisei/meeting/wg/2501_06ai/251107/ai05_04.pdf
- デジタル庁: https://www.digital.go.jp/
「政府情報システムにおける利用者満足度評価の導入に関する最近の取組」へ事業者向け勉強会の実施が追加された旨、当該ページおよび同庁お知らせ一覧における掲載が2026年8月12日である旨、および勉強会の実施日（令和8年8月6日）・申込事業者数128・参加者数366名は、上記デジタル庁のページの記載に基づく（2026年8月14日取得）。
**5段階評価を軸とした質問設計、申請手続の完了画面への設置が想定されている点、および2024年6月からデジタル庁ウェブサイトでユーザレビューツールが試験導入されてきた点は、上記の規制改革推進会議提出資料およびその内容を扱った公開情報に基づく記載であり、細部については当該資料を直接確認してほしい。**勉強会の具体的な内容、対象、開催時期については本稿では扱っていない。
**本稿の主たる内容である社内システムへの応用は、行政の仕組みをそのまま適用することを推奨するものではない。**行政手続と社内業務システムでは利用者の性質と利用頻度が異なる。3段階の測定手順、発注時に加える4項目、および測定時の3つの注意点は、GXOが導入支援の経験から整理したものであって、デジタル庁が示した基準ではない。政府情報システムの調達・評価に関する制度上の要件については、本稿では扱っていない。
