読者です 読者をやめる 読者になる 読者になる

超高速開発コミュニティセミナー「ワークフロー」討論会の様子

さった1月23日に開催された、超高速開発コミュニティのセミナー「ワークフロー特集」のディスカッションが大いに盛り上がりましたので、その報告を行います。

f:id:ynie:20150126103038j:plain

コミュニティ主催セミナーで私が意識していることは、製品紹介ではなく、参加者(会場)と一緒になって課題の解決を議論するということです。会社という立場を超えて、参加者が意見を出し合い、共に考える場はとても貴重です。

若手が参加する技術系コミュニティとは違い、超高速開発コミュニティは年齢層が高いという特徴があります。日本では、ある程度の年齢層が集まる会では議論が活発化しないのではないか?という懸念を持っている方もいらっしゃるかと思います。しかし今回は、沈黙タイムがほとんどないという、まるでテレビ番組の討論会のような質疑応答が行われました。参加ならびに発表いただいた皆様に、心より感謝申し上げます。個人的には、企画してよかったと嬉しく思っています。

さて当日の質疑応答はおおむね、次のようなものでした。各社の製品紹介は省略して、エッセンスだけをメモに残しました。


Q. 組織変更が発生した場合のワークフロー設定、年度をまたいでフローが変わるという点について、どのように運用すればいいか。

A. 今回、発表いただいた4製品とも、ワークフローの世代管理は実現できていない。しかし重要なテーマであることは認識している。参加者で、この点が非常に困っているという方はまだ少なかったが、会場全体で、このような問題があるということを共有できた。

Q. "ワークフロー" と "BPM" の違いは何か。

A. 稟議、起案、決裁処理がワークフローと認識されることが多い。BPMとは、判断処理が多く含まれる印象か。一方で、定義部分がBPMで、その定義によって開始されたものがワークフローという考え方もある。(オブジェクト指向でいうクラス定義がBPMで、インスタンスがワークフローと捉えたもの。)

営業トークという視点では、ワークフローはグループウェアの延長で、BPMはより高尚(高い製品)という説明方法もある。ワークフローという言葉の方が、現場の問題と受け止めてもらいやすいかも知れない。

BPMの"M"は、ManagementかModelingか、という違いがある。

粒度の違い、という視点もある。ワークフローは個々のタスクで、ビジネスプロセスは全体を俯瞰するようなもの。

BPMと、BPMSという違いもある。"S"はSystem。フローとプロセスは違う。フローは実現するための仕組みで、システムとしてはBPMSという視点で設計する。

Q. 日本の基幹系は「最新の」データを保持するものが一般的だが、データの変更履歴をもっているものが少ない。データの履歴管理とワークフローをつなげるようなシステムはできないのか。データに誤りがあるとわかったとき、それを追える仕組みが必要だが、データの更新作業とワークフローを進めることを表裏一体な行為とすれば、ワークフローの承認のタイミングでその時点のデータを保持できていると良い。(データを戻すということではない。)

A. 履歴管理には操作ログ取得と、データ保持という二つの観点がある。いずれの製品もログ取得についてはできている。ログを追うことでデータ誤りの問題点をみつけることは可能だが、システム管理者の操作が必要であり、一般利用者が使いやすいか、ということではまだ課題があるだろう。

ワークフローを進める前と後で、データのここがこう変わったという変更点が赤で表示される、というようなユーザーインタフェースがあるとよいだろうか。

ワークフローは、流れを管理する、ということの先に、データの変更履歴を管理する、ということが求められてくる?

ワークフローは決裁、承認のステータス管理という認識であった。これまでの業務でも、フラグによって管理することは一般的。(受注承認フラグが立っていれば次の業務が行えるなど)ワークフローとは、承認行為を外部化するだけでもよいのではないか。

Q. (ワークフローが承認行為の外部化という位置づけであれば)現行システムはそのままに、ワークフロー機能を追加することはできるのか。

A. ワークフロー側に、Webサービスのインタフェースを持っているものがある。外部システムから(APIを)呼び出してもらい、ワークフロー製品側でステータスを管理する。

既存システムはそのままに、新たに「関所」プログラムを開発し、データ更新時にはこの関所をとおるというようにすればワークフローとの連携も容易になると考えられる。

ユーザーからすると、既存システムの画面をそのまま使えるという前提で、これまでと同じ操作をするだけで(新しい)ワークフローと連携できればいいというのが希望。しかし既存システムがまったく変更なし、にはならないだろう。データ層での連携ならいくらでも可能だが、既存システムへの影響は大きそう。アプリケーション層での連携の方が整合性はとりやすいが、既存システム側にも連携のための拡張が必要になることもある。

現行システムと新システム(ワークフロー付き)を用意し、利用者は現行システムの画面を使い続ける。現行システムの入力が新システムに自動転記されるようなことはできないか? 難しいのではないだろうか。

Q. 業務のクラウド化(SaaS化)について。基幹業務のワークフローをクラウドで動作させることについて、どう考えるか。

A. クラウド環境で動作させることは(いずれの製品もアプローチの差はあるものの)可能。アプリケーションがセキュアかどうかも、個々の製品ベンダーがそれぞれアピールしている。セキュリティについてはマルチテナント型か、プライベートクラウド型かという視点もある。あとはお客様の心理的抵抗感の温度差と、成功事例が鍵になるだろう。

社内システムと、クラウドに設置したワークフローとの連携という形でも、別の課題があるのではないか。VPNをはることができない、社内インフラを変えられないというところもあるか?

クラウド利用では個人情報の管理が適切かどうかも問われる。国内にサーバがあることが必須要件。これらを加味することも必要。

(会場の反応では、現時点でクラウドを使っているのは少数派だった。)

Q. ワークフローでは、既読レベルの承認と、会計的に監査が問われるレベルなど、重要度が異なるものがある。承認者が(ワークフローの)重要度を知るためのアイデアはないか。例えば色をつけるなど。

A. 色づけも含め、各社が工夫すべきところと認識。これからの製品開発のヒントになった。フローの存在は認識したが、今は決められないので既読状態にする、というようなアプローチがあってもいいかも知れない。

Q. 各製品の多言語対応について教えてほしい。

A. 各社とも多言語対応はクリアしている。

Q. オフィスにいないときの承認処理をどのようにサポートしているか。

A. スマートフォン利用というのが現代風のアプローチだが、メール承認(コマンドメールという概念)も有効ではないか。承認すべきワークフローがメールで通知され、返信すると承認など。業務画面を操作せず、メールソフトだけでワークフローを進めたいという利用者もいる。いかに軽い操作で対応できるか、という視点がほしい。しかしスパムメール問題など、メールだけで業務を進めるのは困難になりつつある。

Q. 一般的なグループウェアにもワークフロー機能はついているものが多い。各社の製品は、それとどこが異なるのか。

A. グループウェアに付属しているワークフローは、いわゆる「はんこ」機能(承認機能)であることが多い。しかし超高速開発ツールでのワークフローとは、業務機能との連携のための自由度が高いことが特徴である。さらにBPMという観点でシステム全体を捉えることができる。

次回のセミナー

超高速開発コミュニティでは毎月一回、何らかのセミナーを行っています。次回は2月20日(金)です。DBCの渡辺幸三氏を中心に、いよいよ「超高速開発での設計」を議論します。これも熱くなるテーマですので、興味のある方は是非、参加してください。

http://www.x-rad.jp/

Wagby開発スタッフ募集中です!