発明実務のジレンマ

ここしばらく、製品のV1.0締め切りだったのでバタバタしていました。
直前に急遽他のテストの要望が入ったり、論文直前期にこうなってしまうと何もできなくなるので、来年はこの時期にこうならないことを願うばかりです。
# もちろん、まず短答に受かれ、と…


開発が一段落したフェーズに入ると、今度は開発で出てきたアイデアを特許として緊急出願する準備に入ります。開発前に仕様をベースに出願準備をしていますが、最初の仕様ではうまくいかなかったり、お偉いさんの一言で仕様が変わったりすることがあるためです。

知財部門の人は「苦労したところには必ず進歩性がある！」と何でも出願OKにしますし、技術者は「何年も前からあるアイデアを実装しただけ」と出願する手間を増やすことを嫌います。ここだけでもうちの部門がイケてなさが出てますが、この状況は比較的ありがちなジレンマですよね。

ソフトウェアの開発はLEGOのようなもので、ごくごく簡単なモジュールを組み合わせて、最終的に一つの製品に仕上げます。それだけに完成品を見る知財の目からは発明があるように見えて、モジュールごとに作っている技術者の目からは発明が見えづらいということに陥りがちです。もちろん、知財には技術的視点が、技術には知財的視点が欠けていることも原因です。
リーダーや管理職がその製品のアーキテクトと特許の双方をそれなりに理解していれば少しは話が違ってくるのですが、「モノを作ってなんぼ」と言い切る人が多いのでは全くそうはいきません。口先で「特許が重要！」という人はいますが、そういう時間を取ろうとはしない人の方が多いです。


私としては、ロジックだけはきっちりしておいて出願優先というスタンスでいます。出さなくて後願にやられるより、出してから先願が見つかる方がまだマシですからねぇ。

そのためにも、LEGOの完成品が単にブロックを組み合わせに見えず、どこに発明があるかを見つけ、説明できることが必要なわけですが、これがまた難しい。技術側から知財を始めると最初に当たる壁であり、どこまでも考え続けなければいけないところなんでしょうね。

そして、それを超える努力が弁理士試験上の実力をつける上ではほとんど役に立たないというところが、個人的には最大のジレンマです…。