ITIL活用〜インシデント管理の体制（機能）編〜
おはようございます！atomです。
前々回に引き続きインシデント管理の体制の話です。
前回は、役割としていくつか挙げました。今回は、役割を担うチーム（機能）についてです。
機能という言葉に馴染みがない方もいると思いますが、ITILでは以下の様に定義されています。
「1つまたは複数のプロセスや活動を実施するために用いられる、人材で構成されるチームまたはグループ、および彼らが使用するツール。」
例えば全社単位で見たら、人事総務という機能が部門となっていたり、ITの機能が部門となっていたり、もう少し細かい層でいうなら、ネットワークチームとかですね。
ITILではサービスオペレーション、つまりサービス提供をする上で四つの機能を定義しています。
①サービスデスク
②技術管理（インフラの専門家）
③IT運用管理（日々の運用業務や施設、オペレーターの管理など）
④アプリケーション管理（アプリケーションの専門家）
組織によってインフラしか見ないところは①②③だけを保有するケースなんかもあります。
前々回の役割と機能をプロットすると、以下の様な構成で体制を組みます。
〈サービスデスク〉
一次対応スタッフ
〈IT運用管理〉
プロセスマネージャー
二次対応スタッフ
〈技術管理/アプリケーション管理〉
n次対応スタッフ
サービスマネージャーは全体の統括ということで、特定のチームに属さなくても良いかなと思います。
ユーザーとのタッチポイントはサービスデスクとして、二次、n次と分けていくと整理がしやすくなります。
次回はその機能間のエスカレーションに関してお話しできればと思います。
コンサルタントの仕事術〜健全な働き方〜
こんにちは。atomです。
今日は働き方について話をしてみようと思います。
貴方の周りにこんな方はいませんか？
とても真面目で一生懸命だけど、いつも仕事に追われて大変そう。能力が低いわけではないのに仕事がなかなか進まない。
私の周りにも、そして私自身も以前はこんな仕事の仕方をしていました。
ひたすらに一生懸命やる。
常に短距離走の連続の様な仕事。
なんだか分からないけど負の連鎖の様な状態。
これは健全とは言えない働き方だと思います。
追い立てられて自分を磨く事も、新しい事に臨むモチベーションも下がっていきます。
ではどうすればいいのか。
私は仕事における借金を作らない事を作らない事を意識しています。
借金といっても言葉の通りの意味ではなく、マイナス要素を作らないといった意味合いです。
例えば、依頼されていた仕事を納期通りやらなければ依頼主に対して、負い目ができるので交渉はしづらくなります。
この負い目を借金と表現しているのは、借金は金利がかかるため余計な仕事を生み出します。
借金は時間とともに増えていくのです。
利子を返すだけに追われてしまう自転車操業は、やがて破綻します。
納期遅延に対するリガバリプランの作成、報告などさらにやらなくてもいい仕事が増えていくので、そちらに手がとられて本来進まなくてはいけない仕事が更に遅れます。
納期遅延の例のポイントは最初の計画になります。
ここの精度が甘ければ、結局やりきれず借金を作るリスクを作り込んでる事になります。
なかなか納期がコントロールできず借金体質な方は、まず自分ができると考えたその計画に対して根拠が述べられるかセルフチェックをしてみてください。
また、すでに借金を抱えていると感じている方はとにかく一定期間注力して借金を返す事に取り組むべきだと思います。
もし部下がそうであったなら、借金体質な働き方を長期的に指導するとともに、まずは借金返済を手伝ってあげてください。
では今回はこの辺で。
ITIL活用〜インシデント管理の体制（役割）編〜
こんばんは。atomです。
凄く今日は寒いですね^_^;ブルブルと震えながら帰宅途中にブログを書いています。
今回はインシデント管理の体制についてです。
体制を考える時にまずインシデント管理として以下の役割を作ります。
①サービスマネージャー
→プロセスに関わらず提供するITサービスの責任者
②プロセスマネージャー
→インシデント管理プロセスの運営に関する責任者
③一次対応スタッフ
→一次対応をする担当者。主にサービスデスク
④二次対応スタッフ
→主に運用を担うチーム。サービスデスクからのエスカレーションを受けて対応する
⑤n次対応スタッフ
→開発やベンダーなど、運用チームからのエスカレーションを受けて対応する専門的チーム
それぞれの役割を実際のチームに割り当てる事で（既存のチームを割り当てるケースもチームを新たに作り直すこともあり）、どのチームが何をすべきなのかを明らかにしていきます。
スムーズな連携を図る上では、各役割の定義も重要です。例えば一次対応はどこまで対応するのかなど。
上記の構成は二次スタッフによるチームがハブとなり全体をコントロールできる体制となります。
次回は役割を担う機能であるチームについて触れていきたいと思います。
皆さん風邪にはお気をつけください！
寒い〜
ITIL活用〜インシデントの定義編〜
こんにちは。atomです。
今回も引き続いてインシデント管理の話をしたいと思います。
インシデント管理のプロセス設計をする上で一番最初に実施するのがインシデントの定義です。
ITILの定義上インシデントとは、「ITサービスの計画外の停止、または品質の低下。ユーザに影響は与えていない構成コンポーネントの障害」と定義されてます。
企業によっては、インシデントに作業依頼などのリクエストなども含めて管理しているケースがあります。
ちなみにITILでは、作業依頼などのユーザからの作業を伴うリクエストをサービス要求と定義しており、要求実現という管理プロセスを設けることを推奨しています。
企業内IT部門や余り大きな組織ではない場合は、管理が複雑になるのを防ぐため、必ずしもインシデント管理と要求実現を分けなくても良いです。
どう定義すべきか事例として以下を挙げます。
①問い合わせ
②障害
③サービス要求
④要望
⑤内部検知
彼らをインシデントの分類として分けて記録できると良いと思います。また、より細かい分析をする為にそれぞれにさらに詳細分類を設けることを推奨します。
上記分類のポイントは、内部検知された障害をインシデントとして扱うことが一つ挙げられます。
これらは定義をしておき、ツールなどに登録される様にしておかないと、実態がつかめなくなりがちな部分となります。
それぞれがどういった事象を表すかを定義して共通認識にする事がインシデント管理のプロセス設計の第一歩です。
次回はインシデント管理の体制の考え方についてお話ししていきます。
ITIL活用〜インシデントの分析手法〜
おはようございますatomです。
ITIL活用とうたっておきながらITILネタが少ないので、ITIL活用について色々あげていこうと思います。
まずはインシデント分析です。
分析に用いる手法としては、パレート分析とクロス分析を好んで使います。
パレート分析は、インシデントを何らかの軸で多い順に並べていく分析方法です。
https://ja.m.wikipedia.org/wiki/パレート分析
1番取り組まれている分析手法でもあり、問題管理との親和性が高いです。
例えばインシデントにあらかじめ問い合わせの分類項目を設けておけば、どの問い合わせが多いか分かるので、問い合わせが多いインシデント分類に対して、再発防止やナレッジを整備することで効率的な対応につながります。
次にクロス分析です。
これは２つの軸を掛け合わせる分析手法です。
例えば、問い合わせの分類とインシデントの対応者を集計してみる。
するとどれだけ対象の分類が属人化しているかなどが見えてきます。
他にもインシデントの発生件数とリリース時期を掛け合わせて集計してみると、リリースが起因としてインシデントが発生しているといった仮説が浮かび上がります。
パレートはどの会社でも取り組んでいますが、クロス分析は中々できていないようです。
次回は各社の分析ってどのくらいまでやっているのか紹介していきます。
明日は雪降るみたいなので風邪ひかないように体調には気をつけてくださいね！
ではまた。
コンサルタントの仕事術〜アウトラインを描く〜
こんばんは。atomです。
今回は作業の進め方についてです。
コンサルティングの提供方式にもよりますが、私は案件掛け持ちで実施するので、一つの事に集中しきれる状況には無いです。
物理的に工数か足りなくなるというよりも、色んな事を並行で考える為、脳内のメモリが不足するという実感に襲われます。
特に設計作業。
提案内容や対策方法、計画の作成、合意形成までのシナリオ作成などは非常に頭を使う作業で、私は設計作業と位置づけています。設計作業は時間があっても進まない事もあれば、スラスラと出てくる時もあります。
特に未経験の課題に対する設計は目処が読めないので、納期まで終わらないリスクを減らす為、早く着手するようにして、アウトラインを描く事に最大限注力します。ここでは、マルチタスクというよりは、シングルタスクで一つ一つを最速で終わらす事にしています。
アウトラインが描ければ、あとはピースをはめていくだけ、説明資料に落とすだけなので、目処がつく領域になります。
目処がつけば見積もりができるので、自分もしくは、協力者のリソースを分配することで、対応がとれます。
アウトラインが描けない時は、作業場所を変えて一旦離れる、情報のインプットを増やす事で滞留を防ぐようにしています。
自分なりの脳内のメモリ解放にあたる行為なのかもしれません。
ここにコンサルタントとしての生産性の差が出る気がします。
普段本を絶えず読んでいるのも、知識を得るというのもありますが、この滞留が「怖い」からかもしれません。
ちなみにアウトラインをうまく描けず進める仕事は大体クライアントと話をしても進まない事が多いです。
取り敢えず着手して、うまくアウトラインが描けそうか確認するのはよいですが、アウトラインを描けないまま、がっつり作業するのは手戻りになるので絶対にやめた方がいいです。
別の機会に実際にアウトラインとはどういったものを作っているかなんかもお話できればと思います。
ではでは。
IT部門に求められる変革〜デジタルトランスフォーメーション編その2〜
こんにちは。atomです。
今回は、前々回にお話ししたDXについての続きです。
事業のデジタル化が進む、その担い手は事業部門である中でIT組織は何をするかというところが今日のテーマです。
テーマに入る前にデジタルトランスフォーメーションを学ぶ上でなかなか良かった書籍を紹介します。
大前研一 IoT革命 ―ウェアラブル・家電・自動車・ロボット あらゆるものがインターネットとつながる時代の戦略発想 (「BBT×プレジデント」エグゼクティブセミナー選書)
- 作者: 大前研一
- 出版社/メーカー: プレジデント社
- 発売日: 2016/09/13
- メディア: 単行本
- この商品を含むブログを見る
では本題です。
DXによって事業部門側のITが強くなるにつれて、IT部門の役割構造が変わってきています。
いわゆる攻めのIT（売上増にむけたIT活用）に事業がシフトするので、それまで事業部門側で持っていた、既存業務の企画、構築、保守、運用などをより引き取っていく必要があります。
そもそも事業部門がDXしていきたいといっても、人員が増える訳ではなく、今までも暇しているわけでも無いので、事業部門のDXを支えるために既存業務のITについてより、IT部門の関与を増やす必要があります。
具体的には何をすれば良いのか。
事業部門側で主で行なっていた、要件定義（厳密には要求定義）をIT部門が巻き取る必要が出てきます。
どんなITサービスがあれば良いのか要件を伝える事自体をIT部門が担うという事は業務に精通していないといけないという事です。
そんなのできっこ無いよと言われそうですが、現に多くの企業がその為の一歩を踏み出しています。
事業部門の業務に精通するために、IT部門としての既存業務の一部をノンコア業務として、アウトソーシングする例が非常に増えています。
その為の可視化や標準化という領域の整備に各社取り組んでいる状況です。
また、ジョブローテーションによる事業部門との人材交流なども活発化しています。
そして、ノンコア業務のベンダーへの移管にむけたベンダーマネジメントのルール整備などのお仕事の依頼が後をたたない状況です。
複数社ある委託先のベンダーをコントロールするベンダーを設けるといった動きも出てきています。
先見性のあるマネジメントの方はすでに動き出しています。
貴方の会社は如何でしょうか。
ではまた！
コンサルタントの仕事術〜人材育成を阻むバイアス〜
こんにちは！atomです。
土曜日は月一で勉強会をやっています。
コンサルタントは外に出る仕事なので、意図的に集まる時間作らないとなかなかナレッジの共有が難しかったりします。
今日は、コンサルタントを目指す方でもそうでない方でも気をつけるべき点についてです。
狼少年のお話の中で、羊飼いの少年が狼が来たと大人を日々嘘をついて困惑させていたら、本当に狼が来た時に信じてもらえなかったといった有名な童話があります。
本当に狼が来たという事実があっても、羊飼いの少年に対する認識の偏り（バイアス）できてしまい、事実を事実と受け取れなくなってしまっています。
少し極端な例ですが、実情としてもこういった事は多く起きていてるのではないでしょうか。
上司と部下の関係でこの人はできないと上司による決めつけがあり、必要以上にチェックが厳しくなったり、上司に相談しても無駄だと思い相談がされない状態となったり。
いわゆる人間関係という言葉で表現されたりもしますが、組織活動において、バイアスによって非合理的な判断がされるケースが何処でも発生していると思います。
コンサルタントとして気をつけるべきは、インタビューをする時などに、どの程度バイアスがかかっている発言なのかは注意深く見定めないといけないということです。
よく発生しうる事象としては、声の大きな人（発言力的な意味で）にバイアスがかかっている事を見抜かずに、それを事実としてしまうと、解決価値の高い問題の抽出や正しく原因分析ができなくなるリスクがあります。
一社会人としてもバイアスの存在を意識する必要があります。
今日の題に挙げた人材の育成について。
人に何かを教える際に、基本的には自身の成功体験をベースにああした方が良い、こうした方が良いというアドバイスをしていきます。
それ自体は問題ないと思いますが、そのアドバイス通りに後輩や部下が実施しないからと面白くない気分になっている自分がいたら要注意です。
冷静に考えればすぐ分かりますが、あくまでもそのアドバイスは、成功事例の１つでしかなく、必ずしもそれ以外の選択肢を排除するものにはなり得ないという事です。
また、成功体験といっても前提や背景が異なる中で何処まで今回有効性があるものかは見定める必要があります。
これは、年齢が上がるにつれて気をつけるべき事だと考えています。それは成功体験を積み上げれば積み上げるほど、そしてそれが評価をされるほど、バイアスが強くなっている可能性があります。
これを防ぐにはどうしたらいいか。
私が意識しているのは以下です。
1.そもそもバイアスの存在を意識する事
2.全面的に肯定や否定を基本的にはしない（スタンスとして）
3.細部まで意識する
2と3は近いですが、一つ一つの発言や行動をザックリと捉え、良し悪しを判断してしまうと、その中に含まれる良いものも否定してしまう可能性があります。
否定された側からすると、これでは正しいと自信を持てる発言や行動しかしなくなり、積極性がなくなっていき成長は鈍化します。
それは、更に上からすると不満になり負の循環が生まれます。
建設的な議論がしたくても議論成り立たなくなってきます。
特に教育担当、リーダー、管理職に携わる方は注意してみてください。
下の方は、貴方をそういう判断をしてしまう人なんだと見ているかもしれません。
自分も継続的に気をつけなくては。
では、また。
IT部門に求められる変革〜デジタルトランスフォーメーション編その1〜
おはようございますatomです。
皆さんはデジタルトランスフォーメーション（DXと表記）という言葉はご存知でしょうか。
直訳するとデジタルへの移行。デジタルというのはIT化と読み替えても良いかなと思います。
今までの事業をITをつかって変革させる。店舗での小売からamazonがよく例に挙がります。
ITといっても特にIoT、クラウド、AI、ビックデータなどの新たな技術を用いてビジネスモデルを変革していく事として語られる事が多いですね。
以下でも述べられていきますか、今後どの様な企業もITを事業とするIT企業の側面を持つ状態になると考えられます。
https://ja.m.wikipedia.org/wiki/デジタルトランスフォーメーション
最近はユニクロも情報企業への変革を急いでいたりしますね。
https://www.google.co.jp/amp/s.news.mynavi.jp/articles/2015/06/16/fastretailing/?amp?client=safari
大企業が変革を急ぐ一方で、中小企業は特に現状のメインストリームである既存の事業部門は、ITに強くないため、事業をデジタル化していく事が難しい構造があると感じます。
事業部門とIT部門の意識の違いのようなものがまだまだあるのが現状です。
事業部門はビジネス分かるけどIT分からない。IT部門はIT分かるけど、ビジネス分からない。
こんな事があったりします。
実は、もっと現状は厳しく
事業部門も現場レベルではビジネスの全容を抑えられておらず、IT部門もデジタル化する為のITの利活用の術を知らない位が実態です。
DXの必要性を経営が感じている企業は救いがありますが、経営自体がITに明るくない為、力を入れる必要性を感じていない企業は今後一層厳しい状況になる事が想定されます。
では、誰がDXを担っていくのか。事業部門なのかIT部門なのか。
私は事業部門で担っていくと考えています。
事業部門内にDXを推進する為のITの機能が強化されていくと考えます。
それは、目的が変わるか手段が変わるかで考えると手段が変わる方が受け入れられやすいと考えるからです。
企業内IT部門はITを手段に事業を支える事を目的としています。一方でDXとは手段がデジタル化してきますが、事業により収益を上げるという目的は変わらない事、そしてデジタル化していく為のITのハードルが技術革新によって下がっている事が考えられるからです。
事業部門でのデジタル化が進行していくと、IT部門にはどういった影響があるのでしょうか。
事業部門側でデジタル化が進んだら、IT部門としてやる事がなくなってしまうのでしょうか。
また、別の機会で考えていきたいと思います。
ITILにおける4つのP〜結構使えるフレーム〜
おはようございますatomです。
今回はITILで語られる4つのPについてです。
ITサービスマネジメントを成功に導くために考慮すべき4つの観点といえるものです。
Peaple(人)
Process(プロセス)
Products(ツール)
Partner(パートナー)
これらが大事だよとITILでは語っています。
似たようなフレームにBSC(バランススコアカード)などもあります。こちらはより上流すなわち戦略評価などに使ったりします。
話を戻して4つのPはどういったときに使うのか、大きくは２つのあるかなと。
１つはサービスデザインの段階、つまり設計段階です。もう一つは評価の段階です。
先に評価の段階での使い方としては、アセスメントの軸として使います。
前回プロセスの話をしましたが、プロセスが良くても人の問題でうまくいかないことなんかが良くあります。
物凄く綿密にインシデント管理を設計して、ツールもハイスペックなものを導入したけど、登録がされずにホコリをかぶっています。
非常に残念です。
社内のプロセスは、うまく回っていても委託先の動きが見えず、ブラックボックス化して、高い費用を払い続けるほかない。
これまた残念です。
4つの軸で評価する事で、次のアクションを特定しやすくなります。
同様に４つの軸を網羅的に設計段階で考える事で成果が出やすくなると思います。
特に自社内だけで、現状分析する場合、問題の乱れ打ちで大小入り乱れた観点の違う問題が洗い出されます。
個別に問題解決を図るよりも、4つのPの軸に分けてみると、自社の弱みが全体像としてどこにあるかも把握しやすくなると思います。
みんなで問題を洗い出した後に分類する時にちょっと試してみてはどうでしょうか。
コンサルタントの仕事術〜顧客との合意形成編〜
こんにちはatomです。
前回コンサルタントとは準備が大事だと話しました。
その続きです。
コンサルタントの仕事の仕方は基本顧客との合意形成の繰り返しです。
アプリケーションを開発する場合は、ケースにもよりますが、要件定義から基本設計くらいまで合意形成したら、後はテスト結果や成果物に対する合意形成といった形があると思います。
コンサルタントも問題抽出、原因分析、方針設計、施策の設計など、様々な工程で合意形成をします。
アプリケーションの機能性ほど明確でないケースがほとんどのため、また当初と変わったりするケースが多いため、合意形成をいかに取るかが非常に重要です。
その上でのポイントです。
まず顧客の要求は常に必ずしも目的に対する最適解ではないというのがあります。
それが如実に現れるのは、成果物のレベル感です。
分かりやすいが内容が薄いものと、内容は濃いがかなり理解に経験を要するもの、どちらが適切かは顧客の成果物を使う人の成熟度によって変わります。
リーダークラスと作り上げていても、リーダーの必要とする情報と現場の必要とする情報は異なるので、共に作るリーダーの声に答えるだけでは使えないものになってしまいます。
また、成熟度が低いから分かるように具体的に細かく決めて文書化して欲しいというニーズもありますが、成熟度が低い状況だとそもそも文書を見ないため、見やすい文書で慣れさせる事をまず実施した方が良いケースもあります。
また、細かく決めるには、相応の時間を要するため費用もかかります。
コンサルタントとして重要なのは、顧客の都度の判断時に影響を伝える事が重要です。
ここまで細かくするならば、当初予定のボリューム感から大きく超えるため、スケジュールに影響がでるが良いか。
この先の詳細化は、現場への浸透と共に見えてきた課題を踏まえた方が効率的であるが、それでも今の段階で、詳細化する形で良いか。
いずれも顧客に了解を取って進めています。
これは良い例だと思います。
一方で以下はあまり良くない例です。
もっと具体的に。。。了解しました。頑張ります。
上記の様な回答をして、納期に間に合わなかった場合、顧客は不満を表すでしょう。
そして、遅延をリカバリーするプランも求められたら、遅延を実際にキャッチアップしたりしつつ、さらに同様に顧客の要望に応えようとするあまり、結果応えられずトラブってしまう。負の循環。
これらは、よくよく話を聞くとコンサルタントが目の前の仕事に精一杯で、十分な計画がない中で、とっさの判断で答えてしまって、それがいつの間にか顧客との関係性において固定化され、言われた事をとにかくやる状態になってました。
合意形成とは、双方に責任が発生するものであり、特にコンサルタントとしては、起こり得る事態を想定して適切に情報提供できているか、専門家としての責務を果たしているかが重要だと考えます。
それと共に顧客側にも判断に対して責任を持つ必要があります。当初想定よりもやはり深掘りが必要であれば、スケジュールを伸ばす事を承認するなど。
ここら辺は相手の立場になれば、すぐに分かる事だったりします。
相手の立場を踏まえて、納得し得る選択肢を用意することがコンサルタントの合意形成かなと思います。
またの機会に顧客の視点を探る術について考えていきたいと思います。
