[システム情報] を使って効率的に情報を収集する

前回までの記事で [システム情報] を利用して組織にあるコンピューター (のハードウェア、ソフトウェア、ネットワーク) についての情報を収集できる事を説明したが、今回はその具体的な手順について説明する。

前回説明のように [システム情報] ツールは [スタート] メニューや [ファイル名を指定して実行] から起動できる。画面にそのコンピューターの情報が表示されるのだが、表示される情報はまとめてファイルに保存できるようになっており、ファイルは二つの保存式が選べる。保存形式の一番目はシステム情報ファイル形式という、拡張子が .nfo のシステム情報ツールに固有のファイル形式 (と言っても実際は XML 形式のデータ) で、もう一つはテキスト形式だ。

.nfo 形式のメリットは保存したファイルを [システム情報] ツールで開く事ができる点で、別のコンピューターで保存したファイルを開く事もできる。この場合情報はカテゴリごとにツリーで分類されて表示できるので、特定の項目を探しやすい。
対してテキスト形式の場合は、汎用のデータ形式なので加工しやすく、他のソフトウェアにデータを移行しやすい点だ。テキストはタブ区切りになっているので例えば Excel に読み込んで、必要な所だけ表形式を整えて印刷する事もできる。
どちらの形式を使うのかはその後の利用・管理・整理の方法によって一長一短だが、どうせなら同時に両方の形式で保存しておく事も考慮してよいだろう。

それぞれの形式で保存する操作は以下の通りだ。

システム情報ファイル形式

1. システム情報を起動する
2. [ファイル] – [上書き保存] を選択する
3. [名前を付けて保存] ダイアログで、適当な名前を付け適切な場所に保存する

テキスト形式

1. システム情報を起動する
2. [ファイル] – [エクスポート] を選択する
3. [ファイルのエキスポート] ダイアログで、適当な名前を付け適切な場所に保存する

さてこの方法だといちいちユーザー インターフェイスを使って操作しなければならず、また保存場所を手動で選択、ファイル名も手入力しないといけないので面倒だし、誤操作などを考えるとエンド ユーザーにやってもらうのは難しい。そこで情報を収集して特定の名前で特定の場所に保存する動作をできるだけ自動化する方法を紹介しよう。
[システム情報] ツールにはユーザー インターフェイスを表示せず、情報を収集してファイルに保存する起動オプションがある。これでシステム情報ファイル形式でもテキスト形式でも自動的にファイルとして保存する事ができる。
起動スイッチは次のように指定できる。

msinfo32.exe /nfo pathfilename.nfo    (システム情報ファイル形式の場合)
msinfo32.exe /report pathfilename.txt    (テキスト形式の場合)
※ いずれも path は保存するフォルダのパス、filename は保存するファイル名

参考情報
システム情報 (MSINFO32) の各種スイッチの使い方
http://support.microsoft.com/kb/300887/ja

ファイル名は情報を収集したコンピューターのコンピューター名にしておくと後で分かりやすいのだが、そのためには環境変数 COMPUTERNAME を利用すると便利だ (コマンドに %COMPUTERNAME% と書いておくと、コンピューター名に置き換えられて実行される)。また保存する場所は情報を収集する各コンピューターから利用できるネットワーク上の共有フォルダーにすると良いだろう。
例えば SERVER という名前のコンピューターに SHARE という共有フォルダーがある場合、コンピューター名 TEST のコンピューターで以下のように実行すれば SHARE フォルダに TEST.nfo または TEST.txt という名前で収集した情報が保存される。

msinfo32.exe /nfo SERVERSHARE%COMPUTERNAME%.nfo
msinfo32.exe /report SERVERSHARE%COMPUTERNAME%.txt

利用している環境に併せて保存する共有フォルダのパス名を変えて、実際に [ファイル名を指定して実行] でこれらのコマンドを実行し、情報が保存できる事を確認して欲しい。

さてこのコマンドをさらに簡単に実行するにはバッチファイルにすれば良いのだが、その場合は一つ注意する事がある。[スタート] メニューにショートカットがあるシステム情報ツールの実行ファイル (msinfo32.exe) は Windows XP の場合パスが通っていない場所にあるので、バッチファイルにコマンドとして msinfo32.exe だけ書いても起動できないのだ。バッチファイルやコマンド プロンプトからシステム情報を起動するには、以下のようにフルパスを付けてコマンドを記述しないといけない。

