mark-wada blog

ビジネス視点での業務システム構築を考えていくと、プロセス志向でもなく、どうもオペレーション志向というほうがマッチするような気がしてきた。ちょっと前までプロセス志向だと言っていたのに宗旨替えですかと言われそうだが、どうもプロセスだけでは語れないのである。

だからといって、プロセス志向を否定しているわけではなく、それだけではないということが言いたいのである。いつも言っているように、業務システムというのは、ビジネス要件を円滑にかつ効率的に処理することが大事であり、システム開発して終わりではないのです。

そう考えたとき、どんな構造のシステムがいいのか、どういった機能群で構成されているべきなのかということを自問自答してみる。

そもそも仕事のやり方はどうなんだろう、組織の活動ってどうなっているんだっけという分析から考えることになる。そこは、「サイモンの意思決定論」が非常に役に立つ。

ご存知のように「サイモンの意思決定プロセス」というのは、情報活動（Intelligence Activity）、設計活動（Design activity）、選択活動（Choice Activity）、検討活動（Review Activity）からなっていて、これを個人のレベルそして組織のレベルで実行し、それを連鎖させていくことが業務であり、それを管理するのがマネジメントなのである。

ですから、システムに求められる要件としては、「サイモンの意思決定プロセス」を動かすための情報収集のためのエンジン、プロセスフローを制御するステートエンジン、アクションを誘導してくれるルールエンジンがあって、それを一元的に操作できるコンソールが必要になるわけです。

もちろんこれらのエンジンに投入するデータが要りますから、そのためのデータベース、各種リポジトリーを用意しておくのは言うまでもありません。

これらが、プラットフォームとなります。この仕組みをBOF（Business Operation Framework）と呼ぶことにして、「プロセス」、「機能」、「データ」をコーディネートします。

この考え方は、単にBPMSだとかERPだとかいったこととはずいぶん違うように思います。これからは上述したように“サイモン場”をいかに質の高いものにしていくかがトータル業務効率の向上につながっていくのではないでしょうか。

業務プロセスの設計をすると、プロセスと機能とデータ、それに加えてルールの関係が複雑に絡み合ってくるので混乱する。従来のような密結合でプログラム的に処理する分には、重複さえ注意すれば難しくはない。ただし、作るまではいいがその後のメンテナンス性を考えると恐ろしくなる。

いま、ここで「プロセス」「ルール」「機能」「データ」と言っているが。これがなかなか一筋縄ではいかない。簡単に使っているがちゃんと定義していない。その意味するところは、人それぞれで違うし、狭くとるか広くとるかでも大きく違ってくる。だから、きちんと定義し、構造化していかなくてはいけない。

そこでそのあたりを見ていこうと思うのだが、プロセスについてはさんざん議論をして、ここではアクティビティの粒度を定義し、それを階層化することで、2段ワークフローという概念を提示した。それによって、定型・非定型の切り分けや、コントロール＆オペレーション重視という考え方も採りやすくなり、ビジネスに貢献できる形になると期待している。

一方、「データ」についてもデータベースの設計というアプローチではなく、ビジネス視点の考え方がるべきだと思っているが、これは後にして、ここでは「ルール」について議論してみましょう。

ちょっとその前に、ルールの重要性を強く感じたのでそのことについて書く。業務システムの構造は、以前から「機能とプロセスとデータ」から成っていると言ってきたが、このうちの「機能」というのが若干分かりずらいと思うので、「アクション」と言い換えたほうがいいかもしれないのでそうした表現を使うことにする。

そうすると、業務は“データを使ってアクションを起こし、それをつなげてプロセスにして、そこで新たなデータを生成させる”ことと言える。ところで、この一連の動作をどのように制御しているのだろうか。何をもって進行させているのだろうか。

それが最近、「ルール」であると思うようになったのである。ただ、このルールという言葉も範囲が広いので注意が必要であるが、その中身については次回お話しすることにして、ここでは“決めごと”くらいの感じで言っています。

