戦略・モチベーション・コーチング

ここ数年「ココロ」の問題が様々な所でクローズアップされていますが、ＩＴ業界もしくはＩＴ関連の仕事に従事する人間にとっても非常に大きな問題であり、経営レベルで取り組む会社も多く出てきています。

「うつ」などのメンタルヘルスに関することは”医学”の領域なのですが、「どうもウチの組織の人間はモチベーションが低い」「新しいことをやろうとしてもメンバーの取り組みが甘い」といった類の話はコンサルティングの現場でもよくある話です。

最近行ったセミナーで印象に残ったことがあったのでそれについて触れてみたいと思います。

Ａ社：コーチングによって組織の活性化を図るという手法を展開している
Ｂ社：モチベーションというキーワードに注目して組織の活性化を図るという手法を展開している
Ｃ社：戦略コンサルティングファーム。戦略策定だけではなく、それを如何にして組織に落とし込むかということを提唱している

何が印象に残ったかというと、Ａ社・Ｂ社は「ヒトの内面・組織におけるコミュニケーション」といった所謂”ソフトアプローチ”の会社なのですが、Ｃ社はあくまで戦略ありきのハードアプローチ。

私もどちらかというと普段の仕事はハードアプローチ（戦略・制度・プロセス・体制など）で組織変革を行うという仕事なのですが、この場合の問題は「ヒトは理屈では動かない」ということ。

逆にソフトアプローチはヒトの内面（モチベーション）やヒトとヒトのコミュニケーションスタイルを変革（コーチングやファシリテーション）することで組織が自律的な取り組みを行えるようにしていくというアプローチ。この場合の問題は、「時間がかかる」「企業業績に対する相関関係が見えにくい」といった点にあるように思います。

どちらも一長一短ですが、何故か両方をうまく融合させようという話はどこにも見当たらない。

Ａ社（もしくはＢ社）とＣ社が連携すればもっと面白い話が展開出来るのにな〜と思いつつ、私自信もっとソフトアプローチの知見を深めてそのようなことが出来るようになれればなと感じました。

コスト削減かコスト最適化か

世の中コスト削減という言葉は仕事や洋の東西を問わずどこにでもあると思いますが、コスト最適化という言葉はあまり聞きません。

削減と最適化という言葉はＩＴコストというスコープでみるとまったく異なる意味を持ちます。

何が違うかを端的に言えばサービスレベルをどう考えるか・ＩＴの新規投資をどう考えるかの違いです。

ＩＴコスト削減はサービスレベルを下げてもよいとの前提にたってコスト削減が第一義的な目的としたものであるのに対して、ＩＴコスト最適化はサービスレベルとコストの最適なバランスを保つということになります。

他方、新規のＩＴ投資という視点でにおいて言えば、ＩＴコスト削減は「新規投資は基本的に凍結」であり、ＩＴコスト最適化は「投資対効果の評価をきっちりやる」ということになります。

どうしてもコストを削減しなくては企業の存亡に関わる、よほどの赤字になるといった状況でない限りはコスト最適化を行う企業が大半だと思いますが、この違いはきちんと認識しておく必要があります。

まあどちらにしてもまずは自分達のＩＴコストの「可視化」をきちんとやってからですけどね。

IT投資の評価手法―コストと効果を定量的に分析・管理する

ＩＴを活用したイノベーションとアウトソーシング

以前のエントリーでもちらっと紹介したが、モノ作りの世界では、「デザイン思考」を活用したイノベーションが注目されている。

「デザイン思考の道具箱」によると、

デザイン思考とは

自分が普通に暮らしている日曜世界を他者の目で眺め、新しいアイディアが思いついたらそれを表現する構成を考えて更に最終的なスタイルを決定する

と定義されている。これまでシックスシグマという問題解決の手法を活用して発展したきたＧＥも「ＣＥＮＣＯＲ」というデザインコンセプトを打ち出しているらしい。

ＣＥＮＣＯＲとは顧客が商品やサービスを利用している時の「物語」が提供出来ているかという考え方の商品・サービス開発手法らしい。

Calibrate：観測・観察（現場での顧客の観察）
Explore：探求（価値感の探求）
Create：仮説構築・デザイン（多くのプロトタイプとコンセプトと設計）
Organaize and Realize:市場での検証（なるべく多くの商品やサービスを出して市場の反応を見る）

又、イノベーションで有名なアメリカのデザインファーム（最近はイノベーションファームとも言えるらしい）ＩＤＥＯ社もおなじようなアプローチで数々の革新的な商品やサービスを産み出している。

ＩＴの世界においては、Ｗｅｂサイトデザインの世界では比較的活用されている考え方である。

これらの考え方に共通しているのは

・異能の協働（独創的な発想をたくさん出す）
・考える前にたくさん作る（プロトタイプ志向）
・顧客の声を聞くのではなく、顧客の価値感を取り込む
・商品やサービスを使う際の「物語」を作りこむ

といった辺り。簡単に言えば「Ｊｕｓｔ　Ｄｏ　Ｉｔ！」といったところだろうか。

