コンサルタントの仕事術〜人材育成を阻むバイアス〜

こんにちは！atomです。

土曜日は月一で勉強会をやっています。

コンサルタントは外に出る仕事なので、意図的に集まる時間作らないとなかなかナレッジの共有が難しかったりします。

今日は、コンサルタントを目指す方でもそうでない方でも気をつけるべき点についてです。

狼少年のお話の中で、羊飼いの少年が狼が来たと大人を日々嘘をついて困惑させていたら、本当に狼が来た時に信じてもらえなかったといった有名な童話があります。

本当に狼が来たという事実があっても、羊飼いの少年に対する認識の偏り（バイアス）できてしまい、事実を事実と受け取れなくなってしまっています。

少し極端な例ですが、実情としてもこういった事は多く起きていてるのではないでしょうか。

上司と部下の関係でこの人はできないと上司による決めつけがあり、必要以上にチェックが厳しくなったり、上司に相談しても無駄だと思い相談がされない状態となったり。

いわゆる人間関係という言葉で表現されたりもしますが、組織活動において、バイアスによって非合理的な判断がされるケースが何処でも発生していると思います。

コンサルタントとして気をつけるべきは、インタビューをする時などに、どの程度バイアスがかかっている発言なのかは注意深く見定めないといけないということです。

よく発生しうる事象としては、声の大きな人（発言力的な意味で）にバイアスがかかっている事を見抜かずに、それを事実としてしまうと、解決価値の高い問題の抽出や正しく原因分析ができなくなるリスクがあります。

一社会人としてもバイアスの存在を意識する必要があります。

今日の題に挙げた人材の育成について。

人に何かを教える際に、基本的には自身の成功体験をベースにああした方が良い、こうした方が良いというアドバイスをしていきます。

それ自体は問題ないと思いますが、そのアドバイス通りに後輩や部下が実施しないからと面白くない気分になっている自分がいたら要注意です。

冷静に考えればすぐ分かりますが、あくまでもそのアドバイスは、成功事例の１つでしかなく、必ずしもそれ以外の選択肢を排除するものにはなり得ないという事です。

また、成功体験といっても前提や背景が異なる中で何処まで今回有効性があるものかは見定める必要があります。

これは、年齢が上がるにつれて気をつけるべき事だと考えています。それは成功体験を積み上げれば積み上げるほど、そしてそれが評価をされるほど、バイアスが強くなっている可能性があります。

これを防ぐにはどうしたらいいか。

私が意識しているのは以下です。

1.そもそもバイアスの存在を意識する事

2.全面的に肯定や否定を基本的にはしない（スタンスとして）

3.細部まで意識する

2と3は近いですが、一つ一つの発言や行動をザックリと捉え、良し悪しを判断してしまうと、その中に含まれる良いものも否定してしまう可能性があります。

否定された側からすると、これでは正しいと自信を持てる発言や行動しかしなくなり、積極性がなくなっていき成長は鈍化します。

それは、更に上からすると不満になり負の循環が生まれます。

建設的な議論がしたくても議論成り立たなくなってきます。

特に教育担当、リーダー、管理職に携わる方は注意してみてください。

下の方は、貴方をそういう判断をしてしまう人なんだと見ているかもしれません。

自分も継続的に気をつけなくては。

では、また。

IT部門に求められる変革〜デジタルトランスフォーメーション編その1〜

おはようございますatomです。

皆さんはデジタルトランスフォーメーション（DXと表記）という言葉はご存知でしょうか。

直訳するとデジタルへの移行。デジタルというのはIT化と読み替えても良いかなと思います。

今までの事業をITをつかって変革させる。店舗での小売からamazonがよく例に挙がります。

ITといっても特にIoT、クラウド、AI、ビックデータなどの新たな技術を用いてビジネスモデルを変革していく事として語られる事が多いですね。

以下でも述べられていきますか、今後どの様な企業もITを事業とするIT企業の側面を持つ状態になると考えられます。

https://ja.m.wikipedia.org/wiki/デジタルトランスフォーメーション

最近はユニクロも情報企業への変革を急いでいたりしますね。

