いま、ITの進展はすさまじいばかりで、毎日新しい技術やサービスが登場している。中には大きな変革をもたらすものや生活のスタイルを一変させてしまうようなものまである。ところが、企業の業務システムの世界では同様な変化が起きているのだろうか。

残念ながら、個々の技術要素やハードウエア・インフラなどで新しいものを採用はしているにもかかわらず本質的な変化はないように思われる。

そこで、これからそのあたりの検証と改善策の提案をおこなっていこうと思う。ただし、ことわっておかなくてはいけないことがいくつかある。

まずは、アカデミックなアプローチはしないとうことである。もちろん基本的（初歩的）な論理はあるのだが、学問はおおかた実務的ではないので、その手の本に書いてあるようなことは浅学の身であることもあり、あまり参考とはしていない。

次に、IT用語は極力使わないようにしたい。特にはやりの3文字熟語は避けたいと思っている。業務システムを使う人はITのことはよくわからないビジネスに携わっている人たちだから、その人たちが理解できる言葉で語らなくてはいけないと思っている。

また、こうした検討のとき大上段に振りかぶって、経営はどうあるべきか、どういう戦略を立てたらいいのだろうか、強い組織とは、といったような議論がなされることがあるが、ここではそこはスルーして、そうした経営方針や戦略が決まったあと、それをどう実行させていくのかという観点で見ていきます。いわば、CEOではなくCOOの目線です。

そして、何よりも本当に役に立つにはどうしたらいいのかという根源的な問いかけをどんな場面でもするようにしたいと思います。システムを作ることが目的化すると、正しく作ったと思ったものが実は使われないということになりかねません。

ということで、いままでも似たようなことを何度か書いてきていますが、それから考え方が変わったり、また新しい技術がでてきたりしていますので、この機会に何回かにわたってもう一度整理して「業務システムの再定義」をしてみようと思います。
　

ビジネス実行機能の構造

最初にことわったように、戦略とかビジネスモデルのことではない。どういう活動を行っているかである。簡単にいえば、PDC（Aもありますが、これは結局Pに反映することですから、ここではPDCとしています）サイクルを回す機能ということがいえます。

いい経営者がいても、あるいはいい戦略がっても、いいビジネスモデルがあっても、それを実行するオペレーションの仕組みがなくては会社としては機能しません。

往々にして、戦略やビジネスモデルに注目がいって、本なんかも多く出版されています。しかし、それを執行する業務プロセスや組織の重要性も高いはずなのですが、組織論は多くありますが、意外と業務プロセスのオペレーションはあまり議論されていないように思います。

ですから、ここではそうした実行部隊が何をしているかを考えてみたいと思うのです。逆に、いい実行部隊がいたら、あるいはいい仕組みがあったら、そこから優れた戦略やビジネスモデルも生み出せるのではないかと思いたいのです。

会社の経営方針は主にトップの頭の中で作られます。もちろんコーポレートスタッフもいて彼らが作っているように思うかもしれませんが、私の経験では単に参考情報を渡すだけであって、戦略そのものはトップ自らが作ります。ただし、それは細かいものではありませんが、重要なのは同時にそのコンセプトを実現できる人材を登用していることです。

ここには業務プロセスという概念は入ってきません。そのあとの戦略を具現化するところから業務プロセスが登場してきます。

そこを大きな括りでみていくと、冒頭に言ったPDCサイクルのそれぞれにプロセスが絡んできます。すなわち、計画プロセス、実行プロセス、管理プロセスです。ただし。これは重層かつ縦横構造になっています。

どういうことかというと、重層という意味では、たとえば、実行プロセスには生産プロセスや調達プロセスなどがありますが、そこにもPDCサイクルがあるということです。生産計画があって製造して、製造原単位などを管理します。

縦横というのは、実行系でいうと、事業や商品、サービス単位でプロセスがありますが、そこを横断するプロセスもあるということです。たとえば品質管理プロセスとか輸送管理プロセスとか言ったものがこれにあたります。もちろんこのプロセスにもPDCサイクルがあります。

そしてさらに見ていくと、このPDCのPやDはどういう成り立ちかというとそれぞれに意志決定プロセスを抱えています。実はこの意思決定プロセスも重層的な構造になっています。事業レベルの意志決定もあるし、単なるアクションに対する意思決定もあるという具合です。

ということで、ざっくりとした言い方だが、企業におけるビジネス実行機能の構造は、PDCサイクルと意志決定プロセスの織り重なった構成の上に成り立っているといえます。
　

計画機能

前回、企業のビジネス実行機能の構造は、PDCAサイクルと意志決定プロセスの組み合わせの上に成り立っていると言いました。そこで、まずは大きなくくりでPDCを見ていきましょう。これは、会社の組織のことともいえます。ですからわかりやすいように、会社にはどんな組織があって、どんなミッションを持っているのだろうかとみていきましょう。

最初のPの計画機能です。まず会社全体の中長期計画があります。よく三カ年計画とか、中期経営計画とかいった類です。

ちょっとそれる話ですが、こういう計画は必ず立てるわけではありません。中長期計画を立てない会社もあります。その理由は、このめまぐるしく変化する環境でそんなものを立ててもしょうがないということもあると思いますが、むしろ、計画を立てた途端にそれが独り歩きしてしまい、そういう計画には必ず前提条件というものがあるのに、それが忘れ去られ、計画を守ることが目的化してしまうことを経営者が嫌うからではないでしょうか。

これはよくある話で、計画を作ったときと状況が変わっているのに、中期計画に則ってやればいいんだという思考停止を起こしてしまうのです。あのトヨタだってその失敗をしています。

ですから、中長期計画は必要に応じて立てることになります。だからといって、計画がないということはありません。必ずどこの会社も年度計画、予算は作ります。これをトップダウンでやるのか、ボトムアップでやるのかはありますが、現実的には、ボトムアップの積み上げを集計、調整してトップダウンで計画化することになります。

この機能を担うのが、経営管理室とか経営計画部とか社長室といったところでしょう。そして、ここをサポートする機能があります。この段階では、リソースの状況、あるいは法規制などの問題を検討して、その計画が実行可能なものかをチェックします。

リソースの状況というのは、ヒト・モノ・カネ、すなわち人材・設備・資金がどうなっているのかです。そうした情報を提供するのが、人事部、設備管理部、製造部、財務部になり、法規制などに対しては、法務部、品質管理部、環境管理部、コンプライアンス委員会といったようなところがこれにあたります。

さて、こうした計画機能においての意志決定プロセスはどうなのだろうか。サイモンの意志決定プロセスで見ていきましょう。

Intelligent Activity：
計画を立てるための情報収集をしますが、そこでは、前年までの実績、市況、同業他社状況、研究開発状況などを参照しながらいくつかの計画案（たとえば楽観ケース、悲観ケースといってふうに）を作成します。

Design Activity：
そうした計画案について、サポート機能からくるリソース状況などを考慮して評価します。場合によってはシミュレーションをしたり、ケーススタディなどを行います。

Choice Activity：
ここで一つの計画案を決定し承認します。そして、予算などの手当も同時に決定します。

Review Activity：
この計画に従って実行した結果は、絶えずレビューし、計画からの乖離をチェックし、場合によっては、計画の変更も行います。

こうして整理してみると、計画機能や活動を支援する情報システムはどういう姿が望ましいか、おのずとわかってくると思いますがいかがでしょうか。
　

実行機能

前回は、PDCのPである計画機能について見ていきましたが、次はDの実行機能です。ここはマクロPDCの話ですから、事業執行ということになります。会社の規模によって、事業は複数であったり、一つしかない場合もあります。

しかし、事業を運営して行くのは基本的なところはみな一緒です。すなわち、ここでも一つ下のレベルの計画があり、その計画に従って、モノやサービスといった商材を作るか仕入れて、それらを販売して、売上を立てるということが実行機能になります。

ここでいう計画は、事業方針があって、販売計画、生産計画、調達計画などが作成されます。ここは前回の計画機能のミニ版で、事業企画室のようなところでとりまとめられます。

そして、実行の中心は、サプチェーンやデマンドチェーン、最近はバリューチェーンなんて呼ばれていますが、基本は一緒でも個々では業種により違ってきます。製造業でも生産財を製造しているのか、消費財を製造しているのかでも違います。建設、小売、サービス、商社などといった分類がさなされます。

ただいま実行プロセスが違うと言いましたが、おおかた包含できるコアプロセスは次のようなものだと考えています。販売計画－生産・調達計画－見積－契約－前受注－生産・建設・サービス・手配計画－仕入・調達・手配－生産・建設・サービス－後受注－引当－販売・出荷－検収。このそれぞれの機能（アクティビティ）をバイパスするとかして業種ごとの全体構成ができると思っています。

PDCのCの部分はどうなるのでしょうか。この事業実行の段階でのチェック機能の大事なことは、リアルタイム的に事業の状況（受注、販売、在庫など）をモニタリングすることだと考えられます。

ここでも意志決定プロセスという観点からみてみましょう。計画は会社全体のものと同様の考え方になります。実行機能のところでは非常に多くのプロセスから成っています。そこは、プロセスの階層化が行われ、最終的には単位意志決定（データ確定）というレベルに落されます。

ここは前述したようにバリューチェーンですが、この流れだけでは不十分になります。すなわち、意思決定をしていく時に必要な参照情報や判断基準をどこから得るかという問題です。

たとえば、生産設備をどれにしたらいいか判断するときとか、出荷OKの判断を下すときとかいった場合、設備保全スケジュールを知りたいだとか、ユーザ品質規格に合格しているかどうか知りたいとかいったことである。

これを、サプライチェーン（バリューチェーン）サポート機能と呼んでいるが、事業横断的に配備された機能である。上で述べた設備管理や品質管理以外にも、環境管理や輸送管理といったものがある。

最後のチェックのところでは、リアルタイム性が必要だと指摘したが、従来は技術的な制約などでここがなかなかできなかった。しかし今はITをうまく使えば可能になっている。なぜ、リアルタイム性が要るかというと、事業の舵をいつきるのかということで、今や非常に短いサイクルでやらないと負けてしまうからです。

だが、問題はBIを入れればそれができるというわけではないということです。これが今までBIが浸透しない原因であると思う。どういうことかというと、事業の動きを知るためには、業務プロセスの動きを見なければいけません。

しかもその業務プロセスは可視化されていなければいけないわけで、それができていないのにデータ分析しても、それは死体解剖をしているに過ぎず、解析が終わって原因が分かっても手の打ちようがないということになるわけです。

ここでも、こうして整理していくと情報システムに求められるものは何なのかが見えてくると思いませんか。

管理・統制機能

さてPとDときて最後のCになりますが、Cはそのままだと監視機能というのがいいのかもしれませんが、何か監査役みたいになるので、もう少し広く見て管理・統制機能としてみました。

ですから、どんな組織をイメージするかというと、管理会計とか固定費管理といったことを行う経理組織や労務管理とか資金管理といったリソース管理を行う人事、財務、それと監査、広報なんかも統制という意味ではそうかもしれません。

会社の事業執行の結果、ヒト・モノ・カネ・情報がきちんと生成され、また統制されているかを司る機能である。

ここは、意思決定プロセスは少なく、むしろデータや情報の管理といったことが重要となってきます。最近は、ストレージの容量が格段に大きくなってきていますので、莫大な経営データが蓄積できるようになりました。

しかし、今の状態ではそれらが埋もれてしまって取り出せない、また整理できる技術がないといったことになってはいないでしょうか。宝の持ち腐れです。そして、これからは単に数値データだけではなく、たとえば評判情報や企業サイドからの発信情報といった定量化できないものも扱う必要性が増しています。

実は、こうしたことの先駆はウエブなのであって、そういう意味でこれからの情報システムにはWeb技術の活用がカギになるかもしれません。

ところで、今までいってきたもので抜けているところがあるのがわかりましたでしょうか。

研究開発と従業員サービスがそうです。研究開発はどう考えたらいいのでしょうか。ひとつには、プロジェクトという位置づけにすることです。これまでいってきたのはルーティン化された機能を対象にしていますが、会社にはそれ以外に、テンポラリーに実施するプロジェクト業務があります。

ただこれも、事業実行が建設業やシステム開発のようにいつもプロジェクトである場合もあります。従って、研究開発はそういう位置づけでかまわないと思います。

従業員サービスというのはいかがでしょうか。これは、少し違っていますね。ただ、思うのは、従業員を顧客として定義したらどうだろうということです。そこへサービスを提供する事業だとも強引かも知れないが言えないこともないと思うのです。少なくとも、情報システムとしての見方はその方がいいように思いますがいかがでしょうか。

この管理・統制エリアでは、情報システムの役割はいかに大量のデータから有用なものを抽出できるかが重要であるといえます。
　

本社機能

近頃は、持ち株会社も増え、また子会社化も進んでいる。こうしたことは、中央集権的な形態へと動いていくのだろうか。

政治の世界もよく大きな政府か小さな政府かという議論が起きるように、企業も大きな本社か小さな本社ということを考える必要がある。

すなわち政治では、中央で政策や財源を統括してバラマキをするのか、中央はできるだけ小さくして、地方に権限を委譲し、規制を緩和して民間にまかすという選択肢である。これと同じように、企業でも本社でお金も握って強く制御するのか、事業部とか工場に権限を持たせ、ある程度裁量権を持たすことである。

これはどちらがいいかというのは難しい問題であるが、たとえば、事業が比較的少ない場合には、中央集権的に、多くなると分散させるというのは一般論としては言える。また、成熟した企業でオペレーション重視だと分散でいいが、研究開発型は集権的にやった方がいいという見方もある。ソニーが失敗したのはこの例である。

結局、事業の性格だとか、人材の配置、風土などが重なり合っているので、会社ごとでベストが違うという答えでしまらない話なのだが、よく考えてみると、前提として、複数の事業が見切れないとか、専門的だからといったことがあると思うのだが、そこの見方を変えてみたらどうなのだろうか。

いま言ったことは、ビジネスプロセスが可視化できていないということでもあるのだが、もしそこが見えるようになったらどうなるのだろうか。

経営トップがそれぞれの事業の帰趨がリアルタイム的に見え、そこの状況を事業部長と共有できるようになったら、分権がいいとか集権がいいとかというようなことはどうでもよくて、共同で事業を操縦するという姿が見えてくる。

そうなると、かなり柔軟な経営・事業運営の形になり、事業の性格や事業部長の能力、戦略などをベースにそれぞれの関わり方を最適化すべく変化させていくかもしれない。
　

業務システムはITだけではない

前回までは、「会社は何をしているのか」ということで、会社の組織や機能について議論してきた。そのとき、PDCを回すための構造ということと、意思決定を行うためのプロセスというような話をした。

この構造とプロセスというのは人間の体にたとえると骨格と血流のようなものだと考えている。形は骨で作られていて、活動は血流により行われている。臓器や脳は機能であり、会社では組織というふうに考えられる。

こうした会社としてやろうとしていることを実現してあげるのが業務システムである。そう会社を動かす仕組みと仕掛けこそ業務システムと呼ばれるものでしょう。この場合、業務システムは別にコンピュータを使うことを意味していない。むしろ、全部をコンピュータでやれるということはあり得ないのである。

そうであれば、まずはその仕組みと仕掛けはどうなっているのだろうか、あるいはどういう風に作ったらいいのだろうかというアプローチが正しいことがわかると思います。それを、この時点ですぐにコンピュータシステムはどうするのかというところに持って行ってしまう。これがいま開発者側の最大の誤謬であると思う。

そして、おわかりのようにそのシステムというのは、人間とITが融合した形でできています。この融合ということを考えたとき、どちらが主役であるかということが重要なポイントになります。言うまでもなく、人間が主役であるのですが、意外とそこがわかっていない人がいます。

人間が主役ということは、組織や人間が仕事がしやすいように、いい仕事ができるように、早く仕事ができるように、気持ちよく仕事ができるように、時にはITも使いながらできる仕組みと仕掛けを提供することです。

繰り返すが、この視点を忘れないようにしなくてはいけない。IT導入が仕事がしにくくなったり、ITに使われてしまうようなことにならないことに留意することが大事です。ですから、場合によっては、IT化しない方が効率的であるということもありえるわけです。

業務システムはストックとフロー

前回は、業務システムはITだけでできるわけではなく、ITをうまく使い人間が主役の仕組みと仕掛けをつくらなくていけないということを議論した。

今回は、その業務システムはどんなかたちになっているのだろうかという話です。前回、会社は骨格と血流でできていると書いたが、ちょっとこれでは抽象的なのでもう少し具体的に見ていこうということです。

ここで、まだ抽象的で恐縮ですが、“ストックとフロー”という話をします。どうも「仕組み＝システム」は、ストックとフローから成り立っているように思うのです。人間もシステムとすれば、骨格（＋筋肉＋細胞）がストックで血流（＋神経＋リンパ）がフローという風にいえないこともない。

会社のヒト・モノ・カネ・情報だが、それもストックとフローという面をもっている。人材、設備、資金、データベースなどがストックと呼ばれるもので、それらを動かす、人事、運転、販売、購買、売上、情報共有などがフローとなります。

こうなると、だいぶイメージがわいてくると思いますが、ストックというのは、まずはマスタデータが浮かんでくると思います。このマスタは、会社がビジネス活動を行うために必要な資源、すなわち駆動源です。商品、取引先、従業員、設備などのデータをいいます。

ところで、ビジネス活動をするためのものではなく、ビジネス活動を行った結果もストックと呼んでもいいのです。この結果を蓄積してデータベース化し、次の活動に生かすというのは、前に言ったPDCのCの部分、あるいはCからAへの重要な機能です。

次はフローですが、これはストックを使って、あるいはストックを動かしてビジネス上の成果をあげることです。ここが業務プロセスと呼ばれるものです。人を適正に配置することでプロセスを管理し、設備を効率的に動かすことで早く安く製品を作り、優良顧客を開拓して販売するといった活動です。

もうひとつ、フローという観点から見落とされがちなのは、ストックの管理プロセスです。近頃マスタ管理システムのようなものが出てくるようになりましたが、それに限らず、他の駆動源としてのストック、活動実績としてのストック、さらに暗黙知のような非ITのデータも含めて、これらの情報管理プロセスもきちんと整備しておくことが大事です。
　

構造化された業務システム

さて、業務システムの概観をいくぶん抽象的な表現で見てきましたが、ここではシステム的な観点を中心に考えてみます。

システムは大きくどういうものからなりたっているのでしょうか。前回にも少しふれていますが、プロセス・データ・機能・ルールから構成されていると考えています。この中で機能というがわかりにくいかもしれませんが、簡単にユーザインターフェースと思ってもらっていいかと思います。何かアクションを行うための仕掛けですね。

そして、重要なのはこれらを独立させることです。従来はこれらが一体になって作られたりしています。従って、データやルールが重複し、保守地獄に陥ったりしていました。最近のようなビジネス環境の早い変化に対する変更が大変だということはすぐおわかりだと思います。

ですから、独立したプロセス・データ・機能・ルールをコンポーネント化して、標準的なAPIで取り合うことが大事です。これをSOAというのかどうか知りませんが、必要に応じて、あるいは変化に対応して、すぐに取り換えるイメージになります。こうした構造化が大事なのです。