"%ProgramFiles%Common FilesMicrosoft SharedMSInfomsinfo32.exe"

また Windows Vista / Windows 7 の [スタート] メニューのシステム情報のショートカットは Windows XP とは異なる場所の msinfo32.exe を起動する。これに併せてパッチファイルのコマンドも XP の場合とは変えないといけない。

これらを踏まえて簡単なパッチ ファイルを書くと、以下のようになる。

———- (ここから) ———-
@if "%ALLUSERSPROFILE%"=="C:ProgramData" "%ProgramFiles%Common FilesMicrosoft SharedMSInfomsinfo32.exe" /nfo SERVERSHARE%COMPUTERNAME%.nfo
@if "%ALLUSERSPROFILE%"=="C:Documents and SettingsAll Users" %SystemRoot%system32msinfo32.exe /nfo SERVERSHARE%COMPUTERNAME%.nfo
———- (ここまで) ———-

※ Windows XP と Windows Vista/Windows 7 の区別には、環境変数 ALLUSERSPROFILE の内容の違いを利用している。

このバッチファイルを各コンピューターでダブルクリックして実行すれば、それだけでサーバー上の共有フォルダーに各コンピュータ名のついたファイルが作成される。

情報収集についてはまだ書きたい事があるので、もう一回続ける。

広告

[システム情報] の限界

今回は前回の記事で紹介した [システム情報] ツール (msinfo32) について、制限や注意事項を説明する。
システム情報は便利なツールだが万能ではないのでその点について注意しておこう。

まずこのツールでは、ツールを実行したタイミングで実行中のプログラムの情報は収集できるが、インストールされているだけで実行されていないソフトウェアの情報は収集できない。
[スタート] メニューにあるプログラムのグループは調べて表示してくれる ([ソフトウェア環境] – [プログラムのグループ]) ので、インストール時にスタート メニューにグループを作るソフトウェアは分かる場合もあるが、そうでないソフトウェアについては分からない。
もっともそのコンピューターで実行可能なようにインストールされているソフトウェアをすべて調査するというのは (別の記事で説明する予定だが) 本当に難しい事なので、この点で完璧を期したいという人は相当に苦労することになる。

次に、このツールは一応リモート コンピューターに対する情報の収集も可能に作られている。[システム情報] の [表示] – [リモート コンピュータ] を開くと、図のようなダイアログが表示され、[ネットワーク上のリモート コンピューター] を選択してその下のボックスに "\COMPUTERNAME" の形式 (UNC 形式) で接続したいコンビュー名を入力し、[OK] をクリックすれば、そのコンピューターのシステム情報が表示される仕様になっている。

しかし接続先のコンピューターにセキュリティー上の理由でリモートからの管理 (情報の取得を含む) を無効資する設定かされている場合が少なくない。ファイアウォールで接続がブロックされる場合もあるし、接続先で情報を実際に収集するためのプログラムがリモートからの起動を禁止されている場合もある。そのため結構な確率で以下のようなエラー メッセージに出くわすことになる。

computer name への接続を確立できませんでした。ネットワーク パスが正しいか、WMI (Windows Management Instrumentation) にアクセスするのに十分なアクセス許可があるか、WMI (Windows Management Instrumentation) がコンピュータにインストールされているか確認してください。

この問題については以下のようなサポート技術情報も公開されているが、実際に何が問題でどのようにすればリモート接続ができるようになるのか、その調査も手間がかかるし、結局リモート接続したいコンピューターを直接操作する事が必要になる。それならそのコンピューターで直接 [システム情報] を実行した方が早い。
そういう訳でこのツールを使って情報を収集するのなら、各コンピューターで直接実行し、その結果をまとめるのが現実的だろう。

Windows XP SP2 の WMI に関する問題のトラブルシューティング方法
http://support.microsoft.com/kb/875605/ja

次回は実際にこのツールを使って情報を効率的に収集する方法について説明する。

コンピューターの情報を整理する (2)

前回の記事で、あなたがサポートや IT サービスの提供を担当する組織にあるコンピューター (のハードウェア、ソフトウェア、ネットワーク) についての情報を収集し整理し、台帳のような一覧性のある形にまとめておく事の重要性を説明したが、それでは具体的にどのような方法で情報を収集し、メンテナンスするのか。今回はそれについて説明していきたい。

