西の善き乙女はDO MY BESTでしょ?

　スゴ本。すげぇ面白かった。今年読んだイチオシ→「西の善き魔女」。page turnerならNo.1。文字通りページを繰る手ももどかしく読了。オススメしてくれたのは嫁さん。前回の「ダレン・シャン」もそうだが、嫁さんのオススメは外れがない…極上の面白さをありがとー。

　本書を一言で片付けるなら○○○・○○○○○ーになってしまうが、そういう話で満足したらもったいない。

　最初は主人公である美少女フィリエルの身になって、ひたすらハマれる…

• 運命に翻弄されるままをハラハラドキドキするもよし
  
• ラブコメちっくな展開に萌える女の子の気分を味わうもよし
  
• 百合百合できゅあきゅあな展開に身もだえするのもよし
  

　世界設定をしっかり考えて書いているので、読み手の楽しみ方はいろいろ。第1巻目の感想は[ここ]に書いたが、じゃぁ、ただのそういうお話かというと、かなりちがう。実は、この物語の素晴らしさはもっと深いところに根をもつ。

　面白さと深さは保証する。「何か面白い本ない?」んなら、こいつを強力にオススメしよう。以降、未読の方でもネタバレにならないように書くが、読了してからの方がより興味深いと断っておく。

* * *

　ファンタジーを読み進めるうち、ある疑問をが出てくる。それは、「世界の意義」という命題。推理小説なら「後期クイーン問題」だが、ファンタジーの場合なら「釈迦の手の孫悟空」問題だろう。

　ファンタジーの主人公は忙しい。運命に抗ったり、奇跡を目の当たりにしたり、強大な敵を打ち倒したり。そして、物語として面白ければ面白いほど、エスカレートしてくる。

　しかし、どんなに主人公が強くなろうとも、どんなに奇想天外な展開になろうとも、ファンタジーの中のキャラクターは、物語で設定された枠を越えることができない。孫悟空がいかに強く、速く、賢かろうとも、釈迦の掌から降りてまでして西遊記を続けることができない。

　その話にハマればハマるほど、読み手（＝現実世界）との距離感が希釈され、ページをめくるときに浮かぶ疑問、

「このあとどうなるのだろう?」

が、

「なぜこの世界なのだろう?」

に変化する。実は二つの疑問は同義なのだが、読者は二つ目の疑問を問うてはいけないのだ。良いファンタジーは、二つ目の疑いが浮かんでくる前までに物語を終わらせる。最高のファンタジーは、二つ目の疑問の秘密を自ら明かす。つまり、その物語最大の謎「なぜその世界なのか」を物語そのもので答える仕掛け。

　作家がはまる陥穽はまさにここ。世界を規定せずに書き始めた結果、話がエスカレートしてくると、どうやって世界と折り合いをつければよいか分からなくなる。酷い場合は、途中から趣旨替えして、メタ世界や「最初に戻る」オチにしてしまう。そんな話では無かったのに… これは夢オチに等しい裏切り。

　「十二国記」はその好例で、明らかにカミ（?）の意思が加わっている世界を描きながら、陽子をその存在と同列にまで持ち上げている。このままだと、陽子＝世界にして終わらせるか、陽子 vs カミ という神話にするほかなくなってしまう。今から○○○・○○○○○ーに転向したら一部ファンから暴動が起きるかも。あるいは胡蝶の夢か。

* * *

　意図してやっているのか、筆者の望む展開にキャラを合わせようとするあまり、「いいひと化」しちゃっているのが非常に残念。邪悪なものは邪悪に、厳かなものはそれなりに書き分ければよいものの、巻が代わるとキャラが変わる。この相対化のおかげで毒素がずいぶん減ってしまっている。

　どうしてもオーバーラップしてしまうのが現在進行中の「舞-乙HiME」（アニメの方）。蒼天の青玉やガルデローベ学園、隠されたプリンセスといった設定だけでない。まだ明かされていない仕掛けそのものが同じような予感が。ストーリーは全然違うが、どう見ても「西の善き魔女」を読んでいるとしか思えない。

　萌え萌え学園生活編から打って変わった鬱展開。目が離せない。いっぽうアニメ「西の善き魔女」は2006.4から放送開始。「舞-乙HiME」はオタむけ深夜アニメだが、こっちには『腐女子向け』のレッテルが貼られた乙女アニメにならないよう切に祈る…んが、東京MXテレビ土曜17:00～の『地獄少女』の枠？

徹夜を覚悟する小説

　初読の作家でも読み始めると分かる、「こいつは徹夜を覚悟しないと」。前評判や導入部の『つかみ』、そして本そのものから立ちのぼる『におい』としかいいようのない予感から、冒頭の覚悟に至る。

　さらに読み進めて気づく。あのとき感じた、 ああ、予感は本物。眠気も吹き飛ぶ面白さ。明日の予定そっちのけ、この瞬間こそ全て。「スゴ本＝すごい本」を血眼になって探すのは、この、読みながら吼えたくなる喜びを味わうため。

　ええ、ええ、もちろん「ダ・ヴィンチ・コード」読んだのさ。もう無我夢中でイッキ読み。テーマは「暗号＋歴史＋陰謀」を重厚に描いているにもかかわらず、文字通り「読むジェットコースター」、幸せな数時間を過ごしたのでありました。

　謎を解く鍵がフィボナッチ数列だったり黄金比だったり、どこかで聞いたことがあるトリビアが散りばめられており、読み手も一緒になって楽しめる。特にこの小説の表紙「モナ・リザ」の真の意味を知ったときはおおおおっと雄たけびをあげてしまった。

　このテの小説で気をつけなければならないのは、薀蓄と展開の配分。分量を間違えるとただのトリビア集と成り果てて、「作者は頑張って調べたんだね、えらいね」という感想しか出てこなくなる（←何を指しているのかお分かりかと思うが、京極"弁当箱"のことなり）。

　徹夜を覚悟し、その期待を裏切らない小説。ここでは、「ダ・ヴィンチ・コード」に敬意を表し「暗号＋歴史＋陰謀」モノで徹夜を覚悟した小説をご紹介。

* * *

　まず「薔薇の名前」。舞台は中世ヨーロッパの修道院。連続変死事件ミステリを縦軸、キリスト教神学をベースとした知の探求の成果物を横軸にして、薀蓄の仕掛けに巻き込まれること請け合い。

　人類の知の体系を小説仕立てで再構築しようとする試みなのか、読んでいてクラクラする。徹夜を覚悟した小説だけれど、あえなくダウン。メインの連続変死事件の話よりも、キリスト教神学体系（とそこから派生する有象無象の芸術・文化群）に振り回される。結局読み終えるのに1週間（プラス知恵熱）。

　スゴ本とは何ぞや? 「薔薇の名前」のことなり（思い出してて再読したくなってきた）。

* * *

