本の読み方を知らない新人さん

新人：「パラメータはコンフィグファイルに記述って仕様に書いてありました」

わたし：「それがどうしてレジストリにつながるの？」

新人：「コンフィグファイルを検索してたらレジストリというのが出てきて、それを理解できないとコンフィグファイルの操作方法が分からないのかと思って...」

プログラマで、生きている: ググるな危険

この話に出てくる「コンフィグファイル」というのは、 おそらく、 .NET Framework での 拡張子 .config のファイルのことなのだろうと推測します。 Windows アプリケーションの場合は app.config 、 Web アプリケーションの場合は web.config というファイルを使うことになっています。 Microsoft の用語では、 「構成ファイル」 になっていますね。

.NET Framework の構成ファイル スキーマ ( MSDN )

.NET には、バインディングと呼ばれる仕組みがありまして、 Visual Studio のデザイナでフォーム上に配置したコントロールのプロパティと、構成ファイルの XML 要素をマッピングしておくと、自動的にプロパティを読み書きしてくれる、という機能があるんですよね。 これは、フォームのコントロールに限らず、任意のオブジェクトのプロパティで使えます。

上の話は、新人さんに、 .NET の入門書と仕様書を渡して、作業を指示した、という話なのではないですかね。入門書には、 app.config 、 web.config の説明ぐらいはあったのではないかと思うのです。つまり、この新人さんは、読むようにと渡された、入門書を読んでいない、ということになりますね。渡された本を読まずに Google で検索していると。¹

入門書が読めない人に、プログラミングの仕事を教える、というのは、かなり厳しいと言わざるをえないですねえ。 Google がどうとか、受身だとか、そういうレベルじゃないと思います。 OJT で読書のやり方から教えるというのは、不可能でしょう。

学生時代、 1 冊も本を読まずに済ませてきたのだとすると、それはそれですごいですね。

---

1. .NET について調べるなら、 Google じゃなくて、 MSDN でしょうね。入門書を読めないレベルですと、 MSDN の資料を読むのは無理でしょうけど。

RDBMS の制約の使い方

制約というのは、一意性制約、参照整合性制約、チェック制約などのことです。

個人的には、 RDBMS の制約の典型的な使い方は、 トランザクションの並行実行によって発生する、競合状態 ( race condition ) の検出に使う、というものだと考えてまして。アプリケーション側で、レコード・ロックだの、テーブル・ロックだのやるくらいなら、 RDBMS に任せてしまうが良い、と考えています。

簡単なので、一意性制約の例を挙げますと。単に、テーブルに、値が重複してはならないフィールドの集まりがあるわけですな。

そうすると、2つ以上のトランザクションが、この制約を満たすために、テーブルに既に値があるかどうかを、 SELECT で確認して、それからレコードを INSERT するなり、 UPDATE するなりする、という状況が起きる。 いわゆる、 check-then-act な競合状態が起きるわけです。

ここで、アプリケーション側で RDBMS のロック機能を使って atomic にするというのは、あまりよろしくない。 RDBMS にこんな地雷を埋め込んでいると、新しくリリースされたアプリケーションが、同じ RDBMS を使って、デッド・ロック起こしたり、パフォーマンス障害を起こすのは時間の問題と考えて良いでしょう。

ですので、素直にテーブルのフィールドに一意性制約をつけて、 RDBMS に重複を検出させるのがよろしかろうと思います。 もちろん、アプリケーションのデータ・チェックで、重複回避のために値の存在確認はさせるべきです。RDBMS の制約は、あくまで競合状態の検出にのみ使います。

当然のことながら、 制約を安易に多用しますと、RDBMS 内でロックを多発させることになって、パフォーマンス劣化を引き起こします。 RDBMS の制約は、並行処理の設計の問題であって、単なる RDBMS の便利機能ではありません。アプリケーションのデータ・チェックの代用にはなりませんので、悪しからず。

制約違反が大量発生して RDBMS がとてつもなく遅くて困るって？

アプリケーションが、データ・チェックをさぼってないか、確認してください。本当にそれらの制約が必要なのか、もう一度よく検討してください。

もしそれが、競合状態の多発を意味しているのであれば、根本的にシステムの設計がまずい可能性があります。非同期にして直列処理することを考慮しましょう。ハードウエアのキャパシティ不足であるなら、ハードウエアの増強を検討しましょう。

