メドレーのデザイナー酒井です。最近、 JobMedley から CLINICS に異動しました。 自分はデザインはもちろん、HTML/CSS/JS 実装してプルリク送ったりしているちょっとフロントエンド実装領域に軸足が寄ったタイプのデザイナーです。 ここでは以前所属していた JobMedley 事業部の話をさせていただきます。 当時、JobMedley の社内システムのリニューアルプロジェクトにデザイナーとして参加していました。通常、デザイナーがデザインをするときには Skecth や Figma のようなデザインツールを利用するのが一般的かと思います。 弊社でも基本的にはデザインツールでデザインを行うことが多いのですが、プロジェクトによっては、よりリアルなモックアップが必要なため、デザイナー自身がコーディングでデザインを行い、ブラッシュアップしていくことがあります。その後、フロントエンド実装者が、デザイナーが作ったデザインを参考に、しっかりと設計されたもので作り直します。 今回のリニューアルプロジェクトのデザイン・モックアップの制作では、Figma や Sketch などのデザインツールは使用せず、React でコーディング行い、デザインを制作しています。ここが特殊な制作フローになると思うので、このエントリでは React をデザインツールとして使ったときの流れとメリット・デメリット、ちょっとニッチなポイントに絞ってお話していきます。 デザインの流れ 1.まずは React を勉強する 元々受託制作会社でデザイナーをやっていた時代に Vue.js での開発経験はありましたが、React は今回が初めてでした。そのため、一旦公式チュートリアルを一通り読み、Google などで調べつつ、基礎知識のインプットすることからはじめました。 2.ワイヤーフレームを作る さすがにワイヤーフレーム無しでコード実装には入れないので、ここでは Figma などのツールを使います。ワイヤーフレームを作り、要件定義を進めていきますが、デザインに関してもある程度のあたりを付けていきます。 3.開発環境構築 今回は Next.js で制作を行っています。 そもそも、プロダクトの実装で Next.js を使用することが決まっていたので、デザイン側も Next.js を採用しましたが、結果的に良かったなと感じています。 Next.js で作っておけば、めんどくさい router の設定やデザイナーが苦手な webpack の config を記述しなくてすみます。 また、 next build && next export で静的な HTML ファイルとして書き出されるため、サーバがあればすぐに共有が可能です。今回はエンジニアさんに、develop ブランチに merge されると、 next build && next export が走り、自動で Amazon S3 に静的ファイルをデプロイされるようにしてもらいました。 この時点でプロダクト側のフロントエンド設計も進んでいたため、ESLint やコンポーネント設計、ライブラリなどを流用し、デザインプロジェクト用に最適化させます。 4.Next.js の設計 実際にエンジニアがプロダクトを実装する際には色々なことを検討する必要があると思いますが、デザインツールとして使用する際には、逆にそこまでガチガチにしてしまうと実装に工数がかかりすぎてしまうので「割り切り」が必要になります。私が実装した際の環境は以下のようなものです。 TypeScript は入れない。要件が固まりきっていない状態で型定義をやり始めると修正に時間がかかりすぎるため。 非同期通信処理も入れない。データがほしければローカルに json ファイルを配置しておく。 デザイン側のソースコードの汚さはあまり気にしない。プロダクト版を作成するときにフロントエンドエンジニアがきれいに作り直してくれる。 コンポーネント設計を意識する。共通コンポーネントとして使用する汎用的なものは先に洗い出しておく。 テストコードは書かない。そこまでページ数が多くない上、上記のような割り切りをしているので複雑性も極端に上がらない。 Google Chrome 最新版のみ対応とする。他のブラウザは無視する。 （昨今のフロントエンド開発の流れと真逆、、、） 5.デザインルール設計 続いてデザインルールの設計を行います。 theme.js ファイルを作成し、以下を定義します。この時点で定義が完全にできていることは無いと思うので、分かる範囲で書いていきます。最終的に、不要なものを消したり、一緒にできるものは統合して定義を減らしていきます。 各コンポーネントで padding や margin の余白を数値で指定したり、色味のカラーコドをベタ打ちせず、必ず theme ファイルから値を引っ張ってくるようにします。そうすると、修正が容易になる上、あとからどこで何が使われているかを把握しやすくなります。 ■theme 内に記述する内容のイメージ fontFamily// fontFamily を定義 colors// カラーコードの一覧 spaces // 4/8/16 など余白に使う数字を定義。 fontSizes // fontSize を定義 lineHeight // lineHeight を定義 fontWeight // fontWeight を定義。 boxShadow // ドロップシャドウを使用するなら定義 6.コンポーネント設計 続いて、コンポーネントとコンポーネントに必要な props を洗い出します。 世の中には優秀な UI フレームワークが複数存在していますのでそういったものを参考にします。そういったものはほとんど同じようなコンポーネント設計になっているのでコンポーネントの分け方や受け取る props などを参考にすると作業が捗ります。 Ant Design https://ant.design/ Material-UI https://material-ui.com/ Element https://element.eleme.io/#/en-US ここで気をつけたいのは、コンポーネントの数を極力減らすように努力することです。 同一機能の別コンポーネントが複数できてしまうと、今後の機能拡張時に、どのコンポーネントを使うか迷うことになります。ほとんどのエンジニアやデザイナーにとって、コンポーネント選びで迷うことは時間の無駄です。選択肢は極力減らす努力をし、減らせないようなら使用する場所を明確に定義する必要があります。 例えば component/tab1/ component/tab2/ component/tab3/ のようにタブコンポーネントが複数あると、あとから見たときにどれを使えばいいかわからなくなりますよね。 これを許容してしまうと、知らぬ間に component/tab4/ ができあがっていることでしょう。 7.実装 まずは大枠のページテンプレートを制作します。その後、小さいコンポーネントから順に作り上げていき、ページテンプレートに配置していきます。コンポーネント化ができていれば、見た目の変更はあとから行えるので、まずは page 内に配置し、機能することを目指します。 この時点で、デザインを細部まで作り込んだとしても、結局全体を見渡してから細かく調整をかけていくと思うので、そこまでセンシティブにならずに行っていきます。 8.確認・ヒアリング・修正の繰り返し 見た目が完全にできていない状態で、確認観点を絞って、PM や、ディレクター、実際に業務で使う方々にチェックしてもらいフィードバックを受けます。 徐々にブラッシュアップしていき、完成を目指します。 デザイン中には常に以下を意識して作業することで、無駄なものを介在させない設計を目指します。 コンポーネントを共通化できないか 色数を減らせないか fontSize や lineheight などの定義を減らせないか 9.各種資料の作成 作っているデザインではエラー処理などすべてを表現しきれないので、補足資料として別途スプレッドシートなどにまとめていきます。 また、実際のコンポーネントと想定している props、実装時の注意事項などを記載した UI コンポーネント集ページを制作し、フロントエンドエンジニアと共有します。 Storybook での共有も検討しましたが、受け渡す props の想定、エンジニアへの指示、要件の補足を記載していくだけですので、Storybook ほどの機能は不要と考え、Next.js 内にシンプルな Page を作り、そこに記述する方法を選択しました。 また、デザインの設計ルールも資料化し、最終的には各種資料と、制作したコード、S3 にアップされている URL を成果物としてエンジニアに実装をしていってもらいデザインのフェーズを完了させます。 React でデザインした場合のメリット 忠実度の高いモックアップが制作できる プロトタイプツールは数多くあれど、実装にまさる忠実度の高さなし。 最近は Figma の AutoLayout や XD のスタックなど、便利な機能も登場してきていますし、プロトタイピングに関しても様々なアクションが設定できるので、非常に便利になってきました。ただ、それでも CSS や JS の表現力にはまだ届かない部分も多いかなと感じています。 ボタンを押したとき、特定の <select/> の <option/> が選択されたとき、複数条件下でのみ表示させるもの、ウインドウサイズが小さくなったときの表示など、デザインツールで実装するにはやや面倒な箇所も、コードベースなら対応可能で、デザインファイルと実装されたページでの印象差も起こりづらいです。 実際に操作できる環境を渡すことで高い精度のフィードバックをもらえる 様々なリテラシーのユーザーが使用するサービスであるからこそ、よりリアルなプロトタイプを使用し、ミスコミュニケーションを減らせました。 結果論ですが、新型コロナウィルスによって、コミュニケーションを取りにくい状況が続きましたが、挙動を忠実に再現しているので、精度の高い意見を聞けたのは良かったです。 プロダクト版のフロントエンドの実装時に、こちらの意図が伝わりやすい fontSize や space、color を theme.js ファイルにまとめておき、そこからコンポーネント側では theme 側から読み込むようにしておけば、デザインルールが把握しやすくなります。また、CSS がすでに記述されているので、プロダクト版への移植も可能となり、「デザインファイルと実装でデザインが違う」が起こりにくくなります。 Git やエディタの恩恵をフルに受けられる 一旦別ブランチでデザイン案を作る、作ったブランチの commit から cherry-pick する、過去の log を見る、特定の commit に戻るなど、Git の恩恵をフルに受けられます。また、文字列の一括検索や置換が可能なので、色味を一気に置き換えたい、どこで使われているかを探したい場合などかなり重宝しました。 とはいえいいことばかりではなかった。。。 ちょっと要素の位置を変える、などはデザインファイルのほうが全然楽。コードベースだと CSS と HTML 構造自体を書き換えないといけない React を理解していないと、動かなくなったりした時に、修正で時間を余計に使ってしまう 他のデザイナーに引き継ぎしずらい など、通常のデザインファイルでは起こらないようなデメリットもありました。 結局の所プロジェクトによって向き不向きはあります。 個人的には社内の管理システム系のように、一般的なコンポーネントを組み合わせて、色々なデータを表示する必要があるサイト制作に向いているかなと思います。 逆に、特殊なコンポーネントを量産するケースや、LP のようにグラフィック要素が多くなってくるとデザインツールのほうがはかどります。 プロジェクトの性格に応じて最適なデザイン方法を選んでいきたいですね。 デザイナーだけどコードも書きたい方や、一緒にプルリク送ってくれるデザイナーの方いらっしゃれば、ぜひメドレーで一緒に働きましょう〜 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

メドレーのデザイナー酒井です。最近、 JobMedley から CLINICS に異動しました。 自分はデザインはもちろん、HTML/CSS/JS 実装してプルリク送ったりしているちょっとフロントエンド実装領域に軸足が寄ったタイプのデザイナーです。 ここでは以前所属していた JobMedley 事業部の話をさせていただきます。 当時、JobMedley の社内システムのリニューアルプロジェクトにデザイナーとして参加していました。通常、デザイナーがデザインをするときには Skecth や Figma のようなデザインツールを利用するのが一般的かと思います。 弊社でも基本的にはデザインツールでデザインを行うことが多いのですが、プロジェクトによっては、よりリアルなモックアップが必要なため、デザイナー自身がコーディングでデザインを行い、ブラッシュアップしていくことがあります。その後、フロントエンド実装者が、デザイナーが作ったデザインを参考に、しっかりと設計されたもので作り直します。 今回のリニューアルプロジェクトのデザイン・モックアップの制作では、Figma や Sketch などのデザインツールは使用せず、React でコーディング行い、デザインを制作しています。ここが特殊な制作フローになると思うので、このエントリでは React をデザインツールとして使ったときの流れとメリット・デメリット、ちょっとニッチなポイントに絞ってお話していきます。 デザインの流れ 1.まずは React を勉強する 元々受託制作会社でデザイナーをやっていた時代に Vue.js での開発経験はありましたが、React は今回が初めてでした。そのため、一旦公式チュートリアルを一通り読み、Google などで調べつつ、基礎知識のインプットすることからはじめました。 2.ワイヤーフレームを作る さすがにワイヤーフレーム無しでコード実装には入れないので、ここでは Figma などのツールを使います。ワイヤーフレームを作り、要件定義を進めていきますが、デザインに関してもある程度のあたりを付けていきます。 3.開発環境構築 今回は Next.js で制作を行っています。 そもそも、プロダクトの実装で Next.js を使用することが決まっていたので、デザイン側も Next.js を採用しましたが、結果的に良かったなと感じています。 Next.js で作っておけば、めんどくさい router の設定やデザイナーが苦手な webpack の config を記述しなくてすみます。 また、 next build && next export で静的な HTML ファイルとして書き出されるため、サーバがあればすぐに共有が可能です。今回はエンジニアさんに、develop ブランチに merge されると、 next build && next export が走り、自動で Amazon S3 に静的ファイルをデプロイされるようにしてもらいました。 この時点でプロダクト側のフロントエンド設計も進んでいたため、ESLint やコンポーネント設計、ライブラリなどを流用し、デザインプロジェクト用に最適化させます。 4.Next.js の設計 実際にエンジニアがプロダクトを実装する際には色々なことを検討する必要があると思いますが、デザインツールとして使用する際には、逆にそこまでガチガチにしてしまうと実装に工数がかかりすぎてしまうので「割り切り」が必要になります。私が実装した際の環境は以下のようなものです。 TypeScript は入れない。要件が固まりきっていない状態で型定義をやり始めると修正に時間がかかりすぎるため。 非同期通信処理も入れない。データがほしければローカルに json ファイルを配置しておく。 デザイン側のソースコードの汚さはあまり気にしない。プロダクト版を作成するときにフロントエンドエンジニアがきれいに作り直してくれる。 コンポーネント設計を意識する。共通コンポーネントとして使用する汎用的なものは先に洗い出しておく。 テストコードは書かない。そこまでページ数が多くない上、上記のような割り切りをしているので複雑性も極端に上がらない。 Google Chrome 最新版のみ対応とする。他のブラウザは無視する。 （昨今のフロントエンド開発の流れと真逆、、、） 5.デザインルール設計 続いてデザインルールの設計を行います。 theme.js ファイルを作成し、以下を定義します。この時点で定義が完全にできていることは無いと思うので、分かる範囲で書いていきます。最終的に、不要なものを消したり、一緒にできるものは統合して定義を減らしていきます。 各コンポーネントで padding や margin の余白を数値で指定したり、色味のカラーコドをベタ打ちせず、必ず theme ファイルから値を引っ張ってくるようにします。そうすると、修正が容易になる上、あとからどこで何が使われているかを把握しやすくなります。 ■theme 内に記述する内容のイメージ fontFamily// fontFamily を定義 colors// カラーコードの一覧 spaces // 4/8/16 など余白に使う数字を定義。 fontSizes // fontSize を定義 lineHeight // lineHeight を定義 fontWeight // fontWeight を定義。 boxShadow // ドロップシャドウを使用するなら定義 6.コンポーネント設計 続いて、コンポーネントとコンポーネントに必要な props を洗い出します。 世の中には優秀な UI フレームワークが複数存在していますのでそういったものを参考にします。そういったものはほとんど同じようなコンポーネント設計になっているのでコンポーネントの分け方や受け取る props などを参考にすると作業が捗ります。 Ant Design https://ant.design/ Material-UI https://material-ui.com/ Element https://element.eleme.io/#/en-US ここで気をつけたいのは、コンポーネントの数を極力減らすように努力することです。 同一機能の別コンポーネントが複数できてしまうと、今後の機能拡張時に、どのコンポーネントを使うか迷うことになります。ほとんどのエンジニアやデザイナーにとって、コンポーネント選びで迷うことは時間の無駄です。選択肢は極力減らす努力をし、減らせないようなら使用する場所を明確に定義する必要があります。 例えば component/tab1/ component/tab2/ component/tab3/ のようにタブコンポーネントが複数あると、あとから見たときにどれを使えばいいかわからなくなりますよね。 これを許容してしまうと、知らぬ間に component/tab4/ ができあがっていることでしょう。 7.実装 まずは大枠のページテンプレートを制作します。その後、小さいコンポーネントから順に作り上げていき、ページテンプレートに配置していきます。コンポーネント化ができていれば、見た目の変更はあとから行えるので、まずは page 内に配置し、機能することを目指します。 この時点で、デザインを細部まで作り込んだとしても、結局全体を見渡してから細かく調整をかけていくと思うので、そこまでセンシティブにならずに行っていきます。 8.確認・ヒアリング・修正の繰り返し 見た目が完全にできていない状態で、確認観点を絞って、PM や、ディレクター、実際に業務で使う方々にチェックしてもらいフィードバックを受けます。 徐々にブラッシュアップしていき、完成を目指します。 デザイン中には常に以下を意識して作業することで、無駄なものを介在させない設計を目指します。 コンポーネントを共通化できないか 色数を減らせないか fontSize や lineheight などの定義を減らせないか 9.各種資料の作成 作っているデザインではエラー処理などすべてを表現しきれないので、補足資料として別途スプレッドシートなどにまとめていきます。 また、実際のコンポーネントと想定している props、実装時の注意事項などを記載した UI コンポーネント集ページを制作し、フロントエンドエンジニアと共有します。 Storybook での共有も検討しましたが、受け渡す props の想定、エンジニアへの指示、要件の補足を記載していくだけですので、Storybook ほどの機能は不要と考え、Next.js 内にシンプルな Page を作り、そこに記述する方法を選択しました。 また、デザインの設計ルールも資料化し、最終的には各種資料と、制作したコード、S3 にアップされている URL を成果物としてエンジニアに実装をしていってもらいデザインのフェーズを完了させます。 React でデザインした場合のメリット 忠実度の高いモックアップが制作できる プロトタイプツールは数多くあれど、実装にまさる忠実度の高さなし。 最近は Figma の AutoLayout や XD のスタックなど、便利な機能も登場してきていますし、プロトタイピングに関しても様々なアクションが設定できるので、非常に便利になってきました。ただ、それでも CSS や JS の表現力にはまだ届かない部分も多いかなと感じています。 ボタンを押したとき、特定の <select/> の <option/> が選択されたとき、複数条件下でのみ表示させるもの、ウインドウサイズが小さくなったときの表示など、デザインツールで実装するにはやや面倒な箇所も、コードベースなら対応可能で、デザインファイルと実装されたページでの印象差も起こりづらいです。 実際に操作できる環境を渡すことで高い精度のフィードバックをもらえる 様々なリテラシーのユーザーが使用するサービスであるからこそ、よりリアルなプロトタイプを使用し、ミスコミュニケーションを減らせました。 結果論ですが、新型コロナウィルスによって、コミュニケーションを取りにくい状況が続きましたが、挙動を忠実に再現しているので、精度の高い意見を聞けたのは良かったです。 プロダクト版のフロントエンドの実装時に、こちらの意図が伝わりやすい fontSize や space、color を theme.js ファイルにまとめておき、そこからコンポーネント側では theme 側から読み込むようにしておけば、デザインルールが把握しやすくなります。また、CSS がすでに記述されているので、プロダクト版への移植も可能となり、「デザインファイルと実装でデザインが違う」が起こりにくくなります。 Git やエディタの恩恵をフルに受けられる 一旦別ブランチでデザイン案を作る、作ったブランチの commit から cherry-pick する、過去の log を見る、特定の commit に戻るなど、Git の恩恵をフルに受けられます。また、文字列の一括検索や置換が可能なので、色味を一気に置き換えたい、どこで使われているかを探したい場合などかなり重宝しました。 とはいえいいことばかりではなかった。。。 ちょっと要素の位置を変える、などはデザインファイルのほうが全然楽。コードベースだと CSS と HTML 構造自体を書き換えないといけない React を理解していないと、動かなくなったりした時に、修正で時間を余計に使ってしまう 他のデザイナーに引き継ぎしずらい など、通常のデザインファイルでは起こらないようなデメリットもありました。 結局の所プロジェクトによって向き不向きはあります。 個人的には社内の管理システム系のように、一般的なコンポーネントを組み合わせて、色々なデータを表示する必要があるサイト制作に向いているかなと思います。 逆に、特殊なコンポーネントを量産するケースや、LP のようにグラフィック要素が多くなってくるとデザインツールのほうがはかどります。 プロジェクトの性格に応じて最適なデザイン方法を選んでいきたいですね。 デザイナーだけどコードも書きたい方や、一緒にプルリク送ってくれるデザイナーの方いらっしゃれば、ぜひメドレーで一緒に働きましょう〜 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

