自作の開発ツールであるXEAD Driverをデモすると、「ブラウザベースではないんですね」と言われることがある。ブラウザアプリ全盛のご時勢だ。業務システムをデスクトップアプリとして立ち上げるXEAD Driverに違和感を覚える技術者もいるかもしれない。しかし、デスクトップアプリが業務システムに向かないとみなす理由は今はない。 ブラウザアプリとして開発することの意義として「配布容易性」が筆頭に挙げられる。ブラウザがあればどこでも使えるのは大きな利点である。しかし、デスクトップアプリの配布容易性も、JWS(Java Web Start)や.NETのClickOnceなどの自動配布技術のおかげで遜色はなくなった。ブラウザアプリは規定のブラウザでなければ使えないが、自動配布技術にはそんな制約がない点も魅力的だ。 いっぽう、デスクトップアプリの魅力は「操作性」である。かつてのブラウザベースの業務

大震災から１年たったが、この間に職業上考えさせられたのは自治体システムのことだ。３年ほど前にその基本設計情報「ＣＯＮＣＥＰＴＷＡＲＥ／自治体」をまとめて未完成のまま公開したのだが、あることに気づいて更新をやめてしまっていた。何に気づいたかというと、「住基ネット（住民基本台帳ネットワークシステム）の機能を包含する自治体システムが日本にたった１個あればいい」ということだ。全自治体がそれを使いさえすれば、いろいろな無駄や不便が霧散解消する。震災後にそのことをあらためて痛感させられた。 住基ネットの機能を包含した形の自治体システム――その何がうれしいのか。それは多重化されたサーバ上にあって、全自治体の職員が使う。ふだんは自分たちのセグメントにログインして仕事をするが、災害などの非常時には必要に応じて他自治体向けのセグメントにログインして、そこの住民向けの事務処理を代行する（これを職権代行と呼ぼう）

企業システムには次図で示すような基本構造がある。実際のシステムは固有の経緯にもとづく物理構造をとるが、それを「基本構造からの逸脱」として理解することで特性を把握しやすくなる。システムの統合や刷新といったさまざまな文脈でも役立つ知識なので、理解しておこう。 含まれている５つのモジュール(a,b,c,d,e)を説明しよう。まず、共通データ管理(a)のモジュールでは、企業システム全体で共有されるべきＤＢが管理される。企業名や住所、ユーザ、取引先、消費税率といった企業システム全体で利用される情報がそれには含まれる。 営業管理(b)はいわゆる「基幹システム」と呼ばれるモジュールだ。売上・仕入・在庫といった営業活動にともなう会計情報がここで管理される。業種毎に大きく変わる部分で、製造業では「生産管理システム」、金融・保険業では「契約管理システム」などと呼ばれる。売掛金に対する入金、買掛金に対する出金に

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

４ＧＬ（第四世代言語。既に死語）を使っていた頃に「ソースコードが仕様書だ」と言い張っていたことがある。テーブル操作コマンドと統合されているそのプログラミング言語を使えば、じっさい英語の文章のように明解にコーディングできた。しかしそんな強力な言語を前提にしても、今から考えれば「コードが仕様書だ」と主張したのは間違いだった。 理由は単純。仕様書として通用するほどキレイにコーディングが可能と謳われている言語を使ったとしても、コーディングがキレイになることが「保証」されているわけではないからだ。まあ当然のことで、文章の読みやすさが書き手によってまるで違うのと同様、コードの読みやすさはプログラマによってまるで違う（その日の気分や体調によっても違うかもしれない）。いかに標準化を徹底しようが、同じ動きをするのにいっぽうは読みやすくいっぽうはわけがわからないなんて事態は日常的に起こる。そして、システム開発

「自動生成」に魅せられるソフトウエア技術者は少なくない。欲しいプログラムの仕様を、それぞれに工夫した言語や表形式や図面の形で定義して、それをもとにソースコードを自動生成する。これをコンパイルするだけで（スクリプト言語であればコンパイルなしで）プログラムが完成する。そんな桃源郷を夢見て多くの技術者が情熱を傾けてきた。 ＵＭＬベースのＭＤＡをはじめとして、いろいろなスタイルの自動生成のしくみが考案されたが、生成されたコードの編集を許すか許さないかが肝心の問題になった。編集を許すと、コードから定義を逆生成することが困難なので、中途半端な「コードテンプレート機能」や「コード補完機能」と違いがなくなる。かといって編集を許さないと、仕様の自由度が損なわれる。編集を禁止したままで仕様の自由度を高めようとすれば、しくみの複雑さが増して、教育コストや維持費がかさむようになる。あっち立てればこちらが立たないと

大気の酸素濃度は、地球史においてダイナミックに変化してきた。現在は２１％だが、２２億年ほど前は数％しかなかった。３５億年ほど前にある種のバクテリアが光合成を発明して以来、酸素濃度は次第に高まっていったが、酸素濃度が現在のレベルになるまでには紆余曲折があった。現在より高い時期もあって、シルル紀には２５％、ペルム紀初期にはなんと３４％に達していた。 地球生命史において何度か「進化爆発」が起こった。「進化爆発」とは、「カンブリア大爆発」を好例として、短い期間に「種」どころか「門」のレベルの多様な生物が現れる不思議な現象のことだ。最近の研究で、酸素濃度が低めの時代に、進化爆発が起こるという相関があることがわかってきた。それも酸素濃度が数ポイント変動するだけで、大きな変化が起こるようなのだ。 これをどう解釈したらよいのだろう。酸素を効率的に取り入れることは、生物の基本設計における重大要件である。酸素

「ＣＯＮＣＥＰＷＡＲＥ／販売管理」の実装版といっしょに実装用のフレームワークも開発しているのだが、その過程でオブジェクト指向の威力にあらためて感じ入っている。適切なクラスを導入することでソフトウエアの内部構造がエレガントになる。アルゴリズムを考えるのも楽しいが、クラス構造を考えることにも独特な楽しさがあって、歩きながら考え込んでコケそうになるくらいだ。実装用フレームワークのような複雑なソフトウエアを組み立てる際に、オブジェクト指向は欠かせない。 オブジェクト指向を駆使しつつプログラミングしていて、フレームワークがオブジェクト指向を「隠蔽」するという逆説的な方向性を持っていることに気づいた。 筆者が開発しているフレームワークは、生産管理システムや販売管理システムといった企業向け基幹システム、いわゆる「業務システム」向けのものだ。したがって、フレームワーク内部のクラス構造は、「業務システムにお

データモデリングでは、複合キーに代わって単一項目の代理キー（サロゲートキー）を導入することがある。これは「モデリング上のテクニックのひとつ」ではあるが「モデリングのスタイル（基本方針）」とみなすべきではない。その根拠を説明しよう。 まず、倉庫が複数あるとして、倉庫にはさまざまな商品が保管されるとする。それぞれの商品は倉庫毎の特定の棚に保管される（つまり、商品と倉庫の組み合わせで棚が決まる）ことになっているとする（在庫管理では典型的な業務要件だ）。この関係をデータモデルで表すとモデル１のようになる。横浜第１倉庫でA01の棚に保管されることになっている商品１００の現在庫が２５０個であることが示されている。 このモデルをサロゲートキーにこだわって変形するとモデル２のようになる。 ２つのモデルの形式上の違いはどこにあるのだろう。モデル１では、倉庫コード、棚記号、品番が一次識別子として置かれているゆ

職業選択に関して「やっていて楽しいことや得意なことを仕事にしたらいい」とよく言われるが、この助言は実際にはほとんど役に立たない。消費者を楽しませて稼ぐ商売が山ほどあるおかげで、楽しいことは多すぎるくらいだ。そのいっぽうで、自分が得意と思えることをもっと上手にこなす人々がいくらでもいることが簡単にわかってしまう時代でもある。だいいち、社会は想像以上に多様な職業にあふれていて、自分が得意かどうか、やって楽しいかどうかをそれらのすべての分野で試すなんてできっこない。 むしろ「不快感」の中にこそ、それぞれの個性に応じた職業適性は見出しやすいのではないだろうか。「ああ、なんで他の人たちはこれにガマンできるんだろう」と思えるようなら、そこに職業適性の核があるかもしれない。 ◆不快感は「心地よいものを生み出す能力」に先行する 一般に、何らかの「心地よさへのこだわり」は「心地よさの欠如に対する不快感を感じ