全記事一覧

部門と従業員のデータモデリング
開発者が「コード体系」に関与する必要はない
「危ないデータモデル」の定量的判定基準
総合プログラマではなく専門プログラマになろう
■2019

NoSQLでもデータモデリングが必要
「発効日」を主キーに含むデータモデル
システム開発企業のスリム化戦略
「試算表テーブル」を設計する?
予算テーブルと実績テーブルを分ける?
「技術者とのコネ」で決まる開発の成否
打ち合わせの真ん中にモデルを置こう
「優先順位づけ」は重要なエンジニアリングスキル
システム開発者の給料が安すぎる理由
省庁向けモデリングライブの効果
DB構造の悪さが事業の足をひっぱる
少数精鋭でやれない場合にどうするか
オリンピックをモデリングしよう
Excel仕様書を機能タイプ別に様式化する
仕様の「見える化」と働き方改革
新人にオブジェクト指向の魅力を知られてはいけない
対談イベントのお知らせ
DB設計がマトモであれば何とかなる
UML版在庫データモデルの問題
業務システムを「牢獄」にしないために
内製の前に「自社保守」を目指そう
顧客も業者によって値踏みされる
超高速開発とアジャイルの違い
DB開発とアプリ開発を分離せよ
システム開発ライブのお知らせ
業者の設計スキルをハダカにする
おそ松なデータベース
■2018

クラス図とデータモデルはどうちがう?
危うい「プロセス指向」が廃れない理由
図表ばかりで文章が足りない
「わかりやすさへのこだわり」があるか
システム設計と創造性
データモデリングの達人技を盗め、温泉で
「DDD批判」への批判
「オブジェクト指向」や「アジャイル」では食えない
制限時間1時間で実装せよ(7/29,東京)
単独主キーでもDB設計は楽にならない
「モデリング&プロトタイピング手法」事例紹介
「単独主キー専用環境」と賢くつきあうために
文章術:「改行」を自覚的に用いる
ORマッピングの功罪
「命名標準」に振り回されないために
「科学研究」としてのシステム開発
「他人にとってのわかりやすさ」が至上の価値である
■2017

ALTER文の自動生成機能
開発手法と「クリティカル・スキル」
タコヤキ業務にタコヤキテーブルは必要か
「趣味はシステム設計」くらい言えていい
「WEBサービスで稼ぐ企業の業務システム」のモデリング
「仕様の的確さ」と「アプリ品質」のバランスをはかる
アジャイルではなく「プロトタイピング」を
開発案件の「適正サイズ」を考える
ER図レビューの3つのポイント
「外部設計・内部設計」の危うさ
ドメイン特化基盤の柔軟性を高める
X-TEA Driverの英語版登場
「EXCEL仕様書からコード生成」のアンバランス
正規化崩しの目的は「高速化」だけではない
レコードの変更予約管理を合理化する
適用分野と実装手段の組み合わせ戦略
「論理削除」ではなく「無効化」を
拡大・縮小する前に美しいER図を
フレームワークとドメイン特化基盤
X-TEA Driverが1.3にリリースアップ
テーブル操作と業務ロジックの連動制御
業務ロジックをアプリに置いてはいけない
機能タイプ&テーブルポジションで効率アップ
マイクロサービスと基幹システムの本質
■2016

マイクロサービスで周辺アプリと連係する
値の変更が制限される項目「強属性」について
ドメイン特化基盤がドメインを豊かにする
「論理設計」にこだわる利点
DBの複雑さとアプリの複雑さ
基本設計を分担してはいけない
設計情報のバージョン管理を合理化する
「八合目キャンプ」からのアジャイル
モデリングツールとExcel仕様書の合わせ技
DDDの前に専門性を身につけよう
入出力定義と「非対話型業務」の関係
動くシステムを営業段階で示せるか
XEADがX-TEAとして再登場
データモデルはドメインモデルに先行する
ビブリオバトルで蘇我入鹿を語る
システムモデルを事業別に分割する
「プログラミングの専門家」でも「ツールの専門家」でもなく
ベンチマークとしてのレファレンスモデル
XEAD製品がJava1.8に対応
モデリングの標準問題から学べること
モデル駆動開発勉強会(4/25@東京)で語ります
「フィールドの更新不可制約」の必要性
ドメインの階層化とDSP
「CONCEPTWARE/受注生産」の実装版が完成
新人技術者にはOOPLの前にDSLを
「ドメイン・エキスパート」になろう
データモデルの静と動
セミナーとモデリングライブのお知らせ
アプリの類型における処理テーブルの形式化
データ指向設計・開発の実践
■2015

