2016年8月19日金曜日

インシデント管理で何がしたかったんだっけ?
~ITSM活動の目的とビジョンをもう一度振り返ろう~

こんにちは。流行りのナイトプールが気になって仕方がない志波です。


最近、ITサービスマネジメント(以下、ITSM)に取り組まれている担当者の方とお話させていただく際に、
 ・ITSMの活動を始めたものの、成果に上手く結びついていないな
 ・登録をしているけど次に何をすればいいのかわからない
 ・成果が出ているのか分からないけど成果を報告しないといけなくて困っているよ
という声を少なからず耳にします。

今回は、ITSMの活動を続けてきたみなさんやこれから始めたいみなさんと一緒に、ITSM活動の目的やビジョンを考えていきたいと思います。

1.活動の目的とビジョンを考える                  


さて、みなさんはITSMの活動を始めるにあたり、何を期待していましたか?
また、これから始めるにあたり何を期待していますか?

 ・あの人がいないと対応ができないという状態をなんとかしたい(属人化の解消)
 ・仕事の流れ(プロセス)をわかりやすくシンプルにしたい(業務プロセスの見える化・シンプル化)
 ・監査で、作業証跡やプロセスについて指摘されないようにしたい(監査対策)
 ・ユーザニーズや世間のニーズに応えたい(更なる業績やサービス品質の向上)
 ・トラブルが起こる日常をなんとかしたい(安定した業務の実現)
 ・ベンダ毎に報告内容や対応方法がばらばらでなんとかしたい(ベンダコントロールの実現) ・・・etc

こうした様々な期待が、『ITSMを取り組む目的』(=目指すべきビジョン・将来像)となるわけですが、この目的がしっかりしていないと、取り組みを続ける上に『そもそも何がしたかったのか』がぶれてしまいます。取り組みの目的が後々ぶれてしまわないよう、企画書などに”目的を明文化する”ことをおすすめします。

”目的を明文化する”ことで、目指す目標がわからなくなったときに振り返りができたり、後任へ引き継ぐ際にも主旨や目的が正しく引き継げるため、『活動が形骸化しにくい』などといったメリットがあります。

-前任から引き継いだけど、何を目的にした活動か分からないし、上司にも成果を報告しないといけなくて困っている・・・という話をよく聞きますので、ぜひぜひこの機会に。

また、目的を考える上で大切なことは『どうなりたいか』というビジョン(状態目標)です。

ひとまずは、目先の事態やトラブル解消を目的とした活動で構いませんが、『それらが解消された先に目指すべきビジョン(どうなりたいか、どうなっていたいか)』を考えることが取り組みを続ける上で大切なキーになります。KPIを立てるのが難しいという声もお聞きしますが、困ったときには『どうなりたいか』というビジョンを考えると立てやすいかと思います。

 参考:前回記事「インシデント管理と問題管理のKPI改善に向けた初めの一歩

また、目的を定めることが難しい場合は、『何に困っていてどうしたいか』を考えてみると、分かりやすいかもしれません。

2.活動の妨げとなる要因を押さえ、継続して取り組める活動にする   


では次に、活動を続ける上で成果の妨げとなる要因について考えていきましょう。
しっかりと活動が継続できている場合は問題ありませんが、上手くはいっていないケースの方が上手くいっているケースよりも多いのではないでしょうか。

それでは、何が活動の妨げになっているのでしょう。

 ・活動の継続するためのルールが多く、現実的に守ることが不可能・困難(複雑なルール)
 ・せっかく定めたルールが徹底されない、浸透していない(ルールの不徹底、管理者不在)
 ・経営層に活動を継続する目的を問われ、予算取りや人の確保が大変(経営層への説明不足)
 ・運用ルールにツールがついてこれない(業務に合わないツール)
 ・報告用の資料を作ることに膨大な時間がかかる(時間のかかる報告書作成) ・・・etc

このような話は特によく聞きます。

それぞれ原因が異なるため、一概にこうすべきだと提言することは難しいですが、活動を継続することで大切なことは、
 ・ルール、業務プロセスがシンプルであること(シンプルなルール)
 ・管理プロセス毎の目的が定義され、公開されていること(目的の見える化)
 ・また、目的に則した現状が利用者、管理者に公開されていること(状態の見える化)
 ・少ない管理工数で運営ができること(手のかからない運営)
かと思います。

