インターオペラビリティに関わる技術標準

「The Open Group」のSOA Japan Working Groupにて、SOAに関連する標準仕様について調査を実施。　SOAのインターオペラビリティについての検討の一環で標準仕様についての調査を開始したが、調査をし始めて非常に困難であることがわかってきた。　当初は、インターオペラビリティに関する標準仕様と、ミドルウェア・ベンダーやERPベンダーの対応状況も併せて調査する予定であったが、この調査は事実上不可能であるとの結論に至った。　それは、標準仕様の数の多さと関連する製品ベンダーの情報を全て把握することに非常に多くの時間を要する事が困難であるためである。　今回、調査した標準仕様の数は、１２０種類を超えている。　また、この中には各標準化団体間で重複している仕様や、新旧の仕様が混在しており、現時点でどの標準仕様が実用可能なのかの判断も非常に困難であった。　今回の調査から、SOA（Webサービスを含む）に関わる標準仕様は非常に多く存在しており、その中からどの標準仕様を選択して製品化または既存製品の利用をすれば良いかの判断が難しいことと痛感した。　そんな中での成果として、これらの潮流を読むには、ERPベンダーの標準仕様の採用状況がひとつの指針になる事を感じた。　SAP社、Oracle社ともに自社製品のSOA対応が進んでおり、それらの製品が採用している標準仕様は、今後も主流になる可能性が高い。　今回調査した標準仕様一覧について、現時点では公開できるレベルには無いことが残念であるが、これを０から調査するには相当な時間を要するので、是非公開できるよう努力したい。

スマートフォン

BlackBerryが「BlackBerry Application Center」を立ち上げるらしい、と今朝のニュースで発見。Appleの「App Store」に対抗しての対応と思われる。スマートフォンユーザにとって利用できるソフトウェアが手軽に入手できる事は喜ばしいことである。　一方ソフトウェア開発をビジネスにしている立場から見ると、スマートフォン向けのソフトウェア開発は大きな夢を感じる。　前述のとおりネットを通して簡単に販売できるチャネルが確立しつつあるので、自社で開発したソフトウェアが世界中のユーザに利用していただける可能性があるためだ。弊社でもiPhone開発に注力しているが、早期に世界中で利用できるソフトウェアをリリースしたいと考える。　今後は、モバイル端末からクラウドのサービスを利用するのがトレンドになっていく可能性が高いが、利用可能なソフトウェアの絶対数が不足している状況なので、その領域でのソフトウェア開発の必要性を強く感じている。　

本当に統合して大丈夫？

ここ数年サーバー統合が進んでいる。　スケールアウトでむやみに増加したサーバー群を管理する事が容易ではなく、運用コストも馬鹿にならないし、無駄なリソースがもったいないなど、問題が多いからだ。　そこで、統合、という動きは正しいと思う。だが、統合すれば全ての問題が解決されて皆ハッピーといくのだろうか？　多くの問題は解決されるだろうが、新たに背負い込む問題もある。　”統合＝集中”という構図では、今までは、どこかのサーバーが障害を起こしても、他のサーバーがなんとかしてくれていたはずである。　当然、統合したサーバーも冗長構成を組むなど、ＨＡ対応は必須であり、システムダウンしない対処が必要。　しかし、この集中化が厄介な面もある。　今までのスケールアウトな構成では、いい加減さを許容してくれていたのではないだろうか。　稼動するシステムのリソース計算など、”多めに用意すれば大丈夫だろう”といった感じで。だが集中したシステムでは、このいい加減さの許容が減ってくる。　ある意味メインフレームでのシステム運用に似てくると思う。　メインフレームは、”ほとんどダウンしません”とその可用性が売りであるが、本番業務で稼動しているシステムは、ダウンしないように最適化されているから可用性が高いのだ。　本番運用前のテスト稼動時の最適化前にシステムは結構ダウンする（こともある）。　安定稼動する為には、システムリソースの利用状況などを十分に試算した上で、本番業務運用に耐えうる”設計”が重要。　ＩＡサーバによる統合においても運用管理ツールやモニターリングツールなどで、最適化を図ることが可能である。よって、統合して”集中”したシステムが最適な状況にあるかどうかを見極める目が非常に重要であり、むやみに統合すると新たなリスクが発生する事を認識する必要がある。

今どきのソフトウェア開発