こうしておくと、システムはどんな作りになるでしょうか。まず、何を中心に考えていったらよいでしょうか。今はプロセスを中心に考えてみたらどうかということを提案しています。データ中心や機能中心（パッケージや手組はこれだと思う）はもう限界ではないかと思っています。

ただし、プロセス中心というと全部プロセスがあればできてしまうというような話ではもちろんありません。まず最初にプロセスを定義したらと言っているのです。仕事はどういう流れで成り立っているのかをプロセスを書くことで把握します。

そして、このプロセスを回すために何が必要かと考えるわけです。そのためには、データを参照します、ルールが要ります、機能を使いますということです。そのプロセスを回した結果としてデータを生成するのです。

ですから、みな大事な要素なのですが、どういう順序でシステムを考えていったらいいのかという話です。次回から、その中心となる業務プロセスについて議論していきます。
　

業務プロセスの定義

ここからはフローに焦点をあて業務プロセスについて考えていきます。まずは、業務プロセスの定義になるが、ここはまだ定まったものがない。だから、人によってその解釈もまちまちである。ここは「イノベーションの新時代」（C・K・プラハラード著）に出てくる定義を載せます。

①業務プロセスをできるかぎり広く定義すると、「一連のステップを実行して、特定の成果、あるいは互いに関連するいくつかの成果を生み出す活動」となる。

②業務プロセスとは、特定の顧客あるいは顧客層に向けて、具体的な製品やサービスを提供するための、互いに関連する体系的な活動の集まり、あるいは連続するいくつもの事象を指す。

③商売上の成果をあげるための手法を、業務プロセスと呼ぶ。業務プロセスはみな、投入と産出、手順の実行に先立って投入を用意し、決まった手順に沿ってそれに手を加えると、一定の算出が得られる。

④関係者が力を合わせながら、顧客に価値をもたらすために活発に展開する、さまざまな処理や取引など一揃いの活動。

⑤特定の顧客や市場に向けて具体的な成果を生み出すための、きまりに沿った体系的な諸活動である。つまり、順番に沿いながら、さまざまな場所で時間をかけて行われる一連の仕事を意味する。

みな微妙に違っている。それはこの本にも書いてあるが、人によって関心の対象が異なるからだ。業務運営の立場の人、BPRから見る人、コンピュータからの見方、組織行動として考える人など、それぞれで定義も変わってくる。

ということは、ケースバイケースで考えていいということであり、これでなくてはいけないという一義的なものではないということである。ただ、上の例でもわかるように③を除いて共通の言葉があって、それは「ビジネス上の成果をあげるための一連の活動」ということである。一方、③は手法と言っている。

おそらくこのようにビジネス活動とそれを実行する手法に大きく分かれるような気がする。さらに、その中でも、ビジネス活動といっても、戦略やビジネスモデルを含んだものから、単に決まった手順で行う業務処理まで広くある。

手法といっても、業務を行うためのプロセスの形そのものを指したり、プラットフォームのようなとらえ方もある。

結局、両方を加味したようなとらえ方が現実的であろう。ただし、ビジネス活動では、戦略やビジネスモデルまでを包含すると広げすぎで、手法では詳細なワークフローのようなものまで入れるとこれまた広げすぎのような気がする。

少し狭めた形で定義して、業務運営をしている人にとっては、「柔軟で効率的な業務プロセスを使って、ビジネスの成果を生み出す活動を行うこと」であり、システムサイドからみると「ビジネスの成果を生み出す活動を行うために、柔軟で効率的な業務プロセスを動かすこと」でいいのではないでしょうか。

まずはこの違いを認識してください。たとえばBPMの議論などでここを混同することがよくあるので、ときどきかみ合わないことがあるのですが、往々にしてあるのはこの相違によるものです。

業務プロセスの二面性

前回、業務プロセスの定義を行ったとき、ビジネス側からの見方とシステム側の見方で定義のポイントの置き方が違うということを議論した。すなわち、ビジネス活動と捉えるか、業務プロセスシステムと捉えるかである。

このことは、別段業務プロセスに限ったことではなく、ビジネスとITについて回る問題である。そして、これは対立する概念でも何ともなく、融合させるべきことなのだが、時として、争点になったりする。

こうした議論がなぜ生じるかは、既成の業務システムにおいて、ビジネス側とシステム側の意図と合致したものが必ずしもできていないことに起因している。だから、業務システムとはこういうものだという定義が相反しているわけでもないのに、結果的に対立してしまう。

ここで、原点に帰って考えてみると、何のために業務システムがあるのかという問題設定に対して、あたりまえにビジネスありきですと答えているのだろうか。そうであれば、これはまた、あたりまえにビジネス要求、業務機能をそのまま実装してあげなくてはいけない。

ビジネス側が、ビジネス上の成果をあげるためにこういう活動をしたいという要求があったら、システム側が、それを実現するための業務システム（業務プロセスより広い）はこうしましょうという関係ができていなくてはいけない。

どうもそこで相互不信がおきているようにも思える。システム屋は思ったようなものを作ってくれない、ビジネス屋はちゃんと要求を定義してくれないというわけである。本来は行き着くところは同じでそこを別のアプローチで到達するという協力的関係性を必要とするはずだ。

結局、業務プロセスは要求サイドからの定義と構築サイドからの定義という二面性があるが、それらは対立概念ではなく、お互いに乗り入れしながら、協同的プロジェクトとして作られていかなくてはならない。それをトップダウンアプローチとボトムアップアプローチと呼んでもいいが、どこかで出会うことが重要なことである。
　

業務プロセスの種類

ここからは、業務プロセスの種類について考えてみます。以前にこのブログでも書いたことがあるので、かなり重複しますが、流れ上必要なのでご容赦のほどを。

業務プロセスにはどんなものがあるのかを考えるには、企業におけるビジネス活動のタイプという見方で分けたらいいと思います。その3つは次のようなものです。

１）マネジメントプロセス（経営プロセス）
２）クリエーションプロセス（創造プロセス）
３）オペレーションプロセス（作業プロセス）

１）のプロセスは経営判断やリソース配分を行うものです。リソース配分というのは主に人材配置や事業ポートフォリオを指しています。経営者の重要な職務はこれで、乱暴に言うと、将棋指しが戦法を考え、それに従って駒を動かすようなものです。

このプロセスは、プロセスと言ってもかなりアドホックなもので定型化しにくい。ですから、システムに求められる機能はフローよりも意志決定に必要な情報をいかに選別して鮮度よく提供できるかになります。

クリエーションプロセスは文字通り創造的な活動を行うプロセスです。わかりやすいのは研究開発における新製品や技術の開発プロセスです。それ以外にも戦略立案なんかもこちらに含まれますし、顧客開発やプロモーション、あるいは建設などもこれにあたります。

システム的には、ターゲット決め、それを達成するためのプロセスをどうするかというアプローチになります。仮説検証型のプロセスですね。多くは、プロジェクト的な動きになりますが、だからといってプロセスがなくなるわけではありません。時間的なスパンが長くなるだけで基本的な考え方は同じでいいと思います。

一方、オペレーションプロセスは、ターゲットが設定されているのではなく、主として依頼があってそれに応える形でプロセスが動くというふうに考えられます。ですから、問題解決型ということになります。

よく言われる業務プロセスはほとんどがこのタイプです。このプロセスは、効率性と顧客満足度が重要な評価指標になります。お客さん（この場合、外部の顧客だけではなく、内部も含めて）の要望をよく吟味して、それに対する的確な答えを迅速に返してあげることが大事になります。

ただ、このオペレーションプロセスのシステムはそれだけではなくもっと重要な役目があります。それは、ビジネスの変化によってそのプロセスを素早く変更できるかどうかです。これについてはまた後述していきます。
　

業務プロセスと組織

業務システムは組織を表現しているともいえると考えています。特にその中の業務プロセスは最も組織と密接な関係にあります。ここで少し注意しなくてはいけないのは、そう言うと、組織に合わせてあるいは組織が活動しやすいように業務プロセスを配備するというふうに考える人がいますが、それは逆です。

業務プロセスありきから出発すべきだと思っています。企業のビジネス活動を行うためにはまずはその業務プロセスをデザインし、その業務プロセスが効率的に回るためのITの仕組みや組織や関係先とのネットワークなどを配備します。ですから、業務プロセスというものが非常に重要な位置を占めるのです。

そして、業務プロセスをデザインしたら、どのプロセスをどこの組織でオペレーションさせるか、その結果の責任を誰に担わせるのかということを考えることが必要になってきます。ですから、プロセスの切り方と組織の対応付けがちゃんとできていることが大事なのです。

実はここのところの考え方についての議論が乏しいように感じています。業務プロセスを書いたはいいが、それがあちこちの組織をまたがったものになり、いったいこのプロセス全体を誰が責任を持っているのかがあいまいになってしまう可能性があります。

なぜそういうことがおきるのかというとプロセスのレベルが細かくなっているか、粗いものと混在しているかです。BPMではスイムレーンというものを書きますが、いくつものレーンがあって、それを行き来するフローを書くことがあります。これでは、プロセスの責任の所在がはっきりしないということになりかねません。

とうことは、組織の階層化と対になったような業務プロセスの階層化が非常に重要な要件になると考えています。すなわち、管理する対象が階層化されているわけで、たとえばマクロレベルのプロセスについては、事業部長や部長が責任を負うが、その下のミクロレベルのプロセスについては、課長やグループリーダが責任をもつというイメージです。

冒頭に業務システムは組織を表現しているというのはこういうことを言っています。表裏一体となった関係です。見える化しなくてはいけないとか簡単にいう人がいますが、単にプロセスが書けただけではだめで、そのプロセスの責任も伴った見える化ということが必要なのです。

このプロセスの階層化と切り方という縦横の定義がキーになることがおわかりになったでしょうか。逆に、上述のような考え方に従って定義していけば比較的簡単にできそうだとは思いませんか。具体的には、後で議論していきます。
　

バーナードの組織論

これから、このシリーズで論旨と直接関係ないが、ちょっと横道にそれてみたいということについて、「閑話休題」として書くことにする。

古今東西で経営論や組織論について議論が戦わされているが、それと企業の情報システムとの関連性についてはあまり論じられていないように感じる。なぜなのかはよく分からないが、組織とシステムは表裏一体の関係であるといったとき、そうした組織論をシステムに反映することは大事なことのように思う。

これから、業務プロセスの本質は何かという話として、サイモンの意思決定プロセスが出てくるが、そのサイモンに影響を与えたバーナードの経営理論についても言及しておこう。

チェスター・バーナードは、アメリカの電話会社の社長だった人で、彼の理論では、組織を「孤立した人間の集団ではなく相互に影響を及ぼし合いながら成立する体系(システム)」ととらえている｡そのために必要な組織の3要素を、「共通目的」、「協働意欲（貢献意欲）」、「コミュニケーション（伝達）」であると規定している。

すなわち、メンバー間で相互に協力しあいながら活動するための共通の目的が存在しなくてはいけなくて、それがメンバーの合意が得られたものであることである。

そして、この共通目的を達成しようとする意欲が協働意欲（貢献意欲）である。これを維持するために、組織は、金銭的･物的誘因とともに社会的あるいは心理的誘因を、メンバーに対して十分に供与することが必要となる

最後のコミュニケーションは、前の共通目的と協同意欲とを統合する役割がある。意志決定や命令の伝達を適切に行い、個々人の意欲を共通目的を達成するための活動と結び付けなければいけない。

この3要素がうまく均衡がとれた状態であることが組織の成立条件なのである。そう考えてみると、これらの要件を満足させるための情報システムでなければならないと思うのである。

共通目的というのは経営方針や戦略から導き出されるとしても、協同意欲、コミュニケーションという要件では、そうしたことが実現できる場として情報システムを提示できているのだろうか。

単に、計算機の延長、データ登録・レポート出力のためのシステムにとどまってやしないだろうか。コンピュータそのものから発想していくとそうなってしまうと思う。

もっと、経営論、組織論からみて、いい経営をする、いいビジネス成果をあげる、いい組織を維持するにはどういった体系（システム）が適正なのかを考え、それを具現するための情報システムを構築するこということが求められているのではないだろうか。
　

業務プロセスのライフサイクル

業務プロセスにはライフサイクルがあります。ただし、業務プロセス開発のライフサイクルではありませんし、システムそのもののライフサイクルとも違います。ライフサイクルというと生まれてから死ぬまでといった短絡的なとらえ方をすることがありますが、もう少し、途中経過を注目したいと思います。

往々にして、情報システムを作るというと、システム開発を主眼に置くのが常のような気がします。システム開発プロジェクトを編成して大々的に始め、システムを構築したらはい終了ですということになっていないだろうか。

特にSIベンダーを入れてやるとこうした傾向が強いでしょう。SIベンダーはシステムを作ることがミッションですから、それが最大の関心事で、作られたあとどういうふうに使われているかは極端な話どうでもいいわけで、とりあえず動いてくれればいいということになります。

ユーザから見れば、最終的にはその仕組みでビジネス上の成果をあげることですから、作ったあとが問題なのです。どうもそのあたりの軸足の置き方がまだまだおかしいような気がします。これは、SIベンダーの問題ではなくユーザ側の意識の問題だと思います。

さて、業務プロセスのライフサイクルはどういう形態なのでしょうか。生まれるのは、もちろんビジネス上の要求からです。経営戦略を実行したい、こういう改革をしたい、競争に勝ちたいとかいった様々な要求を実現する仕組みと仕掛けを考えるわけです。それが出発点です。

そして、そのための設計を行い、その設計に従って開発していきますが、この開発という言葉が曲者で、ビジネスを開発するわけではありませんし、では業務プロセスを開発するのかというと、むしろそれは設計の問題であって、開発段階の話ではありません。ですから、システム開発というより、システム構築といったほうが的確なように思います。

いや、新しいプログラムを開発しますと言う人がいますが、そこをはき違えてはいけません。ビジネス上の要請でプロジェクト段階でプログラム開発してくれとは言っていません。

ちょっと話がそれたので元に戻すと、業務プロセスのライフサイクルで重要なのは、構築後のことで、出来上がったシステムを運用していかなくてはいけません。これも誤解しないようにしてもらいたいのですが、システムの運用ではなく、業務アプリケーションの運用です。このプロセス制御を伴った運用（オペレーション）が非常に重要になります。

このオペレーションのイメージは、プロセスがアクティビティという要素のつながりであるとして、そのアクティビティを早く適正に処理しするよう制御し、効率的プロセス活動を行うことです。そして、その進捗管理や成果の評価を行い、プロセスの改善を行っていくことになります。これが、継続的なスパイラルアップを実現していくわけです。

従来、ついついシステム開発に目が行きがちですが、そこは単なる序章ですから、そのあとの業務オペレーションを優れたものにするという取組が必要になるのです。
　

成長するシステム

前回「システムを開発する」という言い方には作って終わりという響きがあり、また、開発するときにちゃんと要求定義と要件定義をしなくてはいけないというようなことを書いたのでそのあたりについて考えてみた。

当然のようにだれもがきちんと定義されたシステムを開発することをめざす。しかし、最初からすばらしいシステムを作ることが重要だという思い込みははたして正しいのだろうか。

以前、会社の構造や活動を人間のからだに例えて、PDCを回すための構造を骨格、意思決定のプロセスを血流といったが、その人間でいえば最初から完璧な人間が生まれてくるわけではない。とりあえず基本的なことができ、だんだんと学習や経験を積むことで成長していく。

情報システムもそれでいいのではないだろうか。こんなことを言うと、ビジネスではそんな悠長なことを言っていられなくてすぐに実践で使えるものを提供してくれなくては困ると言われるだろう。

ちょっと立ち止まって考えてみよう。従来のやり方だと業務改革だとかいって、いきなり今までとぜんぜん違う業務システムになって、みんな戸惑ってしまいその移行に大変苦労している。そして、十分詰めたはずの仕様も使いだすとこんなはずじゃなかったとなる。

それなら、まずは今までとあまり変わらない仕事のやりかたでシステム化してそれを動かして移行する。その後、オペレーションしていくうちに改良点がみつけて、そこに変更を加えていくといった方法がとれないものだろうか。

そんなことはできっこないと言うのだろうか。そういうことを言っておきながら、イノベーションには素早く変更できる業務プロセスがカギとなりますなんて言う。この変化対応力に優れた業務プロセスというのは、言い換えれば成長できるシステムということができる。

ならば、最初から100点をめざす必要がなくなるわけで、だいいちこの環境変化の早いご時世では開発しているうちにビジネスモデルが変わってしまう。だから、アジャイルで素早く作らなくてはいけないという話がでる。

現状の仕事のやり方から逸脱することなく、初期システムができ、それが学習と経験により成長し、日々進化していくというシステムができたら、全くパラダイムが変わってくると思うがいかがでしょうか。

プロセス設計が変わる

ここからは、詳細に入っていきます。まずは業務プロセス設計という話になりますが、断っておくことがあって、前にも書きましたが、戦略的な部分には立ち入りません。プラハードの定義に従えば、業務プロセスは、「事業戦略、ビジネスモデル、日々の業務、この三者のつなぎ役」ということなのでこれをベースに考えていきます

すなわち、「事業戦略から生み出されたビジネスモデルを実行できるプロセスに落とし込み、それを使って日々の業務を実行できる仕組みと仕掛けを設計すること」と規定しようと思います。

そして、このプロセス設計のやり方そのものが変化していると考えていますが、そのあたりの議論をする必要があります。ここは非常に重要なポイントで、いや今までと何も変わっていないと言う人もいるかもしれません。いったいどこが変わるのかがわかりずらいと言われるかもしれません。

そうした考察を行うときに、WhatをそのままでHowの議論をしてやしませんかということを言いたいのです。どういうことかというと、従来のような業務システムの形であれば、確かにその設計のやり方はそう大きくは違わないでしょうし、どう作るかというHowの議論が大切かもしれません。

こうした議論はいろいろなところで多くなされています。今のシステムをどうしたら早く作れるかという開発生産性に焦点をあてた方向です。しかもプロセス設計というフェーズはありますが、業務フローを書くという程度で、設計よりもプログラム開発が中心になっているような気がします。

あるいは、パッケージを持ち込んでフィットギャップをどうやってやるかといったことを始めてしまい、自分たちのやりたいことをすでにあるパッケージでできるかできないかという議論になっていやしないでしょうか。

これまでの記事でも繰り返しているように、プロセスを中心に据えて業務を見ること、そしてシステムを作って終わりではなく、それを使ってちゃんと業務オペレーションすることが大事だということです。

そして、こうした考え方をもとにして作られたシステムは従来のものと違ったものになります。Whatが変わるのです。ですから、Whatが変わったらHowも当然変わってくるのはおわかりだと思います。

繰り返しますが、どうも今の論調は、現状のシステム構造をそのままで、その変わらないシステムの作り方を盛んに議論しているように思います。例えば、SOAやSaaS、あるいはクラウドといったトレンドを追うのも結構ですが、その前に、これまでビジネスに役に立たないシステムばかりを作っているという反省をWhatに生かさなければ意味がないように思えるのです。
　

役に立つためのシステムがもつべき要件

これまでビジネスの役に立たないシステムを作り続けたというようなことを書いたが、役にたたないシステムとはどんなものを指しているのだろうか。逆に役に立つシステムの要件とは一体何なのだろうか。

そこで一応つぎの3つを上げることにしている。

1．ビジネス要求をはじかないこと
2．とにかく安いこと
3．継続的な改善ができること

