組込みソフトを伴う新製品開発におけるプロジェクトマネジメント

近年の電気機器は、多機能化・高機能化が進むにつれて、より複雑で高度な処理を 行うようになっている。技術革新のスピードも驚くべきものがあり、それにあわせて 新製品開発も高度化、複雑化している。更には企業間の競争激化により、新製品を早 期に市場投入して市場における優位性を獲得しようという意図から、開発期間の短縮 が求められている。 　しかしながら、かつて成果を上げていた職人芸的な開発手法を踏襲していることが 原因となり、モノはできるが品質に問題がある、あるいは開発コストや開発期間が超 過するといった失敗プロジェクトが頻出しているのが現状である。 　また開発にあたってはメカ（機構制御部）、エレキ（電気回路部）、ソフト（ソフト ウェア）のコラボレーションが必須であるにもかかわらず、メカやエレキによる要件 実現が難しくなるとソフトにしわ寄せが行き、プロジェクト終盤にソフト開発が膨れ 上がるといった、部門間の壁が原因となって問題が起きることもよく見られる。 　本項では、このような状況を打破するため、製品開発の手法を改善するとともにマ ネジメントを重視し、効率的に高い成果を上げることに成功した事例を紹介する。 高度化・複雑化する開発を短期、低コスト、高品質で行うという要求に応えるために、 状況の可視化・共有化、メカ・エレキ・ソフト間のコラボレーション、リスクや問題 への早期対処をいかにして実現したかを解説する。

　印刷関連機器を製造するメーカーとして業界の 上位に位置付けられ、その技術力は高く評価され ている。しかしながら、技術革新のスピードが速 まっていることや、他社が製品開発に大量のリソ ースを投入していることから、現状のままでは他 社に追い越されてしまうのではないかという危機 感を抱いていた。そのような状況の中、最新の技 術を採用して自社の強みを広くアピールでき、か つ今後の製品戦略の核となる新製品を開発すべく、 今回紹介するプロジェクトが立ち上げられた。
　組織内では、技術力を重視するあまり、高度な 機能を実装した製品を造るためにはコストやスケ ジュールが超過するのは仕方がないという考え方 が蔓延していた。またマネジメントを行う立場の 人達も全員が技術者出身であり、何か問題が起き たら何日でも徹夜をして解決する、解決できない のは技術的に未熟であるからだという、いわば技 術至上主義ともいうべき風潮があった。この状況 の中でプロジェクトを成功させるためには、技術 のみに頼らずプロジェクト全体を見渡して状況を 的確に把握し、タイムリーな判断ができるプロジ ェクトマネージャと、彼を支援する仕組みが求め られていた。

　プロジェクト開始にあたり、解決しなければな らない課題として考えられていたのは以下の3点で あった。 1. プロジェクトマネージャの経験不足 　過去の失敗プロジェクトにおいて、唯一高い成 果を上げたグループを率いていたリーダーをプロ ジェクトマネージャに抜擢したことから、大きな 期待とともに、プロジェクトマネジメントの経験 不足に対する不安を本人も周りも抱いていた。小 さなグループであればリーダー自身が技術的な内 容にまで深く踏み込んで問題を解決することが可 能であるが、プロジェクトマネージャは、プロジ ェクト全体を広く浅く把握しなければならない。 自分の得意とする部分に深入りし全体像を見失っ てしまうことは、どこの業界でも見られるプロジ ェクト失敗の大きな原因のひとつであるが、今回 のプロジェクトでは特にこの点が危惧されていた。 2. 部門間の壁 　製品を構成するユニットは、それぞれにメカ、 エレキ、ソフトのスペシャリストがアサインされ る。各メンバーは自分の担当分野では高い技術力 を持っているが、技術的な事柄に深く入り込みす ぎて周りが見えなくなり、他のユニットの担当者 とのコミュニケーションがうまくいかなくなるこ とが多い。過去にはユニット間のインタフェース 調整がプロジェクト終盤まで行われず、大きな手 戻りが発生した結果、納期が1年以上遅延したこと もあった。このようなことを繰り返さないために、 どのような方法を用いて部門間の連携を促すかが 大きな課題として挙げられていた。 3. 厳しい目標スケジュール、目標コスト 　技術的課題を解決するためのスケジュール遅延、 コスト超過を容認する雰囲気があり、特にコスト については、製品をラインで製造する際のコスト （製造コスト）は重視しても、製品を開発するため のコスト（開発コスト）については無頓着であっ た。そのため開発コストはいつの間にか増大し、 結果として苦労の末製品コストを下げても、開発 コストを賦課すると製品の販売価格をほとんど下 げられないというケースが非常に多かった。
　しかしながら近年の不況の影響で製品価格を高 く設定することはできず、開発コストにも非常に 厳しい制限が課せられていた。また技術力をアピ ールするというプロジェクトの目的から、機能や 性能を犠牲にすることができない上、製品の上市 が他社に遅れるようなことがあってはならないと いう厳しい状況にあった。 　これらの課題を分析し、解決策をひとつひとつ 実行することが、プロジェクトを成功させるため に必要不可欠であった。