最初に残念な話。あなたがもしコンピューターについて常に最新で細大漏らさぬ詳細な情報を、自動的に収集管理できないかと考えているならこの記事は読むに値しないかもしれない。確かにそうした収集・管理が可能だと謳っているシステムは存在するし、実際にそうしたシステムはかなりな能力を持っている。しかし残念なことに (特に Windows ベースのシステムでは) そのようなシステムは有償かつかなり高価であり、また製品ごとにできる事やその方法、運用形態に特徴がある。もしそうした製品を望むのなら、この記事を読むよりベンダーの営業に話を聞いて見積もりを作らせた方が早いだろう。
とは言えこの記事が全然役に立たないのは悔しいので、有名な製品へのリンクを記事の最後にまとめておいたので、参照していただければと思う。

さてそういう訳で、ここではまず予算もない、高度なスキルも (今のところは) ない担当者であるあなたが、どうすれば最低限必要な情報を、できるだけ簡単で予算のかからない方法で収集できるのか、という事について説明したい。
まず考えられることとして、コンピューター (ハードウェア) の機種・形式・仕様を調べるために、実際にそのコンピュータが使われている場所まで行って、銘板を見て機種形式を確認し、さらに筐体を開いて増設メモリや内蔵機器の有無を調べるという方法がある。もちろんオフィスのデスクの下を這いずり回るのが大好きであればこれを止める気はしないし、そうでなくとも最悪他の手段が取れない場合はそうする事を覚悟しなければならない事もあるだろう。だが大抵の人は (あなたも、そして私も) そんな事はできればやりたくない。
そこで次に考えるのは、何かのソフトウェア ツールでそうした情報を表示してくれるものがないか、という事だ。幸いにして、Windows にはそうした機能を持っているツールが標準で付属している。情報収集の手始めとしては、このツールを使ってみるのがよいだろう。

Windows に標準で付属しているツールは「システム情報」という名前で、ちゃんと [スタート] メニューにも登録されている。

[スタート] -> [プログラム] -> [アクセサリ] -> [システム ツール] -> [システム情報]

もっと簡単に呼び出すなら、Windows Vista 以降の Windows (Windows 7 / Windows Server 2008 など) なら [スタート] メニューの [プログラムとファイルの検索] ボックスに、Windows XP / Windows Server 2003 / Windows 2000 なら [スタート] メニューから [ファイル名を指定して実行] を開いて [名前] ボックスに、以下のコマンドを入力して Enter を押す

msinfo32

参考情報
Windows XP システム情報 (Msinfo32.exe) ツールについて
http://support.microsoft.com/kb/308549/ja

これで下図のような画面が表示され、ツールを実行したコンピュータについての情報が収集・表示される (下の図では "システム名" (コンピューター名) と "ユーザー名" は消してある)。左側のツリーでカテゴリを選択すれば、それに対応する情報が右側のペインに表示される。コンピューターのメーカーや機種・形式・仕様は [システムの概要] が確認できるだけでなく、このカテゴリでは同時に Windows の名称やバージョン、コンピュータ名も表示されるので、「どんなコンピューターが使われているのか」という基礎的な情報であれば、この [システムの概要] だけでも十分だろう。

実際にどのカテゴリでどんな情報が表示されるのかは実際にあなたのコンピュータで実行してみて確認するのが一番手っ取り早い。ぜひ試してみてほしい。

次回はこのツールを使う際の注意点について説明する。

参考資料 (代表的なインベントリ管理、アセット マネジメント管理ソフトウェア / システム)

• System Center Configuration Manager
  http://www.microsoft.com/japan/systemcenter/configmgr/default.mspx
• ソフトウェアライセンス管理・PC資産管理ツール　ASSETBASE（アセットベース）
  http://www.asset-base.jp/index.html
• IT資産管理・ライセンス管理 /License Guard /日立情報システムズ
  http://www.hitachijoho.com/license/
• 情報セキュリティ・資産管理・ログ管理　SKYSEA Client View
  http://www.skyseaclientview.net/product/index.html
• QND Plus、QAW
  http://www.quality.co.jp/products/index.html
• ManageEngine ServiceDesk Plus
  http://www.manageengine.jp/products/ServiceDesk_Plus/
• ManagementCore IT統合管理
  http://www.tjpro.co.jp/products/mcore/index.htm
