事業本部 プロダクト開発室エンジニアの日下です。 オンライン診療・服薬指導・クラウド診療支援システム「CLINICS」 の、患者・医療機関に向けたアプリケーションの機能開発、開発基盤、インフラ周りを担当しております。 今回 CLINICS が提供するオンライン診療機能に「画面共有機能」を追加しましたので、その背景・技術的な話をまとめます。 画面共有機能実装の背景 CLINICS とオンライン診療 普段皆さんが病院にかかるとき、多くの場合は病院に行き、医師の診察を対面で受け、会計をして帰るといった流れになるかと思います。 CLINICS のオンライン診療はこの流れをインターネットを通して提供するサービスです。 ※ オンライン診療は、一度、初診等で対面診療を受けた際に医師が可能と判断した場合、次回以降の診察において可能になります。また、現在は新型コロナウイルス感染症対策時限措置として、初診からオンライン診療を受けることが可能となっています。 CLINICS を利用した場合、事前に予約した時間にスマホまたは PC で待機をする、医師の診察をビデオチャットで受け、会計はクレジットカードで行われるという流れとなっています。 クラウド診療支援システムとしての CLINICS は 2016 年に「オンライン診療のためのシステム」としてローンチ され、 2018 年にはクラウド型電子カルテ機能を 、 2019 年には予約管理システム機能を 、 2020 年にはかかりつけ薬局支援システム Pharms との連携機能も追加し 、患者向けアプリからオンライン服薬指導をシームレスに受けることができるようになりました。 プロダクト開発室ではこれらオンライン診療機能・電子カルテ機能・予約管理機能・連携機能の改善を日々行っています。 画面共有機能の需要の高まり、実装の決定 このように CLINICS の改善を日々行なっている中、昨年から始まった 新型コロナウイルス感染症（COVID-19） の流行に伴った需要の増加により、オンライン診療の件数が急増しました。 CLINICS も数多くの医療機関にご利用いただく中で、オンライン診療に関わるさまざまなご要望をいただくようになりました。その中でも特に多かったものが、今回紹介する画面共有機能です。 対面での診察の際に医師が検査結果などを患者に見せながら説明するように、オンラインで診察する場合でも資料をリアルタイムで共有しながら説明ができるようになれば、今まで以上にオンラインでも質の高い診察を行えるようになります。 こういったユースケース、要望などを検討した結果、CLINICS を利用するすべての医療機関及び患者にとって大きな恩恵が見込まれたため、オンライン診察（ビデオチャット）中に医師の PC 画面をリアルタイムで患者に共有する機能として実装をすることにしました。 画面共有機能の実装 画面共有をする医師側向けのコードでどういった実装方法があるのか、大まかな流れをまとめます。 ※ 以下に記載しているコードは説明のための疑似コードですので、このままでは動作しないことにご注意ください。また、医師側の実装例を掲載しているため、患者側（画面共有を受ける側）の実装は別途必要になります。 オンライン診察開始までの処理 オンライン診察を開始するには医師側のマイクとカメラで取得した情報を患者側に送付する必要があります。ここではそこまでの実装の流れを見ていきます。 カメラ・マイクのストリームの取得 オンライン診察開始時点で医師側のマイク・カメラの情報を共有するため、まずはそれらのストリームを取得する必要があります。こういったメディアコンテンツのストリームを司るインターフェイスとして MediaStream が定義されています。 マイク・カメラの MediaStream は、例えば MediaDevices.getUserMedia() を利用して取得できます。 const userMediaStream : MediaStream = await navigator . mediaDevices . getUserMedia ({ video: true , audio: true , }); SkyWay 経由でオンライン診察を始める WebRTC で P2P のビデオチャットを利用するためには、初期の接続のための処理及び接続の維持などの処理を行う必要があります。弊社ではこのあたりの処理を WebRTC SaaS の SkyWay 及びその SDK を利用することで簡略化しています。 オンライン診察開始時には、先程取得した医師側のマイク・カメラの MediaStream を SkyWay の SDK に渡すことで、一対一でのリアルタイムビデオチャットを実現できます。 import Peer , { MediaConnection } from "skyway-js" ; const peer = new Peer ({ key: "your-api-key" }); // 事前に患者と共有しておいた peer id に対して call メソッドと MediaStream を渡すことで診察を開始できる。 const mediaConnection : MediaConnection = peer . call ( "shared-peer-id" , userMediaStream ); // 注: 患者側は送付された処理をハンドリングする機能を実装する必要がある ここまでがオンライン診察を開始するまでの処理です。 ※ 詳細は SkyWay 公式の チュートリアル などを参照ください。 画面共有の処理 ここまでで患者に対して医師側のカメラ・マイクで取得された映像・音声が表示されている状態のため、これを切り替える処理が必要になります。今回は現在接続に利用している MediaStream を、画面共有用の MediaStream に入れ替えることで実現しました。 画面の MediaStream の取得 まずは共有する画面の MediaStream を取得する必要があります。これは MediaDevices.getDisplayMedia() を使うことで実現できます。 const displayStream : MediaStream = await navigator . mediaDevices . getDisplayMedia ( { video: true } ); 画面共有用の MediaStream を作る getDisplayMedia() から共有する画面の MediaStream を取得できるものの、そのまま利用するとマイクの音声が入りません。 これは getDisplayMedia() から取れる MediaStream にマイクの音声が含まれていないことが原因なので、必要な画像・音声の組み合わせを持った画面共有用の MediaStream を作成することで対処ができます。 MediaStreamTrack を組みあわせて画面共有用の MediaStream を作る 画面共有用の MediaStream を作成する前にまず、MediaStreamTrack と MediaStream の関係を理解する必要があります。 MediaStreamTrack はストリームに含まれる一つのメディアトラックを表現するものです。 kind という読み取り専用プロパティがあり、オーディオトラックであれば "audio" が、ビデオトラックであれば "video" が設定されています。 また、 MediaStream は複数の MediaStreamTrack から成り、オーディオトラック・ビデオトラックを取り出すメソッドがそれぞれ MediaStream.getAudioTracks() ・ MediaStream.getVideoTracks() として実装されています。 これらを組み合わせることで、マイクと画面の MediaStreamTrack を持つ MediaStream を作ることができ、これを SkyWay の SDK に渡すことで、画面共有を実現できます。 const [ displayVideoTrack ]: MediaStreamTrack [] = displayStream . getVideoTracks (); // 画面共有の音声はマイクの音声を利用したいので、userMediaStream から audioTrack を取り出しておく const [ userAudioTrack ]: MediaStreamTrack [] = userMediaStream . getAudioTracks (); // 画面共有するための MediaStream を作成する(画面の videoTrack、マイクの audioTrack を持つ MediaStream を作る) const sharingMediaStream : MediaStream = new MediaStream ([ displayVideoTrack , userAudioTrack , ]); MediaStream の入れ替え 最後に画面共有状態への切り替えです。マイク・カメラが共有されている状態からの切り替えにはいくつかの方法が考えられます。 例えば、多重化であれば MediaConnection（ Skyway の SDK の単位で、「接続先 Peer へのメディアチャネル接続」を管理する）の多重化、MediaStream の多重化、MediaStreamTrack の多重化がそれぞれ考えられます。これらの方法はマイク・カメラの切り替え時のチラつき抑制など実装上の選択肢が増えるメリットがある一方で、通信量が多くなってしまう点がデメリットと言えます。 今回は多重化をせずに既存の MediaStream を切り替える実装を紹介します。この方法のメリットは、多重化に比べると通信量が少なく、またすでに MediaStream が一つである前提で作られている場合は、画面共有を受ける側の実装の変更が不要という点です。 この方法は、 SkyWay の SDK であれば MediaConnection の replaceStream というメソッド に対して新しい MediaStream を渡すことで実現ができます。 // 画面共有用の MediaStream を渡すことで、画面共有を開始する // MediaConnection は先程 `peer.call` した際の返り値として取れているため、それを利用する mediaConnection . replaceStream ( sharingMediaStream ); 実装前に懸念していたマイク・カメラの切り替え時のチラつきなども気になるほどはなく、実用に足るような品質を保つことができることを確認しています。 実装の全体概要 以上の流れを実装すると、次のようなコードになります。 import Peer , { MediaConnection } from "skyway-js" ; /** 医師側のマイク・カメラを共有してオンライン診察開始するところまで **/ // getUserMedia()でカメラ・マイクのストリームを取得 const userMediaStream : MediaStream = await navigator . mediaDevices . getUserMedia ({ video: true , audio: true , }); // Skyway sdk の初期化処理 const peer = new Peer ({ key: "your-api-key" }); // オンライン診察の開始 const mediaConnection : MediaConnection = peer . call ( "peerId" , userMediaStream ); /** 画面共有を開始する処理 **/ // 画面共有する画面の stream を取る const displayStream : MediaStream = await navigator . mediaDevices . getDisplayMedia ( { video: true } ); const [ displayVideoTrack ]: MediaStreamTrack [] = displayStream . getVideoTracks (); // 画面共有の音声はマイクの音声を利用したいので、userMediaStream から audioTrack を取り出しておく const [ userAudioTrack ]: MediaStreamTrack [] = userMediaStream . getAudioTracks (); // 画面共有するための MediaStream を作成する(画面の videoTrack、マイクの audioTrack を持つ MediaStream を作る) const sharingStream : MediaStream = new MediaStream ([ displayVideoTrack , userAudioTrack , ]); // 画面共有用の MediaStream を渡すことで、画面共有を開始する mediaConnection . replaceStream ( sharingStream ); 開発中に遭遇した問題への対応 スリープモード・共有を停止ボタンを押したときの対応 Google Chrome で画面共有の際に表示される「共有を停止」ボタンを押下したり、PC をスリープモードにすると、画面の MediaStreamTrack が途切れてしまいます。 これは該当の MediaStreamTrack に "ended" のイベントリスナを登録しておくことでハンドリングできます。 displayVideoTrack . addEventListener ( "ended" , handleEndedEvent , { once: true }); TypeScript の型の対応 現状 TypeScript の型が getDisplayMedia() に対応していなかったため、今回は実装の参考にしている skyway-conf で利用されている型 を流用する形で対応をしました。 declare global { interface MediaDevices { getDisplayMedia ( constraints : MediaStreamConstraints ): Promise < MediaStream >; } } これは根本的には TypeScript の dom.d.ts に型定義が入っていないことが起因していますが、 TypeScript4.4 で対応がされるようです 。 まとめ 昨今の状況により、オンライン診察のニーズが高まり、画面共有機能の重要性が高まりました。 診察中の画面共有機能は以下の api を組み合わせることで実現することができます。 PC 画面の MediaStream は getDisplayMedia() を使うことで取得 MediaStream に含める音声・画像ストリームを変更したい場合は MediaStreamTrack の組み合わせを変えることで作成 接続中の MediaStream の変更は SkyWay の SDK の MediaConnection.replaceStream() を使う 最後に CLINICS では本稿で紹介した画面共有などの新規機能の導入や日々の改善を通じて、医療機関・患者双方に支持されるプロダクトを目指し開発を行っています。興味を持たれたエンジニアの方がいらっしゃいましたらぜひ こちら にご連絡いただければと思います。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに はじめまして、コーポレートエンジニアの山下です。 2020 年に Slack を活用した ChatOps 稟議ワークフローを内製で開発したのですが、さらに、2021 年 4 月にこの Slack 稟議と電子契約システムである クラウドサイン を連携させて、電子契約をもっと便利に使い、生産性の向上を実現しましたのでお話しいたします。 まず、当社の稟議システムは 2020 年 12 月の当社の記事 のおさらいになりますが、稟議の作業が Slack 上で完結する、 ChatOps による稟議ワークフロー となっております。本稿については 2021 年 7 月に執筆しておりますので丁度導入から 1 年程経過し、その間大きなトラブルも無く、今も当社の極めて迅速な意思決定の一助になっています。ChatOps による稟議ワークフローについては、直近、2021 年 6 月に LayerX 社が LayerX ワークフローの新機能として発表 し、サービスとしても提供され、 日経新聞 でも取り上げられていることから、今現在のパラダイムとして、先進的で有効な一手法であったと再認識しております。 今回、新型コロナウイルス感染拡大防止に伴うリモートワークの加速という状況もあり、当社で 2021 年 4 月に電子契約システムとしてクラウドサインを導入しました。電子契約に限らず、契約押印作業は稟議の後続作業に当たるため、ただ導入して使用するのみならず、クラウドサインの API を利用して稟議上にあるデータを電子契約に送信させることでシームレスな連携を実現しています。本稿では当社が行ったシームレスな連携手法について詳細をご説明いたします。 TeamSpirit とクラウドサインの API 連携について 実装概要 弊社の稟議システムである TeamSpirit とクラウドサインとの連携についてお話しします。まず、本稿の開発部分とシステム構成は下記になっております。 処理内容の詳細は後ほど述べますが、概要としては TeamSprit(Apex)からクラウドサインの API をコールし、クラウドサイン上で作成した契約文書へ稟議に記載されている契約書ファイルや先方担当者等の情報を連携する仕組みとなっております。これにより契約担当者はクラウドサインにログイン後、下記の 3 ステップで先方に送信できるようになっています。 記載内容の確認 押印・署名箇所の設定 先方への送信 クラウドサインを使用して契約文書を一から作成する場合のユーザ作業と、当社で採用した API 連携行った場合のユーザ作業を比較したものが下記の表です。作業が半分程度削減されたことが分かります。 作業項番 一から作成する場合 API 連携を利用した当社の場合 1 ログイン ログイン 2 契約文書の作成(件名、契約文書としての宛名設定等) なし 3 契約書ファイルのアップロード なし 4 先方の送信先設定 なし 5 押印欄の設定 押印欄の設定 6 先方への送信 先方への送信 実装 今回の開発で使用した クラウドサイン API は下記の 5 つの API を使用しました (※以降、クラウドサイン API に倣い、変数を表現する場合は {} で括ります)。 API 種類 使用用途 post /token アクセストークンの取得 post /document 契約文書の作成 put /documents/{documentID}/attribute 契約文書の作成で設定できない、細かい項目の設定 post /documents/{documentID}/files ファイルのアップロード post /documents/{documentID}/participants 先方の送信先設定 全体像で記載したクラウドサインの連携部について、上記の API を織り交ぜて詳細化すると下図のようになります。 実装方法としてはクラウドサイン API のリファレンスを参照し、テスト実行時に出力される curl コマンドを参考に同様のレスポンスを得るように Apex で HTTP リクエストを実装しました。アクセストークンの取得を例にとると下記のようになります。 API リファレンスでの curl コマンド例 curl -X 'POST' \ 'https://api.cloudsign.jp/token' \ -H 'accept: application/json' \ -H 'Content-Type: application/x-www-form-urlencoded' \ -d 'client_id=xxxxxxyyyyyyzzzzzz' Apex でのリクエスト実装例 HttpRequest req = new HttpRequest (); req . setMethod ( 'POST' ); req . setEndpoint ( 'https://api.cloudsign.jp/token' ); req . setHeader ( 'accept' , 'application/json' ); req . setHeader ( 'Content-Type' , 'application/x-www-form-urlencoded' ); req . setBody ( 'client_id=' + 'xxxxxxyyyyyyzzzzzz' ); 私自身、Apex もクラウドサイン API もこの案件を担当するまで触ったことがありませんでしたが、リクエストの試行から実装まで 2 週間かからない程度で実装することができました。 ただし、実装や運用にあたっては下記 2 点について注意が必要になります。 Apex からクラウドサインへのファイルのアップロードは単純ではない アクセストークンの有効期限はクラウドサインでコントロールされる 1. Apex からクラウドサインへのファイルのアップロードは単純ではない ファイルのアップロードについては今回使用した API の中で、唯一、テスト実行の curl と Apex のリクエスト実装で差分が生まれます。まず、その差分を確認するために curl コマンド例と Apex のリクエスト実装例で header、body にセットしている値を比較してみます。 API リファレンスでの curl コマンド例 curl -X 'POST' \ 'https://api.cloudsign.jp/documents/{document_id}/files' \ -H 'accept: application/json' \ -H 'Authorization: AAAAAABBBBBBCCCCCC' \ -H 'Content-Type: multipart/form-data' \ -F 'name=テスト' \ -F 'uploadfile=@テスト.pdf;type=application/pdf' Apex でのリクエスト実装例 HttpRequest req = new HttpRequest (); req . setMethod ( 'POST' ); req . setEndpoint ( 'https://api.cloudsign.jp/documents/{document_id}/files' ); req . setHeader ( 'accept' , 'application/json' ); req . setHeader ( 'Authorization' , ‘AAAAAABBBBBBCCCCCC’); req . setHeader ( 'Content-Type' , 'multipart/form-data; boundary={boundary}' ); // ※1 req . setBodyAsBlob ({multipartBody}); // ※2 主な違いは ※1 , ※2 とコメントした部分になります。 Apex では HTTP リクエストの値を手で書いていくことになるので、テスト実行例のように curl がよしなに処理している部分(-F オプションの部分や Apex で記載している boundary)も実装しなければなりません。これが単純に実装できない理由になります。 boundary については multipart/form-data を送信する際に必要な境界でヘッダーでどの文字列が境界であるかを設定します。 curl の-F オプションで定義していた文字列とファイル指定部分は、Apex でファイル(バイナリ)を扱うため、その body に含まれる文字列も含めて Blob 型で扱う必要があります( Content-Transfer-Encoding: base64 に API 提供側が対応している場合は例外になります)。そのため、文字列とバイナリデータを結合し一つの Blob にする方法は下記になります。 「バイナリデータ」、「body の開始からバイナリデータまでの文字列」、「バイナリデータ以降から終端までの文字列」の 3 グループに分ける。 3 グループをそれぞれ Base64 で符号化する。 符号化した「バイナリデータ」と「body の開始からバイナリデータまでの文字列」について、Base64 のデータパディングを示す”=”が含まれないように改行コードで調整する。 「body の開始からバイナリデータまでの文字列」、「バイナリデータ」、「バイナリデータ以降から終端までの文字列」の順で結合する。 結合した Base64 のデータを復号して、一つの Blob とする。 2. アクセストークンの有効期限はクラウドサインでコントロールされる アクセストークンやその有効期限は token API を発行した際のレスポンスとしてクラウドサインから発行されます。 発行されたレスポンス例 { "access_token" : "AAAAAABBBBBBCCCCCC" , "token_type" : “xxxx” , "expires_in" : 3600 } このレスポンスの内、expires_in の値がトークンの有効期限になります。掲題の通り、有効期限の管理はクラウドサイン側で行われ、有効期限内に再度トークンのリクエストを行った場合、経過した時間だけ expires_in の値が小さくなった結果が返ってきて、access_token などは同じ値が取得されます。有効期限内に token API を再度実行した結果が下記になります。 有効期限切れ前に token API を発行した際のレスポンス例 { "access_token" : "AAAAAABBBBBBCCCCCC" , "token_type" : “xxxx” , "expires_in" : 762 } 一方、有効期限後にトークンのリクエストを実行すると、それまでと異なるアクセストークンを取得し、新しい有効期限が設定されます。 有効期限切れ後に token API を発行した際のレスポンス例 { "access_token" : "XXXXXXYYYYYYZZZZZZ" , "token_type" : "xxxx" , "expires_in" : 3600 } そのため、API 連携が一度動いた後、有効期限ぎりぎりでもう一度 API 連携が動いてしまった場合、タイミングが悪いと契約文書の作成から最終処理である先方の送信先設定までのプロセス内のどこかから、トークンの有効期限切れが発生する可能性が想定されます。実際に期限切れが発生した場合、発生時以降に発行したその回の API 連携処理が失敗します。 トークンの有効期限切れが発生した際、API リファレンスより HTTP ステータスコードが 401 かつエラー内容が”unauthorized”で応答されることから、当社ではこのエラーを受けた場合にトークンを再取得して処理をリトライするように実装しました。 押印文書作成を例にとると下記のような実装イメージになります。 //クラウドサイン上に押印文書を作成し、作成した文書 ID を取得する public String getDocumentId ( String authToken, String title, String message){ ・・・中略・・・ HTTPResponse res = http . send (req); if ( res . getStatusCode () == 200 ){ ・・・正常に終了した際の処理・・・ } //タイミングが悪く token がタイムアウトした場合、トークンを取得し直して、リトライする else if ( res . getStatusCode () == 401 ){ //レスポンスの内容を確認するため、エラーレスポンスの中身を取得する Map < String , Object > responseBody = new Map < String , Object >(); responseBody = ( Map <String, Object>) JSON . deserializeUntyped ( res . getBody ()); String errorVal = (String) responseBody . get ( 'error' ); //リファレンス上、アクセストークンが無効(有効期限切れ)の場合、'unauthorized’となる if ( errorVal . equals ( 'unauthorized' )){ //クラウドサインのアクセストークンの再取得 authToken = getAuthToken (); //単純再帰で再実行する。 documentId = getDocumentId (authToken, title, message); } ・・・中略・・・ } ・・・以下省略・・・ } 実装を終えて 上記を実装した結果、稟議と入力内容が同じ、または、稟議から生成できる内容は全てシステム連携で自動生成するため、押印担当は稟議とクラウドサインの画面を並べて転記するような煩雑な作業を必要としない環境になりました。また、契約書の製本、郵送等の紙媒体であるが故の事務の削減ができるようになる等の、電子契約を導入することのそもそものメリットも併せて享受しています。 当社では 2021 年 4 月後半からクラウドサインを導入しましたが、2021 年 6 月時点ではすでに 月間で締結した契約書の「3 割以上」が電子契約を活用しており 、押印担当の展望として今後も利用を拡大していく予定です。 コーポレートエンジニア募集中 メドレーのコーポレート部門では、本稿のように、SaaS の導入ひとつとっても検討を尽くし、既存のシステムと有機的に結合させることで「徹底的に合理性を追求した組織基盤や、仕掛けづくり」を行っています。 面白そう！興味がある！と感じた方は、ぜひ当社採用ページからご応募お願いします！ 最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに はじめまして、コーポレートエンジニアの山下です。 2020 年に Slack を活用した ChatOps 稟議ワークフローを内製で開発したのですが、さらに、2021 年 4 月にこの Slack 稟議と電子契約システムである クラウドサイン を連携させて、電子契約をもっと便利に使い、生産性の向上を実現しましたのでお話しいたします。 まず、当社の稟議システムは 2020 年 12 月の当社の記事 のおさらいになりますが、稟議の作業が Slack 上で完結する、 ChatOps による稟議ワークフロー となっております。本稿については 2021 年 7 月に執筆しておりますので丁度導入から 1 年程経過し、その間大きなトラブルも無く、今も当社の極めて迅速な意思決定の一助になっています。ChatOps による稟議ワークフローについては、直近、2021 年 6 月に LayerX 社が LayerX ワークフローの新機能として発表 し、サービスとしても提供され、 日経新聞 でも取り上げられていることから、今現在のパラダイムとして、先進的で有効な一手法であったと再認識しております。 今回、新型コロナウイルス感染拡大防止に伴うリモートワークの加速という状況もあり、当社で 2021 年 4 月に電子契約システムとしてクラウドサインを導入しました。電子契約に限らず、契約押印作業は稟議の後続作業に当たるため、ただ導入して使用するのみならず、クラウドサインの API を利用して稟議上にあるデータを電子契約に送信させることでシームレスな連携を実現しています。本稿では当社が行ったシームレスな連携手法について詳細をご説明いたします。 TeamSpirit とクラウドサインの API 連携について 実装概要 弊社の稟議システムである TeamSpirit とクラウドサインとの連携についてお話しします。まず、本稿の開発部分とシステム構成は下記になっております。 処理内容の詳細は後ほど述べますが、概要としては TeamSprit(Apex)からクラウドサインの API をコールし、クラウドサイン上で作成した契約文書へ稟議に記載されている契約書ファイルや先方担当者等の情報を連携する仕組みとなっております。これにより契約担当者はクラウドサインにログイン後、下記の 3 ステップで先方に送信できるようになっています。 記載内容の確認 押印・署名箇所の設定 先方への送信 クラウドサインを使用して契約文書を一から作成する場合のユーザ作業と、当社で採用した API 連携行った場合のユーザ作業を比較したものが下記の表です。作業が半分程度削減されたことが分かります。 作業項番 一から作成する場合 API 連携を利用した当社の場合 1 ログイン ログイン 2 契約文書の作成(件名、契約文書としての宛名設定等) なし 3 契約書ファイルのアップロード なし 4 先方の送信先設定 なし 5 押印欄の設定 押印欄の設定 6 先方への送信 先方への送信 実装 今回の開発で使用した クラウドサイン API は下記の 5 つの API を使用しました (※以降、クラウドサイン API に倣い、変数を表現する場合は {} で括ります)。 API 種類 使用用途 post /token アクセストークンの取得 post /document 契約文書の作成 put /documents/{documentID}/attribute 契約文書の作成で設定できない、細かい項目の設定 post /documents/{documentID}/files ファイルのアップロード post /documents/{documentID}/participants 先方の送信先設定 全体像で記載したクラウドサインの連携部について、上記の API を織り交ぜて詳細化すると下図のようになります。 実装方法としてはクラウドサイン API のリファレンスを参照し、テスト実行時に出力される curl コマンドを参考に同様のレスポンスを得るように Apex で HTTP リクエストを実装しました。アクセストークンの取得を例にとると下記のようになります。 API リファレンスでの curl コマンド例 curl -X 'POST' \ 'https://api.cloudsign.jp/token' \ -H 'accept: application/json' \ -H 'Content-Type: application/x-www-form-urlencoded' \ -d 'client_id=xxxxxxyyyyyyzzzzzz' Apex でのリクエスト実装例 HttpRequest req = new HttpRequest (); req . setMethod ( 'POST' ); req . setEndpoint ( 'https://api.cloudsign.jp/token' ); req . setHeader ( 'accept' , 'application/json' ); req . setHeader ( 'Content-Type' , 'application/x-www-form-urlencoded' ); req . setBody ( 'client_id=' + 'xxxxxxyyyyyyzzzzzz' ); 私自身、Apex もクラウドサイン API もこの案件を担当するまで触ったことがありませんでしたが、リクエストの試行から実装まで 2 週間かからない程度で実装することができました。 ただし、実装や運用にあたっては下記 2 点について注意が必要になります。 Apex からクラウドサインへのファイルのアップロードは単純ではない アクセストークンの有効期限はクラウドサインでコントロールされる 1. Apex からクラウドサインへのファイルのアップロードは単純ではない ファイルのアップロードについては今回使用した API の中で、唯一、テスト実行の curl と Apex のリクエスト実装で差分が生まれます。まず、その差分を確認するために curl コマンド例と Apex のリクエスト実装例で header、body にセットしている値を比較してみます。 API リファレンスでの curl コマンド例 curl -X 'POST' \ 'https://api.cloudsign.jp/documents/{document_id}/files' \ -H 'accept: application/json' \ -H 'Authorization: AAAAAABBBBBBCCCCCC' \ -H 'Content-Type: multipart/form-data' \ -F 'name=テスト' \ -F 'uploadfile=@テスト.pdf;type=application/pdf' Apex でのリクエスト実装例 HttpRequest req = new HttpRequest (); req . setMethod ( 'POST' ); req . setEndpoint ( 'https://api.cloudsign.jp/documents/{document_id}/files' ); req . setHeader ( 'accept' , 'application/json' ); req . setHeader ( 'Authorization' , ‘AAAAAABBBBBBCCCCCC’); req . setHeader ( 'Content-Type' , 'multipart/form-data; boundary={boundary}' ); // ※1 req . setBodyAsBlob ({multipartBody}); // ※2 主な違いは ※1 , ※2 とコメントした部分になります。 Apex では HTTP リクエストの値を手で書いていくことになるので、テスト実行例のように curl がよしなに処理している部分(-F オプションの部分や Apex で記載している boundary)も実装しなければなりません。これが単純に実装できない理由になります。 boundary については multipart/form-data を送信する際に必要な境界でヘッダーでどの文字列が境界であるかを設定します。 curl の-F オプションで定義していた文字列とファイル指定部分は、Apex でファイル(バイナリ)を扱うため、その body に含まれる文字列も含めて Blob 型で扱う必要があります( Content-Transfer-Encoding: base64 に API 提供側が対応している場合は例外になります)。そのため、文字列とバイナリデータを結合し一つの Blob にする方法は下記になります。 「バイナリデータ」、「body の開始からバイナリデータまでの文字列」、「バイナリデータ以降から終端までの文字列」の 3 グループに分ける。 3 グループをそれぞれ Base64 で符号化する。 符号化した「バイナリデータ」と「body の開始からバイナリデータまでの文字列」について、Base64 のデータパディングを示す”=”が含まれないように改行コードで調整する。 「body の開始からバイナリデータまでの文字列」、「バイナリデータ」、「バイナリデータ以降から終端までの文字列」の順で結合する。 結合した Base64 のデータを復号して、一つの Blob とする。 2. アクセストークンの有効期限はクラウドサインでコントロールされる アクセストークンやその有効期限は token API を発行した際のレスポンスとしてクラウドサインから発行されます。 発行されたレスポンス例 { "access_token" : "AAAAAABBBBBBCCCCCC" , "token_type" : “xxxx” , "expires_in" : 3600 } このレスポンスの内、expires_in の値がトークンの有効期限になります。掲題の通り、有効期限の管理はクラウドサイン側で行われ、有効期限内に再度トークンのリクエストを行った場合、経過した時間だけ expires_in の値が小さくなった結果が返ってきて、access_token などは同じ値が取得されます。有効期限内に token API を再度実行した結果が下記になります。 有効期限切れ前に token API を発行した際のレスポンス例 { "access_token" : "AAAAAABBBBBBCCCCCC" , "token_type" : “xxxx” , "expires_in" : 762 } 一方、有効期限後にトークンのリクエストを実行すると、それまでと異なるアクセストークンを取得し、新しい有効期限が設定されます。 有効期限切れ後に token API を発行した際のレスポンス例 { "access_token" : "XXXXXXYYYYYYZZZZZZ" , "token_type" : "xxxx" , "expires_in" : 3600 } そのため、API 連携が一度動いた後、有効期限ぎりぎりでもう一度 API 連携が動いてしまった場合、タイミングが悪いと契約文書の作成から最終処理である先方の送信先設定までのプロセス内のどこかから、トークンの有効期限切れが発生する可能性が想定されます。実際に期限切れが発生した場合、発生時以降に発行したその回の API 連携処理が失敗します。 トークンの有効期限切れが発生した際、API リファレンスより HTTP ステータスコードが 401 かつエラー内容が”unauthorized”で応答されることから、当社ではこのエラーを受けた場合にトークンを再取得して処理をリトライするように実装しました。 押印文書作成を例にとると下記のような実装イメージになります。 //クラウドサイン上に押印文書を作成し、作成した文書 ID を取得する public String getDocumentId ( String authToken, String title, String message){ ・・・中略・・・ HTTPResponse res = http . send (req); if ( res . getStatusCode () == 200 ){ ・・・正常に終了した際の処理・・・ } //タイミングが悪く token がタイムアウトした場合、トークンを取得し直して、リトライする else if ( res . getStatusCode () == 401 ){ //レスポンスの内容を確認するため、エラーレスポンスの中身を取得する Map < String , Object > responseBody = new Map < String , Object >(); responseBody = ( Map <String, Object>) JSON . deserializeUntyped ( res . getBody ()); String errorVal = (String) responseBody . get ( 'error' ); //リファレンス上、アクセストークンが無効(有効期限切れ)の場合、'unauthorized’となる if ( errorVal . equals ( 'unauthorized' )){ //クラウドサインのアクセストークンの再取得 authToken = getAuthToken (); //単純再帰で再実行する。 documentId = getDocumentId (authToken, title, message); } ・・・中略・・・ } ・・・以下省略・・・ } 実装を終えて 上記を実装した結果、稟議と入力内容が同じ、または、稟議から生成できる内容は全てシステム連携で自動生成するため、押印担当は稟議とクラウドサインの画面を並べて転記するような煩雑な作業を必要としない環境になりました。また、契約書の製本、郵送等の紙媒体であるが故の事務の削減ができるようになる等の、電子契約を導入することのそもそものメリットも併せて享受しています。 当社では 2021 年 4 月後半からクラウドサインを導入しましたが、2021 年 6 月時点ではすでに 月間で締結した契約書の「3 割以上」が電子契約を活用しており 、押印担当の展望として今後も利用を拡大していく予定です。 コーポレートエンジニア募集中 メドレーのコーポレート部門では、本稿のように、SaaS の導入ひとつとっても検討を尽くし、既存のシステムと有機的に結合させることで「徹底的に合理性を追求した組織基盤や、仕掛けづくり」を行っています。 面白そう！興味がある！と感じた方は、ぜひ当社採用ページからご応募お願いします！ 最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに はじめまして、コーポレートエンジニアの山下です。 2020 年に Slack を活用した ChatOps 稟議ワークフローを内製で開発したのですが、さらに、2021 年 4 月にこの Slack 稟議と電子契約システムである クラウドサイン を連携させて、電子契約をもっと便利に使い、生産性の向上を実現しましたのでお話しいたします。 まず、当社の稟議システムは 2020 年 12 月の当社の記事 のおさらいになりますが、稟議の作業が Slack 上で完結する、 ChatOps による稟議ワークフロー となっております。本稿については 2021 年 7 月に執筆しておりますので丁度導入から 1 年程経過し、その間大きなトラブルも無く、今も当社の極めて迅速な意思決定の一助になっています。ChatOps による稟議ワークフローについては、直近、2021 年 6 月に LayerX 社が LayerX ワークフローの新機能として発表 し、サービスとしても提供され、 日経新聞 でも取り上げられていることから、今現在のパラダイムとして、先進的で有効な一手法であったと再認識しております。 今回、新型コロナウイルス感染拡大防止に伴うリモートワークの加速という状況もあり、当社で 2021 年 4 月に電子契約システムとしてクラウドサインを導入しました。電子契約に限らず、契約押印作業は稟議の後続作業に当たるため、ただ導入して使用するのみならず、クラウドサインの API を利用して稟議上にあるデータを電子契約に送信させることでシームレスな連携を実現しています。本稿では当社が行ったシームレスな連携手法について詳細をご説明いたします。 TeamSpirit とクラウドサインの API 連携について 実装概要 弊社の稟議システムである TeamSpirit とクラウドサインとの連携についてお話しします。まず、本稿の開発部分とシステム構成は下記になっております。 処理内容の詳細は後ほど述べますが、概要としては TeamSprit(Apex)からクラウドサインの API をコールし、クラウドサイン上で作成した契約文書へ稟議に記載されている契約書ファイルや先方担当者等の情報を連携する仕組みとなっております。これにより契約担当者はクラウドサインにログイン後、下記の 3 ステップで先方に送信できるようになっています。 記載内容の確認 押印・署名箇所の設定 先方への送信 クラウドサインを使用して契約文書を一から作成する場合のユーザ作業と、当社で採用した API 連携行った場合のユーザ作業を比較したものが下記の表です。作業が半分程度削減されたことが分かります。 作業項番 一から作成する場合 API 連携を利用した当社の場合 1 ログイン ログイン 2 契約文書の作成(件名、契約文書としての宛名設定等) なし 3 契約書ファイルのアップロード なし 4 先方の送信先設定 なし 5 押印欄の設定 押印欄の設定 6 先方への送信 先方への送信 実装 今回の開発で使用した クラウドサイン API は下記の 5 つの API を使用しました (※以降、クラウドサイン API に倣い、変数を表現する場合は {} で括ります)。 API 種類 使用用途 post /token アクセストークンの取得 post /document 契約文書の作成 put /documents/{documentID}/attribute 契約文書の作成で設定できない、細かい項目の設定 post /documents/{documentID}/files ファイルのアップロード post /documents/{documentID}/participants 先方の送信先設定 全体像で記載したクラウドサインの連携部について、上記の API を織り交ぜて詳細化すると下図のようになります。 実装方法としてはクラウドサイン API のリファレンスを参照し、テスト実行時に出力される curl コマンドを参考に同様のレスポンスを得るように Apex で HTTP リクエストを実装しました。アクセストークンの取得を例にとると下記のようになります。 API リファレンスでの curl コマンド例 curl -X 'POST' \ 'https://api.cloudsign.jp/token' \ -H 'accept: application/json' \ -H 'Content-Type: application/x-www-form-urlencoded' \ -d 'client_id=xxxxxxyyyyyyzzzzzz' Apex でのリクエスト実装例 HttpRequest req = new HttpRequest (); req . setMethod ( 'POST' ); req . setEndpoint ( 'https://api.cloudsign.jp/token' ); req . setHeader ( 'accept' , 'application/json' ); req . setHeader ( 'Content-Type' , 'application/x-www-form-urlencoded' ); req . setBody ( 'client_id=' + 'xxxxxxyyyyyyzzzzzz' ); 私自身、Apex もクラウドサイン API もこの案件を担当するまで触ったことがありませんでしたが、リクエストの試行から実装まで 2 週間かからない程度で実装することができました。 ただし、実装や運用にあたっては下記 2 点について注意が必要になります。 Apex からクラウドサインへのファイルのアップロードは単純ではない アクセストークンの有効期限はクラウドサインでコントロールされる 1. Apex からクラウドサインへのファイルのアップロードは単純ではない ファイルのアップロードについては今回使用した API の中で、唯一、テスト実行の curl と Apex のリクエスト実装で差分が生まれます。まず、その差分を確認するために curl コマンド例と Apex のリクエスト実装例で header、body にセットしている値を比較してみます。 API リファレンスでの curl コマンド例 curl -X 'POST' \ 'https://api.cloudsign.jp/documents/{document_id}/files' \ -H 'accept: application/json' \ -H 'Authorization: AAAAAABBBBBBCCCCCC' \ -H 'Content-Type: multipart/form-data' \ -F 'name=テスト' \ -F 'uploadfile=@テスト.pdf;type=application/pdf' Apex でのリクエスト実装例 HttpRequest req = new HttpRequest (); req . setMethod ( 'POST' ); req . setEndpoint ( 'https://api.cloudsign.jp/documents/{document_id}/files' ); req . setHeader ( 'accept' , 'application/json' ); req . setHeader ( 'Authorization' , ‘AAAAAABBBBBBCCCCCC’); req . setHeader ( 'Content-Type' , 'multipart/form-data; boundary={boundary}' ); // ※1 req . setBodyAsBlob ({multipartBody}); // ※2 主な違いは ※1 , ※2 とコメントした部分になります。 Apex では HTTP リクエストの値を手で書いていくことになるので、テスト実行例のように curl がよしなに処理している部分(-F オプションの部分や Apex で記載している boundary)も実装しなければなりません。これが単純に実装できない理由になります。 boundary については multipart/form-data を送信する際に必要な境界でヘッダーでどの文字列が境界であるかを設定します。 curl の-F オプションで定義していた文字列とファイル指定部分は、Apex でファイル(バイナリ)を扱うため、その body に含まれる文字列も含めて Blob 型で扱う必要があります( Content-Transfer-Encoding: base64 に API 提供側が対応している場合は例外になります)。そのため、文字列とバイナリデータを結合し一つの Blob にする方法は下記になります。 「バイナリデータ」、「body の開始からバイナリデータまでの文字列」、「バイナリデータ以降から終端までの文字列」の 3 グループに分ける。 3 グループをそれぞれ Base64 で符号化する。 符号化した「バイナリデータ」と「body の開始からバイナリデータまでの文字列」について、Base64 のデータパディングを示す”=”が含まれないように改行コードで調整する。 「body の開始からバイナリデータまでの文字列」、「バイナリデータ」、「バイナリデータ以降から終端までの文字列」の順で結合する。 結合した Base64 のデータを復号して、一つの Blob とする。 2. アクセストークンの有効期限はクラウドサインでコントロールされる アクセストークンやその有効期限は token API を発行した際のレスポンスとしてクラウドサインから発行されます。 発行されたレスポンス例 { "access_token" : "AAAAAABBBBBBCCCCCC" , "token_type" : “xxxx” , "expires_in" : 3600 } このレスポンスの内、expires_in の値がトークンの有効期限になります。掲題の通り、有効期限の管理はクラウドサイン側で行われ、有効期限内に再度トークンのリクエストを行った場合、経過した時間だけ expires_in の値が小さくなった結果が返ってきて、access_token などは同じ値が取得されます。有効期限内に token API を再度実行した結果が下記になります。 有効期限切れ前に token API を発行した際のレスポンス例 { "access_token" : "AAAAAABBBBBBCCCCCC" , "token_type" : “xxxx” , "expires_in" : 762 } 一方、有効期限後にトークンのリクエストを実行すると、それまでと異なるアクセストークンを取得し、新しい有効期限が設定されます。 有効期限切れ後に token API を発行した際のレスポンス例 { "access_token" : "XXXXXXYYYYYYZZZZZZ" , "token_type" : "xxxx" , "expires_in" : 3600 } そのため、API 連携が一度動いた後、有効期限ぎりぎりでもう一度 API 連携が動いてしまった場合、タイミングが悪いと契約文書の作成から最終処理である先方の送信先設定までのプロセス内のどこかから、トークンの有効期限切れが発生する可能性が想定されます。実際に期限切れが発生した場合、発生時以降に発行したその回の API 連携処理が失敗します。 トークンの有効期限切れが発生した際、API リファレンスより HTTP ステータスコードが 401 かつエラー内容が”unauthorized”で応答されることから、当社ではこのエラーを受けた場合にトークンを再取得して処理をリトライするように実装しました。 押印文書作成を例にとると下記のような実装イメージになります。 //クラウドサイン上に押印文書を作成し、作成した文書 ID を取得する public String getDocumentId ( String authToken, String title, String message){ ・・・中略・・・ HTTPResponse res = http . send (req); if ( res . getStatusCode () == 200 ){ ・・・正常に終了した際の処理・・・ } //タイミングが悪く token がタイムアウトした場合、トークンを取得し直して、リトライする else if ( res . getStatusCode () == 401 ){ //レスポンスの内容を確認するため、エラーレスポンスの中身を取得する Map < String , Object > responseBody = new Map < String , Object >(); responseBody = ( Map <String, Object>) JSON . deserializeUntyped ( res . getBody ()); String errorVal = (String) responseBody . get ( 'error' ); //リファレンス上、アクセストークンが無効(有効期限切れ)の場合、'unauthorized’となる if ( errorVal . equals ( 'unauthorized' )){ //クラウドサインのアクセストークンの再取得 authToken = getAuthToken (); //単純再帰で再実行する。 documentId = getDocumentId (authToken, title, message); } ・・・中略・・・ } ・・・以下省略・・・ } 実装を終えて 上記を実装した結果、稟議と入力内容が同じ、または、稟議から生成できる内容は全てシステム連携で自動生成するため、押印担当は稟議とクラウドサインの画面を並べて転記するような煩雑な作業を必要としない環境になりました。また、契約書の製本、郵送等の紙媒体であるが故の事務の削減ができるようになる等の、電子契約を導入することのそもそものメリットも併せて享受しています。 当社では 2021 年 4 月後半からクラウドサインを導入しましたが、2021 年 6 月時点ではすでに 月間で締結した契約書の「3 割以上」が電子契約を活用しており 、押印担当の展望として今後も利用を拡大していく予定です。 コーポレートエンジニア募集中 メドレーのコーポレート部門では、本稿のように、SaaS の導入ひとつとっても検討を尽くし、既存のシステムと有機的に結合させることで「徹底的に合理性を追求した組織基盤や、仕掛けづくり」を行っています。 面白そう！興味がある！と感じた方は、ぜひ当社採用ページからご応募お願いします！ 最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに はじめまして、コーポレートエンジニアの山下です。 2020 年に Slack を活用した ChatOps 稟議ワークフローを内製で開発したのですが、さらに、2021 年 4 月にこの Slack 稟議と電子契約システムである クラウドサイン を連携させて、電子契約をもっと便利に使い、生産性の向上を実現しましたのでお話しいたします。 まず、当社の稟議システムは 2020 年 12 月の当社の記事 のおさらいになりますが、稟議の作業が Slack 上で完結する、 ChatOps による稟議ワークフロー となっております。本稿については 2021 年 7 月に執筆しておりますので丁度導入から 1 年程経過し、その間大きなトラブルも無く、今も当社の極めて迅速な意思決定の一助になっています。ChatOps による稟議ワークフローについては、直近、2021 年 6 月に LayerX 社が LayerX ワークフローの新機能として発表 し、サービスとしても提供され、 日経新聞 でも取り上げられていることから、今現在のパラダイムとして、先進的で有効な一手法であったと再認識しております。 今回、新型コロナウイルス感染拡大防止に伴うリモートワークの加速という状況もあり、当社で 2021 年 4 月に電子契約システムとしてクラウドサインを導入しました。電子契約に限らず、契約押印作業は稟議の後続作業に当たるため、ただ導入して使用するのみならず、クラウドサインの API を利用して稟議上にあるデータを電子契約に送信させることでシームレスな連携を実現しています。本稿では当社が行ったシームレスな連携手法について詳細をご説明いたします。 TeamSpirit とクラウドサインの API 連携について 実装概要 弊社の稟議システムである TeamSpirit とクラウドサインとの連携についてお話しします。まず、本稿の開発部分とシステム構成は下記になっております。 処理内容の詳細は後ほど述べますが、概要としては TeamSprit(Apex)からクラウドサインの API をコールし、クラウドサイン上で作成した契約文書へ稟議に記載されている契約書ファイルや先方担当者等の情報を連携する仕組みとなっております。これにより契約担当者はクラウドサインにログイン後、下記の 3 ステップで先方に送信できるようになっています。 記載内容の確認 押印・署名箇所の設定 先方への送信 クラウドサインを使用して契約文書を一から作成する場合のユーザ作業と、当社で採用した API 連携行った場合のユーザ作業を比較したものが下記の表です。作業が半分程度削減されたことが分かります。 作業項番 一から作成する場合 API 連携を利用した当社の場合 1 ログイン ログイン 2 契約文書の作成(件名、契約文書としての宛名設定等) なし 3 契約書ファイルのアップロード なし 4 先方の送信先設定 なし 5 押印欄の設定 押印欄の設定 6 先方への送信 先方への送信 実装 今回の開発で使用した クラウドサイン API は下記の 5 つの API を使用しました (※以降、クラウドサイン API に倣い、変数を表現する場合は {} で括ります)。 API 種類 使用用途 post /token アクセストークンの取得 post /document 契約文書の作成 put /documents/{documentID}/attribute 契約文書の作成で設定できない、細かい項目の設定 post /documents/{documentID}/files ファイルのアップロード post /documents/{documentID}/participants 先方の送信先設定 全体像で記載したクラウドサインの連携部について、上記の API を織り交ぜて詳細化すると下図のようになります。 実装方法としてはクラウドサイン API のリファレンスを参照し、テスト実行時に出力される curl コマンドを参考に同様のレスポンスを得るように Apex で HTTP リクエストを実装しました。アクセストークンの取得を例にとると下記のようになります。 API リファレンスでの curl コマンド例 curl -X 'POST' \ 'https://api.cloudsign.jp/token' \ -H 'accept: application/json' \ -H 'Content-Type: application/x-www-form-urlencoded' \ -d 'client_id=xxxxxxyyyyyyzzzzzz' Apex でのリクエスト実装例 HttpRequest req = new HttpRequest (); req . setMethod ( 'POST' ); req . setEndpoint ( 'https://api.cloudsign.jp/token' ); req . setHeader ( 'accept' , 'application/json' ); req . setHeader ( 'Content-Type' , 'application/x-www-form-urlencoded' ); req . setBody ( 'client_id=' + 'xxxxxxyyyyyyzzzzzz' ); 私自身、Apex もクラウドサイン API もこの案件を担当するまで触ったことがありませんでしたが、リクエストの試行から実装まで 2 週間かからない程度で実装することができました。 ただし、実装や運用にあたっては下記 2 点について注意が必要になります。 Apex からクラウドサインへのファイルのアップロードは単純ではない アクセストークンの有効期限はクラウドサインでコントロールされる 1. Apex からクラウドサインへのファイルのアップロードは単純ではない ファイルのアップロードについては今回使用した API の中で、唯一、テスト実行の curl と Apex のリクエスト実装で差分が生まれます。まず、その差分を確認するために curl コマンド例と Apex のリクエスト実装例で header、body にセットしている値を比較してみます。 API リファレンスでの curl コマンド例 curl -X 'POST' \ 'https://api.cloudsign.jp/documents/{document_id}/files' \ -H 'accept: application/json' \ -H 'Authorization: AAAAAABBBBBBCCCCCC' \ -H 'Content-Type: multipart/form-data' \ -F 'name=テスト' \ -F 'uploadfile=@テスト.pdf;type=application/pdf' Apex でのリクエスト実装例 HttpRequest req = new HttpRequest (); req . setMethod ( 'POST' ); req . setEndpoint ( 'https://api.cloudsign.jp/documents/{document_id}/files' ); req . setHeader ( 'accept' , 'application/json' ); req . setHeader ( 'Authorization' , ‘AAAAAABBBBBBCCCCCC’); req . setHeader ( 'Content-Type' , 'multipart/form-data; boundary={boundary}' ); // ※1 req . setBodyAsBlob ({multipartBody}); // ※2 主な違いは ※1 , ※2 とコメントした部分になります。 Apex では HTTP リクエストの値を手で書いていくことになるので、テスト実行例のように curl がよしなに処理している部分(-F オプションの部分や Apex で記載している boundary)も実装しなければなりません。これが単純に実装できない理由になります。 boundary については multipart/form-data を送信する際に必要な境界でヘッダーでどの文字列が境界であるかを設定します。 curl の-F オプションで定義していた文字列とファイル指定部分は、Apex でファイル(バイナリ)を扱うため、その body に含まれる文字列も含めて Blob 型で扱う必要があります( Content-Transfer-Encoding: base64 に API 提供側が対応している場合は例外になります)。そのため、文字列とバイナリデータを結合し一つの Blob にする方法は下記になります。 「バイナリデータ」、「body の開始からバイナリデータまでの文字列」、「バイナリデータ以降から終端までの文字列」の 3 グループに分ける。 3 グループをそれぞれ Base64 で符号化する。 符号化した「バイナリデータ」と「body の開始からバイナリデータまでの文字列」について、Base64 のデータパディングを示す”=”が含まれないように改行コードで調整する。 「body の開始からバイナリデータまでの文字列」、「バイナリデータ」、「バイナリデータ以降から終端までの文字列」の順で結合する。 結合した Base64 のデータを復号して、一つの Blob とする。 2. アクセストークンの有効期限はクラウドサインでコントロールされる アクセストークンやその有効期限は token API を発行した際のレスポンスとしてクラウドサインから発行されます。 発行されたレスポンス例 { "access_token" : "AAAAAABBBBBBCCCCCC" , "token_type" : “xxxx” , "expires_in" : 3600 } このレスポンスの内、expires_in の値がトークンの有効期限になります。掲題の通り、有効期限の管理はクラウドサイン側で行われ、有効期限内に再度トークンのリクエストを行った場合、経過した時間だけ expires_in の値が小さくなった結果が返ってきて、access_token などは同じ値が取得されます。有効期限内に token API を再度実行した結果が下記になります。 有効期限切れ前に token API を発行した際のレスポンス例 { "access_token" : "AAAAAABBBBBBCCCCCC" , "token_type" : “xxxx” , "expires_in" : 762 } 一方、有効期限後にトークンのリクエストを実行すると、それまでと異なるアクセストークンを取得し、新しい有効期限が設定されます。 有効期限切れ後に token API を発行した際のレスポンス例 { "access_token" : "XXXXXXYYYYYYZZZZZZ" , "token_type" : "xxxx" , "expires_in" : 3600 } そのため、API 連携が一度動いた後、有効期限ぎりぎりでもう一度 API 連携が動いてしまった場合、タイミングが悪いと契約文書の作成から最終処理である先方の送信先設定までのプロセス内のどこかから、トークンの有効期限切れが発生する可能性が想定されます。実際に期限切れが発生した場合、発生時以降に発行したその回の API 連携処理が失敗します。 トークンの有効期限切れが発生した際、API リファレンスより HTTP ステータスコードが 401 かつエラー内容が”unauthorized”で応答されることから、当社ではこのエラーを受けた場合にトークンを再取得して処理をリトライするように実装しました。 押印文書作成を例にとると下記のような実装イメージになります。 //クラウドサイン上に押印文書を作成し、作成した文書 ID を取得する public String getDocumentId ( String authToken, String title, String message){ ・・・中略・・・ HTTPResponse res = http . send (req); if ( res . getStatusCode () == 200 ){ ・・・正常に終了した際の処理・・・ } //タイミングが悪く token がタイムアウトした場合、トークンを取得し直して、リトライする else if ( res . getStatusCode () == 401 ){ //レスポンスの内容を確認するため、エラーレスポンスの中身を取得する Map < String , Object > responseBody = new Map < String , Object >(); responseBody = ( Map <String, Object>) JSON . deserializeUntyped ( res . getBody ()); String errorVal = (String) responseBody . get ( 'error' ); //リファレンス上、アクセストークンが無効(有効期限切れ)の場合、'unauthorized’となる if ( errorVal . equals ( 'unauthorized' )){ //クラウドサインのアクセストークンの再取得 authToken = getAuthToken (); //単純再帰で再実行する。 documentId = getDocumentId (authToken, title, message); } ・・・中略・・・ } ・・・以下省略・・・ } 実装を終えて 上記を実装した結果、稟議と入力内容が同じ、または、稟議から生成できる内容は全てシステム連携で自動生成するため、押印担当は稟議とクラウドサインの画面を並べて転記するような煩雑な作業を必要としない環境になりました。また、契約書の製本、郵送等の紙媒体であるが故の事務の削減ができるようになる等の、電子契約を導入することのそもそものメリットも併せて享受しています。 当社では 2021 年 4 月後半からクラウドサインを導入しましたが、2021 年 6 月時点ではすでに 月間で締結した契約書の「3 割以上」が電子契約を活用しており 、押印担当の展望として今後も利用を拡大していく予定です。 コーポレートエンジニア募集中 メドレーのコーポレート部門では、本稿のように、SaaS の導入ひとつとっても検討を尽くし、既存のシステムと有機的に結合させることで「徹底的に合理性を追求した組織基盤や、仕掛けづくり」を行っています。 面白そう！興味がある！と感じた方は、ぜひ当社採用ページからご応募お願いします！ 最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに はじめまして、コーポレートエンジニアの山下です。 2020 年に Slack を活用した ChatOps 稟議ワークフローを内製で開発したのですが、さらに、2021 年 4 月にこの Slack 稟議と電子契約システムである クラウドサイン を連携させて、電子契約をもっと便利に使い、生産性の向上を実現しましたのでお話しいたします。 まず、当社の稟議システムは 2020 年 12 月の当社の記事 のおさらいになりますが、稟議の作業が Slack 上で完結する、 ChatOps による稟議ワークフロー となっております。本稿については 2021 年 7 月に執筆しておりますので丁度導入から 1 年程経過し、その間大きなトラブルも無く、今も当社の極めて迅速な意思決定の一助になっています。ChatOps による稟議ワークフローについては、直近、2021 年 6 月に LayerX 社が LayerX ワークフローの新機能として発表 し、サービスとしても提供され、 日経新聞 でも取り上げられていることから、今現在のパラダイムとして、先進的で有効な一手法であったと再認識しております。 今回、新型コロナウイルス感染拡大防止に伴うリモートワークの加速という状況もあり、当社で 2021 年 4 月に電子契約システムとしてクラウドサインを導入しました。電子契約に限らず、契約押印作業は稟議の後続作業に当たるため、ただ導入して使用するのみならず、クラウドサインの API を利用して稟議上にあるデータを電子契約に送信させることでシームレスな連携を実現しています。本稿では当社が行ったシームレスな連携手法について詳細をご説明いたします。 TeamSpirit とクラウドサインの API 連携について 実装概要 弊社の稟議システムである TeamSpirit とクラウドサインとの連携についてお話しします。まず、本稿の開発部分とシステム構成は下記になっております。 処理内容の詳細は後ほど述べますが、概要としては TeamSprit(Apex)からクラウドサインの API をコールし、クラウドサイン上で作成した契約文書へ稟議に記載されている契約書ファイルや先方担当者等の情報を連携する仕組みとなっております。これにより契約担当者はクラウドサインにログイン後、下記の 3 ステップで先方に送信できるようになっています。 記載内容の確認 押印・署名箇所の設定 先方への送信 クラウドサインを使用して契約文書を一から作成する場合のユーザ作業と、当社で採用した API 連携行った場合のユーザ作業を比較したものが下記の表です。作業が半分程度削減されたことが分かります。 作業項番 一から作成する場合 API 連携を利用した当社の場合 1 ログイン ログイン 2 契約文書の作成(件名、契約文書としての宛名設定等) なし 3 契約書ファイルのアップロード なし 4 先方の送信先設定 なし 5 押印欄の設定 押印欄の設定 6 先方への送信 先方への送信 実装 今回の開発で使用した クラウドサイン API は下記の 5 つの API を使用しました (※以降、クラウドサイン API に倣い、変数を表現する場合は {} で括ります)。 API 種類 使用用途 post /token アクセストークンの取得 post /document 契約文書の作成 put /documents/{documentID}/attribute 契約文書の作成で設定できない、細かい項目の設定 post /documents/{documentID}/files ファイルのアップロード post /documents/{documentID}/participants 先方の送信先設定 全体像で記載したクラウドサインの連携部について、上記の API を織り交ぜて詳細化すると下図のようになります。 実装方法としてはクラウドサイン API のリファレンスを参照し、テスト実行時に出力される curl コマンドを参考に同様のレスポンスを得るように Apex で HTTP リクエストを実装しました。アクセストークンの取得を例にとると下記のようになります。 API リファレンスでの curl コマンド例 curl -X 'POST' \ 'https://api.cloudsign.jp/token' \ -H 'accept: application/json' \ -H 'Content-Type: application/x-www-form-urlencoded' \ -d 'client_id=xxxxxxyyyyyyzzzzzz' Apex でのリクエスト実装例 HttpRequest req = new HttpRequest (); req . setMethod ( 'POST' ); req . setEndpoint ( 'https://api.cloudsign.jp/token' ); req . setHeader ( 'accept' , 'application/json' ); req . setHeader ( 'Content-Type' , 'application/x-www-form-urlencoded' ); req . setBody ( 'client_id=' + 'xxxxxxyyyyyyzzzzzz' ); 私自身、Apex もクラウドサイン API もこの案件を担当するまで触ったことがありませんでしたが、リクエストの試行から実装まで 2 週間かからない程度で実装することができました。 ただし、実装や運用にあたっては下記 2 点について注意が必要になります。 Apex からクラウドサインへのファイルのアップロードは単純ではない アクセストークンの有効期限はクラウドサインでコントロールされる 1. Apex からクラウドサインへのファイルのアップロードは単純ではない ファイルのアップロードについては今回使用した API の中で、唯一、テスト実行の curl と Apex のリクエスト実装で差分が生まれます。まず、その差分を確認するために curl コマンド例と Apex のリクエスト実装例で header、body にセットしている値を比較してみます。 API リファレンスでの curl コマンド例 curl -X 'POST' \ 'https://api.cloudsign.jp/documents/{document_id}/files' \ -H 'accept: application/json' \ -H 'Authorization: AAAAAABBBBBBCCCCCC' \ -H 'Content-Type: multipart/form-data' \ -F 'name=テスト' \ -F 'uploadfile=@テスト.pdf;type=application/pdf' Apex でのリクエスト実装例 HttpRequest req = new HttpRequest (); req . setMethod ( 'POST' ); req . setEndpoint ( 'https://api.cloudsign.jp/documents/{document_id}/files' ); req . setHeader ( 'accept' , 'application/json' ); req . setHeader ( 'Authorization' , ‘AAAAAABBBBBBCCCCCC’); req . setHeader ( 'Content-Type' , 'multipart/form-data; boundary={boundary}' ); // ※1 req . setBodyAsBlob ({multipartBody}); // ※2 主な違いは ※1 , ※2 とコメントした部分になります。 Apex では HTTP リクエストの値を手で書いていくことになるので、テスト実行例のように curl がよしなに処理している部分(-F オプションの部分や Apex で記載している boundary)も実装しなければなりません。これが単純に実装できない理由になります。 boundary については multipart/form-data を送信する際に必要な境界でヘッダーでどの文字列が境界であるかを設定します。 curl の-F オプションで定義していた文字列とファイル指定部分は、Apex でファイル(バイナリ)を扱うため、その body に含まれる文字列も含めて Blob 型で扱う必要があります( Content-Transfer-Encoding: base64 に API 提供側が対応している場合は例外になります)。そのため、文字列とバイナリデータを結合し一つの Blob にする方法は下記になります。 「バイナリデータ」、「body の開始からバイナリデータまでの文字列」、「バイナリデータ以降から終端までの文字列」の 3 グループに分ける。 3 グループをそれぞれ Base64 で符号化する。 符号化した「バイナリデータ」と「body の開始からバイナリデータまでの文字列」について、Base64 のデータパディングを示す”=”が含まれないように改行コードで調整する。 「body の開始からバイナリデータまでの文字列」、「バイナリデータ」、「バイナリデータ以降から終端までの文字列」の順で結合する。 結合した Base64 のデータを復号して、一つの Blob とする。 2. アクセストークンの有効期限はクラウドサインでコントロールされる アクセストークンやその有効期限は token API を発行した際のレスポンスとしてクラウドサインから発行されます。 発行されたレスポンス例 { "access_token" : "AAAAAABBBBBBCCCCCC" , "token_type" : “xxxx” , "expires_in" : 3600 } このレスポンスの内、expires_in の値がトークンの有効期限になります。掲題の通り、有効期限の管理はクラウドサイン側で行われ、有効期限内に再度トークンのリクエストを行った場合、経過した時間だけ expires_in の値が小さくなった結果が返ってきて、access_token などは同じ値が取得されます。有効期限内に token API を再度実行した結果が下記になります。 有効期限切れ前に token API を発行した際のレスポンス例 { "access_token" : "AAAAAABBBBBBCCCCCC" , "token_type" : “xxxx” , "expires_in" : 762 } 一方、有効期限後にトークンのリクエストを実行すると、それまでと異なるアクセストークンを取得し、新しい有効期限が設定されます。 有効期限切れ後に token API を発行した際のレスポンス例 { "access_token" : "XXXXXXYYYYYYZZZZZZ" , "token_type" : "xxxx" , "expires_in" : 3600 } そのため、API 連携が一度動いた後、有効期限ぎりぎりでもう一度 API 連携が動いてしまった場合、タイミングが悪いと契約文書の作成から最終処理である先方の送信先設定までのプロセス内のどこかから、トークンの有効期限切れが発生する可能性が想定されます。実際に期限切れが発生した場合、発生時以降に発行したその回の API 連携処理が失敗します。 トークンの有効期限切れが発生した際、API リファレンスより HTTP ステータスコードが 401 かつエラー内容が”unauthorized”で応答されることから、当社ではこのエラーを受けた場合にトークンを再取得して処理をリトライするように実装しました。 押印文書作成を例にとると下記のような実装イメージになります。 //クラウドサイン上に押印文書を作成し、作成した文書 ID を取得する public String getDocumentId ( String authToken, String title, String message){ ・・・中略・・・ HTTPResponse res = http . send (req); if ( res . getStatusCode () == 200 ){ ・・・正常に終了した際の処理・・・ } //タイミングが悪く token がタイムアウトした場合、トークンを取得し直して、リトライする else if ( res . getStatusCode () == 401 ){ //レスポンスの内容を確認するため、エラーレスポンスの中身を取得する Map < String , Object > responseBody = new Map < String , Object >(); responseBody = ( Map <String, Object>) JSON . deserializeUntyped ( res . getBody ()); String errorVal = (String) responseBody . get ( 'error' ); //リファレンス上、アクセストークンが無効(有効期限切れ)の場合、'unauthorized’となる if ( errorVal . equals ( 'unauthorized' )){ //クラウドサインのアクセストークンの再取得 authToken = getAuthToken (); //単純再帰で再実行する。 documentId = getDocumentId (authToken, title, message); } ・・・中略・・・ } ・・・以下省略・・・ } 実装を終えて 上記を実装した結果、稟議と入力内容が同じ、または、稟議から生成できる内容は全てシステム連携で自動生成するため、押印担当は稟議とクラウドサインの画面を並べて転記するような煩雑な作業を必要としない環境になりました。また、契約書の製本、郵送等の紙媒体であるが故の事務の削減ができるようになる等の、電子契約を導入することのそもそものメリットも併せて享受しています。 当社では 2021 年 4 月後半からクラウドサインを導入しましたが、2021 年 6 月時点ではすでに 月間で締結した契約書の「3 割以上」が電子契約を活用しており 、押印担当の展望として今後も利用を拡大していく予定です。 コーポレートエンジニア募集中 メドレーのコーポレート部門では、本稿のように、SaaS の導入ひとつとっても検討を尽くし、既存のシステムと有機的に結合させることで「徹底的に合理性を追求した組織基盤や、仕掛けづくり」を行っています。 面白そう！興味がある！と感じた方は、ぜひ当社採用ページからご応募お願いします！ 最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに はじめまして、コーポレートエンジニアの山下です。 2020 年に Slack を活用した ChatOps 稟議ワークフローを内製で開発したのですが、さらに、2021 年 4 月にこの Slack 稟議と電子契約システムである クラウドサイン を連携させて、電子契約をもっと便利に使い、生産性の向上を実現しましたのでお話しいたします。 まず、当社の稟議システムは 2020 年 12 月の当社の記事 のおさらいになりますが、稟議の作業が Slack 上で完結する、 ChatOps による稟議ワークフロー となっております。本稿については 2021 年 7 月に執筆しておりますので丁度導入から 1 年程経過し、その間大きなトラブルも無く、今も当社の極めて迅速な意思決定の一助になっています。ChatOps による稟議ワークフローについては、直近、2021 年 6 月に LayerX 社が LayerX ワークフローの新機能として発表 し、サービスとしても提供され、 日経新聞 でも取り上げられていることから、今現在のパラダイムとして、先進的で有効な一手法であったと再認識しております。 今回、新型コロナウイルス感染拡大防止に伴うリモートワークの加速という状況もあり、当社で 2021 年 4 月に電子契約システムとしてクラウドサインを導入しました。電子契約に限らず、契約押印作業は稟議の後続作業に当たるため、ただ導入して使用するのみならず、クラウドサインの API を利用して稟議上にあるデータを電子契約に送信させることでシームレスな連携を実現しています。本稿では当社が行ったシームレスな連携手法について詳細をご説明いたします。 TeamSpirit とクラウドサインの API 連携について 実装概要 弊社の稟議システムである TeamSpirit とクラウドサインとの連携についてお話しします。まず、本稿の開発部分とシステム構成は下記になっております。 処理内容の詳細は後ほど述べますが、概要としては TeamSprit(Apex)からクラウドサインの API をコールし、クラウドサイン上で作成した契約文書へ稟議に記載されている契約書ファイルや先方担当者等の情報を連携する仕組みとなっております。これにより契約担当者はクラウドサインにログイン後、下記の 3 ステップで先方に送信できるようになっています。 記載内容の確認 押印・署名箇所の設定 先方への送信 クラウドサインを使用して契約文書を一から作成する場合のユーザ作業と、当社で採用した API 連携行った場合のユーザ作業を比較したものが下記の表です。作業が半分程度削減されたことが分かります。 作業項番 一から作成する場合 API 連携を利用した当社の場合 1 ログイン ログイン 2 契約文書の作成(件名、契約文書としての宛名設定等) なし 3 契約書ファイルのアップロード なし 4 先方の送信先設定 なし 5 押印欄の設定 押印欄の設定 6 先方への送信 先方への送信 実装 今回の開発で使用した クラウドサイン API は下記の 5 つの API を使用しました (※以降、クラウドサイン API に倣い、変数を表現する場合は {} で括ります)。 API 種類 使用用途 post /token アクセストークンの取得 post /document 契約文書の作成 put /documents/{documentID}/attribute 契約文書の作成で設定できない、細かい項目の設定 post /documents/{documentID}/files ファイルのアップロード post /documents/{documentID}/participants 先方の送信先設定 全体像で記載したクラウドサインの連携部について、上記の API を織り交ぜて詳細化すると下図のようになります。 実装方法としてはクラウドサイン API のリファレンスを参照し、テスト実行時に出力される curl コマンドを参考に同様のレスポンスを得るように Apex で HTTP リクエストを実装しました。アクセストークンの取得を例にとると下記のようになります。 API リファレンスでの curl コマンド例 curl -X 'POST' \ 'https://api.cloudsign.jp/token' \ -H 'accept: application/json' \ -H 'Content-Type: application/x-www-form-urlencoded' \ -d 'client_id=xxxxxxyyyyyyzzzzzz' Apex でのリクエスト実装例 HttpRequest req = new HttpRequest (); req . setMethod ( 'POST' ); req . setEndpoint ( 'https://api.cloudsign.jp/token' ); req . setHeader ( 'accept' , 'application/json' ); req . setHeader ( 'Content-Type' , 'application/x-www-form-urlencoded' ); req . setBody ( 'client_id=' + 'xxxxxxyyyyyyzzzzzz' ); 私自身、Apex もクラウドサイン API もこの案件を担当するまで触ったことがありませんでしたが、リクエストの試行から実装まで 2 週間かからない程度で実装することができました。 ただし、実装や運用にあたっては下記 2 点について注意が必要になります。 Apex からクラウドサインへのファイルのアップロードは単純ではない アクセストークンの有効期限はクラウドサインでコントロールされる 1. Apex からクラウドサインへのファイルのアップロードは単純ではない ファイルのアップロードについては今回使用した API の中で、唯一、テスト実行の curl と Apex のリクエスト実装で差分が生まれます。まず、その差分を確認するために curl コマンド例と Apex のリクエスト実装例で header、body にセットしている値を比較してみます。 API リファレンスでの curl コマンド例 curl -X 'POST' \ 'https://api.cloudsign.jp/documents/{document_id}/files' \ -H 'accept: application/json' \ -H 'Authorization: AAAAAABBBBBBCCCCCC' \ -H 'Content-Type: multipart/form-data' \ -F 'name=テスト' \ -F 'uploadfile=@テスト.pdf;type=application/pdf' Apex でのリクエスト実装例 HttpRequest req = new HttpRequest (); req . setMethod ( 'POST' ); req . setEndpoint ( 'https://api.cloudsign.jp/documents/{document_id}/files' ); req . setHeader ( 'accept' , 'application/json' ); req . setHeader ( 'Authorization' , ‘AAAAAABBBBBBCCCCCC’); req . setHeader ( 'Content-Type' , 'multipart/form-data; boundary={boundary}' ); // ※1 req . setBodyAsBlob ({multipartBody}); // ※2 主な違いは ※1 , ※2 とコメントした部分になります。 Apex では HTTP リクエストの値を手で書いていくことになるので、テスト実行例のように curl がよしなに処理している部分(-F オプションの部分や Apex で記載している boundary)も実装しなければなりません。これが単純に実装できない理由になります。 boundary については multipart/form-data を送信する際に必要な境界でヘッダーでどの文字列が境界であるかを設定します。 curl の-F オプションで定義していた文字列とファイル指定部分は、Apex でファイル(バイナリ)を扱うため、その body に含まれる文字列も含めて Blob 型で扱う必要があります( Content-Transfer-Encoding: base64 に API 提供側が対応している場合は例外になります)。そのため、文字列とバイナリデータを結合し一つの Blob にする方法は下記になります。 「バイナリデータ」、「body の開始からバイナリデータまでの文字列」、「バイナリデータ以降から終端までの文字列」の 3 グループに分ける。 3 グループをそれぞれ Base64 で符号化する。 符号化した「バイナリデータ」と「body の開始からバイナリデータまでの文字列」について、Base64 のデータパディングを示す”=”が含まれないように改行コードで調整する。 「body の開始からバイナリデータまでの文字列」、「バイナリデータ」、「バイナリデータ以降から終端までの文字列」の順で結合する。 結合した Base64 のデータを復号して、一つの Blob とする。 2. アクセストークンの有効期限はクラウドサインでコントロールされる アクセストークンやその有効期限は token API を発行した際のレスポンスとしてクラウドサインから発行されます。 発行されたレスポンス例 { "access_token" : "AAAAAABBBBBBCCCCCC" , "token_type" : “xxxx” , "expires_in" : 3600 } このレスポンスの内、expires_in の値がトークンの有効期限になります。掲題の通り、有効期限の管理はクラウドサイン側で行われ、有効期限内に再度トークンのリクエストを行った場合、経過した時間だけ expires_in の値が小さくなった結果が返ってきて、access_token などは同じ値が取得されます。有効期限内に token API を再度実行した結果が下記になります。 有効期限切れ前に token API を発行した際のレスポンス例 { "access_token" : "AAAAAABBBBBBCCCCCC" , "token_type" : “xxxx” , "expires_in" : 762 } 一方、有効期限後にトークンのリクエストを実行すると、それまでと異なるアクセストークンを取得し、新しい有効期限が設定されます。 有効期限切れ後に token API を発行した際のレスポンス例 { "access_token" : "XXXXXXYYYYYYZZZZZZ" , "token_type" : "xxxx" , "expires_in" : 3600 } そのため、API 連携が一度動いた後、有効期限ぎりぎりでもう一度 API 連携が動いてしまった場合、タイミングが悪いと契約文書の作成から最終処理である先方の送信先設定までのプロセス内のどこかから、トークンの有効期限切れが発生する可能性が想定されます。実際に期限切れが発生した場合、発生時以降に発行したその回の API 連携処理が失敗します。 トークンの有効期限切れが発生した際、API リファレンスより HTTP ステータスコードが 401 かつエラー内容が”unauthorized”で応答されることから、当社ではこのエラーを受けた場合にトークンを再取得して処理をリトライするように実装しました。 押印文書作成を例にとると下記のような実装イメージになります。 //クラウドサイン上に押印文書を作成し、作成した文書 ID を取得する public String getDocumentId ( String authToken, String title, String message){ ・・・中略・・・ HTTPResponse res = http . send (req); if ( res . getStatusCode () == 200 ){ ・・・正常に終了した際の処理・・・ } //タイミングが悪く token がタイムアウトした場合、トークンを取得し直して、リトライする else if ( res . getStatusCode () == 401 ){ //レスポンスの内容を確認するため、エラーレスポンスの中身を取得する Map < String , Object > responseBody = new Map < String , Object >(); responseBody = ( Map <String, Object>) JSON . deserializeUntyped ( res . getBody ()); String errorVal = (String) responseBody . get ( 'error' ); //リファレンス上、アクセストークンが無効(有効期限切れ)の場合、'unauthorized’となる if ( errorVal . equals ( 'unauthorized' )){ //クラウドサインのアクセストークンの再取得 authToken = getAuthToken (); //単純再帰で再実行する。 documentId = getDocumentId (authToken, title, message); } ・・・中略・・・ } ・・・以下省略・・・ } 実装を終えて 上記を実装した結果、稟議と入力内容が同じ、または、稟議から生成できる内容は全てシステム連携で自動生成するため、押印担当は稟議とクラウドサインの画面を並べて転記するような煩雑な作業を必要としない環境になりました。また、契約書の製本、郵送等の紙媒体であるが故の事務の削減ができるようになる等の、電子契約を導入することのそもそものメリットも併せて享受しています。 当社では 2021 年 4 月後半からクラウドサインを導入しましたが、2021 年 6 月時点ではすでに 月間で締結した契約書の「3 割以上」が電子契約を活用しており 、押印担当の展望として今後も利用を拡大していく予定です。 コーポレートエンジニア募集中 メドレーのコーポレート部門では、本稿のように、SaaS の導入ひとつとっても検討を尽くし、既存のシステムと有機的に結合させることで「徹底的に合理性を追求した組織基盤や、仕掛けづくり」を行っています。 面白そう！興味がある！と感じた方は、ぜひ当社採用ページからご応募お願いします！ 最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに はじめまして、コーポレートエンジニアの山下です。 2020 年に Slack を活用した ChatOps 稟議ワークフローを内製で開発したのですが、さらに、2021 年 4 月にこの Slack 稟議と電子契約システムである クラウドサイン を連携させて、電子契約をもっと便利に使い、生産性の向上を実現しましたのでお話しいたします。 まず、当社の稟議システムは 2020 年 12 月の当社の記事 のおさらいになりますが、稟議の作業が Slack 上で完結する、 ChatOps による稟議ワークフロー となっております。本稿については 2021 年 7 月に執筆しておりますので丁度導入から 1 年程経過し、その間大きなトラブルも無く、今も当社の極めて迅速な意思決定の一助になっています。ChatOps による稟議ワークフローについては、直近、2021 年 6 月に LayerX 社が LayerX ワークフローの新機能として発表 し、サービスとしても提供され、 日経新聞 でも取り上げられていることから、今現在のパラダイムとして、先進的で有効な一手法であったと再認識しております。 今回、新型コロナウイルス感染拡大防止に伴うリモートワークの加速という状況もあり、当社で 2021 年 4 月に電子契約システムとしてクラウドサインを導入しました。電子契約に限らず、契約押印作業は稟議の後続作業に当たるため、ただ導入して使用するのみならず、クラウドサインの API を利用して稟議上にあるデータを電子契約に送信させることでシームレスな連携を実現しています。本稿では当社が行ったシームレスな連携手法について詳細をご説明いたします。 TeamSpirit とクラウドサインの API 連携について 実装概要 弊社の稟議システムである TeamSpirit とクラウドサインとの連携についてお話しします。まず、本稿の開発部分とシステム構成は下記になっております。 処理内容の詳細は後ほど述べますが、概要としては TeamSprit(Apex)からクラウドサインの API をコールし、クラウドサイン上で作成した契約文書へ稟議に記載されている契約書ファイルや先方担当者等の情報を連携する仕組みとなっております。これにより契約担当者はクラウドサインにログイン後、下記の 3 ステップで先方に送信できるようになっています。 記載内容の確認 押印・署名箇所の設定 先方への送信 クラウドサインを使用して契約文書を一から作成する場合のユーザ作業と、当社で採用した API 連携行った場合のユーザ作業を比較したものが下記の表です。作業が半分程度削減されたことが分かります。 作業項番 一から作成する場合 API 連携を利用した当社の場合 1 ログイン ログイン 2 契約文書の作成(件名、契約文書としての宛名設定等) なし 3 契約書ファイルのアップロード なし 4 先方の送信先設定 なし 5 押印欄の設定 押印欄の設定 6 先方への送信 先方への送信 実装 今回の開発で使用した クラウドサイン API は下記の 5 つの API を使用しました (※以降、クラウドサイン API に倣い、変数を表現する場合は {} で括ります)。 API 種類 使用用途 post /token アクセストークンの取得 post /document 契約文書の作成 put /documents/{documentID}/attribute 契約文書の作成で設定できない、細かい項目の設定 post /documents/{documentID}/files ファイルのアップロード post /documents/{documentID}/participants 先方の送信先設定 全体像で記載したクラウドサインの連携部について、上記の API を織り交ぜて詳細化すると下図のようになります。 実装方法としてはクラウドサイン API のリファレンスを参照し、テスト実行時に出力される curl コマンドを参考に同様のレスポンスを得るように Apex で HTTP リクエストを実装しました。アクセストークンの取得を例にとると下記のようになります。 API リファレンスでの curl コマンド例 curl -X 'POST' \ 'https://api.cloudsign.jp/token' \ -H 'accept: application/json' \ -H 'Content-Type: application/x-www-form-urlencoded' \ -d 'client_id=xxxxxxyyyyyyzzzzzz' Apex でのリクエスト実装例 HttpRequest req = new HttpRequest (); req . setMethod ( 'POST' ); req . setEndpoint ( 'https://api.cloudsign.jp/token' ); req . setHeader ( 'accept' , 'application/json' ); req . setHeader ( 'Content-Type' , 'application/x-www-form-urlencoded' ); req . setBody ( 'client_id=' + 'xxxxxxyyyyyyzzzzzz' ); 私自身、Apex もクラウドサイン API もこの案件を担当するまで触ったことがありませんでしたが、リクエストの試行から実装まで 2 週間かからない程度で実装することができました。 ただし、実装や運用にあたっては下記 2 点について注意が必要になります。 Apex からクラウドサインへのファイルのアップロードは単純ではない アクセストークンの有効期限はクラウドサインでコントロールされる 1. Apex からクラウドサインへのファイルのアップロードは単純ではない ファイルのアップロードについては今回使用した API の中で、唯一、テスト実行の curl と Apex のリクエスト実装で差分が生まれます。まず、その差分を確認するために curl コマンド例と Apex のリクエスト実装例で header、body にセットしている値を比較してみます。 API リファレンスでの curl コマンド例 curl -X 'POST' \ 'https://api.cloudsign.jp/documents/{document_id}/files' \ -H 'accept: application/json' \ -H 'Authorization: AAAAAABBBBBBCCCCCC' \ -H 'Content-Type: multipart/form-data' \ -F 'name=テスト' \ -F 'uploadfile=@テスト.pdf;type=application/pdf' Apex でのリクエスト実装例 HttpRequest req = new HttpRequest (); req . setMethod ( 'POST' ); req . setEndpoint ( 'https://api.cloudsign.jp/documents/{document_id}/files' ); req . setHeader ( 'accept' , 'application/json' ); req . setHeader ( 'Authorization' , ‘AAAAAABBBBBBCCCCCC’); req . setHeader ( 'Content-Type' , 'multipart/form-data; boundary={boundary}' ); // ※1 req . setBodyAsBlob ({multipartBody}); // ※2 主な違いは ※1 , ※2 とコメントした部分になります。 Apex では HTTP リクエストの値を手で書いていくことになるので、テスト実行例のように curl がよしなに処理している部分(-F オプションの部分や Apex で記載している boundary)も実装しなければなりません。これが単純に実装できない理由になります。 boundary については multipart/form-data を送信する際に必要な境界でヘッダーでどの文字列が境界であるかを設定します。 curl の-F オプションで定義していた文字列とファイル指定部分は、Apex でファイル(バイナリ)を扱うため、その body に含まれる文字列も含めて Blob 型で扱う必要があります( Content-Transfer-Encoding: base64 に API 提供側が対応している場合は例外になります)。そのため、文字列とバイナリデータを結合し一つの Blob にする方法は下記になります。 「バイナリデータ」、「body の開始からバイナリデータまでの文字列」、「バイナリデータ以降から終端までの文字列」の 3 グループに分ける。 3 グループをそれぞれ Base64 で符号化する。 符号化した「バイナリデータ」と「body の開始からバイナリデータまでの文字列」について、Base64 のデータパディングを示す”=”が含まれないように改行コードで調整する。 「body の開始からバイナリデータまでの文字列」、「バイナリデータ」、「バイナリデータ以降から終端までの文字列」の順で結合する。 結合した Base64 のデータを復号して、一つの Blob とする。 2. アクセストークンの有効期限はクラウドサインでコントロールされる アクセストークンやその有効期限は token API を発行した際のレスポンスとしてクラウドサインから発行されます。 発行されたレスポンス例 { "access_token" : "AAAAAABBBBBBCCCCCC" , "token_type" : “xxxx” , "expires_in" : 3600 } このレスポンスの内、expires_in の値がトークンの有効期限になります。掲題の通り、有効期限の管理はクラウドサイン側で行われ、有効期限内に再度トークンのリクエストを行った場合、経過した時間だけ expires_in の値が小さくなった結果が返ってきて、access_token などは同じ値が取得されます。有効期限内に token API を再度実行した結果が下記になります。 有効期限切れ前に token API を発行した際のレスポンス例 { "access_token" : "AAAAAABBBBBBCCCCCC" , "token_type" : “xxxx” , "expires_in" : 762 } 一方、有効期限後にトークンのリクエストを実行すると、それまでと異なるアクセストークンを取得し、新しい有効期限が設定されます。 有効期限切れ後に token API を発行した際のレスポンス例 { "access_token" : "XXXXXXYYYYYYZZZZZZ" , "token_type" : "xxxx" , "expires_in" : 3600 } そのため、API 連携が一度動いた後、有効期限ぎりぎりでもう一度 API 連携が動いてしまった場合、タイミングが悪いと契約文書の作成から最終処理である先方の送信先設定までのプロセス内のどこかから、トークンの有効期限切れが発生する可能性が想定されます。実際に期限切れが発生した場合、発生時以降に発行したその回の API 連携処理が失敗します。 トークンの有効期限切れが発生した際、API リファレンスより HTTP ステータスコードが 401 かつエラー内容が”unauthorized”で応答されることから、当社ではこのエラーを受けた場合にトークンを再取得して処理をリトライするように実装しました。 押印文書作成を例にとると下記のような実装イメージになります。 //クラウドサイン上に押印文書を作成し、作成した文書 ID を取得する public String getDocumentId ( String authToken, String title, String message){ ・・・中略・・・ HTTPResponse res = http . send (req); if ( res . getStatusCode () == 200 ){ ・・・正常に終了した際の処理・・・ } //タイミングが悪く token がタイムアウトした場合、トークンを取得し直して、リトライする else if ( res . getStatusCode () == 401 ){ //レスポンスの内容を確認するため、エラーレスポンスの中身を取得する Map < String , Object > responseBody = new Map < String , Object >(); responseBody = ( Map <String, Object>) JSON . deserializeUntyped ( res . getBody ()); String errorVal = (String) responseBody . get ( 'error' ); //リファレンス上、アクセストークンが無効(有効期限切れ)の場合、'unauthorized’となる if ( errorVal . equals ( 'unauthorized' )){ //クラウドサインのアクセストークンの再取得 authToken = getAuthToken (); //単純再帰で再実行する。 documentId = getDocumentId (authToken, title, message); } ・・・中略・・・ } ・・・以下省略・・・ } 実装を終えて 上記を実装した結果、稟議と入力内容が同じ、または、稟議から生成できる内容は全てシステム連携で自動生成するため、押印担当は稟議とクラウドサインの画面を並べて転記するような煩雑な作業を必要としない環境になりました。また、契約書の製本、郵送等の紙媒体であるが故の事務の削減ができるようになる等の、電子契約を導入することのそもそものメリットも併せて享受しています。 当社では 2021 年 4 月後半からクラウドサインを導入しましたが、2021 年 6 月時点ではすでに 月間で締結した契約書の「3 割以上」が電子契約を活用しており 、押印担当の展望として今後も利用を拡大していく予定です。 コーポレートエンジニア募集中 メドレーのコーポレート部門では、本稿のように、SaaS の導入ひとつとっても検討を尽くし、既存のシステムと有機的に結合させることで「徹底的に合理性を追求した組織基盤や、仕掛けづくり」を行っています。 面白そう！興味がある！と感じた方は、ぜひ当社採用ページからご応募お願いします！ 最後までお読みいただきありがとうございました。 https://www.medley.jp/jobs/