データもその意味することはある決めごとで定義しますよね。例えば、「在庫」の定義もちゃんとしないと会社によって違ったりします。また、アクションはそれを誘導するためのきっかけが必要です。どういう事象があったらどういうアクションを起こすという決めごとが要ります。プロセスは、その順番や分岐させるためのルールがあります。

こうしてみていくと、プロセス、アクション（機能）、データという要素（コンポーネント）を“ルール”によってコントロールしている司令塔のようなイメージがわいてきます。これが「オペレーション志向」ということでもあります。ルールマネジメントの大切さがここにあります。
　

前回、ルールの重要性を言い、そしてルールといっても人それぞれに違った定義をしているということを話ました。今回はその業務ルールを分類して定義してみようと思います。ただ、ここで注意しなくてはいけないのが、参照情報との境界です。

ルールの前提は、意思決定に直接関与するものであると考えているので、単に参考として見る情報というのはルールではないと考えています。ですから、問題となりそうなものは、規約・契約とか予算などの計画情報でしょう。

こうした情報は確かに意思決定に拘束力を与えるように思えますが、直接的でないのでルールというより参照情報として捉えてほうがよいように思います。これは、それでなくてはいけないというわけではなく、かなり縛られるようならルールとしてもかまわないと思います。

さて、ルールというと、それこそゲームをするのにもルールがありますし、会社のルールがあってそれを破るとクビになったりします。ある世界特有の隠語みたいなものもルールかもしれません。

このように、単にルールといっても様々です。ということは、その性格に応じて少し整理してみる必要があると思います。実はそうして整理してみると、前回提示した「プロセス」「データ」「アクション」にきれいに分類できることがわかります。

すなわち、プロセス、データ、アクションのためのルールの3つに分けて考えると分かりやすいように思います。この区分けで行くと次のようになります。

１） プロセス定義のためのルール
手続きや手順のことで、例えば見積照会ルール、受入検収方法とか、注文書発行手順といったものになります。こうしたルールは、プロセスフローやアクティビティのロールといったものに反映されていきます。プロセス設計の段階で埋め込まれるものです。

２） データ定義のためのルール
データの属性を決めるためのルールで、例えば、無検査認定品とはや、棚卸区分といったように、データの性格付けをするためのルールです。これは、標準的というより各社固有のものになってきます。これらをデータ辞書という形で管理するとよいでしょう。

３） アクション定義のためのルール（オペレーションルール）
アクションを誘導するためのルールで、例えば、与信限度額を超えたら処理しないとか、基準在庫に達したら補充発注するといったように、ある閾値になったらどういうアクションを起こすかを決めることです。これは、動的でオペレーショナルなもので、しかも、実績を積みながら変更を加えていくという不断の改良が大切になります。日々進化させるルールということが言えます。

こうしたルールを設計時、及び運用時に適用して業務システムを効率的なものにすることが非常に大事で、こうした考え方はこれまであまりとられていなかったように思います。開発プロジェクトでそのときだけの一時的で静的な場面でルール適用をするだけで、使いながらシステムを成長させるという意識が乏しかったのではないでしょうか。
　

またまたルールの話です。前回は3種類のルールいついて書きましたが、その中にアクション誘導型のルールがあったと思いますが、それがいわゆるBRM（Business Rule Management）のことで、そのことについて少し考えてみましょう。

ただ、BRMというとルールベースで考えるものとデシジョンサービスという風に考えるものがあります。デシジョンサービスというのはデシジョンプロセスをカプセル化するもので、これだと一概にアクション誘導型だけではありません。プロセス定義型もあるということです。

ここでデシジョンサービスというのがちょっとひっかかるので、デシジョンサポートサービスのほうがいいと思うのですが。なぜかというと決定状況がブラックボックス化してそれを自動的に動かされるとちょっと恐い感じがします。ここはそれまでにしておきます。

ところでこのBRMということについては日本ではあまり活発な議論がありません。少なくともBPMよりは少なく、むしろBPMの付属機能のような扱いを受けています。

