ITIL活用とコンサル的戦略思考ブログ

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

組織の立ち上げに伴う文化形成に気をつけろ②

前回に引き続き文化形成の話です。

 

前回組織を立ち上げる際には多くのルールなどが必要になると話しました。しかしながら、それを守る文化がなければルールも機能しません。

 

組織の成熟度が低い場合、個々の能力や献身で支えられるケースが多く、そういった現場では、現場を回すキープレイヤーが柔軟に動く事で回っている部分があるので、かえってガバナンスがききにくいといった事があります。

 

そういったところでは、トラブルシュートの場面では非常に頼りになる存在だけど、お願いした仕事は基本的に納期が守られないなど、困った時にすごく頼りになるけど、当たり前のことが当たり前に守られないといったいびつな状態が発生したりします。

 

キープレイヤーがそういった状態であると、メンバはそれを規範に動くので組織として統制が取りにくい文化が築かれていってしまいます。

 

現場を回しているという実態がマネジメントの影響力を奪ってしまう事例です。

 

そうならない、そうなってしまったらという意味で私の気づきを記載します。

 

・文化は定着しだすと変えるのは難しいため、最初が肝心。
・文化は上位者(現場リーダクラスのキープレイヤー)の仕事の仕方、指示が形成に大きな影響を与えている
・上位者の行動指針となる文化を創り出す前提にヴィジョン(目指す姿)がある。
・共通のヴィジョンがなければ、個々の行動が波及したものが文化として固定されていく
・おそらくは多くのケースで最低限は実施するが、顧客の期待値を超えるまで勝手に上がることはない。文化形成のキーマンはビジネス目的より現場を回すことを優先する
・文化は現場の行動によって体現される。現場で体現された行動自体を注意しても効果は一時的
・声に出し続けていくことで、文化は矯正、変革可能。意識させ続けることが重要

 

文化形成において最も重要なのは、私なりの答えはビジョンです。

 

キープレイヤーが今の働き方で良いと思うかどうかは、組織としてどこを目指すかに帰結すると思います。

 

マネジメントとして取り組むべきは、そういったキープレイヤーを共感させるビジョンを提示できるかで、そのビジョンこそが組織を形作る文化を創り出すものであると思います。

 

もし現場を統制できていないと感じるマネジメントの方がいたら、今一度自分が共感できるビジョンを提示できているか。そのビジョンが正しく伝わっているかなどを振り返ってみてください。

 

今日はこのへんで。

組織の立ち上げに伴う文化形成に気をつけろ①

組織の立ち上げを行うととにかくルールが決まっていない事が多く、コンサルはルール決めに奔走されます。

 

人によって何をエスカレーションして、何を自己解決で踏ん張るかの基準が異なったり、台帳に記録すべきデータの入力制度なんかも異なります。

 

特に今までバックグラウンドが違う人が集まって新しい組織を作ると(新しい組織なのでバックグラウンドが違う人が集まる事の方が圧倒的に多い)同じ業務をしても結果は変わって来ます。

 

自分が当たり前だと思う事がそうではないのです。

 

例えば運用に携わる人であれば、作業手順にない作業は行わないというのは、経験がある人であればそりゃそうだとなります。

 

しかし、良かれと思って前の人が消し忘れたゴミデータを消そうとして大事なデータを消してしまったら、責任を問われてしまいます。

 

なぜなぜ分析で掘り下げていくと、プロセスやルールの話ももちろん出ますが、人の意識の領域まで踏み込んできます。

 

何に基づいて意志決定をしたのか。もちろんルールなどは必要ですが、気をつけなければいけないのは仮にルールがあってもそれを守るという文化がなければルールは機能しません。

 

では文化とはどの様に作られていくのか。

 

次回は文化形成のポイントについて述べてみたいと思います。

書籍の執筆

久しぶりの更新。

 

企業として書籍を作ろうと思うとす 凄くお金かかるのですね。

 

そしてPRの仕方の多様性にも驚き。

 

平積みコーナーに置くのもただではないと汗

 

本はかなり読むけども、手に取るまでのシナリオがマーケティングのカスタマージャーニーによって事前に想定されたものとは思いたくないなぁなんて。

 

