mark-wada blog

どうやって開発するか

さていよいよ、開発方法の話になります。開発というと忘れらない言葉があって、開発につきまとう２つのジレンマについてのことだ。その２つの大きなジレンマとは

１．アプリケーション仕様のほとんどが、結局、ユーザの恣意でしか決まらないこと

・・・仕様を決定付ける科学的、工学的なモデルが存在しない

２．情報システムと人間の境界が、元来不安定であること

・・・実業務の様々な例外をコンピュータ上に乗せるか否か

ということで、このジレンマを克服しないうちは、前に言ったようにユーザとITがお互いに嘆きあう状況はいっこうによくならない。ただ、ユーザ側からみれば、ある意味当たり前で、システム屋が困ろうが知ったこっちゃないのであって、目の前にあるビジネスをどう切り回すかだけを考える。だから、ITはそこで役に立って当然で、ITが足かせになるなんてもってのほかなのだ。

極論すると、社長が“こうしたい”と言ったらすぐに実現しなくてはならない。昔、松竹新喜劇の藤山寛美がリクエスト公演というのをやったけど、お客さんが望んだものをすぐに提供できるのがプロのシステム屋のすることでしょう。それを、“うちのお客はわがままなことばかりで全く困る”と言っているようではダメなのだ。確かに無茶なユーザがいて頭にくることは分かるが、そんなやつらを軽くさばくのがプロではないでしょうか。プロの定義は「ひとのせいにしないこと」だ。こうしたユーザの“ぶれ”とそれともうひとつ変化のスピードを前提とするなら、どうも従来型のアプローチでは対応が難しいように思える。ということは、システムの作り方を変えていかなくてはいけない。だからこそBPMが有効な手段である可能性を感じて探っているわけです。さて、BPMは”ビジネス機能、あるいはサービスをコンポーネントとして持って、それをBPMで組み合わせてプロセスを作り、それらプロセスの集合が業務アプリケーションとなる”と考えていきたい。その最初のコンポーネントを業務コンポーネントあるいは業務モデルと呼び、それをどんな方法で作るのか、あるいはどこかにすでにあるのかといったことが最初の議論となります。このあたりの試みはもちろんだいぶ前から行なわれていて、いろいろな角度からの検討があります。その結果としてERPやその他業務パッケージになったものもあり、また、データモデリングという切り口で見ているものもあります。そこで、少し最近の動きとして、「要求開発アライアンス」と「ＤＯＡ＋コンソーシアム」という2団体に注目してみていくことにします。両者のアプローチは違うが業務フローや業務モデルを描くという点では共通点があり、BPMが必要とする業務コンポーネントの生成についてどう取り組んでいったらよいか非常に参考になるし、場合によっては連携も考えられる。次回にこれらの団体の考えていることとその利用などについて述べていく。