しかし、BPMという観点からではなく、業務システム全体のあり方を見ていくとBRMの重要さが浮き彫りになてきます。それは繰り返し申し上げているオペレーション志向を実践しようとすると感じることでもあります。

さて、BRMサイドからみたビジネスルールはどんなものがあるのかというと、BRMの草分けであるブレイズコンサルティングの定義は、大きくは、概念ルールと事実ルールとそしていわゆるルールというのがあって、そのルールには、制約、ガイド、アクション、数値、推論という5つのルールがあると言っています。

この中で、前回分類したような形で分けると、概念、事実、数値がデータ定義のためのルールとなり、その他がアクション定義のためのルールになると考えています。

すなわち、アクション、ガイド、制約、推論のいずれも対象となる値や事象が設定した水準になった時にどういうアクションを起こすかを決めることであり、その対象が制約であったり、それを導き出すのが推論だったり、またそのアクションがガイドの場合や次アクションの開始であったりということなので、厳密に分ける必要はないのではないでしょうか。

問題は、このルールをどういう形で活用するかになります。このあたりについては次回に議論します。

ルールマネジメントというが、具体的にどうやっていくのだろうか。それもルールの種類によって違ってくるが、そこのところを考えてみましょう。

プロセス定義のためのルールは、フローの順番や分岐の種類や条件、あるいは承認のしかたのようなロールに関するものです。これらは、おわかりのようにプロセス設計の時点で考慮される事項である。ですから、オペレーション以前の設計で反映されてくることになります。

データ定義のためのルールというのも同様にデータを定義する段階で最初のメタデータレベルでの決め事になります。その語の意味するところを一義的に表現しておくことです。簡単なところでは、会社名の表現は（株）は認めないとか、製造途中の製品を半製品と呼ぶといった類になります。

また、計算ルールみたいなものも含まれてきます。窓口１次回答率の計算式はこうであるとか、合計とは何と何を足したものであるといったものです。こうしたルールはデータ辞書といった形で整理しておくとよいと思うし、できたら管理システムのなかでデータクレンジングの仕掛けをもって統合的に管理するのが望ましい。

さて、アクション定義のためのルールですが、これらは前の静的な二つとは違って動的な要素を持ったルールになります。従って、オペレーションルールとも呼んでもかまいません。日々の運用の局面において使うことになります。

何か意思決定の要求がきたときそれを判断する場合に使うルールであり、判断のきっかけとなる事象やデータを測定し、それが規定の値や制約に達しているかどうか見て、それに達していたら、次にどういうアクションを起こすかを示すことです。

分かりやすい例だと、引合いがきたが与信限度額に引っかかったら取引できないというようなことがそうです。ですから、ここではそのロジックの管理とともにバリューそのものの管理もしていかなくてはいけない。ルールリポジトリーとルールエンジンが必要なのです。

さらに、大事な事は、こうしたルールは一旦決めたらそのままということではなく、常に変化するということを忘れないことです。それは、相手が変わるとか、状況が変わるとかといった受動的な変化もあるが、もう一方で戦略的・戦術的に変えていくこともあるということです。

上の簡単な例を引き継いで言うと、与信限度額というのはリスクとリターンのバランスを設定していることに他ならないから、それを変えることによって、信用には欠けるがコストが安いオファーを採用するのか、あくまでリスク回避するために付き合いの長い信頼のある会社とだけ取引をするのかといったことになる。

こうした判断は、商品によっても違うし、時期によっても違ってきます。また、実績を重ねるごとにそのデータを解析して、より良いルール設定も可能になるのです。成長するあるいは進化するルールつくりが重要になるのです。

再三言っているように、ここが競争優位を生み出し、差別化できるところなのです。
　

しばらくルールの話が続いたので、ここらで一旦“鳥の眼”でながめてみる。

