「ローマ人の物語」を読み始める

　いつか読もう読もうと思ってるうちに往生したらもったいないので、いま読む。そんな積ン読ク山に挑戦してみようと思うのは夏だから? あるいは、今年で完結だからいまから読み始めると、ちょうどイッキ読みできるから?

　理由はともあれ、「ローマ人の物語」を読み始める。

　非常に評判が高いので、おそらく、沢山の方が既に読んでいるだろう。そして、わたしといえば、最近ローマがらみでやったのは「ゴッド・オブ・ウォー」という体たらく（まてよ、ありゃギリシアか?）。冗談さておき、「ローマ帝国衰亡史」は本棚の肥やしになっている（買っただけで満足している）似非読書子。

　だから、ここでできることといったら、「ローマ人の物語」の第○巻の読みどころはコレ！と紹介するぐらいか──と思いつつ、冒頭の「読者へ」を読むとすてきなことが書いてあった。

　　　知力ではギリシア人に劣り、
　　　体力ではケルト（ガリア）やゲルマンの人々に劣り、
　　　技術力では、エトルリア人に劣り、
　　　経済力では、カルタゴ人に劣るのが、

　自分たちローマ人であると、ローマ人自らが認めていた。
　それなのに、なぜローマ人だけが、あれほどの大を成すことができたのか。

　そもそも「ローマ人の物語」を著そうとした理由はこれだという。一大文明を築きあげ、それを長期にわたって維持することができたのか。どの世界史の教科書にもある、軍事力の一点のみに因るのか。そして、そんな彼らさえも例外にはなりえなかった衰亡も、これまたよく言われるように、覇者の陥りがちな驕りによったのであろうか──「ローマ人の物語」を読めば分かるかどうかは知らないが、「読者へ」の最後でこう締めている。

　　　あなたも考えて欲しい
　　　「なぜ、ローマ人だけが」

　…ええ、「ローマ帝国衰亡史」を傍らに読むナリ～

　で、第1巻「ローマは一日にして成らず」で面白かったところは、宗教についての考え方。ローマがなぜ強いかの秘密は、まずコレだろう。ローマ人にとっての宗教は、指導原理ではなく支えにすぎなかったから、宗教を信じることで人間性までが金縛りになることもなかったそうな。

　確かに、一神教の持つ、道徳原理を引き受けてくれる、正しさの根源性としてのメリットは大きい。しかし、自分たちと宗教を共有しない他者は認めないという排他的なマイナス面は見逃せない。カンタンにいうと、ローマ人は宗教戦争はしなかったのだ。

　一神教と多神教の違いは、単に信ずる神の数にあらず、他者の神を認めるか認めないか、にある。そして、他者の神を認めるということは、他者の存在を認めるということ。ここで書き手はチクリと現代を刺す。「二千七百年はすぎているのに、いまだわれわれは一神教的な金縛りから自由になっていない」と。

　では、ローマ人にとって、宗教が担っていた行動原理に相当するものは何かというと→法だった。宗教は共有しない人との間では効力を発揮しないが、法は、価値観を共有しない人との間でも効力を発揮する。むしろ、共有しない人との間だからこそ、必要となってくる。人間の行動原理の正し手を、

　　　宗教に求めたユダヤ人
　　　哲学に求めたギリシア人
　　　法律に求めたローマ人

　この一事だけでも、これら民族の特質が浮かび上がってくる──こう堅苦しく考えなくとも、何でもかんでも神サマにしたがるローマ人の器の広さ（?）を語るエピソードの一つに「夫婦喧嘩の守護神」がある。これは面白い、ハラ抱えて笑わせてもらった。次に紹介するね。

せんせがいるから、この世界は地獄じゃないの。この世界は間違ってなんかいないわ、あたしが言うんだから本当よ

　まさかラノベをスゴ本として紹介することになろうとは──いちばん驚いているのはわたし。ふつうラノベは30分で片付けているにもかかわらず、「円環少女」はたっぷり2時間、夢中に没頭させられた。

　ツンデレサディストつるぺた美少女、美乳女子高生（ハルヒ以上に世界を改変できる）、ツインテールで綾波な魔獣使いといったキャラも魅力的だ。あるいははらわたと脳髄飛び散る血ミドロ壮絶バトル←→ほのぼのお茶の間・六年一組との往還も面白い。

　しかし、これは【魔法】世界設定【体系】がスゴいのよ。

