algonote

There's More Than One Way To Do It

バックエンドとフロントエンドで人を分けるべきか

要はバランス

バックエンドとフロントエンドで人を分けるべきかは業態による

Web開発がCGIでデザイン性のあまりない匿名掲示板を作る位の時代だと、そもそもフロントエンドができることがブラウザの仕様やパフォーマンス上の理由により制限されていたので、今ほど要求は少なかったのですが、デザイン性やUXの部分がプロダクトの中でのウェイトが上がってくるにつれ、ReactやVueを使ったようなサイトも増えバックエンドエンジニアが兼業でフロントエンドを担当するのもつらいシーンも増えました。

そういったケースの場合、Web開発においてバックエンドとフロントエンドを別エンジニアが担当し、分業するのが合理的な場合もあります。一方でPhoenix LiveViewやRuby on RailsのHotwire、LaravelのLivewireといったバックエンドの言語でフロントエンドを一部代替する動きや、React Server Componentsのようなフロントエンドがバックエンドに歩みよる動きもあり、以前より距離が近くなってはいます。

業態などによって変わるのですが、どういうケースだとバックエンドとフロントエンドで人を分ける合理性が高いでしょうか?

技術面での分業の合理性の分岐点はAPIコールしているか

まずバックエンドとフロントエンドと言った時、フロントエンドが指すものは企業によってまちまちという視点はあった方がいいと思います。

バックエンドエンジニアに求められるフロントエンド力やアーキテクチャは以下のようにもっとグラデーションがあると思います。

  • Lv.0: バックエンドのAPIなら開発はできる
  • Lv.1: HTMLやCSSは書ける
  • Lv.2: jQueryや生JSに近い部分でHTMLを動的に書き換えられる
  • Lv.3: HTMLに埋め込んだデータを使ってReactなどで画面を作れる
  • Lv.4: JSONのAPIを使って(場合によっては複数APIコールして)Reactなどで画面を作れる
  • Lv.5: React Routerなどフロントのルーティングを持ったSingle Page Applicationが作れる
  • Lv.6: React Nativeなどを使ったネイティブ(デスクトップ/モバイル)アプリが作れる

個人的にはLv.4のJSONのAPIを使って通信を明確にし、バックエンドとフロントエンドを疎結合したあたりからバックエンドとフロントエンドを完全分業することができるラインのように思います。

Lv.3くらいだとHTML経由でデータを受け渡すためフロントエンドエンジニアでも多少はバックエンドの言語をかけた方が融通がきくかもしれないライン、逆にLv.5くらい複雑になってくるとバックエンドエンジニアの兼業では厳しいように思います。システムの系は疎結合になっているのに同一担当が実装するのはコンウェイの法則とのねじれがあり、つらみが大きいです。

初期スタートアップでは完全分業はやめた方がいい

技術以外に会社のフェーズによっても合理性は変わってくると思います。フロントエンドとバックエンドだけではないですが、成熟したプロダクトと違って初期スタートアップのプロダクトほどピボットだったり、人材不足によりフルスタック性が求められます

その人の雇用を守るための仕事が発生すると全体の速度が落ちるので、事業内容やプロダクトの方向性、タスクが多少変わってもカバー範囲の広いバッファーがある人員のみの構成比率を大きくした方が無駄が少ないです。

逆にフェーズが上がってくると高度な専門性がないと解けない課題を解く合理性が増える、ユーザー数が増えることによって細かいケースでも面積が上がってくるのでフルスタックエンジニアよりは分業の合理性が高くなることはあります。

バックエンド、フロントエンド兼務から分業への緩やかなパスが欲しい

そう考えるとバックエンド、フロントエンド兼務から分業への緩やかなパスが欲しいですが、自分の知る限りその方法は発明されていない認識です。

例えばGETに絞ればLv.3のHTMLに埋め込んだデータを使うのとLv.4のJSONのAPIを使ってデータを取るのではデータを取るという点において共通しています。HTML経由でquerySelectorでデータを取るのとAPI経由でJSON受けとるので書き方が変わる必要はなく、ラッパーメソッドを通せば裏側は可変に簡単にできるのが技術の進化の方向性のように思います。

