自動車部品メーカーのプロジェクトマネジメント導入による製品開発業務改革

車体メーカー、部品メーカーのハイエラルキーが完全に出来上がっている自動車業界において、 近年の自動車メーカーのパラダイムシフトは自身だけでなく業界全体に大きな影響を与えている。 特に業界の大部分を構成する自動車部品メーカーにおいては、従来通りのコストダウン要求や開発 リードタイム短縮要求だけでなく、それらを実現した上での、多品種変量生産への対応、環境対応、 情報化対応など、対応すべきことが山積みとなっており、従来通りのやり方ではそれら全てに対応 し、さらに顧客である車体メーカーへ満足を提供し続けることが困難な状況になってきている。 　このような状況下において、如何にして歴史があり、実績に裏づけされた製品開発業務を現在、 さらには今後の変化にも耐えうるように改革して行ったか、その改革の全体像と進め方、内容につ いての紹介を行っていく。

　事例として紹介する企業は、部品メーカーの中で は大手に位置付けられ、特にその技術力、品質の高 さにおいては業界屈指と認識されている。また、自 動車の完成品以外はほとんど扱っていると言えるほ ど製品種類も多種多様な企業である。今回の開発業 務改革の対象としてはITS（Information Transportation System）として位置づけられる製品であ り、一般的な自動車部品と言うより、自動車に備え 付けられた情報家電製品と言っても通じるものであ った。この製品は、当時は自動車を制御するために 必要となる機能や品質が要求されるものでは無く、ど ちらかと言えば、自動車の利用者のニーズによって 製品の仕様が決まるといった、他の自動車部品（製 品）とは多少異なった特徴を持っていた。その結果、 車体メーカーは自動車を市場に投入するギリギリま で利用者ニーズの動向を把握し製品に反映するとい う志向になり、製品設計の終盤まで仕様が追加・変 更されるため、事例の当該顧客にとっては安定した 開発を妨げるリスクを常に抱えた製品となっていた。 その上さらに、多くの実績と高い信頼によって、能力 をフル稼働し続けなければならないほどの仕事量 が恒常的に存在し、何か問題が発生した時に即座に 対応できる余力を持つことも難しくなりつつあり、結 果として、納期は遵守しているものの、短納期製品 の一部については高品質を保証できるレベルまでの 対応が取れず、普通の品質（品質に何ら問題がある レベルではない）となってしまうことや、納品時に 製品に必要な機能が全て揃っておらず、残作業を抱 えた状態でプロジェクトが完了してしまうといった ことも現実に起こっていた。さらにこの作業を抱え たまま終わるという状況は、製品開発のライフサイ クルからも、将来かならず大きな問題となることが 予想されていた。

