April 2013 Archives

■    なぜBPMSではなくWebデータベースを使うのか

クラウド上にあるWebで作ったコンポーネントを利用してサクッと作りたいと言った。その主要なコンポーネントがWebデータベースである。具体的にはサイボウズ社の提供する「kintone」というソフトウエアを推奨している。ただ、そんなことを言うと業務プロセスシステムだから、なぜBPMS(Business Process Management Suite)を使わないのですかと問われる。当然である。業務プロセスを開発するために作られたツールなのだから、それを使えばサクッと作れるでしょうという。

そう簡単に考えないで、よーく吟味してみましょう。まあ、概して高価であるということもあるが、そうでない切り口でみていく。企業の方々は、ERPのバカ高いパッケージと開発費用がトラウマになっているのかどうか分かりませんが、もうその手には乗らないぞということがあって、費用対効果に疑問を抱いているように思います。だから、なかなかBPMSを導入するのが進んでいないようです。

さて、価格に対する抵抗感はさておくにしてもBPMSが浸透していかない理由は、ベンダーもユーザーもまだまだシステム開発ツールという理解があるのではないでしょうか。スクラッチでコード書いていたのでは生産性があがらないので、フローのロジックのところをパターン化してモジュールにして、設定作業化させればいいのだという考え方である。確かに、ツールになれてくると生産性はあがるので効果的だと思うのでしょうが、そのことはユーザにとってのメリットになるのでしょうか。

皮肉っぽくいえば、ベンダーはいくら生産性をあげたからといって、開発費を下げようとする力学は働きませんから、高価なままなので、何だ開発費用はそんなに下がらないじゃないかとなってしまう。ではそれ以外にどんなメリットがあるでしょうか。開発ツールではないと規定したら、何と考えるべきだろうか。このシリーズで言い続けている業務オペレーションのためのツールと考えてみましょう。

BPMSを使って日常業務のオペレーションを想像してみてください。おそらく、使い方としては業務プロセスの進捗を管理してフローを回して最終的にはデータ登録という形になるわけです。プロセスというのは、案件の処理というふうにとらえてもよいので、入ってきた案件をどう処理してその結果はどうなったかを記録するということでもあります。そうしたオペレーションがBPMSはやりやすいのでしょうか。

BPMSは、基本的には自動化を目指しています。つまり、処理フローのロジックを設定しておけば、決められた流れで処理してくれるというスタンスになります。それはユーザが望むことでしょうか。要するに、自動化してくれるとうれしいのかどうかです。IT導入という出発点は確かに自動化の追求です。電子計算機です。それはそれで大いに進んできました。ですから、その領域はほぼやり尽くしているように思えます。

まだ自動化を追求するところがあるのでしょうか。これからのIT導入は単なる自動化ではなくもっと違った目的をもったものになるような気がします。どうも、自動化に向いていない非定型的な業務に焦点があたってきて、そこの領域のIT化がねらいどころになっていると思います。ですから、そこに定型的な処理をもってこようとするBPMSに矛盾を感じるのです。どうもこの辺の違和感があるために使うのを躊躇している。だから、プロセスといっても最終的にはデータ登録になるわけだから、データ登録がやりやすい、どうやってそのデータを記録したのかがわかるような工夫ができるようなWebデータベースを選択しているのである。
 

■    受注設計生産型の開発方式とは

業務システムは、受注設計生産型にマッチしたような開発方式を採用すべきだと言った。ではその開発方式はどのようなものだろうか。お客さんの注文(要求)に対して、そのものズバリのものがないから、ある程度の設計をしてみて、そこでできたものを見てもらいながら、追加・修正を繰り返しながら仕上げていくことである。とてもアジャイル的である。イテレーションとか、タイムボックス、スプリント、あるいはテスト駆動といったようなことを言わなくても、というかよく知らないから、もっとプリミティブに考えている。

まず、お客さんがどんなことをしたいかは、プロセス設計の段階で聞き取りをすることになる。すなわち、プロセスの始点、終点を決めて、その間のアクティビティを書き、プロセス要素表を作成することで大方の要求が見えてくる。そこには、どんな意思決定すなわち、確定するデータは何か、どういう判断をするのかがあり、そこで使われるルールや参照情報、誰が担当して誰が責任を持つのか、何をコントロールするのかといったことが書かれている。

