astamuse Lab

astamuse Labとは、アスタミューゼのエンジニアとデザイナーのブログです。アスタミューゼの事業・サービスを支えている知識と舞台裏の今を発信しています。

システムテスト自動化カンファレンス2017に登壇しました

f:id:astamuse:20171213181216j:plain

こんにちは。nishikawaです。

12月10日 日曜日に行われたシステムテスト自動化カンファレンスにて、弊社の転職ナビチームの事例紹介をしてまいりましたので、レポートも含めてご報告させていただきます。

資料配布

会場の雰囲気

会場には自動テストに課題のある方や、コミュニティの方など色々な方がおり、質疑応答なども含め白熱したイベントでした。

発表、そして登壇を終えての感想

そんな中、弊社の転職ナビチームがやっているテストや課題などの事例紹介を発表させていただきました。

f:id:astamuse:20171213181132j:plain

始まる前は人生初登壇ということもあり、とても緊張しておりましたが、発表が始まった後は会場の皆様と一緒になって冗談を交えながら楽しく発表することができ、なんとか終わらせることができました。

質疑応答でも、弊社の事例について沢山ご質問いただき、初めての登壇にしては成功だったなと満足することができました。

今後について

今後も転職ナビチームでは、システムの自動化を推進し効率良く開発できるように邁進したいと思います。

そうした努力の末、転職ナビの品質を向上させ、より良い転職ができるサービスという形で様々な方にお返しできればと思います。

それでは。

特許とその制度について 出願後~権利取得まで

お久しぶりです。主に特許関連のデータ処理を担当しているBTと申します。 前回までの3回で、特許出願についてご説明いたしました。 今回は出願後の特許取得までの流れについてご説明したいと思います。 宜しくお願いいたします。

出願公開

特許出願を行うと、その出願の日から1年6月経過するとその特許出願の内容を記載した公報が特許庁より発行されることにより、広く一般に内容が公開されます。 出願公開は、出願人以外の会社等に出願された発明を広く周知するために行われています。

出願公開が無いとするとどうなるでしょうか?

特定の発明に基づいて事業化して商品等を販売している場合に、その発明が他者によってすでに特許出願されていて事業開始後に特許になったとすると、その商品は販売できなくなり事業が継続できなくなることが考えられます。

また、すでに他者である出願人によって出願されている発明を知らずに、同じ内容の発明について研究開発等に重複投資をしてしまうことで、最終的に事業化できずにその投資が無駄になってしまうことも考えられます。

このようなことがあると、新しい発明に基づいて事業を開始したり、新しい発明に投資をしたりすることに及び腰になってしまうことが考えられ、発明を推奨する特許法の目的にそぐわない結果となってしまいます。

そこで、全ての出願(出願から1年6月経過する前に取り下げられたものなどは除く)について、その内容を公開することで出願人以外の第三者にどのような発明が出願されているのか、あるいは今後どのような発明が特許になる可能性があるのか予測できるようにしています。

では、なぜ特許出願から1年6月経過した後に出願公開されるのでしょうか? 上記の話だけですと、出願後すぐに全て公開するようにしてしまえば一番良いように思えます。

すぐに公開しない理由は、出願人の利益を守るためです。 出願人は、特許出願後に元の出願に基づき、内容を高度化したり足りない部分を補足したりして優先権の主張をした出願をすることが出来ます。これの期限が元の出願から1年とされており、優先権の主張のための証明書の提出などが元の出願から1年4月まで認められています。このような手続きを行うことが出来る期間の前に出願内容が公開されてしまうと、悪意のある第三者によって公開された内容を元に別の出願がなされて、出願人が行うことの出来る手続きが妨害されてしまうことが考えれます。

このようなことから、出願人と第三者の利益を調整した結果、出願から1年6月経過した後に公開されることになっています。

なお、出願人が何も手続きをしなければ出願から1年6月経過した後に出願公開がなされますが、出願人が申請することで出願から1年6月経過する前であっても早期に公開されることがあります。

審査(実体審査)

審査請求

特許出願をすると自動的に審査が行われて、特許になるかどうか決まるというわけではありません(過去にはそういう時代もありましたが・・・)。 特許出願した内容について、特許庁に審査をして貰うためには、特許出願とは別に審査請求の手続きを行う必要があります。 審査請求が可能期間は、特許出願から3年以内となっています。

出願人は、特許出願の時にはありとあらゆる関連する発明をカバーしようとしたり、漏れがあるといけないと考えたりして、出願書類にいっぱい記載してしまいがちです。 そこで出願人には、特許出願の後3年の期間を利用して出願した発明について精査し、権利化(特許取得)を目指すべきか否かを熟慮することが求められます。

