業者の設計スキルをハダカにする - 設計者の発言
システム刷新に失敗する理由のひとつが、ユーザ企業が業者の設計スキルを吟味せずに一括請負契約を結んでしまう点にある。彼らに委託すると、実際には下請業者が設計していたりする。多くの業者が多かれ少なかれゼネコン化しているため、設計スキルが空洞化しているためだ。下請業者に的確な設計が出来ないとは限らないが、起用される設計者のスキルレベルを発注者がコントロールできないという意味で、リスクが大き過ぎる。 そもそも「システム刷新に失敗した」とはどういうことか。ユーザ企業自身が想定するコスト感やスピード感でシステムを改善・発展させられなくなっているのであれば、失敗したと判断していい。少しばかり改修しようとしても、無駄に複雑な設計を掌握している開発業者の意向に振り回される。そんな業務システムの命運は業者に握られていて、これはもう経営権の一部を奪われているのと変わらない。そんな事例は少なくない。 なぜそういう
ER図レビューの３つのポイント - 設計者の発言
前回記事で、業務システム開発の上流工程でDB設計がないがしろにされるケースがあると指摘したが、よほど低レベルな職場でない限り、今では上流工程でのER図の作成が標準化されるようになっている。 ところが、そのER図がまるでショボいにも関わらずレビューで承認されるケースがあとを絶たない。理由は単純で、ER図があるかどうかだけがチェックされて、内容レベルの検証がなされていないためだ。それはとりもなおさず、DB設計を的確にレビューできる技術者がいないためでもある。 ER図を見れば、プロジェクトが成功するかどうかまではわからないかもしれないが、「デスマーチ化するかどうか」はわかる。それほど便利な図面が提出されながらレビュワーのスキルが足りないのでは、設計標準の持ち腐れというものだ。 そこで、ER図を効果的にレビューするためのポイントを紹介したい。構成的な心地よさがあるか、キー構成が単純すぎないか、創意
「オブジェクト指向」や「アジャイル」では食えない - 設計者の発言
技術で安定的に稼ぐためには、どんな「専門性」を核に据えるかがカギである。その選定に失敗すれば、貴重な現役時代の１０年くらい簡単に無駄使いしてしまう。これを避けるためには、自分の専門性がターゲットとする「市場」をよくよく見定めておく必要がある。 先日、ある超高速開発ツールを活用している技術者の語りを聴く機会があった。彼は最初にハードウエアの設計技術者としてあるメーカーに入社したのだが、そこで製造管理を強化するために独力で生産管理システムを設計・実装してしまった。この経験を生かしてその後ソフトウエア技術者に転身し、ユーザ企業のシステム部門を渡り歩いてきた。現在所属しているメーカーでは、彼のおかげでシステム部門のプレゼンスが高まって感謝されているという。キャリア経験の中から「自分と家族を食わせてゆくための源泉」を見つけ維持している立派な技術者だと感心させられた。 特定の超高速開発ツールを利用して
基本設計を分担してはいけない - 設計者の発言
プロジェクトメンバーが無駄に多いのが、日本型SIの特徴のひとつである。「工数を人数で割れば工期が出る」と考えることが間違いであることは、ブルックスの著書「人月の神話」によって今から40年前に指摘されている。それにもかかわらず、相変わらず多くのプロジェクトで必要以上の人数が投入されている。 私がとくに不思議に思うのが、基本設計を何人もの要員で分担するやり方だ。DB設計と機能設計と業務設計の担当を分けるとか、サブシステム毎に担当を分けるといった体制がしばしば敷かれる。詳細設計の段階でというのならまだわかるが、基本設計でそれをやってはいけない。 なぜか。業務システムにはアーキテクチャ（意図された構造）が求められる。そして、そこに含まれる膨大な定義要素は、統一感や一貫性を保ち、かつMECEな形で切り出されなければいけない。複数の要員で分担などすれば、それらの課題が一挙に難しくなる。また、DB構成と
自由であるためにドキュメントを作る - 設計者の発言
前回記事で、ドキュメンテーションを重要視しない開発業者を避けるべきだと指摘した。同様の問題は、業務システムを内製した場合にも生じている。むしろ、ドキュメントレスな困ったシステムは、内製で生み出されているケースのほうが多いような印象が私にはある。 ドキュメントレスなシステムが重大なリスクを抱えていることを、ほとんどの経営者は認識していない。なぜなら、ドキュメントレスであってもシステムのあり方は内製担当者の「頭の中」に入っているので、彼に頼めば必要な改修はやってもらえるからだ。結果的に業務システムが、担当者のエンプロイアビリティ（雇用意義）を強化するための政治的ユーティリティと化すことを許してしまう。その歪みは、担当者がいなくなったときに一挙に顕在化する。いなくなった当人としては「後は野となれ山となれ」である。 業務システムがドキュメントレスになりがちな根本的な理由は、まさにここらへんにある。
エンタープライズ・アジャイル：手法論より大事なもの - 設計者の発言
最近耳にするようになった言葉に「エンタープライズ・アジャイル」というものがある。業務システム（販売管理や生産管理といった大規模な基幹システムのこと）をアジャイル開発するやり方を意味する。そのためにSAFe(Scaled Agile Framework)やDAD(Disciplined Agile Delivery)といった洗練された枠組みが提唱されているが、次から次に登場するこの種の手法論が問題を解決してくれるとは私には思えない。 「エンタープライズ・アジャイル」とことさらに「エンタープライズ」を強調するのは、それまでのアジャイル手法が業務システム開発にうまく適用できていないことを物語っている。じっさい、業務システムとアジャイル手法は水と油みたいなところがあって、業務システムの以下の特性ゆえにアジャイル手法の適用は簡単ではない。 特性１：ドキュメントが必要 複雑巨大な業務システムの可読性や
データ指向設計・開発の実践 - 設計者の発言
経験豊かな開発者は知っているが、業務システムというものは「データの扱いに関するこまごました制約の塊」のようなところがある。したがって、データ毎のステータス遷移やそれに伴う制約を丹念に整理するとともに、それらを効果的に実装することを考えなければいけない。そのためには「アプリ指向」ではなく「データ指向」な開発方針を取り入れる必要がある。現在開発中の「受注生産システム」から「製造指示」をとりあげて説明しよう。 まず、製造指示まわりのデータモデルを確認しよう。製造指示(JT010)を完遂させるためには、仕様明細(JT020)、工程明細(JT030)、材料明細(JT040)といった関連情報を管理する必要がある。それらのデータは、製造指示が追加される際に各種のマスターにもとづいてセットアップされる。 製造指示まわりのデータモデル 製造指示のステータス（製造状況）遷移を見よう。新規登録すると「未発行」と
「ドメイン・エキスパート」になろう - 設計者の発言
２０年も昔の話だが、「英語できます」という本を読んで考え込まされたことがある。どんな仕事で稼ぐにせよ、何らかの専門性が要る。英語力というものは、そんな「専門性の効用」を引き上げるためのツール以上のものではない。むしろ中途半端に英語力があったばかりに専門性を深める努力を怠って、英語力を社会で生かせていない。そんな事例がいくつも紹介されていた。 この話、ソフト開発の技能に関してもいえるのではないだろうか。技術が進歩すればするほど開発の技能はコモディティ化し、これを習得しているだけでは大した意味はなくなる。ソフト開発の技能を社会で生かすためには、互いの効用をレバレッジするような何らかの「専門性」が要る。 これは、開発者自身がまず何らかの「ドメイン・エキスパート」であるべしという話に他ならない。ドメイン・エキスパートとは、DDD（ドメイン駆動設計）で言うところの、開発されるソフトウエアの適用分野（
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
オブジェクトモデリングとデータモデリング - 設計者の発言
オブジェクトモデリングとデータモデリングはどこが違うのだろう。クラス図やER図といった成果物を比較するだけではわからない本質的な違いが両者にはある。 オブジェクトモデリングは基本的に、対象をシミュレーションするために実施される。たとえばモデリング課題が「ファミリーレストラン」であれば、ファミリーレストランをコンピュータ上で動作させるための準備として、オブジェクトモデルは作られる。 シミュレーションすることにも何らかの目的がある。たとえばそれは「従業員の役割に応じた作業と効率の決定」のためなのかもしれない。そういった意図にしたがって現実が解釈され、モデルに反映される。たとえば客やウェイトレスといった要素が組み込まれつつも、客のモンスター度だのウェイトレスの美人度といった属性が捨象されたりする。ようするにオブジェクト・モデラーは、なんらかの意図にしたがって対象を抽象化しながらも「写生」しようと
アジャイル手法は分野毎に違っていい - 設計者の発言
業務システムをいかにアジャイルに開発するか。それが私の長年の研究テーマだった。最終的にたどりついた答は「モデルシステム（設計図が添付されている動くシステム）をカスタマイズして導入する」というものだった(*1)。 それは「プログラミング・ファースト」でも「テスティング・ファースト」でもなく「ユージング(using)・ファースト」とでも呼べそうな、きわめてフロントローディングな開発スタイルである。業種・業態別のモデルシステム・ライブラリの第二弾「XEAD生産管理システム」は、OSSとして２０１３年８月に公開される。 モデルシステムのように大げさなリソースがなくてもアジャイルに開発可能なソフトウエアもあるだろう。しかし、こと生産管理システムのような「複雑なデータベース構造を核とする大規模ソフトウエア」に限れば、データベース構造が確立されたモデルシステムをカスタマイズするやり方が理にかなっている。
もう「チーム開発」には戻れない - 設計者の発言
生産管理システムをひとりで開発しているわけだが、このやり方（おひとりさま開発）に慣れると、分業体制でのチーム開発がいかに非効率だったかがよくわかる。チーム開発は「設計・実装技術の未成熟さゆえの必要悪」だったのではないかとさえ思えてきて、仲間と和気藹々とやっていた昔の自分がなんだか恥ずかしい。 たとえば、いくらしっかり設計してもどうしても仕様変更が起こるものだが、これにともなう手戻りコストがチーム開発では想像以上にかさむ。自分で修正したほうが早いと思いつつ、変更作業のための指示を他人のためにまとめたりする。また、実装担当者の稼働率を上げるために、仕様がまだ不明確であるような機能をあえてあてがったりする。今となっては信じがたいほどの非効率だ。 また、自分で作って動かしてみなければ得られない気づきやアイデアがたくさんあるのだが、チーム開発では設計担当と実装担当が分かれていることが多い。それゆえ、
DDLレベルの外部キー制約は不要 - 設計者の発言
テーブルを作る際に、DDLレベルで外部キー制約をつけることがあるが、私はこれには反対である。組み込める制約の幅が狭すぎるうえに、業務ルールに関する記述があちこちに散らばってしまうからだ。順を追って説明しよう。 外部キー制約を組み込むことで、テーブルは更新・追加・削除操作において制約を受ける。たとえば、受注テーブルが顧客idを持っているとして、これに顧客マスターに対する外部キー制約を与えるとしよう。このとき、受注登録の際に顧客idの値がその時点の顧客マスター上に定義されていなければエラーになる。また、特定の顧客データを顧客テーブルから削除しようとしたときに、既存の受注データと関連づけされているような顧客であれば、やはりエラーになる。 この程度の例であれば、外部キー制約をDDLレベルで組み込むことに何ら問題はない。 ところが、現実は想像以上に複雑である。たとえば、多少不自然な例ではあるが、受注
「データモデルなきアジャイル」の危うさ - 設計者の発言
例によってこれは「業務システム」に関する議論である。ゲームソフトでも組込み系でもＢ２Ｃサイトでもサービス系でもなく、販売管理システムや生産管理システムといった基幹系業務支援システム（ＤＢ構造が複雑なシステムといってもいい）に限った話だ。その種のシステムをアジャイル開発しようと考えるのであれば、それまでにシステム全体の「あるべきデータモデル」が確立されていなければならない。 業務システムを「身体」に喩えるなら、データモデルは「骨格の設計図」に相当する。いっぽうアジャイル開発で導き出せるのは身体の表面上の諸問題、すなわち「皮膚のぐあい」とか「顔つき」のようなものだ。そういった特徴についていかに緻密に決定できても、それらから「あるべき骨格の姿」は導けない。 ＤＢ構造のそういった特性を公知させたのが、前回記事で説明した「ＤＯＡ（データ中心アプローチ）」だった。機能のあり方を確立したうえでデータのあ
あんまりプログラミングしないけどアジャイル - 設計者の発言
アジャイル開発はいわゆる「方法論」ではなく「姿勢」や「問題意識」のようなものだと説明されたりする。その割にはこの「問題意識」がプログラミングや自動テストへの奇妙なこだわりを持ち続けている点に、私は違和感を感じる。 代表的なプラクティスとして「ペア･プログラミング」が採用されたことからもわかるように、もともとアジャイル開発はプログラミングの現場で提唱され発展したものだ。「アジャイルでのプログラミングはなんだか楽しそうだ」といった印象を持たれたりもしている。 しかし、そこらへんの出自や印象についてはもう忘れたほうがいい。なぜなら、個別案件においてアジャイルであることを真摯に追求すれば「なるべくプログラミングせずに済ませるためには、どんな工夫ができるだろう」という認識に至るからだ。ゲームやＢ２Ｃやサービス系や組込系では事情は違うのかもしれないが、少なくとも私の専門である基幹システム（業務システム
「印刷物を眺めながらの仕事」の衰退と罪深さ - 設計者の発言
かつて、業務システムには数多くの「帳票プログラム」が含まれていて、見積精度を損なう要因となっていた。開発に入ってから、さまざまな帳票プログラムをあらたに開発する必要が生じて話がこじれがちだった。年に数度しか使わない帳票とか、誰も必要性を理解できない帳票とかを求められたものだ。もちろん喜んで作った（追加工数をもらえる限りは）。 時は流れ、業務システムに含まれる帳票プログラムはすっかり減ってしまった。ＥＸＣＥＬに明細データを流し込むような仕組みさえ作れば、ユーザ自身がディスプレイ上で自由にソートや集計して眺められるようになったからだ。また、ＢＩのような集計・分析用ソフトウエアも普及した。かつてのように「さまざまな切り口での集計状況を眺めるための帳票」を個々にプログラミングする必要はなくなった。 今でも残っている帳票プログラムは、出荷指示書や実棚調査表、それに請求書といった特殊用途向けのものだ。
危ういデータモデルを見破るコツ - 設計者の発言
ひところよりもデータモデル（ＥＲ図）を作成することの重要性が理解されるようになったが、それでも形だけ整えられて納品されてしまうことがある。「納品しろと言われたからしかたなく作った」ようなモデルはヤバい。素人のイラストにもとづいて高層ビルを建てるような無茶を避けるために、危ういモデルを事前に見破るコツを知っておこう。 ただし、データモデルの「意味的な正しさ」は個別の問題なので立ち入らない。ここではその「見かけ」から危ういモデルを見破るための３つのポイントを紹介しよう。「キー設計が甘い」、「多対多を含んでいる」、「他の設計要素を支えない」といった兆候があれば注意したほうがいい。それぞれを説明しよう。 １．キー設計が甘い データモデルはデータ項目間の「関数従属性」と「ドメイン制約」を示すための図面である。それゆえに、キー属性がいい加減に設計されたモデルは役にたたない。キーはテーブルの存在証明のよ
ＳＩ企業が「モデルシステム」を公開しない理由 - 設計者の発言
誰もが参照できる「モデルシステム」がシステム開発業界には必要だ。そんな「知的社会資本」の整備は、この業界が長い間ないがしろにしてきた社会的使命である――私のこの主張に対して非現実的だと言われることがある。曰く、その種のノウハウは開発事業における競争力の源泉みたいなものだから、そんなものを積極的に公開しようとするお人好しな開発企業なんてあるはずがない、と。 モデルシステムは建築業界における「モデルハウス」に相当する。業種別の設計情報やその実装版としてライブラリ化されたもののことを言う。これを叩き台として個別案件が開始されるようになれば、システム開発のスタイルは一変する。なにしろ「作り始める前に完成している」のだから。 そういうリソースをシステム開発企業が積極的に公開するとは私も思っていない。しかしその理由として「システム開発業における競争力の源泉だから公開するはずがない」などと解説されると不
ナチュラルキーを主キーにしてはいけない - 設計者の発言
定期的に複合主キーの話題が盛り上がるのは楽しい。好きな話題なので便乗しよう。 「複合主キーを許すべきかどうか」の議論に関して私が理解できないのが、なぜか「ナチュラルキーを主キー（一次識別子）に含めてはいけない」という話とセットで語られがちな点だ。もちろん、ナチュラルキーを主キーに含めてはいけない。だめ、ゼッタイ。しかしこれは複合主キーの必要性とは無関係な議論であって、複合主キーを回避すべき理由にはならない。 ■ナチュラルキーと人工キー ナチュラルキーについて、公開中の販売管理システムのモデルで説明しよう。まず、商品マスタの主キーは「内部商品№」である。これは、追加されるたびに自動的に発番されてセットされる項目で、ユーザの目には触れない「人工キー」だ。「Row ID」と思ってもらえばいい。 [商品] 内部商品№、品名、{品番}、．．． いっぽうユーザの目に触れる項目は、「二次識別子」とされて
サロゲートキーは強制されるべきものではない - 設計者の発言
複合主キーに代えてサロゲートキー（単独主キーの代替キー）を導入すべきかどうか。それはDB設計上の重要な判断事項である。なにしろレコードのアイデンティティである主キーの設定にかかわる問題だ。さまざまなメリットやデメリットを考慮してそれは判断される。その結果、サロゲートキーを導入することもあるし、しないこともある。 ところが、サロゲートキーを強制する（あるいはサロゲートキーを導入しないと開発しにくい）開発基盤がいくつか存在する。具体的には、全テーブルの識別子が"ID"等のフィールド名を持つ単独主キーであることが求められたりする。私に言わせれば、そういう開発基盤は「大盛を強制する牛丼屋」である。メニューにあるはずの「並」を頼むと、あれこれイヤガラセをされる牛丼屋。 この問題に関連して、「サロゲートキーを使わなかったから、ひどい目にあった」という開発者の声を聞いたことがあるかもしれない。心配はいら
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