EAとかSOAとか全体をあらわす言葉があるが、それらはかなり上流のところについてのことであって、どうも業務システムのようにもう一段下がったとこについて体系化したような言葉をあまり聞かない。業務システムについての全体感が分かるものがあるのかということである。

それはERPがあるじゃんと言われるかもしれないがはたしてそうなのだろうか。ぼくは、まだ一部のことでしかないと思う。ERPで業務システム全体を表しているとは到底思えない。

一方で、CRMやSFA、BPMやワークフロー、EAIやESB、データウエアハウスやBIというふうに部分的な適用ソリューションがある。そして、そこだけ議論して導入したりする。そういった導入の仕方で本当にいいのだろうか。木を見て森を見ない状態になるのではないでしょうか。

そうなると全体図を書かなくてはいけない。ところが問題はそれを書くときパッケージやシステム名をつなげて全体にしがちである。最近はSOAがかなり浸透してきているから、サービスをつないでみたいなことを言って悦に入ることになる。

こういうところでもシステム視点になってしまっている。会社全体の事業の構造はどうなっているのか、組織は、どういう業務プロセスが走っているのかといったアプローチが必要になる。毎度言うように会社があるいは組織が有機的に効率的に機能させるためにITがあるのだから、まずはITを考えない事業・業務・組織構造を組み立てて、それにかぶさるようにITを配置することが大切である。

それを、はいCRMを入れましょう、BIで経営分析しましょうと言ったところで周りの仕組みや、基になるシステムがちゃんとできていないのにそんなものを入れても効果が上がらないのである。

だから、繰り返すが、全体図を書いてどこを優先的にIT化すべきか、それをどうIT、非IT関係なしに連携させていくかという考え方が必要なのである。その全体図は部分的なソリューションを提供するパッケージベンダーやツール屋は描いてくれません。

そして本来それができるはずのSIerも自分たちの商品を売ることだけしか考えないので、結局ユーザ自身がそこをやらなくてはいけないのである。それがEAでもあるのですが、業務システムの構造までなかなか具体化されないのが現状ではないでしょうか。
　

こういう時代だから業務システムを早く作らなければいけない、あるいは安いコストで作ってほしいと言われる。そうすると、いかに開発生産性を高めるかという議論になる。どれだけコーディングの自動化ができるかとか、アジャイルだとかスパイラルとかいう話になる。

それはそれとして希求すべきことではあるが、今のシステム作りの延長線でいくら一生懸命早く安く作っても限界があるように思える。

だいいち既存SIerの経営者が絶対に考えないことである。なぜなら当たり前のように儲からないからである。抱えている社員のクビをドラスティックに切るわけにはいかないだろう。ビジネスモデルを変えられない限り、作り手側からの開発生産性の向上は望むべくもない。

しかしながらユーザの短納期・低コストの要求は続くだろうから、抜本的に作り方を変えていかなくてはいけないのだが、作り方だけを変えても先ほど言ったように限界なのだ。そうであれば、“作るもの”も従来のものと違ったものにしなくてはいけない。

Whatを変えずにHowを変えてももう無理だから、Whatを変えていくという発想の転換が必要なのである。そこの議論ができていない。戦艦大和を作ったのはすごいが、戦艦大和をどう作るかは一生懸命だったが、そういうものを作るべきだったのかどうかの議論がなかったのではないだろうか。

これまで挑戦してきた自動化だとかアジャイルがなぜ陽の目をみないのかをよく考えることが大事だ。そして、どんなシステムを作ればいいのかを再定義して、それに合った作り方を議論しないことには、現状の課題をクリアーできないだろう。

この問題は、単に開発技法だけの話ではなく、プロジェクト体制、人材のスキルセット、ユーザとベンダーの関係などなどあらゆるところに影響を与えるのだ。それをだれが考えるのかが問題だ。

先ほど指摘したようにSIerは自分の首を絞めることになるから考えないし、パッケージやツールで儲けようという話でもないからそうしたベンダーも考えようともしない。そうなると残るはユーザ自身が自分のビジネスをデザインしてそれを高い能力のシステム技術者に作らせてしまうという姿が浮かんでくる。