ソフトウエアの「消費コスト」

というのか、何かそんな概念について。

「ソフトウェア工場はうまくいかないんですね。なぜなら部品の組み立てに相当するものが、アップロードとかDVDに焼くといった工程ぐらいしか存在せず、効率化しようないからです」。

「ソフトウェアは工業製品ではない」 Rubyのまつもと氏が講演 ＠IT

確かに、計算機プログラムの「製造」工程というのは、ソース・コードのビルドであり、サーバへのアップ・ロードであり、 CD/DVD への書き込みであったりして、製造コストは限りなくゼロに近い − 少なくとも「設計」にかかるコストに比べれば − とは思うのですが。

しかし、計算機プログラムには、「設計」以外にも大きなコストが存在すると思うのですよね。

例えば、計算機プログラムを音楽 CD のようなものと比較した場合、大きな違いがあって、それはユーザの「消費コスト」というのか、「使用コスト」のようなものの存在だと思います。つまり、計算機プログラムの入った CD を買ってきて、 PC の CD-ROM ドライブにセットして、「再生」ボタンを押せば、即座に「消費」可能 − ユーザがその製品の付加価値を得ることが出来る − かといえば、否なんですよね。

ユーザが計算機プログラムを入手してから、ユーザがそのソフトウエアの付加価値を享受するまでには、通常、長い道程があるわけです。何百ページだか何千ページだかあるマニュアルと格闘しつつ、ソフトウエアをインストールし、ソフトウエアの使い方を学び、様々な設定をほどこし、データを入力し、そして、ちょっとしたプログラムを書く必要があったりするわけです。

かくして、この大きな労力を必要とする仕事を、ユーザの代わりに行い、ユーザがソフトウエアを使えるような状態にまで持っていく（ターン・キー）、というビジネスが生まれたわけでして。いわゆる SIer と呼ばれる産業です。

こうした、ソフトウエア・ベンダー、ハードウエア・ベンダーから、ユーザまでの「ラスト・ワン・マイル」 − 現状はワン・マイルどころではなさそうに思いますが − を担当する仕事というのが、それなりに大きな産業として存在しているわけです。

そこで感じたのは、現場の科学者が「明日にでも計算したい問題を抱えている」ということは、観念として理解されることはあっても、実感としてはわかってもらえないらしいということであった。彼の答えは、逆に、私の専用機を作るという火に油を注ぐことになった。やはり、自分でやるしかないのである。

杉本大一郎, 『手作りコンピュータへの挑戦 テラ・フロップス・マシンをめざして』, 講談社 ブルーバックス B-956, 1993

上に引用したのは、かの GRAPE 計算機の開発話ですが。著者が、計算機メーカー、計算機科学者への愚痴（？）のようなものを書いています。それは、計算機メーカーや計算機科学者は、「汎用」の問題を解くことにばかり熱心で、科学者の抱えている個別の問題には関心を持ってくれない、といったことです。

これは、計算機ビジネスの構造的要因から来ていると思うのですよね。つまり、ソフトウエアにしろ、ハードウエアにしろ、ベンダーは可能な限り多くのユーザを獲得しなければならないわけでして（業界では「ユーザ・ベース」とかいってますね）。そうすると、システムは可能な限り「汎用」に作る必要が出てきます。特定の問題にフォーカスしても、それこそ、特定の少数のユーザしか得られませんからね。

しかし、「汎用」なシステムを、ユーザが自分の問題解決に使おうとすると、あれこれと自分で作業をする必要が出てくるわけです。このジレンマが解消する日が、いつかは来るのでしょうかね？

基本設計と見積もり

基本設計というのは、費用・工期を見積もることができるレベルの設計といいます。 が、なぜか IT システムの世界では、基本設計の前に顧客に見積もりが提出され、「一括請負契約」が締結される、という不可思議なことが行なわれていたりします。「一括請負契約」が締結された後で、基本設計作業に入ることになるんですよね。

プラント・エンジニアリング業の方が書いた、プロジェクト・マネジメントの本を読むと、基本設計作業と並行して契約交渉が行なわれ、基本設計完了後、競争入札等で、契約が締結される、などと書かれています。基本設計の費用は、全部ベンダーの営業経費になるのかしら、と少し疑問に思っていたのですが、以下の話を読む限り、基本的にはそういうことみたいですね。

