図1-5: 死の谷
出典: NIST（米商務省標準技術院）発表資料
企業によってはこのような状況に危機を感じ，革新活動に転じているケースも聞く。
松下電器(現パナソニック)では従来の事業部制を廃止し，カンパニー制15を取り入れ，
かつ各事業部のLSI設計者の一部を集約し，各製品で共通で使用できるLSIを開発し，
それを使い回すことで，共通部の開発効率化，LSI の共通化によるコストダウンを図
った（図1-6:松下電器におけるデジタル家電統合プラットフォーム UniPhier16）。
auの携帯電話開発，自動車開発においてもプラットフォーム概念を取り入れ，開発 効率化とコストダウン，多機種展開に対応する体制を構築している。このような共通
15カンパニー制という言葉は，もともとはソニーが事業部制を改革する際に用いた造語といわれ る。カンパニー制は，事業部制を進展・補正させたものであるが，最大の違いは，バランスシー ト経営の導入にある。従来の事業部制では，予算と損益の管理はしっかりと行われていたが，事 業採算の重大な要素である資本と資産の使用コストについてはあまり考慮にいれられてこなかっ た。ソニーでは，資産を各カンパニーに割り振ると同時に，各カンパニーの資本金を設定，それ 以外の必要資金は本社からの借入れとみなす仕組みとした（配当目標も定める）。つまり，１つ の会社として独立採算度を高め，それぞれの投資収益性をよりシビアに評価して，次代の経営者 育成に役立てようというのがカンパニー制の狙いである。
16 松下電器はデジタル家電に何より重要である顧客が期待する商品を効率よく開発し，タイム リーに提供するために，商品群を横断する統合プラットフォーム（共通基盤）を導入し，ソフト ウェアとハードウェアの共用と再利用化によって，開発効率かと設計品質を飛躍的に向上するこ とを狙った。この統合プラットフォームはUniversal Platform for High-quality
部分の開発を集中化することで，各カンパニーは価値業務に集中できる。しかし，こ のような活動に積極的に取り組んでいる企業はまだまだ少ないのではないか。
松下電器の未来形 くらし×技術力，日経BP社(2005)
個別から全体最適による連携で新たな付加価値を創造
・大規模化、機能融合化による開発の爆発を解消するプラットフォーム
・商品群横断で、ソフト／ハード資産を活用し、開発効率と設計品質を向上
個別ＰＦ 携帯電話
個別ＰＦ ﾊﾟｰｿﾅﾙAV
個別ＰＦ カーAV
個別ＰＦ ホームAV
個別ＰＦ ﾎｰﾑｾｰﾌﾃｨ
携帯電話 ﾊﾟｰｿﾅﾙAV カーAV ホームAV ﾎｰﾑｾｰﾌﾃｨ
統合プラットフォーム UniPhier
Universal Platform for High-quality Image-Enhancing Revolution
図1-6: 松下電器のデジタル家電統合プラットフォーム UniPhier
出典: 日経BP社(2005)
開発期間短縮を実現するために，コンカレント・エンジニアリングが提唱されてき た。詳細の説明については先行研究・文献レビューに譲る。
これまで，各社でも様々なコンカレント・エンジニアリングの取り組みを実施され てきている。
コンカレント・エンジニアリングでは開発工程を並行化するため，並行化以前と比 べ，
・仕様確定前の開発スタート
・全開発終了以前の評価スタート
Image-Enhancing Revolutionの略をとり，Uniphier（ユニフィエ）と名付けられた。
が余儀なくされる。これはコンカレント・エンジニアリングを意識せずとも，日常的 に開発現場で見られる状況である。
最近の開発期間短縮要請をふまえると，これらは避けられないが，このような状況 を受け入れた上での開発計画・工程立案が必要であり，このような場面に対応できる マネジメントスキルを持ったメンバーが必要になることはいうまでもない。
プ ロ ジ ェ ク ト ・ マ ネ ジ メ ン ト/PMBOK(A Guide of Project Management Body of Knowledge)的には開発計画，リスク・マネジメントができるメンバーをアサインでき ればよいが，そのようなスキルアップ教育が過去から実施されているかというと，OJT にまかされており，かつ人依存が強い状況といえる。
1.1.4 まとめ
・ デジタル化，モジュール化を起点とした開発期間短縮と顧客ニーズの多様化
・ システム，開発対象の大規模化，複雑化
・ 競争の源泉がスピード，コストへシフト
が加速していることはいうまでもない。そこでこのような環境動向に積極的に立ち 向かう必要があるにも関わらず，様々な環境動向や失われた 10 年による投資がか けられないという理由から
・ 先行開発への工数投入ができない
・ 分業化の加速
・ 技術者への教育不足
・ 開発費を抑えるために技術者の人員を抑える，外注化の加速
・ 技術者の慢性的多忙
・ 開発期間短縮を実現するための強引な試作回数削減
・ グローバル対応商品を求められているにも関わらず，顧客研究をする時間が 取れない
という状況となり，結果的に
プロジェクトマネジメント 4章プロジェクト統合マ ネジメント5章プロジェクト・ スコープマネジメント6章プロジェクト・タイム マネジメント7章プロジェクト・コスト マネジメント8章プロジェクト品質 マネジメント 9章プロジェクト人的 資源マネジメント10章ﾌﾟﾛｼﾞｪｸﾄ･ｺﾐｭﾆ ｹｰｼｮﾝﾏﾈｼﾞﾒﾝﾄ11章プロジェクト・ リスクマネジメント12章プロジェクト調達 マネジメント
4.1 プロジェクト憲章作成 4.2 プロジェクトスコープ記 述書暫定版作成 4.3 プロジェクトマネジメント 計画書作成 4.4 プロジェクト実行の指 揮・マネジメント 4.5 プロジェクト作業の監視 コントロール 4.6 統合変更管理 4.7 プロジェクト終結 12.1 購入・取得計画 12.2 契約計画 12.3 納入者回答依頼 12.4 納入者選定 12.5 契約管理 12.6 契約終結
6.1 アクティビティ定義 6.2 アクティビティ順序設定 6.3 アクティビティ資源見積 り 6.4 アクティビティ所要期間 見積 6.5 スケジュール作成 6.6 スケジュール・コントロー ル 7.1 コスト見積り 7.2 コスの予算化 7.3 コスト・コントロール
8.1 品質計画 8.2 品質保証 8.3 品質管理 9.1 人的資源計画 9.2 プロジェクト・チーム編成 9.3 プロジェクト・チーム育成 9.4 プロジェクト・チームのマ ネジメント
10.1 コミュニケーション計画 10.2 情報配布 10.3 実績報告 10.4 ステークホルダー・マネ ジメント 11.1 リスクマネジメント計画 11.2 リスクの識別 11.3 定性的リスク分析 11.4 定量的リスク分析 11.5 リスク対応計画 11.6 リスクの監視コントロー ル
5.1 スコープ計画 5.2 スコープ定義 5.3 WBS作成 5.4 スコープ検証 5.5 スコープコントロール ★スコープ：範囲
図 1- 7: プロジェクト・マネジメントの知識エリア (PM B O K の構成 ) 出典 : P ro je ct M ana ge m ent i n st it ut e( 20 04 )
・品質問題の増加
・コスト対応力の不足（これまでの積み上げ式のスペック検討では，人件費が低 く，日本を徹底的にベンチマークした新興国に負けてしまう）
・先行開発をふまえた新商品投入不足
・目先のスペック向上のみの商品開発
といった悪循環につながっている。
これらを解決していくためには，多面的な施策が必要である。
例えば，
・自社/自部門のコア価値を徹底的に意識し，価値のある業務に徹底してフォーカ スし，アウトソース，アライアンスできる業務はできる限りアウトソースを効 果的に行う。
・先行開発/要素開発の完成度を上げ，商品開発とパラレルに推進するための作戦 を考える。そのためには要素開発担当が始めから市場・顧客を意識し，研究開 発・設計を進められるためのバックアップ，環境づくりも必要である。
・仕様は最初から全て決まらないことをふまえた開発プロセスを検討する必要が ある。
これまではシステム仕様の検討が終了してから，機能仕様の検討に入るといったシ リアルなプロセスであったが，開発期間を短縮するためには全ての仕様が決まってい なくても走り出さないといけない。そのためには仕様の変更可能性の予測と仕様変更 に強いアーキテクチャの検討が求められる。
そもそも，製造業のミッションは，顧客の欲しい商品・技術を
・できるだけ速く
・お客様の喜んでいただける仕様の製品を提供する
ことであるから，開発期間短縮対応することはいいことであるが，行き過ぎにより，
提供側のデメリットばかりが加速するようではまずい。
よって，顧客への価値提供を実現でき，かつ企業側のメリットにもなる開発期間短 縮を行うことがポイントである。
最近，コンカレント・エンジニアリングを進めるための系統的アプローチとしてフ ロントローディングが改めてキーワードになっている。
フロントローディングとは，“開発源流段階に知恵を投入し，手戻りの防止とリス クアセスメントを充実させること”である。フロントローディングと開発工程の並行 化を進めるためには，部門のミッション/機能見直しとそれを実現できるメンバーのス キルアップとチーム力が必要となる。そうでないと，単に開発源流段階の工数のみが 増加し，結果的に技術者の多忙感のみになってしまう，いわゆる「フロント・ヘビー」
になりかねない。
また，1 プロジェクトだけのフロントローディングを進めるだけではなく，全プロ ジェクトをフロントローディングさせるためには技術ロードマップ等のツールを活 用しながら，中期的な視野を常に見据え，プロジェクト間の技術資産も融合させてい くアプローチが必要である。これは，最近提唱されているプロジェクト・ナレッジ・
マネジメントに通じる考え方である。
コンカレント・エンジニアリングはプロジェクトの大きさ，業種・業態によっても 取り組み方は大きく異なる。大規模プロジェクト型，小規模複数プロジェクト並行運 営型では大きく進め方，考え方は異なるということである。また最近は，グローバル 化，他社とのアライアンスも加味して考える必要もある。
本研究では中期的な視野を常に見据え，プロジェクト間の技術資産も融合させてい くアプローチを通じ，クロスファンクショナル・チーム，コンカレント・エンジニア リング，フロントローディングとプロジェクト・ナレッジ・マネジメントについての 事例研究を行う。
1.2 研究の目的とリサーチ・クエスチョン
本研究の主要な目的は，製品開発におけるプロジェクト・ナレッジを他のプロジェ クトにトランスファーするための効果的な方法を明らかにすることである。過去の製 品開発プロジェクトのナレッジ，将来，未来に実施される予定のプロジェクトで検討 すべき事項・情報等を効果的に活用し，現行プロジェクトにおいて，フロントローデ ィング，コンカレント・エンジニアリング，クロスファンクショナル・チーム的な思