「フリッカー、あるいは映画の魔」の一節。芸術についての至言。こいつを頭の隅に置いて読むと面白いというよりも恐くなる。「ダ・ヴィンチ・コード」でも同様。

　　　芸術はすべからく隠蔽することにある
　　　芸術家はつねに表層下で仕事をする
　　　それが人びとの精神にくいこむ唯一の方法だから

　　　―― マックス・キャッスル

　無類の映画好きジョナサンがとり憑かれた魔物、その名はマックス・キャッスル。遺された彼の監督作品はどれもこれも、超絶技巧な映画だった… ジョナサンは彼の究極映像を追い求めるのだが、それは悪夢の遍歴なのかも。

　この主人公がウラヤマしい～と思わない映画ファンはいないだろう。もう好きで好きでたまらない。映画狂が昂ずるあまり古いながらも劇場を手に入れ、映画三昧の毎日。さらに、ベッドの上でカリスマ女流評論家から映画の理論的考察と濃厚なセックスの手ほどきを受け、助教授まで出世する。「映画で食っていく」なんて、映画好きなら誰しも夢想した未来。

　映像美のディテールがまたスゴい。観てきたように緻密に描写されているから、読み手は「マックス・キャッスルの映画観てぇ～！たとえ悪魔に魂を売ることになったとしても」と吼える…で、ラストの"究極の映像"に身もだえするだろう。

　…ああああ、このネタを振るときは、デイヴィッド・マレルのアレを挙げたい…のだが、スーパーネタバレになるので、言えねぇ… 両方とも読んだ方ならピンとくるはずだし、片方しか読んでないなら激しくネタバレだし。

* * *

　「薔薇」も「フリッカー」もボリュームがハンパじゃない。徹夜を覚悟しても翌朝までにはとても読みきれない。一方、「千尋の闇」は徹夜を覚悟し、徹夜で読んだ。文庫上下巻で800頁超だが、やめられない止まらない。「薔薇」「フリッカー」は納得して力尽きることがあろうが、こいつはちょうど完徹できる分量。翌日は休日であることを確認してから頁を開くこと。

　50年前に謎めいた失脚を遂げた、ある青年政治家の手記を読む主人公の『背後から』、この小説を追いかけることになる。このメタ構成を最初にして、さながら万華鏡のように変転する。読み進める毎に、『戻って』読み直したくなる。

　物語が二重底、三重底になっている。部屋の中に部屋があるような奇妙な感覚に陥る。この目くるめく感じがたまらない。この手記に囚われる主人公同様、読み手もどんどん深みにハマる。頁が尽きてくると「終わらないでー」と何度も呻きながら読んだ。

* * *

　明日の予定そっちのけ。眠たくっても、怒られても、トシをとっても、やめられない。なんにも知らない頃に戻って、読みなおしたい夜もたまにあるけど、あのとき感じた気持ちは本物。いま、わたしを動かすのは、スゴ本。

ウォーターフォールはこう使え（まとめ）

　この連載を始めたのは、Waterfall 2006を見たから。ついカッとなって書いてしまった。今は反省している。この連載は体系的じゃないし、blog よりむしろ出版物の形で問うべき。何よりも、今週の睡眠時間を大幅に犠牲にしてきたので、眠くてたまらん。

　…というわけで、ここでは総括＋補足して締める。

* * *

　ウォーターフォール・モデルとは、プロジェクト構造化モデルと言い換えられる。その特徴として、以下のことが挙げられる。（その1）

1. プロジェクトを構造化し、段階を踏んで要素成果物を構築する
   
2. 次に、必要な要素成果物を適切なタイミングで持ち寄り、組み上げる
   
3. 要素成果物を構築する工程はスパイラル・モデルを適用できる。しかし、組み上げる工程は逐次的であることが求められる
   

　プロジェクトを構造化することにより、プロジェクトを「見える化」できる。全体と部分、出来てるところと空白のところが分かる。未確定事項がオープンになり、ベースが明らかになるのでそこへの変更が「変更」として管理できる。（その2）

　クリティカルパスによく乗っかりがちな「仕様の確定」は、日付を決めることで現実的なものにする。契約前はペラペラだろうし、プロジェクト終盤では遅すぎる。だから、契約直後になんとしてでも形にする。そのためには、プロジェクト序盤で、「仕様が明確化されていない」事実を顧客自身の口から言ってもらう。（その3）、（その4）

　責任問題となったとき、最終的にプログラマを「守って」くれるのはドキュメント。プロジェクトが傾いたとき、その建て直しの土台となるのがドキュメント。ソースから自動生成できるが、全部読んで理解することを顧客に求めるのは無謀というもの。ドキュメントとは契約書だと意識すること。（その5）

* * *

　変更、特に仕様の変更について。ウォーターフォール・モデルで「変更」は別ライン、すなわち未来日の peak で受け渡しを約束する別チームが対処する。

　そのためには、リソースを新たに割り当てなければならない。これを嫌がるPMは現在のチームでその作業をさせようとする（←これが間違い）。その結果、現行チームの能率が大幅に低下し、クリティカル・パス上の神輿のスピードが落ちる→未来日の peak に間に合わなくなる… という悪循環がある。

　一方、きちんとリソースを割り当て、別チームが出発できれば、これほど理想的に働く方法はないといえる。なぜなら、未来日の peak で現行チーム・別チームが合流するようコミットできるからだ。ウォーターフォールでマイルストーンの「日付」にやかましいのは、その日をプロジェクト全体として保証するため。「次」はもうないのだ。

* * *

　ウォーターフォールとスパイラルの役割分担について。プロジェクト全体を俯瞰し、マスタースケジュールを粛々と実行するのはウォーターフォール、個々の「すべきこと」を割り当てられたチーム内で実行するのはスパイラルが適している。

　つまり、マイルストーン＋成果物のマネジメントはウォーターフォールで、「方式」や「業務」で、peak とチームが割り当てられた中ではスパイラルで回すほうが良い結果を出している。契約のコミットが求められ、後戻りができないものはウォーターフォール、ある程度分解された目標をクリアするにはスパイラルが良い（と経験的に知った）。特に「方式」のネットワークやデータベースアクセス、部品の開発にはスパイラルが最適。

* * *

　わたしはウォーターフォール信者ではなく、アンチ・アジャイルというわけでもない。ウォーターフォール・モデルでのプロジェクト経験が多かったというだけ。良いウォーターフォール悪いウォーターフォールの双方ともに、沢山の knowledge を積んできている。だから、危機に陥ったときどうすればよいか適切に判断できるし、そもそも酷い目に遭わないようにするには何を準備しておくべきなのかも身をもって知っている。

　フシギなことが一つある。スパイラルであれアジャイルであれ、RUPでもいい。世に問われてから随分と時間が経っているが、knowledge は積まれているだろうか? 偉大なるグルの著作物のことではない。ありゃ"教科書"だ。そうではなく、実践において結果を積んでいるだろうか? 単なる「プログラミング＋アルファ」のレベルを超えて、プロジェクト全体を任せられるものとして育っているのだろうか?

