メイン

パラダイムシフトの正体 アーカイブ

2009年4月27日

パラダイムシフトの正体(1)

先日のBPM協会コンポーネント部会は、季節がらなのかニューフェースが4人も出席して、新旧メンバーによるBPMへの思いを話しあった。

そこで話をしながら、あるいはその後のディスカッションで改めて、そうだ今唱えている「プロセス志向」はすごいパラダイムシフトを起こさせるトリガーになると意識させられた。

単にプロセス志向で業務システムを開発しましょうということでは全くないのである。プロセスを中心においた途端にその周辺のもろもろのことについて、従来とぜんぜん違う考え方をとらないとやっていけなくなる。

例えば、プロセス志向におけるデータベース設計はどうするのか、画面設計はどうするのだ、そもそも従来と画面のイメージが変わるかもしれないとか、開発プロジェクトの構成も進め方も違うだろうというようなことである。

まずは、影響を与える領域はどんなところがあるのだろうか。

1)要求分析・定義
2)プロセス設計・I/O設計・データベース設計
3)開発・製造
4)システム構築プロジェクト
5)保守・運用
6)要求人材・スキルセット
7)ユーザとベンダーの関係・収益モデル

こんなところが浮かんできます。おそらく、上記の全領域に少なからずのインパクトを与え、従来の考え方と大きく変わっていくのではないかと思っている。

これから、そこのあたりを少し詳しく見ていきましょう。ただし、他にもシステム構成とかクラウド・SaaSなどのインフラとかもあるかもしれませんが、それはプロセス志向に限った事ではないので言及しません。

どうも見わたしたところプロセス志向のための開発方法論がまだないと思うので、みなさんよく考えてほしいのだが、とりあえず我流であるが自分が思うことを書いていくことにする。
 

2009年5月 4日

パラダイムシフトの正体(2)~要求分析編~

プロセス志向でインパクトを与える領域として、ますは要求分析・定義について考えてみましょう。

そもそもこの領域は、日本においてはあまり重要視されていないように見受けられます。要求工学というような言われ方でアメリカなどでは盛んですが、わが国ではここをちゃんとやっているプロジェクトは少ないように思います。

経営戦略から事業オペレーションへ落とし、それを執行するためのITはどうあるべきかというアプローチができていないということです。これまでは、パッケージをまずもってきてそれに当て込むようなやり方でIT導入が行なわれて、しかもそれが経営戦略に合っているかというところまでいかずに、とにかくシステムを入れるんだというふうになっています。

なぜそうなっているかというと、ひとつは経営者のITへの理解と期待が希薄であるということ、もうひとつは、実際に経営戦略や事業オペレーションをITが実現できていないことにあると思います。すなわち、使う方と作るほうがお互いに信用していなくて、意思疎通できていないことにあります。それを、相思相愛の関係にもっていってこそ投資対効果もでるというものです。

プロセス志向というのは、業務プロセスが経営戦略から事業オペレーションにもっていくための重要な手段であると位置づけています。ですから、マネジメントにあなたのやりたいことをこの業務プロセスを使って実現してくださいという訴求ができるようになるのです。

どこにどのくらいの速さで行きたいかを決めてください、それに従ってカーナビ付きの車を運転してその目的地に行ってくださいというのが、簡単に言えば、プロセス志向におけるシステムの役割で、その車に相当するのが業務プロセスなのです。

プロセス志向以前は、システムは事業オペレーションの結果を登録するためのものであって、いささか飛躍するが「死体解剖」でしかなかったのです。良かったか悪かったかがわかっても、もう過去のことだから手の打ちようがないのである。ですからそれを「生体ドック」に変えていかなくてはなりません。いまどこが悪いのか、その程度はどのくらいなのか、どんな処方をしたらいいのかが分かることが望まれています。

そのためには、業務プロセスを可視化し、その動きがモニターできることが必須なのです。ですから、みなさんお気づきだと思いますが、プロセスを作って終わりではなく、それを自在にそして効率的に動かしてみて初めてプロセス志向といえるわけです。

逆に言えば、そうしたことができれば、マネジメントもITの有効性を認めてくれるはずで、相思相愛の関係も生まれてくると思います。
 


2009年5月12日

パラダイムシフトの正体(3)~設計編~

今回は、プロセス設計・I/O設計・データベース設計について考えてみましょう。要するに設計方法が従来と変わるのかどうかということです。技術的な詳細については語るスキルもないのでここではコンセプチャルな面から捉えていきます。

