コンサルタントのキャリアパス考察〜コンサルタントへの最短距離とは〜

最近ほぼ新人の若手がコンサルタントになるべく配属されてきます。

ちなみに自分は技術上がりで、セールスエンジニア、マネジメントなど経験してからコンサルになっています。

今なんとかやれているのは、そこで培ったもの+αがあるからだと思います。

そう思うと若手が何も経験しないままコンサル組織に来ることには懐疑的です。

また、コンサルタントといっても専門領域が沢山あるので、コンサルタントになりたいと漠然と考えるのではなく、もしなりたいなら何に対してコンサルティングをしたいのかを考えた方がいいと思います。

これはあくまでも私の経験則ですが多少なりともその領域を経験した方が成長は早いと思います。というか私自身が全くの未経験からコンサルティングをしていないので、その成長のための方法論が確立できてないというのが現状です。

このブログを読んでいる方でコンサルになってみたいと思っている方にアドバイスをするとしたら、もしすでに自身に得意分野があるならばその道でコンサルティングをすれば良いです。正直コンサルとはコンサルと名乗ればコンサルです。なる事に意味はなくそこでのコンサルティング活動に価値があるかどうかが重要です。今いる組織でもコンサルティング業務を行う事は可能だと思います。

ゼロからコンサルタントを目指すなら、新卒のコンサルを大量に採用しているコンサルファームにいく選択肢もあるとは思います。多少は教育してくれるかもしれません。

コンサルタントは職種ではなく、専門性を武器とした問題解決の専門家でしかない気がします。であるならば専門性をいかに身につけるかを考えていけばその先にコンサルタントという職種の道が開けるのではないでしょうか。

その先に学ぶべき+αの部分はまた別の機会にお話ししていきます。

ITIL活用〜構成管理プロセス設計その2〜

構成管理の管理対象を決めたら次に実施すべきは構成識別です。

構成識別とは、一言で言うのであれば管理粒度決めです。

なぜ粒度を決めるのかというと、アプリケーションモジュールを管理対象としたとしても、その一つ一つを管理すると数万モジュールになってしまう場合などあり、一つ一つを管理する事は現実的ではないケースがあります。

その為、どの粒度で管理するかが運用面や得られる成果において重要になります。

一例ですが、アプリケーションモジュールの管理においては、リリースパッケージ化された単位で管理する事が多いと思います。

ちなみパッケージ化という言葉を使いましたが、リリースする際に一つの障害対応や機能追加するモジュールごとにリリースせず、複数まとめてリリースすると思います。そのまとめたものリリースパッケージといいます。

構成管理の粒度を決める上では、構成情報をどう使うかによって要件が変わってきます。

リリースパッケージ単位の管理の例だと、何かトラブルがあった場合、ユーザーの環境がどのリリースパッケージのバージョンなのか特定できれば、障害点の切り分けはしやすくなります。

構成識別は顧客に検討を依頼すると大体どの粒度まで管理すべきか教えて欲しいと言われます。妥当性や確からしい粒度が分からないと。

構成識別は確からしさを求めるとドツボにハマるケースがあります。構成識別に限らずプロセス設計全般に言えますが、一般的な確からしさを求めるのではなく、まず自分達が実現したい成果が最低限出せるレベルで設計する事が重要です。

後日、構成管理のその他の活動や評価指標について話していければと思います。

ITIL活用〜構成管理プロセス設計その1〜

構成管理に取り組んでいきたい。

ITサービスマネジメントに取り組んでいる企業で、インシデント管理や要求実現、問題管理などを整備が済むと大体話に挙がるのが構成管理です。

これから少し構成管理のプロセス設計について話していこうと思います。

構成管理に取り組む上でのはじめの一歩は何か。

その前に少し前提をお話しします。

構成管理は以下の様に定義されています。

『ITサービスを提供するために管理すべきコンポーネントの完全性を保ち、必要なタイミングで利用できる様にする事』

管理すべきコンポーネントを構成アイテム（CI）と呼んだりしますが、管理すべきという点が重要になります。

人の頭の中にあるナレッジはITサービス提供においては重要ですが、構成アイテムとはなり得ません。

管理すべきというのは、コントロールされている状態を作るという事でもあるため、変更管理、リリース管理を通して変更していくといくとでもあります。