fetchにはdata URLが渡せるみたいですね。configのfromHTMLがtrueなら fetch("/api/movies/1")<div id="_fetch_api_movies_1"></div> からデータ取るように自動で切り替わる方向性だとだめなのかなと。

名前のついたロールはいずれコモディティ化する

名前のついたロールはいずれコモディティ化するという考え方もあって、人間が十分に賢く合理的ならその技術専門性の価値は年々減衰します。

Web系は変化がはやいためとある技術専門性がコモディティ化したタイミングで別の技術専門性にトレンドが移り現状そこまで収束してはいませんが、技術の進化が止まったらバックエンドとフロントエンド両方書ける人が普通になる点はいずれ訪れます。

現状ソフトウェアエンジニアの求人倍率は14倍ですが、実際機械や電気系のエンジニアの求人倍率はそれより低いです。社会的にその専門性を持っている人員の需要が大きいなら、賢い為政者がいれば教育機関の定員を増やすなどして、需要が合うよう調整します。

日本では日本国内の地方格差拡大防止のために東京23区内の大学定員の抑制がされていますが、2023/04にそれをIT系に限り緩和する例外措置の指針が発表されました。ただいくつか制約はあるので手放しの緩和ではないようです。

デザインエンジニアやWebAssemblyは別のスキルアドオンの形

バックエンドとフロントエンドの二元論も短絡的で、バックエンドエンジニアのスキルアドオンはフロントエンドだけではありません。

モノリスのバックエンドとマイクロサービスのバックエンドは違いますし、インフラがわかるバックエンドエンジニアもいれば、機械学習のわかるバックエンドエンジニアもいるでしょう。アーキテクトとしての能力を売りにしている方もいますね。

逆にフロントエンジニアはデザイン系のツールを使いこなしデザインエンジニアを売りにしている人もいます。それほどまだ事例はないですが、WebAssembly周りは最近変化が大きいので、クライアント繋がりでWebAssemblyのコードも書けるもセールスポイントでしょう。

企業によってはクライアントサイドテックリードとサーバーサイドテックリードを分けていることはあります。どちらかというとアプリの会社でiOS/Android両方できる人をクライアントサイドテックリードと呼んでいることは多い気がしますが、例えばflutter_hooksのようにReactのhookに影響を受けたような概念はモバイルアプリ開発でも増えてきてはいます。

クライアントなら全てわかるも一つのキャリアの方向性かもしれません。

所感

最新のフリーランスの職種別待遇だとインフラ < フロント < バックエンド < iOS/Android < PM < DS/MLみたいですね。

インフラ周りはセキュリティ要件でフリーランスには任せられないという会社もありそうなので、実需要はもう少し高い気はするのですが、直近マイクロサービスよりモジュラーモノリスの選択をする企業が増えています。

マイクロサービスのバックエンドが簡単かというと語弊はあるのですが、マイクロサービスがインフラは大変だけどバックエンドは簡単な構成だとすればモジュラーモノリスはインフラは簡単だけどバックエンドは大変なアーキテクチャで、バックエンド/フロントよりバックエンド/インフラの需給間の変化の方が直近では大きいかもしれません。

Unityはすでに黒字化している

Unityの決算を読んでみる

UnityにRuntime Feeが導入される

2024/01からUnityにRuntime Feeが導入されることが発表されました。今までの課金モデルと違い、ゲームのインストール数に応じて利用料が発生する仕組みで開発者から反発を受けています。

Unity Software Incは2020/08にNYSEに上場しています。決算も公開されているので今回読んでみます。

investors.unity.com

Unityの概要

Unity社は元々デンマークで設立された会社です。近いところだとSpotifyがスウェーデンで創業、Skypeはデンマーク人とスウェーデン人がルクセンブルクで創業した会社。

Unityはゲームエンジンで、このプラットフォーム上で開発すると異なるゲームコンソール、スマホなどで動くゲームを開発できます。ラッパー上で開発すると個別で開発するよりは労力が減るイメージ。競合はUnreal Engine、Godot Engineなど。

社歴としては元々作っていたゲームGooBallが商業的には成功しなかったので、その開発に使っていた内製ツールを売る方向にピボットしたのがはじまりです。2014年に共同創業者のDavid Helgasonから元Electronic ArtsのJohn RiccitielloにCEOを交代しています。