https://www.google.co.jp/amp/s.news.mynavi.jp/articles/2015/06/16/fastretailing/?amp?client=safari

大企業が変革を急ぐ一方で、中小企業は特に現状のメインストリームである既存の事業部門は、ITに強くないため、事業をデジタル化していく事が難しい構造があると感じます。

事業部門とIT部門の意識の違いのようなものがまだまだあるのが現状です。

事業部門はビジネス分かるけどIT分からない。IT部門はIT分かるけど、ビジネス分からない。

こんな事があったりします。

実は、もっと現状は厳しく

事業部門も現場レベルではビジネスの全容を抑えられておらず、IT部門もデジタル化する為のITの利活用の術を知らない位が実態です。

DXの必要性を経営が感じている企業は救いがありますが、経営自体がITに明るくない為、力を入れる必要性を感じていない企業は今後一層厳しい状況になる事が想定されます。

では、誰がDXを担っていくのか。事業部門なのかIT部門なのか。

私は事業部門で担っていくと考えています。

事業部門内にDXを推進する為のITの機能が強化されていくと考えます。

それは、目的が変わるか手段が変わるかで考えると手段が変わる方が受け入れられやすいと考えるからです。

企業内IT部門はITを手段に事業を支える事を目的としています。一方でDXとは手段がデジタル化してきますが、事業により収益を上げるという目的は変わらない事、そしてデジタル化していく為のITのハードルが技術革新によって下がっている事が考えられるからです。

事業部門でのデジタル化が進行していくと、IT部門にはどういった影響があるのでしょうか。

事業部門側でデジタル化が進んだら、IT部門としてやる事がなくなってしまうのでしょうか。

また、別の機会で考えていきたいと思います。

ITILにおける4つのP〜結構使えるフレーム〜

おはようございますatomです。

今回はITILで語られる4つのPについてです。

ITサービスマネジメントを成功に導くために考慮すべき4つの観点といえるものです。

Peaple(人)

Process(プロセス)

Products(ツール)

Partner(パートナー)

これらが大事だよとITILでは語っています。

似たようなフレームにBSC(バランススコアカード)などもあります。こちらはより上流すなわち戦略評価などに使ったりします。

話を戻して4つのPはどういったときに使うのか、大きくは２つのあるかなと。

１つはサービスデザインの段階、つまり設計段階です。もう一つは評価の段階です。

先に評価の段階での使い方としては、アセスメントの軸として使います。

前回プロセスの話をしましたが、プロセスが良くても人の問題でうまくいかないことなんかが良くあります。

物凄く綿密にインシデント管理を設計して、ツールもハイスペックなものを導入したけど、登録がされずにホコリをかぶっています。

非常に残念です。

社内のプロセスは、うまく回っていても委託先の動きが見えず、ブラックボックス化して、高い費用を払い続けるほかない。

これまた残念です。

4つの軸で評価する事で、次のアクションを特定しやすくなります。

同様に４つの軸を網羅的に設計段階で考える事で成果が出やすくなると思います。

特に自社内だけで、現状分析する場合、問題の乱れ打ちで大小入り乱れた観点の違う問題が洗い出されます。

個別に問題解決を図るよりも、4つのPの軸に分けてみると、自社の弱みが全体像としてどこにあるかも把握しやすくなると思います。

みんなで問題を洗い出した後に分類する時にちょっと試してみてはどうでしょうか。

コンサルタントの仕事術〜顧客との合意形成編〜

こんにちはatomです。

前回コンサルタントとは準備が大事だと話しました。

その続きです。

コンサルタントの仕事の仕方は基本顧客との合意形成の繰り返しです。

アプリケーションを開発する場合は、ケースにもよりますが、要件定義から基本設計くらいまで合意形成したら、後はテスト結果や成果物に対する合意形成といった形があると思います。

コンサルタントも問題抽出、原因分析、方針設計、施策の設計など、様々な工程で合意形成をします。

アプリケーションの機能性ほど明確でないケースがほとんどのため、また当初と変わったりするケースが多いため、合意形成をいかに取るかが非常に重要です。

その上でのポイントです。