「だるいコーディング」を駆逐した後に残る仕事
システム変数とシステム区分の設計
XEAD Modelerがベクター出力に対応
エンタープライズ・アジャイル:手法論より大事なもの
既存システムをハッキングする
自由であるためにドキュメントを作る
「何を使って設計書を書いていますか?」と尋ねよう
テーブル関連の「排他性」をモデル上で表現する
ドキュメントの山で遭難しないために
ユニーク制約の使いどころ
主キーはインデックスではない
ボトルネックは「業務系スキル」
データとして登録されるビジネスルール
「大規模集積回路モデル」と「板チョコモデル」
告知:「受注生産」のためのシステム開発ライブ
フィールドIDが全角日本語であることの意義
「シンプル・イズ・ベスト」はややこしい
システム化の恩恵を中小企業へ
システム開発は「セル生産方式」になる
問題領域とコンピュータの狭間で
DBMSの交換容易性と開発基盤
ソフト開発に資材が要らないことの優位性
設計支援ツールとマルチユーザ対応
フォントを替えて設計・開発を快適に
オブジェクトモデリングとデータモデリング
システムの「基盤交換性」を見極める
取引先にEDI用Webサービスを提供する
ドキュメント不整合問題の様相
良単価・準委任で契約するためにできること
コンテキスト・ダイアグラムを描こう
システムの仕様情報を正規化する
「仕様書プログラミング」とその運命
■2014

複合主キー「否定派」と「許容派」の論争
仕様書の類型化と様式化
「逆方向バリデーション」との付き合い方
トレーサビリティを確保するための便法
「営業カレンダー」のモデリング
「仕様書で駆動される生産管理システム」公開
超高速開発ではなく「超少人数開発」を
CRUD図をわざわざ作る?
アジャイル手法は分野毎に違っていい
売上計上基準の設計と実装
「品番変換」のモデリング
「売上伝票」を問い直す
アンチパターン「成長する主キー」
製造指示の設計と実装 (3)外作
もう「チーム開発」には戻れない
製造指示の設計と実装 (2)開始と完了
サロゲートキーと「とりあえずID」の違い
製造指示の設計と実装 (1)日程化
生産管理オタクは3/30に浜松へ!
業務フローとER図を3D化してみた
DDLレベルの外部キー制約は不要
モデル駆動(MDA)から仕様書駆動(SDA)へ
システム開発のHowToではなくWhatを
SQLを使わないでシステム開発
BOMプロセッサの開発完了
各種技法の「競演モデリングライブ」を
■2013

梱包形態のモデリングと加工出荷
部品表をツリービュー表示する
「丸投げ請負」から「内製支援」へ
「データモデリングライブ@名古屋」報告
「恥ずかしさ」で設計品質を高める
「データモデリングライブ@名古屋(11/24)」のお知らせ
部品表とフィーチャ・オプション
1レコード多段表示一覧に対応
概念モデルと論理モデルの違い(後編)
概念モデルと論理モデルの違い(前編)
「生産管理」で業務知識の学びを効率化しよう
「データモデリングライブ@渋谷」報告
実装スキルと業務知識を統合するために
動くソフトウエアを作る前にアジャイルモデリングを
「データモデリングライブ@渋谷(9/29)」のお知らせ
デザインパターンそのものをプログラミングする
業務システム向けのデザインパターン
「データモデルなきアジャイル」の危うさ
データ中心アプローチと「業務モデル」
「業務マニュアル」と「操作マニュアル」の違い
アンチパターン「大規模集積回路モデル」
「フィールド値の色」をテーブル定義に組み込む
特定ドメイン向け開発環境の意義
Excel方眼紙がダメな2つの理由
DB設計セミナー開催します(東京7/30-31)
フィールド数のメトリクス
たったひとりで踊るために
人海戦術から「おひとりさま開発」の時代へ
VPSでクラウド基幹システムを作ってみた
あんまりプログラミングしないけどアジャイル
「印刷物を眺めながらの仕事」の衰退と罪深さ
Facebookから脱退
「モデル」としての仕様書
サロゲートキーの日常性と心得之条
「てにをはレビュー」の是非
ブラウザアプリと3階層型デスクトップアプリ
成果物のサイズとシステムの保守性
危ういデータモデルを見破るコツ
自治体システムは日本に1個あればいい
セット商品の原価と在庫推移
逆方向バリデーションを自動化する
マスターテーブルと「有効期間」
開発基盤のトリガーとDBMSのトリガー
ショボいDB設計で突っ走るための50の方法
サロゲートキーの事例解説
「強制されたサロゲートキー」の事例を眺める
サロゲートキーは強制されるべきものではない
バリデーションの双方向性問題を解く
企業システムの基本構造を理解しよう
■2012

