元技術者日記(2009/01)

名称は色々ありますが、研究・開発・技術等の部門には「技術報告書」を書いて提出する義務があるのが普通です。

仕事の成果が、直接に売り上げ・利益に繋がらないまたは、数値で表せない部門では仕事内容の報告義務はより重くかつ、継続的 に残す必要があります。

企業には、多くの商品化されていない技術の積み重ねがあると言われた事があります。「技術報告書」の積み重ねは有りますが それが技術の積み重ねとは言えません。

技術は進歩します、そして文献がけではない文字には出来にくいノウハウがあります。それは人材によって受け継がれます。 企業では、人材は流動的に活用します。その為に「技術報告書」を製品につなげる人材の確保は実質的に困難です。(2009/01/06)

定期報告が要求されている所が多いというか、普通でしょう。これは技術のみならず、スタッフ関係全体に関わる事です。

最近は、社内・部内・課内等のLANであるいはグループウェアと呼ばれるソフト・システムで公開している所が増えていると 思います。

情報の共有化が目的です。その場合は、機密情報とグループ内共有情報との区別が明確である必要があります。

公開レベル・参照レベルを設定して、参照権限をコントロールできるソフトでシステムを作る有用性がここにあります。(2009/01/16)

色々なケースがありますが、ここでは他社から出された図面・仕様等を検討する場合を考えます。

ずばりコストを含めた要求の実現可能性を検討する作業です。この様に言えば簡単に聞こえますが、企業の製造の特に営業サポート 技術者は受注する事が目標です。

そのため実現可能性の検討とは建前で、現実は如何に実現するかを考えに考えます。ギブアップは充分にありえますが、それは やむを得ないというよりは受注失敗を意味します。

この場合のデザイン・レビューは、製品のユーザーでの検討中や見積もり段階で発生するのが多いです。従って不明瞭な部分を 含む事が多く、マニュアル化が難しく技術者の能力と柔軟性が表面に出ます。(2009/01/26)