　プロジェクト全体を任せた事例があるなら、紹介してほしい。断っておくが、「実験的なプロジェクト」や「どっかの研究室が主催したやつ」ではない。また、一度きりではなく、繰り返し（＝spiral）実践で培った事例だ。10年以上前、まだ「オブジェクト指向」が手垢にまみれてないときから、ずっと探してきたが、いまだに見当たらない。

* * *

　また稿を改め、ウォーターフォールならでの事例を紹介してみたい。あるいはもっと体系的に書き直すべきかも。いずれにせよ、次回からは「スゴ本」の紹介に戻るとしよう。

ウォーターフォールはこう使え（その5）

　ウォーターフォールの怨嗟の的になっているのは「ドキュメント」だろう。使うかどうかも分からぬような大量のドキュメントを書かされる。しかも顧客の一言で大幅に書き直しを命ぜられる。さもありなん。だが、ここでは、ウォーターフォール・モデルにおけるドキュメントの必要性を強調する。

* * *

ドキュメント＝契約書

　なぜドキュメント化が嫌われるのか?

　SEの立場から言うと、ちゃんと検討していないまま、「とりあえず」ドキュメント化をさせられるから（結果、後から手直しが多発する）だろう。PGの立場からすると、理解してコードに落とすだけの内容を、なぜ語弊の出る日本語に書き直さなければならないか、疑問に思うだろう。

　本当の問題はSE/PGがドキュメントを書いていること。あるいは、片手間にドキュメントを書いていることをなんとかすべき。本来なら専門部隊を準備するか、リソースを明示的に割り当て、執筆期間を設ける必要がある。

　これを理解しないまま、ドキュメント排斥を追求すると、思わぬところで足をすくわれる。例えばトラブル。巨大システムもjob sequenceひとつ間違えただけで全面停止になることがある。アナタのアウトプットが起因でトラブルが発生した場合、誰が守ってくれるのか?

　じっさいそういう場面に出くわせば分かるが、誰もアナタの仕事の正当性を保証してくれない…ていうかできない。イザとなったら自分の身は自分で守らないと。そのときの命綱がドキュメントだといえば、少しは怖がってもらえるだろうか。

　「ドキュメント要りませ～ん、開発現場に顧客が同席しているから」

　「動くプログラムから仕様書を自動的に作るから問題ありません」

なんて、どこの研究室の話ですか? あるいはどこの実験「だけの」プロジェクト? とツッコミたくなる。

　顧客はごく少人数で、サービス開始後も同じ開発者が傍らですぐ控えております、なら分かるが、そんなわけない。"顧客"の背後に控えているおおぜいのオペレータの視線を感じたことがないか。目の前の"顧客"を口頭と目視で納得させればOKだなんて、ムシがよすぎやしないか。

　あるいは、ソースから生成した日本語として体を成していないクソ資料を全部読んで理解して、かつ「承認」してくれる顧客がいるならともかく、そんな人間すらいない…ってか「ソースコードが仕様書です」と本気でいう奴はソースから生成したドキュメントを読んだことがあるのか? と問いたい。自分が書いたやつだけでなく、"全部"だ。あれは開発や保守で大づかみに理解したりするために使うんだよおぉぉ。

　ドキュメントを軽視した結果、土壇場になって「オレはそんなこと言ってない、証拠を見せてみろ」と手のひらを返されたことが一度でもあるならば、おいそれと↑のようなセリフは吐けない。ドキュメントとは契約書なのだから。

* * *

ドキュメント＝チーム間の橋渡し

　顧客とベンダとの契約書になるだけではない。チーム内、チーム間の橋渡しの役割もある。アナタが書いたドキュメントは、ひょっとして一度も日の目を見ることがないかもしれないが、必要なときは是が非でも必要となる。

　デスマの火消しに投入されたことはあるだろうか。ウォーターフォールを採用したプロジェクトが燃えている場合、最初に渡されるのが莫大な仕様書（あるいはその残骸）だ。古文書を読み解くが如く、そいつに喰らいつくのが最初の仕事。んで、プログラム動作との Fit/Gap を見つけるのが次の仕事。

　このドキュメント（のあるべき姿）と、目の前で燃えているコード（もしくはテストシステム）の差に対し、3つの切り口がある。

• コードをなんとかして、仕様書どおりに動かす
  
• 仕様書を書き換えて、コードの振る舞いどおりに直す
  
• 動かないところの仕様書を切り離す（段階的にリリースする）
  

　んで、優先度が高い順に財布とカレンダーをにらめっこしながら、コードを書くのかドキュメントを直すのか、あるいは仕切りなおしさせてもらうのか、を選び取るわけだ。

　一方、ドキュメントをちゃんと作っていないプロジェクトが燃えた場合、最悪のことが起こる。

　即ち、「何が本当か分かりません」だ。ソースなのか仕様なのか、誰が本当のことを知っていて（決断できて）、誰がそれを知るべきなのかがぐちゃぐちゃになる。どのチームに影響が出るか分からないから、ミーティングは全員参加、全員周知になる。ソースの修正による影響も特定できないため、全員周知となる。ペアプロじゃなくって全員で同じコードをプログラミングしているようなもんだ。

　いまだに「ソースコードが仕様書です」を胸張って言うプログラマを見かけるたびに、マイクロソフト・ジョーク「それは仕様です」を思い出してこっそり笑わせてもらっている。

ウォーターフォールはこう使え（その4）

決めるべき2つの日どり

　二つ目の戦略。それは「日どり」だ。「あいまいな仕様」が"今は"決まってないことを顧客自身の口から言ってもらった後は、何月何日までに仕様凍結するかプロジェクト全体のスケジュールの中で顧客と決める。「仕様の再確認」ができていない以上、そいつができる日はいつなのかを決める。

　こいつを最初に決める。ここを過ぎると挽回が不可能とうい点「ポイント・オブ・ノーリターン」を"今"決める。ここまでギッチリ動機づけしておけば、仕様凍結の最大の脅威「先送り」を回避できる。

　あるいは、こっちの方がもっと重要なのだが、「仕様凍結を先送りしている事実」を共有できる。極端な話、仕様が凍結されていないのが問題なのではない。仕様が凍結されていないことが公になっていないまま、先へ進んでいるほうが深刻なり。

　表向きは仕様は固まっているはずなので、顧客からは口頭や電話だけで「指示」がくる。当然、仕様書は書き直さないので、仕様変更ではないと判断される。あいまい仕様に対し、顧客へ問い合わせする度に「固まっているはずの仕様」がずんずん膨らんでくるので、いつしか訊かなくなる。んで、代わりに「自分で考えて」実装するわけだ。

　問い合わせる度に「口頭での」仕様が膨らむ
　→確認する代わりにSE/PGが自分で明確化・実装する
　→"こんなの作れって言ってない"と罵倒される

