もし、海外のSaaSやクラウドから個人情報が漏洩したら？（愚問）

2002年発行の「IT法大全」という本の中に、米国企業であるYahooがフランスで訴訟を起こされたことが詳述されています。

フランス国内の法律ではナチスドイツ関連の物品を販売することなどが禁じられていますが、2001年当時Yahooからは購入可能となっていたため、法律に違反するとしてフランスから閲覧・販売をできなくすることを求めて、フランスの裁判所はそれを認めました。
困り果てた（※IT法大全の本の記述による）Yahooは、最終的にはナチスドイツ関連の物品をサイトから削除しましたが、それと並行してアメリカの裁判所に提訴。その結果、アメリカの裁判所は、フランス裁判所の判決内容がアメリカ国内においては効力が無いとの判決を言い渡しました。

このように国境を越える問題は非常に難しい側面がいくつか有るわけですが、そこで以下の疑問を考えてみましょう：

もし、海外にサーバがあるSaaS・クラウド、SalesforceしかりMicrosoftしかり、から個人情報の漏洩事件が発生した場合、刑事責任や賠償を問えるか？

HibernateはSQLインジェクション攻撃に対応していますか？（愚問）

「Hibernate（などのO/Rマッピングツール）はSQLインジェクション攻撃に対応していますか？」

これ自体かなり愚問ではあるのだが・・・

一般にJDBCからアクセスする場合、SQL文の文字列を自前で組み立てるよりも、RDBMSのバインド変数等（RDBMSの種類によって異なる）の機能を使用するようにコーディングすることによって、かなりのSQLインジェクション対策になる（但し１００％ではなかったような・・・）。

Hibernateについては、Hibernateクエリ言語(HQL)の文字列中に、パラメータのバインドを記述することができる。
http://www.redhat.com/docs/manuals/jboss/jboss-eap-4.2/ja_JP/html/Hibernate_Reference_Guide/Executing_queries-Bind_parameters.html

（※この記述を行えば必ずRDBMSのバインドが使われるか実際に自分は確認してませんが、一応信用するとして）

逆にいえば、Hibernateにおいては明示的にパラメータのバインドをコードに記述する必要がある、ということだ。この点ではJDBC経由で直接使う場合と手間は変わらないことになる。

Hibernateを直接使う場合はまだいいが、「Hibernateを使う」アプリケーションやライブラリ等がある。
これらがSQLインジェクションにどれくらいの耐性があるかは、「Hibernateのバインド機能」をそのアプリケーションの中で使用しているか、または使用可能かを個々のアプリケーション毎に調査しなければ分からない。

「めんどくせ～」という声が聞こえてきそうだが、めんどくさいこと自体は問題ではない。そのアプリケーションにSQLインジェクション対策を組み込むのにかかる手間がどれだけの量なのか見積もれなかったり、あるいは対策を組み込むことそれ自体が可能かどうか分からないとか、対策できているかどうかチェックする方法が分からないのだとすればそれがリスクなのだ。

儲かるIT、儲からないIT

とある飲み会（合コンともいう？）での迷言。

「IT業界には、儲かるITと儲からないITの２種類があるんだよ。例えば楽天とかiPodとかっていうのが儲かるIT。じゃあ、おれ（たち）は？。・・・儲からない方。システムを作る仕事は儲からないんだよ」

個人情報流出対策 ピンからキリまで

もう１ヶ月も前の話になってしまったが、三菱UFJ証券の顧客情報流出事件で、顧客に各種勧誘の電話がかかるなどかなりの被害が出たとのことであるが、成立前後では本屋の店頭でよく見かけた個人情報保護法対応に関する書籍が最近はあまり見かけない。こういうノウハウは一過性のものではないはずなのだか。

さて実際に流出を防止するためには、情報の流出ルートを最小化するとともに、流出抑止と流出時の早期発見・対処のためにアクセス履歴を収集する必要がある。と簡単に書いたが、どこまでやるか？　収集するレベル、RDBMSやアプリケーションの種類やバージョンによって実現可否・コストが大きく変わってくる。

