アイデアを実現できない理由がいっぱいあっても、それはアイデアがダメな証拠ではない
いい本なんだけど
「Joel on Software」を読む。めちゃくちゃ面白い。
ここには理想論はない。ソフトウェア開発者がかわいそうな状態にならないための現実的な策がいろいろ載っている。
例えばスケジュール管理は、Excelでたったの７列からなる表を作ってやれ、MS Projectなんて使うな、とか。
理想論に走らず、自分が苦痛なしにできることをする。やるのは自分なのだから。
そういう精神で書かれているので信用できる。
ただし、著者はパッケージ屋さんであり、同時に腕の良いプログラマなので、受託開発ばっかりやっている平均的プログラマには使えない提案も多い。
たとえば「23. 人のタスク切り替えは有害であると考えられる」はこんな話。
10コマの時間がかかる２つの作業をシングルタスクとマルチタスクで処理した場合どちらが効率的か。
作業１を10コマぶっつづけで処理し、次に作業２を同様に処理すると、答えが出るまでの平均時間は15になる。
１コマずつタスクを切り替えて作業１・作業２を並行処理したら、答えが出るまでの平均時間は19.5になる。
だから、段取替えの時間が０だと仮定しても、プロジェクトを並行させるより、１件ずつ処理する方が効率がいい ... て、知ってるよそんなことは。
でもウチでは並行プロジェクトが発生するのは避けられないんだ。
大野耐一はこう考えた
弊社の場合、受注量のコントロールはできないししない、というのが前提だ。
- よい仕事なら全て取りに行く。
- 人が足りなかったら開発部隊の創意工夫でこなす。
というのがウチの方針なので、全員が並行プロジェクトを抱えて仕事をしている。
TOCの理屈で言えば、全員を100%で稼動させている組織は非効率だ、というのはみんな知っている。
それでもウチは「マルチタスクで動いているからこそ効率的」という境地を目指して、何度でも試行錯誤するのだ。
大野耐一「トヨタ生産方式」は、自分の頭で考えることのものすごい可能性を示して感動的だ。
仕事でも日常でも、１つの問題の解決策が次の問題を呼び込むということがよくあるが、そういう時に「ああ、出発点が間違っていたなのだな」と諦めてしまうのはよくない。
問題が何度現れても、決してアイデアを捨てずに、１つずつ解決してゆくと、ついには全ての問題が解決してしまう。
同書を読むと、プロセスイノベーションというのはそのようにして生まれるものなのだなと思い知らされる。
大野氏の最初のアイデアは「ジャスト・イン・タイム」によるムダの極小化だ。
P-9
「ジャスト・イン・タイム」とは、一台の自動車を流れ作業で組み上げてゆく
過程で、組み付けに必要な部品が、必要な時にそのつど、必要なだけ、生産
ラインのわきに到着するということである。
その状態が実現されれば、＜中略＞在庫をゼロに近づけることができるであろう
と考えたのである。
では、各工程がちょうど必要な数を生産するためにはどうしたらよいか。
トップダウンで各工程の生産計画を作っていたのでは、予測が外れたとか不良が出たとかで、欠品と在庫が必ず生じる。
ならば、各工程が売れた分だけ作る＝「後工程引取」にしたらどうか。
P-11
いま「後工程が前工程に、必要なものを、必要なとき、必要なだけ引き取りに行く」
と考えてみたらどうか。そうすれば、「前工程は引き取られた分だけ作ればよい」
ではないか。
このアイデアを実際にやってみるとどうなったか。
...残念。逆に在庫が増えてしまったのだ。
P-59
いちばん問題となるのは引き取るほうが同じ種類のものをまとめて引き取ることである。
こんなことをしたら、前工程はたちまち欠品を起こしてしまう。在庫をもって対応しようと
しても、どの品物が引き取られるか分からないからＡもＢもとおのおのたくさん在庫を持たないと
やっていけない。
あちこちの前工程がみなこんなことをやり出したら、それこそ工場のいたるところで在庫の
山ができてしまう。
後工程引取に転換すると、いつ大量の引き取りが来るか分からないので、かえって作りすぎてしまうのだ。
後工程が持っていく数に波があるから、前工程は在庫をためる。ならば、波がないようにしてしまえばよい。
そう考えた大野氏は、同じものをまとめて作らない＝「生産の平準化」という概念に到達する。
生産の平準化をほんとにやってみると、トヨタの工場の中は一見非効率な風景になる。
P-69
１つのラインではコロナとカリーナが交互に流れている。
午前中はコロナ、午後はカリーナと、まとめて生産することをしない。
素人目には「そんなことして大丈夫かな」という感じがする。
案の定、平準化は次の問題を引き起こした。
P-70
ロットを小さくして、なるべく同じものを続けて流さない「平準化」の考え方は、当初、プレス
部門にとっては過酷ともいえる要求であった。
ロットを小さくするということは、同じ金型で長く打ちつづけてはいけないことである。
したがって、めまぐるしく変わる製品の種類に応じて、プレスの金型を替える、いわゆる
「段取替え」をひんぱんに行わなければならなくなった。
段取替えにはえらい時間がかかるのが当時の常識だったが、トヨタは、この最後の問題を現場の工夫とトレーニングで克服してしまう。
P-71
トヨタ自工内部のブレス段取替えは、昭和20年代、2,3時間を要していた。それが30年代に
はいって社内の平準化生産を推進するに従い、1時間を大きく割り込み15分となり、40年代
の後半には、わずかに3分にまで短縮したのであった。
アイデアを実現できない理由がいっぱいあっても、それはアイデアがダメな証拠ではない
大野氏の何がすごいって、ジャスト・イン・タイム -> 後工程引取 -> 平準化 -> 段取替えの高速化 と、できない理由が何度現れても１つずつ解決してゆく姿勢がすごい。
生産の平準化を始めた時は、現場も「こりゃー効率悪いや」と思ったはずだ。
世界中の工場が同じ車種をまとめて作っているのに、自分たちだけが２種類を順番ごっこに作っているのだから、モノになるわけないと思った人もいたはずだ。
だが、できない理由はゴールのある方向を指し示しているのだ。
目の前にあるできない理由をとにかく解決する。それが次の問題を呼び込んでも気にしない。
問題解決のループひたすら繰り返すことで、いつか出口に到達し、振り返ってみると全てが連鎖的に変わっている。
やり方を変えるとというのは、そういうことなのだろう。
自動車の場合、コロナとカリーナを交互に組み立てることが、それぞれをまとめて組み立てることよりも効率的だった。
「マルチタスクで動いているからこそ効率的」「タスク切り替えが頻発してるけどマクロで見ると効率的」という境地は、ソフトウェア開発にもあるはずだ。