• 資産管理ASP・SaaSのティーコン・アセット | T-CON Aseet
  http://www.toshiba-finance.co.jp/t-con/service/asset/index_j.htm
• LANDesk Asset Lifecycle Manager
  http://www.landesk.co.jp/Products/Asset-Lifecycle-Management/Index.aspx

コンピューターの情報を整理する (1)

会社内/組織内のヘルプデスクや IT サポートの業務を行う場合、サポートの対象となるコンピューターやソフトウェアには何があるのかを知っておくのは重要だ。
サポート対象となる組織の範囲内で、どのようなコンピューターが使われていて、そのコンピューターではどのようなソフトウェアが利用それているのか調査してまとめておけば、実際のサポートの際に一から情報収集する手間が省けるだけでなく、事前に分かっているコンピューター (ハードウェア) とソフトウェアの環境から問題の原因やその解決方法がある程度絞り込める場合もある。

とは言え実際に稼働している企業 / 組織内環境で、誰がどのような機種・形式・仕様のコンピューターを利用しているのか、またそのコンピューターにはどのようなソフトウェアがインストールされているのかを調査するのは、実は結構面倒な作業である。
もし資産管理が非常に良く行われている企業であれば、会社の資産であるコンピュータについて機種・形式・仕様や現在の利用者が確認できる資料 (資産管理台帳など) が存在するだろうから、ハードウェアについてはそれが利用できるし、ソフトウェアについても会社組織として導入したものであればそのライセンスが資産計上されているだろうから、同じ台帳からわかる場合がある。
しかし現実的に言えば、小規模な企業や事業所でそこまで精緻な管理がされている場合は少なく、ひどい場合は会社として購入したりリースしたりした (そして存在しなければならない) コンピュータが何台なのかも資料が無い場合だってあるだろう。そうなればハードウェアについては実地確認して現況ベースでの情報を得る必要がある。

またソフトウェアについても会社として購入したライセンスならちゃんと台帳に載っているという場合でも、利用者が個人的にインストールした無償利用可能なソフトウェア (フリー ソフトやオープンソース ソフトウェアなど) は把握できない。当然資産管理台帳でソフトウェアは管理していないのなら、これも実地確認して現況ベースでの情報を得る必要がある。
さらにコンピューター以外の IT / ネットワーク機器の把握も必要になる。プリンターやスキャナーなど人が直接操作する機器はまだ「何がどこにあるのか」分かりやすいが、ルーターやハブなど直接操作しない機器はどこに設置されているのかよく分からないという場合もある。またサーバーのようにネットワーク越しの操作しかしない機器の場合、サーバー名と実際の機器の対応関係が不明になる場合もある。サーバー名でアクセスできるのだからどこかでサーバーが稼働している筈だがどこに設置されているのか分からないとか、複数台あるサーバーのどれがどのサーバー名なのか分からない、というケースだ。

こうした「何がどこにあるのか」が分からない状態と、それらが情報として正しく管理されている状態ではヘルプデスクや IT サポートの業務の効率も違ってくる。それだけでなくこうした情報は IT 資産のコスト管理、違法コピーなどの不適切なライセンス利用の防止、さらには情報セキュリティー管理にも重要であり、単にヘルプデスクや IT サポートだけの問題ではない。
一般的にこういう情報に基づくハードウェア / ソフトウェアの IT 資産の管理を「インベントリ管理」あるいは「IT アセット マネージメント」などと呼んで、それを売り物にしたシステムやサービスも大々的に販売されている。そこまで大仕掛けなシステムを作らなくとも、どんなコンピューターがあって、どんなソフトウェアが使われていて、どんなネットワーク構成になっているのか、まとめの情報 (台帳やシステム図) があれば最低限の管理はできる。。

とは言え最初に情報を収集するのは前述のように少し面倒な作業になる場合も少なくない。いちいちコンピュータのある場所まで出向き、機種・形式・仕様を調べ、さらにインストールされているソフトウェアを調べる事になれば、そのコンピュータを使っている人の業務との兼ね合いを考えると作業時間の調整だけでも一苦労するかも知れない。
それでも今後のサポート業務・管理業務の効率化やライセンス管理の適切化、セキュリティーを考えるとぜひやっておくべき作業だし、やり方によっては情報収集をより簡単に行う事も可能だ。

