慌しい日の始まり

あけましておめでとうございます。ブログを始めて初めての年越しとなりました。

今年も少しずつアップできればと思います。

新年早々の仕事は、企業を様々な観点で評価し現状を明らかにするアセスメントモデルを設計しています。

なるべく使いやすくて手軽な物を模索中。。

1年あっという間で重たい案件の合間に物作りに勤しみます。

ITコンサルをしていると山ほどアセスメントのフレームワークと出会います。今後そういったものも紹介していければと思います。

今日はこの辺で。

ITIL 活用〜要求実現で取り組むべき申請統合〜

久しぶりにITIL についてです。

本当はブログのタイトルになってるくらいなのでもっと書いていきたいところですが、興味あることばかり書いてしまってるので、のんびりお付き合いいただければ幸いです。

要求実現とは、サービス要求（ユーザーからの作業の依頼などユーザーからの作業を伴うリクエストの対応）を管理するプロセスです。

一昔前はインシデント管理の一要素として管理されていましたが、サービスの計画外の中止などで定義されるインシデントとは主旨が異なることから分けて管理する事が推奨されています。

サービス要求の例としてはパスワードのロック解除やPCのキッティング依頼など、業務としては申請を受け付けて対応する業務が挙がります。

これらをITIL に準拠させて標準化したり効率化していく際に多く取るのが、バラバラに行われていた申請をツールに載せていく事に合わせて整理するというアプローチがあります。

 申請業務をツールに載せる上で一番やってはいけない事は、現状の業務をそのまま載せようとする事です。

特に組織が大きく利害関係者が多い企業ほど、整理をしてから移行する事が求められます。それは以下の理由からです。

・大企業だと軽く100を超える申請があったりします。それをそのままツールに載せるのはコストがかかりすぎる。

→そもそも同じ意味合いでも申請が分かれていたり、項目もバラついている

・ユーザー視点で申請が統合されずシステム別の提供者視点の申請となっている。

→ユーザーは異動やなんらかの事業上の要件によって申請を出してきます。それらのユースケースではなく、申請対象ごとに申請が設けられたりするので１つのイベントで複数申請を出さなくてはいけないと言った手間が発生します。ひどい時には申請先がそれぞれ異なって状況説明を都度必要となります。

どんなツールでも、無制限にバラついた申請をそのまま載せるには、仕様上の制約やメンテナンス工数が膨大となり、現実的ではなくなります。

申請自体の統廃合や申請項目などの統廃合を行う事で、移行に伴うコストの削減や、ユーザーの手間も削減する事ができます。

まずは、整理するという大方針の元に進めるようにしてください。 

より細かい統廃合のポイントや移行の方法についてはまた後日お話できればと思います。

食から学ぶ持続可能性システム思考

今日は仕事に関係なくプライベートなお話です。

最近妻が建築士をしている関係で、漆喰塗りなど手伝った方にお呼ばれされて食事をしました。そのご夫婦は奥さんの方が野菜を扱う仕事をしているのですが、そこで興味深い話を聞きました。

そこで挙がったのはダンバーバーというシェフの方のお話です。ちなみにtedでプレゼンしたり本も非常に面白いです。

食の未来のためのフィールドノート・上: 「第三の皿」をめざして:土と大地

彼の話が面白くてNETFLIXの動画まで見てしまいました。

料理を突き詰めると、食材に行き当たり、食材を突き詰めると、食材の生産現場にたどり着きます。それを持続可能性なシステムの中で作り上げるある種当たり前が生み出すこの上ない美味。共感するのが、それが一番美味しいというところです。

他にも面白いと感じたのは牛の話。牛は名前をつけると美味しくなるそうです。また、実は沢山の牛の乳を混ぜてバターは作られるのが一般的ですが、一頭一頭同じ餌を与えても味が全然違うとのことでした。

人間に置き換えれば当たり前ですよね。一人ひとり異なると人間だと分かるのに牛に対してはそうは見れない。

当たり前だけど、なかなかそういった視点で考えることがないことってありますね。

 ダンバーバーさんではないですが、持続可能性なシステムを作り上げるという点に自分は凄く魅力を感じます。ビジネスにおいても、関係者がそれぞれメリットを享受できるスキームを考えたり、一過性ではなく続ける事でさらなるメリットが享受できる。そんな仕組みを作り上げることに自分はロマンを感じてしまいます。

ご興味があるかたは、是非ご一読を。

官公庁のITマネージャーに知っておいてほしい事

以前官公庁のトレンドとして運用に課題があると述べました。今回は問題点と意識すべきことについて触れていきたいと思います。

官公庁における問題点は長期間の入札案件の調達仕様の不足という点が挙がります。比較的大きな規模では3年から5年の委託となります。入札参加ベンダーは官公庁の発行する調達仕様書に基づき提案をしますが、そこに記載する情報が十分なものとは言い難いのが実情です。