アクセス履歴の収集において、いつ、どこで、誰が、何を（どれだけの数、どんな項目・・・）どのようにして（アクセス方法）アクセスしたか記録することになるが・・・

●当該のRDBMSやアプリケーションなどが記録する機能を持ち合わせているか？
一般的なWebシステムでは、データベースへのアクセスには高速化のためにコネクションプールを使用することが一般的である。したがって、そのままでは「誰がアクセスしたか」が記録できない。つまりアプリケーション側で実装する必要がある場合がある。
また、RDBMSやアプリケーションのバージョンによって、取得可能な情報が異なるので、ある製品のあるバージョンでは簡単に実装できるが、異なる製品では思わぬ苦労を強いられるといった可能性がある。

●システム管理者権限を持っている人に対する対処をどうするか？
種々のアクセス記録機能を実装したとしても、システム管理者権限を持っている人のアクセスは対象外になっていたり、あるいはアクセス記録の改ざんが可能であることはままある。RDBMSやOSのレベルでアクセス記録の改ざんまで踏まえた対策をとろうとすれば、当該システムとは別に、監査システムを導入する必要がある。そのシステムの製品だけで安くても数百万円かかるし、おそらくは対応できるRDBMSやアプリケーションの種類やバージョンには一定の制限があるはずだ。

日本製品でも同じだが、外国製品とかSaasとかクラウドといったものでは特に、必要なレベルの対処を組み込むのが技術的に可能なのかどうかは慎重に調査する必要がある。たとえば日本郵政がsalesforceを採用したときにどこまで調査したのか、個人的には興味のあるところだ。

ただしベンダーに聞くとき「この製品は個人情報保護法に対応していますか？」という聞き方では愚問で堂々巡りになりやすい。せめて「個人情報保護法に対応するために、・・・のアクセス履歴を取りたいが実装する方法が有るか？」など具体的な質問にしたい。購入前に満足いく答えが得られるかどうかは別だが。

オフショア開発が失敗する理由

「標準テキスト　オフショア　プロジェクトマネジメント【SE編】」
幸地　司、霜田寛之　著、北島義弘、倉田克徳　監修　技術評論社

まだ目次しか見ていないのに薦めるのもどうかと思うが、逆にいえば、目次を見るだけでも価値がある。

オフショア開発を行うにあたってどれだけの事項を考慮しなければならないか、目次を見ているだけでもうんざりする :-) が、逆にいえばこれらの事項はすべて無視できないものなのだろう。

実際、自分は開発にかかわっていないオフショア開発されたアプリケーションに対するバグ対応を行ったことがある。原因がわかってみれば、入力用のファイルの拡張子の異常系処理が不十分だったということで「もしインターネット上にサービスとして出していたらすぐにつぶれるぞ、ぶゎっかやろ～」と文句を言いながら、やりとりの一部を見せてもらったのだが、オフショア先の人が日本語で説明してくれているのだが、肝心の仕様の部分がよくわからない状態だった。これはなかなか実際にコントロールするのは大変だと思ったものだ。

要するに、詳細仕様をもれなく詰めてお互いに認識が合っているか確認するだけでも大きなコストがかかるということである。オフショア開発の目的がコスト削減にあるのなら、オフショア開発を採用するかどうかから、もう一度いちから見直すべきではないか。

もっとも、本当はオフショアだから問題なのではなくて、国内だけの開発でも、たまたまうまくいっていたか、あるいはやっぱり問題が起きていたということにすぎないのではないかとも思うが・・・

「高度なIT人材」とは？

「高度IT人材育成への提言　国際競争力への復権に向けて」
山下　徹　編著、NHK出版

買ってから１年くらい読まずに放置していたのですが、時間ができたのでざっと読んでみた。

日本における問題提起に始まり、諸外国の人材育成の状況や、日本の大学等で始められている人材育成カリキュラムなどに触れられている。

