2005年06月25日

システム要件定義と外部設計

最近のソフトウェア開発プロセスでは「外部設計」ということばを、とんと使わなくなった。たとえば、SWEBOKをみると、序章の次が「ソフトウェア要求」となっていて、以降、「ソフトウェア設計」「ソフトウェア構築」と続く。ISO/JISの「ソフトウェアライフサイクルプロセス(JIS X 0160)」でもソフトウェア要求分析の次はソフトウェア方式設計となっている。
続きを読む
posted by keis at 23:31| Comment(0) | TrackBack(0) | 要件定義 | このブログの読者になる | 更新情報をチェックする

2005年06月23日

「属人性を排除する」

 システム開発アプローチに関する文献を読んでいると、その文献が主張する開発アプローチを採用するさいのねらいとして「属人性の排除」による生産性の向上を強調しているものがある。属人性を排除するとはいったいどういうことを意味しているのだろうか。
続きを読む
posted by keis at 21:16| Comment(0) | TrackBack(0) | システム開発一般 | このブログの読者になる | 更新情報をチェックする

2005年06月17日

増減複式簿記のコンセプト

キャッシュフロー時代の複式簿記−単純仕訳と複合仕訳をてがかりに」で提案した拡張型の複式簿記について整理しておく。
続きを読む
posted by keis at 12:44| Comment(0) | TrackBack(0) | 会計 | このブログの読者になる | 更新情報をチェックする

2005年06月15日

要件定義について

 情報システムの構築にあたっては要件定義が大事だということは誰でも知っているが、じゃあ今から決めようとしている「要件」って何ですかと問われると、答につまってしまうことがある。「要件」というひとつのことばに色々な意味が込められて使われているからだ。
続きを読む
posted by keis at 20:05| Comment(0) | TrackBack(0) | 要件定義 | このブログの読者になる | 更新情報をチェックする

2005年06月11日

マスター削除チェックは誰の責任?

部門や取引先といったマスターデータの削除はやっかいだ。マスターデータは他のさまざまなデータから参照されるので、そうしたデータからの参照の有無をチェックして、削除してよいかどうか確認しなければならない。
リレーショナルデータベースの提供する参照整合性機能を用いればこうしたチェックを簡単に行うことができるが、いかんせん、この方法にも弱点がある。削除できない場合にはリレーショナルデータベースがエラーメッセージを返してくるが、このメッセージがユーザにとっては意味不明なのだ。しかも、削除しようとしているマスターデータを参照しているデータはどれかといった詳細情報を取得する手段が標準化されているわけでもない。

こうしたわけで、リレーショナルデータベースの参照整合性機能は「最後の砦」としておいて、それとは別にアプリケーションプログラムにて削除可否のチェックを行わなければならない場面がでてくる。この場合、「誰が」チェックを行うのかが問題になる。「誰が」と言っても「人」の話ではなく「システム」の話である。
例えば、一般会計システムが管理する「部門マスター」があるとしよう。このマスターを参照するデータは、経費管理システムと出張旅費精算システムにも存在することにする。だから、部門マスターからデータを削除する際には、その部門(の部門コード)が、経費管理システムと出張旅費精算システムのデータで使用されていないか、チェックする必要がある。
このチェックはどのシステムの責任だろうか。すなおに考えると、一般会計システムに含れる部門マスター削除処理のプログラムコードにおいてチェックを行うのが自然だ。だから一般会計システムの責任ということになる。

しかし、ちょっと待って欲しい。
部門マスターを参照するシステムは現在は3つだけかもしれない。しかし、4つ目のシステムが開発されたとき、それも部門マスターを参照することになる可能性は大きい。そうすると、部門マスター削除処理を修正しなければならない。すなわち、部門マスターを参照するシステムが増えるか修正される都度、一般会計システムの修正が必要になる訳だ。

なにか変ではないだろうか?

部門マスターの管理を一般会計システムに委ねたのが原因だろうか。マスター管理機能全般を「共通マスター管理システム」として切り出せばどうだろう。しかし、こうしてみても事態はあまり変わらない。影響を受けるシステムが一般会計システムから共通マスター管理システムに置き換わるだけだ。
いずれのシステム構成でも、マスターの管理を担当するシステムが、マスターを使用するシステムのデータを参照してしまうことが問題なのだ。

この事態を回避するには、マスター削除チェックに関する責任を管理側と利用側の二つに分割すればよい。
  • 管理側: マスターの削除が要求されていることを利用側(複数)に通知して、削除可否を尋ねる責任を負う。
  • 利用側: 管理側からの通知を受け、削除可否を回答する責任を負う。削除不可の場合はその理由を表すメッセージも返す。
