要求仕様戦争（その2）

■要求どおりに動かない、書いたとおりに動く

　「こんなときどうします?」なんて律儀に訊いてくるプログラマならまだいい。その度に顧客と丁丁発止して決めりゃいいから。しかし、世の中には律儀じゃないプログラマもいる。律儀じゃないプログラマは、いちいち確認しない。結果こうなる。

　　　「書いたとおりに作りました」
　　　「書いてあることしか作っていません」
　　　「書いてないことは作りこんでいません」
　　　「書いてないことは何がおきるか分かりません」

　つまり、メインルートから外れると何が起こるか（書いた本人も）分からないブツができあがる。あるいは良かれと思ってプログラマが仕様を創造することにある。経験豊かで優秀なプログラマが先回りすると喜ばれるが、失敗して「よけいなお世話」を作りこんでしまう場合もある。

　あるいは、最初からこうなることを承知の上で、「書いてないもの」を実装するために別料金を請求するベンダーもいる。いわゆるアドオン（add on）仕様というやつ。どこから add on 仕様となるかは力関係・責任分界・契約書によるが、わざとadd on になるように仕向ける悪質な連中もいる。

■仕様のねじれ・仕様の衝突

　ベンダーだけが悪なのではない。発注側が居直る場合もある。ありがちなのが「仕様のねじれ」や「仕様の衝突」だ。つまり、仕様同士が矛盾を起こす事象。

　これは、要求仕様書の不備が原因。実装する段階になって、要求仕様を「確認」する問い合わせが五月雨式に発生する。「確認」された仕様は要求仕様書そのものに反映されることなく、メールの返事、メモ、議事録といった断片化された形で散らばる。貧弱ゥな要求仕様書をメンテするより、確認できた仕様をコードに落とす方を優先されるからだ。

　仕様の確認作業で断片化された仕様同士が、あるとき（ほとんどがテストフェーズで）顕在化する。仕様AもFIXされ、仕様BもFIXされている。しかし、それぞれを実装すると、仕様Cで不具合が生ずる、というやつだ（経験あるでしょ?）

　でもって、仕様A,B,C の優先順位付けと不具合回避策が練られる。どれかの仕様が特定の条件下でねじ曲げられることになる。でもってその複雑怪奇なロジックの実装料金は、このセリフで断ぜられる。

　　　「仕様を出した時、指摘がもれたからです」
　　　「仕様は矛盾していません、実装で対応してください」
　　　「見つけられなかったことが問題です、したがってバグです」

■要求仕様戦争の犯人

　思い返してみると、わたしのキャリアは、この犯人探しの旅かもしれない。

　プログラマの頃は、穴だらけの仕様を持ってきたSEを恨んだものだ。片仕様、エラー対処が一切書いていない。書いてないからと適当に補完してプログラミングするとNG。プロジェクトもタケナワになって要求仕様がようよう見えてくると、

　　要求仕様　≠　実装　　　>　　　「大きなお世話」「バグだ、直せ」
　　要求仕様　≒　実装　　　>　　　「…」（金を請求すると居直り）
　　要求仕様　≒　　　　　　　>　　　地雷

　ペーパーからはとうてい読み取れない「要求」を、断片的なスペックから創造／想像する（まさにクリエイティブだよコレ）。生産性度外視して組み込んでも、感謝もされず、（違ってたら）罵倒され無償で修正させられる。これがくり返されると、最初から書かずに、何かあったら徹夜で突っ込むようになる。

　SEとして折衝しているとき、のらりくらりと決めようとしない顧客を恨んだものだ。決定を先送りし、曖昧な表現を多用することで自由度を上げ、プロジェクトがタケナワになる頃、ようやっとと突っ込んでくる。「この仕様が入っていない、その仕様はここに書いてある（読み取れる／判断できる／自明だ／常識だ）」とくる。あたかも、読み取れなかったオマエが悪いといわんばかりに。

　曖昧な仕様書、五月雨にやってくる「確定仕様」の"伝聞"、"メモ"、"メール"、"ホワイトボード"をつなぎ合わせて、なんとか形に仕立て上げる。断片的なスペックから「やりたいこと」を想像するしかない。顧客は「生産性を上げる」だの「変化に即応した」だの「効率的な運用」といった言葉を振り回すが、その定義はいつまでたってもフリーハンド。顧客の担当そのものが仕様、いわゆるオレオレ仕様に最後まで振り回される。

