コンサル的思考実験と読書メモブログ

ITコンサルタントが身を持って学んだこと、フレームワークの使い方、書評などを挙げていきます。IT企業や企業内IT部門の管理者やリーダ層の方、ITコンサルタントを目指す方に参考になる情報発信できればと思います。

システム運用現場の実態〜変革を妨げる思考停止〜

このところ応援してくれる人が徐々に増えてきて、閲覧数も上がってきたり、検索の順位も上がってきました。有難いですね本当に。

 

ここでブログを書き始めたのは、自分が日々経験した事を書き記して自分でも整理していきたいという想いとともに、中々世に出てるITILの書籍などはフレームワークとしての知識が中心で、自分自身ITILの書籍を見て参考になった事は正直少なかったので、現場で「使えるノウハウ」を公開したら少しでも役立ててもらえるかなぁという気持ちからです。

 

そんなノウハウを少しずつ書き記していきたいと思ってます。あとは、読者の方が多くなってきたので、そろそろスマホで空き時間に書くのではなく、PCで見やすく図表などの例も入れていければ。。。と思います。

 

今日はシステム運用の現場に入って感じている事を書きます。

 

コンサルタントとして、私の守備範囲としては上流の戦略策定〜組織設計などが多いのですが

実際に現場に入って改善などもするので、現場の人がいかに業務を回すかという事に奔走されてるかを間近で見る機会があります。

 

表現が適切ではないかもしれませんが、そこはいわゆる戦地における最前線で、スピード感が非常に早くゆっくりと意思決定出来る余裕はありません。日々数多く挙がってくる問題に対処していかないとトラブルになってしまう。トラブルを発生させない為に現場のマネージャーは何とか対処しているといった印象があります。

そういった日々は以前ここでも挙げましたが、徐々に管理者の創造性を奪ってしまっているとも感じています。

http://goshux.hatenablog.com/entry/2017/07/21/ルーチンは創造性を破壊する

 

結果として現場は回っていて極端にサービスの品質は悪くないけど、変革を起こしづらい状況にある組織が多いと感じます。

 

ここで押さえておくべきは、誰が悪いと言うわけではなく構造的にそうなりやすいということです。ではどうすれば状況を打破できるのか。組織として考えるならば、絶対にしてはいけないのは人の能力を理由にしてしまう事です。英雄を求めるのは私は思考停止だと思っています。変わる事のできない状況、それを実現するための人材がいない状況は過去の積み重ねの結果発生する問題であり、問題には原因があります。その原因を正しく捉え、仕組みによって解決すると言う考え方、思考法が必要になります。

 

今後、もしも自分がIT部門の部門長になったら、どう対処していくべきか。について述べていきたいと思います。

 

ITIL活用によるコスト削減〜インシデント発生数の予測方法

今回はITツールに登録されたインシデントのデータを使ってデータを分析する事により、コスト削減を行った事例を挙げます。

 

今回の事例でのコストは要員の人的コストを示しています。あるシステム運用の現場で運用アウトソーサーとして前の業者から移管されたものの、当初の見積もりを超えて業務量があり、想定を超過する要員で対応していることから赤字案件となっていました。

想定を超える業務量と言っても、常に超えているではなく、閑散期はむしろリソースに空きがある状況でした。しかしながら現場として忙しい時に基準で人を抱えたいので、現場のマネージャーに相談してもNOを突きつけられてしまいます。

 

そういった背景の中でデータをどう使ったのか。まずは今後見込まれるインシデント数の予測を出して、そこに要員数を算出、要員数が多くかかる月のインシデント発生要因を潰しこむ事でインシデント削減→要員削減→コスト削減といった流れを取りました。

 

インシデント予測の方法ですが過去一年間のインシデント件数がわかる場合、月別に件数を出していき、全体の中央値を求めます。

平均値,中央値,最頻値の求め方といくつかの例 | 高校数学の美しい物語

 

平均値ではなく中央値である事がポイントとなります。ベースとなる件数を中央値で算出して、中央値に対して各月の係数を算出します。3月4月は1.7倍、2月は0.9倍といった感じです。

 

この月の係数こそが月別のインシデント発生トレンドとなります。もちろん新システムのリリースなどで変動したり、大規模な障害が発生すれば変わりますが、不確実性に振り回されては身動きが取れないので、わかる範囲で係数をいじってもいいと思いますが一旦はトレンドを基準に考えて良いと思います。

 

出来るだけ、同年度の中央値を取った方が精度は上がります。実績的には平均誤差率で8%の精度で予測できました。

 