構成管理のプロセス設計では、何を管理すべきかを決める事から始めます。

そのためには、ITサービス提供における構成要素の洗い出しから始めます。

ある基幹システムはどんな構成要素があるか。

 ハードウェア、ソフトフェアなどまずは思いつく限り洗い出していってください。

それらがどう関連しているかモデル図を書いて整理していきます。これを構成モデルといいます。

その中で管理すべき対象を決めていきます。

どう管理対象を決めていけばいいのか。その辺の考え方について次回お話しできればと思います。

ITIL活用〜インシデント管理におけるエスカレーションルール〜

こんにちは。atomです。

平日はほぼ日刊ブログとなりつつあります。調子がいい時は日に2回くらい更新してます。

書くことが沢山あるというのは、自分が好きな仕事出来てるんだなと思います。

最近、天職の見つけ方という記事を見てふむふむと思いました。

https://www.kayac.com/news/2016/11/yanasawa_blog_vol18

昔サービスを拡販する部署にいて、マーケティングの一環としてブログを始めて当番制で書いてました。その頃は当番なんて2、3ヶ月に一回でも批判浴びてましたが、自分の興味あることはブログ書くのは苦になりませんね。

書きながら整理されて、より自分なりの理解やその表現の仕方が整理されていく気がします。

では今回のお題のエスカレーションルールについてです。

前回までの体制を円滑に機能させるためには、それぞれの役割の定義とともに、エスカレーションルールなるものが必要になります。

そもそもITILでは、エスカレーションを以下の通りで定義しています。

『サービスレベル目標値や顧客の期待を満たすために必要なときに、追加のリソースを入手する活動。』

また、エスカレーションの種類として機能的エスカレーションと階層的エスカレーションを挙げています。

覚え方として機能的エスカレーションは詳しい人に相談する、階層的エスカレーションは偉い人に相談するくらいに覚えてもらえればいいです。

ネットワークの専門的な質問はネットワークに詳しい人に聞くといった感じです。

エスカレーションにおいて重要なのは、どういう時にエスカレーションすべきかどう判断するかとなります。

ここでは一次対応スタッフと二次対応スタッフのエスカレーション基準について例をあげます。

ナレッジの有無が基準の一つとなります。一次対応スタッフがナレッジを検索しても対応できない場合は、二次対応スタッフにエスカレーションする。

更にサービスレベルに応じて、一次対応スタッフが保有できる時間などでもエスカレーションするか判断します。なるべく機械的に判断できる方が良いですね。

体制を決めたら、体制間を繋ぐエスカレーションルールも決める事を忘れずに。

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×プレジデント」エグゼクティブセミナー選書)

 では本題です。

DXによって事業部門側のITが強くなるにつれて、IT部門の役割構造が変わってきています。

いわゆる攻めのIT（売上増にむけたIT活用）に事業がシフトするので、それまで事業部門側で持っていた、既存業務の企画、構築、保守、運用などをより引き取っていく必要があります。

そもそも事業部門がDXしていきたいといっても、人員が増える訳ではなく、今までも暇しているわけでも無いので、事業部門のDXを支えるために既存業務のITについてより、IT部門の関与を増やす必要があります。

具体的には何をすれば良いのか。

事業部門側で主で行なっていた、要件定義（厳密には要求定義）をIT部門が巻き取る必要が出てきます。

どんなITサービスがあれば良いのか要件を伝える事自体をIT部門が担うという事は業務に精通していないといけないという事です。

そんなのできっこ無いよと言われそうですが、現に多くの企業がその為の一歩を踏み出しています。

事業部門の業務に精通するために、IT部門としての既存業務の一部をノンコア業務として、アウトソーシングする例が非常に増えています。

その為の可視化や標準化という領域の整備に各社取り組んでいる状況です。

また、ジョブローテーションによる事業部門との人材交流なども活発化しています。

そして、ノンコア業務のベンダーへの移管にむけたベンダーマネジメントのルール整備などのお仕事の依頼が後をたたない状況です。

複数社ある委託先のベンダーをコントロールするベンダーを設けるといった動きも出てきています。

先見性のあるマネジメントの方はすでに動き出しています。

貴方の会社は如何でしょうか。

ではまた！