はじめに はじめまして、コーポレートエンジニアの山下です。 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 年に 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 年 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 以外の医療プラットフォーム事業に関連する新たなプロダクト開発に注力しているため、その話はまたの機会に。 医療プラットフォーム事業に関連するプロダクトをこれからも創出し成長させていく面白い時期にあり、現在デザイナーを積極採用中です。カジュアルに話を聞きたい、医療領域のデザインに興味があるといったデザイナーの方は、ぜひ こちら までご連絡いただけると幸いです。 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

はじめまして。メドレーでセキュリティエンジニアをしている三浦です。 私はメドレーには今年（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

はじめまして。メドレーでセキュリティエンジニアをしている三浦です。 私はメドレーには今年（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

はじめまして。メドレーでセキュリティエンジニアをしている三浦です。 私はメドレーには今年（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 はどこだ…」という攻撃観点の思考回路のみで判断するのではなく、「どのようなソリューションや仕組み、またはルールでリスク低減できるのか、そして、それをなるべく自動で運用できるようにはどうするか」という守る側にとっての実務的な課題を考えなければなりません。 * バッファオーバーフローのこと このほかに、私が実際に感じているセキュリティエンジニアとしての気づきや考え方の変化を挙げていくと、以下のようなものがあります。 攻撃手法の理解を踏まえ、（社内リソースを鑑みた）現実的に運用しうる対策の仕組みを提案できなければならないことを痛感した 仕組み化やルール化するにも、エンジニアではない従業員の存在を考慮するようになった 脆弱性単体の影響範囲や度合いではなく、システムの利用方法や情報の種類など、社内だからこそ持てる視点を持って評価するようになった 「アップデートしたくてもできない」問題が生じないシステム設計が肝要であることを改めて認識した これらの変化への対応については、すべてソリューションや自動化に対して私の知見がまだまだ不足しているため、これからは「攻撃者目線」の考え方に加えて「ソリューションと自動化」の知見を補完しながら、メドレーのセキュリティ向上に貢献し続けていきたいと考えています。 セキュリティエンジニア募集中！ 最後となりますが、セキュリティエンジニアは関わる業務の幅広さに加え、絶対的な正解が存在しない問題にソリューションを提供することも多い仕事です。 メドレーでの内製による脆弱性診断や全社セキュリティに興味がある方はぜひジョインしてください。いつでもお待ちしています！ https://www.medley.jp/jobs/