動的参照関係を「宣言的」に扱えるか
「有効期間」を含むテーブルとの参照関係
「自動生成」と「動的制御」
SI企業が「モデルシステム」を公開しない理由
在庫DBにおける「正規化崩しの報い」
業務システムとWEBサービス
語られないアーキテクチャの謎
「アジャイルなスクラッチ開発」ではダメ
コードを仕様書にするために
告知「第1回 DOA+関西分科会」
「動かすまでの手間」の小さいソフトに
アジャイルの人たちは自分の優秀さに気づいていない
古いデータの一括削除処理を設計する
「DB構造の前にUIを決める」というアンチパターン
ナチュラルキーを主キーにしてはいけない
「個性的な機能」の病理
「要件定義」に何週間もかける?
DDD:ドメインをメタ方向へずらす
「プログラミングへのこだわり」を方向づける
レファレンスモデルで社会貢献を
プログラマの地位向上のためにやれること
企業システムに現れるフラクタル構造
「仮想DB」としての開発用プラットフォーム
プログラミングは前後の工程を侵襲しつつ変化してゆく
DB設計が楽しくなければたぶん失敗している
開発効率化のための基本戦略「類型化」
設計とプログラミングの互換性
さらば「方眼紙エクセル仕様書」
「DB構造を見直さない」というアンチパターン
「帳簿組織の育成」としてのシステム開発
大震災
メニューは「権限のインタフェース」である
残高テーブルの設計と統計処理
「動作確認済モデル」でアジャイル開発
敵は「スクラッチ開発」にあり
取引実績テーブルの設計と仕訳
■2011

「無限に広がる大宇宙」のコード進行
さようなら「画面ファイル」
スタンプ属性や更新履歴テーブルの無駄っぽさ
個別案件にオブジェクト指向は要らない
「Smart UI」から「Smart DB」へ向かう道も険しい
11/6,KOF2010にてユーザ企画講演
「アジャイル開発の進め方」はもう聞き飽きた
技術者にリフレッシュ休暇を「強制」せよ
「複合キー」と実装用フレームワーク
会計システムのクラウド化と税理士事務所
ウォーターフォールがなくならない理由
8/18新大阪で勉強会兼飲み会のお知らせ
プログラミングのボトルネックは「感情」
「簿記と業務知識のセミナー」開催
「ドメイン駆動開発」への素朴な疑問
「周辺機能」はありきたり・安普請でいい
「上流工程入門セミナー」開催します
名古屋でやります。XEAD Driver発表会 5/28(金)
XEAD Driver発表会 4/23(金)東京
クラウドと基幹システム
オブジェクト指向とイパネマの娘
アプリケーションドライバ発表会(3/26,Fri)
キレイなコードでも仕様書の代わりにはならない
妥当性検査をDB側に集約する
サブシステムを「使い捨てる」ためのアーキテクチャ
DOAは自動生成の夢を見るか
■2010

酸素濃度と進化爆発と技術革新
続・仕様書でシステムが動く時代へ
仕様書でシステムが動く時代へ
「個別案件」ではプログラミングの可能性を生かせない
「動的参照関係」を手なづける
スクリプトエンジンの可能性
システム業界向け「モデルハウス」開発快調
設計者がひとりで実装できる時代に
詳細設計に吸収されるプログラミング
ツール開発には変人が必要である
フレームワークはオブジェクト指向を隠蔽する
■2009

「ユース・ファースト」なシステム開発
XEADで設計書出力
「国民健康保険」のデータモデル
「特別給付」のデータモデル
8/26に東京で講演します
XEAD、今後の展開
全テーブルが載っているデータモデルは便利か
システム開発の最終兵器「オープンパッケージ」
新刊「販売管理システムで学ぶモデリング講座」
自治体システムのレファレンスモデル
卸売業でも「ロット管理」は常識
■2008

講演「方法論の時代からサンプルライブラリの時代へ」
フィーチャオプションと部品表
パネルの画像ファイルも扱えるXEAD
生産管理システムのレファレンスモデル近日公開
インポート機能をさっそくバージョンアップ
XEADでリバースエンジニアリング
「コピペでシステム設計」の功罪
ブログ2周年・週次から不定期に
「CONCEPTWARE/販売管理」をバージョンアップ
高い心肺能力でもカゼ
内部記述から外部記述へ
「XEADインテグレータ」の開発
「わかりやすいシステム」のためにオーディションを
「定義すること」が苦労の始まり
仲間意識にもとづく残業
販売管理システムの「会計3要素」
成人式で初演奏
「その商品をどう活用してますか?」と問う
■2007