はじめに はじめまして、コーポレートエンジニアの山下です。 2020 年に Slack を活用した ChatOps 稟議ワークフローを内製で開発したのですが、さらに、2021 年 4 月にこの Slack 稟議と電子契約システムである クラウドサイン を連携させて、電子契約をもっと便利に使い、生産性の向上を実現しましたのでお話しいたします。 まず、当社の稟議システムは 2020 年 12 月の当社の記事 のおさらいになりますが、稟議の作業が Slack 上で完結する、 ChatOps による稟議ワークフロー となっております。本稿については 2021 年 7 月に執筆しておりますので丁度導入から 1 年程経過し、その間大きなトラブルも無く、今も当社の極めて迅速な意思決定の一助になっています。ChatOps による稟議ワークフローについては、直近、2021 年 6 月に LayerX 社が LayerX ワークフローの新機能として発表 し、サービスとしても提供され、 日経新聞 でも取り上げられていることから、今現在のパラダイムとして、先進的で有効な一手法であったと再認識しております。 今回、新型コロナウイルス感染拡大防止に伴うリモートワークの加速という状況もあり、当社で 2021 年 4 月に電子契約システムとしてクラウドサインを導入しました。電子契約に限らず、契約押印作業は稟議の後続作業に当たるため、ただ導入して使用するのみならず、クラウドサインの API を利用して稟議上にあるデータを電子契約に送信させることでシームレスな連携を実現しています。本稿では当社が行ったシームレスな連携手法について詳細をご説明いたします。 TeamSpirit とクラウドサインの API 連携について 実装概要 弊社の稟議システムである TeamSpirit とクラウドサインとの連携についてお話しします。まず、本稿の開発部分とシステム構成は下記になっております。 処理内容の詳細は後ほど述べますが、概要としては TeamSprit(Apex)からクラウドサインの API をコールし、クラウドサイン上で作成した契約文書へ稟議に記載されている契約書ファイルや先方担当者等の情報を連携する仕組みとなっております。これにより契約担当者はクラウドサインにログイン後、下記の 3 ステップで先方に送信できるようになっています。 記載内容の確認 押印・署名箇所の設定 先方への送信 クラウドサインを使用して契約文書を一から作成する場合のユーザ作業と、当社で採用した API 連携行った場合のユーザ作業を比較したものが下記の表です。作業が半分程度削減されたことが分かります。 作業項番 一から作成する場合 API 連携を利用した当社の場合 1 ログイン ログイン 2 契約文書の作成(件名、契約文書としての宛名設定等) なし 3 契約書ファイルのアップロード なし 4 先方の送信先設定 なし 5 押印欄の設定 押印欄の設定 6 先方への送信 先方への送信 実装 今回の開発で使用した クラウドサイン API は下記の 5 つの API を使用しました (※以降、クラウドサイン API に倣い、変数を表現する場合は {} で括ります)。 API 種類 使用用途 post /token アクセストークンの取得 post /document 契約文書の作成 put /documents/{documentID}/attribute 契約文書の作成で設定できない、細かい項目の設定 post /documents/{documentID}/files ファイルのアップロード post /documents/{documentID}/participants 先方の送信先設定 全体像で記載したクラウドサインの連携部について、上記の API を織り交ぜて詳細化すると下図のようになります。 実装方法としてはクラウドサイン API のリファレンスを参照し、テスト実行時に出力される curl コマンドを参考に同様のレスポンスを得るように Apex で HTTP リクエストを実装しました。アクセストークンの取得を例にとると下記のようになります。 API リファレンスでの curl コマンド例 curl -X 'POST' \ 'https://api.cloudsign.jp/token' \ -H 'accept: application/json' \ -H 'Content-Type: application/x-www-form-urlencoded' \ -d 'client_id=xxxxxxyyyyyyzzzzzz' Apex でのリクエスト実装例 HttpRequest req = new HttpRequest (); req . setMethod ( 'POST' ); req . setEndpoint ( 'https://api.cloudsign.jp/token' ); req . setHeader ( 'accept' , 'application/json' ); req . setHeader ( 'Content-Type' , 'application/x-www-form-urlencoded' ); req . setBody ( 'client_id=' + 'xxxxxxyyyyyyzzzzzz' ); 私自身、Apex もクラウドサイン API もこの案件を担当するまで触ったことがありませんでしたが、リクエストの試行から実装まで 2 週間かからない程度で実装することができました。 ただし、実装や運用にあたっては下記 2 点について注意が必要になります。 Apex からクラウドサインへのファイルのアップロードは単純ではない アクセストークンの有効期限はクラウドサインでコントロールされる 1. Apex からクラウドサインへのファイルのアップロードは単純ではない ファイルのアップロードについては今回使用した API の中で、唯一、テスト実行の curl と Apex のリクエスト実装で差分が生まれます。まず、その差分を確認するために curl コマンド例と Apex のリクエスト実装例で header、body にセットしている値を比較してみます。 API リファレンスでの curl コマンド例 curl -X 'POST' \ 'https://api.cloudsign.jp/documents/{document_id}/files' \ -H 'accept: application/json' \ -H 'Authorization: AAAAAABBBBBBCCCCCC' \ -H 'Content-Type: multipart/form-data' \ -F 'name=テスト' \ -F 'uploadfile=@テスト.pdf;type=application/pdf' Apex でのリクエスト実装例 HttpRequest req = new HttpRequest (); req . setMethod ( 'POST' ); req . setEndpoint ( 'https://api.cloudsign.jp/documents/{document_id}/files' ); req . setHeader ( 'accept' , 'application/json' ); req . setHeader ( 'Authorization' , ‘AAAAAABBBBBBCCCCCC’); req . setHeader ( 'Content-Type' , 'multipart/form-data; boundary={boundary}' ); // ※1 req . setBodyAsBlob ({multipartBody}); // ※2 主な違いは ※1 , ※2 とコメントした部分になります。 Apex では HTTP リクエストの値を手で書いていくことになるので、テスト実行例のように curl がよしなに処理している部分(-F オプションの部分や Apex で記載している boundary)も実装しなければなりません。これが単純に実装できない理由になります。 boundary については multipart/form-data を送信する際に必要な境界でヘッダーでどの文字列が境界であるかを設定します。 curl の-F オプションで定義していた文字列とファイル指定部分は、Apex でファイル(バイナリ)を扱うため、その body に含まれる文字列も含めて Blob 型で扱う必要があります( Content-Transfer-Encoding: base64 に API 提供側が対応している場合は例外になります)。そのため、文字列とバイナリデータを結合し一つの Blob にする方法は下記になります。 「バイナリデータ」、「body の開始からバイナリデータまでの文字列」、「バイナリデータ以降から終端までの文字列」の 3 グループに分ける。 3 グループをそれぞれ Base64 で符号化する。 符号化した「バイナリデータ」と「body の開始からバイナリデータまでの文字列」について、Base64 のデータパディングを示す”=”が含まれないように改行コードで調整する。 「body の開始からバイナリデータまでの文字列」、「バイナリデータ」、「バイナリデータ以降から終端までの文字列」の順で結合する。 結合した Base64 のデータを復号して、一つの Blob とする。 2. アクセストークンの有効期限はクラウドサインでコントロールされる アクセストークンやその有効期限は token API を発行した際のレスポンスとしてクラウドサインから発行されます。 発行されたレスポンス例 { "access_token" : "AAAAAABBBBBBCCCCCC" , "token_type" : “xxxx” , "expires_in" : 3600 } このレスポンスの内、expires_in の値がトークンの有効期限になります。掲題の通り、有効期限の管理はクラウドサイン側で行われ、有効期限内に再度トークンのリクエストを行った場合、経過した時間だけ expires_in の値が小さくなった結果が返ってきて、access_token などは同じ値が取得されます。有効期限内に token API を再度実行した結果が下記になります。 有効期限切れ前に token API を発行した際のレスポンス例 { "access_token" : "AAAAAABBBBBBCCCCCC" , "token_type" : “xxxx” , "expires_in" : 762 } 一方、有効期限後にトークンのリクエストを実行すると、それまでと異なるアクセストークンを取得し、新しい有効期限が設定されます。 有効期限切れ後に token API を発行した際のレスポンス例 { "access_token" : "XXXXXXYYYYYYZZZZZZ" , "token_type" : "xxxx" , "expires_in" : 3600 } そのため、API 連携が一度動いた後、有効期限ぎりぎりでもう一度 API 連携が動いてしまった場合、タイミングが悪いと契約文書の作成から最終処理である先方の送信先設定までのプロセス内のどこかから、トークンの有効期限切れが発生する可能性が想定されます。実際に期限切れが発生した場合、発生時以降に発行したその回の API 連携処理が失敗します。 トークンの有効期限切れが発生した際、API リファレンスより HTTP ステータスコードが 401 かつエラー内容が”unauthorized”で応答されることから、当社ではこのエラーを受けた場合にトークンを再取得して処理をリトライするように実装しました。 押印文書作成を例にとると下記のような実装イメージになります。 //クラウドサイン上に押印文書を作成し、作成した文書 ID を取得する public String getDocumentId ( String authToken, String title, String message){ ・・・中略・・・ HTTPResponse res = http . send (req); if ( res . getStatusCode () == 200 ){ ・・・正常に終了した際の処理・・・ } //タイミングが悪く token がタイムアウトした場合、トークンを取得し直して、リトライする else if ( res . getStatusCode () == 401 ){ //レスポンスの内容を確認するため、エラーレスポンスの中身を取得する Map < String , Object > responseBody = new Map < String , Object >(); responseBody = ( Map <String, Object>) JSON . deserializeUntyped ( res . getBody ()); String errorVal = (String) responseBody . get ( 'error' ); //リファレンス上、アクセストークンが無効(有効期限切れ)の場合、'unauthorized’となる if ( errorVal . equals ( 'unauthorized' )){ //クラウドサインのアクセストークンの再取得 authToken = getAuthToken (); //単純再帰で再実行する。 documentId = getDocumentId (authToken, title, message); } ・・・中略・・・ } ・・・以下省略・・・ } 実装を終えて 上記を実装した結果、稟議と入力内容が同じ、または、稟議から生成できる内容は全てシステム連携で自動生成するため、押印担当は稟議とクラウドサインの画面を並べて転記するような煩雑な作業を必要としない環境になりました。また、契約書の製本、郵送等の紙媒体であるが故の事務の削減ができるようになる等の、電子契約を導入することのそもそものメリットも併せて享受しています。 当社では 2021 年 4 月後半からクラウドサインを導入しましたが、2021 年 6 月時点ではすでに 月間で締結した契約書の「3 割以上」が電子契約を活用しており 、押印担当の展望として今後も利用を拡大していく予定です。 コーポレートエンジニア募集中 メドレーのコーポレート部門では、本稿のように、SaaS の導入ひとつとっても検討を尽くし、既存のシステムと有機的に結合させることで「徹底的に合理性を追求した組織基盤や、仕掛けづくり」を行っています。 面白そう！興味がある！と感じた方は、ぜひ当社採用ページからご応募お願いします！ 最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