それでは具体的にどのような方法で効率的に情報を収集するのか、またどのように管理するのが良いのか。これについては次に投稿する記事で紹介していきたい。

エスカレーション先を確認する

ヘルプデスク担当者として、あるいはサポート エンジニアとしてあなたがどれだけ優秀だとしても、すべての問題をあなた一人の力で解決できる訳ではない。

より専門的な知識を持っている人の助けが必要な場合もあるだろうし、問題が起きているソフトウェアのベンダーの情報が必要な場合もある。あるいはベンダーが製品サポートを提供していてそれを利用できるなら、問題の調査と解決を丸投げできる場合だってある。
だから対応しなければならない課題について、別の誰か (どこか) にエスカレーションするパスを確認しておくことは、ヘルプデスクやサポートの業務において重要だ。

これは何も技術的な事に限った話ではなく、非技術的な事柄、例えばユーザーが「クレーマー」化してしまった場合の対処や、技術的な対応が業務としての合理的な範囲では困難である場合の対処など、あなた一人の対応や判断では事態を収束できない場合にも、会社としてより上位の権限や権能を持つ人 (や部署) に対処や判断を委ねる必要が出てくる。
だからこうした技術的 / 非技術的なエスカレーション先を常に確認し、適切に機能される事はあなたが仕事としてヘルプデスク業務や IT 担当者、サポート担当者としての業務を進める上での安全弁であり、セーフイーネットでもある。

技術的な面で言えば、あなたが大きな組織の中の一部分についてのヘルプ / サポート担当者であれば、組織全体の IT サービス部門やサポート部門が存在しているだろうし、(本来であれば) そうした部門とあなたのような現場担当者がどのように役割を分担し、どのように連携するのかを決めたルールが存在するはずだ。ルールがあるのならその内容をよく確認し、エスカレーションの方法や手続きを確認しておこう。もし (残念なことに)  ルールが存在しないのなら、そうした部門への (ある意味個人的な) コネクションを作る必要があるかもしれない。もちろん正しいのは「組織の正規の意思決定経路を通じてルールの制定を上申する」事なのだが、そうした意思決定が現実の問題に間に合うかどうかは分からないのだから。
正規のルールに則るにせよ、個人的なコネを活用にするにせよ、組織全体の IT サービス部門やサポート部門にエスカレーションができるようになれば、少なくとも一人では解決できそうにない問題やトラブルを際限なく抱え込む事態は避けられるはずだ。

あなたが組織内でたった一人の (またはごく少人数の同僚だけの) ヘルプ / サポート担当者の場合、上記のような組織内の技術的リソースに頼ることはできない。しかし問題の原因はあなたがスクラッチで作ったソフトウェア ツールであなた以外にそのツールの詳細を知る人が居ない…というのでもない限り、不明点があったりトラブルが起きていたりするシステムやソフトウェアには作成者または専門的な知識を持つ人 (組織) がどこかに居るはずだ。そうした人はエスカレーション先になり得る。
一般的な言い方をすれば、企業で使われているソフトウェアやシステムでは大抵の場合、何らかのサポートが得られるはずだ。市販のソフトウェアであればそのメーカーがサポートを提供しているし、SIer を通じて導入したソフトウェアやシステムであれば、その SIer がサポート窓口になっている場合が多い。「フリー ソフト」やオープンソース ソフトウェアでもコミュニティー ベースのサポートが得られたり、有償のサポートを提供している業者を見つけられる場合がある。こうしたサポートはあなたの問題解決に役立つはずだ。これは組織全体の IT サービス部門やサポート部門がある場合でも同様だ。

しかし「サポートが提供されている」という事と、「あなたがそのサポートを利用できる」という事は別だ。「フリー ランチはない」のと同様、まったく何の見返りも期待されないサポートは無い。コミュニティー ベースのサポートのようにお金を対価として要求されない場合もあるが、それでもコミュニティーへの貢献は常に期待されているのだから。
そこで「どのようなサポートが利用できるのか」「サポートを利用するためにはどうすればいいのか」を確認する事が必要になってくる。