メドレーのデザイナー酒井です。最近、 JobMedley から CLINICS に異動しました。 自分はデザインはもちろん、HTML/CSS/JS 実装してプルリク送ったりしているちょっとフロントエンド実装領域に軸足が寄ったタイプのデザイナーです。 ここでは以前所属していた JobMedley 事業部の話をさせていただきます。 当時、JobMedley の社内システムのリニューアルプロジェクトにデザイナーとして参加していました。通常、デザイナーがデザインをするときには Skecth や Figma のようなデザインツールを利用するのが一般的かと思います。 弊社でも基本的にはデザインツールでデザインを行うことが多いのですが、プロジェクトによっては、よりリアルなモックアップが必要なため、デザイナー自身がコーディングでデザインを行い、ブラッシュアップしていくことがあります。その後、フロントエンド実装者が、デザイナーが作ったデザインを参考に、しっかりと設計されたもので作り直します。 今回のリニューアルプロジェクトのデザイン・モックアップの制作では、Figma や Sketch などのデザインツールは使用せず、React でコーディング行い、デザインを制作しています。ここが特殊な制作フローになると思うので、このエントリでは React をデザインツールとして使ったときの流れとメリット・デメリット、ちょっとニッチなポイントに絞ってお話していきます。 デザインの流れ 1.まずは React を勉強する 元々受託制作会社でデザイナーをやっていた時代に Vue.js での開発経験はありましたが、React は今回が初めてでした。そのため、一旦公式チュートリアルを一通り読み、Google などで調べつつ、基礎知識のインプットすることからはじめました。 2.ワイヤーフレームを作る さすがにワイヤーフレーム無しでコード実装には入れないので、ここでは Figma などのツールを使います。ワイヤーフレームを作り、要件定義を進めていきますが、デザインに関してもある程度のあたりを付けていきます。 3.開発環境構築 今回は Next.js で制作を行っています。 そもそも、プロダクトの実装で Next.js を使用することが決まっていたので、デザイン側も Next.js を採用しましたが、結果的に良かったなと感じています。 Next.js で作っておけば、めんどくさい router の設定やデザイナーが苦手な webpack の config を記述しなくてすみます。 また、 next build && next export で静的な HTML ファイルとして書き出されるため、サーバがあればすぐに共有が可能です。今回はエンジニアさんに、develop ブランチに merge されると、 next build && next export が走り、自動で Amazon S3 に静的ファイルをデプロイされるようにしてもらいました。 この時点でプロダクト側のフロントエンド設計も進んでいたため、ESLint やコンポーネント設計、ライブラリなどを流用し、デザインプロジェクト用に最適化させます。 4.Next.js の設計 実際にエンジニアがプロダクトを実装する際には色々なことを検討する必要があると思いますが、デザインツールとして使用する際には、逆にそこまでガチガチにしてしまうと実装に工数がかかりすぎてしまうので「割り切り」が必要になります。私が実装した際の環境は以下のようなものです。 TypeScript は入れない。要件が固まりきっていない状態で型定義をやり始めると修正に時間がかかりすぎるため。 非同期通信処理も入れない。データがほしければローカルに json ファイルを配置しておく。 デザイン側のソースコードの汚さはあまり気にしない。プロダクト版を作成するときにフロントエンドエンジニアがきれいに作り直してくれる。 コンポーネント設計を意識する。共通コンポーネントとして使用する汎用的なものは先に洗い出しておく。 テストコードは書かない。そこまでページ数が多くない上、上記のような割り切りをしているので複雑性も極端に上がらない。 Google Chrome 最新版のみ対応とする。他のブラウザは無視する。 （昨今のフロントエンド開発の流れと真逆、、、） 5.デザインルール設計 続いてデザインルールの設計を行います。 theme.js ファイルを作成し、以下を定義します。この時点で定義が完全にできていることは無いと思うので、分かる範囲で書いていきます。最終的に、不要なものを消したり、一緒にできるものは統合して定義を減らしていきます。 各コンポーネントで padding や margin の余白を数値で指定したり、色味のカラーコドをベタ打ちせず、必ず theme ファイルから値を引っ張ってくるようにします。そうすると、修正が容易になる上、あとからどこで何が使われているかを把握しやすくなります。 ■theme 内に記述する内容のイメージ fontFamily// fontFamily を定義 colors// カラーコードの一覧 spaces // 4/8/16 など余白に使う数字を定義。 fontSizes // fontSize を定義 lineHeight // lineHeight を定義 fontWeight // fontWeight を定義。 boxShadow // ドロップシャドウを使用するなら定義 6.コンポーネント設計 続いて、コンポーネントとコンポーネントに必要な props を洗い出します。 世の中には優秀な UI フレームワークが複数存在していますのでそういったものを参考にします。そういったものはほとんど同じようなコンポーネント設計になっているのでコンポーネントの分け方や受け取る props などを参考にすると作業が捗ります。 Ant Design https://ant.design/ Material-UI https://material-ui.com/ Element https://element.eleme.io/#/en-US ここで気をつけたいのは、コンポーネントの数を極力減らすように努力することです。 同一機能の別コンポーネントが複数できてしまうと、今後の機能拡張時に、どのコンポーネントを使うか迷うことになります。ほとんどのエンジニアやデザイナーにとって、コンポーネント選びで迷うことは時間の無駄です。選択肢は極力減らす努力をし、減らせないようなら使用する場所を明確に定義する必要があります。 例えば component/tab1/ component/tab2/ component/tab3/ のようにタブコンポーネントが複数あると、あとから見たときにどれを使えばいいかわからなくなりますよね。 これを許容してしまうと、知らぬ間に component/tab4/ ができあがっていることでしょう。 7.実装 まずは大枠のページテンプレートを制作します。その後、小さいコンポーネントから順に作り上げていき、ページテンプレートに配置していきます。コンポーネント化ができていれば、見た目の変更はあとから行えるので、まずは page 内に配置し、機能することを目指します。 この時点で、デザインを細部まで作り込んだとしても、結局全体を見渡してから細かく調整をかけていくと思うので、そこまでセンシティブにならずに行っていきます。 8.確認・ヒアリング・修正の繰り返し 見た目が完全にできていない状態で、確認観点を絞って、PM や、ディレクター、実際に業務で使う方々にチェックしてもらいフィードバックを受けます。 徐々にブラッシュアップしていき、完成を目指します。 デザイン中には常に以下を意識して作業することで、無駄なものを介在させない設計を目指します。 コンポーネントを共通化できないか 色数を減らせないか fontSize や lineheight などの定義を減らせないか 9.各種資料の作成 作っているデザインではエラー処理などすべてを表現しきれないので、補足資料として別途スプレッドシートなどにまとめていきます。 また、実際のコンポーネントと想定している props、実装時の注意事項などを記載した UI コンポーネント集ページを制作し、フロントエンドエンジニアと共有します。 Storybook での共有も検討しましたが、受け渡す props の想定、エンジニアへの指示、要件の補足を記載していくだけですので、Storybook ほどの機能は不要と考え、Next.js 内にシンプルな Page を作り、そこに記述する方法を選択しました。 また、デザインの設計ルールも資料化し、最終的には各種資料と、制作したコード、S3 にアップされている URL を成果物としてエンジニアに実装をしていってもらいデザインのフェーズを完了させます。 React でデザインした場合のメリット 忠実度の高いモックアップが制作できる プロトタイプツールは数多くあれど、実装にまさる忠実度の高さなし。 最近は Figma の AutoLayout や XD のスタックなど、便利な機能も登場してきていますし、プロトタイピングに関しても様々なアクションが設定できるので、非常に便利になってきました。ただ、それでも CSS や JS の表現力にはまだ届かない部分も多いかなと感じています。 ボタンを押したとき、特定の <select/> の <option/> が選択されたとき、複数条件下でのみ表示させるもの、ウインドウサイズが小さくなったときの表示など、デザインツールで実装するにはやや面倒な箇所も、コードベースなら対応可能で、デザインファイルと実装されたページでの印象差も起こりづらいです。 実際に操作できる環境を渡すことで高い精度のフィードバックをもらえる 様々なリテラシーのユーザーが使用するサービスであるからこそ、よりリアルなプロトタイプを使用し、ミスコミュニケーションを減らせました。 結果論ですが、新型コロナウィルスによって、コミュニケーションを取りにくい状況が続きましたが、挙動を忠実に再現しているので、精度の高い意見を聞けたのは良かったです。 プロダクト版のフロントエンドの実装時に、こちらの意図が伝わりやすい fontSize や space、color を theme.js ファイルにまとめておき、そこからコンポーネント側では theme 側から読み込むようにしておけば、デザインルールが把握しやすくなります。また、CSS がすでに記述されているので、プロダクト版への移植も可能となり、「デザインファイルと実装でデザインが違う」が起こりにくくなります。 Git やエディタの恩恵をフルに受けられる 一旦別ブランチでデザイン案を作る、作ったブランチの commit から cherry-pick する、過去の log を見る、特定の commit に戻るなど、Git の恩恵をフルに受けられます。また、文字列の一括検索や置換が可能なので、色味を一気に置き換えたい、どこで使われているかを探したい場合などかなり重宝しました。 とはいえいいことばかりではなかった。。。 ちょっと要素の位置を変える、などはデザインファイルのほうが全然楽。コードベースだと CSS と HTML 構造自体を書き換えないといけない React を理解していないと、動かなくなったりした時に、修正で時間を余計に使ってしまう 他のデザイナーに引き継ぎしずらい など、通常のデザインファイルでは起こらないようなデメリットもありました。 結局の所プロジェクトによって向き不向きはあります。 個人的には社内の管理システム系のように、一般的なコンポーネントを組み合わせて、色々なデータを表示する必要があるサイト制作に向いているかなと思います。 逆に、特殊なコンポーネントを量産するケースや、LP のようにグラフィック要素が多くなってくるとデザインツールのほうがはかどります。 プロジェクトの性格に応じて最適なデザイン方法を選んでいきたいですね。 デザイナーだけどコードも書きたい方や、一緒にプルリク送ってくれるデザイナーの方いらっしゃれば、ぜひメドレーで一緒に働きましょう〜 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは、メドレーのコーポレート本部法務コンプライアンス部で知的財産関連の業務を担当している鬼鞍です。コーポレート本部といっても、知財担当の仕事内容としてはエンジニア、デザイナーの方々としっかり協働することが一番大事なので、テックブログにも僭越ながら登場させていただきました。 先日、社内勉強会のテックランチにて、「特許」についてお話しする機会がありました。 今回の勉強会は、コロナウイルスの影響で全員オンライン参加という状況下でうまく伝えられるか心配だったのですが、予想以上に質問を頂いてそれなりに反響がありましたので、ここで紹介させていただこうと思います（厳密には特許権のことですがここでは説明の便宜上、以下特許と称することにします）。 みなさん、特許と聞いてどのようなイメージをもたれるでしょうか？ あなたが知財を仕事にしている人ではない限り、多くの方にとっては馴染みの薄い世界かもしれません。今回は、世間ではあまり表に出てこない特許という世界にスポットライトを当てつつ、少しでも特許の面白さみたいなものをお伝えできればと思います。 特許とは陣地に敷かれた地雷でもあり、身を守る鎧でもある さて、秒で特許のイメージをつかんでいただくためにここでは極端な例えをします。 他人が取得した特許は陣地に置かれた地雷のようなものであり、この地雷を踏んでしまうと特許権侵害というリスクで怪我をしてしまいます。あまりいい例えではないかもしれませんが、これは特許が技術を独占的に実施し、他社が実施した場合には排他できるという側面を表現しています。 企業の知財部門は、地雷を踏まないように日々特許調査をし、地雷のない安全な道を探る、いわば道先案内人のようなものなのです。 また逆に、自分たちが取得した特許があれば、地雷を踏んで権利を主張されてもカウンターパンチを当てることができるので、身を守るための鎧にもなるわけです。 特許とはエンジニア、デザイナーの成果物である ここで、特許について少し目線を変えて見てみましょう。 特許というものは、皆さんが努力・工夫した目に見えない技術的なアイディアが見える化された成果物である、という見方もできます。皆さんの頭の中にあるアイディアに知的財産権という形を与えることで、外部の人たちに明確に示すことができます。これによって、例えば投資家から高い評価を得たり、自分たちの技術力を PR するためのツールとして特許を用いることもできるのです。 特許権は国から与えられるグッドアイディア賞みたいなもの 特許については知らなくてもグッドデザイン賞についてはご存知の方が多いかもしれません。 メドレーのプロダクトであるクラウド診療システム「CLINICS」はグッドデザイン賞を受賞しています。 「 クラウド診療支援システム [CLINICS] | 受賞対象一覧 | Good Design Award 」 また、ISMS（情報セキュリティマネジメントシステム）についての認証も受けています。 「 全社で本気になってリーンに ISMS の仕組みをつくった話 」 なぜ、こんな話をしているかというと、グッドデザイン賞も ISMS も特許権も 1 つの共通点があるからです。それはいずれも客観的な審査を経て合格したものにだけ与えられてるものだという点です。 そして合格したものは、対外的に一定の信用を示すことができる、という機能を備えていいます。日本の特許庁の審査レベルは世界的に見ても高水準であると言われています。特許権というのは、その企業が技術的なアイディアに優れているという一定の信用を示すためのツールとしての性質も兼ね備えているのです。 特許に潜むリスク 先ほど特許は地雷であるという話をしました。より具体的に地雷を踏むとどんなリスクがあるのでしょうか？そのリスクは主に差し止め請求や損害賠償です。仮にこのような請求を受けてしまった場合は、大変な労力とコストが伴います。訴訟まで発展してしまうと、周囲の信用を失うことにもなりかねません。 このようなリスクを最小限にするために、知財担当の私が各プロダクトごとの開発定例に同席して自社の開発動向をキャッチアップし、他社権利の特許調査を行っています。 特許的な思考プロセスとは本質を考えること さて、ここで「特許的な思考プロセス」を使って皆さんに少し頭の体操をしていただこうと思います。 知財関連ではよく例に取り上げられるのですが、鉛筆の発明を題材にして考えてみます。 あなたは断面が円形の鉛筆を使っていましたが、机の上を転がって下へ落ちてしまうという問題点に気がつきました。あなたは、鉛筆の断面形状に着目し、断面を五角形にすることにより、この問題を解決したとしましょう。そして、「断面が五角形の鉛筆」という内容を特許請求の範囲（特許権の権利範囲部分を決めるもの）に記載して特許権を得ることができたとします。 しかし、その後、あなたの断面五角形の鉛筆を見て他の業者が断面を三角形や四角形にした鉛筆を思いつき、それが市場に多く流通し、あなたの断面五角形の鉛筆の売り上げが下がってしまいました。あなたは特許請求の範囲に何と記載すべきだったのでしょうか？ そう、あなたは「断面が五角形の鉛筆」ではなく「断面が多角形の鉛筆」と書いていれば良かったのですね。 そうすれば、三角形や四角形などの類似品の流通を防ぐことができました。これは簡単です。 その後、あなたは断面が楕円形でも、机の上を転がりにくいという効果を生み出すことに気がつきます。では、多角形も楕円形も含めるためにはどのような表現がいいのでしょうか？ちょっと考えてみてください。 あくまで答えの一例ですが、「断面が非円形の鉛筆」とか、「断面がその中心からの距離である長軸と短軸とを有する鉛筆」などの表現であれば上記の全ての形状をカバーすることができます。 このように、いくつかの具体例から、効果を生み出すために必要最低限な要素は何なのか、共通点は何なのかを探し出すことが、アイディアの本質を捉えることになります。具体と抽象の間を行ったり来たりするプロセスです。 アイディアの本質を捉えるためには多くの具体例を出す発想力が必要です。 もしあなたが発想力豊かなエンジニアやデザイナーであれば強力な特許権が取得できるかもしれません。実際にプロダクトに生かされていない技術的なアイディアというのはあなたの頭の中に埋もれていることが多いものです。 エンジニアやデザイナーの成果が報われる土壌作りに貢献したい 知的財産権の生みの親はエンジニアやデザイナーの皆さんです。皆さんはあまり意識していないかもしれませんが、技術的なアイディアは日々の開発業務で生み出されていて、それが形になるものもあればならないものもあります。 メドレーでは、これまで検討された技術アイディアのうち、プロダクトとして実現化されたものや、そうでないものにかかわらず将来性を見込めそうなものについては、実際に特許出願をしてきました。 ・ ブロックチェーンを用いた電子処方箋の管理方法（特願 2018-078928） ・ 症状チェッカー（特願 2017-011444） ・患者統合基盤（特願 2019-233247）（出願中につき概念図を IR 資料より抜粋） また、メドレーでは、エンジニア、デザイナーの方々の成果物がプロダクトだけでなく、知的財産としてもきちんと社内外で認められ、それが名誉となるような土壌作りをしていこうと考えています。 さいごに メドレーは、テクノロジーを使って医療分野のデジタル化を推進し、医療ヘルスケアの未来をつくる会社です。そんなメドレーで生み出される素晴らしい技術やデザインを知的財産という分野で可能な限りバックアップしてきたいと思っています。少しでも特許の世界を感じて頂ければ幸いです。最後までお付き合い頂きありがとうございました！