M&Aにも積極的で2014年に買収したApplifier、Playnomics、TsugiがUnity Ads、Unity Analytics、Unity Cloud Buildになっています。2019年にVivox、deltaDNA 、ChilliConnect、Obvioos、Artomatix、2020年にMLAPI、RestAR、2021年にPixyz Software、Parsec、Weta Digital、2022年にZiva Dynamics、ironSourceを買収。

多いですね。買収費用がかさむので営業利益と分けて判断したいところ。

Unityは四半期ベースだとすでに黒字構造

さて決算を見ていきましょう。

2022 Q4の決算資料から分かるとおり2022年までは年次で赤字の構造。2022 Q4に黒字化。

最新の四半期報告でも利益が増えています。

2022/10からUnity利用料が2割程度値上げのでそのおかげでしょうか。

Unityのビジネスモデル

UnityはIPO時点での収益源が3つあり、54%がUnity Ads、Unity In-App PurchasesからなるOperate Solutions、31%がUnity Engine使用料のCreate Solutionsそして15%が戦略パートナーシップ他など。

メタ社も大きく影響を受けたとされますが、2021/04のiOS14.5からAppleがIDFA(広告識別子)の取得のオプトイン化の制限が入っています。Unity Adsの将来性に不安を持ったので他をテコ入れした説はあります。実際、Unity株は2022/05にIDFAの影響を受けて37%暴落しています。

2020年のIPO時から報告の形式が変わっています。Create Solutionsは旧Create Solutions + 旧Operate Solutions に入っていたUnity Gaming + Strategic Partnerships。Grow SolutionsにはAds製品、Supersonic、Aura、Lunaが含まれている。旧形式でCreate $508M, Operate $801なので割合としてIPO時と変わっていないですね。もっとIDFAの影響があると思ったのですが。

ハイパーカジュアルゲームはそもそもUnityと競合している

ここがややこしい部分なんですが、ironSourceとSupersonicが2015年に統合。その統合されたironSourceを2022年にUnityが買収。Supersonicはグロースプラットフォームでもあるのですが、自身でハイパーカジュアルのゲームも出しています。Tall Man RunとBasket Battleは2022年のハイパーカジュアルランキングで2位と5位になっています。

2023Q2の決算によるとすでに90個ゲームを出している模様。

今回新規に発表されたUnityのRuntime Feeはインストール数で計算されるので単価が低く広くインストールされるハイパーカジュアルのようなゲームが不利なようです。

UnityのGrow Solutionsに含まれるゲーム自体の売り上げは細かく書かれていないので不明なのですが、仮にハイパーカジュアルゲームがジャンルとして金脈だとして、Unityを使うと簡単にハイパーカジュアルゲームを作れるとすれば構造的に他のゲームが出しにくようにするのは企業としては合理的(妄想)であるようには感じました。

既存顧客のアップセルは鈍化傾向

IR資料には顧客数とDollar-Based Net Expansion Rate(DBNER: 既存顧客の顧客あたり売り上げ成長率)がのっています。

顧客数は増えていますが、アップセルは鈍化傾向

まとめ

  • Unityは積極的に買収をしている
  • ただ機能追加の割にアップセルは成功していない
  • iOSのIDFAの制限により広告頼りは事業的にリスク
  • 直近の買収によりゲームエンジンだけでなくハイパーカジュアルのゲーム自体もポートフォリオに入っている

とすると、代替のアップセルの方法で独占禁止法に抵触しない程度に他のハイパーカジュアルゲームが不利な料金プランにするのが合理的だったのではないか(妄想)と思いました。推測が多いのでチラシの裏の陰謀論程度に読んでもらえればと。

所感

米国市場での一の部とも言えるFORM S-1も公開されているのでそちらも読んでみたいです。

www.sec.gov

Unityと直接関係ないのですが、北欧つながりだとSpotify創業話をベースにしたThe Playlistはエンジニア出身の創業者がどう動いたかわかり面白かったです。

www.netflix.com

[Zenn投稿] オープンソースRailsリポジトリの統計比較

Rails開発のあたりをつける

オープンソースRailsリポジトリの統計比較

Zennに「オープンソースRailsリポジトリの統計比較」を投稿しました。

zenn.dev

オープンソースのプロジェクトは沢山の目によってウォッチされているのでコードは十分に綺麗で完璧という前提を仮定しているのでそこがずれていると結論は変わるかもしれないですね。

