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

　この記事のまとめ。また長文エントリごめん。“IT”コンサルじゃない、「ファーム」のコンサルタントと一緒に仕事をするハメになったら読む本。

1. 「問題解決プロフェッショナル」を読めば、コンサルタントの土俵で話ができる
2. SEとしての分をわきまえるなら「RFP＆提案書作成マニュアル」で準備しておく
3. SEには、コンサルタントに無い視座がある。その強みを生かす「業務システムのための上流工程入門」

　コンサルタントは、知識経験ないけれどキャラとハートがおおまかカバーすることはぶっちゃけありえない。そうなったらどうしようと思い悩む前にメモをどうぞ。

------------------------------------------

　このblogは「それを知らなかった私にとって有益なもの」になるように心がけてる。つまり、その記事の知識・情報を知らなかったとして、「あ、こんな記事を見つけてラッキー」と思えるようなネタ。

　で、この記事は一年前の私が見つけたなら「お、タイムリー」と思えるような内容　→　いきなり「来週から客先でコンサルタントとして働いてもらう」と断固かつ容赦なく言われたとき、来週までに読んでおきたい3冊を挙げた。

　工程を上流下流と分けるのはヘンなのだが、その言葉を使うなら水源地というか震源地。結果システム化したりするが、システムありきではない。CIOや経営層を巻き込み、そもそもそこにカネをかけようとする動機付けがミッションで、要求仕様を決める前の段階。海のものとも山のものともつかない状態。

　だから、“IT”冠のなんちゃってコンサルタントではなく、McKinsey & Company のようなガチガチのファームを想定してほしい。彼らは切れ者で、おそらくあなたよりも学歴も収入も上だ。ディベートが得意で屁理屈も理屈だと言い切る。

　そういう連中と伍する（というよりもついていく）ために必要な知識があるのよ。知らないと会話を成立させることすら困難。もちろん連中は丁寧に教えてくれるはずはないし、そもそも「来週コンサルタントになれ」なんて言う上司は、そんな知識が必要であるということすら知らない。

------------------------------------------

　1冊目、「問題解決プロフェッショナル」、四の五の言わず読め、と断言できる。なんちゃってMECEやなんとなくHOWツリーを二度と書かなくなる。「コンサルの仕事は正解がない」と言われるが、それは「どんな解でも正しい」ではないし、「解が存在しない」という意味でもない。問題への銀の弾丸なんて無い、という意味。

　問題に対し有効な解決策を導き出せ、優先すべき打ち手を論理的に導出することができる（←これがミソ）。ファームの連中が口だけ野郎ばかりだとしても、その論理には一点の曇りもない。これはスゴいことだ。口だけ星人はマネしなくてもいいが、この思考方式は大いに盗むべし。

　第1章　　2つの思考→「ゼロベース思考」「仮説思考」
　第2章　　2つの技術→「MECE」「ロジックツリー」
　第3章　　1つのプロセス→「ソリューション・システム」

　時間がないなら、2章だけでも繰り返し読むべし。ロジックツリーは全ての基本。その進化形「HOWツリー」が分かったときはちょっと感動できるかも。昔、「UMLモデリングのエッセンス」を繰り返し読んで書いて、UMLで何が見えるようになるのか（何を書かなくてはいけないのか）に気付いたときと同じ感動を味わった。

　具体例で「痩せるために何をするべきか」のHowツリーが挙げられている。馴染みやすく分かりやすいのだが、キレイにまとまりすぎている。最初からこんなにまとまって書けない。もっと何度も書いては直しの繰り返しで出来てくる。紙数の関係上、数度のレビューで完成しているが、本当はスクラップ＆ビルドの繰り返しが必要。

　「MECE」「ロジックツリー」は記法だけ学んでも無意味。UMLと一緒。どう使われるか、何を見えるようにするか、を念頭において、読むべし！そして、読むだけでは身につかない、実際に手を動かして、書くべし（ここもUMLと一緒だね）。