はじめに こんにちは、メドレーのコーポレート本部法務コンプライアンス部で知的財産関連の業務を担当している鬼鞍です。コーポレート本部といっても、知財担当の仕事内容としてはエンジニア、デザイナーの方々としっかり協働することが一番大事なので、テックブログにも僭越ながら登場させていただきました。 先日、社内勉強会のテックランチにて、「特許」についてお話しする機会がありました。 今回の勉強会は、コロナウイルスの影響で全員オンライン参加という状況下でうまく伝えられるか心配だったのですが、予想以上に質問を頂いてそれなりに反響がありましたので、ここで紹介させていただこうと思います（厳密には特許権のことですがここでは説明の便宜上、以下特許と称することにします）。 みなさん、特許と聞いてどのようなイメージをもたれるでしょうか？ あなたが知財を仕事にしている人ではない限り、多くの方にとっては馴染みの薄い世界かもしれません。今回は、世間ではあまり表に出てこない特許という世界にスポットライトを当てつつ、少しでも特許の面白さみたいなものをお伝えできればと思います。 特許とは陣地に敷かれた地雷でもあり、身を守る鎧でもある さて、秒で特許のイメージをつかんでいただくためにここでは極端な例えをします。 他人が取得した特許は陣地に置かれた地雷のようなものであり、この地雷を踏んでしまうと特許権侵害というリスクで怪我をしてしまいます。あまりいい例えではないかもしれませんが、これは特許が技術を独占的に実施し、他社が実施した場合には排他できるという側面を表現しています。 企業の知財部門は、地雷を踏まないように日々特許調査をし、地雷のない安全な道を探る、いわば道先案内人のようなものなのです。 また逆に、自分たちが取得した特許があれば、地雷を踏んで権利を主張されてもカウンターパンチを当てることができるので、身を守るための鎧にもなるわけです。 特許とはエンジニア、デザイナーの成果物である ここで、特許について少し目線を変えて見てみましょう。 特許というものは、皆さんが努力・工夫した目に見えない技術的なアイディアが見える化された成果物である、という見方もできます。皆さんの頭の中にあるアイディアに知的財産権という形を与えることで、外部の人たちに明確に示すことができます。これによって、例えば投資家から高い評価を得たり、自分たちの技術力を PR するためのツールとして特許を用いることもできるのです。 特許権は国から与えられるグッドアイディア賞みたいなもの 特許については知らなくてもグッドデザイン賞についてはご存知の方が多いかもしれません。 メドレーのプロダクトであるクラウド診療システム「CLINICS」はグッドデザイン賞を受賞しています。 「 クラウド診療支援システム [CLINICS] | 受賞対象一覧 | Good Design Award 」 また、ISMS（情報セキュリティマネジメントシステム）についての認証も受けています。 「 全社で本気になってリーンに ISMS の仕組みをつくった話 」 なぜ、こんな話をしているかというと、グッドデザイン賞も ISMS も特許権も 1 つの共通点があるからです。それはいずれも客観的な審査を経て合格したものにだけ与えられてるものだという点です。 そして合格したものは、対外的に一定の信用を示すことができる、という機能を備えていいます。日本の特許庁の審査レベルは世界的に見ても高水準であると言われています。特許権というのは、その企業が技術的なアイディアに優れているという一定の信用を示すためのツールとしての性質も兼ね備えているのです。 特許に潜むリスク 先ほど特許は地雷であるという話をしました。より具体的に地雷を踏むとどんなリスクがあるのでしょうか？そのリスクは主に差し止め請求や損害賠償です。仮にこのような請求を受けてしまった場合は、大変な労力とコストが伴います。訴訟まで発展してしまうと、周囲の信用を失うことにもなりかねません。 このようなリスクを最小限にするために、知財担当の私が各プロダクトごとの開発定例に同席して自社の開発動向をキャッチアップし、他社権利の特許調査を行っています。 特許的な思考プロセスとは本質を考えること さて、ここで「特許的な思考プロセス」を使って皆さんに少し頭の体操をしていただこうと思います。 知財関連ではよく例に取り上げられるのですが、鉛筆の発明を題材にして考えてみます。 あなたは断面が円形の鉛筆を使っていましたが、机の上を転がって下へ落ちてしまうという問題点に気がつきました。あなたは、鉛筆の断面形状に着目し、断面を五角形にすることにより、この問題を解決したとしましょう。そして、「断面が五角形の鉛筆」という内容を特許請求の範囲（特許権の権利範囲部分を決めるもの）に記載して特許権を得ることができたとします。 しかし、その後、あなたの断面五角形の鉛筆を見て他の業者が断面を三角形や四角形にした鉛筆を思いつき、それが市場に多く流通し、あなたの断面五角形の鉛筆の売り上げが下がってしまいました。あなたは特許請求の範囲に何と記載すべきだったのでしょうか？ そう、あなたは「断面が五角形の鉛筆」ではなく「断面が多角形の鉛筆」と書いていれば良かったのですね。 そうすれば、三角形や四角形などの類似品の流通を防ぐことができました。これは簡単です。 その後、あなたは断面が楕円形でも、机の上を転がりにくいという効果を生み出すことに気がつきます。では、多角形も楕円形も含めるためにはどのような表現がいいのでしょうか？ちょっと考えてみてください。 あくまで答えの一例ですが、「断面が非円形の鉛筆」とか、「断面がその中心からの距離である長軸と短軸とを有する鉛筆」などの表現であれば上記の全ての形状をカバーすることができます。 このように、いくつかの具体例から、効果を生み出すために必要最低限な要素は何なのか、共通点は何なのかを探し出すことが、アイディアの本質を捉えることになります。具体と抽象の間を行ったり来たりするプロセスです。 アイディアの本質を捉えるためには多くの具体例を出す発想力が必要です。 もしあなたが発想力豊かなエンジニアやデザイナーであれば強力な特許権が取得できるかもしれません。実際にプロダクトに生かされていない技術的なアイディアというのはあなたの頭の中に埋もれていることが多いものです。 エンジニアやデザイナーの成果が報われる土壌作りに貢献したい 知的財産権の生みの親はエンジニアやデザイナーの皆さんです。皆さんはあまり意識していないかもしれませんが、技術的なアイディアは日々の開発業務で生み出されていて、それが形になるものもあればならないものもあります。 メドレーでは、これまで検討された技術アイディアのうち、プロダクトとして実現化されたものや、そうでないものにかかわらず将来性を見込めそうなものについては、実際に特許出願をしてきました。 ・ ブロックチェーンを用いた電子処方箋の管理方法（特願 2018-078928） ・ 症状チェッカー（特願 2017-011444） ・患者統合基盤（特願 2019-233247）（出願中につき概念図を IR 資料より抜粋） また、メドレーでは、エンジニア、デザイナーの方々の成果物がプロダクトだけでなく、知的財産としてもきちんと社内外で認められ、それが名誉となるような土壌作りをしていこうと考えています。 さいごに メドレーは、テクノロジーを使って医療分野のデジタル化を推進し、医療ヘルスケアの未来をつくる会社です。そんなメドレーで生み出される素晴らしい技術やデザインを知的財産という分野で可能な限りバックアップしてきたいと思っています。少しでも特許の世界を感じて頂ければ幸いです。最後までお付き合い頂きありがとうございました！

はじめに こんにちは、メドレーのコーポレート本部法務コンプライアンス部で知的財産関連の業務を担当している鬼鞍です。コーポレート本部といっても、知財担当の仕事内容としてはエンジニア、デザイナーの方々としっかり協働することが一番大事なので、テックブログにも僭越ながら登場させていただきました。 先日、社内勉強会のテックランチにて、「特許」についてお話しする機会がありました。 今回の勉強会は、コロナウイルスの影響で全員オンライン参加という状況下でうまく伝えられるか心配だったのですが、予想以上に質問を頂いてそれなりに反響がありましたので、ここで紹介させていただこうと思います（厳密には特許権のことですがここでは説明の便宜上、以下特許と称することにします）。 みなさん、特許と聞いてどのようなイメージをもたれるでしょうか？ あなたが知財を仕事にしている人ではない限り、多くの方にとっては馴染みの薄い世界かもしれません。今回は、世間ではあまり表に出てこない特許という世界にスポットライトを当てつつ、少しでも特許の面白さみたいなものをお伝えできればと思います。 特許とは陣地に敷かれた地雷でもあり、身を守る鎧でもある さて、秒で特許のイメージをつかんでいただくためにここでは極端な例えをします。 他人が取得した特許は陣地に置かれた地雷のようなものであり、この地雷を踏んでしまうと特許権侵害というリスクで怪我をしてしまいます。あまりいい例えではないかもしれませんが、これは特許が技術を独占的に実施し、他社が実施した場合には排他できるという側面を表現しています。 企業の知財部門は、地雷を踏まないように日々特許調査をし、地雷のない安全な道を探る、いわば道先案内人のようなものなのです。 また逆に、自分たちが取得した特許があれば、地雷を踏んで権利を主張されてもカウンターパンチを当てることができるので、身を守るための鎧にもなるわけです。 特許とはエンジニア、デザイナーの成果物である ここで、特許について少し目線を変えて見てみましょう。 特許というものは、皆さんが努力・工夫した目に見えない技術的なアイディアが見える化された成果物である、という見方もできます。皆さんの頭の中にあるアイディアに知的財産権という形を与えることで、外部の人たちに明確に示すことができます。これによって、例えば投資家から高い評価を得たり、自分たちの技術力を PR するためのツールとして特許を用いることもできるのです。 特許権は国から与えられるグッドアイディア賞みたいなもの 特許については知らなくてもグッドデザイン賞についてはご存知の方が多いかもしれません。 メドレーのプロダクトであるクラウド診療システム「CLINICS」はグッドデザイン賞を受賞しています。 「 クラウド診療支援システム [CLINICS] | 受賞対象一覧 | Good Design Award 」 また、ISMS（情報セキュリティマネジメントシステム）についての認証も受けています。 「 全社で本気になってリーンに ISMS の仕組みをつくった話 」 なぜ、こんな話をしているかというと、グッドデザイン賞も ISMS も特許権も 1 つの共通点があるからです。それはいずれも客観的な審査を経て合格したものにだけ与えられてるものだという点です。 そして合格したものは、対外的に一定の信用を示すことができる、という機能を備えていいます。日本の特許庁の審査レベルは世界的に見ても高水準であると言われています。特許権というのは、その企業が技術的なアイディアに優れているという一定の信用を示すためのツールとしての性質も兼ね備えているのです。 特許に潜むリスク 先ほど特許は地雷であるという話をしました。より具体的に地雷を踏むとどんなリスクがあるのでしょうか？そのリスクは主に差し止め請求や損害賠償です。仮にこのような請求を受けてしまった場合は、大変な労力とコストが伴います。訴訟まで発展してしまうと、周囲の信用を失うことにもなりかねません。 このようなリスクを最小限にするために、知財担当の私が各プロダクトごとの開発定例に同席して自社の開発動向をキャッチアップし、他社権利の特許調査を行っています。 特許的な思考プロセスとは本質を考えること さて、ここで「特許的な思考プロセス」を使って皆さんに少し頭の体操をしていただこうと思います。 知財関連ではよく例に取り上げられるのですが、鉛筆の発明を題材にして考えてみます。 あなたは断面が円形の鉛筆を使っていましたが、机の上を転がって下へ落ちてしまうという問題点に気がつきました。あなたは、鉛筆の断面形状に着目し、断面を五角形にすることにより、この問題を解決したとしましょう。そして、「断面が五角形の鉛筆」という内容を特許請求の範囲（特許権の権利範囲部分を決めるもの）に記載して特許権を得ることができたとします。 しかし、その後、あなたの断面五角形の鉛筆を見て他の業者が断面を三角形や四角形にした鉛筆を思いつき、それが市場に多く流通し、あなたの断面五角形の鉛筆の売り上げが下がってしまいました。あなたは特許請求の範囲に何と記載すべきだったのでしょうか？ そう、あなたは「断面が五角形の鉛筆」ではなく「断面が多角形の鉛筆」と書いていれば良かったのですね。 そうすれば、三角形や四角形などの類似品の流通を防ぐことができました。これは簡単です。 その後、あなたは断面が楕円形でも、机の上を転がりにくいという効果を生み出すことに気がつきます。では、多角形も楕円形も含めるためにはどのような表現がいいのでしょうか？ちょっと考えてみてください。 あくまで答えの一例ですが、「断面が非円形の鉛筆」とか、「断面がその中心からの距離である長軸と短軸とを有する鉛筆」などの表現であれば上記の全ての形状をカバーすることができます。 このように、いくつかの具体例から、効果を生み出すために必要最低限な要素は何なのか、共通点は何なのかを探し出すことが、アイディアの本質を捉えることになります。具体と抽象の間を行ったり来たりするプロセスです。 アイディアの本質を捉えるためには多くの具体例を出す発想力が必要です。 もしあなたが発想力豊かなエンジニアやデザイナーであれば強力な特許権が取得できるかもしれません。実際にプロダクトに生かされていない技術的なアイディアというのはあなたの頭の中に埋もれていることが多いものです。 エンジニアやデザイナーの成果が報われる土壌作りに貢献したい 知的財産権の生みの親はエンジニアやデザイナーの皆さんです。皆さんはあまり意識していないかもしれませんが、技術的なアイディアは日々の開発業務で生み出されていて、それが形になるものもあればならないものもあります。 メドレーでは、これまで検討された技術アイディアのうち、プロダクトとして実現化されたものや、そうでないものにかかわらず将来性を見込めそうなものについては、実際に特許出願をしてきました。 ・ ブロックチェーンを用いた電子処方箋の管理方法（特願 2018-078928） ・ 症状チェッカー（特願 2017-011444） ・患者統合基盤（特願 2019-233247）（出願中につき概念図を IR 資料より抜粋） また、メドレーでは、エンジニア、デザイナーの方々の成果物がプロダクトだけでなく、知的財産としてもきちんと社内外で認められ、それが名誉となるような土壌作りをしていこうと考えています。 さいごに メドレーは、テクノロジーを使って医療分野のデジタル化を推進し、医療ヘルスケアの未来をつくる会社です。そんなメドレーで生み出される素晴らしい技術やデザインを知的財産という分野で可能な限りバックアップしてきたいと思っています。少しでも特許の世界を感じて頂ければ幸いです。最後までお付き合い頂きありがとうございました！

