仕事の報酬の決まり方には大きく分けて２種類ある。就労時間に応じて決まるパターンと、成果に応じて決まるパターンだ。前者の例はアルバイトや一般事務といった仕事で、後者の例はアーティストや専門家の仕事である。後者であっても拘束時間ベースで契約されることが少なくないにせよ、仕事上の評価は、就労時間ではなく成果で決まる(*1)。言い換えるとその種の仕事は、従事者が少ないゆえに給与レベルは比較的高いが、次に仕事を依頼されるのは「より多く働いた者」でも「よりマジメに働いた者」でもなく、「より成果を上げた者」である。 言うまでもなく、システム開発の仕事は「専門職」に分類される。使いやすく保守しやすいシステムという「成果」が生み出されさえすれば、それが100人月で出来上がったか10人月で出来上がったかは問題ではない（じっさいこの程度の違いはふつうに生じ得る）。「残念なシステムになってしまいましたが、みんなで

一次識別子に含まれる項目であれば、登録後に値を変更することは許されない。それを許せば、一次識別子を基礎とするレコード間の対応関係が失われてしまうからだ。では、一次識別子に含まれない属性項目であれば、登録後に値を変更することは一般に許されるのか。否。値が変化するだけでアノマリー（更新時異状。不整合）を生じさせてしまう属性項目が存在する。それらについて仕様策定の管理レベルを上げて、アノマリーを回避しよう。 以前に書いた記事（「フィールドの更新不可制約」の必要性）で、サロゲートキーを導入する際には、もともと認識されていた複合主キーに「ユニーク制約」とともに「更新制約」をかけておく必要があると説明した（かくのごとく、サロゲートキーというものは扱いがややこしい）。この他にも、独特な更新制約を受ける属性項目が存在する。 例を挙げよう。商品の管理項目として「在庫管理対象フラグ」というものがあるとする。在

プロジェクトメンバーが無駄に多いのが、日本型SIの特徴のひとつである。「工数を人数で割れば工期が出る」と考えることが間違いであることは、ブルックスの著書「人月の神話」によって今から40年前に指摘されている。それにもかかわらず、相変わらず多くのプロジェクトで必要以上の人数が投入されている。 私がとくに不思議に思うのが、基本設計を何人もの要員で分担するやり方だ。DB設計と機能設計と業務設計の担当を分けるとか、サブシステム毎に担当を分けるといった体制がしばしば敷かれる。詳細設計の段階でというのならまだわかるが、基本設計でそれをやってはいけない。 なぜか。業務システムにはアーキテクチャ（意図された構造）が求められる。そして、そこに含まれる膨大な定義要素は、統一感や一貫性を保ち、かつMECEな形で切り出されなければいけない。複数の要員で分担などすれば、それらの課題が一挙に難しくなる。また、DB構成と

意識されることが少ないが、「更新不可制約」はRDBを扱う場合に配慮すべき基本事項である。ところが、そのための機構が一般のRDBMSでは手薄であるゆえに、更新不可に関する制御は開発者、または開発基盤に委ねられる。その際の考慮点を説明しよう。 まず、更新不可制約がどのようなものかをおさらいしておこう。一義的には、「PK（一次識別子）の値は更新されてはいけない」くらいの意味である。更新できてしまえば、データの不整合が生じるからだ。たとえば、顧客のPKである顧客IDを"256"から"123"に更新できてしまえば、"256"を顧客IDとしているさまざまなテーブルレコードとの間で簡単に不整合が生じてしまう。まあ、当たり前の話である。 ここで取り上げたいのは、「サロゲートキー」を導入した場合に要請される「属性フィールド（PKでないフィールド）の更新不可制約」である。たとえば、Ruby on Railsの

開発課題を「上位ドメインと下位ドメインの階層」とみなすことで、開発効率は劇的に改善される。上位ドメインに対する配慮を専用の開発基盤に委譲することで、下位ドメインの定義が様式化・最小化されるからだ。 何度か例として挙げた「コンピュータに"イパネマの娘"を演奏させる」の課題で説明しよう。この課題を引き受けたミュージシャンは、「初音ミク」のような専用ツールを使って、"イパネマの娘"の演奏定義ファイルをアジャイルに「編集」する。JavaやRuby等のプログラミング言語を使って大掛りな「"イパネマの娘"演奏システム」をアジャイル開発するわけではない。 ミュージシャンがやっていることは、「上位ドメインの特性」と「下位ドメインの特性」の分離である。すなわち、「コンピュータに"イパネマの娘"を演奏させる」の課題を、「コンピュータに楽曲ｘを演奏させる」という上位ドメインと、「ｘ＝"イパネマの娘"」という下位

