「モノの流れを作る人」を読んでます１

トヨタ生産方式（TPS）に少し興味が出てきたので、どこかのWebサイトでおススメされていた「モノの流れを作る人」原田武彦著　を読んでいます。どうせ工場の話でしょ、と思っていましたが、全然ソフトウェア開発にも適用できますね。まぁいろいろ前提が違うところはありますが。ソフトウェアTPS、なんて言いだす人も出てきそうですね。それはリーンか…。

気になった箇所を引用しつつ、ソフトウェア開発やソフトウェア品質に紐づけて考察してみます。

生産性をあげて　造りすぎは抑える　そして少人数でやる

もう、ほんと、どんなアジャイル？ですよね。アジャイルがTPSから強い影響を受けていることがよくわかります。ここはソフトウェア開発でもすでに言わずもがなになっているので、これ以上のコメントは避けます。

改善とは最終工程に近づくこと

最初は文意が取れませんでした。「最終工程」を「理想的な工程」と読み替えると伝わると思います。これはプロセス改善どこにいっても適用できる話ですね。ソフトウェアで言うと「パッチ当てはだめよ」みたいなもんでしょうか。

局所最適化すると、最終的には全体最適から遠ざかるよ、全体観を持ったうえで改善を進めようよ、と言ったところでしょうか。ソフトウェア開発でもよくある話で、例えば、自然言語の仕様書があってそこから仕様書品質を上げるために自然言語処理を導入し欠陥を20％減らした、みたいな話がありますが、それって自然言語の仕様書が最終形なんだっけ？という問いから始める必要があるよね、ということです。とても納得感がありますね。

ロット形成はモノづくりの進歩を妨げる。かんばんをためるな。外れた順に仕掛けよ

生産ラインである前提で、この話はとても理解できます。しかしこれはソフトウェア開発に適用できるんでしょうか。流れが滞留しているところには必ず何か問題があるはずだ、という抽象度であれば納得できるのですが。

やっぱり、手を動かすことが中心なのか、それとも頭を使うことが中心なのかでここが少し変わってくるような気がしています。ソフトウェア開発の中でも手を動かすことが中心の作業であれば、同じ話が適用できそう、と思います。

1人で全工程の作業を

減産時に手待ちが発生せずに対応できる方法として紹介されていますが、これはアジャイルにおける「多能工」の話に近いですね。ソフトウェア開発の方は目的が少し違って、お互いに助けられるように、みたいな文脈ですが。

なんか響く話が多すぎて全然終わらないので、次に回します。今回はこれでおわり。