小説なのに、濃すぎ。どんだけ付箋貼ったんだろう。
ザ・ジャストインタイム 現地現物が最高の利益を生む | |
 | フレディ・バレ マイケル・バレ 松崎久純 おすすめ平均 |
予想以上に深みのある物語
「トヨタ生産方式小説」以上の内容でした <p>
</p>
<h5>
不具合
</h5>
<p>
不具合が発生しているに違いないが気づかなかった＝不良部品を見つける仕組みがない＝欠陥のある部品が完成品に入っていないという保証がない。
</p>
<p>
不良品は受け取らない。そのためのレッドビン。<br />→レッドビンとは、受け取った前工程からの部品に不具合があったら入れておくゴミ箱です。<br /> 各工程でまず受け入れ検査をしましょう、はいいのですが、同じものを大量生産する場合と違って、それを捨ててしまうと別の部品がなく、すぐに作業が止まってしまいかねないわけですね。それで「見える」ようになるのは良いとしても、なかなかその遅れを許容されることはない。であれば、ある受け入れ検査日を決めて待つのではなく、もっと細かい単位で受け入れていかないといけないのではと思いますね。
</p>
<p>
作業者は実際は直接ラインを止めるというよりは、マネージャに助けを求める。そしてその回に対処できなければ止める。
</p>
<p>
不良を止めるというのは、まだ事後の話。品質を作りこむ話にはなっていない。<br />→単体テストでも本当は遅くて、単体テストで発生しうるバグを防止するような作り方＝標準作業の手順が必要。しかし、そんなすべてを手順化できるような定型作業をやっているわけではない。とは言っても、標準化できる余地が多数あるのも事実。
</p>
<p>
試験も教員の評価も学期の終わりにしかしないのはなぜだろう。終わった後では手の打ちようがないのに。
</p>
<h5>
コスト
</h5>
<p>
価格＝コスト＋利益 ではなく 利益＝価格－コスト<br />→金曜日に飲みながらこんな話が出て、やはり普通は左のように考えてしまう。しかし、若い人がそう考えるのは、そう教えられているからに他ならない。しかも、ある意味現在のSIはそれで行けてしまっている。毎回特注だから毎回特別な値段。見積根拠も工数。顧客もそれを求める。しかし、ここでも「理想的な顧客」（後述）に合わせて価格を決めるようにしていかないと、誰かが始めたら、あっという間に置いて行かれる。
</p>
<h5>
1個流し
</h5>
<p>
理想を実現できれば、必要な部品の数はラインにつく作業者の数と等しくなる
</p>
<h5>
5S
</h5>
<p>
ガラクタが本当に必要かを確認することは、単にそのガラクタを処分すること以上の意味がある。何かに使っているかもしれない。だとすると、本当に心配すべきは、工程に問題があることに気づいていないこと。<br />→なんで机の上に複数のプロジェクトの資料が置いてあるのか。決まってるでしょ。複数のプロジェクトの連絡が来るからです。聞くならなんで複数の連絡が来るのかを聞いてくれ。（いや、反省もしているんですけど）
</p>
<p>
清掃でガタの来ているところを発見して取り替える。清掃は本質的には、点検とメンテナンス。<br />→やっぱり、コードも清掃すべきだなぁ。
</p>
<h5>
監督者
</h5>
<p>
生産工程に問題がある時でさえ、監督者が作業者をシフトさせ、次々と材料を送り込む。いったんそうなってしまうと、決められるのは、何を優先して何を後回しにするかということだけだ。だから、どの注文が重要かを勝手に決めて推し進め、ほかのすべてを犠牲にしてしまう。
</p>
<h5>
在庫
</h5>
<p>
無駄はほとんど目に見えない。だが在庫は目に見える。その裏にムダが推測できる。<br />→ソフトウェアでは何が目に見える？残業とか？
</p>
<p>
作業量がきわめてアンバランスだったとしても、何もしていないところを見られたいと思う作業者はいない。手元に在庫がある限り、作業者は別の作業ができてしまう。キャスター付き台車で運ぶメタファー
</p>
<p>
「理想的な顧客」に引き取ってもらう<br />→「理想的な顧客」は、それが必要になるタイミングで引き取りに来たいはず。運送コストその他の事情で、そうはいかないが、それに合わせて、出荷同然の状態にしておけば、その前の状態の在庫を持たなくてよくなる。<br />ソフトウェアの「理想的な顧客」は、どういう風にそのソフトウェアを欲しがるだろう。
</p>
<p>
生産計画にしたがうということはプッシュしているということ。プルとは、消費されたものを消費された順番に製造するということ。<br />→まめにスケジュールを見直すのも良いかもしれないけど、なぜ見直すかと言ったら、結局、その後の工程とか納品に影響を与えないようにするため。とすれば、後の工程がどのように進むかに従って自動的に次の作業が決まるようにするカンバン的なものがあればよいのでは。カンバンは後工程から帰ってくるものでないといけないのでは。ちょっとプロジェクト管理的なツールを考える際のヒントになった。
</p>
<p>
工場内の容器はすべてカンバンをつけていなければならない。
</p>
<h5>
人
</h5>
<p>
アティチュード<br />→”Be Agile. That’s my attitude.”を思い出す！<br /><a title="http://blog.shos.info/archives/2005/02/be_agile_thats_my_attitude.html" href="http://blog.shos.info/archives/2005/02/be_agile_thats_my_attitude.html">http://blog.shos.info/archives/2005/02/be_agile_thats_my_attitude.html</a><br /><a title="http://www.atm
arkit.co.jp/fdotnet/nagile/nagile02/nagile02_05.html" href=“http://www.atmarkit.co.jp/fdotnet/nagile/nagile02/nagile02_05.html">http://www.atmarkit.co.jp/fdotnet/nagile/nagile02/nagile02_05.html
人はコストではなく資産
→個人的には、会計管理上は固定費にしてほしいと思っている（人件費と生産量が比例しない）が、そもそもコストか？ということ？（もっと抽象的な話をしているようにも思うし、じつは具体的な話をしているような気もする）
その他
「目標はスマート（Simple,Measurable,Achievable,Realistic,Time Constrained）でなくてはならない。」「そのわけのわからんアルファベットのごちゃまぜは役に立つのかね？実際の人間や、仕事、問題に対して」
→一瞬いいんじゃないと思って、すぐに赤面させられる。そうです。スマートな言葉で分かった気になってはいけないのです。
上のアマゾンの写真でも雰囲気が出ていますが、カバーがキラキラしてます。ムダでは・・・。