まず顧客の要求は常に必ずしも目的に対する最適解ではないというのがあります。

それが如実に現れるのは、成果物のレベル感です。

分かりやすいが内容が薄いものと、内容は濃いがかなり理解に経験を要するもの、どちらが適切かは顧客の成果物を使う人の成熟度によって変わります。

リーダークラスと作り上げていても、リーダーの必要とする情報と現場の必要とする情報は異なるので、共に作るリーダーの声に答えるだけでは使えないものになってしまいます。

また、成熟度が低いから分かるように具体的に細かく決めて文書化して欲しいというニーズもありますが、成熟度が低い状況だとそもそも文書を見ないため、見やすい文書で慣れさせる事をまず実施した方が良いケースもあります。

また、細かく決めるには、相応の時間を要するため費用もかかります。

コンサルタントとして重要なのは、顧客の都度の判断時に影響を伝える事が重要です。

ここまで細かくするならば、当初予定のボリューム感から大きく超えるため、スケジュールに影響がでるが良いか。

この先の詳細化は、現場への浸透と共に見えてきた課題を踏まえた方が効率的であるが、それでも今の段階で、詳細化する形で良いか。

いずれも顧客に了解を取って進めています。

これは良い例だと思います。

一方で以下はあまり良くない例です。

もっと具体的に。。。了解しました。頑張ります。

上記の様な回答をして、納期に間に合わなかった場合、顧客は不満を表すでしょう。

そして、遅延をリカバリーするプランも求められたら、遅延を実際にキャッチアップしたりしつつ、さらに同様に顧客の要望に応えようとするあまり、結果応えられずトラブってしまう。負の循環。

これらは、よくよく話を聞くとコンサルタントが目の前の仕事に精一杯で、十分な計画がない中で、とっさの判断で答えてしまって、それがいつの間にか顧客との関係性において固定化され、言われた事をとにかくやる状態になってました。

合意形成とは、双方に責任が発生するものであり、特にコンサルタントとしては、起こり得る事態を想定して適切に情報提供できているか、専門家としての責務を果たしているかが重要だと考えます。

それと共に顧客側にも判断に対して責任を持つ必要があります。当初想定よりもやはり深掘りが必要であれば、スケジュールを伸ばす事を承認するなど。

ここら辺は相手の立場になれば、すぐに分かる事だったりします。

相手の立場を踏まえて、納得し得る選択肢を用意することがコンサルタントの合意形成かなと思います。

またの機会に顧客の視点を探る術について考えていきたいと思います。

コンサルタントの仕事術〜ITILプロセス設計編（変更管理）〜

おはようございます。atomです。

今日はITコンサルタントの業務の一つであるルール文書（規程、基準）などの作成についてお話しします。

私の主要コンサルティングの領域はITサービスマネジメントの領域なので、インシデント管理、変更管理などのルール作りをプロセス設計として取り組む事が多いです。

プロセスとは、特定されたトリガーを起因として、定められた成果を出すための一連の活動といった感じに定義されています。

プロセス設計をする上では２つの軸で考えます。

１つはここの変更の始まりから終わりまでの一連の流れ、もう１つは変更を束でどう管理するか。

前者を作業プロセス、後者を管理プロセスという軸で表現します。

例えば変更管理を例に取ると、変更の起因と種類を特定して、類型化し、類型化されたケースごとに承認のチェックデジットを設け、リリースとの連携などを決めていきます。

どういう流れを設けるべきかは、大体書籍を見れば分かります。顧客の成熟度に合わせてどの粒度に設定するかといった所にノウハウがあったりします。

一方で管理プロセスは、変更管理の作業プロセス全体をどうPDCAするかという観点で設計していきます。

誰が、どのタイミングで、どういったチェックを、どういった評価指標で実施するか。どんな評価指標を設定するかなどに特にノウハウの要素があると思います。

この両者を考える上ではもちろん体制なんかも考えます。

ツール導入に合わせてプロセス設計をする場合、ここでいう作業プロセスの設計がされるものの管理プロセスの設計がされず、プロセスとしての成熟度が回した結果分からないといった事があります。

