watermint.org

kimimasaさんがかかれているSunのソフトウエアにおこる予言が少し気になったのでSunの外の人となった今コメントを (^^;;
その1。2009年はMySQLへの注目度がより高まり、もっと売れると思います[blogs.sun.com/kimimasa]。Sunのソフトウエアの中では相対的に注目度と売り上げはMySQLが集めると思いますが、データベース市場全体として注目度が高まるというのはまだ根拠が足りないと思います。理由としてあげられている、「安さ」と「品質の良さ」は、確かにその通りかもしれませんがすこし考察に深さが感じられません。ユニクロやマクドナルドがこの不景気の中でも成果を上げているのは、安いだけでなく「値頃感がある」からでしょう。Microsoft SQL Server、Sybase、Oracle、IBM DB2 UDBと比較してのTCO削減はデータベース導入を検討したことのある人であれば、資料を見なくても直感的に分かっていたことだと思います。それでもなお、MySQLを使っていなかった理由があったはずです。いくつか思い当たる理由を列挙してみます。

• 安心感 … みんなが使っている、あるいは大手が使っているなど安心感を得るための要素が多く、購入の意志決定者がはんこを押しやすい。問題が生じても、ベンダーに責任をなすりつければよいと考える。
• 安定性 … MySQLが不安定だということではなく、安定性についての前もって与えられたイメージが不十分だと思います。すでに大規模システムでの実績があるSQL Server、Sybase、Oracle、DB2ならば、クラスタリングや、トランザクションログの安全な運用、オンラインバックアップについて実績のあるソリューションを持っているだろうと推測が容易です。一方、MySQLにもそれらのソリューションがあっても、その構成を確たる状況にするまでの道のりが十分知られていないため、無意識のうちに選考対象から外れてしまう。
• パフォーマンス … SAPのSDベンチマークやSPECjAppServerのようなアプリケーションベンチマークの傾向から見るとまだMySQLやPostgreSQLのようなオープンソース・データベースはSQL Server、Oracle、DB2などの商用データベースと比較して10〜20%程度のパフォーマンスペナルティがあるように見えます。

MySQLがさらに注目を集める原因があるとすると、急速な景気後退によって、低価格の代替案を検討せざるを得なくなることでしょう。それにより、MySQLについて今までよりも深く知られるようになるとすれば、注目度は高まり、売り上げも増えるでしょう。
一方、MySQLに注目が集まらないとすると、互換性が原因です。その場合Enterprise DBのようにOracle互換を謳うオープンソース・ベースのソリューションが注目を集めるでしょう。意志決定者が仮に、2〜3年での景気回復を予想している場合、この2〜3年間だけのためにリスクの高い移植作業を行うよりは、設備投資を抑えて乗り越えた方が安全と考えたり、移植作業のためのSI費用が回収できないという考えを持つからです。Enterprise DBのようにOracle互換を謳うソリューションの場合、この移植作業のためのSI費用が低く抑えられると考えるため注目が集まるはずです。

その2。ソフトウェアのセールス活動（特に私のようなプリセールスのエンジニアの活動）に占めるブログやwikiなどのオンラインのメディアの割合が増加していきます[blogs.sun.com/kimimasa]。 割合は増加すると思いますが、激増するにはまだ時間がかかると思います。デジタルカメラや低価格ラップトップPCのように、スペックが重視されるコンシューマ製品の場合ではオンラインメディアによる情報流通はとても大事です。オンライン上の情報だけで意志決定し、購入までのプロセスをたどることが今では抵抗感無く受け入れられています。一方、Sunのソフトウエアはその多くが企業・組織向けのビジネス・ソフトウエアです。購入の意志決定までにたどるプロセスが違ったり、そもそもそのソフトウエアを利用するのが最適かどうかも分かっていない場合もあります。また、同じカテゴリのビジネス・ソフトウエアを横並びで公平に比較した資料はまだオンライン・メディア上には多くありません。担当者がすべての製品について、詳しくブログやデモを検討した上で意志決定するのにはまだまだ敷居が高いはずです。
このため、すでに導入を決めていたり、2つ程度まで候補が絞られている場合に限りオンライン・メディア上での活動割合が増えるでしょう。3つ以上の候補があったり、まだ候補が残っているかもしれないと思う段階ならば、有利な条件で購入したり、最適なソリューションを探すためにほかの候補を従来通り各社セールス・パーソンに問い合わせるでしょう。このため、Sunは社内セールス・パーソン向けの資料を用意するためにもっと時間を使った方がいいでしょう ;-)