　この悪循環をモトから絶つわけだ。つまり、「現在仕様は凍結されておらず、○月○日に確定する」と顧客を巻き込んで宣言する。（その1）で書いた「peak に到達する日」を顧客にもコミットしてもらう。スパイラルでもOK、「その日」までに何回くり返すかだけの話。

　その一方で、もう一つの日どりを密かに決めておく。もう一つの日を知っているのはPMとシニアマネージャだけで良いが、必ず決めておく。

　その日とは、「最悪の事態に陥った場合、納期延期を申し入れる日」のこと。プロジェクトにとって重要な日は納期ではない。納期に間に合うように努力と工夫を重ねるのだから、間に合って当然。大事なのは、そうならないことが分かったとき、いつまでがギリギリといえるのか? ということ。

　プロジェクトが燃えさかってくると、「その日」のことが脳裏にちらつき始める。納期より手前であることは分かっているのだが、それが1週間前なのか、1ヶ月前なのかが見当がつかない。だから火事場で顧客とハラの探りあいなんて阿呆なことをしだす奴が出てくる。

　こいつを回避するために、最初に決めておく→「ダメなときお客さんにゴメンナサイを言う日」。そうすることで肝も据わるだろうし、火事場になったとき、「その日」に向かって、今度は回避・低減・転嫁するためにすべきことに準備できる。

　顧客だってそうだ。なんだかヤバそうだぞと見ていると、ギリギリになって「結局できそうもありません、どうしたらよいですか?」と来られても困る。ダメになったことに言いたいことは沢山あるだろうが、ダメならどうする? を考えて来いと。「ゴメンで済んだら警察いらない」はガキの使いやあらへんで。

　だから、いざとなったら、「その日」に向かって準備ができるよう、「その日」を決めておくんだ。ダメになりそうな要素は見えているもの、見えないものと沢山あり、プロジェクトの最初から準備しておくことは難しい。しかし、「すべきこと」が洗い出され、プロジェクト・ベースラインがあれば、「その日」を決めることは比較的たやすい。

* * *

決戦は月曜日

　戦略は2つある。「仕様の再確認」と「2つの日どり」だ。どちらにも共通するのは、ゴールまでの作業スケジュールを逆算した"日"、すなわち時間を味方にしているところだ。

　ほとんどのSE/PG/PMにとって、時間は脅威以外のなにものでもない。なぜなら、プロジェクト終盤になると、カレンダーを片手に顧客やシニアマネージャーが迫ってくるから。窮すれば鈍す。「時間」や「スケジュール」とは、"追い詰められるもの"というイメージが強いんじゃなかろうか。

　ところが、開始直後では、むしろ「時間」は味方になる。「今、決めておかないとゴールできません」と最初に宣言しておくことで、時間の刃を顧客のシリに突きつける。もちろん"現時点で決まっていない"ことは顧客自身の口から言わせておく。

　この戦略が可能たらしめているのは、「すべきこと」が洗い出されており、かつ、その行程と peak （＝マイルストーン）が見えているから。「何故、いま決めておかないとできないのか」と顧客は必ず切り返す。そのときこそ、「すべきことの結果」（＝成果物）とマイルストーン一覧を示すとき。「成果物」と「マイルストーン」はこうやってオープンにして、顧客を巻き込む。最初にだ。

　おわかりいただけたと思うが、決戦地はプロジェクト開始直後なり。"決戦は金曜日"ではない。夢を真実にしたいんなら、最初に全力を尽くすべし。にもかかわらず、序盤を部下に任せっきりで、終わりのほうになって火事場になると大声と体力勝負で、いかにもリーダーシップしてまっせというPMがなんと多いことか。

ウォーターフォールはこう使え（その3）

　ちょっと思い出して欲しい。次の弾丸が飛んでくるのはいつだろうか?

　　「すでに決まったはずではないか」
　　「そう読み取れるではないか」
　　「いまさら言われても困る」

　よい子のみんなはもちろん分かってる。納品が間近に迫ってきたときだね。品質がアレなのか、そもそもマトモにできていないことが明らかになったか、トリガーは様々だけど、たいていはプロジェクトも終盤になってそんな弾丸が飛んでくる。

　これは「仕様のあいまい性」を先送りしてきたツケだ。実はこの弾丸、プロジェクトを通じて3度発射する機会があるという。

• 1回目：顧客との契約時、仕様の確認をするとき
  
• 2回目：ベンダーと請負会社の契約直前に、請負会社から仕様の確認を求められ、顧客に問い合わせるとき
  
• 3回目：火ダルマになっていることが知れ渡り、顧客が乗り込んできて「こんなのを作れなんて言ってない」と言い放つとき
  

.…にもかかわらず、3回目がほとんどだろ。この弾丸を発射するときがチャンスで、口を尖らせて「そもそもかくあるべき」論がくりひろげられる。そんなんなら最初から言えやボケェ！と叫びたくなるのをグッとこらえるのに苦労しただろう。

　だから、この弾丸は最初に撃ってもらおう。1回目こそが決戦地。ここでは、仕様をきちんと落とし込むためのテクニックは書かない。テクニックはUMLでもマジカでも好きな武器を手にすればよい。ここでは、決戦地で闘うための戦略を書く。戦略は2つある。

* * *

「仕様の再確認」によるあいまい性の排除

　一つ目の戦略。決戦地は「受注確定直後」。ここで決めなければいつまでたってもあいまいなまま。極端な話、動いたものが仕様ですなんてシャレにならん冗談もある。確定直後、「システム仕様の再確認」をやる。ミーティング形式だろうが、題名は　"　仕　様　の　再　確　認　"　であること。

　そもそも受注時にまともな仕様が決まっているハズがない。顧客も営業も社内手続きや次案件に忙殺されてて、内部ネゴが通れば後は済んだ事にしたがる。だから、契約書に添付されている「仕様書もどき」を見ても、ペラペラのスカスカだ。

　だから受注確定時、「分析・検討フェーズ」と称して「仕様の御用聞き」をやってるわけだ。顧客にとってはベンリだよな。契約でスケジュールをしばって、仕様は後付けで決められる。都合の悪いところは「そう読めるじゃねーかよ」と切り返す。どうとでも読み取れるような書き方をしているからだ。

　そこが問題なり。仕様は決まっていないのに、あたかも決まった上での契約として扱われ、フリーハンドの余地をたっぷりと残している。しかも決めにくいところは先送りできる。そうしたしわ寄せは後の人に押し付けられる。

　こいつを回避するためにすることは「仕様の再確認」。仕様は既に凍結しており、今やってることはその再確認に過ぎない、という姿勢で臨む。そこにはペラペラの「仕様もどき」から全力で肉付けしたドキュメントを準備しておく。