上記の手法で見込みのインシデント数を出して上限となっているところが要員数を抱えるきっかけとなる部分となりますので、上限となっている月のインシデント削減に入っていきます。

 

件数規模にもよりますが、シンプルに行うなら一件一件眺めて、分類を分けていくことでどういったインシデントが多いかわかります。実際に行ったのは3月4月は人の異動で申請系の業務が多く発生するで、その部分の問い合わせを減らすために情報発信用のイントラサイトのページを作ったり、人の役割ごとに期日までに対応すべき事項などのガイドを策定、ChatBotの導入、申請業務の一部RPA活用などの効率化や、端末の事前調達によるキッティング負荷の分散などの取り組みによってインシデント発生数の削減、平準化を行いました。

 

結果として件数が減ったことだけでなく、説明のガイドなどをヘルプが案内する事で効率的に対応が取れた事で、一次解決率や平均対応時間、工数が劇的に向上するといった効果もありました。

 

このようにデータを活用すれば事前対策が進みます。溜められたデータをどう活かすか。マネージャーとして出来る事は多いはずです。取り組んでみてはいかがでしょうか。

自分が成長できているかを簡単に確かめる方法

本当はITIL関連の話を書こうと思っていたのですが、ちょっと休憩して人材育成系の話をします。

 

仕事において自分が成長できているか簡単に確かめる方法に興味がありませんか?

 

それは過去振り返って二つの事を自問してみてください。まずここ3年間は随分前に感じるか、比較的近く感じるか。二つ目に過去の仕事の仕方がない恥ずかしい記憶であるかどうか。

 

これは随分前のことと感じて、恥ずかしく感じていたら成長してると考えられます。それは仕事の幅を広げ色んな事にトライしていたら、3年という期間でも密度が濃く、随分色んなことをしているので長く感じるはずです。四年目の社員が新卒の頃を思い出すと随分前に感じるのではないでしょうか。また、過去の仕事を思い出して恥ずかしく感じるのであれば、今は成長した働き方になっており、過去の自分の仕事の仕方に当時はあんな仕事の仕方してたのかと恥ずかしくなるはずです。

 

一方でそう感じていないなら仕事の仕方も変わっておらず、過去と今を比べても同じ仕事の仕方をしている危険性があります。

 

皆さんはどうでしたか?

ITILツール利用時に用いるKPI事例

前回ITILツールを導入する際はKPI設定に基づいて改善に向けて動く事が重要と述べました。

 

では、実際にどんな使い方ができるのかについて述べて見たいと思います。

 

実際に取り入れてる指標としては、リードタイムと遵守率です。

 

問い合わせは8時間以内、作業依頼や申請の対応は40時間以内と目標を設定します。この指標を計測可能にする為には、ユーザーからの受付の日時と完了の日時を取る事で計測が可能になります。

 

そしてどう改善に向けてPDCAを回すかという部分で遵守率を使います。2000件のインシデントが発生した時に、どの程度目標を満たしているか、遵守率として妥当なのは最低80%出来れば90%を目指すべきです。

 

それに対して、遵守率がどの程度だったのか。上記の数字を満たしていないのであれば、サービス提供のプロセス自体が目標を満たせる作りになっていることを疑います。リードタイムを長期化される構造的な問題をインタビューなどにより明確にして、そこから問題に対する対策を立案していきます。

 

もし遵守率を満たしていた場合は、満たすことのできていないデータを抽出して、原因を分析して該当してあきます。件数が多い場合は、どう行ったシステムなどの分類かでまずカテゴライズしてから、一件一件履歴を確認して原因を探ります。異常値の分析です。

 

異常値となるデータの傾向から原因を特定して、原因に対する対策案を策定して、誰がいつまでにどうするかを決めて改善施策に落とし込みます。後は、その施策の実行状況に対して、遵守率がどう変化したか確認し、施策の実行ができているにも関わらず、変化がなければ施策自体の有効性を疑います。このようにして改善のPDCAを回して行くと、ツールに登録して実績が改善に使えます。この設計こそがITILツール活用のポイントとなります。

 

次回はKPIではないですが、登録されたデータの使い方について述べてみたいと思います。

 

ITILツール導入のポイント〜KPIの設計〜

ブログを始めて一年以上たちますが、ITIL系の記事が人気があります。やっぱり検索で来てもらえるようです。

 

私はコンサルタントになる前にはITILツールのセールスエンジニア、マーケティングを担当してました。ツールの導入やカスタマイズのPMなども実施して来ました。そこでの気づきも含めて今回は私が感じる導入のポイントについてまとめてみたいと思います。

 