ITILを活用してプロセスを改善するといった議論から、いつの間にかいかに現状の業務をツールに載せるかに議論が終始してしまうというケースに陥りやすい所です。

ここで重要になるのが、何を成果とするかです。ここも顧客にあった成果レベルの指針を事例などから提示する事が求められます。

そして、この成果レベルの合意が甘いとどこまで議論すれば良いのか分からなくなり、プロセス作りが長期化したりします。

コンサルタントとしての求められるのは、当初描いた成果レベルを実現するための設計において、いかに先回り出来るかだと思います。

先回りが必要なのは、議論の中で都度軌道修正をしないといけないので、先回りしておかないと、その場で最適解が出せないからです。その場で指摘できないと、流れは引き戻すのは非常に大変です。

したがっていかに準備して臨めるかが非常に重要になります。

前半プロセス設計手法、後半コンサルタントの心得みたいになってしまいましたが、どちらも大事なので、今後も少しずつお話しできればと思います。

コンサルタントのスキルアップ方法〜知識編〜

おはようございます。atomです。

前回に引き続きスキルアップについてです。

業務編では、仕事が集まる状態＝信用を得るということをあげました。

スキルアップをはかる上では、担当している業務だけでは学ばない領域がかなり多くあります。

例えば、開発だけをしていたら作ったサービスを売るという事に対しての方法論を持たないです。

ちょっと脱線しますが、開発者の方はこの本非常にオススメです。

開発者である事とマーケティングの観点の重要さを学ぶ事が出来ます。

Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方

それは私の仕事ではないと言ってしまうことも出来ますが、上に立つという事はセールスに対しても技術に対してもものを言える必要があります。

本題のコンサルタントのスキルアップ方法についてです。

コンサルタントは、中核の知識領域とともに幅広い知識を持つ事が重要だと考えます。

私の場合、ITサービスマネジメントが中核です。

しかしながら、やってる仕事はそれだけに留まらず、コーチングの要素であったり、組織論、経営論、マーケティング、ツール利用技術、財務論、セキュリティ、システム監査、新技術の活用、プロジェクトマネジメントなど多岐に渡ります。

私は知識を得るために書籍を活用しています。業務上だけでは学ばない知識を得る事、経験不足を補う事を目的としてます。

読んだ本の数で語るのはあまり良いとは思いませんが、年間50冊くらいは読んでると思います。

だいたい2対1位の割合で2を業務に関係するもの、1を業務とは直接関係しないものを読みます。

では、どの様に選ぶのか。

多分私の選び方は効率的なやり方ではないかもしれませんが、大型の書店で関連しそうな書架で中身をペラペラと見て選んでいきます。

中でもなるべく体系的まとまっていそうな物、読んでいて苦にならない物、事例が含まれているものを選んで買っています。

買って直ぐに全体に目を通しますが、熟読は必要に迫られないとしません。それは、時間がかかってしまうのと、分からない事を学んでいるのでイメージが湧きづらいので私の場合は把握に留めて熟読して理解するまではしないです。

脳内INDEXの作成という感じです。

これがあると、点と点の知識が紐付きやすくなり、仮設立案できる幅が広がると感じます。

あとは、専門家に聞く際に最低限の概念がある中でヒアリングすると理解がかなり進みます。

ただしこのやり方は、書籍購入の実費がかかります。会社負担してもらうこともできるかもしれませんが、自由度考えてしてないです。

自己成長への投資は惜しまない方が良いと思いますよ。損したと思う事はないので。

では、今日はこの辺で。

コンサルタントのスキルアップ方法〜業務編〜

おはようございます。atomです。

風邪で何日か寝込んでました。

皆様も体調には気をつけてください^^;

今日はスキルアップについてです。

仕事ができる人とそうでない人には仕事の集まり方が違います。

仕事をすればするほど経験値は増えますので、仕事はできるようになります。

従って如何に周りから仕事が集まるかを考える事が重要です。

ではどうやったら仕事が集まるのか。

少し視野を上げて仕事を任せる側の上司を目線で考えてみると良いです。

①任せても良いと思える前提知識はあるか。

