記事
はてなブログに引っ越しオブジェクト指向開発もローコード開発も楽しい
「新型コロナワクチン接種管理システム」のデータモデル公開
IT技術者の分類名「WEB系」の奇妙さ
データモデルの変化を抱擁せよ
実装について学ぶこと大杉問題
交響曲はアジャイルに収録できない
業務システムとマイクロサービス（２）
業務システムとマイクロサービス（１）
人数ではなく技能を確保するためのシフト管理システム公開
システム設計のスキルは「掛け算」で作用する
データモデリングの上達には「事例研究」が不可欠
開発者が自動化に負けないためのたったひとつの方法
サロゲートキーにこだわるデータモデルの異様さ
「仕様の妥当性とフィージビリティ」でデスマーチを回避
デスマーチは「失敗」ではないゆえに繰り返される
「真面目で仕事熱心」が業務の合理化を阻む
OOUIは強力だが、合理的なDB構造を導くわけではない
Railsは新人教育に向いていない
自治体向け給付金管理システムのプロトタイプ大競演
SQLの前に「DB設計」を身につけよう
「10万円給付」のためのレファレンスモデルを公開
実装スキルと業務知識のバランスをはかる
「フィーチャ・オプション」のモデルと実装
Modelerの学習用動画と新刊のお知らせ
「ラグビーＷ杯」をモデリングしよう
骨格→筋肉→皮膚の順序で仕様を決めよう
部門と従業員のデータモデリング
開発者が「コード体系」に関与する必要はない
「危ないデータモデル」の定量的判定基準
総合プログラマではなく専門プログラマになろう
NoSQLでもデータモデリングが必要
「発効日」を主キーに含むデータモデル
システム開発企業のスリム化戦略
「試算表テーブル」を設計する？
予算テーブルと実績テーブルを分ける？
「技術者とのコネ」で決まる開発の成否
打ち合わせの真ん中にモデルを置こう
「優先順位づけ」は重要なエンジニアリングスキル
システム開発者の給料が安すぎる理由
省庁向けモデリングライブの効果
DB構造の悪さが事業の足をひっぱる
少数精鋭でやれない場合にどうするか
オリンピックをモデリングしよう
Excel仕様書を機能タイプ別に様式化する
仕様の「見える化」と働き方改革
新人にオブジェクト指向の魅力を知られてはいけない
対談イベントのお知らせ
DB設計がマトモであれば何とかなる
UML版在庫データモデルの問題
業務システムを「牢獄」にしないために
内製の前に「自社保守」を目指そう
顧客も業者によって値踏みされる
超高速開発とアジャイルの違い
DB開発とアプリ開発を分離せよ
システム開発ライブのお知らせ
業者の設計スキルをハダカにする
おそ松なデータベース
クラス図とデータモデルはどうちがう？
危うい「プロセス指向」が廃れない理由
図表と箇条書きばかりで文章が足りない
「わかりやすさへのこだわり」があるか
システム設計と創造性
データモデリングの達人技を盗め、温泉で
「ＤＤＤ批判」への批判
「オブジェクト指向」や「アジャイル」では食えない
制限時間１時間で実装せよ（7/29,東京）
単独主キーでもDB設計は楽にならない
「モデリング＆プロトタイピング手法」事例紹介
「単独主キー専用環境」と賢くつきあうために
文章術：「改行」を自覚的に用いる
ORマッピングの功罪
仕様変更にも良し悪しがある
「命名標準」に振り回されないために
「科学研究」としてのシステム開発
「他人にとってのわかりやすさ」が至上の価値である
ALTER文の自動生成機能
開発手法と「クリティカル・スキル」
タコヤキ業務にタコヤキテーブルは必要か
「趣味はシステム設計」くらい言えていい
「WEBサービスで稼ぐ企業の業務システム」のモデリング
「仕様の的確さ」と「アプリ品質」のバランスをはかる
アジャイルではなく「プロトタイピング」を
開発案件の「適正サイズ」を考える
ER図レビューの３つのポイント
「外部設計・内部設計」の危うさ
ドメイン特化基盤の柔軟性を高める
X-TEA Driverの英語版登場
「EXCEL仕様書からコード生成」のアンバランス
正規化崩しの目的は「高速化」だけではない
レコードの変更予約管理を合理化する
適用分野と実装手段の組み合わせ戦略
「論理削除」ではなく「無効化」を
拡大・縮小する前に美しいER図を
フレームワークとドメイン特化基盤
X-TEA Driverが1.3にリリースアップ
テーブル操作と業務ロジックの連動制御
業務ロジックをアプリに置いてはいけない
機能タイプ＆テーブルポジションで効率アップ
マイクロサービスと基幹システムの本質
マイクロサービスで周辺アプリと連係する
値の変更が制限される項目「強属性」について
ドメイン特化基盤がドメインを豊かにする
「論理設計」にこだわる利点
DBの複雑さとアプリの複雑さ
基本設計を分担してはいけない
設計情報のバージョン管理を合理化する
「八合目キャンプ」からのアジャイル
モデリングツールとExcel仕様書の合わせ技
DDDの前に専門性を身につけよう
入出力定義と「非対話型業務」の関係
動くシステムを営業段階で示せるか
XEADがX-TEAとして再登場
データモデルはドメインモデルに先行する
ビブリオバトルで蘇我入鹿を語る
システムモデルを事業別に分割する
「プログラミングの専門家」でも「ツールの専門家」でもなく
ベンチマークとしてのレファレンスモデル
XEAD製品がJava1.8に対応
モデリングの標準問題から学べること
モデル駆動開発勉強会(4/25@東京)で語ります
「フィールドの更新不可制約」の必要性
ドメインの階層化とDSP
「CONCEPTWARE／受注生産」の実装版が完成
新人技術者にはOOPLの前にDSLを
「ドメイン・エキスパート」になろう
データモデルの静と動
セミナーとモデリングライブのお知らせ
アプリの類型における処理テーブルの形式化
データ指向設計・開発の実践
「だるいコーディング」を駆逐した後に残る仕事
システム変数とシステム区分の設計
XEAD Modelerがベクター出力に対応
エンタープライズ・アジャイル：手法論より大事なもの
既存システムをハッキングする
自由であるためにドキュメントを作る
「何を使って設計書を書いていますか？」と尋ねよう
テーブル関連の「排他性」をモデル上で表現する
ドキュメントの山で遭難しないために
ユニーク制約の使いどころ
主キーはインデックスではない
ボトルネックは「業務系スキル」
データとして登録されるビジネスルール
「大規模集積回路モデル」と「板チョコモデル」
告知：「受注生産」のためのシステム開発ライブ
フィールドIDが全角日本語であることの意義
「シンプル・イズ・ベスト」はややこしい
システム化の恩恵を中小企業へ
システム開発は「セル生産方式」になる
問題領域とコンピュータの狭間で
DBMSの交換容易性と開発基盤
ソフト開発に資材が要らないことの優位性
設計支援ツールとマルチユーザ対応
フォントを替えて設計・開発を快適に
オブジェクトモデリングとデータモデリング
システムの「基盤交換性」を見極める
取引先にEDI用Webサービスを提供する
ドキュメント不整合問題の様相
良単価・準委任で契約するためにできること
コンテキスト・ダイアグラムを描こう
システムの仕様情報を正規化する
「仕様書プログラミング」とその運命
複合主キー「否定派」と「許容派」の論争
仕様書の類型化と様式化
「逆方向バリデーション」との付き合い方
トレーサビリティを確保するための便法
「営業カレンダー」のモデリング
「仕様書で駆動される生産管理システム」公開
超高速開発ではなく「超少人数開発」を
CRUD図をわざわざ作る？
アジャイル手法は分野毎に違っていい
売上計上基準の設計と実装
「品番変換」のモデリング
「売上伝票」を問い直す
アンチパターン「成長する主キー」
製造指示の設計と実装 (3)外作
もう「チーム開発」には戻れない
製造指示の設計と実装 (2)開始と完了
サロゲートキーと「とりあえずID」の違い
製造指示の設計と実装 (1)日程化
生産管理オタクは3/30に浜松へ！
業務フローとER図を3D化してみた
DDLレベルの外部キー制約は不要
モデル駆動(MDA)から仕様書駆動(SDA)へ
システム開発のHowToではなくWhatを
SQLを使わないでシステム開発
BOMプロセッサの開発完了
各種技法の「競演モデリングライブ」を
梱包形態のモデリングと加工出荷
部品表をツリービュー表示する
「丸投げ請負」から「内製支援」へ
「データモデリングライブ＠名古屋」報告
「恥ずかしさ」で設計品質を高める
「データモデリングライブ＠名古屋(11/24)」のお知らせ
部品表とフィーチャ･オプション
１レコード多段表示一覧に対応
概念モデルと論理モデルの違い（後編）
概念モデルと論理モデルの違い（前編）
「生産管理」で業務知識の学びを効率化しよう
「データモデリングライブ＠渋谷」報告
実装スキルと業務知識を統合するために
動くソフトウエアを作る前にアジャイルモデリングを
「データモデリングライブ＠渋谷(9/29)」のお知らせ
デザインパターンそのものをプログラミングする
業務システム向けのデザインパターン
「データモデルなきアジャイル」の危うさ
データ中心アプローチと「業務モデル」
「業務マニュアル」と「操作マニュアル」の違い
アンチパターン「大規模集積回路モデル」
「フィールド値の色」をテーブル定義に組み込む
特定ドメイン向け開発環境の意義
Excel方眼紙がダメな２つの理由
ＤＢ設計セミナー開催します(東京7/30-31)
フィールド数のメトリクス
たったひとりで踊るために
人海戦術から「おひとりさま開発」の時代へ
ＶＰＳでクラウド基幹システムを作ってみた
あんまりプログラミングしないけどアジャイル
「印刷物を眺めながらの仕事」の衰退と罪深さ
Facebookから脱退
「モデル」としての仕様書
サロゲートキーの日常性と心得之条
「てにをはレビュー」の是非
ブラウザアプリと３階層型デスクトップアプリ
成果物のサイズとシステムの保守性
危ういデータモデルを見破るコツ
自治体システムは日本に１個あればいい
セット商品の原価と在庫推移
逆方向バリデーションを自動化する
マスターテーブルと「有効期間」
開発基盤のトリガーとＤＢＭＳのトリガー
ショボいＤＢ設計で突っ走るための５０の方法
サロゲートキーの事例解説
「強制されたサロゲートキー」の事例を眺める
サロゲートキーは強制されるべきものではない
ＤＢＭＳの方言を開発基盤で吸収する
バリデーションの双方向性問題を解く
企業システムの基本構造を理解しよう
動的参照関係を「宣言的」に扱えるか
「有効期間」を含むテーブルとの参照関係
「自動生成」と「動的制御」
ＳＩ企業が「モデルシステム」を公開しない理由
在庫ＤＢにおける「正規化崩しの報い」
業務システムとＷＥＢサービス
語られないアーキテクチャの謎
「アジャイルなスクラッチ開発」ではダメ
コードを仕様書にするために
告知「第１回 ＤＯＡ＋関西分科会」
「動かすまでの手間」の小さいソフトに
アジャイルの人たちは自分の優秀さに気づいていない
古いデータの一括削除処理を設計する
「ＤＢ構造の前にＵＩを決める」というアンチパターン
ナチュラルキーを主キーにしてはいけない
「個性的な機能」の病理
「要件定義」に何週間もかける？
ＤＤＤ：ドメインをメタ方向へずらす
「プログラミングへのこだわり」を方向づける
レファレンスモデルで社会貢献を
プログラマの地位向上のためにやれること
企業システムに現れるフラクタル構造
「仮想ＤＢ」としての開発用プラットフォーム
プログラミングは前後の工程を侵襲しつつ変化してゆく
ＤＢ設計が楽しくなければたぶん失敗している
開発効率化のための基本戦略「類型化」
設計とプログラミングの互換性
さらば「方眼紙エクセル仕様書」
「ＤＢ構造を見直さない」というアンチパターン
「帳簿組織の育成」としてのシステム開発
大震災
メニューは「権限のインタフェース」である
残高テーブルの設計と統計処理
「動作確認済モデル」でアジャイル開発
敵は「スクラッチ開発」にあり
取引実績テーブルの設計と仕訳
「無限に広がる大宇宙」のコード進行
さようなら「画面ファイル」
スタンプ属性や更新履歴テーブルの無駄っぽさ
個別案件にオブジェクト指向は要らない
「Smart UI」から「Smart DB」へ向かう道も険しい
11/6,KOF2010にてユーザ企画講演
「アジャイル開発の進め方」はもう聞き飽きた
技術者にリフレッシュ休暇を「強制」せよ
「複合キー」と実装用フレームワーク
会計システムのクラウド化と税理士事務所
ウォーターフォールがなくならない理由
8/18新大阪で勉強会兼飲み会のお知らせ
プログラミングのボトルネックは「感情」
「簿記と業務知識のセミナー」開催
「ドメイン駆動開発」への素朴な疑問
「周辺機能」はありきたり・安普請でいい
「上流工程入門セミナー」開催します
名古屋でやります。XEAD Driver発表会 5/28(金)
XEAD Driver発表会 4/23(金)東京
クラウドと基幹システム
オブジェクト指向とイパネマの娘
アプリケーションドライバ発表会(3/26,Fri)
キレイなコードでも仕様書の代わりにはならない
妥当性検査をＤＢ側に集約する
サブシステムを「使い捨てる」ためのアーキテクチャ
ＤＯＡは自動生成の夢を見るか
酸素濃度と進化爆発と技術革新
続・仕様書でシステムが動く時代へ
仕様書でシステムが動く時代へ
「個別案件」ではプログラミングの可能性を生かせない
「動的参照関係」を手なづける
スクリプトエンジンの可能性
システム業界向け「モデルハウス」開発快調
設計者がひとりで実装できる時代に
詳細設計に吸収されるプログラミング
ツール開発には変人が必要である
フレームワークはオブジェクト指向を隠蔽する
「ユース・ファースト」なシステム開発
ＸＥＡＤで設計書出力
「国民健康保険」のデータモデル
「特別給付」のデータモデル
８／２６に東京で講演します
ＸＥＡＤ、今後の展開
全テーブルが載っているデータモデルは便利か
システム開発の最終兵器「オープンパッケージ」
新刊「販売管理システムで学ぶモデリング講座」
自治体システムのレファレンスモデル
卸売業でも「ロット管理」は常識
講演「方法論の時代からサンプルライブラリの時代へ」
フィーチャオプションと部品表
パネルの画像ファイルも扱えるＸＥＡＤ
生産管理システムのレファレンスモデル近日公開
インポート機能をさっそくバージョンアップ
ＸＥＡＤでリバースエンジニアリング
「コピペでシステム設計」の功罪
ブログ２周年・週次から不定期に
「CONCEPTWARE/販売管理」をバージョンアップ
高い心肺能力でもカゼ
内部記述から外部記述へ
「ＸＥＡＤインテグレータ」の開発
「わかりやすいシステム」のためにオーディションを
「定義すること」が苦労の始まり
仲間意識にもとづく残業
販売管理システムの「会計３要素」
成人式で初演奏
「その商品をどう活用してますか？」と問う
アナログ人間ほどコンピュータに向いている
「何かと便利」な設計方針？
モデリングのスタイル：意味論と統辞論
優れたツールが備える「ＢＤＴ特性」
自由裁量は有能さを映し出す鏡
変化と共存するために在庫推移を監視する
パッケージ選定のカギはデータモデル
金型プログラマと製品プログラマと
異質なものなんて愛せない
販売管理向けのレファレンスモデルを公開
包丁とバーナーは男のたしなみである（かも）
「押しかけ実況書記」のススメ
購買のポイントは「安さ」よりも「納期の信頼感」
少人数開発と「能力プール」
明細集計処理と富豪的システム設計
「オーバースペック」でコストが下がる話
テーブル関連を「コード」で構成することの是非
代理キーは「スタイル」ではなく「テクニック」
関数従属性は多重度に先行して認識される
在庫引当から在庫推移へ（後編）
在庫引当から在庫推移へ（前編）
老人ホームでミニコンサート
文章術：断言して根拠を示す
拡散思考と集中思考のバランスをはかる
新刊書の校正作業完了
「アジャイル開発」に先行して「アジャイル分析設計」を
フィットネスで発電
システム開発のフロントローディング
集中するためにオフライン環境へ
ＤＯＡ＋で「科目履修管理」をお披露目
「科目履修管理」のレファレンスモデルが登場
書評「一万年の旅路」
オープンソースと「オープンデザイン」が出会うとき
Ａｊａｘで業務マニュアルサーバ
機能モデルのデータモデル
業務マニュアルのデータモデル
業務マニュアルの作り方
「お風呂本」は気宇壮大をもってよしとす
データモデル上の「行番号」とは何か
家計における「資本勘定」とは（後編）
家計における「資本勘定」とは（前編）
万感の想いをこめて「めだかの学校」を弾く
データモデルのデータモデル
けっきょくすべてが「ＳＥ本」
システム要件を捉えるために必要な「疑り深さ」
システムの設計と施工を分離する
システム開発にもセカンドオピニオンを
「対照勘定」はサブシステムをつなげる接着剤
統一感を取るかわかりやすさを取るか
振込手数料と消費税の仕訳
売掛金と消費税の仕訳
プログラマではなくテスターとして現場デビューする
プロセス論の時代からコンテンツの時代へ
システムの論理設計を構造化するための視点
要件を要件として深追いしてはいけない
分析設計手法のスタイルとオフショアの脅威
ユーザがなかなか仕様を決めてくれないって？
ホワイトボードの前でどれだけジタバタできるか
心楽しい無間地獄へ
事務仕事の現場は「情報処理工場」である
わかりやすさと論理性を両立させる（後編）
わかりやすさと論理性を両立させる（前編）
複数の視点で描かれた図面同士の牽制が重要
業務単位は「疎結合」されている
ＭＩＤＩソフト「ソルファノート」公開
「設計情報の構造」に現れる設計品質
詳細設計とコーディングの融合
レガシーの呪いを解くには勇気が必要だ
ＸＥＡＤの国際版が登場
だんだん良くなるレファレンスモデル
川が流れるように過ぎていった日々をコミットする
「ＣＯＮＣＥＰＴＷＡＲＥ／財務管理」は無償で公開
「実装独立」な設計をまとめるのは誰か
「実装独立」な設計を用意することの意義
ビジネスリーダーに必要な「経営の３言語」
モデルにインスタンスを併記できることの意味
ホワイトカラーの仕事をカイゼンするために
ピーター・ガブリエルの家でゴチになった話
会計システムのアーキテクチャ論
バカもハサミもバカなコダワリも使いよう
かすれたマーカーを使わされる拷問
職業選択と「不快感」
経営革新をやれるというシステム屋のうぬぼれ
ＸＥＡＤのＸは、ＸＭＬのＸ
システム設計に求められる適性
会計システムにオトシマエをつける
「As-is先行」か「To-be先行」か
「スクラッチ開発」という名のゴムボート
「関連クラス」をデータモデルで解き明かす（後編）
「関連クラス」をデータモデルで解き明かす（前編）
モデリングセッションに必要な能力「共感力」
設計ノウハウの占有による優位性のあやうさ
ウンザリするほど面白い簿記の「帳簿組織」
失業・転職は「簿記」習得の大チャンス
いつまでもプログラミングを楽しむために
システム設計は「成果物を他人にジロジロ見られるハズカシイ仕事」
「実用と鑑賞に堪えるモデル作品」を待望する
タイトル「設計者の発言」の由来