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

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

創造性を保つ秘訣

前回ルーチンは創造性を破壊すると話しましたが、自分なりに創造性を保って行くための取り組みを紹介します。

 

創造性とは新しく何かを生み出す事だとした場合、創造性を発揮するという事には相応のパワーが必要だと考えられます。新しい事を始めるにはストレスもかかるので、忙殺されるほどのルーチンがあればそれを考える余裕がないというのも繋がります。

 

自分が意識するのは2点です。

 

①落ち着いて思考できる時間と空間を作ること

②情報のインプットを増やす事

 

①について自分は1日のどこかでカフェなどで、思考をする時間を作るようにしています。これはカフェ行かなくてもいいと思いますが、自分なりに落ち着いて考える時間こそが、そもそも自分がどこに向かいたいのか、そこに向かうにはどうしたらいいかを考える事が出来ます。

 

活躍している人こそ、仕事は集まりますし、この様な考える時間を確保する事は難しくなります。なので意図的に作ることが重要です。

 

次に②については、どこに向かいたいのかを考える上では、外部からの情報を取り入れて様々なモデルケースと触れる事で目指していきたい方向性を探る事になります。

 

世の中には見た事もない素晴らしい景色があったとしても、それを知らなければ見てみたい、みに行こうとはなりません。その場所に行き、景色に感動している自分を想像する事が出来てこそ、そこに行きたいとなります。

 

また、そこにどの様に行くのかについても知識が必要になります。職場に置いてよく起こるのが、何か問題を解決しようとするときに答えが見つからない場合、自分の能力を疑う前に置かれている環境に疑いを持ち、他責な考え方に陥り、思考が停止する事があります。

 

今の自分が解決に向けた手段を見出せない事=解決できない問題ではないです。もちろん解決できない事もあるとは思いますか、これ以上なら手段がないと言い切れるほどに答えを探すことに取り組めているケースの方が稀だと思います。

 

情報のインプットを増やす事は可能性や選択肢を増やす事なので、調べれば調べるほど手段がたくさんある事に気付かされます。

 

①やるのには②について重要なのは、それを意識して行う事です。私自身も気がつかない間にできなくなってる事がよくあります。

 

決してサボっている感覚がなくても創造性を保つ活動ができなくなったり、気がつかない間に創造性は失われて行きます。働き方や生活の中にいかに自分なりの創造性の保ち方を築き上げる事が出来るかが、成長のさせかたに大きな差をつける事だと思います。

 

 

ルーチンは創造性を破壊する

現場のリーダーが日々の仕事が忙しいと、本来やって欲しいことをやってくれないという事はないだろうか。

 

これをハーバードサイモンは計画のグレジャムの法則として提唱しています。

【01Blog】計画のグレシャムの法則を考える「ルーチンは創造性を駆逐する」 | 01booster.com【起業家の事業支援プラットフォーム】

 

変化したくないわけではないけど、優先度が上がらない。結局同じことを繰り返すので、能力は上がらない。リーダーが同じ事するので組織は硬直化し、メンバはいつまでもリーダーに頼りきり。

 

これを断ち切るには目的と目標です。

 

目標のために行動するならば、動きは変わります。

 

自分の中に目標感はあるのか、部下に対して目標を意識させる事が出来ているか。

 

振り返るとやらなくてはいけない事が多い事に気づきます。

真摯に向き合う事が出来なければPDCAは回らない

前回前向きな議論によりPDCAが回らないと話しました。

 

誤解を招く表現ではありますが、前向きである事が悪いのではなく、前向き=本質に目を背けるを表しています。

 

PDCAに取り組むマネジメントレベルの方はそれなりに自分の考えを持っている事が多いため、そこから抜け出せず論理をどうしても自分の都合の良い前提や解釈の上で進めてしまう傾向があります。

 

自分が間違っていないと考え出すと、誤りを周りに求めてしまうため、他責思考に陥り抜け出せないといった状況もあるのではないでしょうか。

 

私が大事だと考えるのは、今まで自分の強みだと考えてきたものが、必ずしも今の立場でも成果につながるものではないという事です。

 

