真摯に向き合う事が出来なければPDCAは回らない
前回前向きな議論によりPDCAが回らないと話しました。
誤解を招く表現ではありますが、前向きである事が悪いのではなく、前向き＝本質に目を背けるを表しています。
PDCAに取り組むマネジメントレベルの方はそれなりに自分の考えを持っている事が多いため、そこから抜け出せず論理をどうしても自分の都合の良い前提や解釈の上で進めてしまう傾向があります。
自分が間違っていないと考え出すと、誤りを周りに求めてしまうため、他責思考に陥り抜け出せないといった状況もあるのではないでしょうか。
私が大事だと考えるのは、今まで自分の強みだと考えてきたものが、必ずしも今の立場でも成果につながるものではないという事です。
プレイヤーとして優秀な人材がマネジメントとして優秀とはなれず、伸び悩むというところはこの辺にあるのではないでしょうか。技術的な部分は学ぶ事が出来ますが、そもそもそれを学ぶ必要性を自身が感じるかどうかで、少しずつでも成長するか、いつまでも同じ場所に留まり続けてしまうかの分かれ道のような気がします。
では真摯に向き合うとは具体的に何をするのか次回あげていきたいと思います。
PDCAが回らないのは、前向きな議論のせいかも？
コンサルとして組織に入り、その組織の強さを見るポイントとしては、私はPDCAが回っているかを見る様にしています。
今できない事よりも、この先もできる様にならない事の方が将来的なリスクは大きいと考えるからです。
では私なりに感じるPDCAがうまく回らない組織のポイントを挙げてみたいと思います。
・前向きな議論という大義で振り返りが機能しない
会社の中にはネガテイブな事ばかり言う人もいたりしますが、だいたいそう言った人は評価されず、前向きな意見を出す人材を重宝されます。
それ自体は問題ないと思いますが、前向きな議論とは、一歩間違えるとPDCAのCheck,Actionが機能せず、本質的、構造的に対処すべき課題が棚上げされ、聞こえのいい新しいPlanに走ってしまう危険性もあります。
臭いものに蓋をしててはPDCAは回りません。自らを冷静に分析し、それを乗り越えるからこそ組織は着実な成長を遂げます。日本マイクロソフトの元会長の樋口さん（本日時点ではパナソニック）が自省力と表現していたのにとても共感しました。
「美しい戦略」とはどのようなものか｜出世ナビ｜NIKKEI STYLE
スピードを意識するあまり、この様な基本的な事が出来ず、結果としていつまでも同じ様な課題に悩まされてしまいます。
ではもし自社もそういったところがあると思われる方は何をすべきか。
私はコンサルで入る場合、様々な形でベースラインアセスメントをします。今どこにいるのかを解決していきたい方向性に向かうために必要な観点の現在の能力を明らかにしていきます。
インタビュー調査
アセスメントモデルによる調査票でのアンケート
サービスカタログ作成や工数管理の導入等
あなた達の取り組み方では、成果は出てないし、取り組み方自体が間違っているよとデータを突きつけていきます。
最も強いのはfactであり、それは誰にも否定する事は出来ません。もし自分の所属する組織でPDCAが回っていないと感じるところがあるならば、factデータを集めて回っていないことをまず示しましょう。
急がば回れではないですが、少し意識されてみてはいかがでしょうか。
ITIL活用〜まずはサービスカタログを作るべし〜
最近コンサルに入ると最初にサービスカタログを作る事が多いです。
ここでいうサービスカタログとは、顧客に対する提供サービスを一覧化したものではなく、自分たちの業務一覧を指しています。
技術サービスカタログと言っていいかもしれません。
なぜサービスカタログを作るのか。例えば効率化したいと言った時、大事なのは効率化の成果をどう測るかという点となります。その成果の測定方法を作らずに進めると、改善の成果を語る事が難しくなり、結果として改善主体となる自分たちの改善に向けたモチベーションを維持する事は難しくなります。
改善した結果が数字に現れると張り合いが出ますし、活動の妥当性を証明できます。
そこでまずはサービスカタログを作成して、それに基づいて工数を取れるフォーマットを用意します。会社によってはOBPMなんかを使っているケースもあると思います。
アウトソーシングで運用を請負う会社でこれが無ければ、まず契約の見直しは難しいでしょう。
じゃあどうやって作っていくのが良いのか。
かなりここはノウハウが必要なので、細かい話になってくるので、また別の機会に話ができればと思います。
組織の立ち上げに伴う文化形成に気をつけろ②
前回に引き続き文化形成の話です。
前回組織を立ち上げる際には多くのルールなどが必要になると話しました。しかしながら、それを守る文化がなければルールも機能しません。
組織の成熟度が低い場合、個々の能力や献身で支えられるケースが多く、そういった現場では、現場を回すキープレイヤーが柔軟に動く事で回っている部分があるので、かえってガバナンスがききにくいといった事があります。
そういったところでは、トラブルシュートの場面では非常に頼りになる存在だけど、お願いした仕事は基本的に納期が守られないなど、困った時にすごく頼りになるけど、当たり前のことが当たり前に守られないといったいびつな状態が発生したりします。
キープレイヤーがそういった状態であると、メンバはそれを規範に動くので組織として統制が取りにくい文化が築かれていってしまいます。
現場を回しているという実態がマネジメントの影響力を奪ってしまう事例です。
そうならない、そうなってしまったらという意味で私の気づきを記載します。
・文化は定着しだすと変えるのは難しいため、最初が肝心。
・文化は上位者(現場リーダクラスのキープレイヤー)の仕事の仕方、指示が形成に大きな影響を与えている
・上位者の行動指針となる文化を創り出す前提にヴィジョン(目指す姿)がある。
・共通のヴィジョンがなければ、個々の行動が波及したものが文化として固定されていく
・おそらくは多くのケースで最低限は実施するが、顧客の期待値を超えるまで勝手に上がることはない。文化形成のキーマンはビジネス目的より現場を回すことを優先する
・文化は現場の行動によって体現される。現場で体現された行動自体を注意しても効果は一時的
・声に出し続けていくことで、文化は矯正、変革可能。意識させ続けることが重要
文化形成において最も重要なのは、私なりの答えはビジョンです。
キープレイヤーが今の働き方で良いと思うかどうかは、組織としてどこを目指すかに帰結すると思います。
マネジメントとして取り組むべきは、そういったキープレイヤーを共感させるビジョンを提示できるかで、そのビジョンこそが組織を形作る文化を創り出すものであると思います。
もし現場を統制できていないと感じるマネジメントの方がいたら、今一度自分が共感できるビジョンを提示できているか。そのビジョンが正しく伝わっているかなどを振り返ってみてください。
今日はこのへんで。
組織の立ち上げに伴う文化形成に気をつけろ①
組織の立ち上げを行うととにかくルールが決まっていない事が多く、コンサルはルール決めに奔走されます。
人によって何をエスカレーションして、何を自己解決で踏ん張るかの基準が異なったり、台帳に記録すべきデータの入力制度なんかも異なります。
特に今までバックグラウンドが違う人が集まって新しい組織を作ると（新しい組織なのでバックグラウンドが違う人が集まる事の方が圧倒的に多い）同じ業務をしても結果は変わって来ます。
自分が当たり前だと思う事がそうではないのです。
例えば運用に携わる人であれば、作業手順にない作業は行わないというのは、経験がある人であればそりゃそうだとなります。
しかし、良かれと思って前の人が消し忘れたゴミデータを消そうとして大事なデータを消してしまったら、責任を問われてしまいます。
なぜなぜ分析で掘り下げていくと、プロセスやルールの話ももちろん出ますが、人の意識の領域まで踏み込んできます。
何に基づいて意志決定をしたのか。もちろんルールなどは必要ですが、気をつけなければいけないのは仮にルールがあってもそれを守るという文化がなければルールは機能しません。
では文化とはどの様に作られていくのか。
次回は文化形成のポイントについて述べてみたいと思います。
ITIL活用〜導入の意義とポイント〜
ITIL導入したいという事で声をかけていただき、仕事をする事が多いですが、結構誤解が多いので今日は意義とポイントについて事例を交えて述べてみます。
まずITILを導入する意義はどんなところにあるでしょうか。
押さえておくべきはシステム運用からITサービスマネジメントへの変革が挙げられます。
システムを安定稼働させるという品質の観点から、ビジネスが求めるサービスレベルを実現するというサービスレベルの観点に変わります。
そこには必ず誰が顧客で、顧客が求める事は何かという視点が加わります。
IT部門で社内においては売上を上げる機能ではなくコストセンターとして貢献度を問われる様な場合、顧客の期待と業務を整合させる効能があります。
例えば、多少使い勝手が悪くてもコストが少ない方が良いとか、ビジネスのスピードに追従して、迅速なシステム利用を促すなど。
期待値をサービスレベルとして定量評価が可能になります。
では、導入に際してのポイントとは何か。
前述した想いをマネジメントが持ち、部下にITILを導入せよと指示を出すときにその目的が正しく伝わらない事がよくあります。
すると目的も理解がされないまま、何となく書籍を読んでITILのプロセスを見様見真似で実務に適用し、プロセスを書き換える事を主眼においた活動となってしまいます。
教科書になぞる事は目的ではないです。そもそも顧客のニーズは何なのか。それを押さえない限り成果には繋がりません。ITILベースの運用にしたという事実しか残らないのです。
明確なこうしたいという目的、我々は成果と表現しますが、成果を定義する事から始める必要があります。
次回は実際に事例を述べてみたいと思います。
ITIL活用〜プロセス適用の順序と最低限実装すべきプロセス〜
久しぶりにITILの話です。
今まで、ITILプロセスを導入してしていない企業がITIL導入したいから支援してほしいという相談があります。
今日はオススメの順番とITILに基づいてITサービスマネジメントに取り組むのであれば個人的に最低限取り組むべきプロセスをあげます。
①要求実現
②インシデント管理
③イベント管理
④問題管理
⑤構成管理
⑥変更管理
⑦リリース及び展開管理
⑧サービスカタログ管理
⑨サービスレベル管理
⑩情報セキュリティ管理
適用の順序と最低限は上記だと考えます。
適用の段階としては、
①②
③
④
⑤⑥⑦
⑧⑨
⑩
この塊で実施するのが良いと思います。
次回はどの位の期間を見込めばいいかについてお話ししたいと思います。
官公庁案件における調達仕様書の解釈のせめぎ合い
官公庁の案件では調達仕様書という民間でいうRFPがバイブルとなって、その解釈によって利害の不一致が発生します。
曖昧さの残る表現となるので、官公庁としてはなるべく多くの要求を通したいですし、実施業者としては、範囲をコントロールしなくては、キャッシュアウトしてしまいます。
民間と比べてより、文書遊びととも取れる論理の攻防が繰り広げられます。
論理の攻防においては、己の主張を押し通す一貫性が重要となります。言い切れるかどうかとも言えます。
論理のほつれがあれば、そこにつけ込まれて交渉は苦しくなります。
プロジェクトが大きくなればなるほど、現場とマネジメント側でガバナンスを確保する事が難しくなり、現場で起きている事を抑える事が難しくなります。
そう言った中で、現場で起きている情報を精度高く抑えて、自社の論理展開に一貫性を持たせるか。
官公庁案件では非常に重要になるので、これから取り組んでいきたいと思われる方は気をつけてみてください。
コンサルタントの力量、コンサルタントの育て方
久しぶりの投稿。大規模プロジェクトの参謀として睡眠時間を確保するのが大変な日々を送っています。
大きいプロジェクトだとどうしてもチームで仕事する必要があり、どうしてもチームの中には能力が高くないメンバーがいます。
コンサルタントの力量とはどう決まるのか。
どれだけの問題解決をしてきたかの量に尽きると考えます。
言い換えるならどれだけ問題を自分ごととして解決にもがいてきたか。
問題解決は逃げよう思えば簡単に逃げる事が出来ます。
自分の仕事ではない。これは上司の仕事だ。言い出せばきりがないです。これを自分事として向き合ってもがいた量が、大きな差になっているのかなと。
そういった問題解決を自分で経験しないと育たないと思ってしまうので、優しく一から十まで教えるということはせず、問題解決を部下自身にやってもらうアプローチを人材育成の取り組みをしています。
結果としては、潰れる人4に対して成果をあげる人6といった印象です。内訳をさらにいうと、言わなくてもどのみち成長した人と、言い続けて何年かして目が出た人もいます。
結局言っても本人に腹落ちするまでに個人差はあると思います。
ただ例外なくできる様になった人はエース級の存在になってます。
そして部下に問題解決を丸ごとやってもらうとともに、説いているのは、結局それを乗り越えていかないと、コンサルをする上では損するよ説いて話しています。
今の自分でいることは、自分の過去の選択の結果となのだよと。
小さなチーム、大きな仕事 働き方の新スタンダードを読んで
本業とは別に、社内の研究会で自社の新規事業開発を推進するにはどうしたら良いかとかねてより研究しています。
そこで最初は新規事業開発の制度を構築してみようとトライしてみました。制度によりアイデアを募り、公式な検討の機会を提供する事で、今より新規事業を考える数が多くなったら、考える文化を養おうといった感じです。
結論からいうと自社の規模や文化からだとそれは適さないという結論に至りました。
ビジネスを自分でやりたいと強い意志や行動力は、制度では作れない。新規事業開発の主要な成功要因は人に依存する領域が多く良さそうな事業計画を作ることではないというのが、我々の自社のケースでは結論です。
そこから一旦研究が煮詰まったので人のすすめもありこの本を読んでみました。
小さなチーム、大きな仕事――働き方の新スタンダード (ハヤカワ・ノンフィクション文庫)
- 作者: ジェイソンフリード,デイヴィッドハイネマイヤーハンソン,黒沢健二,松永肇一,美谷広海,祐佳ヤング
- 出版社/メーカー: 早川書房
- 発売日: 2016/12/08
- メディア: 文庫
- この商品を含むブログを見る
Ruby on Railsを作ったベースキャンプ（旧社名37シグナルズ）のジェフリーフリードをはじめとするメンバで書かれています。 新規事業や働き方に関するテーマで元はブログだったのか短いトピックスで読みやすい書籍です。
硬直化した官僚型の組織を変革していきたいという時に皆で読むといいかもしれません。
あまり内容は触れませんが、本質的でない事をいかに削ぎ落とせるか。という点は自分達の制度作りのアプローチの大きな問題点に刺さるものでした。
そもそも新規事業開発の制度自体が本質的でない部分をはらんでいたのです。
公式化された事業開発のプロセスは公式化された故に、どうしても承認にロジックが必要となります。机上で設計されたもの承認するには承認する側も判断材料を求めるので、説明が増えます。
それ自体が事業開発のハードルを上げてしまうのです。
しかしながら、非公式で事業開発をするというのは、それができるポジションでなければできません。例えば新しいサービスの反応を本業のかたわら訪問時に聞いてみるといったことも、内勤のひとはできません。
また、会社が関知せず事業開発計画が誰かに作成されるのを待つというのは何もしないと同じです。
ではどうすれば本質的な活動だけに絞り込むことができるのか。
次回に続きます。