さて、そもそも「高度なIT人材」とはどんな人材か。この本の中ではいろいろに述べられているようでよく咀嚼できてないのだが、どうも、現場の経験とマネジメントなどのスキルの両方を有し、多方面の学際的な知識も有し、さらに自ら学びスキルアップしていく。というようなイメージのようだ。

本書のような内容がまとめられていること自体なかなか驚異的なことでもあるし、経験やスキルの必要性については常々感じるところもある。しかし・・・・

そんな便利な人いないよ～

また、「はじめに」で、「このiPodの成功こそが、国際競争力にソフトウェアが与える影響を示す象徴的な出来事だと受け止めています。」とあるが、これと求めている人材像との間にも、ずいぶんとギャップがあるように感じられる。
iPodの機能を実現するための要素技術自体は、当時としてもそれほど大それたものではなかったと思う。ただ、HDDを搭載しながら価格を低く抑えて、買ってみたい、使ってみたいと思わせる機能とユーザーインターフェースのパッケージング、そういったものは日本人は苦手なのかもしれないが・・・

要するに、いち企業の利益のために「育成させられる」としたら、たまったものではない。

F5TRAP

ひさびさの新作ですm(_ _)m。
Windows環境で[F5]キーの押下をトラップして使用不能にするツールです。

http://homepage2.nifty.com/jr-kun/software/f5trap/index_jp.html

「脱Microsoft」と言うけれど

実際には、Webシステムはブラウザに高度に依存しているわけだし、また、独自APなどで画面系の問題にクレームを付けてくるのを見ていると、暗黙的にMicrosoftのレベルを求めていることがわかる。

OSとブラウザとOfficeを相互依存しながら機能強化するとか、他社の特許技術の取り入れ方法など、やり方には問題あるにしても、機能強化と互換性のバランスは非常にうまく取っていると言える。大量の技術者を使って時間をかけているのも伊達ではないということだ。

本当に「脱」を指向するなら、それなりの覚悟がいるということだ。

SaaSってそんなに偉いのか？ その３ CRM検索機能はデータモデルに要注意

SaaSで激変するソフトウェア・ビジネス　ソフトウェア業界を揺るがす破壊的イノベーション
城田　真琴　著、毎日コミュニケーションズ

上著の「SaaSか自社開発かの判断基準」の「（９）データ構造は標準的か？」についてコメントしたい。

顧客情報に関するデータモデルがCRMアプリケーションの根幹の１つであるが、CRMの性質上、他社との差別化をはかるためにここが異なる（単なる追加ではすまない）ことが往々にしてある。

顧客管理システム開発失敗、東京ガスが損失５０億円 （Yomiuri Online)
（http://www.yomiuri.co.jp/atmoney/news/20060201i215.htm　にあったがもう消えたようです）
東京ガスは、同社とガス器具を販売・修理する協力企業の管理システムを統合する作業を２００３年に始めた。費用を削減するため、市販の汎用（はんよう）業務用ソフトを使って自社で進めてきたが、顧客情報の検索などに時間がかかりすぎて、システムが使いものにならなかった。当初予定（３０億円）の倍の約６０億円を投じ、統合時期も０４年１０月から遅らせたが、最終的に自社開発をあきらめた。費用のうち他に転用可能な機器など１０億円分を除く約５０億円を、０６年３月期連結決算で特別損失として処理する。

この中で「顧客情報の検索などに時間がかかる」という点で似た経験がある。

