不作為の罪：『なぜ、システム開発は必ずモメるのか？』
みんなそれなりに頭もいいし、人間的にもまともな人たちが集まって仕事をしているはずなのに、「なんでこんなことになっちまったのかな・・・オレたちはただ、幸せになりたかっただけなのに」と敗戦後の焼け野原を見たときのような呟きが漏れてしまうことは、日常茶飯事です。
それぞれのプロジェクトには、固有の難しさと失敗の原因が存在するでしょう。いわく、新しい技術にエンジニアが慣れていなかった。いわく、客のキーマンがモンスターカスタマーだった。いわく、オフショア先の品質が低くてメチャクチャなコードが上がってきた――これらはいずれも嘘ではありません。「幸福な家はみな同じように幸福だが、不幸な家の不幸には独自性がある」というトルストイの言葉通りです。
しかし、あたまもやる気も人並みにある人間たちが数十年取り組んできて、それでもなお失敗を繰り返すのだとすれば、それはシステム開発という仕事に何かしら構造的な問題が潜んでいると考えるのが合理的というものです。この問いに対する本書の回答はシンプルです。
作り手の進め方が悪い
「……はい、どうもすいませんでした」。いや、「進め方」という書き方をしましたが、これは別に開発の方法論とかプロジェクトマネジメントの技法に欠陥がある、という意味ではありません。システム屋は、何かと物事を技術論に落として考えようとする癖を持っていますが、本書が指摘するのは、もうちょっと違う、どちらかというとメンタルの問題です。「SIerやベンダは、自分たちの立場を勘違いしている」というのが、本書の中心的なメッセージです。
システム開発がモメる場合、その相手は十中八九が客です。業者間の擦り付け合いというモメ方をすることもありますが、その場合もある程度客が関係しています。開発側と客がモメるとき、開発側は、自分たちは精いっぱいのことはやったのだ、と考える傾向があります。出された要件には従ったし、何度も変更要求を入れてくるワガママにもつきあった。何も分かっていない素人の思いつきに、もう精神と肉体の限界まで付き合った。それなのに何でこれ以上責められなきゃいけないんだよ、と。
しかし、本書が豊富な事例で示す判例は、そのような開発側に対してかなり厳しいものです。
- システムの納入が遅れた原因について要件定義が不十分であったことに対してベンダ責任を認める。（東京地裁 平成16年3月10日）
- ユーザが威圧的なため開発者が離脱したことでシステムを完成させられたなかったことについてユーザ責任はないと認める。（東京地裁 平成19年12月4日）
- パッケージに機能が不足していたことを採用したベンダの責任と認める。（東京地裁 平成22年1月22日）
こうした判例におけるポイントは、「ユーザはシステムに関しては素人なのだから、開発主体はプロとして開発プロジェクトをリードする義務がある。ユーザに言われたことや契約書に書いてあることだけやりました、と言ってもその理屈は通らない」ということです。
開発側は、ともすると「契約書や仕様書に書いてあることだけ満たせばいい」という発想をしがちです（Contract is contract）。しかし、たとえRFP通りのシステムが出来上がったとしても、それが実用に堪えなければ、「常識的にそれはおかしいだろ。プロなんだから、たとえ書面に書かれていなくても柔軟にそこは補えよ」という判断を裁判所は行う、ということです。客の検収が終わった後でも、実用に堪えなかった場合はベンダ側の責任が問われることもある（p.133）。言われてないから知りません、では許されないのです。
このように開発側から見ると厳しい判断が行われる理由は、システムという分野の専門性が高く、買い手と売り手の間に知識の非対称性が大きいからです。いわば、医療や法曹と同じレベルでの注意義務が、作り手には求められるのです（収入は大分違う気がするが、ドンマイ）。
最近も、要求仕様に明記されていないセキュリティ対策を行っていなかったことが開発側の責任として認められる判決が東京地裁から出ました。「たとえ明文化されていなくても、やって当たり前のレベルは言われなくてもやるべきだ」ということです。
確かに、SQLインジェクション対策をやっていないWebシステムを世に送り出したというのは、普通のエンジニアであれば身震いする話ではあります。しかし、ここまで豪快ではなくても、「客は何も言わなかったし、仕様書にも書いていない」という要求を黙って見過ごしたことは、皆さんにもないでしょうか。それは許されない態度だ、と本書は何度も釘を刺します。そこは、プロとして客に注意を促し、コストと便益を情理を尽くして説明し、体を張ってシステムを守らなければならないのだ、と。
刑法の世界には不作為の罪という概念があります。普通、罪というのは何らかの能動的な行為に対して問われます。しかし、よからぬ事態が出来することを知りながら適切な防止策を怠ることも罪なのです。
プロジェクトのリスク管理なんかもそうだけど、ITの世界では何もしないこと自体が問題ってケースがよくあるわ。いろんな問題をただ待つわけじゃなく、積極的に探し回る神経が双方に必要なのかもね。（p.246）
これは、技術論というより、プロとしての自覚というマインドセットの問題です。エンジニアには法律や医療の世界と違って排他的な性格を持つ資格がなく、誰でも「自分はエンジニア／プロマネです」と名乗れてしまうため、人材の品質が安定せず、参入障壁も低いためコスト競争に巻き込まれてしまう、というマクロな構造問題もあるのですが、それはまあ、現場レベルで論じるには大きすぎる話です。
本書は、開発側にとっては耳の痛い紛争の事例が豊富に紹介されています。また、プロジェクト管理やリスク対策にはコストがかかることを理解するべきだ、ということをはじめとして、ユーザ側にとってもSIerやベンダとうまく付き合うためのコツが紹介されており、双方にとって有用な知見が得られます。もっとも、本書をユーザ側が読むと「ふーん、開発サイドってのはそんなに立場が弱いのか・・・なるほどね」と悪用するためのガイドとしても使えそうな予感がするのは・・・気の回しすぎですかね。
新著が出ます：『おうちで学べるデータベースのきほん』
参考に、以下にまえがきと章立てを引用します。
データベースというのは、初心者から見ると具体的なイメージのつかみにくく、それゆえ学習のとっかかりを見つけにくい分野です。プログラミング言語やWeb サイトの作り方が、具体的な目的意識と手触りを持って学べるのとは対照的です。「データを貯める場所なのだろう」ということは想像が付くものの、それ以上何をやっているのかとなると急に曖昧になるのがデータベースの難しさです。本書は、そのような初心者が感じる「イメージの湧きにくさ」を緩和することに重点を置いた入門書です。
対象としては、プログラマーやエンジニアといった「プロ」を目指す人たちだけでなく、営業や一般企業の情報システム部門など、「ユーザ」としてデータベースを扱う方々も含めています。
本書を読むことでデータベースのイメージと役割が以前よりはっきりと結べるようになれば、そして「結構奥が深くて面白いのだな」と思ってもらえれば幸いです。
Chapter List
- Chapter 01 データベースって何だろう
- Chapter 02 リレーショナルデータベースって何だろう
- Chapter 03 データベースにまつわるお金の話
- Chapter 04 データベースとアーキテクチャ構成
- Chapter 05 DBMSを操作する際の基本知識
- Chapter 06 SQL の基本を学ぼう
- Chapter 07 トランザクションと同時実行制御
- Chapter 08 テーブル設計の基礎
- Chapter 09 バックアップとリカバリ
- Appendix パフォーマンスを考えよう
1〜4章で（リレーショナル）データベースの概略や基本的な設計の仕組み、そしてお金のカラクリ（データベースに限らず、システム開発というのは巨額のおカネが動く一大プロジェクトです）について理解し、第5章からMySQLを操作しながらSQLや機能を学んでいくという構成をとっています。これによって、実際にデータベースを触ることになるプログラマから、エンジニアに要求を伝えるユーザ企業の情報システム部門、お金の勘定をしなければならない営業（そして営業と戦うことになる各種の人々）まで、幅広い人たちにとってデータベースの基本を学ぶことができる書籍になったと思います。共著というのは初めてでしたが、一人で書くよりも豊富なアイデアと気づきを盛り込むことができて、個人的にもけっこう勉強になった仕事でした。
なお、現在もう一冊、こちらは中級向けの書籍ですが、刊行に向けた準備が進んでいます。発売時期は春ごろ予定なので、また時期が来たらこのブログで告知します。それまで皆さん、風邪などひかぬよう頑張っていきましょう。
新著が出ます：ジョー・セルコ『プログラマのためのSQL 第4版』
皆さん、お久しぶりです。長らくブログの更新が止まっていたのは、少し大きな仕事をしていたためです。ジョー・セルコ『プログラマのためのSQL 第4版』の翻訳。これに集中するため、ブログもやらずTwitterもやらず（こっちはちょっとやってしまった）頑張っておりました。
長かった。
本当に長かった。
原著が800ページ以上あるうえ内容も簡単ではないので、もともと楽な仕事とは思っていませんでしたが、いや大変でした。ですが無事今月刊行とあいなりました。すでにAmazonはじめオンラインショップでも予約受付を開始しています。あらかじめ言っておきますが「表紙のおっさん誰？」という質問は私にはしないように。私も答えられないので（笑）。
さて、本書の内容を紹介する代わりに、少し長くなりますが訳者前書きを引用します。購入するか判断の参考にしていただければと思います。なお、実行環境としては前書きでも書いていますが、PostgreSQLがおすすめです。
本書は、米国データベース界を代表するエンジニアであるジョー・セルコ氏の著書『JoeCelko’s SQL for Smarties』第4 版の邦訳である。SQLに関して、おそらく世界で最も網羅的かつ体系的に記述された本であり、また高度で実践的なテクニックを満載していることから、英語圏でSQLを学んだり仕事で使う人々にとっては、不動のバイブルとして位置づけられている本である。
原書第2版の邦訳は、2001年にピアソン・エデュケーションから刊行されたが、それから第3版を飛ばして、久々の訳出となる。著者も述べるように、この間のSQLの進歩には目覚しいものがあり、本書もSQLの新機能に対応するべく大幅なアップグレードが行われている。「新しいSQL」を学ぶすべての人にとっての導きの書となるに相応しい重厚な内容であり、本書を訳出できたことは、一人のDBエンジニアとして非常に嬉しく思う。
さて、本書を読む人々のために、ここで本書の内容について簡単なガイドを行いたい。本書は、全39 章からなるが、大きく前半と後半に分けられる。前半は第12章まで、後半は第13章以降である。前半は主にSQLおよびリレーショナルデータベースの基礎的な概念や理論的枠組みについての解説が行われる。後半は、それを踏まえたうえでSQLの持つ多彩な機能の解説と高度な応用テクニックが紹介される。基本的には第1章から順に読んでいくシーケンシャルな読み方でかまわないが、もし読者が手っ取り早くSQLのテクニックを知りたい、あるいは前半をパラパラめくってみて、内容をある程度承知していると感じたならば、第13章から読み始めて、適宜必要な前半を参照する、という読み方をしてもよい。第13章は正確にはSQLのテクニックを解説した章ではないが、必ずすべての読者に読んでもらいたい。「本書の中で最も重要な章は？」と訊ねられたら、迷わず第13章と答えるだろう。
第12章までの前半では、テーブル、ビュー、プロシージャ、トリガーといったデータベースで扱われるオブジェクト、SQLのデータ型、および制約といった概念が扱われる。そのとき核となるのは、リレーショナルモデルと、ファイルシステムや手続き型に基礎を持つ言語との考え方の違いである。私たちはまず、こうした伝統的な言語で身につけた考え方をいったん忘れて、まったく新しい観点で物事を見ることを要求される（SQLに限らず、何の分野であれ、これが一番難しい奥義なのだが）。第13章以降では、EXISTS、LIKE、結合、HAVING、ウィンドウ関数、CASE式といった、SQLの持つ強力な武器の多彩な応用方法を学んでいく。
なお、本書ではいわゆるモデリングや正規化についてはほとんど触れられない。正規化については第9章で取り上げているが、主に理論的解説にとどまり、実践的なケーススタディなどは扱われない。また、トランザクションや同時実行制御についても、第2章で簡単に触れられるのみであるため、こうしたテーマについては別に適切な書籍にあたってもらいたい。
また、本書は原則として標準SQL に準拠する構文で書かれているため、基本的には特定のDBMSに依存しないSQLを学ぶことができる。「基本的には」と留保を付けたのは、標準SQLに対する準拠のレベルは実装によってバラつきがあり、特定のDBMSではそのままの形では使えない構文も含まれているからだ。そのような場合は、適宜訳注にて説明を補っているので参考にしてもらいたい。願わくば、次の版ではこのような訳注の数が減ってほしいものだ。ちなみに、本書のサンプルコードをそのままの形で最も多く実行できる実装は、おそらくPostgreSQLであろう（翻訳時に動作確認環境としてPostgreSQL 9.1.1を使用した）。
ただし、例外的にストアドプロシージャやファンクションについては、Oracle Database のPL/SQLによる構文を掲載している。この理由は、標準SQLによる構文はどの実装でも動作しないため、原著に掲載されているプロシージャやファンクションのサンプルコードを動かせる実装がなかったためである。そこで本書では、動かないコードを載せるよりは実際に動くコードのほうがよいと考え、シェアの高いDBMSであるOracle DatabaseのPL/SQLを採用した（悪いことに、プロシージャやファンクションの構文はDBMS間でもバラバラである）。
最初に述べたように、本書はSQLの教科書としては疑いなく最高峰の水準である。だがそれだけに、本書を読み進めるのに難しさを感じる人もいるかもしれない。その場合は、あわせて読むことを推奨したい本がある。1つは、同じ著者による『SQLパズル 第2版
』（翔泳社、2007）である。これは、さまざまなパズルを通じてSQLのテクニックを身につけるという、いわば「練習問題集」にあたる本である。もう1 つが、拙著『達人に学ぶ SQL徹底指南書
』（翔泳社、2008）である。これは、もともと本書の理解を助けるための「副読本」として書いたものである。肝心の教科書の登場が一番遅れてしまったが、ともあれ、これで教科書、問題集、副読本が揃ったことになる。
最後に、本書を買うかどうか迷っている人に対して、判断の指針を与えたい。もしパラパラとめくってみて、「これはちょっと、まだ歯が立たなそうだ」と感じたならば、いったん本書を棚に戻し力を蓄えてから戻ってくる、というのは賢明な判断である。著者も言うように、本書はお世辞にも初心者に優しい書き方はしていない。だが、もし本書の値段を見て躊躇しているならば、間違いなく本書は「買い」であると背中を押したい。というのも、見かけの値段に反して、実は本書は「安い」本だからだ。その理由は、本書をとことん読み込んでしまえば、あとは中途半端なSQLの参考書など1冊も読む必要がなくなるからだ。その点で、本書は非常に「コスパ」の良い本なのだ。
本書が日本のデータベースエンジニアにとっても導きの書となることを祈っています。
Club DB2 でゲスト講師をしました
昨日 7/13 に渋谷マークウェストで Club DB2 のゲスト講師としてお話をさせていただきました。RDB の設計における物理と論理のせめぎあい（トレードオフ）というテーマで、前回以上に自由に喋らせていただきました。いつもながら運営の寛大な方針に感謝しています。ご参加いただいた皆様、お疲れ様でした。
講演では説明が足りなかった部分、また質問をいただいたことで改めて自分でも考えてみたことを、少しここで補足しておこうと思います。
- ぐるぐる系が悪いケース
まず、前提としてぐるぐる系が猛威を振るうのはバッチです。オンラインでは、そもそもループ回数が少ないので大きな問題にはなりません。講演でも、最初にこのことを明示して話を進めるべきでした。前提をはしょったせいで混乱を招いたかもしれません。
- ぐるぐる系を並列させるのはどうか
ループそのものは直列だとしても、ループ自身をジョブレベルで並列させれば、立派な並列分散になります。私の拙い理解では、Hadoop はまさにそのような仕組みです。
ただし、この並列が有効にスケールするためには、シェアードナッシング的な構成を取る必要があります。ディスクがボトルネックポイントになるケースでのぐるぐるは、どれだけループを並列させてもスケールは難しいでしょう。
- 更新処理が入るとシェアードディスクがスケールしないのはなぜか
同じデータ更新によるロック競合、というお話した問題のほかに、キャッシュの同期更新のオーバーヘッド、という問題もあります。更新が発生すれば各ノードが持っているキャッシュも更新されるため、更新処理が多くなるほどこのオーバーヘッドが多くなり、スケールしなくなっていきます。「更新処理がどの程度含まれているか」というのは業務系ベンチマークを評価するときのポイントの一つなので、皆さんも覚えておいていただければと思います。
豹変しない日本人
先週、大阪市の橋下市長が、関西電力の大飯原発の再稼動を容認する声明を出しました。これまで積極的に脱原発の方針を推し進め、原発の再稼動にも反対してきた橋下氏としては、ほぼ180度の方針転換といってよい内容です。
長期的な方向性としては脱原発にも合理性はあるものの、直近の電力供給事情を考慮すれば、「机上の論だけではいかない」という橋下氏の判断は現実的なものです。あまりに潔い転換だったので、あるいは、最初からこのあたりの落としどころを狙いつつ、当初から容認の姿勢を見せては電力会社がつけあがるので牽制していただけなのでは？ という疑念も浮かぶぐらいですが、これは憶測の域を出ません。
今回の件もそうですが、橋下市長には、よりよいオプションが出てきたらすぐに旧来の路線を捨てて乗り換える、という柔軟さがあります。それは一面では、一貫性がないという批判も可能な態度ですが、しかし大阪市という巨大なシステムを運営する立場にあることを考えれば、市長として大事なことは、一貫した主張に従って間違えることではなく、無軌道であろうともシステムをクラッシュさせることなく維持することです。橋本市長はよく自分を学者と対比して「非インテリ」を標榜していますが、それはこのような柔軟なプラグマティズムの表明とも受け取ることができます。
もっとも、このように間違いをすぐに認める、もっといい方法があるならそれに乗り換える、という態度は、昔から責任ある大人の心構えとして重視されてきたものです。すでに易経に「君子は豹変す」という言葉がありますし、孔子も「過ちては改むるに憚ること勿れ」と言っている。とはいえ、そうは言ってもなかなか・・・。人間誰しもプライドがあるので「自分がバカでした。どうもすいません」と素直に頭を下げるのは、（頭がよく有能な人であればあるほど）簡単にはできない。橋下市長の「非インテリ」という自己規定は、そういう心理障壁を下げるための役割も果たしているのかもしれない。
また、自分の間違いを素直に認めることが難しい理由には、そうした行為を周囲が評価しない、という問題もありそうです。実際、今回の橋下市長の方針転換についても（特に脱原発派からは）「変節」と批判されているし、頻繁に政見を変える政治家は「風見鶏」と揶揄されます。自らの主義主張に頑固一徹な人を「軸がブレない」と評価し、「転向」した人間を一段低く見る傾向は、多くの人が程度に差はあれ心の中に抱えています。最近では、政権を取った政党がマニュフェストを守らないと、理由いかんによらずそれだけで批判されたりしますし、戦後の一時期、日本で共産党が一定の勢力を得たのは、共産主義者が戦前戦中に、投獄されようとも非転向を貫いたことで、人格の高潔さが評価されたからでした（そのような非転向が持つ頑迷さの危険を指摘したのが、最近他界した吉本隆明です）。
もしかすると、私たちがこのような「変節」や「転向」を忌避する背景には、ある種の人間観、日本人に固有のバイアスが潜んでいるのかもしれません。それは、「人間の賢さにはピークがあって、大人になってからさらに賢くなることはない」という頭打ち人間観です。The Economist の記事「私たちは歳を取るほど賢くなるか？」では、日米の成人に対して一種の知性テストを行って、年齢によって賢さに差が出るかどうかを比較する研究が紹介されていました。結論は、次の二つです：
- 若いときは、日本人の方がアメリカ人よりも賢い。
- アメリカ人は年齢とともに賢くなるが、日本人はあまり変わらない。そのため人生の後半ではアメリカ人が逆転する。
この結論は、これまでも日本人とアメリカ人の「成長曲線」について巷で言われてきたことと一致します。日本では、大学受験が厳しいため、子どもの頃にかなり勉強します。でもいったん大学に入ってしまうとそこはレジャーランドだし、大学院に進むと就職先がないということで学部で卒業する人が多いし、いったん卒業したらもう大学に戻って再度勉強する人もほとんどいません（大学への入学者に占める社会人の割合は、OECD 平均が 21.3% に対し、日本は 1.8% ）。そのようなわけで、日本人の知的能力については、以前から「18歳限界説」が唱えられていました。ユニクロのように大学卒業していなくても内定を出すという採用方針を打ち出す企業も、この説を支持していると言えるでしょう。
一方、アメリカの場合は、高校までの勉強はそれほど厳しくなく、大学の入試も（一部エリート校を除けば）ゆるいと言われています。その代わり、大学でも勉強をサボればすぐに退学になってしまうし、社会人になった後でもキャリアアップのために大学院へ戻って勉強する人も少なくない。そのようなわけで、若い頃はアメリカ人より上を行っていた日本人は、何十年後かにはアメリカ人に負けてしまう・・・こう書くとなんだかウサギとカメの話みたいですが、私たちが政治家や学者の食言を嫌う心理には、自分たちがカメではなくウサギなのだと、心の奥では知っているからなのかもしれません。