所感

Ruby 3.2でReDOSの対策の改善が行われました。GitLabはGoogleのre2を使って正規表現の機能をあえて制限しているようです。

他にもGitLabはnative extensionを使ったライブラリーを複数使っており、環境構築時dockerを使わないとつらい印象を受けました。特にApple Silicon Mac。

[Zenn投稿]「オープンソース」と言う用語の歴史

用語の復習

Zennに投稿しました

Zennに「オープンソース」と言う用語の歴史 を投稿しました。

zenn.dev

LLMのオープンソース記述が話題になったので復習も兼ねて。

所感

ソースWikipediaなのでどこまで正しいかは微妙なところもあると言えばあるんですが、日本語版よりは多数の目がある分ちゃんとまとまっている印象。

個人的に、GPL汚染は今でも聞きますが、コピーレフトは若干死語というか話されることが減った印象はあります。MIT Licenseあたりのプロジェクトが増えたからかもしれないですが。

いかにして人類は再び囲碁AIに勝利したか

人類が再びAIに勝つ方法

人間がAIに再び勝利した

2015年、AlphaGoがプロ囲碁棋士に勝利しました。その後汎化して将棋やチェスにも対応したAlphaZeroが2017年に出て、囲碁/チェス/将棋AIにおいて、機械の方が人間より強いと言う共通認識が形成されました。

実際、将棋の藤井聡太9段もゲーミングPCオタクでAIを使って棋力を伸ばしたことが知られています。

一見ゲームAIの進化はAI同士の対戦にフェーズが移ったように思えたところに、アマチュア囲碁棋士であるKellin Pelrine氏が囲碁AIのKataGoに勝利したことを知りました。

AIに奪われる仕事のランキングが出回る昨今において、人類が再びAIに勝利した事例は稀有なのではと思い、今回取り上げてみます。

Adversarial Policies Beat Superhuman Go AIs

Kellin PelrineはPhDでもあり、使った手法のコードや論文はAdversarial Policies Beat Superhuman Go AIsとして公開されています。ICML 2023に採択。

AlphaGoのコードは公開されていないので、公開されている囲碁AIとしては最強のKataGoに弱点はないか調べた論文です。発見された手法はcyclic-exploit: ドーナッツ状に輪を作るとAIの誤認を誘えるというもので、プログラムを破るプログラムを開発する研究の中で、人間でもAIに勝てる手法が見つかりました。

15回対戦して14勝で他の囲碁AIにも使えるので汎用的。ただし、最新のKataGoでは対策が施された模様。

どうやって弱点を見つけたのか

著者の方がかなりしっかりした解説をYouTubeにあげられています。

KataGoが簡単な詰碁を解けなかったのをきっかけにadversarial局面をまっさらな初期盤面からでも生み出せるのではないかという仮説から実験。

素のKataGoとツリーサーチ併用のKataGoでは後者の方が強いので後者の自己対戦データを教師に素のKataGoのネットワークを模倣学習させ、世代を重ねていくと人を超えるKataGoが得られる。攻撃ネットワークでも同様に、素のネットワークとツリーサーチ併用のネットワークを組みわあせて、世代を重ねていった。

一点違うのはツリーサーチは通常のモンテカルロツリーサーチではなくAdversarial モンテカルロツリーサーチ(A-MCTS)な点。また、いきなり強い世代と戦わせるのではなく弱いAdversarialネットワークと戦わせてから徐々により強い世代と戦わせるカリキュラム学習を行った。

使用ルールがプロのルールと違う

一方で批判もあって、使用した囲碁のルールがTromp-Taylorルールで現在日本や中国で使われているルールとは違うものようです。Rdditに作者が降臨して少し議論がされています。

AlphaGo=> AlphaZeroの差分の一つは人間の棋譜を使用せず自己対戦による強化学習を行ったことですが、自己対戦は稀な手筋に弱く、実際他の定石であるMi Yuting's flying daggerは防げないことが多いようです。KataGoでは元から手動でそう言うパターンの棋譜を読み込ませているので対策できているとか。

所感

ちょっと人類に有利な調整はあるようですが、人類が再びAIに勝利したという事実はキャッチーですね。

