DDDを冠するイベントや勉強会が、異様といっていいほどの盛況である。なぜそんなに人気があるのか。DDDが「オブジェクト指向プログラミングをもっとうまくやると同時に、開発者のドメイン知識の不足を補ってくれる方法」と思われているからではないだろうか。 そこには基本的なレベルの勘違いがあるような気がする。DDD本の中でも語られているように、開発者は個別案件が対象にしている特定ドメインに肉薄しなければいけない。そのためには、近傍のドメイン知識を事前に身につけておく必要がある。当然ながらそれは、DDDの実践だけでは身につかない（身につくとしてもひどく効率が悪い）。 「必要な知識はドメイン・エキスパートが補完してくれるから大丈夫。それがDDD」などと甘えてはいけない。ドメイン・エキスパートのカジュアルな語りからシステムのあり方を洞察するには、広範囲のドメイン知識や多能工的スキルに裏打ちされた総合力が要

業務システム開発の世界でも「アーキテクチャ」という言葉がふつうに使われるようになった。この場合のアーキテクチャとは「ソフトウエアのコンポーネント構造やそれらの相互関係に関する基本方針」くらいの意味なのだが、業務システムのように複雑で巨大なソフトウエアを効率的に開発・保守してゆくためには、アーキテクチャが適切にプランされていなければいけない。 私が不思議に思うのは、アーキテクチャが「フレームワーク」のレベルで饒舌に語られるわりに、「アプリケーション」のレベルでほとんど語られない点だ。 ここで言う「アプリケーション」とは、「全社システム」やその１モジュールである「営業管理システム（生産管理システム等の企業の本業を支援するシステム）」のようなソフトウエアのことを言う。いっぽう「フレームワーク」とは、ここでは「アプリケーションを開発するためのミドルウエア」を指している。「実装基盤」と呼んでもいい。

半年ほど前「ドメインモデル」の考え方を調べるうちに、masuda220氏の「システム設計日記」にたどりついた。「Domain-Driven Design」(Eric Evans著, 2003)の精読を通じてドメイン駆動開発の意味や意義を検討している読み応えのあるブログである。興味をもって４月にmasuda220氏に直接会ってお話を伺うことができた。おかげでようやくこの考え方を理解できた（ような気になっただけなので、間違った理解をしているとしたら私の責任である）。同時に、以前からドメインモデルに対して抱いていた疑問もより明確になった。 「ドメインモデル」の「ドメイン」とは、ソフトウエアが支援する「個々の現実」を指す。その現実に含まれる用語を用いて、ソフトウエアに含まれる変数やクラスやメソッドを命名して組み立てた場合、その体系は「ドメインモデル」と呼ばれる。設計成果物も実装成果物も、出来上がる

「モデリング本」の読者に訊かれることがある。「すばらしい設計ノウハウだと思うのですが、こんな貴重な知識を公開したら渡辺さんはそれで稼げなくなるんじゃないんですか」　この手の質問は困る。答えは単純ではないし、微妙で複雑な気持ちが入り混じっていて、とてもひとことでは答えられない。 ◆起こり得ることは遅かれ早かれ起こる 詐欺（サギ）をはたらく人々がしばしば口にする言い訳として、「こういう手合い（詐欺の被害者）は遅かれ早かれ誰かにむしり取られるもんだ。それなら、仲間うちでも良心的なワシにむしられたほうがいい」というのがある。盗っ人に説教されたら世話はないが、それにしてもこれにはいくばくかの真実が含まれている。確かに、起こり得ることは遅かれ早かれ起こる。 設計ノウハウの公開を積極的に進めている筆者の心中には、彼らの言い分に近いものが多少なりとも含まれている。業務ノウハウの公開というものは、遅かれ早か

業務システムの複雑膨大な設計情報を効率的に管理するために、Excelのような汎用ツールではなく、専用のCADツール（システム開発用の設計情報管理ツール）を使おう。そのように主張しているのだが、反応はさまざまだ。もちろんほとんどの技術者が賛同するのだが、所属組織にそれを導入できるかどうかになるとビミョーだったりする。 専用ツールを用いることの効果のひとつが、設計の巧拙がはっきりする点だ。スキルレベルの高い組織であればそれでいいだろうが、そうでない組織は現状維持を望むかもしれない。Excel方眼紙（細かい方眼紙状に設定されたExcelシート）で設計書を書くやり方は蛇蝎のように嫌われているが、それが設計の拙さを見えにくくするための隠れ蓑として役立っていることがある。彼らはExcel方眼紙がもたらす壮大な無駄を棚に上げ、「新たなツールを導入すれば、余計な学習コストがかかる。だいいち、ツールベンダー

「開発効率アンチパターン」という興味深いスライドがある。Android向けアプリ開発において「だるいコーディング（機械的なコーディング）」の手間を減らすための工夫が説明されている。基本的にはコードのテンプレートを活用する手法だが、専用の関数を用意して、パラメータ指定でより複雑なコードブロックを自動生成できるようにしたいと結ばれている。 このような効率改善のためのまっとうな努力は、開発の現場で広くなされていると思われるかもしれないが、必ずしもそうではない。スライドの作者である釘宮氏は、アプリを量産する必要に迫られている現場で働いておられる。そんな立場であれば、効率改善の工夫が欠かせないだろう。 いっぽう、「膨大な工数を下請けにまわして管理費とマージンで稼ぐ」ようなSI系の現場では、開発効率については現状維持を了とする。ときには「だるいコーディング」の手間さえ、契約工数の埋め草として是認される

例によって、業務システム開発の世界に限った話である。ＥＣサイト開発の話でもないし、ＷＥＢサービス開発の話でもない。販売管理システムや生産管理システムといった「業務システム」の開発を専業とする企業において、新人に最初に教えるべき言語は何かという話だ。今ではJavaを教えている企業が少なくないが、OOPL（オブジェクト指向言語）のような「汎用言語」ではなく、本来は業務システム開発に特化したDSL（ドメイン特化言語）を最初に教えるべきだ。 なぜか。前回記事でも述べたように、プログラミング以外の専門分野（ドメイン）を見定めてそれを究めることが、ソフト技術者のキャリアにとっての優先課題だからだ。業務システム開発を専業とする企業に所属する技術者にとってのドメインは、基本的に「業務システム」ということになる。「業務システムの専門技術者」を育てるためということなら、OOPLではなく「業務システム向けDSL

「超高速開発コミュニティ」が発足した。私も機会を見て参加したいと考えているのだが、それにしても「超高速開発」のキーワードは誤解を招きそうではある。その種のツールを使えば工期が半分とか３分の１になる――そのように勘違いされて導入すれば、ツールメーカーにとってもツールユーザー（開発者）にとっても残念なことになるだろう。 開発経験者はわかっているが、システム開発における律速過程は「実装」ではなく「実装されるべき仕様の確立」にある。そして、「統一感があって、有用かつフィージビリティ（実現可能性）が担保された仕様」を確立できさえすれば、どんな実装ツールを使おうがシステムはおおかた無難に完成するものだ。けっきょく「あるべき仕様がなかなか固まらない」点こそが、開発プロジェクトの慢性的な悩みのタネであって、この事実の前では「超高速に実装できる」ことの効果は案に相違して限定的なのである。 このことはドラえも

イケてるフレームワークを用いることで、従来の「案件従属なプログラミング工程」は「詳細設計工程」に吸収される。そういう話を前の記事で書いたが、そのフレームワークは「詳細設計書だけでシステムを動かす」ための基盤である。 詳細設計書を書くだけでシステムが動く――マジックみたいに思われるかもしれないが、それほど難しいことではない（そういうフレームワークを作っている本人が言うのだから間違いない）。「上流工程入門」で説明したように、データベースの部分構造とそこに対する処理様式の組み合わせにもとづく「機能パターン」を想定し、それら毎の処理プログラムを用意すればよい。 ではそのようなフレームワークを用いた場合、案件の実装工程（すなわち、プログラミングを吸収合併した後の詳細設計工程のこと）を担当するのはいったいどんな人物なのだろう。 少なくとも、従来の「案件従属なプログラミング工程」を担当していた要員が引き

誰もが参照できる「モデルシステム」がシステム開発業界には必要だ。そんな「知的社会資本」の整備は、この業界が長い間ないがしろにしてきた社会的使命である――私のこの主張に対して非現実的だと言われることがある。曰く、その種のノウハウは開発事業における競争力の源泉みたいなものだから、そんなものを積極的に公開しようとするお人好しな開発企業なんてあるはずがない、と。 モデルシステムは建築業界における「モデルハウス」に相当する。業種別の設計情報やその実装版としてライブラリ化されたもののことを言う。これを叩き台として個別案件が開始されるようになれば、システム開発のスタイルは一変する。なにしろ「作り始める前に完成している」のだから。 そういうリソースをシステム開発企業が積極的に公開するとは私も思っていない。しかしその理由として「システム開発業における競争力の源泉だから公開するはずがない」などと解説されると不

９０年代の後半以降、WEBアプリの実装技術が急速に発展した。そのおかげで、それまで使いにくかったHTMLページを業務システム（基幹業務支援システム）でも使えるようになった。それはそれで意義深いことではあったが、いっぽうで若手の技術者から業務知識の学習機会が奪われてしまった。いったい何が起こったのか。 ソフトウエアの適用分野毎に、技術者に求められる専門性は異なる。「組込ソフト」の分野であれば、ハードウエアの動作や利用に関するさまざまな専門知識が要るだろう。「音楽ソフト」向けには、MIDIやサウンドデータに関する専門知識が求められそうだ。業務システムの開発者であれば、いわゆる「業務知識」が求められる。具体的には、簿記、DB設計、業務プロセス設計といった知識やスキルだ。業種・業態を越えてシステム要件を仕様化するためには欠かせない素養である。 ところが現在のWEBアプリの開発現場において、日常的に

オブジェクトモデリングとデータモデリングはどこが違うのだろう。クラス図やER図といった成果物を比較するだけではわからない本質的な違いが両者にはある。 オブジェクトモデリングは基本的に、対象をシミュレーションするために実施される。たとえばモデリング課題が「ファミリーレストラン」であれば、ファミリーレストランをコンピュータ上で動作させるための準備として、オブジェクトモデルは作られる。 シミュレーションすることにも何らかの目的がある。たとえばそれは「従業員の役割に応じた作業と効率の決定」のためなのかもしれない。そういった意図にしたがって現実が解釈され、モデルに反映される。たとえば客やウェイトレスといった要素が組み込まれつつも、客のモンスター度だのウェイトレスの美人度といった属性が捨象されたりする。ようするにオブジェクト・モデラーは、なんらかの意図にしたがって対象を抽象化しながらも「写生」しようと