業務システムに含まれるアプリケーションの「類型化」が重要だという話を何度かしたが、その中心課題と言うべき「処理テーブルの形式化」について説明したい。アプリを類型化することは、切り出された類型における処理テーブル（処理されるデータ）の論理的な位置づけを明らかにすることでもある。 前回と同様、製造指示のデータモデルを使って説明しよう（図１）。製造指示には品目マスターや得意先マスターへの参照関係がある。また、製造指示は３つの「子テーブル」を伴っていて、それぞれの子テーブルにも他のテーブルへの参照関係がある。 図１　製造指示のデータモデル この製造指示テーブルを扱うアプリについて検討しよう。パネル表示するためのアプリについては何度も取り上げたので、今回は印刷用アプリとして「製造指示書の印刷」を取り上げたい。このアプリは、拙作の開発基盤において「見出し明細印刷」と呼ばれる機能タイプ（アプリのパターン

モデリングツールXEAD Modelerで作成したモデルを手早く実装する――開発基盤XEAD Driver/Editorはそれを意図して開発された。したがって、これらのツールを組み合わせることでより大きな効果が得られる。通常のシステム開発におけるツール利用の流れは図１のようになる。 図１．通常のシステム開発 Modeler(1)でER図、業務フロー、業務マニュアルといった基本設計情報（モデル）をまとめ、それをEditor(2)を用いてDriver(3)向けのシステム定義（仕様書）に変換する。ちなみにモデルも仕様書も、その中身は様式が公開されているXMLデータである。 つまり、Modelerは「モデルを編集する」ためのツールで、Editorは「仕様書を編集する」ためのツールで、Driverは「仕様書にもとづいてDBを操作する」ためのツールである。Driverが仕様書を読み込んでその場で自らを

前回記事で説明したように、主キーは「ユニーク制約をともなうインデックス」ではなく、「本来的なユニークキー(一次識別子, Primary Key, PK)」である。すなわち、「NULL値をとらないし、レコードのライフサイクルにおいて値が更新されないユニークキー」だ。テーブルはユニークキー（候補キーともいう）をいくつも持ち得るが、その中で少なくとも１個は主キーとして位置づけられる必要がある(*1)。 「本来的なユニークキー」はわかった。では「本来的でないユニークキー」とはどんなものか。その使いどころや効果的なテクニックについて説明しよう。 まず次のモデルを見てほしい。主キーが「顧客コード」であることが<...>で示されている。これに「顧客名＋所在地」の組み合わせでユニーク制約（{...}で示してある）を与えた例だ。同名顧客名があり得るため、SKには「所在地」も含めてある（顧客名や所在地は正規表

仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ

ビジネスルール(*1)と呼ばれるものの多くは「データベース構造」としてシステムに反映されるが、一部は「データ（インスタンス）」としてデータベースに登録される。その位置づけはシステム構成を考える際に興味深い論点で、効果的なシステムを設計するためのヒントになるだろう。 なお、ビジネスルールは業務システムの「業務構成」か「データ構成」か「機能構成」のいずれかの様態として組み込まれる。これらの３要素はそれぞれ、「役割分担や業務手順」、「データベース構造」、「プログラム仕様」くらいに理解してもらえばよい。これらのうちの「機能構成」に組み込まれがちなビジネスルールをいかに「データ構成」側に持ち込むか。それが、保守性の高い業務システムを手に入れるための課題である。 さて、ある種のビジネスルールは「データ構造」としてではなく「データ」としてシステムに組み込まれる。ただしこれは比較的特殊なケースだ。たとえば

