社内IT問い合わせで対応が止まりやすいのは、利用者の説明が下手だからではありません。多くの場合、フォーム側が「何を書けば処理できるのか」を示せていないことが原因です。
たとえば「ログインできません」だけでは、対象システム、発生時刻、端末、エラー表示、本人だけの問題か全社的な問題かが分かりません。「共有フォルダに入れるようにしてください」だけでは、対象者、フォルダ名、必要権限、承認者、利用目的が分からず、確認の往復が発生します。
この記事では、社内IT問い合わせフォームを「受付箱」ではなく、依頼者と情シスの認識をそろえる業務設計として作り直す方法を整理します。ポイントは、すべての情報を一度に聞くことではなく、依頼種別ごとに「作業開始に必須の情報」「あると調査が速い情報」「聞かない情報」を分けることです。
まず決めるべきは「自由記述を減らす」ではなく「対応が止まる条件を潰す」こと
フォーム改善でよくある失敗は、曖昧な依頼を減らそうとして必須項目を増やしすぎることです。入力項目が多いフォームは、利用者に避けられます。結果として、チャットやメールで「急ぎです」と直接連絡され、フォーム運用そのものが形骸化します。
最初に見るべきなのは、過去の問い合わせで情シス側が追加確認した内容です。直近1〜3か月分の問い合わせを見て、差し戻し理由を次のように分類します。
- 対象者が分からない
- 対象システム・機器が分からない
- 希望日・期限が分からない
- 権限や承認者が分からない
- 障害の発生条件やエラー内容が分からない
- 添付ファイルや画面キャプチャがない
この分類で何度も出てくるものだけを、フォーム項目にします。逆に、担当者が見ていない項目、後から台帳で確認できる項目、全依頼に必須ではない項目は、最初から必須にしないほうが運用しやすくなります。
問い合わせ種別ごとの必須項目を決める
社内の問い合わせをプリザンター（Pleasanter）で運用していて、何度も往復になりやすかったのは、共有フォルダやシステム権限の追加依頼でした。「〇〇さんを共有フォルダに入れてください」「このシステムを見られるように」「前任者と同じ権限で」という依頼は、一見単純ですが、受ける側からするとほとんど作業できません。どのフォルダか、読み取りだけか更新も要るか、誰の承認を取っているか、いつから必要か、一時的か恒久的か。ここが分からず、結局聞き返すことになります。急ぎの依頼ほど「今日中に必要です」だけ先に来て、肝心の対象システムや権限種別がなく、急ぎたいのに確認で止まる、ということもありました。
そこで、最初に問い合わせ種別を選ばせ、その種別によって表示項目を分岐させる形にしました。「障害報告」を選んだときだけエラーメッセージ欄と画面キャプチャ添付欄を出し、「アカウント申請」では承認者欄と利用開始希望日を出す、という分岐を実際に組んでいます。問い合わせ種別ごとに表示項目と必須項目を整理しておくと、受付時点で必要な情報が揃いやすくなり、確認の往復も減りました。
社内IT問い合わせを1つの自由記述欄で受けると、依頼者は何を書けばよいか迷います。最初の設問で問い合わせ種別を選ばせ、その回答に応じて必要項目を変えるのが基本です。
| 問い合わせ種別 | 必須にする項目 | 任意でよい項目 | 差し戻し基準 |
|---|---|---|---|
| アカウント作成・変更 | 対象者、部署、対象システム、利用開始希望日、必要権限、申請理由、承認者 | 備考、過去利用の有無、関連チケット番号 | 対象システム、権限、承認者のいずれかが不明な場合 |
| 権限追加・共有フォルダ | 対象者、フォルダ名またはURL、閲覧・編集などの権限、利用目的、承認者 | 利用終了予定日、同じ権限を持つ参考ユーザー | フォルダ名、権限、承認者が不明な場合 |
| 障害報告 | 対象システム、発生日時、影響範囲、端末種別、エラー内容、試した対応 | 画面キャプチャ、ネットワーク環境、再現手順 | 対象システムまたは発生状況が特定できない場合 |
| 端末・周辺機器 | 利用者、端末管理番号、機器名、設置場所、困っている内容、希望日 | 写真、発生頻度、代替機の要否 | 対象機器や設置場所が不明な場合 |
| ソフトウェア・設定依頼 | 対象者、ソフトウェア名、設定内容、利用目的、希望日、費用負担部門 | ライセンスの候補、参考URL | 利用目的、費用負担、承認者が不明な場合 |
ここで重要なのは、「情シスが知りたいこと」ではなく「作業開始に必要なこと」を必須にすることです。たとえば障害報告では、端末のIPアドレスを必須にするよりも、対象システム、発生日時、エラー内容、影響範囲を先に集めたほうが一次切り分けに役立ちます。
「前任者と同じ権限」は、そのままコピーしない
権限追加の依頼では、「前任者と同じ権限でお願いします」という書き方がよくあります。現場としては一番説明しやすい依頼ですが、情シス側ではそのまま受けないようにしています。前任者が異動前の古い権限や、本来不要なフォルダまで見られる権限を持ったままになっている可能性があり、そのままコピーすると不要な権限を引き継いでしまうためです。そこでフォームでは、「前任者名」だけでなく、対象システム、必要な権限、利用目的、承認者を必須にし、必要な範囲だけを確認して付与する形にしています。フォームの必須項目は、確認の往復を減らすためだけでなく、不要な権限をそのまま引き継がないための安全装置にもなります。
必須・任意・聞かない情報の判断基準
フォーム項目を増やす前に、各項目を次の3段階で判定します。
| 区分 | 判断基準 | 例 |
|---|---|---|
| 必須 | その情報がないと作業開始・一次切り分け・承認確認ができない | 対象者、対象システム、権限、承認者、発生日時 |
| 任意 | あると対応が速くなるが、なくても初動は可能 | 画面キャプチャ、参考ユーザー、補足説明 |
| 聞かない | 別システムで確認できる、利用目的に対して過剰、ほとんど使わない | 不要な個人情報、担当者が参照しない管理コード、全依頼共通ではない技術情報 |
個人情報を含む問い合わせフォームでは、取得した情報を必要な範囲で正確に保ち、利用する必要がなくなったときは消去するよう努めること、また漏えい等を防止する安全管理措置が求められます。フォームで「念のため」情報を集めすぎると、管理すべき情報も増えます。
https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/
フォームの設問は「依頼者の言葉」から始める
依頼者は、情シスの内部分類を知りません。「アカウントプロビジョニング」「アクセス権限申請」「インシデント切り分け」と書かれても、自分の依頼がどれに当たるか迷います。
最初の選択肢は、次のように依頼者の言葉に寄せます。
- ログインできない・パスワードを忘れた
- 新しい人のアカウントを作りたい
- 共有フォルダやシステムに入れるようにしたい
- パソコン・プリンター・周辺機器で困っている
- ソフトウェアを使えるようにしたい
- 迷ったので相談したい
その後、裏側の分類として「障害」「申請」「権限」「端末」「相談」に振り分けます。依頼者に分類を考えさせるのではなく、フォームが自然に分類する設計にします。
条件分岐を使うと、入力負担を増やさず情報を集められる
実際にフォームを入れてから、確認の往復は目に見えて減りました。特に効いたのは「種別を最初に選ばせて分岐させる」ことです。なかでも画面キャプチャの効果は大きく、「ログインできません」と書かれていても、実際にはパスワード誤りなのか、権限不足なのか、システムエラーなのか、ブラウザの警告なのかは分かりません。キャプチャがあるだけで、「どんなエラーが出ていますか」という往復がほぼ消えました。
業務影響を選択式にしたのもよかった点です。「自分だけ」「部署内の複数名」「全社」「外部連携に影響あり」のように選ばせると、同じ「使えない」でも、1人だけ困っているのか、部署全体の業務が止まっているのかで対応順を判断できます。ただし、必須項目を増やしすぎるのは逆効果でした。フォームが長すぎると、現場は入力する前に嫌になり、フォームを使わずチャットで「急ぎです」と直接来るようになります。これでは結局、情報が足りないまま対応することになります。だから、全部の問い合わせに同じ項目を必須にするのではなく、種別ごとに必要な項目だけを出すのが大事だと感じました。対応が止まる原因は、技術的に難しいからだけではなく、最初の依頼文に作業に必要な情報が入っていないことも多いのです。
Microsoft Formsでは、回答に応じて関連する質問だけを表示する分岐ロジックを設定できます。ただし、公式ヘルプでは、分岐先は後続の質問またはフォーム終了へ進める形で説明されており、前の質問へ戻す設計は避ける必要があります。
https://support.microsoft.com/en-us/forms/use-branching-logic-in-microsoft-forms
Googleフォームでも、回答に基づいて特定のセクションへ送る設計ができます。また、ファイルアップロード設問では、回答者がGoogleアカウントでログインする必要があること、アップロードされたファイルがフォーム所有者のGoogle Driveに保存されることなどの注意点があります。
https://support.google.com/docs/answer/7322334
ServiceNowのService Catalogでは、Catalog UI Policyにより、カタログアイテムフォームの表示や必須・読み取り専用などの挙動を制御できます。大規模な情シスやITSM運用では、依頼種別ごとにカタログ項目を分け、ポリシーで必要項目を制御する設計が現実的です。
https://www.servicenow.com/docs/r/servicenow-platform/service-catalog/c_ServiceCatalogUIPolicy.html
そのまま使える問い合わせフォーム項目ひな型
最初から完璧なフォームを作る必要はありません。まずは次のひな型をベースに、自社のシステム名、承認ルール、保存期間に合わせて調整します。
共通項目
1. 依頼者氏名
2. 部署
3. 連絡先
4. 問い合わせ種別
5. 対象者：本人／代理申請
6. 希望対応日：通常／期限あり／業務停止中
7. 業務影響：自分だけ／部署内複数人／全社／不明
8. 補足事項障害報告の場合に追加
1. 対象システム・アプリ名
2. 発生日時
3. エラーメッセージ
4. 発生頻度：常に／時々／一度だけ
5. 試した対応：再起動／別ブラウザ／別端末／未実施
6. 画面キャプチャ添付権限申請の場合に追加
1. 対象システム・フォルダ名
2. 必要な権限：閲覧／編集／管理者／その他
3. 利用目的
4. 利用開始希望日
5. 利用終了予定日
6. 承認者名：所属長、システム管理者、データ管理者など、対象システムの権限付与ルールに基づく承認者を記入
差し戻し文面もテンプレート化する
フォームを整えても、不足情報は残ります。そのたびに担当者が文章を考えると、対応品質がばらつきます。差し戻し文面もあらかじめ用意しておきます。
ご依頼ありがとうございます。対応に必要な情報が不足しているため、次の内容を追記してください。
- 対象システム名：
- 対象者名：
- 必要な権限：
- 承認者名：
- 利用開始希望日：
上記が確認でき次第、受付を進めます。なお、承認者や権限付与ルールは、社内の権限管理規程、申請フロー、職務分掌、対象システムの管理ルールに基づいて判断します。
緊急度は「急ぎです」ではなく業務影響で判定する
問い合わせフォームに「緊急」だけを置くと、ほとんどの依頼が緊急扱いになります。緊急度は依頼者の主観ではなく、業務影響で選ばせます。
| 緊急度 | 判断基準 | 例 | 対応目安 |
|---|---|---|---|
| 高 | 業務停止、顧客対応停止、複数人に影響 | 全社で認証できない、部署全体で基幹システムに入れない | 受付後すぐに一次確認し、影響範囲、暫定回避策、関係部署への連絡要否を判断する |
| 中 | 代替手段はあるが業務に支障がある | 特定端末だけアプリが使えない、共有フォルダの一部に入れない | 当日または翌営業日を目安に確認し、代替手段の有無と対応予定を案内する |
| 低 | 業務停止はなく、希望日までに対応すればよい | 新規アプリ相談、プリンター追加、権限見直し | 通常受付として扱い、希望日、承認要否、作業予定日を確認して順次対応する |
運用後に見るべき改善指標
フォームは作って終わりではありません。月1回または四半期に1回、次の指標を見ます。
- 差し戻し件数
- 追加確認が発生した割合
- 問い合わせ種別ごとの件数
- 自由記述欄に頻出する単語
- 未入力・誤入力が多い項目
- ほとんど使われていない項目
改善の判断は単純です。追加確認が多い項目は、選択式にする、入力例を入れる、必須化する。ほとんど使われない項目は、任意化または削除する。自由記述に同じ言葉が何度も出る場合は、新しい選択肢として追加します。
公開前チェックリスト
- 問い合わせ種別ごとに、必須項目が分かれている
- 全依頼に共通の必須項目が多すぎない
- 承認者が必要な依頼と不要な依頼が分かれている
- 緊急度を「急ぎ」ではなく業務影響で判定できる
- 画面キャプチャや添付ファイルの扱いを説明している
- 個人情報や添付ファイルの保存先、保存期間、閲覧権限、削除タイミングを確認している
- 差し戻し文面をテンプレート化している
- 月次または四半期で見直す指標を決めている
社内IT問い合わせフォームの目的は、依頼者に詳しい文章を書かせることではありません。依頼者が迷わず入力でき、情シスが初回確認だけで次の作業に進める状態を作ることです。フォームを「説明を求める場所」から「判断に必要な情報が自然に集まる場所」へ変えることで、確認の往復は減り、対応品質も安定します。
コメント