ジャケ買いではないですが、インスピレーションで買うので、当たらないことを多いですが笑

ITIL活用〜導入の意義とポイント〜

ITIL導入したいという事で声をかけていただき、仕事をする事が多いですが、結構誤解が多いので今日は意義とポイントについて事例を交えて述べてみます。

 

まずITILを導入する意義はどんなところにあるでしょうか。

 

押さえておくべきはシステム運用からITサービスマネジメントへの変革が挙げられます。

 

システムを安定稼働させるという品質の観点から、ビジネスが求めるサービスレベルを実現するというサービスレベルの観点に変わります。

 

そこには必ず誰が顧客で、顧客が求める事は何かという視点が加わります。

 

IT部門で社内においては売上を上げる機能ではなくコストセンターとして貢献度を問われる様な場合、顧客の期待と業務を整合させる効能があります。

 

例えば、多少使い勝手が悪くてもコストが少ない方が良いとか、ビジネスのスピードに追従して、迅速なシステム利用を促すなど。

 

期待値をサービスレベルとして定量評価が可能になります。

 

では、導入に際してのポイントとは何か。

 

前述した想いをマネジメントが持ち、部下にITILを導入せよと指示を出すときにその目的が正しく伝わらない事がよくあります。

 

すると目的も理解がされないまま、何となく書籍を読んでITILのプロセスを見様見真似で実務に適用し、プロセスを書き換える事を主眼においた活動となってしまいます。

 

教科書になぞる事は目的ではないです。そもそも顧客のニーズは何なのか。それを押さえない限り成果には繋がりません。ITILベースの運用にしたという事実しか残らないのです。

 

明確なこうしたいという目的、我々は成果と表現しますが、成果を定義する事から始める必要があります。

 

次回は実際に事例を述べてみたいと思います。

 

 

ITIL活用〜プロセス適用の順序と最低限実装すべきプロセス〜

久しぶりにITILの話です。

 

今まで、ITILプロセスを導入してしていない企業がITIL導入したいから支援してほしいという相談があります。

 

今日はオススメの順番とITILに基づいてITサービスマネジメントに取り組むのであれば個人的に最低限取り組むべきプロセスをあげます。

 

①要求実現

②インシデント管理

③イベント管理

④問題管理

⑤構成管理

⑥変更管理

⑦リリース及び展開管理

⑧サービスカタログ管理

⑨サービスレベル管理

⑩情報セキュリティ管理

 

適用の順序と最低限は上記だと考えます。

 

適用の段階としては、

 

①②

⑤⑥⑦

⑧⑨

 

この塊で実施するのが良いと思います。

 

次回はどの位の期間を見込めばいいかについてお話ししたいと思います。

官公庁案件における調達仕様書の解釈のせめぎ合い

官公庁の案件では調達仕様書という民間でいうRFPがバイブルとなって、その解釈によって利害の不一致が発生します。

 

曖昧さの残る表現となるので、官公庁としてはなるべく多くの要求を通したいですし、実施業者としては、範囲をコントロールしなくては、キャッシュアウトしてしまいます。

 

民間と比べてより、文書遊びととも取れる論理の攻防が繰り広げられます。

 

論理の攻防においては、己の主張を押し通す一貫性が重要となります。言い切れるかどうかとも言えます。

 

論理のほつれがあれば、そこにつけ込まれて交渉は苦しくなります。

 

プロジェクトが大きくなればなるほど、現場とマネジメント側でガバナンスを確保する事が難しくなり、現場で起きている事を抑える事が難しくなります。

 

そう言った中で、現場で起きている情報を精度高く抑えて、自社の論理展開に一貫性を持たせるか。

 

官公庁案件では非常に重要になるので、これから取り組んでいきたいと思われる方は気をつけてみてください。

 

 

コンサルタントの力量、コンサルタントの育て方

久しぶりの投稿。大規模プロジェクトの参謀として睡眠時間を確保するのが大変な日々を送っています。

 

大きいプロジェクトだとどうしてもチームで仕事する必要があり、どうしてもチームの中には能力が高くないメンバーがいます。

 

コンサルタントの力量とはどう決まるのか。

 

