上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


--.--.--|スポンサー広告||TOP↑

入門 JSON 2

「入門 JSON」が微妙に評判がいいみたいなので, 今回はもう少し踏み込んだ内容を書いてみたいと思います。 前回では JSON のデータフォーマットについて曖昧な表現や説明のまま流していますが, ここではもう少し厳密に見ていきます。 またもや長文です。 ご注意を。 なお, この記事は「Introducing JSON」日本語訳)と併せてご覧いただくことをお奨めします。

前回は JSON のデータ型について連想配列(members)と配列(array)の2つがあると説明しました。 しかし実際にはもうひとつオブジェクト(object)という型があります。 実は JSON ではこのオブジェクトがデータの基本になっています。 (説明が長くなるので前回はこの部分についてワザと端折りました)

オブジェクトは以下に示すようにブレス記号で囲んだ表現になります。

{ }
{ members }

ここで注意すべきなのはオブジェクトの内容は(空でないなら)必ず連想配列でなければならないことです。 例えば, 以下のようなオブジェクト-配列表現は許容されません。

{
  [ "element1", "element2" ]
}

またこのような表現も(一見正しいように見えますが)間違いです。

{
  { "name1" : "value1" },
  { "name2" : "value2" }
}

オブジェクトを示すブレス記号は単なる区切りではないということです。

次に連想配列ですが, 以下に示すような「名前:値」表現になります。

string : value

members, string : value

名前と値(value)の間はコロン記号で区切ります。 また連想配列を列挙する場合はカンマ記号で区切ります。 名前は必ず文字列(string)でなければなりません(文字列の形式については後述)。 そして配列は以下に示すように配列要素(elements)をブラケット記号で囲んだ表現になります。

[ elements ]

配列要素はひとつ以上の値をカンマ記号を区切り文字として列挙します。

value
elements, value

連想配列にしろ配列にしろ要素を列挙する場合はカンマ記号に注意してください。 例えば以下に示すように最後の要素の後にカンマ記号を入れるのは間違いです。

{ "array" : [
  "element1",
  "element2",
] }