私は官公庁に呼ばれてその調達仕様を入札参加ベンダーが精度の高い金額を出せる様に必要な情報を整備したり、場合によっては入札業務として提案を作る支援をしたりします。そこで実情を知る訳ですが、もちろん精度の高い金額で契約できている官公庁もあるとは思いますが、本当に必要となる金額と実際に契約している金額では大体1.5倍程度の開きがある様に感じます。官公庁は必要以上の金額を払っているのです。

最終的にはそれは税金となって皆さんから徴収されている訳です。。。

入札参加企業の立場からするといかにリスクヘッジしつつ、指名業者として選ばれる為の提案内容を作らなければなりません。戦略的な提案といった便利な言葉が使えないほど、大規模入札案件では想定外によるダメージが大きくなります。その為、どうしても調達仕様の情報の精度が低いほどリスク分が積まれ金額が上がります。

一旦その金額で契約すると、今度はそれがベースとなり、ある種ベンダーの既得権益となります。官公庁の大規模案件は、費用がとても大きい為、ベンダーとしてはそれをいかに守るかが重要視される為、自ら実態を精度高く報告しコスト削減の余地を与える必要がなくなってしまいます。

対象業務の品目が変われば、年次の契約更新の際に見直しの対象となりますが、そうでもない限りは基本当初の入札金額での契約が保証されてしまうのです。

では、官公庁のITマネージャーは何をすべきか。私は以下だと考えます。

①数多くのベンダーと関係を築く事

②業務可視化と標準化は必ず取り組んでおく事

③第三者の視点を取り入れる事

①は付き合いがないほど、内情を知ってもらう事が出来ないので、入札参加の敷居は高くなります。どの程度の成熟度で調達仕様書がかかるのかどうかの肌感覚もベンダーにとっては重要な情報となります。

②は精度が高い調達仕様書を書くには、業務の可視化が前提となります。業務の全体像が伝えられないのに適正な提案など受けれるはずもありません。また、標準化されていないほど整備に費用が上乗せされてしまい膨らみます。

③は第三者視点というのが重要です。そもそも前述した構図が生まれている要因としては、官公庁のIT担当者自体にコスト意識が高くないこともあるのではないでしょうか。随意契約が続き指導が入るくらいの状況であれば別ですが、そうでもなければ敢えて適正な競争の元に入札させるよりは、つづがなく入札を完了させ色々言わなくてもツーカーでやってくれる方が楽だからです。

世の中悪意まではいかなくてもビジネスという観点においては、多くの人材が怠惰であると思います。その惰性のスパイラルを定期的に引き締めるには外部の人材を使って、実態を明らかにする事が有効であると感じます。中にはもちろん惰性ではなく、革新者とも呼べる人材がいるはずです。そういった人達に援護射撃できる外部の人材を使うべきだと思います。

とコンサルの立場の自分が言ってもというのはありますが、実際に支援するとかなり感謝されたりします。既存ベンダーとの関係に一石を投じてくれたなど。

今回は官公庁のITマネージャー側の立場ですが、願わくば官公庁のITマネージャーが成果を挙げて影響力を発揮していってくれることを願う今日この頃です。

中小企業のIT部門長が持つべき視点とコンサル仕事の本質

最近長くコンサルティングを実施していた企業が区切りを迎えようとしており、部門長の方に結果を報告するとともに将来こうなっていってほしいとの想いを述べる機会がありました。

その企業のIT部門の部門長は現場叩き上げで高い問題解決能力を持っているものの、そもそも全社におけるIT部門の立ち位置が重要性が低く、IT自体が全社への貢献がまだ弱いため、限られた範囲でのパフォーマンスを発揮するに留まっていました。

ITのビジネス貢献とはよく叫ばれることで、事業のデジタル化が進む中では、より貢献の範囲やスピードを大きくする必要があります。そういった背景の中では、全社におけるITの立ち位置を変えていく必要があります。

ではどうやって変えていくか。それを経営に納得してもらうためには、事業におけるITが果たすべき役割を説いていかないといけません。自部門の視点ではなく、より経営的な視点で話が出来ないとこれを実現できません。

我々コンサルタントが出来ることは、部門長に対して水先案内として、事業構造から推測されるIT貢献の可能性を伝えるとともに、一部門長の視点から経営視点に引き上げる事だと考えています。

いつも思いますが、コンサルティングの本質はクライアントが評価される事に資することなのかと思います。自分がコンサルで入った企業の相手がその後偉くなっていたら、それは自身の提供したサービスの成果としてカウントできるものだと思います。ドキュメントを作るのも、プロセスを設計するのも全てはそこに繋がっているのではないかと考えたりします。

願わくば経営視点を持ったITにおけるリーダ、CIOとも呼べる方を増やし一緒に改革を進めていきたいなぁと思う今日この頃です。

