オリンピックをモデリングしよう - 設計者の発言
■２つのモデル 「オリンピックをモデリングしてください」とだけ指示されたら、あなたは何をするだろう。データモデラーであれば、次のように考えを進めるだろう。 求められていることは、オリンピックの運営に関わる情報を管理するためのシステムであろう。選手、コーチ、競技、成績、宿舎、会場などのデータが管理される必要がありそうだ。これらの管理簿の間にはどんな制約があって、どんな業務連係が必要になるだろう。．．． いっぽう、オブジェクトモデラーは、次のように考えるだろう。 オリンピックでは、選手、コーチ、競技、成績、宿舎、会場などのオブジェクトが相互作用するだろうから、これらのクラスを用意しよう。選手クラスには「競技参加の申し込みを行う」、「競技を実施する」などのメソッドが要りそうだ。．．． 違いがおわかりだろうか。データモデラーは、「オリンピック情報管理システム」に必要なDB構造（帳簿組織）やそれを維
DB設計がマトモであれば何とかなる - 設計者の発言
３月にJUASで開催された「データモデリング＆超高速開発ライブ」の動画が公開された（これ）。４分程度のダイジェスト版であるが、当日の雰囲気がよくわかる。私にとって興味深いのはデータモデリングで、描き拡げられる過程がコマ落としで示される様子が面白い。 このときは、私がやったことがないという理由もあって「配員管理システム」を開発課題にした。提案してくださった方の口頭説明にもとづいて、参加者からの意見を取り入れつつ１１個のテーブルを含むデータモデルとして４０分でまとめ、各チームが６０分で実装した。実装だけでなく、それに先行する設計もまた「超高速」である。 これほどの俊敏さで業務システムが出来上がるのは驚くべきことなのだが、このイベントは開発ツールの生産性を示すだけのものではない。当たり前の話だが、データモデルが不細工ならば不細工なシステムしか生み出されない。ツールが発展・普及する過程で実装作業は
システム設計と創造性 - 設計者の発言
これまでさまざまな開発プロジェクトを脇から見てきたのだが、ありがちなパターンとして「分析・設計工程に想定以上の時間がかかってしまって、実装工程の時間が短縮される」というのがある。ほとんどのプロジェクトがこのパターンに陥ると言えるほどに頻発している。 べつに担当者がサボっているわけではない。遅くまで残業してがんばっていたりするのだが、出来上がる成果物はひどく心もとない。では何を熱心にやっているかというと、関係者へのヒアリングと、旧システムの仕様分析である。それの何が問題かというと、「創造的要素」が希薄な点だ。「分析ばかりに夢中になって、設計がほとんどなされていない」と言い換えてもいい。 これに関して私が以前から疑問だったのは、「問題モデル（分析モデル）」と「解決モデル（設計モデル）」とが連続しているような言い方だ。問題モデルを誠実にまとめれば、そこから解決モデルを導出できる――これは信念では
「単独主キー専用環境」と賢くつきあうために - 設計者の発言
「ORマッピングの功罪」の続きである。複合主キーが忌避される開発環境について、もう少しつっこんで考えてみたい。まともなORマッパーであればふつうに複合主キーを扱えるのにもかかわらず、ORマッパー上で組み立てられた開発環境ではしばしば複合主キーが非推奨とされる。なぜなのか。 その種の開発環境において、データ要件を「オブジェクト（クラス）構造」として認識し、それをRDBに落とし込むといった設計スタイルを実践することが前提になっているためだ。個別案件においてOOP（オブジェクト指向プログラミング）を使う余地が大きい開発環境ほど、この傾向が強まる。その独特なスタイルは、かつてはOOA/OODと呼ばれ、今ではDDDと名前を変えつつも(*1)、OOP使いの間で根強い人気がある。 その枠組みにおいてクラスの実際値（オブジェクト）は、RDBテーブルのレコードとして永続化（保存）されることになる。オブジェク
「他人にとってのわかりやすさ」が至上の価値である - 設計者の発言
最近ある事例で、業務システムをわかりやすく作ることの大切さをあらためて思い知った。ひとりの技術者が１０年近く保守してきた案件なのだが、全面刷新しようということになったタイミングで、ある理由でかれが突然いなくなった。残されたシステムを調べてみると、まさにカオスと言うべき出来上がりで、まともなドキュメントもない。関係者が途方に暮れているのは言うまでもない。 もちろん関係者にも責任の一端はある。そんな事態になる前に、リファクタリングしたり、ドキュメントを丁寧にまとめるための働きかけがあるべきだった。しかし、実際にそのような動きが何度もあったのだが、担当者はそれに応えることができなかった。なにしろ他人が見てもわからないシステムだったので、担当者自らが動かないのではどうしようもない。けっきょく、ズルズルと時ばかりが流れて最悪の状況を迎えてしまったのだった。 将来このような事態に陥りそうなシステムはじ
タコヤキ業務にタコヤキテーブルは必要か - 設計者の発言
前々回と前回の記事で紹介した「WEBサービス事業管理システム」のモデルと実装が、「CONCEPTWARE/サービス管理」として近日公開される（2016/10/12に公開済）。このモデリング課題にもとづいて大阪と東京でハンズオンセミナーを開催したわけだが、その中で気づいたことをひとつ紹介したい。DB構造が業務構成や機能構成に必要以上に引きずられてはいけないという話だ。 １回目のセミナーではシステム要件をほとんど口頭で説明しただけだったのだが、２回目では時間の節約のために、あらかじめリストにしたものを事前に配布したうえでデータモデリングしてもらった。その一部が以下である。 ・顧客に利用明細書を送付した時点で売上確定され、顧客は規定の銀行口座に利用料を振り込む ・利用料が未入金であるような顧客に対しては、適宜に督促メールを送信する ４～５名で８チームに分かれてモデリングしたのだが、ほとんどのチー
「外部設計・内部設計」の危うさ - 設計者の発言
「外部設計」という用語がある。業務システム開発の世界では昔からあって、「ウォーターフォール方式(WF)」で工程を区別するために使われている。「外から見える部分の設計」という意味のexternal designを訳したものと思われるが、これがなかなかのくせ者だ。 建築に喩えることを許してもらえるなら、「外から見える部分」は壁の色だの玄関の形だのといった「見た目」であって、そんなものを高層ビル建築の上流工程で提出しても「これだけでは不十分」とつっかえされるのがオチだ。ユーザから見える「フォーム」や「帳票」のデザインをまとめただけの上流工程成果物が役に立たないのも同様であって、この意味で建築とシステム開発は似ている。 「外部設計」のタイミングで優先的になされるべき仕事は何か。それは「見た目」ではなく「骨格」の構想と決定である。高層ビルの設計で言えば基礎や鉄筋の構造に相当する。これらの多くはユーザ
適用分野と実装手段の組み合わせ戦略 - 設計者の発言
ソフト開発者の専門性は「適用分野」と「実装手段」の組み合わせとして位置づけできる。その枠組みから、労働市場でのいくつかの戦略が導かれる。たまには自分がどんな戦略を取っているかを顧みたほうがいい。今の自分に足りないものや将来の見通しがわかるからだ。 ソフトウエアというものは人間の活動を支援するものだが、人間の活動そのものがきわめて多彩である。それゆえ、「どんな分野向けでも承りますよ」なんてスタンスの開発者は稀で、ふつうは得意分野として適用分野を限定している。コンサルタントがそうであるように、開発者も特定分野の知見や経験にもとづく濃いサービスを提供することで、良好な契約単価を確保しようとする。 いっぽう、ソフトウエアの実装手段も多彩である。プログラミング言語の専門化・高級化の動きは未だに収束しそうになく、新しい開発環境、新しい実装条件が日々現れている。それゆえ、「どんな実装手段でも承りますよ」
マイクロサービスと基幹システムの本質 - 設計者の発言
「マイクロサービス(microservices)」が注目されている。社内外のさまざまなシステムが提供するREST APIのような操作手段を組み合わせて、新たなしくみをアジャイルに開発・保守してゆく。そんな開発スタイルのことをいう。 もともとはネット系企業で普及した手法であるが、それ以外の企業にとっても参考になる。前回記事で、基幹システムが効果的なAPIを提供することで「周辺システム」の開発が合理化されると説明した。これを社内システム全体に適用した手法が、マイクロサービスである。ネット系企業でなくても「周辺システム」はいろいろあるので、いくらでも応用できる。ただし、当然ながら万能ではなく使いどころがある。 基幹システムから見た「周辺システム」と書いたが、それらは今風に言い換えるとSoE(Systems of Engagement)、ようするに顧客との関係強化をはかるためのシステム群である。い
モデリングの標準問題から学べること - 設計者の発言
大切な人の記念日に花束とカードを贈りましょう――そんな事業を支援するシステムの三要素モデルを公開した。もともとのシステム要件は「花束問題V1.2」として、IT勉強宴会のサイトで公開されている。複雑過ぎず単純過ぎないバランスの良い問題である。 ・ダウンロードページ（モデルを閲覧するにはX-TEA Modelerが必要） ・花束問題V1.2のページ 要件をざっと説明しよう。「商品」である花束に組み込まれる素材は「単品」と呼ばれ、入荷日毎にロット管理される。単品ロットはナマモノなので、規定の日数後には廃棄されなければいけない。ゆえに、受発注状況に応じた単品の欠品見込や廃棄見込をリアルタイムで示すための仕掛けが要る。次図は公開したモデルの一部である。 ▼受注～出荷の流れを示す業務フロー ▼受注まわりのデータモデル このシステム要件にもとづいてまとめられたモデルを、手法横断的に比較検討する。そんな活
「ドメイン・エキスパート」になろう - 設計者の発言
２０年も昔の話だが、「英語できます」という本を読んで考え込まされたことがある。どんな仕事で稼ぐにせよ、何らかの専門性が要る。英語力というものは、そんな「専門性の効用」を引き上げるためのツール以上のものではない。むしろ中途半端に英語力があったばかりに専門性を深める努力を怠って、英語力を社会で生かせていない。そんな事例がいくつも紹介されていた。 この話、ソフト開発の技能に関してもいえるのではないだろうか。技術が進歩すればするほど開発の技能はコモディティ化し、これを習得しているだけでは大した意味はなくなる。ソフト開発の技能を社会で生かすためには、互いの効用をレバレッジするような何らかの「専門性」が要る。 これは、開発者自身がまず何らかの「ドメイン・エキスパート」であるべしという話に他ならない。ドメイン・エキスパートとは、DDD（ドメイン駆動設計）で言うところの、開発されるソフトウエアの適用分野（
新人技術者にはOOPLの前にDSLを - 設計者の発言
例によって、業務システム開発の世界に限った話である。ＥＣサイト開発の話でもないし、ＷＥＢサービス開発の話でもない。販売管理システムや生産管理システムといった「業務システム」の開発を専業とする企業において、新人に最初に教えるべき言語は何かという話だ。今ではJavaを教えている企業が少なくないが、OOPL（オブジェクト指向言語）のような「汎用言語」ではなく、本来は業務システム開発に特化したDSL（ドメイン特化言語）を最初に教えるべきだ。 なぜか。前回記事でも述べたように、プログラミング以外の専門分野（ドメイン）を見定めてそれを究めることが、ソフト技術者のキャリアにとっての優先課題だからだ。業務システム開発を専業とする企業に所属する技術者にとってのドメインは、基本的に「業務システム」ということになる。「業務システムの専門技術者」を育てるためということなら、OOPLではなく「業務システム向けDSL
オブジェクトモデリングとデータモデリング - 設計者の発言
オブジェクトモデリングとデータモデリングはどこが違うのだろう。クラス図やER図といった成果物を比較するだけではわからない本質的な違いが両者にはある。 オブジェクトモデリングは基本的に、対象をシミュレーションするために実施される。たとえばモデリング課題が「ファミリーレストラン」であれば、ファミリーレストランをコンピュータ上で動作させるための準備として、オブジェクトモデルは作られる。 シミュレーションすることにも何らかの目的がある。たとえばそれは「従業員の役割に応じた作業と効率の決定」のためなのかもしれない。そういった意図にしたがって現実が解釈され、モデルに反映される。たとえば客やウェイトレスといった要素が組み込まれつつも、客のモンスター度だのウェイトレスの美人度といった属性が捨象されたりする。ようするにオブジェクト・モデラーは、なんらかの意図にしたがって対象を抽象化しながらも「写生」しようと
オブジェクト指向とイパネマの娘 - 設計者の発言
以前にＤＡＷ（演奏を録音したりプログラミングして音源を作るためのツール）の話を書いたが、そのソフトもオブジェクト指向言語で作られている。しかし、それを使う際に、ユーザである私はオブジェクト指向を意識する必要はない。同様に何でもいいが、たとえば工場で工業用ロボットの動作プログラム（シーケンス）を管理している製造管理者が、シーケンスデータを編集する際にも、オブジェクト指向を意識することはない。 当たり前のことを言っているように思われるかもしれない。では、こう言ったらどうだろう。業務支援システム（生産管理システムのような事務処理支援システムのこと）の開発者はオブジェクト指向を意識しなくてよい――これには反論があるかもしれない。オブジェクト指向を知らずにシステム開発などできるわけがない、と。 確かに、個別の業務支援システムを「丸腰」で、つまりプログラミング言語を使っていきなり開発するとしたら、オブ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「八合目キャンプ」からのアジャイル - 設計者の発言
「CONCEPTWARE／受注生産」の実装版が完成 - 設計者の発言