出願自体はさほどの費用は掛かりませんが、審査請求には請求項の数に比例した金額+αの費用がかかるため、請求項の数によってはとても高額になります。 このため、出願当初の内容から請求項を削除したり審査請求そのものをしないことで、審査を行う価値があると思われるものに絞り込まれることになります。

なお、特許出願後3年以内に審査請求をしなかった場合は、その特許出願は取り下げたものとして扱われます。

ちなみに、意外に思うかもしれませんが審査請求は出願人でなくとも可能です(もちろん、出願人が審査請求にかかる費用を出さない場合は、自分で負担する必要がありますが・・・)。 これは、出願人にとって審査請求をして特許にする価値がなくても、第三者から見たらその価値がある場合があるからです。 このようなケースで特許になった場合でも、原則として出願人が特許権者になるところは変わりませんので注意が必要です(権利を出願人から譲渡された場合は、自分が特許権者になることができます)。

最初の拒絶理由通知

審査の結果、何ら指摘を受けることが無いということは滅多ありませんので、特許庁の審査官より拒絶理由通知が届きます。

出願人は、拒絶理由通知の内容を精査し、指定された期日までに意見書、または補正書を特許庁に提出します。 指摘された期日までになんら応答をしなかった場合はそのまま拒絶査定になってしまいます。

意見書は、主に審査官が指摘してきた拒絶理由について納得できない場合に反論を提出するもので、審査官が指摘してきた拒絶理由が存在しないことを説明することになります。 補正書は、審査官が指摘してきた拒絶理由に対して、出願書類の内容を変更して拒絶理由が存在しなくなるようにする場合に提出します。場合によっては、追加で意見書も提出して補正書の内容について補足説明などを行うことも出来ます。

なお、意見書で反論する場合を除いて指摘を受けた拒絶理由は全て補正書により解消している必要があります。 解消していないと審査官に判断された場合は、拒絶査定となります。

最後の拒絶理由通知

出願人が最初の拒絶理由通知に対して適切に応答し、指摘された拒絶理由をすべて解消していても、補正書により出願書類を変更したことによって新たに別の拒絶理由が生じる場合があります。 このような拒絶理由のみを出願人に通知するのが最後の拒絶理由通知となります(審査官より届く書類に、「最後の拒絶理由通知」と記載されていますので、最初の拒絶理由通知で無いことがわかるようになっています)。

最初の拒絶理由通知で通知した拒絶理由が残っていれば拒絶査定となるので、それ以外の拒絶理由が存在していた場合、すなわち最初の拒絶理由通知において通知し忘れていた新たな拒絶理由が見つかった場合は、2回目の拒絶理由通知であっても最初の拒絶理由通知として扱われます。

出願人が取るべき応答は最初の拒絶理由通知と同様なのですが、最初の拒絶理由通知の時と異なり指摘を受けた拒絶理由を解消させると共に出願書類の内容を変更することによって新たなに別の拒絶理由が生じることも許されないため(生じた場合は拒絶査定となります)、慎重に対応する必要があります。 場合によっては、確実に拒絶理由が存在しなくなるように大幅に請求項を削除したりするなどを対応をすることになります。

特許査定または拒絶査定

審査官による審査と拒絶理由通知とそれに応答する意見書や補正書の提出を経て、最終的に審査官は特許すべきか否かを決定します。 特許すべき場合は特許査定を、そうでない場合は拒絶査定を出願人に対して出すことになります。

拒絶査定を受けた場合において、その後出願人が取り得るべき手段については次回以降に説明します。

特許登録

特許査定を受けても、特許になったわけではありません。 出願人は、特許査定のあと速やかに所定の特許料を納付しなければなりません。 これが納められて初めて、特許庁により特許番号が振られて新たな特許として登録されることになります。

なお、特許料の納付をしない場合は、特許として登録されず、特許権を取得することは出来なくなります。 特許料はかなり高額になるため、このときになって金額の大きさに驚いて特許料を払わないことで結局特許権を取得しないケースもあるようです。

特許掲載公報

特許庁により特許として登録された場合は、その内容について速やかに特許掲載公報が発行され、特許となった発明について広く周知がなされます。

なお、特許出願と同時に審査請求をした場合や早期に審査請求をした場合などは、出願から1年6月よりも前に特許として登録されることがあります。 このような場合は、出願公開の公報よりも先に特許掲載公報が発行されることになります(この場合は出願公開は法律上不要なのですが、出願当初の内容が知りたいといったニーズがあるため、出願公開の公報も特許掲載公報の発行の後で発行する運用がなされています)。