コンサルタントのスキルアップ術〜ラーニングピラミッド〜

スキルを伸ばす、理解を深める上では人に教える事程理解力が上がる事はないと思います。

皆さんはラーニングピラミッドという考え方はご存知でしょうか。

学習効果アップの鍵「ラーニングピラミッド」とは？ [学習・勉強法] All About

ITILの講師をしていると、説明を繰り返す事で自身の理解が深くなっていく事を日々感じます。

説明の為に、人に伝えるための概念化を繰り返すことで、解釈が変わっていく感じでしょうか。

深く学びたい事こそ、人に教える事をお勧めします。

コンサルタントのスキルアップ術〜行動原理とコンピテンシー〜

成長の仕方やその為の方法論は、個人ごとにある根底のマインドが大きく関わるのは言うまでもない事ですが、具体的にどんなマインドでどういった行動をしたら成果に繋がるのでしょうか。

今日はその辺についてお話ししていきます。

自分は元々仕事に対して劣等感を持っていました。技術者としても中途半端、コミュニケーション力が高くもなく、プレゼンも苦手で人前に出ると汗が止まらずテンパってしまう。資料はうまく作れず文章力も拙い。頭の回転も速くない。様々な点で人並み以下という自覚がありました。

その分人よりやらないと人並みにならないという、危機感があった様に思います。実際に若手の頃お世話になった人には、迷惑かけすぎていて、頭が上がらないです。

現在はどうかと言うと、どれも優れているものはありませんが、結果がついてきている事実から人並みくらいにはなれたと思います。

ジョブアサインにも恵まれたとは思いますが、自分なりにどうすれば成長できるかと言うことだけは人に負けないくらい切実に考えながら過ごしてきた様に思います。

例えば、仕事が任されるチャンスがあると見るや任されるのを待たずに必ず仕事を取りにいってました。そして任された仕事は絶対に逃げずにやりきることは徹底してきたと思います。もちろん大きな失敗も多く経験しています。上司にボロクソに言われることも経験してきています。それでも前のめりに仕事していたと思います。

そうやって動いていると周りの見る目が変わってくるのだと思います。まだ厳しいかもしれないが任せてみようといった感じです。今部下を抱える身となって自分でも感じますが、任せたいと思える人と思われるかどうかいうのは非常に重要な事の様に感じます。ジョブアサインを考えるとき、そのスキル面でのフィジビリティも重要ですが、この人のコンピテンシー（行動特性）を判断されるのだと思います。

スキルがあってやれそうな人よりスキルは足りないけどやり切りそうな人とでもいうのでしょうか。それは日々の仕事ぶりを見て暗黙的に判断されていると思います。スキルはあるのにジョブアサインに恵まれないと考えている人はそういった点に何か問題があるのかもしれません。

あとは、苦手な事や経験のないでも繰り返し取り組んだことが重要だと考えています。慣れていき、型ができてくると以前は苦労したことが全く苦労しなくなります。正確には苦労だと感じなくなります。

苦手な事や経験のないことに取り組むのは勇気がいる事で、それは意識的にやらないとやらないままになります。やらないままで行くか、取り組む事で経験から学び取るかは差に出ると思います。

コンピテンシーを深掘りすると、自分がどうなりたいか、何のために仕事をしているかといった根源的な問いに行き着くと思います。

苦手な事や取り組んだことないことでもやっていくのは、結局それが自分にとってメリットになると感じているからです。今今やりたいかやりたくないかではなく、将来的にそれがプラスになるかどうか、暗黙的に意思決定しているのだと思います。 

 では自分は何の為に仕事をしているのか。

こういった問いを自分にぶつけると、行動原理ともいえる自分の大元の意思決定のロジックが見えてきます。

①人生は一回どうせなら楽しみたい。

②人生の中で多くの時間をさく仕事は楽しみたい

③楽しくするために影響力をもってより貢献できる仕事がしたい

④能力が不足している自分がそれを望むなら足りないものを補っていく必要がある

⑤自分を成長させる働き方を選ぶ必要がある

 これはあくまで自身のケースで、皆さんに当てはまる事は少ないと思います。

しかしながら、自分の成長のさせ方、周りからの見え方に繋がるコンピテンシーとその土台となる行動原理について、少し立ち止まって考えてみてはいかがでしょうか。

IT部門長なら読んでおくべき一冊〜ITコストマネジメント〜

今回はコストマネジメントの話です。

どんな企業でも取り組んでいますが、うまく取り組めていると感じている企業は少ないのではないでしょうか。

部門長クラスの業務として定着していますが、業務の中で覚えたという方がほとんどで専門知識を学ばれていると感じる事は正直ないと感じるのが実態です。

最近多く出るテーマとして費用配賦についてです。