囲碁ネタで言うとヒカルの碁のドラマが中国で制作されており、面白かったです。

www.tbs.co.jp

[Zenn投稿] 法規制が予想されるSBOMについて

ソフトウェア部品表入門

Zennに投稿しました

Zennに「法規制が予想されるSBOMについて」を投稿しました。

zenn.dev

所感

欧州の法律の草案が通れば、ソフトウェアプロダクト全体に関わるかなり大規模な規制であるように思います。

その割にSBOM自体の規格に方言があり過ぎて、マシンリーダブルをうたう割に言うほどマシンリーダブルではない気もしました。

一団体に権限を与え過ぎず公平を優先したとも言えますが、もっとSBOMの規格自体を標準化してから色々はじめたほうが混乱は少なかったのではという気もします。

くるみんマークを取得しているIT企業一覧

子育てサポート企業の見分け方

公的な証明で働きやすい企業を見抜くには

20・30代の7割がマネージャーを希望していないそうです。転職でも年収よりワークライフバランスが重要というケースも増えました。たくさん残業しなければいけないなら、高給でなくてもいいという人も増えているのが時代の流れかなと。

経営者が働きやすい会社です、子育て世代に寄り添っていますと口で言うだけなら簡単ですが、転職して入ったら思ったのと違ったというケースもあると思います。完璧ではないものの、くるみんマークは公的な認証であり、その企業のワークライフバランスへの投資の本気度を測る指標になり得るので今回見ていきます。

くるみんマークとは

くるみんマークは子育てサポート企業として厚生労働大臣の認定を受けた場合に使えるマークです。行動計画を策定する必要があり、いくつかの要件も満たす必要があります。

2022年4月に要件が厳しくなった他、トライくるみんが追加され、要件の厳しさに応じて基本的にプラチナくるみん、くるみん、トライくるみんの3マークの運用になりました。

ざっくりとした 基準の違いは以下です。

  • プラチナくるみん
    • 男性育休取得率: 30%以上(<= 13%以上)
    • 男性育休・育児目的休暇取得率: 50%以上(<= 30%以上)
  • くるみん
    • 男性育休取得率: 10%以上(<= 7%以上)
    • 男性育休・育児目的休暇取得率: 20%以上(<= 15%以上)
  • トライくるみん
    • 男性育休取得率: 7%以上
    • 男性育休・育児目的休暇取得率: 15%以上)

また、不妊治療のための休暇制度等の追加要件を満たせば、プラチナくるみん/くるみん/トライくるみんはプラチナくるみんプラス/くるみんプラス/トライくるみんプラスマークになれます。

認定企業が中小企業の場合、上限50万円のくるみん助成金をもらえる他、公共調達においてくるみん認定企業は加点を得られます

くるみんマークの認定基準

くるみんマークの認定基準の10要件は以下です。

  1. 雇用環境の整備について、行動計画策定指針に照らし適切な行動計画を策定したこと。
  2. 行動計画の計画期間が、2年以上5年以下であること。
  3. 策定した行動計画を実施し、計画に定めた目標を達成したこと。
  4. 策定・変更した行動計画について、公表および労働者への周知を適切に行っていること。
  5. 次の(1)または(2)のいずれかを満たしていること。
    1) 計画期間における、男性労働者の育児休業等取得率が10%以上であり、当該割合を厚生労働省のウェブサイト「両立支援のひろば」で公表していること。
    2) 計画期間における、男性労働者の育児休業等取得率および企業独自の育児を目的とした休暇制度利用率が、合わせて20%以上であり、当該割合を厚生労働省のウェブサイト「両立支援のひろば」で公表していること、かつ、育児休業等を取得した者が1人以上いること。
  6. 計画期間における、女性労働者の育児休業等取得率が、75%以上であり、当該割合を 厚生労働省のウェブサイト「両立支援のひろば」で公表していること。
  7. 3歳から小学校就学前の子どもを育てる労働者について、「育児休業に関する制度、所定外労働の制限に関する制度、所定労働時間の短縮措置または始業時刻変更等の措置に準ずる制度」を講じていること。
  8. 計画期間の終了日の属する事業年度において次の(1)と(2)のいずれも満たしていること。 なお、認定申請時にすでに退職している労働者は(1)・(2)のいずれも、分母にも分子に も含みません。
    1) フルタイムの労働者等の法定時間外・法定休日労働時間の平均が各月45時間未満で あること。
    2) 月平均の法定時間外労働60時間以上の労働者がいないこと。
  9. 次の①~③のいずれかの措置について、成果に関する具体的な目標を定めて実施している こと。
    1) 所定外労働の削減のための措置
    2) 年次有給休暇の取得の促進のための措置
    3) 短時間正社員制度、在宅勤務、テレワークその他働き方の見直しに資する多様な労働条件 の整備のための措置
  10. 法および法に基づく命令その他関係法令に違反する重大な事実がないこと。