まとめ

以上、出願後から特許になるまでについて説明をしてきました。次回は、審判について見ていきたいと思います。

最後になりましたが、 アスタミューゼでは現在、エンジニア・デザイナーを募集中です。 興味のある方はぜひ 採用サイト からご応募ください。

参考にした資料など

PageSpeed Insightsのスコアを上げるために具体的にやったこと

f:id:astamuse:20171206103549p:plain こんにちは。デザイン部でフロントエンドエンジニアをしているkitoです。今回は、Webサイトの高速化を行う際にひとつの基準になりえるPageSpeed Insights について、主にフロントエンドで行える具体的な施策とともにご紹介したいと思います。

PageSpeed Insightsとは?

PageSpeed Insightsは、Googleが提供しているWebサイトのパフォーマンスをスコア化して具体的な改善案を提案してくれるサービスです。スコアの範囲は0~100ポイントで、85ポイント以上が良好とされています。85ポイント以上のスコアであったとしてもPageSpeed Insightsは継続的に改良されているので、定期的にチェックすることをお勧めします。試しにhttps://developers.google.com/speed/pagespeed/insights/に行き、任意のサイトのURLを入力してパフォーマンスを計測してみてください。何の対策もされていないサイトであればスコアが85以下で、ステータスが「Poor」か「Needs Work」になっているかと思います。このスコアは、体感的なサイトパフォーマンスとは必ずしも一致しませんが、PageSpeed Insightsで提案される改善案は具体的で取り組みやすく、筋が良いものが多いのでスコア改善に取り組む価値はあると思います。
スコア下に「適用可能な最適化」という具体策が下記のように列記されているはずです。(対応済み項目は下部にある「適用済みの最適化」に表示されます)

  • 画像を最適化する
  • ブラウザのキャッシュを活用する
  • スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する
  • 表示可能コンテンツの優先順位を決定する
  • 圧縮を有効にする
  • JavaScript を縮小する

各項目にある「修正方法を表示」をクリックするとプルダウンで、修正すべきコンテンツが表示されます。
例えば、「画像を最適化する」だと圧縮すべき画像の一覧が「〜.jpg を圧縮すると 154.4 KB(71%)削減できます。」という形で表示されるので具体的なアクションが取りやすいです。 私が開発・運営に関わっているサイトでは、対策以前はモバイル・パソコンのスコアはそれぞれ60前後でしたがPageSpeed Insightsに提案された対策を可能な範囲で行うことで、85~90以上のスコア「Good」で安定するようになりました。 では具体的に何をしたのかを見ていきたいと思います。

画像を最適化する

「画像を最適化する」は要するに画像を圧縮しましょうということです。画像圧縮は、gruntやgulpのようなタスクランナーに任せるのが最適だと思います。
ただ、grunt-imageのようなプラグインを使った場合、何も考えずにjpeg画像を圧縮すると、PageSpeed Insightsが求める圧縮率に達しないことがあります。また過度に圧縮して画像が潰れてしまわないように注意したいです。optimizerでjpegRecompressを追加し、色潰れが起きないように目視でクオリティーを調整する必要があると思います。

ブラウザのキャッシュを活用する

「ブラウザのキャッシュを活用する」は、Expiresヘッダーを指定してブラウザキャッシュを活用することが主になりますが、長期間開発・運用されているサイトだと、それ以前に不要なファイルを削除するプロセスが必要かもしれません。私が運用に関わっているサイトでは、使われていない広告タグが複数あり削除するだけでスコアは上がりました。その上でサーバーサイドでExpiresを1週間以上に設定し、画像やJS、CSSファイルの末尾にパラメータをつけアセットの更新を確実に行えるようにしなければなりません。
インライン画像やCSSにパラメータを付与するのはサーバーサイドのスニペットで対応して頂き、フロントエンド側では、htmlにロードされているJSとCSS内の画像URL末尾にパラメータを付与しました。その際使ったのが、grunt-asset-cachebusterというgruntプラグインです。gruntでbuildするタイミングでgetTimeからパラメータを作成し、CSS内の画像URLにパラメータを付与しました。弊社の開発体制では、ステージング環境にdeployされるタイミングでgruntがbuildされるので、そのときパラメータが付与されることになります。

スクロールせずに見えるコンテンツのレンダリングをブロックしているJavaScript/CSSを排除する

この項目は、JavaScript/CSSを出来るだけひとつまとめる and JavaScriptを非同期で読み込むように対策することになります。 JavaScript/CSSをひとつまとめるのは、webpackやgrunt/gulpで基本的に対応できると思います。