まず重要なのは、“画面・帳票設計から入るな”ということです。これはけっこう象徴的なことで、従来からやられているのは、画面・帳票設計や業務フロー、データフロー設計といった外部設計があり、そしてプログラム仕様を作る内部設計といったやりかたです。(この外部と内部の設計という考え方がよく分からないのだが)

プロセス志向はあくまでプロセス中心でみていくわけで、プロセスありきから入っていきます。ですから、I/Oもプロセスが機能するためにどうあるべきかが問われてきます。データを登録するためにどんな画面が必要かという見方ではないのです。

もちろん、プロセスを回すためには、データを入力することがトリガーにはなるのですが、あくまで主体はプロセスで画面や帳票の存在意義は相対的に低くなってきます。

プロセスを回すためには、そのプロセスの構成要素であるアクティビティ(あるいはタスク)での処理の仕方がやりやすい、あるいは早くできるなどを重視した設計になるわけです。そうなると、従来型の画面では限界があるのがわかると思います。より自然な仕事のやりかたに近づけたいのです。

今はここのところがWebで実現できるようになったおかげで、単にデータを登録する画面ではなく、個人あるいはグループでコミュニケーションをとりながら処理(意思決定)を行なうことができる場が提供されるようになったのです。こうしたやり方は通常の仕事の進め方なわけで、ITがあろうとなかろうと行なわれていたことです。

昔はだれかの机のまわりに集まってワイワイガヤガヤやりながら、場合によっては電話やFAXを使って仕事をしていたわけです。今は電子メールが大きなウエイトを占めるようになり、隣に座っているひとともメールで会話するなんてことにもなっています。

このような仕事のやり方をネット上の共有的な空間でやれば、遠くの人も参加できるし、仕事がどう進んでいるかが見えるようになります。そうした時の画面と帳票はどうあるべきでしょうか。

まずは情報伝達のためだけの帳票は不要になると思いませんか。それと、少なくとも一人で画面に向かって作業して、それが終わったのでメールしてあるいは紙を流して承認を依頼するようなことは自然ではないように思えるのですがいかがでしょうか。

さて、次にデータベースの設計ですが、この領域でもプロセス志向だと変わるように思います。それを考えるときに、「データ志向」との対比の中でみるとわかりやすいかもしれません。

DOA(Data Oriented Approach)の場合のデータベース設計は、まずは画面や帳票からデータを抽出します。大ざっぱに言うとそこからリソース系のデータとイベント系のデータに分け、それぞれにリレーションをはり、ER図を書くということを行ないます。

ただ、これだと既存のシステムがベースですから、基本的にIT化の範囲で設計するということになり、非システム化領域をどうするのかという課題が残ります。また、イベントデータを時系列で並べるとプロセスになるかもしれませんが、やはりそれではフロー図になれた人にとってはわかりずらさは残ります。

ですから、今言ったようにデータ志向はどうしても画面・帳票主体になってしまい、プロセスの意識が薄いままであり、ビジネスの実相がつかみずらくなります。そういったことでプロセス志向のほうがユーザにとってわかりやすいものになっているのだと思います。

さて、そのプロセス志向におけるデータベース設計はどうなるのでしょうか。プロセスの目的と構造を考えてみましょう。そもそもそのプロセスが存在するのは何のためでしょうか。そのプロセスで処理した結果をビジネスの成果として蓄積することです。その成果はほとんどの場合「データ」として格納されます。

データには、イベントデータとリソースデータの2種類がありますが、まさしくイベントデータはこうして生成されます。リソースデータ(マスタデータ)の生成も、同じようにプロセスを経ることには変わりありませんが、それはデータ管理のためのプロセスです。

ですから、設計という観点から言うと、マスタは、プロセスとは離して、独自に設計した方が言いように思います。マスタというのはその会社の活動のもととなるリソースですから、もちろん様々なプロセスにも使われるし、戦略的な意味も込められる。それは、最初にきちんと分析して設計しておくことが大事であると考えています。

話はイベントデータに戻ると、プロセス志向だとデータをプロセスごとにもつのかという問題が出てきます。それだと、データの重複や管理の煩雑さがおこると言われそうです。

しかし、重要なのは、“プロセスの正規化”をきちんと行なうということで、重複するプロセス、似て非なるプロセス、標準化されないプロセスなどを排除することなのです。そうすれば、分散してデータをもってもかまわないし、必要に応じて仮想化で統合すればいいのです。こうした考え方に依拠したデータベース設計方法論が望まれるのだが、これをだれか作ってくれないだろうか。
 

