株式会社メドレー の技術ブログ
全1359件
株式会社メドレーのエンジニアの阪本です。 緊急事態宣言も開け、普段の生活を取り戻しつつあるこの時期、 皆さんはいかがお過ごしでしょうか？ 私は野球観戦（虎党）を毎日の楽しみとしています。 今年はコロナ渦の影響で開幕予定が遅延したものの、自粛期間を経て 6 月中旬にめでたくシーズン開幕を迎えることができました。 ここまでの「長い冬」が明け、テレビをつけると野球が見られる。 これで私自身も 2020 年が開幕したなと実感しています。 今回は、私がインフラ開発時に直面した問題と解決までの事例について紹介させて頂きます。 背景 私はジョブメドレーのサービス開発を行っています。 このシステムは多くの機能で構成された大規模なもので、AWS の Elastic Container Service(以下 ECS)にて稼働しています。 このシステムに対し既存機能のリプレース案件に携わる機会がありました。 現在のシステムは多くの時間をかけて多くの機能を実装した結果、かなり大きなコードとなっています。 これにより、一つの変更が及ぼす影響が甚大なものになり得る状況だったため、リプレース対象の機能を新システムとして別アプリケーションに切り出して開発することにしました。 しかし、別システムとして一部の機能を切り出すものの、この機能は 既存システムとの連携が必要となります。 そのため、この連携をシステム間の API リクエストで実現することにしました。 課題 ここで１つの問題が発生しました。 システム間の通信が必要になりましたが、お互い ECS サービスで分離した構成となるため このままではアドレスの解決が出来ないことに気づきました。 同一 ECS サービス内でかつ、ネットワークモードが awsvpc モードであれば ポート番号を分ける事により相互でアクセスが可能であるものの 異なるサービスであればポート以前にアドレス解決ができません。 そのため、何らかの手段を持ってお互いの場所を認識できる状態にする必要があります。 そこで、これを実現できる幾つかの方法を検討しました。 アプローチ その１ 全て１つの ECS のサービスにまとめる 上記の通り、既存システムが動いている ECS サービス/タスクに新システム（のコンテナ）を全て混ぜる方法です。 この場合、全てのポートを個別に割り振ることで 127.0.0.1:port によるアクセスが可能となるため 相互のリクエストも実現できることになります。 ただ、インフラ的には２つのシステムが１つの塊として構成される事になるため デプロイの単位やスケールの単位を常に双方共有することになります。 こうなると、せっかくアプリケーションを分けたにも関わらず 運用の部分では何もメリットを得られないどころか制約が増えただけのようになりそうなのが問題です。 その２ 内部 Application Load Balancer を経由する VPC 内部に internal な Application Load Balancer（以下 ALB) を設置し、接続先となる既存システムを TargetGroup に登録します。 この方法であれば、ALB のエンドポイントに向けてリクエストすることで配下の既存システムにアクセスする経路が確保できます。 また ECS サービスと TargetGroup が紐づくことにより既存システム側のデプロイやスケールが自動的に ALB 側にも連動することになるため、新システム側は既存システムのステータスを意識する必要は少なくなります。 これだと不自然な点も無くアプリケーション間の通信経路も確保できると期待しましたが・・・新たに問題が発生しました。 検証時に ALB/TargetGroup を新規作成。 ECS サービスについては 後付けで TargetGroup 脱着はできない 複数 TargetGroup の付与は AWS コンソールでは対応していない といった理由のために AWS CLI での作成作業を行ったのですが、下記エラーが発生してしまいました。 An error occurred (InvalidParameterException) when calling the CreateService operation: load balancers can have at most 5 items. これは AWS による制限で、1 つの ECS サービスに関連付けることのできる TargetGroup は最大 5 つまでという事を表しています。 つまり既存システムは多くの機能やコンテナが同居している ECS サービスとなっていたため、既に TargetGroup が 5 つ存在しており上限に達していたのです。 サービスで使用するロードバランサーを表すロードバランサーオブジェクト。Application Load Balancer または Network Load Balancer を使用するサービスの場合、サービスにアタッチできる 5 つのターゲットグループの制限があります。 Amazon ECS サービス定義パラメータ - Amazon Elastic Container Service Amazon ECS サービスの実行方法を定義するサービス定義パラメータについて説明します。 docs.aws.amazon.com この方法を取るなら不要な TargetGroup を削るかまとめるかの手を打つ必要がありますが、 周辺環境に対する影響があまりにも大きい為に現実的ではありませんでした。 そのため、新たな選択肢を探すことにしました。 その３ Amazon ECS サービスディスカバリを使用する そんな中、ECS の機能としてサービスディスカバリ（サービス検出）というものを見つけました。 Amazon ECS サービスディスカバリ | Amazon Web Services Amazon ECS でサービスディスカバリがサポートされました。これにより、ECS サービスが A […] aws.amazon.com これは ECS サービスと Route53 内部ホスト空間を紐付ける機能です。 また ECS サービスの起動・停止・スケールといった対象が変動した場合にも、自動的にホスト空間のレコードを登録/解除し最新の状態に追従してくれるものです。 この場合、別々のサービス間でもお互い相手の名称を把握することができる上、 TargetGroup も新規に必要としないため、今回のニーズに適した方法になりそうです。 導入してみた結果 試しに ECS サービスにサービスディスカバリを導入し、疎通できるか試してみます。 既に存在するサービスに後付でのサービスディスカバリは出来ないため、新規にサービスを作成 することになります。 今回は初めてのサービスディスカバリとなるので、名前空間も同時に作成することになります。 ひとまず名前空間を「 medley-blog.local 」、サービス検出名を「 service-discovery 」としてみます。 このまま ECS サービスを作成すると、Route 53 にて新たな名前空間「 medley-blog.local 」が作成されていることが確認できます。 この状態でサービスのタスクを 1 つ起動ししばらく待つと、 サービス検出名.名前空間 となる service-discovery.medley-blog.local に A レコードが追加されています。 このレコードに紐づく IP アドレスこそ、ECS タスクに紐付けられている IP アドレスになります。 あとはこの名称で別環境から疎通できるか試してみます。 curl コマンドで service-discovery.medley-blog.local で通信してみると、見事にレスポンスを受け取ることが出来ました。 ※ここでは検証のため、接続先アプリケーションは Nginx コンテナを配置しています これにより、異なる ECS サービス間での通信を実現することができました。 今後の予定 現段階では検証段階のため評価環境への導入のみとなりますが、今の所は大きな問題も発生せず順調に稼働しています。 このまま特に問題無く稼働できれば、本番環境への導入も目指したいと思います。 さいごに メドレーのエンジニアは大小問わず課題に対して真摯に向き合い、試行錯誤し、突破口を開く取り組みを常に続けています。 そんな我々と一緒に働きたいと思った方、まずは下記リンクからご応募いただきカジュアルにお話しませんか？ www.medley.jp 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 のようにグラフィック要素が多くなってくるとデザインツールのほうがはかどります。 プロジェクトの性格に応じて最適なデザイン方法を選んでいきたいですね。 デザイナーだけどコードも書きたい方や、一緒にプルリク送ってくれるデザイナーの方いらっしゃれば、ぜひメドレーで一緒に働きましょう〜 https://www.medley.jp/jobs/designer-new.html
メドレーのデザイナー酒井です。最近、 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
メドレーのデザイナー酒井です。最近、 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
メドレーのデザイナー酒井です。最近、 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」について検証し発表してみました。 まだまだ発展途上感のある技術ですが、実用性のあるプロジェクトだと思いますのでご興味のある方はぜひ一度お試しください！