1. プロジェクトの合理的な意思決定の欠如 　製品の開発体制は、自動車とのインターフェース 部分と製品の全体仕様を担当する部門とソフトウエ ア開発部門、ハードウエア開発部門のメンバーで構 成されるが、製品ごとに明確なプロジェクト体制が 組まれているわけではなかった。そこには、ひとつ の製品を開発するにあたり、ソフトウエア担当メン バーは製品に求められる機能を、ハードウエア担当 メンバーは製品としての箱（もちろん箱だけでなく、 回路、機構を含んだものではあるが）を作り上げて いくため、最終的にはひとつの製品として組み上げ られるものの、それぞれの業務を密接な関わりを持 ちながら進めていことが必須とまではいかないとい うことがあった。すなわち、今まではそれぞれの部 門（担当メンバー）が担う部分をスケジュール上の ある約束の時期までに間に合わせてさえいれば、大 きな問題は起きなかったのである。その結果、開発 業務の報告はプロジェクト単位ではなく、個人単位、 課／部門といった組織単位で行われる形態で定着す ることになる。もちろん、組織としての規模、扱う 製品数と開発プロジェクト数が少なければ各機能組 織による開発のマネジメントだけで十分な場合もあ る。ところが製品が増え、開発プロジェクトが増え、 さらに製品要求機能の複雑、増大化への対応もあり、 組織の規模は数年前に比べ１０倍近くになっていた。 膨大な組織内報告情報からプロジェクトとしての状 況を把握することはほぼ不可能となり、プロジェク トが順調なのか問題があるのかが判断できず、効果 的な意思決定ができない状態となっていた。 2. 問題解決型のマネジメント 　開発現場では製造業としてのコストダウン意識に は目を見張るものがあった。もちろんその背景には 自動車メーカーからの絶え間ない要求もあるが、単 純にムダを省くだけでなく、より効率化するために はどのようにしたら良いかということが、組織内の 階層を問わず常に考えられていた。しかし、そこが 本質的なリスクマネジメントを行う土壌を築いてい く上では障害となっていた。問題解決のために必要 となるリソースは必要なものと認識され投入されて いたが、リスクの顕在化によるプロジェクトへの悪 影響を抑えるための、起こるかどうかわからないこ とに対する予防策を実施するために必要となるリソ ースが単純にコストアップにつながるものと認識さ れてしまっていたのである。この結果、客観的に見 て、明らかにリスクとして認識できることも、リス クとして取り上げても対応策が実現されないという 意識から、表に出て来ず、結果として問題となり、 問題の対応にあたるといった状況を生み出してい た。ただし、その解決は迅速なものであり、問題解 決にかかるコスト、待ったなしでの対応を迫られる 担当メンバーの意識面を考えなければ、プロジェク トに大きな影響を及ぼすところまでは至らない場合 が多かった。 3. エンジニアのマネジメントに関する志向性 　開発業務担当者の大部分は当たり前ではあるが技 術者（エンジニア）である。専門的な技術と最先端 の技術を設計に落とし込み形作っていく。エンジニ アとしてのやりがいが実感できる職場であるはずだ った。過去、製品自体の規模が小さかった時代には、 何とか製品化したいといった意識を同じように持っ た少数のエンジニアによる開発が行われ、その醍醐 味を十分に感じることができていたのも事実であ る。そこでは技術力が全てであり、技術力の高い人 がチームを牽引していた。当時は技術によるマネジ メントでも十分に通用する環境であったということ ができる。ところが時代の変化とともに製品やその 開発を取り巻く環境も変わっていった。製品規模の 増大は、製品構成を複雑化し、多種多様な専門技術 を必要とするようになり、社内の多くのエンジニア がかかわるようになっただけでなく、社外の人的リ ソースや、部品供給先メーカー、協業先などと一緒 に開発を行っていくような形態へと移行させていっ た。それはエンジニアの業務におけるマネジメント のウェイトを高めることにつながり、技術だけでは なく、リーダーシップの発揮やマネジメント力の強 化が要求され、エンジニアとしての理想と現実との 間に大きなギャップを発生させることになった。 4. 失われたエンジニアとしての喜び 　感覚的なものではあったが、本業務を開始した当 初からエンジニアのモチベーションが低下している のではないかと感じられていた。実際に調べてみる と、その印象は現実のものであり、前述したような マネジメント業務量の増加によって設計業務ができ なくなっていることが要因で仕事の達成感や満足感 を得られず、モチベーションを下げていることが明 らかになった。ただし、モチベーション低下の要因 はそれだけではなかった。製品規模の増大は、業務 の種類だけでなく、開発の生産性と品質を向上させ るために、業務を細分化し共通化させていった。そ の結果、担当者一人ひとりが担う範囲は小さく、か つ繰り返しのものとなり、一部の担当者を除き出来 上がる製品をイメージすることができなくなってし まっていた。これはエンジニアにとっては致命的で あり、マネジメント層の多くはこの状況を危惧して いた。

　実際にはまだ他にも大小さまざまな問題が顕在化 しており、ひとつひとつ課題を解決していけばよい 方向に向かっていくというような状況ではなかった。 まず最初に行ったのは、問題の構造を明らかにする ための現状分析で、トップマネジメントを含めた、組 織内の各階層に渡るヒアリング（２０名程度）、アンケ ートによる意識調査・プロジェクトマネジメント成 熟度調査（２００名程度）などを実施した。その結果 から、以下のように問題の整理を行った。 　①開発プロジェクトの実施体制が曖昧
　②複数のプロジェクトを統合的にマネジメントする体制がない
　③根拠ある達成可能なプロジェクト計画が立案できていない
　④設計業務プロセスがスピードについていけていない
　⑤プロジェクトのリスク・課題の可視化が不十分
　⑥プロジェクトの達成感を実感できず、モチベーションがあがらない
　⑦階層間に意識のギャップがあり、権限委譲がうまくいっていない
　⑧協業先のマネジメントが不十分
　⑨人材の技術スキルが向上していない 　個々の問題を解決するための施策の立案は行ったが、それだけでは良くても現状が改善されるだけとなってしまうため、次のステップでは今後の環境変化を見越した上で製品開発をどのように行っていく べきかという「製品開発のあるべき姿」の構築を「Strategy（戦略）」、「Program（プログラム）」、 「Project（プロジェクト）」、「People（人・文化）」の４つの視点で行った。さらに「あるべき姿」を実 現するための重要な成功要因を特定し、それらを施策に落とし込んでいった（図表-1）