　プロジェクトを成功させるためには、起きてし まった問題に場当たり的に対応するのではなく、 問題の芽を早期に発見し、大きくなる前に摘み取 ることが必要である。そのためには「今何が起き ているのか」を正しく把握することはもちろんの こと、「将来何が起きるのか」を予測し、問題を解 決するのではなく、問題を起こさないようにすべ きである。
　この点を踏まえ、以下のように対応を行ってい った。 1. WBS作成 　最初に行ったのは、プロジェクトの全体像を把 握し、作業の抜け・漏れをなくすためのWBS作成 であった。より効率的にブレイクダウンを行うた め、製品をまずユニット単位で分割し、ユニット の責任者がそれ以降のブレイクダウンを行う形を 取った。その際の進め方として、全体を統合した 際にユニット間のインタフェースや要調整事項の 洗い出しを容易にするために、どの階層にどのよ うな内容を表現するかをルールとして定めた。 2. メンバー全員によるスケジュール作成 　納期ありきで無理やり納期に間に合うスケジュ ールを立てることを避けるため、スケジュールに ついてもWBSと同様、まずユニットごとに作成し た。その際には各ユニットの担当者が全員で他ユ ニットからのインプットや調整が必要な事項を明 確にした上で、自信をもって達成できるスケジュ ールを作成した。その後各ユニットのリーダーが 集まりユニット間の作業の前後関係に注意しなが ら統合スケジュールを作成した。

3. リスクマネジメントの実施 　これまでの製品開発プロジェクトでは、技術的 な難関や達成すべき機能・性能にばかり目が行っ てしまうために、例えばソフト開発着手が遅れて リソース調達に苦労する等、マネジメントに関わ る問題はどのプロジェクトでも起きているにもか かわらず軽視される傾向にあった。そこで特にマ ネジメント関わる事柄に重点を置き、リスクの洗 い出しと分析を行った。どのようなことでも思い ついたら発言し、他者の発言を批判しないという ルールの下で行うことにより、漠然と不安に思っ ていたことが具体化され、その対応策を検討する ことができた。例えばソフトウェアの設計はメカ、 エレキのハードウェア設計終了後に開始すること になるため、これまでの製品開発プロジェクトで はハードで想定していた性能が出ないためにソフ トにしわ寄せが行き、結果としてプロジェクト全 体のスケジュールが遅れるということがよく起き ていた。これを防ぐために今回のプロジェクトで は事前の性能検証に重点的に行い、メカ、エレキ により実現すべき性能目標とソフトにより実現す る性能目標を早期に具体化することを目指した。

4. モニタリング・コントロールのルール策定 　プロジェクト遂行中に問題発生の兆候を把握す るためには、状況を正しく把握することが必須で ある。さらに問題が起きたら、あるいはその兆候 を発見したらすぐに情報を適切に伝達するための コミュニケーション、エスカレーションルートを 明確にすることも必要である。
　そこで状況を正しく把握するために進捗報告に おける進捗度測定の基準を定めた。そして状況報 告や情報の伝達等の情報の流れと、それらを用い て意思決定を行うプロセスを明確にし、マネジメ ントプロセスフローを作成した。 5. 情報共有のためのIT導入 　進捗状況、リスクや課題の状況の共有化やコミ ュニケーションの円滑化を促進し、コラボレーシ ョンを向上させるため、ITの導入を決定した。た だしプロジェクトがすでに始まっていることを考 えると、ソフトウェアを一から作りこむことや難 しい操作方法に習熟しなければならないようなも のを使うことは考えられなかったため、導入が容 易で、操作が比較的容易な市販のプロジェクトマ ネジメントパッケージソフトウェア（Artemis製 品）を採用することとなった。