まずはその前にこの領域のツール全般に言える問題点として感じてた事からです。ITIL系のツールとは、いわゆるインシデント管理、問題管理、変更管理、構成管理等が行えるある種、対応のワークフローや対応履歴や構成情報などの台帳機能とレポート機能がコアとなる機能のツールです。一言で言うとマネジメントを行うためのツールです。

 

大きな特徴としては、人が入力、操作を行う使うツールなので運用の設計が必要なのですが、それをツールを導入しただけで使いこなすことが難しいということにあります。

ただ、入力の仕方、フローの組み方がITILに基づいていたとしても、ベンダーが語らない難しいポイントが潜んでいます。

 

それは、成果導出の設計です。

ツールに合わせて登録して、フローを回せば業務プロセスを標準的な形で回す事も出来ます。しかしそれはツールの本質的な目的ではないです。この領域のツールはITサービスの運営を継続的に改善する為にあります。ただただインシデントを登録しても可視化はできますが改善はしません。

 

評価する為の指標(KPI)と、分析による施策の立案、実行としていくことで改善が進みます。どんなKPIを設定して、そこからどう改善するかなプランニングこそが最も重要なのですが、その部分の方法論が語られずツールの機能に話が言ってしまうことが多い現状に待ったをかけるべきです。

 

次回実際に私が現場で取り組んだ事例を挙げてみたいと思います。

 

 

 

コンサルタントとして求められるとスキル

最近は子育てに翻弄しつつ日々幸せな日々を送らせてもらっています。

 

日々成長を遂げる我が子が愛おしく、この子の為に親として何ができるだろうと考えたりします。

 

なんでコンサルタントのスキルの話で子育ての話からから始まっているのか。この書籍を読んでる時に気づきがありました。

 

世界標準の子育て

世界標準の子育て

 

本書の中で述べられている部分で日本の教育と欧米の教育の違いについて述べられている部分があります。

 

日本型教育では数値で評価できる知識や技術、ハードスキルを伸ばす教育、欧米は考え方、論理的思考力、分析力、批判的思考力、問題発見力、問題解決力と言ったソフトスキルを伸ばす教育であり、世界の学校教育はソフトスキルの教育に移行しつつあると。

 

この考え方にコンサルタントとして部下を持つ身として非常に共感するところが多かったです。

 

私の専門領域はITサービスマネジメント、いわゆるITILと言ったフレームワークを軸にしたITサービスの運営の領域のコンサルティングとなります。ここで必要となるのはITILというフレームワークの知識はたしかに必要となります。

 

これらは知識として必要なものだと考えますが、ではITILの資格を取り上位資格であるITIL/expertを持っていれば優れたITサービスマネジメント領域のコンサルタント言えるのかといえば答えはノーです。

 

優れたコンサルタントたる人材は、仮に専門知識を有していない領域においても問題解決です。それは前述したソフトスキルが高いからであると考えます。

 

現状を分析して、問題を発見しロジカルに解決策を考える。コミュニケーションを駆使して問題解決を図るというのは、紛れもなく前述したソフトスキルによるものだと考えます。

 

現状をアセスメントして、対策を検討する仕事にしても、一定の型をハードスキルとして教えることはできますが、ある企業でうまく機能した方法論がそのまま他の企業に適用できることはなかなかないと考えます。その企業にあった解決策を設計することができるかどうかなよってコンサルタントとしての能力の真価が問われるのです。

 

今後も子育てからインスピレーションを受けた部分を述べていければと思います。

 

 

 

部下が成長しない原因と対策②

前回に引き続いて部下が成長しない理由について原因と対策を引き続き考えていきます。

 

組織が臨む成果を出すエースは少数派。

組織には考え方が異なる人が集まる。

成長の仕方には考え方が大きく影響する。

 

ではどう対策を講じるか。

現状私も実験的に取り組んでいますが、考え方少しかっこよく言うとマインドセットを変えるには気づきを持ってもらう必要があると思います。

 

多くのケースで今の自分を変えれないのは、今の自分に大きくは課題意識を持てていないか、変えるためのイメージを持てていないと部下とのやりとりの中で見えてきました。年齢が上がるほど前者の傾向があり、若いほど後者の傾向があるようです。

 

そしてどちらも振り返りが出来ていませんでした。なんとなく振り返る事はあっても、自分の認識の中で振り返りをするので、出てくる答えは限定的になります。そこで振り返るためのベースとなる行動指針を設けてみました。

 