　すると顧客は「そうじゃない」とくる。あたりまえだ。顧客自身、真剣に深堀りして考え抜いたわけじゃないからだ。けれども、ペーパープロトタイピングでも何でもいいから、形になったものをとにかく突きつける。顧客はそこで初めて考え始める。仕様を考えるベースラインがあれば、そいつに朱入れしてもらうなり、顧客自身に書き直してもらうことができる。何も土台がないまま空中戦を続けても何も残らない。

　それでも「仕様の再確認」という姿勢はくずさない。なぜか? 「すべきこと」は決まっているから。（その2）で出てきた「空欄込みのすべきこと」が効いてくる。プロジェクトのゴールが決まっていて、そこから逆算してすべきことが洗い出されていて、順序性と未決定事項がオープンになっているから。仕様は今決まっていないと、順序が崩れるから。「そうじゃない」と"今"言われても困るから。"今"（＝契約直後）に決まっていないと、ゴールは望めないということを、"今"たっぷりと自覚してもらう。

　これができるのは、空欄が入っててもいいから「すべきこと」が全部マナ板の上に乗っているから。「走りながら考える」「とりあえず動いてから決める」姿勢でいる限り、いつまでたっても決まらない。

　プロトタイプ開発方式での仕様決めに参加したことがあるだろうか。プロトタイピングのだんだん肉付けするやり方は、作るのには適しているが、決めるのには最悪なり。これを理解していないと、いつまでたっても決まらない画面をいじりまわしているうちに時間切れになる。顧客が決めたいのは文字の色やボタンの配置なのではなく、そこでやりたいこと、即ち仕様なり。「大学で情報工学を専攻してました！」という連中が最も陥りやすい罠。むしろ、そういう研究室上がりこそ、「色やボタンの配置こそが"仕様"じゃありませんかッ」と詰め寄ってくるので「画面仕様書を「作らない」リスク」あたりを読んで理解してもらおう。

　何が欲しいのか、顧客が説明できないのであれば、何を作っても満足させることはできない。プロトタイピングが根本的に誤解しているのは、ここだ。顧客を巻き込むまでは正しい。しかし、顧客の言うとおりにスパイラルをくり返したところで、顧客が満足するアウトプットは出ない。だから最初にアウトプットを出して「そうじゃない」と顧客自身に言わせる。顧客にとっての"銀の弾丸"は、最初に撃ち尽くしてもらおう。

ウォーターフォールはこう使え（その2）

　ウォーターフォール・モデルとは一言で説明するなら、「プロジェクトの構造化」だ。逐次実行や先手管理、進捗の予実管理なんざ、特徴的だが本質ではない。それらはキチンと構造化された後に実現できる。プロジェクトの構造化をしないまま先手管理しようとするからおかしくなる。

* * *

プロジェクトの構造化はこうやる

　ウォーターフォールは逐次的な開発技法であり、ウォーターフォール全体として「分析>設計>製造>試験」とはならない。顧客受けしやすいようそんな絵を書くこともあるが、実質は異なる。

　「すべきこと」単位に分解して、「すべきこと」同士の順序性を決めた後、「すべきこと」同士では逐次的な関係を守らせるようにすることが本当。

　「すべきこと」の分け方は「分析」「設計」「製造」「試験」ではない。これらは分断するものではない。「なんちゃってウォーターフォール」をダメにしているのは、工程（＝フェーズ）ごとにチームを割り、それぞれの工程を1回でカンペキにこなせるという期待なり。運を点（≠天）に任せているとしかいいようのない希望的観測のおかげで、どれだけの呪詛が生まれたことか…

　学び取るなり盗むなりしてきちんと身に着けていない連中が見よう見まねでマネジメントしていることが、元凶。しかもその部下で実績を積んだ人が、今度はPMとして「なんちゃってウォーターフォール」を任される …悪夢の再生産やね。

　では、どのように分けるのか? プロジェクトにより異なるが、

• 方式
  
• 業務
  
• データ
  
• 環境
  
• 品質
  

に割れる。そして、アサインされたチームがそれぞれの役割を果たす。役割はこんなカンジ。

• 方式　→　ネットワーク、データベース、通信制御、他のシステムとのインタフェースを決定・実装・試験
  
• 業務　→　ビジネスプロセスを分析・実装・試験
  
• データ　→　方式・業務で必要なテーブルセットを準備し、予め用意するべき内容を入れる
  
• 環境　　→　方式・業務・データの開発・試験に必要な環境（ネットワーク・クライアント・サーバなど）を準備
  
• 品質　→　要求されたものと提供するものが合致するためのあらゆる努力（具体的には品質保証/品質管理/品質基準）を実施[参考]
  

　デカいプロジェクトになると、「方式」や「業務」もさらに割れる。ポイントは、役割をアサインされたチームの中で「分析>設計>製造>試験」を回すことと、チーム間での成果物渡しは逐次的なこと。フェーズの名前が気に入らない。なら「検討>執筆>レビュー>」（仕様決め・契約の場合）だろうと、「方針検討>環境構築>実施>検証」（テストの場合）だろうと、お好きな名前をどうぞ。

　仮にウォーターフォールが「逐次的な開発手法」というならば、ココのことを指す。相手チームに渡したら、原則として手戻りは許されない。品質的にアレな場合や、相手チームからのフィードバックがあって初めて手戻りをすることができる。

　「すべきこと」を週単位まで割ることができるならWBSが定義できるが、プロジェクトの最初の段階では全部WBSまで割るのは難しい。だから「すべきこと」はデカいカタマリ単位でOK。このとき大切なのは網羅性。「後で足せばいいや」「やり直しがきくから」なんて甘いことは許されない。なぜなら、「チーム」が別会社にある場合、「契約」が発生してくるから。「あいまいだから分からない」は逃げ。そんなセリフ吐くPMは、いつまでたってもWBS定義をやるはずがない。

　そして、「すべきこと」とWBSが混ざっててもよいから、ネットワークダイアグラムの形にする。つまり、順番を決め、作業量を見込み、矢印で結んでゆき、クリティカルパスを見つける。たいていの場合は、「仕様のあいまい性」がボトルネックとなる作業がクリティカルパス上に乗ってくる。

* * *

構造化すれば、プロジェクトが「見える」

　プロジェクト全体を俯瞰し、プロジェクトを構成する部分を見極め、作業順番を決定し、チームに役割を振ること。これがプロジェクトの構造化。「あいまいなこと」は極力排除するが、残ったところは「あいまいなところ」として「見える化」する（つまり、顧客との共有情報に"空欄"を作っておく）。

　「このプロジェクトの全て」を可視化して、「全体>部分」の構造をオープンにする。まだ決まっていないところや、あいまいな部分は「未決定項」や「未確定事項」として、空欄で定義しておく（←これ重要。これをやっておかないと、変更や追加の要求を受ける際、「変更・追加するモトとなるもの」があやふやになる）。プロジェクトのベースラインを決めることで、そこからのブレを管理することができる。