------------------------------------------

　2冊目。コンサルタントの肩書きを背負ったSEが求められるものは何か？それは「受注へつなげ！仕事獲ってこい！」に尽きる。経営層まで食い込めば高確率でポケモソゲットだぜ！従ってカッコつき『コンサルタント』の成果はRFP。

　これがファームのコンサルタントだと、「業務改革アクションプラン」と銘打った分厚な資料を作りたがる。しかし、SEとしては分を守るべきだろう。経営者が力を込めなければ動かない“アクション”プランよりも、予算さえ獲得できれば得意分野になる田んぼへ引水すべき。

　端的にいうなら、「このRFPならウチがNo.1の名乗りをあげられる」というやつ。

　いや、故意にそうせよ、誘導せよというわけではない（それやったら反則）…んが、規定・契約に触れない範囲でのRFP執筆は許される（と信じる、でないと泣く）。というわけで、RFPの究極の一冊はコレ→「RFP＆提案書作成マニュアル」。なぜ究極かというと、RFPを出す側と受ける側、即ち発注と受注の両方の視点から書いてあるから。例えはアレだけど、セックスのハウツー本に雄サイドと雌サイドの両方が書いてあるようなもの。

　この本を読むと、「良いRFPは良いプロジェクトにつながる」という著者の信念が伝わってくる。言い換えると、酷いプロジェクトはデタラメなRFPから始まっている。だから、発注者も受注者もお互いの手の内を充分に知り尽くした上で、仕事の土俵に臨め、という理屈。

　目からウロコを以下に挙げる。あるいは、自分がいかに無知だったかの恥さらし。

• ユーザ研修費用、マニュアル作成費用は、見落とされがちだが、無料ではない
  
• ベンダーとしての自社だけでなく、ユーザ側のプロジェクト体制表を記載する
  
• プロジェクト完了日だけでなく、プロジェクト開始日も明記する

　な、なんだってー！ΩΩΩ

　いつもリリース直前になって「ごめん、たのむ」の二言で突貫してた「サービス」が有料オプションだったなんてorz …ま、費用の形で見せる/見せないはおいといて、エラい人がソロバンを弾いていることを祈るのみ。また、ユーザ側の体制がハッキリしていれば、責任者が曖昧なため仕様も曖昧に決まってしまうリスクも免れる。さらに、プロジェクト開始を先送りする（でも尻は不動）ことで工数をケチる悲劇に全米が泣いた、なんてこともなくなるだろう。

　ダメプロジェクトの芽はRFP・提案書にあることが、まざまざと見せ付けられる一冊。

------------------------------------------

　3冊目の紹介の前に、コンサルティングのお仕事についての「違和感」を吐き出してみる。

　この仕事はハードだがものすごく面白い。ロジックを組み立てたり、プレゼンテーションしたり、論理の土俵でやり込めたりするのは、これまでの仕事と違って脳が面白く働いてくれる。わたしが考え抜いたロジックを、偉い人がさも自論のように吹聴しだすのを耳にすると、かなり爽快な気分になれる。

　しかし、慣れてきてからずっとある「違和感」に付きまとわれている。その違和感はこういう疑問でやってくる→「本当にこれでいいのか？」。何か大事なものが足りないような、考える基盤から抜けているような違和感。

　それは「データ」だということに気付いた。

　ぶっちゃけ、コンサルの提案なんて、3つしかない。無くすか、替えるか、効率を上げるかだ。どんなに飾って理論武装しててもこの3つから出ない。違和感を感じているのはその対象だ。連中はプロセスにのみ着眼し、そのプロセスを無くすか、替えるか、効率を上げるかしか考えない。そのプロセスがどんな「データ」を扱っているかは考慮しない。

　プログラミングをするとき、引数や参照に気を配る理由は、データを加工してアウトプットを出すことがプロセスの本質だと理解しているから。つまり、データの受渡し・参照のやり方如何によっては、性能がものすごく変わってくることを理解しているからこそ、データの扱い方に気を使うのが“自然”になる。