最近、改めてソフトウェア開発のあり方を考えさせられる出来事があった。何年たっても一定人数を超えるチームでのソフトウェア開発は難しい。私自身が若いころは、重厚長大なメインフレームのオンラインシステムなどで、ウォーターフォールでソフトウェア開発を学んできた。しかし、時代とともに多様な開発方法が試され、ウォーターフォール開発の欠点を補完できることは立証されている。　私も前職では、反復開発に代表される開発プロセス・RUP（Rational Unified Process）を企業に導入する立場であり、ウォーターフォールとの違いや反復開発のメリットを企業側に説明してきた。　でも、この手法でやれば失敗はしない、といった開発方法論が存在しているわけではなく、むしろ開発手法以外の部分にソフトウェア開発の成功の鍵は潜んでいると考える。もちろん開発手法は重要な要素であるが、それだけでは駄目という意味。　少し古い話しになるが、2006年に、XPのケント・ベック氏が来日し、「Agileフォーラム2006」というイベントでトヨタ生産方式とアジャイルの関連や、ＸＰ導入の成功事例などを彼が話していた。このイベントで私も縁がありセッションを持たせていただいた。　その時に私が話した内容は、反復開発とアジャイルであり、重たいRUPプロセスをある程度軽量化し、アジャイルの要素を取り入れた開発手法が、最近の開発プロジェクトには適しているのではないか、との考えだ。　なぜ、こんな古い話しを思い出したかというと、冒頭にあるようにソフトウェア開発のあり方を考えさせられる出来事があったからだ。　これを機会に改めてソフトウェア開発のあり方を再考しようと思う。

BlackBerryの評価

先月からBlackBerryの評価をしている。
スマートフォンがどの程度使えるのかを試すことが目的だ。以前、IBM製のPalmを使っていた経験があるが、その頃と今とでは、状況が大きく変わっている。　インタネットを介したサービスが豊富に存在し、PCからの利用は当たり前になっている。今回、特に興味を持って評価しているのが、Googleのサービスをスマートフォンからどの程度使えるか、である。　現在までに利用したのは、Gmail、Gmail for Google Apps、Google Map、Searchの4種類である。　いずれもBlackBerry用のクライアント・アプリケーションが用意されており、Googleのサイトから簡単にダウンロードが可能。　GmailをBlackBerryのブラウザで使ってみたが、ブラウザ経由だと、PCで使うほどユーザインターフェースがいけていない。　また、通信の回数が多いので実用面ではNGか、と思う。　しかし、クライアント・アプリケーションは、ユーザインターフェースがかなりいい。　Gmailのスレッド表示もPCのブラウザで使う感じで使える。　何よりもアプリケーションを起動すると、すぐにメールのInboxが表示されるところがいい。　電車を待っている最中にメールを確認したり、返信したりするのが、億劫ではない。　右上側の画面は、BlackBerryに各クライアント・アプリケーションをインストールした後の状態。　赤い”Ｍ”が通常のGmail（google.comドメイン）で青い”Ｍ”のアイコンが、Google AppsのGmail。　BlackBerryは、QWERTYキーボードを採用しているので、少々長い文章をタイプするのも楽チン。　しかし、電車の中で片手でタイプするのは、ちょっと厳しい。　今度はiPhoneを試してみたい。

IBM System iでのOpenSource協議会

System iってご存知ですか？　AS400と言ったほうがピンッと来る方も多いかもしれませんね。最近はIBM iという名前になったそう。　さらに、このSystem i上でOSSが動作することを知っていますか？　AS400というとクローズなシステムという印象だった。しかし、現在は、各種OSSが動作できる。　System iでのOSSについて、調査したり技術について協議する会が、「OpenSource協議会System i」だ。　サイオスも参画してから1年ほど経過しているが、System iのインフラ環境に詳しくないので、明確な貢献が出来てなかった。　今回、同協議会に”Web分科会”というものを発足させて、System iプラットフォームで、JavaやAjaxなどのWeb技術を調査＆検討する事になった。　実は、サイオスの製品である「Sales Force Automation +」（営業支援ソフト）は、System iで動作している実績がある。同製品は、JavaのWebアプリ。　System iで難しいのは、動作環境が多様で、L-Per上のLinuxや、ネイティブOSなど、動作する環境で、アプリやミドルウェア対応も変わってくる。　協議会では、このあたりも調査していきたいと思う。　5月27日にサイオスにて第1回の分科会が開催される予定。
「OpenSource協議会System i」　http://i5php.jp/

The Open Group JapanにSOAワーキンググループ発足！

ワールドワイドでは、The Open GroupにSOA-Working Groupがあり、活動をしているが、日本は、この活動になかなか貢献できていない現状がある。　今回、日本にSOA-Working Groupが発足され、近い将来にはワールドワイドの活動にも貢献できる事を目的としている。　SOAは、世界的には盛り上がっている情報が入ってきているが、日本では今一つ盛上り感に欠ける現状である。　しかし、日本国内でも導入事例は着々と増えてきているとの事。　なぜ事例情報が入ってこないか？　理由としては、導入企業が事例を公表することに消極的な姿勢であることがある。　中には、大規模なEAの道具として、SOA適用企業もあるらしい。　日本でのSOA発展のためにも、各企業が事例をオープンにして欲しいものである。