一旦こうしたパラダイムシフトを起こしたほうがいいように思う。そうなるとずいぶんとIT業界の景色が変わってくるわけで、そこから新たなビジネスを構築すればいいと思うのである。
　

先日のエントリーで「創造はシステムである」（中尾政之著　角川one　テーマ21）という本を紹介したが、その中にタイトルにあるような議論があった。アメリカ人は独立が好きで日本人は干渉が好きだという話から、モジュラーとインテグレイテッドの戦いがあるというようなところに展開した。

モジュラーは、基本単位や基本構成（つまりモジュール）が配置された組織や構造を意味し、インテグレイテッドとは、個々の単位が互いに絡んで、融合している組織や構造を意味する。日本の得意な「摺り合わせ」はこのインテグレイテッドのことである。

ただ、この議論はどちらかが良くてどちらかが悪いという問題ではない。どちらも必要であり、バランスさせることが大事だと思う。その切り分けに関して中尾政之さんは、小規模の組織や設計ではインテグレイテッドが有効だが、それ以上の大規模の組織や設計ではモジュールが有効であるとして、その規模として組織では200人、設計･生産エンジニアでは10人がその境界であると言っている。

確かに規模的な問題はあることはある。多くの人がいる場合は摺り合わせも難しいと思うし、少人数だと構成要素に分解されるものでもないからである。ただ、ぼくは規模だけでの問題ではないと思うのである。

規模だけではないとすると何なのだろうか。ぼくはその組織なり、構造のもつ性格であるような気がする。言い方を変えると、業務プロセスを実行するのにどちらに向いているのかが大切ではないかということである。

ある要素を標準化してモジュラーとして扱ったほうがいい場合と、もう少しあいまいにして人間系が入り込んでそれらを連結（インテグレイション）させるほうがいい場合がある。それを使い分けるのが有効であると思う。

中尾さんも言っているように、モジュラーとインテグレイテッドを混ぜたハイブリッドな組織や設計が好ましいであろう。そのとき、規模で分けるのではなく、性格で分けることをお勧めする。

業務システムの話に敷衍していくと、以前から指摘しているように、モジュラー型で設計する業務プロセスレベルとインテグレイテッド型で設計すべき業務プロセスレベルがあるということである。
より具体的に言うと、単位意思決定の連鎖プロセスはモジュラー型であり、その意思決定の中のアクティビティはインテグレイテッド型である。

ここで少し話しは日本製造業に行くが、巷間ではまだ摺り合わせ型で垂直分業型で遅れているような言い方をされているが、確かにそういう面は否めないし、特にグローバルでは水平分業型に移行しているにもかかわらず相変わらず多重下請け構造が足かせになっているだろう。

しかしながら、デジタル技術の導入や情報の共有の迅速化などでずいぶんと干渉を軽減したモジュラーな加工手段を用いるようになったとのこと。

製造業でさえそうした変化がおきているわけで、そうした意味でまた繰り返すが、ITの世界もこの変化に対応していかなくてはいけない。この対応というのは、ユーザ企業の変化にすばやく追随できる業務システムを提供できるかということと、自らがモジュール型の開発スタイルも取り入れてより高い生産性を発揮できるかということである。

ところがまだ、業務システムそのものの構造が相変わらずインテグレイテッドでしかないことと、その設計過程や業界そのものの組織構造がインテグレイテッド型であるように思える。ここが早くハイブリッド型に生まれ変わることを切に望むのである。
　　

プロセスを考えていると、粒度という言葉に出くわすし、自分でも使っている。そして、粒度の対象となっているのも、プロセスであったりアクティビティであったりタスクであったりする。

一方で、抽象度という言い方もされる。これらは同じものでしょうか。よく混同して使われているが、そうではないですね。となると、使い分けていかなくてはいけない。