　プロセスだけではなく、そいつが扱うデータもセットで考えるのがあたりまえの世界で仕事をしてきた。そのためプロセスだけをどうこうすることで結果を出そうとすることは、半分どころか本質ですらないような気がする。例えばこうだ。

　　　「ボクの書いたプログラムが遅いんです」

　　　『それなら簡単、次の3つ打ち手が有効だ、即ち

　　　　　　1. そのプログラムを消す（コメントアウトする）

　　　　　　2. もっと優秀なプログラマに書いてもらう

　　　　　　3. もっと速いCPUでそのプログラムを動かす

　　　以上だ』

　ふ　ざ　け　ん　な　、といいたくなるが、コンサルの本質はこんなもの。

　ありがちな「遅い」理由は入出力のとこか演算対象のデータの扱い方がまずいかだろう。どちらもデータ（情報）を扱っているところだ。コンサルタントはそこに踏み込まずに表層を議論しているような気がしてならない。

　なぜか。答えは簡単。踏み込むためにはその世界を知る必要があるから。参照呼出しなのか値呼び出しなのか（なぜそれにしたのか）、おかしな変数を宣言してないか、妥当な演算子なのか… 実装はjavaだから、Cなら…　といった、「中身」に踏み込んだ分析が必要で、そのためには文字通り「言語」を身につける必要がある。

　しかし、コンサルタントはそんな暇はない。速くするために、「はじめてのC」（えっちなタイトルだが名著）を読むことなんてしない。無くすか、替えるか、性能を上げるかしか考えない。

　コンサルタントは、プロセスばかりに着目しており、プロセスが扱っている「データ」は軽視しているか、無視している。プロセスはチェーンという絵にしやすい。プロセスラインを集めたり組替えたり、まるでレゴのブロックのように扱える（ように見える）。あたりまえだ、その絵にはプロセスが扱う「データ」が描かれていないのだから。

　コンサルタントの言う「データ」とは、業務量、生産性、リソース、リードタイムといった、現場を定量的に表現する数値のことであって、現場の人々が扱っているデータではない。コンサルタントは現場の人々が扱うデータを見ようとすらしない。

------------------------------------------

　そこで3冊目。SEやってるヒトならあたりまえなのかもしれないが、「業務システムのための上流工程入門」を読むと、業務分析をデータ中心に進めている態度に非常に共感を抱く。

　なぜか。

　それは、プロセスなんて、コロコロ変わる（変えられる）ものであり、ひょっとすると「ヒトが違うので別のやり方」が存在することを知っているから。そんな不確かな業務フローを詳細に追求する前に、そのインプットとアウトプットをきっちりと押さえにかかるから。データとプロセスを分離し、プロセスを「そのデータをどう扱うのが正解か？」という観点から再定義しているから。

　その結果、次のような悩み（?）にぶち当たったことがあるだろう。本書より引用する。

　「シンプルすぎるデータ構造」は「複雑すぎるデータ処理」を要求します。どうもデータベースシステムには「複雑さの保存則」のようなものがあって、何かをシンプルにすまそうとすれば別の何かが複雑化してしまうようなのです。どうせ何かが複雑になることが避けられないのであれば、「お金がかからない部分」を複雑にすべきです。ソフトウェア開発においては、プログラミングにいちばんコストがかかることを考えると、テーブル構成をシンプルにするという戦略は的外れです。

　たいていのシンプルさのトレードオフは、石（CPU）を替えたりメモリを積んだりする前に、正規化やインデックスキーの張りなおしでなんとかしようとするはず。データ構造設計がきちんとなされていれば、プログラミングで処理性能をなんとかするハメには陥らない（はず）。