　「あるべき姿」を実現するための施策は、“What to do （何を） ? ” にかかわるもの（StrategyとProgram）と “How to do（どうやって）?”にかかわるもの（ProjectとPeople）大きく２つに分類す ることができる。どちらかが優先度が高いというも のではなく、可能であれば同時に行った方が良いの は事実であるが、その場合の施策実施に必要となる 要員を確保することが難しいことと、すでに決まっ ている製品開発案件について失敗が許されるわけで はないことから、まずは“How”の部分に対象を絞 って施策の詳細を計画し実施した（図表-２）。

1．プロジェクトマネジメント実施体制の整備
　プロジェクトマネジメント実施体制の整備では、 単に体制図を作成したということではなく、体制図 を効果的に活用するためのプロジェクト構成図の作 成も合わせて行った。その目的としては、プロジェ クト実施体制における役割やレポートラインを明確 化することであり、情報配布時の配布先、すなわち 影響範囲を明確化することであった。機能組織中心 に開発が行われてきた経緯から、部門間障壁は自然 発生的にできあがってしまっていたため、そこにプ ロジェクトの軸を通すことによって、バラバラ感を 払拭し、プロジェクトとしての一体感を醸成するこ と、プロジェクト情報の流通経路を作ること、組織 規模が大きくなったことによって見えにくくなって いた影響範囲を掴みやすいようにすることが必要で あった。（図表-３，図表-４）

2．リスクマネジメント手法の構築
　製品開発にリスクがつきものであることは認識さ れており、リスクマネジメントが全く行われていな いというわけではなかったが、リスク対応策の内の 予防策についてはほとんど実施されていなかった り、特定されたリスクが技術領域や要員不足に偏っ ていたりと、十分というには程遠い状況ではあった。 手法構築のゴールはリスクゲートの設定、リスクマ ネジメントプロセスとリスクチェックリスト、リス ク評価シート、リスク管理シートの作成としたが、 もっとも重要なのはリスクマネジメントの文化を作 り上げることと認識し、そのための教育やワークシ ョップを並行して開催していった。（図表-５）

3．プロジェクトマネジメントオフィスの設置
　開発部門内には技術的な支援や、品質向上のため の取り組みを役割とする組織はあったが、プロジェ クトを支援したり、複数プロジェクト間の調整を行 ったり、プロジェクトマネジメントの仕組みそのも のの定着や改善を担うような機能は存在していなか った。また、長い間機能組織中心で開発業務を進め てきていたことからも、突然オフィス機能設置の提 案をしても受け入れられがたいことは十分想像でき たため、プロジェクトマネジメント導入によって発 生する混乱の収拾と、確実に増えることになるマネ ジメント工数の一部を吸収するためという建前で支 援メニューを作成し、実際に体験してもらうことで その必要性を認識してもらい、支援を中心とした弱 いオフィスではあったが、設置へとこぎつけていっ た。現時点においても支援中心のオフィスではある が、５名の専任メンバーによって、常時動いている ２０近くのプロジェクトに対して、プロジェクトコン サルティング、会議運営支援、ツール支援が行われ ている（図表-６）。

4．プロジェクトマネジメントツールの導入
　ツールは弊社のArtemis 7が導入されたが、単純 にツールのみの導入ではなく、ツールを活用するた めの環境整備も同時に行った。
　①プロジェクトマネジメントプロセス
　②製品開発プロセス（＝WBS:Work Breakdown Structure）
　③プロジェクト会議体
　④コミュニケーション計画
特に重点を置いたところは、プロジェクトの状況 を可視化し、次のアクションにつながるようにマネ ジメントプロセス上に会議体を設定したところで、 ソフト・ハード各担当グループによる会議体を経て プロジェクト全体の会議体が開催されるという２段 階の会議体の設定を行った。また、兼務が多い各担 当グループの実作業担当者が以前より機能組織の中 で定期的に行われていた会議体に参加し報告するの みで、プロジェクトの会議体に参加しなくても、プ ロジェクトの状況が確認できるようにしたところも 大きなポイントであった。 5．ヒューマン系施策の実施
　モチベーション向上、マネジメントスキル向上と いう施策については、個々をばらばらに考えるので はなく、人材育成プログラムとして位置付け、体系 立てて行っていった（図表-７）。特にモチベーショ ン向上では、プロジェクトの最終成果物である製品 と軸が異なる機能開発を行っているだけでなく、微 細なモジュール単位を担当しているソフトウエア開 発担当者にはプロジェクトマネジメントで一般的に いわれるプロジェクトチームビルディングだけでは 対応できず、他の手を打つ必要があった。そのため、 技術者としての将来像を描くことができるようにす るための「求められる人材像」と、そこへ辿りつく ためにどのようなことを経験し、学んでいけば良い かがわかるような「キャリアパス」の設計、自己の 意識改革につながるような研修プログラムを実施し た。