そこでは、まだ確実なものになっていない可能性が高い。人間は紙の上に書いたものだけではいくら想像力をたくましくしても限界がある。ですから、実際に動くものを見せるのが一番早い。それも紙芝居のようなものより、できるだけ実オペレーションに近いものである必要がある。ということは、いくら早くプログラミングできるからといってもコードを書いていたのでは遅いのである。自動プログラミングとかプログラミングファーストとかは業務システム開発にとってはアジャイルではないのである。

実オペレーションのためのプラットフォームで要求をそのままお客さんと一緒に作り込んでしまえればそれにこしたことはないと思いませんか。それには、既にアプリケーションとして確立できていて、設定だけでシステム構築ができるものを使うことになる。ただ、そうは言っても、完全なものはないわけで、やっぱり作り込みがあるはずだと言う反論はあろうかと思います。そうですが程度問題があって、基本的な部分ができていれば良しとする精神が大切です。

よくある作り込みは、ユーザインターフェースとか帳票です。ここにいくと正解はこれですはないわけで、ほとんどが個人の趣味の領域になります。そんなところに注力するのは後まわしにしておけばいいのです。いまや、Webにしておけば何とかなる話です。ちょっとそれる逸れるかもしれませんが、これまでの業務システムが抱えてきた諸問題、例えば、情報連携・共有、システム運用、セキュリティ、資産管理といったところの面倒臭ささはWebとクラウドでかなり改善していると思うのですがいかがでしょうか。

そういう時代です。Webで作ったコンポーネントがクラウド上にたくさんあって、しかも安価に利用できるようになっています。もう何十年も世界中で業務システムを作り続けています。業務システムで必要な機能は、ビジネスモデルが変化していてもそれほど増えていくわけではありません。いまだに同じものをせっせとコーディングするのもおかしいと思いませんか。お客さんと一緒に有り合わせのものですぐに作って、ああじゃないこうじゃないと議論しながらブラッシュアップしていくやり方でいきましょうよ。
  

生産形態と開発メソッド

開発というと、最近ではウオーターフォールなのかアジャイルなのかなんて議論があったりします。どんなメソッドで開発するのかという話です。ただ、あたりまえ前の話として、どうやって作るかというHowは、どんなものを作るかというWhatに依存する。作るものや動かすものの性格によって作り方は違ってくる。

このことは、何もITシステムに限ったことではなく、一般的な製造業も同じというか、そもそも製造業は何を作るのかというプロダクトがあって、その生産のためにどんな生産方式を採るのかということになる。なので、ちょっと寄り道をしますが、生産形態について見ていきましょう。生産形態にはタイミングとか、製品の種類、生産方式などで分類することが一般的です。

受注タイミング :受注生産/見込み生産
製品の種類と量 :多品種少量生産/中量生産/少品種大量生産
生産方式    :個別生産/ロット(バッチ)生産/連続生産

といったところですが、それぞれ全部の組み合わせがあるかというとそうではなく、大体次の6種類になります。
(1) 見込み生産/少品種大量生産/連続生産
(2) 見込み生産/少品種大量生産/ロット(バッチ)生産
(3) 見込み生産/中量生産/ロット(バッチ)生産
(4) 受注生産/中量生産/ロット(バッチ)生産
(5) 受注生産/多品種少量生産/ロット(バッチ)生産
(6) 受注生産/多品種大量生産/個別生産

さて、IT(ソフトウエアやサービスシステム)の場合はどうなるのであろうか。どうも物理的な実体がある一般製造業とは違って、量的な問題はあまりないように思える。つまり、物理的な大きさとか数というのは、コピーもいくらでもできるし、倉庫に在庫として持つこともないからである。そうなると、見込み生産型なのかそれとも受注生産型なのか、それとどういった生産方式になるのかになる。ただし、連続生産というのはないだろうから、個別生産かロット生産かになる。