はじめに こんにちは、メドレーのコーポレート本部法務コンプライアンス部で知的財産関連の業務を担当している鬼鞍です。コーポレート本部といっても、知財担当の仕事内容としてはエンジニア、デザイナーの方々としっかり協働することが一番大事なので、テックブログにも僭越ながら登場させていただきました。 先日、社内勉強会のテックランチにて、「特許」についてお話しする機会がありました。 今回の勉強会は、コロナウイルスの影響で全員オンライン参加という状況下でうまく伝えられるか心配だったのですが、予想以上に質問を頂いてそれなりに反響がありましたので、ここで紹介させていただこうと思います（厳密には特許権のことですがここでは説明の便宜上、以下特許と称することにします）。 みなさん、特許と聞いてどのようなイメージをもたれるでしょうか？ あなたが知財を仕事にしている人ではない限り、多くの方にとっては馴染みの薄い世界かもしれません。今回は、世間ではあまり表に出てこない特許という世界にスポットライトを当てつつ、少しでも特許の面白さみたいなものをお伝えできればと思います。 特許とは陣地に敷かれた地雷でもあり、身を守る鎧でもある さて、秒で特許のイメージをつかんでいただくためにここでは極端な例えをします。 他人が取得した特許は陣地に置かれた地雷のようなものであり、この地雷を踏んでしまうと特許権侵害というリスクで怪我をしてしまいます。あまりいい例えではないかもしれませんが、これは特許が技術を独占的に実施し、他社が実施した場合には排他できるという側面を表現しています。 企業の知財部門は、地雷を踏まないように日々特許調査をし、地雷のない安全な道を探る、いわば道先案内人のようなものなのです。 また逆に、自分たちが取得した特許があれば、地雷を踏んで権利を主張されてもカウンターパンチを当てることができるので、身を守るための鎧にもなるわけです。 特許とはエンジニア、デザイナーの成果物である ここで、特許について少し目線を変えて見てみましょう。 特許というものは、皆さんが努力・工夫した目に見えない技術的なアイディアが見える化された成果物である、という見方もできます。皆さんの頭の中にあるアイディアに知的財産権という形を与えることで、外部の人たちに明確に示すことができます。これによって、例えば投資家から高い評価を得たり、自分たちの技術力を PR するためのツールとして特許を用いることもできるのです。 特許権は国から与えられるグッドアイディア賞みたいなもの 特許については知らなくてもグッドデザイン賞についてはご存知の方が多いかもしれません。 メドレーのプロダクトであるクラウド診療システム「CLINICS」はグッドデザイン賞を受賞しています。 「 クラウド診療支援システム [CLINICS] | 受賞対象一覧 | Good Design Award 」 また、ISMS（情報セキュリティマネジメントシステム）についての認証も受けています。 「 全社で本気になってリーンに ISMS の仕組みをつくった話 」 なぜ、こんな話をしているかというと、グッドデザイン賞も ISMS も特許権も 1 つの共通点があるからです。それはいずれも客観的な審査を経て合格したものにだけ与えられてるものだという点です。 そして合格したものは、対外的に一定の信用を示すことができる、という機能を備えていいます。日本の特許庁の審査レベルは世界的に見ても高水準であると言われています。特許権というのは、その企業が技術的なアイディアに優れているという一定の信用を示すためのツールとしての性質も兼ね備えているのです。 特許に潜むリスク 先ほど特許は地雷であるという話をしました。より具体的に地雷を踏むとどんなリスクがあるのでしょうか？そのリスクは主に差し止め請求や損害賠償です。仮にこのような請求を受けてしまった場合は、大変な労力とコストが伴います。訴訟まで発展してしまうと、周囲の信用を失うことにもなりかねません。 このようなリスクを最小限にするために、知財担当の私が各プロダクトごとの開発定例に同席して自社の開発動向をキャッチアップし、他社権利の特許調査を行っています。 特許的な思考プロセスとは本質を考えること さて、ここで「特許的な思考プロセス」を使って皆さんに少し頭の体操をしていただこうと思います。 知財関連ではよく例に取り上げられるのですが、鉛筆の発明を題材にして考えてみます。 あなたは断面が円形の鉛筆を使っていましたが、机の上を転がって下へ落ちてしまうという問題点に気がつきました。あなたは、鉛筆の断面形状に着目し、断面を五角形にすることにより、この問題を解決したとしましょう。そして、「断面が五角形の鉛筆」という内容を特許請求の範囲（特許権の権利範囲部分を決めるもの）に記載して特許権を得ることができたとします。 しかし、その後、あなたの断面五角形の鉛筆を見て他の業者が断面を三角形や四角形にした鉛筆を思いつき、それが市場に多く流通し、あなたの断面五角形の鉛筆の売り上げが下がってしまいました。あなたは特許請求の範囲に何と記載すべきだったのでしょうか？ そう、あなたは「断面が五角形の鉛筆」ではなく「断面が多角形の鉛筆」と書いていれば良かったのですね。 そうすれば、三角形や四角形などの類似品の流通を防ぐことができました。これは簡単です。 その後、あなたは断面が楕円形でも、机の上を転がりにくいという効果を生み出すことに気がつきます。では、多角形も楕円形も含めるためにはどのような表現がいいのでしょうか？ちょっと考えてみてください。 あくまで答えの一例ですが、「断面が非円形の鉛筆」とか、「断面がその中心からの距離である長軸と短軸とを有する鉛筆」などの表現であれば上記の全ての形状をカバーすることができます。 このように、いくつかの具体例から、効果を生み出すために必要最低限な要素は何なのか、共通点は何なのかを探し出すことが、アイディアの本質を捉えることになります。具体と抽象の間を行ったり来たりするプロセスです。 アイディアの本質を捉えるためには多くの具体例を出す発想力が必要です。 もしあなたが発想力豊かなエンジニアやデザイナーであれば強力な特許権が取得できるかもしれません。実際にプロダクトに生かされていない技術的なアイディアというのはあなたの頭の中に埋もれていることが多いものです。 エンジニアやデザイナーの成果が報われる土壌作りに貢献したい 知的財産権の生みの親はエンジニアやデザイナーの皆さんです。皆さんはあまり意識していないかもしれませんが、技術的なアイディアは日々の開発業務で生み出されていて、それが形になるものもあればならないものもあります。 メドレーでは、これまで検討された技術アイディアのうち、プロダクトとして実現化されたものや、そうでないものにかかわらず将来性を見込めそうなものについては、実際に特許出願をしてきました。 ・ ブロックチェーンを用いた電子処方箋の管理方法（特願 2018-078928） ・ 症状チェッカー（特願 2017-011444） ・患者統合基盤（特願 2019-233247）（出願中につき概念図を IR 資料より抜粋） また、メドレーでは、エンジニア、デザイナーの方々の成果物がプロダクトだけでなく、知的財産としてもきちんと社内外で認められ、それが名誉となるような土壌作りをしていこうと考えています。 さいごに メドレーは、テクノロジーを使って医療分野のデジタル化を推進し、医療ヘルスケアの未来をつくる会社です。そんなメドレーで生み出される素晴らしい技術やデザインを知的財産という分野で可能な限りバックアップしてきたいと思っています。少しでも特許の世界を感じて頂ければ幸いです。最後までお付き合い頂きありがとうございました！

はじめに こんにちは、メドレーのコーポレート本部法務コンプライアンス部で知的財産関連の業務を担当している鬼鞍です。コーポレート本部といっても、知財担当の仕事内容としてはエンジニア、デザイナーの方々としっかり協働することが一番大事なので、テックブログにも僭越ながら登場させていただきました。 先日、社内勉強会のテックランチにて、「特許」についてお話しする機会がありました。 今回の勉強会は、コロナウイルスの影響で全員オンライン参加という状況下でうまく伝えられるか心配だったのですが、予想以上に質問を頂いてそれなりに反響がありましたので、ここで紹介させていただこうと思います（厳密には特許権のことですがここでは説明の便宜上、以下特許と称することにします）。 みなさん、特許と聞いてどのようなイメージをもたれるでしょうか？ あなたが知財を仕事にしている人ではない限り、多くの方にとっては馴染みの薄い世界かもしれません。今回は、世間ではあまり表に出てこない特許という世界にスポットライトを当てつつ、少しでも特許の面白さみたいなものをお伝えできればと思います。 特許とは陣地に敷かれた地雷でもあり、身を守る鎧でもある さて、秒で特許のイメージをつかんでいただくためにここでは極端な例えをします。 他人が取得した特許は陣地に置かれた地雷のようなものであり、この地雷を踏んでしまうと特許権侵害というリスクで怪我をしてしまいます。あまりいい例えではないかもしれませんが、これは特許が技術を独占的に実施し、他社が実施した場合には排他できるという側面を表現しています。 企業の知財部門は、地雷を踏まないように日々特許調査をし、地雷のない安全な道を探る、いわば道先案内人のようなものなのです。 また逆に、自分たちが取得した特許があれば、地雷を踏んで権利を主張されてもカウンターパンチを当てることができるので、身を守るための鎧にもなるわけです。 特許とはエンジニア、デザイナーの成果物である ここで、特許について少し目線を変えて見てみましょう。 特許というものは、皆さんが努力・工夫した目に見えない技術的なアイディアが見える化された成果物である、という見方もできます。皆さんの頭の中にあるアイディアに知的財産権という形を与えることで、外部の人たちに明確に示すことができます。これによって、例えば投資家から高い評価を得たり、自分たちの技術力を PR するためのツールとして特許を用いることもできるのです。 特許権は国から与えられるグッドアイディア賞みたいなもの 特許については知らなくてもグッドデザイン賞についてはご存知の方が多いかもしれません。 メドレーのプロダクトであるクラウド診療システム「CLINICS」はグッドデザイン賞を受賞しています。 「 クラウド診療支援システム [CLINICS] | 受賞対象一覧 | Good Design Award 」 また、ISMS（情報セキュリティマネジメントシステム）についての認証も受けています。 「 全社で本気になってリーンに ISMS の仕組みをつくった話 」 なぜ、こんな話をしているかというと、グッドデザイン賞も ISMS も特許権も 1 つの共通点があるからです。それはいずれも客観的な審査を経て合格したものにだけ与えられてるものだという点です。 そして合格したものは、対外的に一定の信用を示すことができる、という機能を備えていいます。日本の特許庁の審査レベルは世界的に見ても高水準であると言われています。特許権というのは、その企業が技術的なアイディアに優れているという一定の信用を示すためのツールとしての性質も兼ね備えているのです。 特許に潜むリスク 先ほど特許は地雷であるという話をしました。より具体的に地雷を踏むとどんなリスクがあるのでしょうか？そのリスクは主に差し止め請求や損害賠償です。仮にこのような請求を受けてしまった場合は、大変な労力とコストが伴います。訴訟まで発展してしまうと、周囲の信用を失うことにもなりかねません。 このようなリスクを最小限にするために、知財担当の私が各プロダクトごとの開発定例に同席して自社の開発動向をキャッチアップし、他社権利の特許調査を行っています。 特許的な思考プロセスとは本質を考えること さて、ここで「特許的な思考プロセス」を使って皆さんに少し頭の体操をしていただこうと思います。 知財関連ではよく例に取り上げられるのですが、鉛筆の発明を題材にして考えてみます。 あなたは断面が円形の鉛筆を使っていましたが、机の上を転がって下へ落ちてしまうという問題点に気がつきました。あなたは、鉛筆の断面形状に着目し、断面を五角形にすることにより、この問題を解決したとしましょう。そして、「断面が五角形の鉛筆」という内容を特許請求の範囲（特許権の権利範囲部分を決めるもの）に記載して特許権を得ることができたとします。 しかし、その後、あなたの断面五角形の鉛筆を見て他の業者が断面を三角形や四角形にした鉛筆を思いつき、それが市場に多く流通し、あなたの断面五角形の鉛筆の売り上げが下がってしまいました。あなたは特許請求の範囲に何と記載すべきだったのでしょうか？ そう、あなたは「断面が五角形の鉛筆」ではなく「断面が多角形の鉛筆」と書いていれば良かったのですね。 そうすれば、三角形や四角形などの類似品の流通を防ぐことができました。これは簡単です。 その後、あなたは断面が楕円形でも、机の上を転がりにくいという効果を生み出すことに気がつきます。では、多角形も楕円形も含めるためにはどのような表現がいいのでしょうか？ちょっと考えてみてください。 あくまで答えの一例ですが、「断面が非円形の鉛筆」とか、「断面がその中心からの距離である長軸と短軸とを有する鉛筆」などの表現であれば上記の全ての形状をカバーすることができます。 このように、いくつかの具体例から、効果を生み出すために必要最低限な要素は何なのか、共通点は何なのかを探し出すことが、アイディアの本質を捉えることになります。具体と抽象の間を行ったり来たりするプロセスです。 アイディアの本質を捉えるためには多くの具体例を出す発想力が必要です。 もしあなたが発想力豊かなエンジニアやデザイナーであれば強力な特許権が取得できるかもしれません。実際にプロダクトに生かされていない技術的なアイディアというのはあなたの頭の中に埋もれていることが多いものです。 エンジニアやデザイナーの成果が報われる土壌作りに貢献したい 知的財産権の生みの親はエンジニアやデザイナーの皆さんです。皆さんはあまり意識していないかもしれませんが、技術的なアイディアは日々の開発業務で生み出されていて、それが形になるものもあればならないものもあります。 メドレーでは、これまで検討された技術アイディアのうち、プロダクトとして実現化されたものや、そうでないものにかかわらず将来性を見込めそうなものについては、実際に特許出願をしてきました。 ・ ブロックチェーンを用いた電子処方箋の管理方法（特願 2018-078928） ・ 症状チェッカー（特願 2017-011444） ・患者統合基盤（特願 2019-233247）（出願中につき概念図を IR 資料より抜粋） また、メドレーでは、エンジニア、デザイナーの方々の成果物がプロダクトだけでなく、知的財産としてもきちんと社内外で認められ、それが名誉となるような土壌作りをしていこうと考えています。 さいごに メドレーは、テクノロジーを使って医療分野のデジタル化を推進し、医療ヘルスケアの未来をつくる会社です。そんなメドレーで生み出される素晴らしい技術やデザインを知的財産という分野で可能な限りバックアップしてきたいと思っています。少しでも特許の世界を感じて頂ければ幸いです。最後までお付き合い頂きありがとうございました！

はじめに こんにちは、メドレーのコーポレート本部法務コンプライアンス部で知的財産関連の業務を担当している鬼鞍です。コーポレート本部といっても、知財担当の仕事内容としてはエンジニア、デザイナーの方々としっかり協働することが一番大事なので、テックブログにも僭越ながら登場させていただきました。 先日、社内勉強会のテックランチにて、「特許」についてお話しする機会がありました。 今回の勉強会は、コロナウイルスの影響で全員オンライン参加という状況下でうまく伝えられるか心配だったのですが、予想以上に質問を頂いてそれなりに反響がありましたので、ここで紹介させていただこうと思います（厳密には特許権のことですがここでは説明の便宜上、以下特許と称することにします）。 みなさん、特許と聞いてどのようなイメージをもたれるでしょうか？ あなたが知財を仕事にしている人ではない限り、多くの方にとっては馴染みの薄い世界かもしれません。今回は、世間ではあまり表に出てこない特許という世界にスポットライトを当てつつ、少しでも特許の面白さみたいなものをお伝えできればと思います。 特許とは陣地に敷かれた地雷でもあり、身を守る鎧でもある さて、秒で特許のイメージをつかんでいただくためにここでは極端な例えをします。 他人が取得した特許は陣地に置かれた地雷のようなものであり、この地雷を踏んでしまうと特許権侵害というリスクで怪我をしてしまいます。あまりいい例えではないかもしれませんが、これは特許が技術を独占的に実施し、他社が実施した場合には排他できるという側面を表現しています。 企業の知財部門は、地雷を踏まないように日々特許調査をし、地雷のない安全な道を探る、いわば道先案内人のようなものなのです。 また逆に、自分たちが取得した特許があれば、地雷を踏んで権利を主張されてもカウンターパンチを当てることができるので、身を守るための鎧にもなるわけです。 特許とはエンジニア、デザイナーの成果物である ここで、特許について少し目線を変えて見てみましょう。 特許というものは、皆さんが努力・工夫した目に見えない技術的なアイディアが見える化された成果物である、という見方もできます。皆さんの頭の中にあるアイディアに知的財産権という形を与えることで、外部の人たちに明確に示すことができます。これによって、例えば投資家から高い評価を得たり、自分たちの技術力を PR するためのツールとして特許を用いることもできるのです。 特許権は国から与えられるグッドアイディア賞みたいなもの 特許については知らなくてもグッドデザイン賞についてはご存知の方が多いかもしれません。 メドレーのプロダクトであるクラウド診療システム「CLINICS」はグッドデザイン賞を受賞しています。 「 クラウド診療支援システム [CLINICS] | 受賞対象一覧 | Good Design Award 」 また、ISMS（情報セキュリティマネジメントシステム）についての認証も受けています。 「 全社で本気になってリーンに ISMS の仕組みをつくった話 」 なぜ、こんな話をしているかというと、グッドデザイン賞も ISMS も特許権も 1 つの共通点があるからです。それはいずれも客観的な審査を経て合格したものにだけ与えられてるものだという点です。 そして合格したものは、対外的に一定の信用を示すことができる、という機能を備えていいます。日本の特許庁の審査レベルは世界的に見ても高水準であると言われています。特許権というのは、その企業が技術的なアイディアに優れているという一定の信用を示すためのツールとしての性質も兼ね備えているのです。 特許に潜むリスク 先ほど特許は地雷であるという話をしました。より具体的に地雷を踏むとどんなリスクがあるのでしょうか？そのリスクは主に差し止め請求や損害賠償です。仮にこのような請求を受けてしまった場合は、大変な労力とコストが伴います。訴訟まで発展してしまうと、周囲の信用を失うことにもなりかねません。 このようなリスクを最小限にするために、知財担当の私が各プロダクトごとの開発定例に同席して自社の開発動向をキャッチアップし、他社権利の特許調査を行っています。 特許的な思考プロセスとは本質を考えること さて、ここで「特許的な思考プロセス」を使って皆さんに少し頭の体操をしていただこうと思います。 知財関連ではよく例に取り上げられるのですが、鉛筆の発明を題材にして考えてみます。 あなたは断面が円形の鉛筆を使っていましたが、机の上を転がって下へ落ちてしまうという問題点に気がつきました。あなたは、鉛筆の断面形状に着目し、断面を五角形にすることにより、この問題を解決したとしましょう。そして、「断面が五角形の鉛筆」という内容を特許請求の範囲（特許権の権利範囲部分を決めるもの）に記載して特許権を得ることができたとします。 しかし、その後、あなたの断面五角形の鉛筆を見て他の業者が断面を三角形や四角形にした鉛筆を思いつき、それが市場に多く流通し、あなたの断面五角形の鉛筆の売り上げが下がってしまいました。あなたは特許請求の範囲に何と記載すべきだったのでしょうか？ そう、あなたは「断面が五角形の鉛筆」ではなく「断面が多角形の鉛筆」と書いていれば良かったのですね。 そうすれば、三角形や四角形などの類似品の流通を防ぐことができました。これは簡単です。 その後、あなたは断面が楕円形でも、机の上を転がりにくいという効果を生み出すことに気がつきます。では、多角形も楕円形も含めるためにはどのような表現がいいのでしょうか？ちょっと考えてみてください。 あくまで答えの一例ですが、「断面が非円形の鉛筆」とか、「断面がその中心からの距離である長軸と短軸とを有する鉛筆」などの表現であれば上記の全ての形状をカバーすることができます。 このように、いくつかの具体例から、効果を生み出すために必要最低限な要素は何なのか、共通点は何なのかを探し出すことが、アイディアの本質を捉えることになります。具体と抽象の間を行ったり来たりするプロセスです。 アイディアの本質を捉えるためには多くの具体例を出す発想力が必要です。 もしあなたが発想力豊かなエンジニアやデザイナーであれば強力な特許権が取得できるかもしれません。実際にプロダクトに生かされていない技術的なアイディアというのはあなたの頭の中に埋もれていることが多いものです。 エンジニアやデザイナーの成果が報われる土壌作りに貢献したい 知的財産権の生みの親はエンジニアやデザイナーの皆さんです。皆さんはあまり意識していないかもしれませんが、技術的なアイディアは日々の開発業務で生み出されていて、それが形になるものもあればならないものもあります。 メドレーでは、これまで検討された技術アイディアのうち、プロダクトとして実現化されたものや、そうでないものにかかわらず将来性を見込めそうなものについては、実際に特許出願をしてきました。 ・ ブロックチェーンを用いた電子処方箋の管理方法（特願 2018-078928） ・ 症状チェッカー（特願 2017-011444） ・患者統合基盤（特願 2019-233247）（出願中につき概念図を IR 資料より抜粋） また、メドレーでは、エンジニア、デザイナーの方々の成果物がプロダクトだけでなく、知的財産としてもきちんと社内外で認められ、それが名誉となるような土壌作りをしていこうと考えています。 さいごに メドレーは、テクノロジーを使って医療分野のデジタル化を推進し、医療ヘルスケアの未来をつくる会社です。そんなメドレーで生み出される素晴らしい技術やデザインを知的財産という分野で可能な限りバックアップしてきたいと思っています。少しでも特許の世界を感じて頂ければ幸いです。最後までお付き合い頂きありがとうございました！