　顧客になり代わって、顧客の肩書で要件定義フェーズを進めたことがある。要求を取りまとめる期間が皆無であること、そのリソースが一切考慮されていないことを知ってガクゼンとした。そもそも意思決定者が「要件定義」の必要性をチリほども考えていない。コンサルタントの絵が全てだと思っている（画餅だが）。だって、こんなに潤沢のカネを使わせたんだから、この分厚なIT戦略資料をそのままシステム化すれば全てハッピー、と心の底から思っている。

　顧客の担当は社内調整に追いまわされており、肝心の要件定義に参加する機会は、ほぼ無い。さらにタチの悪いことにデキる人ほど調整役にひっぱりだこなので、残るのは相対的に低スキル者。しかも、口だけ達者・あしらい上手が窓口に据えられる。

　コンサルティングの経験から言い切る。そこでは要件定義なんてカケラほども考慮されていない。コンサルティングフェーズで必死こいてやっていることは、経営目標を業務戦略へいかにロジカルに緻密に落とし込むか、の一点だけ。仮にシステムに関わるとしても、いかに費用対効果につなげられるかの分析だけで、エンドユーザーにとってのシステム化要件は、皆無。

　あと、わたしがやっていないのは経営者だけだが、戦犯を探すことは無意味なことに気づいた。経営者には経営者の、コンサルにはコンサルの、発注側の担当には担当の、思惑がある。SEにはSEの、プログラマにはプログラマの言い分がある。その結果、

　　　・リスクを負うことを恐れ、曖昧なままに先送り
　　　・当事者意識の無さから、要件定義の重要性を軽視
　　　・ヘタに言及・実装すると火中の栗になるので、ダンマリを決め込む

　誰か戦犯を仕立て上げ、石を投げても解決にならぬ。

■要求仕様戦争を回避するために

　ひとたび勃発したら、収拾はほぼ不可能と思ってよい。思いのスレ違いが増幅し、修復不能になった時点で表面化しているのだから。「もう作っちゃってるんですケド…」「もう出しちゃってるんですケド…」だから。がんばってなんとかなるレベルではない。ありがちなのは、「火消し部隊」と「仕様決め部隊」を分けて工程の引きなおす、深刻度と優先度とショーストッパーを分けて着手する等など。ホレ、かっちょいい言葉でいうならトリアージ開発やね。

　逃げるにせよ、立ち向かうにせよ、起きてしまった戦火をどうこうするのは皆さんご存知のようなので、「死なない程度にがんばろうね」という言葉を贈る。ここでは、そもそもそんな事態に陥らないようにするための手立てがある書籍をご紹介。合いそうな奴を参考にしてほしい。

　要求仕様戦争を回避するための切り口は、以下の3つ。

　　　・仕様書
　　　・開発工程
　　　・人（PM）・組織

USBメモリを用いたソーシャル・エンジニアリング

　ソーシャルエンジニアリングの第一歩は、「組織内の人に化けること」にある。イーサン・ハントみたく化けの皮を被る必要もない。もっと重要なのは、機密ではないが、組織内の人しか知りえないような情報を知っていること。例えば座席表やビルドサーバの名前だとか。

　ひとたび組織内の人に化ける情報を得たならば、攻略はぐっと楽になる。「欺術」を参考に潜入を進めることができる（ホントにやっちゃダメよ）。ここでは、USBフラッシュメモリを使って最初のハードルを効率的に超える方法を考えてみよう。

　オフィスの受付窓口の片隅や、社員食堂（外の人も入れる）の廊下でUSBメモリを拾ったら、どうするよ? USBメモリなんてありふれているし、最近じゃオサレな奴やカワイイ系まで出回っているぐらいだ。誰かが落としたんだろうな… で、何が入っているのだろうか?

　で、自分のPCに挿してみる…が、すぐに覗けない。それぐらい知ってるって、しばらく待たなきゃいけないんだろ。砂時計が矢印になったのを確認して、開けてみる… なんだ、何にも入ってないじゃないか、変なの。え? いや、オレだって知ってるよ、社内通達で、「不審なファイルは開けちゃダメ」って、ほら、".exe" とかいうのがヤバいんだろ? 大丈夫、フォルダを開けるだけなら問題ないはず…