見積が無償なのは、むろん日本だけのことではない。しかし、私は海外で、ある欧米系石油メジャーに対する見積業務に従事していたときの経験を覚えている。案件は競争入札だった。大型プラントの見積作業は、それ自体が億の単位の費用を要する。ところで、その顧客は、応札者に対して、「入札要求仕様書（基本設計書）のベリフィケーション費用」という名目で、かなりの金額を支払う約束をした。

それだけではない。経済状況の乱変動に伴って、見積期間中に顧客の要求事項もあれこれと変化して、ついていくのがひどく大変な状況になった。すると、入札締切の直前に、顧客はベリフィケーション費用を50% 増額する、と宣言し、そのとおり実行したのだ。この時以来、見積はいつでも無料であるべしという感覚が、自分の中から抜け落ちてしまった。

お見積りは無料です (タイム・コンサルタントの日誌から)

IT システム業界の場合、売り手と買い手の同床異夢になっているように思います。

買い手は、「見積もりは無料」だと思っているし、売り手もそう思わせている。しかし、基本設計どころか、要求定義もろくにおこなってないわけですから、その見積もりは、極めて粗悪な代物です。

売り手としては、買い手から早く現金を引き出したいものですから、粗悪な見積もりでも、とにかく契約を結んでしまおうとするわけです。工期は短ければ、短いほど良い。今期の売上ノルマに追加できますからね。

買い手からみた場合は、おそらく、早くベンダーに責任を「丸投げ」してしまいたい、というのがあるのでしょう。見積もりが粗悪であろうがなんであろうが、「一括請負契約」である以上、ベンダーは「最後まで」責任を負うはず、ほぼ無限責任に近い責任が生じるはずだ、というところですかね。

これは、実のところ、買い手の幻想にすぎず、「請負」の対象が明確に定まらなければ、つまり、基本設計が完了していなければ、請負契約は法的に成立しないわけでして。契約を結んだと思っていても、法的には契約は成立していない、という奇妙な状態となります。

このような不安定な関係で、仕事が曲りなりにも成り立つのは、売り手と買い手との間に、一定の信頼関係がある場合だけなのでしょう。結局、長期の取引関係を前提に、ということになります。実際、「一見さん」との取引は、 9 割くらいの確率でトラブルに発展しているような感がありますね。

ソフトウエア工学とは何ぞや

私にとって、「ソフトウエア工学的なもの」の代表例は、オブジェクト指向だったりします。

オブジェクト指向は、少なくとも、「計算機科学的なもの」ではないと思いますね。計算機科学者がアルゴリズムを研究したり、定理を証明したり、学術論文を書いたりするのに、オブジェクト指向が役に立つとは思えませんし。

Wikipedia の Software engineering のページを見てみます。

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches. That is the application of engineering to software.

Software engineering (Wikipedia, the free encyclopedia)

"Sub-disciplines" のところから少し辿ってみますと、 "agile or waterfall" (Software development process) 、 "versioning and source control”（Software configuration management） 、 "Refactoring tools" 、 "Source code generation tools"、 "Unified Modeling Language" (Computer-aided software engineering) などが挙がっていますね。

「ソフトウエア開発に関する何か」であれば、それは、計算機科学というよりは、ソフトウエア工学ではないですかね。従って、ソフトウエア開発の生産性が云々というのも、ソフトウエア工学でしょう。ソフトウエア開発の生産性を議論すること自体が無駄である、というのなら、それは確かにソフトウエア工学の否定かもしれません¹。

---

1.「生産性についての議論は非生産的である」という至言

「更新系」はどこへ？

正直、何を根拠にAPサーバで処理した方が良いなどと言ってるのか、いまだに分かりません。私がアホなんでしょうが、口汚く罵って煽ってみても、そういう主張の方のコメントが得られなかったのは残念です。炎上もさせられなかった（笑）。

炎上までいかなかったけれど、たくさんのご意見ありがとうございました(ベンチャー社長で技術者で)

私も「APサーバで処理した方が良い」という話はよくわからないのですが。

一連のお話を読んでいて、少し思ったのは。

ユーザーインターフェイスに必要なパラメータと戻りはダミーのストアドプロシージャの中に含まれています。更新系では、画面側の項目と、セッションIDやログインIDなどが必要になるかもしれませんが、戻りはエラーコードやエラーメッセージを返せば済みます。

