「データモデルなきアジャイル」の危うさ - 設計者の発言
例によってこれは「業務システム」に関する議論である。ゲームソフトでも組込み系でもＢ２Ｃサイトでもサービス系でもなく、販売管理システムや生産管理システムといった基幹系業務支援システム（ＤＢ構造が複雑なシステムといってもいい）に限った話だ。その種のシステムをアジャイル開発しようと考えるのであれば、それまでにシステム全体の「あるべきデータモデル」が確立されていなければならない。 業務システムを「身体」に喩えるなら、データモデルは「骨格の設計図」に相当する。いっぽうアジャイル開発で導き出せるのは身体の表面上の諸問題、すなわち「皮膚のぐあい」とか「顔つき」のようなものだ。そういった特徴についていかに緻密に決定できても、それらから「あるべき骨格の姿」は導けない。 ＤＢ構造のそういった特性を公知させたのが、前回記事で説明した「ＤＯＡ（データ中心アプローチ）」だった。機能のあり方を確立したうえでデータのあ
要求定義の方法論を知る【前編】：DOA型要件定義の実際
日本IBMのシステム開発プロジェクトで多くの実績を持つDOA（データ中心型アプローチ）型の要件定義手法を解説する。「いまさらDOAか」と思う読者もいるかもしれない。しかし，DOAはあらゆるプロジェクトに応用できる極めて基本的なアプローチである。基本をしっかりと押さえて欲しい。 「いつまでたってもユーザーインタフェースが決まらない」，「設計の段階で機能が追加され，開発範囲が膨れ上がった」，「テスト段階に入ってからも仕様変更が多発する」，「システム・テストの中盤でデータベースが変更され，すべてのテストをやり直さなければならない」…。システム開発ではこうした声があちこちのプロジェクトで聞かれる。なぜこのような状況がいつまでも改善できないのか。結論から言えば，これは要件定義のやり方にそもそもの問題がある。 本来システム開発プロジェクトでは，予算，期間，開発の優先順位に見合った最適なスコープ（開発範
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
