« IT失敗学の研究 | トップページ | 「欺術」――ヒューマン・ハッキング・クックブック »

いきなりコンサルタントに抜擢されたSEが読むべき4冊目

 このエントリは、「いきなりコンサルタントに抜擢されたSEが読むべき3冊」[参照]の続きになる。
情報システム計画の立て方
 「コンサルタント」と一緒に仕事をしたことがあるだろうか? 肩書だけのなんちゃって自称コンサルではなく、McKinsey & Company や accenture といった、それでメシ喰っている連中のことだ。

 彼らの阿呆ほどの猛仕事ぶりは、「マッキンゼーITの本質」[参照] に書いたが、仕事の順序というか、ダンドリの要領よさについては常々不思議に思っていた。「俺たちに明日はない」という言葉がピッタリの猪突猛進なのだが、仕事のやり方は整然粛々としている。見た目のロジカルさだけでなく、コンサルティングの仕事そのものが、あたかも何かのマニュアルに従っているかのような感じがしてならなかった。

 その予感はあたってた。マニュアルを見つけたんだ。それは、「情報システム計画の立て方・活かし方」。いや、その辺に転がっている教科書的な奴じゃない。だって、いわゆる問題解決の技法(現状把握→要因分析→問題の構造化→課題の抽出→打ち手の導出)なんて、そこらに落ちてるでしょ。本にしてもありがたがるのは新人だけだろうし。本書は網羅性や一覧性で読んでもらうつもりではない。文字+成果物だけで、どちらかというと無味乾燥。

 ところがこれは、コンサルタントの種明かしなんだ。本書はズバリ、以下を目的とした調査・分析・資料づくりの方法が書いてある。「方法」というよりも、ひとつのプロジェクトの一連の仕事が克明に書いてある。

    1) 情報システム計画を立てる
    2) それを経営者(意思決定者)に納得させる

 重要なのは 2) 。最初の「計画の立て方」なんて、社内リポジトリをさらえばフォームがいくらでも出てくるだろう。asIs と toBe を絵にして、スケジュールと予算と構成図と体制表をちょいちょいと書けば、ハイ、一丁あがり!

 ところがそれじゃダメなんだ。「計画を立てる」ことは、フォームを埋めることではないんだ。経営者はそれじゃ動かない。システムにカネを使うのがイヤだから、なんじゃない。システム改善施策のそれぞれが、業務運用をどう良くするのか、グランドデザインのどこにどう効くのか、ひいては経営目標にどの程度寄与するのか、それぞれのリスクと実現時期と代替案は…これらの疑問にロジカルかつ数字つきで答えられない限り、ウンと言わない。

 そんな「システム計画」があるのだろうか?

 ある。それが本書。経営目標からトップダウンで作成する作り方 KnowHow が具体的に述べられている。わたしがコレダ!と思ったのは、McKinsey の連中の「動き」が、まさにこれに則ってやっていることに気づいたから。本書は今は亡きアンダーセン出身の気鋭が著したものだが、コンサルティングのダンドリは一緒。

 ぶっちゃけはっちゃけ、彼らのカンペ。

 だから、読めばフルフル震えるはず、怒りで。「システム計画」を策定する際の、スケジュール・予算・リソース・リスクがどんな風に決められているかを知ると(ヒント:計画が認可され、システム開発が始まる頃、彼らの契約は終わる)。

 あるいは、読むとナルヘソと思うはず、経営者をどんな風にコマすのかを知って。その極意はオンナと一緒。人は自分の台詞で口説かれるのが好き。だから、落とす相手の言葉でもって攻める。経営者が出す「目標」を計画の隅々までロジカルに展開させ、一方で、展開された枝葉が「目標」を支えているかのごとく描く。自分のセリフが美しく精緻な計画表になって、立て板トウトウとプレゼンされたら、そりゃ落ちるってば。

 経営者であれ意志決定者であれ、彼らはコンサルタントの話を聞きたいんじゃない。自分の考えを、話して欲しいんだ。自分の考えを、コンサルタントの口から聞くとき、はじめて経営者は耳を傾けるようになるんだ

 この極意、言葉にすると非常に簡単なんだが、こいつをシステム戦略計画の隅々まで行き渡らせる方法は、非常に泥臭く、しんどい。極意は本書のどこにも書いていないが、極意を実現する方法ならいっぱい詰まっている。

 目次を転記しておく、お悩みの方は、お試しあれ。

  序章 経営計画の実現を約束する
  第1章 戦略的システム化計画のすすめ
  第2章 戦略的システム化計画の全体像
  第3章 フェーズ1 経営計画マップの作成
  第4章 フェーズ2 重点施策の整理
  第5章 フェーズ3 情報システム要件の立案
  第6章 フェーズ4 情報システム構成の立案
  第7章 フェーズ5 全体推進計画の立案
  第8章 フェーズ6 経営者向け説明資料の作成
  第9章 企画した効果を出すために

 …あ、ひとつ忘れてた。4章と5章との間に「なぜシステム化か?」の疑問に答えるための理論武装が必要なんだが、意図的に(?)書いていない。こいつまで明かしちゃうと喰いっぱぐれるかもしれないからか。やってみればロジックの飛躍に気づくので、自分で埋めておくこと。

|

« IT失敗学の研究 | トップページ | 「欺術」――ヒューマン・ハッキング・クックブック »

コメント

Dainさん、はじめまして。「情報システム計画の立て方・活かし方」の著者の柴崎です。このたびは、拙著をご紹介いただきありがとうございました。

