基本設計を分担してはいけない - 設計者の発言
プロジェクトメンバーが無駄に多いのが、日本型SIの特徴のひとつである。「工数を人数で割れば工期が出る」と考えることが間違いであることは、ブルックスの著書「人月の神話」によって今から40年前に指摘されている。それにもかかわらず、相変わらず多くのプロジェクトで必要以上の人数が投入されている。 私がとくに不思議に思うのが、基本設計を何人もの要員で分担するやり方だ。DB設計と機能設計と業務設計の担当を分けるとか、サブシステム毎に担当を分けるといった体制がしばしば敷かれる。詳細設計の段階でというのならまだわかるが、基本設計でそれをやってはいけない。 なぜか。業務システムにはアーキテクチャ（意図された構造）が求められる。そして、そこに含まれる膨大な定義要素は、統一感や一貫性を保ち、かつMECEな形で切り出されなければいけない。複数の要員で分担などすれば、それらの課題が一挙に難しくなる。また、DB構成と
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
サロゲートキーと「とりあえずID」の違い - 設計者の発言
サロゲートキー（代理キー）は慎重になされる限り、有用なテクニックである。いっぽう、すべてのテーブルに機械的にIDを置く「とりあえずID（IDリクワイアド）」の設計スタイルでは、複雑なデータ要件を扱った途端にひどい目にあう（とくに保守担当者が）。両者の違いをしっかり理解しておこう。 何でもいいのだが、ここでは生産管理システムで見かけそうなシンプルなモデルを使って説明しよう（図１）。「作業区・品目」は、それぞれの作業区で生産可能な品目の組み合わせと、その品目を扱った際の生産性（時間あたり生産数）の管理簿である。 ＜図１＞ [工程]工程id,工程名,扱い単位 ＋ ￣￣￣ ｜ 001 切削 個 ｜ 002 加工 ｍ ｜ └―∈[作業区]工程id,行番,作業区名,標準生産性 ＋ ￣￣￣￣￣￣ ｜ 001 01 切削１号 1000/hr ｜ 001 02 切削２号 2
「業務マニュアル」と「操作マニュアル」の違い - 設計者の発言
「ユーザマニュアル」という言い方があるが、業務システム開発の文脈でこの表現は使わないほうがいい。「ユーザマニュアルを作りなさい」では、「操作マニュアルを作りなさい」なのか「業務マニュアルを作りなさい」なのか判然としないからだ。いずれも重要な設計要素ではあるが、内容も目的も異なっている。 まず「操作マニュアル」とは、パネルやページの操作方法を説明したものだ。たとえば「パネルＡが表示されたなら、ボタンＢを押してください。するとデータが一覧されるので、一覧のいずれかを選択状態にしてエンターキーを押せば、続くパネルＣが表示されます」といった説明は「操作マニュアル」にありそうな記述だ。文章だけでなく、関連するスクリーンショットを伴うことが多い。 いっぽう「業務マニュアル」とは、文字通り「個々の業務の説明書」のことである。ここで言う「業務」とは、「受注登録業務」や「出荷指示業務」や「実棚報告業務」とい
取引実績テーブルの設計と仕訳 - 設計者の発言
売掛や買掛や在庫に関する取引が起こると残高が更新される。同時に残高の変動に応じた取引実績が記録され、会計上の基礎情報となる。すなわち、取引実績が「仕訳」の元ネタとなる。ここらへんの事情が完全に理解されていないと、業務システムの設計は務まらない。ましてや「アジャイル開発」など無謀だ。 簡単な例で取引実績データと仕訳の関係を眺めながら、取引実績テーブルをどのように設計したらよいかを考えてみよう。 仕入先から商品が100個入荷した。商品単価が100円で、関税やら諸掛やらで合わせて1,000円かかったとしよう。仕入にかかった費用を商品の原価に参入するとすれば、仕訳は次のようになる。 商品 11,000／買掛金 10,000 仕入諸掛 1,000 入荷情報が何らかのトランザクションテーブル（入荷明細テーブルとしよう）に記録され、同時に仕入実績と受払実績データが生成される。それらを保持するためのテー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