②任せても納期内に実行できそうか。

③責任感を持って全うしてくれそうか。

特に③を問うのではないでしょうか。①と②はフォローする人をつければ解決します。

③は実は普段チェックされてたりします。

一つ一つの仕事に対して期待に応える事で、上司からの信用を得る事ができます。

次のステージとしては、顧客から信用を得ていく形になります。

偉くなれば経営から、株主からと対象が変わっていきます。

一つ一つの仕事に対して、依頼者の期待を超える事にこだわりを持ってください。

それを続けていれば、どんな職場でも活躍できる人材になれるはずです。

IT部門における人材の実態〜現場編〜

おはようございます。atomです。

ここまできたら現場編も書こうと思ってます。

しかしながら、個人的には1番難しいところです。

それは最も接点がない事もありますが、部門長や、リーダークラスの様に共通する点が傾向が少なく組織の文化や人材育成の仕組みの整備状況によりかなり異なる事が挙げられます。

現場の方の人材像も幅広いです。必ずしも年次や世代ではくくる事が出来ないです。

すいません。ここはもう少しデータ集めてリベンジしますm(._.)m

IT部門における人材の実態〜中堅リーダー編〜

こんばんは。atomです。

今日は現場のリーダークラスの人材についてです。

人材像として、現場業務に精通してある領域について、エースもしくはエースだった人、経験年数が15年位を人材像を想定しています。

1番パワフルな層かなと思います。

よくコンサルティングを行う際は、私の場合は部門長とリーダークラスの方々と進める事が多いです。

それは部門長の方がリーダーの育成も見込んでの事かなと思います。

また、業務を把握する上で必須の存在と言えます。私的にはここの層のバランスが組織力に大きく繋がると考えてます。

それは、仮に優れた戦略があっても実行がともなわければ良くはならないからです。

では、どんな状況なのでしょうか。

まず１つの傾向としてあるのは、業務実施の延長線上にあるスキルは有して深掘りされていますが、業務視点になりがちで事業としての観点が不足してる面があります。

これは現場に責任を持っているので仕方ない反面もありますが、上長としては早く視野を広げて欲しいと思っているはずです。

自社の業務のばかりで、視点が内向きになるので、より外部と触れさせる事が必要です。我々の様にコンサルに指導させるのも１つの方法ですし、研究会への参加などあると思います。

コンサルとして中に入らせていただくと、問題を教えてくださいと聞くと、山の様に教えてくれますが、組織のありたい姿を教えてくださいというと止まってしまう事が多いです。

リーダークラスの方は人並み以上に責任感が強いがため、自分の守備範囲はなんとか責任を持って取り組んでいます。それ故、大きな目標を意識せずに働いてしまっているケースがあると感じます。

こんな事はないでしょうか。

下が上に上がるというよりも上の方が変わる事の方が多い。

これは、リーダークラスがその視点を持ててないという経営の１つの判断だと思います。

先ほどバランスという言葉を使いましたが、マネジメントの視点と現場の視点を表しています。

自らが人材像に当てはまり、現場向きすぎると感じる人がいたら、少しマネジメントを意識してみてはどうでしょうか。

IT部門における人材の実態〜部門長編〜

おはようございます！atomです。

 今日はIT部門における人材の部分についてです。

 コンサルティングでクライアントの問題解決を支援する上で、マネジメントの仕組みをみなおしたり、組織組み替えたり、スキルマップを作ったりと様々な取り組みをします。

どんな企業でも共通するのは人の問題。

そもそもニーズに見合うスピードで自発的に問題解決解決が可能な組織なら私たちの様なコンサルの仕事はありません。

しかしながら、ITにおける外部への発注はITコンサルティングが最も多いのがデータとしても出ています。

企業内IT部門と情報システム子会社のケースでよく言われるのは、優秀な人材は事業部や外販部隊。いわゆるお金を稼ぐ部門に配置され、そこにあぶれた人が流れてくるとよく部門長の方がおっしゃっているを伺います。

これは確かに事実ではあるとは思います。

しかしながら、それは同時にIT組織がビジネスに貢献できていないことを示唆していると感じます。