「2020 年 9 月に調剤薬局向けのプロダクトをリリースする」 この プレスリリース が発表されたのは、COVID-19 の感染拡大に端を発する緊急事態宣言が発令されていた 2020 年 4 月半ば。その 1 ヶ月後、私はリモートワーク下でのオンライン MTG になじめない状態のまま、調剤薬局向けプロダクトのブランディングについて役員陣や主要プロジェクトメンバーにプレゼンを行っていた。 今回は当時のプレゼン資料をたどりながら Pharms のブランド設計について説明していこうと思う。 医薬分業のルーツとは デザイナーとして前田がメドレーに入社してから、オンライン診療や電子カルテなど、主に医療機関向けのプロダクトデザインを担当していたものの、調剤薬局のプロダクトデザインは未知の領域。ブランディングを検討する上で、薬の処方を行う医師と調剤を実施する薬剤師が分担して行う医薬分業のルーツついて調べることからはじめた。 医薬分業は、毒殺を恐れたフリードリヒ 2 世が主治医の処方した薬を、毒が盛られてないか他者にチェックさせたのが始まりとされている。 （参考： 公益社団法人 日本薬剤師会 HP ｜医薬分業とは ） 医療プラットフォームの未来を見据えたブランド定義 次に、調剤に関する法制度や競合などの外部要因、メドレーとしてのブランド力や開発力などの内部要因について簡易な SWOT 分析を行い、調剤薬局のプロジェクトの妥当性を検証。メドレーが取り組む医療プラットフォーム事業(※)に、あらたに調剤薬局プロジェクトが加わることによる他のプロダクトとのバランスも考慮しながらブランドネーミング検討を行っていった。 ※) 医療プラットフォーム事業では、患者と医療領域の業務システムを SaaS プロダクトでつなぎ、患者と医療機関双方にとって、テクノロジーの恩恵を受けることのできるプラットフォームづくりを行っている。主要サービスはクラウド診療支援システム「CLINICS」やオンライン診療・服薬指導アプリ「CLINICS」。 メドレーのこれまでの歴史を振り返ると、プロダクト内容を明確かつ端的に表したネーミングが多く、メドレーらしさ = 「中央突破なネーミング」ということを定義し、ネーミングを検討していった。 最終的に調剤薬局を表す「Pharmacies（ファーマシーズ）」と「Pharms（ファームス）」の 2 案に絞込み、それぞれのメリット・デメリットを整理していった。 当時、社内では調剤薬局システム = Pharmacies と呼ばれており、その中央突破なネーミングが最有力候補であった。一方で、ブランドで体現すべきアイデンティティの欠如や、呼びづらさなどが課題として散見された。さらには医療プラットフォーム全体を見据えたブランド構築という観点から考慮すると、バランス面での課題が浮き彫りになり、それら課題をクリアにして誕生したのが Pharms（ファームス）である。 ヴィジュアル・アイデンティティの設計 ブランド名が固まれば、あとはヴィジュアル・アイデンティティを突き詰めていくのみ。視認性や可読性を考慮したフォントフェイスの検証や調剤薬局と想起させるブランドカラーの選定、またシンボルの設計などに取り掛かっていく。 ブランドカラーの選定においては、なんとなく「緑」というイメージがチーム内でもあったが、より精緻化するため、薬の起源や調剤薬局本来の役割を踏まえ詳細に落とし込んでいった。 ロゴにシンボルを含めるか、含めないかも検討のひとつであったが、医療プラットフォーム事業にある CLINICS のロゴがシンボルマーク付きであるため、医療プラットフォームに関連するプロダクト = シンボルを定義するというルールを策定しシンボルも設計。シンボルは薬の構造式に利用される「ハニカム構造」をモチーフとし、ブランドカラーと合わせて詳細に作り込んでいった。 また、Pharms の製品紹介用ランディングページやプロダクトデザインのモックアップを作成し、ロゴとのバランスなども考慮しながら調整を行っていった。 最終的に、患者・調剤薬局・医療機関の 3 者のつながりを三角形で表現しつつ、中心を先述した「ハニカム構造」をモチーフとした形状と、Pharms の頭文字「P」をカプセルと錠剤で表現して、調剤薬局システムとしてシンボルマークに命を吹き込んだ。 まとめ このような過程を経て、Pharms のブランドが完成したのだが、これらは調剤薬局システムの開発としては氷山の一角でしかない。本丸はプロダクトデザイン。一般的にはロゴとプロダクトデザインは別プロジェクトで進行したり、担当するデザイナーが別だったりすることも多いのではないだろうか。 Pharms はブランド設計、プロダクトデザイン、マーケティング資材といったデザイン領域をすべて私が担当していくことになるのだが、それ故に事業全体を俯瞰し理解しながらデザインや UI デザインに魂を込めて携わることができた。デザイナーキャリアとしてもここまで幅広く携われたことは非常に貴重な経験を得ることができたと自負している。 続いてプロダクトデザイン開発の秘話について語りたいところだが、現在 Pharms 以外の医療プラットフォーム事業に関連する新たなプロダクト開発に注力しているため、その話はまたの機会に。 医療プラットフォーム事業に関連するプロダクトをこれからも創出し成長させていく面白い時期にあり、現在デザイナーを積極採用中です。カジュアルに話を聞きたい、医療領域のデザインに興味があるといったデザイナーの方は、ぜひ こちら までご連絡いただけると幸いです。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

