今回は、リーン生産方式とリーン製品開発について解説します。リーンとは何でしょうか。リーンとは、英語のleanのことで「やせた」、「細い」、「筋肉質の」、「脂肪のない」という意味です。
【目次】
1. リーン生産方式
1、リーン生産方式
1980年代に、アメリカのマサチューセッツ工科大学で、ジャストインタイムなどのトヨタ生産方式の研究が始まりました。見える化の手法を基に、製造の現場におけるムダを徹底的に排除し、継続的に改善していくというものです。欧米の製造業中心に、リーン生産方式（Lean Manufacturing / Lean Product System）は広がり、大きな成功を収めました。
2、リーン製品開発
製品開発は、生産現場とは大きく異なる点があります。
生産現場では、仕事が繰り返されます。不良品や仕掛品のムダが比較的分かりやすくなっています。しかし製品開発では、ほとんど繰り返しがありませんので、ムダが分かりにくいのです。
リーン製品開発（Lean Product Development＝LPD）では、製品開発でのムダを見える化し、それを削減します。そして開発のスピードや生産性を劇的に改善します。
開発スケジュールの見通しが良くなり、開発期間が短縮され、マーケットニーズの変化に対して迅速（じんそく）に対応することができるようになります。その結果、会社のバランスシートが改善されるのです。
リーン製品開発では、開発のワークフローを見える化し、ボトルネックを見つけ出します。ボトルネックは、開発のスピードを決するところです。それを緩和するようにチームで協力して対処します。
また、リーン製品開発は、開発チームの行動様式を変えていきます。そして、会社のカルチャーを変えていきます。各々のコミットを基に、クロスファンクションでの共同作業を推進します。ワークフローを見える化し、それぞれのタスクを誰が責任を持っているのか、そしてマイルストーンをチームでいかに成し遂げていくのかを明らかにします。問題となる前に、リスクを回避するのです。
3、製品開発のムダとは
開発プロジェクトにおける大きな制約条件の一つが「時間」です。リーン製品開発では「付加価値のない仕事」に割り当てる時間を削減して「付加価値のある仕事」に割り当てます。その結果、製品開発のスピードが早くなり、望ましい成果が得られるのです。
4、開発のスピードを遅くするムダとは
製品開発には、どのようなムダがあるのでしょうか？次のようなことは、全てが製品開発のスピードを遅くします。
【割込みが絶えない】
仕事は、あなたのマネージャーから指示されるだけではありません。そのマネージャーの上司やカスタマーサポートほか、量産工場やサプライヤー、さらには休み時間に会ったコーヒー友だちからも仕事は舞い込んできます。「緊急！」とか「あの人に頼まれたら断れない」といった理由で、新たな仕事の「割込み」が発生します。それまで集中して取り組んでいた仕事が、途中で「仕掛かり」状態になってしまいますので、その中途半端な仕事は多分、最初からやり直さなくてはなりません。
【リソースが不足】
開発リソース（人員）不足は慢性的です。特に、優秀で特殊なスキルを持っている人の席には、待ち行列ができています。ボトルネックとなっていることは分かっていても「余人に代えがたい」とあきらめていませんか？その時には、何とかやりくりできたとしても、また同じことを繰り返します。
【優先順位が不明】
トラブルが一つ発生すると、同時に複数のプロジェクトで、同じようなトラブル処理が必要になります。複数のプロジェクトマネージャーが「私のプロジェクトが最優先！」と、我も我もと日夜フォローのためにあなたの席にやってきます。あなたのマネージャーに「どのプロジェクトから手掛けましょうか？」と質問しても「どれも最優先！」と冷たい返事が返ってきます。その結果、複数のプロジェクトの仕事を「並行」して手を付けることになります。
【リスクが軽減できていない】
プロジェクトが始まるころは、やる気満々です。将来に訪れるはずの成功を思い描いています。「リスク」など考えたくもありません。プロジェクトが崩壊するようなリスクは、決して口にしたくもありません。「言霊」になって、実際に問題（イッシュー）となるからです。ましてや、問題となる前にその対策を考えたり、処置しておくような時間はありません。コストや時間が、さらに必要となろうが、問題となってから火消しにまわったほうが、マネージャーから「認知」されるからです。
【知識や経験は自分だけのもの】
これまで学んだことや、知識は自分だけのものです。ましてや他の人のために文書として残しておくようなことはしません。「先輩の背中を見て学べ」と教えられましたから。でも、後輩が自分と同じような失敗をすると「どうして俺に相談してくれなかった」のかと思いませんでしたか？
【製品の要件がちゃんと定義できていない】
お客様がどういったものを欲しがっているのかを定義すること、それはビジネスの上では大切です。「お客様中心」ですから。開発者が作りたいという趣味のものや「できるのはこれだけ！」という仕様では、他社と差別化できませんので、売れません。
【製品の要件が劇的に変更される】
プロジェクトが一旦スタートすると、途中でかなり要件が変更されても、それを止めるには、かなりの勇気が必要です。しかし、売れないと分かっているものを開発し続けることは、大きなムダです。
【生産性を開発初期に考えていない】
要求機能を満足するものを開発するだけで、精一杯です。ましてや、量産できることまで頭がまわりません。「ピカピカ」のプロト機が数台できあがっても、...
【設計マージンの取り過ぎ】
開発のトラブルを避けるあまり、自分が担当している設計マージンを過剰に確保していませんか？サプライヤーや他部署に過剰なスペックを押し付けていませんか？部分最適化をすると、余分なコスト負担となるものです。
【大量のメールやミーティング】
会議で、スケジュールがほとんど埋まっていませんか？プロジェクトの報告会議、機能組織の報告会議、幹部の講話、サプライヤーやお客様との会議、海外とのWeb会議などなどです。でも、それらの会議で何が決定されましたか？「報告会議」って何のためにしているのでしょうか？また、メールが来たら返信しないといけませんね。でも、長いチェーンメールで、結論がないものが多いですよね？会議中に、たまったメールに返信していませんか？
5、付加価値のない仕事を削減すること
上記のこうしたムダを認識して、それらを徐々に削減しましょう。すると、会社の競争力がどんどん強化されていきます。下図のように会社の利益は、売上から「付加価値のない仕事」と「付加価値のある仕事」を差し引いたものです。付加価値のない仕事を削減しましょう。そうすれば、会社の利益が向上し、競争力が強化されていくのです。
【出典】ピディアック株式会社 HPより、筆者のご承諾により編集して掲載