　しかし、コンサルタントが提案していることは、データ構造に目を向けずに、プログラムを消したり替えたり、メモリを積んだりして、性能を上げようとしていることと同じ。それらの打ち手によって、一時的にプログラムの速度が上がったように見ても、本質的な部分（＝データ構造）がそのままなので、データの増加、リクエストの増加により簡単にに遅くなるだろう。

　レゴのブロックのように組替可能に見えた「プロセス」が、その本質（データ）が見落とされたまま簡略化され、代替されると、どうなるか。一過的に生産性が上がるかもしれないが、続かない。すぐにシワ寄せがくるだろう。どんなシワ? それは、省略されたプロセスが担っていた「データの加工・蓄積」というシワ。

　コンサルタントのご宣託どおり業務プロセスをカイゼンしても、一時的な効果にすぎない原因はここにある。コンサルタントは間違っていない。コンサルティング方法論を正しく適用した打ち手だから。ただ、正しい打ち手を間違った部分に施しているだけなんだ。この事実はコンサルタントは気づかない（というより、認識できない）。なぜなら、コンサルタントはそういう泥臭いデータの扱いに悩んだことがないし、これからも踏み込むことがないから。

　最後に。コンサルタントに「抜擢」と書いたが、わたしの場合は「テメェは現場では使えねェから、客の使いッ走りでもやってな！」と脳内変換して切歯扼腕してる。コンサルティングは非常に面白いが、コンサルタントは大嫌い。

　捲土重来を期して。がんばれオレ、もっとがんばれ。

嫁とするギャルゲー、おすすめありますか？

　適当なものを物色しているのだが、いろいろありすぎてよく分からない。ジャンルも多岐に分かれ、「萌え」「監禁陵辱」「鬼畜」「泣きゲー」「セカイ系」などなど… 百花繚乱というのだろうか、そのコーナーは赤やピンクが入り乱れて、遠目からだとお花畑のようだ。

　昔は「美少女アドベンチャー」というジャンルだけだった。まず物語がしっかりしたゲームがあって、キャラが美少女というやつ。Hシーンはごほうび的にあるだけで、無くてもゲームとして成り立っていた。

　ポイントは二つ。

嫁といっしょにプレイ

　ギャルゲといえば独り閉じこもってしこしこプレイするもの、というイメージがあるが、その手の色濃いものは遠慮しとく。嫁と二人でああだこうだと言いながら試行錯誤して話を進めていくことが目的。つまり、オカズ系は不可。

　カップルで映画を見てて、濡れ場に出くわすとちょっと気まずい思いをするかもしれない。けど話の上で仕方ないか、という感覚。例えばターミネーター（最初の奴ね）とか。

“ゲーム”であること

　いわゆる「ビジュアルノベル」なら沢山ある。ボタンを押すだけ＋選択肢はシナリオルートのためだけにあるといった作品で、これも独りでしこしこ読むならいいかもしれない…が、“ゲーム”性は少ない。つまり、「正解」のシナリオがあり、そこへ行き着くためには推理や想像を働かせる必要がある“ゲーム”であることが必要。

　じゃぁ女の子が出てこなくてもいいじゃん、というツッコミもある。確かにそうだ。しかし、物語性に優れたやつは、たいてい男女の情愛がからむもの。良いストーリーはどこかでラブストーリーになっている。

　嫁とプレイしたベスト3はコレ。ずいぶん古いが参考になればと。

　1.　この世の果てで恋を唄う少女YU-NO
　2.　DESIRE
　3.　EVE burst error

　念のため追記→鬼畜不可。間違っても「隠しカメラでつかんだ弱みをモトに寮生を脅迫する管理人の話」とか「看護婦をとっかえひっかえ陵辱しているうちに復讐される医師の話」とかダメよん。

　この質問、はてなでも訊いてみよう[参照]。

--------------
2005/11/17追記

■■　「はてな」で回答されなかったオススメ　　■■

質問ってしてみるものだね、知らなかったものがつぶやきと共に聞えてくる。

