コンサル的思考実験と読書メモブログスマートフォン用の表示で見るコンサル的思考実験と読書メモブログITコンサルタントが身を持って学んだこと、フレームワークの使い方、書評などを挙げていきます。IT企業や企業内IT部門の管理者やリーダ層の方、ITコンサルタントを目指す方に参考になる情報発信できればと思います。この広告は、90日以上更新していないブログに表示しています。2019-09-25受注率が上がる提案方法1私はコンサルタントとして自分で受注して、自分で対応しきる所までやります。有難い事に新規のお客様の提案においても、提案機会までこぎつけたケースでは大体50%くらいのケースで受注する事ができます。残りの25%は時期がずれ込んでしまう。残りの25%が敗戦してしまうと言った状況です。継続しているもの60〜70%、残りを毎年新規のお客様より仕事をいただき、1億程度の受注をする構成となります。案件のライフサイクルとして、長くても案件の性質上3ヶ月から2年程度のスパンとなります。2年もやると大体の課題が解決してくるので、一旦終息となり、少し経つとまたお声がかかる形となります。人の人月数える提案も中にはありますが、問題解決を成果に人月依存しない提案が多いです。金額や受注率は一概に高い低いはないと思いますが、自分が食べる分+周りにパスできるくらいの受注はしている状況です。考えを少しずつ整理をしながら述べていこうと思います。ご興味があれば、星つけてもらえるとを嬉しいです。20:40受注率が上がる提案方法1Tweet広告を非表示にするもっと読むコメントを書く2019-09-19情シス子会社の生き残りの術とは大企業の情シス子会社を支援する事が多いこの頃です。人月でのビジネスでは人材不足が進む中、売り上げ拡大が見込めず、情シス子会社は生き残りをかけて変化が大きくなっている。事業のデジタル化が進み、親会社のIT機能は事業貢献にシフトが求められており、既存の保守運用は情シス子会社に巻取りが進んでいる。それら背景の中で情シス子会社は、より多くの保守運用を巻きとれるように、親会社だけでなくグループ会社も含めたシェアードサービスの保守運用体制の構築が急務となっている。契約形態も人月ではなく、サービス契約とする事で、効率的なサービス提供による売り上げ拡大や利益率の向上にシフトし始めている。一方でそれをどう実現するかの術が分からない状況が続く。運用を回す事には長けているが、スキルアンマッチにより、ビジネスとしてどう組み立てるかを設計、実行できる人材が圧倒的に不足しているのである。このスキルアンマッチを仕組みとしてどう解決できるかに情シス子会社の生き残りのポイントがある。戦略このところ応援してくれる人が徐々に増えてきて、閲覧数も上がってきたり、検索の順位も上がってきました。ここでブログを書き始めたのは、自分が日々経験した事を書き記して自分でも整理していきたいという想いとともに、中々世に出てるITILの書籍などはフレームワークとしての知識が中心で、自分自身ITILの書籍を見て参考になった事は正直少なかったので、現場で「使えるノウハウ」を公開したら少しでも役立ててもらえるかなぁという気持ちからです。そんなノウハウを少しずつ書き記していきたいと思ってます。あとは、読者の方が多くなってきたので、そろそろスマホで空き時間に書くのではなく、PCで見やすく図表などの例も入れていければ。今日はシステム運用の現場に入って感じている事を書きます。コンサルタントとして、私の守備範囲としては上流の戦略策定〜組織設計などが多いのですが実際に現場に入って改善などもするので、現場の人がいかに業務を回すかという事に奔走されてるかを間近で見る機会があります。表現が適切ではないかもしれませんが、そこはいわゆる戦地における最前線で、スピード感が非常に早くゆっくりと意思決定出来る余裕はありません。日々数多く挙がってくる問題に対処していかないとトラブルになってしまう。トラブルを発生させない為に現場のマネージャーは何とか対処しているといった印象があります。いった日々は以前ここでも挙げましたが、徐々に管理者の創造性を奪ってしまっているとも感じています。http://goshux.hatenablog.com/entry/2017/07/21/ルーチンは創造性を破壊する結果として現場は回っていて極端にサービスの品質は悪くないけど、変革を起こしづらい状況にある組織が多いと感じます。ここで押さえておくべきは、誰が悪いと言うわけではなく構造的にそうなりやすいということです。すれば状況を打破できるのか。組織として考えるならば、絶対にしてはいけないのは人の能力を理由にしてしまう事です。英雄を求めるのは私は思考停止だと思っています。変わる事のできない状況、それを実現するための人材がいない状況は過去の積み重ねの結果発生する問題であり、問題には原因があります。その原因を正しく捉え、仕組みによって解決すると言う考え方、思考法が必要になります。今後、もしも自分がIT部門の部門長になったら、どう対処していくべきか。ついて述べていきたいと思います。今回はITツールに登録されたインシデントのデータを使ってデータを分析する事により、コスト削減を行った事例を挙げます。今回の事例でのコストは要員の人的コストを示しています。あるシステム運用の現場で運用アウトソーサーとして前の業者から移管されたものの、当初の見積もりを超えて業務量があり、想定を超過する要員で対応していることから赤字案件となっていました。想定を超える業務量と言っても、常に超えているではなく、閑散期はむしろリソースに空きがある状況でした。現場として忙しい時に基準で人を抱えたいので、現場のマネージャーに相談してもNOを突きつけられてしまいます。いった背景の中でデータをどう使ったのか。今後見込まれるインシデント数の予測を出して、そこに要員数を算出、要員数が多くかかる月のインシデント発生要因を潰しこむ事でインシデント削減→要員削減→コスト削減といった流れを取りました。インシデント予測の方法ですが過去一年間のインシデント件数がわかる場合、月別に件数を出していき、全体の中央値を求めます。平均値ではなく中央値である事がポイントとなります。ベースとなる件数を中央値で算出して、中央値に対して各月の係数を算出します。3月4月は1.7倍、2月は0.9倍といった感じです。この月の係数こそが月別のインシデント発生トレンドとなります。新システムのリリースなどで変動したり、大規模な障害が発生すれば変わりますが、不確実性に振り回されては身動きが取れないので、わかる範囲で係数をいじってもいいと思いますが一旦はトレンドを基準に考えて良いと思います。出来るだけ、同年度の中央値を取った方が精度は上がります。実績的には平均誤差率で8%の精度で予測できました。上記の手法で見込みのインシデント数を出して上限となっているところが要員数を抱えるきっかけとなる部分となりますので、上限となっている月のインシデント削減に入っていきます。件数規模にもよりますが、シンプルに行うなら一件一件眺めて、分類を分けていくことでどういったインシデントが多いかわかります。実際に行ったのは3月4月は人の異動で申請系の業務が多く発生するで、その部分の問い合わせを減らすために情報発信用のイントラサイトのページを作ったり、人の役割ごとに期日までに対応すべき事項などのガイドを策定、ChatBotの導入、申請業務の一部RPA活用などの効率化や、端末の事前調達によるキッティング負荷の分散などの取り組みによってインシデント発生数の削減、平準化を行いました。劇的に向上するといった効果もありました。このようにデータを活用すれば事前対策が進みます。溜められたデータをどう活かすか。マネージャーとして出来る事は多いはずです。取り組んでみてはいかがでしょうか。スキルアップ本当はITIL関連の話を書こうと思っていたのですが、ちょっと休憩して人材育成系の話をします。仕事において自分が成長できているか簡単に確かめる方法に興味がありませんか?それは過去振り返って二つの事を自問してみてください。ここ3年間は随分前に感じるか、比較的近く感じるか。二つ目に過去の仕事の仕方がない恥ずかしい記憶であるかどうか。これは随分前のことと感じて、恥ずかしく感じていたら成長してると考えられます。それは仕事の幅を広げ色んな事にトライしていたら、3年という期間でも密度が濃く、随分色んなことをしているので長く感じるはずです。四年目の社員が新卒の頃を思い出すと随分前に感じるのではないでしょうか。過去の仕事を思い出して恥ずかしく感じるのであれば、今は成長した働き方になっており、過去の自分の仕事の仕方に当時はあんな仕事の仕方してたのかと恥ずかしくなるはずです。一方でそう感じていないなら仕事の仕方も変わっておらず、過去と今を比べても同じ仕事の仕方をしている危険性があります。前回ITILツールを導入する際はKPI設定に基づいて改善に向けて動く事が重要と述べました。実際にどんな使い方ができるのかについて述べて見たいと思います。実際に取り入れてる指標としては、リードタイムと遵守率です。申請の対応は40時間以内と目標を設定します。この指標を計測可能にする為には、ユーザーからの受付の日時と完了の日時を取る事で計測が可能になります。改善に向けてPDCAを回すかという部分で遵守率を使います。2000件のインシデントが発生した時に、どの程度目標を満たしているか、遵守率として妥当なのは最低80%出来れば90%を目指すべきです。それに対して、遵守率がどの程度だったのか。上記の数字を満たしていないのであれば、サービス提供のプロセス自体が目標を満たせる作りになっていることを疑います。リードタイムを長期化される構造的な問題をインタビューなどにより明確にして、そこから問題に対する対策を立案していきます。遵守率を満たしていた場合は、満たすことのできていないデータを抽出して、原因を分析して該当してあきます。件数が多い場合は、どう行ったシステムなどの分類かでまずカテゴライズしてから、一件一件履歴を確認して原因を探ります。異常値となるデータの傾向から原因を特定して、原因に対する対策案を策定して、誰がいつまでにどうするかを決めて改善施策に落とし込みます。後は、その施策の実行状況に対して、遵守率がどう変化したか確認し、施策の実行ができているにも関わらず、変化がなければ施策自体の有効性を疑います。このようにして改善のPDCAを回して行くと、ツールに登録して実績が改善に使えます。この設計こそがITILツール活用のポイントとなります。次回はKPIではないですが、登録されたデータの使い方について述べてみたいと思います。分析ブログを始めて一年以上たちますが、ITIL系の記事が人気があります。検索で来てもらえるようです。私はコンサルタントになる前にはITILツールのセールスエンジニア、マーケティングを担当してました。ツールの導入やカスタマイズのPMなども実施して来ました。そこでの気づきも含めて今回は私が感じる導入のポイントについてまとめてみたいと思います。その前にこの領域のツール全般に言える問題点として感じてた事からです。行えるある種、対応のワークフローや対応履歴や構成情報などの台帳機能とレポート機能がコアとなる機能のツールです。一言で言うとマネジメントを行うためのツールです。大きな特徴としては、人が入力、操作を行う使うツールなので運用の設計が必要なのですが、それをツールを導入しただけで使いこなすことが難しいということにあります。入力の仕方、フローの組み方がITILに基づいていたとしても、ベンダーが語らない難しいポイントが潜んでいます。それは、成果導出の設計です。ツールに合わせて登録して、フローを回せば業務プロセスを標準的な形で回す事も出来ます。それはツールの本質的な目的ではないです。この領域のツールはITサービスの運営を継続的に改善する為にあります。インシデントを登録しても可視化はできますが改善はしません。評価する為の指標(KPI)と、分析による施策の立案、実行としていくことで改善が進みます。どんなKPIを設定して、そこからどう改善するかなプランニングこそが最も重要なのですが、その部分の方法論が語られずツールの機能に話が言ってしまうことが多い現状に待ったをかけるべきです。次回実際に私が現場で取り組んだ事例を挙げてみたいと思います。最近は子育てに翻弄しつつ日々幸せな日々を送らせてもらっています。日々成長を遂げる我が子が愛おしく、この子の為に親として何ができるだろうと考えたりします。なんでコンサルタントのスキルの話で子育ての話からから始まっているのか。この書籍を読んでる時に気づきがありました。単行本(ソフトカバー)この商品を含むブログを見る本書の中で述べられている部分で日本の教育と欧米の教育の違いについて述べられている部分があります。言ったソフトスキルを伸ばす教育であり、世界の学校教育はソフトスキルの教育に移行しつつあると。この考え方にコンサルタントとして部下を持つ身として非常に共感するところが多かったです。私の専門領域はITサービスマネジメント、いわゆるITILと言ったフレームワークを軸にしたITサービスの運営の領域のコンサルティングとなります。ここで必要となるのはITILというフレームワークの知識はたしかに必要となります。これらは知識として必要なものだと考えますが、ではITILの資格を取り上位資格であるITIL/expertを持っていれば優れたITサービスマネジメント領域のコンサルタント言えるのかといえば答えはノーです。優れたコンサルタントたる人材は、仮に専門知識を有していない領域においても問題解決です。それは前述したソフトスキルが高いからであると考えます。現状を分析して、問題を発見しロジカルに解決策を考える。コミュニケーションを駆使して問題解決を図るというのは、紛れもなく前述したソフトスキルによるものだと考えます。現状をアセスメントして、対策を検討する仕事にしても、一定の型をハードスキルとして教えることはできますが、ある企業でうまく機能した方法論がそのまま他の企業に適用できることはなかなかないと考えます。その企業にあった解決策を設計することができるかどうかなよってコンサルタントとしての能力の真価が問われるのです。今後も子育てからインスピレーションを受けた部分を述べていければと思います。スキルアップ前回に引き続いて部下が成長しない理由について原因と対策を引き続き考えていきます。組織が臨む成果を出すエースは少数派。組織には考え方が異なる人が集まる。成長の仕方には考え方が大きく影響する。現状私も実験的に取り組んでいますが、考え方少しかっこよく言うとマインドセットを変えるには気づきを持ってもらう必要があると思います。多くのケースで今の自分を変えれないのは、今の自分に大きくは課題意識を持てていないか、変えるためのイメージを持てていないと部下とのやりとりの中で見えてきました。年齢が上がるほど前者の傾向があり、若いほど後者の傾向があるようです。どちらも振り返りが出来ていませんでした。なんとなく振り返る事はあっても、自分の認識の中で振り返りをするので、出てくる答えは限定的になります。そこで振り返るためのベースとなる行動指針を設けてみました。我々の目指す仕事とは何か。そこに至るためにどんなポイントに日々気をつけるべきか。それを元にチームで振り返りのセッションを、持つことにしました。それを提示して改めてわかった事は、教育が行き届いていない環境ほど、自分なりの考えに基づいて仕事に臨むので、その自分なりが成長や成果に繋がらない考え方であれば、それは成長のスピードという結果になって現れているようです。気をつけなくてはいけないのは、往々にしてメンバの方々は別に極端にサボっているわけではないので、その状態で頭ごなしに何で出来ないんだといってもモチベーションを奪う結果にしかなりません。上司として取り組むべきは、部下の現状の認識をすくい上げ、別の可能性もあるよと提示し続ける事にあると思います。自分の成功体験を元に行動指針を作っても、それも一つの可能性でしかない事に気をつける必要があります。自分も常に最新の注意をしながら、今後の経過を見守りたいと思います。忘れてはいけないのは、自分が成果を出している側の人間だったとしても、少数派であるならば、少数派で120%の成果を出すより、皆を100%に近づける方が組織としての成果は大きくなります。上司は部下のためにある事を忘れずに今日も一日頑張りたいと思います。スキルアップ仕事の難しさを感じる時多くのケースで人の問題に行き着きます。殆どの組織において、組織の臨む成果を出すエースというのは少数派となり、成果を出すと上に上がるため、課長クラスのミドルマネジメントはエース、部下は次期エースと多数のそうではない人たちという構図が出来上がります。こんな気持ちになった事はないでしょうか。これは私の実体験での話です。エースと呼ばれ圧倒的な成果を出し、人の上に立つ様になって陥った事です。部下に仕事をお願いしたのに進まないことがしばしばありました。なんでこんな当たり前の事が出来ないのか。何もそんなに難しいことお願いしてないのに。できないなら相談してよ。出来ないなりにもがいてよ。こんな気持ちに私はよく陥ってました。部下と話すときは理詰めで話してしまうので、部下は何も言えなくなってしまう。自分の理詰めの内容が合ってようと間違っていようと、部下のモチベーションは上がらず、当たり前だと自分が思う事をその後も部下が実施してくれるという事はありませんでした。年上の部下の場合は理詰めで話をしていると感情的にキレられてしまう事もしばしば。こんな事が続いていたので人間関係も良いものとは言えない状況です。いった状況下は何故発生するのか、どう変革していくのか。私が前提に置くべきだと感じたのは、部下は自分とは違うという事、自分を起点とした論理で人を動かそうとしてもそもそも当てはまりらないという事。論理の落とし穴は暫定を正しく捉えないと正しい答えに近づく事はできません。私はまず考え方やに対する考慮が欠けていだのです。仕事というものの捉え方何のために働くかも人によって異なります。仕事にやりがいを求める度合いも成長に対する必要性に対する認識も違います。そもそも考え方が違う人に対して、自分のロジックで動けという方が難しい事なのでなかったかと今では思うようになりました。エースは組織の少数派という前提のもとにどう考え方の事なる人が集まる組織で、臨む成果を出すのか。久しぶりにアップします。今日は私が最近読んだ本の中で特にオススメしたい書籍を紹介します。