
自社のコア技術の発信 普通の組織をイノベーティブにする処方箋 (その32)


1. コア技術の未活用部分をどう見つけるか
2. コア技術を五感で感じてもらえる場の提供
3. 技術ショールームは、自社技術を「そのまま感じてもらう」場
4. きれいすぎる展示が技術ショールームの問題
5. 技術ショールームは、『ひっくり返されたおもちゃ箱』の実現
続きを読むには・・・
この連載の他の記事
現在記事
「技術マネジメント総合」の他のキーワード解説記事
もっと見る味覚 普通の組織をイノベーティブにする処方箋 (その154)
現在、イノベーション実現に向けての「思考の頻度を高める方法」を解説していますが、そのための2つ目の要素「同じ一つの行動をするにしても思...
現在、イノベーション実現に向けての「思考の頻度を高める方法」を解説していますが、そのための2つ目の要素「同じ一つの行動をするにしても思...
思考の構成要素 普通の組織をイノベーティブにする処方箋 (その59)
前回まではKETICモデルの2つ目、経験(Experience)の解説をし、また前回は経験(Experience)と他の要素、すなわ...
前回まではKETICモデルの2つ目、経験(Experience)の解説をし、また前回は経験(Experience)と他の要素、すなわ...
製品設計:ミス防止対策(その3)
【製品設計:ミス防止対策 連載目次】 1. お客様目線で行う製品設計、「未然防止の品質管理」 2. 過去のトラブル、フィー...
【製品設計:ミス防止対策 連載目次】 1. お客様目線で行う製品設計、「未然防止の品質管理」 2. 過去のトラブル、フィー...
「技術マネジメント総合」の活用事例
もっと見るマトリクス体制での品質保証2 プロジェクト管理の仕組み (その31)
前回のマトリクス体制での品質保証1に続いて解説します。品質計画は、製品開発に必要となる手順やリソースが誰によっていつ適用されるかを明確にした個別製品の開...
前回のマトリクス体制での品質保証1に続いて解説します。品質計画は、製品開発に必要となる手順やリソースが誰によっていつ適用されるかを明確にした個別製品の開...
ソフト開発の手戻りを小さくするには プロジェクト管理の仕組み (その8)
前回のその7:ソフトウェア開発スケジュールと結合テストに続いて解説します。 この数回はプロジェクト管理をテーマにお話ししていますが...
前回のその7:ソフトウェア開発スケジュールと結合テストに続いて解説します。 この数回はプロジェクト管理をテーマにお話ししていますが...
設計部門の仕組み改革(その2)
【設計部門の仕組み改革 連載目次】 1. システムやツールの導入を伴う設計部門の仕組み改革の進め方 2. 設計部門の仕組み改革、事例解説 3. ...
【設計部門の仕組み改革 連載目次】 1. システムやツールの導入を伴う設計部門の仕組み改革の進め方 2. 設計部門の仕組み改革、事例解説 3. ...