はじめに こんにちは、メドレーのコーポレート本部法務コンプライアンス部で知的財産関連の業務を担当している鬼鞍です。コーポレート本部といっても、知財担当の仕事内容としてはエンジニア、デザイナーの方々としっかり協働することが一番大事なので、テックブログにも僭越ながら登場させていただきました。 先日、社内勉強会のテックランチにて、「特許」についてお話しする機会がありました。 今回の勉強会は、コロナウイルスの影響で全員オンライン参加という状況下でうまく伝えられるか心配だったのですが、予想以上に質問を頂いてそれなりに反響がありましたので、ここで紹介させていただこうと思います（厳密には特許権のことですがここでは説明の便宜上、以下特許と称することにします）。 みなさん、特許と聞いてどのようなイメージをもたれるでしょうか？ あなたが知財を仕事にしている人ではない限り、多くの方にとっては馴染みの薄い世界かもしれません。今回は、世間ではあまり表に出てこない特許という世界にスポットライトを当てつつ、少しでも特許の面白さみたいなものをお伝えできればと思います。 特許とは陣地に敷かれた地雷でもあり、身を守る鎧でもある さて、秒で特許のイメージをつかんでいただくためにここでは極端な例えをします。 他人が取得した特許は陣地に置かれた地雷のようなものであり、この地雷を踏んでしまうと特許権侵害というリスクで怪我をしてしまいます。あまりいい例えではないかもしれませんが、これは特許が技術を独占的に実施し、他社が実施した場合には排他できるという側面を表現しています。 企業の知財部門は、地雷を踏まないように日々特許調査をし、地雷のない安全な道を探る、いわば道先案内人のようなものなのです。 また逆に、自分たちが取得した特許があれば、地雷を踏んで権利を主張されてもカウンターパンチを当てることができるので、身を守るための鎧にもなるわけです。 特許とはエンジニア、デザイナーの成果物である ここで、特許について少し目線を変えて見てみましょう。 特許というものは、皆さんが努力・工夫した目に見えない技術的なアイディアが見える化された成果物である、という見方もできます。皆さんの頭の中にあるアイディアに知的財産権という形を与えることで、外部の人たちに明確に示すことができます。これによって、例えば投資家から高い評価を得たり、自分たちの技術力を PR するためのツールとして特許を用いることもできるのです。 特許権は国から与えられるグッドアイディア賞みたいなもの 特許については知らなくてもグッドデザイン賞についてはご存知の方が多いかもしれません。 メドレーのプロダクトであるクラウド診療システム「CLINICS」はグッドデザイン賞を受賞しています。 「 クラウド診療支援システム [CLINICS] | 受賞対象一覧 | Good Design Award 」 また、ISMS（情報セキュリティマネジメントシステム）についての認証も受けています。 「 全社で本気になってリーンに ISMS の仕組みをつくった話 」 なぜ、こんな話をしているかというと、グッドデザイン賞も ISMS も特許権も 1 つの共通点があるからです。それはいずれも客観的な審査を経て合格したものにだけ与えられてるものだという点です。 そして合格したものは、対外的に一定の信用を示すことができる、という機能を備えていいます。日本の特許庁の審査レベルは世界的に見ても高水準であると言われています。特許権というのは、その企業が技術的なアイディアに優れているという一定の信用を示すためのツールとしての性質も兼ね備えているのです。 特許に潜むリスク 先ほど特許は地雷であるという話をしました。より具体的に地雷を踏むとどんなリスクがあるのでしょうか？そのリスクは主に差し止め請求や損害賠償です。仮にこのような請求を受けてしまった場合は、大変な労力とコストが伴います。訴訟まで発展してしまうと、周囲の信用を失うことにもなりかねません。 このようなリスクを最小限にするために、知財担当の私が各プロダクトごとの開発定例に同席して自社の開発動向をキャッチアップし、他社権利の特許調査を行っています。 特許的な思考プロセスとは本質を考えること さて、ここで「特許的な思考プロセス」を使って皆さんに少し頭の体操をしていただこうと思います。 知財関連ではよく例に取り上げられるのですが、鉛筆の発明を題材にして考えてみます。 あなたは断面が円形の鉛筆を使っていましたが、机の上を転がって下へ落ちてしまうという問題点に気がつきました。あなたは、鉛筆の断面形状に着目し、断面を五角形にすることにより、この問題を解決したとしましょう。そして、「断面が五角形の鉛筆」という内容を特許請求の範囲（特許権の権利範囲部分を決めるもの）に記載して特許権を得ることができたとします。 しかし、その後、あなたの断面五角形の鉛筆を見て他の業者が断面を三角形や四角形にした鉛筆を思いつき、それが市場に多く流通し、あなたの断面五角形の鉛筆の売り上げが下がってしまいました。あなたは特許請求の範囲に何と記載すべきだったのでしょうか？ そう、あなたは「断面が五角形の鉛筆」ではなく「断面が多角形の鉛筆」と書いていれば良かったのですね。 そうすれば、三角形や四角形などの類似品の流通を防ぐことができました。これは簡単です。 その後、あなたは断面が楕円形でも、机の上を転がりにくいという効果を生み出すことに気がつきます。では、多角形も楕円形も含めるためにはどのような表現がいいのでしょうか？ちょっと考えてみてください。 あくまで答えの一例ですが、「断面が非円形の鉛筆」とか、「断面がその中心からの距離である長軸と短軸とを有する鉛筆」などの表現であれば上記の全ての形状をカバーすることができます。 このように、いくつかの具体例から、効果を生み出すために必要最低限な要素は何なのか、共通点は何なのかを探し出すことが、アイディアの本質を捉えることになります。具体と抽象の間を行ったり来たりするプロセスです。 アイディアの本質を捉えるためには多くの具体例を出す発想力が必要です。 もしあなたが発想力豊かなエンジニアやデザイナーであれば強力な特許権が取得できるかもしれません。実際にプロダクトに生かされていない技術的なアイディアというのはあなたの頭の中に埋もれていることが多いものです。 エンジニアやデザイナーの成果が報われる土壌作りに貢献したい 知的財産権の生みの親はエンジニアやデザイナーの皆さんです。皆さんはあまり意識していないかもしれませんが、技術的なアイディアは日々の開発業務で生み出されていて、それが形になるものもあればならないものもあります。 メドレーでは、これまで検討された技術アイディアのうち、プロダクトとして実現化されたものや、そうでないものにかかわらず将来性を見込めそうなものについては、実際に特許出願をしてきました。 ・ ブロックチェーンを用いた電子処方箋の管理方法（特願 2018-078928） ・ 症状チェッカー（特願 2017-011444） ・患者統合基盤（特願 2019-233247）（出願中につき概念図を IR 資料より抜粋） また、メドレーでは、エンジニア、デザイナーの方々の成果物がプロダクトだけでなく、知的財産としてもきちんと社内外で認められ、それが名誉となるような土壌作りをしていこうと考えています。 さいごに メドレーは、テクノロジーを使って医療分野のデジタル化を推進し、医療ヘルスケアの未来をつくる会社です。そんなメドレーで生み出される素晴らしい技術やデザインを知的財産という分野で可能な限りバックアップしてきたいと思っています。少しでも特許の世界を感じて頂ければ幸いです。最後までお付き合い頂きありがとうございました！

はじめに こんにちは、メドレーのコーポレート本部法務コンプライアンス部で知的財産関連の業務を担当している鬼鞍です。コーポレート本部といっても、知財担当の仕事内容としてはエンジニア、デザイナーの方々としっかり協働することが一番大事なので、テックブログにも僭越ながら登場させていただきました。 先日、社内勉強会のテックランチにて、「特許」についてお話しする機会がありました。 今回の勉強会は、コロナウイルスの影響で全員オンライン参加という状況下でうまく伝えられるか心配だったのですが、予想以上に質問を頂いてそれなりに反響がありましたので、ここで紹介させていただこうと思います（厳密には特許権のことですがここでは説明の便宜上、以下特許と称することにします）。 みなさん、特許と聞いてどのようなイメージをもたれるでしょうか？ あなたが知財を仕事にしている人ではない限り、多くの方にとっては馴染みの薄い世界かもしれません。今回は、世間ではあまり表に出てこない特許という世界にスポットライトを当てつつ、少しでも特許の面白さみたいなものをお伝えできればと思います。 特許とは陣地に敷かれた地雷でもあり、身を守る鎧でもある さて、秒で特許のイメージをつかんでいただくためにここでは極端な例えをします。 他人が取得した特許は陣地に置かれた地雷のようなものであり、この地雷を踏んでしまうと特許権侵害というリスクで怪我をしてしまいます。あまりいい例えではないかもしれませんが、これは特許が技術を独占的に実施し、他社が実施した場合には排他できるという側面を表現しています。 企業の知財部門は、地雷を踏まないように日々特許調査をし、地雷のない安全な道を探る、いわば道先案内人のようなものなのです。 また逆に、自分たちが取得した特許があれば、地雷を踏んで権利を主張されてもカウンターパンチを当てることができるので、身を守るための鎧にもなるわけです。 特許とはエンジニア、デザイナーの成果物である ここで、特許について少し目線を変えて見てみましょう。 特許というものは、皆さんが努力・工夫した目に見えない技術的なアイディアが見える化された成果物である、という見方もできます。皆さんの頭の中にあるアイディアに知的財産権という形を与えることで、外部の人たちに明確に示すことができます。これによって、例えば投資家から高い評価を得たり、自分たちの技術力を PR するためのツールとして特許を用いることもできるのです。 特許権は国から与えられるグッドアイディア賞みたいなもの 特許については知らなくてもグッドデザイン賞についてはご存知の方が多いかもしれません。 メドレーのプロダクトであるクラウド診療システム「CLINICS」はグッドデザイン賞を受賞しています。 「 クラウド診療支援システム [CLINICS] | 受賞対象一覧 | Good Design Award 」 また、ISMS（情報セキュリティマネジメントシステム）についての認証も受けています。 「 全社で本気になってリーンに ISMS の仕組みをつくった話 」 なぜ、こんな話をしているかというと、グッドデザイン賞も ISMS も特許権も 1 つの共通点があるからです。それはいずれも客観的な審査を経て合格したものにだけ与えられてるものだという点です。 そして合格したものは、対外的に一定の信用を示すことができる、という機能を備えていいます。日本の特許庁の審査レベルは世界的に見ても高水準であると言われています。特許権というのは、その企業が技術的なアイディアに優れているという一定の信用を示すためのツールとしての性質も兼ね備えているのです。 特許に潜むリスク 先ほど特許は地雷であるという話をしました。より具体的に地雷を踏むとどんなリスクがあるのでしょうか？そのリスクは主に差し止め請求や損害賠償です。仮にこのような請求を受けてしまった場合は、大変な労力とコストが伴います。訴訟まで発展してしまうと、周囲の信用を失うことにもなりかねません。 このようなリスクを最小限にするために、知財担当の私が各プロダクトごとの開発定例に同席して自社の開発動向をキャッチアップし、他社権利の特許調査を行っています。 特許的な思考プロセスとは本質を考えること さて、ここで「特許的な思考プロセス」を使って皆さんに少し頭の体操をしていただこうと思います。 知財関連ではよく例に取り上げられるのですが、鉛筆の発明を題材にして考えてみます。 あなたは断面が円形の鉛筆を使っていましたが、机の上を転がって下へ落ちてしまうという問題点に気がつきました。あなたは、鉛筆の断面形状に着目し、断面を五角形にすることにより、この問題を解決したとしましょう。そして、「断面が五角形の鉛筆」という内容を特許請求の範囲（特許権の権利範囲部分を決めるもの）に記載して特許権を得ることができたとします。 しかし、その後、あなたの断面五角形の鉛筆を見て他の業者が断面を三角形や四角形にした鉛筆を思いつき、それが市場に多く流通し、あなたの断面五角形の鉛筆の売り上げが下がってしまいました。あなたは特許請求の範囲に何と記載すべきだったのでしょうか？ そう、あなたは「断面が五角形の鉛筆」ではなく「断面が多角形の鉛筆」と書いていれば良かったのですね。 そうすれば、三角形や四角形などの類似品の流通を防ぐことができました。これは簡単です。 その後、あなたは断面が楕円形でも、机の上を転がりにくいという効果を生み出すことに気がつきます。では、多角形も楕円形も含めるためにはどのような表現がいいのでしょうか？ちょっと考えてみてください。 あくまで答えの一例ですが、「断面が非円形の鉛筆」とか、「断面がその中心からの距離である長軸と短軸とを有する鉛筆」などの表現であれば上記の全ての形状をカバーすることができます。 このように、いくつかの具体例から、効果を生み出すために必要最低限な要素は何なのか、共通点は何なのかを探し出すことが、アイディアの本質を捉えることになります。具体と抽象の間を行ったり来たりするプロセスです。 アイディアの本質を捉えるためには多くの具体例を出す発想力が必要です。 もしあなたが発想力豊かなエンジニアやデザイナーであれば強力な特許権が取得できるかもしれません。実際にプロダクトに生かされていない技術的なアイディアというのはあなたの頭の中に埋もれていることが多いものです。 エンジニアやデザイナーの成果が報われる土壌作りに貢献したい 知的財産権の生みの親はエンジニアやデザイナーの皆さんです。皆さんはあまり意識していないかもしれませんが、技術的なアイディアは日々の開発業務で生み出されていて、それが形になるものもあればならないものもあります。 メドレーでは、これまで検討された技術アイディアのうち、プロダクトとして実現化されたものや、そうでないものにかかわらず将来性を見込めそうなものについては、実際に特許出願をしてきました。 ・ ブロックチェーンを用いた電子処方箋の管理方法（特願 2018-078928） ・ 症状チェッカー（特願 2017-011444） ・患者統合基盤（特願 2019-233247）（出願中につき概念図を IR 資料より抜粋） また、メドレーでは、エンジニア、デザイナーの方々の成果物がプロダクトだけでなく、知的財産としてもきちんと社内外で認められ、それが名誉となるような土壌作りをしていこうと考えています。 さいごに メドレーは、テクノロジーを使って医療分野のデジタル化を推進し、医療ヘルスケアの未来をつくる会社です。そんなメドレーで生み出される素晴らしい技術やデザインを知的財産という分野で可能な限りバックアップしてきたいと思っています。少しでも特許の世界を感じて頂ければ幸いです。最後までお付き合い頂きありがとうございました！