「管理側」と「利用側」の間でやりとりを行う際のデータフォーマットや呼び出し手順はあらかじめプロトコルとして決めておく。
設計上のポイントは、「利用側」システムとして例えば経費管理システムと出張旅費精算システムがあるという知識を「管理側」システムが持たない、というようにすることである。つまり「利用側」がプロトコルに従っている限り、「管理側」としては自分が話しかけている相手が具体的にだれであるか関知しなくてもよいのである。(脚注@)
実際に存在する「利用側」システムの一覧は設定ファイルなどに列挙しておき、「管理側」システムの起動時に読み込むようにすればよい。システムの一覧の代りに、「利用側」システム内でじっさいに削除可否のチェックを担当するプログラムの名前(識別子)の一覧を記述しておくことにしてもよい。

このようにすれば、最初の例にもどって、部門マスターを使用するシステムが増えても、部門マスター削除処理は修正しなくてもよいことになる。設定ファイルにそのシステムを登録するだけだ。

上記の議論は、マスター削除処理というひとつのセッションの中(データベース処理の用語でいう『トランザクション』内)で処理が完結できることを暗黙の前提としていた。マスター利用側のデータベースの所在によってはこのような前提が置けないこともあるだろう。そうした場合は、削除可否の回答があるいは非同期で行われるということも想定して、上記の枠組みを修正することが必要だろう。


(脚注@)
オブジェクト指向設計にある程度慣れた方には、このメカニズムは「デザインパターン」でいうObserverパターンの変形である、と説明した方がわかりやすいかもしれない。
Observer パターンと共通なのは、不特定多数の(実体は不明な)相手に通知を行う点である。「管理側」が "Subject" 役で、「利用側」が "Observer"役である。異なるのは、Observer パターンでは、Subject から Observer に一方的に通知が行われるのに対して、ここで説明しているメカニズムは、通知に対する回答が Observer から Subject にもたらされる双方向の伝達のしくみであるという点だ。
posted by keis at 13:04| Comment(0) | TrackBack(0) | システム構造設計 | このブログの読者になる | 更新情報をチェックする

2005年06月04日

キャッシュフロー時代の複式簿記−単純仕訳と複合仕訳をてがかりに

簿記の本を読むと、仕訳には単純仕訳と複合仕訳があると書かれている。単純仕訳は、借方・貸方の勘定科目が一対一で対応している仕訳であり、複合仕訳は両者の対応が、多対多になっている仕訳のことだ。
たとえば、1000円の買掛金を支払う際に20円の割引を受けたとすると、それぞれの形式での仕訳は以下のようになる。なお、「割引」とは期限前に支払えば支払額をいくらか減じるという取引慣行だ。

〔単純仕訳〕
仕訳@ (借方) 買掛金 980 (貸方) 当座預金 980
仕訳A (借方) 買掛金 20 (貸方) 仕入割引 20

〔複合仕訳〕
仕訳B (借方) 買掛金 1,000 (貸方) 当座預金 980
仕入割引 20

実際の取引は一件であるが、単純仕訳では取引が二件あったかのように仕訳を二件作成する(会計用語ではこれを、「取引を擬制する」と表現する)。

単純仕訳も複合仕訳も、当然ながら勘定残高に与える効果は変わりない。上記の例をみればおわかりのように複合仕訳の方が取引を自然に表現できる。また、一対一対応は多対多対応の特殊ケースだ。だから、会計システムを設計する際には複合仕訳に対応できるようにしておけば十分で、単純仕訳についてはとりたてて考慮しなくともよいように思える。

しかし経理の実務では複合仕訳をきらう企業が相当ある。というのは、複合仕訳を許すと、勘定残高の増減分析が行いにくくなるからだ。仕訳は仕訳帳に記入され、勘定元帳に転記される。このながれは手作業でもEDP処理でも同じである。勘定元帳には「相手勘定欄」というものがあり、単純仕訳であればそこに各仕訳での相手勘定科目がしるされる。上述した例をもとにすれば、こんなぐあいだ。

勘定科目:買掛金 残高は貸方+
〔摘要〕 〔借方発生〕 〔貸方発生〕 〔残高〕 〔相手勘定〕
(月初残高) 2,000
X社に支払 980 1,020 当座預金
X社から仕入割引 20 1,000 仕入割引

一方、複合仕訳であれば、行単位で借方・貸方勘定科目が対になるという前提が置けないため、相手勘定は原則として不明となる。勘定元帳では以下のように「諸口」と表示する。

勘定科目:買掛金 残高は貸方+
〔摘要〕 〔借方発生〕 〔貸方発生〕 〔残高〕 〔相手勘定〕
(月初残高) 2,000
X社に支払 1,000 1,000 諸口