更新系に必要なものは、システムの共通仕様として、あらかじめ、まとめておけばよいことです。

テーブル設計は実装の後に！ (ベンチャー社長で技術者で)

と、当初は「更新系」、OLTP系の話が少し出ているのですけど。

当たり前ですが、

（クライアントへ）データ転送 > データスキャン >>>> 四則演算

つまり、DBで1回テーブルスキャンするのと、そのときに集計処理をついでに行うのはパフォーマンスには差が出ませんから、DBサーバにとって四則演算をどこかで肩代わりしても意味がないのです。

SQLを使うとスケーラビリティの問題が起きる？ それはエコじゃないね (ベンチャー社長で技術者で)

後半では、完全に集計処理、OLAP系だけの話になってしまっている、というところです。

大量のユーザが、大量の更新をかけるような、OLTP系のシステムの場合、 DBサーバをスケール・アウトしたい、ということはあるのではないですかね。

こんな感じで、OLTP系処理に対しては、DBサーバを複数台用意して、DBサーバ1台あたりの書き込み負荷を下げる。OLAP系処理に対しては、もう一台、集計用のDBサーバを用意して、そこで集計をすると。

まあ、別にOLTP系処理で、 テーブルを直接書きにいかずに、ストアド・プロシージャー経由でも、全く問題ない と思います。ですので、別に結論は変わらないのですけどね。

ただ、OLTP系の場合は、「スケーラビリティをあげるために、処理は極力DBサーバで行うべき」は言いすぎかもしれません。当たり前ですが、 DBのデータ使わない処理まで、DBサーバでやる必要はないですから ね。 「生の入力データ」（例えば、HTML）を、そのまま DBサーバに渡して、DBサーバで解析・バリデートとか。

結局のところ、 データに対する処理は、そのデータのある場所に近いところで行なうのが良い、という話でしょう。昔から言われていることですが。

顧客とリスクについて話すのは難しい

見積もり2億のIP電話が820万円で構築できたという話について。

「年に1日コケても良ければシステム価格は1/10になります」とか「システムがコケても〜〜とやれば問題は起きません」ということが提案出来るベンダーは素晴しいし、それを受け入れることが出来るユーザは賢いだろう。でも、それはベンダーにとっては「ビジネスチャンスと信頼の両方を失なう」ことになりかねない。

おごちゃんの雑文 「2億円が820万」

ほぼ同じ感想を持ちました。

丁度、システム一式移設という話が来ていて、見積もりを作っていたのですけど。見積もり依頼は、「一枚ペーパー」すらなく、口頭で営業担当者が、ひとことみことで言われただけらしい。顧客側は、具体的なことは何も考えておらず、「とりあえず概算が知りたい」のだそうで。

実際の発注は、競争入札になるのでしょうけど。その前に、顧客側内部の手続きで、企画・稟議を書く必要があるので、予算がいくらになるか知りたい、という話でしょう。で、現システムの担当である私に、「ざっくり」教えてくれ、というわけです。

まずは、考えうるすべての可能性を考慮しつつ、可能な限り、必要な成果物・作業を洗い出しします。いわゆる、 WBS と呼ばれるものを作るわけです。

WBS が出来上がれば、次は、顧客側作業・ベンダー側作業、顧客が負うリスク・ベンダーが負うリスク、と項目を顧客とベンダーに振り分けて、ベンダー（つまり自社）に振り分けた項目に、見積もりの数字を入れていくわけです。見積もりの「前提条件」というやつですね。

いつものことながら、「前提条件」をどうするかで、頭を悩ませていました。システムの停止期間はどのくらい許されるのか、顧客側作業としてどこまでお願いできるのか、移設後の動作確認・検証はどこまでやるのか、などなど。

この辺は、顧客の事情・懐具合を探りつつ、数字を入れるわけです。

私の段階では、「見積もり」には、顧客側作業、顧客の負うリスク等の「顧客側負担」は、書かれているのですが。おそらく、部門上長・営業を経由して、顧客の手に渡ったときには、消えているでしょうね。「そんなことはとてもお客様にはいえない」、つまり、「ビジネスチャンスと信頼の両方を失なう」ことになる、というわけです。

顧客・ベンダー双方で、リスク負担と責任分岐点、それとコスト負担とのトレード・オフについて、冷静に話し合うことができれば、建設的なんですけどね。それが本来の契約交渉というものの姿であろうとも思うわけですが。これが、日本ではなかなか成り立たないのですよね。