　前段で述べた取り組みには、プロジェクトマネ ージャが指示して行うのではなく、中核となるメ ンバー全員で取り組んだ。その結果、課題やリス クに対してメンバーは自分の担当する部分だけで はなく、プロジェクト全体を俯瞰して最適となる 解決策を考えるようになった。また技術ばかりで なくマネジメントも重要であるという認識が広が り、技術を偏重する風土に変化が見られた。そし て最終的にプロジェクトをスケジュール、コスト、 品質すべての面において成功裡に完了できたこと が最大の成果である。その成果を生んだ要因とし て特に顕著であったものを以下に挙げる。 1. 手戻りの減少 　WBSを用いた構造的な作業の洗い出しの結果、 作業に漏れがなくなり、かつそれぞれの作業は確 実かつタイムリーに実施された。またWBSによっ て常にプロジェクトの全体像を俯瞰することがで きたため、問題の兆候を把握することが容易とな り、リスクを効率的にマネジメントすることがで きた。問題が起きてからではなく、兆候が見つか った時点で対応できたことにより問題が大きくな らず、結果として手戻りも大幅に減少した。 2. 状況の可視化 　ITの活用により、進捗状況やリスク状況がいつ でも最新の状態で見られるようになり、問題に対 するアクションが非常に早くなった。一般にプロ ジェクトマネージャの仕事の8割がコミュニケーシ ョンに費やされると言われるが、モニタリング・ コントロールのルールとITを活用してコミュニケ ーションを効率的に実施できたことで、プロジェ クトマネージャが問題・リスクへ対応する時間を より多く確保できたことは、プロジェクトの成功 要因のひとつであろう。 3. 決断のスピードアップ 　リスクマネジメントを実施することにより、早 期対応が不可欠な問題に効率的に対応することが できた。一例として出力関連で採用する技術の早 期決定が挙げられる。当初は1分あたりどれだけの 量を処理しなければならないのかが明確になって おらず、とにかく高速化しなければならないとい う思いから可能性のある複数の処理方式について 検討を進めていた。これは製品企画部門が製品の コンセプトを明確に示していなかったためである が、彼らが決定するのを待っていては無駄な待ち 時間ややらなくても良い作業が発生してしまうこ とは明らかであった。そこで、関係するメンバー を集めて想定顧客に対してヒアリングを行うこと により、必要な性能を具体的に把握し、製品コン セプトの明確化を促すことができた。 4. スケジュール遵守意識の向上 　納期を達成するための工夫を具体的に検討する ことにより、メンバー全員が、「これならできる」 という気持ちを持つことができた。また自分の作 業が他の作業に与える影響を認識できたこと、そ して何より自分たちで立案したスケジュールであ るという意識が、スケジュール遵守意識を高め、 結果として当初の計画に遅れることなく開発を完 了することができた。 5. 安心感のめばえ 　十分な検討により計画が現実的で実現可能性が 高いものとなったこと、状況把握の仕組みをしっ かり構築できたことから、「ここにあることを粛々 と実行すればプロジェクトは無事完了できる」と いう気持ちを持てたことがプロジェクトマネージ ャの自信につながり、プロジェクトメンバーも安 心してプロジェクトに取り組むことができた。こ のことはプロジェクト全体の雰囲気やメンバーの モチベーションにも良い影響を与え、結果的にこ れまでにない高い生産性を示すことになった。こ れは問題が起きたときにも冷静に対応することが でき、大きな混乱もなくプロジェクトを完了させ ることができたためである。

　今回のプロジェクトで実施した事柄は、決して 特殊なものではなかった。まったく同じことを実 施してもうまくいかなかった過去の例と比べた時 に最も異なるのは、プロジェクトマネジメントの 必要性、重要性をメンバーに理解してもらうため の啓蒙・教育活動を重要視し、徹底的に実施した ことである。メンバー全員で危機感を共有し、プ ロジェクトマネジメントの必要性を認識すること が第一歩であった。押し付けではなく各自が積極 的にプロジェクトマネジメントに取り組めるよう、 実践する手法・方法論は全員が理解し納得できる まで根気よく説明した。その結果プロジェクトメ ンバーは、自分の技術面における使命だけでなく、 マネジメントにおける役割を十分に理解し、当然 のこととしてそれを果たすことができた。
　今後はこのプロジェクトで得られた経験やノウ ハウを他のプロジェクト、更には他の事業部門で も活用して行くことが期待されている。現在はそ のための施策としてPMO（Project Management Office） の設置等を検討している。

日本有数の印刷・イメージング関連機器製造メ ーカー。従業員数は数万人、研究開発投資額は数 千億円にのぼる。