システムをデザインする
それでは、奥出直人の言う「デザイン思考による創造のプロセス」にもとづき、情報システムの開発について考えてみることにする。
「デザイン思考による創造のプロセス」とは、“社会的背景や哲学的背景を踏まえた上での考え方、作り手の問題意識を表わす哲学を考えるところから始めて、具体的に何を作りたいかビジョンを決め、それを持ってフィールドワークに行き、どのようなものを作るかコンセプト／モデルを作り、機能やインタラクションを検討しながら実際の設計デザインを行い、実証する。つぎにビジネスモデルを構築して、実際の運営方法を決定する”プロセスのことと言っている。
そのそれぞれのステップについて追いかけるが、より重要なプロセスとして上流のプロセスの最後であるデザインするところまでを取り上げる。
まず、ステップ１「哲学とビジョンを構築する」ことだが、企業の情報システムであれば、会社の経営理念や方針あるいはもう少し狭くて部門の運営方針といったものが哲学やビジョンに相当する。さらに、最近よく言われるＥＡ（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の懐の深さを感じる。
「それでもぼくはやってない」では、「疑わしきは被告人の利益に」なるはずが、無実を証明できないため有罪になってしまったが、その理屈を他のところにあてはめるとどうなるのだろうか。
最近話題の「タミフル」は、服用後の異常行動との因果関係は証明されていないが、疑わしいと思える。タミフルの無実だって証明するのは難しいから、なぜ有罪とならないのだろうか。タミフルに冤罪はあるのか。冤罪がわかったとしてもタミフルの失われた人生を返せとなるのか、ならないのか。あるとすれば、タミフルを使用禁止したおかげでインフルエンザで死ぬひとが増えた場合だ。だから、厚労省も薬害と思われるのはいやだからではなく、薬には副作用があるがそれ以上に効能のほうが勝っているから使わざるを得ないとはっきり言えばいい。そうじゃないとなぜ使用禁止にならないのかという声が大きくなる。
そんなことを考えていたら、九州の光化学スモッグが最近増加してどんよりとした空が多くなってきたという報道があった。その原因はどうも中国らしい。中国大陸の工場や車から排出される汚染ガスが飛んでくるようだ。これも疑わしいという話だが、この場合は中国に光化学スモッグの原因がそちらにないことを証明しろもしできなかったら罰するぞなんて言えないですよね。そうなると、疑わしきは罰せずということになり、結局は疑わしいことが闊歩することになる。
と書いてみて、そうなんだぼくを含めて普通の人々は、こころの奥で疑わしくは罰すべきだと思っていることに気がついた。それが、「それでもぼくはやってない」のように冤罪を生む土壌になっていると言ったら大げさだろうか。
ここ数日、何となく元気がでない。このブログもビジネス関連を続けているが、他のネタであまり書いていない。でもだんだん快復してきたので何を書こうかなあと思案していたら、そもそもブログというのは何なのかと考えてしまった。日記なのか、備忘録なのか、エッセイなのか、時事批評なのかと、でもこれは別に枠にはめなくてもいいわけで、自分の好きなように書けばいいだけという当たり前の結論。
ただ、自分はこういうブログを書くのだというちょっとしたポリシーは要るかもねということと、日記や備忘録ではなく、自分の考えとか思いを書きたいとなると、自ずとその書き方というものがあるような気がする。やはり、たかがブログだけれど、根底に誰かに読んでほしいというのがあるのだから、読みやすい、わかりやすい書き方というものもあるはずだ。
そんなことに関して、梅田望夫さんがなるほどと思わせるいいことを自身のブログに書いていた。梅田さんは、文章を書くときの重要な３つの要素を「構造化」、「想定読者」、「書き手の個性」だと言っている。
「構造化」というのは、対象を幅広い視点から俯瞰して理解することで、「想定読者」は文字通り誰に読まれたいのか、訴えたいのかで書き方も変わるということ、そして、「書き手の個性」ということで、前２つはいわば普遍的なものであるので、それだけだと同じものになるかもしれないので、書き手による差別化が要る。読者は実は文章の向こうの「書いてる人」を読みたいものだという。梅田さんはそういうことをいつも考えながら文章を書いているそうだ。まさにこの３要素は重要で、ぼくもすごく難しくて実行できているかお寒い話ではあるが努力しようと思う。
このような、文章表現のお手本は「天声人語」（他の新聞社も含めて１面下のコラムのこと。いまは、読売新聞の「編集手帳」のほうがおもしろいが）なのかもしれない。あの限られた字数のなかで、起承転結をきちんとさせて、読書をうならせる術はたいしたものだ。ただ、ぼくらとぜんぜん違うのは、参照するデータベースがものすごいから、関連する情報がぽんぽん飛び出すので、文章に重みがある。
それで今日の朝日新聞を読んでいたら、「～天声人語から書く～ 現役高校生の天声新語コンクール」の記事があった。これは、「天声人語」の第一段落に続く文章を競い合うもので、その結果が出ていた。この第一段落というのは、「ニュースの関心度を測る物差しはいろいろあるが、現場が遠いか近いかもその一つ。地球の裏側の都市で五十軒焼けた火事よりも、隣町のぼや騒ぎの方が、とかく耳目を集める」でこのあとに文章を続ける設定である。
最優秀賞に輝いたのは1年生の女子高生で、高校に電車で通うようになって、駅までの間で見かけるものが新鮮で面白く感じ、それが毎日変わることを自分だけが気づくことかもしれないが、新聞で読む世界の出来事と同じくらい大事なことだというようなことを書いていた。すごくセンスのいい文章で感心させられる。きっと彼女のブログ（あるかどうか知りませんが）も素晴らしいのではないでしょうか。
しかし、受賞した9人のうち8人が女子高生という完全な女性上位という結果。最近の文学賞の受賞者も女性が多いし、文章を書く能力は女性が優れているのかなあと嘆いているのであります。男性諸君がんばりましょう。
どうやって開発するか
さていよいよ、開発方法の話になります。開発というと忘れらない言葉があって、開発につきまとう２つのジレンマについてのことだ。その２つの大きなジレンマとは
１．アプリケーション仕様のほとんどが、結局、ユーザの恣意でしか決まらないこと
・・・仕様を決定付ける科学的、工学的なモデルが存在しない
２．情報システムと人間の境界が、元来不安定であること
・・・実業務の様々な例外をコンピュータ上に乗せるか否か
ということで、このジレンマを克服しないうちは、前に言ったようにユーザとITがお互いに嘆きあう状況はいっこうによくならない。ただ、ユーザ側からみれば、ある意味当たり前で、システム屋が困ろうが知ったこっちゃないのであって、目の前にあるビジネスをどう切り回すかだけを考える。だから、ITはそこで役に立って当然で、ITが足かせになるなんてもってのほかなのだ。
極論すると、社長が“こうしたい”と言ったらすぐに実現しなくてはならない。昔、松竹新喜劇の藤山寛美がリクエスト公演というのをやったけど、お客さんが望んだものをすぐに提供できるのがプロのシステム屋のすることでしょう。それを、“うちのお客はわがままなことばかりで全く困る”と言っているようではダメなのだ。確かに無茶なユーザがいて頭にくることは分かるが、そんなやつらを軽くさばくのがプロではないでしょうか。プロの定義は「ひとのせいにしないこと」だ。こうしたユーザの“ぶれ”とそれともうひとつ変化のスピードを前提とするなら、どうも従来型のアプローチでは対応が難しいように思える。ということは、システムの作り方を変えていかなくてはいけない。だからこそBPMが有効な手段である可能性を感じて探っているわけです。さて、BPMは”ビジネス機能、あるいはサービスをコンポーネントとして持って、それをBPMで組み合わせてプロセスを作り、それらプロセスの集合が業務アプリケーションとなる”と考えていきたい。その最初のコンポーネントを業務コンポーネントあるいは業務モデルと呼び、それをどんな方法で作るのか、あるいはどこかにすでにあるのかといったことが最初の議論となります。このあたりの試みはもちろんだいぶ前から行なわれていて、いろいろな角度からの検討があります。その結果としてERPやその他業務パッケージになったものもあり、また、データモデリングという切り口で見ているものもあります。そこで、少し最近の動きとして、「要求開発アライアンス」と「ＤＯＡ＋コンソーシアム」という2団体に注目してみていくことにします。両者のアプローチは違うが業務フローや業務モデルを描くという点では共通点があり、BPMが必要とする業務コンポーネントの生成についてどう取り組んでいったらよいか非常に参考になるし、場合によっては連携も考えられる。次回にこれらの団体の考えていることとその利用などについて述べていく。
少し前に財布を落としてからじっと家にいておとなしくしている。財布を落としたことを嫁はん（この表現はOKなのかな？家内って言ってはいけないそうだから）からなじられるし、実質的にも、現金、キャッシュカード、クレジットカード、免許症、Suica、各種プリペイドカード、病院の診察券、会員カード、各種ポイントカード、呑み屋のおねえちゃんの名刺、みんななくなってしまった。とほほ。
大船の居酒屋で呑んでいてその店で財布からお金を出して、お釣りを直接ポケットに入れたところまで覚えていて、歩いて駅まで行ってすぐにタクシーに乗って、タクシー代はそのポケットにいれたお釣りで払った。そしてタクシーを降りて家に入ろうとしたら財布のないことに気づき、幸いタクシーがUターンして来たので止めて中を確かめたけどないのだ。ですぐ呑んでいた店へ電話したが見当たりませんという返事。万事休す。
その日のうちにキャッシュカードとクレジットカードを止めて、翌日すぐに交番に紛失届けを出し、二俣川に行って免許証の再交付をしてもらう。おお、金と時間のロス。しばらく買いたいものも買えない、呑むのも控えてという情けない状況になった。
ここでちょっと腹立ったのは、病院の診察券の再発行にお金がかかることで、ある病院で「再発行にはお金がかかりますがどうしますか？」、え、どうしますと言われても、よほど「再発行しなかったらどうなるんですか、診察してくれなんですか？」と聞き返そうと思ったがやめた。
ぼくは、いままで財布を持っていなかった。厳密に言うと、お金は財布に入れて持たないことにしていた。それと、カードや免許証は持ち歩かないことにしていた。なぜって、落とすかもしれないからで、よくズボンのお尻のポケットに半分出かかっている財布をみかけるが、そんなのを見ていると危ないからなのだ。それが、家で仕事をするようになると結構カードを使う機会が増えるし、自分を証明するのに免許証がいることもあって財布を買って使っていた。
というわけで、あれからは、財布は持たず現金をそのままポケットに入れ、カード、免許証は持ち歩かないことにした。まあ、みなさんも気をつけてください。
サンマーメンというのがある。知らないひとはサンマが入ったラーメンと思っている。これは、ラーメンの上にもやしやその他の野菜を片栗粉のあんで絡めたものである。冬の寒い時なんかでも中味がなかなか冷めないので汗をかくくらいだ。ぼくの大好きな料理で、おいしいですぞ。
以前、ぼくはこの料理は全国どこにでもあると思っていたら、何と神奈川県にしか(静岡県の一部にもあるらしい)ないのだそうで、びっくりしたが、そういえば東京にもないし、ましておや三重県では見たこともなかったと思いあたった。
このサンマーメンで有名な店が鎌倉の材木座にある。「中華 薊」という店で九品寺のすぐ近くにあり、テーブルで20席くらいの小さな店だがいつも混んでいる。ときどき行くんだけどだいたいがサンマーメンを注文する。やはりお客さんのほとんどがサンマーメンを頼むらしい。
ところが、ぼくが行っているときサンマーメンを頼む人が割と少ない。なぜだろうと考えたら、よくサンマーメンを頼むひとはガイドブックを持った遠くから来た人が多いようだ。近所の人たちは毎回サンマーメンを食べるわけではないので、そういうひとたちが多い時はそんなことはないということのようだ。地元密着の有名店はこういうことがよくある。
で、今日は、プールに行ったらあいにく競技大会があって一般の人が入れないとのこと、しかたなく、そこから北鎌倉に抜けて少し鎌倉を走ってみることにした。鎌倉駅を通り過ぎたところで、そうだ「薊」に行こうとひらめいて、そのまま直行。幸いにも駐車スペースが一台分空いたので待たずに入店。
さて、サンマーメンにしようかと思ったら、いやかつ丼だとなった。中華料理屋でかつ丼って邪道と言われるかもしれないが、ここのかつ丼はうまいのだ。中華料理屋特有のラードで香ばしく揚げたかつをのせ、ちょっぴり甘めでイケてるのだ。というわけで、本日はB級グルメの中華料理屋のかつ丼の巻でした。
「要求開発アライアンス」と「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）や仕事の流れを表現するマジカあたりで、気になるところです。
昨日は、芝公園で日本BPM協会の交流会があったのでそこに出掛ける。事例報告やWGの進捗などの説明があって、夜は懇親会となった。立食だったので歩き回ってひとしきりいろいろなひととおしゃべりをする。そのあと、その会の幹事のひとりであるUさんと約束していた2次会へ行く。どこにしようかと言うので大門の近くの小料理屋にする。
ここは、「新日本料理 美正」というのだが、何が“新”なのかよくわからない。少なくともメニューはここ5年くらい変わっていない。板さんと女将のふたりでやっていて、さかながうまい店で、お客さんはまあ年配のひとが多く、落ち着いたところです。以前の会社が芝公園にあったのでそのときはちょくちょく接待なんかに使っていたが、ホント久しぶりに行きました。いつものように、お刺身とぼくの好きなさよりをあぶってわさびマヨネーズで食べるやつを出してくれました。
で、これからはその女将の話で、このひといつも着物を着てその上に割烹着をしているのだ。いまの若い人は割烹着なんて知らないかもしれないが、ぼくらのおかあさんは皆割烹着を着ていたのだ。だからって、萌えているわけではありませんので念のために。
あるとき、お客さんがいなくなったので一緒に呑んでいたら、なぜか話がぼくがそのとき住んでいた白山のことになった。下の息子と1年半くらい暮らしたことがあって、いつも近くの焼き鳥屋に行っていて、そこの夫婦とも懇意になった。話が進んで、その焼き鳥屋の話になった。そうしたら私もよく知っていると言い出した。何ということはないぼくのちかくのマンションに住んでいることが判明。しかも、その焼き鳥の娘と自分の娘が中学の同級生でよく知っているという話。大いに盛り上がったのであった。
前にも、たまたまバーで隣合わせたひとがぼくの家のすぐ近くのひとだったという話を書いたが、世の中狭いなあという続編です。
そのとき女将に「ねえ近くなんだから休みの日に一緒に呑みましょうよ」と誘われてしまった。もちろん「ハイ」と答えたが残念ながら実現しなかった。だって、いまどき割烹着を着る人の歳ってわかりますよね。
業務プロセスモデリングの進め方
ここでは、業務プロセスのモデル化を行い、できあがったプロセスからある単位（粒度）で切り出してコンポーネント化する作業のとっかかりのところを議論することにする。
まず、要件を定義していくとき、トップダウンアプローチなのかボトムアップアプローチなのか、AsIs先行かToBe先行かという問題があります。ここでいうトップダウンアプローチとうのは、経営管理あるいは事業運営上必要となる要件、いわゆるビジネスモデル的なハイレベル要件から見るもので、ボトムアップアプローチというのは、逆に業務フローをまわすための要件、いわゆるオペレーショナルなローレベル要件からみるものであるが、当然両者とも必要なアプローチであるが、筆者は最初はローレベル要件から入って、そこを固めてからトップダウン的にこだわり要件を付加していくやり方が現実的であると考える。
同じように、AsIsかToBeかの議論もAsIsから入ってTobeへ持っていくほうがこれまた現実的だと考える。
理想的には、経営戦略や事業戦略からあるべき姿を描くほうが、BPR的だし、新しいシステムによって会社を変えるんだという意気込みのある企業にはいい