その3、今年もSunのアイデンティティ管理ソリューション(ID管理ソリューション）は突っ走ります[blogs.sun.com/kimimasa]。 アイデンティティ管理の需要はまだかなりあると思いますが、景気後退による影響が気になるところです。J-SOXの施行や個人情報保護など、一種の脅迫的なモチベーションは一段落し、そしてその話に翻弄された意志決定者は疲れてしまい、アイデンティティ管理がなくとも何とかなるという楽観的なムードが支配的になっています。そこに景気後退による予算縮小が重なれば、アイデンティティ管理に関するモチベーションはさらに低くなっていくことでしょう。このため、アイデンティティ管理ソリューションを販売する者は、経営者や意志決定者に、いま組織内でアイデンティティ管理について見えないコストがどの程度費やされているかを調査させるために働かなくてはならなくなるでしょう。見えないコストにはアイデンティティ管理のために働く担当者の作業時間や、コンプライアンス違反によるリスク解消にかかる費用などが含まれれますが、J-SOXのときのようにうんざりさせないために後者のような費用はあまり訴求せず、直接削減可能なコストについて説明するのが良いと思います。

さて、最後に個人的な予想です。いま、サンのソフトウエアでおもしろそうなのはGlassFishとVirtualBoxです。GlassFishは今年Java EE 6がリリースされそうな時期ということもあって注目していますが、まずは値頃感からGlassFish v2がもうすこし勢いを持ってくると思っています。
VirtualBoxについては、いまパーソナル向け仮想化ソリューションは手元にVMware Fusion、Parallels Desktop、VirtualBoxを持っています。VirtualBoxはSunに統合された当時ではまだ本格的に使う気になりませんでしたが、統合から1年足らずの今、VirtualBoxが持っている機能と品質から考えると僕はParallels Desktop 4.0にアップグレードはせず、VMware Fusionが新しく出てもアップグレードせず、VirtualBoxを主に使うようになると思います。
一方、今ひとつ訴求力に欠けるのはSun Java System Web Serverがオープンソース化されたOpen Web Serverでしょう。ググらビリティが悪すぎるのも一つの原因で、まったく情報にリーチできないまま今年は終わるでしょう。また、性能は良いのですが、いまさらこのクラスの「でかい」Webサーバはさほど必要ないと思います。もうすこしOpen Web Serverプロジェクトが成熟し、高速軽量なHTTPサーバあるいはリバースプロクシとして製品パッケージングが変わっていけば、かなり良くなっていくと思います。オープンソース版Open Web Serverと、Sun Java System Web Serverの機能比較[wikis.sun.com] で見る限りだと、Open Web ServerはServletコンテナが無かったり、クラスタリングや管理系コマンドが無いようですが、かえってこれぐらいのほうが使いやすそうですね。もう少し機能がそぎ落とされて、使いやすいようになってくるのを期待します。あるいは、AkamaiのEdgeComputingのようなソリューションの一部として組み込まれるソリューションが出てくるとおもしろくなりそうですね。

今度はドキュメントに関する話題です。佐藤さんのブログによると、ドキュメントは不要、最小限に。とのことで、これは同じくそう思います。というか、そうあってほしいと願っていますが、なかなかそういう訳にも行きません。

佐藤さんは今回のブログ・エントリでは触れられていませんが、 今後の潮流としては開発の現場にも内部統制がはいってくるということがこのドキュメントを残すという、エンジニアのあまりやりたがらない作業を法令等によって強いられることになります。

今回、佐藤さんはドキュメントの役割は「人に伝えること」 をドキュメントの主な使命とされていますが、内部統制という視点から見れば「監査あるいは内部統制の証拠」としての使命を負うことになります。内部統制がどの程度開発の現場にはいってくるのかは不勉強のため今はわかりませんが、少なくとも開発から本番への移行は必ず別の担当者が行わなければならないとか、そういったルールがはいってくるでしょうし、勘定系や基幹系のシステムであればそのシステム仕様書と実装に矛盾が無いかなどの監査を受けることになるかもしれません。

ところで近年、開発の現場ではウォータフォールの反省あるいは、様々な開発支援ツールを導入することによって積極的にドキュメントを作成する工数を減らそうという動きがありました。たとえばJavaであればそのAPI仕様をソースコード中に記述し、javadocという形式のドキュメントが自動生成できるようになりました。また、JavaのソースコードからUML表現を相互に同期をとれるような、たとえばNetBeans Enterprise Packとか、ツールも安価あるいは無償で手に入るようになりました。

また、あるいはその逆にWordやExcelで作ったドキュメントをもとにJavaソースコードや設定ファイルを生成するようなソフトウエア、たとえばキヤノンソフトウエアのWeb Performerなど、も数多く存在するようになりました。

この二つのアプローチは「ドキュメントを作成する」という工数を確実に自動／半自動化することを可能にしました。 佐藤さんの言うような「実装者の意思を設計者に伝える」という種類のものは前者の「プログラムからドキュメントを生成」というアプローチ、また「顧客の意思を設計者に伝える」という種類の物は後者の「ドキュメントからプログラムを生成」というタイプのアプローチによって自動／半自動化することが可能になってきました。

ところが、たしかにこのような潮流によって主としてメンテナンスしなければならないドキュメントが減ってくれることを期待していましたが、現実をみれば実際には重複した内容のドキュメント、冗長あるいは不必要なドキュメントは未だに氾濫しており、ドキュメントを作成し、探し出し、利用するための工数は実質的ほとんど減っていません。

この問題の原因と考えているのはドキュメントがどういう目的で、誰に読ませようとしているのかが不明瞭である状態のまま作成され続けているというところです。この傾向は知る限り日本においては顕著です(せいぜい英語がぎりぎり読めるぐらいなのでそれほど多くの国の事情を知っている訳ではありませんが・・・)。

たとえば日本でよく見かけるドキュメントの「はじめに」の章は形式的な挨拶が書かれている程度でそれ自体無くても不都合のない場合がほとんどです。このため、たとえば対象読者をプロジェクト全員に広げてしまい、実際に読むのはJavaに詳しいエンジニアであるのにも関わらずJavaの基礎を延々と説いているというような無意味なドキュメントが作成されてしまっています。一方、欧米のドキュメントでは最初の章に「ドキュメントの利用目的」「ドキュメントの対象読者」「ドキュメントの前提としている事柄」といったことが記述されており、それに続く内容も整合性がとれた物になっています。

そういった意味で、実際のところ開発プロセス云々の前にドキュメントの作り方自体が間違っていると言わざるを得ないと思っています。ぜひとも、開発プロセス云々の前に「理科系の作文技術」でも読んでもらいたいと思うシーン幾度か経験したことがあります。

オープトーンの佐藤さんのところでオープンソースで開発プロセスを作られているそうです。でもちょっと違うな、と感じるというか、もはや口出しできる状態ではないような気がするのでこちらからコメントさせていただこうと思います。

アジャイルは「変化に強い」という幻想

「変化に強いプロセス」というのは存在しないと思っています。アジャイルも、RUPも決してその性質として「変化に強い」ということは無くて、偶発的に「変化に強く見えている」ということにすぎないというのがその考えの根拠です。
本来、プロセスはその意味通り、一連の決まったやり方によって作業なりをこなすことであって、そもそもプロセス化可能であるというのは既にその作業について一定の経験の蓄積があってこそできるのであって、「変化に強い」というのはそもそもプロセス化されていないということにほかならないためです。

アジャイルやRUPが「変化に強いように錯覚されている」のは、ウォーターフォールのような旧来のプロセスに比べて最終コストが低く抑えられたためだと思うし、「最終コストが低く抑えられた」ことを「変化に強い」という解釈をするのは生兵法は怪我のもと、なんて言いたくなるぐらい。

足して二で割るという危険さ

プロセスは、消しゴムと鉛筆をくっつけたら便利になった！というような、成果物を作る過程において素材を足して二で割るのと違い、その作業過程には大きなリスクが混じり込むように思います。

たとえばソフトウエア製品を思い出していただければわかりやすいと思うけれど、ソフトウエアというのは、それ自体一連のプロセスとなっていて、あるソフトウエア2つをくっつけて一緒にするという作業を想像したとき、例えばWordとExcelを完全に一つのソフトウエアとして統合する、という作業を想像してみると、たとえばWordとExcelはそれぞれ成熟したソフトウエアであって、巨大なプロセスの集合体です。それらを統合しようとするのであればファイル形式から利用形態まですべてを抽象化した上で統合しなければ、上っ面だけ統合された（例えば昔ならMS Worksなんてのがありましたが）ソフトウエアになるだけであって、それは統合された、というよりは集約された、というだけに他ならないように思うからです。

プロセスを集約する、という作業自体が無意味であるという訳ではないけれども、そのアプローチは潜在的に分裂も容易である、と思えるし、そう陥ればこのプロジェクトは求心力を失いかねないし、一枚岩ではないものでは訴求力も分散する危険性を感じるためです。

権利関係について

この開発プロセスはオープンソースを謳っているものの、仮に深意は無いとしても制約が大きすぎるように思います。たとえば権利関係についてのページの次の項目(2006年8月22日時点)。

本プロセスならびにプロセス内の雛形集は商用・非商用に関わらず
自由に使用することができます。ただし、本プロセス自体ないし、
改変を加えたものを商品として販売することはできません。

とのことですが、プロセスの販売を禁じるのは結構厳しいかと。最悪、GPL汚染呼ばわりされかねない危険性があるように思いますがいかがでしょう。たとえば、SIであるA社が顧客であるB社に対しこのプロセスにA社のノウハウを詰め込んだ上で提供しようとしてもできない可能性があるのでは？