単純仕訳を用いている場合は、勘定残高がどのような取引で増減したのか、勘定元帳をみることでほぼ把握できる。対して、複合仕訳を採用するとそれは不可能になることがご理解いただけるだろう。こうしたわけで、実務上、複合仕訳を避けることが多いのである。

勘定増減高の分析は、公表決算や経営管理の上で重要な情報を提供するために行われる。たとえば「設備投資額」は重要な経営情報だが、これは固定資産勘定の増減高の内訳数値だ。ところがこのような重要な情報を入手するために、現在の複式簿記のしくみでは、「勘定元帳の相手勘定欄の表示内容」といった、かなり貧弱な手がかりに頼らざるを得ないわけだ。

これはおそらく簿記の発達の歴史と関係している。複式簿記はルネサンス期のイタリアで成立したと考えられているが、その当初のねらいは債権管理だった。その後、もとでに対してどれだけ儲かったかを把握するために、損益計算のしくみが成立した。損益計算とは、「もとで(=自己資本)」についての増減内訳情報の作成処理であると言ってもさほどはずしてはいないと思う。別の言い方をすると、複式簿記の元々の使命はストックの記録であり、フローの記録については損益計算という限定的なかたちで、いわば「おまけ」的に追加されたと言ってもよかろう。

しかし、現在では、損益計算に加えて「キャッシュフロー計算」も重視されるようになっている。キャッシュフロー計算は、形式的にみれば現金および現金同等物についての増減内訳情報を作成することだが、実質的にはその他さまざまな勘定科目に関する増減情報が、キャッシュフローステートメントには織り込まれている。たとえば先ほどでてきた「設備投資額」もキャッシュフローステートメントに顔を出す。現預金出納帳がそのままキャッシュフローステートメントになるわけではないのだ。

こうした観点にたつと、複式簿記のしくみについて、「もとで」の増減を記録するだけではなく、貸借対照表の任意の勘定科目について増減を記録できるような拡張をほどこすことが求められていると思う。

具体的には、勘定科目に加えて「増減科目」を設けることで、目的を達することができると思う。仕訳の借方・貸方それぞれに勘定科目と増減科目を指定するのである。 この方式で先の取引の仕訳(複合仕訳の方)を作成すると次のようになる。

〔複合仕訳〕
仕訳B' (借方) 買掛金 [決済] 1,000 (貸方) 当座預金 [営業債務支払] 980
仕入割引 [-] 20

勘定科目の直後に、[]でくくって示したのが「増減科目」だ。P/L勘定科目である「仕入割引」については増減科目を指定する必要はない。P/L勘定科目自体が本質的には「利益剰余金」の増減科目であるからだ(*1)。「仕入割引[-]」は、「利益剰余金[仕入割引]」の略記法であると考えてもよい。

さて、増減科目が設けられたことで勘定元帳の表示も変わる。
勘定科目:買掛金 残高は貸方+
〔摘要〕 〔借方発生〕 〔貸方発生〕 〔残高〕 〔増減科目〕
(月初残高) 2,000
X社に支払 1,000 1,000 決済

「相手勘定」欄が「増減科目」欄に置き換わり、その表示内容も「諸口」ではなく「決済」となった。これによって、「複合仕訳を用いた場合に勘定増減高の分析が困難になる」という問題が解決されることをご理解いただけると思う。

仕訳の項目が増えることになるが、入力の手間はたいして増えないだろう。まず、経理部門以外のユーザが入力しなければならない勘定科目はほとんどP/L科目であるが、上述したようにP/L科目に対しては増減科目を指定する必要がない。また、現在では多くの取引が自動仕訳の対象となっているので、そうした取引については増減科目も自動設定することができる。

増減科目を設けることによって、キャッシュフローステートメントをはじめとするフロー系の経営情報を勘定元帳から容易に入手できることになるし、複合仕訳を採用する上での障害も無くなる。本来は複合仕訳としたいような取引を無理に単純仕訳で表現している場合には、取引内容が理解しにくくなりかつ仕訳データの件数も増えるという弊害が発生しているはずだ。情報システムへのインパクトが大きいのですぐに対応するのは無理だろうが、長い目でみると一考の価値はあるのではないだろうか。


(*1) 複式簿記に損益計算のしくみが組み込まれたときに、「勘定科目」と別に「増減科目」を設けることをしなかったために、B/S科目とP/L科目というまったく性質の違う概念が「勘定科目」の中に同居することになったのだ。

2005年6月15日 加筆修正
posted by keis at 18:46| Comment(2) | TrackBack(0) | 会計 | このブログの読者になる | 更新情報をチェックする

