筆者は,これまでほぼ30年,ソフトハウスのSEとして,基幹業務や会計システムなどの開発を経験してきた。納入先は銀行,信販,生保/損保,製造業,と多岐にわたるが,既存の業務の効率化が本質的な目的であった点は変わらない。現行業務に詳しいお客様の担当者から要望を聞き出し,先輩たちの経験をなぞりながら,メインフレームのアーキテクチャにその時々の実装技術をマッピングすることの繰り返しであったとも言える。

 しかし,昨今のインターネットをはじめとする情報通信技術の進歩は,この状況を大幅に変えてしまった。一つは,システムにアクセスするエンドユーザーの数が飛躍的に増加したこと。さらに重要なのは,システムに期待されていることが単なる人手による作業の置き換えではなく,全く新たな価値の創造となってきたことである。つまり,ITシステムのパワーを利用することで「新しい仕事のやり方」を考えなければならなくなったのである。

 もっとも,「新しい仕事のやり方」とは言っても,多くの場合,それぞれの企業における過去の様々な業務を踏まえてのものであることが多い。こうした業務を理解したうえで,ビジネスやITの世界で培われてきた技術を礎に,本当に有用な「新しい仕事のやり方」を新しいビジネスへの「要求」としてとらえなければならない。

 筆者のような経験を持つ者が,こうしたビジネス上の要求をシステム開発の要求へと,うまく引き渡す役目を果たすならば,顧客である企業にも喜ばれるだろうし,新しい技術に強い若手SEの方々への申し送りにもなるのではないか。以下では筆者が,このような考えにいたった経緯として,いくつかのエピソードを紹介しよう。

ビジネス上の概念は顧客にきちんと確認しておく

 業務システムを開発する際に,対象業務についての深い理解が必要であることは言うまでもない。筆者は,開発経験がない業務について上流工程から参加するときは,業界解説本を一通り読んで出かけるようにしている。ただ,こうした解説本だけに頼っていると,思わぬ勘違いをすることもある。

 ある信販業務を担当したときのこと。そのときに読んだ解説本では,信販会社と加盟店の関係について「信販会社は会員顧客から手数料を徴求するだけでなく,販売契機を増やしたということで加盟店からも手数料を受け取る」と記されていた。また,だからこそ「会員顧客は,お店独自の月賦価格よりも安く商品を購入できる」とも書いてあった。

 ところが,顧客によく話を聞いてみると,実態は必ずしもそれだけではなかった。カードの流通促進のために信販会社が加盟店に対して支払う「加盟店支払」が生じるカードもあったのだ。この場合,「支払」といっても「手数料」の「支払」とは全く別の概念を指す。このように実際の業務においては,同じような呼び方をする概念であっても,全く別の意味になる場合がある。

 業界における現実の商習慣は,なかなか新参者のソフトウエア設計者にはつかめないことが多い。最近のように金融商品が多様化してくれば,なおさらである。こういう場面で,ビジネス上の概念をきちんと記録し,顧客と開発者で合意しておくことはとても大切なことである。Openthologyの言う,ビジネス・モデリングにおける「概念モデル」の重要性もここにある(次回に続く)。

(佐々木 啓一=要求開発アライアンス)