技術サイクルと情報アーキテクトの位置づけ

Facebook にシェア
このエントリーをはてなブックマークに追加
[`livedoor` not found]
Delicious にシェア

大学院で技術サイクルと情報アーキテクトの位置づけを事例と共に考察しました。
合っているかは分かりません。適当に流してください。。

1. 技術サイクルとは
技術または企業が進化・発展する為には技術サイクルが必要不可欠である。
具体的には以下の流れを繰り返すことで、成長していく。

  1. 技術の不連続性
  2. 1→2の変化には、エバンジェリストが必要

  3. 不安定期
  4. 2→3の変化には、市場創造者が必要

  5. ドミナントデザイン
  6. 3→4の変化には、マネジメントが必要

  7. 安定期
  8. 4→1の変化には、発明・発見者必要

本考察では、1: ”技術の不連続性”→2: ”不安定期”→3: ”ドミナントデザイン”までの2期で活躍をする、
エバンジェリストと市場創造者の動きに着目し、今後の技術者の在り方について考察する。

2. MySQL
考察時のモデル事例として、MySQLを取り上げる。
私が初めてMySQLを知ったのは2005年春でバージョンは4.0の頃であった。
それまでMS SQLServer, DB2といった商用データベース(以下、DB)を使用して、
アプリケーションを組んでいたが、この頃初めてオープンソースDBに触れた。
Webサービス構築を通して、すぐにMySQLの虜になってしまった。
その当時を振り返りながら、MySQLの進化・発展、取り巻く環境の変化を確認していく。

2.1. MySQLの収益源
MySQLはオープンソースDBである為、無償で使用可能である。(※厳密にはGPL Version2)
使用者側でMySQLを使いこなす事が出来れば、追加のコンサルティング費用等は不要である。
MySQL社では、各種サポート(問題発生時のサポートなど)やサービス(チューニングなど)を提供しており、
年間売上は$60million – 70million程である。(認知度に対して決して大きくない)

2.2. ある日本人MySQLコンサルタント
現在、日本語によるMySQLの本が多数出版されており、中には内部構造を詳細に解説した本や、
パフォーマンスチューニングのTIPSをふんだんに散りばめられた本もある。
2005年当時、英語の本は多数出ていたが、日本語によるMySQL本は3冊のみであった。
但し、内容的に古かったり薄かったりとコンテンツとしては充分とは言えない状況であった。
自分が担当していたWebサービスのパフォーマンス改善をしていたが、MySQL4.0→4.1→5.0→・・・と、
バージョンアップする毎にパフォーマンス改善や新機能が盛り込まれていった為、これらの情報収集には苦労していた。
そんな時「現場で使える MySQL」(著:松信 嘉範さん)という本が出版された。
今でこそ、この本よりも多くのTIPSが書かれた本は多くあるが、当時としてはこれ以上の本はなく、
何度も繰り返し読み、また実機で実践をした。
この頃は既にMySQLはWeb系サービスでかなり使用されており、
メジャーな存在であったが、まだまだ未完成なデータベースで
文字コードの問題やストレージエンジンのパフォーマンス問題などの問題があった。
この本はこういった問題を丁寧に解説+対応方針を示し、他エンジニアも含めて参考にしていた。

2.3. WebサービスとMySQL
今日の有名なWeb系サービスでMySQLを使用していないサービスはほぼ無いと思われる。
前述の2005,6年頃では、YahooやGoogleは大規模に使用をしていたし、
新鋭サービスとしてはYoutubeや日本ではmixiが大量のアクセス・データを
どのようなアーキテクチャで捌くかに注目が集まっていた。
これらのサービスの成功により、MySQLの認知度は一気に上がり、様々なサービスの中核となった。
LAMPがWebサービスのデファクトスタンダードとして広まったのもこの頃であった。
一方、エンタープライズ業界ではまだ浸透しきれておらず、現場で使用されるまでに至っていなかった。
現在はWeb・エンタープライズ共に、多くのMySQLが稼働しており、商用データベースを脅かす存在となっている。

2.4. SUNによる買収
2008年2月、SUNによりMySQLは買収された。
収益はサービス・サポートからで$60million – 70million程であったMySQLを何故買収したのか。
理由はMySQLを使用する多数のユーザの存在である。
これらユーザの大多数はSUN以外のサーバを使用しており、
買収をする事で自社のサーバへ誘導する事が狙いであったと考えられる。

