皆様 新年明けましておめでとうございます。
今年もアプレッソはDataSpider Servista、DataSpider BPM、PIMSYNC各種製品の強化に全力で
取り組んで行きますので、本年もどうぞよろしくお願い致します。
昨年の11月に、永和システムマネジメント社が「これは、これからの受託開発の新しいカタチになるかもしれない」と予感させる、非常に興味深いサービスを発表しました。今日はこの「アジャイル受託開発」とでも呼ぶべきサービスについて紹介してみたいと思います。このサービスでまず目を引くのが「システム開発初期費用が0円である」という点です。
その代わり、ユーザーはシステムを使い続けるには、月々のサービス利用料を支払い続ける必要があります。いわば、SaaS等の月額料金のモデルを受託開発の世界にも応用した価格体系になっています。月々支払う価格は、もっとも安価なプランSSでは15万円と、かなり低めに設定されています。
永和システムマネジメント社は、アジャイル開発関連で名の知られる会社ですが、この価格体系はアジャイル開発に非常に適していると言えます。要件定義が終わり、初期バージョンの開発が終わった後も、実際に現場で使ってみたところ、ちょっとした修正を加えたい点が使っていく中で出てきた。
しかし、それらに対応するには数年先の次のフェーズを待たなければならない－そういったケースは多々あると思いますが、アジャイル開発では、継続的な改良を行っていくことができますし、月額料金の中にはそうした要望に応えるための保守・サポートのチケットも含まれています。
こうした取り組みが広がっていけば、それに伴ってアジャイル開発も普及していくでしょうし、システムが毎月継続的に進化していくことで、業務の生産性も向上し、ソフトウェアライフサイクル（使い続けられる期間）も長くなり、より丁寧にソフトウェアを設計・開発していく必要が生じ、プロジェクトに関わったエンジニアも自ずと技術レベルが上がっていくでしょう。
「アジャイル受託開発」は永和システムマネジメント社の中でもまだ実験的な試みのようですが、非常に興味深い試みで、今後とも注目していきたいと思います。
それでは、本年がソフトウェアに関わるすべての人達にとって、素晴らしい一年となりますように。
参考・永和システムマネジメント社「新しい契約形態での受託開発サービス」
http://www.esm.co.jp/trial/new-agile-contracts-service.html
・「漢のコンピュータ道」アジャイルと受託開発
http://nippondanji.blogspot.com/2010/11/blog-post_14.html
私が実行委員長を務めているMIJS製品技術委員会では、現在エンタープライズの世界でクラウドを活用していくための様々な調査や実証実験を進めています。その一環として先日、「同じエンタープライズアプリケーションを4大クラウドそれぞれを用いて構築する」という実証実験を行ないました。ここで言う4大クラウドとは、Windows Azure、Force.com、Amazon Web Services、Google App Engineを指します。
この実証実験のポイントとしては、次の2つの点が挙げられます。
■ ポイント1. エンタープライズに求められる各種要件が含まれる「家庭教師予約システム」を構築する
「クラウド上にアプリケーションを作る」と言っても、個人向けのサービスをつくるのと、エンタープライズ向けのシステムを作るのでは事情が違ってきます。
そこで今回は、エンタープライズシステムに求められるロックや排他制御、トランザクション等の要件を含む「家庭教師予約システム」をテーマに選びました。
■ ポイント2. RDBMSは原則として使用せず、クラウドのNoSQL系ストレージのみを使用してシステムを構築する
さらに、最近ではどのクラウドサービスでも従来と同じRDBMS系のサービスが提供され始めていますが、「今までと同じように開発できるから」という理由だけでRDBMSを選択するのではなく、今回はクラウドのメリットが最大限活かしやすいNoSQL系のストレージだけを用いて実証実験を行ないました。
実験を通して感じたのは、各クラウドプラットフォームとも、NoSQL系ストレージの長所を活かしつつ、エンタープライズ系で求められる要件を満たすための各種機能がかなり充実してきている、ということです。エンタープライズシステムでクラウドを活用するためのインフラが着々と整ってきていることを改めて実感しました。
現在、この実証実験の結果も含め、MIJS製品技術委員会でのこの一年間のクラウド関連の活動内容をまとめた資料を作成予定ですので、資料が完成したら、またこのメルマガでも告知したいと思います。
（APPRESSO Now！ 2010年11月10日 第11号）
]]>
先日、日経ソフトウェアで「プログラムのソースコードは20%を切ることが望ましい」という記事を書きました。また、8月のMIJSでのディスカッションでも議論の中で同じように「詳細設計書やプログラムのコメントは多い方が良いか、少ない方が良いか」という議論がありました。
この話は、私が大学時代に教官から「以前は、コメント率(ソースコード中のコメントの割合)は50%を超えていないと品質が低いとされた」という話を聞いて衝撃を受けたことが発端となっています。私自身は、詳細設計書やコメントは少なければ少ないほど良いと思っていたのに、「コメント率は50%を超えなければいけない」と言われ、驚いたわけです。その頃は、自分はプログラムは小学生の頃から趣味で色々と書いていたとはいえ、まだプロとしての経験がないので理解できていないだけかとも思ったものですが、大学を卒業してプロとしてのプログラマーの経験を10年強積んだ今、以前にも増して「ソースコードのコメント率は低ければ低いほど良い」という考えが強まっています。
私がプログラムのコメント率が低い方が望ましいと考える理由は、次のような理由です。
「とりわけオブジェクト指向のソフトウェア開発においては、クラス設計やメソッドの切り分け、クラスやメソッドの名称等、ソースコードそのものに語らせることが望ましい。これらでは十分な説明ができず、日本語で記述されたコメントがないと理解が難しいなら、設計そのものに問題がある可能性が高い。」
この意見について、日経ソフトウェアの記事に対する反応でも、MIJSの中での議論でも、「コメント率は高い方が良い派」と「コメント率は低い方が良い派」にはっきりと分かれました。
例えば、「名前を設定する機能」としてsetName(String)というメソッドがあったとします。コメント不要から見れば、setName( )というメソッドの名前から「名前を設定する機能」であることは明らかなので、「名前を設定します」というコメントは必要ないわけです。コメントを書かなければならないのは、「setName( )という名前だが名前を設定するだけでなくかれこれ云々の挙動も伴うので注意」など、メソッド名からは挙動が推測できない時です。こうした視点で見ると、コメントを書かなければならないコードが大量にあるということは、同時に、コメントを読んでもわかりにくいコードが大量にあるということなのです。別の言い方をすれば誤用されて混乱を招きやすいコードが大量にある、とも言えるでしょう。
色々な立場の人の意見を聞くと、年齢に比例して高いコメント率を求める傾向があるように見受けられますが、このような考え方の相違が生まれるのは、その背景にはIDE（統合開発環境）の進化があると思います。現在のIDEは、あるクラスやメソッドが参照されている箇所を即座に検索したり、クラスの継承関係を親子とも即座に階層化して表示したり、メソッドの中で呼び出される別のメソッドにジャンプしたりすることが非常に容易になっています。こうしたIDEの変化によって、現在では以前よりずっと「ソースコードを追いやすく」なってきています。
こうした変化の中で、例えばApacheのオープンソースのライブラリなど、公開されて広く利用されているライブラリなどのAPIドキュメントも、以前は上述のsetName()のようなメソッドにもいちいちコメントがついていましたが、最近ではこの手の名前から即、推測できるクラスやメソッド、フィールドについては、コメントがまったくつけられていないケースをよく見るようになってきました。詳細設計書やコメントをできるだけ丁寧に詳細に書き込んでいく作業は以前は当たり前のことだったかも知れませんが、現在はIDEの進化に伴い、「コメントはできるだけ書かないコードが美しいコード」という考え方をする人もかなり増えてきています。
もちろん、従来のコメントを厚くつけく方法で開発を進めていくことも可能ですが、むしろコメントは少なければ少ないほど良い、という考え方もあるし、それなりに普及してきている、ということは、特に以前は現場で開発に携わっていたが、最近はマネジメントに特化していてあまり開発はしていない、という方は、頭の片隅に置いておくと良いのではないでしょうか。ひょっとすると、若いエンジニアたちの発言が今までと違った角度で見えるようになるかもしれません。
3年ほど前から、九州大学大学院(工学部)の「高度ICTリーダー特論」という授業の非常勤講師として授業をしています。
アプレッソのオフィスは東京にあるので毎週九州まで通うことはできませんが、3日間の夏期集中講義という形なので仕事にあまり影響がない形で授業を受け持つことが出来ています。今年は8月9日から8月11日までの3日間授業をしてきたので、今日はその感想を書いてみたいと思います。
この講義では毎年、ベンチャー、日本の大企業、外資系企業、官僚などの様々な立場の講師がそれぞれの視点からのリーダーシップについて発表したりパネルディスカッションをしたりしているのですが、今回印象的だったのは東京海上火災の牧野さんの発表の中で紹介されていた、ダニエル・ピンクの「やる気に関する驚きの科学」です。
ビジネスの世界では、「成功報酬があればやる気が増幅する」ことを前提とした各種報酬制度が用意されていますが、これに対して、ダニエル・ピンクは「ローソクの実験」の例を出します。この実験は、少し知恵を絞る必要があるローソクのクイズを、２つのグループに出題します。一つめのグループには「問題を解くのにかかる平均時間を測りたい」と説明し、もう一方のグループには「早く問題が解けた人には5ドル～20ドルを支払う」と説明します。この実験はもう40年間続けられているそうなのですが、どの年の結果を見ても、前者の、報酬を設定されていないグループの方が問題を早く解けるそうです。つまり、クリエイティブな要素の強い仕事や知恵を絞る必要のある仕事は、報酬が設定されているからと言ってより良い成果がでるわけではない、というわけです。ダニエル・ピンクは「こうした事実があるにも関わらず、ビジネスの世界ではこの事実と反することが行われている」と指摘します。
また、同じく牧野さんの発表の中で紹介されていた「AZスーパーセンター」の話も大変印象的でした。AZスーパーセンターでは、売上目標は立てず、利益は第一に考えず利益第二主義を明言し、脱管理主義を徹底して従業員の自主的で積極的な行動を促しているのだそうです。
その他の例も含めて、牧野さんがこの授業で一貫して主張していたのは、「アメリカ型のリーダーシップで、報酬を提示し、従業員を管理するのではなく、もっと従業員がしなやかな感性を発揮できる『良い会社』『大切にしたい会社』の在り方があるのではないか」ということです。
牧野さんの授業を聞いていて、以前ブログで紹介した「Eric Sink on the Business of Software」*1でエリック・シンクが主張していた「小さなISV」の話を思い出しました。「小さなISV」とは、「倍々ゲームの成長率を重視するのではなく、丁寧にソフトウェアを作り上げてゆき、社内の様々なプロセスに磨きをかけながら、大企業化を志向しないソフトウェアベンダー」のことを指します。
業態や会社のカルチャー、経営者の考え方等によって、牧野さんが紹介するような運営形態を実現するのは難しい場合もあるかと思いますが、こうした例があることを常に念頭におきながら、自分自身の仕事や、会社の運営を行って行きたいものです。
（APPRESSO Now！ 2010年9月9日 第9号）
]]>
6月27日に、京都大学情報学同窓会「超交流会」に参加してきました。
私自身は慶応義塾大学出身なので、京都大学のOBというわけではないのですが、「CTOのから騒ぎ」というパネルディスカッションのパネラーとしてお声がけいただいたので、せっかくなので他のセッションもいくつか聴講してきました。また、イベント前日には講演者同士の交流会の場として、京都で最も大きい禅寺である妙心寺の、宮本武蔵が悟りを開くきっかけとなった国宝「瓢鮎図(ひょうねんず)」で知られる退蔵院での懇親会にも参加してきました。
今回は少しITの話から離れて、超交流会と、前日の妙心寺の懇親会で印象的だった話を書いてみようと思います。
■ 妙心寺 退蔵院での懇親会
妙心寺では、副住職の方から退蔵院の説明を受けたのですが、ここで印象的だったのは、昔、妙心寺が雨漏りした時の話でした。雨漏りしたとの知らせを聞いて、一人の弟子はざるを持ってきたそうです。もう一人の弟子は鍋を持ってきたそうです。雨漏りの対策として有効なのは鍋ですが、鍋を持ってきた弟子はこっぴどく叱られたそうです。それは何故か？
答えは、「すぐ来なかったから」だそうです。
上の例は厳密には禅問答ではないそうですが、禅問答とはこの例にあるように、ある問いを通じて、大切なことに気づいていくプロセスだそうです。副住職ご自身の体験としても、目の怪我をして入院した際、友人が本を持ってきてくれたそうです。目を怪我していたので読めなかったけれど、まず駆けつけてくれたことがとにかく嬉しかった、と話していました。
■ 栗城さんのセッション
超交流会で参加したセッションの中で一番印象的だったのは、登山家の栗城さんのセッションでした。
栗城さんはエベレストなどの8,000m級の山を単独無酸素登頂されていて、以前からネットでも有名だったので、私もYouTubeで動画を何度か観させていただいていました。栗城さんは上京してきたものの、ニートに近い生活をしていたのが、今では登山費用1億を超えるプロジェクトも動かせるようになったそうです。何もないところから夢を実現するためにはどうすれば良いのか、ということについて、栗城さんは「叶うという字は10回口にすると書く。夢を叶えるには毎日10回口にすること。」と話していました。
妙心寺副住職の話と、栗城さんの話に共通するのは、「まず口にしたり、行動したりすること」が大切だということだと思います。私たちは普段の仕事や生活の中で、考えすぎてなかなか行動しないことがあったりもしますが、行動や提案、発言を踏みとどまりそうになったときには、副住職と栗城さんの話を思い出そう、と心に決めた6月の京都出張でした。
（APPRESSO Now！ 2010年7月7日 第8号）
]]>この数ヶ月で、エンタープライズでのクラウドの活用に関するいくつかの重要な発表がありました。既に、技術的詳細がアナウンスされているマイクロソフトのWindows Azureに加え、 その他4大パブリッククラウド関連では、具体的には、2月に発表されたAmazon Web ServicesのAmazon SimpleDBにおけるConsistent Readオプションの追加、4月に発表されたセールスフォースとVMwareの「VMforce」、5月に開催されたGoogle I/Oで発表されたGoogle App Engine for Businessなどです。Windows Azureのアナウンス以来、エンタープライズ向け用途のクラウドと言えばWindows Azure、という印象がありましたが、ここに来て各クラウドプラットフォームともエンタープライズ向けの機能を拡充させてきています。
■ Amazon SimpleDB Consistent Read
いわゆるNoSQLに分類されるAmazon SimpleDBに、Consistent Readオプションが追加されました。読み取りクエリを発行する際にこのオプションを有効にすると、「成功した書き込み処理の内容が必ず反映された状態」でデータを読み取ることができます。従来のRDBMSなどでは「書き込みに成功したのであれば、読み取りの際にはその内容が反映されていること」はごく当たり前のことですが、クラウド系のストレージでは、データの即時一貫性より応答性や分散耐性を重視し、タイミングによっては少し古いデータが読み取られることを許容する場合も少なくありません。応答性より一貫性を重視するオプションが追加されたことで、クラウドネイティブなSimpleDBにエンタープライズでの利用の可能性が広がりました。
■ セールスフォース+ VMware = VMforce
VMforceの登場により、Springフレームワーク上での開発のノウハウがクラウドでそのまま活かせるようになります。Tomcatなどのアプリケーションサーバー上に通常のSprintアプリケーションを構築するのと同じ要領でクラウド上のアプリケーションを構築できるわけです。世界には600万人以上のJava技術者がいると言われていますが、クラウドでこれまでのJavaアプリケーション開発のノウハウやスキルを活用できるようになることは、エンタープライズでのクラウドの利用にとって大きな前進です。
■ Google App Engine for Business
Google I/Oで発表されたGoogle App Engine for Businessは従来のGoogleApp Engineに、エンタープライズ用途向けの各種機能や契約体系が強化されたものです。具体的には、従来から提供されていたBigTableに加え、RDBMSがサポートされる他、99.9%のSLAとサポートサービスが追加されています。
従来はGoogleApp Engineといえば特にウェブ系を中心に、スタートアップの会社が使っている印象がありましたが、これらの拡張により、エンタープライズでの適用範囲が広がりました。
マイクロソフトはAmazon、Google、セールスフォースなどに続いて比較的後発でクラウドに参入したわけですが、このような最近の流れを見るとエンタープライズ・クラウドの分野では、先発組の各社が、逆にWindows Azureを追いかけるような格好になっています。この数ヶ月でエンタープライズ・クラウドを考える上での重要な発表が相次ぎましたが、これらを受けて、年末くらいまでにエンタープライズ・クラウドの事例も次々と出てくるものと思われます。これからますます目が離せなくなってきそうです。
（APPRESSO Now！ 2010年6月11日 第7号）
メールマガジン購読をご希望の方は、こちらからご登録ください。
株式会社アプレッソ メルマガ運営事務局merumaga@appresso.com
]]>
■4月21日に、アプレッソは「つなぐ」ソリューションの第３弾「DataSpider BPM」を発表しました。（ 詳しくはこちら＞http://bpm.appresso.com/）
今回は、アプレッソがDataSpider BPMを提供することにどのような意味があるかをお話します。
■ BPMの役割
まず最初にBPMという言葉についてですが、これはBusiness Process Management を略したもので、業務プロセスの定義改善を継続的に行い、それを管理し、あるべきプロセスに近づける、という経営管理概念となっています。具体的には各プロセス内のタスクを「定義設計」(Process Modeling)し、その定義に従った「業務実施」(ProcessOperation)を統制し、業務実績を「モニタリング」(Process Monitoring)し、これらを循環的に反復することで、事業環境に適したプロセスを模索し続ける活動を指します。言い換えれば、社内業務プロセスに関する改善サイクル(PDSサイクル／PDCAサイクル)そのものであるとも言えます。
■ 2つのワークフロー
アプレッソではこれまで、データ連携にフォーカスを絞ってDataSpiderを開発し、機能拡張してきました。ワークフローには大きく分けて、各種の申請や承認などの業務プロセスを表す「ヒューマンワークフロー」と、システムの処理の流れを示す「システムワークフロー」という２つの種類があります。
SOAの文脈では、これらはそれぞれHuman-Centric SOA、Integration-Centric SOAと呼ばれ、同じようにBPMでも、Human-Centric BPM、Integration-Centric BPMと呼ばれています。この分類で言うと、DataSpiderがこれまで取り組んで来たのは「システムワークフロー」の分野だったわけです。
ヒューマンワークフローとシステムワークフローとは、相互に接続することで足し算ではなく掛け算の効果を生み出すものです。システムワークフローのみでは重要なデータを更新する際に直前に人による目視での確認処理を入れることができませんし、ヒューマンワークフローのみでは人がフォームから入力したデータをバックエンドシステムに反映させることができません。もし、ヒューマンワークフローとシステムワークフローとの双方向の柔軟な連携が実現すれば、一つのフローの中で、入力フォームの一部にシステムから取得してきた値を表示し、人が入力した値を自動的にシステムに格納することも可能になってきます。
■ クラウドともつながるヒューマンワークフロー
アプレッソでは現在、クラウド連携に特に力を入れて開発を進めています。このことと、今回のDataSpider BPMのリリースとは、無関係ではありません。今後、クラウドを活用したシステムを検討する企業が急増してくるものと思われますが、DataSpiderを使えば、申請処理等の各種業務のヒューマンワークフローの中に、クラウドに格納されたデータを埋め込むことができるのです。逆に、ヒューマンワークフローのフォームで入力したデータを、ノンプログラミングでクラウドに格納することもできます。もちろん、クラウド上のデータだけでなく、メインフレームやERP、Excelといった従来のシステムとクラウドのデータとをマージし、その結果を入力フォームに表示させる、といった応用も可能です。
アプレッソのキーワードは「つなぐ」ことですが、DataSpider BPMの登場でデータやシステムを「つなぐ」だけでなく、人とシステムとを「つなぐ」ことができるようになり、ヒューマンワークフローとシステムワークフローとがシームレスに連携できるようになります。
今後も「つなぐ」をキーワードに製品の開発を進めていきますので、ご期待ください。
（APPRESSO Now！ 2010年4月21日 第6号）
メールマガジン購読をご希望の方は、こちらからご登録ください。
株式会社アプレッソ メルマガ運営事務局merumaga@appresso.com
]]>今回は「mixiアプリ」の成功例の一つである「ブラウザ三国志」について考察してみたいと思います。
mixiアプリとは、名前の通りmixiの一部として動作させることができるアプリケーションの総称で、現在リリースされているアプリケーションの多くはゲーム系のアプリケーションとなっています。私が今没頭している戦国シミュレーションゲームのブラウザ三国志 for mixiもmixiアプリの一つとなっており、このサービスのビジネスモデルがソフトウェアビジネスの今後を考える上で大変興味深い事例なので、こちらでも紹介したいと思います。
ブラウザ三国志は、基本的に無料のゲームです。武将を育てたり、都市を成長させたりすることができますが、通常の一人で遊ぶタイプの戦国シミューレションゲームと異なり、周囲の君主もコンピューターではなく人間が操作しています。ですので、自分の本拠地の近くの領土が取られたとなれば、「周囲の君主が自分を倒そうとしている」ということで非常に焦り、どういう意図なのかを該当領地を取得した君主に書簡で問い合わせ、もし納得出来る回答がなければ場合によっては開戦することもあります。ゲーム中盤以降は、ほとんどのプレイヤーがどこかの同盟に参加していきます。他のプレイヤーと同盟を組むことで、軍事面での抑止力を向上させたり、難易度の高い城の攻略を目指したりすることができるからです。
このゲームは基本的にずっと無料で遊ぶことができますが、有料の便利オプションがあります。例えば、建設に時間のかかる建物の工事を150円で即座に終わらせたり、内政面での各種資源の収穫量を180円でアップさせたり、派兵していた兵士を80円で即時帰還させたりすることができます。
私は当初、「無料で最後まで遊ぶことができるのに、お金を払う人なんているのだろうか」と疑問に思っていたものですが、ゲームに没頭していくにつれ、例えば自分や味方の周囲に脅威が差し迫った時、「今1,000円くらいかければ安全が確保できるかもしれない」と思うと、緊急時だから今回だけ、ということでついつい有料オプションを使ってしまいます。この時の心境は、遅刻しそうになってタクシーを使う時のそれと似ているかも知れません。
こうして私などは、運営会社の思う壺、掌の上でコロコロと転がされているわけですが、先日あるところでmixiアプリで人気のあるゲームの売上を一部目にすることがありました。ユーザーの中には私のような人が多数いるようで、ゲーム1本で年間数十億を売り上げている会社もありました。以前、ITMediaのゲーム業界を考察した記事で、「米国のあるソーシャルゲームメーカーは、ゲーム内のアイテム課金は『7つの大罪』（傲慢、嫉妬、憤怒、怠惰、強欲、暴食、色欲）を刺激することでうまく回ると話していたという」という指摘がありましたが*1、まさにこの指摘の通りかと思います。
ブラウザ三国志に見られるように、欧米のFacebookアプリ、日本のmixiアプリ*2などのソーシャルアプリと呼ばれるソフトウェアサービスでは、従来のソフトウェアのビジネスとまったく異なるビジネスモデルが実現し、高い収益を上げています。従来のソフトウェアのビジネスモデルは、SIであれば人月に対して、パッケージであれば初期購入とメンテナンス、SaaS/ASPであれば月額費用と、それぞれ工数やソフトウェアやデータセンター運用といった、対価のはっきり見えるものに対してお金を払うものでした。しかしソーシャルアプリのビジネスモデルは、これらの価値に対して課金するのではなく、ユーザーの欲求充足のためにお金を払うモデルとなっています。プログラム的に言えばif文のある条件にマッチさせるようにするだけのためにお金を払うわけですから、「原価がこれくらいなのだから○○円くらいが妥当」という感覚から言えば信じられないような世界です。
こうした「欲求ドリブン課金」は少なくとも当面はエンタープライズのビジネスとあまり接点のないものかも知れませんが、同じソフトウェアのビジネスの展開としては大変興味深い事例ではないかと思っています。
※ SNSが実質プラットフォーム戦争の世界に入っていることについては、これはこれで一本の記事になる面白いテーマなので、また別のコラムで取り上げるかも知れません。
*1 http://www.itmedia.co.jp/news/articles/1002/17/news087_2.html
*2 先日、GREEもプラットフォーム事業を始めましたね
（APPRESSO Now！ 2010年3月24日 第5号）
メールマガジン購読をご希望の方は、こちらからご登録ください。
株式会社アプレッソ メルマガ運営事務局merumaga@appresso.com
]]>今回は、今後のソフトウェアの在り方を示す興味深い例として、reCAPTCHAというプロジェクトを紹介したいと思います
まずおさらいですが、CAPTCHA(キャプチャ)とは、ユーザーが人間であるかどうかを確認するために、グニャグニャに歪んだ英数字や単語をユーザーが入力する仕組みのことです。「ああ、ウェブのサービスを使っていると時々出てくるあれか」と思い起こされる方も多いのではないでしょうか。
通常のCAPTCHAでは一塊の文字や単語を入力しますが、reCAPTCHAでは、二組の文字を入力する必要があります。一つは正解のわかっている文字、そしてもう一つは、正解のわかっていない文字です。現在、世界の様々なところでOCRを用いた書籍のデジタル化が進んでいますが、インクが滲んでしまっていたり、かすれて薄くなってしまっていたりすると、プログラムでは判別できない文字というのがどうしても出てきてしまいます。そこで、どのOCRで読んでも同じ文字と認識されるような「正しいことがわかっている単語」と、OCRによって読取結果が異なるような「正解のわからない単語」とを一つずつCAPTCHAの入力画面に表示し、前者はユーザーが人間であることの認証に、後者は機械が読み取れなかった文字の解読に用いるのです。
reCAPTCHAでは、無償のCAPTCHAサービスを提供しており、ウェブでサービスを始める際にはreCAPTCHAを使えばCAPTCHAの機構を自分で作成することなく利用できるようになっています。そして、reCAPTCHAを採用しているサービスに文字を入力する時、私たちは自分が人間であることを証明するだけでなく、書籍や各種文書のデジタル化に、間接的に貢献しているのです。
「気づかぬうちに何かに貢献している」という話としては、改札を通る人達の「踏みつけエネルギー」を発電につなげようという東京駅の発電床が有名ですが、reCAPTCHAプロジェクトは「いつのまにか貢献している」ことの他にも、まず機械ができるところまではプログラムで処理し、どうしてもダメだったところを人間が対応する、という機械と人間のコラボレーションの事例としても大変興味深い事例です。
ソフトウェアには、例えばビジネスアプリケーションを使って業務効率を上げたり、ゲームソフトで遊んで楽しんだり、といったようなソフトウェア単体での使い方もありますが、reCAPTCHAプロジェクトが示したように、ユーザーがソフトウェアを通じて、自然と何かに貢献するようなアーキテクチャを設計することも可能なわけです。こうした変化が起こりつつあることを踏まえて、今後のソフトウェアの在り方や、開発するプロダクトの方向性を考えて行きたいものです。
*1「機械と人間のコラボレーション」という意味では、Amazon Mechanical
Turkというサービスがありますが、これはこれで大変面白いサービスなので、また別の機会にでも紹介したいと思います。
（APPRESSO Now！ 2010年3月3日 第4号）
メールマガジン購読をご希望の方は、こちらからご登録ください。
株式会社アプレッソ メルマガ運営事務局merumaga@appresso.com
]]>
アプレッソのソフトウェア製品「DataSpider」は、SOA、EAI、ETLなどいろいろな既存の「カテゴリー」で分類されています。 2000年当初、私がこの「DataSpider」の開発を始めたときには私の頭の中には、「自由自在に多種多様なデータやシステムを連携させる」といった、ある意味、漠然としながらも、明確な目的がありました。
その時の私の発想は「EAI」や「ETL」といったカテゴリーやジャンルから起因したものではなく、また、その当時はまだ「SOA」という概念や用語も世の中に出回ってはいませんでした。
ソフトウェア以外でも「モノづくり」全般に共通して言えることかと思いますが、何か「新しいモノ」を生み出そうとするとき、まず「似ている既存の何か」や「カテゴリー」を意識して考えがちになると思います。
まだ世の中に全く存在しない「モノ」について、自分の頭の中に浮かんだ漠然とした「アイディア」以外に例えるものがない状態では、うまく説明がつきません。また、その「アイディア」を聞かされている側からすれば既存の類似製品やジャンルで説明してもらう方が親切で、少なくともその「概念」は理解した気分になりますし、伝わりやすくなります。こうした理由から、私たちは「新しいモノ」に対して、既存のカテゴリーと結びつけて考えがちです。
しかし一方で、こうした比較は、当初何かを作ろうと思うに至った、「アイディアのエネルギー」を減退させる危険性も持ち合わせています。
「こんなモノがあれば！」と、自らの発見に大いに興奮した直後、ふとGoogleでキーワード検索したら、似たようなものが存在することを知って落胆する...とりわけネットでの検索が高度に進歩した現在、こうした光景も珍しいことではありません。しかし、そんなときでも忘れてはならないのは、その発見の瞬間、そのアイディアの原点が何だったのかということです。落胆してそこであきらめてしまうのではなく、「神は細部に宿る」という言葉の示すように、もし似たような製品が存在していても、多くの場合、その細部には、重要な改善の余地が残されています。
特にITの世界には、こうした「改善」のチャンスがゴロゴロ転がっているように思えます。さらにソフトウェアの世界では、その改善余地も無限大だと思います。既存のソフトウェアをちょっと不便だなと思いな がらも工夫してうまく使いこなすことも大切ですが、プログラムという「モノづくり」でも自分のアイディアと情熱を忘れずに、また分類や既存概念に捕われすぎず、ひらめき、着眼点、細部に光る長所を持った ソフトウェアを作っていきたいものです。
（APPRESSO Now！ 2010年2月19日 第3号）
メールマガジン購読をご希望の方は、こちらからご登録ください。
株式会社アプレッソ メルマガ運営事務局merumaga@appresso.com
]]>今回は「クラウド」をテーマに、少し技術的な話も交えながら、クラウドの現状やアプレッソの取り組みなどについてお話ししたいと思います。
先日某所のセミナーで早稲田大学の丸山不二夫先生が、クラウドの現状を「2009年は疑問から関心へ、2010年は関心から受容へ」とおっしゃっていましたが、エンタープライズ分野でのクラウドの活用、という観点から見ても、従来からの Amazon や Google、Salesforce に加え、エンタープライズ分野 でのキープレイヤーのマイクロソフトも WindowsAzure の本格稼働を開始、続いてAmazon もクラウドの国内でのサポート体制強化を発表と、昨年末から今年の年初にかけて、クラウドをエンタープライズで活用していくためのインフラが急速に整ってきています。
米国でも、「2010年から2011年にかけて、エンタープライズITの分野でのクラウドはキャズムを越える」という記事がTechCrunchに掲載されたりと、エンタープライズ分野でのクラウド活用の勢いはとどまるところを知りません。
クラウドのテクノロジーは、スケールアウトの自動化や大規模分散処理の実現、運用コストの削減など、いくつものメリットをもたらします。
そして、インターネットのコンシュマー向けのサービスから生まれてきたクラウドのテクノロジーの多くは、エンタープライズの分野にもそのまま応用することができます。
一方で、クラウドにメリットがあるからといって、ユーザー企業から見てあらゆるシステムがクラウドで稼働することが常に望ましいわけではありません。例えば動画配信サービスを考えてみると、すべてのシステムをクラウド上で動作させることも可能ですが、動画コンテンツのような大容量データはクラウドに配置し、動画の閲覧履歴や購入情報といった個人情報は社内で管理したい、という要求もあるでしょう。また、すでに投資を行ってきた既存システムを活かしつつ、スケールアウトの要求が特に強い箇所や、コスト効率が要求される箇所のみクラウド上で新規開発を行って置き換えていきたい、というケースもあるでしょう。一つのシステムの中で、価値ある既存資産と、クラウドの利点との両方の価値を最大限発揮していくわけです。
さらに、クラウドの技術の中には、データの即時一貫性が取れないものもあるため、要件的にクラウドに乗せにくかったり、クラウドに乗せてもクラウドのメリットが活かしにくい場合もあります。
こうした、「すべてを移行するわけではない」状況の中で、従来通りオンプレミス(社内運用)に配置されるシステムと、クラウドに移行するシステムとの間の連携が必要になってきます。そして、アプレッソが1年ほど前から最重要テーマとして取り組んでいるのが、この「クラウドとオンプレミスの連携」をDataSpiderで簡単に実現するための各種機能の開発です。
すでに、Amazon、Google、Salesforce、WindowsAzureそれぞれについてアダプタの開発が進んでおり、特にWindows Azureについては、wipse(windows Plus services consortium)において、昨年夏の時点でDataSpiderを用いたクラウド - オンプレミス連携の実証実験が成功し、2月23日、24日のマイ クロソフトの「Tech・Days」ではさらに進んだ実証実験の紹介とデモンストレーションを行う予定です。
そして、来月以降、クラウドに接続するアダプタが順次製品としてリリースされ、この先数ヶ月で4大クラウドプラットフォームすべてに対して、クラウド- オンプレミス、複数のクラウドをまたがる連携などが、従来のDataSpiderと同じ要領で、ノンプログラミングで簡単に実現できるようになります。もちろん、これらのクラウド接続アダプタは、既存のすべてのアダプタと相互接続が可能です。
このあたりのDataSpider関連の話は、2月10日のアプレッソの事例セミナーでもご紹介しますので、お時間と興味のある方はお立ち寄りください。
アプレッソが設立以来DataSpiderの開発に注力してきたのは、「データの格納場所とシステムの差異を意識せず、シームレスに、簡単にデータ連携を実現する」IT環境を実現するためです。
クラウドの時代にも、この初心を貫き、クラウドとオンプレミスのシステムの相互連携をノンプログラミングで実現できるプラットフォームをいち早く提供していきます。
後半少し製品の話が多くなりましたが、クラウドの時代には様々なことが変化してきます。データの保存方法やモデリング一つとっても、従来のRDBをベースとしたものから、クラウドの利点を活かしたキー・バリュー・ストアを使うケースが増えてきますし、システムのアーキテクチャもかなり変わってきます。この辺りのテーマについては、この連載でも追って触れていきたいと思います。
（APPRESSO Now！ 2010年1月22日 第2号）
メールマガジン購読をご希望の方は、こちらからご登録ください。
株式会社アプレッソ メルマガ運営事務局merumaga@appresso.com
]]>
皆さんこんにちは、アプレッソでCTOを勤めている小野と申します。普段はブログ(*1)や日経ソフトウェアの連載(*2)で文章を書いたり、Twitter(*3) でつぶやいたりしているのですが、今回からアプレッソのメルマガでもコラムを書くことになりました。こちらでは、IT業界、プログラミング、データ連携、クラウドなどに関するテーマを扱っていきたいと思います。
今回は第一回ということで、なぜ日本でアプレッソという会社を始めたのかについて書きたいと思います。
*1http://blog.livedoor.jp/lalha/
*2 日経ソフトウェア連載 「小野和俊のプログラマ独立独歩」
*3http://twitter.com/lalha/
大学卒業後、日本サン・マイクロシステムズに就職した私は、研修後に米国本社での半年間の開発プロジェクトに参加する機会を得ました。よく、「シリコンバレーは日本より五年進んでいる」と耳にしていた私は、「そんな風に言われるシリコンバレーは、一体どんなところなのだろう」と、目を輝かせてシリコンバレーへと向かいました。
半年間という短い期間のプロジェクトでしたが、その期間に私は、シリコンバレーの優れている点と、逆に日本の方が優れている点とを痛感しました。
本社での私のマネージャーはダグラス・ヒルという人だったのですが、生まれも育ちも仕事もシリコンバレーという生粋のシリコンバレーっ子である彼のマネジメントは、本当に独特でした。プロジェクトの納期が迫っていたある日、まだ解決できていない問題がいくつもあり、日本から来た私たちは、ねじりはちまきでがんばろう、というような話をしていました。
するとダグラスは、「ところでスキー板は持ってきてるかい？」と聞いてきます。翌日、私たちはダグラスのワゴンに乗り、スキーやカジノなどのリゾート地として有名なレイク・タホに向かいました。
「これはオフサイト・ミーティングだ」と言って、彼はそこで私たちに選択を迫りました。「スキーか、スノーボードか、どちらかを選んでほしい」。二日間雪山で過ごした私たちは、「そういえばあの二つの機能は一つの実装で実現できるな」「あの機能はそもそも必要ないのでは？」などと、遊びながら、いくつかのことに気づきました。
彼は、レイク・タホに、多忙で狭くなっていた私たちの視野を広げに行っていたのです。
一方で、ダグラスは、私が日本から持参したティッシュ箱に、とても驚いていました。
一つは、空き箱の脇から手を入れると、折りたためること。もう一つは、箱上部のミシン目が二段階になっていて、指を差し込みやすくなっていること。また、以前米国在住のブロガーの方が書かれていた話で、日本ではスーパーの卵は必ず皆同じ方向を向いているが、米国では向きがまちまちだったり、空きがあったり、割れていたりするのは当たり前だという話もありました。
ダイナミックな発想を生み出すマネジメントや風土という意味ではシリコンバレーから私たちが学ぶことは多くあると思いますが、作り込みの細やかさや、高い品質のための徹底したテストという点では、ティッシュ箱に限らず、やはり日本の方が優れている、と至る所で感じました。
米国で半年間の開発を経験し、私は、ソフトウェア開発の世界で、こうした米国の柔軟さとダイナミクスと、日本の細やかさとを持ち合わせた会社を作れないか、と考えました。また、「原材料を伴わずに製造可能」というソフトウェアの特性を活かし、パッケージベンダーとして、少数のソフトウェアに注力して磨きをかけていきたい、と考えました。
第一回と言うことで少し長くなってしまいましたが、以上のような経緯で始めたのが、アプレッソという会社です。ソフトウェアだけには限りませんが、「日本ならでは」の価値創造を見直すことや、限定された視野に陥りやすい状況での、「緩急自在」のシリコンバレー流マネジメントを取り入れることは「今」の日本に必要な発想であることを創業時を振りかえって改めて感じるこの頃です。
（APPRESSO Now！ 2009年12月19日 創刊号）
メールマガジン購読をご希望の方は、こちらからご登録ください。
株式会社アプレッソ メルマガ運営事務局merumaga@appresso.com
]]>