ピンと来る方は来ると思うが、アジャイルなシステム開発手法にも非常に通じる所があるように思える。

アジャイルなシステム開発手法もそうだが、「企画するヒトと作るヒト」というのは基本的には一体化しているという点が重要なポイントで、ユーザー側もはっきりとニーズ（要件）が分からないような状況においてはこのようなアプローチは有効に機能するだろうということ。

ここまで来てようやくタイトルの話に入れるが、実際にアメリカでもアジャイル手法を取り入れてオフショアアウトソースを止めたという例もあるように、アウトソースを活用することは「コスト削減・効率化」にはとても寄与するが、「ＩＴを活用したイノベーション」を引き起こすためにはまったく別のアプローチが必要になるということ。

ユーザー企業には「ＩＴ企画人材」が必要だと言われて久しいが、私の感覚では「プロトタイプを自分で作れないＩＴ企画人材」の価値がどれだけあるのかはとても疑問である。

外部ベンダーに「下流工程」と称して仕事を出すのはよいが、「上流特化」なんて言っているといつまでたっても経営が求める「ＩＴを活用したイノベーション」にはたどりつかないのではないだろうか。

ペルソナ戦略―マーケティング、製品開発、デザインを顧客志向にする

発想する会社! ― 世界最高のデザイン・ファームIDEOに学ぶイノベーションの技法

年金新システムを分割発注

予想通りと言えば予想通りですが、社会保険庁が分割発注をしているそうです。

村瀬清司社保庁長官は今国会での審議で、「基本設計工程を５つに分割して調達を行う分割発注ということ。３月末に基本設計が完了した」と説明

ここまで来るとＮＴＴデータとの随意契約を続けるのは困難なのでしょうが、先日のエントリーでも書いたように、複数のベンダーを使うということはプロジェクト管理上の難易度は相当上がるため、システム開発のリスクも高くなっているわけです。

恐らく、外部から招聘しているＣＩＯ補佐官（及びＣＩＯ補佐官の会社のメンバー）が中心となってプロジェクト管理を推進していると推察しますが、「委託側も受託側も民間人」という状況でプロジェクトが失敗したら一体誰が責任とるんでしょうかね？

一方でＮＴＴデータは実費で不明な年金記録の照合システムを受注したとのことですが、これって見方を変えると「私達が悪いことをしてきました。今回は罪滅ぼしのために勉強させて頂きます」と言っているに等しいですね。ＮＴＴデータにとってこの対応が吉とでるのか更に泥沼にはまるきっかけになるのかは今後の注目です。

NTTデータと社会保険庁の関係

「契約書作らず年８００億円　社保庁、ＮＴＴデータに」

先日のゆうちょ銀行に引き続き、またＮＴＴデータがやり玉に挙がっています。

ＮＴＴデータと社会保険庁の”グレーな”関係がとり立たされたのは今回が初めてではないので、昨今の社会保険庁の不祥事のあおりをくらったというのが業界関係者の見方ではないでしょうか。

ＮＴＴデータはその売り上げの多くを公共セクターから得ており、今後同様の”グレー”な関係が他の官公庁でも批判される可能性があると思います。

ＮＴＴデータに同情するつもりはありませんが、所謂ＳＩ業界のＢＩＧ４であるＩ社、Ｆ社、Ｈ社も多かれ少なかれ似たような側面があり、ＮＴＴデータの人間は「何でウチだけ」と感じているかもしれません。

ＮＴＴデータだけが悪いのか

官公庁の情報システム調達に関する問題はここ数年様々な形でとりだたされ、官公庁の側もＢＩＧ４に過度に偏った調達を改めようという姿勢が「表向きには」感じられます。

というのも、現実的にはどれだけＢＩＧ４への依存をやめようとしても、これだけ巨大なシステムの面倒を見きるには相応の規模が無いと現実的には回らないからです。

仮に複数のベンダーに委託した場合（所謂マルチソーシング）でも、一社に委託するよりも発注者側の能力と体力が必要になってきます。今の官公庁側にそのような人間がどれだけいるのかというと、殆どいません。

最近ではＣＩＯ補佐官ということで外部の民間人を招聘して調達能力を向上しようとしていますが、ＣＩＯ補佐官を受託するとその官公庁のシステムを受託出来ないために、結果として「内情をよく知らない先生」のようになってしまっているのではないでしょうか。

結局、発注者側の能力・体力の無さが根本的な原因であり（勿論そこにつけこむＮＴＴデータは論外ですが）、一方的にどちらだけが悪いという問題ではありません。

民間も官公庁も同じ構図

発注者として素晴らしい能力を持っている企業もありますが、基本的には民間も官公庁も「発注者側の能力・体力の欠如」という点ではほぼ同じ構図にあると思います。（民間の方がコスト意識がある分、ぼったくられ度が低いですが・・）

それにしても、情報システムにこれだけ依存した社会になっており、そのトラブルが組織や社会に大きな影響を及ぼしていると共に、情報システムによって事業や業務を改革していく必要性が認識されているのにも関わらず、