　しかし、「あやふやなもの」を放置しておけば破綻する。いったんは空欄としてベースにしたとしても、いずれ明確化する必要はある。この連載では、「あやふやなもの」の真っ先のターゲットとして挙げられる「仕様のあいまい性」に着目する。

　　「すでに決まったはずではないか」
　　「そう読み取れるではないか」
　　「いまさら言われても困る」

　「あいまい仕様」に対し、顧客の使う三大文句はこれだ。顧客にとっては銀の弾丸だが、先送りしているにすぎず、いずれ破綻する。破綻のケツはPM/SE/PGに持ってこられる場合が多い。では、ウォーターフォールを使って、誰がどう動けば「仕様のあいまい性」を排除もしくは低減することができるのか?

ウォーターフォールはこう使え（その1）

　ウォーターフォール・モデル悪玉論が幅を利かせている。一方でスパイラル・モデルやアジャイル・モデルがもてはやされている、銀の弾丸のごとく。
　曰く、

• この無駄な成果物を作らされているのはウォーターフォールだから
  
• あいまいな仕様と理不尽な要求に振り回されているのはウォーターフォールだから
  
• スケジュール後半になって追い立てられるのはウォーターフォールだから
  
• いつまでたっても品質が向上しないのはウォーターフォールだから
  
• 赤字プロジェクトが垂れ流されているのはウォーターフォールだから
  
• このプロジェクトがデスマってるのはウォーターフォールだから
  

　偉大な（?）グルの尻馬に乗って叩く。まるでウォーターフォールという軛がボクの創造性と可能性をことごとくダメにしていると言わんばかりに。何かに責任転嫁して考えを止めるのは楽だけど、その「何か」が真の原因で無い限り、解決にはならない。

　仕事ができないのは道具が悪いと騒ぐ前に、その道具ちゃんと使ってる? 知らないままコトバだけを振り回すことはとても危険なことは、ＯＯ談義で語り尽くされてるでしょ? 10年前のトドメ文句「オブジェクト指向ですから」は、それなりに効力をもっていた。わたしはよく分かっていなかったから…が、今はそうではない。試行錯誤を繰り返す中で、その両刃の剣に何度も傷ついたから。

　今ではウォーターフォールとスパイラルを併用している。M.Fowler氏のようなスゴいことは言えないけれど、それでも蔓延する誤解というか怨念というか思い込みについて、提案めいたものは出せる。

* * *

ウォーターフォールモデルとは

　はてなの定義によると、ウォーターフォールモデルでは逐次開発モデルであり、フィードバックがないらしい。

　滝が上から下へ流れ落ちる如く、手戻りは認められない。「上流」で決定されることは碑（いしぶみ）と同じ、絶対命令かつ誤りが一切無いことが前提。その一方で、拡大解釈可能かつあいまいに書かれてあることも事実。「下流」に至り顧客の目に見える段階になって要求が具体的になり、しかもそれは碑に書いてある（＝解釈可能）と言い張り、無償で直せ、これは仕様どおりでないと言い放つ…

　この例は、今の状況なのかもしれない。安請合した営業やダメPM、あいまいな仕様や無謀な計画がプロジェクトを破綻させているにすぎない。"ウォーターフォールだから"なのではない。理論武装のヘリクツと、開発方式とは別物。

　これをふまえた上で定義する。ウォーターフォールモデルとは、まずマイルストーンまでの成果物を厳密に決め、次にそこに向かって収束させることを段階的に進めるやりかた。

　成果物とはドキュメントやコードに限らない。他システムの接続確認ができる試験環境だったり、○○業務を行うためのデータセット一式だったり。

* * *

"河下り"よりもむしろ"山登り"

　"ウォーターフォール"という名前に違和感がある。上から下へ、"河下り"のイメージじゃない。現実はむしろ、順番に段階を踏んで上を目指す"山登り"の方が近い。

　ただし、頂上がゴールなのではなく、一つの peak であって、peak から peak をリレー式に縦走する感じ。一人で黙々と登るのではない。皆で登る。それも全員がいっせいに始めるのではなく、チームごとにバラバラ。ある人は途中の peak で下山し、別の人は途中から peak を目指す。また、登山口から登る人もいれば、市販ソフトを使って五合目からの人もいる。

　最初から最後まで縦走する人はいない。リレー式に渡されるバトンというより、むしろ神輿のようなものを担ぎながら次の peak を目指す。途中で合流する人から部品を組み込んで、神輿はだんだん大きくなる。担ぎ手もどんどん増えてくる。

　ポイントは、peak に到着する日を予めコミットしておくところ。つまり、マイルストーン毎に必要な成果物は厳密に提示させるところ。「次でがんばるからいいや」「○○のせいで遅れます」なんてセリフは言わせないところ。

　「○月○日に peak-1 に到達し、次のチームへの引継を行う」のであれば、何が何でも神輿はその日に着いてなければならない。できなければ peak-1 で待っている人のお金と、そこへ向かっているチームのお金がどんどん使われることになる。

　神輿は一つに限らない。むしろ2つ3つあるのが普通。どんな神輿かはプロジェクトの性格による。1回こっきり、失敗が許されないならば、試験環境やテストツールがデカい神輿になるだろう。あるいは、レガシーシステムの更改ならば古い神輿が引っ張り出される。

　その中で、最も遅れてはならない神輿のルート、すなわち一番時間がかかる神輿のルートがクリティカルパス。こいつを見極め、こいつだけはゼッタイに遅れないようにする。計画との Fit/Gap に目を光らせる。この神輿が遅れるということは、プロジェクト全体のケツを割ることになるから。

　仮に「間に合わない」「成果物がそろわない（貧弱ゥ）」な場合は、挽回策とセットで peak-1 に臨む。peak-1 には皆が待っているのだ。PMがマイルストーンと成果物に喧しいのは、自分の責任で他人（他社・他チーム）のお金を会社に使わせることがイヤだから。

* * *

ウォーターフォール・モデルの真髄

　ウォーターフォール・モデルの真髄はこうだ。プロジェクトを構造化し、段階を踏んで要素成果物を構築する。次に、必要な要素成果物を必要なタイミングで持ち寄り、組み上げる。これを複数のルート・複数のチームで行う。だからこそ「マイルストーンの厳守」「成果物の厳守」が求められる。"ウォーターフォール・モデル"を言い換え、「プロジェクト構造化モデル」と呼ぶほうがしっくりする。

　幸か不幸か、「あじゃいる」だの「らっぷ」といったカッコイイ呼び名が付けられず、"ウォーターフォール"という語感から様々な誤解・曲解が生まれては一人歩きしたのが真相だとふんでいる。

たたり

　怖い、じつに怖い。「こわい本」大好きなわたしだが、今までさんざんそのテの小説は読んできたつもりだが、こいつはスゴく怖い思いをした。恐怖が直接的に記述されているのではない。スゴい描写が飛び出てくるわけでもない。