連想配列および配列の値として許容できる形式は以下の通りです。

  • 文字列
  • 数値(number
  • オブジェクト
  • 配列
  • true, false
  • null

例えば配列要素として以下のように連想配列を直接入れることはできません。

{ "array" : [
  "name1" : "value1",
  "name2" : "value2"
] }

連想配列の要素を配列に入れる場合は, いったんオブジェクトにする必要があります。 (以下は連想配列の要素を個別にオブジェクトとする場合)

{ "array" : [
  { "name1" : "value1" },
  { "name2" : "value2" }
] }

文字列は文字(char)の列(chars)をダブルクォーテーション記号で囲んだ形式です。

""
"chars"

文字列として使える文字は通常の UNICODE 文字(ダブルクォーテーション記号およびバックスラッシュ記号(\)を除く)の他, バックスラッシュ記号からはじまるエスケープシーケンスが使えます。 利用可能なエスケープシーケンスを以下に示します。 C 系のプログラミング言語を扱っている方にはなじみのある表現だと思います。

\" quotation mark
\/ solidus
\\ reverse solidus
\b backspce
\f form feed
\n newline
\r carriage return
\t holizontal tab
\ufour-hex-digits charactor code for UNICODE

文字列データにおいて文字コード(厳密には文字エンコーディング)は常に悩みの種ですが, JSON においては UNICODE のみ許容しています。 したがって他の文字コード(Shift-JIS や EUC-JP など)を採用しているツール・サービスでは文字コードの変換処理も必要になります。

数値は10進数のみ(任意のN進数には対応していません)で, マイナス表現や指数表現を許容します。 例えば -1.23e+4 といった感じです。 +1001 といった表現は許容されません(必ずサプレスします)。 また数式表現も許容されません。 (前回紹介した xml2json.cgi は数値の解釈がうまくなく時々変換をしくじります。 私は Perl とか正規表現とかいったものはあまり得意ではないので, どなたかやってくださらないかなぁ...)

JSON は値としてオブジェクトを許容しているため, いくらでもデータを入れ子にすることができます。 この部分がデータフォーマットとしての柔軟性に繋がっていて, XML と同様に従来の RDBMS とはまた違ったデータベース操作を可能にしています。 (いくらでもデータを入れ子にできるというのはリスクでもあります。 データ同士の関連が循環しているような構造のデータベースを JSON に展開するときは注意が必要です)

JSON は Javascript の言語仕様をベースに作られたことは前回説明しましたが, これまで述べたように Javascript に比べると色々と制約が多いと言えます。 しかし実際には JSON は Javascript の eval 関数で簡単にインポートできてしまうため, Javascript で解釈可能な表現ならば何でも受け入れてしまう可能性があります。 特に問題になりそうなのは値(value)として関数(function)が記述されている場合です。

もし JSON データを自前で構文解析して Javascript 表現に変換できるのなら比較的安全に取り扱うことができます。 「JSON in JavaScript」では JSON.parse をパーサとして使うことを推奨しています。 例えば JSON データ json.txt を Javascript 上でインポートするには以下のようなコードにします。

<script type="text/javascript" src="jkl-parsexml.js"></script>

<script type="text/javascript" src="json.js"></script>
<script type="text/javascript">
  var url = "json.txt";
  var json = new JKL.ParseXML.Text(url);
  var text = json.parse();
  var data = JSON.parse(text);
</script>

json.txt の読み込みには前回も紹介した JKL.ParseXML ライブラリを利用しています。 このライブラリではクロスドメインの制約を超えられないのでご注意を。 クロスドメインの制約を超えるためには(前回紹介した) xml2json.cgi などの CGI を使う必要があります。

さて, これで JSON について大体のイメージができたのではないでしょうか。 この記事が少しでもお役に立てれば幸いです。



スポンサーサイト
2011.08.23|パソコンな日々コメント(0)TOP↑

入門 JSON

ここではあまりプログラミングの話はしないのですが(私も今気がついた), たまにはいいでしょう。 今回は JSON というデータフォーマットのお話です。 めっさ長文です。 ご注意を。 (3/8 追記があります)

最近 JSON (JavaScript Object Notation)にハマってます。 JSON というのはごく軽量のデータフォーマットで, Javascript (というより ECMAScript と言うべきかもしれませんが)の言語仕様がベースになっています。 とはいえ, JSON 自体は Javascript からは独立していますので他の言語(C/C++, Java, C#, Perl, Ruby, Python など)でも問題なく扱うことができます。 JSON は以下の2種類のデータ構造の組み合わせでできています。 (JSON フォーマットの詳しい解説をご所望の方は「入門 JSON 2」を参照ください)

  • 「名前:値」の組み合わせ(連想配列)。組み合わせ自体をひとつの要素として扱うことができます。
  • 要素の順序つきリスト(配列)。リスト全体をひとつの要素として扱うことができます。

例えば私についての情報を JSON で作成するとしましょう。 まず私の名前は連想配列を使って

{ "name" : "Yasuhiro ARAKAWA" }

といった具合に表現できます (「名前:値」の名前の部分は必ず文字列である必要があるのでクォーテーションで囲みます。私はここでハマりました)。 ついでにニックネームも追加しましょうか。 データ全体をあらわす名前も付けますしょう。

{
  "Person" : {
    "name" : "Yasuhiro ARAKAWA",
    "nick" : "Spiegel"
  }
}

更に最近注目しているサイトなんかも入れてみましょう。

{
  "Person" : {
    "name" : "Yasuhiro ARAKAWA",
    "nick" : "Spiegel",
    "interest" : [
      { "title" : "SETI@home", "url" : "http://setiathome.ssl.berkeley.edu/" },
      { "title" : "Flickr", "url" : "http://www.flickr.com/" }
    ]
  }
}

何かに似てきました。 そう FoaF です(というか,似るように要素を追加していったのですが)。 JSON の記法は RDF の Turtle に似ているそうで, RDF への応用を考えている方もいらっしゃいます。

JSON は(成り立ちから考えても当然ですが) Javascript と非常に相性の良いフォーマットです。 JSON のデータを丸ごと Javascript の eval メソッドに通すと構造ごとオブジェクトができてしまいます (実際にはそのまま eval メソッドに通すのはセキュリティ上危険なので, JSON.parse などのパーサを通すことが推奨されています)。 Javasript と相性がいいということは Web ブラウザ(クライアント側)で操作がしやすいということです。 そこで当然 Ajax と組み合わせたアプリケーションが色々と思いつくわけですが, そうなると XML と JSON との相互変換が重要になってきます。 XML と JSON との相互変換, 特に XML から JSON への変換を行うライブラリは既にネットに色々あるようです。 Javascript で動作するものでは以下のライブラリがいい感じです。

Javascript でリモートのデータを取得するには XMLHttpRequest クラスを使うのですが, XMLHttpRequest ではセキュリティ上の制約から他所のドメインにアクセスできないようになっています(「クロスドメインの制約」と言います)。 他所のドメインから XML や JSON データを取得するには大きく2つの方法があります。 ひとつは, いったんサーバ側でデータを取得してからクライアントに渡す方法(CGI などのサーバサイド・スクリプトが必要です)。 もうひとつは Javascript ソースとしてインクルードする方法です。 del.icio.us では JSON データのフィードに後者の方法を使っています。 この方法はとても便利なのですが, JSON データを無条件に受け入れてしまうためセキュリティ上の危険を意識する必要があります。

前者の方法は(サーバ側で適切なパーサを通せば)後者よりもいくらかマシです。 そこで, 前者の方法を試してみることにします。 BOINC が提供しているクライアントのバージョン情報(XML 形式)をサーバ側で取得し, JSON 形式に変換してクライアントに渡します。 サーバ側のスクリプトには以下を使わせていただきました。

このスクリプトは Perl の Data::Dumper が JSON の形式に似ていることを利用して効率的に変換を行っています。 ただ, これをこのまま使うとオープンプロキシのようになってしまうので, 特定 URL の情報のみを取得するように改造しました。 このスクリプトで取得した JSON データを「Club-HUAA サポートページ」で受けてクライアント側で表示します。 クライアント側の Javascript は以下のような感じです。

<div id="versiondata">読み込み中...</div><script>
window.onload = function(){
    var s = document.getElementsByTagName("head")[0].appendChild(document.createElement("script"));
    s.type = "text/javascript";
    s.charset = "utf-8";
    s.src = "http://huaa.baldanders.info/xml/?type=client";
}
var client = {};
client.onload = function(data){
    var src = "<div><table>";
    var platform = "";
    for (i = 0; i < data.versions.version.length; ++i) {
        var item = data.versions.version[i]
        if( item.platform != platform ) {
            src += "<tr><th colspan=\"4\">" + item.platform + "</th></tr>";
            platform = item.platform;
        }
        src += "<tr>"
        src += "<td><a href=\"" + item.url + "\">" + item.description + " " + item.version_num + "</a></td>"
        src += "<td>" + item.installer + "</td>"
        src += "<td>" + item.size_mb + " MB</td>"
        src += "<td>" + item.date + "</td>"
        src += "</tr>"
    }
    src += "</table></div>";
    document.getElementById("versiondata").innerHTML = src;
}

</script>

結果についてはテストページを参照してください。 CGI パラメータ以外にも若干修正しています。 取得したデータは一定時間キャッシュするようになっているのですが, キャッシュの時間を10分から6時間に変更しました。 また XMLin で XML データを Perl の内部表現に変換する際に XML のルート要素が欠落する問題があったため, 該当部分を以下のように変更しています。

my $xmlobj = XMLin($res->content);
              ↓
my $xmlobj = XMLin($res->content, KeepRoot => 1);

最終的なスクリプトを xml2json.txt に公開しています。 また CGI の機能については「JSON 変換サービス」を参考にしてください。 (順次機能を増やしていく予定です)

クライアント側で簡単にデータを操作できるというのはサービスのユーザにとって大きなメリットがあります。 一方でセキュリティ上の問題も見逃せないところです。 これからも JSON に注目していきたいと思います。



2011.08.23|パソコンな日々コメント(0)TOP↑
http://home.att.ne.jp/wood/myagi/erp.htm

ERPとMRPllの基礎知識

いつまでたっても工事中 m(__)m
  1. ERPとMRPll
  2. MRPの発展経過
  3. MRPllを構成するモジュール
    1. 基準値と在庫管理
    2. 資材所要量計画と基準生産日程
    3. 購買管理
    4. 負荷計画
    5. 工程管理
    6. 会計と原価計算
    7. 販売管理
    8. 売掛金と売掛金
  4. 機能の拡張
    1. ロット追跡と品質保証
    2. DRP
    3. 固定資産
    4. 出退勤管理と人事/給与
  5. 各種生産形態への対応
    1. JIT
    2. 繰り返し生産
    3. 作番生産
    4. プロジェクト
  6. 高度化と新しいアプローチ
    1. オーダーディスパッチコントロール
    2. 有限負荷山積み計算
    3. CALS
    4. TOC(Theory of Constrains)
    5. サプライチェンマネジメント
  7. 品質と生産管理
    1. 品質問題への接し方
    2. 手直し
    3. 分解、再生

  本文書はERPや統合業務パッケージソフトを評価・導入の際に必要な「パッケージを構成する一般的・標準的な仕組みとはどういうものでどのような考え方で 成り立っていて、実際に使おうとするときにどういう事に注意すべきか」について概説したものです。 このような知識の普及が大切であると感じるようになった理由は、従来は一般的な生産管理理論に基づいてシステムの導入を支援するコンサルタントが結構いたのですが、 ERPパッケージの普及に伴い、特定のパッケージの導入を支援するコンサルタントは増えたのですが、パッケージに依存しないコンサルティングを行なう人は反って減ってしまったように思われるからです。 対象者はこの手の導入プロジェクトにかかわる人という事で、特にコンピュ-タの知識を前提条件とは考えていません。

  また、業務システムの開発に携わる人にとってERPの理解は必須であると思います。ERPは巨大なデザインパタ-ンとも言えます。これの仕組みを理解すると「どこで発生したデータがどことどこでどう使われているか」といった会社の仕組みが整理された形で頭に入ります。 ですから業務ソフトの開発に従事する人は、是非ERPの導入に参画してみるべきです。あなたのキャリアに非常に有効な経験と知識を得られるでしょう。 実際に導入に参画する機会がなくても、調査・評価などの機会があれば少しは役に立つでしょう。 そもそも、業務アプリケ-ションを開発する際にはERPの利用を選択肢として評価し、使わないのであればERPでは実現出来ないものは何かが明らかになっているべきです。

  ERPのパッケージソフトは、主にアメリカ的な考え方の上に成り立っています。ヨ-ロッパの会社の製品でも多くはアメリカの生産管理理論を基礎にしています。 一方、多通貨対応などはヨ-ロッパのものが先行ていました。現在主流のものはあまり国籍を感じさせなくなっています。これらは会計系から発展したものと、生産管理系から発展したものに大別できると思いますが、本書は特に後者の流れを中心に解説してあります。 ここでのスタンスは「生産管理は科学的な研究分野である」という考えであり、生産管理を行う人は立派な専門家たりうるとみなしています。 ですからその業務は科学的に研究され、そこから標準的な手法が導かれソフトウェアとして実装出来るはずなのです。

  このような考え方は日本のメ-カ-で実際に生産管理の仕事をした者としては、まるでよその国の事という感じがします。生産管理に対する考え方は、理論ではなく、目の前の事実を経験で積み重ねてきたものを信条としている人が多いように思われます。
多くの日本のメ-カ-で、生産管理部門の人は製造部門と販売部門の両側から責められ、しかも経営者からもあまり評価してもらえない損な役回りになっている のではないでしょうか? 生産管理のやり方はひたすら経験から築き上げてきた手順に凝り固まっていないでしょうか? 一方で製造業には多種多様な流行があります。それらの多くは明らかに過去のものの焼き直しです。その根底には基礎となる生産管理理論があります。そして、 現在、生産管理に携わっている方々は、新人の育成に悩みがあるのではないでしょうか?単なるOJTではもはや人の育成は出来なくなっています。そのような 人の考え方(職業観、人生観)になってしまっています。まして、海外の工場にどうやってOJTでしか教えられないやりかたをもって行くのでしょうか?
流行によっても変わらない部分を理論的に理解しておくことは、現代の生産管理者に必須であると思います。ここでは、理論はほとんど述べません。理論を学ぶ 為の本は多くはありませんが、通信教育の講座がいくつかあるようです。英語に強ければ*APICSから購入できますが、英語でも読もうという方は希でしょ う。本格的な内容の本の出版・復刻が期待されます。
*(American Production and Invenroty Control Society の頭文字ですが、最近はThe Educational Society for Resource Managementと自らを定義しています。 生産管理の試験を行い、Certified in Integrated Resource Management (CIRM) や Certified in Production and Inventory Management (CPIM)の資格を認定しています。)



 
 

1.ERPとMRPll

ERPは、Enterprise Resource Planning、MRPllのMRPは、Manufacturing Resource Managementの頭文字です。 これだけで両者がどう違うのかわかった感じがします。 後者はManufacturingという以上、明らかに製造業のための概念です。 前者はEnterpriseですから企業全体/全般を対象にしている感じがします。しかし、やらんとすることは似通っています。いづれも企業の持つ物、 人、金といった資源をうまく活用するように計画するという事です。
情報技術から見ると、これらを実装したパッケージ・ソフトは情報の統合・一貫性・即時の同期を保証するように作られています。つまりデータベースを使い個 々のトランザクションは直ちに関連するテーブル(データセット)を総て更新してしまうのが原則です。そのため会社全体へ情報がすばやく行き渡り、全体とし ての動きが速くなることが期待されます。
このようなシステムは、従来の業務別システムの間をバッチ処理でつなぐといったやり方に対し、うまく活用できれば極めて有効な仕組みを作れる可能性があります。ビジネスのスピードが注目されている時にこのようなシステムの導入が流行るのは自然なことです。



 
 

2.MRPの発展経過

MRP(Material Requirements Planning:資材所要量計画)は1970年代初頭にアメリカで提案され、70年代前半にはIBM社のCOPICSのようにソフトウェア製品として販売されるまでになりました。
一方、APICS(American Production and Inventory Control Society)という生産管理実務者の教育・資格認定団体がこのコンセプトの普及に努めました。MRPの知名度はかなり上がり、日本にも紹介されました。
当初のMRPはその名のとおり、完成品の計画に対して必要な部品の量を計算し、在庫や入庫予定を差し引いて新規発注量を求めるというMRP本来のコンセプト・機能を示していました。
その後、購買はともかく、社内で作るものの生産計画(特に負荷計画)や工程管理の機能が必要である、あるいは、事前に生産体制を整えておかないと、いきなり発注したり製造を指示しても対応出来ない、といった現実的な問題から、MRPの前後に色々な機能が追加されました。
その結果、製造会社、少なくとも一つの工場全体の計画を行うという事から、もはやMatrerial Requirements Planningだけではないという事で、MRPllと呼ばれるようになりました。 これが80年代半ばころではなかったかと思われます。



 
 

3.MRPllを構成するモジュール

3.1.基準値と在庫管理

狭義のMRPの実行には、入力される完成品の計画(MPS:Master Producion Schedule)、部品展開し部品の必要量を求めたり、発注する時の発注時期・量を求めるための種ヾの基準値が必要です。
MPSについては、3.2.で触れることにし、ここでは基準値と在庫管理を取り上げます。これらは、生産管理システムを考えるときの基本であり、出発点です。 工程管理や負荷計画を考える時は、ワ-クセンタ-や、工程、設備の定義や工程手順などの基準値が必要になります。これらについては関連する部分で触れることにします。

品目のコード体系と定義、部品構成などの基準値の整備・保守体制の確立は、システムを動かすための出発点といえます。特に下請け的な体質 の会社では、品目コ-ドはお客さんが管理してくれるものと割り切って、コ-ド体系や保守制度を持っていない事があるので要注意です。誰がコ-ドや図面を管理するにしろ、 きちんとしたコ-ド体系とそのメンテナンスの仕組みが実際に機能していることは、この先すべての前提です。
実務では、新規の図面発行だけではなく、設計変更や部品構成の変更が発生し、これらを「どの時点から適用するか」というのも問題となります。 このようなケースでは機械的に必要な指示、手続きが行われるとは期待しない方が良いでしょう。大切なことは、その変更に対し、どこの誰が何に対処するかが明確になっていて各々の動きが集約され共有されることです。 そのためには、関係する品目が「どこにどのような状態でどれだけあるか」をきちんと把握できることが第一歩です。
PDM(product data management)という概念が提唱され、ソフト製品も出ていますが、使う側からの活用事例をあまり見た記憶がありません。

在庫の把握は基本的な事項ですが正確性を維持するのはなかなか難しいものです。例外も含めた入出庫の手順を決めて守る事は言うが易し行う は難しです。製造現場に行って、出庫されたが使われず倉庫に戻すこともされていない部品が在ったり、あるいは手直しが必要な組立途中や組立完成品が散 在しているような現状を目の当たりにすると、生産管理の理屈と現実の乖離を一番強く感じさせられます。「当たり前のことを馬鹿にしないでちゃんとやる」事 の難しさは身を持って知っておく必要があります。 とかく品質が不安定だったり需要変動の波が大きい場合は、部品の入出庫の決まりを作ってもそう簡単には守ってもらえません。 あらゆる手段を駆使して、守るように躾けてゆく方策を繰り出さねばなりません。
多くの場合、このような現象の原因となっているのは、仕組みや仕掛け、しつけや規則、管理手法といった問題ではなく、「品質」です。これについては、最後の部分で更に考えてみます。

3.2.資材所要量計画と基準生産日程

今ではあたりまえに思えるかもしれませんが、部品がどれだけ必要かは完成品の量で決まるというのは、なかなか画期的な発想だったようです。 これを理屈っぽく言うと、完成品は独立需要、部品は従属需要という事になります。完成品がいつどれだけ必要かは、顧客注文などの外部の要因で決まりますが、部品はそれ自体でいくつ必要かを決める必要はなく、完成品の量より導かれるのです。 この考え方が出る迄は、部品は部品を管理する人が、在庫や使用状況を見て発注していたようです。
また、材料メーカが川下の組立に進出した場合などでも、どうしても完成品からではなく川上の材料から生産計画を作ろうとします。 独立需要と従属需要という概念は生産管理の基本ですが、現実には部材の供給ががネック工程の場合は、このようなアプローチもその時点の制約への対処という意味ではあながち否定すべ きではないのかもしれません。

独立需要と従属需要という概念と部品表は、製造業ばかりでなく色々と応用がききます。たとえば、梱包仕様は一種の部品表になります。内箱、外箱、仕切り板、ラベルなどが組みあって一つの梱包が完成します。あるいはレストランの食材の発注にも応用できるかもしれません。
ここでは詳細なMRPロジックには触れません。MRPロジックについては「SEのためのMRP」(日刊工業新聞社:ISBN4-526-03645-5)に詳しい説明があります。

基準生産日程(MPS)は、生産の意思表示でなければなりません。この点は、実運用上誤解されやすいのですが、単に注文を納期に従って並べたものではありません。 受注生産が原則の会社ですと基準生産日程には一部は注文に基づいた量、一部には見込みに基づいた量が入ります。 基準生産日程では、通常これらの間に区別はありません。単に確定期間かその先かといった期間による違いだけであり、確定期間の先で、「この分は注文を受けている」とか「この分は見込生産分だ」とかは考えないものです。 基準生産日程に入っていれば、MRPで正味所要量が発生すれば、注文であろうが見込であろうが、発注時期になれば必用な量を発注/生産するようにオーダーが作られます。
どのような基準生産日程を作成するかについては幾つかのチェック事項があります。

  1. 最長の購買/製造リ-ドタイムをカバ-するだけの計画期間が必要です。とかくリードタイムの短縮など、改善・改革の目標を素直に受け入れて短くしすぎる傾向があります。今、現実に出来るリードタイムや合格率を基準値にしないと、今日からの生産に支障を来します。
  2. タイムバケットの大きさ、どの期間はどの程度の大きさにするかは、計画サイクルや購買/製造リ-ドタイムを考慮して決定します。 なお、現在ほとんどのパッケ-ジは、複数のタイムバケットが使えるはずです。 つまり、最初の4週間は日単位、次の4週間は週単位といった設定ができるようになっています。
  3. 計画基準値はできるだけ「ロット・フォー・ロット(Lot for Lot)」にしておいた方が良いでしょう。 ロットサイジングの基準値を複数使うと、MRPをまわした結果、購買担当者が思っているような計画オ-ダが出てこないとき、何故そういう計画オーダーが出来たのかがわからなくなってしまい、そのままオーダーをリリースしてもよいのか検証できないという問題が発生します。 慣れるまでは上位の所要量からそのまま素直に正味所要量を求めるようにしておいた方が無難です。
  4. 例外勧告が多数出るようなならば、MPSや基準値の設定の考え方に根本的な問題があります。 例外勧告とは、発注済み・製造指示済みのオーダーの納期・数量変更を勧めるもので、本来は直せない「確定期間」内の分について「例外的に」変更を要請するものです。 これが多数出ても実際には変更は困難ですし、それを前提としたその先の計画など使い物になりません。
これらに共通して大事な事は、とにかく「現実的である」ということです。多くの場合、このようなシステム構築は仕事の仕組みから考え直す「リエンジニアリング」のはずです。 抜本的な見直しには大いに期待し支援しながらも、ここはその時点の実力以上のことをやろうとしてはいけません。 実力が上がれば基準値などを改定すればよいのであって、「達成目標」的な数字を基準値にして基準生産日程を設定するとシステムが使いものにならなくなってしまいます。 管理職の目標管理とは峻別しましょう。

3.3.購買管理

事務用消耗品や生産設備の購入に比べると、部品購買は生産に直結しているだけに発注、納期管理、購買先管理などに厳しさと難しさがあります。 MRPは購買計画オーダーを作ってくれますが、部品調達を円滑に行うためにはMRPシステムから出てくるものに依存するよりも、もう一歩踏み込んだ手を打つ必要があります。 例えば、
  1. MPSを購買先に公開する。:MPSの変更を即座に知らせられれば、購買先も発注サイクルの短縮、小ロット発注/納入指などに理解を示してくれる可能性が高くなります。 購買先のリスクで見込み生産してくれる可能性もあります。
    「完成品レベルだけ見せてもらっても、うちは部品屋なんだから部品展開してくれないと使える情報にはならないよ」などと言われる可能性もあります。 もちろん、展開して部品レベルの計画オーダーまで開示する方法もあるでしょう。 単純な組立品や、工程外注先への開示ならば、MPSで十分なケースも多々あるはずです。
  2. コック在庫システム:後述のサプライチェンマネ-ジメントで最近またもてはやされていますがもう何十年来ある方式です。 納入業者が発注者に近いところに在庫し、発注者は必要な都度必要なだけ持って行きその使用分だけ買い取ったことにします。 在庫場所は発注者の倉庫でも近所でも良いのですが、場合によっては発注者が入出庫管理することもあります。 指定倉庫を子会社にして、納入業者からしっかり保管料を取っている会社もあります。これらは個別の決め事です。 発注者としては、いつでも必要な分だけそこにあって欲しい訳です。それをただ納入業者の在庫管理能力に依存していては実現はできません。 やはり、使用見込みとなる情報を的確に伝達してあげる必要があります。 予め正式発注して指定倉庫へ納入させ、使った分だけ検収するという方法を採っている企業もあります。 ただし、下請け法に注意して適用対象とする会社を選定する必要があります。
どのような方法であれ、
  1. 設計変更や、大きな需要変動時の納入業者からの引き取り保証範囲、
  2. 少量しか使用しないカスタム部品のまとめ生産への保証やまとめ購買
などについて事前に取り決めておく必要があります。

MRP発注の場合、製造オーダーと購買オーダーは内外製区分で分かれるだけであって、本質的には所要量を満たすためのオーダーとして両者は同等です。 しかし、購買の発言力は製造の発言力に負けている事が多いのではないでしょうか? 日本の製造業は、社内の製造現場を中心に考えがちで、既製品を購買する場合はもちろん、こちらの仕様で作らせる外作も製造部門からの圧力が色々な面で強いように思われます。 部品調達部門が製造部門からの圧力に弱すぎると、中の問題を外にしわ寄せするような事にもなりかねません。 基本的に、社内の前工程と社外の調達先は同列に扱うというスタンスが求められます。

3.4.負荷計画

負荷計画は何故必要なのでしょうか?ここで、幾つか考えねばならない事があります。
  1. どのレベルの負荷計画が必要か?:ここで注意すべきは、負荷計画とスケジューリングの違いです。 一般的に負荷計画は対策をたてるために計画します。スケジューリングは実際に生産指示するために用います。生産指示は、細かく出す必要が無いのが好ましい状態です。 適切な負荷計画は細かに生産指示せずに済ませるために必要です。 つまり、上記の一貫した物流と均一な生産能力と適切な負荷計画という条件が整えば、大まかなスケジューリング(日程計画などでなくもっと木目が粗くても)で生産は円滑に進みます。
  2. つまり、負荷計画は工場設計の時から周到に考える必要があるという事です。 既に出来上がってしまっている工場でも、上述の状態にどうすれば近づける事が出来るかを考えて改善を積み重ねて行くべきです。
  3. 日常的な負荷計画は「先手必勝です」。早く動けばそれだけ何とか出来る可能性が高くなります。 しかし、需要の変動はそうそう十分なリ-ドタイムを与えてくれません。能力の柔軟性を求めた改善を積み重ねるのが一つの対策です。 原価構成に着目し、狙い目を明確化することも大切です。 設備産業の要素が強ければ在庫を多めに持って需要変動に対処し設備稼働率を上げる方が利益が出るでしょう。 ただ、こればかりやっていると体質が現状に固定されてしまうので、それでも能力の柔軟性を高めてゆく努力は必要です 。最近、自社の中でのこうした改善が余り話題にならず、納入業者や外注先との関係に焦点が当たりすぎているような気がします。 内側の改善は当然の事として行われ続けているのであれば良いのですが.....

3.5.工程管理

工程管理には、
  1. 仕掛(仕掛オーダー)の状態把握(マクロ的、ミクロ的)
  2. 計画どおりに各オーダーを完成させるための対策(能力の調整、品質対策など)
  3. 新規オーダー発行の調整と着手順序の調整
などの要素があります。
ここでの基本は、目の前の具体的でせっぱ詰まっている事象はとにかく何とかして(出来るならば目をつぶって)、全体を把握し効果ある手をうつ事です。 工程管理はとかくマッチ・ポンプ(自分で火を付けて大騒ぎを起こし結局自分で火を消す)になりがちです。 常に全体を管制するという姿勢を持っていないと、決して泥沼から這い上がることはできません。

生産管理の実務担当者には「細かく実績収集したい」という人が必ずいます。 今、現場を飛び回わらないと仕事にならないので、もっと事務所で状況を把握したいというニーズなのですが、それを素直に受け入れると、報告を求められる現場の人から不評を買いますし、 センサーやFAからデータを取ってこようとすると、それなりの投資が必要です。
MRPllで工程管理の部分機能としは、「インプット/アウトプット・コントロール」という考え方があります。 COBOLプログラマには聞き覚えのある言 葉ですが、要するに入りと出を把握し、その間の量を適正に保つように投入を制御するという事です。 入れれば自律的に出てくるのが一つの工程とすれば、その工程が長ければそれだけ管理するポイントは減ります。
そこで、対象とする生産現場は、主要工程で幾つかに分かれているのかを見てみましょう。 例えば、部品製造、組立てなど。これらが分かれた工程として考えられている場合は、その間に在庫があると思ってよいでしょう。 望ましいのはそこに在庫が無いことです。つまり、実質的に前工程と後工程が直結されていて生産管理上は一つの工程と看做せるという状態です。 それは、工程間のつなぎでも現品はラインから降りずそのまま流れるという事です。私はこの「物を降ろさない」というのが生産ラインを設計する時にとても重要な要素だと考えています。 ここでものが滞留することがあっても、先入れ先出しが維持できていれば構いません。 現場の人は、一々指示を受けなくても来たものを順番に作業すればよいのですから、そのポイントでは生産管理は不要です。
次の工程に出す物を指示せねばならないのであれば、もう「降りた」状態です。また、「追い越し」が発生する場合も実質的に「降りた」状態です。
「一個流し」とか「セル方式」は、こういう状態を作る具体的な方策となります。
「物を降ろさない」ラインを作るという一般的には生産管理担当者の担当外での配慮が生産管理を簡素化するには極めて有効です。 技術系の工場管理者は、設備投資額と設備の能率に主眼が行ってしまいがちで、それでいて生産管理に手間がかかる、人が多いと文句を言う傾向があります。 そういうラインにしてしまわない見識が求められているのです。

3.6.会計と原価計算

パッケージ・ソフトでは原価計算として、一般的に標準原価計算が使われます。原価はオーダ毎に把握され、標準との差異もオーダ毎に把握されます。 製造オーダ毎に原価が把握されると聞くと、製造オーダは作番として使えるのかという感じがしますが、両者が1:1である必然性はなく、製番=Σ製造オーダとか、製造オーダ=Σ製番ということもあり得るはずです。
部品の原価が製造オーダ毎に積み上げられるというのは、工程管理との関係で戸惑わされる事があります。 オーダに基づいて出庫された部品は、その製造オーダの原価に積みあげられ、その時点で資産としては消費され消えてしまいます。 この考え方は、現場に行くとまだ部品の状態で物がある訳ですから、物中心の現場管理の立場からすると馴染めませんし、実際不便です。 割り切り方と何に力点を置くかの違いでしょうが、個人的には原価を積んで払い出せば消費された事になるというこの割り切り方は好きです。
どうしても工程中に出庫された部品数を把握したい場合は,現場倉庫を定義しそこへ倉庫間移動するようにします。 現場倉庫からの部品の払い出しは組立て品の実績報告時に自動出庫(バックフラッシュ)すればよいでしょう。 この場合は、部品レベルで不良が出た場合は、それぞれをきちんと報告させる必要があります。 自動出庫は現場の人にはお手軽ですが、決められたことをきちっと守る習慣付けという点では弱点になる可能性があるトいう事に留意すべきです。

買掛金と売掛金は、購買や販売管理からデータをもらって、支払い・入金で消しこむ受払いを行います。 またその過程で支払い計画や入金予定のリストを作ったりします。 これらが本質的には受払い計算であるということがわかれば、もう理解したと言ってよいでしょう。 発行済みオーダーと同様に、入金予定や支払予定の把握が必要です。在庫の受払いと違うのは、支払方法に種類があるという点です。 いつどのような方法(現金か手形かとか)で支払い/入金するかはキャッシュフローを見る上で重要な点です。 在庫と違ってお金の問題ですから、残高を棚卸するといつのまにか減っているということはあまりないでしょうが、返品、価格改定などの訂正ルールが決められ守られている必要があります。
こちらの売掛はあちらの買掛で、こちらの買掛はあちらの売掛ですから両者を一致させておかないとお金が入ってこなかったり、取引先から文句を言われたりし ます。両者を明細単位で突合せを行うと、件数が多いととても手間がかかりますし、月単位などの合計で把握していると不一致の時、その理由がわかりません。 そこでコンピュータで付き合わせようというニーズが出てきます。マッチングのキーは基本は注文書番号ですが、双方の明細データの持ち方の違いからうまくマッチング・キーを見出せない事もあります。 この点は、社内システムでの受払いでは一般的に起こらない問題点となります。



 
 

4.機能の拡張

4.1.ロット追跡と品質保証

技術革新が急速な分野では、研究・開発から量産までの期間が極めて短く、量産技術が確立するまえに大量の生産を行い、製造技術が固まった頃にはその製品は次世代製品にとって代わられているという事がよくあります。 このような場合、不良の山から良品を探して出荷するといった状況を改善するために、かなり詳細な品質関連のデ-タ収集が要求されます。

一方、 PL法などもあって、ある程度安定した品質を確保できている場合でも、QAの観点からの品質・製造履歴管理情報の体系的な収集と蓄積・検索手段の提供が求められています。

これらから出てくるデータの収集と生産管理用の実績収集とは、目的が異なるため内容・タイミング・収集ポイント が異なってきます。 しかし、データを提供する側としては出来るだけ一緒に処理したいでしょうし、集めたデータの整合性を確保する必要もあります。品質統計と工程管理で異なる 作業実績が経営幹部に報告されるのは好ましいことではありません。しかし、逆にこれらを一括してデータ収集しようとすると、収集する データが細かくなりすぎたり、タイミングが合わないなどの運用上の問題が発生します。ですから、これらを纏めて収集すべきかは個々に判断せねばなりませ ん。

ERPパッケージなどでは、QA関係のデータ収集はオプションであり、工程管理のための実績収集とは切り離したモジュールとなっているのが普通です。 通常は検査指示をしてそのデ-タ収集をするようになっています。ライン検査の指示には不向きでしょう。 また、ロット管理機能は、医薬品関係など原材料から製品までのロット追跡が必要な業種を対象に作ってあるものが多く、適当にロット混合も起こり得る普通の業種ではやや窮屈なものも見受けられますが、QAのモジュ-ルよりは広い業種で使える可能性が高いと思われます。

4.2.DRP

DRP(Distribution Requirements Planning)は、流通拠点の在庫・配送計画を作るもので、MRPがMPSからバリューチェンの川上となる生産・発注へ展開されるのに対して、川下へ展開されるものです。 日本は狭くて交通網が充実しているので、大勢として物流拠点は統合の方向でしょう。80年代の一時期、ロジスティックスの概念が出た頃には色々な試みがされましたが、DRPを使うというニーズは現在ではあまり聞かれません。

4.3.固定資産

アメリカでは固定資産の管理と減価償却計算は外注できます。パッケージソフトでも、これを一モジュールとして持っていないものが多いはずです。 或いは使われていないケースが多いでしょう。固定資産の管理や償却、税制などは、企業毎に異なる部分は少なく、法律で決められている範囲しか選択肢がありません。 このような仕事のために社内システムを作るのは無駄だという事です。日本でもここにはビジネスチャンスがあるように思われます。

4.4.出退勤管理と人事/給与

アメリカでは給与体系が単純なので、給与計算・支払事務も外注の対象です。こういうサービスを提供する会社がどこでも容易に見つかります。 そのため給与計算は企業内パッケ-ジではまず扱いません。(日本では給与体系-特に手当てや控除-が会社ごとに多様なため汎用的なサ-ビスが成り立ちにくくなっています。) そのため単純な出退勤の実績を収集するだけの仕組みとなっています。むしろ人的資源の管理という側面での機能が盛り込まれています。 しかし、これらの機能がパッケ-ジソフトに入っていても実際に活用するのはなかなか難しいことです。



 
 

5.各種生産形態への対応

5.1.JIT

トヨタ生産方式は色々真似され研究され、JITも一般化したと言えるでしょう。 単にJITと言うとかんばん納入だけのイメ-ジとなってしまうかもしれませんが、ここではTPS(Toyota Production System)などと言われる範囲にまで話を広げず、生産管理の中でもごく限られた範囲について考えます。
  1. 後工程引き取り方式を採用できると、前後工程を一つの製造オ-ダ-でまとめ単純化できます。つまり生産管理全般が簡素化出来るので積極的に取り組むべきです。

  2. 簡素な工程管理の為には、前述の「降ろさない」ラインを作る(つまり全体を単一工程として管理できるようにする。澱みのない流れを作る)必要があり、そのためには計画段階での平準化や後工程引き取り方式で工程間の調整を自律的にやらせるといった手段が必要です。
  3. 部材調達のかんばん納入

  4. 外注先などからかんばん納入させるのはなかなか骨がおれます。
    • 下請け法を守ること。
    • 単に自分の在庫負担を取引先へ転嫁するだけのような導入は長期的には効果を出せない。

    • 当たり前のようで、こうなっている実態の方が多いのは否定できないでしょう。 サプライチェン全体としての効率向上になるべきなの ですが、「よその会社」ですから直接手を出せることは限られます。よその会社に乗り込んでいってIEや現場改善を指導・助言するというやりかたと、取引きを継続したければ対応しろというスタンスの両極端に振れ勝ちです。 言われた方は、取りあえず在庫を増やしてでも対応し、後で何らかの改善をしてきちんと対応しようという方向に走ります。 これで徐々にでも改善が進めば良いのですが、うまく行かないと経営体質が悪化してしまいます。 ですから、やらせる側としては、取りあえずうまく実施できたという所で安心しないで継続的に取引先の体質強化の支援策を繰り出して行く必要があります。

5.2.繰り返し生産

一定の量で同じものが連続して同じ工程を何日も流れるとき、製造オーダーを日単位とか週単位で発行するのではなく、「レート」という概念で管理しようというものです。 多品種少量生産の傾向の中ではあっても、個々のサイトではこのような生産形態が結構見受けられます。

このような形態を

  1. 繰り返し生産(Repetitive)

  2. 組み立て型ではなく装置産業的な生産形態
    よく例に出されるのは、飲料(ジュースなど)やペットフードの生産です。
  3. 連続型(Continuous)

  4. (一昔前の)自動車の最終組み立てラインのような、同じものを連続して生産する形態
と分ける場合もあります。

前者については、多くのパッケージ・ソフトがこれをサポートしています。 その場合、生産指示をレートで行うという他に、この形態の特徴として部品表ではなくてレシピ(配合比率)を用いるという点を挙げているものが多いようです。 そういう意味ではかなり特定業種に特化したモジュールとなっていることがあります。

5.3.作番

私自身は作番を使う生産管理の実務経験がありません。そのためか、作番というものには懐疑的です。
受注生産の場合、注文に結びついた作番は納期に対する進捗が把握しやすいので効果があるのかもしれません。後述の「プロジェクト型」などはその典型です。 しかし、ほとんどの製品を毎月継続的に繰り返し生産していても作番を使っている場合があるのには驚かされます。 受注生産でも、注文の納期などが頻繁に変更される場合には作番は振り替えなどの手間を増やすだけです。実際、作番振り替えの達人がいる工場を知っています。 情報システムの裏をかくように手際よく伝票処理する様は匠の世界です。
世の大勢は製造リ-ドタイムを確保できるような悠長な受注生産から「使う時が発注する時」へ限りなくシフトしています。 これはリ-ドタイム短縮の努力をいくらしても、Build-To-Orderで消費者向け最終製品を作っている(この場合、消費者は発注から納入まで待ってくれることが前提です。 もしも大多数の消費者がパソコンや車を店からすぐに持って帰りたいとか、翌日には自宅に配送してくれと要求したら、このビジネスモデルは崩れます。 実は私はそういう類の消費者です。)のでない限りは見込み生産・発注を避けられません。このような場合、作番を使う意義があるのでしょうか?

余談ですが、Build-To-Orderが流行るにつれ、(奇妙なことに)需要予測が重視されて来ているように思われます。 これは、つまりBuild-To-Orderの為の部品はVMIとして自工場の中やそばに在庫させておき、受注後すぐに組み立ててお客さんへ届けないと私 よりも少し気が長いお客さんも待ってくれない、でもVMIへの部品の補充は何らかの見込みに依らざるをえないという現実を反映しています。

5.4.プロジェクト

建設関係や設備関係の、日本では一般的に典型的な作番の適用対象です。
アメリカ製のパッケージでは、オーダー・コントロール・コードというものを付けてこの単位で製造・購買オーダーなど総てを把握するようにしているものがあります。 製造・購買オ-ダ-はこの単位で発行され、複数のオ-ダ-コントロ-ルの所容量がまとめられることはありません。原価もこの単位で積み上げられま す。



 
 

6.高度化と新しいアプローチ

6.1.オーダーディスパッチコントロール

結局、製造現場の問題が相変わらず残っていることを思い出させてくれるのが90年代に特にアメリカで話題となったこのオーダーディスパッチコントロールと次の有限負荷山積み計算のソフトウェアです。
オーダーディスパッチコントロールは、工程管理の中の「新規オーダー発行の調整と着手順序の調整」の役割ですが、これがMRPllパッケージに外付けする形のソフトとして売られるようになりました。 MRPllの製造実施計画(オーダー発行計画)とかインプット/アウトプット・コントロールの部分を扱うと位置づけできます。 機能としては、負荷計算を日々やり直して適切なオーダー発行を行おうとするものなので、下記の有限負荷山積み法と深く関連しています。

6.2.有限負荷山積み計算

1990年代半ばにアメリカでホットなソフトウェア・パッケ-ジだったのがこれ。 負荷調整は従来から行わずには済まなかった事なのですが、やはり人手の方が今でも一枚上手なのか、大きな成果を収めたという実例に乏しいように思われます。 そもそも有限山積みのロジックは昔から妙案がありません。山積みのロジックは、
  1. ネック工程をフル稼働させるように負荷を積む。
  2. 納期順や優先度順にバックワードで負荷を積む。
といった方法であり、溢れた分のやりくりは、
  1. 着手日を前後にずらすか、
  2. 代替工程やワークセンターを探す
しかやりようがありません。

この手のソフトは、大雑把に有限山積みをし、それを人手で修正するエディタのような使われ方をしている例を多々見かけます。 その程度で結構と割り切れるのであれば検討すべきでしょう。 こういうソフトに金をかけるならラインバランスを良くするような設備に金をかけるほうが賢明というものです。

この種の問題がいつまでも決定打がないまま残っているのは、

  • 生産能力を考える時、ネック工程や主要工程の設備や人の対策にばかり目が行き、ライン全体のバランスを最適化するという考え方は徹底されにくい。
  • 生産設備による対策は金がかかるので、工程管理のやりくりでなんとか出来ているならば、そのまま放置しておく方が、管理者としては気楽である。(このような考え方は、納期=スピードが差別化要因である場合には致命的です。)
などの要因があるように思われます。MRPllでは、能力所要量計画や製造実施計画の機能に相当します。

6.3. CALS

ドキュメントや図面情報の標準化から始まり、これによりコンカレントエンジニアリングや受発注を取引先全体とスピ-ディに行おうということでしょう。
それにしても「CALSが何の頭文字であるか」がいかに変えられたかを思い出せば、この言葉がこれで儲けようと思っている人たちによっていかに都合のよいように使われて来たかがわかるでしょう。 そもそもはDoD(アメリカ国防総省)の資材調達におけるドキュメント電子化が始まりでした。 90年代終わりになると後述の「サプライチェンマネジメント」の影に隠れたようになってしまった観があります。
  1. Computer Aided Logistic Support
  2. Computer-aided Acquisition and Logistic Support
  3. Continuous Acquisition and Life-cycle Support
  4. Commerce At Light Speed

後になるほどわざとらしいのがよくわかりますね。
 

6.4. TOC(Theory of Constrains)

TOCは、Dr. Eliyahu M. Goldratt により提唱されたました。APICSのDictionary 9th Edition では、次のように説明 されています。
TOCは三つの別個だが相互に関連した分野-(1)ロジスティックス、(2)パフォーマンス・メジャメント(実績の測定)、(3)論理的思考-から成る経営哲学です。
  1. ロジスティックスには、ドラム-バッファ-ロープ・スケジューリング(DBR)、バッファ管理、VAT分析といった手法ががあります。
  2. 実績測定は、スループット、在庫、操業費用と五つのフォーカシング・ステップ(手順)から成り立ちます。
    スループットは、売上によって得るMoneyを言います。…コンピュータのスループットの概念とは異なります。
  3. 論理的思考のためには、問題の根源の把握(現状の事実ツリー)、Win-Winソリューション (Win-Winとは、例のS.R.コヴィーの「7つの習慣」の第4の習慣のことです。)の識別と拡張(モヤモヤの解消と将来像のツリー)、導入計画の開 発(前提条件ツリーと移行ツリー)といったツールがあります。」

これでは、さっぱりですので上記の説明の中の単語を更に説明しましょう。
ドラムとは、一番無理がかかる(Constrain)部分の(例えばある工程や設備、特定の部材調達など)ことです。この部分が、(楽器の)ドラムとして生産全体のリズムを決めます。MPSはこれを基準に顧客要求を満たすように計画されねばなりません。
ロープは「一番無理がかかる部分」から投入工程への連絡ルートです。これにより投入をコントロールします。
バッファは不確実性を防御し、スループットを最大化するように設けられます。バッファは「一番無理がかかる部分」や出荷、組立工程などに設け、ここの手持ちを常に補充するように計画をたてます。こうして「一番無理がかかる部分」での手待ちを無くし最大限に稼動させます。
VATは、V論理構造、A論理構造、T論理構造から成ります。

  1. V論理構造とはある部材がある分岐点まで工程を流れて多用な製品へ分かれる形態です。
  2. A論理構造は多くの部材がある製品へと部分組立て、組立工程を経て合流する形態です。
  3. T論理構造は共通部品・部分組立品・組立品から幾つもの類似の製品ができる形態です。
これらの分析で部材のフローを把握し管理ポイントを明らかにします。

論理的思考ツ-ルとして、

  1. 「現在の事実ツリー(Current Reality Tree:CRT)」は、問題の根源を見つけるために、原因-結果の因果関係をまとめる手法です。
  2. 「将来像のツリ-(Future Reality Tree:FRT)」は、解決策を探し、拡張し、完成させます。そしてこの解決策を導入したときに引き起こされるであろう問題を予測し事前対策します。
  3. 「前提条件ツリ-(Prerequisite Tree:PRT)」はこの解決策を導入する際に障害となること/ものを明らかにし、それへの対策を立案します。
  4. 望ましい状態を実現するための手順・段階を定めるのには「移行ツリ-(Transition Tree:TRT)」という手法を用います。

理屈っぽいわりに、関係者を納得させて実行して行く過程の苦労をよく反映させて作り上げられている事が感じられます。 しかし、これらの事は別に言われなくても計画技法、問題解決、改善手法として当たり前に行われてきたことのようにも感じられるかもしれません。 論理的思考や思考プロセスの体系化は日本人が不得手とする部分ですが、これを、体系的にまとめてくれた事で教育しやすくなったとは言えるかもしれません。 日本で今一つ流行らないのも分かる気がしますが、経験的にわかっていた事であっても体系化して他人に説明・教育出来るものにしておかないと継続的な活動には出来ません。

また、「スループットを最大化する」という考え方はわかっているようで実は実行されてこなかった事が多いのではないでしょうか?
「スループットを最大化する」ことは、操業益を最大化することではありません。「操業で稼ぐ」という発想は長らくメーカの管理者の頭に染み付いていました。 スループットは売上-在庫(棚卸資産全般)なので在庫を増やして操業益を出しても評価されません。

6.5.サプライチェンマネジメント

90年代も終わりに近づいた頃、日本でもいろいろなコンピュータ屋さん、コンサルティング会社、この手の業界専門誌が日本でも流行らそうとしました。
サプライチェンマネジメント(SCM)は、複数の要素技術や管理手法の集合と言えます。つまり、個々に見るとEDIであり、コンカレントエンジニアリングであり、コック方式であり、かんばん納入です。 ただ、全体をデ-タ通信技術を駆使して情報の流れを円滑・スピ-ディにする事が重視されているように思われます。 ですから、これはパッケ-ジソフトを買ってきて立ち上げれば済む話ではないのは明らかでしょう。 CALSという概念も同様で、結局はこれらは、この文書で説明してきたことをチュ-ンナップするもので、一挙にすべてを実現するのは到底無理な話です。 きちんと積み上げてきた会社だけが取り組むことができる一段上のレベルの仕組みです。
80年代前半にM.ポ-タ-の本を読んで「バリュ-チェン」の概念がわかっていればSCMの概念はすぐに理解できるでしょう。 これが流行っているのはWal-Martなどのス-パ-マ-ケットやDellComputerのビジネスモデルなどの評判からでしょう。 両者に共通した仕組みは、自社の在庫・売上・生産情報を購入先へ開示する代わりに、納入業者は自分の責任で必要な分を供給することを要求している点にあります。 この考え方は、消費者向けにとどまらず、これからはもっと川上の業界にも浸透して行くと思われます。

SCMはTOCをヴァリューチェン全体から見たアプローチと言えるかもしれません。 要するに原材料から顧客までのスループットの最大化が目的だと言えるからです。 ただ、複数の会社が絡むので事は一層ややこしくなります。「3.3.購買管理」で述べたような方法を更に発展させて、 CPFR(Collaborative Planning,Forcasting and Replenishment)といった形で、最終顧客から小売-卸-組立-部品-材料まで一貫した実需・予測と各々の在庫を把握する必要があります。 これを実行して行くには、以下のような行動が必要でしょう。

  1. チェン内各社の役割-特に流通-の見直し:チェンにとって付加価値がなければ「中抜き」という事になるでしょう。
  2. 前後の取引先の絞込み:取引先が多いとこのような事はやりにくい。協調できる絞られた取引先と太いパイプを築く
  3. ある程度標準化されたデータ交換のインフラ構築:特に同期/非同期を問わず、メッセージングの形式
  4. 共通コードの定義:特にモノを表すコード。恐らく最終製品のユニークなコードが出発点でしょう。
  5. 各社の持つデータの粒度と鮮度を揃える活動
  6. 何よりも、バリューチェン全体の相互信頼感の醸成
ただ、このような事を進めて行くとき、主導権を握るのは小売でしょうか、組立メーカでしょうか、材料メーカでしょうか。恐らく、業種・業界ごとにそれぞれの事情でその時々で変わるのでしょう。覇権争いをしてしまうようでは、この考え方自体を理解していないことになります。
このチェンの成果は、TOCと同様に「一番レベルが低い会社以上にはならない」事に注意が必要です。
結果的にこれが、買う側・売る側双方にとって余分な手持ちを減らし、売れるときに売れるものを用意することで売上が増えれば万歳です(Win-Winの関係になります)。売る側に在庫負担を押しつけるだけであれば、買う側の横暴となってしまい長持ちはしないでしょう。


 
 

7.品質と生産管理

7.1.品質問題への接し方

半導体の世界の合格率の低さは有名です。合格率が50%位を越えるとれっきとした量産体制でその後合格率が1%あがるとどんどん利益が増えるといった様なことが言われています。 どこまでが本当かは別にして、製品のライフサイクルが短くなり、新技術の投入が早くならざるをえない時勢では、生産管理は品質問題を所与のものとして扱わざるを得ません。
生産管理の立場から言えば、不良による合格率の変動は、合格率が低い事よりも扱いにくいものです。 たとえば、合格率が25%でもそれがいつも安定して25%前後であれば生産計画は組めます。完成予定数の4倍を投入すればよいのです。 もっともそれだけの生産能力を確保することは経営的には無駄に見えるでしょう。
扱いにくいのは、合格率が25%のこともあれば95%のこともあるような場合です。このような状態で納期確保を大前提に25%で計画を組むと、仮にそれだけの生産能力があったとしても過剰生産になってしまいます。 管理者からすれば過剰な設備投資は行いたくないので、25%と95%の間をとって60%の合格率で計画を組めなどと言いかねません。 そうなると納期を守ることは至難の技です。

7.2.手直し

正常な製造オーダーから出る手直し可能な不良品というのはやっかいな存在です。 概してこういう作業はメインの工程に対して低いものに扱われ、ある程度まとめて外注したり、正規の作業場所ではない所で作業させたりと冷たい扱いを受けます。 管理者から見ると確かに見たくはない現実なのです。組立品であれば、まず分解して部品レベルで捨てるもの、手直しするもの、そのまままた使うものに分ける必要があります。 常に一定の率で同じような不良が発生するのであれば、この分別作業と手直し作業は、生産計画に組み込むべきです。
時に、本ラインの生産能力に余裕がなくなって手直し待ち品が突然脚光を浴びたりします。 製造の責任者が、本ラインに新規に投入するだけでなく、手直しにも人を投入しないと能力が足りないなどと言い出すと、別の悩みが浮かび上がります。 手直しにより救われる量をどの程度充てこんだ計画にすべきかです。 こうなると、普通の生産計画システムでは対応できなくなってしまい、手直し用の製造オーダーを緊急オーダーとして発行し、MPSの入庫予定は手直しの状況を見ながら日々微調整して行く‥などといった事態に陥ります。





2011.08.18|業務な日々コメント(0)TOP↑
http://www-indblue.blogspot.com/2010/10/javascript.html

JavaScriptでよくある性能劣化ポイント

WEB+DB PRESS vol.59より。
自分のためのメモ代わりとして、気になった部分をピックアップ。

まずポイント列挙

JavaScriptコード上でよく見られる性能劣化ポイント(抜粋)。
以下、まず列挙します。リンクはページ内アンカです。

  1. 意図しない変数のグローバル化

  2. コストの高い配列アクセス方法を利用

  3. try/catchの間違った使用

  4. ブラウザの再描画について



意図しない変数のグローバル化

JavaScriptでは、関数内で変数を参照する際にまず自身のスコープ内を探します。
見つからない場合、入れ子になっている関数であれば外側の関数のスコープをたどっていき、グローバルスコープは必ず最後に探索されます(スコープチェイン)。そのため、グローバル変数を発見するのは時間がかかることになります。
また、「var」をつけずに宣言された変数はグローバル変数となります。
なので、グローバルにする必要のない変数は必ず「var」を付けて宣言しましょう。
関連:JavaScriptのクロージャ、スコープチェインについての記事(World Wide Windblue)

コストの高い配列アクセス方法を利用

配列にアクセスするには、以下の2通りの方法がある。

  1. メソッド呼び出し
    後発で使用追加されたメソッドを呼び出すこと。(Array.pushなど)

  2. プリミティブ操作
    原始的なアクセス方法


プリミティブ操作を使用するほうがパフォーマンスが高くなる。

try/catchの間違った使用

catch節が実行されるたびに新しいスコープが生成・破棄されるため、頻繁に実行されるとパフォーマンスが低下する可能性があります。
入力チェック時などエラー判定をするときなどでも、別の方法があるならtry/catch節を排除することが望ましいケースが多いでしょう。

2010 11/1 追記ここから
実際に試してみる。
エラー判定にtry/catchを使わない場合と使った場合で比較。
比較したブラウザはIE7、Firefox3.6.8、Google Chrome7、Opera10.63。
各検証を10回して平均を取った。

エラー判定にtry/catchを使わない場合。
window.onload = function(){
var start = new Date();
for(var i = 0;i < 10000; i++){
var a = 100;
if(typeof a === 'string'){
return a.substring(0, 2);
}else{
}
}
var end = new Date();

alert((end - start));
}

1回の実行にかかった平均の時間。
IE…11(ms)
Firefox…0.6
Google Chrome…0
Opera…1.9

エラー判定にtry/catchを使わない場合。
window.onload = function(){
var start = new Date();
var a = 100;
for(var i = 0;i < 10000; i++){
try{
a.substring(0, 2);
}catch(e){
}
}
var end = new Date();

alert((end - start));
}

1回の実行にかかった平均の時間。
IE…540.7(ms)
Firefox…760.7
Google Chrome…1395
Opera…28.9

(Operaが早すぎて不安です。PCのスペックが低いのも関係あるかもしれません)
2010 11/1 追記ここまで

また、catch節の実行時に生成されるスコープは、ローカルスコープよりも上位に位置します。
そのため、catch節の中で変数を定義することは、それだけで処理のオーバーヘッドになります。

ダメな例。
try{
...
}catch(error){
if(error.code === '500'){
var c = error.code;
...
}
}

この倍、errorオブジェクトに対する処理は別の関数に委譲するコトでパフォーマンスへの影響を最小限に抑えられる。
関数かされた処理はcatchスコープから呼び出されても、ローカル変数は通常のローカル変数スコープ内に定義されます。
よい例。
try{
...
}catch(error){
handleError(error);
}


ブラウザの再描画について

JavaScriptによりDOM要素の位置やサイズ変更、新たなDOM要素の追加などを行うと、ブラウザはその変更を表示されているWebページに反映しなくてはなりません。
このような場合にブラウザの再描画が発生しますが、再描画に要するコストは高く、頻繁に発生すると深刻なパフォーマンス低下を招きます。
再描画の回数を減らすポイントは次の2点。

  1. DOMに対する「スタイルの取得」と「スタイルの変更」を混ぜない

  2. DOMに対する「スタイルの変更」は短時間ですばやく行う



2011.08.17|パソコンな日々コメント(0)TOP↑
http://d.hatena.ne.jp/zakira/20080129/1201614381

そのまま使えるmodRewriteの技10発Add Star

| 22:46 |

modRewiteはURL操作で最強のツールです。

数年前、これの存在を知ったときはWEB関連の技術の中で一番の衝撃を受けました。

modRewriteの小技をまとめてあるサイトが無かったので、まとめの為のエントリーです。


modRewiteとは

・Apacheのモジュールの一つ

・URLを書き換えられる(リダイレクト)

・一般的には.htaccessに書いて使う


modRewiteで何ができるか

・携帯サイトの振り分けができる

・動的ページを静的ページに見せることができる(SEO対策)

・サイトの引越し(リニューアル)の時に一度にリダイレクトができる。

・外部からの直リンクを防ぐ(ページ)

・外部からの直リンクを防ぐ(画像)

等、考えれば他にも色々あるかもしれません。


modRewiteの設置方法

一般的には、.htaccessの中に記述します。.htaccessの書き方については別のサイトを参照してください。

まずは、.htaccessの中に

Options FollowSymLinks

RewriteEngine On

の2行を書きます。FollowSymLinksに関しては必要ないサーバーもありますが、書いていても害は無いはず。


実際に使ってみよう

■技1発目 携帯サイトの振り分けを行う

携帯サイトを作るときは、ディレクトリ [i] [e] [s]などを作って、そこにファイルを設置し、

http://www.hogehoge.com/i/

などとしてアクセスしますが、下記の記述でhttp://www.hogehoge.com/でアクセスしたら自動的にリダイレクトすることができます。

少し考えると、ちょっと悪いこともできちゃいます。

ファイル: .htaccess
設置場所http://www.hogehoge.com/のドキュメントルート

Options FollowSymLinks
RewriteEngine On 

RewriteCond %{HTTP_USER_AGENT} DoCoMo
RewriteRule ^$ http://www.hogehoge.com/i/ [R]
RewriteCond %{HTTP_USER_AGENT} SoftBank
RewriteRule ^$ http://www.hogehoge.com/s/ [R]
RewriteCond %{HTTP_USER_AGENT} UP.Browser
RewriteRule ^$ http://www.hogehoge.com/e/ [R]

■技2発目 動的ページを静的ページに見せる

modRewriteはSEO対策で有名になりました。

動的ページを静的に見せ、検索エンジンにインデックスされやすくします。

例)

http://www.hogehoge.com/search.php?type=a&id=123
 ↓
http://www.hogehoge.com/a_123.html

ファイル: .htaccess
設置場所: URLを書き換えたいディレクトリ

Options FollowSymLinks
RewriteEngine on

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([0-9A-Za-z]+)_([0-9A-Za-z]+).html$ search.php?type=$1&id=$2

すこし、ぐちゃぐちゃしてます、

[a_123.html]の部分が ^([0-9A-Za-z]+)_([0-9A-Za-z]+).html$になります。アンダースコア(_)区切り文字になっています。

[0-9A-Za-z]は、数字またはアルファベット(大文字/小文字含む)を表しています。

その後ろのプラス(+)が、1文字以上という意味です。そしてそれを丸括弧()で囲むことで、後方の$1$2に渡しています。

詳しくは、マニュアルを読むのが良いと思いますが、正規表現という書き方です。


■技3発目 サイトの引越し(リニューアル)の時に一度にリダイレクト。

例えば、http://www.hoge.com/http://www.fuge.com/ というように、ドメインが変わったとします。

その際、http://www.hoge.com/のどのファイル/ディレクトリにアクセスされても、http://www.fuge.com/に転送させることができます。

と、言っても実はコレ、機能的には.htaccessでもできてしまうのですが、modRewriteを使うメリットとしては検索エンジン対策にもなります。

ステータスコード301を返すことによって、検索エンジンの評価(有名なのはGoogleのPageRank)をそのまま引き継ぐことができます。

ファイル: .htaccess
設置場所: http://www.hoge.com/のドキュメントルート

RewriteEngine on
RewriteRule ^/(.*)$ http://www.fuge.com/$1 [R=301,L]

■技4発目 外部からの直リンクを防ぐ(ページ)

あるページへ、直接リンクされたくない場合、下記のようにすることでページへの直リンクを防ぐことができます。

下記はドキュメントルートが、/public_htmlで、http://www.hoge.com/test/に直リンクされたくない場合です。

ファイル: .htaccess
設置場所: http://www.hoge.com/のドキュメントルート

/public_html/test> 	Options FollowSymLinks 	RewriteEngine On  	RewriteCond %{HTTP_REFERER} !^http://www.hoge\.com/.*$ [NC] 	RewriteRule ^(.*)$ - [F] </Directory> 

■技5発目 外部からの直リンクを防ぐ(画像)

画像への直リンクは特に要望が多いと思います。

下記のようにすれば、直リンクを防ぐことが可能です。

ファイル: .htaccess
設置場所: http://www.hoge.com/のドキュメントルート

Options FollowSymLinks
RewriteEngine On

RewriteCond %{REQUEST_URI} ^(.*)\.(gif|png|jpg)$ [NC]
RewriteCond %{HTTP_REFERER} !^http://hoge\.com/.*$ [NC]
RewriteRule ^(.*)$ - [F]

今回は、ここまで。



2011.08.08|パソコンな日々コメント(0)TOP↑
http://d.hatena.ne.jp/zakira/20080129/1201614381

そのまま使えるmodRewriteの技10発Add Star

| 22:46 |

modRewiteはURL操作で最強のツールです。

数年前、これの存在を知ったときはWEB関連の技術の中で一番の衝撃を受けました。

modRewriteの小技をまとめてあるサイトが無かったので、まとめの為のエントリーです。


modRewiteとは

・Apacheのモジュールの一つ

・URLを書き換えられる(リダイレクト)

・一般的には.htaccessに書いて使う


modRewiteで何ができるか

・携帯サイトの振り分けができる

・動的ページを静的ページに見せることができる(SEO対策)

・サイトの引越し(リニューアル)の時に一度にリダイレクトができる。

・外部からの直リンクを防ぐ(ページ)

・外部からの直リンクを防ぐ(画像)

等、考えれば他にも色々あるかもしれません。


modRewiteの設置方法

一般的には、.htaccessの中に記述します。.htaccessの書き方については別のサイトを参照してください。

まずは、.htaccessの中に

Options FollowSymLinks

RewriteEngine On

の2行を書きます。FollowSymLinksに関しては必要ないサーバーもありますが、書いていても害は無いはず。


実際に使ってみよう

■技1発目 携帯サイトの振り分けを行う

携帯サイトを作るときは、ディレクトリ [i] [e] [s]などを作って、そこにファイルを設置し、

http://www.hogehoge.com/i/

などとしてアクセスしますが、下記の記述でhttp://www.hogehoge.com/でアクセスしたら自動的にリダイレクトすることができます。

少し考えると、ちょっと悪いこともできちゃいます。

ファイル: .htaccess
設置場所http://www.hogehoge.com/のドキュメントルート

Options FollowSymLinks
RewriteEngine On 

RewriteCond %{HTTP_USER_AGENT} DoCoMo
RewriteRule ^$ http://www.hogehoge.com/i/ [R]
RewriteCond %{HTTP_USER_AGENT} SoftBank
RewriteRule ^$ http://www.hogehoge.com/s/ [R]
RewriteCond %{HTTP_USER_AGENT} UP.Browser
RewriteRule ^$ http://www.hogehoge.com/e/ [R]

■技2発目 動的ページを静的ページに見せる

modRewriteはSEO対策で有名になりました。

動的ページを静的に見せ、検索エンジンにインデックスされやすくします。

例)