　普通人の視線で発動しなくなる「魔法」を背負って地獄（この世）に堕とされたウィザードたちの永き世にわたる闘いは、何のメタファーになるだろうか? 迷わずあたしゃ、「良識」と「個性」との闘争に置き換えたぞ。筆者は世界設定に何のメッセージ性も持たせてないので、読み手が好きに改変できる。しなくてもいいけれど、きっと何かに喩えたくなる。

　読めば分かる。物語りの世界へ読者を連れて行くのはヘタクソだけど、世界そのものは魅力的。ここはひとつ、読み手みずからが歩み寄ることで、そのスゴさが堪能してみてはいかが。読みづらいことおびただしい悪文をガマンして進めると、突然、小説世界のありようが分かる。

　すると金脈を掘り当てたような気分になる。例えば、鋼錬の等価交換な世界、ジョジョの波紋、寄生獣のミギーの第1話を思い出してくれ。なにがなんだか分からないまま、話に巻き込まれ、その話のルール（＝設定）に気づいたとき、「その設定なら間違いなく面白くなる。たとえオレがプロット書いたとしても」と思ったかもしれない←それそれ、その気分を味わえる。これはわたしが書いてもヒットになる設定。この世界を考え抜いた筆者に幸あれ。

　いや、書き手は一人だけでない。おそらく中に三人いる。バトルファンタジーばかり書いていた筆者、萌えとほのぼのをバランスよく注文する編集さん、科学的根拠やTipsを補強する担当さんの3人だ。小説を書くのはチームワークなんだなーといまさらながら実感する。

　さて、中身にほとんど言及せずに紹介したぞ。クセがあるけれど、あとは自分でハマってくれ。あー蛇足だが、1巻からよりも、2→3→1 の順に読むといいかも。

ラノベの奇書「円環少女」

　つるぺた小学生（美少女）。呼びかけは「せんせ」（≠せんせい）。授業中に手サインで「大好き」を送ってくる。地獄（という名のこの世界）に堕とされた魔法使い、という設定だけど、どう見てもエスパーです、ありがとうございました。

あたし強くなって、せんせが心配なんかしなくていいように屈服させたげるから。せんせは毎日、あたしが作った手料理を、あたしの手から食べて生きていくの

　ヒロインはツンデレサディストロリ。ロリ好きなら破壊力満点。そうでない方には、豊乳女子高生（美少女）もとりそろえてある。萌え学園モノかと思いきや、灼熱のウィザーズ・バトルが謳い文句（←宣伝に偽りなし）。

　バトルはスゴいの一言。魔法戦というより超人ロックのノリ。あるいは幽波紋の頃のJOJOか。命の奪り合いの真ッ最中に、素っ裸の女子高生が降ってきたりする発想が面白い。ジョジョの奇妙な冒険のみならず、鋼の錬金術師をホーフツとさせるネタに微笑む──が、本シリーズの世界設定はオリジナルで、とても巧妙にできている。

　ただし、難しいコトバを使いたがり、体言止めを多用して主語を省略する典型的な悪文。さらに、話が飛び回って説明だったり描写だったりするので、読みにくいことおびただしい。

　──で、「円環少女」面白いかって? うん、妙にツボにハマった。

徹夜本「復讐する海」

　徹夜するほど面白かった小説企画。「徹夜するほど面白かった小説」で知った「復讐する海」を読了、これはスゴい。ありがとうございます、Bさん。

　ただし、ボリュームは無いので徹夜するまでもなし。しかも開始早々度肝を抜かれ（予備知識ゼロで手にしたのだ！）→以後イッキ読み→気づいたら終わってた、幸せな読書体験…というのは真っ赤な偽り。

　幸せと評したが、マチガイ、

　これを読めば地獄体験ができる。

　特に、この本、食前食後に読むの禁止。

　さらに、心臓の弱い方もやめておいたほうが吉。

　怒ったマッコウクジラに体当たりされ、沈没させられた捕鯨船の話は、『モービィ・ディック』が有名だが、本当の悲劇は「白鯨」のクライマックスから始まる。捕鯨船から脱出したのは20名――そのうち、生き残ったのはわずかに8人――赤道直下の太平洋で起きた極限状況を綿密な調査の下に描いたノンフィクション。2000年の全米図書賞を受賞。

　紹介文に「これが冒険小説ではなく、実話であることに衝撃を覚えずにはいられないだろう」とあるが、激しく同意。読む前も、読んでる途中も分かってはいたんだが、あとがきで、これがかけ値なしの実話だというところを再認識させられてめまいを覚える。