正規化されてテーブル間のリレーションシップが複雑化したCRMのデータモデルで、「○○県の××さんのリストを、所有している製品と一緒に一覧表示する」といった条件で検索したいという要望があった。
数個のテーブルをまたぐ検索であり、開発テスト時に数百件レベルのテストデータでは特に問題なかったが、運用環境の数十万件のレベルでは性能問題が発生した。（数分待っても応答が帰ってこない）Oracleの実行計画(Explain plan)を確認したが、すべてindexを使用して検索する計画となっており、cardinarityの数値など特に問題は見当たらなかった。
この案件の話を最初に聞いたとき、クサいと感じたのではあるが、ここまでになると想像が及ばなかった。
お客様のＩＴ部門の方に検索条件に制限をかける（一定文字数を入力してもらう）ことを交渉して一度は理解してもらえたが、エンドユーザー部門の一声で覆された。結局、１本のSQL文で検索するのをあきらめてSQL文を数本に分割して多少改善したが、数分待っても応答が帰ってこない状況に大きな違いは無かった。
実はこの状況になると、サーバ上ではOracleのクライアントプロセスがCPU１個分のリソースを消費し続ける状態となり、複数個発生するとサービスの運用に支障をきたすのであるが、発生頻度がたまたま少なくてなんとか持ちこたえることができた。

東京ガスの事例も似たようなものだったのかもしれない。
東京ガスとガス器具販売・修理企業のシステムを統合するためのデータモデルということは、「汎用業務用ソフト」のデータモデルと根幹の顧客・器具などの管理部分で大きな違いがあっただろうことは想像に難くない。
これは予算や大まかなアプリケーションとして何を使うかなど、費用見積などごく初期・上位の段階で、アプリケーションのデータベースの物理設計が合わないと読み違えることがあるということ。

マッシュアップで簡単に高機能なモノが作れる時代だ、と考えて油断していると、こういう所でつまづくこともあるということだ。

こんな問題が下位のＳＥに納期・費用固定で押し付けられるとたまらないのであるが、逆に費用見積の時点でこのリスクを見極めることはそもそも可能であろうか？。

SaaSってそんなに偉いのか？ その２ Salesforce.comはたしかにすごいのだが…

SaaSで激変するソフトウェア・ビジネス　ソフトウェア業界を揺るがす破壊的イノベーション
城田　真琴　著、毎日コミュニケーションズ

今更ながら、読んでみました。

本書と日本法人のホームページを見る限りではありますが、Salesforce.comはたしかにすごいですね。

高度なシステム運用技術によってロングテールのビジネスモデルを可能にしている。

さて以前記事に書いた、「SI費用縮減の圧力、でもSaaSってそんなに偉いのか？」の続きとして、費用縮減の圧力で疲弊しているSIサービス業のすべての代替の方向性について改めて考えてみよう。

自身がSaaSプラットフォームのプロバイダになるにはそれなりの技術と体制、すなわち初期投資が必要である。

既存SEにあたる「SaaSパートナー企業」は業界知識や業務内容に精通し、SaaSシステムの最適な利用方法を考え、またSaaSシステムと既存システムの連携などの実装を行うことになるが、これまで以上に、業務・IT技術ともに深い知識が必要となる。

たとえばApexコードなどはJavaに似ているといっても、「似ている」と「同じ」とは違う。Salesforce.comのサイトでみられるコード例を見ても、データベースアクセスに関する構文は全く独自のものであることが分かる。すなわちこれはニッチな言語系を新たに学習する必要があることを示している。つまりその技術者を確保するのには通常よりも高いコストがかかるということである。

一方、成果物の「量」は減少する方向になるだろう。

しかしこの状況下においても、→人月商売以上の単価を要求できる機会があるだろうか？。

また、SaaSのプラットフォーム上ででの追加アプリケーションを作成する方向に舵を切ることも考えられるが、ビジネスの規模はジリ貧になるだろう。
逆にいえば、アイデアがありSLAなどの課題をうまくクリアすれば、零細とか個人とかのレベルでも参入可能かもしれない。

SaaSはそのビジネスモデルゆえにユーザから見て安いサービスが提供され得るので、少なくとも数年は伸びると思える。
またITを道具と見て厳密な費用対効果を考えて、その対策としてもロジックや機能の再利用の促進を考えれば、SaaSはその流れに合致するものである。
一方で、技術的・運用レベル的に高度なSaaSプラットフォームを構築するには非常に高い技術力と体力が必要であるので、プラットフォームの寡占化が進むので、労働力の階層化をさらに進める要因でもある。