こんにちは、インキュベーション本部でエンジニアをしています世嘉良です。 インキュベーション本部は 2020 年 2 月から新規事業の開拓などを目的に新設されたのですが、その中でも若手の部類として日々頑張っています。 CTO 平山のインタビューとともにインキュベーションチームの紹介記事が、コーポレートサイトに掲載されています。こちらもぜひご覧ください。 www.medley.jp www.medley.jp さて、今回は社内で行っている勉強会：テックランチの中で「Kotlin/Native」について発表する機会があったので紹介させていただきます。 Kotlin/Native について Kotlin は JetBrains 社によって 2011 年に発表されたプログラミング言語です。 現在では Android 開発などで主流の言語となっており、多くの人に利用されていると思います。 Kotlin/Native とはそんな Kotlin を使って様々なプラットフォーム上で実行可能なファイルを生成しようというプロジェクトです。 Kotlin/Native - Kotlin Programming Language 仕組みとしては Kotlin のコードをもとに LLVM を生成し、それを様々なプラットフォームで利用可能なネイティブバイナリにコンパイルすることで追加のランタイムや JVM なしで動作するようにしています。 サポートしているプラットフォームは下記のとおりです。 iOS (arm32, arm64, simulator x86_64) macOS (x86_64) watchOS (arm32, arm64, x86) tvOS (arm64, x86_64) Android (arm32, arm64, x86, x86_64) Windows (mingw x86_64, x86) Linux (x86_64, arm32, arm64, MIPS, MIPS little endian) WebAssembly (wasm32) コードの共通化について Kotlin/Native のチュートリアルを参考に、Android / iOS で共通化の流れを追ってみます。 作成されるプロジェクトは Android / iOS でそれぞれ “Hello, World!” を出力するシンプルなプログラムです。 Kotlin Playground: Edit, Run, Share Kotlin Code Online 通常のプロジェクトとは別に SharedCode というプロジェクトを作成し、この中に Kotlin/Native (Android / iOS 共通のコード) を記述していきます。 それぞれのコードのレイアウトは以下の通りです。 ※ SharedCode を読み込むためのマルチプラットフォームのための gradle ファイルも必要で、先程のウェブサイトに記載されています。 commonMain の中に 「expect」 というキーワードを使って抽象型のようなものを宣言し、 androidMain / iOSMain といった各プラットフォームの実装の中で 「actual」 というキーワードを使用してその内容を記述します。 // commonMain expect fun platformName (): String // androidMain actual fun platformName (): String { return "Android" } // iOSMain actual fun platformName (): String { return UIDevice.currentDevice. systemName () + " " + UIDevice.currentDevice.systemVersion } このチュートリアルには記載ありませんが、「expect」 というキーワードはクラスや関数・アノテーションといったすべてのものに定義することができます。 Platform-Specific Declarations - Kotlin Programming Language また iOSMain 内であれば iOS の Foundation フレームワークといったように、各プラットフォームごとのフレームワークもそれぞれ利用することができます。 こうしてできた、SharedCode のライブラリは Android/iOS のプロジェクトから使い慣れたライブラリと同じようにインポートすることができます。 Kotlin/Native の制約について JVM 上で Kotlin を動かしていた時には標準ライブラリやメモリ管理には Java の資産を利用することができましたが、Kotlin/Native ではそれを利用することができないという制約があります。 具体的にアプリを作成する際には下記の点に注意が必要でした。 Java の標準ライブラリを使用しているライブラリを利用できないため Kotlin で記述されたライブラリのみが使用する iOS アプリを開発する際には memScope, alloc / free などを利用してメモリ管理を自分で行う必要がある Java の資産が利用できない Kotlin に対して心配することもありましたが、Kotlin/Native 向けに様々なライブラリが 提供されておりそれらを利用することで問題を解決しました。 現状は日付管理ですらサードパーティ製のライブラリで操作する必要があるのが不満ですが、Kotlin/Native の発展によってこういった不便さは解決されるように願っています。 「suspend」 関数を iOS 側から直接呼び出すことができない (コールバック関数やなどに変換して呼び出す必要がある) Kotlin で定義した宣言や型の一部が Swift だと別名になっている (「 objc_runtime_name」 や 「swift_name」 を参照する必要がある) 「companion object」 や 「object」 などシングルトンの宣言に対してオブジェクトをフリーズするか 「ThreadLocal / SharedImmutable」 のアノテーションを付与する必要がある こちらは iOS で利用する場合の注意ですが、いくつかの Kotlin の機能が利用できなかったり、追加の記述が必要なものがあります。 詳しくは下記の資料を参照ください。 Kotlin/Native as an Apple Framework - Kotlin Programming Language kotlin-native/IMMUTABILITY.md Kotlin/Native の利用例 まだまだ利用例が少ないため参考になる資料などがあまりないのですが、以下の実装がオープンソースとして公開されているため構成や雰囲気を掴むためにはちょうど良い資料となりました。 GitHub - JetBrains/kotlinconf-app: KotlinConf Schedule Application GitHub - DroidKaigi/conference-app-2020: The Official Conference App for DroidKaigi 2020 Tokyo まとめ 弊社では 「CLINICS」 というオンライン診察を行うことができるアプリをリリースしています。 CLINICS を長期的に運用していくための技術調査の一環として、近年の Android 界隈で話題にあがっていた「Kotlin/Native」について検証し発表してみました。 まだまだ発展途上感のある技術ですが、実用性のあるプロジェクトだと思いますのでご興味のある方はぜひ一度お試しください！

こんにちは、インキュベーション本部でエンジニアをしています世嘉良です。 インキュベーション本部は 2020 年 2 月から新規事業の開拓などを目的に新設されたのですが、その中でも若手の部類として日々頑張っています。 CTO 平山のインタビューとともにインキュベーションチームの紹介記事が、コーポレートサイトに掲載されています。こちらもぜひご覧ください。 www.medley.jp www.medley.jp さて、今回は社内で行っている勉強会：テックランチの中で「Kotlin/Native」について発表する機会があったので紹介させていただきます。 Kotlin/Native について Kotlin は JetBrains 社によって 2011 年に発表されたプログラミング言語です。 現在では Android 開発などで主流の言語となっており、多くの人に利用されていると思います。 Kotlin/Native とはそんな Kotlin を使って様々なプラットフォーム上で実行可能なファイルを生成しようというプロジェクトです。 Kotlin/Native - Kotlin Programming Language 仕組みとしては Kotlin のコードをもとに LLVM を生成し、それを様々なプラットフォームで利用可能なネイティブバイナリにコンパイルすることで追加のランタイムや JVM なしで動作するようにしています。 サポートしているプラットフォームは下記のとおりです。 iOS (arm32, arm64, simulator x86_64) macOS (x86_64) watchOS (arm32, arm64, x86) tvOS (arm64, x86_64) Android (arm32, arm64, x86, x86_64) Windows (mingw x86_64, x86) Linux (x86_64, arm32, arm64, MIPS, MIPS little endian) WebAssembly (wasm32) コードの共通化について Kotlin/Native のチュートリアルを参考に、Android / iOS で共通化の流れを追ってみます。 作成されるプロジェクトは Android / iOS でそれぞれ “Hello, World!” を出力するシンプルなプログラムです。 Kotlin Playground: Edit, Run, Share Kotlin Code Online 通常のプロジェクトとは別に SharedCode というプロジェクトを作成し、この中に Kotlin/Native (Android / iOS 共通のコード) を記述していきます。 それぞれのコードのレイアウトは以下の通りです。 ※ SharedCode を読み込むためのマルチプラットフォームのための gradle ファイルも必要で、先程のウェブサイトに記載されています。 commonMain の中に 「expect」 というキーワードを使って抽象型のようなものを宣言し、 androidMain / iOSMain といった各プラットフォームの実装の中で 「actual」 というキーワードを使用してその内容を記述します。 // commonMain expect fun platformName (): String // androidMain actual fun platformName (): String { return "Android" } // iOSMain actual fun platformName (): String { return UIDevice.currentDevice. systemName () + " " + UIDevice.currentDevice.systemVersion } このチュートリアルには記載ありませんが、「expect」 というキーワードはクラスや関数・アノテーションといったすべてのものに定義することができます。 Platform-Specific Declarations - Kotlin Programming Language また iOSMain 内であれば iOS の Foundation フレームワークといったように、各プラットフォームごとのフレームワークもそれぞれ利用することができます。 こうしてできた、SharedCode のライブラリは Android/iOS のプロジェクトから使い慣れたライブラリと同じようにインポートすることができます。 Kotlin/Native の制約について JVM 上で Kotlin を動かしていた時には標準ライブラリやメモリ管理には Java の資産を利用することができましたが、Kotlin/Native ではそれを利用することができないという制約があります。 具体的にアプリを作成する際には下記の点に注意が必要でした。 Java の標準ライブラリを使用しているライブラリを利用できないため Kotlin で記述されたライブラリのみが使用する iOS アプリを開発する際には memScope, alloc / free などを利用してメモリ管理を自分で行う必要がある Java の資産が利用できない Kotlin に対して心配することもありましたが、Kotlin/Native 向けに様々なライブラリが 提供されておりそれらを利用することで問題を解決しました。 現状は日付管理ですらサードパーティ製のライブラリで操作する必要があるのが不満ですが、Kotlin/Native の発展によってこういった不便さは解決されるように願っています。 「suspend」 関数を iOS 側から直接呼び出すことができない (コールバック関数やなどに変換して呼び出す必要がある) Kotlin で定義した宣言や型の一部が Swift だと別名になっている (「 objc_runtime_name」 や 「swift_name」 を参照する必要がある) 「companion object」 や 「object」 などシングルトンの宣言に対してオブジェクトをフリーズするか 「ThreadLocal / SharedImmutable」 のアノテーションを付与する必要がある こちらは iOS で利用する場合の注意ですが、いくつかの Kotlin の機能が利用できなかったり、追加の記述が必要なものがあります。 詳しくは下記の資料を参照ください。 Kotlin/Native as an Apple Framework - Kotlin Programming Language kotlin-native/IMMUTABILITY.md Kotlin/Native の利用例 まだまだ利用例が少ないため参考になる資料などがあまりないのですが、以下の実装がオープンソースとして公開されているため構成や雰囲気を掴むためにはちょうど良い資料となりました。 GitHub - JetBrains/kotlinconf-app: KotlinConf Schedule Application GitHub - DroidKaigi/conference-app-2020: The Official Conference App for DroidKaigi 2020 Tokyo まとめ 弊社では 「CLINICS」 というオンライン診察を行うことができるアプリをリリースしています。 CLINICS を長期的に運用していくための技術調査の一環として、近年の Android 界隈で話題にあがっていた「Kotlin/Native」について検証し発表してみました。 まだまだ発展途上感のある技術ですが、実用性のあるプロジェクトだと思いますのでご興味のある方はぜひ一度お試しください！

こんにちは、インキュベーション本部でエンジニアをしています世嘉良です。 インキュベーション本部は 2020 年 2 月から新規事業の開拓などを目的に新設されたのですが、その中でも若手の部類として日々頑張っています。 CTO 平山のインタビューとともにインキュベーションチームの紹介記事が、コーポレートサイトに掲載されています。こちらもぜひご覧ください。 www.medley.jp www.medley.jp さて、今回は社内で行っている勉強会：テックランチの中で「Kotlin/Native」について発表する機会があったので紹介させていただきます。 Kotlin/Native について Kotlin は JetBrains 社によって 2011 年に発表されたプログラミング言語です。 現在では Android 開発などで主流の言語となっており、多くの人に利用されていると思います。 Kotlin/Native とはそんな Kotlin を使って様々なプラットフォーム上で実行可能なファイルを生成しようというプロジェクトです。 Kotlin/Native - Kotlin Programming Language 仕組みとしては Kotlin のコードをもとに LLVM を生成し、それを様々なプラットフォームで利用可能なネイティブバイナリにコンパイルすることで追加のランタイムや JVM なしで動作するようにしています。 サポートしているプラットフォームは下記のとおりです。 iOS (arm32, arm64, simulator x86_64) macOS (x86_64) watchOS (arm32, arm64, x86) tvOS (arm64, x86_64) Android (arm32, arm64, x86, x86_64) Windows (mingw x86_64, x86) Linux (x86_64, arm32, arm64, MIPS, MIPS little endian) WebAssembly (wasm32) コードの共通化について Kotlin/Native のチュートリアルを参考に、Android / iOS で共通化の流れを追ってみます。 作成されるプロジェクトは Android / iOS でそれぞれ “Hello, World!” を出力するシンプルなプログラムです。 Kotlin Playground: Edit, Run, Share Kotlin Code Online 通常のプロジェクトとは別に SharedCode というプロジェクトを作成し、この中に Kotlin/Native (Android / iOS 共通のコード) を記述していきます。 それぞれのコードのレイアウトは以下の通りです。 ※ SharedCode を読み込むためのマルチプラットフォームのための gradle ファイルも必要で、先程のウェブサイトに記載されています。 commonMain の中に 「expect」 というキーワードを使って抽象型のようなものを宣言し、 androidMain / iOSMain といった各プラットフォームの実装の中で 「actual」 というキーワードを使用してその内容を記述します。 // commonMain expect fun platformName (): String // androidMain actual fun platformName (): String { return "Android" } // iOSMain actual fun platformName (): String { return UIDevice.currentDevice. systemName () + " " + UIDevice.currentDevice.systemVersion } このチュートリアルには記載ありませんが、「expect」 というキーワードはクラスや関数・アノテーションといったすべてのものに定義することができます。 Platform-Specific Declarations - Kotlin Programming Language また iOSMain 内であれば iOS の Foundation フレームワークといったように、各プラットフォームごとのフレームワークもそれぞれ利用することができます。 こうしてできた、SharedCode のライブラリは Android/iOS のプロジェクトから使い慣れたライブラリと同じようにインポートすることができます。 Kotlin/Native の制約について JVM 上で Kotlin を動かしていた時には標準ライブラリやメモリ管理には Java の資産を利用することができましたが、Kotlin/Native ではそれを利用することができないという制約があります。 具体的にアプリを作成する際には下記の点に注意が必要でした。 Java の標準ライブラリを使用しているライブラリを利用できないため Kotlin で記述されたライブラリのみが使用する iOS アプリを開発する際には memScope, alloc / free などを利用してメモリ管理を自分で行う必要がある Java の資産が利用できない Kotlin に対して心配することもありましたが、Kotlin/Native 向けに様々なライブラリが 提供されておりそれらを利用することで問題を解決しました。 現状は日付管理ですらサードパーティ製のライブラリで操作する必要があるのが不満ですが、Kotlin/Native の発展によってこういった不便さは解決されるように願っています。 「suspend」 関数を iOS 側から直接呼び出すことができない (コールバック関数やなどに変換して呼び出す必要がある) Kotlin で定義した宣言や型の一部が Swift だと別名になっている (「 objc_runtime_name」 や 「swift_name」 を参照する必要がある) 「companion object」 や 「object」 などシングルトンの宣言に対してオブジェクトをフリーズするか 「ThreadLocal / SharedImmutable」 のアノテーションを付与する必要がある こちらは iOS で利用する場合の注意ですが、いくつかの Kotlin の機能が利用できなかったり、追加の記述が必要なものがあります。 詳しくは下記の資料を参照ください。 Kotlin/Native as an Apple Framework - Kotlin Programming Language kotlin-native/IMMUTABILITY.md Kotlin/Native の利用例 まだまだ利用例が少ないため参考になる資料などがあまりないのですが、以下の実装がオープンソースとして公開されているため構成や雰囲気を掴むためにはちょうど良い資料となりました。 GitHub - JetBrains/kotlinconf-app: KotlinConf Schedule Application GitHub - DroidKaigi/conference-app-2020: The Official Conference App for DroidKaigi 2020 Tokyo まとめ 弊社では 「CLINICS」 というオンライン診察を行うことができるアプリをリリースしています。 CLINICS を長期的に運用していくための技術調査の一環として、近年の Android 界隈で話題にあがっていた「Kotlin/Native」について検証し発表してみました。 まだまだ発展途上感のある技術ですが、実用性のあるプロジェクトだと思いますのでご興味のある方はぜひ一度お試しください！