2.5. SAPの画策
SAPとMySQLは2003年頃から提携して、次世代DBを開発してきた。
MySQLをベースとして、SAP用に機能を削ぎ落したDBである。
このDBではSAP DBと言われ、後にMAX DB, live cacheと言われるデータベースとなった。
SAPがMySQLと組んだ理由としては、Oracleを打ち負かす為だと考えられる。
OracleはSAPと競合するERPを保持している為、SAPとしてはOracle DBを使用する事は推奨しない。
また、TomorrowNowに関連した賠償問題もある。
現在、SAP ERPのバックエンドで稼働可能なDBとしてSQL Server, DB2, Oracle, MAXDBが選択肢としてあるのだが、
OracleはERPで競合となるソフトウェアを保持しており競合にあたる為、メリットが無い。
そこで、メリット/デメリットあるもののライセンス費用がかかる3社ではなく、
ライセンス費用をかけずにSAPに特化したDBを共同開発可能なMySQLを選択したと考えられる。
しかし、SAPは2007年9月頃にMySQL社との提携を解除し、次なる道を模索し始めた。
結果、2010年5月にSybase買収へと進んだと思われる。この買収の狙いはOracleへの対抗である事は明白である。
また、Sybaseはインメモリ技術を保持していた為、現状のアーキテクチャの流れに足していたとも言える。
その後、このインメモリを搭載したリアルタイム分析ツール HANAをリリースした。

2.6. Oracleによる買収
2009年4月、OracleはSUNを買収した。この買収は最近の流行りである垂直統合システム化への道である。
自社でハードウェア・ソフトウェア・データベース等を一貫して提供し、
自社製品によるエコシステムを作り上げて親和性を武器に顧客を囲い込む作戦である。
前段のSAPによるSybase買収もこの垂直統合システム化を狙ったエコシステム構築の1つの動きである。
またOracleにはSUN買収にもう1つ狙いがあった。それはMySQLの存在である。
Webアプリケーションを席巻するMySQLを手にすることで、エンタープライズ側のOracle DB、
Web側のMySQLを使い分けることが出来る。
Oracleには更にメリットがあった。ストレージエンジンのInnoDBである。
MySQLはDBの核となるストレージエンジンを入れ替える事が出来る。
デフォルトのストレージエンジンはMyISAMであったが、このエンジンはトランザクションをサポートしていない為、
トランザクションを伴う場合はInnoDBを使用する。
以前からMySQLの存在が邪魔であったOracleは、2005年10月にInnoDBを保有するInnobase社を買収した。
これにより、MySQLは自身のソフトウェアの中核ストレージエンジンを奪われる事となる。
但し、Oracle側で制限をしなかった為、今までと変わらずにInnoDBは使用可能であった。
但し、SUN買収後のバージョン5.5からはデフォルトストレージエンジンがMyISAM→InnoDBへと変更された。
Oracle社内では元々あったInnoDBチームと買収したMySQLチームを統合し、開発にスピード間が出てきたとの事である。

2.7. RDBMSへの刺客
2009年、RDBMSへの刺客としてkey-value型のデータベースが注目され始めた。
これはNoSQL(Not Only SQL)と言われる。
Key-value型の考え方は以前からあり、memcached等によりWebのアプリケーションサーバではよく使用されてきた。
情報が爆発的に増えていくなかで、Big Dataを効率的に処理する為にkey-value型データベース等のNoSQLに注目が集まっている。当初は、RDBMSが無くなる・・と言った意見もあったが、現状は適材適所でRDBMSとNoSQLを使い分けていくというのが流れである。
NoSQLの流れに対抗する為に、MySQLではバージョン5.6からmemcachedプロトコルを利用したNoSQLアクセスを提供する予定である。
NoSQLなDBが今後どのように発展していくかは分からないが、RDBMSと適材適所で使い分ける必要がある。

2.8. MySQLコアメンバの動き
冒頭で、日本人のMySQLコンサルタントの話をしたが、今度はMySQLのコアメンバの動きを確認する。
まず、MySQLの創設者であるMichael “Monty” Wideniusは、MySQLからforkしたMariaDBを開発し始めた。(Mariaは娘の名前)
このDBは、ストレージエンジン”Maria”をデフォルトエンジンとするDBで、MySQL6.0(リリースされず)で出荷される予定だった機能が盛り込まれている。データベース本体として、MySQLを打ち負かす可能性は低いが、ストレージエンジンの1つの選択肢として使用されていく可能性はある。
 次にMySQLの開発責任者であったBrian Akerは、MySQLからforkしたDrizzleを開発し始めた。