　…こんな奴ぁいねぇ、と誰も断言できない。やる奴はいる、必ず。社内のセキュリティシステムを突破して、直接ファイアウォール内のPCへ『配達』してくれるのだから笑いが止まらない。たった一人でOKなんだ。

　グッチやシャネルといった有名ブランドのUSBメモリなんていかが? パチモノで充分。ディズニーキャラクターをプリントしてもいい。女の子が「欲しい」と思った時点でトロイの木馬が成功。あるいは『2GB』とプリントするのなんてどう? ギガバイト級の情報を持ち歩くなんて、いったいどんな情報なんだろう? 興味津々好奇心はネコを殺す。

　信じたいあなたに実例をどうぞ→"Social Engineering, the USB Way"[参照]。これはセキュリティのコンサルタント会社が擬似的にアタックをかけた例なのだが、受付係のキャンディ皿に蒔けというのは、なかなか気が利いている。

　良い子はマネしちゃいけません。そして、"そういう立場の人"は対策を考えておくこと。そのうち出てくるか、見つかってないだけで既にいるのかも。

要求仕様戦争（その1）

■要求仕様とは

　要求仕様とは、開発するシステムに対する顧客のニーズのこと。要するに「お客さんがやりたいこと」そのもの。仕様調整で紛糾したときの決め台詞「結局アナタは何がしたいの?」の【何】に相当する。仕様トラブルの100％はこのスレ違いによる。

　要求仕様について考えるために、ちょっとした質問に答えてみよう。以下のa. b. のうち、「要求仕様」を表現しているのはどちらになるだろうか?

　　a. 身長57メートル体重550トン

　　b. 汎用人型決戦兵器

　まず a. を考えてみる。これは「何」だろうか? これは「何」かのスペックだ（しかも部分的だ）。身長・体重は分かるが、横幅や厚み、姿かたち、素材 etc... は分からない。これは受注側が「○○はどうするの?」といちいち問い合わせる必要がある。当然、聞くのを忘れたスペックは製造者の「思い」で作られるリスクを負う。

　次に b. はどうだろう。身長・体重その他もろもろは分からないが、「何」かは分かる。要求されているのは「兵器」だ。したがって、スペックは分からないにせよ、次の質問は、こう続くだろう。何を想定した「兵器」なのか? 必要な性能は? 操作方法は? … 身長や体重といったスペックは、その結果によって決まってくる。

　正解はもうお分かりだろうが、本当の問題はここから始まる。要求仕様として最初に「身長57メートル」と提示されると、スペックからの視点に引きずられ、結果として仕様モレにつながることこそ、大問題。一見、矛盾しているようだが実はよくある話。

　いや、スペックを書くなといっているわけではない。もちろんスペックは重要であり、できる限り詳細に書いておくべきだ。しかし、本当に欲しいものが書いていなければ、スペックの羅列は罠になる可能性が非常に高い。欲しい「何」が書いてない場合、作り手はスペックの羅列から「想像」しはじめるからだ。

　その結果、どうなるか?

■「仕様書に書いてある！バグだ！」　vs　『読み取れない！追加要件だ！』

　萌芽は要求仕様書にある。一瞥しただけで分かる。表紙はご大層だが中身はスカスカ。経営層が決定を先送りしてきたからだ。「要求」をまとめ、仕様化し、レビューするだけの時間は、常に省みられない。「何が欲しいのか」が読み取れない要求仕様書が契約のテーブルに載る悲劇。それで見積もってくる営業に石を投げても詮なし。

　いっぽう受注者は、そこに書かれた「仕様」を逐一実装すれば、「要求」を実現できると信じる…わけねぇだろ！それは「仕様」の体を成しておらず、ひょっとすると「要求」どころか要望すら突き抜けた希望的観測の羅列となっている。

　それでも、「要求仕様書」と表紙に書いてあるので、恭しく頂いて、そこを起点に「仕様」を補完することになる。いくばくも進む前に気づく。これは穴だらけの仕様ではなく窓だらけ、ドアだらけだというべきことに。