こんにちは、インキュベーション本部でエンジニアをしています世嘉良です。 インキュベーション本部は 2020 年 2 月から新規事業の開拓などを目的に新設されたのですが、その中でも若手の部類として日々頑張っています。 CTO 平山のインタビューとともにインキュベーションチームの紹介記事が、コーポレートサイトに掲載されています。こちらもぜひご覧ください。 https://www.medley.jp/team/creator-story-incubation.html さて、今回は社内で行っている勉強会：テックランチの中で「Kotlin/Native」について発表する機会があったので紹介させていただきます。 Kotlin/Native について Kotlin は JetBrains 社によって 2011 年に発表されたプログラミング言語です。 現在では Android 開発などで主流の言語となっており、多くの人に利用されていると思います。 Kotlin/Native とはそんな Kotlin を使って様々なプラットフォーム上で実行可能なファイルを生成しようというプロジェクトです。 Kotlin/Native - Kotlin Programming Language 仕組みとしては Kotlin のコードをもとに LLVM を生成し、それを様々なプラットフォームで利用可能なネイティブバイナリにコンパイルすることで追加のランタイムや JVM なしで動作するようにしています。 サポートしているプラットフォームは下記のとおりです。 iOS (arm32, arm64, simulator x86_64) macOS (x86_64) watchOS (arm32, arm64, x86) tvOS (arm64, x86_64) Android (arm32, arm64, x86, x86_64) Windows (mingw x86_64, x86) Linux (x86_64, arm32, arm64, MIPS, MIPS little endian) WebAssembly (wasm32) コードの共通化について Kotlin/Native のチュートリアルを参考に、Android / iOS で共通化の流れを追ってみます。 作成されるプロジェクトは Android / iOS でそれぞれ “Hello, World!” を出力するシンプルなプログラムです。 Kotlin Playground: Edit, Run, Share Kotlin Code Online 通常のプロジェクトとは別に SharedCode というプロジェクトを作成し、この中に Kotlin/Native (Android / iOS 共通のコード) を記述していきます。 それぞれのコードのレイアウトは以下の通りです。 ※ SharedCode を読み込むためのマルチプラットフォームのための gradle ファイルも必要で、先程のウェブサイトに記載されています。 commonMain の中に 「expect」 というキーワードを使って抽象型のようなものを宣言し、 androidMain / iOSMain といった各プラットフォームの実装の中で 「actual」 というキーワードを使用してその内容を記述します。 // commonMain expect fun platformName (): String // androidMain actual fun platformName (): String { return "Android" } // iOSMain actual fun platformName (): String { return UIDevice.currentDevice. systemName () + " " + UIDevice.currentDevice.systemVersion } このチュートリアルには記載ありませんが、「expect」 というキーワードはクラスや関数・アノテーションといったすべてのものに定義することができます。 Platform-Specific Declarations - Kotlin Programming Language また iOSMain 内であれば iOS の Foundation フレームワークといったように、各プラットフォームごとのフレームワークもそれぞれ利用することができます。 こうしてできた、SharedCode のライブラリは Android/iOS のプロジェクトから使い慣れたライブラリと同じようにインポートすることができます。 Kotlin/Native の制約について JVM 上で Kotlin を動かしていた時には標準ライブラリやメモリ管理には Java の資産を利用することができましたが、Kotlin/Native ではそれを利用することができないという制約があります。 具体的にアプリを作成する際には下記の点に注意が必要でした。 Java の標準ライブラリを使用しているライブラリを利用できないため Kotlin で記述されたライブラリのみが使用する iOS アプリを開発する際には memScope, alloc / free などを利用してメモリ管理を自分で行う必要がある Java の資産が利用できない Kotlin に対して心配することもありましたが、Kotlin/Native 向けに様々なライブラリが 提供されておりそれらを利用することで問題を解決しました。 現状は日付管理ですらサードパーティ製のライブラリで操作する必要があるのが不満ですが、Kotlin/Native の発展によってこういった不便さは解決されるように願っています。 「suspend」 関数を iOS 側から直接呼び出すことができない (コールバック関数やなどに変換して呼び出す必要がある) Kotlin で定義した宣言や型の一部が Swift だと別名になっている (「 objc_runtime_name」 や 「swift_name」 を参照する必要がある) 「companion object」 や 「object」 などシングルトンの宣言に対してオブジェクトをフリーズするか 「ThreadLocal / SharedImmutable」 のアノテーションを付与する必要がある こちらは iOS で利用する場合の注意ですが、いくつかの Kotlin の機能が利用できなかったり、追加の記述が必要なものがあります。 詳しくは下記の資料を参照ください。 Kotlin/Native as an Apple Framework - Kotlin Programming Language kotlin-native/IMMUTABILITY.md Kotlin/Native の利用例 まだまだ利用例が少ないため参考になる資料などがあまりないのですが、以下の実装がオープンソースとして公開されているため構成や雰囲気を掴むためにはちょうど良い資料となりました。 GitHub - JetBrains/kotlinconf-app: KotlinConf Schedule Application GitHub - DroidKaigi/conference-app-2020: The Official Conference App for DroidKaigi 2020 Tokyo まとめ 弊社では 「CLINICS」 というオンライン診察を行うことができるアプリをリリースしています。 CLINICS を長期的に運用していくための技術調査の一環として、近年の Android 界隈で話題にあがっていた「Kotlin/Native」について検証し発表してみました。 まだまだ発展途上感のある技術ですが、実用性のあるプロジェクトだと思いますのでご興味のある方はぜひ一度お試しください！

こんにちは、インキュベーション本部でエンジニアをしています世嘉良です。 インキュベーション本部は 2020 年 2 月から新規事業の開拓などを目的に新設されたのですが、その中でも若手の部類として日々頑張っています。 CTO 平山のインタビューとともにインキュベーションチームの紹介記事が、コーポレートサイトに掲載されています。こちらもぜひご覧ください。 www.medley.jp www.medley.jp さて、今回は社内で行っている勉強会：テックランチの中で「Kotlin/Native」について発表する機会があったので紹介させていただきます。 Kotlin/Native について Kotlin は JetBrains 社によって 2011 年に発表されたプログラミング言語です。 現在では Android 開発などで主流の言語となっており、多くの人に利用されていると思います。 Kotlin/Native とはそんな Kotlin を使って様々なプラットフォーム上で実行可能なファイルを生成しようというプロジェクトです。 Kotlin/Native - Kotlin Programming Language 仕組みとしては Kotlin のコードをもとに LLVM を生成し、それを様々なプラットフォームで利用可能なネイティブバイナリにコンパイルすることで追加のランタイムや JVM なしで動作するようにしています。 サポートしているプラットフォームは下記のとおりです。 iOS (arm32, arm64, simulator x86_64) macOS (x86_64) watchOS (arm32, arm64, x86) tvOS (arm64, x86_64) Android (arm32, arm64, x86, x86_64) Windows (mingw x86_64, x86) Linux (x86_64, arm32, arm64, MIPS, MIPS little endian) WebAssembly (wasm32) コードの共通化について Kotlin/Native のチュートリアルを参考に、Android / iOS で共通化の流れを追ってみます。 作成されるプロジェクトは Android / iOS でそれぞれ “Hello, World!” を出力するシンプルなプログラムです。 Kotlin Playground: Edit, Run, Share Kotlin Code Online 通常のプロジェクトとは別に SharedCode というプロジェクトを作成し、この中に Kotlin/Native (Android / iOS 共通のコード) を記述していきます。 それぞれのコードのレイアウトは以下の通りです。 ※ SharedCode を読み込むためのマルチプラットフォームのための gradle ファイルも必要で、先程のウェブサイトに記載されています。 commonMain の中に 「expect」 というキーワードを使って抽象型のようなものを宣言し、 androidMain / iOSMain といった各プラットフォームの実装の中で 「actual」 というキーワードを使用してその内容を記述します。 // commonMain expect fun platformName (): String // androidMain actual fun platformName (): String { return "Android" } // iOSMain actual fun platformName (): String { return UIDevice.currentDevice. systemName () + " " + UIDevice.currentDevice.systemVersion } このチュートリアルには記載ありませんが、「expect」 というキーワードはクラスや関数・アノテーションといったすべてのものに定義することができます。 Platform-Specific Declarations - Kotlin Programming Language また iOSMain 内であれば iOS の Foundation フレームワークといったように、各プラットフォームごとのフレームワークもそれぞれ利用することができます。 こうしてできた、SharedCode のライブラリは Android/iOS のプロジェクトから使い慣れたライブラリと同じようにインポートすることができます。 Kotlin/Native の制約について JVM 上で Kotlin を動かしていた時には標準ライブラリやメモリ管理には Java の資産を利用することができましたが、Kotlin/Native ではそれを利用することができないという制約があります。 具体的にアプリを作成する際には下記の点に注意が必要でした。 Java の標準ライブラリを使用しているライブラリを利用できないため Kotlin で記述されたライブラリのみが使用する iOS アプリを開発する際には memScope, alloc / free などを利用してメモリ管理を自分で行う必要がある Java の資産が利用できない Kotlin に対して心配することもありましたが、Kotlin/Native 向けに様々なライブラリが 提供されておりそれらを利用することで問題を解決しました。 現状は日付管理ですらサードパーティ製のライブラリで操作する必要があるのが不満ですが、Kotlin/Native の発展によってこういった不便さは解決されるように願っています。 「suspend」 関数を iOS 側から直接呼び出すことができない (コールバック関数やなどに変換して呼び出す必要がある) Kotlin で定義した宣言や型の一部が Swift だと別名になっている (「 objc_runtime_name」 や 「swift_name」 を参照する必要がある) 「companion object」 や 「object」 などシングルトンの宣言に対してオブジェクトをフリーズするか 「ThreadLocal / SharedImmutable」 のアノテーションを付与する必要がある こちらは iOS で利用する場合の注意ですが、いくつかの Kotlin の機能が利用できなかったり、追加の記述が必要なものがあります。 詳しくは下記の資料を参照ください。 Kotlin/Native as an Apple Framework - Kotlin Programming Language kotlin-native/IMMUTABILITY.md Kotlin/Native の利用例 まだまだ利用例が少ないため参考になる資料などがあまりないのですが、以下の実装がオープンソースとして公開されているため構成や雰囲気を掴むためにはちょうど良い資料となりました。 GitHub - JetBrains/kotlinconf-app: KotlinConf Schedule Application GitHub - DroidKaigi/conference-app-2020: The Official Conference App for DroidKaigi 2020 Tokyo まとめ 弊社では 「CLINICS」 というオンライン診察を行うことができるアプリをリリースしています。 CLINICS を長期的に運用していくための技術調査の一環として、近年の Android 界隈で話題にあがっていた「Kotlin/Native」について検証し発表してみました。 まだまだ発展途上感のある技術ですが、実用性のあるプロジェクトだと思いますのでご興味のある方はぜひ一度お試しください！

こんにちは、インキュベーション本部でエンジニアをしています世嘉良です。 インキュベーション本部は 2020 年 2 月から新規事業の開拓などを目的に新設されたのですが、その中でも若手の部類として日々頑張っています。 CTO 平山のインタビューとともにインキュベーションチームの紹介記事が、コーポレートサイトに掲載されています。こちらもぜひご覧ください。 https://www.medley.jp/team/creator-story-incubation.html さて、今回は社内で行っている勉強会：テックランチの中で「Kotlin/Native」について発表する機会があったので紹介させていただきます。 Kotlin/Native について Kotlin は JetBrains 社によって 2011 年に発表されたプログラミング言語です。 現在では Android 開発などで主流の言語となっており、多くの人に利用されていると思います。 Kotlin/Native とはそんな Kotlin を使って様々なプラットフォーム上で実行可能なファイルを生成しようというプロジェクトです。 Kotlin/Native - Kotlin Programming Language 仕組みとしては Kotlin のコードをもとに LLVM を生成し、それを様々なプラットフォームで利用可能なネイティブバイナリにコンパイルすることで追加のランタイムや JVM なしで動作するようにしています。 サポートしているプラットフォームは下記のとおりです。 iOS (arm32, arm64, simulator x86_64) macOS (x86_64) watchOS (arm32, arm64, x86) tvOS (arm64, x86_64) Android (arm32, arm64, x86, x86_64) Windows (mingw x86_64, x86) Linux (x86_64, arm32, arm64, MIPS, MIPS little endian) WebAssembly (wasm32) コードの共通化について Kotlin/Native のチュートリアルを参考に、Android / iOS で共通化の流れを追ってみます。 作成されるプロジェクトは Android / iOS でそれぞれ “Hello, World!” を出力するシンプルなプログラムです。 Kotlin Playground: Edit, Run, Share Kotlin Code Online 通常のプロジェクトとは別に SharedCode というプロジェクトを作成し、この中に Kotlin/Native (Android / iOS 共通のコード) を記述していきます。 それぞれのコードのレイアウトは以下の通りです。 ※ SharedCode を読み込むためのマルチプラットフォームのための gradle ファイルも必要で、先程のウェブサイトに記載されています。 commonMain の中に 「expect」 というキーワードを使って抽象型のようなものを宣言し、 androidMain / iOSMain といった各プラットフォームの実装の中で 「actual」 というキーワードを使用してその内容を記述します。 // commonMain expect fun platformName (): String // androidMain actual fun platformName (): String { return "Android" } // iOSMain actual fun platformName (): String { return UIDevice.currentDevice. systemName () + " " + UIDevice.currentDevice.systemVersion } このチュートリアルには記載ありませんが、「expect」 というキーワードはクラスや関数・アノテーションといったすべてのものに定義することができます。 Platform-Specific Declarations - Kotlin Programming Language また iOSMain 内であれば iOS の Foundation フレームワークといったように、各プラットフォームごとのフレームワークもそれぞれ利用することができます。 こうしてできた、SharedCode のライブラリは Android/iOS のプロジェクトから使い慣れたライブラリと同じようにインポートすることができます。 Kotlin/Native の制約について JVM 上で Kotlin を動かしていた時には標準ライブラリやメモリ管理には Java の資産を利用することができましたが、Kotlin/Native ではそれを利用することができないという制約があります。 具体的にアプリを作成する際には下記の点に注意が必要でした。 Java の標準ライブラリを使用しているライブラリを利用できないため Kotlin で記述されたライブラリのみが使用する iOS アプリを開発する際には memScope, alloc / free などを利用してメモリ管理を自分で行う必要がある Java の資産が利用できない Kotlin に対して心配することもありましたが、Kotlin/Native 向けに様々なライブラリが 提供されておりそれらを利用することで問題を解決しました。 現状は日付管理ですらサードパーティ製のライブラリで操作する必要があるのが不満ですが、Kotlin/Native の発展によってこういった不便さは解決されるように願っています。 「suspend」 関数を iOS 側から直接呼び出すことができない (コールバック関数やなどに変換して呼び出す必要がある) Kotlin で定義した宣言や型の一部が Swift だと別名になっている (「 objc_runtime_name」 や 「swift_name」 を参照する必要がある) 「companion object」 や 「object」 などシングルトンの宣言に対してオブジェクトをフリーズするか 「ThreadLocal / SharedImmutable」 のアノテーションを付与する必要がある こちらは iOS で利用する場合の注意ですが、いくつかの Kotlin の機能が利用できなかったり、追加の記述が必要なものがあります。 詳しくは下記の資料を参照ください。 Kotlin/Native as an Apple Framework - Kotlin Programming Language kotlin-native/IMMUTABILITY.md Kotlin/Native の利用例 まだまだ利用例が少ないため参考になる資料などがあまりないのですが、以下の実装がオープンソースとして公開されているため構成や雰囲気を掴むためにはちょうど良い資料となりました。 GitHub - JetBrains/kotlinconf-app: KotlinConf Schedule Application GitHub - DroidKaigi/conference-app-2020: The Official Conference App for DroidKaigi 2020 Tokyo まとめ 弊社では 「CLINICS」 というオンライン診察を行うことができるアプリをリリースしています。 CLINICS を長期的に運用していくための技術調査の一環として、近年の Android 界隈で話題にあがっていた「Kotlin/Native」について検証し発表してみました。 まだまだ発展途上感のある技術ですが、実用性のあるプロジェクトだと思いますのでご興味のある方はぜひ一度お試しください！

