総合プログラマではなく専門プログラマになろう - 設計者の発言
まず(B)は「専門性が低く、技術要求度が高い」の組み合わせ、すなわち「総合プログラマ」だ。高い技術力を用いて、依頼されればどんなソフトウエアも開発するというスタンスである。ソフトウエアの適用分野を特定しないゆえにIT技術以外の専門性は要らないが、ITに関する広く深いスキルが求められる。ソフトウエア技術にあこがれる若者の多くは、そんな技術者になりたいと思っているかもしれない。 いっぽう(C)は「専門性が高く、技術要求度が低い」の組み合わせ、「専門プログラマ」である。ゲームソフト、業務管理システム、組み込みソフト、セキュリティ対策、ネットワークといった特定分野を担うIT技術者をイメージしてもらえばいい。どんな分野であっても、その分野なりの固有の知識体系（業務知識）や経験が求められる。その総体が「専門性」だ。 ちなみに私自身は業務管理システム向けの専門プログラマ(C)であるが、この分野に必要な専
UML版在庫データモデルの問題 - 設計者の発言
IPAによるデータベーススペシャリストの平成28年春期試験で、UMLモデルを使った問題が出されていた（これ）。最近たまたま見つけたのだが、これには驚いた。問題や解答が間違っているわけではないのだが、クラス図でデータモデルを描くことの危うさをこれほど雄弁に示している例はないので紹介したい。 まず注意してほしいのは、問題に添えられている「データモデル」の上でPK（一次識別子）が示されていない点だ。これは、クラス図ではすべてのインスタンスがID（オブジェクトID）で識別されるためだ（つまり、すべてのPKがIDであればいちいち示す必要がない）。PKを補ってER図として描き直すと図１のようになる。 図１．倉庫と商品の関係 一見すると問題がなさそうだが、このまま実装すれば悲惨なことになる。具体例を書き添えてみればわかるのだが、図２で示したようなデータ状況を許してしまう。すなわち、「倉庫と商品の同一の組
システム設計と創造性 - 設計者の発言
これまでさまざまな開発プロジェクトを脇から見てきたのだが、ありがちなパターンとして「分析・設計工程に想定以上の時間がかかってしまって、実装工程の時間が短縮される」というのがある。ほとんどのプロジェクトがこのパターンに陥ると言えるほどに頻発している。 べつに担当者がサボっているわけではない。遅くまで残業してがんばっていたりするのだが、出来上がる成果物はひどく心もとない。では何を熱心にやっているかというと、関係者へのヒアリングと、旧システムの仕様分析である。それの何が問題かというと、「創造的要素」が希薄な点だ。「分析ばかりに夢中になって、設計がほとんどなされていない」と言い換えてもいい。 これに関して私が以前から疑問だったのは、「問題モデル（分析モデル）」と「解決モデル（設計モデル）」とが連続しているような言い方だ。問題モデルを誠実にまとめれば、そこから解決モデルを導出できる――これは信念では
単独主キーでもDB設計は楽にならない - 設計者の発言
我ながらしつこいが、どんな開発環境においても「id」のような単独主キーを用いる設計手法の危険性について、もう一度指摘したい。この手法を「単独主キー主義」と呼んでおくが、これに関して「複合主キーを用いると主キーが変化しやすいから」とか「単独主キーのほうが仕様変更に対応しやすい」といった擁護意見がある。それらの主張が無効であるばかりか有害でさえあることを説明しよう。 なお、私はこの議論で「だからナチュラルキーが正しい」と言おうとしているのではない。じっさいのところ私はナチュラルキーを主キーにすることに反対しているが、それは本稿の主張と矛盾しない（参考記事）。ここで私が言いたいのは、複合主キーを用いたオーソドックスな設計手法を身につけたうえで、利用する開発環境の制約にもとづいて慎重に正規化崩しできるようになろう、ということだ。 ■サンプルのデータ要件 複合主キーを要求するデータ要件として、前の記
タコヤキ業務にタコヤキテーブルは必要か - 設計者の発言
前々回と前回の記事で紹介した「WEBサービス事業管理システム」のモデルと実装が、「CONCEPTWARE/サービス管理」として近日公開される（2016/10/12に公開済）。このモデリング課題にもとづいて大阪と東京でハンズオンセミナーを開催したわけだが、その中で気づいたことをひとつ紹介したい。DB構造が業務構成や機能構成に必要以上に引きずられてはいけないという話だ。 １回目のセミナーではシステム要件をほとんど口頭で説明しただけだったのだが、２回目では時間の節約のために、あらかじめリストにしたものを事前に配布したうえでデータモデリングしてもらった。その一部が以下である。 ・顧客に利用明細書を送付した時点で売上確定され、顧客は規定の銀行口座に利用料を振り込む ・利用料が未入金であるような顧客に対しては、適宜に督促メールを送信する ４～５名で８チームに分かれてモデリングしたのだが、ほとんどのチー
開発案件の「適正サイズ」を考える - 設計者の発言
「4000億円がパー」とも噂される某銀行のシステム刷新プロジェクトのデスマーチぶりが話題になっている。当事者ではないのでよくわからないが、議論の余地がないのが「開発対象がとにかくデカい」という点だ。どう考えてもひとまとまりで「設計・施工・引っ越し」が可能な大きさを超えている。種々雑多な問題が生じることは、デカすぎる開発対象を切り出した企画段階ですでに運命づけられていたのではないか。 銀行のシステムに限らない。製造業向けの生産管理システムや卸売業向けの販売管理システムといった基幹業務支援システム（業務システム）の開発案件には、共通の「適正サイズ」があると私は考えている。そのサイズを超えるようなものがあれば、「大型案件」と言うよりは「不適切案件」とみなすべきではないか。 「システムのサイズ」ではなく、「１回あたりの開発範囲」の話であることに注意してほしい。業務システムの大きさは、当然ながら個々
「設計情報の構造」に現れる設計品質 - 設計者の発言
私を日本語に上手は使えます。 こんな文があったら読者はどう感じるだろう。これには「書き手は日本語が上手いわけではない」というメタレベルの情報が含まれている。この文が「私は日本語が上手に使えます」の意味で書かれたものならば、読み手は混乱する。少なくとも書き手の日本語能力が信用されることはないだろう。 同じことがシステム設計に関しても言える。設計情報そのものの構成の巧拙に、設計者自身の設計能力が示されている。どんな業務や業種を対象にしているかに関係なく、設計情報そのものがうまく構造化されていないことが、システム要件に対してうまく設計がなされていないことの間接的な証拠となる。 仕事柄、いろいろな設計書を目にするが、ざっと眺めるだけで設計者の実力がわかってしまうものだ。最初に目を通すのは「目次」だ。章立て・節立てには設計者のシステム観が反映されているし、それらのタイトル表現からは言語的センスが透け
ER図レビューの３つのポイント - 設計者の発言
前回記事で、業務システム開発の上流工程でDB設計がないがしろにされるケースがあると指摘したが、よほど低レベルな職場でない限り、今では上流工程でのER図の作成が標準化されるようになっている。 ところが、そのER図がまるでショボいにも関わらずレビューで承認されるケースがあとを絶たない。理由は単純で、ER図があるかどうかだけがチェックされて、内容レベルの検証がなされていないためだ。それはとりもなおさず、DB設計を的確にレビューできる技術者がいないためでもある。 ER図を見れば、プロジェクトが成功するかどうかまではわからないかもしれないが、「デスマーチ化するかどうか」はわかる。それほど便利な図面が提出されながらレビュワーのスキルが足りないのでは、設計標準の持ち腐れというものだ。 そこで、ER図を効果的にレビューするためのポイントを紹介したい。構成的な心地よさがあるか、キー構成が単純すぎないか、創意
「外部設計・内部設計」の危うさ - 設計者の発言
「外部設計」という用語がある。業務システム開発の世界では昔からあって、「ウォーターフォール方式(WF)」で工程を区別するために使われている。「外から見える部分の設計」という意味のexternal designを訳したものと思われるが、これがなかなかのくせ者だ。 建築に喩えることを許してもらえるなら、「外から見える部分」は壁の色だの玄関の形だのといった「見た目」であって、そんなものを高層ビル建築の上流工程で提出しても「これだけでは不十分」とつっかえされるのがオチだ。ユーザから見える「フォーム」や「帳票」のデザインをまとめただけの上流工程成果物が役に立たないのも同様であって、この意味で建築とシステム開発は似ている。 「外部設計」のタイミングで優先的になされるべき仕事は何か。それは「見た目」ではなく「骨格」の構想と決定である。高層ビルの設計で言えば基礎や鉄筋の構造に相当する。これらの多くはユーザ
テーブル操作と業務ロジックの連動制御 - 設計者の発言
テーブルに依存する業務ロジック（ビジネスルール）であれば、アプリから独立した「テーブルの拡張定義」として一元的に管理されなければいけない。そしてそれは、アプリによるテーブル操作に応じて暗黙的に呼び出され、アプリと変数域を共有しつつ実行されなければいけない。何のためか。アプリをうすっぺらにして、開発・保守の効率を高めるためだ。前回記事でそのように説明した。 では、テーブルに依存する業務ロジックであれば、アプリによってテーブル操作がなされたら必ず実行されるべきかというと、じつはそうではない。テーブル操作と業務ロジックを連動させるかどうかは、システム内部のアプリによって選択可能でなければいけない。両者を連動させたいことも、そうでないこともあるからだ。 このことに関係するのだが、RDBMSによって提供される外部キー制約やカスケードオプションのような「気の利いた機構」を、私はよほどのことがない限り使
マイクロサービスと基幹システムの本質 - 設計者の発言
「マイクロサービス(microservices)」が注目されている。社内外のさまざまなシステムが提供するREST APIのような操作手段を組み合わせて、新たなしくみをアジャイルに開発・保守してゆく。そんな開発スタイルのことをいう。 もともとはネット系企業で普及した手法であるが、それ以外の企業にとっても参考になる。前回記事で、基幹システムが効果的なAPIを提供することで「周辺システム」の開発が合理化されると説明した。これを社内システム全体に適用した手法が、マイクロサービスである。ネット系企業でなくても「周辺システム」はいろいろあるので、いくらでも応用できる。ただし、当然ながら万能ではなく使いどころがある。 基幹システムから見た「周辺システム」と書いたが、それらは今風に言い換えるとSoE(Systems of Engagement)、ようするに顧客との関係強化をはかるためのシステム群である。い
「論理設計」にこだわる利点 - 設計者の発言
業務システムのあり方を構想する際には、論理設計と物理設計とをフェーズ分けしたほうがいい。システム要件を仕様化しやすくなるだけでなく、スキル育成や効率改善の基礎となるからだ。それはソフトウエアの特性にもとづくプレゼントのようなもので、ありがたく活用したい。 そもそも「論理設計」とは何か。「受注情報だけを管理する」という単純なシステム要件があったとしよう。その際、たとえば以下のような「論理定義」がまとめられることになる。 １．業務構成 受注登録業務、受注保守業務、受注照会業務 ２．データ構成 受注見出しテーブル、受注明細テーブル ３．機能構成 受注一覧機能、受注登録機能、受注保守機能、受注照会機能 ここでは定義要素の字面だけが示されているが、それぞれ独特な形式の詳細情報を伴う。たとえば「業務構成」は「いつ誰がどのようにこのシステムを利用するか」についての定義のまとまりなのだが、それぞれ「いつ(
基本設計を分担してはいけない - 設計者の発言
プロジェクトメンバーが無駄に多いのが、日本型SIの特徴のひとつである。「工数を人数で割れば工期が出る」と考えることが間違いであることは、ブルックスの著書「人月の神話」によって今から40年前に指摘されている。それにもかかわらず、相変わらず多くのプロジェクトで必要以上の人数が投入されている。 私がとくに不思議に思うのが、基本設計を何人もの要員で分担するやり方だ。DB設計と機能設計と業務設計の担当を分けるとか、サブシステム毎に担当を分けるといった体制がしばしば敷かれる。詳細設計の段階でというのならまだわかるが、基本設計でそれをやってはいけない。 なぜか。業務システムにはアーキテクチャ（意図された構造）が求められる。そして、そこに含まれる膨大な定義要素は、統一感や一貫性を保ち、かつMECEな形で切り出されなければいけない。複数の要員で分担などすれば、それらの課題が一挙に難しくなる。また、DB構成と
自由であるためにドキュメントを作る - 設計者の発言
前回記事で、ドキュメンテーションを重要視しない開発業者を避けるべきだと指摘した。同様の問題は、業務システムを内製した場合にも生じている。むしろ、ドキュメントレスな困ったシステムは、内製で生み出されているケースのほうが多いような印象が私にはある。 ドキュメントレスなシステムが重大なリスクを抱えていることを、ほとんどの経営者は認識していない。なぜなら、ドキュメントレスであってもシステムのあり方は内製担当者の「頭の中」に入っているので、彼に頼めば必要な改修はやってもらえるからだ。結果的に業務システムが、担当者のエンプロイアビリティ（雇用意義）を強化するための政治的ユーティリティと化すことを許してしまう。その歪みは、担当者がいなくなったときに一挙に顕在化する。いなくなった当人としては「後は野となれ山となれ」である。 業務システムがドキュメントレスになりがちな根本的な理由は、まさにここらへんにある。
ボトルネックは「業務系スキル」 - 設計者の発言
私は業務システムというものが好きだ。売上そのものを生み出すしくみではないので派手さはないが、経営効率を高めるための縁の下の力持ちのような奥ゆかしさがある。そして、日本企業の特質である「顧客のわがままに柔軟に応える姿勢」を貫くための鍵が、他でもない業務システムである。効果的な業務システムをいかに効率的に設計・実装するか。それを考えたり実践することが楽しくてしょうがない。 この分野にも固有の専門性がある。まず必要なスキルは、業務連係やデータベースの設計技術、そしてシステム構成と統合された会計知識だ。適性としては、論理的な思考力や人並み以上の言語能力が求められる。これらの技能を合わせて「業務系スキル」と呼んでおくが、その重要さは実装手段が変わっても揺るがない。 ところが、開発を専業とする組織における業務系スキルの空洞化が著しい。じっさい今になって営業担当者があわてている。長い不況を抜けてやっと業
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
良単価・準委任で契約するためにできること - 設計者の発言
システム開発はベンダーとの請負契約（成果物基準）で進められることが多いが、準委任契約を結べるのであれば、ベンダーもクライアントもプロジェクトからより多くの果実を得られる。そんな理想的な契約を結ぶことは可能なのだろうか。 なお、「準委任契約」とは、成果基準ではなく「提供した時間」にもとづいて請求額が決まる契約形態のことだ。ちなみに「準委任契約」の"準"に大した意味はない。"準"のつかない「委任契約」は、弁護士等の法律関係の契約を指す用語で、ようするに「法律関係以外の委任契約」が「"準"委任契約」である。 IPAの尽力もあって、上流工程（要件定義～基本設計）を準委任契約で請け負うことは、今では広くなされるようになった。なにしろ、作業を始める前に成果物がどんなものであるかを明確にできない。せいぜい納品物の「一覧」を決めることしかできない。だから、上流工程は準委任契約と相性がいい。 問題は下流工程
ドキュメント不整合問題の様相 - 設計者の発言
業務システムはいったん完成すれば終わりというものではなく、事業に合わせて変化・発展していかねばならない。その過程で開発者は、システムのあり方を把握するための包括的ドキュメントとシステムの実際のあり方を整合させるという課題に直面する。「仕様書とプログラムの不整合」はそういうった問題のひとつである。私が提唱する「３要素分析法」の枠組みを使って、ここらへんをじっくり眺めてみよう。 ◆不整合はどこで生じるか まず、問題の様相を理解するために、基本設計書と仕様書（詳細設計書）とアプリケーションのそれぞれに含まれる要素と、それらの対応関係を見よう。まとめると図１のようになる。 図１ まず、この議論の起点となる「基本設計書」には、私の言う「業務システムの３要素」が概念上含まれる。すなわち、業務モデル(どのようにシステムが利用されるか)、データモデル(データベースはどのような形をしているか)、機能モデル(
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「技術者とのコネ」で決まる開発の成否 - 設計者の発言
図表と箇条書きばかりで文章が足りない - 設計者の発言