とはいえ、始めからガッチガチにルールを考えるとなかなか活動が開始できなかったり、スモールスタートという言葉にあやかって『まずは始めてから考えようよ』と始めたけど、結局、最初の状態のまま何年も続けてしまっているということもあるかと思いますので、ぜひ始める際には”活動の振り返りを行うタイミングを定義”してください。

参考までに、上手く運営されている企業様の事例を紹介します。

<A社事例(ヘルプデスクでインシデント管理活動を取り組んでいる)>
 ・日次 :当日の発生インシデント件数・対応状況・困り事項の共有
 ・月次 :当月の発生件数、クローズ件数、オープン件数の集計、発生傾向の分析
 ・年次(or四半期) :1年間(or四半期)の活動を通しての実績、課題の共有、改善点の検討
  →翌年(or次四半期)で、改善点の改善を行う

<B社事例(全国拠点のヘルプデスクでインシデント管理活動を取り組んでいる)>
 ・リアルタイム :全国拠点向けに、拠点毎のKPI遵守率、上位ランキング、下位ランキングの公開
 ・月次 :当月の発生件数、クローズ件数、オープン件数の集計、発生傾向の分析
 ・年次(or四半期) :1年間(or四半期)の活動を通しての実績、課題の共有、改善点の検討
  →翌年(or次四半期)で、改善点の改善を行う

活動の振り返りや情報共有を行う頻度は関係者の人数や活動範囲によって様々かと思いますが、活動を継続的に改善し、よりよい活動とするためにも振り返りは必要です。活動を始める際には、そうした振り返りを”いつ、どのタイミングで行い、改善していくのか”を決めましょう。

・ ・ ・

さてさて、今回は、ITSM活動にフォーカスをあて、活動を運営するための目的やビジョンについて触れました。まだまだお伝えできていないことや、上記の内容よりも良い方法もあるでしょう。
 
ITSM活動に関わらず、業務上何かしら活動を行う上でも、目的やビジョンがしっかりしていないと活動自体が形骸化してし、意味のないものになってしまいます。何がしたかったのか、何がしたいのか分からなくなったときには、今回触れたような原点に帰ってみるのもありだと思います。原点に帰った結果、もう今は必要ない活動であれば、終止符を打つのも手だと思います。

それでは、みなさんの活躍を祈願しまして、今回はお開きにしたいと思います。

 参考:ユニリタが提唱するITSMツール「LMIS on cloud

2016年7月27日水曜日

宝の持ち腐れ、DeepLearningで活かせインシデント大量データ

こんにちは開発の佐野です。


段々と蒸し暑い季節になってきましたね。
これからまだまだ気温が上がると思うと少し憂鬱な毎日です。

さて、今回は今話題に挙がっているDeepLearning(深層学習)について話したいと思います。

今では機械学習でポケモンGO並みに名の知れた学習方法です。
白黒画像をカラー画像にしてしまったり、最近では囲碁のプロに勝ってしまいましたね。

こんな急激にAIの技術が進歩してしまって、
いつか人類は侵略されてしまうのではと思いますが・・・。
使える時には最大限に使っていきましょう。

DeepLearingを使うだけならSaasを使えば簡単ですが、何が凄いのでしょうか?
今回はその凄さを少し分かってもらえた上でITサービスに生かしてもらえればと思います。

本来、機械学習と呼ばれているものとDeepLearning(深層学習)は少し違います。

機械学習と一般的に言われるものは、予め人がプログラミングなどで指示した上で学習を行い、
その学習データをもって色々な結果を返すものです。

ここで人が指示するのは何を特徴として学習するかの特徴です。


ですが、DeepLearningは違います。

元々は人間の脳のシナプスを参考にして作られました。
人間は自分で考えて行動しますよね?
人間と同じでDeepLearningでは自分で与えられたデータの特徴を見つけて学習してしまいます。


一般的な機械学習では与える特徴を間違えると意図しない学習をして
判断を誤ってしまいます。

一方DeepLearningだと誤った特徴を渡すことはないので、
高い精度で判断をしてくれます。
人間に一歩近づいたわけですね。

簡単な説明でしたが、ここまで聞いてDeepLearningの凄さが分かってもらえたでしょうか?

それではそのDeepLeraningをどこで活かせば良いかという話になりますね。
ITサービスマネジメントではインシデント(問い合わせや障害)を管理し
日々そのデータを貯めていっています。

例えば、こんな事にDeepLearningを使うといいでしょう。