　まずは、hiroki_yaさんのご紹介→並列世界。ありがたいのは、この記事に込めたメッセージを読み取ってくださったところ。実をいうと、この私の記事はツッコミどころ満載で、特に「嫁とプレイしたベスト3」に込めたネタ（剣乃ゆきひろ作品）を分かった上でオススメしてくれたのはありがたや。

　　『ひとかた』
　　『久遠の絆 再臨詔』
　　『時の故郷』
　　『ひぐらしのなく頃に』

　…嫁と一緒に「ひぐらし」やったらどういう結果になるか怖すぎる。

　次はまなめさん[参照]。「最近のゲームは本を読むのと同じ感覚だったりする」が刺さる。同意なのだが、同意なのだが…「が」以降が大切だったりする。“ゲーム”でしか表現できない世界がありますぞ（力説）。YO-NOはそのつもりでベスト1に持ってきた。小説でいうと叙述系になるのだろうか、お話そのものに仕掛けがある作品。ゲームならEver17、小説なら「ハサミ男」を思いつく。

　　『CROSS CHANNEL』
　　『大悪司』
　　『うたわれるもの』
　　『君が望む永遠』

　「君望」は独りプレイ済み（嫁はときどき見てた）。遙か水月かでもだえてた私に、「結局ビアンカとフローラの話でしょ？私ならビアンカ」と言い切った時点で終了。

　その他のつぶやきから。

　　『終末の過ごし方』
　　『バルドフォース』
　　『未来にキスを』
　　『群青の空を越えて』
　　『つよきす』
　　『AIR』
　　『Fate』は駄目なの？
　　『かまいたちの夜』で良くね？ 怨霊編

　ええ、「かまいたち」は部屋を真っ暗にして嫁（当時は彼女）とプレイ。Goodなのは、怖い場面になると彼女が手を握ってくる（惚気勘弁）。ギャルゲじゃないけれど、ホラー映画を一緒に見る感覚だね。

--------------

　「極めて個人的に楽しむギャルゲを、女性と一緒にプレイする」という、いっぷう変わった命題を考えていただき、感謝感謝。

　これを「くだらねぇ」とか「前提が間違っている」と揶揄するのもありだけど、ま、ちょっと考えてみてはいかが→「彼女と一緒にプレイするなら、どれがいい？」そんなものは無い（知らない、質問が間違っている）、というのが答えだとすると…。

悪霊（ネタバレまくり）

　男は目で、女は耳で感じる。たとえ bad-looking でも超ミニスカだったら振り向かずにはいられないのが男。体をなでまわされる前に、まず愛の囁きが欲しいのが女。

　アダルトビデオやエロ本が大好きなのも、明るくしてヤりたがるのも、裸よりも裸エプロンの方を好むのも、男の性。昔、あれだけ渇望してたパンティの中も、見てしまえばなぁんだと枯尾花。エスカレートしてくると、○○している姿を見たがったりする。

　隠されているもの、見てはいけないものをこっそり覗くというシチュエーションが、男にはたまらないものがある。だから男は見たがる。見ることによって支配する。女のぱんつを下ろすとき、一種の征服欲が満たされる。

　見るという行為を推し進めるとフェチに行き着く。下着や服といったモノに限らず、それらが包んでいる鎖骨、ナマアシ、ドテといったパーツも、そこに執着すれば立派なフェチというもの。究極のフェチはボディだな。いや、カラダだけという意味ではなく、顔や人格すら執着するパーツの一つとしてしまう。まさに相手の人間性を無視した最終形態といえる。

　ドストエフスキー「悪霊」の終章「スタヴローギンの告白」を読んだとき、↑のようなことを考えた。「悪霊」そのものはイデオロギー対立のカリカチュアかもしれないが、「告白」は少女陵辱の告白そのもの。

　書かれなかった陵辱の具体的描写は妄想をたくましくするしかないが、「神さまを殺してしまった」と追い詰められた少女の最終手段の結果を覗き見るスタヴローギンはたまらなくいやらしい。このシーンはとても静か&心拍数MAX。