まあ、素直に粒度は大きさすなわちスケールを表していて、抽象度というのは、あいまいさの程度とか、堅さと緩さみたいなことでいいと思う。

ですから、大きな粒度でも抽象度の高いものもあったり、小さな粒度で抽象度の低いものもあることになる。そのあたりの使い分けをうまくやらないと、ここはやけに細かいけど、こっちにいくと何てラフなんだろうというようなことが起きる。

そう考えると粒度というのはむしろ管理単位という括りでみるのがいいかもしれない。ある組織体またはある役割の人が管理する単位として、このプロセスの単位は、事業部で管理するとか、このアクティビティはこのグループで管理するといった感じである。

既存の業務システムを眺めると、ずいぶんとそうしたアンバランスな構成で作られているように思う。あまりリジッドに決め付ける必要はないが、ある程度の均一感を持たせた方がいいのではないだろうか。

ぼくはこれまで、粒度という表現を多く使ってきたが、どうも抽象度との組み合わせでみていくのがより適正な表し方ではないかと最近思うようになった。というのも、SOAのような概念が提示されてくると、サービスという括りを意識してきます。そのとき、サービスはスケールというより、機能というのが重要であり、あるサービスを依頼して、それに応えるサービスを返してくれれば、サービスの大きさは関係ないと思うからである。

ですから、業務プロセスを設計するとき、まずはプロセスの粒度ということを考えますが、そのときプロセスの抽象度も同時にみるほうがいいように思え、また、アクティビティの粒度という場合も同様で、そのアクティビティがかなり複雑で長いプロセスを内在したものでもINとOUTで取り合いだけでプロセスを形成していければ、ブラックボックスでもかまわないといえます。

ただ、呼び方もあるが大事なことは、プロセスやアクティビティをどういう考え方、どういう法則で定義していくかである。ここがはっきりしないからいつまでたっても属人性の強いプロセスが作られるのである。
　
さらに、こうしたことで気になるのは、プロセスの自動化のことである。すぐに自動化というのだが、それは上述した抽象度に関わってくる問題であって、抽象度のレベルで自動化してもいいか悪いかを見定める必要があると思う。

すなわち、抽象度の低いところでは自動化は有効かもしれないが、抽象化レベルが高いところで自動化してしまうといったいそこで何が起こっているのかわけがわからないとなるような気がするからである。コンポーネントをどういう粒度と抽象度に最適化するかがシステムの質を決定する非常に重要な要素であるといえる。
　

モデラーなどでプロセスを設計していくときプールとスイムレーンというものを書いていくのが普通である。ではそのスイムレーンは組織を表しているか、人を表しているのかどちらなのだろうか。あるいはロールなのだろうか。

それについては、アクティビティの粒度（抽象度）問題と関連してくるが、その前にロールの定義もしておく必要がある。ロールは役割だから、そのアクティビティを回す役回りのことを指すのか、そのアクティビティを実行する主体を指しているのか。人によっては能力みたいなものを言う場合もあります。

こういうと混乱してきますよね。具体的にみていきましょう。やはり、アクティビティの中身から考えた方が分かりやすいと思います。

細かい粒度、抽象度の低い場合、アクティビティは“申請”、“確認”、“連絡”、“調整”、“入力”、“承認”といったものになります。このときのロールってしょうか。このアクティビティそのものがロールと言えないこともないのがわかると思います。そのアクションをする権限を付与されていることがこれにあたるわけです。承認権限なんてはわかりやすですよね。

そうすると、スイムレーンでは、その権限を持っている人の単位でレーンを書くことになります。ところが、それだとかなり入り組んだフローになってしまいます。長いプロセスや関係者が多くいたりすると複雑さになってしまいます。

一方、ぼくが推奨しているような一段抽象度を上げた「単位意思決定」というアクティビティにすると、その単位意思決定をするためのロールという言い方もおかしく、むしろ組織といったほうがしっくりきます。