溜まっているデータから一つ一つ障害や問い合わせの文章を学習させ、
それぞれ、どのカテゴリーかを分類させます。
分類を行ったので新たなインシデントが来た場合、
そのインシデントがどの分類なのか、また過去にどのような
ワークアラウンドや解決策を提示できたかを
サポートデスクが瞬時に知ることができるわけです。





また、分類したインシデントから
どんな傾向のインシデントが多いかなどを把握することができますね。

ほんの一例をあげましたが、まだまだインシデントデータから色んな活用方法がありそうです。

では、どのようなツールを使えば
DeepLearningができるか紹介したいと思います。

まずはMicrosoftが提供している
Microsoft Azure Machine Learning


こちらはSaas型で、機械学習を詳しく知らなくても簡単にデータ分析を行ことができます。
GUI形式でパズルを組み合わせる感じで構築することができるので初心者でもお勧めです。

まずは試してみようかなという方にはうってつけだと思います。


次にGoogleが提供している
Tensorflow

こちらは多少玄人向けにはなりますが、
Linux系でPython言語でプログラミングをして機械学習を行うOSSになります。
機械学習した結果はあとでグラフで見ることができたり他のOSSより分かりやすくなっています。
OSSなのでお金は一切かからないのも強みです。

ただ、試したいだけならMicrosoft Azure Machine Learningのチュートリアルは無料なのでおすすめです。


大量のデータをただ持っているだけでは宝の持ち腐れです。
それをどう活かすかがこれからの課題になっていくと思います。

上記のようなツールを駆使してこれからのITサービスに活かしてはいかがでしょうか。

2016年7月13日水曜日

ITサービスにおけるサポート改善とCS向上

こんにちは開発の蛯名です。

今回はCS向上につながるWebサポートについて書いてみたいと思います。

みなさんは、商品やサービスの不具合などで企業に問い合わせをした際、
こんな経験をしたことはありませんか?


  • サポートセンターに何度も電話をかけたのに、つながらなかった
  • 電話先のオペレータに状況を把握してもらえず、たらい回しにされた
  • 問い合わせメールの返信が遅く、さらには質問のやり取りが続いた


これらは、企業サポートで時々遭遇する“がっかり事例”です。
今すぐ問題を解決したいのに、そのような対応をされると本当にがっかりしますよね。


よくあるサポート手段として、電話、メール、Webフォーム、FAQサイトなどがありますが、
上記の“がっかり事例”に対して、サポートセンターの規模を拡張するといった対策では
CSの向上にはつながりません。

実際ある調査によると、製品やサービスにて不明点があった場合、お客様の多くは
お客様自身で一旦調べるそうです。

しかし、お客様自身で調べても解決できないという理由から、サポートセンターへ電話やメール、
Webフォームを利用して問い合わせを実施しているお客様が存在します。
このような形でお問い合わせをさせてしまっている時点でCSに悪影響を与えています。

お客様自身での自己解決率低下の原因の多くは、サポートサイトのユーザビリティにあります。
サポートサイトの内容が以下のようになっていませんか?

  • カテゴリ分けが悪い、または無い
  • 検索で見つけられない
  • 説明が分かりづらい


サポートサイトやFAQを構築する際には、お客様がどのような問題解決手段や情報をこのサイトに
求めてくるのかを想定し、それに合わせたサイト設計と情報設計だけでなく、
それを実現するためのナビゲーションや検索機能についても、十分考慮しましょう。

また昨今、メール、Webフォーム以外に、SNSやチャット等を利用したサポートチャネルも増えてきています。
これらのサポートチャネルの選択もCS向上を目指す上で非常に重要になってきます。


下図は、サポート手段を課題解決のリアルタイム性と問い合わせの心理的ハードルの2軸で
表したものになります。


緊急性の高いお問い合わせに関しては、電話でのサポートが向いていますが、緊急性の低いものは、
わざわざ電話でサポートをするのではなく、メールやWeb上でサポートができれば理想的です。

また最近ではオペレータを介さず、AIを使用して自動的に回答するといったサポートも出てきています。

上記のようなWebサイトやソーシャルメディアは、マーケティング部門が扱う物と思われがちですが、
サポート的観点でも重視されてきていますので、是非活用してみてはいかがでしょうか。

引用元:CS向上2つのポイント


2016年6月29日水曜日

サービス要求を振り返る

こんにちは。開発の高橋です。

6月ももう終わりですね。
もう今年の半分が終わろうとしているなんて信じられないですが、
現実を受け止めて、残り半年を有意義に過ごしたいものですね!