　スケジュール上では「設計フェーズ」になっているので設計書みたいなアウトプットを作るのに注力することになる。実際は「何がしたいのか?」を想像したり尋ねたり、仕様の穴埋めをせっせとしているのだが。

■仕様戦争の起爆装置

　その結果、仕様の穴埋めは「製造フェーズ」まで持ち越される。仕様戦争が勃発する起爆装置の代表例は次のものが挙げられる。

• 片仕様…最もポピュラーな起爆装置。「○○の場合、△△をする」とあるが、「○○でない場合」が未決定。放っておくとプログラマは「何もしない」ルートにつなぐ
• error漏れ…片仕様のエラー版。エラーだった場合何をすればいいかが未決定。放っておくと最悪の場合「読み捨て＝何もしない」ルートにつなぐ。今ならexception漏れというべきか
• 状態考慮漏れ…「○○の場合」は値なので漏れも気づきやすいが、「状態」は通常外出しテーブルで定義される。状態を参照して判定するロジックは、安易に追加される「新状態」を考慮されない
• 仕様の賞味期限漏れ…その仕様が影響する開始時点と終了時点（仕様の賞味期限）が明記されてないがため起きる仕様間衝突

　なんせ「作りながら仕様決め」に等しいため、作り手は決めながら実装してるような気になる。コードの可読性は後回しとなり、「できるだけ早く」が合言葉になる。

　当然、当初の「要求仕様書」は省みられず、「メモ」「メール」「議事録」「資料の朱書き」といった形であちこちに飛び散った断片が実装されることになる。

■仕様戦争の勃発

　上記の起爆装置が作動するのはいつだろうか?

　　　　「顧客からの仕様変更が多すぎて…」

　　　　「やってるうちに要求の追加がつぎつぎと…」

　　　　「実装フェーズで見積もりの甘さが露呈して…」

　よくある上のセリフは的外れな場合が多い。ぶっちゃけ、ホントのところは作っている最中に仕様を検討しているからなんだが、さすがにおおっぴらに言えん。まさか仕様も決めずに受注しちゃってリソースを投入しているなんて、経営層にバレたら懲戒モノだぜ。

　王様は裸じゃないから、一度ついたウソは続けなければならない。ホンネとタテマエの使い分けが上手いSE/PMが出世する。マジメに取り組む奴ぁ出世する前に胃に穴があく。開き直った連中がテストファーストとかスパイラルとか名前を変えているだけで、やっている本質はまるっきり同じ。むしろ現実にタテマエを追随させようとしているに過ぎぬ。

　経営層が先送りしたIT戦略意思「未」決定のツケがスカスカ仕様書に化け、スカスカ仕様書を押し付けられたSE/PMはプログラマへ華麗にスルーパス。そして、全てのシワヨセがプログラマへ。

　ところが、プログラマは正直者だから、

　　　　「if (hoge)の後のelseには何を実装すればいいんでしょうか?」

　　　　「HogeException を受け取ったらどうすればいいんでしょうか?」

　　　　「状態テーブルの値と case 判定が一致しませんケド?」

…と訊いてくる。あたりまえだ。知らないと書けないから。しかし、誰も答えられない。当然だ、誰も考えてなかったから。

　さあ、仕様戦争の始まりだ。野郎ども、準備はいいか? ハイホー！ハイホッホー！

徹夜小説「告白」でトランス

　はてなでオススメいただいた徹夜小説「告白」を読んだ。一言で表すなら、読むロック（ただし8beat）。幸いなことに（?）これが何の小説であるか予備知識ゼロで読んだ。真黒なラストへ全速力で向かっていることをビクビク感じながら、まさかこんなとんでもない「事件」とは露知らず。

　テンポのいい河内弁でじゃかじゃか話が進む。この一定のリズムは音楽を聴いているようで心地よい。中毒性があり、ハマると本を閉じられなくなる。読み進むにつれ、朦朧とした不思議な感覚に包まれる。

　面白いなぁ、と思ったのは、明治時代の主人公の頭を極度に思弁的にしている設定。当然、ムラの衆との意思疎通や日常生活まで齟齬を来たしまくる。語彙と相手さえあれば、とてつもなく知的な存在になりえたのに、それが無いがために周囲からは理解を得られず、痴的な存在と見なされる。読み手はこの葛藤にまず笑うだろう。