(Dainさんに紹介いただいてから反響の大きさに驚いております。)

投稿: shibasaki | 2006.06.12 22:49

>> shibasaki さん

 はい、売れてます。「コンサルタントのタネ明かし」が効いているようです。最初に読んだときは「ここまで手の内をバラして良いものだろうか?」と思ったものです。しかし、よく考えてみると、読んだだけでは身につかず、実践を伴ってはじめて理解できるものなんだなぁ…と合点がゆくようになりました。

 いわゆるプログラミングや開発手法を紹介することと一緒ですね。

投稿: Dain | 2006.06.12 23:28

Dainさんおはようございます。柴崎です。

書評やコメントを拝見すると、Dainさんはこの領域の経験が相当おありのようですね。また、なんとなくですが、この領域のコンサルティングについて同じような問題認識をもたれているのではないかというように感じます。

企業のビジネス改革(改善)という同じ目標をもって仕事をしている経営者、クライアント企業の関係者、システムベンダー、経営コンサルタントの4者は、目標は同じでも役割が違うために、実現方法や進め方に対する考え方がバラバラなことが多く、そのことが目標達成の大きな阻害要因になっているように感じます。

「どのような体制、スケジュール、検討内容でプロジェクトを進めれば期待する結果が出せるのか」について4者で共通認識を持ちたい。その上で役割分担し取り組みを進めたい。そのためには、4者が共通の具体的イメージをまず共有化し、その上で各企業の状況に合わせて進め方を見直し、一番いい結果が得られると思われる方法を4者で合意できることが理想です。

例えば、システム化の優先順位決めなどの検討について現行システムの状況やシステム構築面からみた検討が薄いと感じられていると思います。そこが重要で、その薄さについて社内情報システム部門が指摘し、この段階からシステムベンダーさんに参画いただき、その部分の調査、検討を行なった上で結論を出すという認識に立ちたいわけです。

この作業を従来企画書などで説明を行なっていたのですが、具体的なイメージを持って理解いただき、後の作業に反映させることは至難の業でした。何とか具体的イメージをもっていただくための「検討サンプル/たたき台」を作りたいと思い本書を記載しました。

企画書よりは「まし」にはなりましたが、Dainさんのおっしゃるとおり「やってみなければわからない」部分も多く、まだまだ課題は多いと感じています。このあたりのことがもう少しうまくできるようになれば、コンサルタント嫌いのSEさんも減ると思いますし、プロジェクトの成果としてもいい結果がだせるのではないかと思っています。(SE、コンサルタントの両方の立場を経験している身としてそう思っています)

また進め方の共通認識ができたとしても、「各項目を具体的にどう検討し結論づけるか」というもう一段高い壁がありますね。コンサルタントとしては、そこで価値を出したいものだと常々思っております。

投稿: shibasaki | 2006.06.14 06:58

>> shibasaki さん

 わたしはしがないSI 屋です。一時期、コンサルティング・ファームのお手伝いをしたことがあるだけで、コンサルタントとの仕事の交点はほとんどありません。企画書の残骸や焼け野原の後片付けは幾度もありますが、後姿どころか、名前すら聞かされないのが常です。

 そのため、「コンサルタント」、特に"IT"が冠に付く人は敬遠しています。「経営者は自分の考えにロジカルな『根拠』が欲しいだけだ、コンサルティングとはそのための膨大な作業の積み上げに過ぎない」… ファームの中の人の言葉ですが、本質を言い当てていると思います。

 ところが、柴崎さんのコメントを読むと、それ以上の視線を感じます。たしかに、経営者の意思決定を促すためのメソッドとして貴書を著したのかもしれません。しかし、柴崎さんの視座は、そこだけに留まらず、

  1. 経営者
  2. クライアント企業の関係者
  3. システムベンダー
  4. 経営コンサルタント

 四者の win-win-win-win を目指している志の高さはスゴいと思います。また、システム化の優先順位の決め方で四者の振り付けについて、明確なイメージを描いている時点で、強い立場にいる人だなぁ、と感じます… というのも、2. や 3.の間に立って引き裂かれながら調整するのがわたしの仕事の一つでもあるからです。おそらく、わたしの現場には、柴崎さんのような、志の高い、強い人がいないのでしょう…(自称コンサルタントは、たんと居ますが)

 ともあれ、現実の壁にぶつかるときは必ずあります。それは、ご指摘の通り「各項目を具体的にどう検討し結論づけるか」が議論になったときでしょう。例えばKPI について、先出の「ファーム」の中の人が興味深いことを言っていました。「KPI は最初から決めておくのがコツ。考えさせたら紛糾するだけ」とのこと(おおー)。

 コンサルタントとSEの関係は、以前のエントリが参考になるかもしれません。考察の一助となれば幸いです。
http://dain.cocolog-nifty.com/myblog/2005/09/se_6eec.html

投稿: Dain | 2006.06.15 00:58

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/18285/10395067

この記事へのトラックバック一覧です: いきなりコンサルタントに抜擢されたSEが読むべき4冊目:

» メモ [PukiWiki Plus! (PukiWiki/TrackBack 0.3)]
PC(?) 16進を知らない子供達へ この程度のことは、知っておこうってことらしい。環境変数やレジスタ、ヒープなど。プログラマの常識程度ならだいたい知ってるんだけど。(低レベル処理が多いな) Java技術最前線:ITpro 最近のJava知らないけど、結構変わってきてるみた... [続きを読む]

受信: 2006.06.07 13:41

« IT失敗学の研究 | トップページ | 「欺術」――ヒューマン・ハッキング・クックブック »