以下では、前著とSalesforce.com日本法人のホームページで得られる情報の範囲であるが気になった点を補足しておく。

●セキュリティについてはユーザ名・パスワードのクラッキングに対する対策が気になる。
意図的な漏洩やソーシャルエンジニアリングはとりあえず保留するとしても、インターネットのどこからもアクセスできるということは、ユーザ名とパスワードがわかってしまうと他人でもアクセスできてしまい、情報漏洩のリスクがあるのではないか？。

●SLAにおいて可用性の保証はあるか？
可用性の実績レベルでは、CRMシステムとしてはおそらく世界最強の部類と思われるが、保証されるかどうかは一応別の問題である。
マルチテナント（複数のユーザに対するサービスを１つのハードウェアリソースを共有して提供する）であるるからこそ、一部の不具合が全体に広がる可能性がある。
実際に２００５年末に大規模なシステム停止があって各社の業務に影響が出たとのことである。
全く別のASPプロバイダで、根元のCiscoルータがダウンして全てのサービスが半日ほど停止したという話もある。このようなことも今後起こりえるということである。

●性能について
実際には、ユーザ自社内やインターネットに接続するネットワークプロバイダでのネットワーク性能のほうが問題になるのだろう。

●会社が潰れたり買収されたりしてサービス提供が停止されるリスク

●顧客情報の読込、更新等のアクセスへの監査は可能か？が不明
個人情報保護法対応など。Apexコードレベルでのカスタマイズは避けたい。

●バージョンアップのときにユーザ側で再検証が必要ないのは本当か？
かなり少なく済むとはいえるだろうが、以前使っていた機能の動作が変わることが全く無いとは言い切れない。
特にApexコードレベルでのカスタマイズを行った場合に心配だ。バージョンアップの際に言語レベルでの変更が無いとは言い切れない。

●データ構造が業務と合致するか
これは長くなるので別の記事（その３）にします。

●日本郵政や他の金融機関が導入を決定したことについて
「金融機関」という冠は割り引いて考える必要がある。口座情報の集中管理を行っているわけではなく一部の金融商品販売にかかわるCRMのみと思われる。

…結局CRMはコア業務ではないという皮肉か。

SI費用縮減の圧力、でもSaaSってそんなに偉いのか？

（１）「IT産業崩壊の危機」（日経BP社）
http://ec.nikkeibp.co.jp/item/books/176680.html

（２）SaaS市場に本格参入する会計ソフトPCAの戦略：田中克己の針路IT：ITpro
http://itpro.nikkeibp.co.jp/article/Watcher/20080117/291345/

IT産業、とくにSIサービスにおいて、費用（≒人件費）縮減の圧力は相変わらず高い。（１）によると、既に中国などでのオフショア開発を前提とした要求も出てきているとのこと。
幸いにして？私自身はそこまでの要求に直面したことは無いが、オフショア開発というのは国内以上に業者とのコミュニケーションが難しくなり、仕様書やテストを更に厳密にしないといけないはずなので、ブリッジSEの役割と責任は更に重いはずである。
この点の議論は別にするとして、費用縮減の圧力や海外ベンダとの競争に克つために、（１）はSaaSへのビジネスモデル転換を勧めているが、はたして実際にうまく実現できるであろうか？。

SaaSをまず技術的に実現するためには、既存のSIまたはアプリケーションソフト開発に比べて、エンドユーザレベルで同等のサービスレベル（信頼性）を提供するためには、サービス自身は更に高度なレベルの信頼性を確保する必要がある。既存SIを単にSaaS化するというのは単にコストアップであるから、SaaSとして提供するには、複数のエンドユーザに共通して同じサービスを使ってもらう形態にしないとペイしないと思われる。その形態にするのであれば、サービス自体の信頼性を高めないと、エンドユーザレベルで同等のサービスレベルにできない。また、そのために自前で高度な運用管理を行い、またはそのノウハウを蓄積していく体制が必要である。