　どうして怖いのかというと、恐怖が間接的に、読み手の想像力に働きかけているかのように描かれているから。それはまず、登場人物が丘の屋敷から感じる、はっきりしない違和感として描かれる。不安定な感覚は不安に、そして恐怖へと静かに変わってゆく。

　じわじわ、じわじわ変わってゆく。

　屋敷のもつゆがみや感覚を狂わせる仕掛けは、登場人物へ影響する。さらに、彼らの調子がズれてゆく感覚が読み手まで伝染する。読書という行為で、読み手は多かれ少なかれ登場人物とシンクロしているもの。最初、親しみを持てていた人物がだんだん離れてゆく。

　読み手は本能的に追いすがろうとする。

　結果、読み手は登場人物といっしょになって、おかしくなる感覚を味わう。単に彼らが恐ろしい目に遭うから怖いのではない。さいしょは行動を共にし、心の中まで読み取れる彼らが、いつのまにか読み手の傍らを離れて先へ、闇の向こうへ行ってしまうのが怖い。

　真っ暗な中に取り残されるのが怖い。

　「S.キング『シャイニング』、R.マシスン『地獄の家』に影響を与えたゴシックホラーの傑作」とあるが看板に偽り無し…むしろ本書が本家本元というべき。

心霊学研究者モンタギュー博士は、幽霊屋敷として知られる「丘の屋敷」を調査するため三人の男女を呼び集めた。まるで意志を持つかのように彼らの前に怪異を繰り広げる「屋敷」。そして図書館に隠された手稿が繙かれ、秘められた過去が明るみに出るとき、何が起きるのか?幻想文学の才媛が描く、美しく静かな恐怖。（amazon紹介文より）

　「シャイニング」は「シャイニング」、「地獄の家」は「ヘルハウス」という題で映画化されている。「たたり」は「ホーンティング」なり。どの映画も良かったけれど、この「作中人物とともにおかしくなる感覚」は味わえない。これは小説ならではの特権として、たっぷり味わって欲しい。

　冬こそ、ホラー。

美少女ホラー3冊

　冬だからこそホラー。ホラーには美少女がよく似合う。だから3冊まとめて美少女ホラーを読了。少女怪談【；゜Д゜】怖いでも書いたが、少女という存在は見ているこっちが不安になるほど不安定なるもの。だから少女をきっちり描いているだけで、ゾワゾワしてくる。

　一冊目は「ずっとお城で暮らしてる」（シャーリイ・ジャクソン）。これは劇薬小説企画でスズキトモユさんに教えていただいた一冊。

　由緒ある屋敷で暮らす姉妹の話。叔父さんやいとこも出てくるが、中心は美少女姉妹。姉ちゃんはハタチ超えているから少女というにはアレかもしれないが、2年前の惨劇の後、引きこもりになってしまったので、深窓の美女として脳内補完。

　話は妹ビジョンの一人称で語られるので、彼女の状況につい肩を持ってしまう。姉ちゃんとの何気ない会話が乙女ちっくで良い（一方で、どこかしら危うさが見え隠れする）。また、妹の独白がこれまた女の子女の子してて可愛い（が、なんだか不安な気持ちにさせられる）。

　読み進めても不安定な気持ちは消えず、むしろ掻き立てられる。そして…　読後感というよりも、読んでる途中、たしかにイヤ～な気分を味わえた。スズキトモユさん、ありがとうございます。

　二冊目は「聖女の島」（皆川博子）。これは嫁に「後味の悪い読後感の小説って何かある？」と訊いたら返ってきた一冊。さすが俺嫁、読後感はでんぐり返ったイヤな気分。

　設定がナイス。昔は炭田の採掘基地で、今は廃墟化した孤島が舞台。そこに修道会のつくった矯正施設がある。売春、盗み、恐喝の非行を重ね、幼くして性の悦楽を知った少女たちが集められる。

　事故で何人か死んだはずなのに全員いる、少女たちの不気味な儀式、食い違う発言、姉の記憶…イヤな仕掛けがたくさんあり、読み手の疑問と不安がどんどんふくらんでくる。悪夢に引き込まれるように先へ先へと進んでいって、ラスト。こいつはまいった。

　最後は「巫子」（皆川博子）。ぜんぶ「少女」が主人公の短編集。「聖女の島」と同様、視点の書き分けが手練れ。人称だけでなく、空間的な視座、過去と現在を渡る視線…それが巧妙な伏線になっている。唐突なラストで視線が肉体を追い越す感覚には何度も肌があわ立った。紹介では、

　　・少女霊媒となった少女たちを待つ残酷な運命（巫子）。
　　・過去の自分からかかってきた深夜の電話（夜の声）。
　　・少女と女流画家の世にも奇妙な愛欲地獄（幻獄）

…とあるが、「流刑」がイチオシ。恐いだけでなく、美しく哀しい環。

　シャーリイ・ジャクソンといい皆川博子といい、男性作家には絶対書けない少女ばかりなり。だからこわい…。どんどん引き込まれ、ふと気づけば、超えてはならない一線のあちら側にいる自分と目が合うかもしれない。

　次は「たたり」いってみよーか。

ITエンジニアの「心の病」

　自殺1名、過労死1名、入院不明。不明なのは数えられないぐらい多いから。自宅療養も含めると結構な数になる。噂話ではなく、直接関係ある人。PG/SE/PM…10年もこの仕事をしていると、そんな「同僚」「上司」「協力会社の人」が出てくる。超弩級プロジェクトでは、最初は「人月」で数えるが、そのうち「柱」で数えるようになる。

　誰も死んでいないのに「デスマーチ」と嬉しそうに。

　本当に酷くなると誰もデスマなんて言わなくなる。代わりに、行方知れずが出てくる。単なる出社拒否じゃなく本当に行方不明になる。燎原の真っ只中にいるときは気づかない。「○○が来ませーん」『なにー！どーすんだよ、コレなんとかしなくちゃ』…人じゃなく仕事の心配ばかりするようになったらオワリ。

　おかしくなるまで仕事する／させる／させられるハメにならないように…そんな自戒も込めて「ITエンジニアの"心の病"」を読んだ。「ITエンジニアがとりつかれやすい30の疾患」が並んでいて、一つ一つ自分に当てはめながら読んだ。

　類書、類サイトより秀でているのは、疾患を羅列するだけでなく、危険信号を4つの段階に分けて説明しているところ。自分だけでなく同僚・上司・部下の"兆候"に当てはめることができる。マネージャーは必読。

　　デフコン1：気分の変化に現れるシグナル
　　デフコン2：身体症状として現れるシグナル
　　デフコン3：行動異常・感覚異常に現れるシグナル
　　デフコン4：自殺を予告するシグナル

　また、予防法やストレス解消法が詳述されている。どこかで見聞きしたものばかりだが、断片的ではなく、まとまっているのがよい。わたしの場合、「いい加減」と「よい加減」の話が響いた。メンタルヘルスを考慮に入れて自分のキャリアを再考してみる。

