クラウドベースのグループウェアや業務改善サービスを軸に「サイボウズ Office」シリーズや「kintone」などを手掛けるサイボウズ株式会社。
今回はサイボウズ株式会社 開発本部 製品戦略チーム/OSS推進チーム の上池 睦 氏にお話を伺いました。
知財との出会い
出会いは大学生の頃です。大学は法学部だったんですけど、そこで専門性をつけたいなと思って。そういった中で、映画や音楽が好きで「著作権」だとか、SFやITに興味があったこともあって「特許」というものを意識していて、なんとなく知財の勉強をはじめました。
そのまま東京理科大学専門職大学院のイノベーション研究科知的財産戦略専攻に進学して、知財の実務や活用手法などを学びました。
当時学生の自分としては、ビジネス的な観点が入ってくるので、ちょっとハードルは高いと感じましたが、身につくスキルの幅が広がるだろうなと思いながら大学院で学んでいましたね。
サイボウズの特許担当へ
大学院を修了して、就職活動の舵をIT系にきったところですぐにサイボウズに内定を貰い就職しました。
ちなみに、1日で3次面接まで急ピッチで進む選考プロセスでびっくりしましたが、面接を受けた感じも相性がよさそうだったのですぐに入社を決めました。
結果、辞めずに９年目になるのでめっちゃ相性よかったなという感じです(笑)
現在は開発本部製品戦略チームで特許担当をしています。
サイボウズ入社時は特に配属みたいなものは決まっていなかったのですが、私自身文系の出身だったこともあり、専門的な技術を全く知りませんでした。
そんな自分がどのようにして特許を扱うのかと考えたときに、まずは技術の知識を身に着けようということに思い至りました。
そして、配属面談で開発系の部署を希望した結果、クラウドサービスのインフラシステムの品質保証を行うチームに配属になりました。そこで4年くらい、テストエンジニアを担当していました。
そこでは、インターネットの仕組みがどうとか、データのバックアップをどうやっているのかという、Webサービスそのものをリアルで見ながら業務をして知識をつけることができました。
サイボウズはクラウドサービスを自社開発しているので、その仕組みが正常に動くのか、データ消失しないかといった、不具合がないかといったことを確認する業務を行っていました。
4年目に法務との兼務希望を出して、工数半々くらいで両方の仕事をしていた時期がありました。契約書対応などの業務もやりながら、当時は法務が特許、商標、著作権といった知財を全部見るというような体制だったので、知財全般も扱っていました。
その後、エンジニアと特許部門の距離が近いほうがいいという話になり、特許については私が現在所属する開発部門の管轄になりました。
特許の管轄が移り、製品開発チームと距離が近くなったことで、開発の方針がこうだから先にこの権利を抑えておこうというような、”逆算して動く”みたいなことがやりやすい体制になりました。
実際、開発部門の将来像や長期的な事業戦略といった時間軸に目線を合わせながら、特許を取得する動きができ始めたと感じています。
会社の将来像を逆算して導き出す知財戦略
やはり知財部門に求められるのは、会社の描く将来像やビジネスプランを反映した形で特許出願をするといったことで、そのための戦略が非常に重要になります。
開発や会社の方針について、時間軸でいうと5年スパンとかの長期的な話は、経営層が中心に行いますし、3年後くらいの将来像については各製品のマネージャー・部門長等が中心となって検討しています。
私の立場としては、各製品のマネージャーの集まりに入って実際に知財戦略をプランニングする感じです。
特許担当がそこに入ることで、各製品のマネージャーはあまり特許のことを考えず、開発プランの検討に専念できることになります。
各マネージャーのやりたいことを吸い上げて、我々数人の特許チームで、各製品でどういう特許のとり方をしたらいいかということを具体的に検討して、各製品の責任者に共有します。
取得する特許が大まかに決まったら、弁理士の先生を交えてさらに発明のブラッシュアップを行うという進め方になります。
特許取得をするにあたって、どういった目的で、どのあたりの分野や範囲で特許を取るかといったことは、まずは社内の特許チームだけで検討しています。
たとえば、この範囲で権利化されたら他社が嫌がるだろうから、「権利範囲が少し狭くなっても取る」というような判断をすることもあります。
発明発掘からみえる新しいアイデア。自分たちの製品の延長線上に何があるのか
出願権利化も我々の重要な役割ですが、発明発掘にも力を入れています。弊社では発明発掘のパターンが２つあります。
一つ目は、弊社のエンジニアが年に一度行っているハッカソン（特定のテーマや問題解決のため、プログラマー、プロジェクトマネージャーなどが集まり新しいアイデアやプロジェクトを生み出すイベントのこと）です。そこでは、既存製品だけでは解決できない課題を解決できないかと、さまざまなアイデアが出てきます。その中で出てきたアイデアが特許になり得るかを検討して、エンジニアにヒアリングしに行ったりします。
そしてもう一つは、先行技術調査や他社製品の調査をしていく中で出てくる、「この辺りで特許を取ると良さそう」といった特許担当目線のアイデアをベースに、エンジニアに声をかけてそれを製品に落とし込むためのブレストなどを行ったりします。
自社がどういうことをしようとしているかのイメージを自分の中にも持っておくことで、日頃の調査においても、なんとなく特許を取った方が良い方向性が見えてきます。
自社の見ている方向と、普段の特許調査の際に目にする、特許文献に書かれているユーザーが抱えている課題を把握しておくこと、そして、常に課題を探すという姿勢でいることを意識しています。
たとえば、自社のプロダクトと同じ課題を感じているプレイヤーは誰で、今の他社製品だとどうなっているかといったこともみたうえで自分たちの戦略を練ります。
3Cや5Forceなどの分析を、特許情報に置き換えているようなイメージです。
あとは、調査をしているときに、今までおさえていなかった企業がぽっと出てきたりもしますね。その企業が何らリリースをしてなかったとしても、企業の動きが特許情報に現れてくるので、それは特許からしか得られない情報だと感じています。
調査に対する考え方とツールへの要望
私の調査に対する思想としては、検索式を書けない人でもちゃんと調べられるというのがいいと思っています。
プロダクトに関する会議をしているときに、クイックで欲しい情報を探せたらいいなというのが理想ですね。
一方で、コア技術の侵害予防調査など、絶対に漏らせないという状況では、プロに依頼したいですね。検索式を組んで、調査して、さらに検索式を練り直してというのは、すごく専門性の高い分野ですので。
TokkyoAiさんのツールだと可視化までが早いので、技術がどの産業で活用されているかというのをサッと出してくれるという点について良いなと思います。
知財情報を活用しようとしている方へ
知財情報を見るのは楽しいですし、油断すると数珠つなぎのように色々と見ていってしまいますが、それはあくまで手段であることを見失わないようにと考えています。
ツールを使っていると色々な情報が目に入りやすいですが、その調査にどのような目的があって、そのためにどの情報を活用しなければならないかが頭に入っていないと、会社にとってあまり意味のない調査や分析結果になってしまいます。
知財情報はリッチである反面、情報が多いので、とくに知財調査を面白いと感じる方ほど、その点に気を付けて知財情報の活用を心掛けると良いと思います。