逆に言えば、多数のユーザで共通的に利用できる分野でないとビジネスとして成立しないということである。この点では既存のASPサービスと本質的には同様であるように思う。

このように考えてみると、（２）の記事で報告されている会計ソフトのSaaS提供が、SaaSの可能性と限界をおのずと示唆しているように思える。

何万というユーザに共通して同様の機能を提供できる会計という分野だからこそ信頼性提供にコストをかけてもビジネスとして成立しうる。ただし会計ソフトの特性上、月末とか期末とかに利用が集中して処理が間に合わないと困るので、慎重には慎重を期して当初はユーザ数を限定して念入りに運用ノウハウを収集する。自社運用だけではサポートしきれない（くらいの数にしないとビジネスにならない）ので、販売店やデータセンター業者にもSaaSソフトウェアを提供して運用してもらう。

（１）の中でGoogleが提供するオフィスツールも成功例として挙げられているが、Googleの場合は、本業に付随する広告収入で挙げている莫大な利益を回していることは想像に難くない。

また（１）の中で、SaaSの普及の鍵の１つとして「インターフェースの共通化が課題」と指摘しているのもポイントである。つまり、インターフェースの共通化を検討する対象になる技術的なレイヤーが変わるかもしれないが本質的には既存の技術と変わるところではないということである。

すなわち、費用縮減の圧力で疲弊しているSIサービス業のすべての代替の方向性としてSaaSが有効になるとは思われないのだが、どうだろうか。

OracleのInstr関数でシステムが止まる？

タイトルで半分ネタばらしとなっていますが、以前経験した事例です。

あるシステムを運用開始してからしばらくして、ある日突然、以下のような現象が発生しました。

• サーバのCPU１個の負荷がほぼ100%になる状態が約30分続く。
• CPU負荷が下がるのと前後して、メモリのディスクスワップが発生し、約30分続く。

その後、この現象は不定期に発生し、発生する日は１日数回、全く発生しない日もある状況が続きました。また、その中で時々、現象の継続時間が約２倍のものも現れました。

当初は、再現頻度が低く、ログファイル等にも手がかりになりそうな情報が無かったため、実際のところ対策の施しようがありませんでした。

その後、問題発生時刻前後でのクライアントの操作状況のヒアリングなどを続けて、発生パターンを１つ発見しました。
それは、顧客情報のあいまい検索において、既に存在しない郵便番号を入力して検索を実行した場合に発生していました。当時、いわゆる自治体の平成の大合併によって、郵便番号の統廃合が行われ、住所変更に伴っていくつか廃止された郵便番号が出てきていました。
このシステムの中で、あいまい検索は別サーバ上のOracleデータベース上に実装されており、この機能が実行されると、本体のOracleのPL/SQLファンクション内からデータベースリンクによって別サーバ上のPL/SQLファンクションを呼び出す実装となっていました。
この別サーバの中の郵便番号辞書は適宜メンテナンスされていたために、逆に古い郵便番号を入力した場合に何らかの不整合が発生していたのです。

この問題の対処をする上で壁になったのは、この別サーバの機能および本体側の呼び出し用PL/SQLファンクションの部分は、システム運用を行う我々とは異なるベンダー（海外を含む複数）であったことです。当初は、そのベンダーの方へお客様を通じて調査依頼を行っていましたが、調査は遅々として進みませんでした。
しかしその間も時々問題は発生しました。サーバの管理センターから連絡があると、サーバの状態を確認し、上記と同様の問題と思われてCPUにいくつか空きがあれば、とりあえずサーバの機能は動作するので、１時間くらい様子見して収まるか待つといった対処療法でしのいでいました。このシステムは夜中の利用は少なかったのですが、休日の昼間はある程度の利用があったため、休日に連絡があるときもありました。ひどいときにはゴールデンウィークの休みに長野県内の電車の車中で連絡があったこともありました。このときは、万一引き返すとしてもその電車を終点まで乗るのが最善の策で、緊張しながらサーバが収まってくれるのを待ちました。