1．プロジェクト状況の可視化によるプロアクティブなプロジェクト運営
　ツールとしてのArtemis 7の導入・活用と、週次 で定期的に進捗会議を開催したことによって、かな り早い段階からプロジェクト情報が常に最新の状態 に保たれるようになり、進捗や課題対応状況などが 可視化され、プロジェクト状況を関係者間で共有で きるようになった。なかでも、問題について消火型 から防火型に自然に移行したのは、進捗会議の定期 開催と常に先のことを意識できるように会議をファ シリテートした支援業務の成果であると認識されて いる。他にも議事設計による会議時間の短縮、問題 先送りの減少など具体的な効果が出ており、現在で は余程のことがない限り、アドホックに会議が開催 されることはなくなっている。 2．リワークの減少
　ツール導入と並行して行った製品開発プロセスの 整備（WBSの標準テンプレート化）によって、 個々のプロジェクトはスコープに基づく、必要作業 項目を設定することが可能となった。初期の計画立 案が効率化されたため、余裕を持って新機能分の追 加作業項目を検討することも可能となり、作業項目 が漏れることによって発生していた追加作業や、リ ワークが明らかに減少したと認識されていた。要す るに、計画精度が上がったのである。また計画精度 が向上することによって、変更発生時の影響範囲を 把握することが可能となり、事前に対応策を検討し ておくことができるようになった。 3．マネジメント意識の向上
　組織の中、およびプロジェクトの中で誰がどのよ うな役割と責任を担うべきなのか、自らが人材像を 構築していくことによって、自然にマネジメントに 対する意識は高まっていった。その結果は会議等に おけるリーダーシップの発揮という形で現れてきて いる。もちろん、全ての必要な能力を発揮するとこ ろまでには至っていないが、施策自体は継続してお り、今後も継続的に改善されていくことが期待でき る。 4．設計現場の雰囲気の変化
　モチベーションの低さは当初より気になっていた が、プロジェクト実施体制の整備による人の意識の プロジェクト志向へのシフト、自らの将来を描くこ とを可能とするキャリアパスの提示とキャリアアッ プ計画の立案、そして研修プログラムの参加などに よって徐々にではあるが雰囲気は変わっていった。 今までは自分を守るために業務範囲を自ら狭めた り、囲い込んだりしていたが、積極的に周りとの関 係を築き、部門間のどちらかといえばグレーな業務 領域についてお互い補完し合うような行動や発言が 出てくるようになっていた。雰囲気としては、明る さや空気が澱むことなく常に動いているように感じ られるようになったと認識されていた。

これまでの取り組みと現在認識されている効果を 通じて判断できることは、その検証を行うことはで きないものの、どれかひとつの施策でも欠けていた としたら、効果は出ていなかったのではないかとい うことである。顧客自らが自分達の抱えている問題 を構造化し、自分達がどうなりたいかを明確化した うえで、問題を解決しながらステップアップしてい くための施策を計画し着実に実施してきた。例えば、 製造業として、数値的な目標を持った品質・コスト に対する改善要求が社内外から絶え間なくあり、ど のような取り組みも数値目標達成度合いが評価され るというような厳しい環境にありながらも、効果を 測ることが本質的に難しい、「人の意識改革」にかか わる施策も採用されている。これは右肩上がりの成 長を続けている状況であっても、顕在化しつつあっ た問題の本質が理解され、危機感を持っていたこと を示していると考えている。業務改革のゴールに向 けてはまだまだ緒についたばかりといえる状況では あるが、今後の成功を予感させられる一番大きな要 因といえる。２、３年後には自動車部品メーカーにお けるプロジェクトマネジメント制度導入による業務 改革の先駆者として業界をリードする立場となって いることを期待している。

国内大手（従業員数：数千人規模）の自動車部品メーカー。