2009年5月16日

パラダイムシフトの正体(4)~開発編~

さて、いよいよ開発・製造という段階のことになります。プロセス志向という場合、少し拡張して考えた方がいいと思います。すなわち、単にあるがままのプロセスを作っていけばいいというものではないわけで、前回にプロセスの正規化ということを言ったと思いますが、ある程度型にはまったもものにする、いわゆるパターン化をしましょうということです。

そのために必要なのは、「シンプルで一貫化されたきれいなプロセス」であることは何度も繰り返して言っていることですが、そのようなパターン化ができれば、いちいちコードを書く必要がなくなるということが重要なのです。最初からフレームワーク化しておけばいいからなのです。

ただし、このシンプルなプロセスは、パターン化できるレベルの話ですから、そのもっと下のレベルではあいまいなプロセスがあることも何回も言っていますが、そのレベルではゆるくして“場”を与えるようにするだけなのです。そこでは、仕事の流れをいちいちコードで記述するのではなく、情報共有させ、人が動きをつくるようにしておけばよいのです。

ここがプロセス志向の開発に及ぼすインパクトです。ユーザと対峙する開発プロジェクトでは原則コードを書かないことが大きな意味を持つのです。

少々脱線しますが、そもそも“業務システム開発”と言ったとたん、ええーとなってしまいます。こういう場合いったい何を開発するのでしょうか。“業務プロセス”を開発するのでしょうか、“ITシステム”を開発するのでしょうか。

開発というのは何もないところから新たなものを作ることだから、今までなかった新業務プロセスを作るということなのだろうか、もしそうなら、ITは関係ないはずです。ですから、システム開発プロジェクトでやることではないのです。

ではITシステムを開発するのでしょうか。それだったら、逆にどうしてそんなプロジェクトにユーザが入らなくてはいけないのでしょうか。それは、IT側で勝手にやればいいと言われてしまいます。だから、“開発”というのはそぐわない言葉なのです。

問題は、言葉だけのことではなく、実際のプロジェクトで“開発”をしてしまうことにあるのです。だから、思ったものと違うとか、それじゃだめだから変えてとか、最悪デスマーチとなるわけです。

もっと容易に“システム構築”ができることをめざすべきです。以前にも言ったことだが、家を建築するとは言うが開発するとは言いませんよね。家を建てるときにトイレを開発したりしませんよね。

あえて開発と言えば、部屋の形とか生活スタイルのところです。それは、むしろ好きなようにアレンジするといった方があっているような気がします。だから、プロセス志向の開発は、開発するのではなく構築あるいはアレンジするということになります。

そのためには、予め部品やフレームワークあるいはアダプターを用意しておき、それをユーザと顔をつき合わせて組み合わせてしまう工法が求められるのです。

もちろん、部品やフレームワーク、アダプターはコードを書きます。そこを開発プロジェクト段階ではなく、その前に製造しておくことが必要です。

こうすれば、いまのIT業界よりましな建築業と同じような業種になってくると思うのですがいかがでしょうか。
 

2009年5月20日

パラダイムシフトの正体(5)~プロジェクト~

プロセス志向はシステム開発プロジェクトのすすめ方にも影響を与えます。まず大きな観点として、プロジェクト規模という側面と開発工程という側面から見てみましょう。

最初のプロジェクト規模では、これまではかなり広い範囲を一気に導入するビックバン方式がとられる場合も少なくはありませんでした。ERPの導入などはこの方式の方が、無駄なインターフェースを作らなくてもいいとか、データ移行と整合性の維持が容易といった理由からよく行なわれています。

ただ、これだと非常に多人数のプロジェクトとなり。そのマネジメントが大変でそこの調整コストが甚大となってしまいます。その点、プロセス志向では、部分的、段階的導入がやりやすくなると考えられます。

プロセス志向というのは、プロセスがシステムの骨格を形成するということだから、広義の解釈ではSOAという概念の上に成り立っていると言えます。このSOAの考え方は、一度に全部のサービスを一斉に動かさなくてもよく、しかもサービスの挿げ替えが可能ということですので、ビックバンではない導入方式がとれるというわけです。

一方、開発工程というところを考えてみると、従来のウオーターフォール型の開発は減ってきたとはいえまだまだ行なわれているのではないでしょうか。とくに大規模になればなるほどこの方式になります。