「2020 年 9 月に調剤薬局向けのプロダクトをリリースする」 この プレスリリース が発表されたのは、COVID-19 の感染拡大に端を発する緊急事態宣言が発令されていた 2020 年 4 月半ば。その 1 ヶ月後、私はリモートワーク下でのオンライン MTG になじめない状態のまま、調剤薬局向けプロダクトのブランディングについて役員陣や主要プロジェクトメンバーにプレゼンを行っていた。 今回は当時のプレゼン資料をたどりながら Pharms のブランド設計について説明していこうと思う。 医薬分業のルーツとは デザイナーとして前田がメドレーに入社してから、オンライン診療や電子カルテなど、主に医療機関向けのプロダクトデザインを担当していたものの、調剤薬局のプロダクトデザインは未知の領域。ブランディングを検討する上で、薬の処方を行う医師と調剤を実施する薬剤師が分担して行う医薬分業のルーツついて調べることからはじめた。 医薬分業は、毒殺を恐れたフリードリヒ 2 世が主治医の処方した薬を、毒が盛られてないか他者にチェックさせたのが始まりとされている。 （参考： 公益社団法人 日本薬剤師会 HP ｜医薬分業とは ） 医療プラットフォームの未来を見据えたブランド定義 次に、調剤に関する法制度や競合などの外部要因、メドレーとしてのブランド力や開発力などの内部要因について簡易な SWOT 分析を行い、調剤薬局のプロジェクトの妥当性を検証。メドレーが取り組む医療プラットフォーム事業(※)に、あらたに調剤薬局プロジェクトが加わることによる他のプロダクトとのバランスも考慮しながらブランドネーミング検討を行っていった。 ※) 医療プラットフォーム事業では、患者と医療領域の業務システムを SaaS プロダクトでつなぎ、患者と医療機関双方にとって、テクノロジーの恩恵を受けることのできるプラットフォームづくりを行っている。主要サービスはクラウド診療支援システム「CLINICS」やオンライン診療・服薬指導アプリ「CLINICS」。 メドレーのこれまでの歴史を振り返ると、プロダクト内容を明確かつ端的に表したネーミングが多く、メドレーらしさ = 「中央突破なネーミング」ということを定義し、ネーミングを検討していった。 最終的に調剤薬局を表す「Pharmacies（ファーマシーズ）」と「Pharms（ファームス）」の 2 案に絞込み、それぞれのメリット・デメリットを整理していった。 当時、社内では調剤薬局システム = Pharmacies と呼ばれており、その中央突破なネーミングが最有力候補であった。一方で、ブランドで体現すべきアイデンティティの欠如や、呼びづらさなどが課題として散見された。さらには医療プラットフォーム全体を見据えたブランド構築という観点から考慮すると、バランス面での課題が浮き彫りになり、それら課題をクリアにして誕生したのが Pharms（ファームス）である。 ヴィジュアル・アイデンティティの設計 ブランド名が固まれば、あとはヴィジュアル・アイデンティティを突き詰めていくのみ。視認性や可読性を考慮したフォントフェイスの検証や調剤薬局と想起させるブランドカラーの選定、またシンボルの設計などに取り掛かっていく。 ブランドカラーの選定においては、なんとなく「緑」というイメージがチーム内でもあったが、より精緻化するため、薬の起源や調剤薬局本来の役割を踏まえ詳細に落とし込んでいった。 ロゴにシンボルを含めるか、含めないかも検討のひとつであったが、医療プラットフォーム事業にある CLINICS のロゴがシンボルマーク付きであるため、医療プラットフォームに関連するプロダクト = シンボルを定義するというルールを策定しシンボルも設計。シンボルは薬の構造式に利用される「ハニカム構造」をモチーフとし、ブランドカラーと合わせて詳細に作り込んでいった。 また、Pharms の製品紹介用ランディングページやプロダクトデザインのモックアップを作成し、ロゴとのバランスなども考慮しながら調整を行っていった。 最終的に、患者・調剤薬局・医療機関の 3 者のつながりを三角形で表現しつつ、中心を先述した「ハニカム構造」をモチーフとした形状と、Pharms の頭文字「P」をカプセルと錠剤で表現して、調剤薬局システムとしてシンボルマークに命を吹き込んだ。 まとめ このような過程を経て、Pharms のブランドが完成したのだが、これらは調剤薬局システムの開発としては氷山の一角でしかない。本丸はプロダクトデザイン。一般的にはロゴとプロダクトデザインは別プロジェクトで進行したり、担当するデザイナーが別だったりすることも多いのではないだろうか。 Pharms はブランド設計、プロダクトデザイン、マーケティング資材といったデザイン領域をすべて私が担当していくことになるのだが、それ故に事業全体を俯瞰し理解しながらデザインや UI デザインに魂を込めて携わることができた。デザイナーキャリアとしてもここまで幅広く携われたことは非常に貴重な経験を得ることができたと自負している。 続いてプロダクトデザイン開発の秘話について語りたいところだが、現在 Pharms 以外の医療プラットフォーム事業に関連する新たなプロダクト開発に注力しているため、その話はまたの機会に。 医療プラットフォーム事業に関連するプロダクトをこれからも創出し成長させていく面白い時期にあり、現在デザイナーを積極採用中です。カジュアルに話を聞きたい、医療領域のデザインに興味があるといったデザイナーの方は、ぜひ こちら までご連絡いただけると幸いです。 https://www.medley.jp/jobs/designer-new.html

