「データモデルなきアジャイル」の危うさ - 設計者の発言
例によってこれは「業務システム」に関する議論である。ゲームソフトでも組込み系でもＢ２Ｃサイトでもサービス系でもなく、販売管理システムや生産管理システムといった基幹系業務支援システム（ＤＢ構造が複雑なシステムといってもいい）に限った話だ。その種のシステムをアジャイル開発しようと考えるのであれば、それまでにシステム全体の「あるべきデータモデル」が確立されていなければならない。 業務システムを「身体」に喩えるなら、データモデルは「骨格の設計図」に相当する。いっぽうアジャイル開発で導き出せるのは身体の表面上の諸問題、すなわち「皮膚のぐあい」とか「顔つき」のようなものだ。そういった特徴についていかに緻密に決定できても、それらから「あるべき骨格の姿」は導けない。 ＤＢ構造のそういった特性を公知させたのが、前回記事で説明した「ＤＯＡ（データ中心アプローチ）」だった。機能のあり方を確立したうえでデータのあ
「ドメイン駆動開発」への素朴な疑問 - 設計者の発言
半年ほど前「ドメインモデル」の考え方を調べるうちに、masuda220氏の「システム設計日記」にたどりついた。「Domain-Driven Design」(Eric Evans著, 2003)の精読を通じてドメイン駆動開発の意味や意義を検討している読み応えのあるブログである。興味をもって４月にmasuda220氏に直接会ってお話を伺うことができた。おかげでようやくこの考え方を理解できた（ような気になっただけなので、間違った理解をしているとしたら私の責任である）。同時に、以前からドメインモデルに対して抱いていた疑問もより明確になった。 「ドメインモデル」の「ドメイン」とは、ソフトウエアが支援する「個々の現実」を指す。その現実に含まれる用語を用いて、ソフトウエアに含まれる変数やクラスやメソッドを命名して組み立てた場合、その体系は「ドメインモデル」と呼ばれる。設計成果物も実装成果物も、出来上がる
クラウドと基幹システム - 設計者の発言
「猫も杓子もクラウド」のご時勢だが、どうも腑に落ちないことがある。クラウドというのは要するに「部屋を借りるのも安いし、必要に応じて部屋の大きさが拡張します」という話である。それはそれで気が利いていると思う。しかし、そもそもその「部屋」を誰が作るのか。 「作る必要はありません。クラウドベンダーによって提供され、保守されます」 ほほぅと感心しつつ調べてみると、見積書と納品書あたりを発行するためだけの「販売管理システム（！）」とかＥＣサイトのような単機能モジュールは見つかる。いわば「会議室」とか「展示会用ホール」とか「小売用店舗」みたいな特定用途向けの部屋だ。そういうものではなく、事業を進めるための統合事務処理環境、つまり「基幹システム」はどうなっているのか。 「ＳＯＡですよ。ご存知ありません？クラウド上で提供されているサービスを自由に組み合わせることで、基幹システムだろうとお望みのものが手に入
サブシステムを「使い捨てる」ためのアーキテクチャ - 設計者の発言
友人から、最近の「薬品卸売業界」の話を聞いた。知られているように、規制緩和によって一部の薬がコンビニや電器量販店でも扱えるようになった。そうすると薬品卸売業としては、多様な販売先に対応したきめ細かい受注・出荷体制や棚割ノウハウの提供が求められるようになる。ところが、規制緩和したからといって国民がいきなり市販薬をより多く買うようになるわけではない。結果的に、新しいタイプの顧客からの売上が増えるいっぽうで、その分だけ既顧客からの売上は減る。 その業界で生き延びてきた企業の多くは、販売管理システムを手作りすることでサービスレベルの向上をはかってきた。この経営方針は「サービスレベルを向上させつつ物流コストを抑えるためには、システムを手作りしたほうがまだトータルのコストを抑えられる」という経済合理性にもとづいている。しかし、この方針は売上高が右肩上がりで増大することを前提としている。より多様な顧客へ
妥当性検査をＤＢ側に集約する - 設計者の発言
テーブルフィールドの妥当性検査をどこに配置するかは、ＤＢシステムの開発において重要な問題である。大別してプログラム側に置く流儀とＤＢ側に置く流儀とがあるが、基本的に後者が正しい。 なぜなら、どのプログラムで実行されるかに関わらず同じ検査がなされるとしたら、その仕様はフィールド固有の属性とみなされるからだ。たとえそのフィールドに対する妥当性検査を実行するプログラムが１個しかないとしても、そのように考えるべきである。フィールド固有の属性については、テーブル側の定義情報を読めばひととおりわかるようでなければいけない。以前にも書いたように「カエサルのものはカエサルへ、ＤＢのものはＤＢへ」の原則で、フィールドの扱われ方に関する仕様はテーブル上に集約したほうがよい。 では次のような妥当性検査があったらどうだろう。「テーブルＡ上の関連レコードのフィールドＢの値がナントカの場合、テーブルＣ上のフィールドＤ
少人数開発と「能力プール」 - 設計者の発言
■少人数プロジェクトが儲かる理由 開発案件の最終利益率とプロジェクトメンバー数には一定の相関がある。開発に関わったメンバーの数が少ないほど、一般に利益率は高い。実際に数字で調べてみたわけではないが、筆者の過去の経験からも確信できるし、そのように思い当たる人も多いだろう。 その理由は単純である。メンバーが多いほど、メンバー間の情報伝達のためのコスト（情報コスト）が飛躍的に増えるためだ。指示やいわゆるホウレンソウのための初期コストだけでなく、訂正や伝達ミスにともなうさまざまな後追いコストが、人数の多いプロジェクトほど大きくなる。メンバーが２人のときに情報コストが１だとすれば、（１人のときなら０）、人数に従って次のようにコストは増えてゆく。 ２人 １ ３人 ３ ４人 ６ ５人 １０ ： ： ｎ人 n(n-1)/2 たとえこの事実が理解されていたとしても、これらのコストを考慮して工数積み上
ユーザがなかなか仕様を決めてくれないって？ - 設計者の発言
「ユーザがなかなか仕様を決めてくれないんです」という悩みをじつによく聞く。検討の過程で明確にされたいくつかの選択肢があって、ユーザに決断力がないゆえに決めきれていないとすれば、確かに困ったものだと思う。しかし「ユーザがどんなシステムにしたいかをなかなか明確に語ってくれない」といったレベルの悩みなのであれば、問題はどちらかといえば設計者の側にある。 ◆デートの過ごし方を決める過程 休日のデートの過ごし方に関して男性から尋ねられて、事細かに意向を説明してくれる女性はどちらかといえば少ない。たいていは「うーん、いい景色を見て、なにか美味しいものを何か食べたいな」なんて曖昧な答えが返ってくる。そのときに彼は「イイケシキだのナニカオイシイモノなんて曖昧な言い方をされてもわからない。もっと具体的に説明してくれないか」なんて言うだろうか。 そんなことを言う男がいるとすれば、彼女のいぶかる様子に気づくこと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