このウオーターフォールというのは、最終的にはシステム化要件からきちんとプログラム仕様書を起こし、それに基づいてコーディングするというのが前提ですから、前回の開発編で述べたようにコードを書かないシステム構築になっていった場合は、おのずと限界があると思います。

ですから、プロセス志向のプロジェクトでは、ユーザ要求から、それを実現するためのプロセスを設計し、コンポーネントを組みたてて実装してしまうわけですから、テクニカルスペシャリストというより、業務をよく知った人が少人数で作り上げてしまうという形態がとれるのです。

実際には、ユーザのひととFace to Faceでテンプレートを見せながら、ああじゃないこうじゃないと言いながら、組み上げるイメージです。セル生産やイテレーションの要素が入ったものになります。そうしたアジャイル的なシステム構築となるはずです。

そうなると、プロジェクトメンバーで必要な人材は、ユーザの人たちとプロセスをつくっていくビジネスプロセスデザイナー(ビジネスアナリスト)、システム構成を考え、セキュリティや運用設計ができるITアーキテクト、そしてできたらデータ管理をするデータアドミニストレーターがいれば、プロジェクトが回せることができます。

そして、この構築段階のプロジェクトでは登場しませんが、部品やフレームワーク、アダプターを予め作っておくクリエータの存在も重要です。これだけ少数精鋭にしておけば、非常に短い構築期間でしかも質の高いシステムを作ることができます。

こうして、プロセス志向は、ウーターフォール型開発から少数精鋭によるアジャイル的な開発への移行を促すのです。では、従来のコーダーはどうなるのでしょうか。これについては、人材編で書いていきます。
 

2009年6月 8日

パラダイムシフトの正体(6)~運用編~

なぜプロセス志向が保守とか運用に影響を及ぼすのかを考えてみましょう。一見変化がないように見える領域ですが、実は大きな変化というか、変革をもたらすのです。というより、ここが非常に重要な意味を持つようになってきます。システムを作ることより、それを保守し、運用することのウエイトが相対的に高くなってくるのです。

プロセス志向では、業務プロセスを効率的に動かしてこそ事業に貢献できるということを重要視しています。オペレーションエクセレンスが主要目標になります。それは一時的ではなく、継続的な営みでもあり、不断のブラッシュアップが欠かせません。

こうしたパラダイムに適応した保守・運用とは一体どういうことになるのでしょうか。従来の保守・運用管理はシステムがダウンしない可用性や安定性を保持し、正しくデータを更新することに重きが置かれていました。いわば、ちゃんと決算ができることを担保することです。

ところがプロセス志向では、もちろん今のことは大事であることは言うまでもないのですが、それに輪を掛けて業務プロセスの稼動状況を把握し、適正にオペレーションできているかが大事になります。そのために、BPMSにはプロセスの制御や監視の機能が装備されています。

大事なのは、その機能を有効に使うには、“だれがどこに責任をもってオペレーションしている”かを明確にする必要があるということです。いままでだと、どちらかというとシステム側の稼動についての責任という見方でしたが、これからは、ビジネス側のプロセスオペレーションの責任が問われていくようになります。

実際にそうしなければ意味がありません。だから、基幹業務ではアウトソーシングなんてできないはずで、しっかりと自分たちの手でControl&Operation をしなくてはいけません。
 


2009年6月12日

パラダイムシフトの正体(7)~人材編~

ここに、「ITスキル標準 V3 2008」がある。これを参照しながら、プロセス志向における必要人材やスキルセットを考えていきましょう。

プロセス志向と言った場合、まず浮かぶのはプロセス設計のところだと思います。ビジネス要求を解析してそれを業務プロスに落とし込むところです。そこの役割を担うのはITSSではどのスキル標準なのでしょうか。

基本戦略系のコンサルタントでしょうか。それともソリューション系のITアーキテクトあるいはアプリケーションスペシャリストでしょうか。どうもいずれもちょっと違うように思います。ということは、業務プロセスを設計する人材のスキルセットがないということになります。

経営とITの融合とか言っていてもそこの橋渡しをする人材を定義していないのです。先日もこのITSSに実際に携わっているひとと話したときも、ここが抜け落ちていることを認めていました。

これからはビジネスアナリストとかビジネスプロセスデザイナーといった、名前はともかくとして、そうした役回りの人材を置くことが非常に重要になってきます。経営戦略や事業実行方針をちゃんと理解し、それをITで実装するところをマネジメントできる人たちである。

