データモデルはドメインモデルに先行する - 設計者の発言
関わっているあるプロジェクトで、Javaでのコンポーネントベース開発を進めるためのクラス図が出来上がりつつある。DDD（ドメイン駆動設計）に関心を持つ技術者にとってお手本になるような端正なドメインモデルだ。それを眺めながら関係者がしみじみと感じていることがある。どんなに優秀なドメインエキスパートと組んだとしても、DDDにもとづいてこのモデルを「先に」生み出すことは不可能だっただろう。 どういうことか。我々はまず、泥臭い分析と設計を重ね、あるべきデータモデルを完成させた。そのうえで実装方式の専門家の協力を仰ぎ、クラス図が出来上がった。つまり、データモデルからドメインモデルが導かれたのであって、その逆ではない。じっさい、ドメインモデルからデータモデルを導くことが不可能であったことは、両者を並べたら一目瞭然なのであった。 これは重要な論点だ。データモデリングとドメインモデリングのどちらを先行させ
業務システムとマイクロサービス（１） - 設計者の発言
マイクロサービス・アーキテクチャ(MSA)は、モダンなソフトウエアのあり方を考える際に欠かせない考え方だ。複雑で巨大なソフトウエアを扱いやすいモジュールに分割することで、独立したチームに開発や運用・保守をまかせられるようになる。モジュール間の通信はシンプルなAPIを用いてなされ、それらの仕様さえ理解しておけばモジュール間連係をスマートに実現できる。経済産業省が2018年に発表した「DXレポート～ITシステム『2025年の崖』の克服とDXの本格的な展開～」でも好意的に紹介されていた。 しかし、業務システム開発でMSAを適用する際には注意が要る。業務システムを1個のサービスとみなして、他システムに対するインタフェースを与えることになんら問題はないし意義深い。しかし、業務システムを構成する個々のブロック（サブシステム）を機械的にマイクロサービスの単位とみなすべきではない。更新制御に関する問題を生
OOUIは強力だが、合理的なDB構造を導くわけではない - 設計者の発言
話題の新刊書「オブジェクト指向UIデザイン」を読んだ。使いやすいUIについては昔から興味があって手に取ったのだが、読みながら既視感につきまとわれた。かつてAS/400使いであった筆者は、90年代初頭に「アクション→オブジェクト vs オブジェクト→アクション」という話題で仲間と盛り上がっていたことがある。その内容がまさにこの本で書かれていたことだった。 「アクション→オブジェクト」とは古いタイプのUIで見られるパターンである。ワープロソフトが普及する以前、「ワープロ専用マシン」というものがあった。それを起動して最初に現れるメニューには、以下のようなメニューオプションが並んでいたものだ。 ・ドキュメントの追加 ・ドキュメントの複写 ・ドキュメントの編集 ・ドキュメントの削除 ・ドキュメントの印刷 たとえば「ドキュメントの編集」を選ぶと、ドキュメント名を入力・選択するためのダイアログが現れる。
新人にオブジェクト指向の魅力を知られてはいけない - 設計者の発言
新人研修の季節に思うところを書こう。開発作業の中核として活躍するはずの中堅技術者の多くがまともにDB設計できない、という寒々した状況がある。関数従属性も移動平均単価も知らない「設計担当者」がいたりする。私にとってその原因は明らかで、８０年代から９０年代にかけて注目されたDB設計や業務知識の重要性を、「オブジェクト指向」が怒涛のように押し流してしまったためだ。業務システム設計にとっての「失われた２０年」といっていい。 具体的には、JavaやRubyといったオブジェクト指向言語ベースのフレームワーク（未完成な骨格のようなコード群）を用いた開発スタイルが一般的になったためでもある。その結果、新人教育がオブジェクト指向言語の一辺倒になった。同時に、クラス設計を学べばDB設計も学んだことになると勘違いされて、「実装手段から独立したDB設計の枠組み」を学ぶための気運が失われた。IDのような単独主キーだ
DB設計がマトモであれば何とかなる - 設計者の発言
３月にJUASで開催された「データモデリング＆超高速開発ライブ」の動画が公開された（これ）。４分程度のダイジェスト版であるが、当日の雰囲気がよくわかる。私にとって興味深いのはデータモデリングで、描き拡げられる過程がコマ落としで示される様子が面白い。 このときは、私がやったことがないという理由もあって「配員管理システム」を開発課題にした。提案してくださった方の口頭説明にもとづいて、参加者からの意見を取り入れつつ１１個のテーブルを含むデータモデルとして４０分でまとめ、各チームが６０分で実装した。実装だけでなく、それに先行する設計もまた「超高速」である。 これほどの俊敏さで業務システムが出来上がるのは驚くべきことなのだが、このイベントは開発ツールの生産性を示すだけのものではない。当たり前の話だが、データモデルが不細工ならば不細工なシステムしか生み出されない。ツールが発展・普及する過程で実装作業は
UML版在庫データモデルの問題 - 設計者の発言
IPAによるデータベーススペシャリストの平成28年春期試験で、UMLモデルを使った問題が出されていた（これ）。最近たまたま見つけたのだが、これには驚いた。問題や解答が間違っているわけではないのだが、クラス図でデータモデルを描くことの危うさをこれほど雄弁に示している例はないので紹介したい。 まず注意してほしいのは、問題に添えられている「データモデル」の上でPK（一次識別子）が示されていない点だ。これは、クラス図ではすべてのインスタンスがID（オブジェクトID）で識別されるためだ（つまり、すべてのPKがIDであればいちいち示す必要がない）。PKを補ってER図として描き直すと図１のようになる。 図１．倉庫と商品の関係 一見すると問題がなさそうだが、このまま実装すれば悲惨なことになる。具体例を書き添えてみればわかるのだが、図２で示したようなデータ状況を許してしまう。すなわち、「倉庫と商品の同一の組
単独主キーでもDB設計は楽にならない - 設計者の発言
我ながらしつこいが、どんな開発環境においても「id」のような単独主キーを用いる設計手法の危険性について、もう一度指摘したい。この手法を「単独主キー主義」と呼んでおくが、これに関して「複合主キーを用いると主キーが変化しやすいから」とか「単独主キーのほうが仕様変更に対応しやすい」といった擁護意見がある。それらの主張が無効であるばかりか有害でさえあることを説明しよう。 なお、私はこの議論で「だからナチュラルキーが正しい」と言おうとしているのではない。じっさいのところ私はナチュラルキーを主キーにすることに反対しているが、それは本稿の主張と矛盾しない（参考記事）。ここで私が言いたいのは、複合主キーを用いたオーソドックスな設計手法を身につけたうえで、利用する開発環境の制約にもとづいて慎重に正規化崩しできるようになろう、ということだ。 ■サンプルのデータ要件 複合主キーを要求するデータ要件として、前の記
ALTER文の自動生成機能 - 設計者の発言
拙作のモデリングツールX-TEA Modelerで、テーブル定義の差分からDDLを生成できるようになった。もともと個々のテーブル定義にもとづいてCREATE文が示されるようになっていたのだが、今回のアップデートで、定義ファイルの差分にもとづくALTER文やDROP文を得られるようになった。これでテーブルモジュールの維持が楽になる。 使い方は簡単。X-TEA Modelerでは、システム定義ファイル(.xead)を更新する際に、適宜に専用フォルダにバックアップできるようになっている。最新版との違いを確認するための「差異レポート」の機能を呼び出し、いずれかの過去定義ファイルを指定する。パネルが表示されたらその上の「差分DDLを出力する」をチェックする（次図）。それだけで、DDLが新規のテキストファイルに出力される。 ▼「差異レポート」での差分DDL出力指定 便利な機能だが、限界はある。ある種の
アジャイルではなく「プロトタイピング」を - 設計者の発言
◆ボトルネックは「的確な仕様」の確立 業務システム開発の一般的なボトルネックは、プログラミングやテストやプロジェクト管理ではなく、「的確な仕様を確立すること」にある。どんなに優れたプログラマやＰＭを起用しようと、的外れな仕様のまま突っ走ってはクタビレ儲けにしかならない。反対に仕様が的確でありさえすれば、プログラミングやプロジェクト管理に問題があっても、立て直せる可能性はずっと高い。 それなら優れた設計スキルを持つ要員を起用すれば安泰かというと、話はそれほど単純ではない。まずは、クライアントによってシステム要件がクリアに表明される必要がある。それを手がかりにして整合性のあるシステム仕様を創案することは簡単ではないが、この後にさらに困難な過程が続く。「クライアントがその仕様を理解し、妥当性を評価すること」だ。けっきょく、優れた設計スキルといえども、的確な仕様を確立するための必要条件ではあるが十
「EXCEL仕様書からコード生成」のアンバランス - 設計者の発言
EXCELで書かれた仕様書は、その見かけから「EXCEL方眼紙」と揶揄されているが、今ではそれなりに進歩して、そこからDDLやクラスコードを出力できるようになっていたりする。しかし、そのような「気の利いた機能」を搭載すれば、EXCEL仕様書はますます奇妙なものになってゆく。 まず、生成されたコードが案外役に立たないという問題がある。たとえばCREATE TABLE文は文字通りテーブルを作成するためのものだが、現実の開発ではテーブルは何度も作り変えられる。それゆえに、CREATE TABLE文だけでなくALTER TABLE文も生成できるようであってほしい。ところが、EXCEL仕様書のテーブル定義からCREATE TABLE文を生成するのは簡単だが、定義修正後の差分からALTER TABLE文を生成するのは簡単ではない。 手段がないわけではない。テーブルオブジェクトのメタデータを読み出せばよ
正規化崩しの目的は「高速化」だけではない - 設計者の発言
ひとつの事実が１か所にしか記録されないようにする――これはDB構造を正規化する際の基本だが、このルールを意図的に違反すること（正規化崩し）で、効果的なDB構造が生み出されることがある。正規化崩しは高速化のためだけにあると思われがちだが、それ以外の目的もある。そのような正規化崩しのテクニックとして、「抽象化（汎化）」を取り上げよう。 説明の前に、正規化崩しに関して大事なことを言い添えておきたい。勘違いしている技術者がいるが、正規化崩しとは「正規化してから崩す」という意味である。本来の正規形を経由せずに非正規形になっているとしたら、正規化崩しではなく、単なる「無手勝流」でしかない。 では、いったん正規化してから崩すことがなぜそれほど重要なのか。事前に「更新時異状（更新処理にともなって発生するデータの不整合）」に対処しておくためだ。正規化崩しにせよ無手勝流にせよ、そのままでは遅かれ早かれ更新時異
テーブル操作と業務ロジックの連動制御 - 設計者の発言
テーブルに依存する業務ロジック（ビジネスルール）であれば、アプリから独立した「テーブルの拡張定義」として一元的に管理されなければいけない。そしてそれは、アプリによるテーブル操作に応じて暗黙的に呼び出され、アプリと変数域を共有しつつ実行されなければいけない。何のためか。アプリをうすっぺらにして、開発・保守の効率を高めるためだ。前回記事でそのように説明した。 では、テーブルに依存する業務ロジックであれば、アプリによってテーブル操作がなされたら必ず実行されるべきかというと、じつはそうではない。テーブル操作と業務ロジックを連動させるかどうかは、システム内部のアプリによって選択可能でなければいけない。両者を連動させたいことも、そうでないこともあるからだ。 このことに関係するのだが、RDBMSによって提供される外部キー制約やカスケードオプションのような「気の利いた機構」を、私はよほどのことがない限り使
フレームワークとドメイン特化基盤 - 設計者の発言
JavaやRubyは「汎用プログラミング言語」であって、これを使えばたいていのソフトウエアを作れる。ゲームソフトも、組み込みソフトも、業務システムも、バンドのリズムセクションの自動演奏音源だって作れる。すばらしい。しかしこれは、汎用プログラミング言語の使い方として適切なのだろうか。 それらのソフトウエアは、いずれかの「ドメイン（ソフトウエアの分野）」に分類される。同一ドメイン内のソフトウエア群であれば、同一の特性を具えている。その共通特性にもとづいて、開発過程を合理化するための枠組みを想定できる。 そのような枠組みとして、もっとも素朴なものが「クラスライブラリ」だ。当該ドメイン向けに便利なクラス群をあらかじめ用意しておくのである。それらにテンプレート機能等を組み込んで整備すれば「アプリケーション・フレームワーク(APFW)」と呼ばれるものになる。 ドメインに対する合理化の営為はこれで終わら
業務ロジックをアプリに置いてはいけない - 設計者の発言
業務システムを純然たるソフトウエアとして見た場合、テーブルとアプリ、そして「業務ロジック（ビジネスルール）」の３つの定義要素の組み合わせとしてモデル化できる。この中の「業務ロジック」の配置様式は、システムの開発・保守効率に決定的な影響を与える。 業務ロジックとはどういうもので、それはどのように配置されるのだろう。たとえば「注文テーブル」に「XXX数量」があるとして、その「初期値」が1000であるとしよう。素朴ではあるが、このルールも業務ロジックの一種である。これがどのように配置されるかというと、ふつうは注文テーブルのCreate文のDefault句として組み込まれる。 「初期値」だからといって、Default句で対応できるとは限らない。実際には「YYYが'A'の場合は1000だが、YYYが'B'の場合は0を初期値とする」といった条件をともなうことがある。さらに、「YYYが'C'の場合には、
機能タイプ＆テーブルポジションで効率アップ - 設計者の発言
拙作のOSSモデリングツールX-TEA Modelerの「機能定義」に含まれる「テーブル入出力定義」の属性として「ポジション」を追加した（次図）。X-TEA Modelerにおいて機能定義はユーザ定義された「機能タイプ」別に分類されるが「（テーブル）ポジション」はこれと密接に関係している。それらを組み合わせて機能定義することで、設計情報を実装につなげやすくなる。 ▼テーブル入出力定義のポジション属性 業務システムには多種多様な機能定義（アプリ定義）が含まれるが、それらを「機能タイプ（データ処理パターン、デザインパターン）」に分類することで、設計過程が合理化される。私の経験では、10種類以下に整理された機能タイプで、業務システムに含まれる70%程度の機能定義（アプリ）をカバーできる。それらについてはざっくりしたフォームのデザインを補足するだけで、設計作業が完了する。残りの30%については「そ
基本設計を分担してはいけない - 設計者の発言
プロジェクトメンバーが無駄に多いのが、日本型SIの特徴のひとつである。「工数を人数で割れば工期が出る」と考えることが間違いであることは、ブルックスの著書「人月の神話」によって今から40年前に指摘されている。それにもかかわらず、相変わらず多くのプロジェクトで必要以上の人数が投入されている。 私がとくに不思議に思うのが、基本設計を何人もの要員で分担するやり方だ。DB設計と機能設計と業務設計の担当を分けるとか、サブシステム毎に担当を分けるといった体制がしばしば敷かれる。詳細設計の段階でというのならまだわかるが、基本設計でそれをやってはいけない。 なぜか。業務システムにはアーキテクチャ（意図された構造）が求められる。そして、そこに含まれる膨大な定義要素は、統一感や一貫性を保ち、かつMECEな形で切り出されなければいけない。複数の要員で分担などすれば、それらの課題が一挙に難しくなる。また、DB構成と
ドメインの階層化とDSP - 設計者の発言
開発課題を「上位ドメインと下位ドメインの階層」とみなすことで、開発効率は劇的に改善される。上位ドメインに対する配慮を専用の開発基盤に委譲することで、下位ドメインの定義が様式化・最小化されるからだ。 何度か例として挙げた「コンピュータに"イパネマの娘"を演奏させる」の課題で説明しよう。この課題を引き受けたミュージシャンは、「初音ミク」のような専用ツールを使って、"イパネマの娘"の演奏定義ファイルをアジャイルに「編集」する。JavaやRuby等のプログラミング言語を使って大掛りな「"イパネマの娘"演奏システム」をアジャイル開発するわけではない。 ミュージシャンがやっていることは、「上位ドメインの特性」と「下位ドメインの特性」の分離である。すなわち、「コンピュータに"イパネマの娘"を演奏させる」の課題を、「コンピュータに楽曲ｘを演奏させる」という上位ドメインと、「ｘ＝"イパネマの娘"」という下位
データモデルの静と動 - 設計者の発言
業務フローで「スライドショー」が出来るというのが、XEAD Modelerの売りのひとつである。業務フロー上の業務単位やフローをタイミングをずらしながら表示することで、業務間の連係様式がわかりやすく示される。 最新版(1.4.15)では、データモデルでもスライドショーが出来るようになった。すなわち、モデル上でテーブル毎のインスタンス（レコードの実際値）とその表示順序を登録しておけば、インスタンスが変化する過程をスライドショーとして眺めることができる（次図）。試してみるとこれは大変効果的で、ともすれば難解になりがちなデータモデルが俄然わかりやすくなる。他のモデリングツールと違ってテーブルが横長の矩形として示されるゆえの芸当である。 図 データモデルのスライドショー 本来はテーブル間に「前後関係」はない。テーブルは常にそこに存在するものなので、それらの関係を模式化したデータモデルはもともと「静
データ指向設計・開発の実践 - 設計者の発言
経験豊かな開発者は知っているが、業務システムというものは「データの扱いに関するこまごました制約の塊」のようなところがある。したがって、データ毎のステータス遷移やそれに伴う制約を丹念に整理するとともに、それらを効果的に実装することを考えなければいけない。そのためには「アプリ指向」ではなく「データ指向」な開発方針を取り入れる必要がある。現在開発中の「受注生産システム」から「製造指示」をとりあげて説明しよう。 まず、製造指示まわりのデータモデルを確認しよう。製造指示(JT010)を完遂させるためには、仕様明細(JT020)、工程明細(JT030)、材料明細(JT040)といった関連情報を管理する必要がある。それらのデータは、製造指示が追加される際に各種のマスターにもとづいてセットアップされる。 製造指示まわりのデータモデル 製造指示のステータス（製造状況）遷移を見よう。新規登録すると「未発行」と
「ドメイン・エキスパート」になろう - 設計者の発言
２０年も昔の話だが、「英語できます」という本を読んで考え込まされたことがある。どんな仕事で稼ぐにせよ、何らかの専門性が要る。英語力というものは、そんな「専門性の効用」を引き上げるためのツール以上のものではない。むしろ中途半端に英語力があったばかりに専門性を深める努力を怠って、英語力を社会で生かせていない。そんな事例がいくつも紹介されていた。 この話、ソフト開発の技能に関してもいえるのではないだろうか。技術が進歩すればするほど開発の技能はコモディティ化し、これを習得しているだけでは大した意味はなくなる。ソフト開発の技能を社会で生かすためには、互いの効用をレバレッジするような何らかの「専門性」が要る。 これは、開発者自身がまず何らかの「ドメイン・エキスパート」であるべしという話に他ならない。ドメイン・エキスパートとは、DDD（ドメイン駆動設計）で言うところの、開発されるソフトウエアの適用分野（
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