メーカーやベンダーがサポートを提供している場合、サポートの利用条件は大きく別けて二つだ。一つ目は製品の購入で、要するに購入した製品にアフターサービスとして一定の期間や回数分のサポートが含まれているパターンだ。もう一つは有償のサポート契約で、これは製品価格にはサポート サービスは含まれておらず別途必要なサービスを購入してくださいというパターンになる。
こうした条件付きのサポートとは別に、最近ではほとんどのメーカー、ベンダーが無料で利用できる Web 上のサポート情報や Q & A を公開しているが、これは「エスカレーション先」にはならないのでここでは触れない。こうしたサービスからの情報収集については別に記事にしたいと思う。
製品に付属している場合でも別途契約する場合でも、今の時点でそのサービスが利用可能なのか、またそのサービスはどのような範囲で提供されるのかを知っておく事は、いざという場合のエスカレーション先の確保として重要だ。

市販の製品に付属するサービスの場合、大抵は製品自体のドキュメントに記載があるだろうし、メーカーやベンダーの Web サイトにもサービスの利用方法が掲載されている。利用している市販のソフトウェアのそれぞれについて、時間のある時にサポートの利用方法を確認し、エスカレーション先の資料としてまとめておくとあなたにとって便利なだけでなく、あなたの同僚や後継者にとっても有益だ。もちろん資料のメンテナンスは忘れず、またメンテナンスの必要性を後継者に伝えることもお忘れなく。
なお前述のような組織全体の IT サービス部門やサポート部門がある場合、組織として購入した製品に付属しているサポートの権利をそうした部署で一括して管理していて、ユーザーや個々の部署が個別に利用できないようにしている場合がある。全社的な担当部署がある場合は、その点についても確認しておこう。
また「フリー ソフト」やオープンソース ソフトウェアでコミュニティー ベースのサポートが得られる場合 (その多くは Web フォーラムや ML [メーリング リスト] だろう) も、どこでどのようにサポートが得られるのか確認しておく事は有益だ。前述のようにこうしたコミュニティー ベースのサポートの場合、単に質問するだけでなく貢献も期待されているので、質問したい時にフォーラムや ML に参加して質問し、解決したらされっきり無関係というパターンは歓迎されない。できれば (特に業務上重要な役割をそのソフトウェアが果たしているなら) 質問のあるなしにかかわらずコミュニティーへの参加・登録を行い、またもし自分が提供できる情報があれば回答者として投稿するなどしていると、自分が質問者になった際により大きなリターンも期待できるだろう。
もちろんこうしたエスカレーション先の情報 (どこの ML / フォーラムでどのソフトウェアの情報が得られるか) も資料として整理し、メンテナンスしておこう。

契約が必要なサポートの場合、まずそうした契約をしていないのかどうかの確認が必要だ。組織全体の IT を管理する部門があるような企業ではまず間違いなくその部門が契約を管理しており、契約が必要なサポートを利用する際は、その部門を通じて行う事になるだろう。
こうした全社的な管理部門が無い場合、サポート契約の有無が適切に管理されていない場合もある。ソフトウェアやシステムの調達を行った部署 (担当者) は、SIer やベンダーの勧めでサポート契約をしているのに、実際にそれを運用する人にその契約が正しく伝わらず、総務課のキャビネットにサポート契約書が眠っているという場合も実際にある。これを掘り出すのは (場合によっては社内政治的にも) 結構面倒な作業だが、いざという時に使えないのではお金の無駄でしかないし、ヘルプ / サポートを担当するあなた自身にも不幸だ。暇をみつけて少しずつでもよいから確認し、必要な時に利用できる状態にしておこう。

そして最後に、非技術的な問題のエスカレーション先の確保だ。ヘルプデスク / IT サポートの業務遂行上、技術的ではないトラブルや困難な判断に直面した場合、それを一人で抱え込むのはあなたにとっても (精神安定上、という以上に) 危険だし、会社の業務全体の効率を考えても問題だろう。あるいは対処自体は技術的な物であっても予算が必要になる場合、当然あなた一人の意思決定では済まないだろう。こうした問題を誰に (どこの部署に) 相談し、上申し、あるいは起案すれば良いのか、日頃から注意して確認しておこう。
大きな組織でヘルプデスク / IT サポートの専任であれば、その業務の直上の管理職が居るはずで、その管理職がプライマリーなエスカレーション先になるからあまり問題はないだろう。
問題は専任ではない場合だ。その場合、ヘルプデスク / IT サポートの業務は誰の管理下で行われているのか、あいまいになっている事も少なくない。直上の管理職とは別に、さらに上位の管理職 (たとえば部長とか社長とか) から「パソコンの面倒を見てくれ」と言われて対応をしている人も少なからずいるだろう。こうした場合責任の所在があいまいになりがちで、いざ (非技術的な) トラブルが起きた場合、誰がどう仕切るのか考えられていない事が多い。そうなると一番大変な目にあうのは担当者であるあなただ。
そうした事態を回避するためにも、ヘルプデスク / IT サポートの業務について誰が管理者であり、だれが最終責任者なのか、言い方は悪いけれど言質を取るよう心がけよう。もちろん正規の職制や業務規則に盛り込むチャンスがあるなら、ぜひそうするべきだ。最近は「コンプライアンス」という言葉が流行っていて、経営者や管理職はこの言葉に弱いようだから、「情報管理に密接にかかわる IT 関係の業務の責任体制がはっきりしないのはコンプライアンスにもとる」と説得すると良いかもしれない。