このDBはクラウド上での使用を想定しており、Webサービスのバックエンドで使用する時に不要と思われる機能を極限まで削ったDBである。
今後、Cassandra等のNoSQLのライバルとなってくる可能性がある。

3. 考察
以上が、ここ数年でMySQLに起こった事象である。
この個人や企業の様々なアクションを技術サイクルに当て込み考察する。

3.1. 技術の不連続性 (エバンジェリスト)
まず、日本人MySQLコンサルタントの松信嘉範さんである。
彼はMySQLがまだ日本に浸透したとは言えなかった時代にDBマガジン(少し前に廃刊)や
書籍でMySQLの良さを布教していった。
彼がいなければ、日本におけるMySQLの成功はなかったかもしれない。

3.2. 不安定期 (市場創造者)
市場創造者はいくつかありそうである。以下にまとめた。

  1. SUN
  2.  MySQLを使用しているたくさんのユーザを狙った買収を行い、
     MySQLユーザを自社のサーバへ誘導しようとした。

  3. SAP
  4.  Oracleに勝つ為に、自前のDBを開発しようとしていた。
     また、開発を取りやめ、Sybaseを買収し、最近の流行りの垂直統合化で自社のエコシステムを構築しようとしている。クラウドに関しては、流れに乗り遅れているように感じる。

  5. Oracle
  6.  SUNの買収、MySQLへ対抗する為にInnoBaseの買収と、無駄がないように感じる。
     周囲の競合ベンダを威嚇しながら、買収を繰り返し、垂直統合システムを完成させていっている。だが、これはベンダーロックインとなる為、懸念される可能性もある。(中立的な立場であるPublicSectorがMicrosoftを嫌がり、OpenOfficeへ入れ替えていっているように)

  7. MySQL
  8.  MySQLはWebで圧倒的な強さを見せた。
     これは、Web業界を対象として製品をプッシュしていったからではないだろうか。
     また、Webがオープンソースを利用していくという流れにも乗っていた。
     だが、その他のオープンソースDB御三家(MySQL, PostgreSQL, Firebird)と何が違ったのだろうか。
     特に機能としては、優っているとの見解もあるPostgreSQLは何が足りなかったのか興味がある。

3.3. ドミナントデザイン (マネジメント)
ここでの登場人物はいなかったので、割愛する。

3.4. 安定期 (発明・発見者)
2人のMySQLの開発者は、新たな道を歩み初めている。
MontyはMariaDBを始め、BrianAkerはDrizzleを進めている。
先日、どちらのDBも新バージョンをリリースした為、次のTermである技術の不連続性へ進んでいく。
彼らはMySQL時代にエバンジェリストを経験し、既に流れを作った経験を持っている。
これはまさに技術のサイクルでもある。

3.5. 1技術者として自分が出来る事、取るべき行動
ここ数年は今後を左右する技術の変遷期にあたると考えている。
まず、技術者が避けなければならない事として、自分のスキルが陳腐化することである。
バズワードのように、たくさんの技術が出てきて、1部はメジャーとなり、一部はすぐ消える。
また、既存の技術であっても消えていく事も充分ありえる。
よって、業界動向、技術サイクルを見極め、今どこのTermにいるのか、
エバンジェリストや市場創造者はどこに進もう・進ませようとしているかを冷静に判断しなければならない。
その上で自分がアーリーアダプターとなり、他者をリードしていけるように心がける。(そうなりたい)
以前はエンタープライズ業界がIT業界を牽引していた。
例えば、IBM、Microsoftといったベンダーが新しい技術を産み、市場を創造していった。
しかし、今はWeb業界がIT業界を牽引している。
例えば、GoogleがAndroidを開発し、携帯メーカーはそのOSを利用して製品を作る
(もはや、auのCMはAndroidの機能紹介となっており、au独自の機能はないように感じる)。
Twitterがブームとなったことにより、Salesforce.のchatterやSAPのマイクロブログツールへと連鎖した。
このことから、まずはWebに認められるか否かが、ポイントとなると考えられる。
そのWebを支えているのは技術者である。よって、Webに認められたければ、技術者へ訴え続ける必要がある。
エグゼクティブを対象としたカンファレンスはかりを開くのではなく、
技術者を対象とした技術カンファレンスを定期的に開き、技術者を味方につけることである。
技術者は次の技術サイクルを創出していく可能性を常に秘めている。

以上。