「2020 年 9 月に調剤薬局向けのプロダクトをリリースする」 この プレスリリース が発表されたのは、COVID-19 の感染拡大に端を発する緊急事態宣言が発令されていた 2020 年 4 月半ば。その 1 ヶ月後、私はリモートワーク下でのオンライン MTG になじめない状態のまま、調剤薬局向けプロダクトのブランディングについて役員陣や主要プロジェクトメンバーにプレゼンを行っていた。 今回は当時のプレゼン資料をたどりながら Pharms のブランド設計について説明していこうと思う。 医薬分業のルーツとは デザイナーとして前田がメドレーに入社してから、オンライン診療や電子カルテなど、主に医療機関向けのプロダクトデザインを担当していたものの、調剤薬局のプロダクトデザインは未知の領域。ブランディングを検討する上で、薬の処方を行う医師と調剤を実施する薬剤師が分担して行う医薬分業のルーツついて調べることからはじめた。 医薬分業は、毒殺を恐れたフリードリヒ 2 世が主治医の処方した薬を、毒が盛られてないか他者にチェックさせたのが始まりとされている。 （参考： 公益社団法人 日本薬剤師会 HP ｜医薬分業とは ） 医療プラットフォームの未来を見据えたブランド定義 次に、調剤に関する法制度や競合などの外部要因、メドレーとしてのブランド力や開発力などの内部要因について簡易な SWOT 分析を行い、調剤薬局のプロジェクトの妥当性を検証。メドレーが取り組む医療プラットフォーム事業(※)に、あらたに調剤薬局プロジェクトが加わることによる他のプロダクトとのバランスも考慮しながらブランドネーミング検討を行っていった。 ※) 医療プラットフォーム事業では、患者と医療領域の業務システムを SaaS プロダクトでつなぎ、患者と医療機関双方にとって、テクノロジーの恩恵を受けることのできるプラットフォームづくりを行っている。主要サービスはクラウド診療支援システム「CLINICS」やオンライン診療・服薬指導アプリ「CLINICS」。 メドレーのこれまでの歴史を振り返ると、プロダクト内容を明確かつ端的に表したネーミングが多く、メドレーらしさ = 「中央突破なネーミング」ということを定義し、ネーミングを検討していった。 最終的に調剤薬局を表す「Pharmacies（ファーマシーズ）」と「Pharms（ファームス）」の 2 案に絞込み、それぞれのメリット・デメリットを整理していった。 当時、社内では調剤薬局システム = Pharmacies と呼ばれており、その中央突破なネーミングが最有力候補であった。一方で、ブランドで体現すべきアイデンティティの欠如や、呼びづらさなどが課題として散見された。さらには医療プラットフォーム全体を見据えたブランド構築という観点から考慮すると、バランス面での課題が浮き彫りになり、それら課題をクリアにして誕生したのが Pharms（ファームス）である。 ヴィジュアル・アイデンティティの設計 ブランド名が固まれば、あとはヴィジュアル・アイデンティティを突き詰めていくのみ。視認性や可読性を考慮したフォントフェイスの検証や調剤薬局と想起させるブランドカラーの選定、またシンボルの設計などに取り掛かっていく。 ブランドカラーの選定においては、なんとなく「緑」というイメージがチーム内でもあったが、より精緻化するため、薬の起源や調剤薬局本来の役割を踏まえ詳細に落とし込んでいった。 ロゴにシンボルを含めるか、含めないかも検討のひとつであったが、医療プラットフォーム事業にある CLINICS のロゴがシンボルマーク付きであるため、医療プラットフォームに関連するプロダクト = シンボルを定義するというルールを策定しシンボルも設計。シンボルは薬の構造式に利用される「ハニカム構造」をモチーフとし、ブランドカラーと合わせて詳細に作り込んでいった。 また、Pharms の製品紹介用ランディングページやプロダクトデザインのモックアップを作成し、ロゴとのバランスなども考慮しながら調整を行っていった。 最終的に、患者・調剤薬局・医療機関の 3 者のつながりを三角形で表現しつつ、中心を先述した「ハニカム構造」をモチーフとした形状と、Pharms の頭文字「P」をカプセルと錠剤で表現して、調剤薬局システムとしてシンボルマークに命を吹き込んだ。 まとめ このような過程を経て、Pharms のブランドが完成したのだが、これらは調剤薬局システムの開発としては氷山の一角でしかない。本丸はプロダクトデザイン。一般的にはロゴとプロダクトデザインは別プロジェクトで進行したり、担当するデザイナーが別だったりすることも多いのではないだろうか。 Pharms はブランド設計、プロダクトデザイン、マーケティング資材といったデザイン領域をすべて私が担当していくことになるのだが、それ故に事業全体を俯瞰し理解しながらデザインや UI デザインに魂を込めて携わることができた。デザイナーキャリアとしてもここまで幅広く携われたことは非常に貴重な経験を得ることができたと自負している。 続いてプロダクトデザイン開発の秘話について語りたいところだが、現在 Pharms 以外の医療プラットフォーム事業に関連する新たなプロダクト開発に注力しているため、その話はまたの機会に。 医療プラットフォーム事業に関連するプロダクトをこれからも創出し成長させていく面白い時期にあり、現在デザイナーを積極採用中です。カジュアルに話を聞きたい、医療領域のデザインに興味があるといったデザイナーの方は、ぜひ こちら までご連絡いただけると幸いです。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

