例会部会
先号　　次号

「第191回例会」報告

例会部会長　枝窪　肇　[プロフィール]　：12月号
　日頃、プロジェクトマネジメントの実践、研究、検証などに携わっておられる皆様、いかがお過ごしでしょうか。今回は、10月に開催された第191回例会についてレポートいたします。

【データ】
開催日： 2014年10月24日(金)　19：00～20：30
テーマ： 研究開発を成功させるプロジェクトマネジメント
　～複数の事業分野における多くのプロジェクトの経験を踏まえて～
講　師： 株式会社日立製作所　電力システム社　技術参事　大和田　政孝　様
講師略歴及び講演概要：  
  こちら のリンク先の例会案内をご覧ください。

【はじめに】
　講師はこれまで、原子力部門、防衛部門、宇宙部門、医療部門、再利用エネルギー部門と、さまざまな部門の研究開発プロジェクトに従事されてきました。
　今回のご講演では、まず講師略歴とともにこれらのプロジェクトの概略をご紹介いただいたのち、これらの経験を踏まえ、また、通常のプロジェクトマネジメントと研究開発のプロジェクトマネジメントとの相違点を把握した上で、いかにして研究開発のプロジェクトを成功に導くかということについてお話しいただきました。
　以下に今回のご講演の概要をまとめます。

【講演概要】
研究開発プロジェクトのダイナミックス：
　ダイナミックスとは「プロジェクトはいろいろと動く」ということです。
　プロジェクトにはいろいろな特徴があり、それぞれの物語があります。それを評価するために、「開発仕様」「開発体制」「開発期間」「マネジメント」「開発費」の5つを指標に取ったレーダーチャートに示しました。評価指数=開発終了後の実績値÷開発初期の計画値としており、1であれば計画どおり、数値が大きくなるほど大変なプロジェクトということになります。研究開発プロジェクトの評価方法の一つとして役に立ちます。
　「研究開発の主体」が「国家」「会社」「個人(ベンチャー)」のいずれであるかは、ダイナミックスに大きく影響を与える可能性があります。具体的に言うと、例えば「責任者」を考えると、国家の場合は省庁、会社の場合は事業部・研究所、個人の場合は個人になりますし、「開発目標」であれば、国家の場合は世界レベルの追及、会社と個人は市場開拓ということになります。
　他にも影響を与える要因として「研究開発計画書の妥当性」「保有している基盤技術」「研究開発目標の技術レベル」「経営幹部の関与」「研究開発体制」「リーダーシップ」「マネジメント」「人員計画」「社内予算制度」などがあり、これらによって研究開発のプロジェクトは動くということになります。
　また、プロジェクトは進行に伴っても動きます。初期フェーズでは活気があり、開発責任者も楽観的です。中間フェーズになると現実が見えてきて、皆で頑張ろうとなります。最終フェーズでは猫の手も借りたくなり、目標達成が厳しいという雰囲気が出てきたり一部の仕様実現を諦めるといった事態が発生する場合すらあります。大事なのはこうしたプロジェクトを成功させるためにはどうすれば良いかということなのです。

通常のPMと研究開発のPMとの相違点：
　ここで言う通常のプロジェクトとは、「既に製品化が完成した製品を、新たな市場や顧客へ納入するプロジェクト」のことです。つまり、設計の手法、基準などは確立されており、技術開発も済んでいます。
　研究開発を含むプロジェクトの場合、「研究」「開発」「製品化」「事業化」と進んでいきます。一般的に研究から開発へ行くときには「魔の川」があり、開発から製品化へ行くときには「死の谷」があり、事業化が始まると「ダーウィンの海」が待っていると言われており、そこをどのようにマネジメントしていくかがポイントになります。
　そのポイントですが、「魔の川」では技術、「死の谷」では技術に品質・コストを加え、「ダーウィンの海」では市場・販売価格・強豪製品との差別化がそれぞれ必要です。
　NEDOの「平成25年度成果報告会」資料によりますと、研究開発フェーズにおける課題は6割以上が技術的な課題で、次いで開発資金の確保となります。またうまくいった要因は資金が確保できた、目標設定が適切であった、体制が確保できた、部門全体の熱意が高かったという順となっています。
　以下、製品開発フェーズでは、製品開発中断の課題は市場環境の変化、販売中断は技術的課題が最も大きな課題であり、開発達成したプロジェクトではリーダーが適切に指揮したということが大きな要因として挙げられ、販売フェーズではユーザーの評価への対応がうまくできなかったことが課題となっています。
　以上のように、各フェーズによって課題や達成要因は異なります。
　また、提案時のビジネスプランが適切であったかどうかを見てみると、途中で中断したプロジェクトでは定義が明確でなく、逆に販売を継続できているプロジェクトではしっかりと定義されていたということがわかります。つまり、全体的に計画をしっかり作ることが大事だと言えます。
　こうしたデータを踏まえると、研究開発プロジェクトにおいては、「魔の川」「死の谷」「ダーウィンの海」を超えるために、課題や成功要因を考慮した、プロジェクトマネジメント的にコントロールするためのドキュメントが必要になります。
　具体的には、通常のPMで必要なドキュメント(「プロジェクト定義書」「プロジェクトマネジメント計画書」「品質マネジメント計画書」「リスクマネジメント計画書」)の他に「開発計画書」「技術検証マネジメント計画書」を加え、この2つをしっかり実施することで成功確率が高まるということになります。

