InfoQ

InfoQ

News

マイブックマーク

ブックマークするためにログイン または 会員登録 する

ブックマークされました!

ブックマークがエラーになりました。もう一度お願いします。

インタビュー: Miko Matsumura氏にAlignSpaceについて聞く

作者 Jean-Jacques Dubray , 翻訳者 編集部 投稿日 2009年4月30日

セクション
プロセス/プラクティス,
エンタープライズ・アーキテクチャ
トピック
コラボレーション ,
SaaS ,
Business Process Management ,
Architecture ,
Business Process Modeling
タグ
BPMN ,
ソーシャルネットワーキング

原文(投稿日:2009/4/21)へのリンク

InfoQは、先月公開された(リンク)新しいAlignSpace(リンク)サービス(ベータ版)について、Software AGの副CTOであるMiko Matsumura氏と話をした。

[AlignSpace] とは、ビジネスプロセスマネジメントの実践者(プラクティショナー)向けのSaaS(Software as Service)ベースのソーシャルプラットフォームです。最初は、コラボレーティブなビジネスプロセスモデリング機能のみが、制御されたベータプログラ ムで利用可能です。その他の計画されている機能には、以下が含まれます。

コラボレーティブなプロセス発見および設計

ピアネットワーキング

プロセスモデル変換サービス

BPM関連の資産とサービスの市場

このプラットフォームは、2010年初旬までに商用化される準備が整っている。

InfoQ: AlignSpaceで対処しようとしているのは、どのような部類の問題ですか?

Miko氏: SOAの最大の障壁は、複数形「私たち(we)」です。企業には多くの異なる集団が存在します。組織の境界、特にビジネスとIT組織間の境界を越えるとき には、大きなインピーダンスミスマッチがあります。ビジネスプロセスにおける俊敏性を実現することで、BPMによってSOAのROIが左右されることがま すます多くなっています。もし、BPM周辺のクラウド内に、固有の現象として現れるコラボレーティブな機能を置くことができたら、どうなるでしょうか?

最初の問題は、「幸せな道」というのは境界をあまりよく越えないということです。主な障壁は、意図という障壁です。これは何を意味するのでしょう か? 本質的に、ある人の「幸せな道」は、別の人の悪夢です。すべて物の見方次第です。ビジネス組織を幸せにするものは、IT組織を不幸せにする可能性がありま す。ビジネス組織にとっては実現を加速させるものであっても、規制者をうんざりさせるものである可能性があります。

これは、導入を妨げる大きな障壁であり、複雑なところです。また、BPMをビジネス用語に変換しなければならないという問題があります。どうしたら「利益 は何か」という質問に正確に答えることができるか? どのようにして、すべての関係者に適した「グローバルな最適化」をもたらすことができるか?

私たちは、この2つの問題に集中し、すべての主要な関係者を共通のベースラインに結び付けるという目的を持って「クラウド内のコラボレーション」を構築しています(地理的に、レポーティング構造、他の企業…)。

InfoQ: 設計の原則はどのようなものですか?

Miko氏: これはSoftware AGにとって非常に大きな開発です。これまで、私たちはSOAの「配管系統」の側面に追いやられ、主としてBPMを通じてインターフェイスを表面化してき ました。しかし、BPMの経験を積むにつれて、導入には汎用のパターンがあるとわかるようになりました。そしてそれは、バリエーションの管理と関係してい ます。

SOAでは、ビジネスプロセス、インターフェイス、データスキーマのどのバリエーションを管理していようと、競争のために差別化するが運用コスト削減のために統一するという一般原則が適用されます。

すべての実装で直面する問題は、この2つの相反する目標を達成する最も賢明な方法は何かということです。

ツール自体は、異なるコンポーネント上でのコラボレーションを可能にする十分な柔軟性があります。たとえば、当社はプロセス周囲の豊かなユーザー体験を提 供します。私たちの目標は、サイロを超えることです。別のイネーブリング技術は運用面です。当社のツールを使用して、異なる組織を結び付けるKPIを推進 できます。鍵となるのは、共通の目標を確立して測定することです。そのため、最終的にAlignSpaceはプロセスを超えて他のコラボレーション領域に移行するでしょう。しかし、もちろんBPMが第一です。

私たちは、コラボレーションは種をまくことであるように感じていますが、成功を測定できるようになることが、継続的なプロセス改善を達成する鍵となります。

Align Spaceは純粋に設計時のソリューションです。私たちはクラウドに「種まき」をしており、これらの種のいくつかが完全に機能的なプロセスへと開発される ことになります。鍵となるのは合意を得ることであり、ここでクラウドが役に立ちます。この環境は非常にオープンであり、多くの状況で使用できます。