CSSファイルを出来るだけひとつにまとめることが大事ですが、まとめきれないCSSが小さいサイズ(具体的には14KB以下)であるなら、htmlにインライン化する方法もあります。
だだし、たとえCSSをひとつにまとめたとしても、その最後のCSSがレンダリングをブロックしている状況は変わりありません。このCSSを非同期で読み込めば良いと考えるかもしれませんが、そうするとCSSが読み込まれる前にhtmlがレンダリングされるのでCSSがあたっていないhtmlが一瞬ちらつくことになってしまいます。
この対策として考えられるのが「クリティカルCSS」という考え方です。ちらつきがおきないようにファーストビューの小さなCSSだけをインライン化して先に読み込み、その他のCSSは非同期で読み込みます。grunt-critical を使えば自動的にクリティカルCSSを作成できます。しかし、留意すべきなのはファーストビューに必要なCSSだけだとしても、サイトによっては巨大になることがしばしばあるでしょう。また、クリティカルCSSの作成を自動化したとしても、レイアウトの異なるページが複数あるとbuildタイムが肥大化するのも厄介な点です。弊サイトでは、他の対策をしてスコアが85以上になったのでクリティカルCSSを採用するまでに至りませんでした。

JavaScriptの非同期読み込みに関しては、まずscriptタグにasync属性やdefer属性をつけて読み込む対策が考えられます。async属性やdefer属性をscriptタグにつけると、JavaScriptを非同期に読み込むようになりレンダリングをブロックしません。注意点としては、scriptタグを読み込む順番を担保する必要があるときはasync属性でなくdefer属性をつける必要があります。 またasync属性やdefer属性に対応していないブラウザを考慮する必要がある場合は、下記のようにcreateElementでscriptオブジェクトを作成してDOMに追加する方法もあります。

var s = document.createElement('script');
s.type = 'text/javascript';
s.src = 'https://◯◯.js';
document.getElementsByTagName('head')[0].appendChild(s);

ライブリを使いJavaScriptファイルを非同期で読み込む方法もあります。LABjsを使えばIE8以下の対応が必要なサイトでも問題なく非同期読み込みを実現できます。

JavaScriptを非同期に読み込むうえでひとつネックになるのは、広告タグのような外部サーバーにあるJavaScriptを読み込んでいる場合です。管理外にあるのでできる対策は限定的です。広告タグを発行しているベンダーが非同期読み込み対応のタグを再発行している場合があるので調べてみるとよいでしょう。 あまりお勧めしませんが、PageSpeed Insightsのユーザーエージェントをみて弾くという方法もあります。

if(navigator.userAgent.indexOf("Speed Insights") == -1) {
  //外部サーバーにあるJavaScriptをここで読み込む
}

PageSpeed Insightsのみ狙い撃ちで対応する方法なので、弊サイトでは導入しませんでした。繰り返しになりますがあまりお勧めではありません。

html圧縮

htmlの圧縮は、インデントや空白の削除を行います。これもタスクランナーなどで自動化することをお勧めします。ローカル開発環境でhtmlを圧縮してしまうと開発時の可読性が大幅に下がるので、ステージングでbuildするタイミングでhtml圧縮するタスクを動かすとよいと思います。個人的にはhtmlを圧縮するのは好みではなく最低限の圧縮にしたかったので、grunt-contrib-htmlminを使いスコアを上げるために空白やインデントを削除するなど最低限かつ効果のある設定にしました。下記のようなオプションの設定でPageSpeed Insightsからは合格点を貰えるはずです。

    htmlmin: {
        dist: { 
            options: { 
                removeComments: false,
                collapseWhitespace: true,
                preserveLineBreaks: true,
                minifyCSS: true,
                minifyJS: false,
                keepClosingSlash: true
            },
            〜省略〜
        }
    },

最後に

今回はフロントエンドの対策を中心に書きましたが、データベースのパフォーマンスチューニングは当然必要になると思われます。またPageSpeed Insightsのスコアへの貢献度は不明確でも重要な項目はあります。例えば、HTTP/2への切り替えなどがそうでしょう。HTTP/2対応したことでサイトパフォーマンスは明白に向上しましたが、PageSpeed Insightsのスコアが向上したかどうかは定かではありません。PageSpeed Insightsはあくまでひとつのベンチマークであることを意識しつつ、UX向上への道標として活用を考えてみてはいかがでしょうか。
アスタミューゼでは、エンジニア・デザイナーを募集中です。ご興味のある方は遠慮なく採用サイトからご応募ください。お待ちしています。

Copyright © astamuse company, ltd. all rights reserved.