開発計画書：
　開発計画書には、
1． 開発計画する製品
2． 対象となる市場動向
3． 開発する製品コンセプト
4． 関係する法制度・規制、許認可等
5． 想定する事業規模
6． 製品投入時期
7． 開発スケジュール
8． 開発体制
9． 投資金額(開発費、製造設備他)
10． 利益
11． ステークホールダーへの対応
12． リスク分析・解決策
を盛り込み、これらを幹部に説明し承認を受けて、開発を進めていくことになります。
　開発計画書のポイントとして、以下を駆使しながらプロジェクトを進めると開発がどんどん進んでいきます。
1． 魅力的な開発計画の提案 => 誰もが納得出来る製品コンセプト
2． 経営方針にマッチした計画の提案 => 会社として重点化する事業分野
3． 社内関係者の応援 => 経営幹部、管理部門、グループ会社他
4． 社外からの応援 => マスコミ、大学、有識者、外部機関他
5． 社外からの支援 => 外部資金、国内・海外メーカとのパートナリング
6． コンソーシアムの構築
一方で、以下のような課題があります。
1． 開発計画書の妥当性 => 将来の予測が含まれるので不確定要因がある。
2． 社内認可取得に全力投球 => 認可取得のために計画見直しもありえる。
3． 実行時に各種障害 => 開発人員の確保、組織の壁、チーミング他
4． 計画の変更 => 外部要因(市場環境、競合他社他)、社内要因(開発遅延、経営方針の変更他)
5． 進捗状況の報告 => 管理部門、経営幹部、外部スポンサー他
　いずれにせよ、開発計画書をしっかり作成し、それをベースに進めていくことが、成功への近道であり、大事なことになります。

技術検証マネジメント計画書：
　技術検証にはVerificationとValidationの2種類があります。Verificationはやることをきちんとやっているか、Validationは顧客要求を満足しているかという観点です。
　技術検証を行う上では、両方の観点を含めてマネジメント計画書を作成し、コントロールしていくことが有効です。
　技術検証マネジメント計画書には以下の内容を盛り込みます。
1． 検証の範囲 => システム、サブシステム、部品
2． コンフィギュレーションコントロール => 構成品体系、図書体系、スペックコントロール、不具合管理、動作回数管理
3． 検証マトリックス => 構成品検証マトリックス、仕様検証マトリックス
4． 検証時期 => 研究開発の進捗に合わせて時期を設定
5． ホールドポイントの設定
　検証の範囲はどういう位置付けの製品を開発するかということ、コンフィギュレーションコントロールは構成品や図書の体系およびスペックのコントロールを行うとともに不適合管理をすること、検証マトリックスは構成品の検証手段を表にまとめたもの、ホールドポイントはこれをやればマネジメント的に大丈夫だというポイントということになります。
　プロジェクトではいろいろな経験を積んだ人が集まって一つの開発をしますが、例えばコンポーネントのスペシャリストにシステムレベルのまとめを行う場合などは、経験不足を補うためにも技術検証マネジメント計画書をしっかりと作成して運用することが大事です。
　以下は技術検証マネジメント計画書の作成・運用がもたらすメリットです。
1． 構成品検証マトリックスは開発計画の立案に有効 => 検証マトリックスにより開発課題の明確化が出来る。
2． 検証マトリックスにより計画的な開発が可能 => 開発工程と検証マトリックスのマッチングが図れる。
3． 技術検証の確実な実行が可能 => 検証結果を定期的に確認することにより漏れなく検証
4． 技術検証状況の見える化 => 検証の進捗状況を明示することにより情報共有化
5． フェーズゲートに活用可能 => 検証結果が確認出来るまではホールドする
　一方で課題もあります。
1． 技術検証マネジメントの文化形成 => 会社・職場で培われた武運化の継続性が障害
2． 技術検証マネジメントの確立 => 効率良いマネジメントのルール作り
3． 技術検証マネジメントの責任者 => 検証実行者と直接関係のない第三者が理想
4． 技術検証マネジメントにはコスト発生 => エビデンス作成、マネジメント工数他が必要となる

研究開発を成功させるためのPM：
　最後に、研究開発を成功させるためのポイントをまとめます。
1． 現実的な開発計画書の作成
(開発仕様、開発時期、開発体制、開発費、検証計画)
2． 柔軟な開発計画書の改訂
3． WBSによる開発内容の明確化
4． システム設計書の作成
5． 製品の品質レベルに対応した開発プロセスの確立
6． 外部専門機関を含めた開発体制の構築
7． 検証マトリックスによる着実な検証
8． 開発完遂に向けた執念
9． 経営幹部の長期的な視点
　他にもポイントはあるかも知れませんが、自分の経験の中ではこういったことがポイントであると考えています。

【感想】
　今回の講演は、さまざまな研究開発に携わってこられた講師がその経験を元にたくさんの事例を示しながら内容を説明していただいたことで、大変わかりやすく興味深いものでした。

　以上が今回の例会の概要です。今回のご講演資料は、協会ホームページの「PMAJライブラリ(例会・関西例会)」のページにアップロードされていますのでご参照いただければと思います。

　なお、本年9月より、今回講師の大和田様も発起人の一人となり、研究開発SIG(研究会)が発足し、活動を開始しております。
　また、我々と共に部会運営メンバーとなるKP(キーパーソン)を募集しています。参加ご希望の方は、日本プロジェクトマネジメント協会までご連絡下さい。

以上
ページトップに戻る