tag:crieit.net,2005:https://crieit.net/tags/%E6%9C%AC/feed Crieitでタグ「本」に投稿された最近の記事 2020-11-04T00:31:27+09:00 https://crieit.net/tags/%E6%9C%AC/feed tag:crieit.net,2005:PublicArticle/16198 2020-11-04T00:31:27+09:00 2020-11-04T00:31:27+09:00 https://crieit.net/posts/reading-memo---knowledge-of-product-development <h1 id="TL; DR"><a href="#TL%3B+DR">TL; DR</a></h1> <p>アジャイルでやってこう！</p> <p>メモ書きの割にまとまってないけど、それだけ重要な点が多いってことで許してください。<br /> それくらいには、読んでためになる内容が多かった印象です。</p> <h1 id="はじめに"><a href="#%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB">はじめに</a></h1> <p>「製品開発の知識」という書籍（以降、本書と呼びます）の内容要約、および、自身の感想などを記します。</p> <p>本書は、2002年に発売の古い本ですが、2016年には第15版が登場しています。<br /> 今回は、その第15版を読みました（何が違うかは把握できてませんが、多分ここかなーという目星はついた程度です）。</p> <ul> <li><a target="_blank" rel="nofollow noopener" href="https://nikkeibook.nikkeibp.co.jp/item-detail/10862">製品開発の知識 | 日本経済新聞出版</a></li> <li><a target="_blank" rel="nofollow noopener" href="https://www.amazon.co.jp/製品開発の知識-日経文庫-延岡-健太郎/dp/4532108624">製品開発の知識 (日経文庫) | 延岡 健太郎 |本 | 通販 | Amazon</a></li> </ul> <p>本書の要約については、である調で記します。</p> <p>箇条書きについては、次のルールで記述しています。<br /> 簡単に書くと、項目自体についてを太字で、項目の説明を常体で、それぞれ書いていきます。</p> <ul> <li><strong>項目1</strong> <ul> <li><strong>項目1-1</strong> <ul> <li>項目1-1の説明</li> </ul></li> <li><strong>項目1-2</strong></li> </ul></li> <li><strong>項目2</strong> <ul> <li><strong>項目2-1</strong></li> <li><strong>項目2-2</strong> <ul> <li>項目2-2の説明a</li> <li>項目2-2の説明b</li> <li><strong>項目2-2-1</strong></li> <li><strong>項目2-2-2</strong> <ul> <li>項目2-2-2の説明</li> </ul></li> </ul></li> </ul></li> </ul> <h1 id="「製品開発の知識」"><a href="#%E3%80%8C%E8%A3%BD%E5%93%81%E9%96%8B%E7%99%BA%E3%81%AE%E7%9F%A5%E8%AD%98%E3%80%8D">「製品開発の知識」</a></h1> <p>製品開発の現場では、マニュアル的な知識よりも基礎知識の方が重要である。<br /> 本書はヒット商品そのものではなく、ヒット商品を生み出す企業体質についてを記述する。</p> <h2 id="製品価値の役割"><a href="#%E8%A3%BD%E5%93%81%E4%BE%A1%E5%80%A4%E3%81%AE%E5%BD%B9%E5%89%B2">製品価値の役割</a></h2> <p>製品価値の役割は、以下の2点。</p> <h3 id="付加価値創造"><a href="#%E4%BB%98%E5%8A%A0%E4%BE%A1%E5%80%A4%E5%89%B5%E9%80%A0">付加価値創造</a></h3> <p>付加価値の源泉は以下の3点。</p> <ul> <li><strong>顧客にとって高い価値の提供</strong></li> <li><strong>低コストでの提供</strong></li> <li><strong>競合企業に対する優位性の確保（希少価値の提供）</strong></li> </ul> <p>付加価値の高い製品開発により、次の対象に大きく貢献する。</p> <ul> <li><strong>従業員</strong> <ul> <li>給与を潤沢に支払えるため</li> </ul></li> <li><strong>社会</strong> <ul> <li>税金を多く納められるため</li> </ul></li> </ul> <h3 id="企業の将来の担保"><a href="#%E4%BC%81%E6%A5%AD%E3%81%AE%E5%B0%86%E6%9D%A5%E3%81%AE%E6%8B%85%E4%BF%9D">企業の将来の担保</a></h3> <p>以下のバランスが重要。</p> <ul> <li><strong>短期的な視点</strong> <ul> <li>利益および業績の追求</li> </ul></li> <li><strong>長期的な視点</strong> <ul> <li>将来的な競争力を左右する技術／製品開発力の蓄積</li> </ul></li> </ul> <h2 id="製品開発マネジメント"><a href="#%E8%A3%BD%E5%93%81%E9%96%8B%E7%99%BA%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88">製品開発マネジメント</a></h2> <p>マネジメントすべき対象は、以下の3点。</p> <h3 id="創造性"><a href="#%E5%89%B5%E9%80%A0%E6%80%A7">創造性</a></h3> <p>以下のバランスが重要。</p> <ul> <li><strong>細かい行動規程</strong></li> <li><strong>自由な発想</strong></li> </ul> <h3 id="複雑性"><a href="#%E8%A4%87%E9%9B%91%E6%80%A7">複雑性</a></h3> <p>複雑性を持つ対象は、以下の通り。</p> <ul> <li><strong>技術</strong></li> <li><strong>開発組織</strong> <ul> <li>社内の人間だけでなく、社外の人間も巻き込む必要がある</li> </ul></li> </ul> <h3 id="不確実性"><a href="#%E4%B8%8D%E7%A2%BA%E5%AE%9F%E6%80%A7">不確実性</a></h3> <p>不確実性を持つ対象は、以下の通り。</p> <ul> <li><strong>市場</strong> <ul> <li><strong>顧客が期待する価値</strong></li> <li><strong>ニーズに関する価値観</strong></li> <li><strong>製品の持つ価値の持続性</strong></li> </ul></li> <li><strong>技術</strong> <ul> <li><strong>技術対象</strong></li> <li><strong>最終的な総コスト</strong></li> </ul></li> </ul> <h2 id="製品開発と競争力"><a href="#%E8%A3%BD%E5%93%81%E9%96%8B%E7%99%BA%E3%81%A8%E7%AB%B6%E4%BA%89%E5%8A%9B">製品開発と競争力</a></h2> <p>差異化の源泉は、以下の通り。</p> <ul> <li><strong>製品</strong> <ul> <li><strong>特定機能</strong></li> <li><strong>勝負軸</strong></li> <li><strong>製品分野</strong></li> </ul></li> <li><strong>製品開発能力</strong> <ul> <li><strong>技術力</strong> <ul> <li>特に、核となる技術を1点に絞る「コア技術戦略」が重要</li> </ul></li> <li><strong>組織プロセス能力</strong> <ul> <li>競合企業よりも短期間／低工数／高品質を実現できる組織力のこと</li> </ul></li> <li><strong>価値創造能力</strong> <ul> <li><strong>製品／市場戦略に関する能力</strong> <ul> <li>顧客ニーズ（特に潜在的なニーズ）に合致した製品を開発する能力のこと</li> </ul></li> <li><strong>独自のビジネス・システムを構築／活用する能力</strong> <ul> <li>複数の企業を巻込んで、1つの製品の開発準備から販売網までのフローを「ビジネス・システム」と呼ぶ</li> <li>そのビジネス・システムをうまく活用することで、独自の販売網構築から業界標準策定までを可能にする</li> </ul></li> </ul></li> </ul></li> </ul> <h2 id="イノベーションのタイプ"><a href="#%E3%82%A4%E3%83%8E%E3%83%99%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E3%82%BF%E3%82%A4%E3%83%97">イノベーションのタイプ</a></h2> <p>イノベーション対象という視点でのタイプは、以下の通り。</p> <ul> <li><strong>市場的革新</strong> <ul> <li>既存技術の組合せが新しいもの</li> </ul></li> <li><strong>技術的革新</strong> <ul> <li><strong>製造技術</strong> <ul> <li>品質や生産効率の向上など</li> </ul></li> <li><strong>製品技術</strong> <ul> <li><strong>アーキテクチャ</strong> <ul> <li>製品要素の組合せなど</li> </ul></li> <li><strong>要素技術</strong> <ul> <li>製品要素そのものの機能向上など</li> </ul></li> </ul></li> </ul></li> </ul> <p>この枠組みを利用する利点は、次の2点。</p> <ul> <li><strong>イノベーションのタイプに応じて戦略が変化し、戦略に応じてPMやメンバーが変化する</strong></li> <li><strong>企業内での製品開発PJの組合せを考えられる</strong> <ul> <li>企業内で、全て一方の革新性を取るような製品開発だけを実施しない</li> </ul></li> </ul> <h2 id="イノベーションの判定"><a href="#%E3%82%A4%E3%83%8E%E3%83%99%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E5%88%A4%E5%AE%9A">イノベーションの判定</a></h2> <p>イノベーションの判定は、以下の2点。</p> <h3 id="イノベーションの基準点"><a href="#%E3%82%A4%E3%83%8E%E3%83%99%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E5%9F%BA%E6%BA%96%E7%82%B9">イノベーションの基準点</a></h3> <p>基準点としては、以下の2点。</p> <ul> <li><strong>市場に存在しなかった技術</strong></li> <li><strong>特定企業が利用できなかった技術</strong> <ul> <li>既にある技術を、他産業の企業が利用できた場合は、イノベーションになりうる</li> </ul></li> </ul> <h3 id="イノベーションの変化量"><a href="#%E3%82%A4%E3%83%8E%E3%83%99%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E5%A4%89%E5%8C%96%E9%87%8F">イノベーションの変化量</a></h3> <p>変化量としては、以下の2点。</p> <ul> <li><strong>機能やコストの変化量の大小</strong></li> <li><strong>特定企業の保持する既存技術のベクトルの方向性の差異</strong> <ul> <li>特定企業が保持している既存技術の応用として対応できない技術を利用できた場合は、イノベーションになりうる</li> <li>既存技術の存在が、新技術の足枷になることもある可能性に注意</li> </ul></li> </ul> <h2 id="イノベーションのパターン"><a href="#%E3%82%A4%E3%83%8E%E3%83%99%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3">イノベーションのパターン</a></h2> <p>イノベーションを起こすためには、以下の2つの戦略に分けられる。</p> <h3 id="改善重視型戦略"><a href="#%E6%94%B9%E5%96%84%E9%87%8D%E8%A6%96%E5%9E%8B%E6%88%A6%E7%95%A5">改善重視型戦略</a></h3> <p>既存機能の改善を重視する戦略。</p> <ul> <li><strong>市場で売れる製品のライフサイクルが短い場合</strong> <ul> <li>機能的には比較的小さな差異でも、新製品を次々に投入することが重要である場合</li> </ul></li> <li><strong>市場／顧客ニーズがわかりにくく、かつ、製品コンセプトが重要な場合</strong> <ul> <li>売上げの予測が立てにくい場合は、改善内容を変えて次々に開発した方が良い</li> <li>必要以上の高頻度な新製品の開発は、投資が過度に増え、在庫管理が大変になることに注意</li> </ul></li> <li><strong>フォロワー戦略を取る場合</strong> <ul> <li>リーダー戦略企業が新市場の開拓や新技術の導入に成功したことを確認した後で、迅速に同様の製品を開発する戦略</li> </ul></li> </ul> <h3 id="革新重視型戦略"><a href="#%E9%9D%A9%E6%96%B0%E9%87%8D%E8%A6%96%E5%9E%8B%E6%88%A6%E7%95%A5">革新重視型戦略</a></h3> <p>既存機能に囚われずイノベーションを重視する戦略。<br /> 基本的には、改善重視型戦略の逆を取る。</p> <ul> <li><strong>市場で売れる製品のライフサイクルが長い場合</strong></li> <li><strong>市場／顧客ニーズがわかりやすい場合</strong></li> <li><strong>技術の優位性を製品のアピールポイントにできる場合</strong></li> <li><strong>技術的に大きな優位性を維持できる場合</strong></li> <li><strong>リーダー戦略を取る場合</strong> <ul> <li>誰よりも早く革新的な製品を開発する戦略</li> </ul></li> </ul> <p>なお、リーダー戦略およびフォロワー戦略は、どちらが良いというわけで無く、それぞれに一長一短が存在する。</p> <h2 id="イノベーションのジレンマ"><a href="#%E3%82%A4%E3%83%8E%E3%83%99%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E3%82%B8%E3%83%AC%E3%83%B3%E3%83%9E">イノベーションのジレンマ</a></h2> <p>イノベーションを生み出すために乗り越えるべきジレンマとして、以下の3つが存在する。</p> <ul> <li><strong>研究開発と製品開発のジレンマ</strong> <ul> <li>初期段階では研究内容の技術や方向性が定まっておらず、投資の多くが無駄になりやすい</li> <li>初期段階では大量生産ができず、量産効果が得られない</li> <li>累積生産量が少なく、学習効果を享受できない</li> </ul></li> <li><strong>技術革新のジレンマ</strong> <ul> <li>革新技術のコストは既存技術のコストより高い</li> <li>既存顧客に革新技術は対応できない場合がある</li> <li>初期段階では革新技術が本当に既存技術より優れていることを判別できない</li> </ul></li> <li><strong>組織のジレンマ</strong> <ul> <li>事業部門の視点と研究開発部門の視点が異なる <ul> <li>事業部門は、比較的短期的な視点から、既存技術より全ての面で優れた新技術の提供を期待する</li> <li>研究開発部門は、長期的な視点から、既存技術より優れた技術を提供できる可能性を提供する</li> </ul></li> </ul></li> </ul> <p>重要な点は、新旧技術の利点欠点を理解しつつ、どちらかを適切なタイミングで意思決定するリーダーの存在である。<br /> 革新的技術の投資は、タイミングを見計って遅すぎない段階に実施する必要がある。<br /> または、競合企業が革新的技術に投資している中、自企業だけ既存技術で優位性を高める戦略もある。</p> <p>なお、日本企業では、イノベーションの多く（特に、破壊的イノベーションの多く）が大企業から生み出されている。<br /> これは、次の2点を象徴している。</p> <ul> <li>日本の大企業における柔軟性に富んだ開発組織能力に裏づけされた強さ</li> <li>大企業を脅かすベンチャー企業の弱さ</li> </ul> <h2 id="製品戦略"><a href="#%E8%A3%BD%E5%93%81%E6%88%A6%E7%95%A5">製品戦略</a></h2> <p>製造業にとって製品戦略は、企業戦略の下位概念ではなく、経営戦略とオーバーラップして考えるべき重要なものである。</p> <h3 id="製品戦略の役割"><a href="#%E8%A3%BD%E5%93%81%E6%88%A6%E7%95%A5%E3%81%AE%E5%BD%B9%E5%89%B2">製品戦略の役割</a></h3> <p>外部環境との関係として重要なステークホルダーは、次の3つである。<br /> 自社を含めて、通称 4C と呼ぶ。</p> <ul> <li><strong>顧客</strong></li> <li><strong>競合企業</strong></li> <li><strong>協力／補完企業</strong></li> </ul> <h3 id="製品戦略の分野"><a href="#%E8%A3%BD%E5%93%81%E6%88%A6%E7%95%A5%E3%81%AE%E5%88%86%E9%87%8E">製品戦略の分野</a></h3> <p>製品戦略の分野は、次の3つに大別できる。</p> <h4 id="製品技術戦略"><a href="#%E8%A3%BD%E5%93%81%E6%8A%80%E8%A1%93%E6%88%A6%E7%95%A5">製品技術戦略</a></h4> <p>短期的な視点。</p> <p>マーケットイン戦略（市場の要求から製品を開発する戦略）より、プロダクトアウト戦略（存在しない市場を生み出す製品を開発する戦略）の方が、最終的に取得できるパイは大きい。</p> <h4 id="製品市場戦略"><a href="#%E8%A3%BD%E5%93%81%E5%B8%82%E5%A0%B4%E6%88%A6%E7%95%A5">製品市場戦略</a></h4> <p>短期的な視点。</p> <ul> <li>選択と集中を徹底し、限られた数の新製品でヒットを狙う戦略</li> <li>多数の新製品を、なるべく小さい投資と低い開発／製造コストで開発する戦略 <ul> <li><strong>マスカスタマイゼーション戦略</strong> <ul> <li>低コスト戦略（標準化した製品として量産効果を享受する戦略）と高付加価値戦略（顧客の要望に全て答えて付加価値を高める戦略）のいいとこ取り</li> <li><strong>部品共通化戦略</strong> <ul> <li>疎結合化することで共通部品を作成し、コストを抑える戦略</li> <li>経営資源や技術や部品までも共通化できることはすると良い</li> </ul></li> <li><strong>高付加価値汎用化戦略</strong> <ul> <li>従業員の半数以上を営業として顧客配属させることで、膨大な顧客情報から共通化できそうな要求を見つけることが可能（キーエンス社の場合）</li> </ul></li> </ul></li> </ul></li> </ul> <h4 id="製品展開戦略"><a href="#%E8%A3%BD%E5%93%81%E5%B1%95%E9%96%8B%E6%88%A6%E7%95%A5">製品展開戦略</a></h4> <p>長期的な視点。</p> <ul> <li><strong>製品ドメイン戦略</strong> <ul> <li>既存技術による市場範囲の拡大、または、既存市場に対する技術範囲の拡大の、どちらかの戦略が存在する</li> <li>既存の製品ドメインから大きく離れすぎた多角化は、成功の確率が低いことが研究で証明済み</li> <li><strong>製品展開マップ</strong> <ul> <li>製品の技術プラットフォーム／製品プラットフォーム／製品ラインの関係を可視化できるフレームワーク</li> <li><strong>技術プラットフォーム</strong> <ul> <li>コア技術と呼ばれるようなもの</li> </ul></li> <li><strong>製品プラットフォーム</strong> <ul> <li>アーキテクチャ（組合せ）</li> </ul></li> </ul></li> </ul></li> </ul> <h2 id="製品開発プロセス"><a href="#%E8%A3%BD%E5%93%81%E9%96%8B%E7%99%BA%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9">製品開発プロセス</a></h2> <p>最初から完璧な設計開発を実現するという発想でプロセスを考えるべきでは無い。</p> <h3 id="製品開発の業務"><a href="#%E8%A3%BD%E5%93%81%E9%96%8B%E7%99%BA%E3%81%AE%E6%A5%AD%E5%8B%99">製品開発の業務</a></h3> <p>製品開発の業務は、以下の5つに大別できる。</p> <h4 id="製品企画"><a href="#%E8%A3%BD%E5%93%81%E4%BC%81%E7%94%BB">製品企画</a></h4> <p>製品コンセプト、技術計画、収益性計画を検討する。<br /> 製品開発終了まで常に参照し、実際とのギャップを埋める必要がある。</p> <p>収益性計画は、原価企画という手法で定めると良い。<br /> 原価企画とは、顧客価値の視点から見た販売価格から、経営戦略上必要とされる利益目標を差し引いた金額（目標コスト）を、製品企画の段階で設定する手法のこと。<br /> 逆に、コストの積上げ式で最終的な販売価格を決めるのは悪手となる（市場での競争力が失われてしまうため）。</p> <h4 id="設計開発と試験／テスト／解析"><a href="#%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BA%E3%81%A8%E8%A9%A6%E9%A8%93%EF%BC%8F%E3%83%86%E3%82%B9%E3%83%88%EF%BC%8F%E8%A7%A3%E6%9E%90">設計開発と試験／テスト／解析</a></h4> <p>設計者が設計案を創出する必要がある。<br /> その設計案が実際に目標や製品コンセプトにあっているかを検証する。<br /> この「設計案の創出」と「検証」を繰返すことで、設計は具体化する。</p> <h4 id="要素技術開発"><a href="#%E8%A6%81%E7%B4%A0%E6%8A%80%E8%A1%93%E9%96%8B%E7%99%BA">要素技術開発</a></h4> <p>キーとなる要素技術の開発は、他の要素技術に先駆けて進める必要がある。</p> <h4 id="生産準備"><a href="#%E7%94%9F%E7%94%A3%E6%BA%96%E5%82%99">生産準備</a></h4> <p>製品設計開始前に、生産条件を製品技術者に提示する。<br /> これにより、生産しやすい製品設計が可能となる。</p> <h4 id="開発管理"><a href="#%E9%96%8B%E7%99%BA%E7%AE%A1%E7%90%86">開発管理</a></h4> <p>原価企画によるコスト管理が良い。</p> <h2 id="製品開発の複雑性"><a href="#%E8%A3%BD%E5%93%81%E9%96%8B%E7%99%BA%E3%81%AE%E8%A4%87%E9%9B%91%E6%80%A7">製品開発の複雑性</a></h2> <p>製品開発の複雑性の要素は、次のように分けられる。<br /> イノベーションのタイプと部分的に似ている。</p> <ul> <li><strong>市場／顧客ニーズの複雑性</strong> <ul> <li>顧客ニーズがネットワークの外部性（顧客数によって価値が変わるようなもの）や流行によって変化する場合</li> <li>顧客ニーズが暗黙的で捉えにくい曖昧な性質を持っている場合</li> <li>製品開発によっては、初期から顧客の潜在ニーズを取込む必要がある</li> </ul></li> <li><strong>製品技術の複雑性</strong> <ul> <li><strong>要素技術の複雑性</strong> <ul> <li>技術の新しさ</li> <li>技術開発の内容と機能との因果関係</li> </ul></li> <li><strong>製品アーキテクチャの複雑性</strong> <ul> <li><strong>部品間関係の複雑性</strong> <ul> <li>インターフェイスのモジュール化／標準化の有無</li> <li>インターフェイスの高精度性や緻密性の必要性</li> </ul></li> <li><strong>部品点数の多さ</strong></li> </ul></li> </ul></li> </ul> <h2 id="組織マネジメント"><a href="#%E7%B5%84%E7%B9%94%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88">組織マネジメント</a></h2> <p>組織体勢の種類は、以下の通り。</p> <ul> <li><strong>機能重視組織</strong> <ul> <li>専門家を束ねる組織</li> <li>有効的な場面 <ul> <li>特定分野の新技術開発</li> <li>長期プロジェクトに配属する技術者の技術獲得</li> <li>各機能部門の相互依存性が低い場合</li> </ul></li> </ul></li> <li><strong>プロジェクト重視組織</strong> <ul> <li>プロジェクトメンバーを束ねる組織</li> <li>プロジェクトを重視せずに組織を重視している場合は成功しない <ul> <li>組織間に壁があってはならないように、プロジェクトに貢献することで自部門にも利益があることを事業部長や研究所長に理解させる仕組みが必要</li> </ul></li> <li>有効的な場面 <ul> <li>機能横断的にプロジェクトを成功させたい場合</li> <li>短期プロジェクト</li> <li>各機能部門の業務間の相互依存性が高い場合</li> </ul></li> </ul></li> <li><strong>ハイブリッド型組織</strong> <ul> <li>両方のいいとこ取り組織</li> <li>確立方法 <ul> <li>開発メンバーの役割に応じて、機能重視組織とプロジェクト重視組織に分けつつ、両方をミックスする</li> <li>製品開発プロセスのある時点で、機能重視組織からプロジェクト重視組織に変更する</li> </ul></li> </ul></li> </ul> <p>PM の権限については、以下の通り。</p> <ul> <li>プロジェクトの牽引、および、組織としての効率的なプロジェクトの推進のためには、企業のトップが PM を全面的にサポートする必要がある</li> <li>プロジェクトを重視する場合は、 PM もそれに応じて権限を強くする必要がある</li> </ul> <h2 id="製品開発プロセスのマネジメント"><a href="#%E8%A3%BD%E5%93%81%E9%96%8B%E7%99%BA%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E3%81%AE%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88">製品開発プロセスのマネジメント</a></h2> <p>製品開発プロセスのマネジメントをする際に重要となる用語として2点、また、コンカレント・エンジニアリングを機能させるために必要な活動について1点、それぞれ挙げる。</p> <h3 id="コンカレント・エンジニアリング"><a href="#%E3%82%B3%E3%83%B3%E3%82%AB%E3%83%AC%E3%83%B3%E3%83%88%E3%83%BB%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0">コンカレント・エンジニアリング</a></h3> <p>製品開発業務の各工程を、並行して実施する開発手法のこと。<br /> 特に設計と生産技術の間における並行化が、製品開発プロ性巣の成否に影響が大きい。</p> <h3 id="フロントローディング"><a href="#%E3%83%95%E3%83%AD%E3%83%B3%E3%83%88%E3%83%AD%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0">フロントローディング</a></h3> <p>問題解決の前倒し、つまり、後工程で起こりうる問題を、なるべく早期に顕在化させること。<br /> これにより、プロジェクトにおける開発期間短縮、および、工数削減が実現できる。</p> <h3 id="コンカレント・エンジニアリングを機能させるために必要な活動"><a href="#%E3%82%B3%E3%83%B3%E3%82%AB%E3%83%AC%E3%83%B3%E3%83%88%E3%83%BB%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0%E3%82%92%E6%A9%9F%E8%83%BD%E3%81%95%E3%81%9B%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AB%E5%BF%85%E8%A6%81%E3%81%AA%E6%B4%BB%E5%8B%95">コンカレント・エンジニアリングを機能させるために必要な活動</a></h3> <p>実際に製品開発プロセスを効率的に促進するためには、関連機能間のコミュニケーションと情報交換が重要である。</p> <h4 id="「生産しやすい設計」ノウハウの蓄積と共有"><a href="#%E3%80%8C%E7%94%9F%E7%94%A3%E3%81%97%E3%82%84%E3%81%99%E3%81%84%E8%A8%AD%E8%A8%88%E3%80%8D%E3%83%8E%E3%82%A6%E3%83%8F%E3%82%A6%E3%81%AE%E8%93%84%E7%A9%8D%E3%81%A8%E5%85%B1%E6%9C%89">「生産しやすい設計」ノウハウの蓄積と共有</a></h4> <p>設計開始前に、生産技術から設計へ、生産要件に関する情報を十分にインプットすることが大切である。<br /> つまり、設計時に守るべきポイントを提示することで、設計に生産技術の要素を組込むことが重要である。</p> <p>この時、失敗事例をデータベース化しておくと良い。</p> <p>ただし、ルールを厳しくしすぎると創造的な設計活動に悪影響をもたらすため、定期的な見直しが必要である。</p> <h4 id="効果的な情報移転の方法"><a href="#%E5%8A%B9%E6%9E%9C%E7%9A%84%E3%81%AA%E6%83%85%E5%A0%B1%E7%A7%BB%E8%BB%A2%E3%81%AE%E6%96%B9%E6%B3%95">効果的な情報移転の方法</a></h4> <p>設計の途中過程であっても、情報を生産技術部門に逐一報告するとよい。<br /> ただし、生産準備が全て無駄になっては意味がないため、未完成であっても有意義な情報である必要がある。</p> <p>チームとして一体感がなければ、責任問題を問われる可能性を恐れて、前段側は情報を出せない。<br /> 共同で問題解決に取組む姿勢が必要となる。</p> <h2 id="企業間関係のマネジメント"><a href="#%E4%BC%81%E6%A5%AD%E9%96%93%E9%96%A2%E4%BF%82%E3%81%AE%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88">企業間関係のマネジメント</a></h2> <p>製品開発には複数企業が関わることが一般的になっている。</p> <h3 id="企業間関係のタイプ"><a href="#%E4%BC%81%E6%A5%AD%E9%96%93%E9%96%A2%E4%BF%82%E3%81%AE%E3%82%BF%E3%82%A4%E3%83%97">企業間関係のタイプ</a></h3> <p>企業間関係のタイプには、次の2種類が存在する。</p> <ul> <li><strong>垂直的関係</strong> <ul> <li>製品の上流／下流工程という関係</li> <li>分業化が進んでいる <ul> <li>製造業の組立て受注を専門とする EMS (Electronics Manufacturing Services)</li> <li>半導体設計のみを請負う「ファブレス」</li> <li>半導体生産のみを請負う「ファウンダリ」</li> </ul></li> </ul></li> <li><strong>水平的関係</strong> <ul> <li>競争企業間関係 <ul> <li>製品や技術の共同開発</li> <li>技術供与（ライセンシング）</li> <li>ジョイントベンチャー（合併）</li> <li>競合企業から製品を供給してもらい、自社のブランっで販売する OEM (Original Equipment Manufacturer)</li> </ul></li> <li>重要な課題 <ul> <li>自社の請負範囲</li> <li>自社の企業ネットワーク内での立ち位置</li> <li>他社との関係性の濃淡</li> </ul></li> </ul></li> </ul> <h3 id="外部調達の決定基準"><a href="#%E5%A4%96%E9%83%A8%E8%AA%BF%E9%81%94%E3%81%AE%E6%B1%BA%E5%AE%9A%E5%9F%BA%E6%BA%96">外部調達の決定基準</a></h3> <p>内部で開発／製造する部品を選択する際の観点として、以下の3点を挙げる。</p> <ul> <li><strong>部品の付加価値</strong> <ul> <li>設計／生産することが高い付加価値になるか</li> <li>次の場合は、自社内で実施すべき <ul> <li>顧客への価値が高い</li> <li>企業の強みを反映したコア技術</li> <li>技術の発展性／応用性が高い</li> </ul></li> </ul></li> <li><strong>部品の供給企業</strong> <ul> <li>ある部品を供給する優れた企業が複数あるか</li> <li>次の場合は、自社内で実施すべき <ul> <li>優秀な部品企業の数が少ない</li> </ul></li> </ul></li> <li><strong>部品の設計特性</strong> <ul> <li>その部品が他の部品とどれくらい相互依存性を持つか</li> <li>次の場合は、自社内で実施すべき <ul> <li>他の部品との相互依存性が高い</li> <li>標準化されていない</li> </ul></li> </ul></li> </ul> <h3 id="企業ネットワークの構築"><a href="#%E4%BC%81%E6%A5%AD%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%81%AE%E6%A7%8B%E7%AF%89">企業ネットワークの構築</a></h3> <p>企業ネットワークを構築することで、部品調達が優位になる場合がある。<br /> 取引企業の数によって、それぞれ以下のような優位点がある。</p> <ul> <li><strong>多数企業から調達する優位点</strong> <ul> <li>特定の調達企業への依存度が低下し、取引交渉力が有利になる</li> <li>部品調達の上で柔軟性が増し、より最適な部品を購入できる可能性が上がる</li> <li>1社に依存することにリスクを減らせる</li> </ul></li> <li><strong>少数企業から調達することの優位点</strong> <ul> <li>規模の経済性を期待でき、大量購入によるコスト削減が見込める</li> <li>調整や取引の業務コストを削減できる</li> </ul></li> </ul> <p>基本的に、取引企業は多すぎても少なすぎても良くない。<br /> 基本的には、2〜3社と取引することが最適だと（本書では）考えられている。</p> <h3 id="デザイン・イン"><a href="#%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%BB%E3%82%A4%E3%83%B3">デザイン・イン</a></h3> <p>コンカレント・エンジニアリングの組織プロセスに、部品企業を組込む（製品開発プロジェクトに、部品企業を早期から参加させる）こと。<br /> これにより、手戻り削減が期待できる。</p> <p>デザイン・インを実施するためには、以下の条件が必須である。</p> <ul> <li>部品設計が全く決まっていない初期段階から、部品企業を選択する必要がある</li> <li>部品企業の開発能力が高い必要がある <ul> <li>言われた通りに作るだけではダメ</li> </ul></li> <li>自社とその部品企業が相互に信頼している必要がある <ul> <li>部品企業が競合企業に情報を漏洩されては困る</li> <li>自社が部品企業の部品設計データを粗悪に扱ってはならない</li> </ul></li> <li>綿密なコミュニケーショが実施できるインフラが必要である</li> </ul> <p>かつての欧米企業では、調達供給関係である企業は疑心暗鬼の関係であった。<br /> そのため、デザイン・インの考え方は、欧米企業では一般的ではなかったが、近年では取入れている企業が増えている。</p> <h2 id="持続的な製品開発能力の構築"><a href="#%E6%8C%81%E7%B6%9A%E7%9A%84%E3%81%AA%E8%A3%BD%E5%93%81%E9%96%8B%E7%99%BA%E8%83%BD%E5%8A%9B%E3%81%AE%E6%A7%8B%E7%AF%89">持続的な製品開発能力の構築</a></h2> <p>優れた製品開発能力とは、自由と規律、コストと付加価値、繊毛性と統合性、といった、矛盾する目標を高次元で統合的に解決する仕組みによって成立つ。</p> <h3 id="相反する要素"><a href="#%E7%9B%B8%E5%8F%8D%E3%81%99%E3%82%8B%E8%A6%81%E7%B4%A0">相反する要素</a></h3> <p>相反する要素の組合せ、および、解決策は、以下の通り。</p> <ul> <li><strong>自由と規律</strong> <ul> <li>これらの関係は、本質的に相反するものではなく、むしろ補完的なものとして考えることが大事である</li> <li><strong>自由</strong> <ul> <li>技術開発が失敗しても責められない環境</li> <li>上司は技術者が提案した新しいアイデアを決して潰してはならないと言う文化</li> </ul></li> <li><strong>規律</strong> <ul> <li>そもそも開発してよい内容に制限がかかっている</li> </ul></li> </ul></li> <li><strong>コストと付加価値</strong> <ul> <li><strong>コスト</strong> <ul> <li>共通化によるコスト削減</li> <li>優れたサプライチェーンによる他社との関係の良好化</li> </ul></li> <li><strong>付加価値</strong> <ul> <li>受注生産によるカスタマイズ</li> </ul></li> </ul></li> <li><strong>専門性と統合</strong> <ul> <li>部門横断プロジェクトの効果的な活用によって、専門技術部門とプロジェクトを組合せることができる</li> <li>部門横断プロジェクトによる製品開発の成功体験の積重ねが大切である</li> </ul></li> <li><strong>オープン化と信頼構築</strong> <ul> <li>この2つのトレードオフの打破が求められている。 <ul> <li>グローバルな視点から最適なパートナーを、戦略的に取捨選択する</li> <li>緊密な信頼関係によるデザイン・インを、効果的に実行する</li> </ul></li> </ul></li> </ul> <h3 id="企業例"><a href="#%E4%BC%81%E6%A5%AD%E4%BE%8B">企業例</a></h3> <p>二律背反を高度な視点から解決できた企業の例を、以下に示す。</p> <ul> <li>シャープ <ul> <li>重要な技術開発や新製品開発の組織横断プロジェクト化「緊プロ」 <ul> <li>25年に渡るプロジェクト組織の広範囲化による部門間の壁の破壊</li> </ul></li> </ul></li> <li>トヨタ自動車 <ul> <li>競合他社への部品供給の推奨、および、系列に拘らない最新技術の共同研究先企業の選定 <ul> <li>系列企業との緊密な信頼関係によるグループ企業間での相互学習を促進する仕組みの構築</li> <li>製品開発における広範なネットワークの構築</li> </ul></li> </ul></li> <li>シスコ・システムズ <ul> <li>多くのベンチャー企業の買収 <ul> <li>ベンチャー企業の活力や革新技術</li> <li>大企業の開発組織や顧客開拓力</li> </ul></li> </ul></li> </ul> <h3 id="今後特に注目される視点"><a href="#%E4%BB%8A%E5%BE%8C%E7%89%B9%E3%81%AB%E6%B3%A8%E7%9B%AE%E3%81%95%E3%82%8C%E3%82%8B%E8%A6%96%E7%82%B9">今後特に注目される視点</a></h3> <p>本書が、2002年当時（から2016年までの間）に注目している視点は、以下の通り。</p> <ul> <li>企業外部の技術力の獲得</li> <li>情報技術による製品開発の仕組みの根本的な改革</li> </ul> <h1 id="おわりに"><a href="#%E3%81%8A%E3%82%8F%E3%82%8A%E3%81%AB">おわりに</a></h1> <p>全体的に、ソフトウェア開発ではアジャイルに相当することを、ハードウェアでも実施することが望ましいということが言われていました。<br /> が、これは新製品開発での話である、という前提を考慮すれば、そうでない場合（いわゆる保守／運用）ではどうすべきか、については書いてないと言えますね。</p> <p>製品開発を会社として本気で取組むためには、会社の文化から変えていかないといけないみたいです。<br /> そこまでちゃんと取組めている会社がどれだけあるのか......？という疑問は残りますが、企業選択の時点では考えるべき観点の1つかもしれません（就職／転職しかり、株式購入しかり）。</p> <p>また、保守運用チームと新製品開発チームを併用している会社の場合（今の多くの企業はそういう感じな気がしますが）、どのように両立させると良いか、気になりました。<br /> 保守運用チームと新製品開発チームの両方が Win-Win になるためには、「ハイブリット型組織」が生かせるような、そうでもないような......</p> <p>それと、営業チームと開発チームとの関係について、ほとんど書いてなかった点が気になりました。<br /> そこが知りたいところでもあるのですが、製品開発に営業はいらないってことなのでしょうか？<br /> いや、そんなことはないはず......</p> <p>後、本書でチラッと書いてましたが、デファクト・スタンダードの対義語はデジューリ・スタンダードというらしいです。</p> Morichan