どれだけの問題解決をしてきたかの量に尽きると考えます。

 

言い換えるならどれだけ問題を自分ごととして解決にもがいてきたか。

 

問題解決は逃げよう思えば簡単に逃げる事が出来ます。

 

自分の仕事ではない。これは上司の仕事だ。言い出せばきりがないです。これを自分事として向き合ってもがいた量が、大きな差になっているのかなと。

 

そういった問題解決を自分で経験しないと育たないと思ってしまうので、優しく一から十まで教えるということはせず、問題解決を部下自身にやってもらうアプローチを人材育成の取り組みをしています。

 

結果としては、潰れる人4に対して成果をあげる人6といった印象です。内訳をさらにいうと、言わなくてもどのみち成長した人と、言い続けて何年かして目が出た人もいます。

 

結局言っても本人に腹落ちするまでに個人差はあると思います。

 

ただ例外なくできる様になった人はエース級の存在になってます。

 

そして部下に問題解決を丸ごとやってもらうとともに、説いているのは、結局それを乗り越えていかないと、コンサルをする上では損するよ説いて話しています。

 

今の自分でいることは、自分の過去の選択の結果となのだよと。

 

 

小さなチーム、大きな仕事 働き方の新スタンダードを読んで

本業とは別に、社内の研究会で自社の新規事業開発を推進するにはどうしたら良いかとかねてより研究しています。

 

そこで最初は新規事業開発の制度を構築してみようとトライしてみました。制度によりアイデアを募り、公式な検討の機会を提供する事で、今より新規事業を考える数が多くなったら、考える文化を養おうといった感じです。

 

結論からいうと自社の規模や文化からだとそれは適さないという結論に至りました。

 

ビジネスを自分でやりたいと強い意志や行動力は、制度では作れない。新規事業開発の主要な成功要因は人に依存する領域が多く良さそうな事業計画を作ることではないというのが、我々の自社のケースでは結論です。

 

そこから一旦研究が煮詰まったので人のすすめもありこの本を読んでみました。

 

小さなチーム、大きな仕事――働き方の新スタンダード (ハヤカワ・ノンフィクション文庫)

小さなチーム、大きな仕事――働き方の新スタンダード (ハヤカワ・ノンフィクション文庫)

  • 作者: ジェイソンフリード,デイヴィッドハイネマイヤーハンソン,黒沢健二,松永肇一,美谷広海,祐佳ヤング
  • 出版社/メーカー: 早川書房
  • 発売日: 2016/12/08
  • メディア: 文庫
  • この商品を含むブログを見る
 

Ruby on Railsを作ったベースキャンプ(旧社名37シグナルズ)のジェフリーフリードをはじめとするメンバで書かれています。 新規事業や働き方に関するテーマで元はブログだったのか短いトピックスで読みやすい書籍です。

 

硬直化した官僚型の組織を変革していきたいという時に皆で読むといいかもしれません。

 

あまり内容は触れませんが、本質的でない事をいかに削ぎ落とせるか。という点は自分達の制度作りのアプローチの大きな問題点に刺さるものでした。

 

そもそも新規事業開発の制度自体が本質的でない部分をはらんでいたのです。

 

公式化された事業開発のプロセスは公式化された故に、どうしても承認にロジックが必要となります。机上で設計されたもの承認するには承認する側も判断材料を求めるので、説明が増えます。

 

それ自体が事業開発のハードルを上げてしまうのです。

 

しかしながら、非公式で事業開発をするというのは、それができるポジションでなければできません。例えば新しいサービスの反応を本業のかたわら訪問時に聞いてみるといったことも、内勤のひとはできません。

 

また、会社が関知せず事業開発計画が誰かに作成されるのを待つというのは何もしないと同じです。

 

ではどうすれば本質的な活動だけに絞り込むことができるのか。

 

次回に続きます。

 

 

顧客思考は自分事から。その先のコンサル視点

前回問題解決には顧客思考と論理的思考が重要だというお話をしました。

 

顧客の思考を考えるにはどうしたら良いか。

 

顧客だったらどう考えるか。顧客の立場によっても推測が可能です。管理者ほど企業自体の目標に資することを求められます。一方で現場ほど企業の目標ではなく、現場の業務をどう回していくかということに目線が行きます。

 

