« 「アジャイルソフトウェアエンジニアリング」におけるプロダクトバックログの考え方 | トップページ | EVMとバーンダウンチャートは本質的に違う »

2012/05/12

チケット管理は商品管理のモデルと同等なのか

RedmineでWebショップの商品管理を実現した記事を見つけたのでメモ。

【元ネタ】
Redmine でWEBショップの商品管理をしてみる | まったり覚書

(引用開始)
$REDMINE_HOME/config/locales/ja.ymの文言をそれっぽく修正します。
プロジェクト→ショップ
チケット→商品
作業時間、時間→売上
トラッカー→商品種別
バージョン、ロードマップ→納品計画
ワークフロー→商品の流れ
開始日→納品日
期日→回収日
題名→商品名
予定工数→売上目標
時間を記録→売上(税込)
報告したチケット→登録した商品
(中略)
1. 作業時間を金額として利用する場合に、そのままだと1000までしか入力できないので、桁数のチッェクを外します。
2. 時間表示部分を金額表示に変更します。
(中略)
ステータス(商品の状態)とワークフローを商品管理っぽく設定します。
使いそうなカスタムフィールド(納品先、納入価格など)を追加します。
扱う商品種別(トラッカー、例:アクセサリなど)を設定します。
商品のカテゴリ(チケットのカテゴリ)を設定します。
(引用終了)

面白い点は、プロジェクト管理ツールの概念を商品管理のモデルに変換できるという事実だ。
チケットを商品と同じ概念とみなした場合、チケットの各属性は商品の属性に置き換えられる。

チケットNo→商品ID
題名→商品名
説明→商品の説明
開始日→納品日
終了日→回収日
カテゴリ→商品の分類
ステータス→商品の状態(未納品、納品準備中、納品済、販売済、入金済、返品)
トラッカー→商品の種別(アクセサリ、雑貨、家電AV、パソコン)
バージョン→毎月の締め日
予定工数→売上目標
実績工数→日々の売上

つまり、工数集計の機能が売上集計の機能に置き換えることもできるだろう。

UMLモデリングの本質」では、アナリシスパターンの勘定パターンが在庫モデルに適用できることを説明しているが、それは、会計と在庫という概念モデルとしては性質が異なるはずなのに抽象的なモデルでは構造が似ていることを意味している。
同様に、チケット管理のモデルも商品管理とモデル的に同等なのかもしれない。

チケット管理のモデルは、基本はデータを蓄積するモデルだと思う。
イメージは、大量のチケットが蓄積される仕組みが前提であり、その蓄積された情報をガントチャート・タスクボード・バーンダウンチャートなどの各種ビューで分析できる仕組みを提供するモデル。
これはいわゆる情報系システムと同じ構造だと思う。

商品管理の場合、毎月の売上集計が単に蓄積されていくだけならば、チケット管理のモデルと同じ。
だが、商品管理に会計モデルの概念を導入すると、フロー(売上・費用)だけでなくストック(資産・負債)という概念も出てくるので、チケット管理の仕組みだけでは実現できない部分も出てくるだろうと思う。

エリック・エヴァンスのドメイン駆動設計の本では、船舶の輸送モデルをドメイン分析していくと船荷証券(つまり荷為替手形ないし未着品)のような概念が出てきた例や、利息サービスの計算をドメイン分析していくと発生主義会計(つまり経過勘定科目、例えば未払利息や受取利息など)の概念が出てきた例が載っている。
それらが意味するのは、プログラムやシステムという実在の動く論理モデルを抽象化すると、以前から知られている概念と同等になるということなのだろう。
すると、ドメイン駆動設計とは、システムのアーキテクチャをビジネスで知られている概念に結びつけて、本質的な意味を与えるものなのかな、とか思ったりする。

Agile開発に足りないもの~モデリング技術: プログラマの思索

【告知】SEA関西ではOOA、関西IT勉強宴会はDOAの勉強会あります: プログラマの思索

広中平祐著の「学問の発見」の一節に、フィールズ賞を受賞した業績である定理を証明する時、恩師の方から、問題をもっともっと難しくして理想的な形にすれば解けますよ、とアドバイスされたそうだ。
我々IT技術者も、現実のビジネスモデルを抽象化したモデルにマッピングして設計していく時、違う業界のモデルが同等に見えるレベルまでどんどん抽象化していくのがいいのかもしれない。

【追記】
@hino666さんのつぶやきから、平鍋さんが以前説明されていたモデルの4象限を思い出した。
問題→解へいきなり解くには難しい場合、問題→分析モデル→設計モデル→解の道に進む方法もある。
モデリングは、児玉公信さんが言われている「モデルの揺さぶり」が大事だと思う。
作ったモデルに対して、色んな仕様変更を想定しながらモデルをより汎用的に抽象化して、洗練させていく。

Twitter / @hino666: 具象(業務問題) →抽象(モデル) →具象(解決システム) ≫ チケット管理は商品管理のモデルと同等なのか: プログラマの思索 http://forza.cocolog-nifty.com/blog/2012/05/post-67d5.html

Twitter / @masayh: 分析モデル、設計モデル、実装モデルの違いは平鍋さんのブログをご覧ください。http://blogs.itmedia.co.jp/hiranabe/2010/12/vsug-architect.html アーキテクトの思考法にもなっている非常に重要なものです。4象限の絵。

VSUG アーキテクトアカデミーで講演しました:An Agile Way:ITmedia オルタナティブ・ブログ

|

« 「アジャイルソフトウェアエンジニアリング」におけるプロダクトバックログの考え方 | トップページ | EVMとバーンダウンチャートは本質的に違う »

Redmine」カテゴリの記事

チケット駆動開発」カテゴリの記事

モデリング」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« 「アジャイルソフトウェアエンジニアリング」におけるプロダクトバックログの考え方 | トップページ | EVMとバーンダウンチャートは本質的に違う »