プレイヤーとして優秀な人材がマネジメントとして優秀とはなれず、伸び悩むというところはこの辺にあるのではないでしょうか。技術的な部分は学ぶ事が出来ますが、そもそもそれを学ぶ必要性を自身が感じるかどうかで、少しずつでも成長するか、いつまでも同じ場所に留まり続けてしまうかの分かれ道のような気がします。

 

では真摯に向き合うとは具体的に何をするのか次回あげていきたいと思います。

PDCAが回らないのは、前向きな議論のせいかも?

コンサルとして組織に入り、その組織の強さを見るポイントとしては、私はPDCAが回っているかを見る様にしています。

 

今できない事よりも、この先もできる様にならない事の方が将来的なリスクは大きいと考えるからです。

 

では私なりに感じるPDCAがうまく回らない組織のポイントを挙げてみたいと思います。

 

・前向きな議論という大義で振り返りが機能しない

 

会社の中にはネガテイブな事ばかり言う人もいたりしますが、だいたいそう言った人は評価されず、前向きな意見を出す人材を重宝されます。

 

それ自体は問題ないと思いますが、前向きな議論とは、一歩間違えるとPDCAのCheck,Actionが機能せず、本質的、構造的に対処すべき課題が棚上げされ、聞こえのいい新しいPlanに走ってしまう危険性もあります。

 

臭いものに蓋をしててはPDCAは回りません。自らを冷静に分析し、それを乗り越えるからこそ組織は着実な成長を遂げます。日本マイクロソフトの元会長の樋口さん(本日時点ではパナソニック)が自省力と表現していたのにとても共感しました。

「美しい戦略」とはどのようなものか|出世ナビ|NIKKEI STYLE

 

スピードを意識するあまり、この様な基本的な事が出来ず、結果としていつまでも同じ様な課題に悩まされてしまいます。

 

ではもし自社もそういったところがあると思われる方は何をすべきか。

 

私はコンサルで入る場合、様々な形でベースラインアセスメントをします。今どこにいるのかを解決していきたい方向性に向かうために必要な観点の現在の能力を明らかにしていきます。

 

インタビュー調査

アセスメントモデルによる調査票でのアンケート

サービスカタログ作成や工数管理の導入等

 

あなた達の取り組み方では、成果は出てないし、取り組み方自体が間違っているよとデータを突きつけていきます。

 

最も強いのはfactであり、それは誰にも否定する事は出来ません。もし自分の所属する組織でPDCAが回っていないと感じるところがあるならば、factデータを集めて回っていないことをまず示しましょう。

 

急がば回れではないですが、少し意識されてみてはいかがでしょうか。

 

 

ITIL活用〜まずはサービスカタログを作るべし〜

最近コンサルに入ると最初にサービスカタログを作る事が多いです。

 

ここでいうサービスカタログとは、顧客に対する提供サービスを一覧化したものではなく、自分たちの業務一覧を指しています。

 

技術サービスカタログと言っていいかもしれません。

 

なぜサービスカタログを作るのか。例えば効率化したいと言った時、大事なのは効率化の成果をどう測るかという点となります。その成果の測定方法を作らずに進めると、改善の成果を語る事が難しくなり、結果として改善主体となる自分たちの改善に向けたモチベーションを維持する事は難しくなります。

 

改善した結果が数字に現れると張り合いが出ますし、活動の妥当性を証明できます。

 

そこでまずはサービスカタログを作成して、それに基づいて工数を取れるフォーマットを用意します。会社によってはOBPMなんかを使っているケースもあると思います。

 

アウトソーシングで運用を請負う会社でこれが無ければ、まず契約の見直しは難しいでしょう。

 

じゃあどうやって作っていくのが良いのか。

かなりここはノウハウが必要なので、細かい話になってくるので、また別の機会に話ができればと思います。

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

今日はこのへんで。

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

書籍の執筆

久しぶりの更新。

 

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

 

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

 

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

 

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

 

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

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

 

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

久しぶりにITILの話です。

 

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

 

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

 

①要求実現

②インシデント管理

③イベント管理

④問題管理

⑤構成管理

⑥変更管理

⑦リリース及び展開管理

⑧サービスカタログ管理

⑨サービスレベル管理

⑩情報セキュリティ管理

 

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

 

適用の段階としては、

 

①②

⑤⑥⑦

⑧⑨

 

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

 

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

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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