InfoQ: 人々はクラウドの使用を快適に感じるでしょうか?

Miko氏: 私たちは80対20の法則が適用されることに気付きました。プロセスの20%は複雑で組織専用ですが、80%は多かれ少なかれ共有化されます。このため、 顧客やインテグレーターといったパートナーとの共有が容易になります。アクセス制御を定義してアクセス制御を操作できることは重要な一面です。パブリック スペースとプライベートスペースを定義できる能力と、情報をある場所から別の場所へ移動できる能力が非常に重要です。

InfoQ: リーンシックスシグマ(Lean Six Sigma)などの方法論とはどのように関係していますか?

Miko氏: こうしたタイプの方法論は、それほど頻繁に変化せず高いトランザクション量を示すことの多いコアプロセスに最適です。私たちがターゲットにしているプロセ スは、最適化に関するものです。最適化は大きなROIをもたらすことが可能です。コアプロセスは程度の差こそあれ、あまり差別化を生じません。それらはす でに最適化されています。現在のところ私たちは方法論に依存しないことを焦点に当てており、幅広い実践者を受け入れています。

InfoQ: あなたの考えで、AlignSpaceを使用すると思う役割は何でしょうか?

Miko氏: 私たちは多くのプロジェクトを研究しました。そして、特定の役割だけでなく、あらゆる成功プロジェクトに関与しているプレーヤーの図式があることを発見しました。遅いよりは早めにコネクションを確立することが重要です。AlignSpaceは、関与する人々を再定義するものではありませんが、私たちは人々がより早く設計プロセスに加わることを可能にします。これこそ、私たちがプロジェクトの成功に不可欠だと思っていることです。

プロセス改善には、非常に異種のプレーヤーが関与するようになってきています。これにはビジネスの人々が含まれますが、ITの人々も多くの異なるサイロに 腰を下ろしています。私たちは、多数の事業体、顧客、サプライヤ、そして規制者さえもが、プロセスの最適化の利益を得られるかもしれないと想像していま す。

InfoQ: AlignSpaceはBPMNとどのように関係していますか?

Miko氏: BPMNは、AlignSpaceプロジェクト内の第一級市民です。私たちは、表記法としてBPMNを使用しますが、独自の内部表現を持っています。

モデリングに関して素晴らしいことは、取得される情報量を減らすことです。種まきの段階では一般的な表記法で十分ですが、最終的にこれらのモデルをランタイム環境に伝播しなくてはなりません。

この種のすべてのツールにとって重要な側面は標準を交換できることであり、この目標に向けて1つにまとまることが期待されます。

InfoQ: AlignSpaceはSoftware AGの戦略にどのように当てはまりますか?

Miko氏: これはSoftware AGにとって大きなステップであり、AlignSpaceは 当社がどこに向かって進むかを定義する助けとなります。人々はビジネスインフラストラクチャを配管設備として見なす傾向があります。ここで鍵となるのは、 Software AGは豊富な経験があり、最も解決が困難な問題は対人関係を管理することであるということを長年にわたって学んできたことです。当社にとって、これは非常 に大きな氷山の一角にすぎません。私たちはさまざまな支持者に同意してもらうことを目指しています。

当社の存在は2つの主要な可変要素によって定義されると考えています。昔から受け継ぐ現実と、会社を進歩させるために革新する現代の現実がありま す。40年にわたる当社の長年の経験からすると、企業はすでに投資したものから同じだけの価値を引き出す傾向があります。最適なモデルは過去に大きく依存 します。統合(好ましくない古い言葉)はビジネスの現実であり、人々は合併し続けるでしょう。ここに相互運用性を妨げる隔壁があり、そこで私たちはSOA (好ましくない新しい言葉)を目にしていますが、それでは十分ではなく、私たちは対人関係のレベルでギャップを縮めることも望んでおり、1つの問題だけに 対処することは十分ではありません。

特集コンテンツ一覧

GAE開発の落とし穴

Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します

イベントレポート:「Coqチュートリアル#1」

去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。

Javaの未来についてのNeal Gafter氏とのディスカッション

Choosing Options

Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。

Google Dartのエッセンス:アプリケーションの構築、スナップショット、Isolate

GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式

CSPベースのモデル検査ツール「Process Analysis Toolkit」

本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。

Jenkinsによる継続的インテグレーションのススメ(4) ~CloudBeesでJenkinsをサービスとして使う~

前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。

書籍『抽象によるソフトウェア設計-Alloyではじめる形式手法-』の紹介

Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。

Windows デバイスで開発するタッチユーザーインターフェイス

スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。