先日サービス要求について調べる機会があったのですが、
このブログではあまり語られていなかったので、
今回はサービス要求について書いてみたいと思います。

そもそも「サービス要求」とはどんなものでしょうか。
ITILでは、以下のように定義されています。

「ITサービスの使い方などに対する標準的な変更を求めるユーザからの要求のこと。」

これだけではよく分かりませんが、具体的にはアプリケーションのインストールや、
新規ユーザ作成、パスワードのリセットのことを指します。

このように一般的にサービス要求は、
  • 低リスク
  • 発生頻度が高い
  • 低コスト
である小さな変更です。

元々ITIL V2では、インシデントの一種とされていましたが、
ITIL V3から要求実現プロセスの管理対象としてインシデント管理から切りだされました。

では、サービス要求とインシデントの異なるところはどんなところでしょうか。

既知のインシデントについては、ある程度は対応方法を定めておくことはできますが、
初めての事象のインシデントも発生することがあります。

しかし、サービス要求は頻繁に繰り返される作業であるため、
事前に必要な対応や期間、フローを定義しておくことができます。
逆に考えれば、事前に変更内容について承認を得ておくことが大切になります。

もしサービス要求をインシデントと一緒に管理されている方が居れば、
別々に管理することを検討してみてはいかがでしょうか。
インシデントと別にすることで、申請内容や承認フロー、サービスレベルをそれぞれ定義することができ、
レポートで集計する際にもより正確な分析ができるのではないでしょうか。

2016年6月15日水曜日

ITサービスマネージャに必要な108のスキル

梅雨の時期、いかがお過ごしでしょうか?開発の尾上です。

今回はIPAの公開しているiコンピテンシ ディクショナリ2016のスキルディクショナリに記載されている、ITサービスマネージャに必要とされているスキルを抜粋し、ご紹介します。

このiコンピテンシ ディクショナリは企業においてITを活用するビジネスに求められる業務(タスク)と、それを支えるIT人材の能力や素養(スキル)を体系化したものとなります。

それではご紹介しましょう・・・
---------------------------------------
■(戦略) 製品・サービス戦略
001.サービス戦略手法

■(戦略) 製品・サービス開発戦略
002.顧客環境分析手法

■(戦略) システム戦略立案手法
003.システム化戦略手法
004.システム活用促進・評価
005.業務プロセス
006.情報システム戦略

■(企画) システム企画立案手法
007.システム企画立案手法

■(実装) ソフトウェアエンジニアリング手法
008.保守サービス提供手法

■(実装) カスタマーサービス手法
009.予防保守手法

■(実装) 見積り手法
010.コストの見積り手法

■(実装) プロジェクトマネジメント手法
011.プロジェクトマネジメント
012.プロジェクト統合マネジメント
013.プロジェクト品質マネジメント

■(利活用) サービスマネジメント
014.統合サービスマネジメント手法
015.サービスレベルマネジメント手法
016.顧客関係マネジメント手法
017.継続的サービス改善手法

■(利活用) サービスの設計・移行
018.サービスの設計手法
019.サービス移行手法

■(利活用) サービスマネジメントプロセス
020.サービス提供プロセス遂行手法
021.解決プロセス遂行手法
022.統合的制御プロセス遂行手法
023.関係プロセス遂行手法

■(利活用) サービスの運用
024.サービスの運用手法
025.システム運用管理手法
026.ナレッジ管理手法
027.運用オペレーション手法
028.運用支援ツール手法
029.サービスデスク運用手法
030.スタッフィング手法

■(支援活動) 品質マネジメント手法
031.テスト技術・手法
032.テストのマネジメント手法

■(支援活動) リスクマネジメント手法
033.リスク管理手法

■(支援活動) 情報セキュリティ
034.リスク分析手法
035.情報セキュリティポリシー策定手法

■(支援活動) チェンジマネジメント手法
036.協働の管理手法

■(システム) ソフトウェアの構築技術
037.構築品質
038.テスティングツール

■(システム) ソフトウェアの利用技術
039.ソフトウェアの進化や保守

■(開発) システムアーキテクティング技術
040.システム要件定義

■(保守・運用) ITサービスマネジメント業務管理技術
041.ITサービスマネジメントの業務フロー分析
042.運用業務管理システムの運用管理
043.運用業務管理システムの導入・設定