その後、ある程度時間がとれるときがあり、こちらから調査を開始しました。まず問題発生時の別サーバの負荷状況の確認をベンダーに依頼しました。別サーバ側も負荷が上がっているのではないかと想像していましたが、実際には別サーバ側には目だった負荷はかかっていませんでした。
そこで、呼び出し元のPL/SQLコードを解析したところ、怪しげな部分を見つけました。郵便番号の文字列をInStr文の第２引数に使用し、前後をFor文のループで囲んでいる部分です。その中に問題のコードがありました。InStr文がNullを戻した場合の異常系処理が記載が無く（戻り値０の場合は記載があった）、この場合、Forループが無限ループとなっていました。戻り値０の場合の異常系処理と同じ処理を戻り値Nullの場合にも記載することで、この問題はあっさり解消しました。

最初の発見から２年以上結果していました。問題の全容が分かってから改めて考えてみると、本件はサーバのCPU数やプロセス数の設定などの関係から、同時に４件以上実行されるとサーバがパンクする恐れがあったのです。たまたま運用中には１～２件の同時実行しか行われなかったのでかろうじてサーバは動いていました。

実はOracleのPL/SQLのInStr文は、検索文字列となる第２引数がNullの場合は、戻り値がNullとなります。もっと正確に言えば、OracleのPL/SQLの全ての関数は、引数にNullが含まれるとNullを戻すというのが仕様です。これはOracleのドキュメントには、InStrなど個々の関数のところには記載されておらず、ドキュメント冒頭のPL/SQL全体の規則の項に記載されています。
このことを私はこの調査で始めて知りました。他の言語では０など違う値を返すものがあり、私自身もその考えに染まっていました。問題のコードはどこの人が書いたものか知りませんが、その人もこのPL/SQLの仕様を知らなかったということでしょう。

各種の言語やフレームワークがあふれ、現在も膨張し続けている中で、一見似たような名前・機能の関数でも、とくに異常時の戻り値が異なるということが十分に有り得るということです。異常系の処理はシステムの安定には特に重要で、実際には正常系の処理よりも手間がかかることもあります。今回の事例のような問題は、一旦分かってしまえば対処は簡単ですが、果たして事前にチェックし尽くすことが100%可能であると言い切れるでしょうか？。

ITサービス企業は、会計基準の変更で潰れてしまうのではないか？

お恥ずかしい話であるが、ITサービス企業の会計基準が変更される予定であることを、日経ソリューションビジネス実践セミナーの案内メールで初めて知った。

●日経ITPro Watcher
2008年度からSIにも進行基準、怒るCFOの真意とは
http://itpro.nikkeibp.co.jp/article/Watcher/20070720/277918/

●日経ITPro Watcher
まさに他山の石、会計基準の変更でITサービス会社は大丈夫？
http://itpro.nikkeibp.co.jp/article/Watcher/20071010/284209/

●日経ソリューションビジネス実践セミナー
『目前に迫る、「工事進行基準」にどう対応すればよいのか』
http://coin.nikkeibp.co.jp/coin/wat/semi/0712/

私は凡人なので企業経営についてはよく分からないが、とりあえず思いつく範囲で、現場レベルでは以下のような問題が起きるのではないかと想像する。

★「正確な見積もり」がそもそも可能か？
１つの要件においても、技術的に正確に要件レベルの認識合わせをしないと、費用がピンからキリまで、桁が違うほどの費用差が発生することが有り得る。

• サービスレベル、保守体制
• セキュリティ
• バックアップ
• 性能
• 他者（顧客や第三者）が作成した物への対応（既存システムの改造、他の既存システムとのインターフェースなど）
• 個人情報保護法対応
  　など

★「正確な見積もり」が仮にできるとして、その作成（これまで以上に時間がかかるはず）に必要なコストをどうやって回収できるのか？
受注できない場合もあるし、受注できる場合でもその費用を事後請求できないのではないか？。