私は業務システムというものが好きだ。売上そのものを生み出すしくみではないので派手さはないが、経営効率を高めるための縁の下の力持ちのような奥ゆかしさがある。そして、日本企業の特質である「顧客のわがままに柔軟に応える姿勢」を貫くための鍵が、他でもない業務システムである。効果的な業務システムをいかに効率的に設計・実装するか。それを考えたり実践することが楽しくてしょうがない。 この分野にも固有の専門性がある。まず必要なスキルは、業務連係やデータベースの設計技術、そしてシステム構成と統合された会計知識だ。適性としては、論理的な思考力や人並み以上の言語能力が求められる。これらの技能を合わせて「業務系スキル」と呼んでおくが、その重要さは実装手段が変わっても揺るがない。 ところが、開発を専業とする組織における業務系スキルの空洞化が著しい。じっさい今になって営業担当者があわてている。長い不況を抜けてやっと業

中小企業のシステム化は遅れている。事業規模が小さいからといって、彼らが扱うデータが単純少量というわけではない。Excelでは管理しきれない複雑大量のデータが日常的に扱われている。にもかかわらずシステム化が進んでいないのは、IT予算が少なすぎてSIerから敬遠されるからだ。IT予算の相場は売上額の1～3%と言われているから、売上10億以下の中小企業はSIの対象とはみなされにくいという現実がある。 なお、「中小企業」の定義は業種によって異なる。製造業を例にすると「資本金の額又は出資の総額が3億円以下の会社又は常時使用する従業員の数が300人以下の会社及び個人」が中小企業である。製造業における中小企業比率は、売上高で34.1%、従業員数で59.8%、企業数ではなんと99.5％を占めている（平成10年の統計）。ようするに日本の企業の圧倒的多数が中小企業である。 彼らが業務データを管理するために、出

WindowsXPの保守期限が迫っていることから、いろいろな苦労話を耳にする。その中から、業務システムに関する深刻な問題を取り上げよう。 昔、EUC（エンドユーザコンピューティング）という流行語があった。いまどきの「内製」に似ているのだが、気の利いた開発ツールを使ってちょっとした機能をエンドユーザ自身がプログラミングしてしまうことをいう。 EUC向けに人気を集めた当時の開発基盤が、DelphiやVisual Basicだった。私自身、Delphi1.3でPCでのプログラミングを始めた手合いで、このツールには今でも初恋の相手のような懐かしさがある。それらのツールに夢中になったのは、私のようなプロの開発者ばかりではなかった。正真正銘の「素人」によるEUCが全国津々浦々でなされた。 その結果、今になって何が起こっているか。その種の古い基盤で開発されたモジュールが新しいOSで動かないことに気づいて