DBサーバの性能

昨年末、約10年前のノートパソコンに、Vine Linux をインストールしていたのは、 OSDL Database Test Suite の Database Test 1 (DBT-1) を試してみようと思ったからだったりします。

テストデータベース (PostgreSQL 7.4) は出来上がったのですが。

DBT1=# \timing
Timing is on.
DBT1=# select count(*) from orders;
  count
---------
 2593048
(1 row)

Time: 31606.238 ms

260 万件程度の集計で、 32 秒かかるという遅さ。

ちなみに、某 Oracle データベースのサーバ機で、似たような集計を試してみますと。

SQL> set timing on
SQL> /

  COUNT(*)
----------
   3128119

経過: 00:00:00.17

まあ、10年前のノートパソコンと、最近のサーバ機を比べても勝負になるわけないのですけどね。

メモリ搭載量が、 192MB 対 5GB ですからね。 Oracle のサーバ機の方は、ディスクアクセスがほとんど発生していないのではないですかね。ディスクの性能も全然違うでしょうけど。おまけに、サーバ機の方は、 RAID 1 構成ですし。

APサーバ追加でスケール･アウトできるのはユーザ数では？

以下の一連の話を、面白いと思いながら、読ませていただきました。

スケーラビリティが上がるというのは、「APサーバの増設が簡単」ということになろうかと思います。確かに簡単に追加できますが、それはエコじゃないね〜。

SQLを使うとスケーラビリティの問題が起きる？ それはエコじゃないね (ベンチャー社長で技術者で)

クライアント・サーバ・システムで、「パフォーマンスがでない」という相談を受けて、プログラムを見せてもらうと、アプリケーション側で、データベースからフェッチしてきたレコード 数百万件を集計していた、というのはよくありますね。 SQL でやれば、 数秒で終わるような処理の典型例です。

毎回、DBサーバから、ネットワーク越しにレコードを受け取りつつ、アプリケーション側でループまわして集計してたら、そりゃ遅いですよね。

また、こうした集計処理というのは、単純に「APサーバの増設」では、スケール・アウトできないですよね。それこそ、 Google の MapReduce のように、集計処理を分散して実行する仕組みがないと。

よくある、 Web（AP）サーバ ・ DBサーバ での、Webアプリケーション構成では、Webサーバ、 APサーバ の増設でスケールアウトできるのは、 同時接続ユーザ数 であろうと思うわけです。

しかし、企業内システムで、 Google や Yahoo! のように、 数千万人のユーザ がアクセスしてくる、なんてことはないわけでして。大企業でも、システムのユーザ数は、せいぜい 1万人 くらいですからね。

私も SQL という言語自体はあまり好きではなかったりするのですが（CODASYL 風味なところが）。企業内システムでは、強大な威力を発揮するというのは、確かです。仕事では、 SQL （と Oracle PL/SQL） ばかり使っていますしね。

何回目のITシステム統合？

現在、ばらばらに管理されている ITシステム を ＸＸＸ で統合して、バラ色の未来、みたいな話は昔から繰り返されていますね。

To the CIO, CEO, CFO, CTO and shareholders,

As a result of the following I can now only deduce that SOA is a failure and any attempts at SOA will result in failure.

Ahh Shucks, SOA Is A Failure

SOA は失敗だった、という記事。

まあ、この種の試みというのは、大抵は失敗に終わってきたわけでして。

そもそも、統合＝善と短絡に考えるのもどうかと。そりゃ、ＩＴだけみていれば、よさげに思えるかもしれませんけど。組織が分散されているのにも、それなりの理由があるわけですからね。

I firmly believe that SOA is nothing more than fancy CORBA or COM.

しかし、この手のＩＴシステム統合のための技術というのは、 RPC 以来、ＩＴ技術者のトラウマ量産技術になっているような気がしますね。ディレクトリ・サービスも、流行期にはトラウマ発生装置と呼ばれていたような。

Thanks for understanding and I'd like to declare in advance that Cloud Computing, Virtualization and SaaS will be failures under my direction as well.

クラウド、仮想化、SaaS も失敗に終わるであろう、と。セールス・トークに「統合」が入っていたら、そしてそれを真に受けるとそうなる確率は高いでしょうね。