業務システムとマイクロサービス（２） - 設計者の発言
マイクロサービス・アーキテクチャ(MSA)を適用する際に頭を悩ます問題のひとつが「複数サービスにわたる更新操作」である。マイクロサービスを成すソフトウエアのまとまりは、個々に独自のデータストアを持っている。ゆえに複数サービスを横断する更新操作の際、トランザクション管理によるACID特性を保証できなくなる。 この問題に対処するために二相コミットや結果整合性等の考え方があるが、どのやり方でも限界があるし、ある種の制約や余分な手間を受け入れざるを得ない。もっとも穏当な設計方針は「複数サービスに渡る更新が起こるような粒度ではサービスを切り出さない」である。個々のサービスを実装する段になって悩む前に、サービス粒度の設計に関して事前に考慮すべきことがあるということだ。 前回記事で説明した「CRUD基準によるサブシステム分割」は、更新制御の面から見たサービス粒度の設計基準として応用できる。ドメイン駆動設
業務システムとマイクロサービス（１） - 設計者の発言
マイクロサービス・アーキテクチャ(MSA)は、モダンなソフトウエアのあり方を考える際に欠かせない考え方だ。複雑で巨大なソフトウエアを扱いやすいモジュールに分割することで、独立したチームに開発や運用・保守をまかせられるようになる。モジュール間の通信はシンプルなAPIを用いてなされ、それらの仕様さえ理解しておけばモジュール間連係をスマートに実現できる。経済産業省が2018年に発表した「DXレポート～ITシステム『2025年の崖』の克服とDXの本格的な展開～」でも好意的に紹介されていた。 しかし、業務システム開発でMSAを適用する際には注意が要る。業務システムを1個のサービスとみなして、他システムに対するインタフェースを与えることになんら問題はないし意義深い。しかし、業務システムを構成する個々のブロック（サブシステム）を機械的にマイクロサービスの単位とみなすべきではない。更新制御に関する問題を生
サロゲートキーにこだわるデータモデルの異様さ - 設計者の発言
サロゲートキーは「ワサビ」のようなものだ。ある種の料理を引き立てるため、熟慮のうえ利用される。どんな料理にもワサビが強制されるとしたら、異様な食卓になるだろう。同様に、どんなデータを扱う場合にもサロゲートキーが強要されるとしたら、異様な情報管理システムになるだろう。 その異様さはさまざまな例で示せるが（参考記事「Railsは新人教育に向いていない」）、今回は「予実管理」のモデルで眺めてみよう。まずはまともな例（図１）。期間別の管理項目が、年月を含む主キーで与えられるテーブル上に保持されている。業務システムではふつうに見られるものだ。 図１．予実管理のモデル さまざまなリソース毎に期間別の計画値を設定して実績値と比較することは、業務システムの日常的な役割のひとつである。期間別の計画と実績の乖離を見るというのは、業務上の管理レベルを高めていくための常套手段だ。実績値の集計元となるトランザクショ
仕様の「見える化」と働き方改革 - 設計者の発言
工学の世界広しといえども、複雑膨大な設計情報をExcelで管理しているのはIT業界くらいだろう。ITは現代社会のインフラを成すほど重要なものだが、その有り様がOfficeのような汎用ツールで管理されているとしたら、なんと脆弱なインフラだろうか。Excelで設計情報が管理されている飛行機や高層ビルなど、怖くて誰も利用しないだろう。プロのIT技術者を名乗るなら、プロ用のCAD/CAM（エンジニアリングツール）を使おう。気に入るものがなければ、ITスキルを行使して自作しよう。私は長年そのように主張してきた。 残念ながら、業界でのCAD/CAMの利用は進んでいない。今でも石を投げれば「Excel方眼紙」の峨々たる集積にあえぐプロジェクトに当たる。何回か説明したが、これにはそれなりの理由がある。まず、ExcelやWordやパワポやVisioでの仕様管理を前提とすれば、余分な工数や要員を見積に上乗せで
クラス図とデータモデルはどうちがう？ - 設計者の発言
しばらく前に、初対面の先輩技術者とDB設計について話していたときのことだ。彼が書いた「データモデル」を見せてもらったのだが、そこには主キーが示されていなかった。不思議に思って尋ねると、「主キーを何にするかは実装上の問題なので、示してありません」という答だった。 これには驚いた。「鉄筋の本数は施工上の問題なので、設計図には示してありません」と言われたようなものだ。主キーはシステムが扱うデータの論理構造を表すために不可欠なもので、それが示されていないデータモデルはセンチメンタルな「ポエム」でしかない。 そういうものにもとづいて高層ビルを建設すれば施工中に倒壊して、設計図がポエムでしかなかったことが明らかになる。ところがシステム開発の場合、現場が苦労に苦労を重ねるとまがりなりにも出来上がってしまうので始末が悪い。設計者は自分のやり方を是正することなく、いつまでも彼の文学作品をデータモデルとして世
「命名標準」に振り回されないために - 設計者の発言
テーブルやフィールドの命名標準は悩ましい問題だ。「フィールドIDが全角日本語であることの意義」で全角日本語で設定することの合理性について述べたが、いくつかの技術的障害や習慣の影響もあって、なかなか広まっていないのが現状である。 いっぽう、英語表現にこだわっている職場もあるが、英語に堪能な技術者ばかりでないために、けっきょくどの国の人間が見ても了解不能な表現になっていたりする。表現が的確であったとしても、文字列として長過ぎては作業記憶に納まらないので仕事がやりづらい。かといって省略形を駆使して短めにすると、符牒のようになって第三者にわかりにくくなる。 「一覧順」の問題もある。全角日本語なり、半角の英語や日本語ローマ字でdescriptive(記述的)な表現をすると、一覧した場合の並び順が二の次になる。とくにテーブルの並び順というのは、仕様管理におけるエンジニアリング課題のひとつなので、それが
「論理削除」ではなく「無効化」を - 設計者の発言
以前の記事で、テーブルに「スタンプ属性」をいちいち載せるのは惰性的習慣ではないかと書いたが、似たものに「論理削除フラグ」がある。各テーブルにいちいちこれが置かれているDBを見ることがあるが、それもまた惰性の結末ではないか。スタンプ属性だろうが論理削除フラグだろうが、必要ならば置くべきだし、必要でないなら置くべきではない。ただし、多くのケースで必要なのは「論理削除」ではなく「無効化」であることは知っておいたほうがいい。 削除のややこしさは、他テーブルとの関係にある。まず、通常の削除（物理削除）について見よう。テーブルAと参照関係にあるテーブルBがあるとする（図１）。ここで、テーブルA上のレコード①が、テーブルB上のレコード③と④によって結合（参照）されているとすれば、①を削除することは許されない。もし削除してしまえば、存在しないAレコードを結合するBレコードの存在を許してしまう。典型的な更新
モデリングの標準問題から学べること - 設計者の発言
大切な人の記念日に花束とカードを贈りましょう――そんな事業を支援するシステムの三要素モデルを公開した。もともとのシステム要件は「花束問題V1.2」として、IT勉強宴会のサイトで公開されている。複雑過ぎず単純過ぎないバランスの良い問題である。 ・ダウンロードページ（モデルを閲覧するにはX-TEA Modelerが必要） ・花束問題V1.2のページ 要件をざっと説明しよう。「商品」である花束に組み込まれる素材は「単品」と呼ばれ、入荷日毎にロット管理される。単品ロットはナマモノなので、規定の日数後には廃棄されなければいけない。ゆえに、受発注状況に応じた単品の欠品見込や廃棄見込をリアルタイムで示すための仕掛けが要る。次図は公開したモデルの一部である。 ▼受注～出荷の流れを示す業務フロー ▼受注まわりのデータモデル このシステム要件にもとづいてまとめられたモデルを、手法横断的に比較検討する。そんな活
新人技術者にはOOPLの前にDSLを - 設計者の発言
例によって、業務システム開発の世界に限った話である。ＥＣサイト開発の話でもないし、ＷＥＢサービス開発の話でもない。販売管理システムや生産管理システムといった「業務システム」の開発を専業とする企業において、新人に最初に教えるべき言語は何かという話だ。今ではJavaを教えている企業が少なくないが、OOPL（オブジェクト指向言語）のような「汎用言語」ではなく、本来は業務システム開発に特化したDSL（ドメイン特化言語）を最初に教えるべきだ。 なぜか。前回記事でも述べたように、プログラミング以外の専門分野（ドメイン）を見定めてそれを究めることが、ソフト技術者のキャリアにとっての優先課題だからだ。業務システム開発を専業とする企業に所属する技術者にとってのドメインは、基本的に「業務システム」ということになる。「業務システムの専門技術者」を育てるためということなら、OOPLではなく「業務システム向けDSL
データ指向設計・開発の実践 - 設計者の発言
経験豊かな開発者は知っているが、業務システムというものは「データの扱いに関するこまごました制約の塊」のようなところがある。したがって、データ毎のステータス遷移やそれに伴う制約を丹念に整理するとともに、それらを効果的に実装することを考えなければいけない。そのためには「アプリ指向」ではなく「データ指向」な開発方針を取り入れる必要がある。現在開発中の「受注生産システム」から「製造指示」をとりあげて説明しよう。 まず、製造指示まわりのデータモデルを確認しよう。製造指示(JT010)を完遂させるためには、仕様明細(JT020)、工程明細(JT030)、材料明細(JT040)といった関連情報を管理する必要がある。それらのデータは、製造指示が追加される際に各種のマスターにもとづいてセットアップされる。 製造指示まわりのデータモデル 製造指示のステータス（製造状況）遷移を見よう。新規登録すると「未発行」と
エンタープライズ・アジャイル：手法論より大事なもの - 設計者の発言
最近耳にするようになった言葉に「エンタープライズ・アジャイル」というものがある。業務システム（販売管理や生産管理といった大規模な基幹システムのこと）をアジャイル開発するやり方を意味する。そのためにSAFe(Scaled Agile Framework)やDAD(Disciplined Agile Delivery)といった洗練された枠組みが提唱されているが、次から次に登場するこの種の手法論が問題を解決してくれるとは私には思えない。 「エンタープライズ・アジャイル」とことさらに「エンタープライズ」を強調するのは、それまでのアジャイル手法が業務システム開発にうまく適用できていないことを物語っている。じっさい、業務システムとアジャイル手法は水と油みたいなところがあって、業務システムの以下の特性ゆえにアジャイル手法の適用は簡単ではない。 特性１：ドキュメントが必要 複雑巨大な業務システムの可読性や
「複合キー」と実装用フレームワーク - 設計者の発言
テーブルの主キーの設定に関して「複合キーと代理キーのどちらが適切か」という議論がある。私の立場は明確で、 分析段階では必要に応じて複合キーを用いながらモデリングし、実装段階で環境の事情に応じて代理キーを導入すればよい。もちろん、モデルのとおりに実装することが許されるならば、それがいちばんよい。 というものだ。根拠を説明しよう。 以下のようなデータ要件があるとする。記号ではイメージしにくいという読者には、テーブルＡが「社員」で、Ｃが「趣味」で、ＡＣが「社員の趣味」と想像してもらえばよい。その場合の属性eは、各社員の各趣味に対する「好みの度合い(-2は大嫌い、2は大好き、とか)」くらいと考えてもらえばよい。要は a,b,c,d,e の５つの管理項目が見出され、項目間に b=F(a)、d=F(c)、e=F(a,c) の関数従属性が認められたという例だ。 [Ａ] {a}, b ＋ 100 aaa
テーブル関連の「排他性」をモデル上で表現する - 設計者の発言
どんなに複雑に見えるデータモデルでも、テーブル関連には親子関係、参照関係、派生関係の３種類しかない。ただし、それぞれの関連には排他的なものとそうでないものがある。これを見かけ上区別できるような工夫を紹介しよう。ここらへんを理解しておけば、データモデリングのスキルがワンランクアップする。 まず、参照関係の例を見よう。あるテーブル(B)に置かれたレコードが、別のテーブル(A)上のレコードに対して対応関係を持つとする。このとき、B上のAへのアクセスキーが、B自身の主キーに包含されていない場合、両者の関係を参照関係という（図１）。この場合、B側のテーブルを「参照元」、A側を「参照先（被参照）」といい、B側のアクセスキーを外部キー（または参照キー）と呼ぶ。 図１ ここで、BがAの他にA'の間にも参照関係を持つとしよう（図２）。ここで、BがAとの対応を持つときはA'との対応を持たず、A'との対応を持つ
ユニーク制約の使いどころ - 設計者の発言
前回記事で説明したように、主キーは「ユニーク制約をともなうインデックス」ではなく、「本来的なユニークキー(一次識別子, Primary Key, PK)」である。すなわち、「NULL値をとらないし、レコードのライフサイクルにおいて値が更新されないユニークキー」だ。テーブルはユニークキー（候補キーともいう）をいくつも持ち得るが、その中で少なくとも１個は主キーとして位置づけられる必要がある(*1)。 「本来的なユニークキー」はわかった。では「本来的でないユニークキー」とはどんなものか。その使いどころや効果的なテクニックについて説明しよう。 まず次のモデルを見てほしい。主キーが「顧客コード」であることが<...>で示されている。これに「顧客名＋所在地」の組み合わせでユニーク制約（{...}で示してある）を与えた例だ。同名顧客名があり得るため、SKには「所在地」も含めてある（顧客名や所在地は正規表
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
「プログラミングへのこだわり」を方向づける - 設計者の発言
業務システムの生産性や保守性を高めるための基本は「コードを１行でも減らす」である。なぜなら、コーディングとこれにともなうテスティングこそが、開発作業の中でもっとも人手のかかる作業だからだ。個別案件においては、良いコードだろうが悪いコードだろうが少なければ少ないほどよい。 いっぽう、そんな方針と明らかにそぐわない人たちがいる。彼らはプログラミングそのものに強いこだわりを持っていて、より良いコードをより多く生み出すことに生きがいを感じる人たちだ。チャーミングな彼らの姿を個別案件の開発現場で見るたびに、私はキャスティングの失敗事例を見る思いがして切なくなる。 それは全国チェーンの外食店の厨房に、新しい料理を生み出すことに情熱を覚える若者が働いているようなものだ。彼がどう工夫しても、全国一律の料理メニューを改変するのは難しいだろう。そんな才能あふれた若者には、本部の企画部門で働いてもらったほうがい
残高テーブルの設計と統計処理 - 設計者の発言
買掛残高、売掛残高、在庫残高といった「残高テーブル」の構成に関して見る。とくに、残高テーブルと「統計情報」との関係について検討したい。 以前に取り上げた「取引実績テーブル」もそうなのだが、業務システムにとってごく基本的なテーブルであるにもかかわらず、どのように設計すべきかの議論がきわめて少ない。経理まわりの知識は書籍やサイトで豊富に手に入るが、これをＤＢ設計の問題と関連させた記事がほんとうに少ない。こんな粗末なエントリーでも、ないよりはマシに違いない。 まず買掛残高テーブルと売掛残高テーブルを見よう。基本的に次のような形をとる。取引先テーブルは「マスター管理サブシステム」に、仕入先テーブルは「買掛管理サブシステム」に、得意先テーブルは「売掛管理サブシステム」に所属する。仕入先と得意先は、取引先の拡張属性を保持する「サブタイプ」として位置づけられる。 ┌＋取引先 {取引先Ｃ} 名称,所在地,
クラウドと基幹システム - 設計者の発言
「猫も杓子もクラウド」のご時勢だが、どうも腑に落ちないことがある。クラウドというのは要するに「部屋を借りるのも安いし、必要に応じて部屋の大きさが拡張します」という話である。それはそれで気が利いていると思う。しかし、そもそもその「部屋」を誰が作るのか。 「作る必要はありません。クラウドベンダーによって提供され、保守されます」 ほほぅと感心しつつ調べてみると、見積書と納品書あたりを発行するためだけの「販売管理システム（！）」とかＥＣサイトのような単機能モジュールは見つかる。いわば「会議室」とか「展示会用ホール」とか「小売用店舗」みたいな特定用途向けの部屋だ。そういうものではなく、事業を進めるための統合事務処理環境、つまり「基幹システム」はどうなっているのか。 「ＳＯＡですよ。ご存知ありません？クラウド上で提供されているサービスを自由に組み合わせることで、基幹システムだろうとお望みのものが手に入
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
人数ではなく技能を確保するためのシフト管理システム公開 - 設計者の発言
ドメイン特化基盤がドメインを豊かにする - 設計者の発言