　「告白」の名の通り一人称でずっと進むと思いきや、妙なトコで冷徹に三人称で書いたり、同じ一人称でも著者がしゃりしゃり出てきたり、誰? だか分からないツッコミが入ったり。読み手の気持ちピッタリなので、とりあえず「わたしの代わりにツッコミ」だと思いつつ進む。ドツボにはまる男を憎めないのと、彼の苦悩（周りに分かってもらえない）に同調しつつ、どんどん感情移入してゆく。

　ときおり、物語の構図がクッキリと閃く瞬間があって妙に恐ろしい。男の脳内独白を後ろで聞き書きしてツッコむ著者の文章を追いかける読み手、という多層構造。男のお面を被った著者が後ろ向きにこっちへ突っ込んでくる感じ。著者の視線をもって男の後ろ側か皮膚に入り込む…ううむ、UNIXパイプ処理の方が表現し易い、要はこうだ。

　　　cat　主人公の独白　>　思弁を聞き書き（著者）　>　読み手

　この独白が上手い具合に自分にシンクロしてくるとさぁ大変。長広舌が病み付きになる。だるだる付き合ってるのが熱中してくる。仕舞いにゃ自分も河内弁で語りだす。

　…で、その延長上にそんな出来事が待っているとは…！！

　カタストロフの直前、男が被る獅子舞の内側から見た世界が最も恐ろしい。全世界から疎外される男の苦悩は、脳内をエコーしまくるだけでちっとも外へ出てこない。出るとしても切れ切れの思考の欠片だけで意味をなさない（だから愚者扱い）。まぶたの内側で涙を流すしかない。

　　　cat　獅子舞から見た世界　>　主人公　>　読み手

　獅子舞を被ったトンネル越しの世界、これこそ男の世界そのもの。河内弁なんざかなぐり捨てて現在用語でもって全力で語られる。男と読み手が一直線に貫かれる瞬間。そしてついに、【以降ネタバレ】殺戮が始まる。河内十人斬のビート（ホントにこのCDがある）が腕を這い回る、知らないはずなのに踊れるぞジョジョォォォーーッ！彼にしてみればとても明々白々。正義を成し善を遂行するために完全無欠に必要な行動を順番に実行する。やっている行為の一つ一つは輝くほど明白なのだが、思考の断絶がフラッシュのように入り込む。ずっと不審に思ってきた出来事の【非】一貫性は（作者の準備不足ではなく）、周到に計算された前フリなのかと好意的に捉えたくなる。大量殺人者にいたるまでの思考をシミュレートしたんだから仕方ないか。ところが読み手であるわたしと極限までシンクロしちゃっているんで、執行シーンでは体を（心を?）もぎ離すのに苦労する。パイプ">"を通じてしっかりと喰い込んじゃっているから、今やめると吠えだすに違いない、この体は！何て叫ぶって? もちろん人間停止ッ！、人間停止ッ！！

　本書を「キ○ガイシミュレーター」と名付けてもいいが、どこから狂っているのかが分からないトコロが欠点。さらに、彼をキ印扱いするなら、わたしは…? と慄然とするところが非常にヤヴァい一冊。

　ええ、もちろん徹夜だよ徹夜…ただし一徹で済んだ。

――――――――――――――――――――――――――――――――――――――

企画「徹夜小説を探せ！」のリストを更新

■これから読む徹夜小説

　　永遠の仔（天童荒太）
　　第六大陸（小川 一水）
　　ガダラの豚（中島らも）
　　傭兵ピエール（佐藤賢一）
　　ゼウスガーデン衰亡史（小林恭二）

　　魔術師（J.ファウルズ）
　　北壁の死闘（ボブ・ラングレー）
　　イヤー・オブ・ミート（ルース.L.オゼキ）
　　スワン・ソング（ロバート.R.マキャモン）
　　シャドウ・ダイバー（ロバート・カーソン）
　　カラマーゾフの兄弟（ドストエフスキー）米川正夫訳 ／岩波文庫版

■徹夜を覚悟・徹夜した小説