最初の「ビジネス要求をはじかないこと」というのは、こうしてほしい、こんな機能があるといいと言ったのにできあがったら実現できていなかったので使わないといったことがないようにという意味である。

ここには2つの問題があって、要求定義をしてもそれがどう実装されているのかを確認するのがずっと先になるということと、実現手段がないことがあるということである。実現手段がないならないと言わないといけないし、実現手段があったとしてもすぐに見せなくてはいけない。

つぎの「とにかく安いこと」は、単純に費用対効果がでやすいのである。しかも、投資絶対額が低いから経営も承認しやすい。

経営者にとって、投資額が高くなればなるほど慎重になるのは当たり前で、ただ慎重にということは、とりあえず作ってみてなんてことは許せないわけで、きちんとRFPを書いて、そして確実に動くことを保証してくれる、あるいは動かない場合でもちゃんと面倒をみてくれるところに頼むということになる。そして、必然的にそこにお金をかけざるを得なくなる。

これが曲者で、こうなるとますますシステムが確実に動くことが第一義になり、そのためにビジネス要求ははずされてしまうという弊害もでてくる。新しいことというのはやったことがないから、稼働が保証されていないわけで、それはやめてどこでもやっていることをやりましょう、それなら安全ですとなる。

その原因は、システム投資が高いからで、失敗したら大変なことになるから安全な道を選ぶわけで、それはビジネスの要求と相いれないことになる。ですから、たいした投資ではない、失敗してもそんなに痛くはないということであれば、チャレンジしたがだめなら役に立つまで作り直せばいいじゃないかということも可能なのである。

最後の継続的な改善というのは、作った当初のものが完璧なものではありえないわけで、そうなると運用しだしてから、手直しをしたくなってくる。それがたやすくできないと意味がない。その手直しが手間と金がかかっては、やれなくなって、そのままになり、結局使われなくなるという悪循環に陥る。

最初から100点を狙うから、がちがちのウオーターフォールでやらざるをえないし、要求仕様が決められないと言ってなげくのである。そうではなく、最初は、80点、場合によっては60点でもいいじゃないか、徐々に100点にもていけばいいのである。こうしたことができる構造のシステムを作ることが重要なのである。

HowではなくWhatですよと言っているのはこのことで、役に立つシステムにするには作り方ではなくどんなものを作るかがポイントである。
　

作るものが変わるから設計も変わる

前回、今のWhatに対するHowではなく、新しいWhatを考え、それに合ったHowを模索することが求められているという話をしました。ですので、ここではそのWhatについて考えてみます。

Whatすなわちどのような構造のシステムにしたらいいのだろうかということです。それを先に設定してからプロセス設計という手順もありなのですが、それよりも業務プロセスを設計して、それをそのまま実行できるものとして定義したほうがいいような気がします。

いま大変重要な曲がり角に来ていると思っています。それは何かというと、プロセス志向という流れが作られつつあるからです。BPMやSOAはそうした傾向を象徴しています。また、内部統制といった外的要因も絡んでプロセスの可視化が強調されています。

このプロセス志向という流れは、ビジネスの実態に合わせたシステムを作ることが企業としてムダな投資を避けるために不可欠であるということがわかり始めたのではないでしょうか。そのビジネスの実相に近い仕組みこそこれからの業務システムに要求されることなのです。

それがどういうものであるかを議論する前に、逆に既成の業務システムがどうなっているのかを検証し、その問題点を摘出していくという作業も必要かもしれません。何が問題でそれをどう変えて新しいWhatを作りだしたらいいのだろうか。

最大の問題は何かというと、従来型のシステムには“プロセスがない”ことです。これは、パッケージであろうが、手組であろうが同じです。正確に言うと、プロセスを回す機能がシステムに備わっていないということです。

従来型でも、パッケージ開発にしても、手組の開発にしても、パッケージにあるプロセスに従って、あるいは業務フローを書いてという風にプロセスを設計しているという声が聞こえてきます。しかし、それはシステム間をどうつなぐかといった観点からのフローになっているのではないでしょうか。

システムだけではプロセスを回すことはできません。実務における業務プロセスは人間が回しているのです。その証拠は帳票が依然としてなくならないということだと思います。画面間を紙が媒介して流れを作っているのです。

わかりやすく言うと、画面と帳票設計から入っていませんかということです。こうした作り方をするとどうしてもシステム主体になってしまいます。この場合の設計者の頭の中はいかにして後の財務会計につなげるかになっています。

ですから今の画面は、基本的にはデータ登録用のものです。それでは、そのデータをどうやって作っているのかというのが抜けています。実はそこにプロセスであるわけです。こうした変革のポイントを頭に入れてこれからプロセス設計のやり方を考えていきましょう。

プロセスの構造

前回までに、従来型のシステム構造から変えていかなくてはいけない、なぜならその既成システムにはプロセスがないということを指摘しました。そこで、プロセスがちゃんとある構造を見ていきます。

まずプロセスのプロセスたる所以は、始点と終点が明確なことと連続性です。ケミカルプロセスでいうと、原料の投入があって、単位操作を繰り返して製品にします。この場合、途中でどっかに行ってしまうことはありません。

自動車の生産ラインも同じように部品を組み立てて製品を作り上げます。これも途中で切れることはありません。情報システムも「情報」の生産ラインからなっていると考えられるわけで、そうであれば、一貫したプロセスがなければいけません。

そして、そのプロセスを考えてみると何から何まで一本のラインで流れていることはありません。それはできないことはありませんが、効率的ではありませんし、複雑になってわけがわからなくなります。部品の組み立ては別のところでやって、それを生産ラインから流れてくる本体に組み込むようなことを想像してください。

業務プロセスも同じように考えられます。それは、階層化という考え方になります。サブプロセス化とも言えます。粗く並べておいて、その中身の詳細は別のプロセスで行うという風な構造になります。

ここの2段プロセス化が重要なポイントです。マクロのプロセスとミクロのプロセスの組み合わせです。これは効率的というようなことは先に言いましたが、もう少しみていくと、プロセスの性格が違うことがわかります。

では性格の違いはどんなことでしょうか。いきなり言われてもわからないので、例を出しながら考えてみます。わかりやすい例で、「見積依頼プロセス」を想定してみます。ある商品の見積依頼がきて、それに対して、提供商品名、納期、価格を答えるというプロセスがあったとします。

マクロプロセスはいま言った順番がそれに当たります。すなわち、依頼受付－プロダクト確定－納期確定－価格確定－見積書提出となるわけです。しかし、これではいかにもラフですよね。そうです、このそれぞれにもプロセスがあると思われるでしょう。例えば、納期を決めるのにも在庫を確認したり、配送の予定を見たり、上長の承認を得たりといったことがあります。これが、ミクロのプロセスになります。

さて、こうしてマクロとミクロにわけてみてどう感じますか。性格が違うのがおわかりになったでしょうか。まずはマクロのプロセスは抽象度が高いですよね。ですから、これってどんな見積でもあるいはどこの会社でもほぼ同じようなことをしていることです。そして、順番もほぼ決まった定型的なものであることがわかります。

一方、ミクロのプロセスを見ると、これは見積の対象や会社によって違うのがわかると思います。納期の確定を例にしても、在庫品の場合と生産品でも違うし、確認する部署っだって違うし、順番があっても行ったり来たりすることで、何より人間の判断が入ってきます。非定型で人間系のプロセスであることがわかると思います。

こうして、性格に違うプロセスをいっしょくたにしないことが重要なのことになります。なぜなら、実現するITを性格の違いに応じて変えなくてはいけないからです。従って、必然的に2段プロセスになるということです。

そして、プロセスの始点と終点を明確したうえで、2段のプロセスを挟むという構造を目指していきます。
　

二段思考法

業務プロセスを二段の階層で考えようという提案をしているが、この二段思考というのは、業務プロセスに限ったことではなく、一般的にもよく使われているように思う。たとえば、経済学や量子力学なんかでもマクロとミクロという二段階の言い方がある。

また、あえてマクロとミクロと言わなくても、それと似たような思考態度がるのではないだろうか。このように、二段で見るということは、すこし大仰にはなるかもしれないが、鳥の目と虫の目のことでもある。

要するに大きく掴んでおいて、それぞれの構成要素を詳しく見ていくという姿勢のことである。別の角度から言うと、まずは方向性を示すことであり、そこに向かう動作はそれとは違ったものであるともいえる。このことは非常に重要なことで、何にでもあてはまるように思われる。

多少の飛躍が許されるなら、今注目の事業仕分けもそうかもしれない。この事業仕分けそのものはミクロプロセスなのであって、マクロの視点のものではない。だから、一部の人からのまともな批判は、この国をどうするかという大きな構想がない中で、枝葉を議論してもしょうがないじゃないかという。まさに、マクロプロセスが欠如していることに他ならない。

ですから、マクロとミクロの両方を押さえることとそのバランスをうまくとることがすごく重要なことなのです。このように、大づかみで本質的な根幹の理解をし、構造的な絵をかき、それを実行するディテールを精査するというアプローチである。

また、他のところでも、たとえば戦略と戦術といった区分けも同じようなことを言っているのである。ということで、この二段でものごとを把握するというのは優れたやり方だと思っている。整理されてわかりやすいという意味が大きい。

こうしたことから、業務プロセスにおいても、事業オペレーションという視点と、そのための個別アクションを分けて考えることの大切さを提起しているのである。

プロセス設計アプローチ

これまでの議論の結果、現状の抱える課題を解消するには、プロセスをちゃんと設計して、そのプロセスがシステムとして途切れず動くことをめざすべきだということになります。従来のように画面の設計から入るのではなく、まずは業務プロセス、仕事の流れを先に書けということです。

そのプロセスを書くにあたって留意することは、ITを意識するなということです。業務プロセスは、個人あるいは組織としての活動ですから、ITがあろうとなかろうと厳然と存在するものです。ですから、そうした観点からあぶりだす必要があります。だからこそ、画面から入るなと言っているわけです。

さて、ここでプロセス設計への入り方をみていきましょう。そこには、トップダウンとボトムアップの両方からのアプローチがあるように思います。

トップダウンというのは、事業プロセスのような大きな抽象度でくくったプロセスからだんだん分解していくやりかたです。この場合は、高いレベルだとモデル化できるのでそうしたモデルを参照するのが有効な手段になります。

一方、ボトムアップというのは、日々の業務からその仕事の流れを引き出してきて、それらを結合させて、プロセスにしていくというやり方である。ただ、これは現状の業務の拾い出しなので、新規業務についてだとか、抜本的に業務を変革するとかいった時には難しい。

これは、いずれがいいという問題ではなく、おそらく両方向からアプローチするハイブリッド型が実務的であると考えられる。すなわち、トップダウンでモデル的かつ網羅性を勘案したプロセスを素描しておいて、実行ベースのプロセス落とし込みはボトムアップ的にやるという風なことである。

これは、トップダウンアプローチにはリファレンスモデルを利用するのが有効だが、そうしたモデルというのは概して、レベルの高いところのものしかないという制約も影響している。共通的に、あるいは標準とするにはいたしかたないと思われる。

このハイブリッド型のアプローチのキーポイントは、上からと下からでどこで出会うかということである。業務プロセスはアクティビティをつなげたものであるという定義にすると、そのアクティビティの粒度と性格をどうマッチングさせるかということである。
　

プロセスの設計アプローチの実際

さて、前回プロセス設計にトップダウンアプローチとボトムアップアプローチがあって、その両者を融合したハイブリッド型のアプローチが現実解であるという提案をしました。ただ、それだけではまだ具体性にとぼしいと思うので、実存するツールや技法でもって説明してみようと思います。

前回の説明にもあったように、トップダウンというのは上流の戦略的なところから分解していくことで、ボトムアップはAsIsの日常業務から抽象度をあげていくといいました。そこをもう少し掘り下げてみます。

まず、トップダウンと一口で言ってもたいへん難しい。なぜなら、ビジネスモデルを業務プロセスに落とし込んでと言ったところで、そのビジネスモデルっていったいどうなっているのということなのである。そりゃあビジネスモデル学会というのもあるくらいだから確立しているかもしれないが、少なくともITに落とし込むという観点からは議論が薄いのではないだろうか。

ビジネスモデルのフレームができて、それをある程度ロジカルにプロセスに落すということをどうやったらいいのかである。参照モデルがないことや競争優位をどこに求めるかなど難しいのである。ここについては、別の稿で書いてみたい。

さて、新規ビジネスの場合でその戦略・ビジネスモデルからというアプローチ以外を見ていくと、既存の業務システムの刷新や改善といったことと、まだITが導入されていない領域でのシステム化がある。

こうした領域へは、プロセスをスクラッチから掘り起こす技法が肝になります。具体的に言うと、日常の業務行動からプロセスとデータ・ルールを引き出してきて、それを論理的な構造へ変換しプロセス化するものです。

その際、網羅性と標準化をチェックするためにリファレンスモデルを参照します。ただし、そのリファレンスモデルは、下から上がってプロセス化したものと同じレベルのものでなくてはチェックできませんので、そこまで分解されたものでなくてはなりません。また、そういうものであれば、上記の技法でモデルからトップダウン的にプロセスを起こすことが可能になります。

これができるものを探してみましょう。初めの日常の業務行動からプロセスとデータ・ルールを引き出す方法は「マジカ」です。なぜマジカなのかというとやさしいからです。日常の業務をやっている人が書けなくてはいけないという意味でマジカなのです。他にもありますが、作り手側の論理を前面に出しているためエンドユーザにとっては難しいものばかりです。

一方、リファレンスモデルはどうでしょう。世の中には多くのモデルがあります。しかし、それはおしなべて抽象度の高いものになっています。それはしかたないことで、大多数が共通で使えるものでなくてはいけないわけで、固有性を排除した形にするとおおぐくりのものしかできないのです。

そこで、「ESCORT」です。これは、SCORのレベル3モデルをさらにレベル4まで分解しています。そのレベルまで落としてくれるとプロセスの粒度がそろってくるのです。

そして、この両者をつなげられるのが「Kailas」です。ボトムアップ的にプロセスを作りたかったら、マジカから上げる、トップダウン的にリファレンスモデルをベースに下げてくるのなら「ESCORT」を使うということになります。

ボトムアップでは」、「マジカ」で吸い上げた業務行動の4コマ漫画を並べてフローにしたものや成果物から、依頼受付と単位意志決定、そして報告・登録というアクティビティを抽出・整理してプロセス化します。

トップダウンでは、「ESCORT」のプロセス詳細記述書の内容が基本的にアクティビティのプロパティになるので、その並べ方とデータ項目をKailas Designerで記述し、その他の情報はKailas Webで設定することでプロセス化できます。
　

プロセスの設計作法

「Kailas」におけるプロセス設計の手順についてです。手順といっても詳細なものがあるわけではありません。できるだけシンプルなものにしたほうがいいと思っていて、どんなものに対しても大体同じであるという意味で“作法“と言ったほうが適切かもしれません。

なぜシンプルになるかというと、プロセスの構造がシンプルだからです。これまで議論したように、プロセスは性格が違うものを分けて考えることで2段プロセスになると提案しています。上位のプロセスは、依頼受付をして意思決定を連鎖させ、報告・登録をするというマクロフローとして定義しました。

下位のプロセスは、単位意志決定を起案－確認－確定－承認というミクロフローであるとして、それらは、人間系であいまいさを抱えているため、行ったり来たりしてもいいように情報共有の場で実行させることと規定しました。

この考えに基づいて、まずはマクロフローの設計をしてみましょう。プロセスを大きく捉えると、最初に何らかの依頼が来ます。これは外部からも内部からも、そしてシステム的にあるいはスケジュール的にやってくることもあります。しかし、いずれにしろ、プロセスの始点は「依頼受付」です。

そして、この「依頼項目」について答えていくことになるわけで、それが単位意志決定で、そのあとに作業があって、その結果を報告・登録するということになります。単位意志決定が中間点で、報告・登録が終点になります。

ですから、プロセス名を付けてそのプロセスの始点を決め、そこにある依頼者の特定と依頼項目（答えるべきデータ項目）を定義します。たとえば、見積依頼プロセスと命名し、依頼者名・所属・所在地、依頼日などと、堤供商品名、価格、納期などになります。

つぎに単位意志決定では、アクティビティ名を付けて、そこで確定するデータ項目を定義します。たとえば、納期確定というアクティビティであれば、納期になります。終点の報告・登録では依頼に対する答え、すなわちそこまでに確定したデータが定義されます。このデータのデータ型やデータ長などのバリデーションのための制約も定義しておきます。

これで、プロセスが書けることになりますが、もうひとつ大事な定義があります。それは参照情報の定義です。単位意志決定というアクティビティでは、何もなしに決めているわけではありません。必ずと言っていいほど何らかの情報を参照しながら意志決定を行っています。参照情報には、業務ルールであったり、各種のリソース状況、計画・履歴データ、シミュレーション結果、契約・規制値など様々な種類のものがあります。

単位意志決定の各局面でどんな情報を見ているのかを定義するわけです。そして、その実体がどこにあるのか、内部のデータベースなのかそれと外部からSaaSとして取得するものなのかといったことも定義しておきます。

マクロフローはもうこれで終わりです。簡単に言うと、プロセスの始点と終点を決め、中間の単位意志決定の確定データを特定し、それらに使う参照情報をリストアップするというだけです。

一方のミクロフローはどうでしょう。ここでは、ロールの設定を行います。ロールには、起案、確認、確定、承認を誰にやらせるのかということです。実はこれとてもマクロフローで設計してしまってもかまわないので、実質的にミクロフローで設計することはないとも言えます。

以上が、「Kailas」におけるプロセス設計のやりかたです。たったこれだけと思われるでしょうが、最低限のオペレーションはこれでできます。もちろん、ここから、各社の固有性を盛り込むのはいっこうにかまわないわけなのですが、大事なのは、基本部分と応用部分は分けて考えないといけないということなのです。

まずは基本を押さえて、それから応用問題に入り、さらに飾りや癖などを表現するということが非常に大切な作法になります。しつこいようですが、基本はマクロフローの定義です。“何を依頼されて、どう答えて何を報告するか”をきちんと書くことなのです。
　

2段プロセス化のもうひとつの理由

前の記事で、プロセスを分解あるいは抽象レベルを上げていくと、性格が違ってくるという話があって、だから2段プロセスで考え、プラットフォームも分けましょうということを書いた。ここでは、さらにもうひとつの理由について考えてみましょう。

それはどういうことかというと、プロセスのレベルによって、それを管理し、責任を持つ人も違ってくるのではないかということです。別な言い方をすると、組織における職位によって、その人が責任を持たされるプロセスレベルは違うのではないかということです。

現状をみてみると、どうもそのへんがあいまいになっているように思えますがいかがでしょうか。部長が面倒みるべきところを課長がやっていたり、その逆で部長なのに現場の細かいところまで口を出すといった話をよく聞く。

ですから、あなたが責任をもってもらうプロセスレベルはこれですと言ってやらなくてはいけない。これまでプロセスという観点が乏しいからこうしたことは難しかったかもしれないが、これからプロセスを重視するということはこのようにプロセスと管理責任ということを意識させることでもある。

ところが、単にプロセスを作ればいいやになっていると、いくらプロセス重視といったところで、誰がどこまで見るのかがわからないという事態になる。プロセスと組織のヒエラルキーは対になっているという認識を持つ必要がある。