中小企業だと軽減もあるのですが、学生起業で若手ばかりの人員構成だと5の実績面が満たせない場合はありそうなのと、8の残業規定は引っ掛かりそうなポイントでしょうか。育休をカバーするために一部の名ばかり管理職がたくさん残業してカバーするとダメそうですね。

プラチナくるみんだと少し要件が厳しくなるのですが、8の残業の規定は変わらないようで、個人的にはもう少し厳しめでもいい気はします。誰かがカバーして残業している会社は真の子育てサポート企業ではないかなと。

くるみんマークを取得しているIT企業一覧

くるみんマークを取得している企業は公表されているのでIT企業を抽出してみます。2023年6月末時点の表をベースに202x年で認定のある企業。

IT企業の定義が難しいのもあるのですが、似たような名前が多いのもつらいですね。公共調達で有利になるからか取得企業にSIerが多いように感じます。C向けのWeb系の会社は少ないですね。

プラチナくるみん認定

  • ソフトバンク株式会社
  • キヤノンITソリューションズ株式会社
  • 日鉄ソリューションズ株式会社
  • 株式会社日立ソリューションズ・クリエイト

くるみん認定

  • 株式会社ジャパンテクニカルソフトウェア
  • NECソリューションイノベータ株式会社
  • 株式会社エヌ・ティ・ティ・データ・フィナンシャル・ソリューションズ
  • かんぽシステムソリューションズ株式会社
  • キーウェアソリューションズ株式会社
  • 住友電工システムソリューション株式会社
  • 中外製薬ビジネスソリューション株式会社
  • パナソニックシステムソリューションズジャパン株式会社
  • 三井倉庫サプライチェーンソリューション株式会社
  • 横河ソリューションサービス株式会社
  • 株式会社早稲田大学アカデミックソリューション
  • GMOペイメントゲートウェイ株式会社
  • KDDI株式会社
  • 株式会社NTTデータSMS
  • 株式会社NTTデータNJK
  • 株式会社NTTデータアイ 
  • 株式会社オールアバウト
  • 株式会社ぐるなび
  • サイバネットシステム株式会社
  • さくら情報システム株式会社
  • 株式会社ソフマップ
  • 日本ヒューレット・パッカード合同会社
  • ビットバンク株式会社
  • 楽天銀行株式会社

トライくるみん認定

該当なし

くるみんマークを見るコツ

プラチナかどうかも確かに大事なのですが、公表されている企業の中にはだいぶ昔に取ってからそのままの企業も多そうなので、そういう観点でも見た方がいいですね。

助成金がもらえたから取得したという企業だったり、過去取ったものの今は要件を突破できなくなってしまったという企業もありそうなので、継続的にくるみんマークを取得している企業は信頼できるなと。

IT企業かというと微妙なラインですが、日本ヒューレット・パッカードは2007~2021で計5回取得しているようです。

所感

両立支援のひろばにも統計データおいてあるようなので分析してみたいですね。

子育て世代が働きやすい会社というのは関係ない人でも働きやすい会社というのはよく言われることで、くるみんマーク取得企業が増えれば多少はワークライフバランスを考えた会社が増えるのではと思いました。

github.com

[Zenn投稿] デメテルの法則を根拠にdelegateを乱用するのは間違い

ではないか

デメテルの法則を根拠にdelegateを乱用するのは間違い

Zennに「デメテルの法則を根拠にdelegateを乱用するのは間違い」を投稿しました。

zenn.dev

所感

法則にのっとているかでその後のバグを防げたかだったり、何かしらの指標が改善するのか比較してみたいですね。