我々の目指す仕事とは何か。

そこに至るためにどんなポイントに日々気をつけるべきか。

 

そしてそれを元にチームで振り返りのセッションを、持つことにしました。それを提示して改めてわかった事は、教育が行き届いていない環境ほど、自分なりの考えに基づいて仕事に臨むので、その自分なりが成長や成果に繋がらない考え方であれば、それは成長のスピードという結果になって現れているようです。

 

気をつけなくてはいけないのは、往々にしてメンバの方々は別に極端にサボっているわけではないので、その状態で頭ごなしに何で出来ないんだといってもモチベーションを奪う結果にしかなりません。

 

上司として取り組むべきは、部下の現状の認識をすくい上げ、別の可能性もあるよと提示し続ける事にあると思います。自分の成功体験を元に行動指針を作っても、それも一つの可能性でしかない事に気をつける必要があります。

 

自分も常に最新の注意をしながら、今後の経過を見守りたいと思います。そして忘れてはいけないのは、自分が成果を出している側の人間だったとしても、少数派であるならば、少数派で120%の成果を出すより、皆を100%に近づける方が組織としての成果は大きくなります。

 

上司は部下のためにある事を忘れずに今日も一日頑張りたいと思います。

 

 

 

 

 

 

 

 

部下が成長しない原因と対策①

仕事の難しさを感じる時多くのケースで人の問題に行き着きます。

 

殆どの組織において、組織の臨む成果を出すエースというのは少数派となり、成果を出すと上に上がるため、課長クラスのミドルマネジメントはエース、部下は次期エースと多数のそうではない人たちという構図が出来上がります。

 

こんな気持ちになった事はないでしょうか。

これは私の実体験での話です。エースと呼ばれ圧倒的な成果を出し、人の上に立つ様になって陥った事です。

 

部下に仕事をお願いしたのに進まないことがしばしばありました。

なんでこんな当たり前の事が出来ないのか。

何もそんなに難しいことお願いしてないのに。

できないなら相談してよ。

せめて出来ないなりにもがいてよ。

こんな気持ちに私はよく陥ってました。

部下と話すときは理詰めで話してしまうので、部下は何も言えなくなってしまう。

 

自分の理詰めの内容が合ってようと間違っていようと、部下のモチベーションは上がらず、当たり前だと自分が思う事をその後も部下が実施してくれるという事はありませんでした。年上の部下の場合は理詰めで話をしていると感情的にキレられてしまう事もしばしば。こんな事が続いていたので人間関係も良いものとは言えない状況です。

 

こういった状況下は何故発生するのか、どう変革していくのか。

 

まず私が前提に置くべきだと感じたのは、部下は自分とは違うという事、自分を起点とした論理で人を動かそうとしてもそもそも当てはまりらないという事。論理の落とし穴は暫定を正しく捉えないと正しい答えに近づく事はできません。私はまず考え方やに対する考慮が欠けていだのです。

 

例えば仕事というものの捉え方何のために働くかも人によって異なります。仕事にやりがいを求める度合いも成長に対する必要性に対する認識も違います。そもそも考え方が違う人に対して、自分のロジックで動けという方が難しい事なのでなかったかと今では思うようになりました。

 

ではエースは組織の少数派という前提のもとにどう考え方の事なる人が集まる組織で、臨む成果を出すのか。

 

次回に続きます。

企業再興の秘訣とは〜次世代の経営者に贈る珠玉の1冊〜

久しぶりにアップします。

 

今日は私が最近読んだ本の中で特にオススメしたい書籍を紹介します。

 

まずはこちら。Hit Refresh。Microsoftの現CEOのサティア・ナデラがGoogleAppleに遅れを取ってから再興のするまでにナデラが考えた事、実行した事、そしてテクノロジーの未来について紹介されています。

 

Hit Refresh(ヒット リフレッシュ) マイクロソフト再興とテクノロジーの未来

Hit Refresh(ヒット リフレッシュ) マイクロソフト再興とテクノロジーの未来

 

 ナデラを語る上でキーワードとなるのが東洋思想ですが、本書では経営者としておさえるべき哲学が語られていると感じます。

 

企業の存在理由とは。OS市場のゼロサムゲームから脱却し、新たにMicrosoftのCEOとしてとんなビジョンを語り、従業員を成長のマインドセットに転換していったか。

 

私が本書から学ぶべき事として、経営者として本質的に問われる能力として最も根幹をなすのは、倫理観ではないかと感じる。人として、経営者が述べる言葉に共感できるかどうか。そこから企業のパフォーマンスに関わる文化形成が始まる。

 