2段プロセスとしたのはこのこともあるわけで、マクロレベルのプロセスは、だいたい部長か課長レベルのもので、ミクロの領域はグループリーダぐらいの位置の人の範囲であろうと思う。たとえば、見積依頼プロセスであれば、見積書を出すまでの全体の責任は、営業部長の責任で、納期を決めるのはグループリーダの責任といった感じです。

ですから、ITの役割は、それぞれの責任あるひとが責任ある意志決定を行えるように、その人の責任となっているプロセスを彼の手のひらに乗せてあげることなのです。
　

これからの業務システムは何を志向しているのか

ここでは、業務システムそのものがどう変化していくのか、どう変えていくべきかを議論していきます。それには、「Kailas」のコンセプトを語るのが話が早いと思います。

「Kailas」の主要なコンセプトは次の3つになります。
１． プロセス志向
２． オペレーション志向
３． コラボレーション志向

最初のプロセス志向ですが、すでにこの前の章で業務プロセスのことを書いてきましたので同じことかと思われますが、少し違っています。先に議論した「業務プロセス」はここで言うプロセスよりももう少し広く、ビジネスを実現する仕組みや仕掛けとして見てきました。ですから、システム的な観点ではなくビジネスの視点からの議論でした。

ここでは、業務システムを考える上でのコンセプトのようなことを言っています。従って、プロセス志向というのは、業務プロセスありきからシステムを見ていこうという姿勢です。機能ではなく、データではなく、プロセスを中心にしようということです。昨今のBPMやSOAはこうした流れを象徴しています。

ところが、このプロセス中心だけでは片手落ちで、どうもプロセスを作って終わりといった感じになっているように思えるのです。プロセスは、動かしてナンボ、そしてそれをどう動かすのかで価値が出てきます。そういった踏み込みが足らないと思うのですがいかがでしょうか。当たり前の話として、システムの目的は正しいシステムを作ることではなくて、ビジネスに貢献できて初めて目的が達成できたことになります。

このことは2番目の「オペレーション志向」ということを言っています。できたプロセスをどうやって動かすのか、運営するのか、ビジネス上の成果をあげるのかが焦点になるわけです。従来のシステムでは、このオペレーションという意識が低く、単なる金銭登録機あるいはレポート出力機になっていやしないでしょうか。

業務システムの再定義と言っている意味のひとつはここです。システムをもう少しダイナミックなものとして扱おうよというメッセージです。目的地に向かって自動車を運転するように、ビジネスのゴールに向かってITシステムを運転しようよということです。

従って、賢い読者はおわかりのようにビジネスのなんたるか、業務のなんたるかを知っていないと設計できないわけで、既成のSIベンダーでは、そこの感覚が決定的に不足していると思いませんか。ただ、業務経験の有無のことを言っているわけではありません。そういうセンスを磨いていたかということだと思います。

3つ目のコラボレーション指向というのは、仕事というのは昔から協同作業として行われていました。それが組織でもあったわけです。しかしながら、コンピューターによるシステム化によって、そうした協同作業の様態が崩れているように思うのです。ですから大げさかもしれませんが、そうした協同的な場を提供しましょうということなのです。
　

感知－判断－アクションのトライアングル

ここからは、オペレーション志向に基づいて、どんな機能や構造が必要なのかというオペレーション設計について考えていきます。おそらく、こういう概念で設計するといったことはあまり聞いたことがないように思います。部分的な機能を使えとか、はめ込むことはするが、全体構成をデザインすることはないのではないでしょうか。

以前、業務プロセスの定義について書いたが、狭義のものと広義のものがあることがわかる。狭義のものは、簡単にいうと、決められた手順に従って、業務処理を行って、所定の結果を出すことであるが、もう少し、ビジネス上の諸活動を含めた広義の規定をした方がいいように思う。「ビジネス活動」に主眼を置いた考え方（オペレーション志向）である。

そうなると、ビジネス全体をどう動かしていくのかといったスコープで見て行くことになる。なぜそう思うかというと、以前に言ったようにBPMだとかBAM、BRM、SOA、SaaSとかいう言葉を断片的にとらえる傾向があるからである。それぞれを取ってみて、プロセスをどうする、ルールをどうするというふうな議論をしても仕方がないのではないかということである。

ですから、それらを総合的、構造的、有機的にとらえることが大事だと思う。ただ、その中でも中心に置くのはプロセスであることは言うまでもない。なぜなら、最終的なアクションに落とし込むのはプロセスだからである。

ですから、プロセスが機動的かつ効率的に動くために周辺の機能があるという考え方である。そこで、前述した3文字熟語をみると、Monitoring、とかRuleといった言葉がポイントになる。従って、“活動（オペレーション）“というのは、結局、何か起こったことを感知し、それをどうするかを判断して、アクションを起こすということになるのではないでしょうか。

感知－判断－アクションという三角関係がイメージされます。これが、従来になかった視点であって、オペレーションをしっかりやることが大事であるということを意味しています。

さて、このことは再三指摘していることなのですが、生産プロセスを想起させられるのである。ただ、これまではどちらかというと、業務プロセスも生産プロセスも同じプロセスがあるといった程度の見方でしたが、もう少し、制御とオペレーションということに踏み込んでみたいと思います。

感知－判断－アクションはまさにケミカルプラントのコントロール＆オペレーションそのものだからです。かなりの共通性を有しているといえます。

さて、これまでの業務プロセスでは、単にプロセスを実行すること、そしてその結果を登録することが主眼になっていたように思います。それでも良かったのです。従来のビジネス活動では、それほどスピードやリアルタイム性を要求されていなかったのです。

ですから、スタティックな動きでも何とかなったのですが、今では全く違ったスピード感が要求されているように思います。そうしたとき、現に起こっていることを素早く感知して、その事象に対して、迅速にかつ的確な判断を下し、しかるべきアクションを誘導するという一連の動作が重要になってきます。

連続系のケミカルプラントでは、原料を投入すると、それらを分解、分離、合成、添加などの単位操作の連鎖により製品が生み出されます。これがプロセスで、単位操作がアクティビティに相当します。

そして、この単位操作は、加熱、冷却、圧縮などのアクションで実行されていきますが、そのとき、単位操作の前の流体の状態を感知し、それによってどういうアクション条件にしたらよいかを判断して、その値を投下します。多くは自動制御という形でなされ、同時にその制御の結果も感知してフィードバックによる修正動作もおこないながらオペレーションを行うわけです。

おそらく、これからの業務プロセスにおいても同じような考え方でコントロール＆オペレーションが行われていくような気がします。プラントオペレーションではもっと進んでいて、さらに広い範囲での状態検知をして、最適化の制御が行われています。例えば、コスト計算をして、コストミニマムモードにするとか、そうではなくプロフィットマックスモードにするとかといったマクロレベルの複合的なコントロールである。

こうしたエンジニアリング的思考は何も金融工学だけではなく、もっと基礎的な理論でいいのでそれを業務プロセスコントロールに持ち込むのも必要ではないかと思うのである。
　

何を測定するのか

前回、感知－判断－アクションのトライアングルという話をしました。そのなかの感知ということについて考えていきましょう。センス＆レスポンスという言葉を聞くことがあります。何かの事象を検知し、その状態によって適切な答えを導き出し、対応するということになります。まさに、そのセンスのことです。

一見簡単そうですが、けっこう難しいのが、何を測定するのかということと測定できるのかという問題です。やたら測定するわけにはいきませんから、“そこの値”を測定するちゃんとした理由がなくてはいけません。

そこは、後ろから考えていきます。すなわち、そのプロセスのパフォーマンスは何で測るのかという問いから見ていきます。そして、これもトップダウン的なものとボトムアップ的なものがあります。

トップダウンというのは、戦略実現のためのパフォーマンスチェックです。よくやられるのは、バランススコアカードから導出されたKPIやKGIになります。ただ、これはそのままというわけにはいかないので、プロセスの測定値や計算値への翻訳が必要になります。

一方、ボトムアップというのは、オペレーショナルな意味合いのもので、どんなプロセスにもデフォルトで備わっているべきパフォーマンスで、基本的にはQCDFになります。すなわち、早く低コストで質の高い、そして変化対応力のあるオペレーションをしているかということです。

この二通りのパフォーマンス管理を分けて考えたらいいと思っています。ボトムアップはそう難しいことはなくて、早さは各意思決定のスピードを、コストは人数☓時間（これはABC：Activity Based Costingですね）をみます。では質はどうして測ったらよいのでしょう。ここでは、手戻り率を採用しています。意志決定の質でもあって、これが悪いと後工程から戻ってくるからです。

変化対応力はどうでしょうか。この場合の変化とは不確定な要求がくることですから、それにいかに迅速に応えるかということになります。おそらく応え方は、フローの順番を変える、意思決定の基準を変えるといったことかもしれません。

問題は、これを最初から予測してあらゆるケースを作り込んでおくかですが、そんなことは不可能です。では実際にそういう状況になった時にいちいちコードを書き足したり、変更したりすることでしょうか。それでは変化対応力があるとは言えません。

結局、そこが重要なところで、作り方になるわけで、コードを書かずに部品（コンポーネント）の差し替えといったことが可能なPluggableな構造にしておくことです。雪道になったらスノータイヤに取り換えて運転するといったイメージですね。
　

BAMとBI

前回は、センス＆レスポンスで何を測定するかが大事であるという話をしました。この場合は、ある時点で起こる事象（イベント）を検知するとしていました。これは、いわゆるBAM（Business Activity Monitoring）と呼ばれるものです。

これは、リアルタイム的に即座に反応しアラートなどを発信することです。最近のビジネス環境ではこうした俊敏さを要求される機会が増えてきています。ただ、あまり過敏になるのもどうかと思います。まあ、業種にもよりますが、即時性が求められるのは進捗管理で問題が発生したときぐらいだと思います。

それと、前回にKPIやKGIから落ちてきてというような話もしましたが、実際問題として、KPIやKGIでそんなに即時性を要求されることはあるのだろうか。もちろん緊急事態とか顧客対応とか言ったことは当たり前として即時対応なのですから。

もう一方のBI（Business Intelligence）はどうでしょうか。最近は、CPM (Corporate Performance Management)と言うそうですが、要するに、データウエアハウスに格納されたデータを分析してレポーティングするといったことです。

これは、以前からやられていましたが、いまいち効果が疑問視されていました。それはなぜかというと、プロセスがきちんとできていないのに結果だけを集めたところで、そのデータがどのようにして生まれたのか、その解析結果をどのようにして活かすのかができなかったためだろうと思っています。

ですから、BAMとBIの違いは、「死体解剖」と「生体ドッグ」ということです。すなわち、過去の履歴を分析しレポートするBIは死体解剖的で、現在の状態を分析し、アラートを発するBAMは生体ドックというわけである。

これはどちらがいいということでははなく、どちらも必要でうまく使い分けをすることが大事なのである。これまではどちらかというと、BIの方が使われていましたが、ここへきてBAMの機能が使われるようになったのではないでしょうか。そのための前提条件は、プロセスをきちんと設計し、オペレーションできてこそ初めて生きてきます。

そして、これからのセンス＆レスポンスについてですが、単なるデータやイベントだけでなく、ビジネス活動の経過だとか、個別の顧客に対する対応結果だとかといった事例実績をいろいろな要素から分析したものをベースに、その条件に類似のビジネス活動が来たときにどう対処したらいいいかをレコメンドしてくれるといった機能も出てくるように思います。

プラント制御の世界でDMC（Dynamic Matrix Control）というのがありますが、それと似たようなもので、さまざまな角度から状態を感知して、そこから最適な解をみつけ、動的に制御していくという考え方で、これをビジネスプロセスにも適用すると面白いと思います。
　

ユーザインターフェース

オペレーション設計で重要なものとしてユーザインターフェースがあります。プラント制御の世界などではマンマシンインターフェースとも言っています。人間と機械が接するところです。そこを使い勝手のよいものにする必要があります。そうでないと、誤操作をしたり、操作が遅れたりします。それは事故を招いたり、大きな損害を生むことになるのでとりわけ重要視されるのです。

ところが、業務システムのユーザインターフェースはそうした重要性を意識しているでしょうか。おそらくオペレーションという捉え方が希薄であるため、それほど重要視されていなかったのではないかと思います。

顧客とのインターフェースあるいはグループウエアのようなものではそうした配慮があるのですが、生産、販売、購買システムとか会計のようなところでは、データ登録画面、帳票出力画面、検索画面を用意すればいい程度で考えられていたのではないでしょうか。

ところが、オペレーションという概念でみていくと、操作性がすごく大事であることがわかります。すなわち、操作がわかりやすく簡単なのか、間違わないように安全にできるのか、質の高い操作が可能なのかといった使う人のためになるようにちゃんと設計されているかである。

ちょっと話がそれますが、こうしたインターフェースの設計に工業デザインの考え方を持ち込むべきだと思っている。そのくらい気をつかうべきだと言いたいのです。ユーザビリティの向上は、仕事の質をあげ、ビジネス上の成果をあげることにも寄与できると思うのですがいかがでしょうか。

さて、これまでの業務システムの画面をながめてみてください。画面名称をあげてみればわかるのですが、「受注登録」、「受注検索」、「受注帳票出力指示」、「出荷一覧」、「出荷予定検索」、「受払表出力指示」などなどです。どうです、なんか先に書いたように登録、帳票出力、検索といった機能が画面に反映させているだけです。

これで、業務プロセスをオペレーションできるのでしょうか。例えばあるオーダーが来てそれに対して在庫を引き当てて、出荷してという一連の動きが見えているのだろうか。これでは、データをコンピュータに打ち込んで、そこに格納された情報を見たり、紙で印刷したりすることが主眼の仕組みのようにみえてくる。

従って、ユーザインターフェースという観点からみると、まるでATMあるいはネットバンキングに近いように思える。しかし、日常の業務はもっとダイナミックに流れているはずで、その流れを監視して、正しくスムーズに流れるように操作するというのが仕事のように思う。そうしたことができるように、従来のユーザインターフェースは見直されてもいいはずなのである。
　

コラボレーション

最初に、プロセス志向、オペレーション志向、コラボレーション志向ということを書いた。この最後のコラボレーション志向ということである。これは、主にオペレーションとくにユーザインターフェースに関係するので、ここの中で議論することにする。

前回の、画面の話で画面名の例をあげて説明したように、これまでのような登録、出力、検索を主体では組織としてどう動いているのかが見えないと思う。むしろ、個人が画面に向かって、データを登録して、帳票を出力してといった動作がイメージされる。

結局、伝票のような紙を回すことでプロセスを確保しているように思える。そんな姿からは、コラボレーションという仕事のやり方は消えています。コラボレーションというのは、利害を同じくする複数のひとたちがビジネス上の目的に向かって、お互いにコミュケーションを図りながらよりよい解決策をさぐりあてて実行することだから、それには不適であることがわかると思います。

そして、今言ったようなコラボレーション型の仕事の進め方こそ、現代の複雑化し、スピードを求められるビジネス環境下では絶対に必要になってくるはずである。では、もう少しコラボレーションのメリットについて考えてみましょう。

・ 意思決定の質があがる
・ コンプライアンスにもなる
・ 技術伝承ができる

といったことがあげられるでしょう。コラボレーションは、いろいろな人の経験、知識、ノウハウなどを動員することによって、いい意思決定を行うことができます。Web2.0でいうところの参加型のアーキテクチャによる集合知が発揮できるのです。

コンプライアンスになるというのは、意思決定の過程が見えているわけですから不正はできないわけです。よほどみんなが結託してやればできないことがないかもしれませんが、アーカイブされますし、そもそもメンバー選定で注意できるはずです。いい意味の衆人監視社会ですね。

最後の技術伝承ということは、お分かりのようにコラボレーションの場に経験豊かなベテランを配しておき、ところどころでそのノウハウを吐き出すようなアドバイスをしてもらうことである。もう定年退職で辞めてしまうので、それまでにあなたの持っている経験やノウハウを紙に書いて残してくださいと言ったところで、おそらくそんな奇特な人はいないと思う。

それを、実際の日常業務遂行の場面に引っ張り出しておいて、若手が処理しているのをみて、それはおかしいとかこうしたほうがいいといったコメントを残して、それをデータベース化するということが最も効果的な技術伝承だと思うのである。

こうした仕事のやり方は年代間や部署間の関係もスムーズになるわけで、不機嫌な職場からの脱却のひとつの手だというのは言い過ぎだろうか。

グループウエア

前にコラボレーションの必要性を述べたが、そういうとグループウエアでもすでにやられているじゃないかという反論が返ってきそうである。そこで、グループウエアというか、もう少し広くフロント系のツールという捉え方で考えてみたい。

フロント系のツールやソフトウエアはコラボレーションを謳ったものなのですが、ちょっと考えてみると本当にそうだろうかと思ってしまう。何が問題なのかというと、どうもそのツールやソフトウエアを使ってやっていることが、会社の業務であるという感覚が薄いのでないかということである。

例えば、情報共有するとか、ナレッジマネジメントを行うこととかコミュニケーションを円滑にすることとかいったことを目的化してしまうのである。おわかりだと思いますが、今の話は手段のことですよね。

ですから、情報共有したほうがうまく仕事が運ぶ、ナレッジを蓄積し、それを生かしたほうが質の高い業務が行える、コミュニケーションを円滑にしたほうが早く仕事がこなせるといった合理性があるからやるわけである。

もしそういう必要性がない、例えばワンマン社長の胸先三寸でやってしまうほうがビジネスはうまくいくなら、そんなカッコいいことはやらなくてもいいのだ。ここで何を言いたいかというと、会社としてやらなくてはいけないことは何かが先にあって、それを執行するために必要な効率的手段は何かというふうに考えるべきなのである。

ということは、最初に考えるべきは、ビジネス活動はどんなことをしているのかということだ。ビジネスは簡単に言うと自分たちの製品やサービスを売ってお金を稼ぐことだ。（ところで、このお金を稼ぐこと、儲けることが悪いという人がいたりするが、その話はややっこしいのでここではしない）

そして、企業ではお金を稼ぐために様々な局面で多くの業務プロセスが走っているわけです。主たるところでは、注文をもらって、その注文に対して、「ヒト・モノ・カネ・情報＋サービス」を提供し、その対価として最終的にお金をもらう営みです。

それを最小のコストで最大のメリットを得ようと努力します。（これで成功したのがユニクロですが、これも非難するおかしな人たちがいます。この話もここではしません）ですから、最初に言ったように“そのために”情報共有が、あるいはナレッジマネジメントが必要なのかということなのです。

ということでお分かりかと思いますが、フロントエンドの問題はそういった機能が、業務プロセスの中に組み込まれてこそ効果を発揮するのです。手段は合目的であるかどうかの基準で選択されるのであって、それ自身を導入することが目的化するのは避けなければいけないのである。
　

見える化と見せる化

近頃、いたるところで「見える化」という。「可視化」ともいうが、本当に「見える化」を目ざしているのだろうか。どうしてこんなことを言うかのというと、実態は「見える化」ではなくて、「見せる化」になっているのではないかということである。

「見せる化」というのは文字通り“誰か”が、「見える化」できるようになりましたよと“見せる”ことで、どうもこんなことが多いように思える。何をしたいかから、何をみたいのかが決まるのに、これを見れば「見える化」ができますよというのは本末転倒ではないでしょうか。今の業務システムの発想はほとんどこのパターンになっています。