　彼女は見られることを承知で首を吊った。最も見られたくないもの、ほんとうに隠さなければならないのは、自分の死に様だろう。男を受け入れたことのない体を開くことも初めてだったが、その罪悪感から首を吊ることも初めて。わかって吊った。

　スタヴローギンは少女をそそのかし、体を開かせ、裸を見ることで支配し、さらに彼女の死体を覗き見ることで神にでもなったつもりか。ちいさく揺れる屍体は狩の成果であり、究極のフェチの対象なんだ（しかも見てるだけ！）。ああ気分わるい。まだ腐りゆく恋人と屍姦しまくる映画ネクロマンティックの方が"健康的"に見える。

　そういう怪物が、「悪霊」の主人公。

　傲慢と虚無が人格をまとうと、こうなる、という例。

　その怪物性を引きずりおろそうとした試みが、「『悪霊』神になりたかった男」なり。少女の被虐嗜好説（マゾ）や、スタヴローギンとの心理的共犯説（ストックホルム症候群）はナルホドーと納得させられつつも、もう少し素直に読めねぇのかしらね、と思ったり。

　このエントリそのものが「告白」のネタバレだ。しかし、「『悪霊』神になりたかった男」の方がもっと非道い。なぜなら、「『悪霊』神になりたかった男」の冒頭に「告白」を載せているから。この怪物が「悪霊」本編で、「なぜ」そのような行動を取ったのかが「告白」で明らかになっているのだから。

　「悪霊」を読んだ後、「『悪霊』神になりたかった男」を読むことをオススメする。逆はもったいないし、そういう風にしか読めなくなる。あるいは、既読の方には再読した気分＋発見読みができるスゴ本だといえる。

　ドストエフスキーって、ほんとうに、怖い。

怪談（一次情報）

　仕事がテンパってくるとゆとりがなくなってきて、あらぬものを見たり、おかしな体験をしたりする。自分の怒号で目覚めたり、やりかけの資料は妖精さんが仕上げてくれるようになる。血走った目で薄ら笑いを浮かべ、「こんな話があってさー」と持ちかける。ありがちなネタは、

　　このコード最後まで読んだら一週間以内に死ぬ

　　リアルデスマーチになったあの人が、さっきマシン室にいた

てなとこか。以下ネタじゃない。

水音

　なんせ古いビルなので、空調やガタピシする音が気になる。常に音がするならば慣れてしまうのだが、普段は静かで、ときおり思い出したかのように「ごぅん…」「ビシっ」とくる。最初は怖かった。

　いっぽう、うるさくはないが、ありえない場所から水音や呼吸が聞える。「疲れているんだ」と言い聞かせている。休み明けで比較的元気な時にも聞えるのは心が病んでる証拠なのか、あるいはそこに何かがいるからか。

テニスプレイヤー

　毎日すごい深夜に帰っている。途中、テニスの音が聞える。パコーンパコーンと、壁打ちというやつ? 木々に隠れてコートが見えない。「こんな遅くに熱心だな」と毎日思ってた。

　そしてある晩気付く。このあたりは街灯が少なく、深夜になるとそれこそ真っ暗になることに。あるいは目をつぶっても壁打ちできるプロ級の腕前か?

カバン

　中身は本とノートと少々。なのに、朝異常に重い。「非常に」ではなく、持てないぐらい重い。帰るときは軽々としているのに。これは逝きたくねー心理が体まで蝕んでいる証左か。妖精さんは私のカバンを寝床にしているのか。ある朝、あまりの重さに、思わずもうゴールしてもいいよね?と口走る。

--------------------

うん、きっとガンバリすぎで疲れているのだ。

たまには自分にご褒美を。

おそくまでまでやってる居酒屋にもぐりこむ。

生ビールの前にでてくるつき出しは二つ。箸は二膳。

疲れているのではなく、憑かれてるのかも。