コンサルタントの仕事術〜ITILプロセス設計編（変更管理）〜
おはようございます。atomです。
今日はITコンサルタントの業務の一つであるルール文書（規程、基準）などの作成についてお話しします。
私の主要コンサルティングの領域はITサービスマネジメントの領域なので、インシデント管理、変更管理などのルール作りをプロセス設計として取り組む事が多いです。
プロセスとは、特定されたトリガーを起因として、定められた成果を出すための一連の活動といった感じに定義されています。
プロセス設計をする上では２つの軸で考えます。
１つはここの変更の始まりから終わりまでの一連の流れ、もう１つは変更を束でどう管理するか。
前者を作業プロセス、後者を管理プロセスという軸で表現します。
例えば変更管理を例に取ると、変更の起因と種類を特定して、類型化し、類型化されたケースごとに承認のチェックデジットを設け、リリースとの連携などを決めていきます。
どういう流れを設けるべきかは、大体書籍を見れば分かります。顧客の成熟度に合わせてどの粒度に設定するかといった所にノウハウがあったりします。
一方で管理プロセスは、変更管理の作業プロセス全体をどうPDCAするかという観点で設計していきます。
誰が、どのタイミングで、どういったチェックを、どういった評価指標で実施するか。どんな評価指標を設定するかなどに特にノウハウの要素があると思います。
この両者を考える上ではもちろん体制なんかも考えます。
ツール導入に合わせてプロセス設計をする場合、ここでいう作業プロセスの設計がされるものの管理プロセスの設計がされず、プロセスとしての成熟度が回した結果分からないといった事があります。
ITILを活用してプロセスを改善するといった議論から、いつの間にかいかに現状の業務をツールに載せるかに議論が終始してしまうというケースに陥りやすい所です。
ここで重要になるのが、何を成果とするかです。ここも顧客にあった成果レベルの指針を事例などから提示する事が求められます。
そして、この成果レベルの合意が甘いとどこまで議論すれば良いのか分からなくなり、プロセス作りが長期化したりします。
コンサルタントとしての求められるのは、当初描いた成果レベルを実現するための設計において、いかに先回り出来るかだと思います。
先回りが必要なのは、議論の中で都度軌道修正をしないといけないので、先回りしておかないと、その場で最適解が出せないからです。その場で指摘できないと、流れは引き戻すのは非常に大変です。
したがっていかに準備して臨めるかが非常に重要になります。
前半プロセス設計手法、後半コンサルタントの心得みたいになってしまいましたが、どちらも大事なので、今後も少しずつお話しできればと思います。
コンサルタントのスキルアップ方法〜知識編〜
おはようございます。atomです。
前回に引き続きスキルアップについてです。
業務編では、仕事が集まる状態＝信用を得るということをあげました。
スキルアップをはかる上では、担当している業務だけでは学ばない領域がかなり多くあります。
例えば、開発だけをしていたら作ったサービスを売るという事に対しての方法論を持たないです。
ちょっと脱線しますが、開発者の方はこの本非常にオススメです。
開発者である事とマーケティングの観点の重要さを学ぶ事が出来ます。
Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方
- 作者: Eric Sink,エリック・シンク,青木靖
- 出版社/メーカー: 翔泳社
- 発売日: 2008/09/11
- メディア: 単行本（ソフトカバー）
- 購入: 17人 クリック: 182回
- この商品を含むブログ (89件) を見る
それは私の仕事ではないと言ってしまうことも出来ますが、上に立つという事はセールスに対しても技術に対してもものを言える必要があります。
コンサルタントは、中核の知識領域とともに幅広い知識を持つ事が重要だと考えます。
私の場合、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社以上に命を吹き込んだプロ中のプロが教える
- 作者: 坂本桂一
- 出版社/メーカー: 東洋経済新報社
- 発売日: 2010/04/09
- メディア: 単行本
- 購入: 5人 クリック: 11回
- この商品を含むブログ (1件) を見る
他にもかなり乱読しましたが、この本が特に気になりました。
イノベーションパスの中に記載される人の要素の部分です。
事業開発には、必ず確固たるモチベーションが必要になる。
その一歩を踏み出し、アクセルを踏み続けるには、何が必要なのか。
お金？お金が欲しいだけなら程度にも寄るがフリーで食べれるだけの能力と人脈をつければ、それなりの対価は得ることができる。
名声？人の評価だけでキツイ思いできる気がしない。
実際に企業した人の話では、見たことのない景色が見えると表現してましたが、きっと最終的に面白いと思ってるからなのではないか、後は自分のプランに可能性を感じてるからではないかと感じている。
コンサルという仕事をすると、基本的にはロジカルに物事考える様になりますが、この領域はロジカルではない気がする。
自分は山登りを趣味としてるので共感できる部分が多い。
何故山に登るのか。
面白いからに決まってる。
もちろん一歩一歩はツライが、ふっと見回すと見たことのない景色に出会えたりする。山登りはルートが基本的には決まってるので、不安と闘うことはないが近いものがある気がする。
では、どうやったら面白がれるのか。
そう言う気質は後天的に身に付けることができるのか。
ここら辺が目下の検討テーマです。
クライアントともこんな話をすると、なかなか仕事を面白がれていないのではないかという話がでる。
コンサルディングをしていても、自身で事業開発を模索しても人の要素は必ず付いて回る、さらに深掘りしていこう。
IT組織の人に関わる部分の実態なんかも書いていこうと思います。
コンサルに求められる問題解決能力、キャリアパス
こんにちは！atomです。
朝方の冷え込みがしんどくついにコートを投入し始めました^^;
今日は自分がコンサルにおいて最も必要とされる能力だと思う問題解決能力についてです。
最近若手でコンサルをしたいと入ってくる人がいて、その人に対して何を学べば良いかを考えたりします。
自分の経験だけで語るのは、１つの事例でしかなく固定観念にとらわれないように色んな人にも意見を求めたりもします。
自分なりの答えとしては問題解決能力という言葉にいきあたりました。
コンサルタントは事例やフレームワークを駆使してクライアントの目指す姿になる為に問題解決を支援します。
しかしながら、フレームワークは万能ではなく、クライアントの状況に応じて使い分ける必要があります。
事例とて私がまだ経験値が不足している部分も多分にあり、経験したことのない問題に出会う事も少なくないです。
そんな時に必要になるのが問題解決能力だと思います。
ここでいう問題解決能力とはどんなものか解釈を挙げてみます。
・好奇心
・情報を主体的に収集するリテラシー
・ありたい姿を描く能力
・ありたい姿に対して問題を定義する能力
・問題を正しく分析する論理的思考
・解決に向けた行動力
・物事を概念化して伝える能力（文書化なども含む）
・一連の流れを他者と合意形成しながら進めるコミュニケーション能力
・最初は仮説でも一歩を踏み出す勇気
大きくはこの様な要素があると思います。
一連の流れを通じて論理的思考能力はお作法のごとく必要で、前提、必須と言えると思いますが、それ以上にありたい姿を描く、デザイン的な思考能力が個人的には重要だと思います。
そもそもここでいう問題とは、日々発生している良くないと考えられる事象を示しているのではなく、ありたい姿と現状のGAPを示しています。
つまり、ありたい姿がなければ本当の意味での問題解決にならないと考えます。
では、ありたい姿を描くにはどうしたらいいのか。
明確な解はないですが、ありたい姿を描ける人が上級マネージャーを勤めるケースが多く、その多くが情報のインプット量が多いと感じます。
例えば業界の動向も知らずに、自社の市場ドメインは考えられません。
そして、その根本には好奇心の様なものを持ち合わせてる気がします。
コンサルタントと企業内のマネージャーのスキルセットはかなり高いと思います。
コンサルタントを目指される方、マネージャーを目指される方、問題解決能力を身に付ける事を意識してみてはどうでしょうか。
また、別の機会にそのトレーニング方法も述べてみたいと思います。
IT企業におけるITILのビジネス活用
こんにちはatomです。
今日はITILのビジネス活用についてお話していきます。
ITIL活用の現状としては、品質や効率の問題などから、インシデント管理、問題管理を取り入れたり、ガバナンスの観点から変更リリース管理を取り入れるというケースが多いように感じます。
これは、ITILがツール導入に合わせて取り入れられること、ツール自体がITIL v2をベースに作成されていることが大きいと考えられます。
ちなみにITIL v2では、ライフサイクルの考え方はなく、デリバリーとサポートを主眼としていました。
では本題のITILのビジネス活用という点ですが、サービス化という考え方資産の利用という点が非常に重要になると思います。
また、現状はユーザー企業やIT企業の企業内の整備にITILが使われていますが、その形態も変わってきています。
サービス化とは、システムを運用するという考え方から、利用できる状態をサービスと捉えて、運用仕事をサービス提供というものに視点に切り替わることだと理解いただければと思います。
これを実務に当てはめる上で重要なのがサービスレベルです。
運用とは究極要員が半分になっても回ります。もちろんトラブルが増えたり、依頼の対応は遅れます。100だったパフォーマンスが50に下がるかもしれません。
しかしながら、実は業務上は50のパフォーマンスで十分でそれ以上にコストが安いことを顧客は期待してるかもしれません。
要はサービスレベル次第。
次に資産の所有から利用への変革です。物理サーバーをもはや顧客自身が管理することはなくなってきています。
固定費の変動費化という考えはユーザー企業にとって競争にお金を回すために、より必要になってくると考えられます。
ITサービスを提供する企業は 、サーバーの運用保守に対して役務提供するのではなく、ITサービスをサービスレベルに基づいて提供する。という形態が当たり前になってくるとおもいます。
資産も顧客が所有するのではなく、サービス提供側が用意し、顧客は必要なスペック分だけ利用する。監視業務も決められたサービスレベルのパターンから選ぶなどなど。
イメージはデータセンタービジネスの拡張版ですね。必ずしも筺体を保有しなくても良いと思います。IT企業自体もクラウド利用して、特定分野のサービス提供も十分考えられます。
結果としては、IT企業からすると顧客あたりのビジネスボリュームは増え、顧客としてもコア業務へのシフトが可能になります。
そういった中では、業務も領域ごとにサービスレベルをどう設計するかといったといった知見が必要になります。
自社の改善ではなく、ユーザー企業によるサービス利用、IT企業におけるサービス提供、それらの共通言語としてITILがより活用されるようになると思います。
自社のITサービスを定義して、サービスレベルをつけてカタログ化する、それらの需要を踏まえてキャパシティ設計する。要件の変化に応じてサービスを変更して、リリースする。リリース後のユーザーからの依頼に応える、インシデントに対応する。
ようやくビジネス環境がITILに追いついてきたのかなと思う今日この頃でした。
次回はITILからは離れて戦略思考の入り口だと思う、問題解決についてお話ししてみたいと思います。
ITIL活用の実態
こんにちはatomです。
今日は私の主要コンサル領域のITILについてお話します。
私はITILの中位資格のintermidiateを4つ取得してもう直ぐ上位のExpartまでもう少しってところです。
エントリー資格のITILファンデーションの講師などもやったりしてます。
ITILは、ITサービスマネジメントのベストプラクティスで、IT業界では、運用寄りの方々の中では標準的な資格になって来てます。
講師をやってる身としては、ITILは運用の人だけなくITに関わる人は言葉の使い方としてもお作法として所得するべきだと思っていますが。
もともとITILとは5冊の書籍からなるITサービスの運営におけるやっぱ方がいいとか、こんな事に考慮すべきだよという点の事例の集まりのようなものです。
正直一回読んで分かるものだはなく、同様にプロジェクト管理の知識体系のPMBOKの方がわかりやすいと思います。
現場の実態としても、ITILツールを使ってはいるが、ITILを理解してる人というのはかなり少ないと感じる状況です。
また、活用状況としてもITILツールがフォローしている領域が主で、イベント管理、インシデント管理、問題管理、変更管理、リリース管理、構成管理、要求実現（リクエスト管理）くらいがほとんどです。
ITILの本質的なメッセージは、ビジネスとITの整合を図ることで、サービスストラテジ、サービスデザイン、サービストランジション、サービスオペレーション、継続的サービス改善とITサービスのライフサイクルをどうマネジメントしていくかするかというものです。
しかしながら、実態はトランジションとオペレーションぐらいの活用状況。。。
実にもったいない！
恐らくはITILの中位資格以上があまり普及しておらず、マネジメント層に十分理解されてない事もあるのかなと思います。
あとはITIL=運用のフレームワークという誤解もある気がします。
次回はITILをビジネスに活用する例を挙げていこうと思います。
では、皆さん良い祝日を。
システム運用における課題と官公庁でのトレンドその1
こんばんはatomです。
このところ官公庁系の話題です。
最近の官公庁のトレンドとして、調達仕様の中に記述される運用業務にITILに基づくといった要件が記述される事が多くなってきました。
また、SLAやKPIを具体的に提示することも求められており、構築に強みを持っていても運用については体系的な運用モデルなかったりSLA設計に苦しんでいるベンダも多くいると感じます。
運用は、どちらかといえば開発よりは脚光が当たらず、投資もされづらい領域だと思いますが、実は顧客視点で考えると運用に課題を感じる官公庁が多く、提案価値向上の要素が非常に大きな部分でもあります。
入札案件の構造上、ベンダー側の改善の必然性がないことも、より運用が評価対象となる要因だと思います。
ここら辺の価値に気づいている企業はまだまだ多くはなく、取り組みが早い企業と従来型の構築だけを事業ドメインにしている企業と差がついていくのでは、とちょっと感じたりしてます。
今日はこの辺で。ではおやすみなさい。
