2008年10月21日火曜日

「なでしこ」と設定値(属性)データのやり取り

INIファイルを作成しておき、プログラムを読むときに、属性をセットできる仕組みは作る

INIファイルの中身は
(1)属性名  (2)属性値 (3)改行復帰コード

トラブルを未然防止するために【INIファイルの決め事】を明確にする

(1)ファイル名は半角英数字とし、拡張子はiniとする
(2)一つの属性は、属性名と属性値のセットとし、必ず1行で書く
(3)属性名と属性値のセットの後ろに必ず改行コードを入れる

INIファイルと「なでしこ」のやり取り手順

(1)INIファイルを開く
(2)INIファイルを読む
(3)INIファイルを読んだ内容を配列に格納する
(4)属性名と同じ名前の変数をつくり、属性値をそこに入れる
(5)属性値が変わった場合は、指示によりINIファイルに保存する

属性をDBに格納する

DBをファイルシステム代わりに使ってアプリケーションシステムを構築しようと言う発想

1.TCP/IP通信を使えばロケーションフリーのアプリケーションになる
2.DBなので一度つくったソフト部品の再利用が極めて容易にできるような感じがする

考慮すべき点

1.アイコンなど画像ファイル(ビットファイル)の簡単にDB出し入れする仕組みが必要
2.ローカルの何処に展開するかというロケーション管理情報もセットでDBに登録する必要がある。
3.認証及び課金システムをどうするか。
4.DBからローカルに展開し、使用した後、完全に破壊しておく必要がある

2008年10月20日月曜日

グループ生産方式とは_その2続き

10.各グループの親分の量に応じた加工チャンスが設定される。たとえば、国定グループの忠治親分には月4回の加工チャンスが与えられている。また、清水グループの次郎長親分には月2回の加工チャンスが与えられている。

11.加工計画は次のように立てられる。前述の国定グループを例に話を進める。
(1)システム基準を定め、あらかじめ登録しておく
  ①月間要求量……内示数から算出する
  ②稼働日数………社内稼働カレンダー(昼勤基準)より算出する
  ③日当基準………①/②で算出する
  ④リードタイム……初工程(塑性加工)から製品入庫まで要する標準的な稼働日数を登録する

(2)親分の忠治の加工日を決める。
  ①今現在の在庫(製品及び仕掛)を調査し入力する
  ②今現在の注残を調べ入力する
  ③2週間先までの日別の確定注文数を調べる。
  ④

グループ生産方式とは_その2

たとえば、加工のネックになる一番大きな要因が段取であり、その段取に対して一番影響力のある因子が「材料径」であるという前提に立って話を進めよう。

1.加工アイテム(品種)を材料径ごとに、まとめる→グループを形成させる。

2.便宜上、加工時間が極めて少ないグループ(たとえばアイテムが数点以内で、加工時間が数分のグループ)については、他のグループに含めてしまう。


3.グループごとにPQ分析を行い、一番量の多いモノを「親分」とし、2番以降については「子分」とする。

4.理論的にはグループは加工のネック特性を基準に分けられているので同一グループに所属するアイテムを連続的に加工するのが最も効率がよい。

5.グループ生産方式の狙いは「効率のより生産と多品種変量(お客様への追従)を両立させること」である。

6.基本的にグループが変わったときに、大段取が必要になる。同じグループを続けている限りは大段取の発生がないので、効率よく加工できる。

7.しかし、別のグループのアイテムが欠品になっては「お客様への追従」という目的に反してしまう。

8.そこで、各グループの「親分(最量産品)」の加工サイクル(何日毎に加工するのか、逆に言うと、毎月何回加工するか)をあらかじめ決めておく。

9.加工サイクルに基づいて定めた加工日を「加工チャンス」と呼ぶ。

グループ生産方式とは

1.多品種変量のモノを加工する「現場」にたいして適切な加工指示(=計画)を提供する仕事を支援するシステムである。

2.多品種変量のモノには概ね次のような特徴があるとみなすシステムである。

(1)PQ分析(加工対象品を特定期間における要求量を大きい順に並べること)を行うとアイテム(品種)数の20%未満の加工対象品が概ね全体の80以上を占める。

(2)加工にはネックが存在する。たとえば段取時間などである。