それが全面的に作り手側に問題があると言っているわけではありません。当然使い手側もこれがみたいという要求を出していないのです。

そして、可視化は基本的にはいいことなのですが、ある種の痛みをもたらします。昔は、エンピツをなめるという言い方があるように、わからないところで細工をするということもあったわけで、現代ならさしずめキーボードをなめるとでもいうのだろうか。

そんなことができなくなるのです。そうです、これからはそんな世界ではなく、あからさまになっていくことが合理的であるという感覚をみんなが感じ取るようになるでしょう。隠して何かしていたら、競争にも勝てないし、組織能力にも影響を及ぼすという自覚的な雰囲気を作ることだと思います。

ですから、見える化というのは簡単に言えば、次にどんな手を打ったらいいのかが、組織として見晴らし良くわかるということのように思えます。そうした景色を共有するためには、やはりプロセス中心で考えていくべきだというのが従前からの主張なのです。

ただし、ここで間違ってはいけないのが、一体みなさん何が見えたらいいのか思っているのかということです。それは、仕事の中で、決めなくてはいけないことを誰が何を見ながら、誰と相談しながら、誰に承認をもらって決めているかではないでしょうか。

ここのプロセスの進捗の透明性ということが大事なことのように思われます。意思決定の行為が不正に行われていないか、最善を尽くしたのかということを、そこに関係する人たちで共有するということである。

それはよくいえば集合知につながる話でもあるが、誤解をおそれず言えば、いい意味で「赤信号みんなで渡ればこわくない」のである。
　　

表題のようなタイトルで書いてきたが、最初にきちんとした構成があったわけではなく、行き当たりばったり的なノリで始めた。従って、脈略がなかったり、くどい表現があったりしたと思う。そこで、これまで書いてきたことを中心にまとめてみることにする。

今、情報システムが置かれている状況といえば、ビジネスの方の停滞で元気がでないのはしかたがないのだが、ここで立ち止まって、情報システムのあり方やそのかたちがどうあるべきかといったことを考えようではないかというのがそもそもの出発点であった。

何度も言ってきているように、情報システムはその時々のビジネスの状況に左右されるのは当然である。なぜならビジネスありき、そしてビジネスに貢献してこそ情報システムの存在意義があるからである。

そう考えたとき、高度経済成長の時代から謳歌した日本経済もとっくに曲がり角を通過し、今や停滞あるいは衰退の時にきている。ということは、そんな時代に適応したビジネスであり、それと対となった情報システムでなければいけないはずである。

ところがどうであろうか。旧来型のいわば右肩上がりの経済成長ありきの情報システム（＝業務システム）であり、その延長でしか考えていないという旧態のままになっていやしないかということを指摘しているのである。

ビジネスのほうは生き残りをかけて変化するためにそのビジネスの再定義を始めているわけで、ならば業務システム、情報システムも同じように再定義していかなくてはいけないのは自明のことである。そうでなくては、ビジネスの足を引っ張る不良資産と化してしまう。

それ以上に、ITエンジニアは手をこまねいていないで、ビジネス側の変革を待つのではなく、変革を促す道具を提供するぐらいの意気込みをもってもいいと思うのである。そういう意味ではITの進展はすさまじいものがあり、これまでできなかったことがかなりのレベルまで可能になったという現状は後押ししてくれるはずである。

そういう気持ちをこめてこれまで書いてきた。ということで、最後にまとめとして要点を簡潔に説明しておこうと思う。そして、文章だけでわかりにくいと思うので図も入れながら書いていきます。下記のような課題設定のもとにまとめていけたらと思います。

１．従来のどこを変えなくてはいけないのか
２．これからの業務システムに求められる要件は何か
３．ビジネスとITを結ぶためのポイント
４．What（構造・道具）を先に構想する
５．Whatを効率的に構築するためのHow（技法・作法）を考える
６．成長するオペレーションの重要性を認識する

従来のどこを変えなくてはいけないのか

１． 業務システムに影響を及ぼすビジネスの変化とは

（１）プッシュ型からプル型へ
いいものを作れば売れる時代から、顧客ニーズにあった「モノ＋サービス」を提供することが求められてきた。

（２）俊敏な変化対応力
ユーザニーズの多様化やビジネスのグローバル化にともなって、状況変化に対するスピードとアジリティがなければ生き残れないようになってきた。

（３）オープン化
すべての領域で隠すことから開示する方向へ流れているが、実はオープンになっているのは、「要素」のところが主で、それぞれの要素を組み合わせるところが差別化要因となってきている。

２．これまでの業務システムとは

（１）業務システムの基本は変わっていない
情報技術（IT）そのものは大きく変わってきているが、ITを使って行う業務遂行は昔もいまも基本的には同じようなやり方である。

（２）決算システムがベース
もともと経理計算から始まっている（経理部電算課などと言っていた）から、販売・、生産・調達・購買などのモノとカネの実績、給与計算などのヒトの実績、詰まりはお金をいくら使って、いくら売って、いくら儲かったかを計算するためであった。

（３）データ入力・帳票出力システム
決算システムは、“バックヤード起点”だから、そこへ向かって（決算をするために）データを登録し、その結果やチェックリストを紙で出力するというのが、基本のシステム機能であった。これは、最初の電算システムでも現代のERPでも基本的には同じ考え方でできている。

３．どこを変えるのか

（１）日常の業務をシステム化する
これからのシステムは、経理計算のための電子計算機から組織のメンバーが共同目的のために意思疎通を図りながら協働する場へと軸足を移す必要がある。

（２）顧客接点プロセスの組み込み
決算システムに登録するまでのデータを確定するプロセスをシステムの中に組み入れる。

（３）柔軟な構造
ビジネスが変化したとき、すぐさま変えられるような業務システムにする。

ざっくりと、従来のシステムの問題点と課題について書いたが、ここの根本的な認識がないと、新しい仕組みを考えたところで、現状の延長でしかなく、革新的なものは生まれてこないと思う。ほとんどの人が認めると思うが、今のビジネスがドラスティックに変化しているわけだから、業務システムも同じように変革していかなくてならないのだ。

オープン化時代の処し方

オープン化の流れが加速している。ITが先鞭をつけたのかもしれないが、あらゆる分野で情報開示の動きが増えてきている。文学や音楽などでは著作権保護の観点から異議を唱えているだろうが、そのうちこの流れに抗しきれなくなると思う。

だから、もはや隠すことで価値を高めることが困難になってくる。そうであれば、逆に積極的にオープンにすることで対応したほうがいいような気がする。前回にも書いたが、オープンにするといっても基本的に「要素」の部分なのである。そして一方、オープンということとは別に今日では、お客さんはその要素だけを欲しているわけではなく、それらを組み合わせたものを評価するようになってきている。

従って、オープンにしても失われないものを作り出すことが求められているのです。それはどんなことかというと、文化・風土に裏打ちされた組織力、経験・ノウハウをもった技術力、仕事や生活のスタイルを提案できるサービス力といったものではないでしょうか。

ここで挙げたことは、すぐにまねることができないもので、長年の積み重ねであり、人の精神や心の中に備わったものであるわけです。そういったものを競争力として企業価値を高めることができるのです。

ただ、気をつけなくてはいけないのは、こうした暗黙知的な技能は時として反オープン的な傾向になることがあることで、それに対しても新陳代謝としてのオープン化を促していく必要があるということだ。

かっこいいことを少し言うと、オープン化するということは必然であると思っている。なぜかというと、たとえば、非常に素晴らしいものを発明しました、あるいはみんなが喜ぶようなものを開発しましたとなったとき、それを秘密にして、ある特定の人にだけ高く提供するということがいいことなのだろうか。

優れたものができたら、できるだけ早くみなに与えて喜んでもらえることが、その作られたものの願いでもあるはずだ。使ってもらう人、喜んでもらえる人が多ければ多いほど研究者・開発者冥利に尽きるというものではないだろうか。

ITのオープンソース精神はここにあると思う。お金を儲けるために研究し、開発している人はもちろんいるかもしれないが、たいていの人は自分の夢を実現することを欲しているはずだ。だって、こんないいものができたからみんなに見てもらいたいというのは素直な人情というものである。

ということで、人々の暮らしや仕事が楽しくなるように、オープンな要素を使って新しい価値を提供するようにしたいものだ。これこそ、日本のこれまでの「ものつくり神話」からの脱却ということかもしれない。
　　

これからの業務システムに求められる要件は何か－その１

前回、ビジネスと呼応した業務システムの変革の必要性を強調した。では、そうした業務システムに求められる要件について考えてみましょう。そのとき、まずはわかりやすい次の図をみてください。

この図は、日本BPM協会のコモンセンス部会で今盛んに議論されているプロセス改革モデルで、企業がビジネスを行うときにもつべき能力として、組織能力（ケーパビリティ）と価値提供力（子ンピテンシー）をあげ、縦軸と横軸の関係であると位置づけています。

ここですごく重要なのは、その交差点に“プロセス”を置いてあることです。BPM協会だからそうしたということではなく、まさにこれがいまのビジネスにとって必要な構造なのです。この構造こそ、多様化する顧客ニーズやめまぐるしく変化するビジネス環境などへの素早く、そして柔軟な対応が可能になるのです。

すなわち、顧客からの要求に対して、事業組織としてプロセス活動を行い、顧客に価値を提供し、収益を得るという横軸の活動がある。一方、そのプロセス活動では、戦略目標や計画に基づき、自分たちの資源を有効に使って、最大限の能力を発揮するということである。

こうしてみると、どんな業務システムが望まれているかが浮かんでくるのではないでしょうか。情報システムというのは、実際のビジネスモデル、事業活動、組織の写像であらねばなりません。ですから、上図のようなプロセス改革モデルを実現してみせるプラットフォームを提供することなのです。

これまでの業務システムはともすれば、ITからの発想になっているように思います。ITシステム（例えば、会計システム、販売管理システム、グループウエア、メールシステム、BIなどなど）がまずあって、それをビジネスの一部の機能に当て込むことだったのではないでしょうか。

そうではなくて、ビジネス活動全体を設計して、それをできるだけ乖離しないような形でシステム化する。そういった発想で見ていくと、業務システムのイメージを書くと次のようになる。

これからの業務システムに求められる要件は何か－その２

前回、業務システムの構造イメージを書いてみましたが、今回は現状の業務システムはどこにマッピングされているのだろうかという話です。今の多くのパッケージや手組システムが全体をカバーしているとは到底思えないので、どこがカバーされていて、どこが抜けているかということである。

そこを検討するにあたって、前回使用した構造図に既存のシステムをかぶせてみます。

統合的な業務パッケージではERPが代表的ですが、それは図のようにバックヤードのところをカバーしています。ERPの持つ基本的な機能は、生産計画／管理、出荷管理、販売管理、在庫／購買管理、財務会計、管理会計といったところです。

これは簡単に言うと、何をどれだけ作って、それをどれだけ売った、そのときにいくらの費用をかけたのか、そしてどれだけの収益をあげたのかを登録して、管理する仕組みです。

しかしながら、企業活動、ビジネスはそれだけではありません。特に顧客や取引先との関係のなかの業務プロセスが抜けているように思います。そこを考えるとき、図のプロセス活動をフロントエンドとバックエンドに分けてあるところを注目してください。

プロセス活動はひとくくりで言えないという意味ですが、プロセスの性格をみていくと分かると思います。それを端的に示すのが、プロセスの起点という見方で、そのプロセスは何がトリガーになって始まるのかということです。ERPのような場合、あまりプロセスという意識はないのですが、そこには決算のためのプロセス、ＢＳ／ＰＬに反映したいためにその実績データを取得するプロセスになります。これがバックエンドプロセスです。

一方、実際のビジネスは顧客や取引先があって成立します。そこのプロセスはどうやって始まるのでしょうか。顧客や取引先の要求というのがあって、それに応える形でプロセスが形成されます。これが顧客起点のフロントエンドプロセスということになります。

その他では、個別あるいは部門単位の業務システムが存在していて、それらは主にヒト、モノ、カネのリソース管理になっています。また、SalesForceのような営業管理あるいはLandingPageのような顧客獲得のためのWebサイトなどが作られていますが、そこからエスカレーションするためのプロセスの概念が乏しいように思います。

ですから、今問題なのはこのフロントエンドプロセス、言い換えれば「顧客接点サービスプロセス」の領域のシステムが弱いことではないでしょうか。いろいろなパッケージやソフトウエアがありますが、こうしてビジネス構造との対比の中で、そのビジネスをシステムが支援しているのかという観点でみると、やるべきことも見えてくるように思います。
　　

“管理”システムを作るのはやめよう

ごく普通にシステムを開発するとき、「○○管理システム」という風にすることが多くある。営業管理システム、人事管理システム、購買管理システムとかあらゆるものに管理という言葉がつく。設備とか商品、取引先とかいったリソース系のものに対して管理システムというのはまだわかるが、プロセス系のものに対して、管理という言葉はあまりそぐわないような気がする。

例えば、営業管理システムなんてものがあったとすると、だいたいが営業マンの人を管理するイメージになってしまいます。ですから、システムの作りはどうなるかというと、管理している人のためにそのシステムをどうするかが主体になります。管理側の観点です。

そうなると、営業マンの日常業務、例えば見込み顧客訪問だとか、商談内容などを逐次記録させるわけです。それを一覧表にして進捗管理をするということになります。まあ、それはそれとして大切なことではありますが、システムのもつ本来の目的とちょっとずれるような気がします。では本来の目的は何でしょうか。

それは当たり前のこととして、顧客の獲得、オーダーの受領であるわけです。そこに向けて、ケーパビリティとコンピテンシーが発揮できるようにしなくてはいけないのはずですが、そうなっているでしょうか。単なる管理システムでは、プロセスという概念が希薄であるため、実績の管理でしかないという限界があるように思えます。

一方、リソース系のものについては管理というワーディングもおかしくはないが、その中味として、プロセス改革モデルのケーパビリティとして、リソースをどう管理するのかという視点を強く意識する必要があると思う。すなわち、事業成果を上げるためのリソース管理になっているのかということである。

そうした意味で、ERPは文字通り企業資源計画であり、リソース管理システムなのである。ただ、不足しているのが、コンピテンシーの方で特に顧客との間のプロセスが弱いと言える。

いずれにしろ、管理という事後処理的なふるまいではなく、業務プロセスの進捗にそって即時的に適解を見つけ出す“新たな管理”の仕組みが望まれるのではないでしょうか。

ビジセスとITを結ぶためのポイント－その１

前回までに、ビジネスとシンクロした業務システム構造イメージと現状の課題を提示したが、これからはどういうコンセプトでシステム構築を検討するのかということを議論しようと思います。その時のキーポイントはプロセスを中心に据えた構造であるということである。

ここが非常に重要であるが、もう少し、他のポイントも含めて、なぜ重要なのか、あるいはどんな点で従来と違っているのかといった切り口で整理していきます。

なお、最初にサブタイトルを「それを実現するためのビジネスアーキテクチャとは」としていましたが、ビジネスアーキテクチャとという言葉もなじみが薄く、定義もあいまいなので、もっと直載に標記のような表現にしました（前のエントリーも修正しました）ので、それについて考えてみたいと思います。

重要な3つのコンセプトは下図のようなものになりますが、それぞれについて掘り下げてみようと思います。

１．プロセス中心で設計する（Process　Oriented)
ビジネスと情報システム（IT）の結びつきを考えるとき、一番大事なことはビジネス構造の“へそ”にあたる業務プロセスを中心に考えていこうということである。この辺りは、もう何回も言っているので、ここでは“どんなことをしたいがため”にプロセスを中心にしたかという視点でみてみる。それはつぎの二つではないだろうか。
（１） 経営とITを同期させたい
（２） ビジネスを可視化したい

ここで経営とITという言い方をしているが、現実的には事業とITという表現の方が適確なよう気がする。事業成果を上げるためのITといったイメージだ。では同期とはいったいどういうことなのか。これは文字通り、ビジネスの動きと同じようにシステムも連動して動くことで、これは可視化や他のこととも関連するのですが、事業、ビジネスとITの間に途切れがないことを言います。

ちょっと分かりにくいと思いますが、逆に今は途切れてしまっていると言った方がいいかもしれません。事業やビジネス活動からの要求をそのまま実装できていないのが実状です。だから、その乖離のために同期がとれていないと言わざるを得ないのです。

2番目の「ビジネスを可視化したい」というのは、いま盛んに言われていることです。ここでも、逆に今見えているものは何かという捉え方をしてみましょう。そのとき重要なのは、時間の考え方で、要するに過去、現在、未来の見え方がどうなのかです。

過去のことしか見えていないように思えるのです。ビジネスの結果でしか事業成果が見えていないことで、これでは“後の祭り”になってしまいます。それよりも今日では、現在のこと、そして未来のことを見える化したいのではないでしょうか。未来のことは、現在と過去のことを前提として、予測するわけだから、重要なのは現在の姿がちゃんと見えていることになると思います。

そして、この現在を見るには、プロセスがなければいけませんし、そのプロセスがどう動いているのかが見えていなくてはなりません。従って、プロセスを中心に置くというは、現在の姿から過去や未来が導かれるという意味で一番重要だからです。

ビジセスとITを結ぶためのポイント－その２

２．オペレーションで成果を出す（Operation　Excellence)

オペレーションが大事であるということを言ってもなかなかわかってもらえないところがある。そのことはビジネスとITの乖離を意味していると思う。どういうことかと言うと、使う側の人にとって、システムが威力を発揮するのは、当たり前のようにビジネスとしての結果を残すことであるが、それは優れたオペレーションによってもたらされる比重が高いということである。

作ったシステムがいいか悪いかもあるが、いくらいいシステムでもうまくオペレーションできなかったら何にもならない。クルマの話で言えば、いくらいいクルマを買ったとしても、そのクルマで事故を起こしたらと考えたら何もならないのと同じことだ。クルマを事故なくスムーズに運転するように、システムを動かして成果を上げることが非常に重要なのである。

こうした意味において、ほんとうにオペレーションを考えている人が少ないように思う。SIerと呼ばれる人たちは、基本的に作ってナンボのビジネスをやっているわけで、それなら頼んだ側のユーザに自分たちがオペレーションしていくのだという意識があるだろうか。どうも希薄なような気がするのです。

さて、ここでもなぜオペレーションが重要かという話になります。前と同様に“どんなことをしたいがため”にちゃんとオペレーションしようよと言っているのかである。それは次の二つではないだろうか。

（１） 変化に対する俊敏な対応
（２） プロセスへの責任

今や変化対応力は非常に重要な差別化要因にもなってきています。それを実現するにはITを駆使してプロセスをオペレーションできる環境が必須です。また、従来は受注量だとか売上高のようにビジネスの結果についての責任を議論しがちですが、その途中のなぜそうした結果がでたのかというプロセスに対する責任を見ていくことが求められているのです。

ですから、システムは作っただけでは、変化対応力やプロセス責任といったことまで踏み込めません。従って、システムも誕生してからどう使われて、どう成長していくかというライフサイクルが重要になってくるのです。次に、そのライフサイクルを図示しておきます。

今の開発というのはそのライフサイクルのごく一部を占めるだけであるにもかかわらず、どうもそこだけに多くのリソースを投入しているように思えます。ここはユーザが早く気がついて、もっと声を大きくして言うべきだと思います。
　　

ビジセスとITを結ぶためのポイント－その３

３．情報共有の場で仕事をする（Collaborative Workspace）

最後の3つ目のCollaborative Workspaceについてです。企業における仕事は一人でやるものではありません。ところが、既存の業務システムは一人でやるような仕組みになっているのではないでしょうか。そこに問題があるような気がします。

以前にも紹介したチェスター・バーナードの組織論では、組織を「孤立した人間の集団ではなく相互に影響を及ぼし合いながら成立する体系(システム)」ととらえています｡そのために必要な組織の3要素を、「共通目的」、「協働意欲（貢献意欲）」、「コミュニケーション（伝達）」であると規定しています。

そのものずばりで理解できると思います。そうであれば、組織と業務システムは一体であると考えていますので、組織の3要素も業務システムに必要な要素であると言えます。ではそれぞれについて考えてみましょう。

仕事をする上で共通目的を共有してそこに向かうことは非常に重要です。ではその共通目的を今はどう設定して、どう知らしめているのでしょうか。もっと言えば、業務システムを使って仕事をするのにそれがどこに表現されているのでしょうか。最初に言ったように従来のような業務システムではそこが弱いように思うのです。

そこを変えていくのがプロセス志向なのです。プロセスを作るときの大事なことの一つにプロセスの始点と終点を決めることがあります。このときにそのプロセスの“合目的性”をチェックします。（間違えてはいけないのは、目的の明確化ではないということです）すなわち、なぜそのプロセスが提起されて、何を成果とするのかを定義するわけですが、それが会社のビジネスの目的に合っているかを問うことをします。こうしてできたプロセスを組織で動かすのですから「共通目的」は確保されるのです。

「協働意欲」と「コミュニケーション」はどうでしょうか。近頃の職場は、合理化が進み、最小人員で運営するようになっていて、どうしても他人のことはかまっていられなくなり、チームプレーから個人プレーに傾いているように見えます。こうした傾向は組織としての能力が単に個人の和でしかないという事態を招来しています。

さて、どうしたらいいのでしょうか。それが情報共有の場で仕事をすることなのです。個人の机の上にPCがなかった時代には、だれかの机のまわりに当事者が集まって、直接の会話や電話をしながら、時にはけんかをしながら、そして、紙や黒板に書いて、ものごとを決めていました。それを、PCの画面上に再現すればいいのです。これは、Ontologyの概念に通じるものだと思います。

ここでも前と同じように、なぜそうしたことをしたいのか、どんないいことがあるのかについて考えてみましょう。それは次の2つであると思っています。

（１） 意思決定の質の向上
（２） 技術・ノウハウ・経験の伝承

Web2.0でよく言われるのは、参加型のアーキテクチャとか集合知があります。これらは、意思決定の質の向上をもたらします。この実現の場がCollaborative workspaceなのです。“練りに練った”、“バランスのとれた”、“英知を結集した”デシジョンが生まれるのです。

また、そこに参加するメンバーは自分の意見を出すことが求められています。もしそこで何も言わなければ、そこで確定されたものに賛成したことにするわけで、そうなると自分の経験やアドバイスを言わざるを得ない状況となるはずです。そして、こうしたコメントはアーカイブされ、分析を経て次の類似案件で生かすことができるのです。

そして結局、このような形のコラボレーションが、「不機嫌な職場」からの脱却をもたらしてくれるのではないかと願うのである。
　　

業務システムとクルマを比べてみる

クルマもシステムである。何らかの目的を実現するための仕組みと仕掛けが施されたものという意味でシステムなのだ。ということであれば、このクルマと対比をすることで業務システムとはどうあるべきかを考えてみたい。

こうしたたとえをすると、すぐに自動車産業の生産システムと業務システム開発の比較を思い浮かべます。ですから、ベルトコンベアの生産ラインだとか部品化、“すり合わせ”技術だとかといった議論になります。

人によっては、日本のIT産業は自動車産業化しなくてはいけないなんて論を張る。ここを少し掘り下げてみていくと、現状のシステム開発やIT産業の問題点が見えてきやしないかと思うのである。

それではまずは、自動車の生産システムをとりあげてみよう。この生産システムの目的は何でしょうか。何のために存在しているのでしょうか。それはあたりまえですが、ある決まった車種の車自体を作ることです。目的生産物がモノとして存在していて、それをいかに効率的に生産するかということになります。

それをIT産業に当てはめるとどうなるでしょうか。これは、ソフトウエアやパッケージの製造にあたります。自動車そのものはプロダクトだからこうしたものと同じと言えます。大型セダンがERPで、軽トラックがグループウエアでとかそんな風に考えられないこともありません。あくまで、道具に近いものという捉え方になります。

では少し観点を変えて、IT産業に多く存在するSIerというのは、自動車産業ではどこに相当するのでしょか。自動車販売代理店でしょうか、ちょっと違いますよね。ということは、そんなものは存在しないということではないでしょうか。

もしあるとしたら、誰かがこんなところでこんな使い方ができる車がほしいと言うと、はいそれに合った車を作ってあげましょうという会社があるということです。だから、家電にしてもそうだが、そうした機能はないのだ。似ているのに建設業とか住宅があるが、これとて、スクラッチからというのは少ないと思います。

だから、自動車産業はいいと言っているわけではありません。逆に、自動車はプロダクトアウトだから、お客さんの生活スタイルがこうだから、それにフィットした商品を提供するというアプローチというより、これを使えという感じですから、ベンツに乗って田んぼのあぜ道を走ることもあるわけです。

こんな風に考えると、顧客志向とか顧客満足度を上げるとか言うが、それを強く打ち出すと、極端な話、一品ずつ手作りとなるわけで、逆に、作ったものをそのまま使ってもらうとなると、スタイルに合わない、あるいは使わない機能がでてくるとかいったギャップが生まれます。

ここで飛躍してしまうかもしれませんが、電気自動車になった場合、ずいぶんと車のイメージが変わるような気がします。今は、ガソリンエンジンなのでどうしても同じような形になってしまいますが、それがモーターになると、様々な意匠が可能になるのではないでしょうか。

慶応大学の清水教授が開発したエリーカのインホイールモーターを使えば、どんな形の車でも作れてしまいます。個人的にはエコとしての電気自動車より、こちらの方がインパクトあるように思います。

少々、脱線しましたが、モジュール化がキーになり、そのモジュールの機能粒度と性格付けをどううまく設計できるかであるように思います。これは、自動車であろうが、家電であろうが、住宅であろうが、ましておや、業務システムでも同じことが言えるのではないでしょうか。そこのコーディネータとしてSIerが生きればいいのだと思うのです。
　　

What（構造・道具）を先に構想する－その１

さて前回まで、ビジネスとITを結ぶためのポイントとして、Process Oriented、Operation Excellence、Collaborative Workspaceということを提示してきた。こうした考え方に基づいてどんな業務システムにしていくかになるが、つい、どん技術や言語を使ってとか、どんなパッケージで実現するのかといった作り方議論になってしまいがちである。

しかしながら、大事なことはこうしたHow to　ではなく、実装から独立したどんな構造のもの、あるいはビジネスを実行するための道具はどんなものが要るのかというWhatを議論することなのである。

特に、いまは従来型の構造や道具では限界がきているように思え、そうしたものをベースにいくら方法論をとやかく言ったところで意味がないのである。そこで今までの議論を参考にしながら、Whatを見ていくことにします。

初めのほうでプロセス改革モデルから導かれた業務システム構造を提示してありますが、あれをもう少しIT寄りに分解していくことになります。そのときの切り口として、プロセスのカテゴライズをしてみます。業務システムの中に様々なプロセスが存在しますが、それぞれに性格や機能がちがったりします。分かりやすいと思うので、企業活動のPDCAサイクル(マクロ的な)で見てみます。

P：計画プロセス
D：実行・活動系プロセス
C：決算系プロセス
A：分析・リソース系プロセス

PとDはおわかりだと思いますが、C（check）がどうして決算系かというと、決算というのは、事業を実行した結果を集計して、正しく実行されたか、成果を上げたかをチェックして公開するという機能ですからCということになります。

A（Action）の分析・リソースは少し分かりにくいかもしれません。いずれも事業実行の結果を分析し、あるいはそれによってリソースの質や量を変化させたり、つぎのアクションに生かすという意味で言っています。ここは結構重要なところです。

今度は、それぞれを企業活動の中身をみていくことにします。少し前にEnterprise Ontologyの記事の中に3つのレベルのことを書きました。すなわち、
1．Datalogical　：データ転記のような単純処理
2．Infological　 ：計算や加工といった意味付与を行う処理
3．Ontological　：意思決定を伴う活動

これと、先にみたPDCAを対応付けてみます。Cの決算系というのはDatalogicalですね。逆にそうでなくてはねつ造みたいな話になりかねません。また、分析・リソース系はInfologicalだと思います。生のデータや情報をPやDに活かせるように加工するからです。

残ったPとDは、どうもOntologicalのようですね。計画でも中期計画とか予算のようなものと、実行系に連動した計画があるので、それを実行・活動系に含めて考えると、そこの領域こそ企業活動の骨格で非常に重要になります。まさにOntologicalなわけです。

従来の情報システムの構造は、InfologicalとDatalogicalの世界が中心でした。ですから、DについてもむりやりInfologicalとDatalogicalでの取り扱になっていたのではないでしょうか。

どうも類型化のほうに行ってしまって、構造や道具の話からそれてしまったので、次回からはもう少し具体的なWhatのことに入っていきます。

What（構造・道具）を先に構想する－その２

前回論じた中でこれからの重要な対象プロセスとして、実行・活動系のプロセスをOntologicalな扱いでシステム化したものが求められるようなことを指摘しました。そこの強化に向けてどういったものを作っていくのかがここでの議論になります。それを示したのが次の図です。この図の赤線で囲ったKeyProcessがそれにあたります。

ですから、それ以外の決算系は既存のERPや会計パッケージで十分であると考えています。
そして、個別的に存在するWebアプリケーションやリソース管理システム（例えば、設備管理、在庫管理、物流管理、人事管理など）もそれぞれ特化したものがあって、それを使えばいいし、そこのデータ管理プロセスが弱い場合は、新しいプロセス構造で補完すればいいと思います。

さて、そのフロントエンドプロセスのシステム構造とツール化の問題になります。前からの流れで、まずはプロセス構造を考えていきましょう。業務プロセスを階層的な見方でとらえると、ハイレベルになればなるほど定型的で反復的であることがわかります。逆に言えば、ローレベルでは非定型でアドホックなものになっています。

ここで注意しなくていけないのは、データ処理や情報処理といったレベルは定型的ではないかということですが、あくまでプロセスというレベルの話であって、スナップショット的なアクションは除いています。

なぜ、レベルが低くなると定型的でなくなるのかというと、人間が介在する余地、すなわち人のつながりで仕事をすることがでてくるため、意図的な要素が入り込んでくるからだと思います。ですから、そこの線引きをする必要があります。道具の作り方が変わるからです。

この2段プロセスの構造が重要なポイントになります。この2段の上位プロセスというのはある程度パターン化できるものです。ここは、個人のつながりではなく組織のつながりになってくるので、あいまいさが排除されてくるのです。この辺りは何度も議論してきたところです。

一方、下位のプロセスでは、あらかじめきちっと決められないことが多く、ケースによって様々な様相を呈します。こうしたタイプでは、線で結んだり、ツリーで書くことは難しいのです。ですから、“線”ではなく“場”という概念が必要になると言っているのです。

上位はフローで下位は場でという構造になります。別の見方で言うと、業務プロセスとは「人のつながりでしたしごとのつながり」という構造になるわけです。しごとのつながりだけでもなくひとのつながりとの合わせ技が現実的な解であると思うのです。
　　

What（構造・道具）を先に構想する－その３

前回は、プロセスの構造ということで、ローレベルのプロセスは“場”という概念を採用したことを説明しました。それが、Collaboration Workspaceで、情報共有を志向していますが、この考え方は実はWeb2.0のコンセプトやアーキテクチャ、技術が有効な実現手段となります。

Web2.0も特徴は、双方向コミュニケーション、オンデマンド、ハイパーリンクだと考えていて、ということは、自分のほしい情報を素早く手に入れ、コミュニケーションによる調整を行いながら目的を遂行するというのがWeb2.0の基本的なアクティビティであると思います。これは、業務プロセスを動かす時も同じなのです。

さて、もうひとつのオペレーションということですが、これこそが、業務を遂行する、仕事をこなすための道具が必要になります。いい仕事をするのにはいい道具が要るというのは、大工さんでも主婦でも言えることです。その良しあしで出来上がり品質や能率が変わってしまいます。

そういった意味でいうと、従来の業務システムのユーザインターフェースに対する力の入れようが弱かったように思います。仕事をするために必要な情報を揃えてあげているのか、使い勝手はいいのかといった問いかけがこれからは大事ではないでしょうか。

さて、道具の構成はどんなものになるのでしょうか。次の4つを想定しています。
１． Process Designer 　・・・アクティビティの定義とフロー設定
２． Activity Setup　　　・・・案件ごとのアクティビティの要素パラメータの設定
３． Process Overview　・・・プロセスの稼働状況一覧
４． Decision Workspace・・・コラボレーションによる意思決定とデータ入力

それぞれの関係などについては、後述することにして、業務システムの構造のモデル図は次に示します。

道具ということ

いまWhatということで構造と道具という言い方をしています。この場合の道具ですが、つい開発ツールと誤解されてしまいそうですが、そうではなくビジネスの道具、すなわちそれを使って仕事をして業務成果を上げるものを指しています。

こういうと、じゃあExcelとかメールのことなのと言われそうですが、そうした個人の知的作業ではなく、組織活動としてどういう道具で行うかという観点です。すなわち、業務プロセスをオペレーションするためのものです。

そういうと今度はBPMSのことですかと言われる。全く否定はしませんがちょっと違うように思います。よく考えてみると、これまではシステムを作るというアプローチですから、どうしても、人間がやっていることを代替するものという捉え方が一般的ではないでしょうか。

すなわち、機械化とか自動化というような視点です。これは正しい方向でしょうか。何と言っても最後は人間が判断し、人間が操作するわけで、そう考えると、人間の能力を衰退させるようなIT化は避けるべきだと思うのです。

ということは、人間が何かをするときに支援する道具としてのITが本来のあるべき姿であるような気がします。何かする主体はあくまで人間で、その人間が判断し、行為を行うのを手助けしてくれる、人間がこうしたいときに邪魔をしないで、素直についてくれるものとしてシステムがあるべきです。

今話題になっているトヨタのリコール問題にしても、どうもブレーキがどうのという機械的なことではなく、電子制御装置の不具合に帰されそうである。それはソフトウエアのプログラム上の問題ということで外から見ても何がどうなっているか誰もわからなくなってしまっている。ということは、人間がクルマを道具として使っているのではなく、クルマに埋め込まれたITシステムに使われているという恐ろしいことになっている。

さて世の中いろいろ道具はありますが、ぼくが考えるすばらしい道具は何だと思いますか？それは「キャスター」です。旅行カバンや椅子などについているやつです。これって、人間がこっちに行きたいと思うとそちらに向いてスムーズに動いてくれます。けっして、自分から動くわけではありませんし、いちいち方向を示さなくても大丈夫です。そんな道具がいい道具ではないでしょうか。

ちょっと飛躍したかもしれませんが、要するに繰り返しますが、人間が主役であり、そこを支援するものとしてITがあるということを肝に銘じることが大切で、そうなると「道具」という考え方でシステムを開発するべきだと思うのです。

What（構造・道具）を先に構想する－その４

前回、業務システムの構造と、道具についてもその構成として次の4つを提示しました。

　１． Process Designer 　・・・アクティビティの定義とフロー設定
　２． Activity Setup　　　・・・案件ごとのアクティビティの要素パラメータの設定
　３． Process Overview　・・・プロセスの稼働状況一覧
　４． Decision Workspace・・・コラボレーションによる意思決定とデータ入力

このことについてもう少し詳しくみていきましょう。これらは、市販のBPMSの機能にあるやつですねと言われる。確かにそのとおりではあるが、微妙に違っています。ひとことで言うとより業務オペレーションのための道具という意識が強いことでです。

ビジネスの成果をあげるため、より質の高い意思決定を素早くできるのかというものとして、そのための機能をどうもったらいいのかということです。組織のふるまいと一体となった動作が可能かどうかです。

まず、Process Designerですが、モデラーと言われているものですが、モデラーというと最適なプロセスをつくるためにシミュレーションなんかもしてというイメージですが、ここでは実装に向けて、プロセスを設計するだけのものです。ただし、個別案件についての設計ではなく、汎用的なプロセス設計、別な言い方をするとテンプレート設計に近いものになります。

そして、具体的な案件が出てきたときには、デプロイされたそのテンプレートに対して、必要な個別プロパティやパラメータを設定します。それを、Activity Setupという画面を使って行います。案件名や参照情報、ロールなどを特定するわけです。

Process Overviewでは、稼働中のプロセスの進捗が一覧として見ることができます。そして、アラート機能を持たせておいて、ある閾値を超えると警報を出します。通常考えられるのは、「時間」です。一つひとつのアクティビティでの処理時間やプロセスの完了時期などです。こうして、スムーズな業務処理を促すわけです。

そして、完了したプロセスのアーカイブを検索することができ、例えば、プロセス別、会社別、地域別といったセグメント別のソートで実績を分析し、レポートします。

最後のDecision Workspaceは、意思決定すなわちデータ確定を行う場です。この意思決定は孤立した個人が行うのではなくコラボレーションにより行うようになっています。そして、この意思決定は何も見ずに単純に決めるのではなく、参考とすべき情報を横目でみながら行っていきます。例えば、設備を割り当てるには、いまの稼働状況や予定をみることをするはずです。

こうしてみていくと、道具的な概念としての業務システムが従来と違うと思いませんか。これまでは、個人がデータを登録するため、あるいは帳票を出力するための道具であったわけですが、ここで提示しているのは、組織の行動と一体となった業務システムです。

もちろん、従来の機能は必要ですから、なくすわけにはいきませんが、個人の道具から組織の道具へと変貌させるべきだと言っているのです。この4つの道具をうまく使いながら、組織として業務プロセスを安定的にかつ迅速に処理していくことが大事になるのです。

影響を受ける理論

「業務システムの再定義」というエントリーで業務システム構造や機能について記してきて、前回4つの道具を提示してその概略を説明しましたが、ここで思いつきのアイディアで言っているのではないという意味から理論的な裏付けのような記事を書いていこうと思う。

かねてから思うことは、机上のあるいは紙上の議論は盛んにするのだが、では実際に動くものはどうやって作るのということになると、それはそれという逃げを打たれる。逆に動くものを作っている人たちは、じゃあそれはどういう役に立つのだというと口ごもってしまう。

だから、重要なのはコンセプトやモデリングがあって、それを実現する具体的なソッフトウエア、ツール、モジュールといったものを作り出すという一連の合わせ技が大事であるということを言いたいのである。

そこで、そのへんのことを書いていこうと思う。で最初の稿は、Kailasは一体どんな理論と関係があるのかという話です。実はそういっても、Kailasが最初から高邁な理論がもちろんあったわけではなく、もちろん後付けである。自分の頭で考えたことが、理論的にも主張されているものに近かったのだという“こじつけ”です。

しかし、理解してほしいのは、一方で大学の偉い先生が考えるような高尚さと、実際の現場で苦労して編み出した知恵が、結果的に結びつく、同じゴールになるということである。これは自分の中では”ささやかな産学協同”と呼んでいます。

さて、その理論のことである。Kailasに影響を及ぼした（というか正確にはKailasと同じことを言っていると思っている）理論は次の４つである。

１． Chester Barnardの組織論
２． Herbert Simonの意思決定プロセス
３． Terry WinogradのLAP
４． Jan DietzのEnterprize Ontology

理論を言うなら実践しろと思うのだが、大学の先生はどうしても実践よりも理論を重んじるから、実践のところまではやってくれない。現場はというと、理屈なんかどうでもいいからとすぐに言う。だからそれをつなげてやればいいのだ。

次回から、これらの4つの理論のエッセンスについて議論しながら、Kailasの設計反映や機能といったところへ言及していきます。

Chester Barnardの組織論

情報システムを考える場合、往々にしてITから発想しがちになります。○○システムを導入するんだと意気込むわけです。こうした場合、どうしても局部的で、業務全体からみると一部だけに適用することになります。

こうしたことはIT系の雑誌をみているとよくわかるのですが、そんな話ばかりです。こんないいパッケージができた、どこかの会社で販売システムを入れた、クラウドに移行してコスト削減をはかった、といった類の記事です。それか、あとは戦略的なトーンであるのだが、ITと結びついていかない話とかが出てくる。

ところがよく考えてみると、企業活動の主体は組織であって、その組織が機能するためにシステムを形成するわけです。ただ。このシステムは別にITを使わなければいけないということはなくて、極端な話、全く使わなくてもかまわないのです。

ですから、発想の出発点は組織全体としてのシステムをどうするかということのはずです。一面的なITシステムはずっと後で考えるのであって、最初にITシステムありきでは順序が逆です。

ということで、業務システムは組織論と密接につながっています。そこでChester Barnardの組織論を取り上げてみます。バーナードの理論では、組織を孤立した人間の集団ではなく相互に影響を及ぼし合いながら成立する体系(システム)ととらえています。そうした組織が成立する条件としてつぎの三つをあげています。

■共通目的
人々が協力して、意識的に調整された活動を行うためにはメンバー間に共通の目的が必要。

■協働意欲(貢献意欲)
組織メンバーの共通目的を達成しようとする意欲のことで、協働意欲を高めるためには、組織が金銭的･物的誘因とともに社会的あるいは心理的 誘因をメンバーに対して十分に供与することが必要｡

■コミュニケーション(伝達)
組織内における各種の情報の伝達のことであり、共通目的と協働意欲とを統合する役割を果たす｡意思決定や命令の適切な伝達が行われな ければ、個々人の協働意欲が組織全体の目的を達成するための活動に結びつかない｡

要するに、複数の人間がコミュニケーションを媒介に協力して1つの目的のために働くことで組織が成り立っているといっているのです。この協働のための仕組みをシステムとしてもつことが大事なのです。

そして、さらに言い及んでいるのは、組織均衡と有効性・能率についてです。組織均衡というのは、組織に参加する人にとってのインセンティブと貢献のバランスで、インセンティブが貢献よりも大きくなければ参加者は組織から離れていってしまうという。一生懸命貢献しても見返りがなかったら辞めてしまうのです。

そうした、組織均衡を維持するためには、組織の有効性と能率を同時に高める必要があります。どういうことかというと、有効性とは組織目的の達成度のことで、どれだけインセンティブの原資を確保できるかという意味です。業績を上げれば給料が上がることをさします。能率というのは、そのなかの個人としての満足度です。個人の分配により能率を高めることが必要なのです。こうした、環境を用意してあげることも重要な組織の要素なのです。
　　

Herbert Simonの意思決定プロセス

このサイモンの意思決定プロセスについては、本ブログでも何回も取り上げているので詳述はしないが、この意思決定プロセス以外のところについて少し見ていくことにする。

そのひとつが、限定合理性と満足化原理ということです。はじめの限定合理性ということについてですが、彼は人間を限定された合理性を有する意思決定主体と仮定しています。すなわち、人間はできるかぎり合理的に意思決定しようとするが、合理性に限界が存在するために、完全に合理的な意思決定をすることはできないということです｡

これは、バーバナードも同じようなことを言っていて、多分にサイモンもそれに影響されたと思います。そして、なぜ限界が生じるのかというと、意思決定のために必要なすべての情報を収集できないという情報収集能力の限界と、意思決定に基づいた行動の結果をすべて完全に予想することはできないという計算能力の限界からきています。

従って、人間が完全に合理的な存在であるなら、最適化原理に基づく意思決定できますが、合理性に限界があるので、満足化原理に基づく意思決定をせざるを得ないということになります｡このことを逆読みすると、情報収集能力と計算能力を高めれば最適な意思決定に近づけることができることを意味しています。

この限定合理性により、問題の大きさや複雑さによっては、解決が難しいことが起きます。従って、組織を階層化してことにあたる必要が出てきます。目的を階層化して、それに対応して組織も階層化することが求められるのです。

ただし、この階層化された組織で意思決定を行っていく場合、気をつけなくてはいけないのが、それぞれの階層で意思決定がばらばらにならいようにすることで、そのため、各層の意思決定が連動していくために、「価値前提」と「事実前提」ということを言っています。

価値前提というのは、何を目的とし、何を望ましいと考えるかの価値判断であり、事実前提というのは、環境や組織が持っている能力がどうなっているかという事実認識で、これらを共有しておくことが大事なのです。

つぎに、サイモンは意思決定の種類を定型的意思決定と非定型的意思決定の２つに大別しています。簡単に言うと日常反復的に発生するのかそそうでないかである。反復的であれば決まった手続きや方式でやれるが、そうでないと新たな代替案を必要とします。

結局、サイモンは人間は限定された合理性をもったものであるがゆえに、組織を意思決定のための体系と規定し、それを組織目的に合わせて階層化し、合理性の限界を乗り越えていこうと主張しているのです。
　　

Terry WinogradのLAP

このLAPと次のEnterprise　Ontologyについては、このブログの記事でも書いたように、最近知った理論であって、ですから後付けもいいところです。しかし、これまでやってきたことと同じようなことを理論的に究明していた人がいたことに驚いたのです。

Kailasの発想はITを意識しないなかで業務の実相をそのままシステムに乗せたいところからきています。ですから、人間系の仕組みに注目するわけで、LAPやEnterprise　Ontologyで言っている「ひとのつながりにも目配りするビジネスモデリング」と合通ずるのです。

さて、そのLAPですが、LAPとはLanguage/Action　Perspectiveのことで、タンフォード大学のWinograd教授が唱えたものです。Winograd教授はもともと人工知能の研究で有名な先生でしたが、Fernardo Floresという人と出会ってから、このLAPにのめりこんだとのこと。

ただし、いまはそこから離れて、Human-Computer Interactionの方に行っているそうです。おそらく、LAPのようなことを研究していくと、ユーザインターフェースに行きつくような気もする。このへんはまた別途考えてみたいと思います。

前置きが長くなったが、所詮にわか勉強なので深いところが分からないが、LAPについては専修大学ネットワーク情報学部小林隆教授が詳しく説明してくれている。その肝のところは、新しい認知科学のアプローチであって、そこでは「認識を人間と環境との適合（カップリング）と考えよう」というところである。外部に適用するために行動することで、そうした行動をすることで認識が高まるというわけである。

そして、人間は言語を通じてカップリングする生き物で、うまく行くと（Happy　Path）定型的な会話パターンとなる。ところが、そううまく行くことばかりではなく会話が破綻する（Breakdown）場合もあって、そこでは厳密な単語を使った話合いを行うのだが、そうしたことをできるだけ回避するように会話パターンを設計することが必要になる。

結局、「人間生活の基礎は、行為の調整であり、調整は言語によって行われ、言語は要求と約束にもとづく」ということになる。こうしたことを表現する最も分かりやすい図を下に掲げます。

この図を見ていると、Kailasでいう業務プロセスのパターン化と似ていることがわかると思います。Kailasでは依頼－依頼受付－単位意思決定（データ確定）－作業－報告・登録としていますが、これがHappy Pathで、Breakdownになると、（KailasはBreakdownに限らず）そこは関係者間のコミュニケーション（言語）によってその行為あるいはデータを確定していくことになります。

この考え方の根本は、「“人間を代行するコンピュータ”から“人間の道具としてのコンピュータ”へ方向転換する」ことにあります。」　これもかねてから、人間主体の業務システムを標榜していることにも通じることでもあります。
　　

Jan DietzのEnterprize Ontology

さて、最後のEnterprize Ontologyについてです。これについては最近聞いたもので後付けの理論です。しかしながら、共鳴部分が多いので勝手に基礎理論であると言っているのです。もちろん、全部が同意できるかというとそうでもないところもあるが、体系化、モデル化してあるので分かりやすということは言えます。

DEMO理論のエッセンスをみていきましょう。まずは、企業活動についてオントロジカルな側面を重要視していることです。ではそうではない部分は何かというと、データ転記のような単純処理であるデータロジカル、計算や加工といった意味付与を伴う処理であるインフォロジカルな活動です。

従来の業務システムは、このデータロジカルとインフォロジカルを主体とした「情報処理システム」であったのです。ところが実際の企業活動は、そうしたものだけではなく、オントロジカルなものが重要であるわけです。

では、そのオントロジカルとは一体何のことなのでしょうか。Ontologyを辞書で引くと、存在論とか本体論という風になっています。よくわかりませんので、コンピューターの世界の話にします。ここでは「知識を共有するために、物事を体系的に分類したり、物事の間の関係性を記述する」ことを意味するとなっています。言い換えれば、「異なる語彙間の関係性を定義する」、もしくは「人間が理解している物事の関係性をコンピューターにも理解できるように表現する」ことだそうです。

それでもよくわからないところがありますが、人間のやることは表層的に現れるもの以外に深層にある文脈的なものがあって、そうしたものはこれまでのコンピューターでははじかれていたのをコンピューターに乗せようという動きです。その概念的なモデルとしてLAPにもとづく会話モデルがあるわけです。

さて、つぎにDEMOにおけるいくつかのモデルについて見ていきます。まずは階層化という概念があります。体系というのは簡単に言うと縦横の関係を整理した構造のことですので、この階層化という概念は重要です。

ここでは、プロセス－活動－行為（活動＋意図）になります。例をあげて言うと、「請求から支払い」があると、その全体がプロセスになります。そして「支払い」が活動ということになり、「支払、要求」や「支払、約束」などの行為があるということになります。

そして、DEMOでは５つのモデルが提示されています。

　■相互作用モデル：活動（行為の連鎖）、アクター、活動の結果の関係
　■相互束縛モデル：活動、行為者、外部情報ソースの関係
　■プロセスモデル：行為、アクター、活動間の関係
　■行為モデル　　：個々の活動の内容
　■データモデル　：オブジェクト、属性、データ型

初めの相互作用モデルと相互束縛モデルは合わせて構成モデルと呼ぶことができます。これらは分子レベル構成要素としてのモデルで、原子レベル構成要素としてプロセスモデルの中身があります。

そして、これらの関係を分かりやすく図示したのが前にも提示した次の図です。（ステートモデルはデータモデルと読み変えてください）いかがですか、これを見て従来の”情報処理システム”ではなく、人が業務を遂行（意思決定）するための活動をちゃんと記述して、そのように動く仕組みと仕掛けが必要になると思いませんか。

ただ、何となく難しそうな理論になっていますが、そんなに難しいことなのでしょうか。人間の行動って理屈ではないわけで、それを理論立ててもなかなかうまくいかないような気がします。それよりももっと簡単に考えて、人間が合理的なアクションを起こせるようITでお手伝いしますくらいでいいのではないでしょうか。

Whatを効率的に構築するためのHow（技法・作法）を考える－その１

さて、だいぶ寄り道をしましたが、今回からはHowの話になります。これまでは、Whatを主体に議論してきましたが、そのWhatをどのようにして作っていったらいいのかいうことです。このHowはWhatによって大きく違ってきますので、初めにきちんとWhatを決めておいたわけです。

Howから入っていくと、似て非なるものや同じものを繰り返して作ったりすることになります。あるいは、人によって作り方も変わることにもなります。従来型のシステム開発は逆にこうしたやり方をベースにビジネスモデルができていたのです。すなわち、人を抱え、その人たちに仕事を与え、その工数で売り上げるというモデルですから、再利用性を高めたり、標準化して開発生産性を上げるインセンティブは乏しいわけです。

話をもとに戻しましょう。これまでのWhatの議論で導かれたものは、パターン化できるものはパターン化して、できないものは、その部分を謂わばブラックボックス化するという考え方です。マクロフロー部分（アクティビティの流れ、LAPでいうHappy Path）は定型的なのである程度パターンとしてもつことになります。

一方、ミクロフロー（アクティビティの中身、Ontologicalなふるまい）では、人間系の要素が入り込むので定型化できないので、情報共有の場というあいまいさを許容したものにし、そのインターフェースをきちんと定義して取り合うことにしています。

ということで、アクティビティの粒度とプロパティを定義しておけば、業務システムは、そのアクティビティの置き方（構成や順序）とその機能とUIを作っていけばいいことになります。

もちろんこれだけの簡単なことではありません。アクティビティの機能といっても様々ですから、それをどうやって作っていくかも問題になります。ただし、このときでも要件に対していちいちコードを書くのではなく、コンポーネントという考え方をとることが重要です。

アクティビティもコンポーネントの一種で、ビジネス機能コンポーネントと呼べるものになります。それ以外にも、システム機能コンポーネントがあります。例えば、バリデーション、検索、印刷、アカウント管理、メール送信とかいったものがそれです。

そう言うとおわかりだと思いますが、こうしたコンポーネントは一度作ったら使い回しができそうだ、あるいはどこからか持ってくればいいといったことが思いつくことでしょう。ですから、究極的にはレゴ細工のように組み立てていけばいいのです。

結局、以前に提示した4つの道具を使ってどういう業務システムを作るのかというのとその道具をどうやって作るかになります。

さて、前置きが長くなりましたが、次回からそのあたりの具体的なHowのことを議論していきます。

コンポーネントについて

システム構築でコンポーネントを組み合わせることを提案しているが、最近ではSOAもそうだがこうした傾向が出てきている。そこで、以前にも紹介した「イノベーションの新時代」（C・K・プラハラード著　日本経済新聞出版社）でも取り上げられているので少し見ていくことにする。

この本では、イノベーションを起こすためには、これからは「顧客経験の共創」と「グローバル資源の利用」を強く訴えているのだが、これを軸とした競争環境において、革新性を発揮するために、ICT基盤に最低限求められる要件を4つ挙げている。

要件１　業務プロセスをコンポーネント化する。
要件２　イントラネットとインターネットを介して、時間と場所を問わない利用を実現する。
要件３　データや外部システムとのオープンインターフェース。
要件４　総合的な分析力。

このように真っ先にコンポーネント化を提案している。これは、“融通の効く“業務システムには不可欠なことなのである。そして著者は、その実現のためには次のような３つのフェーズを踏むのがよいと言っている。

フェーズ１はいわゆるレガシーシステムで、業務アプリケーションごとに、データ、業務ロジック、ユーザインターフェースが独立している状態です。この状態を出発点として、フェーズ２は、ERPのようなエンタープライズソフトウエアの導入である。データ、業務ロジック、ユーザインターフェースが互いに切り離された状態で、とくにデータの一元管理が達成された。

ところが、このパッケージの導入は今言った統合化とか標準化という意味では効果があったが、まだ硬直的な構造のため柔軟性が欠け変化に弱いのだ。そこで、フェーズ３として、コンポーネントベースの業務プロセスを築く必要があると言っている。

そのコンポーネントの定義として、「業務コンポーネントとは、業務プロセスのうち何度も繰り返し実行されるサブプロセスどうしの関係性やルール、それらルールにまつわるデータ、ルールやデータを利用者に見えやすくするためのユーザインターフェースなどを指す」としている。

そして、「業務コンポーネントを合理的な順序でつなぎ合わせると、業務プロセスができる。例えば、顧客や注文などいくつものコンポーネントを用いた作業を、理屈に沿って並べれば、受注プロセスができあがる。」としている。

ただし、このコンポーネントやデータをどれくらい細かく分けるべきかについては、ソフトウエア設計者の力を借りろと言っていて、抽象論としては素晴らしいが、存外そこの設計が難しく、逆に言うとそこをうまくやれるかどうかが技術レベルを決めるような気がする。

いずれにしろ、アメリカで最も影響力のある戦略論の思想家の1人と見なされているプラハラードがこんなことを言っていて、しかもそれを実践している企業が出てきていることに感動するとともに、日本の企業（特にIT産業）もこうしたトレンドをしっかりと受け止めるべきだと強く思うのである。
　　

イノベーションの新時代

posted with yusukebe.com::AmazonSearch on 2010.3.7

• M S クリシュナン C K プラハラード
• 単行本 / 日本経済新聞出版社
• Amazon 売り上げランキング: 47974

• Amazon おすすめ度の平均:
  • 「個客経験の共創」と「グローバル資源の利用」の価値創造戦略
  • 世界的なダイナミズムの潮流、多数の企業事例はおもしろい
  • 事例がイマイチ
  • 肩すかし
  • 主張に新規性なし

Amazon.co.jpで詳細を見る

業務プロセスの強調についても、市場の分析や戦略策定に熱心で日常の業務プロセスに無頓着な米国企業の経営者には、インパクトのある主張かもしれないが、ミドルマネジャーが日々工夫しながら業務プロセスを精緻化している日本企業にとっては、「何をいまさら」といった印象である。

Whatを効率的に構築するためのHow（技法・作法）を考える－その２

前回、どうやって業務システムを作るのかについて、4つの道具を使って作る方法とその道具そのものをどう作るかになると書いた。この後者については、かなりシステム寄りになりここで説明するのも難しいので、それができたという前提で話を進める。

その道具はスーパープログラマに作ってもらうわけですけど、道具のもつべき機能はちゃんと定義してあげなくてはいけないので、そこについては設計のところでおいおい説明をしていく。

4つの道具をおさらいします。それはつぎのようなものでした。

１． Process Designer 　・・・アクティビティの定義とフロー設定
２． Activity Setup　　　・・・案件ごとのアクティビティの要素パラメータの設定
３． Process Overview　・・・プロセスの稼働状況一覧
４． Decision Workspace・・・コラボレーションによる意思決定とデータ入力

Howの大きな流れは、プロセス設計、データ定義、アクティビティ詳細設定といったところになります。ですから、１と２の道具を使って作っていきます。３と４はオペレーションのための道具になります。

すなわち、Process Designerでプロセス設計とデータ定義を行い、Activity Setupでアクティビティ詳細設定を行うわけです。そして、原則コードは書きません。

ではそのプロセス設計のところから入っていきます。業務プロセスをどういう単位で捉えるかは重要なことですが、以前議論したように、ここでは依頼があってそれに応えるまでを一つの単位としています。またヒト・モノ・カネの出入りがあった場合はそこで切るようにしまう。例えば、注文をもらってそれに応じた商品を出荷して納品するというプロセスと代金を請求して回収するプロセスは分けて別プロセスとします。

従って、最初にやることはプロセスの始点と終点を決めることです。どんな依頼があって、それに対してどんな返し方をすればいいのか、あるいはこのデータを作るために何をどうやって決めていくのかといったことを特定することをします。

それが決まると、その間を埋めていくことになります。そのとき、すぐに詳細を詰めるのではなく、全体を俯瞰することが大事になってきます。そこで「コンテ」の作成を行います。「コンテ」というのは映画を作るときに使う絵コンテをメージしてください。映画には脚本があって、シーンがあってカットがありますが、このカットを並べたものをいいます。

Kailasでいうコンテは、業務・仕事のあらすじを表したもので、業務プロセスの構造で見てきたように依頼（起）、依頼受付（承）、意思決定（転）、報告（結）で構成されています。そして、それらを記述するためのシートがあり、そこに記載していきますが、その作法は次のようになります。

１．プロセスの始点と終点を先に決めます。
　　・顧客接点のプロセスの場合は始点を先に決めます。お客さんの要求が最優先となります。
　　・内部プロセスの場合は終点を先に決めます。最終的に決算書（BS/PL）に繋がることを意識します。
２．依頼の内容から、何を決めて、何を答えればいいのかという見方で、意思決定することを決めます。
３．その時、どんな情報を参考にして意思決定するのかを書き出します。
４．最終の報告は、依頼に対する答えを揃えることになります。

次回からは、アクティビティの詳細設定についてみていきます。

Whatを効率的に構築するためのHow（技法・作法）を考える－その３

前回はプロセス全体を俯瞰することをしましたが、それができると次にデータ管理票を作成します。コンテを書いていくときに、確定するべきデータを記入しました。依頼された内容に対する答えをひとつずつ決めていくわけですが、その単位意思決定に伴うデータ確定を定義することです。

この段階で定義する内容は、データ項目とデータ型で、各アクティビティで設定していきます。データ型には、文字列、数値、日付などになります。特殊なものとして、テキストフィールドやURLなどもあります。

この表を見ていくと、プロセスの進行に応じて徐々にデータが確定していくことが分かります。簡単に言うと、依頼票がきて、そこに何も書いていない依頼項目があり、その依頼票の項目ひとつひとつを転記して完成させるイメージです。

こうして書き込まれたデータは、このあと実際のプロセス設計において、この票を見ながら、アクティビティの属性値として、バリデーション（桁数や文字数などの制限）とともに設定されます。実際の修理プロセスの例を下記に示します。

Whatを効率的に構築するためのHow（技法・作法）を考える－その４

続いて、それぞれのアクティビティについて、そのプロパティを詳細に設定していきます。具体的には、これもコンテに従って、それぞれの「アクティビティシート」に記入していくことで設計できます。

ここで、前もって気をつけておくべきことについて触れておきます。

　１．分岐の取り扱い
　　・分岐が最初から静的に存在する場合は、原則、別プロセスとして記述する。
　　・動的な分岐、すなわち前のアクティビティの処理結果で次のアクティビティが変わる場合は分岐として記述する。
　　・表現のし方は、つぎのアクティビティの何を取捨選択かを定義することである。
　２．ロール設定
　　・権限は、起案／確認／確定／承認とする。基本的に、起案と確定は同じ人が行う。
　　・確認という役割は、関係者が複数参画し、必要関連情報、アドバイス、知見やノウハウの提供を行い、起案/確定者をサポートする。
　３．アラート
　　・デフォルトとしては、処理時間は測定し、それがある時間を超えた場合と設定期を超えた場合にアラートをだします。

では、記入すべきアクティビティシートにはどんなものがあるのでしょうか。つぎの６つがあげられます。

　１． 依頼受付アクティビティシート
　２． 意思決定アクティビティシート（固定・分岐なし）
　３． 意思決定アクティビティシート（分岐あり）
　４． 意思決定アクティビティシート（選択）
　５． 作業指示アクティビティシート
　６． 報告・登録アクティビティシート

このシートに記載する項目は共通的な基本項目は次のようになっています。
　・アクティビティID
　・アクティビティ名
　・内容
　・データ（受付データ、確定データ、報告データ）
　・ロール
　・受け渡し書類
　・参照情報

このほか、各シートで固有の項目を持ちます。

　・意思決定アクティビティシート全般・・・アラート（項目と閾値）
　・意思決定アクティビティシート（分岐あり）・・・分岐条件とデータ、選択アクティビティ
　・意思決定アクティビティシート（選択）・・・選択元アクティビティ
　・報告・登録アクティビティシート・・・登録先

例として、意思決定アクティビティシート（分岐あり）のシートを下記に示す。

参照情報

この方法論で特徴的なものとして、意思決定に必要な参照情報をちゃんとそこで見せてあげようというのがある。H・A・サイモンは、意思決定を行う場合の前提として、「事実前提」と「価値前提」があると言っています。

すなわち、置かれた環境や能力に関する事実認識と、何を目的として何を望ましいと考えるかの価値判断である。こうした情報をもとに意思決定を行うのです。

意思決定プロセスからいうと、情報収集や代替案の探索といった段階では、事実前提としての情報を取得する。次の代替案の評価、選択では、価値前提にもとづく情報を参照しながら判断を行うわけである。

ではこうした参照すべき情報にはどんなものがあるのでしょうか。その情報の性格によっていくつかに分類することができます。参照情報は大きくは次の3つになると考えます。
　
　１． 事実情報
　２． 判断情報
　３． 制約情報

さらに、それぞれの情報についてみていきましょう。事実情報も次のように分けることができます。その具体的な情報名もみていきます。

　１． マスタデータ　　　　：商品リスト、取引先リスト、従業員データなど
　２． 履歴情報　　　　　　：販売実績、トラブル履歴、工事履歴など
　３． 計画情報　　　　　　：予算、中期計画、工事予定など
　４． 外部環境情報　　　：競合他社情報、為替レート、地図など

要するに事実として存在するデータなどで、ヒト・モノ・カネ・情報などの時間的な要素（過去、現在、未来）に対するものである。つぎに、判断情報ですが、同様にみていきます。

　１．業務ルール（判断基準） ：与信限度額決定基準、担当者決定ルール、自動発注ルールなど
　２．リソース状況　　　　　　　：要員管理表、設備稼働状況、配車繰り表など
　３．シミュレーション・計算　 ：参考見積、スケジューリング、コスト計算など
　４．外部サービス　　　　　　 ：与信チェック、特許検索サービス、各調査など

ここは意思決定をする際に参照するもので、そういう意味では重要な情報となります。前にも言ったように、ここに戦略的あるいは差別的な要素を反映させることが往々にしてあります。例えば、与信限度額について言えば、この限度額の多寡でリスクテイクの方針が現れます。

最後の制約情報も最近の企業経営では、コンプライアンスやリスクマネジメントといった観点から重要性が増してきていると思います。その分類と具体的な例をみていきましょう。

　１．契約・規約　　：法規、販売契約、品質管理規定、チェックシートなど
　２．制約条件　　　：休日不可、キャンペーン、地域限定など

こうしてみると、企業における意思決定には多くの情報を参照していることがわかります。しかしながら、従来はこれらの情報が分散、偏在していて十分に参照できていなかったのではないでしょうか。現在のITの威力はこうした情報の収集および処理能力にあるわけなので大いに活用したいものです。

成長するオペレーションの重要性を認識する－その１

さて、今回からは最後のテーマであるオペレーションについてです。ここで「成長するオペレーションの重要性を認識する」という表現にしたのは意味があることなのです。ではその“成長する”ということを考えてみましょう。

その前に、業務システムのライフサイクルのようなことをみると、最初はこんな仕組みを作りたいという要求定義のところから入って、それを設計し、開発していくわけですが、よくあるのは、ここで止まってしまうことです。作って終わりということです。

作る人と使う人が違うからといえばそうなのですが、大事なのは両者がお互いの領域に入り込むことが必要です。（究極は使う人が全部自分でやってしまうことですが）すなわち、ユーザは設計や開発にも加わること、ベンダーは業務運用まで考えた設計・開発を行うことでしょう。

ここでは、誤解をおそれず言うと、作ることより、使う方が重要であると言っているのです。そして、システムというのは、当然のように使ってみて効果を出すことで価値があるわけですが、実際問題として、使ってからでないと分からないことがあるので最初から完璧なものはできません。

ということで、使いながら、運用しながら改修、改良しながらより良いものにしていくという精神が大切になってきます。言いかえれば、現代は非常に外部環境の変化が激しいから、そうせざるを得ないとも言えるのです。

そうしたことができる業務システムを志向しなくてはいけないし、たえず学習し、成長していくための仕組みと仕掛けをどうするのかが大きな課題となります。

そして、何よりも基本的にやらなければいけないこととして、オペレーションプラットフォームという場を提供することです。サイモンにしてもバーナードにしても、個人の合理性には限界があるから、企業活動は組織的行動であるべきだと言っている。

ということは、複数の人間が協働してより良い意思決定を行うことができるプラットフォームこそが、これから必要となるシステムなのではないでしょうか。動けばいい、正しい計算をしてくれればいい、きれいに帳票を出してくれればいいということではないということがお分かりになったと思います。

次回から、この協働（コラボレーション）する仕組みと実際にそれをどうオペレーションしていくのか、さらに学習と成長という仕掛けを施していくのかについてみていきます。

成長するオペレーションの重要性を認識する－その２

以前、4つの道具の話をしました。すなわち下記のような道具を使って設計・開発を行い、またそれを使って動かすということでした。

　１．Process Designer 　・・・アクティビティの定義とフロー設定
　２． Activity Setup　　　・・・案件ごとのアクティビティの要素パラメータの設定
　３． Process Overview　・・・プロセスの稼働状況一覧
　４． Decision Workspace・・・コラボレーションによる意思決定とデータ入力

実は、これらの名前も少し変えていくつもりですが、これまでのいきさつからそのままにしておきます。この４つのうち１と２は設計・開発で使いますので、すでに説明したとおりですが、オペレーションでは３と４を使います。

ただ、案件が発生すると、Process Designerから設計することもあるし、案件ごとのプロパティ設定は２で行いますので、これらもオペレーションの一部ということもできます。では、実際に案件が来たところからみていきましょう。

まず、あるサービスの要求があったとき、もし過去のプロセスと同じものであれば、Process Designerのレポジトリーにあるプロセスをコピーすればいいのですが、新規の場合はプロセスを作っていきます。このやり方はHOWのところで説明したとおりです。そして、このProcess Designerで設定したものをデプロイします。

次にActivity Setupで案件IDや参照情報、権限、アラートなどの案件特有の設定を行います。それが終わると、３のProcess Overviewにその案件が現れます。そこでは、案件ID、案件名と各アクティビティといまアクティブになっているものが色変わりで表示されています。

Process Overviewの使い方は、現在稼働中の複数のプロセスの状況が一覧できるもので、各プロセス進捗状況をチェックします。ですから、どちらかというとマネジャー用の監視ツールです。オペレーションで監視というと必ずアラートが必要になります。すなわち、異常状況が現れたら警報を鳴らすというものです。

本来は、常時監視していち早く異常を発見するのが望ましいでしょうが、いつも見ているわけにはいかないのでアラート機能をつけるわけです。ただ、問題は、何を監視しておくのかという監視対象を特定するのが案外難しいことがあります。

こうしたパフォーマンス要素を何に見出すかというのは、戦略的あるいはトップダウン的に決めるものかもしれません。例えばKPIをそこに落とし込むようなことが考えられます。しかし、これはかなり難しく、ここではプロセス自体のパフォーマンスを時間的要素でチェックすることだけにしておきます。

すなわち、アクティビティごとの処理時間とプロセス全体の処理時間です。それと、期時、期日です、そのアクティビティあるいはプロセスを終わらせる時間、日を設定するわけです。こうした閾値としての時間、期日を超えるとアラートを発する仕掛けです。

また、この画面では過去に完了したプロセスの履歴を出すことができるようにしておきます。類似のプロセスでそのときどんな実績であったかを引用して、現在動いているプロセスをチェックするような使い方になります。
　　

パフォーマンス

オペレーションのところでアラート機能について、パフォーマンスのチェックであるという話をした。そして、まず最初は時間的な監視でいいじゃないかと言ったが、まあ、これはどんなプロセスに対してもデファクトとして通用するからである。

ところで、よく考えてみると、簡単にパフォーマンスと言っているが、どうやら二つの意味があることがわかる。一つは、いま言っているようにプロセスそのもののパフォーマンスのことで、そのプロセスがいかに早く効率的に動いているかである。こうした角度で見た場合他にはコストと質があると思っている。いわゆるQCDである。

業務プロセスの場合のコストはほとんど時間と同義なので、時間を見ればいいと思うが、では質をどうやって測定しチェックいたらいいのだろうか。それは手戻り率ではないかと考えている。

なぜなら、Kailasでは、プロセスは意思決定の連鎖だと言っているわけで、質の悪い意思決定を行ったとき、どこにその影響があらわれるのだろうかと考えると、それは手戻りとなって出てくるのではないかと思う。すなわち、差し戻しにあってやり直すという結果になるということである。

もうひとつは何だろうか。それはビジネス上のパフォーマンスで、例えば納期順守率だとか在庫回転率、あるいは欠品率だとかいった指標である。確かにこうした指標はBSC（バランススコアカード）などの検討から導き出されるので、重要なのだが、問題はそれを監視しチェックするにはどうしたらいいのかということである。

だから目的関数はわかるのだが、変数を何にするのか、それが現実に測定できるのか、あるいはリアルタイムで監視することができるのかといったむずかしさがある。しかしながら、戦略的、戦術的に非常に重要であればそれをやらなければいけないので大きな課題となるのだろう。

ここで言いたいのは、パフォーマンスとひとことで言っても、ビジネス的なものとオペレーション的なものの2種類があって、それぞれで何を変数としてもってきて監視するのかをきちんと定義しないといけないということなのである。

そして、結果を分析的に解析することは比較的できるのだが、それでは“あとの祭り”になるから、リアルタイムで解析・監視をするということがことのほか大変なのである。事後的な監視はやさしいが、その場で手を打つことは難しいからだ。ただ、ITの進歩はこうしたことを可能にするかもしれない。ここら辺りは、こ今後のOperation　Exceｌlenceのキーポントかもしれない。
　　

成長するオペレーションの重要性を認識する－その３

前回はProcess Overviewを使って、稼働中のプロセスを監視することを議論しました。そこで俯瞰的にプロセスの進捗を管理しておいて、その中の個別プロセスを進めていくのは、「Decision　Workspace」を使います。

そこには、大きく、「データ確定」「フロー」「コメント」「参照情報」「権限」「承認」といったエリアが配置されています。これらを見たり、書いたりして最終的にはデータを確定し、それを承認してそこのアクティビティを終わらせることになります。

「データ確定」では、Designerで定義したデータ項目の入力フィールドが現れるので、そこに入力していきます。このとき、データを確定するためにはいろいろ情報を参照しながら決めていくので、あらかじめ設定した情報を見ながら行います。最初は、起案者として権限を与えられた人が、データを入力します。

それに対して、確認者あるいは承認者に指名されたひとたちが、同じ参照情報をみたり、コメントに自分の意見をいれたり、確認したりしてデータを確定していきます。このとき、確認者に指名されたのに何もコメントがない場合はOKしたとみなします。ここら辺りはオペレーション上重要なことで、よく若いやつがやっていることを脇で冷ややかに見ている先輩社員がいますが、そういう図式はなくしたいのです。

ここでデータの確定は普通は起案した人がやることになりますが、fixボタンを押すと承認伺いにいきます。従来のシステムだと承認伺いがなくて、承認者は自分で承認用の画面を開いて、へたすると何も見ないで一括承認したりします。メールで連絡が来る場合もあります。心ある人だと部下に確認したりしますが、ムダな時間を使うことになります。

しかし、Kailasでは、このDecision　Workspaceで承認します。基本的に承認者は、先ほど言ったような起案から確定までのいきさつをみていなくてはいけません。必要ならば、コメントを書いてもかまいません。そのことによって、承認するときにどういう決め方をしたのか、どんな意見を聞いたのかがわかるので、すぐに承認できるのです。この早さもさることながら、業務プロセスに責任を持てるということにつながるのです。

ここで一つのアクティビティを承認すると次のアクティビティに進みます。その様子はフローのところで色変わりによって視認できます。こうして、順次アクティビティを進めていき、最後は完了ということでその案件についてのプロセスオペレーションを終わらせます。もちろん、この実績は、履歴といて保存され、あとで検索して見ることができますし、参照情報として持つこともできます。

このDecision　Workspaceの重要なポイントは関係者が参加して行う協働作業によって、業務を進めていくことです。このことにより、以前にも指摘したように、意思決定の質が向上することと、技術・ノウハウ・経験の伝承がもたらされます。先ほど書いたように、経験のある先輩が若い人にアドバイスすることでこうした効果があると思います。

これで、オペレーションについて終わりますが、少し重複するような話ですが、オペレーションという側面が大事だよと何度も言っていますが、今見てきたように、同じ目的でみなが一緒になって仕事をして、それがどう動いているか見えているというのが重要なところだと思います。それができてこそ、そのプロセスに責任がもてると同時に、自分たちの事業に、あるいは新たなビジネスモデルにフィットするものにすることが可能になるのです。
　　

まとめのまとめ
18回にわたって展開した「業務システムの再定義」はこれで終わりますがいかがでしたでしょうか。具体的なツールの実際や、事例による設計といった詳細については物足りなかったかもしれませんが、これはもう少したったらまた記事にするつもりでいます。その前に、この考え方に基づいて開発した「Kailas」という方法論とフレームワークで実際の業務アプリケーションを作っていこうと考えています。

ここまで書いたことをどれだけの人に理解してもらえたかはわかりませんが、おそらく従来のものとかなり違った部分があるので様々な反応があると思います。こんな“ゆるい”やり方ではシステムとはいえないとか、しょせん基幹系には使えないよとか、ボリュームが増えたらこんなことやってられないとか、そうした声は当然だと思います。

しかしながら、だからといってそういった要望にこたえるつもりはありません。あくまで仕事のやり方を実装しようとしていますから、仕事のやり方と合わないと言うなら聞きますが、従来のシステムができたことがなぜできないのかというようなことには応えないということです。

ですから、既成概念で固まった会社は、ユーザであれITベンダーであれ相手にしたくありません。生意気かもしれませんが、「Kailas」のコンセプトや技術を理解し賛同してくれる人、会社と一緒にやれたらと思っています。そうなると、案外既成ITを知らないベンチャーなのかもしれません。

どうもIT業界ではいまのままでダメだから何とかしようという声も上がってきていますが、やはり既得権を失うことの怖さと大変さを超えられないように思います。とはいえ、世界ではビジネスモデルが変わってきています。米国は失速気味ですが、ヨーロッパにおけるフィロソフィーに裏打ちされた標準化、体系化の動き、中国・インドの上流工程志向などずいぶんと動きも早くなっています。

このテーマで何度も出てくるように、ITやシステムというのは、会社が行うビジネスや人間が行う仕事、あるいはユーザが要求するサービス提供を支援する道具であるべきです。こうした考え方を前面に置いたとき、どんな業務システムが望まれるのでしょうか。

けっしてこれまでの業務システムの延長ではないと思います。作り手側の論理から使い手側の論理へと比重を移すべきであり、それによって、”役に立たない正しいシステム”を作り続ける愚から脱却することができるはずです。

おわり。