　書き手も分かってる。感情を排した淡々とした描写で、事実のみを記そうという姿勢で一貫している。おどろおどろしくドラマティックに書くことだって可能だろう。「くじ」を引いて友達を○○しなけりゃいけないことになった場面とか（泣いた）、死期を察したリーダーが取った行動とか。

　また、もっとジャーナリスティックに書くことだってできたはず。「最初に食べられた4人の黒人は、なぜ『黒人ばかり』だったのか?」、あるいは「船長の決断が覆り、結果的に全員を絶体絶命の場所へ追いやった原因は?」――等など、センセーショナルに書けば書けたものを、そうしなかった。

　メルヴィル「白鯨」は、ある生存者が書いた記録を元に著されているが、実は半分に過ぎない。本書では、最近発見された別の乗組員の手記とつき合わせることにより、より立体的に悲劇が明らかにされる。ともすると最初の記録を書いた乗組員の過ち、ごまかしを糾弾する筆致になろうとするのを著者は抑え、常に公平な立場で事実を詳らかにしよう、という意志が見える。

　さらに興味深いのは、救かった人の「その後」が描かれているところ。「こうして彼らは助かり、故郷へ帰っていったのでした、めでたしめでたし」となるはずがないところ。生き延びた時点でまだ10代、20代だった彼らが、その後、どうしたのかが、これまた淡々と書かれている。特に胸が一杯になったのは、生き延びた部下たちが、次の航海で選んだリーダー。思わず目が熱くジワっときたなり。そしてそのリーダーの末路…

　ええ、「白鯨」は未読ですとも。

　もちろん読みますとも。

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

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

■これから読む徹夜小説

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

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

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

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

観鈴グッドエンド

　ゲームのみならず、TVアニメ、映画と、わたしたちは、何度も彼女の死に立ち会ってきた。微妙に違えども、ラストで彼女は必ず、「もうゴールしてもいいよね?」と訊いてくる。その度にひるんだり涙にむせたり。

　くり返される「ゴール」の果てに、異なるラストに出会う。ちょっとふっくらとした観鈴、だがすんなり伸びた二の腕がまぶしい。「オフィシャル」の冠の下、同じ展開かと思いきや、まさかそうなるとは… !!

　いやいや、これはこれで良し。ファーストプレイのとき、彼女が助かるエンディングがあるに違いないと、必死になって探したことがある方なら。

　空の少女にとらわれていたのは、実はわたしだったのかもしれない。これで憑き物が落ちた気分。これでようやく救われる、ありがとう。AIR、全2巻、知ってる方だけにオススメ。

要求仕様戦争（その4）

■開発工程をどうこうする――「要求開発」というフェーズを設ける

　いったい何が作りたいのか?――この問答を真摯に行う作業がすっぽりと抜け落ちている。仕様凍結ギリギリまで曖昧なままにしておこうとする顧客と、早い段階で仕様をFIXさせてしまおうとする開発側の、両方から引っ張られ、要求仕様決めが考慮されていないのが実情。

　これまで後工程に埋め込まれ、属人的に処理されている「仕様のカケラから要求を復元する作業」「経営課題から要求まで洗練する作業」に名前を付けよう。それだけでなくその作業を一つのフェーズとしてキチっと定義しよう…そんな提言を行っているのが要求開発アライアンス[参照]。

　例えば、システムをいかに効率的に作るかについては、開発手法、プロセス、開発支援環境が編み出され、適用されている。例えば、Eclipse はコード書きのためのツールだけでなく、テスター、QC（品質管理）、生産物、バグトレースから再利用まで、様々な立場の人に使われている。

　しかし、要求を決める方法はおそまつ。とてつもなく場当たり的に試行錯誤を繰り返して「要求」を決めている。これは「情報システム部門」を作れば解決というわけでもなく、システムを超えた業務の全体最適化を図るためには、情報システムへの要求がロジカルに導出される必要がある（情報システム部は、「システム」しか目が行かないからね）。

　いかに良いツール（Eclipse）を有していても、何を作るかが曖昧モコモコのままだったら、まともなブツができるはずがない。まちがった要求を正しく作っても仕方がない――要求開発の発想はここが原点。そこで、ソフトウェア工学技術によって体系化された方法論――Openthology の出番。これを用いて、ビジネス上の目的と整合性の取れた価値のあるシステム要求を導くことを目的とした2冊をご紹介。

■「要求開発」のバイブル