ＩＴ人材の重要性に対する認識があまりにも低い！！！

ということで民間も官公庁もこの手の話は当分尽きないと思います。。。

オフショア会社に買われる日

日本企業でオフショアというと中国の会社が多いかと思いますが、先日あるインドのＩＴベンダーに関する調査報告を聞く機会があり、日本のＩＴベンダーがインドの会社に買収される日はそう遠くないのではないかと改めて感じました。

インドのＩＴベンダーは欧米企業を中心にオフショアを受託してきましたが、ここへ来て中国に対するライバル意識が相当あるようです。

というのも、欧米企業からのオフショアの成長率が鈍化しつつある中で、「新たな刈り取り場」を求めているからです。そのターゲットの１つとなっているのが日本。

勿論一部の先進企業もしくはグローバル企業は直接インドのＩＴベンダーを使ったりしていますが、まだまだ中国と比較すると色々な点で出遅れているというのが現状でしょう。

そんな中で、日本での営業基盤を手っ取り早く築くとしたらやはり日本のＩＴベンダーを買収して顧客基盤を引き継ぐこと。日本のＩＴベンダーは昨年辺りから好景気に沸いているので、今すぐということは無いかもしれませんが、次のＩＴ不況がくるＸ年後には中堅どころでインドの会社に買収されるところが出てくるのではないでしょうか。

ＣＯＢＩＴの使い方

J-SOX対応（ＩＴ統制）のフレームワークとしてCOBITもしくはCOBIT for SOXを参照している企業は多いかと思うが、日々のコンサルティングの中でCOBITを様々な局面で利用している身として、COBITの使い方についてちょっとまとめてみたいと思う。

何故COBITなのか？

細かい定義はさておき、ＩＴガバナンスもしくはＩＴマネジメントと呼ばれる活動において参照されるフレームワークとしては

• ＣＯＢＩＴ
• ＩＴＩＬ
• ＩＳＭＳ
• システム管理基準
• 情報セキュリティ管理基準
• ＦＩＳＣの安全対策基準　など

ざっと思いつくだけでもこれだけあります。J-SOX対応のみならず、ITガバナンス（マネジメント）を確立しようと考えている企業にとっては何を見れば「網羅性のある」ガバナンスが確立できるのかがよく分からないのではないでしょうか？

COBITを参照する利点は、ITILやISMSなど他のフレームワークを包含した所謂「アンブレラフレームワーク」である（≒網羅性がある）という点と「グローバルスタンダード」であるという２点に集約されるのではないでしょうか。

COBITと他のフレームワークの対応付けはCOBITの関連文書にも掲載されているので、その点ではCOBITを中心に他のフレームワークとの対比は比較的やり易いと思われます。

COBITの問題点

一方で、COBITにも幾つかの問題点があります。私が感じる一番大きな問題点は

「分かりにくい」

これにつきます。私のように日常的にITガバナンスの仕事をしている人間でも、全部の意味を理解するのには相当苦労しました。
これには２つの理由があるように思います。

１つは、アンブレラフレームワークであるが故に、ITILやISMSなどの前提知識がある程度必要になること。加えて複数のフレームワークをやや強引にまとめた感があるために、個々の統制項目の粒度がバラバラであったり一見同じようなことを別の所で言っているように見えたりします。

もう１つは、「日本語訳が分かり辛い」。日本語化に尽力頂いている方々には本当に頭が下がりますが、正直言って英語版と見比べながら読まないと書いてあることの意味を取り違えます。

もう１つ私が感じる問題点は、各プロセスの関連性が見えづらいため、実際にCOBITをベースに「業務手順書」のようなものを作ろうとしても何をインプットにしてそのアウトプットがどこに繋がるのかが分かり辛いということです。

一応、COBITにも各プロセス間の関係は記述されているのですが、あんな細かいものを理解しろというのは実質的には不可能。。。

更に言うと、欧米の労働環境やIT環境をバックグラウンドに書かれているため、日本の環境にはそぐわない点がいくつかあります。（例えば新規開発と運用・保守という日本的なやり方ではなく、開発とITサービスであったり、契約社員の扱い方など）

COBITをどう使うか

ありきたりですが、上記のような点をよく理解して、COBITをそのまま使うのではなく、COBITを「参照資料」としてうまく使い、自社なりのITガバナンス（マネジメント）の方法や手順を取りまとめていくということが重要だと思います。

色々問題点は書きましたが、COBITは、J-SOX対応に留まらないスコープでITガバナンスの向上を目指すには今の所一番網羅性があって使えるのではないでしょうか。ただ気になるのはITILのバージョン３はこれまでよりも更に広い範囲をスコープにしているようなので、ITILの動向にはきちんと目を向けておきつつ、必要があれば自社で作成したものに付加していくというスタンスでよいのではないでしょうか。

図解 これならできるIT統制

図解入門ビジネス最新ITILがよ~くわかる本 (How‐nual visual Guide Book)