　さらに、自分ではどうしようもなくなってしまったらどうすればよいかが書いてある。保険が適用できてSSRI（抗うつ剤）込みで、初診3,000円なんてことは頭の片隅に置いておこう。精神科、神経内科、神経科、心療内科、一般内科　とあるが、自覚症状に応じ、どの科を受診すればよいかも分かる。

　「ITエンジニアがとりつかれやすい30の疾患」を自分に当てはめてみる。

1.頭痛
　原因はストレスや疲労。肩こり頭痛は職業病だと諦めていたが、「えぐるような痛み」は思い当たる。ストレスによる痛みには冷えピタではなく、暖めると良いらしい。眠気覚ましも兼ねて冷えピタしてたのは逆効果だったのかも。

2.慢性疲労症候群
　普通とは違う激しいだるさに悩まされる。今のところ、だるさの原因は、酒・睡眠・ゲームのいずれかしかないので大丈夫だろう。

3.エコノミークラス症候群
　血液どろどろ環境でハイリスクに。"IT技術者"はじーっと座り仕事しているからだそうな。わたしの場合はむしろ逆で、仕事が込んでくると、ずっと立ちっぱなしになる。「座ってる時間＝便座」になる。

4.自立神経失調症
　ストレスによる自動コントロール装置の乱れとあるが、いまのところ縁なし。

5.失感情言語化症（アレキシサイミア）
　あるはずのストレスを感じない。いるいる、まるでマシンのような人。システマティックな性格なので仕事相手には重宝していたが、普通人よりも大きなストレスを抱えていたとは。

6.ＩＴてんかん
　パソコンがてんかん体質者の脳波を刺激。ボケモンビームでアワ噴いた子どもがいたからなぁ。

7.社会不安障害（対人恐怖症）
　プレゼンテーションができない。多かれ少なかれ、誰しもあると思うぞ。だんだんに慣れてくるもんじゃないかしら。

8.うつ病
　何ごとに対しても意欲がなくなってくる。実は分からない。「何をしても絶望感」しか感じられない時期があったが、それが「うつ」かは未だ分からずじまい。まぁ、立ち直ったから、うつ病じゃなかったんだろうと独り合点。

9.睡眠障害
　寝付けない、眠れない。わたしもそんな時期もあった…と思っていたが、もっと深刻なものらしい。寝てもすぐ目が覚めてしまったり、疲れているのに眠れない。ゆっくりたっぷり眠ることが一番のゼイタクなわたしにとって、睡眠障害は恐怖以外の何ものでもない。

10.適応障害
　ストレスが普通の生活への適応を阻害。火消し屋として放り込まれる度にキリキリと腹痛になるが、適応障害だったのだろうか。

11.インターネット依存症
　ネットに接続していないと不安になる。そうそう、ブログ始めた頃とか（w

12.電磁波症候群
　そういや、さいきん電磁波エプロン見かけないな…

13.ＶＤＴ症候群
　画面を長時間見つめると現れるさまざまな症状。

14.ドライアイ
　目の感染症を招きやすくなる。これも職業病とあきらめている。

15.化学物質過敏症
　多様な症状が多様な現れ方をする。

16.過敏性大腸症候群
　ストレスが腸の働きをかく乱。腸はsecond brain（第2の脳）ということをはじめて知った。確かに「ストレス→下痢」は「台風→眠気」と同じぐらい黄金律。

17.呑気症候群（ゲップ・おなら）
　ストレスが空気の飲み込みを増加。ストレスが溜まるとまず暴食に走ってたなぁ。

18.ディスペプシア（胃の痛みやもたれ）
　長引く原因不明の不調。わたしには無縁だが、「ストレス→胃痛」の人がいる。ナポレオンのごとく腹に手を当てている。

19.胃・十二指腸潰瘍
　胃壁の血流悪化で粘膜にキズ。

20.摂食障害
　食べられなくなったり、食べすぎになったり。あるある、ストレス太りは経験済み（もちろん元に戻した）。ストレスが溜まると"本能"に忠実な行動をとりたがるようになった。例えば食欲と性欲。睡眠時間は極端に削られているため、食べることとスルことにがっついてくるのは自然なことだと思う。

21.狭心症・心筋梗塞
　発症前の不摂生と大きな関わり。

22.脳梗塞
　身体の片側に現れる異変に要注意。「予告」がある発作らしい。上司の一人は会議の直後、これで逝った。

23.円形脱毛症
　ストレスで免疫システムに狂い。経験済み（今は戻った）。ハゲしくハゲるが、戻るのも早かった。

24.顎関節症
　ストレスが引き金であごがガクガクに。嫁さんと一緒になって分かったこと→「歯軋りがひどい」

25.頸肩腕症候群
　ストレスが主因で首・肩・腕に痛み。

26.手根管症候群
　使いすぎが招く手指のしびれ。あるある。プログラマよりもテスタやってた頃にひどかった。プログラマの頃は打鍵してる時間よりも考えたり調べたりする時間の方が長かった。一方テスタ時代はひたすら打鍵してた。

27.腰痛
　「心の問題」に着目すると解決することも…本当か!? これも職業病だとあきらめている。一つだけ贅沢していいなら、CPUよりもメモリよりも、良い椅子が欲しい。

28.痔核
　座りっぱなしの作業は痔にまっしぐら。時間の問題だと覚悟している。

29.生理不順・無月経
　ストレスが招く更年期様症状。

30.勃起障害（ＥＤ）
　ありがたいことに未経験。疲れ魔羅ならしょっちゅうだが（w

　こうして並べると、お題の「IT技術者」に限らないかも。著者は医師らしいが、「IT技術者」のイメージからくる　「まじめ」「ロジカル」「融通きかない」「独りで抱え込む」と想像して書いたんじゃぁないかと。

　なんだか実態と離れた記述もある。例えば「うつ病になりやすい残業時間」。月45時間を超えると、うつ病になりやすくなるそうな。さらに月100時間を超えるか、平均80時間が2～6ヶ月続くとリスクが飛躍的に高くなるらしい。

　えーと、45時間はふつうだし、酷くなったら100時間超もふつうだと思うんだけど…おかしいかな?

　それでも本書を通じて、メンタルケアも自己管理の対象になるなーと思い知った。今までは、「呑・食・眠」だけコントロールしてたけれど、「心」も考慮しとかないとダメなのね。

　「心」も考慮した自己管理とは、好・不調の原因を「呑・食・眠」以外で探し、それを意識的に行動すること。例えば、残業キツいなーと思ったら、ギブアップ宣言しちゃうとか。「他に任せられない、オレでなきゃできない」という傲慢に飲まれないように、自戒自戒。

　おまけ。本書で知った中央労働災害防止協会の疲労度蓄積チェックリストは定期的にやっておくといいかも。定期的にチェックすることでメンタルヘルスを意識づけた仕事のやり方ができるようになるはず。