　ひとつめ。「要求開発」はズバリそのもの、バイブルを目指して編まれており、要求開発を考える上で必要な全てのトピック・手法を網羅している。

　その重要性や位置付けはとても同意できる。特に激しくうなづけるのは次の一文――要求はもともとあるものではなく、ビジネス要求をもとに合理的かつ能動的に開発すべきもの――つまり、要求分析、要求定義といった「いまそこにあるもの」ものを紙に落としたりモデリングするやり方ではダメよ、というところ。

　確かにユーザーヒアリングを通じて得られる「要件定義」には限界がある。ユーザーから聞き出した要求を明文化したり、分析したりする作業とは一線を画した、能動的に要求を開発することが必要だ――が本書の主張。

　ではどうすればよいか? その答えを出来る限り網羅しようとしている。

　モデリング手法にUMLを取り入れ、ほとんどのグラフはUMLの流用。さらに、BSC戦略マップ、問題分析ツリー、ターゲット分析モデルといったコンサル手法もおさえている。すなわち、開発者とコンサルタントの双方のイイトコ取りをしている。スタッフ部門やコンサルタントがこっそり参考にすると重宝する。

　必読は第5章。それまでの「体系化」「網羅性」をかなぐり捨てて、「要求開発を『絵に描いた餅』に終わらせないために」とある。「Openthology に魂を入れる45のポイント」と銘打って、要件定義の場の泥臭い丁丁発止や、プロジェクト立上げに絶対やっておかなければならないこと、沢山の失敗事例がコレデモカというぐらい続く。これは読んでおくべき　…まぁ、全ての要件定義フェーズに共通するリアルな教訓なんだが、Openthology に胡散臭さを感じ取っている人には良いキックとなるだろう。

■コンサルティング寄りの「要求開発」本

　さらに上流の次元での話。「戦略的要求開発のススメ」は、視座が高いから「良い」というわけではない。鳥瞰的な分、より具体性が薄れている面もあるが、これから重要になることは間違いない。

　ひとたび作り始めてしまえば、あとは「いかに与えられたモノを正しく作るか」に没頭することになり、「与えられたモノ」を論議することはない（あたりまえだ）。あるいは、昨今の開発手法論議やメソドロジーは、ほとんどといってよいほど、「いかに正しく作るか?」に全力を費やしている。しかし、与えられたモノが誤っていたなら? 間違ったものをいかに正しく作っても無意味だ、「顧客は要求を正しく表現できる」なんて寝言だろ！というのが趣旨。

　で、そのために、「要求開発」というフェーズを設けましょうという提案が続く。経営レベルの要求をITで実現するために「やるべきこと」を明確化するフェーズだ。まず、経営分析から「ビジネス要求」がアウトプットとして出てくる。「××の売上○%アップ」や「△△製品の歩留まりを○%にする」とかいうやつ。次に、それを実現するために、ITとして何ができるのかをああだこうだと議論する。それが「要求開発」というやつ。

　言っていることはごもっともなんだけれど、本書を読むと、これ、一度も動かしたことがないやり方だということが良く見える。コンサルティングメソッドをかじった抽象論が延々と続いており、そのままでも煮ても焼いても使えない。書いてる人も分かっているようで、「これからそんな戦略的なフェーズが要りますよ」と提唱をくり返す。

　むしろ、ここから真髄を素直に読み取り、自分のやり方に適用するのが賢い本書の使い方なんだろ。例えば、1コ上の要求（を併記した）仕様書にからめて、より高い（ビジネス戦略から見た「要求仕様」）とのリンケージをするとか（やりすぎ?）。

■「要求開発」というフェーズの弱点

　システムのグランドデザインを決めるフェーズにおいて、「要求を開発する」ことは、今後ますます重要視されるだろうし、その方式論がもてはやされるのも必至。コンサルタントは銭のネタとして、そして、ベンダーは要求仕様戦争の要因を回避する最終兵器として。

　しかし、経営者（意思決定者）にとってのメリットが皆無。ないことはないが、無理矢理ひねり出している後付けの理由。考えてもみるがいい。自分が経営者だとして、コンサルタントが書いた計画書がある段階で、こいつをRFPなり仕様書なりに落とすためにさらにひと手間かかる、といわれたら何と答えるだろうか?

　「要求仕様」の必要性なり必然性を確信しているのは、作り手であって顧客ではない。「デスマを回避するために必要」などとヌかしたら、顧客はきっとこう言う「期限内・予算内で、そうならないようにするのがオマエの仕事だ」と。ご紹介した2冊はこの疑問に答えていない。