こんにちは、インキュベーション本部でエンジニアをしています世嘉良です。 インキュベーション本部は 2020 年 2 月から新規事業の開拓などを目的に新設されたのですが、その中でも若手の部類として日々頑張っています。 CTO 平山のインタビューとともにインキュベーションチームの紹介記事が、コーポレートサイトに掲載されています。こちらもぜひご覧ください。 www.medley.jp www.medley.jp さて、今回は社内で行っている勉強会：テックランチの中で「Kotlin/Native」について発表する機会があったので紹介させていただきます。 Kotlin/Native について Kotlin は JetBrains 社によって 2011 年に発表されたプログラミング言語です。 現在では Android 開発などで主流の言語となっており、多くの人に利用されていると思います。 Kotlin/Native とはそんな Kotlin を使って様々なプラットフォーム上で実行可能なファイルを生成しようというプロジェクトです。 Kotlin/Native - Kotlin Programming Language 仕組みとしては Kotlin のコードをもとに LLVM を生成し、それを様々なプラットフォームで利用可能なネイティブバイナリにコンパイルすることで追加のランタイムや JVM なしで動作するようにしています。 サポートしているプラットフォームは下記のとおりです。 iOS (arm32, arm64, simulator x86_64) macOS (x86_64) watchOS (arm32, arm64, x86) tvOS (arm64, x86_64) Android (arm32, arm64, x86, x86_64) Windows (mingw x86_64, x86) Linux (x86_64, arm32, arm64, MIPS, MIPS little endian) WebAssembly (wasm32) コードの共通化について Kotlin/Native のチュートリアルを参考に、Android / iOS で共通化の流れを追ってみます。 作成されるプロジェクトは Android / iOS でそれぞれ “Hello, World!” を出力するシンプルなプログラムです。 Kotlin Playground: Edit, Run, Share Kotlin Code Online 通常のプロジェクトとは別に SharedCode というプロジェクトを作成し、この中に Kotlin/Native (Android / iOS 共通のコード) を記述していきます。 それぞれのコードのレイアウトは以下の通りです。 ※ SharedCode を読み込むためのマルチプラットフォームのための gradle ファイルも必要で、先程のウェブサイトに記載されています。 commonMain の中に 「expect」 というキーワードを使って抽象型のようなものを宣言し、 androidMain / iOSMain といった各プラットフォームの実装の中で 「actual」 というキーワードを使用してその内容を記述します。 // commonMain expect fun platformName (): String // androidMain actual fun platformName (): String { return "Android" } // iOSMain actual fun platformName (): String { return UIDevice.currentDevice. systemName () + " " + UIDevice.currentDevice.systemVersion } このチュートリアルには記載ありませんが、「expect」 というキーワードはクラスや関数・アノテーションといったすべてのものに定義することができます。 Platform-Specific Declarations - Kotlin Programming Language また iOSMain 内であれば iOS の Foundation フレームワークといったように、各プラットフォームごとのフレームワークもそれぞれ利用することができます。 こうしてできた、SharedCode のライブラリは Android/iOS のプロジェクトから使い慣れたライブラリと同じようにインポートすることができます。 Kotlin/Native の制約について JVM 上で Kotlin を動かしていた時には標準ライブラリやメモリ管理には Java の資産を利用することができましたが、Kotlin/Native ではそれを利用することができないという制約があります。 具体的にアプリを作成する際には下記の点に注意が必要でした。 Java の標準ライブラリを使用しているライブラリを利用できないため Kotlin で記述されたライブラリのみが使用する iOS アプリを開発する際には memScope, alloc / free などを利用してメモリ管理を自分で行う必要がある Java の資産が利用できない Kotlin に対して心配することもありましたが、Kotlin/Native 向けに様々なライブラリが 提供されておりそれらを利用することで問題を解決しました。 現状は日付管理ですらサードパーティ製のライブラリで操作する必要があるのが不満ですが、Kotlin/Native の発展によってこういった不便さは解決されるように願っています。 「suspend」 関数を iOS 側から直接呼び出すことができない (コールバック関数やなどに変換して呼び出す必要がある) Kotlin で定義した宣言や型の一部が Swift だと別名になっている (「 objc_runtime_name」 や 「swift_name」 を参照する必要がある) 「companion object」 や 「object」 などシングルトンの宣言に対してオブジェクトをフリーズするか 「ThreadLocal / SharedImmutable」 のアノテーションを付与する必要がある こちらは iOS で利用する場合の注意ですが、いくつかの Kotlin の機能が利用できなかったり、追加の記述が必要なものがあります。 詳しくは下記の資料を参照ください。 Kotlin/Native as an Apple Framework - Kotlin Programming Language kotlin-native/IMMUTABILITY.md Kotlin/Native の利用例 まだまだ利用例が少ないため参考になる資料などがあまりないのですが、以下の実装がオープンソースとして公開されているため構成や雰囲気を掴むためにはちょうど良い資料となりました。 GitHub - JetBrains/kotlinconf-app: KotlinConf Schedule Application GitHub - DroidKaigi/conference-app-2020: The Official Conference App for DroidKaigi 2020 Tokyo まとめ 弊社では 「CLINICS」 というオンライン診察を行うことができるアプリをリリースしています。 CLINICS を長期的に運用していくための技術調査の一環として、近年の Android 界隈で話題にあがっていた「Kotlin/Native」について検証し発表してみました。 まだまだ発展途上感のある技術ですが、実用性のあるプロジェクトだと思いますのでご興味のある方はぜひ一度お試しください！

こんにちは、インキュベーション本部でエンジニアをしています世嘉良です。 インキュベーション本部は 2020 年 2 月から新規事業の開拓などを目的に新設されたのですが、その中でも若手の部類として日々頑張っています。 CTO 平山のインタビューとともにインキュベーションチームの紹介記事が、コーポレートサイトに掲載されています。こちらもぜひご覧ください。 www.medley.jp www.medley.jp さて、今回は社内で行っている勉強会：テックランチの中で「Kotlin/Native」について発表する機会があったので紹介させていただきます。 Kotlin/Native について Kotlin は JetBrains 社によって 2011 年に発表されたプログラミング言語です。 現在では Android 開発などで主流の言語となっており、多くの人に利用されていると思います。 Kotlin/Native とはそんな Kotlin を使って様々なプラットフォーム上で実行可能なファイルを生成しようというプロジェクトです。 Kotlin/Native - Kotlin Programming Language 仕組みとしては Kotlin のコードをもとに LLVM を生成し、それを様々なプラットフォームで利用可能なネイティブバイナリにコンパイルすることで追加のランタイムや JVM なしで動作するようにしています。 サポートしているプラットフォームは下記のとおりです。 iOS (arm32, arm64, simulator x86_64) macOS (x86_64) watchOS (arm32, arm64, x86) tvOS (arm64, x86_64) Android (arm32, arm64, x86, x86_64) Windows (mingw x86_64, x86) Linux (x86_64, arm32, arm64, MIPS, MIPS little endian) WebAssembly (wasm32) コードの共通化について Kotlin/Native のチュートリアルを参考に、Android / iOS で共通化の流れを追ってみます。 作成されるプロジェクトは Android / iOS でそれぞれ “Hello, World!” を出力するシンプルなプログラムです。 Kotlin Playground: Edit, Run, Share Kotlin Code Online 通常のプロジェクトとは別に SharedCode というプロジェクトを作成し、この中に Kotlin/Native (Android / iOS 共通のコード) を記述していきます。 それぞれのコードのレイアウトは以下の通りです。 ※ SharedCode を読み込むためのマルチプラットフォームのための gradle ファイルも必要で、先程のウェブサイトに記載されています。 commonMain の中に 「expect」 というキーワードを使って抽象型のようなものを宣言し、 androidMain / iOSMain といった各プラットフォームの実装の中で 「actual」 というキーワードを使用してその内容を記述します。 // commonMain expect fun platformName (): String // androidMain actual fun platformName (): String { return "Android" } // iOSMain actual fun platformName (): String { return UIDevice.currentDevice. systemName () + " " + UIDevice.currentDevice.systemVersion } このチュートリアルには記載ありませんが、「expect」 というキーワードはクラスや関数・アノテーションといったすべてのものに定義することができます。 Platform-Specific Declarations - Kotlin Programming Language また iOSMain 内であれば iOS の Foundation フレームワークといったように、各プラットフォームごとのフレームワークもそれぞれ利用することができます。 こうしてできた、SharedCode のライブラリは Android/iOS のプロジェクトから使い慣れたライブラリと同じようにインポートすることができます。 Kotlin/Native の制約について JVM 上で Kotlin を動かしていた時には標準ライブラリやメモリ管理には Java の資産を利用することができましたが、Kotlin/Native ではそれを利用することができないという制約があります。 具体的にアプリを作成する際には下記の点に注意が必要でした。 Java の標準ライブラリを使用しているライブラリを利用できないため Kotlin で記述されたライブラリのみが使用する iOS アプリを開発する際には memScope, alloc / free などを利用してメモリ管理を自分で行う必要がある Java の資産が利用できない Kotlin に対して心配することもありましたが、Kotlin/Native 向けに様々なライブラリが 提供されておりそれらを利用することで問題を解決しました。 現状は日付管理ですらサードパーティ製のライブラリで操作する必要があるのが不満ですが、Kotlin/Native の発展によってこういった不便さは解決されるように願っています。 「suspend」 関数を iOS 側から直接呼び出すことができない (コールバック関数やなどに変換して呼び出す必要がある) Kotlin で定義した宣言や型の一部が Swift だと別名になっている (「 objc_runtime_name」 や 「swift_name」 を参照する必要がある) 「companion object」 や 「object」 などシングルトンの宣言に対してオブジェクトをフリーズするか 「ThreadLocal / SharedImmutable」 のアノテーションを付与する必要がある こちらは iOS で利用する場合の注意ですが、いくつかの Kotlin の機能が利用できなかったり、追加の記述が必要なものがあります。 詳しくは下記の資料を参照ください。 Kotlin/Native as an Apple Framework - Kotlin Programming Language kotlin-native/IMMUTABILITY.md Kotlin/Native の利用例 まだまだ利用例が少ないため参考になる資料などがあまりないのですが、以下の実装がオープンソースとして公開されているため構成や雰囲気を掴むためにはちょうど良い資料となりました。 GitHub - JetBrains/kotlinconf-app: KotlinConf Schedule Application GitHub - DroidKaigi/conference-app-2020: The Official Conference App for DroidKaigi 2020 Tokyo まとめ 弊社では 「CLINICS」 というオンライン診察を行うことができるアプリをリリースしています。 CLINICS を長期的に運用していくための技術調査の一環として、近年の Android 界隈で話題にあがっていた「Kotlin/Native」について検証し発表してみました。 まだまだ発展途上感のある技術ですが、実用性のあるプロジェクトだと思いますのでご興味のある方はぜひ一度お試しください！

こんにちは、メドレープロダクト開発室 エンジニアの岸田です。 先日、社内勉強会 TechLunch にて、弊社の提供する医療介護分野の人材プラットフォーム「ジョブメドレー」の開発で利用している CircleCI での CI/CD についての取り組みを発表しましたので、紹介させていただきたいと思います。 ジョブメドレーの開発で CircleCI をどのように利用しているか ジョブメドレーの開発では、主に次の 2 つを CircleCI を用いて行なっています。 ユニットテスト・構文チェック デプロイ デプロイに関しては、ECS 環境と EC2 環境への 2 通りのデプロイを CircleCI を利用して行なっています。 そのため CircleCI の Workflow は「ユニットテスト・構文チェック」「EC2 へのデプロイ」「ECS へのデプロイ」の 3 つに分かれています。 3 つの Workflow を大まかに説明させていただきます。 ユニットテスト・構文チェック ジョブメドレーは主にサーバサイドを Ruby on Rails、フロントエンドを React を使って開発をしています。 そのためユニットテストには RSpec ・ Jest を、構文チェックには Rubocop と ESLint 利用しています。 この Workflow は 3 つのジョブで構成されています。 ライブラリのインストール bundle install ・ yarn install などを行い、ユニットテスト・構文チェックの実行に必要な依存ライブラリをインストールし、CircleCI のキャッシュ機能を用いてキャッシュを行なっています RSpec の実行 2 コンテナを利用しての並列実行を行なっています 構文チェックと Jest の実行 RSpec と比較して Jest でのテストコードはボリュームが少なく・実行時間が短いため、構文チェックと一緒に 1 つのジョブにしています この Workflow はどのブランチでも GitHub へ Push が行われるたびに実行されるようにしています。 EC2 へのデプロイ この Workflow ではデプロイを行うための準備と、文字通り EC2 へのデプロイを行なっています。 デプロイには Ruby gem の Capistrano を利用しています。 下記のような 2 つのジョブで構成しています。 ライブラリのインストール 前述のユニットテスト・構文チェックの Workflow の 1 つ目と同じ役割です ビルドとデプロイ Rails の assets:precompile や yarn build などの処理と、Capistrano を用いたデプロイを行なっています この Workflow は特定のブランチでしか実行されないようになっています。 ECS へのデプロイ この Workflow では ECS へデプロイするための Docker image 作成とそのためのビルドなどを行なっています。 ジョブは下記のように 4 つで構成されています。 npm package のインストール フロントエンドのビルド Gem のインストールと Rails の assets:precompile Docker image の作成と Push こちらの Workflow も特定のブランチでしか実行されないようになっています。 抱えていた課題と assets:precompile ジョブメドレーの開発では CircleCI の各ジョブが全て正常に完了することを PR をマージする条件の 1 つにしています。 しかし各 Workflow ・ジョブの実行時間が長く、ジョブの実行待ちをしなければいけないという状況がよく起こってしまっていました。 特に時間がかかっていたのが、下記の 3 つでした。 「EC2 へのデプロイ」Workflow の「デプロイ」ジョブ 「ECS へのデプロイ」Workflow の「Gem のインストールと Rails の asset_precompile」ジョブ 「RSpec の実行」ジョブ RSpec の書き方などを改善することで短縮できるため、割愛させていただきます これらについて調査したところ、1・ 2 は、assets:precompile が主に時間を使っていることが分かりました。 この点について原因と行なった改善を説明をさせていただこうと思います。 assets:precompile に時間がかかる ジョブメドレーでは Rails のアセットパイプラインを利用して、アセットファイルのコンパイル・最小化などを行なっています。 これを実行する際に assets:precompile コマンドを利用しています。 また、同コマンド実行時にコンパイルしたファイルを AWS S3 バケットにアップロードするために asset_sync gem を利用しています。 このコマンドの実行には 9 分から 10 分ほどの時間がかかっており、下記の 2 つの原因で遅くなっていました。 毎回 1 からコンパイルを行なっていた コンパイル後のファイルをアップロードする S3 バケットに大量のファイルが存在する 毎回 1 からコンパイルを行なっていた こちらについては読んで字のごとくですが、デプロイ Workflow が実行されるたびにアセットファイルの変更有無に関わらず、毎回 3 分ほどを費やして全てのアセットファイルをコンパイル・最小化していました。 こちらの解決策としては、 CircleCI の公式ドキュメントでも例が載せられています が、 assets:precompile コマンドで生成されるファイルが置かれるディレクトリ（ public/assets ）を CircleCI でキャッシュさせることで対応しました。 キャッシュさせることで、毎回 3 分ほどかかっていた処理を 1 分ほどに短縮することができました。 コンパイル後のファイルをアップロードする S3 バケットに大量のファイルが存在する こちらついてはもう少し背景が複雑かつ、まだ解決まではできていません。 まず asset_sync を利用したファイルのアップロード処理ですが、毎回 6 分以上の時間がかかっていました。 CircleCI のログをよくよく見てみるとアップロード自体に時間がかかっているのではなく、「どのファイルをアップロードすべきか」を判断する処理に多くの時間を費やしていることが分かりました。 （1 ファイルもアップロードしていないが 6 分 20 秒かかっている） そこで、 asset_sync gem のソースコードを読んでみると、「アップロード先の S3 バケットにあるファイルを全て取得し、 assets:precompile コマンドが生成したファイルのファイル名と比較する」という処理がありました。 この処理が怪しいのではないかと思い、S3 バケットを確認してみたところ数十万件以上のファイルが存在することが分かりました。 数十万件以上のファイルの情報を取得していることを考えると 6 分以上時間がかかるのも納得です。 この問題の解決策は下記の 2 つが考え得ると考えました。 不要なファイルを S3 バケットから削除する 前回のデプロイとの比較をして S3 にアクセスせずにアップロードすべきファイルかどうかを判断するようにする 1 つ目の方法は正攻法で、数十万ファイルを全て使っているわけではないため利用されていないファイルを削除してしまう方法です。 asset_sync も早くなり、S3 の利用料も少なくなるためこの方法を取れるのであれば、この方法で解決するのが良いように思います。 ジョブメドレーでもこの方法を取れないかと検討しましたが、ジョブメドレーから配信している HTML メールなどでも利用しているファイルがあるため一概にアクセスされていないからといって削除することができず、この方法での解決は一旦断念しました。 2 つ目の方法は assets:precompile コマンドが生成する manifest ファイル（生成したファイルのリストなどが記述されている）と CircleCI のキャッシュ機能を使って短縮する方法です。 manifest ファイルは、コンパイル後のアセットファイルが出力されるディレクトリ（ public/assets/ ）に同じように出力され、また、上記で public/assets を CircleCI のキャッシュ機能でキャッシュするようにしたため、manifest ファイルも一緒にキャッシュされるようになっています。 assets:precompile の実行により今回作成された manifest ファイルと、キャッシュされていた manifest ファイルを比較して差分が出たファイルだけを S3 にアップロードするようにしようという試みです。 この処理は asset_sync gem ではできそうになかったので、シェルスクリプトと Rake タスクを作成して実行してみたところ、「アップロードすべきファイルかどうか」を判断するための時間がほぼなくなり、6 分以上の短縮をすることができました。 ただし検証が不十分なため、実運用に乗せることはまだできていません。 CircleCI のジョブ実行時間を短縮する小さな改善事項 上述の通り、各 Workflow で大きく時間を費やしているのは assets:precompile と RSpec の実行でしたが、細かな点としては他にも小さい改善をしたことがあります。 コードのチェックアウト CircleCI では組み込みのコマンドとして checkout コマンドがあります。 これは対象のリポジトリのブランチをクローンしてくれるコマンドですが、ジョブメドレーはモノレポに近い構成になっており、コードベースのサイズや履歴が大きいためクローンするだけである程度の時間がかかってしまっています。 そこでまずは、 .git ディレクトリを CircleCI のキャッシュ機能を利用してキャッシュするようにしてみました。 すると、 checkout コマンド自体は大きく短縮しましたが、キャッシュの save/restore に短縮した以上の時間がかかるようになってしまいました。 別の方法として checkout コマンドを利用せずに、Git の Shallow clone や Sparse clone を駆使して必要なファイルや履歴だけをクローンするということができます。 現在は Sparse clone を一部導入してみており、Shallow clone も導入したいと考えています。 Docker image の作成 ジョブメドレーでは ECS へのデプロイの際に CircleCI 上で Docker image をビルドしているため、 docker build コマンドの実行時間も可能な限り抑えたいと考えています。 短縮する方法は様々あるかと思いますが、CircleCI 上でも Dokcer Buildkit を利用することがきますので、それを利用してビルドすることで簡単に短縮することができます。 詳しくは Docker のガイド に記載の通りではありますが、DOCKER_BUILDKIT=1 を指定して docker build を実行するだけで利用することができ、ジョブメドレーでは 2 分ほどかかっていたビルドを 40 秒ほど短縮することができました。 まとめ 今回は、TechLunch で発表したジョブメドレーにおける CircleCI の活用と改善の取り組みについて紹介させていただきました。 今回紹介させていただいた以外にも様々な用途があり、今後もさらにうまく活用していきたいと思っています。 ご覧いただきありがとうございました。