こうした準備や確認をして、使える物はずの物は実際に使える状態に常にメンテナンスしていく事は、企業内・組織内のヘルプ / サポート担当者に必要な仕事だ。

ゴールを定める

ヘルプデスク、あるいはサポート担当者としてユーザーの質問に答えたりトラブル対応を行う場合、重要なのはゴールの設定です。

ゴールとは、ユーザーの「ああしたい」「こうしたい」というニーズ (要求) と、担当者 (あなた) の提供できるサービスで実現できる事の一致点であり、ユーザーが得られる物と担当者が行うべき事の目標になります。
簡単な例では、ユーザーにある文書を特定の用紙枚数 (例えば 4 枚) 以内に印刷したいという質問がある場合、その一番妥当なゴールは「その方法の案内」になるでしょう。別の例として、ユーザーからあるソフトウェアでデータを袋とじ印刷したいが意図通り印刷されないというトラブルの相談があった場合、そのゴールは「必要なデータを袋とじ形式で印刷する事」になるでしょう。
ゴールを達成される事で、担当者はユーザーにヘルプやサポートで適切かつ十分な対応が得られたという満足感を与える事ができますし、また仕事の区切りをする事ができます。ゴールが明確でないため、ユーザーから次から次へと質問や苦情を突き付けられ、苦労した経験がある人も少なくないでしょう。
そのためユーザーからの質問やトラブル申告を整理し、ユーザーのニーズを把握し、それに適切に対応したゴールを設定する事は重要です。ゴールが明確であれば「ここまでちゃんとやりましたよ」とユーザーにも、またあなたの上司にも言えるわけです。

さてここで注意しなければならないのは、ゴールは明確であるべきだけれど、そのゴールを達成する手段が限定されるような設定にはしない事です。
例えば上の例の前者の場合、ユーザーは印刷を行うソフトウェアの印刷設定で印字用紙枚数を設定する事ができないかと思って質問しているかもしれません。しかしここでゴールを「そのソフトウェアの印刷設定で用紙枚数を設定する方法」にしてしまうと、もしそのソフトにそうした機能が無ければゴールは達成できない事になります。しかし「そのソフトウェア」と限定しないでゴールを設定しておけば、プリンターの機能で実現してもゴール達成となります。
また後者の場合もゴールを「あるソフトウェアの袋とじ印刷の正しい設定方法」にすると、もしトラブルの原因がソフトウェアの不具合 (特定の条件で袋とじ印刷が正しくできないバグ)だった場合、ゴールが達成されていてもユーザーの本来の希望 (袋とじ印刷を行う事) は実現できません。上と同様に手段を限定しないゴールを設定していれば、ソフトがバグで正しく機能しなくともプリンターの設定で袋とじが可能であればそれでゴールは達成でき、ユーザーの希望も叶います。
一つの目標を達成する手段は常に一つとは限りません。またコンピュータ システムの場合不具合 (バグ) で期待通りの動作ができないため「運用回避」や「代替手段」で問題に対処せざるを得ない場合も少なくありません。またセキュリティー上の規制などコンピュータを使っている環境 (企業、会社) でのルールによって手段が制約を受ける場合もあります。
「ゴール」で達成すべき課題は明確にするべきですが、手段を制約するような内容はできるだけ含まないようにする事、これが重要です。