　言い換えると、経営者に要求開発の動機づけをさせたSIer が勝ち、と読み取るのだ。つまり、フェーズ（期間）を新たに設けるのではなく、経営戦略フェーズにメンバを潜り込ませたり、人員増のための方便として… 等など。フェーズ、すなわち時間という概念を外しても可。例えば、要求仕様の「成果物」を出すための作業の必要性を認識させる。で、その作業への予算を割り当ててもらう。

　要は、この考え方を銭につなげられたモン勝ち。システム開発にあたり、見えてなかった本質が本書によりクッキリあぶりだされている。

東京大震災から生き残るために

　首都圏において大規模な震災が予想されているにもかかわらず、対策はお寒い限りのようだ。特に、「首都機能の一部を地方へ移転」がいつのまにか「首都移転」に読み替えられ、さらに知らぬうちに葬り去られている以上、この地はさらに混沌の限りを尽くすだろう──その日まで。だから、何も起きていない「今」その準備をする。

　同じ動機で「パパは必ず、歩いて帰ってくる」[参考]を書いたが、強化すべき点と考え直す部分がありそうだ。今回参考にしたのは「スーパー都市災害から生き残る」と「大地震──死んではいけない」の2冊。

　「スーパー都市災害」は「東京」「地震」を中心キーワードに、かつそれに固執せず、人災、風災、火災、水害なんでもござれで、来るべき日への準備から生き延びる術（と減災のための行政・企業側の打ち手）を紹介している。「サバイバル」（さいとうたかを）が「起きてしまってからどう生き延びるか」なら、これは「いずれ起きる日のために今すべきこと」が書いてある。「大地震──死んではいけない」は、さらに具体的に準備すべきことが分かりやすく紹介されている。ネットを漁ればノウハウ集は沢山あるが、網羅性・一覧性でここまでまとめたものはないだろう（電源なしで閲覧できるし）。

■備えあればうれしいな──まだ起きていない「今」すべきこと

• クツ──カイシャに履いていく靴は、なんちゃってビジネスシューズ。革靴は走れないし、長時間の歩行にも不向き。黒または茶のウォーキングシューズでごまかしている
  
• 帰宅支援マップ──「歩いて帰る」人向けのマップは常に携帯。ただし、徒歩帰宅は最終手段とする。東京は脆弱な街だが、復旧は早い。安否の確認が取れるならば、最初の72時間はむやみに移動しないほうが良い場合もある
  
• ラジオ──生死を分ける決定的なのは情報だと痛感。100円ショップで複数購入、会社や自宅のあちこちにおいておく。アバウトさ加減が良いとのこと
  
• 携帯充電器──阪神・淡路大震災の時、携帯「電話」はまず使えないが、携帯「メール」は有効とのこと。そのために充電器は必須。イザというとき、携帯はメール専用機として使うつもり
  
• ライト──地下鉄をよく利用するので、停電時には必要となる。ビル・エレベーター内、地下など、都市部は密閉空間にいる場合がほとんど。非常灯が頼りになればよいが、自助のために準備しておく
  
• 水とカロメ──普段からお茶じゃなくてペットボトルの水をたっぷり飲んでいるのは、いざというときのため。カロメともども、会社の机に常備
  
• ポリタンク、非常食、非常携行品──家庭に常備、非常食は一年に一回買いなおす（古いのは食べてしまう）
  
• 電車──先頭と最後尾車両は、衝突・追突のおそれがある。連結部やドア付近は構造上「弱い」部分。JR福知山線脱線事故からも示すとおり、電車で最も安全な場所は、車両中央部。隣の人をクッションにできる
  
• エレベーター──都の発表による閉じ込め被害予想人数は6,000名。この中に入ると、脱出までに数時間を要する。だから常にボタンの前に立つ。イザというときは全部のボタンを押してさっさと脱出する。防犯上にも良し
  

■東京大震災から生き残るために

• 最初にすること──自分・家族の安全と脱出経路を確保。そのときいる場所、時間によって最も安全な場所を確保する（それを念頭において普段から行動する）。机の下、クッションをアタマに、買い物カゴを被る、ドアを開ける（柱が傾くと開かなくなる）、非常口を確保する…
  
• 次にすること──安否の確認。171、i モード災害用伝言板、電話は輻輳必至。イザとなれば張り紙で。非常時の公衆電話はコインなしで使える（場所を確認）。安否の確認方法は予習・シミュレートしておく
  