2005年06月03日

アプリケーション設計のポイント−業務制約の発見

業務上のルールが変わったときには、アプリケーションシステムの処理内容を調整する必要が生じる。そのさいプログラムを手直しすることなくユーザ自身の手によりシステムを調整できた方が望ましいという場合は多い。パッケージソフトのように多数の企業に導入することが想定されているシステムにおいてだけではなく、単一の組織で使用されるシステムでも業務ルールが変わることはごく普通に想定される。開発期間や費用とのトレードオフに注意するのは当然であるが、アプリケーションシステムにフレキシビリティを盛り込むことは重要である。以上のことはシステム設計者の間で広く理解されていると思う。

一方で、十分に認識されていないかもしれないのは、フレキシビリティに制約を設けることの重要性である。たとえ開発にかかる期間や費用の問題をさておいても、アプリケーションシステムはフレキシブルであればあるほど良いというものではない。フレキシブルすぎるとシステムの設定変更手続きが複雑化してユーザの手に負えなくなる。フレキシビリティがかえって業務上の隘路をつくってしまう。事実上ほとんど変更されないような点についてはフレキシビリティを排除するとともに、本当にフレキシビリティが必要とされる機能についても、そのなかみに制約を設けることがだいじなのだ。

じっさい、業務条件が変わるといっても、その変更は一定の枠というか制約条件の中での変更であることが多い。たとえば、そこそこの規模の会社の決算業務では、ほぼ例外なく「配賦計算」というものがでてくる。簡単化して言うと、配賦計算とは単一の「配賦元」の数値を複数の「配賦先」に割り振ることである。たとえば、総務部で支払った本社ビルの賃借料を、そのビルに入居している各部門に対して使用床面積比で配分して負担させる、といったぐあいである。「配賦元」の金額をどう把握するか、配賦先を何にするか、配分比の元データとして何の数値を使用するか、配賦元と配賦先がループしたらどうするか、等々、配賦計算に関する可変要素は多い。会計パッケージを売ったことのある方なら、配賦機能の詳細についてお客さまから重箱の隅をつつくような質問攻めにあったことがあるかもしれない。有能なシステム設計者であればあるほど、いっそのこと、四則演算やら関数やらを使った計算式をユーザが自由に設定できるしくみを作ればどうか、といった思いに駆られる。そうすれば、すべてユーザまかせにできるではないか。

しかし配賦計算には配賦計算なりの制約条件がある。もっとも目立つ制約は、すべての配賦先に配賦された数値を合計すると配賦元のもともとの数値と一致しなければならない、という条件である。この制約条件を満たすためには、計算上で端数が発生した場合にはどこかの配賦先で調整することが必要だ。上述した「計算式をユーザが設定する」方法を採ると、端数調整のための計算式もユーザが書くことになるだろう。つまり、この場合、業務上の制約条件を満たす責任が、システムではなくユーザに委ねられていることになる。

考え方にもよるだろうが、私は、これはあまりほめられた責任分担ではないと思う。業務上変わることのない制約条件が存在するなら、それを満たす責任はシステムに負わせるべきではないだろうか。そうした見方に立つと、配賦計算において「計算式をユーザが設定する」という仕様は、フレキシビリティ過剰というべきだろう。業務において不変の制約はシステムが保証し、可変な要素はユーザに委ねる。こうした不変要素と可変要素の切り分けが、アプリケーションにフレキシビリティを持ち込む際に肝要だと思うのである。

業務における不変要素を見つける作業はアプリケーション設計の醍醐味でもある。不変要素はいつでも明らかなかたちで認識されているわけではない。何を不変要素とみるのかは、ユーザやアプリケーション設計者による業務理解そのものでもある。隠された不変要素を見つけ、すっきりとした仕様が得られたときの喜びは格別だ。

以上、アプリケーション設計者の立場から問題を眺めてきたが、ユーザの立場からみると、これは「何でもできます」という宣伝文句に動かされるのは危険だということだ。何でもできるというのは本当か?といった面もあるが、本当に何でもできたらかえって困る、ということもあるのだ。

posted by keis at 23:03| Comment(0) | TrackBack(0) | システム外部設計 | このブログの読者になる | 更新情報をチェックする

タイトルについて

Hot Heart, Cool Mind.
だれが言ったか忘れましたが、好きな言葉です。
何かを達成するためには、ハートは熱く判断は冷静に。
この反対の状態に陥いりかける瞬間のなんと多いことでしょうか!
posted by keis at 18:54| Comment(0) | TrackBack(0) | 雑感 | このブログの読者になる | 更新情報をチェックする
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。