コンサルタントのスキルアップ術〜行動原理とコンピテンシー〜

成長の仕方やその為の方法論は、個人ごとにある根底のマインドが大きく関わるのは言うまでもない事ですが、具体的にどんなマインドでどういった行動をしたら成果に繋がるのでしょうか。

今日はその辺についてお話ししていきます。

自分は元々仕事に対して劣等感を持っていました。技術者としても中途半端、コミュニケーション力が高くもなく、プレゼンも苦手で人前に出ると汗が止まらずテンパってしまう。資料はうまく作れず文章力も拙い。頭の回転も速くない。様々な点で人並み以下という自覚がありました。

その分人よりやらないと人並みにならないという、危機感があった様に思います。実際に若手の頃お世話になった人には、迷惑かけすぎていて、頭が上がらないです。

現在はどうかと言うと、どれも優れているものはありませんが、結果がついてきている事実から人並みくらいにはなれたと思います。

ジョブアサインにも恵まれたとは思いますが、自分なりにどうすれば成長できるかと言うことだけは人に負けないくらい切実に考えながら過ごしてきた様に思います。

例えば、仕事が任されるチャンスがあると見るや任されるのを待たずに必ず仕事を取りにいってました。そして任された仕事は絶対に逃げずにやりきることは徹底してきたと思います。もちろん大きな失敗も多く経験しています。上司にボロクソに言われることも経験してきています。それでも前のめりに仕事していたと思います。

そうやって動いていると周りの見る目が変わってくるのだと思います。まだ厳しいかもしれないが任せてみようといった感じです。今部下を抱える身となって自分でも感じますが、任せたいと思える人と思われるかどうかいうのは非常に重要な事の様に感じます。ジョブアサインを考えるとき、そのスキル面でのフィジビリティも重要ですが、この人のコンピテンシー（行動特性）を判断されるのだと思います。

スキルがあってやれそうな人よりスキルは足りないけどやり切りそうな人とでもいうのでしょうか。それは日々の仕事ぶりを見て暗黙的に判断されていると思います。スキルはあるのにジョブアサインに恵まれないと考えている人はそういった点に何か問題があるのかもしれません。

あとは、苦手な事や経験のないでも繰り返し取り組んだことが重要だと考えています。慣れていき、型ができてくると以前は苦労したことが全く苦労しなくなります。正確には苦労だと感じなくなります。

苦手な事や経験のないことに取り組むのは勇気がいる事で、それは意識的にやらないとやらないままになります。やらないままで行くか、取り組む事で経験から学び取るかは差に出ると思います。

コンピテンシーを深掘りすると、自分がどうなりたいか、何のために仕事をしているかといった根源的な問いに行き着くと思います。

苦手な事や取り組んだことないことでもやっていくのは、結局それが自分にとってメリットになると感じているからです。今今やりたいかやりたくないかではなく、将来的にそれがプラスになるかどうか、暗黙的に意思決定しているのだと思います。 

 では自分は何の為に仕事をしているのか。

こういった問いを自分にぶつけると、行動原理ともいえる自分の大元の意思決定のロジックが見えてきます。

①人生は一回どうせなら楽しみたい。

②人生の中で多くの時間をさく仕事は楽しみたい

③楽しくするために影響力をもってより貢献できる仕事がしたい

④能力が不足している自分がそれを望むなら足りないものを補っていく必要がある

⑤自分を成長させる働き方を選ぶ必要がある

 これはあくまで自身のケースで、皆さんに当てはまる事は少ないと思います。

しかしながら、自分の成長のさせ方、周りからの見え方に繋がるコンピテンシーとその土台となる行動原理について、少し立ち止まって考えてみてはいかがでしょうか。

IT部門長なら読んでおくべき一冊〜ITコストマネジメント〜

今回はコストマネジメントの話です。

どんな企業でも取り組んでいますが、うまく取り組めていると感じている企業は少ないのではないでしょうか。

部門長クラスの業務として定着していますが、業務の中で覚えたという方がほとんどで専門知識を学ばれていると感じる事は正直ないと感じるのが実態です。