(3)ネックには、ある特定の特性が存在する。たとえば、段取時間というネックは「材料」という特性に左右される。さらに、材料という特性を分解すると、材料の外径や材質(材料の成分)などに分けられ、たとえば材料の外径が最もネックを左右する特性だという具合に特定できる。

2008年10月18日土曜日

必要な要素技術の検討

1.MySQL付属のクライアントツールを用いて、指定テーブルをテキストに変換し、任意のファイル名で保存する技術的な課題の明確化

(1)最高のスピードを求めるので、dumpコマンドを用いる

(2)dumpコマンドによって任意のデバイスに任意のファイル名に出力できる
※select ~ into outfile構文を使う手もあるが、これは出力ファイルはSQLサーバー内に限定されるだけでなく、同名ファイルがあるとエラーになるので、事前に同名ファイル対策を別のシステムによって施す必要があるので、ローカルネットワークに限って使用する場合を除いて、実用的とは言えない。

(3)しかし、dumpコマンドの泣き所は、レコードだけを抽出する機能がない点である。
必ずSQL文を伴う。オプションで変化可能の部分もあるが、いずれにせよレコードの中身だけCSV形式で一発でテキスト出力することは無理である。
そこで、dumpコマンドで出力したファイルを加工する技術が必要である。

これにも様々な方法が考えられる。
①文字列処理をするスクリプトで処理し、直接CSV形式のファイルを作成する。
②クライアントローカルにMySQLをインストールしておき、一旦ローカルのテーブルに吸い上げてから、ローカルのMySQL機能をつかってファイル出力する。

自動実体化する手順の検討事項

ITシステムの自動実体化を実現するために乗り越えるべき課題は多い。
それを一つ一つ理論的に克服しテストで検証してクリアしていきたい。


1.データベース接続の課題

ネイティブなクライアントツールを直接使う。

ODBCなどはACCESSなどで扱うのに便利だが、接続が突然消失する現象が避けられず、処理速度も遅い。ODBC接続で既存のオフィスなどの市販ソフトで扱う場合でも極力ネイティブにDBにアクセスするのが望ましい。
ACCESSの場合パススルークエリーでSQLを発行するという方法を取らないと、遅くて実用的でない。ODBCあるいはADO接続などの市販の互換手段を介すると多くのリソースを消費することを前提とした設計が必要である。

2.データ取得の課題

シンプルにテキストファイルとしてハードディスクに保存し、その後すぐにDB接続を閉じてしまう

一般的には、接続したあとにレコードオブジェクトをインスタンスとして保持するやり方であろう。
しかし、オブジェクトの実態が小さいときは問題が出にくい(大雑把には数千件)が、オブジェクトが大きくなると処理に時間がかかり、その間に接続が消失してレコードオブジェクトも失うと言うトラブルが絶えない。

3.ITシステムを実体化させる元データ

枠組みだけクライアントに常駐させ、設定データのファイル(以下INIファイルという)だけITSDBから取得、利用する。

データベースに実行ファイルやソース及びデータまで全て格納しておき、必要に応じてクライアント側に送り込むという方法が一般的であろうが、これだとトラフィックが多くなり非効率になる。基本的にクライアントは利用したいサブシステムのID、データ操作の結果だけを送り、処理はサーバーに任せ、処理の結果の表示データだけサーバーから受けるというシンプルな形にしたい。

利用手順のイメージ

1.メニューを選択する
サブシステムIDが特定される

2.ITSDBにアクセスする
引数=サブシステムID

3.ITSDBからメニューで指定したサブシステムのソース(または実行ファイル)を取得する

4.取得したソースを実行して、そのサブシステムを起動する

5.そのサブシステムを使う

6.そのサブシステムを終了する

7.ソースを削除する。

システム構築手段の研究・アイデア

ITシステムを構成する各種部品のソースまたは、実行ファイルを全てデータベースに格納してしまうと言うアイデア。ITシステムデータベースをITSDB(IT System Data Base)と呼ぶ。

ある手順でITSDBにアクセスすると完全自動で瞬時にリアルなITシステムが実体化されるというアイディア。

実体化は、その時必要なサブシステムに限定され、そのサブシステムの利用が終るたびに破壊される。