「2020 年 9 月に調剤薬局向けのプロダクトをリリースする」 この プレスリリース が発表されたのは、COVID-19 の感染拡大に端を発する緊急事態宣言が発令されていた 2020 年 4 月半ば。その 1 ヶ月後、私はリモートワーク下でのオンライン MTG になじめない状態のまま、調剤薬局向けプロダクトのブランディングについて役員陣や主要プロジェクトメンバーにプレゼンを行っていた。 今回は当時のプレゼン資料をたどりながら Pharms のブランド設計について説明していこうと思う。 医薬分業のルーツとは デザイナーとして前田がメドレーに入社してから、オンライン診療や電子カルテなど、主に医療機関向けのプロダクトデザインを担当していたものの、調剤薬局のプロダクトデザインは未知の領域。ブランディングを検討する上で、薬の処方を行う医師と調剤を実施する薬剤師が分担して行う医薬分業のルーツついて調べることからはじめた。 医薬分業は、毒殺を恐れたフリードリヒ 2 世が主治医の処方した薬を、毒が盛られてないか他者にチェックさせたのが始まりとされている。 （参考： 公益社団法人 日本薬剤師会 HP ｜医薬分業とは ） 医療プラットフォームの未来を見据えたブランド定義 次に、調剤に関する法制度や競合などの外部要因、メドレーとしてのブランド力や開発力などの内部要因について簡易な SWOT 分析を行い、調剤薬局のプロジェクトの妥当性を検証。メドレーが取り組む医療プラットフォーム事業(※)に、あらたに調剤薬局プロジェクトが加わることによる他のプロダクトとのバランスも考慮しながらブランドネーミング検討を行っていった。 ※) 医療プラットフォーム事業では、患者と医療領域の業務システムを SaaS プロダクトでつなぎ、患者と医療機関双方にとって、テクノロジーの恩恵を受けることのできるプラットフォームづくりを行っている。主要サービスはクラウド診療支援システム「CLINICS」やオンライン診療・服薬指導アプリ「CLINICS」。 メドレーのこれまでの歴史を振り返ると、プロダクト内容を明確かつ端的に表したネーミングが多く、メドレーらしさ = 「中央突破なネーミング」ということを定義し、ネーミングを検討していった。 最終的に調剤薬局を表す「Pharmacies（ファーマシーズ）」と「Pharms（ファームス）」の 2 案に絞込み、それぞれのメリット・デメリットを整理していった。 当時、社内では調剤薬局システム = Pharmacies と呼ばれており、その中央突破なネーミングが最有力候補であった。一方で、ブランドで体現すべきアイデンティティの欠如や、呼びづらさなどが課題として散見された。さらには医療プラットフォーム全体を見据えたブランド構築という観点から考慮すると、バランス面での課題が浮き彫りになり、それら課題をクリアにして誕生したのが Pharms（ファームス）である。 ヴィジュアル・アイデンティティの設計 ブランド名が固まれば、あとはヴィジュアル・アイデンティティを突き詰めていくのみ。視認性や可読性を考慮したフォントフェイスの検証や調剤薬局と想起させるブランドカラーの選定、またシンボルの設計などに取り掛かっていく。 ブランドカラーの選定においては、なんとなく「緑」というイメージがチーム内でもあったが、より精緻化するため、薬の起源や調剤薬局本来の役割を踏まえ詳細に落とし込んでいった。 ロゴにシンボルを含めるか、含めないかも検討のひとつであったが、医療プラットフォーム事業にある CLINICS のロゴがシンボルマーク付きであるため、医療プラットフォームに関連するプロダクト = シンボルを定義するというルールを策定しシンボルも設計。シンボルは薬の構造式に利用される「ハニカム構造」をモチーフとし、ブランドカラーと合わせて詳細に作り込んでいった。 また、Pharms の製品紹介用ランディングページやプロダクトデザインのモックアップを作成し、ロゴとのバランスなども考慮しながら調整を行っていった。 最終的に、患者・調剤薬局・医療機関の 3 者のつながりを三角形で表現しつつ、中心を先述した「ハニカム構造」をモチーフとした形状と、Pharms の頭文字「P」をカプセルと錠剤で表現して、調剤薬局システムとしてシンボルマークに命を吹き込んだ。 まとめ このような過程を経て、Pharms のブランドが完成したのだが、これらは調剤薬局システムの開発としては氷山の一角でしかない。本丸はプロダクトデザイン。一般的にはロゴとプロダクトデザインは別プロジェクトで進行したり、担当するデザイナーが別だったりすることも多いのではないだろうか。 Pharms はブランド設計、プロダクトデザイン、マーケティング資材といったデザイン領域をすべて私が担当していくことになるのだが、それ故に事業全体を俯瞰し理解しながらデザインや UI デザインに魂を込めて携わることができた。デザイナーキャリアとしてもここまで幅広く携われたことは非常に貴重な経験を得ることができたと自負している。 続いてプロダクトデザイン開発の秘話について語りたいところだが、現在 Pharms 以外の医療プラットフォーム事業に関連する新たなプロダクト開発に注力しているため、その話はまたの機会に。 医療プラットフォーム事業に関連するプロダクトをこれからも創出し成長させていく面白い時期にあり、現在デザイナーを積極採用中です。カジュアルに話を聞きたい、医療領域のデザインに興味があるといったデザイナーの方は、ぜひ こちら までご連絡いただけると幸いです。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