最近多く出るテーマとして費用配賦についてです。

売上を上げる組織ではないので、事業体から費用を配賦する事でIT部門における予算を組んでいきますが、どの様に考えていいかわからず助けて欲しいと言った悩みにのったりします。

また、何をIT部門が管理すべきIT資産とするかという点も曖昧になるケースが多いと思います。

事業部門が契約しているクラウドサービスはIT資産となるのか。電話機などは総務管轄なのかなど線引きができず、結果として全社のIT資産を特定ができずITコストの可視化ができていないといった状況があります。

少し古い書籍ですが、IT資産の管理対象の考え方を学ぶ上で役に立った資料を紹介します。

IT投資とコストマネジメント

何をIT資産とすべきかという点や企業の成熟度に合わせてコストマネジメント実施レベルが記載されているため、その辺も参考になりました。

興味ある方はご一読いただければと思います。 

ITIL活用〜変更管理のプロセス設計その1〜

構成管理のプロセス設計の話を少ししましたが続いては、変更管理の話をしていきたいと思います。

変更管理とは、以下の様に定義されています。

「変更が素早く正確に、ITサービスのインパクトを最小限に抑えるために、定められたルールや手順を確実に行うプロセス」

ここでいう変更とは、顧客の事業上のニーズに応えたら、インシデントの根本原因を解決する為に構成情報に対するリソースの追加やアプリの改修などを示します。

ITILでは、変更の種類を大きく以下の三つに分類しています。

①標準的な変更

→低リスク高頻度で変更内容が定型化できる変更

②緊急の変更

→障害修正など緊急で対応すべき変更

③通常の変更

→標準的でも緊急でもなく運用上発生する変更

私はここに独自に以下を追加して設計しています。

④大規模な変更

→大規模な基盤刷新などプロジェクト化されて開発側で主管で管理する変更

④を追加しているのは、開発側主管で管理される大規模な変更も統合管理すべきとの想いからです。

プロセス設計の話に戻りますが、 まずは構成情報に対して発生しうる変更の洗い出しと分類となります。

これはのちに変更の種別ごとにプロセスフローや承認者を特定していく上での前提情報となります。

また、一覧に変更のユースケースを洗い出し、上記分類と現状のフローや承認者を洗い出していきます。

これらを類型化する事でITILプロセス導入とともに効率化を実現したり、ガバナンスの強化を図ったりします。

次の機会ではフローや承認者の考え方について話していければと思います。

IT部門長なら読んでおくべき一冊〜デジタル化時代のIT組織〜

以前デジタルトランスフォーメーションという書籍を紹介しましたが、同じくベイカレントコンサルティング社の著作となる以下の書籍を紹介します。

デジタル化を勝ち抜く新たなIT組織のつくり方

事業のデジタル化は、不可避なトレンドだと思います。その中で、IT組織の構造変革は既に始まっています。

しかしながら、取り組みを加速させている企業と全く意識できていない企業と大きな差を感じる状況にあります。

本書では、外部環境の変化をおさえたり、IT組織の目指すべき指針を探る上で一助となると思います。

IT組織の部門長や課長、リーダークラスの方に読んで頂きたいですね。

コンサルタントの仕事術〜合意形成こそ変革成功の鍵〜

このところIT部門のコンサルに入っていて、事業部の支援機能を強化する為に、組織変更案を策定といったコンサルティングを実施しておりました。

組織変更の概要としては、多角的な事業を展開する企業のIT部門で少人数で日々の業務を回していたので、兼務が進行していました。

結果として一つ一つの業務の把握が甘くなっていたため、事業部担当チームの設置とそれを実現するためのノンコア業務のソーシング活用とその準備などを実施してきました。

ようやく組織変更の目処がついてくると、次のステップとして、組織変更の詳細を如何に現場に伝えて理解を得るかという課題が挙がってきます。

組織として最適配置を考えると、必ずしも個々人の意見通りにはならない事は良くあります。そういった際に部門長はどう動くべきなのか。

正解はその段階で動くのではなく、方針策定時点での合意形成こそが重要です。