業務システムはいったん完成すれば終わりというものではなく、事業に合わせて変化・発展していかねばならない。その過程で開発者は、システムのあり方を把握するための包括的ドキュメントとシステムの実際のあり方を整合させるという課題に直面する。「仕様書とプログラムの不整合」はそういうった問題のひとつである。私が提唱する「３要素分析法」の枠組みを使って、ここらへんをじっくり眺めてみよう。 ◆不整合はどこで生じるか まず、問題の様相を理解するために、基本設計書と仕様書（詳細設計書）とアプリケーションのそれぞれに含まれる要素と、それらの対応関係を見よう。まとめると図１のようになる。 図１ まず、この議論の起点となる「基本設計書」には、私の言う「業務システムの３要素」が概念上含まれる。すなわち、業務モデル(どのようにシステムが利用されるか)、データモデル(データベースはどのような形をしているか)、機能モデル(

「DB構造の正規化」は業務システム設計の眼目である。それはデータ項目間の関数従属性をDB構造に反映させるために必要な配慮であり、これを怠ると、データの矛盾やアプリの複雑化にともなう保守性の低下といったさまざまな問題が生じる。いわゆる「正規化崩し」を行うにせよ、基準となる正規形の認識なしでは失敗する。以上は事実として広く知られるようになった。 ところが「システムの仕様情報」を正規化することの重要性はほとんど認識されていない。従来の仕様書の分厚い束には、記述の重複やそれゆえの矛盾があちこちに埋まっている。DB構造だけでなく仕様情報の構造についても、関数従属性にしたがって"one fact in one place"の形に正規化される必要がある。何のためか。矛盾を除くとともに、仕様の作成・保守コストを最小化するためだ。 たとえば「テーブルＴ」のフィールドとして「XX単価」と「XX数量」があって、

米国の確定申告は複雑なので、確定申告用ソフトの開発が奨励され、使いやすいツールがいろいろ登場した。そのため、確定申告の有償支援サービスがあらかた要らなくなって、この５年間で８万人の公認会計士(CPA)が職を失ったという。訴求力のある専門性を持っているか、創造的な役割を果たせる会計士しか生き残れないだろうと言われている。 わざわざこんな例を挙げるまでもなく、コンピュータが人々の仕事を奪い続けてきたことは広く知られた事実である。そんな動きに関してコンピュータの売り手は「機械的で退屈な仕事は機械にまかせ、人間は創造的な活動に邁進すればよい」と語ってきた。いかにも対岸の火事を眺めるようなお気楽な言い草だし、本来は自発的であるはずの創造性の発揮が強制されるなんて勘弁してほしい。 とはいえ当然ながら、ソフトウエアの作り手にもこの「創造性の強制」は及んでいる。機械的で退屈なプログラミングがコンピュータに

「仕様書で駆動されるOSS生産管理システム」の実案件への適用を進めているのだが、その過程でさまざまな気づきがある。前回の記事に続いてもうひとつ説明しよう。生産管理システムであってもロット管理は必須ではない――という話だ。 どんなに作業を標準化したとしても、製造ロット（製造したまとまり）毎に品質特性は異なる。工程条件が微妙に異なるし、投入された資材品の品質特性も異なるからだ。ロット情報を管理することはメーカーの課題のひとつである。 ところが、ロット管理をやろうと勢いづいて在庫までをロット毎に管理しようとすると、システムは想像以上に複雑化する。まずロット別の在庫を管理するのであれば、ロットマスター（品目ロット）とともに、ロット別の内訳（倉庫在庫明細）を保持しなければいけない（図１）。 図１．ロット管理型の在庫モデル 在庫ＤＢはシステムの背骨のような要素なので、これが複雑になればシステム内のさま

予定より１ヶ月遅れたが「CONCEPTWARE／生産管理」の実装作業が完了した。さっそく実案件向けに修正課題をまとめているところなのだが、とりあえず現時点の仕様で公開することにした。もう少し機能を整理する予定の暫定版をここからダウンロードできる。 OSSのパッケージシステムとして「安かろう悪かろう」などと侮ってはいけない。まずこのシステムには無償であることよりも重要な特徴がある。データモデル、業務フロー、業務マニュアル、仕様書といったドキュメントが添付されている点、そしてなによりも「仕様書を編集すればシステムの動きが動的に変化する開発基盤(XEAD Driver)」の上で実装されている点である。 "動的に変化する"という点がとくに重要で、仕様変更の過程でコードの再生成もリコンパイルも伴わない。なぜかというと、仕様書を読み込んで開発基盤そのものが変形して立ち上がる「動的制御」のしくみだからだ

システム設計資料のひとつに「CRUD図」と呼ばれるものがある。システムに含まれているそれぞれの機能（データ処理プログラム）が、それぞれのテーブルに対してどんな操作をしているか。それをマトリックス形式で俯瞰するためのものだ（次図）。操作として"CRUD"として示された場合には、Create,Read,Update,Deleteの全操作がされている、という意味になる。ちょっとした設計ミスもこの資料を使えば見つけやすい。 この表は「機能」と「データ」の関係を示したものであるが、CRUD関係を見るための切り口としては「業務」もはずせない。ここで言う「業務」とは「特定の役割を担う要員が、特定のイベントが起こったときに実施する一連の手続き」に名前を与えたもので、「業務単位」や「業務定義」とも呼ばれる。DFDで描かれた業務フローには、これらの業務単位がデータフロー図上のプロセス（楕円で示される）として置

商品を販売する過程で、厳密にはどのタイミングで売上計上が起こるのだろう。スーパーでは商品をレジに持っていったときに売上計上される。B2B（business to business,企業間取引）ではもっとややこしく、「計上基準」によって違う。すなわち、出荷基準（売り手が出荷した時点で売上計上）、納品基準（買い手に渡した時点で売上計上）、検収基準（買い手が検収した時点で売上計上）、といったタイミングの違いが生じる。 売り手にとっての売上計上は買い手にとっての「仕入計上」なので、本来であればこれらの事象は同時に起こるはずだが、会計基準において仕入計上と売上計上の同時性は大きな問題にならない。業務システムの多くは、顧客側の仕入計上基準に関係なく単一の売上計上基準で処理している。 国際会計基準(IFRS)では売上計上基準の適用厳格化が図られるため、業務システムが単一の売上計上基準では処理しきれなくな