仕様書をいい加減に書くと、思った通りのプログラムが出来上がらない。かといって懇切丁寧に書いていると、自分でプログラミングしたほうが早いというバカバカしい気持ちになる。そうでなくても、仕様書とソースコードの整合性を維持するのが面倒――これらの矛盾を解消するのが、筆者の言う「アプリケーションドライバ」だ。アプリケーションドライバは仕様書（仕様情報）を読み込んで、システムを動的に立ち上げる。 筆者謹製のアプリケーションドライバ「XEAD Application Driver」の公開に先立って、その概要を紹介しよう。このツールは大雑把に言うと、"Editor"と"Driver"の２種類のソフトウエアで出来ている。仕様書を編集するためのソフトが"Editor"で、編集された内容を解釈してシステムを立ち上げるためのソフトが"Driver"である。 "Editor"を用いて仕様書を編集している様子が図１
ソフト開発企業に所属するプログラマが十年一日のように「個別案件」を相手にしているというのは、マイケル･ジャクソンが盛り場あたりで毎晩「流し」で日銭を稼いでいるようなものだ。もったいない。そんなやり方ではマイケルやプログラミングの可能性がもたらすさまざまな効果を享受できない。 仮にあるソフト会社が「ロボットの振る舞いのカスタマイズサービス」を提供しているとしよう。顧客の要望がそれぞれ微妙に違うとすれば、彼らはまず個々の要望を様式化して、その内容をあるソフトウエアに読ませるだろう。そうすればそのソフトウエアが個々の要望にしたがってロボットを動かしてくれるからだ。そんなソフトウエア、すなわち「ハードウエアドライバ」をあらかじめプログラミングしておくのが、その事業で効率的に稼いでゆくための賢いやり方というものだ。 ところが、現在の「基幹業務支援システム開発事業」の分野では、あらかじめドライバをプロ
卸売業向けの販売管理システムは、ソフト技術者がシステム設計を学ぶためには最良の案件である。まず卸売業の企業数が多いということがその理由のひとつだが、もっと重要なのは、骨格が共通している点だ。個々の企業の特性に合わせて販売管理システムにはさまざまな違いが生じるが、基本的な骨格は同じである。 その骨格とは、筆者が呼ぶところの「会計３要素」、すなわち「仕入」、「売上」、「受払」だ。販売管理システムはこれらの要素を周到に取り扱って、その数字を財務管理システムに渡さなければならない。それらが集計される過程で企業の特殊性は捨象されてしまう。そういうわけなので、その骨格を正しく理解しておけばシステム設計はぐっと楽になる。武道において腰や腹の安定が基本中の基本であるようなものだ。 「３要素」のそれぞれを説明しよう。「仕入」は買掛残高、「売上」は売掛残高、「受払」は在庫残高をそれぞれ増減させる取引である。も
業務システム開発を決定してそのためのコストを引き受けるのは経営者である。それゆえに、ふつうは「経営者のためのシステム」が開発される。ところが、スポンサーの意に反した「従業員のためのシステム」が出来上がってしまうことがままある。 物販業における在庫引当の話である。これまでも何度か「在庫推移監視方式」の有効性を説明してきたが、実際にその枠組みを受け入れてもらうことは簡単ではない。それは、その方式が「経営上の便宜をはかるためのしくみ」であるいっぽう、従来の「在庫引当方式」が「従業員の便宜をはかるためのしくみ」であるからだ。後者を前者に置き換えるときに一般ユーザから反発があるのも当然だ。 「在庫引当方式」と「在庫推移監視方式」の違いをもう一度説明しよう（参考エントリー「在庫引当から在庫推移へ」）。まず、「在庫引当方式」では、受注して在庫があればそれを「引当」する。つまり、ある受注(J01)の数量が
データモデリングでは、複合キーに代わって単一項目の代理キー（サロゲートキー）を導入することがある。これは「モデリング上のテクニックのひとつ」ではあるが「モデリングのスタイル（基本方針）」とみなすべきではない。その根拠を説明しよう。 まず、倉庫が複数あるとして、倉庫にはさまざまな商品が保管されるとする。それぞれの商品は倉庫毎の特定の棚に保管される（つまり、商品と倉庫の組み合わせで棚が決まる）ことになっているとする（在庫管理では典型的な業務要件だ）。この関係をデータモデルで表すとモデル１のようになる。横浜第１倉庫でA01の棚に保管されることになっている商品１００の現在庫が２５０個であることが示されている。 このモデルをサロゲートキーにこだわって変形するとモデル２のようになる。 ２つのモデルの形式上の違いはどこにあるのだろう。モデル１では、倉庫コード、棚記号、品番が一次識別子として置かれているゆ
◆オープンソースの台頭 無償で手に入る業務システム向けの開発・実行環境やフレームワークが急速に充実してきた。Apatche,Eclipse,Seasar2,MySQL,Ruby on Rails等々、枚挙にいとまがない。それらの多くが活発なＯＳＳ(open source software)コミュニティを伴っていて、優れたソフトウエアを開発して社会に貢献したいと願う技術者達の情熱の受け皿となっている。その創造的な流れが止むことはないだろう。 そのような変化を、ソフトウエア業界を牛耳ってきた大規模ＳＩｅｒも無視できなくなっている。初めの頃には品質がアテにならないとかドキュメントが貧弱などと言って相手にしていなかったのだが、いつの間にか実務で使えるレベルまで成熟していることに気づきはじめている。クレイトン・クリステンセンが「イノベーションのジレンマ」で示したさまざまな業界での事例と似たことが、ソ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