アナログ人間ほどコンピュータに向いている
「何かと便利」な設計方針?
モデリングのスタイル:意味論と統辞論
優れたツールが備える「BDT特性」
自由裁量は有能さを映し出す鏡
変化と共存するために在庫推移を監視する
パッケージ選定のカギはデータモデル
金型プログラマと製品プログラマと
異質なものなんて愛せない
販売管理向けのレファレンスモデルを公開
包丁とバーナーは男のたしなみである(かも)
「押しかけ実況書記」のススメ
購買のポイントは「安さ」よりも「納期の信頼感」
少人数開発と「能力プール」
明細集計処理と富豪的システム設計
「オーバースペック」でコストが下がる話
テーブル関連を「コード」で構成することの是非
代理キーは「スタイル」ではなく「テクニック」
関数従属性は多重度に先行して認識される
在庫引当から在庫推移へ(後編)
在庫引当から在庫推移へ(前編)
老人ホームでミニコンサート
文章術:断言して根拠を示す
拡散思考と集中思考のバランスをはかる
新刊書の校正作業完了
「アジャイル開発」に先行して「アジャイル分析設計」を
フィットネスで発電
システム開発のフロントローディング
集中するためにオフライン環境へ
DOA+で「科目履修管理」をお披露目
「科目履修管理」のレファレンスモデルが登場
書評「一万年の旅路」
オープンソースと「オープンデザイン」が出会うとき
Ajaxで業務マニュアルサーバ
機能モデルのデータモデル
業務マニュアルのデータモデル
業務マニュアルの作り方
「お風呂本」は気宇壮大をもってよしとす
データモデル上の「行番号」とは何か
家計における「資本勘定」とは(後編)
家計における「資本勘定」とは(前編)
万感の想いをこめて「めだかの学校」を弾く
データモデルのデータモデル
けっきょくすべてが「SE本」
システム要件を捉えるために必要な「疑り深さ」
システムの設計と施工を分離する
システム開発にもセカンドオピニオンを
「対照勘定」はサブシステムをつなげる接着剤
統一感を取るかわかりやすさを取るか
振込手数料と消費税の仕訳
■2006

売掛金と消費税の仕訳
プログラマではなくテスターとして現場デビューする
プロセス論の時代からコンテンツの時代へ
システムの論理設計を構造化するための視点
要件を要件として深追いしてはいけない
分析設計手法のスタイルとオフショアの脅威
ユーザがなかなか仕様を決めてくれないって?
ホワイトボードの前でどれだけジタバタできるか
心楽しい無間地獄へ
事務仕事の現場は「情報処理工場」である
わかりやすさと論理性を両立させる(後編)
わかりやすさと論理性を両立させる(前編)
複数の視点で描かれた図面同士の牽制が重要
業務単位は「疎結合」されている
MIDIソフト「ソルファノート」公開
「設計情報の構造」に現れる設計品質
詳細設計とコーディングの融合
レガシーの呪いを解くには勇気が必要だ
XEADの国際版が登場
だんだん良くなるレファレンスモデル
川が流れるように過ぎていった日々をコミットする
「CONCEPTWARE/財務管理」は無償で公開
「実装独立」な設計をまとめるのは誰か
「実装独立」な設計を用意することの意義
ビジネスリーダーに必要な「経営の3言語」
モデルにインスタンスを併記できることの意味
ホワイトカラーの仕事をカイゼンするために
ピーター・ガブリエルの家でゴチになった話
会計システムのアーキテクチャ論
バカもハサミもバカなコダワリも使いよう
かすれたマーカーを使わされる拷問
職業選択と「不快感」
経営革新をやれるというシステム屋のうぬぼれ
XEADのXは、XMLのX
システム設計に求められる適性
会計システムにオトシマエをつける
「As-is先行」か「To-be先行」か
「スクラッチ開発」という名のゴムボート
「関連クラス」をデータモデルで解き明かす(後編)
「関連クラス」をデータモデルで解き明かす(前編)
モデリングセッションに必要な能力「共感力」
設計ノウハウの占有による優位性のあやうさ
ウンザリするほど面白い簿記の「帳簿組織」
失業・転職は「簿記」習得の大チャンス
いつまでもプログラミングを楽しむために
システム設計は「成果物を他人にジロジロ見られるハズカシイ仕事」
「実用と鑑賞に堪えるモデル作品」を待望する
タイトル「設計者の発言」の由来
■2005