優れた人が能力を発揮できる場所を果たして貴方は十分に作っていますかと問うと、頭が下がりますと大抵返ってきます。

IT組織の部門長自体が、自部門の範囲を限定しているケースが多いと感じます。

ビジネスにITは不可欠になるのは、メガトレンドとして不可避なものです。そういった中で、事業側の業務にいかに踏み込めるのか、もしくはデジタルトランスフォーメーションの推進者としての立ち位置を築く事が出来るかといった点がIT組織の部門長に求められる視点です。

管理者の観点での人の問題について話しましたが、現場はどうでしょうか。

また、別の機会お話できればと思います。

新規事業開発の主要成功要因とは！？

おはようございます！atomです。

今日は新規事業開発に関するお話です。

自社で新規事業開発の仕組みを構築しようと悪戦苦闘している気づきなんかを書いてみます。

そもそも何故新規事業開発の仕組みを作ろうと思ったか。

一言既存の事業だけでは、将来的には会社が立ち行かないと考えたからです。

自分で新規事業を考える事も視野に入れつつ、そんなに簡単にビジネスを継続して採算取れるものには出来ないと考えたので、仕組みを作っとこうといったところです。

最初は新規事業開発の制度作りから始めました。

アイデアを募り、一次承認通ったものは一定のパワーを割いて事業計画を作る許可を得る、最終承認を通ると予算化され事業化していく。主にビジネスのアイデアを創る、0から1を増やす試みとして纏めた。

それに伴う活動やルール、運営主体など制度は月一の研究活動で半年で形になった。多分3ヶ月でも出来たと思う。

経営にプレゼンして、意見を聞くと本当にビジネスしたいと思う人は制度どうこうではなく、すぐに動く、アイデアだけには価値がないと差し戻しとなった。

そこから思考を深めていく。

投資にたるビジネスかどうかをどう判断するか。それは、ビジネスプランだけでなく、それを進める人も信用に足るか。という事である。

そして、その人という要因を制度や啓蒙活動で育てる事が出来るのか。

事業を立ち上げる上では、想定しない問題解決の連続となる。それは物凄くパワーがいるし、自分の考えを信じ切らないと進む事は出来ない。

色んな人の話を聞いたり、書籍やwebなど個人で手に入る情報はかなり調査したと思う。

ちなみに一部ですが参考にした書籍を挙げます。

制度設計には、この本がオススメです。

新規事業・成功の〈教科書〉 ―200社以上に命を吹き込んだプロ中のプロが教える

 他にもかなり乱読しましたが、この本が特に気になりました。

INNOVATION PATH イノベーションパス

 イノベーションパスの中に記載される人の要素の部分です。

事業開発には、必ず確固たるモチベーションが必要になる。

その一歩を踏み出し、アクセルを踏み続けるには、何が必要なのか。

お金？お金が欲しいだけなら程度にも寄るがフリーで食べれるだけの能力と人脈をつければ、それなりの対価は得ることができる。

名声？人の評価だけでキツイ思いできる気がしない。

実際に企業した人の話では、見たことのない景色が見えると表現してましたが、きっと最終的に面白いと思ってるからなのではないか、後は自分のプランに可能性を感じてるからではないかと感じている。

コンサルという仕事をすると、基本的にはロジカルに物事考える様になりますが、この領域はロジカルではない気がする。

自分は山登りを趣味としてるので共感できる部分が多い。

何故山に登るのか。

面白いからに決まってる。

もちろん一歩一歩はツライが、ふっと見回すと見たことのない景色に出会えたりする。山登りはルートが基本的には決まってるので、不安と闘うことはないが近いものがある気がする。

では、どうやったら面白がれるのか。

そう言う気質は後天的に身に付けることができるのか。

ここら辺が目下の検討テーマです。

クライアントともこんな話をすると、なかなか仕事を面白がれていないのではないかという話がでる。

コンサルディングをしていても、自身で事業開発を模索しても人の要素は必ず付いて回る、さらに深掘りしていこう。

IT組織の人に関わる部分の実態なんかも書いていこうと思います。