これらの組み合わせも大体決まっていて、受注生産型は個別生産方式であり、見込み生産型はロット生産方式といってもいいだろう。ロット生産というのは製品ごとにあるまとまった量を作っておくことなので、ITではそんなことはしないと言われそうだが、ある量を販売するためにあらかじめ用意しておくという意味でロット生産と呼んでもいいだろう。

さて、システム開発という大雑把な言い方をした時に、その生産形態はどうなのかと見ると、ソフトウエアとかパッケージはどうも見込み生産/ロット生産と言えそうだし、業務システムは受注生産/個別生産のようだ。特定の会社の業務システムがそのまま他の会社で使えるかというとそうはいかないので個別に作り込むことになる。

では、冒頭に言ったウオーターフォールなのかアジャイルというのは、個別生産に向いているのか、あるいはロット生産に向いているのかという見方にもなりそうだ。どうも、作り手側で製品の仕様を決めて生産するやり方はウオーターフォールが合ってそうだし、お客さんの要求を調整しながら、場合によっては開発や設計行為も入り込みながら作り込むのはアジャイルが良さそうだ。

ここでお気づきかと思いますが、これまでは、受注・個別生産型である業務システムをウオーターフォールで作ってきたことである。この問題点がいまクローズアップされているように思う。ただ、昔にもアジャイルでやればよかったとは言えない。そういった技術もインフラもなかったのだから仕方がなかった。しかし、現代は環境がずいぶんと進歩したので、問題を引きずることから脱却しなくてはいけない。

ですから、従来のやり方では、受注・個別生産型なのに、製造工程に移る段階で要件定義と称してあらかじめ決められた仕様に沿って作る方式である見込み・ロット生産型にしてしまったのである。その結果、一度決めたら最後まで行って後戻りできない羽目に陥っていたのである。これからの業務システム開発は受注設計生産型にマッチした開発方式を採用すべきなのである。
  


■    再び「ぐだぐだ言ってないでプロセスを書けよ、ハゲ」

前回にコードを書かないという話をしました。そして、シリーズの第1章でウェブ系のハッカーたちの間で「肝に命じる」言葉として、「Shut the fuck up and write some code.」というのがあって、その意味する「ぐだぐだ言ってないでコードを書けよ」のコードをプロセスに置き換えて「ぐだぐだ言ってないでプロセスを書けよ」という話を書いた。つまり、プロセスを中心にして業務を見ていこうということなのだから、とやかく言う前にプロセスを書こうぜということである。

このコードの代わりにプロセスとしたというのが前回の議論のポイントなのである。Webサービスとビジネスサービスではサービス粒度が違っていることに注意してください。単一的なものに対して複合的であるとでも言いましょうか、アクティビティレベルなのかプロセスレベルのなのかという言い方になる。つまり、Webサービスはアクティビティレベルが多く、ビジネスサービスはアクティビティの連なりであるプロセスから成り立っている。

ですから、Webサービスでコードを書くというのが、ビジネスサービスでプロセスを書くことに対応するということになる。コードを書くことでアクティビティを生成するのに対し、アクティビティを組み合わせフロー化することでプロセスを生成するということである。例え話でいうと、自動車や家電製品を作るのがWebサービスで、それらを使ったライフスタイルがビジネスサービスと考えてみてください。田舎に住んでいたら自動車は必須ですが、都会では電車を利用するから必要ないといったことになるわけです。

もうおわかりだと思いますが、田舎に住んでいるから田舎暮らしに適した自動車を設計して作りますか。部屋の空いているスペースにぴったり収まるテレビを作りますか。スタイルをデザインして、それに沿って活動するということは、システム製品を作ることが目的ではありませんよね。いかに快適にとか、節約できるとかいったことが目的になります。

さて、「ぐだぐだ言ってないでコードを書けよ」というのは何しろ動くものを作れよということであるから、プロセスを書いたら直ぐに動かさなくてはいけない。逆に言うと、イメージしたビジネスサービスが直ぐに動くようにするためにはどうしたらよいかである。それがシステム開発(システム構築と言ったほうがよいというのは前回書きましたが)となるはずである。設計フェーズで実際にオペレーションするイメージが持てるようにプロセス要素を定義したのはこの流れを意識しているわけです。