「2020 年 9 月に調剤薬局向けのプロダクトをリリースする」 この プレスリリース が発表されたのは、COVID-19 の感染拡大に端を発する緊急事態宣言が発令されていた 2020 年 4 月半ば。その 1 ヶ月後、私はリモートワーク下でのオンライン MTG になじめない状態のまま、調剤薬局向けプロダクトのブランディングについて役員陣や主要プロジェクトメンバーにプレゼンを行っていた。 今回は当時のプレゼン資料をたどりながら Pharms のブランド設計について説明していこうと思う。 医薬分業のルーツとは デザイナーとして前田がメドレーに入社してから、オンライン診療や電子カルテなど、主に医療機関向けのプロダクトデザインを担当していたものの、調剤薬局のプロダクトデザインは未知の領域。ブランディングを検討する上で、薬の処方を行う医師と調剤を実施する薬剤師が分担して行う医薬分業のルーツついて調べることからはじめた。 医薬分業は、毒殺を恐れたフリードリヒ 2 世が主治医の処方した薬を、毒が盛られてないか他者にチェックさせたのが始まりとされている。 （参考： 公益社団法人 日本薬剤師会 HP ｜医薬分業とは ） 医療プラットフォームの未来を見据えたブランド定義 次に、調剤に関する法制度や競合などの外部要因、メドレーとしてのブランド力や開発力などの内部要因について簡易な SWOT 分析を行い、調剤薬局のプロジェクトの妥当性を検証。メドレーが取り組む医療プラットフォーム事業(※)に、あらたに調剤薬局プロジェクトが加わることによる他のプロダクトとのバランスも考慮しながらブランドネーミング検討を行っていった。 ※) 医療プラットフォーム事業では、患者と医療領域の業務システムを SaaS プロダクトでつなぎ、患者と医療機関双方にとって、テクノロジーの恩恵を受けることのできるプラットフォームづくりを行っている。主要サービスはクラウド診療支援システム「CLINICS」やオンライン診療・服薬指導アプリ「CLINICS」。 メドレーのこれまでの歴史を振り返ると、プロダクト内容を明確かつ端的に表したネーミングが多く、メドレーらしさ = 「中央突破なネーミング」ということを定義し、ネーミングを検討していった。 最終的に調剤薬局を表す「Pharmacies（ファーマシーズ）」と「Pharms（ファームス）」の 2 案に絞込み、それぞれのメリット・デメリットを整理していった。 当時、社内では調剤薬局システム = Pharmacies と呼ばれており、その中央突破なネーミングが最有力候補であった。一方で、ブランドで体現すべきアイデンティティの欠如や、呼びづらさなどが課題として散見された。さらには医療プラットフォーム全体を見据えたブランド構築という観点から考慮すると、バランス面での課題が浮き彫りになり、それら課題をクリアにして誕生したのが Pharms（ファームス）である。 ヴィジュアル・アイデンティティの設計 ブランド名が固まれば、あとはヴィジュアル・アイデンティティを突き詰めていくのみ。視認性や可読性を考慮したフォントフェイスの検証や調剤薬局と想起させるブランドカラーの選定、またシンボルの設計などに取り掛かっていく。 ブランドカラーの選定においては、なんとなく「緑」というイメージがチーム内でもあったが、より精緻化するため、薬の起源や調剤薬局本来の役割を踏まえ詳細に落とし込んでいった。 ロゴにシンボルを含めるか、含めないかも検討のひとつであったが、医療プラットフォーム事業にある CLINICS のロゴがシンボルマーク付きであるため、医療プラットフォームに関連するプロダクト = シンボルを定義するというルールを策定しシンボルも設計。シンボルは薬の構造式に利用される「ハニカム構造」をモチーフとし、ブランドカラーと合わせて詳細に作り込んでいった。 また、Pharms の製品紹介用ランディングページやプロダクトデザインのモックアップを作成し、ロゴとのバランスなども考慮しながら調整を行っていった。 最終的に、患者・調剤薬局・医療機関の 3 者のつながりを三角形で表現しつつ、中心を先述した「ハニカム構造」をモチーフとした形状と、Pharms の頭文字「P」をカプセルと錠剤で表現して、調剤薬局システムとしてシンボルマークに命を吹き込んだ。 まとめ このような過程を経て、Pharms のブランドが完成したのだが、これらは調剤薬局システムの開発としては氷山の一角でしかない。本丸はプロダクトデザイン。一般的にはロゴとプロダクトデザインは別プロジェクトで進行したり、担当するデザイナーが別だったりすることも多いのではないだろうか。 Pharms はブランド設計、プロダクトデザイン、マーケティング資材といったデザイン領域をすべて私が担当していくことになるのだが、それ故に事業全体を俯瞰し理解しながらデザインや UI デザインに魂を込めて携わることができた。デザイナーキャリアとしてもここまで幅広く携われたことは非常に貴重な経験を得ることができたと自負している。 続いてプロダクトデザイン開発の秘話について語りたいところだが、現在 Pharms 以外の医療プラットフォーム事業に関連する新たなプロダクト開発に注力しているため、その話はまたの機会に。 医療プラットフォーム事業に関連するプロダクトをこれからも創出し成長させていく面白い時期にあり、現在デザイナーを積極採用中です。カジュアルに話を聞きたい、医療領域のデザインに興味があるといったデザイナーの方は、ぜひ こちら までご連絡いただけると幸いです。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

「2020 年 9 月に調剤薬局向けのプロダクトをリリースする」 この プレスリリース が発表されたのは、COVID-19 の感染拡大に端を発する緊急事態宣言が発令されていた 2020 年 4 月半ば。その 1 ヶ月後、私はリモートワーク下でのオンライン MTG になじめない状態のまま、調剤薬局向けプロダクトのブランディングについて役員陣や主要プロジェクトメンバーにプレゼンを行っていた。 今回は当時のプレゼン資料をたどりながら Pharms のブランド設計について説明していこうと思う。 医薬分業のルーツとは デザイナーとして前田がメドレーに入社してから、オンライン診療や電子カルテなど、主に医療機関向けのプロダクトデザインを担当していたものの、調剤薬局のプロダクトデザインは未知の領域。ブランディングを検討する上で、薬の処方を行う医師と調剤を実施する薬剤師が分担して行う医薬分業のルーツついて調べることからはじめた。 医薬分業は、毒殺を恐れたフリードリヒ 2 世が主治医の処方した薬を、毒が盛られてないか他者にチェックさせたのが始まりとされている。 （参考： 公益社団法人 日本薬剤師会 HP ｜医薬分業とは ） 医療プラットフォームの未来を見据えたブランド定義 次に、調剤に関する法制度や競合などの外部要因、メドレーとしてのブランド力や開発力などの内部要因について簡易な SWOT 分析を行い、調剤薬局のプロジェクトの妥当性を検証。メドレーが取り組む医療プラットフォーム事業(※)に、あらたに調剤薬局プロジェクトが加わることによる他のプロダクトとのバランスも考慮しながらブランドネーミング検討を行っていった。 ※) 医療プラットフォーム事業では、患者と医療領域の業務システムを SaaS プロダクトでつなぎ、患者と医療機関双方にとって、テクノロジーの恩恵を受けることのできるプラットフォームづくりを行っている。主要サービスはクラウド診療支援システム「CLINICS」やオンライン診療・服薬指導アプリ「CLINICS」。 メドレーのこれまでの歴史を振り返ると、プロダクト内容を明確かつ端的に表したネーミングが多く、メドレーらしさ = 「中央突破なネーミング」ということを定義し、ネーミングを検討していった。 最終的に調剤薬局を表す「Pharmacies（ファーマシーズ）」と「Pharms（ファームス）」の 2 案に絞込み、それぞれのメリット・デメリットを整理していった。 当時、社内では調剤薬局システム = Pharmacies と呼ばれており、その中央突破なネーミングが最有力候補であった。一方で、ブランドで体現すべきアイデンティティの欠如や、呼びづらさなどが課題として散見された。さらには医療プラットフォーム全体を見据えたブランド構築という観点から考慮すると、バランス面での課題が浮き彫りになり、それら課題をクリアにして誕生したのが Pharms（ファームス）である。 ヴィジュアル・アイデンティティの設計 ブランド名が固まれば、あとはヴィジュアル・アイデンティティを突き詰めていくのみ。視認性や可読性を考慮したフォントフェイスの検証や調剤薬局と想起させるブランドカラーの選定、またシンボルの設計などに取り掛かっていく。 ブランドカラーの選定においては、なんとなく「緑」というイメージがチーム内でもあったが、より精緻化するため、薬の起源や調剤薬局本来の役割を踏まえ詳細に落とし込んでいった。 ロゴにシンボルを含めるか、含めないかも検討のひとつであったが、医療プラットフォーム事業にある CLINICS のロゴがシンボルマーク付きであるため、医療プラットフォームに関連するプロダクト = シンボルを定義するというルールを策定しシンボルも設計。シンボルは薬の構造式に利用される「ハニカム構造」をモチーフとし、ブランドカラーと合わせて詳細に作り込んでいった。 また、Pharms の製品紹介用ランディングページやプロダクトデザインのモックアップを作成し、ロゴとのバランスなども考慮しながら調整を行っていった。 最終的に、患者・調剤薬局・医療機関の 3 者のつながりを三角形で表現しつつ、中心を先述した「ハニカム構造」をモチーフとした形状と、Pharms の頭文字「P」をカプセルと錠剤で表現して、調剤薬局システムとしてシンボルマークに命を吹き込んだ。 まとめ このような過程を経て、Pharms のブランドが完成したのだが、これらは調剤薬局システムの開発としては氷山の一角でしかない。本丸はプロダクトデザイン。一般的にはロゴとプロダクトデザインは別プロジェクトで進行したり、担当するデザイナーが別だったりすることも多いのではないだろうか。 Pharms はブランド設計、プロダクトデザイン、マーケティング資材といったデザイン領域をすべて私が担当していくことになるのだが、それ故に事業全体を俯瞰し理解しながらデザインや UI デザインに魂を込めて携わることができた。デザイナーキャリアとしてもここまで幅広く携われたことは非常に貴重な経験を得ることができたと自負している。 続いてプロダクトデザイン開発の秘話について語りたいところだが、現在 Pharms 以外の医療プラットフォーム事業に関連する新たなプロダクト開発に注力しているため、その話はまたの機会に。 医療プラットフォーム事業に関連するプロダクトをこれからも創出し成長させていく面白い時期にあり、現在デザイナーを積極採用中です。カジュアルに話を聞きたい、医療領域のデザインに興味があるといったデザイナーの方は、ぜひ こちら までご連絡いただけると幸いです。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

「2020 年 9 月に調剤薬局向けのプロダクトをリリースする」 この プレスリリース が発表されたのは、COVID-19 の感染拡大に端を発する緊急事態宣言が発令されていた 2020 年 4 月半ば。その 1 ヶ月後、私はリモートワーク下でのオンライン MTG になじめない状態のまま、調剤薬局向けプロダクトのブランディングについて役員陣や主要プロジェクトメンバーにプレゼンを行っていた。 今回は当時のプレゼン資料をたどりながら Pharms のブランド設計について説明していこうと思う。 医薬分業のルーツとは デザイナーとして前田がメドレーに入社してから、オンライン診療や電子カルテなど、主に医療機関向けのプロダクトデザインを担当していたものの、調剤薬局のプロダクトデザインは未知の領域。ブランディングを検討する上で、薬の処方を行う医師と調剤を実施する薬剤師が分担して行う医薬分業のルーツついて調べることからはじめた。 医薬分業は、毒殺を恐れたフリードリヒ 2 世が主治医の処方した薬を、毒が盛られてないか他者にチェックさせたのが始まりとされている。 （参考： 公益社団法人 日本薬剤師会 HP ｜医薬分業とは ） 医療プラットフォームの未来を見据えたブランド定義 次に、調剤に関する法制度や競合などの外部要因、メドレーとしてのブランド力や開発力などの内部要因について簡易な SWOT 分析を行い、調剤薬局のプロジェクトの妥当性を検証。メドレーが取り組む医療プラットフォーム事業(※)に、あらたに調剤薬局プロジェクトが加わることによる他のプロダクトとのバランスも考慮しながらブランドネーミング検討を行っていった。 ※) 医療プラットフォーム事業では、患者と医療領域の業務システムを SaaS プロダクトでつなぎ、患者と医療機関双方にとって、テクノロジーの恩恵を受けることのできるプラットフォームづくりを行っている。主要サービスはクラウド診療支援システム「CLINICS」やオンライン診療・服薬指導アプリ「CLINICS」。 メドレーのこれまでの歴史を振り返ると、プロダクト内容を明確かつ端的に表したネーミングが多く、メドレーらしさ = 「中央突破なネーミング」ということを定義し、ネーミングを検討していった。 最終的に調剤薬局を表す「Pharmacies（ファーマシーズ）」と「Pharms（ファームス）」の 2 案に絞込み、それぞれのメリット・デメリットを整理していった。 当時、社内では調剤薬局システム = Pharmacies と呼ばれており、その中央突破なネーミングが最有力候補であった。一方で、ブランドで体現すべきアイデンティティの欠如や、呼びづらさなどが課題として散見された。さらには医療プラットフォーム全体を見据えたブランド構築という観点から考慮すると、バランス面での課題が浮き彫りになり、それら課題をクリアにして誕生したのが Pharms（ファームス）である。 ヴィジュアル・アイデンティティの設計 ブランド名が固まれば、あとはヴィジュアル・アイデンティティを突き詰めていくのみ。視認性や可読性を考慮したフォントフェイスの検証や調剤薬局と想起させるブランドカラーの選定、またシンボルの設計などに取り掛かっていく。 ブランドカラーの選定においては、なんとなく「緑」というイメージがチーム内でもあったが、より精緻化するため、薬の起源や調剤薬局本来の役割を踏まえ詳細に落とし込んでいった。 ロゴにシンボルを含めるか、含めないかも検討のひとつであったが、医療プラットフォーム事業にある CLINICS のロゴがシンボルマーク付きであるため、医療プラットフォームに関連するプロダクト = シンボルを定義するというルールを策定しシンボルも設計。シンボルは薬の構造式に利用される「ハニカム構造」をモチーフとし、ブランドカラーと合わせて詳細に作り込んでいった。 また、Pharms の製品紹介用ランディングページやプロダクトデザインのモックアップを作成し、ロゴとのバランスなども考慮しながら調整を行っていった。 最終的に、患者・調剤薬局・医療機関の 3 者のつながりを三角形で表現しつつ、中心を先述した「ハニカム構造」をモチーフとした形状と、Pharms の頭文字「P」をカプセルと錠剤で表現して、調剤薬局システムとしてシンボルマークに命を吹き込んだ。 まとめ このような過程を経て、Pharms のブランドが完成したのだが、これらは調剤薬局システムの開発としては氷山の一角でしかない。本丸はプロダクトデザイン。一般的にはロゴとプロダクトデザインは別プロジェクトで進行したり、担当するデザイナーが別だったりすることも多いのではないだろうか。 Pharms はブランド設計、プロダクトデザイン、マーケティング資材といったデザイン領域をすべて私が担当していくことになるのだが、それ故に事業全体を俯瞰し理解しながらデザインや UI デザインに魂を込めて携わることができた。デザイナーキャリアとしてもここまで幅広く携われたことは非常に貴重な経験を得ることができたと自負している。 続いてプロダクトデザイン開発の秘話について語りたいところだが、現在 Pharms 以外の医療プラットフォーム事業に関連する新たなプロダクト開発に注力しているため、その話はまたの機会に。 医療プラットフォーム事業に関連するプロダクトをこれからも創出し成長させていく面白い時期にあり、現在デザイナーを積極採用中です。カジュアルに話を聞きたい、医療領域のデザインに興味があるといったデザイナーの方は、ぜひ こちら までご連絡いただけると幸いです。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

