在庫推移監視方式にみるDOAのアプローチ #benkyoenkai
生産管理再入門-MRPを超えて <第43回IT勉強宴会> に参加しました。
メインの話題は在庫推移監視方式(Stock Projection Monitoring)で、その基本と事例の紹介でした。在庫推移監視方式はMRP(所要量計算)方式がバッチで処理するところを、手作業を前提とする事でリアルタイム処理する方式です。
在庫推移監視方式について
在庫推移監視方式は(1)新たな発注などの入出庫予定の変動があった際に、MRPは、(2)所要量の計算、(3)受払予定の再編成、(4)在庫推移の再計算、(5)推移以上の対応までバッチ行います。
しかし、実際は在庫を見たいだけなのに、(1)の入出庫予定の変動があるたびにバッチを実行しているユーザが多いそうです。そこで在庫推移監視方式は(2)と(3)だけをリアルタイムで行うことで、在庫の状況を確認できる様にしています。
在庫推移監視方式の事例
事例では、受注と発注の担当者を同じ組織にすることで、MRPがルールで行うことを人間によって調整できる様にしています。これによって、ムダに生産や在庫することが無い様に稼働を調整しているそうです。
在庫管理のポイントは、DB設計、方式設計、組織設計、工程負荷だそうですが、 在庫推移監視方式にあわせて組織設計までされたようです。
お話で興味深かったのは、在庫推移監視方式を知って実践したのではなく、実践してからそれが在庫推移監視方式であることに気付いたそうです。GoF本が出た時に「前からやっていた」という人がおられましたが、良いパターンは誰もがたどり着くものなのでしょうね。
そしてそのパターンを見いだして命名された渡辺幸三さんは、生産管理というドメインを極めたスパーエンジニアなのでしょうね。
在庫推移監視方式は方式設計?
在庫推移監視方式は方式設計ではないかということです。ドメイン分析の様に見えながら、実はリアルタイム処理かバッチかという方式まで決めています。
同じような感じは、ライブモデリングの時にもしました。データモデリングのようなのですが、理由を問われると「こんな有力画面を考えているんですよ」と答えられていました。
データモデリングと言いながら、画面設計もある程度できていたのです。DOAは常に実装と繋がっているのだと思います。
DOAのアプローチ
渡辺幸三さんは、ドメイン知識はDDDがいうような汎用的な方法では獲得が難しく、ドメイン専門家にならないといけない、といった主旨のお話をされていました。今回の在庫推移監視方式は専門的な経験があるからこそ、できる事なのでしょう。
DOAのアプローチはどちらかというと業務分析に始まるトップダウンアプローチです。でも、実装がどうなるかを意識していないと動くシステムは作れません。
たぶん、DOAはその溝を業務固有のデザインパターンでつないでいるのだと思います。今回は在庫推移監視方式というパターンでしたが、それ以外にも多くのパターンがあり、その獲得がドメイン専門家になるという事であると思いました。
« [#TiDD] ウォータフォール型開発の問題点とチケット駆動開発 #seakansai | トップページ | [#UAS] アジャイル開発とフィードバックそしてリスク - Ultimate Agile Stories Iteration 5 - »
「ソフトウェア」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- 論文研修会(導入編)- 論理的思考のすすめ -(2019.12.01)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
「プログラミング」カテゴリの記事
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 論理的に考え伝える – SEA関西「開発現場で役立つ論文の書き方のお話」 -(2021.05.09)
- 論文研修会(導入編)- 論理的思考のすすめ -(2019.12.01)
- スクリプト言語入門 - シェル芸のすすめ - 第2回クラウド勉強会(2019.01.27)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
« [#TiDD] ウォータフォール型開発の問題点とチケット駆動開発 #seakansai | トップページ | [#UAS] アジャイル開発とフィードバックそしてリスク - Ultimate Agile Stories Iteration 5 - »
コメント