BPMやワークフローについてのメモ

組織内の業務フローをシステム化するやり方に、ワークフローシステムとか、BPMといったものがある。いくつか調べたので、メモ代わりに残したい。権威でも熟練の実践者でもないので、おそらく間違いや、抜け漏れがあると思われる。

過去の仕事上、内部の人が使うツールというのは幾つか作ってきたけれど、業務システムをガッツリやったことはないので、ワークフローとかBPMとかって言われると、知識の不足は否めない。UCD方面の手法はインタビューや観察などは分かるのだけど、モデリングはあまりわからない。BAとUCDと業務モデリングはとっても近い分野だと思うのだけれど、流派が分かれているのか混ぜるな危険なのか、これという統一的な話を聞かない気がする。

業務モデリングの前提として必要なこと - アカウント管理

まず、人事情報が名寄せされ、しっかり確立している必要がある。某ベンダーさんのコンサルの人がここに苦労した案件があったと教えてくれた。そもそも社内にどういう人がいて、どういう職責なのか、ということが一意に分からないと、その上の業務モデリングやフローのモデリングにバリエーションが出過ぎて難しい。人の出入りの管理というのは意外と難しく、各個人や組織や制度上にさまざまな都合があり、ソフトなフローがあるものだったりするのだろうというのは想像に難くない。

昨年行ったOpenIDのカンファレンスで、基本的に人事DB(人事台帳)と業務執行上のアカウント管理のためのDBというのは別にしている、というのが各発表者の前提にあった。これは上記のような人事にまつわる複雑な処理と、アカウントというはっきりした決めが必要なものとは別に管理した方がいい、ということなのだろう。

人事台帳と、アカウント台帳は別にしておく、というのが基本的なプラクティスのようだ。
アカウント台帳は外部提供用の本番データで、そこに至る様々なデータ整備や調整の流れが人事台帳やそれにまつわる仕事、と考えておくと、すっきりするかもしれない。とりあえずそう理解しておく。

業務モデリングの実装

次に、何かしら分析/計画/実装した業務プロセスが、どういうプラットフォームで動くのかを考えることが重要だろう。ソフトウェアサービスはリリースされて初めて価値を生む。そこで初めてフィードバックされる。なので、アーキテクチャを決め、リリースしたり利用されたりという基盤を作らなければ、いろんな計画の出口が確保できなくなる。

大きく分けると以下のような流れがあるようだ。

SOA+BPM : サーバー間の相互接続とオープン化から発生したもの
ワークフロー : 稟議や承認などの業務フローを紙から移行するために発生したもの
情報共有基盤 : Wikiやメッセージングを中心に記録機能や承認機能を作ったもの

使っていないので間違っているのかもしれない。

SOA+BPM : サーバー間の相互接続とオープン化から発生したもの

業務のコンピュータ処理は、コンピュータが民生用に使われるようになった頃から始まっている。90年代には汎用機/ミニコン/オフコンからオープン化の流れがあり、PCの普及があり、2000年問題というのもあって、業務システムを載せかえる案件がたくさんあった時代だ。そこでHTML/XMLやhttp(Web)/smtp(メール)なんかが発明されたり普及したりした。

SOA(サービス指向アーキテクチャ)は、エンタープライズの基盤をどう作るか、という話で、XMLと主にhttpが普及したことで、それをデータとプロトコルとして採用する前提で、サーバ感のプロトコルを整備し、異なるベンダーや基盤ソフトウェアがあっても通信できる、というものを目指したものだとおもう。Java系の実装が多い気がする。業務プロセスというのは、プログラミングやソフトウェア設計についての知識があまりないビジネス系の人が企画することが多く、利用するのも予算を握るのも非エンジニアなので、そういう人向けの中間言語があるといい。そうして生まれたのが、BPM(ビジネスプロセスモデリング)という形式のようだ。UMLと思想的に似ているが、よりビジネスの人が使うことを念頭に作られた図法らしい。

図法だけだとリリースできないので、BPM2.0では、IBM/SAP/Oracleが参加して仕様が改訂され、これら３社を始めとして、「作れば動く」により近づいた製品群というのが出ているようだ。BPMはオープンな仕様なので、多くの会社が参入しているらしい。

一方で、BPMというのは本当に非プログラマに理解されるのか？という課題はありそうだ。現在は、「書いてもらわなくてもいいけど、共通の図表として間に置いて、お互いに間違いを探しやすくする」というところに落ち着いているのではないかと想像される。モデリングする人と実装する人と業務する人は別だ。このあたりはUMLに似ているんじゃなかろうか。図に記せば伝わる、という想像は割と多くの人が試してみて失敗するやり方だと思う。記法があることは、情報の整理や議論に非常に助かるが、一緒にやっていない人に説明するためには、説明と記法はセットにすべき、という事なのだろう。