　　火車（宮部みゆき）某弁護士事務所では、新人研修に使う
　　半落ち（横山秀夫）ラストで号泣、涙で読めねぇ
　　ダ・ヴィンチ・コード（ダン・ブラウン）読むジェットコースター
　　摩天楼の身代金（リチャード・ジェサップ）「最高」の冠を付けたい
　　悪童日記（アゴタ・クリストフ）「ふたりの証拠」「第三の嘘」と一緒に！
　　ベルガリアード物語（D・エディングス）ドラクエとFFを足して2倍した面白さ
　　大聖堂（ケン・フォレット）2006年のNo.1スゴ本
　　告白（町田康）読むロック（ただし8beat）

「わたしを離さないで」は重い思い出になる

　スゴ本なんだが、どこまで紹介していいか分からない。カズオ・イシグロを知っているなら黙って読めとオススメするが、知ってる人なら既読だろう。だから、彼の作品を知らない人向けに語ってみる。

　…とはいうものの、この小説に隠されている秘密はご自身で確かめていただきたいので、とても抽象的にレビューする、ご勘弁。

　これはとても奇怪な小説。静かで端正な語り口から始まって、いかにもありそうな共同生活が語られる。淡々と語られる「思い出」が積み上げられていくうちに、読み手はだんだんと不安な心持にさせられる。彼女は何を伝えようとしているのか、と。

　それでも語られる内容は、ありふれた人間関係と思い出ばなし。イギリスの全寮制の学校を舞台としたドラマ? でもこの微妙な違和感は? と思いながらも、語り手の真摯さに思わず引き込まれる。

　真実は薄皮をはがすように、一枚また一枚と明らかになってゆく。読み手は自分が抱いた違和感（異物感?）を半ば確信しつつも、もどかしさにページを繰るだろう。書き手はそれを充分に意識した上で、抑制の利いた語り口でじわじわと切迫感を募らせてゆく…

　この小説が、いったい何をテーマに語っているのかが分かる段階では、読み手は、この語り手から目を離せなくなるだろう。結末がどうなるか、ではなく彼女が何を伝えたいのかが気になって仕方がない。… いや、ネタをバラしてもいいんだが、作品世界を成り立たせている要素の一つ一つは、ご自身の目で発見して欲しい。予備知識ゼロで、どうぞ。

　… ここまで書いて、何のこっちゃか全然分からんね。だから、朝日日曜版レビュー(2006/5/28)の一文を引用する。（読み終わったわたしに）突き刺さってくる。

　わたしたちは、何かの目的のために生まれるわけではない。生まれるために生まれ、生きるために生きる。なぜ、生きていくのか、わからないままに、先の見えない暗闇を進んでいく。ある目的のもとに生を受け、役割を果たして死ぬ彼らは、その点で私たちとまったく異なってみえる。だが、どんな圧力が彼らの生を限定し未来を縛ろうとも、命それ自体は、目的など無効にして、ただ生きようとするのだ。生きるために。

　これは、感動ではない。この気持ちに名前をつけることはできない。この気持ちは誰も経験したことがない。しかし、わたしは知っている。この未来があることを。この気持ちは、いずれ誰もが経験することを。

--

　カズオ・イシグロ著作リスト。「わたしを離さないで」と「日の名残り」は自信をもってオススメ。

A Pale View of Hills (1982)「遠い山なみの光」　ハヤカワepi文庫
An Artist of Floating World (1986) 「浮世の画家」　中公文庫
The Remains of the Day (1989) 「日の名残り」　ハヤカワepi文庫
The Unconsoled (1995) 「充たされざる者」　中央公論社
When We Were Orphans (2000) 「わたしたちが孤児だったころ」　ハヤカワepi文庫
Never Let Me Go (2005) 「わたしを離さないで」　早川書房

「消された一家」で最高に胸クソ悪い体験を

　はてなブックマークでオススメいただく。スズキトモユさん、たいへん感謝しております。これほどの胸クソ悪い体験はめったにないですゾ。

　これ以上気分が悪くなりようのないぐらい嘔吐感を味わう。おまけにこの酸味、読んだ後いつまでも引きずっていられる。