売上を上げる組織ではないので、事業体から費用を配賦する事でIT部門における予算を組んでいきますが、どの様に考えていいかわからず助けて欲しいと言った悩みにのったりします。

また、何をIT部門が管理すべきIT資産とするかという点も曖昧になるケースが多いと思います。

事業部門が契約しているクラウドサービスはIT資産となるのか。電話機などは総務管轄なのかなど線引きができず、結果として全社のIT資産を特定ができずITコストの可視化ができていないといった状況があります。

少し古い書籍ですが、IT資産の管理対象の考え方を学ぶ上で役に立った資料を紹介します。

IT投資とコストマネジメント

何をIT資産とすべきかという点や企業の成熟度に合わせてコストマネジメント実施レベルが記載されているため、その辺も参考になりました。

興味ある方はご一読いただければと思います。 

ITIL活用〜変更管理のプロセス設計その1〜

構成管理のプロセス設計の話を少ししましたが続いては、変更管理の話をしていきたいと思います。

変更管理とは、以下の様に定義されています。

「変更が素早く正確に、ITサービスのインパクトを最小限に抑えるために、定められたルールや手順を確実に行うプロセス」

ここでいう変更とは、顧客の事業上のニーズに応えたら、インシデントの根本原因を解決する為に構成情報に対するリソースの追加やアプリの改修などを示します。

ITILでは、変更の種類を大きく以下の三つに分類しています。

①標準的な変更

→低リスク高頻度で変更内容が定型化できる変更

②緊急の変更

→障害修正など緊急で対応すべき変更

③通常の変更

→標準的でも緊急でもなく運用上発生する変更

私はここに独自に以下を追加して設計しています。

④大規模な変更

→大規模な基盤刷新などプロジェクト化されて開発側で主管で管理する変更

④を追加しているのは、開発側主管で管理される大規模な変更も統合管理すべきとの想いからです。

プロセス設計の話に戻りますが、 まずは構成情報に対して発生しうる変更の洗い出しと分類となります。

これはのちに変更の種別ごとにプロセスフローや承認者を特定していく上での前提情報となります。

また、一覧に変更のユースケースを洗い出し、上記分類と現状のフローや承認者を洗い出していきます。

これらを類型化する事でITILプロセス導入とともに効率化を実現したり、ガバナンスの強化を図ったりします。

次の機会ではフローや承認者の考え方について話していければと思います。

IT部門長なら読んでおくべき一冊〜デジタル化時代のIT組織〜

以前デジタルトランスフォーメーションという書籍を紹介しましたが、同じくベイカレントコンサルティング社の著作となる以下の書籍を紹介します。

デジタル化を勝ち抜く新たなIT組織のつくり方

事業のデジタル化は、不可避なトレンドだと思います。その中で、IT組織の構造変革は既に始まっています。

しかしながら、取り組みを加速させている企業と全く意識できていない企業と大きな差を感じる状況にあります。

本書では、外部環境の変化をおさえたり、IT組織の目指すべき指針を探る上で一助となると思います。

IT組織の部門長や課長、リーダークラスの方に読んで頂きたいですね。

コンサルタントの仕事術〜合意形成こそ変革成功の鍵〜

このところIT部門のコンサルに入っていて、事業部の支援機能を強化する為に、組織変更案を策定といったコンサルティングを実施しておりました。

組織変更の概要としては、多角的な事業を展開する企業のIT部門で少人数で日々の業務を回していたので、兼務が進行していました。

結果として一つ一つの業務の把握が甘くなっていたため、事業部担当チームの設置とそれを実現するためのノンコア業務のソーシング活用とその準備などを実施してきました。

ようやく組織変更の目処がついてくると、次のステップとして、組織変更の詳細を如何に現場に伝えて理解を得るかという課題が挙がってきます。

組織として最適配置を考えると、必ずしも個々人の意見通りにはならない事は良くあります。そういった際に部門長はどう動くべきなのか。

正解はその段階で動くのではなく、方針策定時点での合意形成こそが重要です。

組織変更する際はその目的、目指すビジョンへの共感を部下から得る必要があります。

誰もが会社を悪くしたいとは考えてませんが、良くするために必要以上の事をしたいとも考えていないのが現状です。その考えを変革していくには常日頃からビジョンを語り合える状態を作る必要があります。

そして上が決めたビジョンではなく、皆で決めたという構図を予め作る事が重要です。その為、組織変更の際になって困らないように、方針策定時点での合意形成が重要となります。

合意形成から日が経つと忘れてしまう事があるので、必ず合意した内容は言質として資料化する事をお勧めします。記名で残しておくとなお良いと思います。

コンサルタントとしては、何手先を読んでその為の準備をしておけるか、この辺が成果に跳ね返ってくると思います。

変革を行う前には意識して見てはどうでしょうか。