»いきなりコンサルタントに抜擢されたSEが読むべき4冊目このエントリは、「いきなりコンサルタントに抜擢されたSEが読むべき3冊」[参照]の続きになる。いった、それでメシ喰っている連中のことだ。書いたが、仕事の順序というか、ダンドリの要領よさについては常々不思議に思っていた。「俺たちに明日はない」という言葉がピッタリの猪突猛進なのだが、仕事のやり方は整然粛々としている。見た目のロジカルさだけでなく、コンサルティングの仕事そのものが、あたかも何かのマニュアルに従っているかのような感じがしてならなかった。その予感はあたってた。マニュアルを見つけたんだ。それは、「情報システム計画の立て方・活かし方」。いや、その辺に転がっている教科書的な奴じゃない。構造化→課題の抽出→打ち手の導出)なんて、そこらに落ちてるでしょ。本にしてもありがたがるのは新人だけだろうし。本書は網羅性や一覧性で読んでもらうつもりではない。文字+成果物だけで、どちらかというと無味乾燥。ところがこれは、コンサルタントの種明かしなんだ。本書はズバリ、以下を目的とした調査・分析・資料づくりの方法が書いてある。「方法」というよりも、ひとつのプロジェクトの一連の仕事が克明に書いてある。最初の「計画の立て方」なんて、社内リポジトリをさらえばフォームがいくらでも出てくるだろう。絵にして、スケジュールと予算と構成図と体制表をちょいちょいと書けば、ハイ、一丁あがり!ところがそれじゃダメなんだ。「計画を立てる」ことは、フォームを埋めることではないんだ。経営者はそれじゃ動かない。システムにカネを使うのがイヤだから、なんじゃない。システム改善施策のそれぞれが、業務運用をどう良くするのか、グランドデザインのどこにどう効くのか、ひいては経営目標にどの程度寄与するのか、それぞれのリスクと実現時期と代替案は...これらの疑問にロジカルかつ数字つきで答えられない限り、ウンと言わない。そんな「システム計画」があるのだろうか?ある。具体的に述べられている。連中の「動き」が、まさにこれに則ってやっていることに気づいたから。本書は今は亡きアンダーセン出身の気鋭が著したものだが、コンサルティングのダンドリは一緒。ぶっちゃけはっちゃけ、彼らのカンペ。読めばフルフル震えるはず、怒りで。「システム計画」を策定する際の、スケジュール・予算・リソース・リスクがどんな風に決められているかを知ると(ヒント:計画が認可され、システム開発が始まる頃、彼らの契約は終わる)。読むとナルヘソと思うはず、経営者をどんな風にコマすのかを知って。その極意はオンナと一緒。人は自分の台詞で口説かれるのが好き。落とす相手の言葉でもって攻める。経営者が出す「目標」を計画の隅々までロジカルに展開させ、一方で、展開された枝葉が「目標」を支えているかのごとく描く。自分のセリフが美しく精緻な計画表になって、立て板トウトウとプレゼンされたら、そりゃ落ちるってば。経営者であれ意志決定者であれ、彼らはコンサルタントの話を聞きたいんじゃない。自分の考えを、話して欲しいんだ。自分の考えを、コンサルタントの口から聞くとき、はじめて経営者は耳を傾けるようになるんだ。この極意、言葉にすると非常に簡単なんだが、こいつをシステム戦略計画の隅々まで行き渡らせる方法は、非常に泥臭く、しんどい。極意は本書のどこにも書いていないが、極意を実現する方法ならいっぱい詰まっている。目次を転記しておく、お悩みの方は、お試しあれ。企画した効果を出すために...あ、ひとつ忘れてた。4章と5章との間に「なぜシステム化か?」の疑問に答えるための理論武装が必要なんだが、意図的に(?)書いていない。こいつまで明かしちゃうと喰いっぱぐれるかもしれないからか。やってみればロジックの飛躍に気づくので、自分で埋めておくこと。»コメントDainさん、はじめまして。「情報システム計画の立て方・活かし方」の著者の柴崎です。このたびは、拙著をご紹介いただきありがとうございました。(Dainさんに紹介いただいてから反響の大きさに驚いております。さんはい、売れてます。「コンサルタントのタネ明かし」が効いているようです。最初に読んだときは「ここまで手の内をバラして良いものだろうか?」と思ったものです。考えてみると、読んだだけでは身につかず、実践を伴ってはじめて理解できるものなんだなぁ...と合点がゆくようになりました。いわゆるプログラミングや開発手法を紹介することと一緒ですね。23:28Dainさんおはようございます。書評やコメントを拝見すると、Dainさんはこの領域の経験が相当おありのようですね。なんとなくですが、この領域のコンサルティングについて同じような問題認識をもたれているのではないかというように感じます。企業のビジネス改革(改善)という同じ目標をもって仕事をしている経営者、クライアント企業の関係者、システムベンダー、経営コンサルタントの4者は、目標は同じでも役割が違うために、実現方法や進め方に対する考え方がバラバラなことが多く、そのことが目標達成の大きな阻害要因になっているように感じます。「どのような体制、スケジュール、検討内容でプロジェクトを進めれば期待する結果が出せるのか」について4者で共通認識を持ちたい。その上で役割分担し取り組みを進めたい。そのためには、4者が共通の具体的イメージをまず共有化し、その上で各企業の状況に合わせて進め方を見直し、一番いい結果が得られると思われる方法を4者で合意できることが理想です。システム化の優先順位決めなどの検討について現行システムの状況やシステム構築面からみた検討が薄いと感じられていると思います。そこが重要で、その薄さについて社内情報システム部門が指摘し、この段階からシステムベンダーさんに参画いただき、その部分の調査、検討を行なった上で結論を出すという認識に立ちたいわけです。この作業を従来企画書などで説明を行なっていたのですが、具体的なイメージを持って理解いただき、後の作業に反映させることは至難の業でした。何とか具体的イメージをもっていただくための「検討サンプル/たたき台」を作りたいと思い本書を記載しました。企画書よりは「まし」にはなりましたが、Dainさんのおっしゃるとおり「やってみなければわからない」部分も多く、まだまだ課題は多いと感じています。このあたりのことがもう少しうまくできるようになれば、コンサルタント嫌いのSEさんも減ると思いますし、プロジェクトの成果としてもいい結果がだせるのではないかと思っています。(SE、コンサルタントの両方の立場を経験している身としてそう思っています)また進め方の共通認識ができたとしても、「各項目を具体的にどう検討し結論づけるか」というもう一段高い壁がありますね。コンサルタントとしては、そこで価値を出したいものだと常々思っております。一時期、コンサルティング・ファームのお手伝いをしたことがあるだけで、コンサルタントとの仕事の交点はほとんどありません。企画書の残骸や焼け野原の後片付けは幾度もありますが、後姿どころか、名前すら聞かされないのが常です。そのため、「コンサルタント」、特に"IT"が冠に付く人は敬遠しています。ファームの中の人の言葉ですが、本質を言い当てていると思います。ところが、柴崎さんのコメントを読むと、それ以上の視線を感じます。たしかに、経営者の意思決定を促すためのメソッドとして貴書を著したのかもしれません。目指している志の高さはスゴいと思います。3.の間に立って引き裂かれながら調整するのがわたしの仕事の一つでもあるからです。わたしの現場には、柴崎さんのような、志の高い、強い人がいないのでしょう...(自称コンサルタントは、たんと居ますが)ともあれ、現実の壁にぶつかるときは必ずあります。それは、ご指摘の通り「各項目を具体的にどう検討し結論づけるか」が議論になったときでしょう。ついて、先出の「ファーム」の中の人が興味深いことを言っていました。最初から決めておくのがコツ。考えさせたら紛糾するだけ」とのこと(おおー)。コンサルタントとSEの関係は、以前のエントリが参考になるかもしれません。考察の一助となれば幸いです。この程度のことは、知っておこうってことらしい。環境変数やレジスタ、ヒープなど。プログラマの常識程度ならだいたい知ってるんだけど。答えが見つからないときは、問題を変えてみよう。(哲学はなぜ間違うのか)本は読まなくても書評を書くことはできる。