WEBVTT 00:00.150 --> 00:01.050 インストラクター：このレッスンでは､ 00:01.050 --> 00:07.470 トラブルシューティング手法の最後のステップであるステップ6､ ドキュメンテーションについてお話しします｡ 00:07.470 --> 00:09.960 CompTIAでは､ この文書を「調査結果､ 処置､ 00:09.960 --> 00:11.580 結果」と呼んでおり､ 何が問題だったのか､ 00:11.580 --> 00:18.600 それに対して何をしたのか､ 今後それを防ぐためにはどうすればよいのかを文書化することを目的としている｡ 00:18.600 --> 00:26.730 さて､ 組織ごとに､ 社内で発生したさまざまな問題や課題に対するドキュメンテーションの方法は少しずつ異なる｡ 00:26.730 --> 00:29.340 今､ 私の会社では､ トラブル・チケット・システムを使って､ 00:29.340 --> 00:31.230 すべての問題､ 誰に割り当てられたか､ 00:31.230 --> 00:37.410 解決するために何をしたか､ 解決策は何だったかを文書化できるようにしている｡ 00:37.410 --> 00:38.280 それに加えて､ 私たちは独自の社内ナレッジベースを持っており､ 00:38.280 --> 00:46.470 そこにトラブルシューティングの手順や､ 過去にさまざまな問題をトラブルシューティングする中で学んだことをすべて集めることができる｡ 00:46.470 --> 00:47.640 さらに､ よくある質問と呼ばれるエリアがあり､ 00:47.640 --> 00:57.330 エンドユーザーから日々寄せられる質問に基づいたさまざまなサポート記事が掲載されています｡ 00:57.330 --> 01:01.080 ナレッジ・ベースとよくある質問を構築するのには長い時間がかかりましたが､ 01:01.080 --> 01:02.610 特に新しい技術者がチームに加わったときに､ 01:02.610 --> 01:08.460 よくある質問とナレッジ・ベースに目を通して､ 私たちのビジネスのやり方や問題解決の方法を学ぶことができるので､ 01:08.460 --> 01:11.970 本当に役立っています｡ 01:11.970 --> 01:13.440 技術者として働く場合､ 組織の規模にもよりますが､ 01:13.440 --> 01:21.630 ナレッジ・ベースやよくある質問､ トラブル・チケット・システムがある場合もあれば､ ない場合もあります｡ 01:21.630 --> 01:24.030 しかし最近では､ 小規模な組織であっても､ 非常に低コストで､ 01:24.030 --> 01:29.820 あるいは場合によっては無料で､ 優れたトラブル発券システムを手に入れることができる｡ 01:29.820 --> 01:32.340 Freshdesk､ Jira､ Help 01:32.340 --> 01:36.840 Scout､ Intercomなど､ 他にもたくさんある｡ 01:36.840 --> 01:38.880 さて､ どちらを使っても構わないが､ 01:38.880 --> 01:40.710 考え方は同じだ｡ 01:40.710 --> 01:44.760 調査結果､ 行動､ 結果を文書化できるようにしたい｡ 01:44.760 --> 01:45.960 さて､ もうひとつは､ 01:45.960 --> 01:49.770 これをするために必ずしも最後まで待つ必要はないということだ｡ 01:49.770 --> 01:51.060 チケットを割り当てられ､ 01:51.060 --> 01:54.750 問題を特定するとき､ あなたはトラブル・チケット・システムに戻り､ 01:54.750 --> 02:04.890 あなたが特定したもの､ あなたが見た症状､ この問題の可能性のある原因は何だと思うかを文書化する必要があります｡ 02:04.890 --> 02:07.020 一回で解決できるような小さな問題であれば､ 02:07.020 --> 02:11.310 おそらくステップごとにチケットを更新する必要はないでしょう｡ 02:11.310 --> 02:13.560 しかし､ より大きな問題に対処しているのであれば､ 02:13.560 --> 02:17.820 トラブル・チケット・システムの中で文書化することが本当に重要だ｡ 02:17.820 --> 02:19.530 トラブル・チケット・システムが非常に重要であるもう一つの理由は､ 02:19.530 --> 02:24.990 特に大きな組織では､ 傾向分析ができることです｡ 02:24.990 --> 02:31.110 これによって､ あなたの組織が苦しんでいる共通のテーマや問題を把握することができる｡ 02:31.110 --> 02:33.690 例えば､ 私がいたある組織では､ トラブルチケットの電話の90％が､ 02:33.690 --> 02:39.510 パスワードのリセットが必要だというものだった｡ 02:39.510 --> 02:41.490 パスワードのリセットのためだけに､ 02:41.490 --> 02:44.580 膨大な時間を費やしていたのだ｡ 02:44.580 --> 02:46.890 そこで私たちは､ これは傾向として好ましくない､ 02:46.890 --> 02:48.630 と判断し､ 開発者やシステムエンジニアと協力して､ 02:48.630 --> 02:55.620 人々が自分でパスワードをリセットできるようなパスワードリセットオプションを作ることにした｡ 02:55.620 --> 03:00.420 そして､ このシステムが稼動すると同時に､ トラブルチケットの負荷が約90％減少したんだ｡ 03:00.420 --> 03:05.040 そのため､ この文書化は､ 組織の継続的な改善分野を特定する上でも､ 03:05.040 --> 03:07.110 実に重要な意味を持つ｡ 03:07.110 --> 03:11.970 あなたが発見したこと､ 行動､ 結果を文書化するために使用しているこのトラブル・チケット・システムのもう一つの側面的な使用方法は､ 03:11.970 --> 03:16.350 実際にあなたが行った作業量を文書化できることです｡ 03:16.350 --> 03:18.330 しかし､ 私はITディレクターとして､ 03:18.330 --> 03:22.950 15,000人以上のユーザーをサポートする150人のヘルプデスクを運営していた経験から､ 03:22.950 --> 03:35.400 15,000人のユーザーをサポートするためにもっと人員が必要であることを正当化するために､ トラブル・チケット・システムを常に使用していた｡ 03:35.400 --> 03:38.970 そして､ チケットの枚数が増え始めたからだ｡ 03:38.970 --> 03:40.560 私たちがそれを調べ始めると､ 03:40.560 --> 03:45.030 新しいシステムが導入されたからだとわかりました｡ 多くの場合､ 03:45.030 --> 03:48.540 組織は新しいシステムにはお金をかけるのですが､ 03:48.540 --> 03:55.020 ユーザーのトレーニングにはお金をかけないのです｡ 03:55.020 --> 03:58.110 さもなければ､ システム全体が停止し始める｡ 03:58.110 --> 03:59.280 だから､ このことを覚えておいてほしい｡ 03:59.280 --> 04:01.530 文書化できればできるほど､ 技術者としてのあなたや､ 04:01.530 --> 04:05.970 あなたが所属している大規模なヘルプデスクスタッフが行っていることを正当化することができます｡ これは､ 04:05.970 --> 04:07.890 より多くのリソースをサービスデスクシステムに投入して､ 04:07.890 --> 04:18.070 より多くの人を雇うことができるようにしたり､ より良い､ より効率的な方法でこれらのコールに答えることができるように持っている人々のスキルレベルを向上させる必要があるときを識別するのに役立ちます｡