PxQで計算するということ
某プロジェクトが一旦のキリがついたので、ちょっと今までの経験とかまとめてをupdateしておきます。
これから記す内容は、実際のモノをハンドリングする業務ITについて、特にそのデザイン（設計）のポイントについての考え方です。一応、検討の範囲外にあるものは、モノそれ自体よりもその情報に本来的な価値があるような財・サービスになります。例えば金融。（実はあまり違いはない、という話もありますが、相対的に曖昧な部分があるのは事実だと思うので、一応除外しておきます。）
まず、いきなり要諦ですが、そもそも業務系のシステムや仕組みを設計するときの最大のポイントの一つは、「PxQを分けて管理し、どの時点でかけ算するか？」という風に考えると良い、という点です。経験的に非常に見通しが良いことが多い。
ここでいうP(price)はコスト・プライス・価額等々の単価/原価/売価系の情報をさします。またQ(quantity)は個数/量の情報をさします。モノをハンドルするということは最終的には両者を管理することにつきます。ところが現実には両方同時に行うことの方が少ないです。
■SCMのような仕組みではQの管理が優先される
例えばSCMの仕組みを考えてみましょう。部外者から見るとちょっと違和感があると思いますが、大抵の生産管理やSCMの仕組みは実はほとんどがQ（量）の管理に機能を集中しています。Pについては関与しないという仕組みが多い。理由は以下です。
1 とりあえずスループットをあげるのが仕事です。
生産効率向上のサポートがITの主要の役割です。これはいかにして投入単位資源（特に代替性の低い「時間」）あたりの生産性を向上させるか、ということになります。製造のみならず、サービス系の仕組みも同じ目的を持ちます。物流・輸送・配送・運輸・医療・エンターテイメント系、には須く、こういった要請があります。この場合は、やはり生産量を計るものはquantityになります。
2 コスト情報は生産行為それ自体には影響を与えないことが多い。
ある一定の生産計画（あるいはなんらかのアウトプット計画）が作られた段階で、あとは実際の実行計画の策定とその実施、および結果の検証がシステムの役割になります。生産効率の維持にはコストデータは必須の情報ではないことが多いです。勿論、ビジネスの方向性との整合性をとるという意味で多少のコスト情報も持ち回りますが、あくまで参考情報であることが多いかと。
3 そもそもQの管理一つとっても、相当に処理は複雑になります。
基本的にFA系の仕組みや端末に近づけば近づくほど、ハンドルする情報はQに関するものになります。量の管理ひとつとっても、その受払記録・トレース・作業とのマッチング・例外業務の処理、また作業計画の実行サポートをシステムがこなす必要があり、この上コスト・価格情報まで持ち回るとシステムが複雑になりすぎます。
ただしバリューチェーンの最終フェーズでは、PxQの形で測定をしないと生産高の比較ができないし、そもそも財・サービスの交換可能性を満たさないので、PxQの形に必ずなります。要は結合処理が必ず入ります。
■PxQの結合処理
というわけで、問題はPとQの結合処理になります。
この場合に以下の要素が入ります。
1. Priceの管理手法への配慮
Priceの管理は、実際のものを利用するか、ある程度の想定を利用するかになることが普通ですね。勿論、管理会計との整合性もありますが、大抵はほぼ想定のものを利用し、最後に実際のものに再マップします。一定のスキームに当てはめるという言い方が正しいでしょう。Priceデータの管理は、一定のマスター的なものを管理していく方法と、実際のデータを時系列で管理して一定のプールをつくっておくという方法が取られることが多いですね。
補足しておくといわゆる時系列管理については、通常はPとQでタイムスケールが違うことが多いので、同じフレームで処理をすると大抵は崩壊します。この意味でもPとQを分けて管理する意味は十分にあります。
また、Pの管理は、よく見ると実際はマルチ・スキームで行った方が効率がよいことが多いです。ところが、これは表面上は単独に見えることが多いので、わりと簡単なシングル・スキームの手法で突入してしまうという、ありがちな罠にハマることになります。この手のミスは設計・実装・テスト・リリースまで行って、最後に運用の段階で顕在化することが多く、「運用でカバー」というなんのためにシステムを導入したのかわからない結末になることが多いですね。気をつけると何かとよいかと。
2. 結合処理のタイミングと処理
さて、最大の課題はPとQとの結合になります。大抵はPrice系のマスターデータとQを処理するTRNデータの結合になります。また、PriceがTRNの場合も当然あります。この場合はTRNとTRNの複数groupの併合処理になりますね。
考慮すべき点は以下
・結合のタイミング
PとQを分けて管理する最大の理由は効率性の重視です。通常、結合処理をすることで出来上がったデータは、普通に考えると維持コストは上がります。（一般にデータ属性が多いデータはいろんな意味でコストが高いです。）したがって持ち回るコストが最低になるような設計戦略を取るべきです。つまり、慌ててホイホイ結合するな、と言っています。
・多段階結合を選択すべきか
どの精度のレベルのデータが必要とされるのか？という問題です。特に集計するような場合は、集計目的に応じて、利用するPのスキームを選択することになります。特にマルチ・スキームになることが多いのであれば、当然多段の結合処理になります。または、まとめて一回で全部結合処理をしてしまう、という選択肢もなくはないですね。このあたりの選択は慎重に行った方が吉です。
・結合のコストをどう判断するか
この種の処理は、Qは元々TXであることが多いので、特にPがTX的な場合は圧倒的に処理コストが高くつきます。全データへのフルアクセスに対して鬼のマッチング処理が発生します。普通はバッチ処理。現在のところは汎用機が強い分野でしょう。RDBMSを主軸にしたオープン系はパラダイム的にはかなり厳しい。（正直、このためにHadoopを利用するというのが自分のそもそもの狙いの一つです。）事前にきっちり見積もって置く事が肝要です。この辺の見積もりが甘いと終盤で玉砕するという羽目になります。
3. そもそもPxQを便宜的に一つに結合してしまって処理をする方式もあります。
これはまぁ、最初から最後まで力技というケースですね。ハードに任せて全データを全部持ち回るぜ、という言ってみれば、かなりセンスの悪い方法です。とはいえ、あまり考える事はないので、「下手な考え休むに似たり」というような場合で、かつ、ハード・リソースが割と自由に使える場合は考えてもいいかと思います。（とはいえサイジングで失敗すると終わるので要注意です。）
または、割と単純なシステムで、PとQをわけて管理するまでもない、というケースですね。個人的にはそのような場合は、変にシステム化するよりも、もはや無敵のツールと化しているエクセルという道具を使うことをお勧めします。最近はかなりのデータ量までハンドルできてしまうので、なかなか侮れません。
■具体的な例
さて、モデル的な話はともかくとして、経験的に業務モデルでの適用プランの例をいくつか提示しておきます。（通常は、かなり複雑なことが多いので、そうは簡単にはいきませんが、まぁ指針として有効だと思います。）割といろんなところに適用できるということがわかると思います。自分的な覚え書きも含めて書いておきます。
・原材料管理（生産管理・工程管理）Qの管理＝仕掛品・完成品・投入材料の数量管理
Pの管理＝単価配分・原価差異把握
結合処理＝原価計算
現状の生産管理の仕組みではERP（MRP）＋FAというパターンが、散見されますが、この場合、そもそもERP入れた段階で、結合処理の自由度をある程度放棄していることも自覚すべきでしょう。この結合のバッチ処理がまぁ割と遅いというのは有名な話です。理由は前述の通りです。
通常FAサイドではQの管理を徹底することが多いです。んで、バックエンドで必要に応じてPと結合処理をするというパターンの利用。結合処理の手法としては、一定のキーを決めたあとで、FIFOやMAやらを利用して、複数のPの割当を行うということが通常です。
尚、このときに留意すべきは、結合後の処理をどのように利用するか？です。実態としては(Qa - Qb) x Paの形で最後に一気に結合するか、Qa x Pa – Qb x Paの形で段階結合処理をするかです。この辺りの切り分けがシステムのコストに響きます。
MRPを眺めるときや、FAの仕組みを俯瞰するときには、PとQの管理や結合処理の観点からレビューしたり、設計することがどうしても必要です。これにより、場合によってはシステム全体のポテンシャル・スループットを想定することすらできます。
・受発注管理Qの管理＝受注または発注の数量管理
Pの管理＝単価管理（ロット管理を含む）
結合処理＝決済処理または別のシステムに渡すタイミング
まさにバッチ・オンリーの世界になりますね。データ・クレンジングを行いつつ、結合処理をどのタイミングでやるか？という問題に集約されます。かなり手前で結合処理をして、ある程度のコストを覚悟でQ自体にデータを持たせるという手法もいいですし、まとめた段階でマッピングする（条件テーブルからマッチさせる）ということもあります。いずれにしろスクラッチ・バッチの独壇場ですね。デザインがパフォーマンスに大きく影響します。
内容によっては、PがTXデータ化している場合もあります。この場合は、事前の結合処理は絶望的に無理なので、他のデータとの整合性を取るために仮置きのPで一時結合処理をして、あとからオーバーライドするということもあります。または、そのまま結合なしで最後まで走りきるか。
時々見かけるのは、本来必要ないのですが、「昔の流れ」で無理矢理結合処理をして作っていたデータが負の遺産でそのまま残って、まったく無意味なPデータを結合処理をして持ち回った挙げ句に、最後にオーバーライドされて全部消えます的な非常に残念なシステムもあります。そういうケースでは、システムのリプレースの際に、抜本的に見直すことをお勧めします。
あとは重要なのは、「例外処理」ですね。P・Qが一定ならばいいのですが、あとから遡及的な修正が発生した場合、修正フローの後追いバッチ処理を走らせる必要があるのですが、かなりの負担です。結合コストはイレギュラーな処理には、相当なコストが追加で発生するということを事前に認識していることは重要です。ま、大体忘れていて、修正バッチをつくるときに発狂することが多いですね。
・販売商品の在庫管理Qの管理＝在庫管理
Pの管理＝原価引当による単価管理
結合処理＝損益処理やコストの見積もり・確定処理、または別システムへの連携時
割と一般的に使われることが多いスキームだと思います。結合処理はクオートに使われることが最も多いですね。あとは勿論、事後的な販売確定時の処理でも使われます。正常系だけとはいえエンド・ポイントでその場でのほぼリアルタイム結合も行われることもあります。この辺は組み込みの世界と言いつつも PとQを両方扱うということになります。この場合、大抵はシステムの製造コストが見合わないので、スクラッチはほとんどありません。割とパフォーマンス優先のITかと。
また普通に構築する場合も、1to1の結合処理ではなくて、RangeJoinとか行われる事もあったりして、油断するといつの間にか複雑怪奇になっていることが多いのも特徴でしょう。このスキームはTXの量に大きく依存しますし、またPのボラティリティにも影響されます。経験的には、ぐちゃぐちゃに段階結合するよりは、スパッと一気に結合してしまった方が後腐れがないので、取り回しが楽なのですが・・そうはいかない、というケースでは泣きそうになります。大抵は安請け合いしたフロントの影響で、大赤字＋デスマ要因になることが多い典型例かと。もっとも、やってるSEサイドも最後の方になって真っ青になるというケースも見られるので、営業もSEもお互い注意した方がよいです。
・人件費管理Qの管理＝作業時間管理
Pの管理＝賃金テーブル・諸手当等の管理
結合処理＝人件費計算、給与等の支払計算
人＝物という発想でみるのが人件費ですね。コイツも鬼門です。Qの管理はLabor Schedulerか勤怠管理のFAまたは端末系で処理して、んで、コスト計算時点で結合処理をするということが多いですが、まぁ相当に複雑です。なので、大抵はパッケージ管理か、一種のASPを利用するということが非常に多いです。ただし、スキームに乗り切らない場合は、結果としてパッケージやASPの魔改造になってしまうというケースも時々見ます。こうなると、とっととケツ捲った方が勝ちですが、そうも行かない場合は、お客さんと一緒に腰を据えてどうするかじっくり話し合った方がいいです。
人件費の結合（誰にどういった単価/手当/OTを割り当てるか）は例外系業務処理のカタマリです。この辺は、実はやり始めるととても面白いのですが、とてもとてもとても大変なので設計・実装はお勧めしません。ただ、今後の人件費の測定や効率性の重視の社会的な要請の中でさけては通れない可能性もありますので、人生どこかで一度は経験するといいかも知れません。「ナントカだと変更に強い」とか寝言は寝て言え、とか、いろいろ言いたくなります。ナントカ信者系の人は一度経験するといいです。皆さんが考えるほど世の中簡単じゃないです。
■まとめ的なアレ
実際、その辺の落ちているような、あるいは、いろいろと関わっているようなシステムを、モデルとかそーいった大上段な設計とは別に、PとQに分けて観察してみると、いろいろな示唆が得られることが多いです。これはまた、俯瞰視点の確保にもなるので、仕様の抜け漏れを発見できることもにつながります。システムの作り手だけではなく、エンド・ユーザーレベルでもかなり有効な手法だと思います。
PとQにわけるという発想は、実はそもそもはITの発想ではないです。業務よりの発想です。要は現場の知恵の中で生まれたノウハウで、特に複雑でヤバい業務の時は、一時的にPとQを切り離して別々に管理するという手法は、divide and conquer の発想に近く、割と頻繁に利用されます。IT以外にも実際の現場では、うまく分けて業務をまわしていることは多々あります。一種の経験的に編み出された効率的な管理手法と言ってもいいでしょう。IT的なアプローチはどうしても業務ニュートラルなことが多いのですが、ま、世の中そーでもないですよ、ということで。覚えておくとなにかと便利でござる。
そんな感じで。
