消極的リーダーの戦争責任：勝田龍夫『重臣たちの昭和史』
なぜまったく勝機のない戦争（特に対米戦争）を始めてしまったのか。
この疑問について考えようとするとき、必ず出てくる説明の一つに「太平洋戦争は避けられない自衛戦争だった」というものがあります。この主張は、東京裁判で東条英機も述べており、当時からこういう認識は日本の指導層の一部では共有されていました。また、太平洋戦争について振り返るテレビ番組の特集などでも、米国の対日禁輸や野村=ルーズベルト会談の調整失敗あたりから説明を開始するものがあり、そういう短期的なスパンで見ると「米国の陰謀に嵌められた」ような印象を受けやすいのも事実です。
しかし、日米開戦をゴールとして見た場合、こうした出来事はすでにゲームの終盤に差し掛かってからのダメ押し点みたいなもので、実際はもっと前から着実に日本は軍事と外交の両面で失点を重ねてきたし、米国も長い時間をかけて日本に対して不信感を募らせていたというバックグラウンドを見過ごすことになります。
東条英機は、開戦を決断し、戦中もずっと首相を務めたということで、今日では戦犯の代表格のような扱いを受けていますが、開戦に至る長い長い伏線を考えると、もうほとんど選択肢が残されていない中で貧乏くじをひかされたようなものです。本当は、彼にバトンを渡す前に前に開戦への道を舗装した「戦犯」がいる――近衛文麿。それが本書の最重要人物です。
近衛文麿は、あまり強い印象を残すタイプの政治家ではありません。五摂家筆頭の華族出身で、若くして首相となり計三回も内閣を組閣したほど、当時は大衆的な人気がありました。強いパーソナリティや確固たる主義主張は持っておらず、若いころはワイルドの「社会主義下の人間の魂」を翻訳して社会主義に傾倒したり、ナチスが台頭してからはヒトラーのコスプレをやってリベラル派の顰蹙を買ってみたり、後見役の西園寺公望からは腰の据わらなさについていつも苦言を受けていました。
彼の政治家としての姿勢を一言で要約するならば「妥協」です。英米との協調と陸軍の抑制を望む天皇や西園寺の期待を受け、本人としてもそれが最善だと頭で分かっているものの、時にテロも辞さずの姿勢で高圧的に押してくる陸軍の暴走を、結果的に容認する政策を次々に打ち出すことになります。日中事変の拡大、日独伊三国軍事同盟、国家総動員法の施行、大政翼賛会の結成など、日本が国際社会から孤立し、中国および米国との対立を決定的なものとする事件は、すでに近衛内閣に用意されていました。天皇の側近で、近衛と東条をどちらもよく知る木戸幸一が「東条は最後にどうにもならなくなってから責任を押し付けられただけで、日米開戦は近衛が準備した」と評するゆえんです。
もちろん、近衛としても好きで陸軍に妥協を重ねたわけではありません。当時は、陸軍に毅然と抵抗する政治家がテロによって次々に殺されることが日常茶飯事だった時代です。浜口雄幸、高橋是清、井上準之助、犬養毅といった見識と意志を兼ね備えた政治家たちは、いずれもテロにより「排除」され、元老の西園寺が「天皇のそばに人なし」と嘆く事態になる。近衛としては、自分まで死ぬわけにはいかないという思いもあったでしょう。しかし、政局が行き詰まりそうになるとすぐに内閣を放り出して「仏門に入る」とか言い出したり、およそ粘り強さとか不退転の意志といった困難な時代の政治家に不可欠の資質は持っていなかった。近衛は終戦後、結果的に自らが開戦への道を用意したことを後悔し、A級戦犯に指定されると、東京裁判を待たず自殺しました。今日、彼の印象が薄い理由は、東京裁判で裁かれなかったということも関係している。
私たちは、ともすると戦争というのは独裁者のような狂気を帯びた強いリーダー（ヒトラーのような）が国民をうまく誘導し、また狡猾な敵国の術策によって追い込まれることで起きると考えがちです。しかし実際は日本の場合、「弱いリーダー」が妥協を重ねることによって、誰も望まなかった――当の陸軍ですら、米国との戦争は大勢が反対だった――最悪の結果に導かれるというパターンが多い。「こんなつもりじゃなかったが、仕方なかったのだ」という言い訳を、破綻した国家的プロジェクトのリーダー格の人物たちから聞くことは、新国立競技場建設の失敗を見るまでもなく現代の日本でも珍しい光景ではありません。
独裁者の狂気よりも消極的リーダーの無責任が怖いのは、それがあまり目立たず、時にポピュリストとして大衆的な人気を博しながら根幹を蝕んでいく病魔であることです。このような見えにくいリスクを、私たちはもっと警戒した方がいい。
ありのまま願望を超えて：NHK Eテレ「ねほりんはほりん」
NHKのEテレでやっている「ねほりんはほりん」という番組がNHKらしくなくはっちゃけていて面白いという噂を聞いたので、さっそく見てみました。
面白い。
確かにこれは面白い。
南海キャンディーズの山里さんとYOUさんが司会となって、普通あまり社会の表舞台には出てこないワケありなゲストの人生について根堀葉堀きいていくという、これだけ聞くと民法バラエティでやった方がいいのでは？という下世話な企画。しかしそこはさすが旧3チャンネルの血をひく教育テレビ。ちゃんと啓蒙的な内容になっていて素晴らしい。
7/1回のゲストは「プロ彼女」。この言葉、私も番組で初めて知ったのですが、能町みね子さんという人がロンドンブーツ淳の結婚相手の女性を評して作った言葉だそうです。その定義は以下の通り：
プロ彼女っていうのは一応改めて言うと、基本、芸能人や有名人としか付き合わない一般女性。で、よく芸能人の方が『一般女性と結婚した』って出る時の、だいたいその人がプロ彼女なんですよ。
で、芸能人とかを常に狙っていて。本人は芸能活動は、昔、もう名前が残らない程度にほんのちょっとやっていた程度。まあ、あるいはやっていない。で、検索しても名前が見つからない・・・ブログ見つからない。そういう意味での自己主張はほとんどしていない。にもかかわらず、なぜか芸能人とばかり付き合っている容姿端麗な女性。
「能町みね子 NHK『ねほりんはほりん』プロ彼女特集を絶賛する」
さて、番組では、このプロ彼女（当然匿名）さんが語る「どうやって有名人に辿りつく人脈を作るか」「どうやって相手に気に入られて結婚までもっていくか」「結婚生活を円満に送るためにどんなことに気を付けているか」という、適齢期の女性であれば有名人狙いでなくても知りたい技術について、実に説得力をもって語ってくれています（司会の二人の引き出し方もうまい。特にこの手の話はやはりYOUさんの独壇場）。
芸能活動もしていない一般人が有名人と知り合いになるなんて、普通無理じゃない？ という山里さんのもっともな疑問に対して、プロ彼女さんは、「直接狙うのではなく、まずは六本木のクラブのVIP席にいる『女の子』と仲良くなる」「Twitterなどを使ってタニマチや後援者に近づく」など、実に明快で説得力のある回答を返していきます。これはもはや恋愛という名の仕事。「プロ」の名に恥じない明確な目的意識と確立されたメソッドからは、職人的な美意識すら感じさせます。
他の国の事情は私も知りませんが、日本人は恋愛に関してはかなりのロマン主義者というか、「ありのまま願望」がかなり強い人たちです。アナ雪の歌がはやるずっと昔からそうです。仕事や勉強においては努力して技術を身につけ成果を挙げることは賞賛の対象になりますが、恋愛の分野でそれをやると「あざとい」と言われ忌避されます。「やるにしてもそういう努力は隠れてやれよ」と。最近一部界隈で盛り上がっている「恋愛工学」がたたかれるのも、一部はそのあたりに起因するものでしょう。AV監督にして異色の恋愛指南書を書いた二村ヒトシさんも、（特に女性の）心に潜むありのまま願望の問題について指摘しています。
「愛されたい」ということは「君は、今の君のままで、いいんだよ」と受容されたいということです。
自己受容してなくても、どんなに「より良い自分」になりたがっているとしても、あなたは本当は、今のままで受け入れられることを望んでいるんです。
そのことに気づくと、あなたを愛さない（肯定・受容しない）相手を求めていることが、バカバカしくなりませんか？本当は「このままの自分」で受容してほしい。
p.73痛い、痛いよ、監督。
そう、なぜか日本人は、こと恋愛に関しては「努力をするのは邪道だ」という奇妙な規範を内面化している。
そこをさくっと抉るプロ彼女さんの意見だけでもグサッと来た視聴者の心に、司会のYOUさんが追い打ちをかけます。
「ありのままの大根が食えるかっての。辛いんだよ。」
大根はちゃんと出汁でゆでて、調味料を最適に使うから美味しいんであって、掘ったばかりの泥ついた大根なんか誰が食べるか。
ああ、言っちまった。
そうなのです。女性だってほっとけばワキ毛も生えるし、運動しなければ体型も崩れる。きちんとしたテーブルマナーやエレガントな立ち居振る舞いは、教わって練習しなければ身に付かない。「ありのまま」の人間は男女問わず、獣に近い存在です。「ありのまま」の姿を見せていいのはもうそれだけで十分に鑑賞に堪える美しさと生きていける強さを持ち合わせた神に近い存在だけです。
だから、神ならぬ凡百の我々が相手に気に入られるために努力をすることは何も悪くはない・・・悪くはないはずなのに、なぜかパンドラの箱が開く瞬間を見てしまったような罪悪感が伴うのは、私の中にまだ啓蒙されていない闇が残っているからに違いありません。ねえそうですよね、Eテレのスタッフの皆さん。我々にはもっと啓蒙の光が必要なんですよね。「恋愛のために努力して何が悪いの？」とカラっと言えるプロ彼女さんの境地を目指すべきなんです。「同性で結婚して何が悪いの？」とカラっと言えるようになったように。
「ねほりんはほりん」は、番組のHPを見ても次回告知とかないのでまだパイロット版のようですが、絶対にレギュラー化してほしいと思って応援のエントリを書いた次第です。このエールが番組スタッフまで届け〜。できれば局の偉い人の方まで届け〜。
因果から相関へ：『ビッグデータの正体』
いろんな会社の営業さんなんかと話すと、とりあえずビッグデータと名前がついていれば仕事や予算の食いつきがいいという状況がまだしばらく続いているようで、何よりな話です。「IoTで集めたビッグデータをNOSQLでリアルタイムに分析」とか書いておけば提案書のウケが違うのだから、まあ良い時代です。「爆安！」以外何もお客さんの心に響かないというよりずっといい。「付加価値」ってやつです。
私も一応データベースが専門のエンジニアという肩書きになっているので、ちょこちょこと「ビッグデータ」案件に関わったりしてます。昔「データウェアハウス」と呼んでたころには大して流行らなくて、「ビジネスインテリジェンス」と名前を変えてちょっと流行って、「ビッグデータ」で爆発したのだから、名前というのも馬鹿になりません。本当はそれ以外にもいろんな環境変数が関係しているのでしょうが、三度目の正直。
実際ものになる取組みはごく一部なのでしょうが、統計分析を意思決定に活用するというアイデアが持っている可能性の射程が広く長いのは事実なので、バブルが終わった後に十分な実りが得られればよいと思いますし、一つでも成功事例を増やす義務は、我々エンジニアにもあります。
ビッグデータや統計分析についての書籍も、今が盛りとばかりに百花繚乱です。その多くは「ビッグデータを使えばこんなすごいことができます」とか逆に「こんな面倒な問題が持ち上がるかも（ビッグブラザー的な監視社会の到来が云々）」という事例を中心に話を展開したものです。まあそういう事例を集めたのも十分面白いし、近未来のディストピアというのは、いつでもSF的な想像力を掻き立てるテーマで、これも別のベクトルで知的興味をそそるものではあります。
本書も、そういう事例を多く紹介していますし(Amazonが昔は書評家を雇ってレビューを書かせていた、というのは知らなかった)、『1984』や『マイノリティ・リポート』が描いたような人権を侵害する権力側の技術としてビッグデータが利用されるのではないか、という懸念についてもかなりの紙幅を費やして論じています*1。しかし、本書が他の類書と一線を画しているのは、ビッグデータが人間の物の考え方をかなり根本的なところで変えてしまうのではないか、という点に対する考察を行っていることです。
従来、私たちが将来を予測しようとするとき、その方法論はエンジニアリング（工学）的なものでした。因果関係を表す法則性を見つけ出してモデルを作り（数式にまで落とせればベスト）、結果に影響を与える因子をすべて洗い出す。あとはモデルに入力パラメータを与えれば結果が得られます。もし予測精度が悪ければ、それはモデルが間違ってるか入力値がウソだったかのどちらかです。このような「原因→結果」世界観においては、なによりも原因とそれが作用するプロセス（→の部分）を突き止めることが非常に重要でした。別に、研究者だけがそうしているわけではなく、普通に仕事や勉強をしている我々ですら、「このミスはなぜ起きたのか？」とか「英語の成績を上げるには単語力が足りない」とか「中継ぎさえ立ち直れば今年の中日はもっとやれるはずだ」とか、「原因→結果」の考え方は、私たちの思考のベースを形成しています。
統計分析のパラダイムは、これとは違い、ベースになるのは相関関係です。複数の変数が互いに連動しているかどうか、という事実に着目します。もちろん、そこには因果があるのかもしれないけど、そこまで突き止めるのは難しかったり、どういうメカニズムで相関しているのかブラックボックスということは珍しくありません。「あなたは5年以内にガンになる確率が90%です」という分析結果が出てきて「何を根拠にそんなことを」と医師に詰め寄っても、満足のいく因果的な説明は期待できない。いい加減な話だな、という気もしますが、「メカニズムが分からなくても役に立つなら使っちゃえ」の精神で多くの技術は社会に受け入れられているので、統計分析もその予測精度が認められれば、ブラックボックスのまま浸透していく可能性はある。一部の麻酔みたいに、何で効くのかよく分からないけど、経験的に「効く」ということだけ分かっているので医療現場で使われているという技術もあるわけだし。
そのとき、人間の世界を認識するやり方はどういう影響を受けるのでしょうか。いきなりみんなが物事を因果関係で考えるのをやめる、ということはないでしょう。著者も、人間が物事を因果関係で考えるのは人間の本性に基づくものなので因果モデルが消えてなくなることはない、と述べています。むしろ相関関係を因果関係だと錯覚する人の方が多いと思う。その習性を利用した統計トリックの悪用は今でも散見されます（谷岡一郎『「社会調査」のウソ』
将来的には、人々はもう少し賢くなって、因果モデルと相関モデルを場面に応じて使いこなすようになるのだろう、というのがまあまあ楽観的な予想でしょうか。そうなるためには、統計リテラシについての授業が義務教育に組み込まれるぐらいのところまで行かないとダメな気もするけど。
本書は、ビッグデータのビジネスシーンでの応用から、人間の認識や社会の在り方に対する変化についてまで広く目を配った視野の広さと適度な考察の深さが光る良い本です。この内容を分量的にかなりコンパクトにまとめているのは、『WSJ』や『The Economist』のエディタの人も執筆陣に参加しているだけあって、プロの編集の仕事だなと感心します。そんなに技術的詳細に踏み込まずエッセンスを抽出できているので、技術畑以外の人が読んでも楽しみながら考えを深められるのもよいところです。
Club DB2で講演します
5/15にClub DB2（恵比寿ガーデンプレイス）で講演を行います。タイトルは「ループをめぐる物語――SQLにおける手続き型の復権」です。中身は、『SQL実践入門』の内容についての解説ですが、特にウィンドウ関数の使い方にスポットをあてて、これまでループの代用として使われてきた自己結合や相関サブクエリに比べて、直観的でわかりやすく書けて性能もよいというメリットについてお話しようと思います。
大量データを入れたテーブルを使って、実際にSQL文を実行して性能を見ながら、なぜそのような差が生じるのかということを、実行計画を確認しながら解き明かしていくというデモも予定しています。
お楽しみに。
2015/5/19追記
講演資料をアップしました。当日はたくさんの方にご来場いただきありがとうございました。そして200回続けてこられた運営の方々、お疲れ様でした。毎回好き勝手しゃべらせてもらって、寛大さに感謝です。
さて、当日のダイジェストをざっくり私の視点でまとめるとこんな感じです：
- 講演のテーマは、タイトルのとおりSQLの中で手続き型の考え方（行の順序を意識したコーディング）が復活しつつあって、それを利用するととてもいい感じなのではないかと。
- 具体的には、今回の本の主役であるウィンドウ関数が最強伝説すぎる。これを使うと相関サブクエリと結合を消去できるのでウソみたいに性能が良くなるし、実行計画も安定して一石二鳥。
- 結合というのは性能問題の温床なので、ない方が性能的にはいいに決まっている。Nested Loops/Hash/Sort Mergeとアルゴリズム変動しちゃうし、それが起きなくても駆動表がひっくり返るだけでもNested Loopsの性能はブレブレ。
- Hashの方が駆動表の変動に対する感度が小さいので、Nested LoopsよりむしろHashを基本に据えた方がよいのでは？ それは単性能ベース見た場合なだけで、実際は多重走行するとHashはけっこうメモリ食いなので怖いのですよ。テーブルが小さければTEMP落ちも起きないけど、テーブル小さならそもそもNested Loopsで十分ですしねえ。
- そのようなわけで、MySQLがNested Loopsしか結合アルゴリズムを持っていないのは、利用シーンを考えると一つの見識だとかねがね思ってます。実際同時実行数の多いWeb系のシステムでHashやSort Mergeが選択されたらメモリ不足ですぐに爆死してしまうのではないでしょうか。
- MySQLがウィンドウ関数を持っていないのも同じ理由によるのではないかと。「Oracle買ってね（はぁと）ってことでしょ」とか、憶測でものを言うのはよろしくないですな。AにはAの、BにはBの仕事がありましょう。
- ビッグデータ分析はSQL/RDBとは別のアーキテクチャ（R言語+NoSQLとか）で実現する方が適切ではないのか？ 私もそんな気がするのだけど、SQL/RDBって長年何かにとってかわられると言われ続けてなかなかくたばらないんですよね。こんだけ寿命長く一線にとどまる言語も珍しい。なんでか？ うーんなんででしょうね・・・。
- 以前ぐるぐる系は性能が悪いってdisっちゃったけど（事実なんだけど）、やっぱり実行計画が安定するというメリットは無視できないのではないか、と思い直しました。特にゼロリスク願望の強い日本の風土にはよくマッチする処理方式なのかも。日夜複雑なSQLの実行計画の最適化に心を砕いているDBベンダの方が見ると「・・・」な気分になっちゃうかもしれないけど。
- ジョジョネタはしばらく封印。
それでは、250回記念でまたお会いしましょう。
参考文献にかえて
前回のエントリで拙著『SQL実践入門』を紹介させてもらいましたが、本書には参考文献はつけていないので、ここで本書を書く際に参考にした本をいくつか紹介したいと思います。
どちらも実行計画の読み方やメモリ機構、データの物理的な格納方法などDBMS内部のパフォーマンスアーキテクチャを解説した本です。
そもそもの話として、実行計画の解説書というのは多くありません。おそらく日本語でまとまった分量が読める本は存在しないと思います（もしあったら教えてください）。なので必然的に英語書籍にあたるしかないのですが、それでもやはり数が多いとは言えません。この理由は推測の域を出ませんが、プロプライエタリな製品の場合は企業秘密の一部になっていること、そもそも実行計画をユーザに読ませるのは「ウチのオプティマイザはあまり賢くありません」と認めることになるのであまりベンダとして気乗りする話ではない、というところではないかと思います（ヒント句を山のように揃えてSPMまで使えるOracle社だけは、違う見解を持っていそうな気もしますが）。
どちらの本も実行計画の色々なパターン（Oracleの場合はそれに対応するヒント句）を挙げてくれていて、本書を書く上で大いに参考にさせてもらいました。バージョンはちょっと古いですが、こういうコアロジックはそれほど劇的に変わることはないので、あまりそのあたりを気にしなくてもよいでしょう。
ちょっとマニアックな分野ですが、『SQL実践入門』を読んでもっと実行計画の色々なパターンを勉強してみたいと思った奇特な方向けです。
新著が出ます：『SQL実践入門』
リレーショナルデータベースというのは、SQLという自然言語を模したインタフェースによって、低次のレイヤーを隠蔽する意図で作られたミドルウェアなので、本当は実行計画などという手続レベルの世界をユーザが覗き見るのは、本末転倒なところもあります。ただそうはいっても、現実にSQLが遅かったら原因を解析せざるをえないわけだし、大体本当にブラックボックスにしたいなら、なんでどのDBMSも実行計画を見られる手段なんか用意してるんでしょうね不思議ですね、という理想と現実の狭間で悩むエンジニアの方々に少しでもベターな解に辿りつけるアプローチを提示できれば、と考えております。
以下まえがきと章立てです。
本書の目的は、パフォーマンスの良いSQLの書き方、特に大量データを処理するSQLの性能向上の方法を理解することです。SQLの第一の目的は、ユーザが欲しいと思ったデータを選択すること、あるいは望んだ結果になるようデータを更新することです。通常のプログラミング言語と同様、一つの目的を実現するSQLの書き方は複数あり、それらの間には機能的には差異はなくても、パフォーマンスには大きな差が生じることが頻繁に起こります。したがって、SQLの組み立てを行うにあたっても、効率やパフォーマンスを重視した書き方が求められることが多くあります。
アプリケーション開発者の方の中には、普段あまりDBMSの内部アーキテクチャやストレージといった下位層を意識せず、データベースをブラックボックスとして扱っている人も多いでしょう。実際、データベースの扱うデータ量が少なければ、そのスタンスでも十分実用に堪えるシステムが作れるのが、RDB（リレーショナルデータベース）とSQLの良いところであり、「ブラックボックスとして扱えるデータベース」は、RDBが目指してきた目標の一つとすら言ってよいぐらいです。
しかし近年は、データベースが扱うデータ量は飛躍的な増大を遂げており、「ビッグデータ」という言葉も、IT業界の枠を超え社会全般に広まりました。それと歩調を合わせて、データベースのパフォーマンスに対する要求も高くなる一方です。
データベースのパフォーマンスについて理解するには、SQLだけでなく、データベース内部のアーキテクチャやストレージのようなハードウェアの特性まで含めた総合的な知識が必要となります。あるSQLがなぜ速く、それと同じ結果を得る別のSQLがなぜ遅いのかを理解するには、ブラックボックスの蓋を開けて中を覗のぞいてみることが必要となります。本書は、その中を実行計画を通して覗いてみることで、ブラックボックスをホワイトボックスにすることが目的です。
振り返ってみると、RDBとSQLは、ユーザが直観的に利用できるインタフェースと、大量データの効率的な処理という、2つの相反する命題の間で常に揺れ続けてきたミドルウェアでした。RDBとSQLが、この難問をどのように解決しようと努力してきたか、その成果はどのようなものか──そして今、どのような壁に突き当たっているか──それらを一つ一つ、本書の中で明らかにしていきます。
本書もまた、この難問に対する最終解決を与えるものではありません。しかし、現場で日々データベースのパフォーマンスと戦うエンジニアに、RDBとSQLをブラックボックスとして扱っていたときよりも一歩進んだアプローチを示すことができればと考えています。
- 第1章：DBMSのアーキテクチャ──この世にただ飯はあるか
- 第2章：SQLの基礎──母国語を話すがごとく
- 第3章：SQLにおける条件分岐──文から式へ
- 第4章：集約とカット──集合の世界
- 第5章：ループ──手続き型の呪縛
- 第6章：結合──結合を制する者はSQL を制す
- 第7章：サブクエリ──困難は分割するべきか
- 第8 章：SQLにおける順序──甦る手続き型
- 第9章：更新とデータモデル──盲目のスーパーソルジャー
- 第10章：インデックスを使いこなす──秀才の弱点
- Appendix A：PostgreSQL のインストールと起動
- Appendix B：演習問題の解答
実行計画のサンプルとしてはOracleとPostgreSQLを採用しました。この理由は、実行計画がテキストベースの綺麗な階層構造で表示されるので学習用に向いていることです。
内容的には以前『Web+DB Press』で連載していた「SQL緊急救命室」、「SQLアタマアカデミー」、「DBアタマアカデミー」などをベースに加筆修正を行ったものなので、これらのサイトを見てみるとイメージがつかめると思います（救命室のようなストーリー仕立てではありませんが）。
皆様のお役に立てば幸いです。
不作為の罪：『なぜ、システム開発は必ずモメるのか？』
みんなそれなりに頭もいいし、人間的にもまともな人たちが集まって仕事をしているはずなのに、「なんでこんなことになっちまったのかな・・・オレたちはただ、幸せになりたかっただけなのに」と敗戦後の焼け野原を見たときのような呟きが漏れてしまうことは、日常茶飯事です。
それぞれのプロジェクトには、固有の難しさと失敗の原因が存在するでしょう。いわく、新しい技術にエンジニアが慣れていなかった。いわく、客のキーマンがモンスターカスタマーだった。いわく、オフショア先の品質が低くてメチャクチャなコードが上がってきた――これらはいずれも嘘ではありません。「幸福な家はみな同じように幸福だが、不幸な家の不幸には独自性がある」というトルストイの言葉通りです。
しかし、あたまもやる気も人並みにある人間たちが数十年取り組んできて、それでもなお失敗を繰り返すのだとすれば、それはシステム開発という仕事に何かしら構造的な問題が潜んでいると考えるのが合理的というものです。この問いに対する本書の回答はシンプルです。
作り手の進め方が悪い
「……はい、どうもすいませんでした」。いや、「進め方」という書き方をしましたが、これは別に開発の方法論とかプロジェクトマネジメントの技法に欠陥がある、という意味ではありません。システム屋は、何かと物事を技術論に落として考えようとする癖を持っていますが、本書が指摘するのは、もうちょっと違う、どちらかというとメンタルの問題です。「SIerやベンダは、自分たちの立場を勘違いしている」というのが、本書の中心的なメッセージです。
システム開発がモメる場合、その相手は十中八九が客です。業者間の擦り付け合いというモメ方をすることもありますが、その場合もある程度客が関係しています。開発側と客がモメるとき、開発側は、自分たちは精いっぱいのことはやったのだ、と考える傾向があります。出された要件には従ったし、何度も変更要求を入れてくるワガママにもつきあった。何も分かっていない素人の思いつきに、もう精神と肉体の限界まで付き合った。それなのに何でこれ以上責められなきゃいけないんだよ、と。
しかし、本書が豊富な事例で示す判例は、そのような開発側に対してかなり厳しいものです。
- システムの納入が遅れた原因について要件定義が不十分であったことに対してベンダ責任を認める。（東京地裁 平成16年3月10日）
- ユーザが威圧的なため開発者が離脱したことでシステムを完成させられたなかったことについてユーザ責任はないと認める。（東京地裁 平成19年12月4日）
- パッケージに機能が不足していたことを採用したベンダの責任と認める。（東京地裁 平成22年1月22日）
こうした判例におけるポイントは、「ユーザはシステムに関しては素人なのだから、開発主体はプロとして開発プロジェクトをリードする義務がある。ユーザに言われたことや契約書に書いてあることだけやりました、と言ってもその理屈は通らない」ということです。
開発側は、ともすると「契約書や仕様書に書いてあることだけ満たせばいい」という発想をしがちです（Contract is contract）。しかし、たとえRFP通りのシステムが出来上がったとしても、それが実用に堪えなければ、「常識的にそれはおかしいだろ。プロなんだから、たとえ書面に書かれていなくても柔軟にそこは補えよ」という判断を裁判所は行う、ということです。客の検収が終わった後でも、実用に堪えなかった場合はベンダ側の責任が問われることもある（p.133）。言われてないから知りません、では許されないのです。
このように開発側から見ると厳しい判断が行われる理由は、システムという分野の専門性が高く、買い手と売り手の間に知識の非対称性が大きいからです。いわば、医療や法曹と同じレベルでの注意義務が、作り手には求められるのです（収入は大分違う気がするが、ドンマイ）。
最近も、要求仕様に明記されていないセキュリティ対策を行っていなかったことが開発側の責任として認められる判決が東京地裁から出ました。「たとえ明文化されていなくても、やって当たり前のレベルは言われなくてもやるべきだ」ということです。
確かに、SQLインジェクション対策をやっていないWebシステムを世に送り出したというのは、普通のエンジニアであれば身震いする話ではあります。しかし、ここまで豪快ではなくても、「客は何も言わなかったし、仕様書にも書いていない」という要求を黙って見過ごしたことは、皆さんにもないでしょうか。それは許されない態度だ、と本書は何度も釘を刺します。そこは、プロとして客に注意を促し、コストと便益を情理を尽くして説明し、体を張ってシステムを守らなければならないのだ、と。
刑法の世界には不作為の罪という概念があります。普通、罪というのは何らかの能動的な行為に対して問われます。しかし、よからぬ事態が出来することを知りながら適切な防止策を怠ることも罪なのです。
プロジェクトのリスク管理なんかもそうだけど、ITの世界では何もしないこと自体が問題ってケースがよくあるわ。いろんな問題をただ待つわけじゃなく、積極的に探し回る神経が双方に必要なのかもね。（p.246）
これは、技術論というより、プロとしての自覚というマインドセットの問題です。エンジニアには法律や医療の世界と違って排他的な性格を持つ資格がなく、誰でも「自分はエンジニア／プロマネです」と名乗れてしまうため、人材の品質が安定せず、参入障壁も低いためコスト競争に巻き込まれてしまう、というマクロな構造問題もあるのですが、それはまあ、現場レベルで論じるには大きすぎる話です。
本書は、開発側にとっては耳の痛い紛争の事例が豊富に紹介されています。また、プロジェクト管理やリスク対策にはコストがかかることを理解するべきだ、ということをはじめとして、ユーザ側にとってもSIerやベンダとうまく付き合うためのコツが紹介されており、双方にとって有用な知見が得られます。もっとも、本書をユーザ側が読むと「ふーん、開発サイドってのはそんなに立場が弱いのか・・・なるほどね」と悪用するためのガイドとしても使えそうな予感がするのは・・・気の回しすぎですかね。