■(保守・運用) ITサービスオペレーション技術
044.サービスデリバリ
045.業務システムオペレーション
046.システム運用(オペレーション)
047.ジョブスケジュール
048.障害管理
049.システムの監視
050.稼働状況管理

■(保守・運用) システム保守・運用・評価
051.移行設計
052.移行
053.プラットフォーム移行設計
054.プラットフォーム移行
055.アプリケーションシステムの受け入れ
056.システム運用管理設計
057.システム運用方式技法
058.システムの投資評価技法
059.システム管理計画
060.システム管理技術
061.システム保守基準
062.運行管理
063.システム管理製品
064.運用管理ソフト製品
065.運用システムの構築
066.運用システムの改善
067.運用に関するシステム評価
068.性能管理
069.障害時運用方式
070.災害対策
071.構成管理
072.保守技術
073.メンテナンス
074.保守・廃棄

■(保守・運用) 障害修理技術
075.障害状況把握・原因特定
076.障害コール受付
077.処置・修復作業の実践・動作検証

■(非機能要件) セキュリティの基礎技術
078.情報セキュリティ
079.情報保証と情報セキュリティ
080.情報倫理とセキュリティ
081.アプリケーションセキュリティ
082.情報プラットフォームのセキュリティ技術
083.ネットワークのセキュリティリスク
084.暗号技術
085.セキュリティと個人情報
086.保証、信用、信頼のメカニズム
087.セキュリティ技術の理解と活用

■(非機能要件) セキュリティの構築技術
088.セキュリティ方針の策定
089.セキュリティ対策基準の策定
090.情報セキュリティ対策
091.セキュリティシステムの計画策定
092.セキュリティシステムの要件定義
093.コンピュータ・フォレンジクス(証拠保全追跡)

■(非機能要件) セキュリティの利用技術
094.セキュリティシステムの運用管理
095.システム運用・保守技術(セキュリティ)
096.セキュリティ障害(事件事故/インシデント)管理
097.情報セキュリティ管理
098.情報セキュリティ監査の実施・支援
099.セキュリティ技術評価
100.セキュリティの分析
101.セキュリティの見直し(セキュリティシステムの評価と改善)
102.コンテンツセキュリティ技術

■(共通技術) ナレッジマネジメント技術
103.FAQ
104.ナレッジベース
105.ナレッジマネジメントの意義

■企業活動
106.会計・財務
107.情報セキュリティ監査

■法規・基準・標準
108.標準化関連
---------------------------------------

というように、ITサービスマネージャという職責をこなすためには非常~に多くのスキルが必要になります。

スキルディクショナリをダウンロード頂き、ご確認頂けると分かるのですが、このスキルの中に更に細かく知識項目というのが設定されておりまして、それらの数の方でカウントしますと、1,000を超える知識項目が記述されております。

ただし実際に働く場合においては、ここに記載したスキルの業務をすべてITサービスマネージャ1人が請け負うわけではなく、それぞれの領域のプロセス管理者たちが協働してサービス運営していくという形になります。

全体を知っておくことで、他のプロセスとの仕事の質が改善されることが期待されるのと、ITサービスマネージメントに関わる高度人材が皆、同程度の知識を有しておくことで、各プロセス間の認識の齟齬や摩擦が軽減され、プロセス効率化が促進される効果が期待されるため、この秋の試験ではぜひITサービスマネージャの取得に挑戦されてはいかがでしょうか。


2016年6月1日水曜日

サービスデスク業務改善~「新米主任 ITIL使ってチーム改善します!」レビュー

開発の大久保です。

5月より気温が20度後半に達する日が増え始め、職場でも蒸し暑さを感じるようになってきました。
今年は卓上扇風機を職場用に買って、来る夏の暑さに備えようかと考えています。
皆さんも熱中症には十分にお気をつけくださいね。

さて、今回はITILを活用した業務改善例として、お勧めの書籍を紹介したいと思います。


新米主任 ITIL使ってチーム改善します!


こちらの書籍は、2015年4月に発売された第1弾の「新人ガール ITIL使って業務プロセス改善します!」の続編として、2015年11月に発売されました。
第1弾はITIL全体を包括的に説明しているのに対し、第2弾の「新米主任 ITIL使ってチーム改善します!」はサービスデスク業務にテーマを絞って、具体的な改善策を提案する内容となっております。


