「ドメイン・エキスパート」になろう - 設計者の発言
２０年も昔の話だが、「英語できます」という本を読んで考え込まされたことがある。どんな仕事で稼ぐにせよ、何らかの専門性が要る。英語力というものは、そんな「専門性の効用」を引き上げるためのツール以上のものではない。むしろ中途半端に英語力があったばかりに専門性を深める努力を怠って、英語力を社会で生かせていない。そんな事例がいくつも紹介されていた。 この話、ソフト開発の技能に関してもいえるのではないだろうか。技術が進歩すればするほど開発の技能はコモディティ化し、これを習得しているだけでは大した意味はなくなる。ソフト開発の技能を社会で生かすためには、互いの効用をレバレッジするような何らかの「専門性」が要る。 これは、開発者自身がまず何らかの「ドメイン・エキスパート」であるべしという話に他ならない。ドメイン・エキスパートとは、DDD（ドメイン駆動設計）で言うところの、開発されるソフトウエアの適用分野（
エンタープライズ・アジャイル：手法論より大事なもの - 設計者の発言
最近耳にするようになった言葉に「エンタープライズ・アジャイル」というものがある。業務システム（販売管理や生産管理といった大規模な基幹システムのこと）をアジャイル開発するやり方を意味する。そのためにSAFe(Scaled Agile Framework)やDAD(Disciplined Agile Delivery)といった洗練された枠組みが提唱されているが、次から次に登場するこの種の手法論が問題を解決してくれるとは私には思えない。 「エンタープライズ・アジャイル」とことさらに「エンタープライズ」を強調するのは、それまでのアジャイル手法が業務システム開発にうまく適用できていないことを物語っている。じっさい、業務システムとアジャイル手法は水と油みたいなところがあって、業務システムの以下の特性ゆえにアジャイル手法の適用は簡単ではない。 特性１：ドキュメントが必要 複雑巨大な業務システムの可読性や
自由であるためにドキュメントを作る - 設計者の発言
前回記事で、ドキュメンテーションを重要視しない開発業者を避けるべきだと指摘した。同様の問題は、業務システムを内製した場合にも生じている。むしろ、ドキュメントレスな困ったシステムは、内製で生み出されているケースのほうが多いような印象が私にはある。 ドキュメントレスなシステムが重大なリスクを抱えていることを、ほとんどの経営者は認識していない。なぜなら、ドキュメントレスであってもシステムのあり方は内製担当者の「頭の中」に入っているので、彼に頼めば必要な改修はやってもらえるからだ。結果的に業務システムが、担当者のエンプロイアビリティ（雇用意義）を強化するための政治的ユーティリティと化すことを許してしまう。その歪みは、担当者がいなくなったときに一挙に顕在化する。いなくなった当人としては「後は野となれ山となれ」である。 業務システムがドキュメントレスになりがちな根本的な理由は、まさにここらへんにある。
ユニーク制約の使いどころ - 設計者の発言
前回記事で説明したように、主キーは「ユニーク制約をともなうインデックス」ではなく、「本来的なユニークキー(一次識別子, Primary Key, PK)」である。すなわち、「NULL値をとらないし、レコードのライフサイクルにおいて値が更新されないユニークキー」だ。テーブルはユニークキー（候補キーともいう）をいくつも持ち得るが、その中で少なくとも１個は主キーとして位置づけられる必要がある(*1)。 「本来的なユニークキー」はわかった。では「本来的でないユニークキー」とはどんなものか。その使いどころや効果的なテクニックについて説明しよう。 まず次のモデルを見てほしい。主キーが「顧客コード」であることが<...>で示されている。これに「顧客名＋所在地」の組み合わせでユニーク制約（{...}で示してある）を与えた例だ。同名顧客名があり得るため、SKには「所在地」も含めてある（顧客名や所在地は正規表
テーブル関連の「排他性」をモデル上で表現する - 設計者の発言
どんなに複雑に見えるデータモデルでも、テーブル関連には親子関係、参照関係、派生関係の３種類しかない。ただし、それぞれの関連には排他的なものとそうでないものがある。これを見かけ上区別できるような工夫を紹介しよう。ここらへんを理解しておけば、データモデリングのスキルがワンランクアップする。 まず、参照関係の例を見よう。あるテーブル(B)に置かれたレコードが、別のテーブル(A)上のレコードに対して対応関係を持つとする。このとき、B上のAへのアクセスキーが、B自身の主キーに包含されていない場合、両者の関係を参照関係という（図１）。この場合、B側のテーブルを「参照元」、A側を「参照先（被参照）」といい、B側のアクセスキーを外部キー（または参照キー）と呼ぶ。 図１ ここで、BがAの他にA'の間にも参照関係を持つとしよう（図２）。ここで、BがAとの対応を持つときはA'との対応を持たず、A'との対応を持つ
ドキュメントの山で遭難しないために - 設計者の発言
業務システム開発において、包括的ドキュメントは決定的に重要である。仕様がコードや開発者の頭の中にしか存在しないとすれば、そのシステムは限定された要員にしか保守できない。その結果、ユーザ企業は開発ベンダーにロックインされ、内製であれば担当者の不在リスクと長期雇用を押し付けられる。意図的であれ意図しない結果であれ、開発方針として上等とはいえない。 では、とにかくドキュメントを整備すれば良いのかというと、そういうことではない。大規模システムではしばしば、峨々たるドキュメントの山が築かれる。これでもかと階層化されたフォルダ構造と、EXCEL,パワポ,WORD,PDFのファイルの山。しかもそれらに含まれる定義要素間の制約関係は目視で維持されることになるため、整合性がじわじわと失われてゆく。また量が多すぎるため、欲しい情報に第三者がなかなかたどりつけないうえ、同じような文書が何度も作られたりする。 ド
データとして登録されるビジネスルール - 設計者の発言
ビジネスルール(*1)と呼ばれるものの多くは「データベース構造」としてシステムに反映されるが、一部は「データ（インスタンス）」としてデータベースに登録される。その位置づけはシステム構成を考える際に興味深い論点で、効果的なシステムを設計するためのヒントになるだろう。 なお、ビジネスルールは業務システムの「業務構成」か「データ構成」か「機能構成」のいずれかの様態として組み込まれる。これらの３要素はそれぞれ、「役割分担や業務手順」、「データベース構造」、「プログラム仕様」くらいに理解してもらえばよい。これらのうちの「機能構成」に組み込まれがちなビジネスルールをいかに「データ構成」側に持ち込むか。それが、保守性の高い業務システムを手に入れるための課題である。 さて、ある種のビジネスルールは「データ構造」としてではなく「データ」としてシステムに組み込まれる。ただしこれは比較的特殊なケースだ。たとえば
ボトルネックは「業務系スキル」 - 設計者の発言
私は業務システムというものが好きだ。売上そのものを生み出すしくみではないので派手さはないが、経営効率を高めるための縁の下の力持ちのような奥ゆかしさがある。そして、日本企業の特質である「顧客のわがままに柔軟に応える姿勢」を貫くための鍵が、他でもない業務システムである。効果的な業務システムをいかに効率的に設計・実装するか。それを考えたり実践することが楽しくてしょうがない。 この分野にも固有の専門性がある。まず必要なスキルは、業務連係やデータベースの設計技術、そしてシステム構成と統合された会計知識だ。適性としては、論理的な思考力や人並み以上の言語能力が求められる。これらの技能を合わせて「業務系スキル」と呼んでおくが、その重要さは実装手段が変わっても揺るがない。 ところが、開発を専業とする組織における業務系スキルの空洞化が著しい。じっさい今になって営業担当者があわてている。長い不況を抜けてやっと業
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
システムの仕様情報を正規化する - 設計者の発言
「DB構造の正規化」は業務システム設計の眼目である。それはデータ項目間の関数従属性をDB構造に反映させるために必要な配慮であり、これを怠ると、データの矛盾やアプリの複雑化にともなう保守性の低下といったさまざまな問題が生じる。いわゆる「正規化崩し」を行うにせよ、基準となる正規形の認識なしでは失敗する。以上は事実として広く知られるようになった。 ところが「システムの仕様情報」を正規化することの重要性はほとんど認識されていない。従来の仕様書の分厚い束には、記述の重複やそれゆえの矛盾があちこちに埋まっている。DB構造だけでなく仕様情報の構造についても、関数従属性にしたがって"one fact in one place"の形に正規化される必要がある。何のためか。矛盾を除くとともに、仕様の作成・保守コストを最小化するためだ。 たとえば「テーブルＴ」のフィールドとして「XX単価」と「XX数量」があって、
複合主キー「否定派」と「許容派」の論争 - 設計者の発言
定期的に取り上げたくなるDB設計に関する話題である。WEBアプリが一般化して以来、議論されてきた事柄がある。テーブルの主キーを「単独主キー」のみとするか、複数項目を組み合わせた「複合主キー」を必要に応じて使うべきかという問題だ(*1)。複合主キーに対する「否定派」と「許容派」に分かれた議論は劇烈で、宗教論争のようにも見える。 主キーというものは、テーブルの存在意義といってもいいほどに重大な要素である。にもかかわらず、なぜそんな基本的なレベルの議論が始まってしまったのか。２つほどの理由が考えられる。 まず、単独主キーとしてIDを機械的に置くやり方（ID方式）が「オブジェクト指向」と相性がよかったからだ。オブジェクトは固有の識別子（オブジェクトID）を持つので、これに相当するIDをテーブルの主キーとすることで、オブジェクトとDBの設計問題を統合できると考えた技術者が少なからずいた。そのアイデア
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