もう一つ重要なのは、適切なゴールは必ずしもユーザーの (表面的、直接的な) 希望と同じではないという事です。
例えばユーザーのコンピュータでは定期的に原因不明で正体不明のエラー メッセージ ダイアログが表示され、これについてあなたに対応を求めてきたと考えてください。この場合正しいゴールは「エラーが表示されなくなる事」でしょうか。
もちろんユーザーの直接的な問題はエラー メッセージが表示されることです。しかしユーザーは「エラーが出る」という現象の裏側で、何か自分では理解できないコンピュータの異常が発生しているのではないかという不安を抱いているはずです。したがって単に「エラーは出なくなりました」というだけの対処ではそうしたユーザーの不安が十分に払拭されるとは言い難いのです。
ユーザーの本当のニーズは不安が取り除かれる事であり、安心して業務にコンピューターを使える事です。ですからゴールもそれにフォーカスした内容であるべきです。具体的にどのようなゴールが可能かは、エラーが発生している状況にもよりますし、またヘルプデスク業務、サポート業務についての組織 (会社) の方針、ポリシーによって変わってくるでしょう。しかしいずれにせよ「コンピュータが (その会社にとっての) 業務に利用しうる要件 (安定性、安全性) を持っているかどうかを確認する」ところまではゴールに含まれる必要があると思います。

そして最後に留意すべきなのは、できそうにない事、無理だとわかっている事についてユーザーの期待値をうまくコントロールし、期待値が高すぎないようなゴールを設定すべきだという事です。
実際にトラブル対応やヘルプデスクの仕事をしていると、ユーザーから繰り返し同じような質問への回答やトラブルへの対応を求められる事があります。そしてその大半は「残念ながらこのソフトではできません」とか「現在の我が社のシステムではできません」とか、あるいは「このトラブルは初期化 (リカバリー) 以外に確実な解決方法が確立されていません」だったりします。
当然ユーザーは希望が叶う答えが得られる事、問題が簡単に解決する事を期待している訳ですが、それをそりままゴールにしたのでは、最初から未達成になるのは目に見えています。だからと言って門前払いするような対応をすれば、ユーザーは不満に思うでしょうし、場合によっては納得しないでしょう。
そこでユーザーの期待通りの結果になるのは難しい事を誠意をもって伝えつつ、それならばどうするのが一番良いのか、例えば代替案を提示してユーザーがやりたかった事と極力同じ結果が得られるようにするのか、あるいは現時点ではユーザーが我慢するとして、将来的なソフトやシステムの改善を求めるアクションが必要なのか、ユーザーの気持ちを汲み取ったゴールを設定する必要があります。

つまり「ゴール設定」とは単にユーザーの言っている事を無条件に反映させる物ではなく、ユーザーの言っている事の裏側にある本当の希望やユーザーが直面している現象の状況をうまく引き出す作業であり、そうして引き出した物と担当者 (あなた) が「仕事として」できる範囲とをマッチングさせる作業なのです。

ゴールがうまく設定できれば、目標がはっきりするのでユーザーとのコミュニケーションも取りやすくなりますし、ユーザーも担当者は何のために何をやっているのか、理解しやすくなります。そういう相互疎通は作業を円滑にし、作業の切りや手離れを良くし、またどのような結果になっても (は言いすぎかもしれませんが) お互いに達成感め満足感が高くなるでしょう。

もしあなたがサポート業務、ヘルプデスク業務でいつもユーザーに振り回され、やらなくて良い事まで付き合わざるを得なくなる事が多いと思っているなら、それは最初のゴール設定に問題がある可能性が大きいと考え、ゴールの設定の仕方を見直すべきだと思います。

ブログを始めます

こんにちは、株式会社シーピーエスで代表取締役と IT エンジニアをやっている村地です。

当社の IT サービス事業では、専任の管理者がいない小規模な事務所や個人企業を対象に、管理運用、セキュリティー、システム導入構築に関するサービスを提供しています。

そうした専任の担当者がいない所でも、「パソコン担当」「IT 担当」的に何かあると面倒を見なければならない立場の人、あるいは兼務で社内ヘルプデスクをやっている人は少なくないと思います。

このブログではそうした人に向けて、ヘルプデスク対応やトラブルシュート、セキュリティー対応に役立つ情報を発信していきたいと思います。

また併せて当社からのお知らせやご案内も投稿していきますので、ご愛読のほどよろとくお願いいたします。