基本設計を分担してはいけない - 設計者の発言
プロジェクトメンバーが無駄に多いのが、日本型SIの特徴のひとつである。「工数を人数で割れば工期が出る」と考えることが間違いであることは、ブルックスの著書「人月の神話」によって今から40年前に指摘されている。それにもかかわらず、相変わらず多くのプロジェクトで必要以上の人数が投入されている。 私がとくに不思議に思うのが、基本設計を何人もの要員で分担するやり方だ。DB設計と機能設計と業務設計の担当を分けるとか、サブシステム毎に担当を分けるといった体制がしばしば敷かれる。詳細設計の段階でというのならまだわかるが、基本設計でそれをやってはいけない。 なぜか。業務システムにはアーキテクチャ（意図された構造）が求められる。そして、そこに含まれる膨大な定義要素は、統一感や一貫性を保ち、かつMECEな形で切り出されなければいけない。複数の要員で分担などすれば、それらの課題が一挙に難しくなる。また、DB構成と
ボトルネックは「業務系スキル」 - 設計者の発言
私は業務システムというものが好きだ。売上そのものを生み出すしくみではないので派手さはないが、経営効率を高めるための縁の下の力持ちのような奥ゆかしさがある。そして、日本企業の特質である「顧客のわがままに柔軟に応える姿勢」を貫くための鍵が、他でもない業務システムである。効果的な業務システムをいかに効率的に設計・実装するか。それを考えたり実践することが楽しくてしょうがない。 この分野にも固有の専門性がある。まず必要なスキルは、業務連係やデータベースの設計技術、そしてシステム構成と統合された会計知識だ。適性としては、論理的な思考力や人並み以上の言語能力が求められる。これらの技能を合わせて「業務系スキル」と呼んでおくが、その重要さは実装手段が変わっても揺るがない。 ところが、開発を専業とする組織における業務系スキルの空洞化が著しい。じっさい今になって営業担当者があわてている。長い不況を抜けてやっと業
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
Excel方眼紙がダメな２つの理由 - 設計者の発言
悪名高い「Excel方眼紙」について、「そうそう。あのやり方は最悪だ。まだWordのほうがいい。なぜなら」なんて議論が始まったりすると残念過ぎて泣けてくる。ExcelやWordを使って仕様書を書くことの問題を、改めてはっきりさせておきたい。 私の言う「Excel方眼紙」はいくぶん象徴的な言い方である。正確に言えば、Excelを使って仕様書を書くことそのものが間違っているわけではない。Excelで書かれた仕様書の内容にもとづく「自動生成」や「動的制御」を実現しているのであれば、それはまともな職場といっていい。 そのような合理化を模索しようとせず、ExcelやWordやパワポやネット上の文書作成ツールあたりを使って仕様書を書いて、さらに別途プログラミングをやっているとすれば、大いにカイゼンの余地がある。あまりに生産性が低いし、仕様書とコードが分離しているゆえに遅かれ早かれ両者の整合性が失われる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