従来のように要件定義書やプログラム仕様書ではオペレーションのイメージをわかすことができるでしょうか。コードを書くということはアクティビティレベルのサービスのイメージはわきますが、プロセスレベルのものは難しいでしょう。ですから、設計ではできるだけ業務視野で記述して、そのまま実装できるのが望ましいのです。

設計から直ぐに動かそうとしたらコードを書いてなんていられないので前回に提起したようにコードはやむを得ない場合のみにして極力書かない旨を徹底することだと思います。ということは、自動車や家電に相当するような既成のものとしてあるコンポーネントを利用することです。要求ユーザの前でレゴ細工のように組み上げて見せるようなやり方が必要になるのです。
 

■    コードは書かない、ドキュメントは作らない

さて、ここからは開発ということになります。設計フェーズではプロセスを構成する要素を定義し、「プロセス要素表」というものを作成します。開発ではそれに従って実装していきます。具体的なやり方に入る前にすこし考え方のようなことについて議論していきましょう。開発というと要件定義から起こされたプログラム仕様書に従ってコーディングをするというのが一般的ですが、そこを考え直そうではないかというのが趣旨です。

ですから、Webサービスとも違うわけです。Webサービスは明らかにコードを書いてサービスを作っていきます。もちろん、フレームワークやモジュールを利用したり、マッシュアップといった組み合わせもありますが、基本的にはコーディングが開発作業の重要な位置を占めているわけです。そういったやり方だと開発という言葉が合うのですが、コードを書かないとなると開発というのもおかしいかもしれません。

では、コードを書かないのならどうやってシステムを作っていくのかということになります。ざっくり言うと既成のソフトウエアを組み合わせてシステムを作るということです。家を建てるのにプレハブ工法というのがありますがそんなイメージになります。ですから、開発という言葉はそぐわないですね。家を開発するとは言いませんから。開発ではなく構築と言ったほうがぴったりします。従って、業務システムの場合はシステム開発とはいわずにシステム構築と呼ぶことにします。

逆に、業務システムに使われるソフトウエアは開発することになります。ある機能を実現するために開発されたソフトウエアを組み合わせて組み上がったものが業務システムとなっていくわけです。ノンコーディングで構築されるというのはこういうことです。ただ、全部が全部コードレスかというと現実には多少のプログラミングをする場合ももちろんあります。本当に特殊な機能の盛り込みとかインターフェースといった部分です。

また、既成のソフトウエアは特定の業務システム向けの仕様で作ってあるわけではありませんから、ぴったりフィットしない場合や不足機能があったりします。そんなときについアドオンとかカスタマイズということをしたくなります。それは極力しない方向で考えます。不充分なところや不足する点は人間がカバーしてもよいという割り切りをします。何でもかんでもITで自動化するというのはやめたほうがよいと思います。

例えば、業務フロー進行を自動化しようとすると分岐の嵐になったり頻繁な差し戻しがおきて却って複雑してしまうということがあります。あるいは、トラブルがあった時の異常の発見、復旧に時間がかかることもしばしばおきます。人間の目で管理できる限界を超えてしまっているわけです。しかしある程度人間がシステムに入り込んでおけば防ぐことが可能です。

それと、業務システム構築の段階でプログラミングすればするほどバグの発生という危険が待っています。よくERPなんかでもテストの時にバグが発見されて修正に追われるのはアドオン部分だと言われています。その点、既成のソフトウエアを利用すればその点は非常に楽です。きちっとテストされバグフィックスされたものが納入されるわけですから安心して使えます。だから、余計な手をあとから加えないでそのまま使えばよいのです。

今や、そうしたソフトウエアがクラウド上に多く置かれるようになったのでそれを利用しない手はありません。このクラウドソフトを見てもお分かりのようにドキュメントはありませんよね。多くは、ソフトウエアのヘルプを開けば分かるようになっています。昔のように分厚いドキュメントを書くのだが、いつも間にかメンテできなくなり誰も読まなくなり、結局はコードを書いた人に聞くなんて破目に陥ることもなくなっています。"コードは書かない、ドキュメントは作らない"という方向で行きたいものです。