http://www.hogehoge.com/search.php?type=a&id=123
 ↓
http://www.hogehoge.com/a_123.html

ファイル: .htaccess
設置場所: URLを書き換えたいディレクトリ

Options FollowSymLinks
RewriteEngine on

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([0-9A-Za-z]+)_([0-9A-Za-z]+).html$ search.php?type=$1&id=$2

すこし、ぐちゃぐちゃしてます、

[a_123.html]の部分が ^([0-9A-Za-z]+)_([0-9A-Za-z]+).html$になります。アンダースコア(_)区切り文字になっています。

[0-9A-Za-z]は、数字またはアルファベット(大文字/小文字含む)を表しています。

その後ろのプラス(+)が、1文字以上という意味です。そしてそれを丸括弧()で囲むことで、後方の$1$2に渡しています。

詳しくは、マニュアルを読むのが良いと思いますが、正規表現という書き方です。


■技3発目 サイトの引越し(リニューアル)の時に一度にリダイレクト。

例えば、http://www.hoge.com/http://www.fuge.com/ というように、ドメインが変わったとします。

その際、http://www.hoge.com/のどのファイル/ディレクトリにアクセスされても、http://www.fuge.com/に転送させることができます。

と、言っても実はコレ、機能的には.htaccessでもできてしまうのですが、modRewriteを使うメリットとしては検索エンジン対策にもなります。

