  |
はてなキーワード: ジャストインタイムとは
「うちが欲しい時に欲しい分だけ部品くれ」ってやり方だから何事も起きなければト○タ的には最高に効率がいいのかもしれないけど、下請けはト○タの都合にひたすら振り回される本当に大変なシステムなんだろうな
さっき工場稼働停止のニュース見てたらトラブルのあった部品メーカーとは別の企業が生産ストップせざるを得なくなってるそうで、ト○タ本体よりこういう下請けの方が気の毒に感じてしまった
親がト○タで働いてて、小さい頃にこのジャストインタイムというシステムの話を聞かされた時は「なんかすごいんだな〜」と漠然と思ってたんだけど、いざ自分が大人になったらすごい嫌なやり方に見えてしまって正直苦手意識がある
リアルでは言わないし言えない(親に悪い気持ちとその無茶振りシステムによる儲けで自分が育てられた側面とで)から増田に書いた
単純にロジスティクス(日本語だと兵站)の概念が欠如していることが問題だと思う。
はっきり言って、最上流(政府が各自治体に何個発送したか)と末端(現場で何回打ったか)だけで在庫管理なんてできるわけがない。
最上流から末端へワクチンが流通していく際に、中間に倉庫が1つ以上存在している。というのも、輸入量が毎日一定ではないし、消費量もまた一定ではない。ワクチンを一度倉庫へ搬入しある程度の量をプールすることによって供給量の変動と消費量の変動をクッションする機能を果たしている。在庫管理の世界ではこの中間部分の入出庫情報の管理もまた重要と考えられている。
製造業的には在庫管理というよりかは仕掛品(しかかりひん)の管理というやつ。仕掛品を少なくすると製品の製造に着手してから出荷されるまでのLT(リードタイム)を短縮することができる。ワクチンにおいては「あるワクチンを政府が輸入してから我々が接種するまでにかかる時間」がLTで、これが短くなることを意味する。全体LTの把握と短縮は多くのメリットを提供することが知られている。広く知られている知識なのでメリットの詳細については適当にググってほしい。ちなみにT社のジャストインタイム方式は仕掛品をゼロにする活動のひとつ。よくできてる。
その結果「来週からワクチン足らないからキャンセルで！」みたいなことがなくなり、スムーズな摂取に寄与できると考えられる。
兵站という概念がないと「末端から上がってくる数字だけ見ておけばいいや」という発想に陥ってしまう。しかしながら製造や物流の世界では極めて当たり前の概念なので当然ノウハウもある。時間がないのだから民間のそういうノウハウを吸い上げてシステムを構築して欲しかったし、そういう所に税金を投じて欲しかった。VRSの問題は末端の管理方法の問題ではなく、もっと根深いところにある。
「VRSの入力遅れのせい」って主張、一件単位のデータが出てこないなら、各自治体にワクチン消費数の概算だけでも出させて需要予測すればいいだけだと思うんですよね。たぶん、本当の原因はそこにはないんじゃないか。
仕組みはありましたが、既に終わってます→V-SYS。VRSとの二重作業に不満が多く、一般接種では5末に「入力不要」になりました
これだな。教えてくれてありがとう。
なぜ一本化するのがV-SYSではなく、入力作業が非常に煩雑で大不評な（バーコード入力が事実上使い物にならず手入力強制）なVRSなんだろう。やはり例によって、官邸の肝入りで強引に開発・導入したシステムが早々にお蔵入りになるのは面子が許さないとか、そういうくだらない理由か…？
VRSは、もしきちんとしたものができていれば、日本のワクチン接種を加速させるゲームチェンジャーになっていただろう。だが、実際には使い物にならないものを作ってしまったわけで、そこを認めず撤退しないのはどういうわけだ。
世間では「VRSを無視した明石市にワクチンが届かないのはブーメランで自業自得」という風潮になっているが、俺はおかしいと思う。接種一件一件の入力（「◯◯県◯◯市の増田太郎さんは接種を受けました」）を集計して統計を出すシステムは、そもそも普及率が上がらないと話にならないのは誰にでも分かることだ。ワクチンの流通状況を把握するのは本来なら必達目標のはずで、最初から集計値を入れさせるV-SYSにしないのは全く合理的ではないと思う。
もし、それを分かった上でなお、不正確な値しか出せないVRSに拘っているなら、ワクチンの正確かつリアルタイムな流通状況を曖昧にしておきたい裏の事情があると勘繰られても仕方がないんじゃないか。
泉市長の訴えに対し、「首長の怒りはもっともです」と政府関係者はうなずく。
「ワクチンの差配は正直、利権化されていて、実質的にそれを仕切る官邸は“ワクチンマフィア”と裏で呼ばれています。各県からの要望数量を認めたり、割り落としたり、どのように差配しているかは正直、ブラックボックス。VRSのボロタブレットで文句を言った自治体を含め、菅政権に従順でない自治体、更にリアルな話をすると、首長が自民党以外の自治体への配布を減らしたりといった恣意的な運用はあると聞こえてきます」
河野氏は6月23日の記者会見で、今後のワクチンの配送計画について「目をつぶって綱渡りをするようなオペレーションにならざるを得ない」と漏らした。そのうえで、在庫を減らして必要なものを必要な時につくるトヨタ自動車の生産方式を引き合いに見通しを語った。
「自動車工場のようにジャスト・イン・タイムというわけにもいかない。すぐにVRSで（職域の）数字が見えないので、正直ちょっと厳しいと思っている」
おいおい…。
ていうか、やっぱりJIT（ジャスト・イン・タイム）がやりたかったんだな。確かに実現したらTwitterで信者にドヤ顔できるもんね。だがこの調子だと、JITのキモは「かんばん」のような洗練された情報システムの整備に加えて、それを使いこなす現場作業員の意識改革だということを全く理解してないな。今、どっちもダメじゃん。それをムチで脅してゴリ押しすればどうにかなるとか思っているのだとしたら、JITを舐めすぎ。とりあえず大野耐一の「トヨタ生産方式」を100回読んで出直してこい。
ジャストインタイムやりたけりゃ、普通に発注点カードでアナログ→デジタルのカンバン方式で十分じゃねーの説を唱えたい。発注点カードが現れたら、スマホでQRコード読んでURLにアクセスで発注指示が出る奴よ。
そうそう、サプライチェーンの仕組みづくりってそういうことよ。パワハラとマイクロマネジメントを管理だと勘違いしている自称「運び屋大臣」には理解できない発想かもしれないが。
ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。
今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。
「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。
タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー
面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。
Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。
かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日にリリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。
今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。
Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日にオラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」（The Network is the Computer）というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。
当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。
1996年の時点にこんな言語が登場したのですから革新的でした。
いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。
プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロード、テンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。
Wikipediaからピックアップすると1.1での大きな機能追加は
といったところです。当初よりJavaの内部文字コードはUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ！というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。
なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。
当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。
JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアのフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。
Microsoft Visual J++ もこの時代ですよ。
Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。
当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。
この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。
strictfpキーワードは浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。
リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassをロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。
1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。
初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。
JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードにコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。
あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。
Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつがMicrosoftだったわけですね。
Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルはMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの！と喧嘩になったわけです。当時のMicrosoftはブラウザまわりでも独自拡張がやりたい放題、標準規格？なにそれ美味しいの？みたいなスタンスをあちこちで見せていたものです。
結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。
JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。
Java SE とは別にこの時代に Java EEがリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。
2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットのサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的なユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。
企業で用いられる社内システムにもServletは多く採用されました。
理由はいろいろ挙げれると思うのですが
というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャはある意味では便利で簡単でした。
もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。
2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホ、ガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。
そこにdocomoのiアプリ、Jフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ！というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリはちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。
iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。
docomoはiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。
この賭場が、将来にAppleのiPhone, GoogleのAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoはSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。
話を2001年に戻しましょう。
Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。
Java Appletがブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。
Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。
端的に言えば入力値が数字かどうか？みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。
また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。
こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい！という要望があったわけです。Webシステム使いにくい！という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。
Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。
RIAの代表とされるのは
あたりです。三つ巴の戦い、どこに軍配が上がるのか！？と注目されましたが、勝利したのはHTML / JavaScriptでした。
Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。
RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントのひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。
しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。
1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。
Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。
言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。
Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。
Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日にオラクルに吸収合併されました。
Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。
やや戻って2007年にAndroidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。
Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。
このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語も次世代へと移りつつあります。業界動向には注視していきましょう。
anond:20150920130007 の理屈は変だ。
今の祝日は週末につながっているのが普通で、飛び石にならない。ゆえに、止めたり動かしたりする回数は変わらない。
たとえば、今回の連休は、
土日
土日月火水
のどちらでも、止めたり動かしたりする回数は同じである。（時期がズレるだけだ。）
納入する部品は、すべて5日分を1ロットとして考えるだけで済む。今週は4日しかないから普段の80%の製造量にしなくては、などと例外に対応する必要がない。
トヨタはカンバン方式でジャストインタイムで最適の量を納入する。「5日分を1ロットとして考える」なんて、カンバン方式よりも前の、ずっと古い方式だろ。在庫管理をコンピュータで制御できる時代に、何を言っているんだ。50年前の手書き伝票時代と間違えているんじゃないのか？
また、「今週は4日しかないから普段の80%の製造量に」なんてことはない。普段の100%の製造量にして、稼働日数を80%にするだけだ。自動的に調整が付く。普段の80%の製造量にしたら、稼働日数が80%なので、生産量は64%になってしまうぞ。勘違いするべからず。
では何があるかというと、「ほとんどあるかなきかの小さな会社の利益向上のために、従業員に多大な迷惑をかける」ということだ。「自分が１円の利益を得るために、従業員に100円の損失をもたらす」ということだ。
こうして、従業員の生活を犠牲にして、家族の団らんを破壊することで、エゴイズムを貫徹する。乾いた雑巾を絞り、従業員の血の一滴も絞るようにして、ひたすら自社の利益を上げようとする。
- - - - - - - - - - - - - - - - - - - -
すべては自民党のおかげだよ。
きみたちが自民党にいっぱい投票したから、自民党はお返しで、労働者を虐待して上げるんだ。
マゾな労働者は、「嬉しい、嬉しい」と感謝して、鞭打たれていろ。
※ 最後の「きみたち」とは、トヨタ労働者のことではない。一般国民（の大半）のことだ。
ここでは話が変わっている。わかりやすくするために、あとで区切り線を入れておいた。
追記しておくと、トヨタの海外工場は、原則として、現地の労働法制に従っており、違法な行為はしていない。（日本と同じならば、違法になることもあるが。）
たとえば、フランスでは、法律を守って、週 35時間労働で、バカンスもある。
http://www.mynewsjapan.com/reports/1262
http://www.ritsumei.ac.jp/~hyodot/semihomepage/kenkyutenkai3.html
社会主義の方は、読み手（の感覚）が分かりやすい表現ってことで例を挙げた感じです。
流通か・・・確かに余り考えてませんでした。
現場を知らないので何とも言えませんが、Amazonの場合は1日に何回もトラックがモノを運んでると考えると、トヨタの「ジャストインタイム」のような方式を採用しているはずです。
となると、トラックを若干待たせる（トラック運転手に払う給与が増える）という無駄はあるものの、運送会社に膨大な数の注文を出すと言う立場を生かして、量販店よりも流通コストを安くできるのではないでしょうか？
デルは組立工程をを運送会社に投げて、運送会社自身が組立すぐ発送と言う手法を取ったとかなんとか。（大前研一「新・資本論」）
流通に関しては良く知らないので、良い解説を頂けると嬉しいです。（単に知りたい）
デルとAmazonの比較ですが、後者は複数のジャンルにわたる商品を1つのボックスに詰めるわけですから、工場の固定資産税、箱詰めする従業員の賃金、などがかさみますね。
あと、
>>巨大資本と零細企業の競争に関しては、飛躍があり過ぎて話にならない。<<
と
次回以降、もう少しまともな記事を書けるようになるためにも、流通以外で飛躍してる点と、自分勝手な理論の部分がどこらへんにあるか、そしてそれは何故かを具体的に教えて下さい。（バカですみません）
>>自分勝手な理論から脱出できない。それこそが、別次元同士での不毛な議論を生み出してしまう原因です。<<
確かに良くあることだと思います。
>>（と思うよ）<<
優しさが滲みでてて、嬉しかったです