　こんな人間が「存在する」ことはよく理解できた。この人間を悪魔だの人でなしだの呼ぶのはたやすい。しかし、彼を悪魔とみなすことで思考を止めたら負けかな、と思いながら読み続けた。父親の解体の場面で体が読むのを拒絶した。しかし、なぜそんな事件が起きたのか、どうすれば回避できたのか、知りたくて最後まで読んだ。

　今から考えると、そこで読むのを止めておけば良かったのに、と思っている。

　それが、「消された一家―北九州・連続監禁殺人事件」

　最悪の読後感を味わえるのは、最後まで読んでも、「なぜそんな事件が起きたのか」はぜんぜん分からないから。無抵抗の子どもの首にどういう風にコードを巻いて、どんな姿勢で絞めたか、といった行動は逐一知らされるが、「なぜ・どうして」は想像すらできない。

　これを著者の筆力不足に帰するのは、あまりに気の毒。一人称で書けないルポルタージュの限界なのか。「事実は小説よりも奇」とは、たしかにその通り。しかし、事実を理解することができない。虚構でもいいからこの出来事を理解したいと願うのならば、小説にするしかないのか。

　さて、ここまでひっぱった上で内容の紹介を。思い出したくもないのでamazon紹介文で茶を濁す。わたしが自信をもって言えるのは、以下の文が大変ひかえめだ、ということだ。

　被害者は妻の父・母・妹夫婦・姪・甥…。「天才殺人鬼」松永太は、一家をマンションに監禁し、「殺す者」と「殺される者」を指示した。彼らは抵抗も逃亡もせず、互いを殺し合った。遺体はバラバラに解体された。ついに妻一人を残し、家族は消滅した。七人が抹殺された“史上最悪”の密室事件。

　どう見ても劇薬本です。本当にありがとうございました。

　amazon 見てたら同事件の別ルポを見つける。「なぜ家族は殺し合ったのか」だ。読むか…

子どもに「タバコ」を教える

　5年前のわたしは、楽しくタバコを吸っていた。紙巻・パイプの両刀使い、喫煙ルームで仕事するヘビーなスモーカーだった。酒とオンナはやめられても、こればっかりはやめられない、世界で最も楽しい（ホッとする、安心できる、至福の）時間は、タバコに火をつける瞬間だと信じてた。

　そんなわたしに、ある人が訊ねた。「じゃ、あなたの子が大きくなったら、タバコを教えるんだね。その味わいと素晴らしさを伝えるんだ。そして、あなたの子も喜んで一緒に吸うようになるに違いない」

　その人の名はアレン・カー、「禁煙セラピー」でこの問いを投げかけられ、禁煙（というか卒煙）のきっかけとなった。以来、タバコとは縁のない人生を送っている。それはそれでメデタシメデタシなのだが、この話が終わったわけではない。

　そう、子どもに「タバコ」を教えておかないと。メディアや環境から刷り込まれる前に、ちゃんと教えておかないと。そのヒントは同著者の「子どもにゼッタイ吸わせない禁煙セラピー」にある。

　学校では、「タバコ」とは何であるかを教えない。タバコの害を説き、真ッ黒な肺を見せるだけ。それじゃ半分だ。好奇心が湧いて「ボクはそうならない」と思ってオシマイ。あたかも、交通事故現場の写真と一緒。陰鬱な気分になるだけで、どうすれば回避・予防できるかは分からない。家から一歩も出ることなしに、関連する一切を遮断して生きていくつもりならそれでもいいが、そういうわけにもいくまい。だから、タバコの本質を伝えないと。

　タバコの本質は、合法的な麻薬だ。タバコなしの自分には何かが欠けていることを常に感じさせ、タバコを身につけていないと、パニックに陥る。タバコを吸うのはタバコが楽しいからではなく、心の中の不安感や渇望感が一時的に満たされるため。そして、その不安感や渇望感は、さっき吸ったタバコが作り出したもの。

　喫煙とは、頭を壁に打ち付けて、それをやめたときのホッとした気持ちを楽しむ行為と一緒。タバコがリラックスさせるのは薬物の禁断症状が緩和されるからホッしているに過ぎない。タバコがストレスを和らげているのではない。一回前に吸ったタバコのニコチンがストレスを引き起こしているんだ。