必要なデータはITSDBの管理範囲内に置かれ、不正なコピーを防止する。

必ずTCP/IPを通信手段としてITSDBにアクセスするため、DB側からアクセス権限や料金徴収の一元管理が可能となる。

例 フォーム及びフォーム上に配置するGUI部品

【フィールド構成の試案】 
----------プロジェクトマスタ-------------
プロジェクトID、フォームID、GUI部品ID、製作日時、更新日時、ソーステキスト、配置ファイル名

----------パーツマスタ-----------------
パーツID、種類ID、プロパティ名、プロパティ値

----------プロパティマスタ---------------
パーツIDプロパティID、プロパティ名、ディフォルト値、設定値

NK2グループ生産方式の前に-その3

「売れたらつくる」方式がなぜ現実に出来たのか。

1.超シンプルな仕組みで自由度が高い。


(1)製品ごとに在庫の基準を大まかに決めておく
(2)製品ごとに在庫数(完成品+仕掛)を登録しておく
(3)製品ごとに在庫数から毎日「①売れたら引く②つくったら足す」を計算する
(4)在庫数が基準より小さくなったら、パソコン画面に上でその製品に赤ランプを点灯させる。
(5)現場は赤ランプが点灯した製品とその材料寸法などの情報を画面でみて加工順序と量を決める。
(6)時には、赤ランプが点いていない製品でも「赤ランプ」の点いた製品の「ついで」に一緒に加工することも認めらている。
(7)現場が加工した製品の種類と量は毎日現場が現場でデータを入力して在庫に反映させる。

NK2グループ生産方式の前に-その2

NK生産方式によって、生産進捗のポイントは電算システムになった。
間接的な人間はドンドン手を抜いた。

現場は困った。部品の条件が変わるとマスタに反映しなければならないのに、NK生産方式で完全に手が抜けると勘違いし、手を抜いてしまった。電算機のことは「分からない」ということが最大の言い訳に出来た。

現場が困り、システム開発者も困った。なぜなら、電算機が分からないから維持できないと言われ、やむを得ずマスタの反映、在庫データの修正などの作業も仕事に加えざるを得なかった。

時には現場は、パソコンを工場の外に投げ捨てた。でも止めて、元の木阿弥になれば、毎日ケンカの状態に戻ってしまうのも絶対嫌だった。

システム開発者は、現場でシステム内のデータを維持できる仕組みを作った。間接スタッフが完全に手を抜いた何割かの工数を現場で負担せざるを得なかった。

現場の手におえなくなるほど、データに異常が増えたとき、現場は上司に訴えた。でも、上司にスキルがなく、システム開発に頼るしかなかった。システム開発者は、自分の仕事を中断させてでも、請け負った。「昔に戻る」ことだけは避けたかったからだ。

■■■■■■
教 訓
■■■■■■
改善で、確かに「ラク」になる。でも、活動そのものを「ラク」にしてはいけない。それは「ダラク」だ。
よりレベル高い、より深い問題を解決するために、力を振り向ける対象を変化させていくことが重要なのだ。

NK2グループ生産方式の前に

足掛け10年前からNK生産方式というものを開発した。
今も、元気よく動いている。

基本は「売れたらつくる」

なぜ、「売れたらつくる」なのか、開発当時を思い起こしてみる。

1.内示は振れるのがあたりまえ。
2.確定指示は直前にならないと来ない。
3.材料入手は約3ヶ月前から着手しておく必要がある。
4.加工する機械は3台なのに約900点の種類がある。

毎日が生産進捗担当者(複数)と加工現場のケンカのような状況であった。現場能力の奪い合い。
私は、現場の親方に取り入ろうと努力したほどだ。

現場も苦しんだ。殺し文句は「欠品を起こせばラインが止まり、わが社は吹っ飛ぶ」だ。


だから何とか、理論的に優先順位を決めて、能力の範囲でケンカをしないで楽しく仕事がしたい!
そう考えざるを得なかった。

頼りになる情報は、他に無かった。「売れた」という事実データぐらい確かな情報は。

売れたと言う事実は、電算機で売上計算をしているので、容易に取得できた。売上があがっているのに売上データがないということは無いハズ(当時はまじめにそう考えていたが、実際は問題があった)