• 情報と判断が必要なこと──帰宅難民になること必至…だが、本当に帰宅する必要があるのか? 安否確認が取れている、帰宅ルートの被災状況が不明なら、その場所にとどまって救助・復興活動に協力したほうが結果的に吉
  
• 常にアタマにとどめておくこと──あきらめるな。けれど数珠はいつもポケットに
  

　これらの発想は防災ではなく減災。災害を「防ぐ」ことなんて土台ムリ。起きてしまった被害を最低限に抑えるための準備を、今からしておく。しかし、起きたことには祈るほかない。だから、毎朝会社に行くとき、数珠は、今でも肌身離さず持っている。

欠陥上司が部下を殺す

　上司に恵まれなかったら「オー人事」は古いか… 今じゃ上司次第で部下が死ぬ。冒頭、冗談ぬきの事例が紹介される。「むごい」というしかない。仕事を続けるのにソコまでしなきゃならんのか、と言いたくなる。だけど、追いつめられた本人はそこまで考えがおよばない。

　「心の病」が増加しているという。成果主義への移行、派遣社員・正社員の責務差、IT偏重の業務、組織のフラット化による若年管理職… など、要因はいくらでも思いつく。ストレス社会は今に始まったことではない。にもかかわらず、特に最近、急上昇している原因は上司にある、と筆者は断ずる。「こんな上司が部下を追いつめる」は、部下を生かすも殺すも上司次第という。これは同意。しかし、そろそろ課長クラスを担うようになるバブル入社組をヤリ玉に上げるのはカワイソス(´・ω・`)

　「こんな上司」とあるが、どんな上司が部下を追いつめるのだろうか?

1. 部下は使い棄て、育てるつもりがない
   
2. 保身的で自己分析ができず他人のせいにする
   
3. 窮地に追い込まれている部下をサポートしない
   
4. 仕事の目的や構想を語らず、作業のみを与える
   
5. 独断的で部下の意見に耳を貸さない
   
6. 目線が下げられず部下の気持ちを想像できない
   
7. サークルのノリで外れた部下を仲間外れにする
   
8. 困っている部下をサポートしない。質問に答えない
   
9. 叱りベタ・怒鳴り散らす、叱れない・見て見ぬフリ
   
10. 部下の特性を考えず、一律ノルマを課して数字管理
    

　んー、どの世代にも「こんな上司」はいるような。

　ほんとうに、こんな上司が増えているのだろうか? そうは思えない。ただ、心の病を抱える社員が増えていることは事実。そして、上司・部下限らず増えているのも、事実。著者は課長クラスに「問題アリ」と烙印を押しているが、課長は課長で押しつぶされている現実はきれいに除かれている。

　昔は、仕事そのものよりも、部下のケアに心を砕いていた上司が多かったのではないか。そして今は、仕事をこなすだけで精一杯で、そんなゆとりがなくなったのかもしれぬ。今の上司をヤリ玉に上げるより、会社のあり方にメスを入れるべきじゃないかなー、などと思ったり。

　犯人探しは著者と意見を異にするが、部下のメンタル面に気を配るべきなのが上司だ、という点においては、大きく頷ける。上司の「気づき」がたいせつ。部下から相談を持ちかけられたとき、上司はひたすら傾聴に徹せよ、と言う。激しく同意。

　その際、絶対に口にしてはいけないセリフ5は以下のとおり。

1. がんばれ
   
2. 逃げちゃダメだ
   
3. もう一度、考え直してみないか
   
4. もう少し、続けてみないか
   
5. マイナス思考や弱気はやめよう
   

　うん、確かに言ってはいけない。この辺については、「ITエンジニアの心の病」[参考]で予習した。末尾にそれを記す。IT業界に限らず、欠陥上司（欠陥顧客も含む）に当たったとき、眠れない日々が続いたとき、次の文を思い出して欲しい。

　心の問題は、自分の問題ではない。プライバシーや世間体や気恥ずかしさから、「自分の問題」として囲わないこと。「自己管理は社会人の常識」は二日酔いの顔に言っていいセリフだが、自分に向けるとき限りなく残酷な桎梏になる。だから、もう一度言う、「心の問題は、自分の問題ではない」って。

エロ文学「眠れる美女」で匂いに悶える

　ええ、もちろんエロオヤジですよ。エロ大好きだけど「エッチ」はいただけない。わたしゃヘンタイじゃない。それでもヘンタイに限りなく近いところがエロの極意であることを悟りつつある今日この頃なので、その辺で良さげな作品をピックアップしてみる。

　今回は川端康成「眠れる美女」。

　ひとことで表すなら、「これはエロい」だな。

　ひとことで喩えるなら「マンガにするなら陽気婢で！」だな。

　挿入も濡れ場も無し。にもかかわらず、動機がエロい、描写がエロい、展開がエロい、オチが○○、完全無欠、逃げ場無しのエロさ。ノーベル文学賞だかなんだか知らないけれど、この人の作品を教科書に載せていることがエロくて顔真っ赤にして反撃したくなる。川端康成といえば「掌の小説」がいいなぁ、と思っていたが、こんなにエロい（当時の用語では退廃：デカダン）のを書いてたなんてっ。

　白眉なのは匂い。小説読んでて「匂い」をこれほどまぢかに感じ取るのは珍しい。おんなの生々しい匂いなら他の小説でかいだことがあるが、濃いきむすめの匂いをシミュレートできるのは本書だけ。女の本質は匂いだ、と言い切るわたしにとって、おもわずガシッと握手したくなる。確かに、薬で深い眠りに陥った美女たちとコミュニケートするには、匂いでしかない。こちらは○○したり△△したり、いろいろできるだろうが、その反応といえば… やはり匂いだろう。

　エロを追求している読み手に、ふと老いの本質に迫る文章が突きつけられる。みずみずしい裸の肉体をそばにすると、老いは、より対照的になる。

娘はただ金ほしさで眠っているだけにちがいない。しかし金を払う老人どもにとっては、このような娘のそばに横たわることは、この世ならぬよろこびなのにちがいない。娘が決して目をさまさないために、年寄りの客は老衰の劣等感に恥じることがなく、女についての妄想や追憶も限りなく自由にゆるされることなのだろう。目をさましている女によりも高く払って惜しまぬのもそのためなのだろうか。

　世界最高のコストパフォーマンスを誇る日本の風俗業は、介護産業をしのぐだろうな。その際、このような「ニッチ」な添い寝サービスもありうるな、と半ば冗談でも思わせられる。

　しょっぱなからして誘うような文章。お気に召したら、召し上がれ。

たちの悪いいたずらはなさらないで下さいませよ、眠っている女の子の口に指を入れようとなさったりすることもいけませんよ、

要求仕様戦争（その3）

■仕様書をどうこうする――「要求」の見える化

　「要求を仕様化する技術・表現する技術」がオススメ。「要求とは」「仕様とは」からはじめて、仕様戦争までの経緯、回避するための具体的施策までが分かる。「Excel を用いた仕様書」はなかなか興味深い。

　著者は「要求」と「仕様」の関係をロジックツリーに見立てる。こんなカンジ。仕様1～n を実装すれば要求Ａが実現する、という仕掛けだ。

┌───┐
│要求Ａ │
└┬──┘
　 ├─仕様1（スペック1-1,1-2,1-3...）
　 ├─仕様2（スペック2-1,2-2,2-3...）
　 ├─　…
　 └─仕様n（スペックn-1,n-2,n-3...）

　まぁ、こんなにキレイにならないだろうが、「このスペック（群）で"やりたいこと"は実現していると言えるのだろうか?」という視線が、どのフェーズでも配れるという点は素晴らしいと思う（実際に目配りするかどうかは別として）。

　本書のポイントは、「仕様書に要求"も"書け」に尽きる。つまり、仕様書に「スペック」だけ書くなと。「要するに何がしたいのか＝要求」も併記しろとしつこく主張する。なぜか?

　なぜなら、要求は「その仕様になった理由」を表すから（←超重要）。だから、要求とセットで仕様を検討することで、仕様モレは防げる。「その要求を実現するためにその仕様で必要十分か?」 という視線がつきまとうから。ホントのところ、実装フェーズになったらそれどころじゃないって、確定仕様をコードに落とすのに精一杯で、見る箇所も極めて狭い範囲に限られている。それでも仕様書を見る度に要求が目に入れば、「この仕様だけで要求は実現できる?」という問い直しをすることになる。言われたとおりに書いたはいいが、やりたいことは結局できませんでした、という悲しいよくあることは、これで、無くなる。

　あるいは、仕様の衝突を事前に察知→顧客レベルで回避する。仕様の衝突の根本は、要求の衝突だからだ。その場合、どちらか、あるいは両方の「要求」が曖昧性を含んでいる。要求を仕様に分解するのではなく、要求をロジカルに分解する。これにより、仕様化する前に要求同士で矛盾を起こしていることが「見える」ようになる。そうなればシメたもの。

　どっちを仕様を優先するかは、どの要求を優先するか、の議論になる。A担当の「要求A」とB担当の「要求B」で決める話。ひどい場合は、A担当が先月言った「A要求」と、昨日言った「A'要求」との衝突。Aさんに判断してもらえるよう「要求の見える化」をしよう。道理が引っ込む無理な要求の狭間で苦しむことは、やめよう、仕様バグの温床だ。

　しかし、一つのドキュメントに「要求」と「仕様」が混ざると分かりにくい、といった弊害が出てくる。あるいは、仕様書を開くと要求が見えるため、オーバースペックになる恐れがある。著者に言わせると、これを回避するための「Excel仕様書」だそうな。「要求」の階層と「仕様」の階層を分けて記述するところがミソ。Excel のオートフィルタを使えば階層ごとの表示／非表示をコントロールすれば問題解決。詳しくは本書で。

■「要求の見える化」の実践と効果

　その実践。Excel で仕様書は邪道じゃーと思っているので、著者が推奨するExcel 仕様書は作らなかったが、要求を念頭においた仕様管理は確かに効果があった。チームメンバーにこう周知したのだ→「顧客へのレポートの先頭、仕様書の各セクションの冒頭、ソースヘッダコメント、さらにメモ／メール／ホワイトボードに至るまで、関係する"要求"を必ず書け」ってね。そして、要求は「○○をするために…」という表現形式でロジックツリーで分解せよとレクチャー。

　その結果、変わったのは、ペーパーではなく、質問のやり方。曰く

　　　「この機能が実現すれば、本当に○○要求が実現したことになりますか?」

　　　「やりたい○○が曖昧なため、△△機能は追加仕様がありますね」

　　　「○○をやるにあたって、足りないスペックはありますか?」

そして極めつけが、プロジェクトに火がついてケンアクな雰囲気で出てくるセリフ、

　　　「とどのつまり、何がしたいのでしょうか?」

が、かなり早い段階で（したがって比較的なごやかな空気の下）、お互いに口にするようになった。これは進歩。

　これまで、部分的に五月雨で放り出される「仕様」をキャッチして、ジグソーパズルのピースを当てはめるように組み上げていたものが、最初に「やりたいこと」を念頭におきながら作業を進めるようになった。もちろんモレは絶滅したとは言わないが、行き違いは格段に減った。さらに、仕様がぶつかりそうなとき、その仕様が支えている要求どうしを並列して見せることにより、顧客に優先順位付けをしてもらえるようになった。

　冒頭の質問例になぞらえると、こんなカンジになる。

┌─────────────┐
│身長57メートル体重550トン　　│
└┬────────────┘
　 ├─素材（超合金）
　 ├─横幅（?）
　 ├─　…　　←←←←ココ★
　 └─動力（超電磁）

　…このやり方だと間違いなく★で取りモレが出るだろう。プロジェクトの途中で超電磁ヨーヨーの「要求」が挙がったとしても対応できるだろうか?

┌────────┐
│汎用人型決戦兵器│
└┬───────┘
　 ├─汎用（陸・海・空、メンテナンス、パイロット）
　 ├─人型（スペックサイズ）
　 ├─決戦（使徒撃退?第3新東京市防衛?、勝利条件）
　 └─兵器（敵の定義、戦闘方法、装備）

　…このやり方だと、それぞれのノードからさらに要求が定義され、要求のブレークダウンによりスペックが決まってくる（当然、エヴァ単体を作るだけでは意味がなく、チルドレン、セントラルドグマ、マギ、第3新東京市そのものを準備・運用・メンテナンスする必要が出てくることが分かる）。さらに、人類補完計画は想定外の運用であることも見えてくる（顧客は誰かにもよるが…）

　本書のやり方をそのまま適用できるかは分からないが、考え方は非常に使える。経験を積んだ方なら「そんなのアタリマエじゃねーか」ということばかりあるし、あるいは身につまされるエピソードが多々あるかもしれない。しかし、著者の主張・方法を知るにつれ、「わたしならこうする！」というアイディアが必ず浮かぶ。読んで分かった気になってオシマイという無駄本と違い、本書を読むと何らかの具体的アクションができるはず、しかも自分の中から湧いてくる、そういうスゴ本。