ステータスコード301を返すことによって、検索エンジンの評価(有名なのはGoogleのPageRank)をそのまま引き継ぐことができます。

ファイル: .htaccess
設置場所: http://www.hoge.com/のドキュメントルート

RewriteEngine on
RewriteRule ^/(.*)$ http://www.fuge.com/$1 [R=301,L]

■技4発目 外部からの直リンクを防ぐ(ページ)

あるページへ、直接リンクされたくない場合、下記のようにすることでページへの直リンクを防ぐことができます。

下記はドキュメントルートが、/public_htmlで、http://www.hoge.com/test/に直リンクされたくない場合です。

ファイル: .htaccess
設置場所: http://www.hoge.com/のドキュメントルート

<Directory /public_html/test>
	Options FollowSymLinks
	RewriteEngine On

	RewriteCond %{HTTP_REFERER} !^http://www.hoge\.com/.*$ [NC]
	RewriteRule ^(.*)$ - [F]
</Directory>

■技5発目 外部からの直リンクを防ぐ(画像)

画像への直リンクは特に要望が多いと思います。

下記のようにすれば、直リンクを防ぐことが可能です。

ファイル: .htaccess
設置場所: http://www.hoge.com/のドキュメントルート

Options FollowSymLinks
RewriteEngine On

RewriteCond %{REQUEST_URI} ^(.*)\.(gif|png|jpg)$ [NC]
RewriteCond %{HTTP_REFERER} !^http://hoge\.com/.*$ [NC]
RewriteRule ^(.*)$ - [F]