組織変更する際はその目的、目指すビジョンへの共感を部下から得る必要があります。

誰もが会社を悪くしたいとは考えてませんが、良くするために必要以上の事をしたいとも考えていないのが現状です。その考えを変革していくには常日頃からビジョンを語り合える状態を作る必要があります。

そして上が決めたビジョンではなく、皆で決めたという構図を予め作る事が重要です。その為、組織変更の際になって困らないように、方針策定時点での合意形成が重要となります。

合意形成から日が経つと忘れてしまう事があるので、必ず合意した内容は言質として資料化する事をお勧めします。記名で残しておくとなお良いと思います。

コンサルタントとしては、何手先を読んでその為の準備をしておけるか、この辺が成果に跳ね返ってくると思います。

変革を行う前には意識して見てはどうでしょうか。

コンサルタントの考察〜色々コンサル〜

コンサルタントをしていると周りに色んなタイプの人がいます。

フレームワーク至上主義コンサル

→フレームワークを如何にうまく使うかを考えてる人。作成される資料は細かめ。

現場主義コンサル

→現場に入り込み、絶大な信頼を得るが共感しすぎて自らも現場と同化する。フレームワークは嫌い。

評論家コンサル

優れた分析力を武器に問題抽出、原因分析をするも、実行のプランニングとアクションは苦手。ロジックには自信があるが、担当を割り当てられると急に声が小さくなる。

指導者系コンサル

圧倒的な存在感で皆に先生と言われるが、資料作成は苦手。いるだけで安心感があるのか、顧問契約しているクライアントを渡り歩く。

資料作成スペシャルコンサル

圧倒的な資料作成能力を駆使してpptで100枚を超える資料でクライアントを圧倒。

大リーガーコンサル

話を広げるだけ広げてロマン飛行。話をたたむ頃にはいなくなる。受注能力がやけに高かったりする。請負契約には不向き。

実務至上主義コンサル

実行能力は極めて高く、確実な成果をあげるが話を広げることには慎重なため、話が大きくならない。大リーガーコンサルは嫌い。

マイウェイコンサル

資料を見るたびに自分なりに編み出した言葉や考え方が追加されていく。業務に非常に精通しているせいか、説明を聞いてるうちにクライアントも何故か納得していまう。突破力が非常に高いが、結局どう進めるのか誰も分からない。

キャッチアップコンサル

PMOとして参画し、打ち合わせの中でキャッチアップという単語を多用する。

体調不良コンサル

常に体調が悪そうでマスクは外さない。一生懸命で、仕事を抱え込む傾向がある為、クライアント自ら気を遣って仕事を引き取ってしまう。

Excelマクロコンサル

Excelマクロを駆使し定量的な分析では右に出る者がいない。ただし1番やりきった顔をするのは美しいマクロが組めた時。商用ツールは基本的に嫌い。

寝技使いコンサル

提案した成果を出す事に注力するのではなく、クライアントとお酒を酌み交わし、鉄のリレーションを築き上げる。キックオフ前の打ち合わせで、まず飲み会の日程を確認する。

皆さんは今までどんなコンサルタントに出逢ってきたでしょうか。コンサルと一緒に仕事するときは、楽しみながらご一緒できれば幸いです。

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

構成管理の管理対象が決まったら、構成アイテムを維持管理する活動、体制、評価指標などを設計しています。

構成管理の代表的な活動としては、棚卸しがあります。構成監査という言葉でITILでは定義されています。

実際の構成アイテムの実態と構成情報として管理している情報を照合し、正しい構成情報が維持できているか、完全性などをチェックしていきます。

実態と言ってる方は資産管理ツールなどで収集した情報とITILツールから出力した情報を比較して、違いがあるかなどを確かめます。

違いがあればあるほど、ツール上などで管理されている情報の精度が低いことが分かります。

構成情報に実態との差異が生まれてくるのか。

変更管理の説明とともに今後説明していければと思います。

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

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

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

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

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

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

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

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

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

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

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

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では、エスカレーションを以下の通りで定義しています。

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

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

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

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

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

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

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

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

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