渉外の引き継ぎは順調、とか書いていたんだけれども。
実はそんなことは全然なくて、あら勘違い〜という状態だったことが判明したここ数日である。同じ案件を同じように担当として取り組んできたつもりでいても、同じものが見えているわけではないんだなぁ(人が違うんだから当然なんだが)、と反省しているところ。
これがまあ、私の前の担当者と私の間ではほとんど齟齬がなく意識無意識の共有ができているため、特に改めて引き継いだ覚えもないし、そんなもんだろうという思い込みもあって、今回の引き継ぎから漏れる漏れる。特に社内調整の部分と全体の方針立案のところが痛い。・人がつけた段取りに乗っているだけでは自分で段取りする力はつかない。
⇒失敗しても自分でやってみる機会を持たないとダメ
・無意識のうちにやっていることは、可視化しないと人には伝わらない。
⇒暗黙知を形式知に
・自分が人から引き継いでいないことは、誰しも当然やるものだという(無意識の)思い込みが発生しやすい。
⇒人に引き継ぐ対象になりにくいので要注意。
おもわず、自分が担当していたときに、特許係争案件（受側）が発生した場合どうするのかということを、通常モードで考え飛ばさずに順を追ってみた。
１．まず、対象特許を解析担当（特許技術者）に渡して、ざっと見てもらい、感触を報告してもらう。
a)『感触』なので、この特許はなんの関係なのか、当社の製品のどこに関係しそうなのか。
遠いかもしれないが、相手が言ってくるならこのあたりかな、という感覚レベルで。
b)特許と被疑製品との距離感も。例えば
c)技術論争するならポイントになってくるのはこのあたり、というのが分かるならそれも・ドンピシャ踏みそう
・明細書に書いてある発明の実態とは違うがクレーム文言だと当たりそう
・全然違うけど無理矢理こう言ってくるかもしれない
・何が関係してるんだかさっぱりわからない
この感触つかみは、本当にざっと読んで、これまでの製品知識を動員して関係しそうなところに当たりをつけ、不明なところがあれば開発に聞き取りをして、という程度で完了する。詳細な比較検討まではやらないので、せいぜい１日〜２日で。にっこり笑って『明日までにざっくり聞かせてくださいね』とやる。だって同じ部内だし。
２．１の報告を口頭ベースで受け、ポイントを確認する
大体のところを頭に入れたら、自分でも対象特許を読んで本当にそんな風に書いてあるのかを確かめる。人任せにしておくと、読みが甘かったり、誤解していたり、距離感が間違っていたり、ということが時に起こるので、複数人でやった方がよいし、ポジション判断をしていくには自分で読んでちゃんと理解しておく必要がある。
ものによっては、１を頼んでいる間に自分も読んでおくこともあるし、技術的に難しい場合は（特に外国特許だったりするとダブルで難しくて時間がかかる）、ざっと報告を聞いてから読んだ方が効率がよいのでそうすることもある。バイアスを避けるためには、できるだけ並行して「さら」の状態から読んだ方がよいが、渉外担当をやりながら特許の読み込みをやるのは時間的に結構厳しいことが多い。
３．今後の方針と大体のスケジュール感を相談する
１と２で、この案件がどういう『スジ』のものかという感触が技術担当との間で一致するので、それに沿って、どういう方針で臨むかを大体決める。というか、どんな感じで進みそうかを予想する、といった方が正確かもしれない。方針というか進み方にも色々パターンがあるが、例えばこんな感じ。
立てた方針に沿って、最初の回答の方向、時期、それに対する相手の回答（内容と時期）の予想、それに対するこちらの回答、とシナリオを立てていく。大抵、この手のやりとりは、回答期間が１ヶ月程度というのが常識なので、そこを見込んで、大体１年くらいはスケジュールを立てていく。そのくらいで目処が立ってくるといいね、とか、そのくらいで消えてくれるといいね、とか。（消えてくれるのがどんなケースでもベストなんだが）・技術論争をガッツリやって、相手が消えるのを狙う
・低額和解を目指す
・適当なところで落とすことを目標に、そこまでのストーリーを立てる
・時間を稼いでその間に設計回避する
・時間を稼いで特許が切れるのを待つ
４．情報を収集する
３で立てたシナリオに沿って、こちらの回答に必要になる情報を収集する。情報としては、例えば、
必要に応じて、事業部門と打ち合わせをしたり、情報提供の依頼をかけたり、開発に特許を読んで検討してもらったりする。相手にクレームチャートを要求した上で進めることもある。・関係製品の型番
・製造販売の台数、売上金額
・関係製品の構成、処理の方法の詳細
・クレームと被疑製品の対比
いずれにしても、シナリオ上必要になる時期までに、必要な情報が手元に集まるように、適宜期限を設定し、リマインドして進めていく。
５．初回の回答を作成する
シナリオに沿って、決して書きすぎないように、言わなくても良いことは言わずに、たいていの場合設定されている期限ぎりぎりに回答する。期限が短い場合は、調査するのでと言って（勝手に）延期した期限を通知しておくこともよくやる。
どんなケースでも、大抵最初の警告状は特許の番号とぼんやりした製品カテゴリが特定されている程度なので、当社の製品のどこが権利範囲に入ると考えているのか示せという回答になることが多い。それを示すのは特許権者の責任なので、クレームチャートを要求するところから始めるわけだ。クレームチャートを要求した場合、それを受け取るまでは詳細な解析には入らずに技術サイドは一旦停止することが多い。
６．クレームチャートの検討とシナリオの修正
要求したクレームチャートが出てきたら、技術解析に回す。初回の感触つかみよりは詳細に見てもらうが、まずはポイントになる構成要件を特定することを目的とする。技術論争するにしても、揚げ足取りのようなことをやっても仕方がないので、争点をいくつかに絞っておきたい。
争点が絞られたところで解析担当と打ち合わせをして、シナリオを練り直す。技術論争の方向性、勝算、相手の反応の予想などの精度が上がってくるので、シナリオの練り直しや微調整が必要になってくる。が、あまり大きく軌道修正する必要まではないことが多い。
シナリオを固めた段階で、事業部門と打ち合わせをし、認識をあわせて、方針とシナリオに了解をもらっておく。
７．適時対応
シナリオができてしまえば、それに沿って回答を出し、相手から返ってくれば、予想の範囲内かどうかを検証し、多少の見込み違いがあればシナリオを微修正し、修正したシナリオに沿って回答を出す、というサイクルを回していくことになる。ここまで来ると、技術論争のネタが尽き、和解の局面に入ってくるまでは、あまり深く考えることもなくルーティン作業に近くなる。
などということを、特にチェックリストとか作っていたわけでもなく、手順書に落とし込むでもなく、ごく自然にやっていたので、あまりやり方のグランドデザインとして伝わっていなかったみたい。このまま手順書にしてしまおうかしら、これ。
