ライナーセン氏　1997年に「Managing the Design Factory」という書籍を執筆したのですが、それはトヨタ生産システムのジャストインタイムに触発されたものでした。現在の製造工程は、トヨタ生産システムの登場によって、40年前とはまったく違ったものになりました。ところが、製品開発の世界に、これに匹敵するようなイノベーションは起きていません。製品開発の管理手法は、トヨタによる変革が起こる以前の製造工程と変わらないもので、相変わらず大きなバッチサイズをもって効率化を図ろうとしているのです。

　もちろん、製品開発の世界でも個々の作業でバッチサイズの削減と待ち時間の現象を問題にすることはあったでしょうが、開発工程全体を通して待ち時間というムダを削減しようという統合的な考え方、つまりトヨタのジャストインタイムのように全社で導入できる手法を確立し、それを製品開発に導入しようとする動きはありません。

　リーン製品開発とは非常に新しいコンセプトで、これに言及する人はそれぞれに異なる主張をしていますが、私の考えるリーン製品開発とは、バッチサイズを小さくすることと、待ち時間を削減するということです。

―― 製造工程の中でムダ取りを行うのは、作業が見えるだけに取り組みやすいですが、製品開発の工程管理では物理的な物が登場せず、作業は主にエンジニアの頭の中で行われるので、ムダ取りを行うのは困難ではないでしょうか。

ライナーセン氏　確かに製品開発の工程に存在するムダ取りは、非常に難しいです。在庫を数えられるわけではないですし、設計情報は見えにくいものです。そして財務的な効果も測定しにくいですから。しかし、多くの企業はリーン製品開発についてもっとよく知りたいと考えています。品質に問題があったり、納期を守れなかったり、そうした問題は設計工程に原因があると感じているのです。だから何か新しい開発の手法を求めているのは確かです。

―― 見えにくい設計段階でのムダをどうやって管理したらよいでしょうか。

ライナーセン氏　ITテクノロジーをうまく活用することで可能になると考えています。製造工程における画期的な工作機器の登場が、生産性を飛躍的に向上させるのと同じ役割をITテクノロジーが果たすでしょう。

　例えば、200枚の設計図面をデザインレビューするのに、エンジニアを大勢同じ部屋に集めて意見を出し合うというのは、時代遅れのやり方です。図面というのは情報であって、鉄でできた部品などとは違うのです。鉄製の部品であれば、ある工程が終わってからでないと次の工程に移れないという物理的な制約はあるでしょう。しかし、設計情報は物理的な存在ではなく情報なのですから、同時に複数の場所に存在したって構わないわけです。

　設計とは情報なのだと気付きさえすれば、シカゴにいる設計エンジニアが図面を描いていて、同時に中国にいる製造部門のエンジニアがその図面を見ることは可能なのです。設計エンジニアが10週間かけて作成した200枚の図面をまとめてレビューする時代遅れの開発手法に代わって、PLMのようなITシステムを使えば1枚の図面を作成すると同時にレビューを行い、その日のうちにフィードバックを得られるようになります。

―― 200枚の図面という大きなバッチサイズが、1枚ずつの図面ごとにレビューやフィードバックが得られる小さなバッチサイズに分割できた、ということですね。

ライナーセン氏　コンカレントな設計とレビューを行う前提には、製品開発におけるフィードバックの大切さがあります。もし大きなバッチサイズで設計とレビューを行うなら、200枚の図面を一度にレビューしなければならない。もっと小さなバッチサイズであれば、最終的な図面にたくさんの寸法や公差が描き込まれていたとしても、一度にそのすべてをレビューせずに済みます。小さいバッチサイズで設計とレビューを繰り返せば、重要な寸法や公差に絞って検討すればよくなるわけです。製造におけるロットサイズは物理的な1つの部品以下にはできませんが、設計では部品より細かいサイズである1枚の図面に細分化できるのです。