古い論文なのでその後のソフトウェア開発研究業界上のデメテルの法則の評価を聞きたいところですが、いい後続論文あるかどうか。

それってパクリじゃないですか?で学ぶ特許

ドラマで学ぶ特許

それってパクリじゃないですか?

「それってパクリじゃないですか?」は企業の知財部を舞台にしたドラマです。小説が原作ではあるのですが、既刊が2巻だけのため追い越した部分があり、小説で書かれる予定のものを一部取り込んだようです。

2023年4月期放送。Huluで全話見れます。

インタビューによると作者の奥乃桜子先生は以前大学で研究者をされていたようです。作者が理系バックグラウンドという意味ではすべてがFになる、数学ガール系でしょうか。

話数一覧

話のタイトルはこんな感じ。知財部なので特許だけでなく商標の話もありますね。

  1. 盗まれた発明
  2. パクリとパロディ
  3. 侵害予防調査
  4. 商標出願の勝者
  5. 調整の樹海
  6. ヤバイで特許出願
  7. 特許の怪物、現る
  8. 本物の怪物
  9. 完璧上司の涙
  10. 守るべきもの

いろんな概念が出てくるのですが、いくつか部分的に取り上げてみます。

弁理士

士業の中では、弁護士、司法書士、税理士と比べると弁理士は知名度で言うとマイナー扱いされることもある印象です。劇中でも便利屋扱いされていました。

弁理士は知的財産の専門家で特許申請の代行業務などいくつかが独占業務として認められています。

弁理士試験の他に特定侵害訴訟代理業務試験というより実務に踏み込んだ試験もあります。

冒認出願

冒認出願は発明の権利を有していないものが特許を出願してしまうことを言います。

割合最近までアメリカは先発明主義でしたが、先願主義に移行しています。秘密情報をベースに先願されてしまった時に冒認出願を訴えるわけですね。

商標の出願区分

商標は出願区分が細かく区切られており、区分ごとに権利が定められています。

最近商標でもめた事例だと"zoom"でしょうか。AItuberの商標登録でも一悶着ありました。

クロスライセンス契約

A社が持っている特許をB社が侵害していて、B社が持っている特許をA社が侵害している際に打ち消しあうのがクロスライセンス契約

日本で特許訴訟があまり起きないのもメーカー同士で裏で特許権のマージンの調整をしているからとも言われていますね。

分割出願

1つの特許の一部を切り出して提出したのが分割出願

ただ実務上は一部というよりコピーに近い扱いで審査を進める中でスコープを変えたり、広く使える特許と手堅い特許の二段構えをするための分割出願も多いようです。

ユニクロ(ファーストリテイリング)とアスタリスクのセルフレジの訴訟でも弁護士の方が分割出願が訴訟費用の高騰を招いたとも語られているので中小企業の特許戦略としては乱用は微妙かもしれません。ユニクロは裁判で負けていますが、最終的にライセンス料ゼロで和解となっています。。。

所感

IT系でもウマ娘がパワプロの育成システムに似ているとして訴訟されていますね。

それってパクリじゃないですか?はドラマ自体もむすっとしている男性と感情豊かな女性の掛け合いがコミカルで面白かったです。

#ex_cookpad に集まったアクティブに採用している企業一覧

求人まとめ

前口上

クックパッドで人員削減、退職勧奨があったようで、各社が採用情報をTwitter上で #ex_cookpad に流しています。

クックパッド社で働いたことはないんですが、Rubyコミュニティーへの貢献は大きいものがあり、よく技術ブログを読んでいます。

エンジニアのレベルが高いのもあるのですが、デザイナーが半分PMを兼ねているような業態が独自な部分で強いところですね。

フローメディアだと流れてしまうので、exクックパッドな人も、単に転職先探している人にも有用そうなので簡単にまとめておきます(職業紹介を目的としておらず個人的なメモです)。

エンジニア

Ruby

PHP

Python

Go

Java

node.js

フロントエンド

iOS

Android

Unity

データサイエンス、機械学習

SRE

言語不明

デザイナー

PM、ディレクター他

所感

途中で力尽きました。。。

スタートアップ界隈でよく言われるスケールしないことをしようではないですが、ハッシュタグに求人のせるはスタートラインで個別に連絡とるのも大事な気はしますね。楽なやり方だけでは成し得ないこともあるのかなと。