「2020 年 9 月に調剤薬局向けのプロダクトをリリースする」 この プレスリリース が発表されたのは、COVID-19 の感染拡大に端を発する緊急事態宣言が発令されていた 2020 年 4 月半ば。その 1 ヶ月後、私はリモートワーク下でのオンライン MTG になじめない状態のまま、調剤薬局向けプロダクトのブランディングについて役員陣や主要プロジェクトメンバーにプレゼンを行っていた。 今回は当時のプレゼン資料をたどりながら Pharms のブランド設計について説明していこうと思う。 医薬分業のルーツとは デザイナーとして前田がメドレーに入社してから、オンライン診療や電子カルテなど、主に医療機関向けのプロダクトデザインを担当していたものの、調剤薬局のプロダクトデザインは未知の領域。ブランディングを検討する上で、薬の処方を行う医師と調剤を実施する薬剤師が分担して行う医薬分業のルーツついて調べることからはじめた。 医薬分業は、毒殺を恐れたフリードリヒ 2 世が主治医の処方した薬を、毒が盛られてないか他者にチェックさせたのが始まりとされている。 （参考： 公益社団法人 日本薬剤師会 HP ｜医薬分業とは ） 医療プラットフォームの未来を見据えたブランド定義 次に、調剤に関する法制度や競合などの外部要因、メドレーとしてのブランド力や開発力などの内部要因について簡易な SWOT 分析を行い、調剤薬局のプロジェクトの妥当性を検証。メドレーが取り組む医療プラットフォーム事業(※)に、あらたに調剤薬局プロジェクトが加わることによる他のプロダクトとのバランスも考慮しながらブランドネーミング検討を行っていった。 ※) 医療プラットフォーム事業では、患者と医療領域の業務システムを SaaS プロダクトでつなぎ、患者と医療機関双方にとって、テクノロジーの恩恵を受けることのできるプラットフォームづくりを行っている。主要サービスはクラウド診療支援システム「CLINICS」やオンライン診療・服薬指導アプリ「CLINICS」。 メドレーのこれまでの歴史を振り返ると、プロダクト内容を明確かつ端的に表したネーミングが多く、メドレーらしさ = 「中央突破なネーミング」ということを定義し、ネーミングを検討していった。 最終的に調剤薬局を表す「Pharmacies（ファーマシーズ）」と「Pharms（ファームス）」の 2 案に絞込み、それぞれのメリット・デメリットを整理していった。 当時、社内では調剤薬局システム = Pharmacies と呼ばれており、その中央突破なネーミングが最有力候補であった。一方で、ブランドで体現すべきアイデンティティの欠如や、呼びづらさなどが課題として散見された。さらには医療プラットフォーム全体を見据えたブランド構築という観点から考慮すると、バランス面での課題が浮き彫りになり、それら課題をクリアにして誕生したのが Pharms（ファームス）である。 ヴィジュアル・アイデンティティの設計 ブランド名が固まれば、あとはヴィジュアル・アイデンティティを突き詰めていくのみ。視認性や可読性を考慮したフォントフェイスの検証や調剤薬局と想起させるブランドカラーの選定、またシンボルの設計などに取り掛かっていく。 ブランドカラーの選定においては、なんとなく「緑」というイメージがチーム内でもあったが、より精緻化するため、薬の起源や調剤薬局本来の役割を踏まえ詳細に落とし込んでいった。 ロゴにシンボルを含めるか、含めないかも検討のひとつであったが、医療プラットフォーム事業にある CLINICS のロゴがシンボルマーク付きであるため、医療プラットフォームに関連するプロダクト = シンボルを定義するというルールを策定しシンボルも設計。シンボルは薬の構造式に利用される「ハニカム構造」をモチーフとし、ブランドカラーと合わせて詳細に作り込んでいった。 また、Pharms の製品紹介用ランディングページやプロダクトデザインのモックアップを作成し、ロゴとのバランスなども考慮しながら調整を行っていった。 最終的に、患者・調剤薬局・医療機関の 3 者のつながりを三角形で表現しつつ、中心を先述した「ハニカム構造」をモチーフとした形状と、Pharms の頭文字「P」をカプセルと錠剤で表現して、調剤薬局システムとしてシンボルマークに命を吹き込んだ。 まとめ このような過程を経て、Pharms のブランドが完成したのだが、これらは調剤薬局システムの開発としては氷山の一角でしかない。本丸はプロダクトデザイン。一般的にはロゴとプロダクトデザインは別プロジェクトで進行したり、担当するデザイナーが別だったりすることも多いのではないだろうか。 Pharms はブランド設計、プロダクトデザイン、マーケティング資材といったデザイン領域をすべて私が担当していくことになるのだが、それ故に事業全体を俯瞰し理解しながらデザインや UI デザインに魂を込めて携わることができた。デザイナーキャリアとしてもここまで幅広く携われたことは非常に貴重な経験を得ることができたと自負している。 続いてプロダクトデザイン開発の秘話について語りたいところだが、現在 Pharms 以外の医療プラットフォーム事業に関連する新たなプロダクト開発に注力しているため、その話はまたの機会に。 医療プラットフォーム事業に関連するプロダクトをこれからも創出し成長させていく面白い時期にあり、現在デザイナーを積極採用中です。カジュアルに話を聞きたい、医療領域のデザインに興味があるといったデザイナーの方は、ぜひ こちら までご連絡いただけると幸いです。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめまして。メドレーでセキュリティエンジニアをしている三浦です。 私はメドレーには今年（2021 年）の 2 月に入社し、このブログを執筆している時点で入社 4 ヶ月目となります。現在、全社的なセキュリティを担当しています。 今回のブログは以下のような構成でお届けします。 目次 自己紹介と、本ブログのテーマについて 前職でのセキュリティエンジニアとしての仕事 メドレーでのセキュリティエンジニアの仕事 セキュリティエンジニアとしての活動内容や役割の違いと気づき、課題 セキュリティエンジニア募集中！ 自己紹介と、本ブログのテーマについて 私は前職でセキュリティ専業会社のセキュリティエンジニアとして脆弱性診断やペネトレーションテストのほか、セキュリティ研修の講師、ファイアウォールや Web アプリケーションファイアウォール（WAF）と呼ばれる機器の導入支援などに携わっていました。 このなかでも脆弱性診断の案件に多く関わっていたこともあり、最後には脆弱性診断のサービスオーナーとしてサービスに関わるすべてを取りまとめる立場でした。 今では事業会社のセキュリティエンジニアとして活動しているわけですが、このブログではセキュリティエンジニアとしての活動内容や役割にどのような変化があり、その変化により直面している自分自身の課題や苦労について書いていきます。 前職でのセキュリティエンジニアとしての仕事 先述のとおり前職では脆弱性診断に関わることが多かったため、ここでは脆弱性診断について取り上げます。 脆弱性診断はスポット案件として実施することがほとんどでしたので、案件の流れという観点で仕事内容を整理すると以下のようになります。 営業フォロー（同行や Q&A など） スケジュールや診断対象などについてお客様にヒアリング a. ここで診断用環境の準備をお願いすることが多い 診断対象の調査、クロール作業 スケジュール感や制限事項についてお客様とすり合わせ 計画書を作成 社内で計画書レビュー、お客様へ送付 診断作業 a. 自動診断ツールの調整 a. 手動診断の実施 a. 出力結果の精査、再現性の確認 a. 速報があれば当日中に整理して送付 診断結果のエビデンス整理 報告書の下書き、リスク度合いの検討 社内で報告書レビュー お客様へ報告書を納品 報告会の実施 このなかで、特に診断担当者の技術的スキルが問われたのが「手動診断の実施」と「出力結果の精査、再現性の確認」で、全体のうち約 4 割ほど。残りはドキュメント作成、レビュー、ミーティング、業務改善といった定型業務が占めていました。 私は「この 4 割の部分に対して付加価値を提供したい」というエンジニアとしての気負いと、個人的な関心という 2 つの理由から、寝る時間を削っては脆弱性の悪用（Exploit）手法の習得と、知識的な補強としての資格取得に明け暮れる時期がありました。 結局、寝不足が続いたことが原因で肺炎を発症し、入院一歩前まで炎症マーカーが悪化するという自分自身の脆弱性が露呈することになったのですが。ちゃんと夜は寝ましょう。 話がすこし脱線しましたが、脆弱性診断や SI 案件などは年度末にピークを迎えるものの年間を通じて五月雨で受注することも多く、一定の品質を維持しながらも納期を守るために目の前の案件で必死だったというのが今までの仕事のスタイルでした。 目の前の案件をひたすらこなし、組織に対して「報告書を提出して終わり」の関わり方に対して『これで社会の役に立っているのだろうか』という疑問が生まれたことが、メドレーに入社する転機になっています。 メドレーでのセキュリティエンジニアの仕事 さて、セキュリティサービスを提供する側で案件に追われていた私がメドレーでセキュリティエンジニアとして活動することになっているわけですが、具体的に今なにをしているのか？というと、大きくは以下の 6 つが挙げられます。 自社サービスに対する脆弱性診断 脅威情報や脆弱性情報の収集、周知 全社的な業務プロセス上のリスク調査 全社システムの BCP 整備、保守 ISMS 運用 セキュリティ相談 自社サービスに対する脆弱性診断というのは「脆弱性診断の内製化」で、脆弱性診断を外部の業者にお願いするのではなく自社内で実施して開発にフィードバックする形です。 内製による診断であっても、基本的な流れはすでにご紹介した流れで進めていますが、対象サービスをクロールしてから診断対象を確定させるまでの主要なポイントでは、操作手順に漏れがないかなどの観点で開発からのレビューを挟むようにしています。これは内製であるからこそ実現できているアプローチだと思います。 内製で実施している診断対象一覧の例 なお、ここまで脆弱性診断について書いてきましたが、これは現在の業務のほんの一部で、このほかには ISMS の運用（事務局）としての活動のほか、コーポレート IT メンバーと共に事業継続計画（BCP）整備なども並行して進めなければなりません。とにかく関わる範囲が広く、そして、とても地道な活動です。 ですが、会社全体を俯瞰してセキュリティのことを意識して物事を考え続けられる立場というのはセキュリティ会社では経験できないことで、自社にとっての最適解は何か？を探求し続けることの新たな面白さを見いだすことができています。 セキュリティエンジニアとしての活動内容や役割の違いと気づき、課題 ここまでの内容でお気づきの方もいるかと思いますが、現在の業務は ISMS 運用を初めとしてリスクマネジメントの分野も多く、実務的なバックグラウンドのない業務も出てきています。 システム的なセキュリティに関しても「どうやって悪用できるか…好物の BOF*は無いのか..BOF はどこだ…」という攻撃観点の思考回路のみで判断するのではなく、「どのようなソリューションや仕組み、またはルールでリスク低減できるのか、そして、それをなるべく自動で運用できるようにはどうするか」という守る側にとっての実務的な課題を考えなければなりません。 * バッファオーバーフローのこと このほかに、私が実際に感じているセキュリティエンジニアとしての気づきや考え方の変化を挙げていくと、以下のようなものがあります。 攻撃手法の理解を踏まえ、（社内リソースを鑑みた）現実的に運用しうる対策の仕組みを提案できなければならないことを痛感した 仕組み化やルール化するにも、エンジニアではない従業員の存在を考慮するようになった 脆弱性単体の影響範囲や度合いではなく、システムの利用方法や情報の種類など、社内だからこそ持てる視点を持って評価するようになった 「アップデートしたくてもできない」問題が生じないシステム設計が肝要であることを改めて認識した これらの変化への対応については、すべてソリューションや自動化に対して私の知見がまだまだ不足しているため、これからは「攻撃者目線」の考え方に加えて「ソリューションと自動化」の知見を補完しながら、メドレーのセキュリティ向上に貢献し続けていきたいと考えています。 セキュリティエンジニア募集中！ 最後となりますが、セキュリティエンジニアは関わる業務の幅広さに加え、絶対的な正解が存在しない問題にソリューションを提供することも多い仕事です。 メドレーでの内製による脆弱性診断や全社セキュリティに興味がある方はぜひジョインしてください。いつでもお待ちしています！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめまして。メドレーでセキュリティエンジニアをしている三浦です。 私はメドレーには今年（2021 年）の 2 月に入社し、このブログを執筆している時点で入社 4 ヶ月目となります。現在、全社的なセキュリティを担当しています。 今回のブログは以下のような構成でお届けします。 目次 自己紹介と、本ブログのテーマについて 前職でのセキュリティエンジニアとしての仕事 メドレーでのセキュリティエンジニアの仕事 セキュリティエンジニアとしての活動内容や役割の違いと気づき、課題 セキュリティエンジニア募集中！ 自己紹介と、本ブログのテーマについて 私は前職でセキュリティ専業会社のセキュリティエンジニアとして脆弱性診断やペネトレーションテストのほか、セキュリティ研修の講師、ファイアウォールや Web アプリケーションファイアウォール（WAF）と呼ばれる機器の導入支援などに携わっていました。 このなかでも脆弱性診断の案件に多く関わっていたこともあり、最後には脆弱性診断のサービスオーナーとしてサービスに関わるすべてを取りまとめる立場でした。 今では事業会社のセキュリティエンジニアとして活動しているわけですが、このブログではセキュリティエンジニアとしての活動内容や役割にどのような変化があり、その変化により直面している自分自身の課題や苦労について書いていきます。 前職でのセキュリティエンジニアとしての仕事 先述のとおり前職では脆弱性診断に関わることが多かったため、ここでは脆弱性診断について取り上げます。 脆弱性診断はスポット案件として実施することがほとんどでしたので、案件の流れという観点で仕事内容を整理すると以下のようになります。 営業フォロー（同行や Q&A など） スケジュールや診断対象などについてお客様にヒアリング a. ここで診断用環境の準備をお願いすることが多い 診断対象の調査、クロール作業 スケジュール感や制限事項についてお客様とすり合わせ 計画書を作成 社内で計画書レビュー、お客様へ送付 診断作業 a. 自動診断ツールの調整 a. 手動診断の実施 a. 出力結果の精査、再現性の確認 a. 速報があれば当日中に整理して送付 診断結果のエビデンス整理 報告書の下書き、リスク度合いの検討 社内で報告書レビュー お客様へ報告書を納品 報告会の実施 このなかで、特に診断担当者の技術的スキルが問われたのが「手動診断の実施」と「出力結果の精査、再現性の確認」で、全体のうち約 4 割ほど。残りはドキュメント作成、レビュー、ミーティング、業務改善といった定型業務が占めていました。 私は「この 4 割の部分に対して付加価値を提供したい」というエンジニアとしての気負いと、個人的な関心という 2 つの理由から、寝る時間を削っては脆弱性の悪用（Exploit）手法の習得と、知識的な補強としての資格取得に明け暮れる時期がありました。 結局、寝不足が続いたことが原因で肺炎を発症し、入院一歩前まで炎症マーカーが悪化するという自分自身の脆弱性が露呈することになったのですが。ちゃんと夜は寝ましょう。 話がすこし脱線しましたが、脆弱性診断や SI 案件などは年度末にピークを迎えるものの年間を通じて五月雨で受注することも多く、一定の品質を維持しながらも納期を守るために目の前の案件で必死だったというのが今までの仕事のスタイルでした。 目の前の案件をひたすらこなし、組織に対して「報告書を提出して終わり」の関わり方に対して『これで社会の役に立っているのだろうか』という疑問が生まれたことが、メドレーに入社する転機になっています。 メドレーでのセキュリティエンジニアの仕事 さて、セキュリティサービスを提供する側で案件に追われていた私がメドレーでセキュリティエンジニアとして活動することになっているわけですが、具体的に今なにをしているのか？というと、大きくは以下の 6 つが挙げられます。 自社サービスに対する脆弱性診断 脅威情報や脆弱性情報の収集、周知 全社的な業務プロセス上のリスク調査 全社システムの BCP 整備、保守 ISMS 運用 セキュリティ相談 自社サービスに対する脆弱性診断というのは「脆弱性診断の内製化」で、脆弱性診断を外部の業者にお願いするのではなく自社内で実施して開発にフィードバックする形です。 内製による診断であっても、基本的な流れはすでにご紹介した流れで進めていますが、対象サービスをクロールしてから診断対象を確定させるまでの主要なポイントでは、操作手順に漏れがないかなどの観点で開発からのレビューを挟むようにしています。これは内製であるからこそ実現できているアプローチだと思います。 内製で実施している診断対象一覧の例 なお、ここまで脆弱性診断について書いてきましたが、これは現在の業務のほんの一部で、このほかには ISMS の運用（事務局）としての活動のほか、コーポレート IT メンバーと共に事業継続計画（BCP）整備なども並行して進めなければなりません。とにかく関わる範囲が広く、そして、とても地道な活動です。 ですが、会社全体を俯瞰してセキュリティのことを意識して物事を考え続けられる立場というのはセキュリティ会社では経験できないことで、自社にとっての最適解は何か？を探求し続けることの新たな面白さを見いだすことができています。 セキュリティエンジニアとしての活動内容や役割の違いと気づき、課題 ここまでの内容でお気づきの方もいるかと思いますが、現在の業務は ISMS 運用を初めとしてリスクマネジメントの分野も多く、実務的なバックグラウンドのない業務も出てきています。 システム的なセキュリティに関しても「どうやって悪用できるか…好物の BOF*は無いのか..BOF はどこだ…」という攻撃観点の思考回路のみで判断するのではなく、「どのようなソリューションや仕組み、またはルールでリスク低減できるのか、そして、それをなるべく自動で運用できるようにはどうするか」という守る側にとっての実務的な課題を考えなければなりません。 * バッファオーバーフローのこと このほかに、私が実際に感じているセキュリティエンジニアとしての気づきや考え方の変化を挙げていくと、以下のようなものがあります。 攻撃手法の理解を踏まえ、（社内リソースを鑑みた）現実的に運用しうる対策の仕組みを提案できなければならないことを痛感した 仕組み化やルール化するにも、エンジニアではない従業員の存在を考慮するようになった 脆弱性単体の影響範囲や度合いではなく、システムの利用方法や情報の種類など、社内だからこそ持てる視点を持って評価するようになった 「アップデートしたくてもできない」問題が生じないシステム設計が肝要であることを改めて認識した これらの変化への対応については、すべてソリューションや自動化に対して私の知見がまだまだ不足しているため、これからは「攻撃者目線」の考え方に加えて「ソリューションと自動化」の知見を補完しながら、メドレーのセキュリティ向上に貢献し続けていきたいと考えています。 セキュリティエンジニア募集中！ 最後となりますが、セキュリティエンジニアは関わる業務の幅広さに加え、絶対的な正解が存在しない問題にソリューションを提供することも多い仕事です。 メドレーでの内製による脆弱性診断や全社セキュリティに興味がある方はぜひジョインしてください。いつでもお待ちしています！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめまして。メドレーでセキュリティエンジニアをしている三浦です。 私はメドレーには今年（2021 年）の 2 月に入社し、このブログを執筆している時点で入社 4 ヶ月目となります。現在、全社的なセキュリティを担当しています。 今回のブログは以下のような構成でお届けします。 目次 自己紹介と、本ブログのテーマについて 前職でのセキュリティエンジニアとしての仕事 メドレーでのセキュリティエンジニアの仕事 セキュリティエンジニアとしての活動内容や役割の違いと気づき、課題 セキュリティエンジニア募集中！ 自己紹介と、本ブログのテーマについて 私は前職でセキュリティ専業会社のセキュリティエンジニアとして脆弱性診断やペネトレーションテストのほか、セキュリティ研修の講師、ファイアウォールや Web アプリケーションファイアウォール（WAF）と呼ばれる機器の導入支援などに携わっていました。 このなかでも脆弱性診断の案件に多く関わっていたこともあり、最後には脆弱性診断のサービスオーナーとしてサービスに関わるすべてを取りまとめる立場でした。 今では事業会社のセキュリティエンジニアとして活動しているわけですが、このブログではセキュリティエンジニアとしての活動内容や役割にどのような変化があり、その変化により直面している自分自身の課題や苦労について書いていきます。 前職でのセキュリティエンジニアとしての仕事 先述のとおり前職では脆弱性診断に関わることが多かったため、ここでは脆弱性診断について取り上げます。 脆弱性診断はスポット案件として実施することがほとんどでしたので、案件の流れという観点で仕事内容を整理すると以下のようになります。 営業フォロー（同行や Q&A など） スケジュールや診断対象などについてお客様にヒアリング a. ここで診断用環境の準備をお願いすることが多い 診断対象の調査、クロール作業 スケジュール感や制限事項についてお客様とすり合わせ 計画書を作成 社内で計画書レビュー、お客様へ送付 診断作業 a. 自動診断ツールの調整 a. 手動診断の実施 a. 出力結果の精査、再現性の確認 a. 速報があれば当日中に整理して送付 診断結果のエビデンス整理 報告書の下書き、リスク度合いの検討 社内で報告書レビュー お客様へ報告書を納品 報告会の実施 このなかで、特に診断担当者の技術的スキルが問われたのが「手動診断の実施」と「出力結果の精査、再現性の確認」で、全体のうち約 4 割ほど。残りはドキュメント作成、レビュー、ミーティング、業務改善といった定型業務が占めていました。 私は「この 4 割の部分に対して付加価値を提供したい」というエンジニアとしての気負いと、個人的な関心という 2 つの理由から、寝る時間を削っては脆弱性の悪用（Exploit）手法の習得と、知識的な補強としての資格取得に明け暮れる時期がありました。 結局、寝不足が続いたことが原因で肺炎を発症し、入院一歩前まで炎症マーカーが悪化するという自分自身の脆弱性が露呈することになったのですが。ちゃんと夜は寝ましょう。 話がすこし脱線しましたが、脆弱性診断や SI 案件などは年度末にピークを迎えるものの年間を通じて五月雨で受注することも多く、一定の品質を維持しながらも納期を守るために目の前の案件で必死だったというのが今までの仕事のスタイルでした。 目の前の案件をひたすらこなし、組織に対して「報告書を提出して終わり」の関わり方に対して『これで社会の役に立っているのだろうか』という疑問が生まれたことが、メドレーに入社する転機になっています。 メドレーでのセキュリティエンジニアの仕事 さて、セキュリティサービスを提供する側で案件に追われていた私がメドレーでセキュリティエンジニアとして活動することになっているわけですが、具体的に今なにをしているのか？というと、大きくは以下の 6 つが挙げられます。 自社サービスに対する脆弱性診断 脅威情報や脆弱性情報の収集、周知 全社的な業務プロセス上のリスク調査 全社システムの BCP 整備、保守 ISMS 運用 セキュリティ相談 自社サービスに対する脆弱性診断というのは「脆弱性診断の内製化」で、脆弱性診断を外部の業者にお願いするのではなく自社内で実施して開発にフィードバックする形です。 内製による診断であっても、基本的な流れはすでにご紹介した流れで進めていますが、対象サービスをクロールしてから診断対象を確定させるまでの主要なポイントでは、操作手順に漏れがないかなどの観点で開発からのレビューを挟むようにしています。これは内製であるからこそ実現できているアプローチだと思います。 内製で実施している診断対象一覧の例 なお、ここまで脆弱性診断について書いてきましたが、これは現在の業務のほんの一部で、このほかには ISMS の運用（事務局）としての活動のほか、コーポレート IT メンバーと共に事業継続計画（BCP）整備なども並行して進めなければなりません。とにかく関わる範囲が広く、そして、とても地道な活動です。 ですが、会社全体を俯瞰してセキュリティのことを意識して物事を考え続けられる立場というのはセキュリティ会社では経験できないことで、自社にとっての最適解は何か？を探求し続けることの新たな面白さを見いだすことができています。 セキュリティエンジニアとしての活動内容や役割の違いと気づき、課題 ここまでの内容でお気づきの方もいるかと思いますが、現在の業務は ISMS 運用を初めとしてリスクマネジメントの分野も多く、実務的なバックグラウンドのない業務も出てきています。 システム的なセキュリティに関しても「どうやって悪用できるか…好物の BOF*は無いのか..BOF はどこだ…」という攻撃観点の思考回路のみで判断するのではなく、「どのようなソリューションや仕組み、またはルールでリスク低減できるのか、そして、それをなるべく自動で運用できるようにはどうするか」という守る側にとっての実務的な課題を考えなければなりません。 * バッファオーバーフローのこと このほかに、私が実際に感じているセキュリティエンジニアとしての気づきや考え方の変化を挙げていくと、以下のようなものがあります。 攻撃手法の理解を踏まえ、（社内リソースを鑑みた）現実的に運用しうる対策の仕組みを提案できなければならないことを痛感した 仕組み化やルール化するにも、エンジニアではない従業員の存在を考慮するようになった 脆弱性単体の影響範囲や度合いではなく、システムの利用方法や情報の種類など、社内だからこそ持てる視点を持って評価するようになった 「アップデートしたくてもできない」問題が生じないシステム設計が肝要であることを改めて認識した これらの変化への対応については、すべてソリューションや自動化に対して私の知見がまだまだ不足しているため、これからは「攻撃者目線」の考え方に加えて「ソリューションと自動化」の知見を補完しながら、メドレーのセキュリティ向上に貢献し続けていきたいと考えています。 セキュリティエンジニア募集中！ 最後となりますが、セキュリティエンジニアは関わる業務の幅広さに加え、絶対的な正解が存在しない問題にソリューションを提供することも多い仕事です。 メドレーでの内製による脆弱性診断や全社セキュリティに興味がある方はぜひジョインしてください。いつでもお待ちしています！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp