ユーザのためのシステムを作るんですよね
第1回目は、誰のためのシステムなのかということから始める。こんなことは皆当たり前に分かっているとお思いでしょうが、実は、勘違いも含めて、え、そんなことも分かってないのということがある。
最近、ある二つのカンファレンスに出席してみて感じたことが、そのあたりの状況を見てとれる。それは、「Developers Summit 2007」と「経営とITの融合（KIU）」研究会主催の「第１回 アジャイル・エンタープライズ・カンファレンス」で前者はソフト開発者の集まりで、参加者の多くがプログラマーやSEの若い人たちであり、後者はどちらかというと企業の情シ部門の人だとかSIベンダーのコンサルタントの人だとか、比較的年配が多いカンファレンスであった。
簡単にいえば、システム開発というのは、ユーザとSIベンダーのコンサル・SEとソフトハウスのプログラマーという三者の協業で作られる。この場合、企業の情報システム部門はユーザなのかSIベンダーなのかだが、そこは、情報システム子会社も含めてSIベンダーのほうに入れて考えたほうがよいだろう。そういう意味では、「Developers Summit 2007」プログラマー主体、「第１回 アジャイル・エンタープライズ・カンファレンス」はコンサル・SE主体であり、ユーザの参加は少なかったように思える。
そこで感じたことは、この三者の間のギャップなのです。別な言い方をすれば、システム開発の上流設計から製造までのプロセスが分断されているというか、うまく受け渡しがなされていないように思える。
要件定義は、経営戦略的にこうすべきだから、そのためのビジネスのゴールを設定して、それが実現できるように仕様を決めていくべきだと言われても、それはあくまでSIベンダーサイドの言い分であって、ユーザは本当にそう思っているの、ユーザのプロジェクト担当者だけ思っていることではないのとツッコミたくなる。
また、開発者サイドも自分たちの得意エリヤで、自分たち独特の言い回しで、自分たちだけで楽しむという一種のムラ意識があるように感じる。彼らのセッションでは出席者から「アウエーの雰囲気だったけど・・・」というような言葉も出てくる。どうも上流のビジネスプロセスがどうのこうのということに興味がないようだ。
ユーザからみると困ったもので、このギャップを埋めて欲しいと願っている。ただそれがすぐにできるとは思えない。なぜなら、本質的なあるいは構造的なといったほうがいいかもしれないがそういう問題が潜んでいる。
どういうことかと言うと、ユーザとSIベンダーとの間で言えば、両者の利益が相反するということが一番大きい。SIべンダーは自分たちの商品が売れればいいし、開発にかかった工数分の費用がもらえればいいのであって、それによってユーザの事業の役に立っただとか、収益に寄与したかなどどうでもいいのだ。実際にどこもがそうやっていると言っているわけではなく、本来的にそういう体質を持っているということなのだ。
開発者の場合について言えば、技術をというか技能といったほうがいいかもしれないが、それを極めるには必然的に足元の世界にのめりこむ。だから、同様にビジネスに貢献するとかという思考回路はあまり働かない。
開発者は無関心、SIベンダーとユーザはお互い嘆きあう構図はもううんざりだ。さて、どうしたらいいんだろう。そこはこれからの議論で追々詰めていくことになるが、少なくとも、「システムとはユーザのためにある」ということはよろしいでしょうな。
それで次回は、そのユーザとは誰のことかというテーマで書こうと思います。
システムをデザインする
それでは、奥出直人の言う「デザイン思考による創造のプロセス」にもとづき、情報システムの開発について考えてみることにする。
「デザイン思考による創造のプロセス」とは、“社会的背景や哲学的背景を踏まえた上での考え方、作り手の問題意識を表わす哲学を考えるところから始めて、具体的に何を作りたいかビジョンを決め、それを持ってフィールドワークに行き、どのようなものを作るかコンセプト／モデルを作り、機能やインタラクションを検討しながら実際の設計デザインを行い、実証する。つぎにビジネスモデルを構築して、実際の運営方法を決定する”プロセスのことと言っている。
そのそれぞれのステップについて追いかけるが、より重要なプロセスとして上流のプロセスの最後であるデザインするところまでを取り上げる。
まず、ステップ１「哲学とビジョンを構築する」ことだが、企業の情報システムであれば、会社の経営理念や方針あるいはもう少し狭くて部門の運営方針といったものが哲学やビジョンに相当する。さらに、最近よく言われるＥＡ（Enterprise Architecture）もこれにあたるものである。
ついで、ステップ２「技術の棚卸とフィールドワーク」は、従来の方法では、ビジョンからすぐにコンセプトへとつなげるが、ビジョンとコンセプトを明確に分け、この二つをつなぐ作業として位置づけられる。この考えが非常に重要である。
技術の棚卸しとは、アイデアや技術をたくさん集めて並べ、それをビジョンに割り振ってみるやり方であり、フィールドワークとは、ビジョンに基づき自分のビジョンを実現してくれるだろう「師匠」のところに出かけ、弟子入りし、みずからの経験を拡大していく、その記録を分析して「ワークモデル化」した段階で「魔法のシナリオ」と呼ばれるものを書く作業を行なう。「初心者であることは素晴らしい。それは自分の知らないことを知って、驚き、不思議に思う、その差分が価値を生むからだ」ということである。
これを、システム開発にあてはめてみると、いわゆる現場ヒアリングという行為に相当するかもしれない。しかし、いま実際にやられているのは単に現状業務の手順や問題点を聞いているだけで、ビジョンをきちんと確立してから行っているわけではないし、そもそもデザインするというマインドを持っていないと言える。ここは非常に重要なポイントで、ユーザニーズを聞くということももちろん大切だが、実現したいビジョンを頭の中に入れて、そのために現場のエキスパートをよく観察して分析する姿勢が肝要である。
ステップ３はいよいよ「コンセプト／モデルの構築」に入る。コンセプトというのは、アイデアをいくつか組合わせて、具体的にどのような技術でそれが可能になるかを検討していき、そこで生まれたビジョンを実現するための具体的な方法とその構造をいう。なおコンセプトには技術の裏打ちが絶対必要であることを忘れてはいけない。そのコンセプトを実現するための基本構造や仕組みを選んだり作りだしたりする作業を「モデル」を作るあるいは探すと呼ぶ。
そしてダーティプロトタイプあるいはラピッドプロトタイプと呼ばれる原初的なプロトタイプを作っていく。このあたりのやり方は、システム開発でいうプロトタイピング手法であるが、この場合はコンセプト形成はやってない場合が多く、しかもプロトタイプというとどちらかと言うと画面や帳票といったユーザインタフェースが中心で、システムの構造やプロセスの動きなどは分からないため、ここでいうステップの作業とはずいぶんと違う。
これからの開発で必要なのは、システム全体が見渡せるプロトタイプができる道具が要るということ、その道具は簡単に安く作れ、ラフなものからだんだん精巧なものへ進化させることができ、それを皆で議論しながらやっていける、そんなものが欲しいのだ。プロセスモデラーやシミュレーターみたなものが機能を追加すればこれにあてることができる可能性がある。
また、コンセプトの一部はＥＡから引用してくることができる。
このステップでおおかたのシステムの構造やプロセスの骨格が決まってくる。
上流プロセスの最後は、ステップ４「デザイン－ デモンストレーション用プロトタイプをデザインする」である。デザインとは、機能を考えながら必要な要素を集め、構造や仕組みをつくっていく作業である。
これは、まさにコンポーネント開発に他ならないのではないでしょうか。そして、大事なのは、見えるもの（プロトタイプ）を早く作ってそれを見ながらデザインしていくということである。
こうしてみていくと、「デザイン思考」ということが、情報システムの開発にも適用できる、いやこうした思考方法が非常に重要であることがわかると思う。
なお、デザイン思考を活用するために使いこなすべき道具として、「経験の拡大」「プロトタイプ思考（build to think）」「コラボレーション」の３つを上げている。
この3つについて簡単に言えば、「経験の拡大」とは現場の人間の動きをよく観察せよということであり、「プロトタイプ思考」は見えるものを実際に作りながらスパイラルアップして行こうというものであり、同じ言葉が話せる精鋭による「コラボレーション」で作業することと理解できる。
今回は、「デザイン思考」によるシステム開発プロセスの有効性について書いたが、実際のワークモデルなどより具体的な手法の話まではここでは言及しない。なお、次回は、道具としてのＢＰＭの可能性について考える。
SAPの変化を見ると分かってくること
これまで、Whyと上位概念としてのHowを中心に、本当にユーザに役立つシステムを作らなければいけないこと、そのためにはユーザと作り手が一緒になってシステムをデザインするという思考が大事であるというようなこと議論した。
ここからは、どんな構造のシステムを作るのか、それをどんなMethodologyや道具を用いるのかというWhatとHowについて論じていくことにする。
まず、「道具としてのBPMの可能性」の前に、企業情報システムの変遷をみてみる。ここで教科書に書いてあるようなことを言ってもおもしろくないので、世界最大のERPであるSAPの変化の過程（SAPは進化と言っているが）を例に考える。
SAPのERPは現在「mySAP ERP2005」というのが最新バージョンであるが、その前1992年に投入されたSAP R/3というのが有名でこれによって大きく普及した。R/3というのは、メインフレームのシステムであったR/2からクライアント･サーバー型に移行したもので、今までばらばらであった基幹業務システムを統合し、システム間の整合性をとることに威力を発揮した。そしてよく言われたのが、バッチからリアルタイムへと変わるということで、その当時、一度入力するとすっと最後まで行ってしまうから入力するとき怖くて手が震えたといった話をしていたことを思い出した。このリアルタイムということには誤解があってそれについては後で述べる。
この時点でのERPの特徴は、統合化、リアルタイム化、標準化（グローバルスタンダード）であった。しかしながら日本ではこのうちリアルタイム性とグローバルスタンダードは合わないため、メインフレームで統合化されたシステムを持っているところは、それほど魅力があったわけではなかった。
そして、つぎに出てきたmySAP ERPで大きくコンセプトを変えることになる。それは、ESA（Enterprise Service Architecture）と呼ばれる、いわばSOAの概念を採り入れたことだ。そして、ポータル、データ連携、BI、マスタデータ管理などのシステム基盤であるNetWeaverをリリースしたのである。このESAのアーキテクチャは非常に重要でこの理解がないといくら新しいERPを入れても無駄だ。
わが国でもいま少しずつ分かってきていると思うが、おそらく本当にここを理解しいているひとは数少ないのではないでしょうか。だからまだ、アドオンをいっぱいして旧来型の作りにしているプロジェクトも多いかもしれない。どこがどう変わったかを検証すると、ここで議論しようとしているシステム開発の方法の参考になる。というか、結局めざすところは一緒なのだということがわかる。
新バージョンの価値をひと言で言うと「情報を起点としたオペレーションと管理」ということになる。すなわち、情報が業務のアクションを誘導することであり（これが最初に言ったリアルタイムということなのだ）、常に事業の状況を監視し、異常が生じたらワーニングする仕組みなのだ。
そのため必要なことは、シンプルで一貫化された業務プロセスでなくてはならないということと、それが可視化されていることが重要である。従来は、この業務プロセスがすでにSAPにあって、それを使えるかどうかと考えるイメージだったと思う。そして、もし自社のプロセスが合わない場合、２つの誤った方向に走ったわけです。ひとつは、無理やりSAPに合わせて窮屈な思いをする。もう一方は、現状システムを生かそうとしてアドオンの嵐となる。
これが新しいSAPの姿では、標準化された機能を組み合わせてプロセスを自社の要件に合わせて組み上げるイメージです。従って、自社のプロセスと機能（機能とプロセスは明確に分離することが肝要）を特定し、業務プロセスを個性化することができるのです。よく、ERPパッケージは要件定義する必要がないように言う人もいるが、このように要件定義が重要なステップになるのです。
「システムの枠組みにプロセスを合わせる」ことから、「プロセスに必要なシステムを組み合わせる」ことに大きく舵を切ったことをよく認識することが必要です。これって、なんかBPMでしょ。そうなのです。SAPの今の姿はSOA基盤に乗っかったBPMシステムなのです。
SAPという会社はこのパッケージだけに多くの人間を抱え、日夜開発にいそしんでいるわけで、それを考えるとIBMより大きな会社とも言えるし、そのシステム開発のトップランナーがこうした方向性を示していることは特筆すべきであろう。
余談になるが、奥出教授の「デザイン思考の道具箱」によれば、SAPの共同創立者であるハッソ・プラットナーはスタンフォード大学のデザインスクールに3500万ドルもの資金を提供して「デザイン思考」の研究を支援しているのだ。SAPの懐の深さを感じる。
どうやって開発するか
さていよいよ、開発方法の話になります。開発というと忘れらない言葉があって、開発につきまとう２つのジレンマについてのことだ。その２つの大きなジレンマとは
１．アプリケーション仕様のほとんどが、結局、ユーザの恣意でしか決まらないこと
・・・仕様を決定付ける科学的、工学的なモデルが存在しない
２．情報システムと人間の境界が、元来不安定であること
・・・実業務の様々な例外をコンピュータ上に乗せるか否か
ということで、このジレンマを克服しないうちは、前に言ったようにユーザとITがお互いに嘆きあう状況はいっこうによくならない。ただ、ユーザ側からみれば、ある意味当たり前で、システム屋が困ろうが知ったこっちゃないのであって、目の前にあるビジネスをどう切り回すかだけを考える。だから、ITはそこで役に立って当然で、ITが足かせになるなんてもってのほかなのだ。
極論すると、社長が“こうしたい”と言ったらすぐに実現しなくてはならない。昔、松竹新喜劇の藤山寛美がリクエスト公演というのをやったけど、お客さんが望んだものをすぐに提供できるのがプロのシステム屋のすることでしょう。それを、“うちのお客はわがままなことばかりで全く困る”と言っているようではダメなのだ。確かに無茶なユーザがいて頭にくることは分かるが、そんなやつらを軽くさばくのがプロではないでしょうか。プロの定義は「ひとのせいにしないこと」だ。こうしたユーザの“ぶれ”とそれともうひとつ変化のスピードを前提とするなら、どうも従来型のアプローチでは対応が難しいように思える。ということは、システムの作り方を変えていかなくてはいけない。だからこそBPMが有効な手段である可能性を感じて探っているわけです。さて、BPMは”ビジネス機能、あるいはサービスをコンポーネントとして持って、それをBPMで組み合わせてプロセスを作り、それらプロセスの集合が業務アプリケーションとなる”と考えていきたい。その最初のコンポーネントを業務コンポーネントあるいは業務モデルと呼び、それをどんな方法で作るのか、あるいはどこかにすでにあるのかといったことが最初の議論となります。このあたりの試みはもちろんだいぶ前から行なわれていて、いろいろな角度からの検討があります。その結果としてERPやその他業務パッケージになったものもあり、また、データモデリングという切り口で見ているものもあります。そこで、少し最近の動きとして、「要求開発アライアンス」と「ＤＯＡ＋コンソーシアム」という2団体に注目してみていくことにします。両者のアプローチは違うが業務フローや業務モデルを描くという点では共通点があり、BPMが必要とする業務コンポーネントの生成についてどう取り組んでいったらよいか非常に参考になるし、場合によっては連携も考えられる。次回にこれらの団体の考えていることとその利用などについて述べていく。
「要求開発アライアンス」と「DOA＋コンソーシアム」
「要求開発アライアンス」というのは、2003年5月にビジネスモデル研究会としてスタートし、2005年3月に「要求開発アライアンス」として発足した団体。豆蔵の人たちが多く参加していますが全部で13人が発起人みたいになっています。当初、「要求開発宣言」としてまとめられたものが、このアライアンスの趣旨を表わしているので、長くなるが引用する。
・情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである。
・情報システムは、それ単体ではなく、人間の業務活動と相互作用する一体化した業務プロセスとしてデザインされ、全体でビジネス価値の向上を目的とするべきである。
・情報システムの存在意義は、ビジネス価値の定義から要求開発を経てシステム開発にいたる目的・手段連鎖の追跡可能性によって説明可能である。
・ビジネス価値を満たす要求は、直接・間接にその価値に関わるステークホルダー間の合意形成を通じてのみ創り出される。
・要求の開発は、命令統制によらず参加協調による継続的改善プロセスを指向すべきである。
・「ビジネスをモデルとして可視化する」ということが、合意形成、追跡可能性、説明可能性、および継続的改善にとって、決定的に重要である。
これに基づき、モデリングのやり方やビジネスフローの標準化など要求開発の方法論が提示されている。
体系的でよくできていて、例えば「モデリングガイドライン」というのがあって、その中に「ビジネスフロー編」があるが、まずUMLアクティビティ図から業務の流れとシステムの関係を捉え、そのアクティビティの粒度の基準があって、それを調整して標準化するやり方が書いてあったりします。
ただこうした手法も有効かと思うが、トップダウンアプローチ的なところがあり、もう少し泥臭いやり方でいいのではないかと思ってしまう。
「DOA＋コンソーシアム」は、2003年12月に設立された。一体ここは何をめざすのかですが、この会の代表幹事であるデータ総研の椿正明さんの言葉を引用してみます。ちなみに、その他の代表幹事が東京国際大学の堀内一教授、株式会社エス・ディ・アイの佐藤正美さんという、DOAをかじったことがあるひとはびっくりするメンバーです。（3人が一同に会することも含めて）
システムの上流工程にモデルアプローチを適用するのが正解とされつつありますが、ＤＯＡなのか、それともＵＭＬによるＯＯなのかについては、迷っておられる方が多いように見受けられます。さらにＯＯについては「人の数ほどいろいろなやり方がある」、また「ＤＯＡについてもいくつかのアプローチがある」ということで余計な混乱を招いているようです。
われわれは、「情報システムの製品は画面・帳票であり、これと直結したデータがシステムの基盤を作る」として、「まずはＷＨＡＴとしてのデータを固め、次にＨＯＷとしての処理を考えるＤＯＡアプローチが正解なのではないか」と考えます。そして９０年代、メインフレームからＣ／Ｓ、あるいはＥＲＰへのシフト に追われているうちに、「ＤＯＡ技術の継承が中断され、危機的状況にあるのではないか」と心配しております。そこで「これを解消したい」との思いから、かつてのＩＲＭ研究会を思い出しながら、「ＤＯＡ＋コンソーシアム」を立ち上げることにいたしました。
狭く簡単に言うと、DOAとOOは対立するものではなくうまく棲み分けすることができるはずで、そのためにはUMLとの融合あるいはOOPとの接続が論点だとしている。
BPMではデータについてはあまり議論されていません。業務の構造は、プロセスモデルとデータモデルで表現されるものですから、しっかりしたデータベースの構築は非常に重要です。そのためのアプローチはDOAが一番です。ですから、BPMとデータモデルはうまく連携する必要があります。従って、DOAでデータモデリングすることは必須になると考えます。
詳しくは次回に。
DOAによるデータモデリング
DOA＋の手法についてはいくつかあって、代表的なのが「T字形ER手法」、「THモデル手法（PLAN-DB）」、Xprime（Xupper手法）、「三要素分析法（渡辺法）」などである。それぞれ特徴があるが、THモデル手法を開発したデータ総研の椿さんの考え方を中心に書いてみる。
前にも言ったように、業務モデルは「プロセスモデル」と「データモデル」から成り立っていますが、この業務モデルは実装独立であることが重要です。例えば、受注という業務を考えたとき、顧客、商品、数量、納期、金額などのデータが扱われますが、これはいつの時代でも変わらないもので、変わるのは実現手段です。従って、業務アプリケーションソフトウエアは「業務モデル」を実装手段を用いて実現したものとなります。ここが今まで一緒くたになっていたと思われる。
さて、業務モデルの構成要素を椿さんは次のように定義しています。
クライアント側の要素 ： 「人」と「IO」
サーバー側の要素 ： データベース、エンティティ、データ項目
これらの要素をフロー図やIOイラスト、概念DB構造図、データ定義書などに表現するわけです。そして、こんなことも言っています。
われわれの夢は、今は価値がないとされる業務モデルのコンテンツが流通し、市場価値を持つようになることです。ある単位の業務モデルリポジトリのコンテンツをライブラリとして貯え、これを適宜選択・組合わせて、自社に合ったデータモデルを構築することができれば、「パッケージに身体を合わせろ」と言った妥協を大幅になくせるものと考えます。これをアメリカより、１年でも２年でも早く実現するのです。そうすれば９０年代に付けられた差を一気に逆転する可能性すらあるように思うのです。
そうですよね、椿さんはもう70歳を越えて益々元気なひとで、そのアグレッシッブさには頭が下がりますが、ぜひ夢を実現していきましょう。
つぎにDOAの条件として、「データ先行・リソース先行・概念先行」ということになります。データをプロセス／処理に先行して考え、イベントデータ（受注・出荷・請求など）より先にリソースデータ（社員・顧客・商品など）を固め、物理データベースより概念データベースを先行するという意味です。
こうして、DOAで業務アプリケーションの開発をやってみると、データ構造からみてつぎの6種類に分類できると言っている。
Ａ．建設：見積－受注－建設計画－建設－検収
Ｂ．生産財製造業：受注－生産計画－生産－出荷
Ｃ．消費財製造業：販売計画－生産計画－生産－受注－引当－出荷
Ｄ．卸業：販売計画－仕入－受注－出荷
Ｅ．小売業：販売計画－手配－販売
Ｆ．サービス：契約－設定（工事／担保）－サービス－検収
また、企業はこのように基幹系業務は、Ａ－Ｆの６種類に分類できるが、企業にはこのほかに、次のようなリソース（経営資源）整備軸とも言うべき６種類の業務アプリケーションがあるとのこと。これは、別な言い方をすれば、コア業務システムを支えるサポートシステムとも言える。
１．人材調達・育成（人事）
２．市場開発・保守（ＣＲＭ）
３．設備建設・保守
４．商品開発・改良（ＰＤＭ・ＰＬＭ）
５．資金調達・利殖（財務）
６．情報システム開発・保守
まあ、ここではDOAがメインテーマではないので、かなりざっくりとポイントだけ書いてみましたが、何となくBPMとDOAの関係がわかったでしょうか。
例えば、上記業務アプリケーションに必要なデータモデルがあるでしょうから（なかったら、この手法で開発する）、それを使ってBPMでプロセスモデルを生成するというスタイルは有効のような気がします。というより、データモデリングとうまく連動しないといけないのです。
この他、これから注目したいのは、羽生章洋さんのABD（Activity Based Datamodel）や仕事の流れを表現するマジカあたりで、気になるところです。
業務プロセスモデリングの進め方
ここでは、業務プロセスのモデル化を行い、できあがったプロセスからある単位（粒度）で切り出してコンポーネント化する作業のとっかかりのところを議論することにする。
まず、要件を定義していくとき、トップダウンアプローチなのかボトムアップアプローチなのか、AsIs先行かToBe先行かという問題があります。ここでいうトップダウンアプローチとうのは、経営管理あるいは事業運営上必要となる要件、いわゆるビジネスモデル的なハイレベル要件から見るもので、ボトムアップアプローチというのは、逆に業務フローをまわすための要件、いわゆるオペレーショナルなローレベル要件からみるものであるが、当然両者とも必要なアプローチであるが、筆者は最初はローレベル要件から入って、そこを固めてからトップダウン的にこだわり要件を付加していくやり方が現実的であると考える。
同じように、AsIsかToBeかの議論もAsIsから入ってTobeへ持っていくほうがこれまた現実的だと考える。
理想的には、経営戦略や事業戦略からあるべき姿を描くほうが、BPR的だし、新しいシステムによって会社を変えるんだという意気込みのある企業にはいい方法かもしれませんが、非常に難しいアプローチのように思えます。コンサルやベンダーはどちらかというとこのやり方を推奨してきます。
筆者も以前はそのやり方がベターと考えていたが、これだと、一旦既存のシステムや仕事のやり方を忘れてゼロベースで考えてください、そしてこうすべきだという姿を描いてくださいとなるわけですが、そう言われても普通の人はとても難しく、どうしても今もこうだからとか手持ちのリソースでは無理だとか思ってしまう。結局、現状ベースから抜け出せないことになる。それならいっそ最初からボトムアップでAsIsから入ればいいのではないかと考えるのです。
モデリングの進め方の概略としては、
１．現状の業務プロセス(AsIsモデル)を抽出します。
２．その業務プロセスをプロセス・アクティビティ・タスクなどに分類・整理して可視化します。
３．可視化された現状業務からプロセスと業務機能を分析・評価します。
４．プロセス・機能を共通化・標準化・一貫化したり、重複を排除したりプロセスを適正化します
５．事業要件などから追加・修正を行いTobeモデルを作成します
このとき、ただプロセスと機能のマトリックス表を埋めるだけになってしまうと、単なる現状追認業務モデルになってしまうので、どうやって適正モデルにもっていくかが重要なポイントとなる。そこは人の頭の中で考えてよ風の方法論があったりして困ってしまうことがある。だから、そこを属人性を排した論理的なメソッドが必要となるのだ。だれがやってもだいたい同じ結果になるようなルールやガイダンスが用意されているかとなる。
いまここで、適正モデルと言ったが、ほんとうは最適モデルと言いたいのだが、２つの点で最適モデルができるのだろうかと疑問になる。ひとつは、真の最適モデルが作れるのだろうかという問題で、何もかも満足できる成果物となりえないのでないかということです。
もうひとつは、よしんば最適モデルができたとしてもその寿命はどれだけあるのだという問題で、いまの世の中ではすぐに陳腐化してリニューアルしなくてはならなくなる。従って、苦労して最適化するより、その時点で最適に近いと思われるところでどんどん進めていって、絶えずアップデートしていくようなやり方ができないかということである。ですから、最適モデルというより、「適正モデル（Normalized Modeｌ）」としたほうが何となくマッチしていると思うのですがいかがでしょうか。
業務プロセスの適正化
前回、概略のモデリングついて述べましたが、今回はそれをもう少し詳細にみていくことにします。
まず、AsIs先行ですから、最初に現状業務プロセスの抽出を行いますが、これは一般的にやられているように業務フロー図（アクティビティ図という場合もあり）に書き出すことになります。既存システムがある場合はその画面や帳票から抜き出していきます。
また、業務としてのプロセスを捕捉するわけですから、システムで行っているものだけではなく、手作業や外部に委託している作業なども書きだします。業務フロー図は２次元ですから、２軸に何を記述するかがありますが、部署・役割―工程・プロセスというのが普通です。
こうして、AsIsベースの業務プロセスを抽出したら、プロセスと業務機能のマトリックス表（Excel）を作成する。対象プロセスは、プロセス・サブプロセス・アクティビティに階層化される。例えば、受注～売上計上―受注－注文受付というイメージです。
このとき、プロセスは始点と終点が明確になって完結していることが重要なポイントです。そのアクティビティレベルで業務手順、前後のつながり、参照情報、作業手段、帳票、担当者などを記入する。これにより、現状のプロセスと機能機能（アクティビティ）が整理されます。ここでのチェックポイントは、
１．業務プロセスと業務機能が全部抽出されていること
・・・抜けているプロセスや機能がないか
２．業務プロセスが自己完結していること
・・・業務がどこで終わっているか不明だったりしないようにする
さて、ここからToBeへ展開していくわけだが、具体的には、まずつぎのような視点で見直ししていく。
１．業務プロセスとデータが途切れず流れているか（一貫化のチェック）
２．業務プロセスが複雑で分かりにくくなっていないか（シンプル化のチェック）
３．業務機能で似て非なるものがないか（共通化のチェック）
４．同じ業務処理なのに部署によって違っていないか（内なる標準化のチェック）
５．業務機能で例外処理がないか、へんなこだわりはないか（外なる標準化のチェック）
６．電子化やシステムに置き換えられることはできないか（IT化のチェック）
とにかく”シンプルな”業務プロセスにすることが最も重要である。ムダのない単純な構造は美しいものなのです。
上記視点で業務プロセスと機能を見直していく。具体的には、二重入力・起票の有無、迂回路有無、重複作業、分岐処理などいくつかのチェック項目を設け、それを上述の表に追記していく。同時に共通化あるいは標準化できる業務機能を洗い出して、その機能を汎化や集約を行ないながら定義していく。
こうして、共通化、標準化された業務機能からなるシンプルで一貫化されたプロセスができあがる。この一連の進め方を業務プロセスの適正化と呼ぶ。ここをある程度自動化できないかというのが筆者の願いなのです。ツールが適正モデルに誘導してくれるイメージです。BPMSにこうした機能が具備されることを期待している。
さて、ここでとりあえず“きれいな”プロセスとなるが、あくまでボトムアップ的アプローチであるため、ハイレベルな要件があれば、このプロセスに付加して価値を高め、差別化を図っていくトップダウン的作業がある。“魅力的なプロセス”になるかどうかはここにかかってくる。ただし、ここはもちろん自動的にはいかないのでしっかり議論し、ベンチマーキングもしながら知恵を出すことになる。
コンポーネント化
プロセスができたら、そこから機能（プロセスまで含む場合もある）をカプセル化して、コンポーネントを作成していく。まず、コンポーネントの分類と粒度ということから考えていこう。
業務プロセスは、業務サービス―業務コンポーネント―システム機能コンポーネントから成り立っていると考える。例えば、「販売管理」で「受注」～「代金回収」までのプロセスを考えると、そこには「出荷」という業務サービス（この単位でコンポーネントとしてもかまわない）があり、そのなかの「出荷指示」というアクティビティが業務コンポーネントになる。
一方、認証だとか帳票やコード変換といったシステム的な機能については、システム機能コンポーネントとして括り、共通部品的な使い方となる。もう少し、例示的言うと、
・業務サービス ：見積り、受注、発注、与信、クレーム処理、出金伝票承認・・・
・業務コンポーネント ：受注受付、在庫引当、検収、見積査定、出荷指示・・・
・システムコンポーネント：カレンダー管理、データ集配信、ロール管理、メール・・・
これらの粒度でコンポーネント化をしていきます。コンポーネント化は、MVC（model/view/control）モデルをベースにして行ないます。また、当然データベースがきちんと構築されているという前提です。ただし粒度については、これでは大雑把すぎますので、作業者がひとりで行える単位にするとか後続機能に後処理を依存させない単位にするだとかの基準は設ける必要があります。
ちなみに、大和総研の池田大造氏は、コンポーネント化の指針で、分割基準として、「最小構成単位」と「機能的な完結」，「コンポーネント構造」をあげていて、その中の「最小構成単位」でつぎのように言っています。
複数のアプリケーションを集めたコンポーネントの最小構成単位は，ビジネスで扱う人や物など「もの」として定義された対象物（エンティティ）の生 成から消滅までにしている。例えば債権についてのコンポーネントは，債権の発生から消滅に関する更新要求や参照要求への対応，ビジネスロジック（債権充 当，充当修正，滞納判定，滞納情報作成，滞納解消情報作成，回収代行債権返戻情報作成など），コンポーネント外部とのインタフェースを制御するデータ変換 部分を対象とする。コンポーネントは，情報として管理するものの最小単位ともいえる。
また、何でもかんでもコンポーネント化すればいいというものではなく、なかにはコンポーネント化に向かない機能もあるので、そういうものは無理してコンポーネントにしたところで再利用もされないわけなのであきらめます。例えば、スタッフの不定形作業なんていうのは難しいのではないでしょうか。
こうして作られたコンポーネントをライブラリーに格納して使い回していきます。
さて、このコンポーネントすなわち業務モデルは標準業務モデルであるのかという問題がある。前にも書いたが、標準化では、内なる標準化と外なる標準化という表現をした。内なる標準化というのはいわば社内標準であって、支店や営業所でまちまちであった処理慣習などを標準のものにすることである。一方外なる標準というのは、業界標準であるのかとかグローバルな目でみたとき固有性が排除されているのかといったことになる。
おそらく、業務コンポーネントのレベルでは、自社固有の部分は少なく、業務サービスのレベルで固有性が現れるのではないかと筆者は考える。従って、業界あるいは一般的に業務コンポーネントを共通利用するのは可能であるように思える。ですから、業務サービスはこの業務コンポーネントの集合ですから、その組み合わせで“クセ”が出ると考えられないか。このことは、逆に差別化する源泉でもあるわけで、他社と比べて違った業務サービスを持っていることが事業上で有利になるとも言える。「組合わせの妙」ということだ。
さて、業務サービスという言葉で言ったようにこのレベルでひとかたまりにして大きな粒度のコンポーネントにしてもかまわない。だから、狭義のERPや業務パッケージもコンポーネントと考えてもいいと思う。その場合は、カスタマイズやアドオンがほとんどないという前提での話しだが。
さらに、そうしたサービスを自分たちで作るのではなく外部から持ってくることも可能だ。例えば、与信管理のサービスを外部の信用調査会社のサービスを利用するとか、最近では福利厚生関連の多くは外部サービス化している。
次回にこうしてできたコンポーネントあるいは外部サービスを使ってシステム開発する「コンポーネント開発」について論ずる。
ビジネスコンポーネント指向開発
コンポーネント活用の開発法には、「コンポーネントベース開発」とか「コンポーネント指向開発」などと呼ばれているものがある。しかし、いずれもソフトウエアのコンポーネントという考えが強く、ビジネスの視点が弱いので、ここではあえて「ビジネスコンポーネント指向開発」とする。
さて、コンポーネントを使って開発しようというのは、まずは早く開発できること、すなわち開発効率があがること、変更要求に素早く対応できることなのだが、これだけだと、まだ前に言った「開発の２つのジレンマ」の解決にならない。特に仕様がなかなか固まらないことへの対策は弱い。それでは、なぜユーザは仕様を決めないのだろうか、決められないのだろうか。
おそらく、一番大きな｢理由はユーザが“なかなかその気にならない”ということではないだろうか。そうですよね、どんなプロジェクトでも尻に火が着かないとまじめに考えないものなんです。いくら、開発側が早く仕様を決めてくれと言っても、いま忙しいからだとか、自分じゃ分からないので現場の人に聞いてみるからちょっと待ってくれだとか言っていっこうにフィックスできないことが多い。また、逆にあれやこれや思いつくものななんでもいいから仕様に入れておけということになる。これをどうにかしたいのだ。
ということは、ユーザに早く本気モードにさせるのはどうしたらいいのだろうか。筆者は、とりあえず動くものをその場ですぐに見せることだと思う。見たものがすぐに稼動できてしまうのだということがわかると真剣に向き合ってくれるはずだ。ユーザの心理としては、紙に書いたものを見せられてもよくわからないし、周りのメンバーにも説明できない、実際の画面がどう動くのかとかをチェックしながら決めたいと思っている。それに、いくつかのケースを動かしてみて比較して決めたいのですぐにそれができるようにしてほしいのだ。Ismael GhalimiがBPM2.0で必要な機能としてOne Click Deployを揚げていたのはこういうことではないかと思う。
コンポーネントベース開発の概略手順はつぎのようになる。
１．対象業務プロセスの特定
２．プロセスと機能のマトリックス表の作成
３．コンポーネントライブラリーから適用可能ものを選ぶ
４．ライブラリーにないものは書き出す
５．BPMのモデラーを使ってフローを書くと同時に適正化を行なう
６．必要に応じてハイレベル要件を埋め込む
７．ライブラリーにないものは極力コンポーネント化
８．すぐに実装してユーザと摺り合せ、戻って修正・テストを繰り返す
９．システム本番稼動
この開発の特徴は、キーワードでいうと、モデル駆動型、イテレーション開発、テスト重視というところでしょうか。また、大事なポイントは、ユーザに見せてから稼動までを最短でやるために、実際に動くものを見せて、その場で修正してやっていくようなことでないといけない。他所からそんなことはシステムを知らないやつが勝手に言っていることだという声が聞こえてきそうだが、無理を承知で知恵をだすべきだと思う。
このプロセスで難しいのはモデリングと実装のギャップをどう埋めていくかだが、そこはいわゆるSE（最近はITアーキテクトとも言う）の登場でしょう。すなわち、ビジネスプロセスデザイナーが業務モデルをデザインし、プログラマーがコンポーネントをつくり、システムエンジニアそれを実装するという役割になる。それぞれの間でのコラボレーションや「摺り合せ」が開発プロジェクトを成功に導くのだ。
この開発形態は、ウォーターフォール型では難しく、アジャイル開発、手法としてはXPに近い形になると思うが、ユーザの人にとっては、むしろ、「セル生産方式」といった方がわかりやすいのではないだろうか。あのキャノンの生産方式で多能化された少数の人で最初から最後まで組み立ててしまうやりかたで、「ビジネスコンポーネント指向開発」も「セル生産方式」のように、数人で組み上げるイメージなのではないだろうか。
この開発方法は、（株）日立製作所 ソフトウエア事業部の桐越信一氏が提示している「コンポーネントベースモデリング」が非常によく整理されて参考になる。ただ、データモデルにあまり言及していないことと開発はフェイズドアプローチを言っているのがちょっと気になる。
また、「コンポーネントベース開発」ということで言えば、コンポーネントスクエアという会社ができていて、CBDスクエアというコミュニティを運営して、まさに「コンポーネントベース開発」について議論している。ただし、ここでは、参加がSIer中心のようで、ビジネスというより、どうしても開発側のシステム寄り視点になっている。だから、いい業務プロセスを作ろうというのではなく、再利用性が高いコンポーネントをどうやって作ったらいいのかという開発効率重視の考えが強いように思える。これは、再三言いますが、このコミュニティだけの話ではなく世の中全般に言えることのようです。
コンポーネントの粒度
ここまででは、コンポーネントとして、業務サービスという言い方をした小さな単位の業務プロセス、例えば「受注」というようなものもコンポーネントとみなすと、こうした大きな括りの業務サービスコンポーネントがあって、その下に「受注受付」のようなアクティビティあるいはタスク主体の業務コンポーネントがあり、それを動かす共通基盤的な仕組みとしてのシステム機能コンポーネントがあると言ってきた。それでは、それぞれのコンポーネントの粒度をどう考えていったらよいのでしょう。
システム機能コンポーネントについては比較的考えやすいと思うので、