　例えばエンジンブロックの開発を考えてみましょう。いま設計エンジニアが一生懸命図面を描いているとします。一方で、エンジンブロックを組み立てる製造エンジニアは、治具の配置を決めるために必要な寸法を早く知りたいと思っています。製造エンジニアにとって、エンジンの内部的な部品であるベアリングアボアの寸法など、知る必要はありません。治具の配置設計に必要な情報さえ得られれば、すぐ仕事に取り掛かれるのです。ところがエンジン全体の設計を1つの大きなバッチサイズとして管理してしまうと、すべての設計情報が決定されるまで製造エンジニアは治具の設計に取り掛かれない。ここで発生する待ち時間がムダなのです。

―― これまでの話を聞くと、リーン製品開発とコンカレント開発は非常に近い考え方に思えますが、両者の違いは何ですか。

ライナーセン氏　コンカレント開発を実践しようと思ったら、設計のバッチサイズを小さくしなければ実現できません。ところがコンカレント開発では、工程をオーバーラップさせる部分を強調するばかりで、具体的な手法は示していません。コンカレント開発はリーン製品開発の基本的な要素ではありますが、どちらかというと哲学的なものです。とても良い考え方ではありますが、科学的ではないのです。

　つまり設計やレビュー、解析、試作などの工程間オーバーラップを可能にする適正なバッチサイズを教えてくれはしません。バッチサイズを変化させると、コストの変化はUカーブを描きます。つまりバッチサイズが大き過ぎたり、または小さ過ぎたりすると、コストは上昇してしまいます。こういった科学的な検証を取り入れているのがリーン製品開発です。

　一方、コンカレント開発では、効果やリスクなどを数量化して評価するのが困難です。例えば200枚の図面をレビューするとしましょう。コンカレント開発では、レビューをオーバーラップさせなさいというでしょう。リーン製品開発では、レビューをオーバーラップさせるために、バッチサイズを小さくしなさいといいます。適切なバッチサイズにすることで、作業コストと保有コストの正しいトレードオフが可能になります。リーン製品開発では、定期的な時間ベースのサイクルに基づいて、適切なバッチサイズを注意深く分析します。そして、正しいバッチサイズが20枚の図面だと解明されれば、例えば毎週水曜日の13時に過去1週間に完成した図面をすべてレビューするというルールを決め、正しいバッチサイズで工程管理できるようにするのです。

―― 現場のエンジニアはバッチサイズが小さくなると、チーム間の調整やレビューなどで会議が増え、修正の頻度が増えることを嫌うかもしれません。

ライナーセン氏　確かにエンジニアは嫌がるでしょう。しかし、先ほど例に出したエンジンブロック組み立てでは、最初に確定させたいのは設備設計に必要な寸法なのです。バッチサイズを小さな単位に分割して、設備設計に必要な部分だけを独立させておけば、ほかのバッチ工程で発生する設計変更による手戻りに影響を受けません。リーン製品開発が科学的な考え方だというのは、どの作業をどのバッチに振り分けたらいいのかという疑問に答えられるからです。

　例えば携帯電話の画面サイズは、設計のかなり初期段階で決定されます。しかし画面に表示させる文字のサイズは、かなり後ろのバッチ工程で決定されるでしょう。なぜなら、文字サイズは簡単に変更できるからです。ですから、科学的な根拠に基づいてバッチサイズを小さくすることは、設計変更による手戻りリスクからエンジニアを守ることになるのです。

　さらにITテクノロジーは、複数の人がリアルタイムに設計情報へアクセスすることを可能にします。その結果、会議のように大きな時間的コストを削減できます。エンジニアやマネージャは、バッチサイズを小さくすることで発生する多くの会議を嫌がるでしょうが、それはITシステムを活用したオンラインのレビューや意見交換などで削減できる部分です。

本稿で紹介したライナーセン氏のリーン製品開発に関する著作が2008年中に出版される予定だという。Reinertsen & AssociatesのWebページでは「連絡してくれたら、本が出版されたときにお知らせします（Contact me if you would like to be notified when the new book on Lean Product Development is available.）」とあるので、興味のある方はメールを送ってみてはいかがだろうか。

前のページへ 1|2 　　　　　　