★顧客や第３者ステークホルダーが原因の遅延が発生した場合の費用回収はどうなるか？

★「正確な見積もり」が可能な案件に限る、とするならば、自分たちにできること、顧客が理解できている範囲に限られる。となるとそもそもSIサービス企業の存在価値が無くなる（単なる顧客の下請けになる）のではないか？。
あるいは、SIという仕事が、できることしか行わない、つまらない仕事になるのではないか。

★「正確な見積もり」を行っても上記のようにリスク要因はいくつも有り、利益が予定以上に上がる可能性はほとんど無いのに対し、コストが増えるリスクは多い。こうなるとSIはもはやビジネスとして成立しなくなるのではないか？。

Web2.0とGoogle礼賛へのアンチテーゼ

「Web2.0が殺すもの」宮脇　睦　著、洋泉社

タイトルや表紙の印象よりも冷静に、「Web2.0」という言葉をとりまく状況を分析しており、私はこの本から受ける著者の知識量に圧倒された。
そもそもWeb2.0的とは何かという定義自体が曖昧である点、それ自体も著者による批判のひとつであるが、私なりに敢えて纏めるならば、Web2.0的と呼ばれている企業のサービスの共通点は、「情報のリンク」を新たな情報・知識として提供していると言えると思う。
但しビジネスのモデルは一致していない。Googleなどは基本的にはほとんどが古典的なWebの広告収入である（但し、広告収入のロングテール化には成功しているといえるだろう）。

たしかこの本の中だったと思うが、あるソフトウェアの重鎮の方が、「はてな」が Google Earthにマッシュアップしたアプリケーションサービスを１週間で行ったことに驚嘆の声を上げたエピソードがあった。確かに驚異のスピードではあるのだが、この点については私は敢えて２点ほど異論を唱えたい。
１つは、Googleが過去の莫大な広告収入によってGoogle EarthやマッシュアップAPIを開発しているだろうという点。また、地球表面の画像を得るためにGoogle自身が人工衛星を打ち上げたわけではない（必要と思えば将来やってしまうかもしれないが）。
もう１点はサービスの性質である。こんなことを言うとお叱りを受けるかもしれないが、たとえば「はてな」のサービスが３日止まったとしてどれぐらい困るかということを考えてみよう。YouTubeなどもしょっちゅうサイトのメンテナンスでサービスの一部を止めている。対してIP電話のインフラが５時間止まったら大騒ぎで一般新聞の記事にもなる。

また、Google Earthのサービス開始直後は嘉手納基地の映像を消していた、グーグルとはその程度の会社だと指摘している（現状ではそれを確かめるすべが無いが）。

「Google誕生」デビッド・ヴァイス／マーク・マルシード　著、田村　理香　訳、イースト・プレス

本書は緻密・大量の取材をもとにGoogleの今日までの成長に至る内情を記しており、私は読むのにかなり時間がかかった。

本書自体の帯を含め、Google礼賛の言葉が並んでいるが、何点か指摘したい。

・Googleのサービスの根幹が検索エンジンであることは言うまでもないが、それは創業者２人が学生時代に、本業？の研究のために必要だから製作したのが始まりであること。はじめから「検索エンジンで儲けよう」などと発想していたわけではない。
・貴重な人脈との出会いなどを含めて当時のアメリカの情勢。
・創業者２人が会社への影響力を保ち続けて私企業としてうまくふるまったこと。（株式公開にあたっても特殊な株式構成として影響力の低下を極力避けた）
・一時、検索結果と広告の表示が明確に分けられていなかった。

創業者の理念がぶれずに会社内に浸透しているうちは、それによる利点があるかもしれないが、皮肉にもサービス内容の拡充（Google Earthや、全書籍スキャンプロジェクトなど）とともに組織の巨大化＝かつて対抗していたマイクロソフトに有る意味近づいているのではないかと想像できる。今後、Googleが組織としてきちんと著作権やコンプライアンスなどの問題に対応できるかどうかが注目点だと思う。