人が賃金以外の理由で情熱的働くに足る動機を創り出す上では、ただただ数値的な売り上げ目標を与える事ではない。それはあくまでも手段である。自分達の仕事に意義を与え、自信を持って働く事の力こそがMicrosoftの再興に繋がったということが本書を通じて体験できるのではないだろうか。

 

思わず自社の社長に進めた一冊です。

 

 

ダークスキルの必要性〜人を動かすメカニズムの考察〜

書店でふらふらと面白そうな本を探してたらこんな本見つけました。

 

ダークサイド・スキル 本当に戦えるリーダーになる7つの裏技

ダークサイド・スキル 本当に戦えるリーダーになる7つの裏技

 

 

内容としては、ミドルマネジメント向けの書籍です。改革を起こすためには、情報の非対称性(あの人は知ってるけどこの人は知らない)があるため、トップマネジメントは限定された情報を拠り所にマネジメントを行うしかない。

 

そういった中では、どちらの視点も持ちうるミドルマネジメント課長クラスが変革の担い手となる必要がある。

 

ロジカルシンキングや会計の知識などのいわゆる王道的なブライトスキルを身につけるだけでなく、周りを巻き込むためのコミュニケーション能力や上司すら動かすダークスキルの必要性を説いています。

 

実際には確かに必要性を感じたりします。

 

成長に段階があるとするならば、自分自身の能力により問題解決出来るようになる段階が第1段階、人を動かして問題解決していくのが第2段階であると感じます。

 

第1段階を変えれば、社内では優秀な部類に入ったくると思いますが、そこから第2段階に進む事が出来ずに忙殺されてしまっているケースなど目にする事があります。

 

第1段階と第2段階では努力するベクトルが変わります。自分が頑張ればいいわけではないので、より人を動かす戦略が必要になると思います。

 

とはいう自分もうまく第2段階に行けていないと感じています。自分で完結できる問題解決はある程度解決の筋道は見いだせるのですが、他者からその能力を引き出すにはその人ごとに異なる動機付けが必要になります。

 

まだ完全にうまくいってはいないですが、意識しているのは構図です。これは営業活動でも有効なのですが、どうやったら相手にとっての必然性を導き出す構図を作るかを意識します。

 

例えばお客様にとって我が社のサービスを選ぶ必然性。言葉にすれば当たり前の事ですが、買ってくださいではなく、いかに売ってくださいと言わせるかが重要です。その為には相手の論理を見抜く事が必要だと思っています。

 

人が何か意思決定をするのは、意思決定に至るロジックがあります。詰将棋のイメージが最もしっくりくるのですが、相手のロジックを先読みして、判断の選択肢をコントロールする。

 

現代のビジネスはロジカルシンキングをベースに行われているので、そこまで突飛な発想は必要ないと思います。ただし、ロジカルシンキングは前提をうまく捉える事が精度を上げる事なので、相手の立場になってロジックを組み上げる事かできれば、後はやるだけです。

 

上司の立場で考えるならばどう動くと自分の求める答えを引き出せるか、部下の視点で考えるならば自分がどう動くという事を聞いてくれるか。

 

非常に頭を使いますね。

まだまだ徹底してやりきれていないです。。

 

ただここまで考えてると他責の感情というのは無くなってくると思います。ただなんでそこまでやらなきゃいけないんだろうという葛藤が生まれたりもします。

 

こういった事を意識的でなく出来てしまう人はただただ尊敬です。

 

突き詰めていくと自分自身をいかに動機付けするかや、思いやりの心を持つかとかうっすらとですが、そんなものの、必要性を感じたりしてます。

 

今日も頑張ろっと。

 

新しい運用の形〜Googleで行われる最新の運用管理〜

最近この書籍を読んでいます。

 

Googleの運用管理ノウハウが詰め込まれている書籍です。

 

Googleでは運用を担当する人に50%ルールというものがあり、開発者が運用して、運用業務に当たる工数を50%までに減らすために自動化を推進する。

 

DevOpsで運用のフロントローディング、すなわち開発への参画という考え方があったが、こちらはDevOpsの考え方を進化させていて、開発者が運用を自動化するまでをスコープとしているところが興味深かかった。

 

開発者と運用者ではスキルセットが異なるため、自動化が進まないケースが多い。 

 

ご興味がある方は是非。

運用なら課題を感じたり、コンサルやる人は必読です。

 

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム