超高速開発ではなく「超少人数開発」を - 設計者の発言
「超高速開発コミュニティ」が発足した。私も機会を見て参加したいと考えているのだが、それにしても「超高速開発」のキーワードは誤解を招きそうではある。その種のツールを使えば工期が半分とか３分の１になる――そのように勘違いされて導入すれば、ツールメーカーにとってもツールユーザー（開発者）にとっても残念なことになるだろう。 開発経験者はわかっているが、システム開発における律速過程は「実装」ではなく「実装されるべき仕様の確立」にある。そして、「統一感があって、有用かつフィージビリティ（実現可能性）が担保された仕様」を確立できさえすれば、どんな実装ツールを使おうがシステムはおおかた無難に完成するものだ。けっきょく「あるべき仕様がなかなか固まらない」点こそが、開発プロジェクトの慢性的な悩みのタネであって、この事実の前では「超高速に実装できる」ことの効果は案に相違して限定的なのである。 このことはドラえも
モデル駆動(MDA)から仕様書駆動(SDA)へ - 設計者の発言
■何がMDAを殺したのか 期待されたわりにあっけなく消えてしまった技術用語は数多いが、そのひとつとして「モデル駆動アーキテクチャ(MDA,Model Driven Architecture)」を取り上げよう。ソフトウエアのあり方を「モデル」としてまとめ、これにもとづいて開発作業を合理化するための枠組みのことをいう。考え方としては昔からあったが、オブジェクト指向技術の標準化団体であるOMGによって2001年に体系化された。当時は注目されたものだが、今ではすっかり聞かれなくなった。 なぜか。MDAを実現させるための自由な発展を「UML」が邪魔したため――そう私はにらんでいる。 じっさいは、MDAにおいてUMLの利用が強制されているわけではない。しかし、なにしろOMGによって提唱された枠組みなので、UMLの利用が前提と理解されたのは自然の成り行きだった。ちょうどその頃は、この表記体系がソフトウエ
サロゲートキーと「とりあえずID」の違い - 設計者の発言
サロゲートキー（代理キー）は慎重になされる限り、有用なテクニックである。いっぽう、すべてのテーブルに機械的にIDを置く「とりあえずID（IDリクワイアド）」の設計スタイルでは、複雑なデータ要件を扱った途端にひどい目にあう（とくに保守担当者が）。両者の違いをしっかり理解しておこう。 何でもいいのだが、ここでは生産管理システムで見かけそうなシンプルなモデルを使って説明しよう（図１）。「作業区・品目」は、それぞれの作業区で生産可能な品目の組み合わせと、その品目を扱った際の生産性（時間あたり生産数）の管理簿である。 ＜図１＞ [工程]工程id,工程名,扱い単位 ＋ ￣￣￣ ｜ 001 切削 個 ｜ 002 加工 ｍ ｜ └―∈[作業区]工程id,行番,作業区名,標準生産性 ＋ ￣￣￣￣￣￣ ｜ 001 01 切削１号 1000/hr ｜ 001 02 切削２号 2
もう「チーム開発」には戻れない - 設計者の発言
生産管理システムをひとりで開発しているわけだが、このやり方（おひとりさま開発）に慣れると、分業体制でのチーム開発がいかに非効率だったかがよくわかる。チーム開発は「設計・実装技術の未成熟さゆえの必要悪」だったのではないかとさえ思えてきて、仲間と和気藹々とやっていた昔の自分がなんだか恥ずかしい。 たとえば、いくらしっかり設計してもどうしても仕様変更が起こるものだが、これにともなう手戻りコストがチーム開発では想像以上にかさむ。自分で修正したほうが早いと思いつつ、変更作業のための指示を他人のためにまとめたりする。また、実装担当者の稼働率を上げるために、仕様がまだ不明確であるような機能をあえてあてがったりする。今となっては信じがたいほどの非効率だ。 また、自分で作って動かしてみなければ得られない気づきやアイデアがたくさんあるのだが、チーム開発では設計担当と実装担当が分かれていることが多い。それゆえ、
Excel方眼紙がダメな２つの理由 - 設計者の発言
悪名高い「Excel方眼紙」について、「そうそう。あのやり方は最悪だ。まだWordのほうがいい。なぜなら」なんて議論が始まったりすると残念過ぎて泣けてくる。ExcelやWordを使って仕様書を書くことの問題を、改めてはっきりさせておきたい。 私の言う「Excel方眼紙」はいくぶん象徴的な言い方である。正確に言えば、Excelを使って仕様書を書くことそのものが間違っているわけではない。Excelで書かれた仕様書の内容にもとづく「自動生成」や「動的制御」を実現しているのであれば、それはまともな職場といっていい。 そのような合理化を模索しようとせず、ExcelやWordやパワポやネット上の文書作成ツールあたりを使って仕様書を書いて、さらに別途プログラミングをやっているとすれば、大いにカイゼンの余地がある。あまりに生産性が低いし、仕様書とコードが分離しているゆえに遅かれ早かれ両者の整合性が失われる
続・仕様書でシステムが動く時代へ - 設計者の発言
前回の「プログラム仕様書の編集パネル」に続いて「XEAD Application Editor（以下、Editor）」の「テーブル仕様書の編集パネル」を紹介しよう。テーブル定義は、単純なcreate table文によるメタ情報を核にして、そのまわりを拡張定義が取り囲んだような形をしている。 これをEditorで編集している様子が図１だ。テーブル「商品」に含まれるフィールド「外観」の拡張属性として「画像ファイル」が指定されている。これによって、フィールド値が画像ファイル名とみなされるようになる。つまり、機能が実行されてテーブルからこのフィールドが読み込まれた際には、規定のフォルダからその名前のイメージファイルが探索され、パネル上に表示される。 テーブル定義に含まれる要素としてこの他に紹介したいものが「スクリプト」だ（図２）。テーブル操作のいろいろなタイミングで指定のスクリプトを実行できるよう
酸素濃度と進化爆発と技術革新 - 設計者の発言
大気の酸素濃度は、地球史においてダイナミックに変化してきた。現在は２１％だが、２２億年ほど前は数％しかなかった。３５億年ほど前にある種のバクテリアが光合成を発明して以来、酸素濃度は次第に高まっていったが、酸素濃度が現在のレベルになるまでには紆余曲折があった。現在より高い時期もあって、シルル紀には２５％、ペルム紀初期にはなんと３４％に達していた。 地球生命史において何度か「進化爆発」が起こった。「進化爆発」とは、「カンブリア大爆発」を好例として、短い期間に「種」どころか「門」のレベルの多様な生物が現れる不思議な現象のことだ。最近の研究で、酸素濃度が低めの時代に、進化爆発が起こるという相関があることがわかってきた。それも酸素濃度が数ポイント変動するだけで、大きな変化が起こるようなのだ。 これをどう解釈したらよいのだろう。酸素を効率的に取り入れることは、生物の基本設計における重大要件である。酸素
「個別案件」ではプログラミングの可能性を生かせない - 設計者の発言
ソフト開発企業に所属するプログラマが十年一日のように「個別案件」を相手にしているというのは、マイケル･ジャクソンが盛り場あたりで毎晩「流し」で日銭を稼いでいるようなものだ。もったいない。そんなやり方ではマイケルやプログラミングの可能性がもたらすさまざまな効果を享受できない。 仮にあるソフト会社が「ロボットの振る舞いのカスタマイズサービス」を提供しているとしよう。顧客の要望がそれぞれ微妙に違うとすれば、彼らはまず個々の要望を様式化して、その内容をあるソフトウエアに読ませるだろう。そうすればそのソフトウエアが個々の要望にしたがってロボットを動かしてくれるからだ。そんなソフトウエア、すなわち「ハードウエアドライバ」をあらかじめプログラミングしておくのが、その事業で効率的に稼いでゆくための賢いやり方というものだ。 ところが、現在の「基幹業務支援システム開発事業」の分野では、あらかじめドライバをプロ
システム業界向け「モデルハウス」開発快調 - 設計者の発言
持ち家を欲しいと考えた人は、たいていモデルハウス巡りをする。その過程で、曖昧だった家のデザインや予算もはっきりしてゆく。依頼すべき業者も決まってくる。顧客が満足できる家を手に入れるために欠かせないもの、それがモデルハウスだ。 ところが、システム業界にはモデルハウスに相当するものがない。簡単にダウンロードできて、簡単にインストールできて、いきなり動かせる業務システムがない。これはおかしい。その異常さを理解するためには、モデルハウスのない住宅建設がどんなふうになるかを考えてみたらよい。たとえばこんな風だったりするのだろう。 持ち家を欲しいと考えたある若夫婦が住宅建設会社にやってくる。担当営業は「わが社はお客さまの持ち家に対する要求をモデリングして、わかりやすくフィードバックします」と言う。何だかわかりにくい言い方をするなといぶかりつつも夫婦が了承すると、数日後、彼らのもとにひとりの技術者が現れ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