さて、先回のプロジェクト編でも書いたように、プロセス志向では、少数精鋭で素早くプロジェクトを回していくようになるわけで、そうなると、必然的に多能化ということは避けられないと思います。ですから、ITSSにあげられているような細分化したスキルではなく、もう少し広い範囲の能力が要求されてきます。

そして、大きくビジネスエンジニアとテクニカルエンジニアの2極分化と相互融和が図られるものと推測しています。すなわち、ビジネスの要求をきちんと理解し、その業務プロセスをどう実装するのか、どうオペレーションしたらいいのかを的確にユーザに提供できる人材とビジネスを俊敏かつ効率的に回すための仕組みに必要な機能を設計し、コーディングできる人材である。さらに、この異質の人材同士でコミュニケーションが取れることも必須である。

ITSSもそうですが、各企業のなかでもこうした必要人材の配置を急ぐ必要があると思います。ただし、そうはいってもという事がもちろんありますので時間がかかるかもしれません。さらに、こうしたスキル価値が変化するわけですから、従来のように仕様書に基づいてコードを書いていた人たちはどうなるのかという問題があります。

きれいごとで言うと、ビジネス寄りにいくか、クリエーターとして究めていくかになりますが、もうひとつは、運用エンジニアとして生きる道もあるような気がします。運用といっても従来のようなシステム運用というより、ユーザが行なうビジネスオペレーションに対するサポートという領域が重要になると思っています。

少なくとも、これからの必要人材スキルは変化していくものと思われるので、ITSSにとらわれないで今のうちに準備しておくことかもしれません。

ITSS.bmp

2009年6月16日

パラダイムシフトの正体(8)~ベンダー編~

さて最終回は、ユーザとベンダーの関係の変化、あるいはIT業界にもたらす影響などについて考えてみましょう。

これまでの議論で、システムの構造から設計・開発や運用のやり方、プロジェクトの進め方、必要人材など多くの領域でこれまでとは違ったものになっていくことがお分かりになりましたでしょうか。

そうした変化は当然、ユーザとベンダーの関係にも影響していきます。直接的には、プロジェクト体制やマネジメントが変わって行くでしょう。

ここでこれまでの両者の関係をみてみましょう。簡単に言うと「情報の非対称性によるインセンティブの歪み」が特徴的であるように思います。

どういうことかというと、情報システムに関する情報は、専門家であるベンダー側のほうが圧倒的に情報を持っていて、ユーザ側の持つ情報は多くはありません。まずは、この情報のアンバランスがあります。

こうしたアンバランスがもたらすものは何かというと、悪く言うとベンダーが何をしてもユーザはわからないということなのです。ですから、ユーザはベンダーから開発にこれだけ人月がかかりましたからお金をくださいと言われても、高いけどしょうがないなあと言って支払うのです。こんな関係がいいわけありません。

こうした歪みを修正できる可能性がプロセス志向にはあります。なぜなら、ユーザが自分たちで作りたいと思ったシステムがそのまま実現できるようになり、しかも初期の段階でその姿が見えるようになるからです。

専門的、技術的なものは隠蔽されたビジネスコンポーネントをベースにユーザとベンダーが会話するのです。

こうしたことは、ユーザにとっては僥倖ですが、ベンダーにとってはどうでしょうか。問題はここにあります。このモデルでは、おそらく従来のようなコストとは全く違ったものになるはずで、大方のケースで低く抑えられるようになります。

ウオーターフォール用にたくさん抱えた人材を遊ばせることになりかねないので大変なことになってきます。だからといっていつまでもユーザが知りませんということはないのであって、徐々にユーザは気が付き出しています。

普通に考えれば、ITはそもそも使われてナンボですから、使われ方や使うものが変わったら、当然そのビジネスモデルも変化するのです。それを、自分たちのビジネスを守るために、ユーザに不当に費用を負担してもらうなんてことは本末転倒なのです。

そういう意味では、ベンダー側がユーザより先んじてビジネスモデル、収益モデルを変えていく必要があるのですが、どうも自己保全に軸足がいっているようでお先が思いやられます。こんことをしていると、わが国のSIerと呼ばれる会社はどうなるかはおわかりですよね。
 

About パラダイムシフトの正体

ブログ「mark-wada blog」のカテゴリ「パラダイムシフトの正体」に投稿されたすべてのエントリーのアーカイブのページです。新しい順番に並んでいます。

前のカテゴリはビジネスサービスのつくり方です。

次のカテゴリはビジネスプロセスパターン研究です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type