そうした場合、プロセス設計でその組織を設定することはどういうことなのかということになります。もちろん、意味がないということではないが、書く意味が薄くなると思う。そして、書いたところで組織変更があったらそれに伴いプロセス変更になったりしてしまう。

従って、ロールという概念は単位意思決定の中の役割を指すことになります。単位意思決定は、だれかが起案しそれを確定し、承認することですから、だいたい、三層くらいのロール設定をすればよいことになります。

このようにプロセスの抽象度の低いアクションレベルでロールの設定が行われます。そこでは、あとからユーザを割り当てる形にしておけば、組織が変わろうと人が異動しようがシステムの変更をしないで設定だけを変えることになるわけです。
　
結局、今のビジネスは組織をどんどんいじっていったり、突然アウトソースしたり、ネットワーク型になったりといったように、組織やロールは非常にフレキシブルであることが望まれています。それをITが阻害しないようにする必要があるのです。
　

業務プロセスというとおおかたはフローがあってそれを順番に流していくというイメージがあると思います。そして、それもわりと短時間で進めていくと思われています。

それとは違った仕事のやり方として、プロジェクト業務があります。フローというよりあっち行ったりこっち行ったりしながら、わりと長い時間をかけて終わらせるというものです。こうしたプロジェクト業務の管理はプロセスとは異質のものなのでしょうか。

いま、ぼくが提案している「単位意思決定の連鎖がプロセスである」という概念からいうと、実はプロジェクト管理もプロセスであると考えられます。すなわち、プロジェクトはもちろんスケジュールがあり、マイルストーンがあり、そしてWBSが設定されるわけです。

ということは、様々なタスクでひとつ一つ意思決定を積み重ねてマイルストーンにたどり着き、最終的にプロジェクトを完遂させるというプロセスであるといえるのではないでしょうか。

ですから、今開発しているBPM Framework「Kailas」はプロジェクト管理ツールにもなると思っています。プロジェクトというものはコラボレイティブな仕事を通して進捗を管理していくことが必要ですから、コミュニケーションの場、進行が追える場、成果物を格納する場、履歴を参照できる場といったものを用意することが有効であると思うからです。

このように業務、いや会社の仕事だけではなく私的なものでもそうだと思うのだが、すべからく意思決定とその連鎖で成り立っているように思う。その意思決定の大きさや範囲が違ったり、連鎖が短期なのか長期なのかだったりするだけで、本質的には同じものであると思うのです。

だって、そこで活動している人って、業務プロセスだから、プロジェクトだからという意識もないし、やっていることを変えているわけではないと思うのです。働き方のスタイルも同じなわけだから、そこが基本の仕組みを用意するということが大事なことなのである。

世の中には、いろいろなシステムや業務パッケージ、ソフトウエアが出回っていますが、そこの視点が欠如していて、それぞれ固有のワークスペースであり、そもそも一部の機能しか提供されないから、異なったワークスペースを行き来しなくてはならない。

少し話はそれたが、プロジェクト管理も結局はプロセス管理と同じであるということを言いたかったのである。
　

システム開発では、よく例外処理をどうするのかという問題が“例外なく”指摘される。現にぼくも開発のジレンマのひとつとして「実業務のさまざまな例外をコンピュータ上に乗せるか否か」ということを言ってきた。

しかしながら、よく考えてみると例外とはいったいどういうことを指しているのだろうか。めったにないこと、予想外のこと、決まったことから外れたこと、そう言ったところでそれが大事（必須）なことであれば例外ではないはずだ。

ということは、まずは重要なことであれば、それがめったに起きることであっても例外とは言わないのだろう。そして、それはシステムに組み込まれる。しかし、１０年に１回しかないことを定例というのだろうか。

では逆に重要でなければ無視すればいいと考えられるのなら、システムには例外というものがないである。もっと正確にいうと最初に設計したときには例外というものはないということになる。

だから、例外というのは運用のときに出てくる問題なのである。最初に設計した、プロセス、ルール、データのそれぞれの定義から外れたことやものが出てきたときに初めて例外処理という問題が生じる。