第1弾でも言及されていましたが、ITILは全てを実践しようとしなくても、「つまみ食い」「いいとこどり」で実践できることが特長の一つです。
第2弾ではITILのプロセスの中から、以下の4つのプロセスに焦点を当てて、問題だらけのコールセンター部署で主任を任された主人公が業務改善に取り組むストーリーを展開しています。

1.サービスレベル管理
2.インシデント管理
3.問題管理
4.ナレッジ管理


フィクションなので若干大げさなところはありますが、ミスを指摘されると逆切れする社員や、業務時間中にネットサーフィンに明け暮れる社員など、あり得ないようなメンバが複数登場します。
チームの統制は全く取れておらず、メンバが各々の判断でお問い合わせに対応しているため、以下のような問題が発生しています…

・担当者によって、対応速度にばらつきがある。
・回答がないまま、放置されている問い合わせがある。
・対応状況が共有されておらず、誰がいつ対応したのかわからない。
・問い合わせ内容が記録されておらず、問い合わせを受けた担当者が休むと対応できない。


これらの問題は、実際の職場でも起こりえるのではないでしょうか?
このように、本書にはお問い合わせ担当を経験された方なら共感できるような「あるあるネタ」が至る所に散りばめられています。

また、問題提起に留まらず、ITILのプロセスを通じて問題解決に取り組むヒントを得ることができます。
例えば、以下のようなことを実践するだけでもサービスデスク業務は確実に改善されます。

・サービスレベルの目標を定義する(オペレーションミス0件、一次回答率80%など)
・お問い合わせの内容・対応時間を記録する
・知識の共有のため、業務手順書やQ&Aを作成する


本書はサービスデスク担当者やリーダーにお勧めできる一冊です。
業務上で発生した問題に、適切かつ迅速に対応するにはどのような活動をすればいいのか?という悩みをお持ちでしたら、是非とも本書からITIL活用のノウハウを学び取り、業務改善に役立てていただければと思います。

物語の中では、顧客満足度やチームワークが改善されていましたが、実際の企業ではITIL導入の効果のほどはどうなのかと思われるかもしれません。
ITILを活用するためのツールを提供している企業もありますので、導入事例を参考にされてはいかがでしょうか。
http://www.unirita.co.jp/products/lmisonpremises/requirement/case.html

2016年5月25日水曜日

■ITに関わる新入社員の皆さんへ ~お勧めの講座~

こんにちは、中村です。

今年度も早くも2ヶ月が過ぎようとしています。

新入社員の方々も研修中の方々もいれば、まだ数ヶ月続く方々もいることでしょう。
システム運用にかかわるうえで、基本ともなるべき、ITILにおける入門試験として、
ファンデーション(Foundation)があります。

ITILファンデーション試験攻略法」という記事で、勉強の方法について説明されています。

決して難しい試験ではないのですが、
ただ、業務経験もない状態で、ITILファンデーションの試験対策本を読んで、
自己学習で勉強しようと思っても、
試験問題も、英語を翻訳したものであったりと、すこし分かりづらいんです。

そんな方々へ、お勧めしたい講座があります。

新入社員で、研修中の方にも、研修が既に終わった方にも、
新入社員ではないけれど、まだITILのことをよく知らない方にも、
教育担当者で、研修内容に困っている方にも、お勧めです。

システム管理者の会の「システム管理者認定講座」です。














こちらは、半日の3日間コースなのですが、
初級コースの2日目「テクニカルスキルナレッジ編」の内容が
「ITサービスマネジメント入門」となっていて、
要はITILの説明がメインです。

3日目の「効果的な運用プロセスの実践」では、
2日目に学んだITサービスマネジメント入門に関して、
身近な内容に置き換えて、他社の方とワイワイ相談しながら、体験することができます。

1日目に関しても、ヒューマンスキルの中でも基礎となる「コミュニケーションスキル」について、
知識を学びつつ、実際に体感して、実感することができます。

3日目には試験があるのですが、こちらの試験に合格すれば、
全日本能率連盟の登録資格を取ることができるので、
業務経歴書の資格欄にも記載できます。

金額も、6,000円と資料代のみなので、例え自腹だったとしても十分に手が届く額です。
とはいえ、平日の日中帯ですが・・・

システム管理者の会の回し者ではありません!
といいつつ、講師をしていたりするので、回し者になるのかな・・・

システム管理者の会は、非営利団体で、弊社の利益のために実施しているものではないので、あしからず。

全員に受講させるとかで、毎回数名コンスタントに受講されている会社もいらっしゃいますよ。

よろしければ、ご検討ください。