ワークフロー : 稟議や承認などの業務フローを紙から移行するために発生したもの

BPMが業務システム全体のモデリングや設計に関するものだったのにたいして、仕事のフローを電子化する、というより喫緊のニーズに対応するのがワークフローシステムだろう。Webサーバの上に構築されるものや、クラウド上のサービスが多数ある。

基本的には業務上で人と人が関わる作業の受け渡しを見える化したり、記録したり、できれば分析してよりよくしたい、という目的で使われる。行政が規定した形式の文書だとか、各種の社内申請書など、紙とハンコベースで担当間や会社間で取り交わされてきたものを、電子化する、という流れだと思われる。BPMに比べると、既存システムの活用や移行というニーズより、一つのツールでまとめる事で全員にとっての利便性をあげていこう、という傾向が強いと思われる。

BPMに比べると、より業務部門が自ら業務をマネジメントするというニーズに近いため、非エンジニア向けに作られているものが多そうだ。その分、全体としてちぐはぐなフローや、機能不全のフローが大量生産されて収拾がつかなくなるリスクが懸念される部分もある。

LeanKit Kanban は、アジャイル等を勉強された方にはとても有名な David J. Anderson の Kanban をベースにしたワークフローシステムだ。業務フローを見える化してカンバンにし、WIP(仕掛かり)の数を制御することで全体の最適を目指す。

情報共有基盤 : Wikiやメッセージングを中心に記録機能や承認機能を作ったもの

業務の電子化として最初に思いつくのは、Excelで帳票を作って電子メールで送りあうことだろう。ソフトウェアエンジニアの間ではExcelの帳票というのは素人によって作られたカオスから業務システムへの移行を行う悪夢を連想させたりする。...というくらい、PCと電子メールが標準装備された現在のオフィスでは第一の選択肢としてExcelが使われる。

電子メールの量が増えすぎるという課題はよく指摘され、代替として、グループウェア、SNS(ソーシャルネットワーキングサービス)などが提案されてきた。メールの課題は関連する文書をひとつの場所にためておく事ができないことなので、その部分はファイルストレージや電子掲示板を拡張したようなフォーラムを提供しているのが、グループウェアや社内SNSだ。さらに、業務フローに則った処理を提供しているものがある。

知り合いの会社は、電子メールをやめて、自社が販売している社内SNSを導入し、業務上のデータもそこに入れるようにしたと言っていた。非エンジニアについてとっつきやすいのは移行上非常に重要だろう。

だれが業務フローを分析・設計するのか

業務を行う人が困らないようにするためにフローをシステム化するのだが、じゃあそれは一体誰が分析できるのか/やるのかが問題になる。ここでは関連しそうなロールをあげてみる。

情報システム部門の人 : 組織内の情報システムの開発管理運用を取りまとめる部門の人。社内の窓口になったり、予算を取るのはこの部門の人たちなので、ここの人員の数やスキルは、鍵になるだろう。
ITアーキテクト : そういうのが専門の人たちがおり、経営層向けの資料から、実装上の考慮、運用にいたるまで、設計を手伝ってくれる気がする。
業務をやっている人 : 業務をやっている人自身が手直ししていければ仕組みを業務の変化に対して適応させていく事ができる。業務は分担されているので、全体を見ている人と業務をやっている人は別かもしれない。
開発者 : どちらの部門に属しているかは様々だが開発者は実装を最もよく知っているはずだ。プログラミングは好きだけど、コミュニケーションはあまり慣れてないとか、社内の"政治"のようなものを見せられるのは辛いとか、利用者のクレームが直接届くと仕事にならない、ということはありそうだ。
要件定義の担当 : 要件定義そのものなので、担当がきちんと業務モデリングできるとよいのだろう。利用の現場に行ってインタビューしたり、観察をする作業は面倒だがなるべくやった方がよいように思う。
プロダクトオーナー : 要件定義の担当とほぼ同じ。規模によっては自身で要件定義の詳細に立ち入るべきだろう。少なくともパイロットは自分でやるべきな気がする。
ビジネスアナリスト : 業務分析の専門家として働いている人はほとんどいないと思われるが、業務とシステムを理解し、業務の分析と説明、フィードバックを受けて改善していく、というところは誰かがやらないといけないだろう。