　この事実を理解してもらうために、たっぷりタバコを吸わせる必要なんて無い。悪友たちに勧められ、好奇心もあって、最初の一本に火を点けたことを思い出そう。今でもハッキリと覚えている。マイルドセブンだった、冬の日だった。そのとき自分がどう感じていたか、そして今、どんなに後悔しているか、子どもに語ってみよう。

　タバコが合法的な麻薬である限り、スモーカーはこれからも生産されていく。彼らの立場を配慮しつつ、自身が罠にハマらないように付き合っていく必要がある。わたしは脱出できたが、わが子は最初からかからないようにしたい。

　「ノンスモーカーの子なら、絶対タバコを吸わない」なんて希望的観測に過ぎない。子どもがタバコを吸うようになるか否かは、今のわたしに懸かっているんだ　…なんて気合を入れていたら、嫁さんの一言で済んだ。歩きタバコの人を指して

　「あれは毒を吸っているの、煙を吸い込んじゃダメよ」

「欺術」――ヒューマン・ハッキング・クックブック

　コンピュータの名著100冊[参照]で推されて一読、スゴいね、これ。

　いわゆる、コンピュータやネットワークの脆弱性を狙った正攻法クラッキングなら多々あれど、これはソーシャルエンジニアリングの事例集。ねとらん無用の逸品だ。

　ショルダーハッキングからハードウェアハッキングまで、19の手口が具体的に挙げられている。そして、全てのパターンにあてはまる共通項がある。それは、人間こそが攻略のカナメだということ。

　認証デバイス、アクセスコントロール、侵入検出システムなどは、今の企業では必需品（日用品?）かもしれないが、そんな「守り」をいくら固めても、彼らはやすやすと突破できる。なぜなら、それらを相手にしないから。どんな防御であれ、ウィーケストリンク（最も弱い環）になるのが人間だという真実を思い知らされる。

　「最も安全なコンピュータは、電源を切ってあるコンピュータだ」とは言い得て妙だが、真実ではない。ソーシャルエンジニアは、もっともらしい口実を駆使して、内部の誰かを口説いてコンピュータの電源を入れてしまうのだ。これは本書で言及されている話だが、ウソでも冗談でもない。

　セキュリティ本のほとんどが、ハードウェアとソフトウェアの話に終始し、最も深刻な脅威である人間に対する詐欺的な犯行を扱っていない。この本は、（わたしも含まれる）読者だけでなく、同僚、上司、部下が騙されるときにはどうやって騙されるのかがケーススタディ方式で書かれている。さらに、煽っておしまいではなく、犠牲者にならずに済むための防御の方法、犯行の兆候、予防施策がこれまた事細かに列挙されている。

　忙しい方なら p.501 の付録「一目で分かるセキュリティ」を読んで（わずか10ページにまとめてある）、第16章のセキュリティポリシーを取捨選択すればよい。まさに至れり尽せりの一冊なり。

　ただし、問題がある。ヒューマン・ハッキングの共通パターンが易々と身に付くので、読み終わったときには「ボクにもできるカモ」と思ってしまうところ。サイト「激裏情報」や「悪のマニュアル」（PC版でない奴、今は絶版）、コミック「ナニワ金融道」、小説なら「白昼の死角」（詐欺小説の傑作）などと一緒。法律スレスレのテクニックと、どこがボーダーラインかの見極めはセンス。よい子はもちろんマネしないが、センスだけは磨いておこう。

　実はもう一つ、問題がある… いや、「ない」と言うべきか。何が「ない」のかというと、企業の"外側"からの犯行ばかりで、企業"内"犯罪者の手口・事例が書いてないのだ。企業にとって最も恐るべきなのは、社員の犯行だろう。優秀なエンジニアなら痕跡を完璧に消し去り、企業活動の奔流に犯行を散りばめ呑み込ませるだろう。著者が意図的に書かなかったのは明らかだが、賢明というべきか。あるいは読み手が推して知るべしというメッセージか。獅子身中のワームについは「悪のプログラマ」に書いたが、この辺でやめておこう。

いきなりコンサルタントに抜擢された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章との間に「なぜシステム化か?」の疑問に答えるための理論武装が必要なんだが、意図的に（?）書いていない。こいつまで明かしちゃうと喰いっぱぐれるかもしれないからか。やってみればロジックの飛躍に気づくので、自分で埋めておくこと。