☆☆☆Web配信セミナー☆☆☆
『オープンイノベーションを成功させる優れたベンダーの見つけ方と活かし方』
〜ベンダー側に意図を的確に伝える概要設計書と、ベンダー側の創意工夫と最先端技術を活かす性能仕様書の作成方法〜
S220426AW
☆☆☆本セミナーは、Zoomを使用して、行います。☆☆☆
開催日時：2022年4月26日（火）11:00-17:00
受 講 料：お1人様受講の場合 51,700円[税込]／1名
1口でお申込の場合 62,700円[税込]／1口（3名まで受講可能）
★本セミナーの受講にあたっての推奨環境は「Zoom」に依存しますので、ご自分の環境が対応しているか、
お申込み前にZoomのテストミーティング（http://zoom.us/test）にアクセスできることをご確認下さい。
★インターネット経由でのライブ中継ため、回線状態などにより、画像や音声が乱れる場合があります。
講義の中断、さらには、再接続後の再開もありますが、予めご了承ください。
★受講中の録音・撮影等は固くお断りいたします。
澤田雅之（さわだまさゆき） 氏
澤田技術士事務所 所長
| ＜略歴、等＞ |
1978年に警察庁に入庁し、2013年に警察情報通信研究センター所長を退職するまでの間の通算17年にわたり、多種多様な警察情報通信システムの研究開発や整備に係る発注者エンジニアリング業務（性能発注）に従事。
2015年に技術士事務所を開業して以降、発注者エンジニアリング（性能発注）、ドローン飛行・自動運転走行の安全対策技術、顔画像･人物画像の認識技術などに係るコンサルティング、講演、論文執筆を行っている。
本セミナーに関係する主な著作は、以下の通りです。
＊公共事業における性能発注〜技術士が「公益確保の責務」を果たす切札 ：月刊『技術士』10月号、2020年。
＊イノベーションに不可欠な発注者エンジニアリング：警察政策学会資料第99号、2018年4月。
＊警察情報通信の発注者エンジニアリング～ターゲット発見システムの実現に向けて： 『警察政策』第19巻、2017年3月。 |
|
| |
技術革新が著しい分野や、ソフトウェアが機能・性能を左右する分野では、優れた設計･製造ができるベンダーを広く外部から募る「オープンイノベーション」が、大きな成果を産み出すところです。これには、ベンダー側の創意工夫や最先端技術を存分に活かすことができる枠組み作りが欠かせません。そこで問題となるのは、優れたベンダーを見つけ出す方法と、ベンダー側の創意工夫や最先端技術を存分に活かす方法です。我が国では、「この設計図書のとおりに造ってもらいたい。」といった、実現の手段や手法を示す「仕様発注」の考え方が、あらゆる分野に深く根付いています。しかし、このような考え方では、「オープンイノベーション」には百害あって一利無しです。そこで、「このようなものを設計･製造してもらいたい。」といった、実現の目標を示す「性能発注」の考え方の出番となります。この場合、「部分最適化」に陥りがちな「形ばかりの性能発注」ではなく、ベンダー側での「全体最適化」が可能となる「真の性能発注」の考え方でなければなりません。具体的には、ベンダー側に意図を的確に伝えられる「概要設計書」と、ベンダー側の創意工夫と最先端技術を存分に活かせる「性能仕様書」を作成することが、「オープンイノベーション」を成功に導く鍵となります。
そこで、本セミナーでは、優れたベンダーを見つけ出し、その創意工夫や最先端技術を存分に活かしていく上での出発点となる、「真の性能発注」の考え方に基づく「概要設計書」と「性能仕様書」の作成方法について、色々な具体的事例に基づき分かりやすく説明します。
本セミナーで、以下のことの修得を目指します。
＊「オープンイノベーション」を成功させる鍵は、優れたベンダーを見つけ出すことと、ベンダー側の創意工夫や最先端技術を存分に活かすことの2点であることが理解できます。
＊優れたベンダーを見つけ出し、ベンダー側の創意工夫や最先端技術を存分に活かすには、「真の性能発注」の考え方に基づく「概要設計書」と「性能仕様書」の作成が大事であることが理解できます。
＊「真の性能発注」の考え方とは、シーズとニーズのベストマッチングに基づく「全体最適化」の考え方であることが理解できます。
＊「概要設計書」の作成方法を通じて、「現状の課題」･「課題解決方策の概要」･「課題解決により期待される効果」の3点を簡潔明瞭にまとめた「概要設計書」であれば、「オープンイノベーション」に向けた組織内の意志統一や、ベンダー側との問題意識の共有に大きな効果があることが理解できます。
＊「性能仕様書」の作成方法を通じて、ベンダー側が創意工夫や最先端技術を存分に活かして「全体最適化」を達成していく上で、ベンダー側から見て必要十分となる「機能要件と性能要件」のまとめ方が理解できます。
|
1 オープンイノベーションの効能・効果
1.1 オープンイノベーションとは？
1.2 オープンイノベーションが特に効果的な分野
①技術革新が著しい分野
②ソフトウェアが機能・性能を左右する分野
1.3 オープンイノベーションのメリット
①自社内で研究開発・設計・製造の体制を整えるよりも迅速かつ効率的
②技術革新が著しい分野での優れた製品の創出に効果的 ③ソフトウェアが機能・性能を左右する分野での優れた製品の創出に効果的
1.4 オープンイノベーションを成功させる鍵
①優れたベンダーを見つけ出すこと
②ベンダー側が創意工夫や最先端技術を存分に活かせる枠組みを作ること
③「真の性能発注」の考え方に基づく「概要設計書」と「性能仕様書」を作成すること
1.5 優れたベンダーの見つけ方
①欧米でオープンイノベーションが盛んな理由
②我が国の官公庁における「政府調達官報」を用いたオープンイノベーション
③オープンイノベーション仲介会社の活用
2 「真の性能発注」の考え方に基づく「概要設計書」の作成
2.1 「真の性能発注」の考え方とは？
①シーズとニーズのベストマッチングに基づく「全体最適化」を追求すること
②ベンダー側の創意工夫に委ねるべき「設計」には立ち入らないこと
③ベンダー側が「設計」する上で必要十分となるよう、達成を求める「機能要件」と「性能要件」をベンダー側に提示すること
2.2 「概要設計書」に記載する3項目とその作成方法
①現状の課題
②課題解決方策の概要
③課題解決により期待される効果
2.3 「概要設計書」の作成による効能･効果
①組織内での「オープンイノベーション」に向けた意志統一
②ベンダー側との問題意識の共有
③ベンダー側からの「提案書」としても効果的に活用可能
3 「真の性能発注」の考え方に基づく「性能仕様書」の作成
3.1 「性能仕様書」とは？
①実現方法を示す「設計仕様書」 vs. 実現目標を示す「性能仕様書」
②設計･製造の一括発注に欠かせない「性能仕様書」
3.2 「性能仕様書」作成上のキーポイント
①シーズとニーズのベストマッチングに基づく「全体最適化」を念頭に置くこと
②ベンダー側の創意工夫に委ねるべき「設計」には決して立ち入らないこと
③ベンダー側が「設計」する上で必要十分となるよう、達成を求める「機能要件」と「性能要件」をリストアップすること
3.3 「性能仕様書」の作成による効能･効果
①イノベーションを促進
②全体最適化を実現
③費用対効果の最大化を実現
④ベンダーとの間における責任の所在を明確化
4 零戦～「真の性能発注」による戦前最大のイノベーション事例
4.1 20世紀の世界地図を塗り替えた零戦は「真の性能発注」の賜物
①発注者は「性能仕様書（1枚のみ）」を作成して詳細設計と製造を発注
②発注者が求める性能を実現する責任を負うのは受注者
③発注者の役割は、シーズとニーズのベストマッチング
4.2 「真の性能発注」に欠かせない発注者の技術力
①シーズの把握力～最新の技術動向を把握する力
②ニーズの把握力～現状の課題を見極める力
③シーズとニーズのマッチング力～期待される効果を予見する力
4.3 零戦が成功した秘訣
①零戦に求める「機能要件と性能要件」を「性能仕様書」に必要十分に網羅
②理想的な「性能仕様書」が受注者による「全体最適化」の目標
③理想的な「性能仕様書」がイノベーションを促進
4.4 零戦の後継機「烈風」の開発失敗
①零戦と同様な「性能仕様書」で発注
②発注者が「烈風」の詳細設計に立ち入ったため「全体最適化」が破綻
③「真の性能発注」の成否が国運をも左右
5 大阪ガス（株）のオープンイノベーション
5.1 全社的なオープンイノベーション推進体制を構築
5.2 簡潔明瞭な「性能仕様書」を作成
5.3 優れたベンダーの見つけ方
①オープンイノベーション仲介会社を活用
②関係の深い外部研究機関等の伝手を活用
③自らオープンイノベーションセミナーを全国で開催
6 ボーイング737MAX連続墜落事故からの教訓
6.1 ボーイング737MAXの墜落原因はいずれも「ソフトウェア」の誤作動
6.2 これからの車やドローンなどの機能・性能を左右するのは「ソフトウェア」
6.3 目に見えない「ソフトウェア」の不具合やバグを、事前の設計審査や実機試験で確実に発見することは困難
6.4 機能・性能を左右する「ソフトウェア」の開発には、ボトムアップによる「部分最適化」ではなく、トップダウンによる「全体最適化」のアプローチが重要
7 X線天文衛星「ひとみ」～「ソフトウェア」の誤作動により空中分解
7.1 X線天文衛星「ひとみ」が衛星軌道上で空中分解するまでの経緯
①国際協力プロジェクトの「ひとみ」は打ち上げに成功
②天体観測機能確認期間中に衛星異常回転が発生して空中分解
7.2 X線天文衛星「ひとみ」が大失敗した原因
①直接的な原因は、ソフトウェアのバグとデータ入力ミス
②根源的な原因は、「性能仕様書」による「全体最適化」ではなく、従前どおりの「設計仕様書」による「部分最適化」の追求
③機能・性能を左右する「ソフトウェア」のバグを、従前どおりの「設計審査」で発見することは困難
④事前のリスクマネジメントの欠如によるダメージコントロールの失敗
7.3 大成功した小惑星探査機「はやぶさ」との対比
①プロジェクトマネジメントとしての「全体最適化」
②事前のリスクマネジメントの徹底が産んだ見事なダメージコントロール
8 ターゲット発見システム～「概要設計書」と「性能仕様書」の作成モデル
8.1 「概要設計書」に基づく「提案書」の作成上のキーポイント
8.2 某セキュリティソフトの「提案書」の記載例
①現状の課題
②課題解決方策の概要
③課題解決により期待される効果
8.3 ターゲット発見システムの「性能仕様書」の記載例
①目的
②機能要件
③性能要件
9 某セキュリティソフト～「概要設計書」に基づく「提案書」の作成モデル
9.1 「概要設計書」に基づく「提案書」の作成上のキーポイント
9.2 某セキュリティソフトの「提案書」の記載例
①現状の大問題～マルウェアを防ぎきれない！
②大問題の抜本的な解決策～某セキュリティソフト！
③某セキュリティソフトで期待される効果～マルウェアの活動を完璧にブロック！