クライアントの立場は様々ですがベースは自分の立場ならどう考えるかだと思います。自分が顧客企業の部門長ならどう動くか。担当者なら何を思うか。自分事に置き換えることが重要だと思います。自分にフォーカスする必要があります。

 

一方で気をつけなくてはいけないのは、相手の立場を理解しつつ、相手の立場に縛られない事です。例えば現場の気持ち考えすぎて動けなくなるということもあります。

 

コンサルに求められる機能ということを念頭に置いた上で、あくまでも外部の立ち位置である事が重要です。

 

自分の問題として捉えられるか、一方で客観的な立場で捉えられるか。バランス能力が求められる気がします。

 

ちなみに私はまだ30代前半なので、キャリア的に部門長クラスのマネジメント視点は不足しがちです。そこを補う上でも、書籍などからマネジメントの方の視点を得ようと試みており、それは成果として繋がっている気がします。

 

日々勉強ですね。これホント大事。

問題解決能力を科学する

コンサルにおいて最も重要な能力は問題解決能力であると以前話をしましたが、どの様に向上させるのかについて考えていきたいと思います。

 

コンサルティングを行う際、全く同じ経験を使いまわせるケースというのはそんなに多くないです。

 

お客様から事例を求められても、その事例が必ずしもそのお客様にFitするものではなく、お客様に合った解決策を導き出して行かなくてはいけません。

 

もちろん仮説や持っていくべき方向性も見出すことができない様なケースは提案は慎重になります。提案段階ですり合わせをして合意をもらえた際には、その合意に基づいて進めます。

 

問題解決能力とは、答えのないところから答えを導く能力とも言えると思います。その一つとしては、概念を資料化して認識を合わせ合意形成を図る事があると思います。

 

物事を進めるのが上手い人とそうではない人の違いとして、考えを資料化できるかどうかというのが挙がります。特に成果イメージや進め方などは徹底的に資料化する事に慣れるべきです。これはそのまま提案力向上にも繋がります。

 

次に、分からない事を調べる調査能力も一つだと思います。人に聞く、ウェブ、書籍など情報を取ろうとするときに、どういった調べ方をすれば知りたい情報が導き出せるか。そこに対して、シナリオを組める必要があります。

 

順番が前後しましたが、調査能力によって得た情報から仮説を立てていきますが、仮説立案において重要となるのが論理的な思考能力と顧客思考です。

 

あえて顧客思考と書いたのは、顧客の立場ならこう考えるであろうという観点です。それが論理形成の前提となります。論理は前提を捉え間違うと意味がありません。なるべく精度高く顧客思考するために必要なのが、経験となります。こんなケースのお客様ではこんな悩みがあるといった感じです。それを正確に捉えれば論理が成り立っていれば説明が筋が通るため合意が得やすくなります。

 

こういった事の繰り返しが問題解決なんだと思う様になってきました。

 

顧客思考と論理的思考についてはもう少し深掘りして次回お話していきたいと思います。

コンサルタントの仕事術〜成果を示すデータ作り〜

コンサルタントの成果は時として非常に定性的で、最終成果を報告する際の特に上級マネジメントへの説明をする際に数値で成果を示さないと成果に納得してもらえないという事態が発生します。

 

例えばルールを作る仕事。

 

標準化されました。属人化が解消する仕組みができましただけでは納得感はないです。

 

そのためコンサルタントとしては、必ず成果を示すデータを作り込む必要があります。

 

これはコンサルタントだけでなく、自社で改善をする時も同様だと思います。

 

分かりやすい例は、顧客満足度向上。

 

顧客満足度向上の施策だけを設計しても、成果が施策を考えましたでは、通用しません。

 

施策を設計する前に、現状の顧客満足度を調査して、基準点が分かって初めて施策を実行した後の成果が説明できます。

 

いかにデータを作り込むことこそが、案件を上手くクロージングできるかどうかに関わってくるのです。

 

提案の際は顧客担当者は施策を打つ事にしか興味がなかったとしても、コンサルとしてデータ作り込む段階を設けるようにしましょう。

 

データの作り込みの例は次の機会でお話しできればと思います。