筆者は前職のエンジニア時代に設計・開発業務の一部としてプログラムを組んでおりました。プログラミングの経験を通じて、明細書および特許請求の範囲は、「自然言語で構築するプログラム」のようなものであるとつくづく感じます。
決して比喩的な表現ではなく、プログラムを組む感覚と酷似しているのです。
例えば、プログラム経験のあるかたなら理解いただけるかと思いますが、細部のコーディングに気を配る作業の繰り返しを通じて、例えば、ある部分のコードを修正した場合、その修正が他のコードのどの部分に影響が出るかを常に気を配らなければならないというバイアスが意識の中に働きます。そして、プログラミングに慣れてくると、その修正の影響がプログラムのどこに及んでいるのか、どこを修正しなければならないのか、という当てが瞬時に付いたりします。
明細書も同じです。ある部分を追記・修正した場合、明細書の中のどの部分に付随して影響が出るのか、どの部分を修正しなければならないのかを把握しなければならず、明細書の作成に慣れていれば、その部分をすぐに探し出すことができたりします。
他にも、プログラムと明細書には、以下のような共通点があるように思います。
構造化プログラミング
プログラムでは、ちょっと古いかもしれませんが「構造化プログラミング」のように、全体の動作のコードを書き、その中で多用したり汎用性のある処理をサブルーチンや関数として別の部分に書き、・・・というように階層的に記載したりします。
明細書も同様で、最初に全体システムの構成、そのシステムの中に含まれる装置の構成・機能・動作、というように階層的に記載していきます（※１）。
ロジックの矛盾
プログラムは、どこか一カ所にでもロジックに矛盾があると動きません。
明細書でも、どこかの技術内容・説明の中に論理的矛盾があると、その発明の実施ができないとして「実施可能要件違反」を打たれる場合があります（特許法36条4項1号）。
表現の統一
プログラムは、どこか変数などの書き間違いがあるとうまく動きません。
明細書でも、同じ動作・事象について異なる表現で記載すると、著しく判読性が低下します。例えば、「・・・か否かを判定する」「・・・か否かを分析する」「・・・か否かを解析する」「・・・か否かを判断する」など、明細書のあちらこちらで、同じ処理を説明するのに異なる単語を用いると、文章の読み手の理解度に影響を及ぼしてしまい、最悪の場合には、特許権の成否や権利範囲の解釈にも影響を及ぼしてしまうことにもなりかねません（※２）。
したがって、プログラムで変数表現を統一する（当たり前のことですが）のと同じで、明細書でも、同じ動作・事象については表現を統一することが求められます。
バグの内在
プログラムにバグが内在していると、今まで稼働していたシステムに不具合が生じて利用者に甚大な影響を及ぼすことがあります。
明細書にも論理的な誤り等があると、特許権として成立していたものが、無効理由（例えば実施可能要件違反、明確性要件違反（特許法36条6項2号）等）を内在することによって、特許権の消滅（無効）に追いやられることもあり得ます。
脆弱性
プログラムに脆弱性があると、その抜け穴に付け込んでハッキングされるリスクがあります。
明細書や特許請求の範囲の記載に不完全な部分があると、その抜け穴を利用して特許権を巧みに回避した模倣を許してしまったりします。
感情表現がない
プログラムに感情表現・意見の表明（メモとして付与するコメントを除きます）は要りません。
明細書はどうでしょうか。たまに感情表現的な記載や強調的表現を見かけることありますが、基本的には、装置の構成、機能、動作、効果を粛々と書き連ねるものです。この点で、感想文、小説、新聞記事、論文などとは一線を画していると思います。
いがかでしょうか。プログラムのコーディングと、明細書・特許請求の範囲の作成とはとても似通っています（と個人的に感じています）。その点で、論理的思考力、構成力などの素養を持ったかたが明細書の作成にはとても向いているかと思います。筆者自身にとっては前職のプログラム経験が現在の特許の業務と相性が良かったようです。
（※１）あくまで筆者の明細書の書き方であり、これが正解というわけではありません。
（※２）後々の補正の幅を広げるために、あえて異なる表現をサポートしておく、というテクニックはあり得ます。
Follow me!