今回は、ここまで。



2011.08.08|DreamNewsコメント(0)TOP↑
ref http://homepage2.nifty.com/BASH/oracle/sqlplus_tech.html
sqlplusでSELECT文の結果をファイルにCSV形式で出力する
   SELECT文の結果内容をCSV形式でファイルへ出力する方法を紹介します。

SQL> set linesize 1000
SQL> set pagesize 0
SQL> set trimspool on
SQL> set colsep ','
SQL> spool /tmp/hogehoge
SQL> select * from emp;
      ・
      ・
SQL> spool off

上記の「set」コマンドを説明します。
・1行目の「linesize」:1行の長さを指定します。少し大きめの数字を取っておきましょう。
・2行目の「pagesize」:数レコードずつの間のセパレータを無効にする。
・3行目の「trimspool」:SPOOLファイルの行末のスペースを無効にする。
・4行目の「colsep」:セパレータの設定。ここでは「,」とする。

多少、スペースが入り込んだりとする部分はありますが、とりあえずこれでCSV形式でデータをファイルにすることができます。

INSERT文の時に「&」という文字を入れたい
   INSERT文を使用時にVALUES内に「&」という文字は通常入りません。それは、Sqlplus内で「&」という文字は、置換変数として認識されるためです。
しかし文字として入れたい場合には以下のように行いましょう。

SQL> set define off
SQL> insert into emp values('**',・・,'aa&bb');


2011.08.03|パソコンな日々コメント(0)TOP↑
Waha! Transformer
Waha! Transformerはデータの抽出・加工・ロードを容易に行うためのETL(Extraction Transformation Loading)ツールです。

HULFT―DataMagic
これは、hulftのコンポーネントで、dbのオプションを追加すると、db直の操作も可能です。
外字の変換などhulftと連動して各種コード変換、データ移行の手伝いが可能です。



2011.08.01|パソコンな日々コメント(0)TOP↑
カテゴリー
最近の記事
最近のコメント
最近のトラックバック
ブログ検索
管理人のブログ一覧
管理人へメール

名前:
メール:
件名:
本文:

月別アーカイブ
プロフィール

やまもも実験室

Author:やまもも実験室
FC2ブログへようこそ!

RSSフィード
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。