設計・開発の段階から例外を予想するというのは矛盾するのである。予想できないから例外なのだから。じゃあどうしたらいいのだろうか。それはシステムを動かしながら柔軟に例外を吸収できるようにしておくことである。

具体的に言うと、例外が発生したら、それは人間系で処理できるようにしておくことだ。そして、例外が続くことがあるが、そうしたらそれは例外ではなくなるわけだから、ITシステムに組み込んでいくというやり方である。

細かいアクションまでITにのせ、さらに自動化しようなんてすると、この問題にぶち当たる。従って、最初からどうやって例外処理を開発しようなんて思わないほうがいい。“ゆるい”ものは人間の“やわらかさ、しなやかさ”で受けて、“かたく”なったらITに組み込むという姿がいいと思うのである。

この間のYAPCでJPAのエマーソンと話す機会があって、彼は今アジャイル開発の先生をしているのだそうだ。それで、すこしそのあたりの話をしようと思っていたが、あまり時間がとれなく中途半端になってしまった。

今回のプレゼンも「親子でアジャイル」という言い方もしているので、考えてみようと思う。しかし、本を読んだり、誰かが定義したものを引用したりはしないことにする。もともと、世の中のアジャイルのこととか、XPだとかは正直あまり知っていない。

アジャイルという意味は、早く俊敏にという意味だから、究極的にはどんなやり方をしても素早くできればいいはずだ。だから、こうやれば速くできるというのはいいのだが、こうしなくてはいけないという話はない。

もうひとつ考えなくてはいけないのは、どこの工程が速いかである。このことは、アジャイルだけに限ったことではなく、システム開発のすべてに関わることである。システム開発を混同して議論することがよくあるのだ。

すなわち、組み込みはちょっと置いといて、ソフトウエアやフレームワーク、ツールなどいわゆるプロダクトを作る開発とそれを使ってアプリケーションを構築する場合（これともっとコアのところの開発もあるがそこはスーパーギークの世界なので省略）である。この二つは同じ開発でも性格が違う。したがって、議論は分けてしないといけないのだが、往々にして混然とさせてしまう。

ソフトウエアの開発の場合は、ものをいかに早く作り上げるという開発者のパフォーマンスに依拠する。だから乱暴にいうと早くあるいは短いコードを書くかになる。

一方、業務システムの場合はどうだろうか。ここでは、何が早いことを求められるのだろうか。少なくとも、システムを作ることだけではなさそうだ。実際に作ったものが使われて、そしてもっといえばそれで効果を発揮してはじめて価値がでるのであるから、どうもそこまでの早さを言うべきであるということがわかる。

こう考えると、いくら早く作ってもうまく運用できなかったり、効果がなかなか出なかったりしたら、アジャイルでもなんともないのではないでしょうか。

また、コードを書かないですぐ動かせたらそれはアジャイルなのだろうか。おお、アジャイルがあやしくなってきた。だから、アジャイルは、設計・プログラム仕様確定・製造の工程を早く回すひとつの手法という感じですね。

業務システムは作って終わりではないというのが、ユーザの意識なのだが、そこがまだ作り手側とのずれがあって、そう思うのなら、自分たちで主導しろと思うのだが、ベンダーにまかせているままだからその溝は埋まらない。

これからの業務システムに大事なのは、当たり前のことなのだが、目的の達成スピードである。どれだけ、早く当初の目的に対する効果をあげるかがシステム化の価値であるはずだ。

ところが、なかなかその意識が出てこない。なぜかというと、“当初の目的”が希薄、あるいはない場合があるからである。ユーザ側にも責任があるわけで、そこをきちんとしておくことが前提であることはいうまでもない。

結局、設計－開発－稼働－オペレーションといったフェーズまで考慮して、どこが律速になっているのかをチェックして、トータルの迅速性を評価しなくてはいけないと思う。それも、ビジネス視点、ユーザ目線で洞察していかなくてはいけないのです。