こんにちは、株式会社 ラク スで横断的にITエンジニアの育成や、技術推進、採用促進などを行っている開発管理課に所属している鈴木( @moomooya )です。 前回はデータを匿名化する際の一般化の例についてお話ししました。 tech-blog.rakus.co.jp 今回は匿名化したデータがどの程度匿名化されているか数値化する方法についてお話ししていこうと思います。 連載目次 『全文検索 〜 Elasticsearchとデータ匿名化手法』 『全文検索の探求 Elasticsearch(1) 』: プロジェクト方針およびElasticsearch概要 大量データを検索するサービスでElasticsearchはRDBの代替候補になりうるか？(Elasticsearch vs pg_bigm)』 データ匿名化 第1回：匿名化された個人情報とは何なのか データ匿名化 第2回：個人情報は匿名化しても意味がないのではないか？ データ匿名化 第3回：個人情報を匿名化するプロセス データ匿名化 第4回：匿名化のために行うデータ項目の一般化とは データ匿名化 第5回：データ匿名化の指標 ←今読んでいる記事 データ匿名化 第6回：実際の匿名化 匿名化指標 匿名化されたデータの特性を表す観点は複数あり、これらを指標としてデータがどの程度匿名化されているかを判断します。 これらのデータ特性はすべてを適用しなければならないものではなく、用途に応じて必要な特性を適用していくことが重要です。なぜならこれらのデータ特性を適用していくことによりデータの匿名性が上がりますが、元のデータからの乖離もまた大きくなるためです。データの匿名性を追求するあまり、利用の要件を満たさなくなってしまうようでは本末転倒です。 そのような中でも、k-匿名性は比較的どんな場合にでも利用出来そうに感じました。l-多様性も多くのケースで適用できそうです。ただし、t-近似性などは用途に応じて検討が必要になるでしょう。 k-匿名性 / k-Anonymity k-匿名性 はもっとも一般的な特性です。すべての準識別子を複合させた値で見た場合に、最低限 k 件のレコードが存在することにより k-1 件を区別することができない状態を指します。 例えば以下のようなデー タセット で考えてみます。 識別子 / Identifying 「名前」 準識別子 / Quasi-identifying 「色」 「種類」 機密属性 / Sensitive 「取引先」 漏洩したくない情報 とします。 匿名化の手順については第3回の記事で説明した通りです。 tech-blog.rakus.co.jp まずは識別子が削除されます。 そして準識別子は全て複合された項目として扱われるので以下のようになります。 注意：実際には「色」と「種類」が1カラムにまとめられるわけではないが理解のためこのように表現しています。 この時、準識別子の値を見ると全レコード異なった値になっています。例えば「緑の野菜」という情報があれば機密属性である取引先は「A商店」と確定してしまいます。他のレコードもこのままでは準識別子が特定された場合に機密属性である取引先が明確になってしまいます。 この状態は k=1 と表現し、 k-1 = 1-1 = 0 件が特定できない状態＝必ず特定できる状態、となります。 k の値を増やすために色の情報を秘匿してみます *1 。 こうなると準識別子で特定できるレコード数は 「果物」「野菜」が 3 レコード 「花」が 2 レコード となり、k の値は最小の値を表現するので k=2 となり、 k-1 = 2-1 = 1 件となるので特定の1件を特定することはどの値をとった場合でもできない状態となりました。 例えば「花」という情報があっても「花」のレコードが2件あるのでどちらが特定したいレコードなのか判断できない状態になっていることを指します。 l-多様性 / l-Diversity しかしながら見ての通り「花」というレコードは2レコードありますが、どちらも機密属性である取引先が「B商事」となっており、レコードは特定できなくとも機密属性の特定はできてしまいます。 これに対応する指標が l-多様性 となります。 l-多様性とは同一の準識別子に対して、機密属性の値が何パターンがあるかという指標になります。 上述の場合、k=2になっているものの、l=1となっているため、機密属性が特定される状態になっています。 このとき、l の値を大きくする方法として 準識別子の一般化を見直す lが小さな項目を秘匿してしまう 通常は一般化の見直しが理想的ですが、問題になっている値のグループが少数の場合には秘匿してしまうのもアリでしょう。 種類が「花」の取引先を秘匿したことで機密属性も特定できなくなりました。種類が「果物」「野菜」の取引先は「A商店」と「B商事」の2種類を含んでいるため l=2 となります。 t-近似性（近接性とも） / t-Closeness l-多様性について準識別子ごとに特定される機密情報を複数にするというアプローチを撮りましたが、デー タセット によってはデータの偏りが発生することがあります。 たとえばデー タセット 全体としては全国の取引先が入っているのに、特定の準識別子には特定地域の取引先しか入っていないなどです。 こういったデー タセット 全体に対するデータの偏りを t 以下にする指標が t-近似性 です。 t の値はデー タセット 全体と、準識別子ごとのサブデー タセット の分布の距離によって定められますが、この分布の距離を測定する方法としては 地球移動距離(EMD: Earth Mover's Distance) という距離尺度で測定するのが一般的なようです。しかし今回の検証ではt-近似性までは必要としなかったため詳細について気になる方は各自ご確認いただければと思います *2 。 その他 上述の他にもk-Map、δ-Presense、δ-Disclosure privacy、β-Likenessなどがあるようですが、これらは調査できていないためキーワードの列挙のみとさせてください。 まとめ 今回は匿名化したデータがどの程度匿名化されているか数値化する方法について触れました。 これらの指標値がどの程度の値になれば適正なのかは第2回で説明したリスクメトリクスの考え方を組み合わせて判断していくことになります。 tech-blog.rakus.co.jp 次回は実際のデータ匿名化を行う流れと、評価に利用したツールについてお話ししたいと思います。 連載目次 『全文検索 〜 Elasticsearchとデータ匿名化手法』 『全文検索の探求 Elasticsearch(1) 』: プロジェクト方針およびElasticsearch概要 大量データを検索するサービスでElasticsearchはRDBの代替候補になりうるか？(Elasticsearch vs pg_bigm)』 データ匿名化 第1回：匿名化された個人情報とは何なのか データ匿名化 第2回：個人情報は匿名化しても意味がないのではないか？ データ匿名化 第3回：個人情報を匿名化するプロセス データ匿名化 第4回：匿名化のために行うデータ項目の一般化とは データ匿名化 第5回：データ匿名化の指標 ←今読んでいる記事 データ匿名化 第6回：実際の匿名化 *1 : 第3回の記事ではなるべく秘匿しないように、と書きましたがここでは説明を簡単にするため秘匿します。 *2 : すごく大雑把にいうと各分布に含まれる要素間の距離を重みを考慮して総和したようなものらしいです。

こんにちは、新卒2年目のmrym_618です。 今回は、 VBA やマクロを使わずに、 Excel で 正規表現 を使って置換する方法についてまとめていきたいと思います。 はじめに エディタを使って置換する方法 最後に はじめに 最近、業務で Excel を 正規表現 を使って置換したいことがありました。 しかし、 Excel の置換機能では、 正規表現 を使うことができませんでした。 VBA やマクロを使えばできそうですが、 VBA やマクロの知識があまりないので少し難しそうだと思っていました。 そこで、もっと簡単に 正規表現 を使える方法について調べてみると、エディタを使うことでできることがわかりましたので、その方法を紹介していきたいと思います。 エディタを使って置換する方法 今回は、 サクラエディタ を使った方法について紹介します。 まず、 Excel をコピーし、 サクラエディタ に貼り付けます。 その後、 サクラエディタ のメニューバーの「検索」→「置換」を選択します。 ここで、「 正規表現 」にチェックを入れ、置換したい文字列を入力します。 最後に、置換した文字列を Excel に貼り付けることで、 Excel の文字列を 正規表現 を使って置換することができます。 最後に 今回は、エディタを使い Excel で 正規表現 を使って置換する方法についてまとめました。 この方法を使うことで、 VBA やマクロの知識がなくても 正規表現 を使って置換することができますので、もし同じことで困っていれば、参考にしてもらえると幸いです。 また、今回は サクラエディタ を使う方法を紹介しましたが、他のエディタでも同様のことができるはずなので、ぜひ試してみてください。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんにちは、株式会社 ラク スで横断的にITエンジニアの育成や、技術推進、採用促進などを行っている開発管理課に所属している鈴木( @moomooya )です。 前回はデータを匿名化していく手順と、匿名化したデータを比較するための情報量の算出についてお話ししました。 tech-blog.rakus.co.jp 今回は匿名化する中で一般化をする際の具体的な値の置き換え方法についてお話ししていこうと思います。 連載目次 『全文検索 〜 Elasticsearchとデータ匿名化手法』 『全文検索の探求 Elasticsearch(1) 』: プロジェクト方針およびElasticsearch概要 大量データを検索するサービスでElasticsearchはRDBの代替候補になりうるか？(Elasticsearch vs pg_bigm)』 データ匿名化 第1回：匿名化された個人情報とは何なのか データ匿名化 第2回：個人情報は匿名化しても意味がないのではないか？ データ匿名化 第3回：個人情報を匿名化するプロセス データ匿名化 第4回：匿名化のために行うデータ項目の一般化とは ←今読んでいる記事 データ匿名化 第5回：データ匿名化の指標 データ匿名化 第6回：実際の匿名化 一般化とは 前回お話させてもらいましたが 一般化 値をグルーピングした値に置き換えることで特定しにくい状態にする 「1989年09月14日生まれ」を「1989年生まれ」にする、など 一般化の前後で情報量を計測し、差分を求めることで失われた情報量を 定量 化する 秘匿してしまうとデータが完全に失われてしまうため、まずは出来るだけ一般化することができないかを検討すると良いでしょう。 ということです。 ただし、一言に一般化と言っても具体的な値の置き換え方は色々あります。また、前回は グルーピングした値に置き換えることで としていましたが、これは一例に過ぎず一般化の範囲はもう少しバリエーションがあります。 それぞれについて見ていきたいと思います。 一般化の方法 一般化の方法は値の種類――日付であったり、数量であったり、自由入力テキストであったり――によって変わってきます。 日付、時刻 日付や時刻を一般化する際には大きく分けて「間隔を維持したい場合」と「間隔を維持する必要がない」ケースに分かれます。 間隔を維持する場合 レコード間の日付や時刻の分布や感覚を維持したい場合は一律n日/n時間ずらすといった固定でスライドする方法があります。 例）3日ずらす 2019/08/29 → 2019/09/02 2019/09/01 → 2019/09/04 ※2日の間隔は維持される 間隔を維持する必要がない場合 間隔を維持する必要がない場合や「だいたい同程度」「平均で同程度」の間隔になればいいケースでは、各レコードに一律の値ではなく -n 〜 +n の範囲でランダムな値でずらす方法があります。 こちらの方がより情報量が低下（＝特定しにくくなる）します。 数量、年齢 数量や年齢についてはデータの分布具合に応じて調整が必要になることがあります。 単純な一般化 [23, 30, 42, 48, 51] を1の位で切り捨てて [20, 30, 40, 40, 50] などとする。いわゆる年齢についての20代、30代というのがこちらです。 基準に応じた一般化 先ほどと同じデータですが、 マーケティング の年齢区分（1: 20～34, 2: 35～49, 3: 50～）などの基準で分ける分け方もあります。 [23, 30, 42, 48, 51] 上記に従うと [1, 1, 2, 2, 3] となります。これに性別(F: 女性, M: 男性)を組み合わせることで マーケティング でよく耳にする「F1層」などとなってきます。こちらも一般化の1例となります。 自由入力テキスト 自由入力のテキスト項目というのは匿名化を考える上で、どんな情報が含まれるのか読みにくいため厄介なものです。 対応としてはあらかじめ定義したルールに従って置き換えを行う ルールベースでの一般化 と統計や 機械学習 を利用する パターンベースの一般化 があります。 それぞれルールベースでは検出漏れが少なく、モデルベースでは誤検出が少ないと言われ、ルールベースで検出した後にモデルベースで検出するのが理想とされています。 今回の取り組みではルールベースでの置き換えを試しました。 今回はElasticsearchの性能検証を行うためのテストデータだったことと、自由入力テキスト項目が特別重要というわけではなかったため、Elasticsearchと同じ 形態素解析 エンジンであるkuromojiを利用して 形態素解析 を行い、名詞の大部分を意味のない文字列（「●●●●」など）に単純に置き換えています。 例） ラクスは新宿にある会社です。 ↓ ●●●●は●●●●にある●●●●です。 まとめ 今回はデータ項目の一般化について具体的な置き換えルールについて触れました。 しかしこれらはほんの1例であり、扱うデータ項目の意味合いに応じて適切な一般化ルールを設定していく必要があります。 次回は実際にデータを置き換えた後のデー タセット が「どの程度匿名化されているのか」を表現する方法についてお話ししたいと思います。 連載目次 『全文検索 〜 Elasticsearchとデータ匿名化手法』 『全文検索の探求 Elasticsearch(1) 』: プロジェクト方針およびElasticsearch概要 大量データを検索するサービスでElasticsearchはRDBの代替候補になりうるか？(Elasticsearch vs pg_bigm)』 データ匿名化 第1回：匿名化された個人情報とは何なのか データ匿名化 第2回：個人情報は匿名化しても意味がないのではないか？ データ匿名化 第3回：個人情報を匿名化するプロセス データ匿名化 第4回：匿名化のために行うデータ項目の一般化とは ←今読んでいる記事 データ匿名化 第5回：データ匿名化の指標 データ匿名化 第6回：実際の匿名化

こんにちは。最近、体型維持の目的で筋トレを始めたbadaikiです。 先日、業務で PostgreSQL のテーブルサイズを調査することがあり、 PostgreSQL の仕様の理解が不足していると実感しました。今回はそのことについて備忘録的に書いていこうと思います。 はじめに PostgreSQLのデータサイズの持ち方 概要 TOASTテーブル 実際に取得してみる システムカタログ 取得手順 おわりに 参考 はじめに 冒頭にも記載しましたが、業務で PostgreSQL のテーブルサイズを調査する機会がありました。テーブルサイズを調査する上で PostgreSQL の仕様について理解したことや、テーブルサイズの調べ方をまとめていきます。 実は過去に資格受験でこの辺りを学習していたのですが、すっかり内容を忘れておりました。 資格学習での知識って実用可能なレベルで理解するのは難しいですね... PostgreSQL のデータサイズの持ち方 概要 PostgreSQL は固定長のページサイズ（通常8kB）を使用し、複数ページにまたがる行（tuple）を許しません。それによって大規模なフィールド値を直接格納することができません。そこでフィールド値を圧縮したり、複数の物理的な行に分割するTOASTと呼ばれる技法を用いたりして大規模なフィールド値を格納しています。 ※なお、TOASTは可変長（varlena）表現を持つデータ型のみサポートしています。 TOASTテーブル ページサイズを超過し物理的に分割された行はTOASTテーブルに格納されます。TOASTテーブルは通常のテーブルを定義するとそのテーブル専用のTOASTテーブルが作成されます。TOASTテーブル名は pg_toast_{対象テーブルのoid} になります。 テーブルリスト TOASTテーブルの構成は以下のようになっています。 名前 型 説明 chunk_id oid 特定のTOAST化された値を識別するOID chunk_seq integer 値の塊に対する連番 chunk_data bytea 塊の実際のデータ そして chunk_data の値が TOAST_TUPLE_TARGET バイト（通常1994Byte）より小さくなるかそれ以上の縮小ができなくなるまで、フィールド値の圧縮や行外への移動を繰り返します。 下のレコードは約150kBのフィールド値をもつテーブルのTOASTテーブルです。 TOASTテーブル 実際に取得してみる システムカタログ テーブルサイズを取得するために登場するシステムカタログを紹介します。その中でも登場するカラムのみ抜粋して説明していきます。 pg_class このカタログは、テーブルとその他に列を持つもの、あるいはテーブルに似た全てのものを列にしています。その中にはインデックス（pg_indexも参照）、シーケンス、ビュー、マテ リアライズ ドビュー、複合型およびTOASTテーブルが含まれます。 名前 型 説明 oid oid 行識別子（隠し属性です。明示的に選択しなければなりません） relname name テーブル、インデックス、ビューなどの名前 relnamespace oid このリレーションを持つ 名前空間 のOID reltoastrelid oid このテーブルに関連しているTOASTテーブルのOID。 何もない場合はゼロです。 TOASTテーブルは"行に収まらない"大きい属性を副テーブルに格納します。 relkind char rは通常のテーブル、iはインデックス、Sはシーケンス、vはビュー、mはマテ リアライズ ドビュー、cは複合型、tはTOASTテーブル、fは外部テーブルを表します。 pg_namespace pg_namespaceカタログは 名前空間 を保存します。 名前空間 は SQL スキーマ の裏にある構造です。それぞれの 名前空間 は、リレーション、型などの集合を、名前が競合することなく、個別に持ちます。 これは pg_class.relnamespace から参照されます。 名前 型 説明 oid oid 行識別子（隠し属性です。明示的に選択しなければなりません） nspname name 名前空間 の名前 取得手順 ① 対象テーブル情報を取得する SELECT pc.oid, relname, reltoastrelid FROM pg_class pc INNER JOIN pg_namespace pn ON relnamespace = pn.oid WHERE nspname IN ( ' public ' , ' pg_catalog ' ) AND relkind IN ( ' r ' , ' S ' , ' i ' ) AND relname = ' ｛対象テーブル名｝ ' ORDER BY relname; 対象テーブル情報取得結果 WHERE句の条件にTOAST要素を追加するとTOASTテーブルも取得できます。 SELECT pc.oid, relname, reltoastrelid FROM pg_class pc INNER JOIN pg_namespace pn ON relnamespace = pn.oid WHERE nspname IN ( ' public ' , ' pg_catalog ' , ' pg_toast ' ) AND relkind IN ( ' r ' , ' S ' , ' i ' , ' t ' ) AND relname = ' pg_toast_16404 ' ORDER BY relname; TOASTテーブルのoid取得結果 ② 対象テーブル中の行の長さを取得する SELECT tuple_len FROM pgstattuple( 16408 ); pgstattuple() 関数を呼び出すにはモジュールを取り込む必要があります。 取り込み方法は↓のサイトに記載されています。 https://www.postgresql.jp/document/9.4/html/contrib.html pgstattuple() 関数の引数はテーブル名でも可能です。 select tuple_len from pgstattuple( ' big_tuple ' ); select tuple_len from pgstattuple( ' pg_toast.pg_toast_16404 ' ); TOASTテーブルは pg_toast というTOAST専用の スキーマ に所属しており、またpg_toastは スキーマ サーチパスに含まれていないので、検索するときは スキーマ 名をテーブル名の前に付けておきます。 ③ （参考）TOASTテーブルの取得 SELECT chunk_id, chunk_seq, chunk_data, OCTET_LENGTH(chunk_data) FROM pg_toast.pg_toast_16404 TOASTテーブル（再掲） おわりに 今回は業務で PostgreSQL のテーブルサイズを調査したことをきっかけに、どのような構成でTOASTが成り立っているのかを更に調べました。1行に大規模なデータが格納されている場合に、どのような仕様で実際どのような形で格納されているのかを確認することができました。 1つの物事に焦点を当て、深掘りする楽しさを経験することができました。 参考 www.bishounen.sakura.ne.jp kaigai.hatenablog.com detail.chiebukuro.yahoo.co.jp エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんにちは、株式会社 ラク スで横断的にITエンジニアの育成や、技術推進、採用促進などを行っている開発管理課に所属している鈴木( @moomooya )です。 前回は匿名化された個人情報において 個人が特定されない とはどういうことなのかについてお話ししました。 tech-blog.rakus.co.jp 今回は匿名化のプロセスについてどういった手順で行うのかをお話ししていこうと思います。 第1回、第2回がこってりした文量になってしまったので今回は軽めに行きたいと思います。 連載目次 『全文検索 〜 Elasticsearchとデータ匿名化手法』 『全文検索の探求 Elasticsearch(1) 』: プロジェクト方針およびElasticsearch概要 大量データを検索するサービスでElasticsearchはRDBの代替候補になりうるか？(Elasticsearch vs pg_bigm)』 データ匿名化 第1回：匿名化された個人情報とは何なのか データ匿名化 第2回：個人情報は匿名化しても意味がないのではないか？ データ匿名化 第3回：個人情報を匿名化するプロセス ←今読んでいる記事 データ匿名化 第4回：匿名化のために行うデータ項目の一般化とは データ匿名化 第5回：データ匿名化の指標 データ匿名化 第6回：実際の匿名化 匿名化の手順 デー タセット を匿名化する場合に以下の手順で進めて行きます。 対象デー タセット 内の識別子と準識別子を定義する 識別子を削除する 準識別子をなるべく秘匿せずに一般化する 検証要件に合わせて一般化の度合いを調整する 平均情報量を計測する それぞれ見て行きましょう。 1. 対象デー タセット 内の識別子と準識別子を定義する まずはデー タセット の各項目を 識別子 と 準識別子 に分けていきます。 識別子 その情報単体で個人を特定できる情報 氏名、社員番号、会員番号、など 準識別子 他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるもの 性別、年齢、 都道 府県、居住ビル、など 2. 識別子を削除する 次に識別子をすべて削除します。削除は非可逆な置き換えを含みます。 3. 準識別子をなるべく秘匿せずに一般化する 秘匿 、 一般化 という言葉が出てきました。 準識別子を匿名化する場合にはこんな方法があります。 秘匿 外れ値などの特定しやすい値を（NULLなどで）上書きする 上書きの単位は項目単位やレコード単位で行う 秘匿されたデータの量は 欠損 としてメトリクス化される 項目単位の欠損は セル欠損 、レコード単位の欠損は レコード欠損 と呼ばれる 一般化 値をグルーピングした値に置き換えることで特定しにくい状態にする 「1989年09月14日生まれ」を「1989年生まれ」にする、など 一般化の前後で情報量を計測し、差分を求めることで失われた情報量を 定量 化する 秘匿してしまうとデータが完全に失われてしまうため、まずは出来るだけ一般化することができないかを検討すると良いでしょう。 サブサンプリング デー タセット のレコード数が必要以上に多い場合は必要なレコード数を抽出（サンプリング）することで、デー タセット のサブセットを作ることも匿名化に有効な手段になります。 サブセットを作ることでデー タセット に含まれているか、含まれていないかという情報を秘匿することができます。 一般化でグルーピングする範囲 一般化でグルーピングする範囲には注意が必要です。 例えば以下のような値の場合に単純に10ごとのグルーピングをすると実質的に一般化されていないことになります。 13才, 27才, 32才, 59才, 61才 ↓ 10代, 20代, 30代, 50代, 60代 このような場合は 0〜39才, 0〜39才, 0〜39才, 40〜79才, 40〜79才 といったようにグルーピングする値域を変えなければなりません。 ただし、大量のレコードを含むデー タセット の場合には各値を見ながらグループの値域を判断するというのは現実的ではありません。Mondrian アルゴリズム *1 というグループの値域をもとめる アルゴリズム があるので、こちらを用いて値域を求めるのが良いでしょう。 4. 検証要件に合わせて一般化の観点や度合いを調整する 一般化は1度行って終わりではありません。 デー タセット の用途に応じて一般化の観点や度合いを調整する必要があります。どういうことかというと、 [リンゴ, レモン, キウイ, ニンジン, レタス, ダイコン, タンポポ, スズラン] というデー タセット を [果物, 果物, 果物, 野菜, 野菜, 野菜, 花, 花] と種類で一般化した場合に、検証したい内容が「種類で絞り込んだ検索性能」だったとしたら、一般化する観点を「種類」以外の観点に変えるべきでしょう。 一般化の観点が変われば情報量も変化することになります。変化した情報量が問題ないかどうかは匿名加工の方法を変更するたびに計測する必要があります。 5. 平均情報量（ エントロピー ）を計測する 平均情報量（ エントロピー ）とは ここまでに何度か「情報量」という表現が出てきていますが、厳密には 平均情報量（ エントロピー ） を扱い、確率の小ささの度合いを示します。 平均情報量の算出方法 例をあげると 赤玉4個、青玉2個、黄玉2個が入った袋から1個を取り出す時の平均情報量を求める時、それぞれの確率は 赤玉の確率 4/8 = 1/2 青玉の確率 2/8 = 1/4 黄玉の確率 2/8 = 1/4 となります。 情報量を求める公式は「 」 *2 で、平均情報量は各場合の総和となります。 ちなみに分数の対数(log)は対数(log)の引き算に直せて、 なので $$ \begin{align} \log_2\frac{1}{\frac{2}{3}} &= \log_2{1} - \log_2{\frac{2}{3}} \\ &= 0 - \log_2{\frac{2}{3}} \\ &= -\log_2{\frac{2}{3}} \end{align} $$ とか $$ \begin{align} \log_2\frac{1}{\frac{1}{2}} &= \log_2{1}-\log_2{\frac{1}{2}} \\ &= \log_2{1} - (\log_2{1} - \log_2{2}) \\ &= 0 - (0 - \log_2{2}) \\ &= \log_2{2} \end{align} $$ と変換できます。 先ほどの確率を公式に当てはめると $$ \begin{align} \log_2\frac{1}{\frac{1}{2}} + \log_2\frac{1}{\frac{1}{4}} + \log_2\frac{1}{\frac{1}{4}} &= \log_2{2} + \log_2{4} + \log_2{4} \\ &= 5 bit \end{align} $$ となります。 今度は色を全て混ぜて（一般化して）灰玉8個から1つを選ぶ場合（当然常に灰玉が選ばれます） $$ \begin{align} \log_2\frac{1}{\frac{8}{8}} &= \log_2\frac{1}{1} &= \log_2{1} \\ &= 0 bit \end{align} $$ となり、情報量は0 bitとなります。この時、一般化によって情報量が5から0に損なわれていると考えます。 なお、情報量が損なわれる＝レコードが特定しにくくなるということなので、匿名加工後の情報量が大きければ大きいほどレコードを特定しやすいという見方ができます。ただし、これは情報量の多寡を比較することができますが、デー タセット 自体の特性によって基準が変わるため「一律で情報量がいくつ以下であれば安全」という使い方はできないので勘違いしないでください。 具体的な例 [リンゴ, レモン, キウイ, ニンジン, レタス, ダイコン, タンポポ, スズラン] といった値がバラバラなデー タセット を「果物」「野菜」「花」と種類により一般化したとします。 [果物, 果物, 果物, 野菜, 野菜, 野菜, 花, 花]と一般化 この時の一般化前の情報量は $$ \begin{align} 8 \times \log_2\frac{1}{\frac{1}{8}} &= 8 \times \log_2{8} \\ &= 24 bit \end{align} $$ 一般化後の情報量は $$ \begin{align} \log_2\frac{1}{\frac{3}{8}} + \log_2\frac{1}{\frac{3}{8}} + \log_2\frac{1}{\frac{1}{4}} &= -\log_2\frac{3}{8} - \log_2\frac{3}{8} + \log_2{4} \\ &= 4.83 bit \end{align} $$ *3 ここで一般化したデータが種類で一般化されたものでは検証に適さなかったため、色で別れるように一般化を見直したとします。 [赤, 赤, 黄, 黄, 緑, 緑, 白, 白]と一般化の観点を変更 その場合の情報量は $$ \begin{align} 4 \times \log_2\frac{1}{\frac{1}{4}} &= 4 \times \log_2{4} \\ &= 8 bit \end{align} $$ となり、種類で一般化したデー タセット （情報量 4.83 bit）よりも情報量が増しています。 情報量が増している、すなわちレコードが特定しやすくなっている ため、 リスクマトリクスを再計測して匿名化度合いが十分かどうか再評価 する必要がある、という考え方をします *4 。 まとめ 今回はデータを匿名化するにあたっての手順と、匿名化したデータの情報量の算出について触れました。 これで異なる匿名化方法を選択したデータ同士を比較することができるようになりました。 次回は一般化の具体的なデータ置き換え例についてお話させていただければと思います。 連載目次 『全文検索 〜 Elasticsearchとデータ匿名化手法』 『全文検索の探求 Elasticsearch(1) 』: プロジェクト方針およびElasticsearch概要 大量データを検索するサービスでElasticsearchはRDBの代替候補になりうるか？(Elasticsearch vs pg_bigm)』 データ匿名化 第1回：匿名化された個人情報とは何なのか データ匿名化 第2回：個人情報は匿名化しても意味がないのではないか？ データ匿名化 第3回：個人情報を匿名化するプロセス ←今読んでいる記事 データ匿名化 第4回：匿名化のために行うデータ項目の一般化とは データ匿名化 第5回：データ匿名化の指標 データ匿名化 第6回：実際の匿名化 MathJax.Hub.Config({ tex2jax: { inlineMath: [["\\(","\\)"] ], displayMath: [ ['$$','$$'], ["\\[","\\]"] ] } }); *1 : 名前の由来は コンポジションシリーズ で有名な画家 ピエト・モンドリアン かと。 *2 : ちなみに対数の底は2に限らないようですが、底が2の場合に単位をbitとするようなので本稿では2を用います。 *3 : 対数の計算は Google 計算機や Excel や 関数電卓 で計算してしまうのが楽です。 *4 : 情報量が増す≠特定されるのでダメ、ではありません。情報量が増した場合にはその情報量が「問題あるのかないのか」を 再測定する必要 があるという考え方をしましょう。

こんにちは。新卒2年目のchoreiiです。 最近は会社所有の書籍を読むのが趣味になってきています。 今回のブログはそんな書籍のうちから ソフトウェアテスト に関する1冊を紹介します。 目次 目次 はじめに ソフトウェアテスト手法 同値クラステスト 境界値テスト ペア構成テスト 最後に 参考 はじめに 今回紹介するのは「はじめて学ぶ ソフトウェアテスト のソフト技法」という書籍になります。 https://www.amazon.co.jp/dp/B00HE8082Q 今まで業務でテストを作成・実施してきましたが、テストの手法などについて意識したことがあまりなく、既存のテスト仕様書に書き方や粒度をあわせて実施することが多かったです。書籍を読むことで、何気なくおこなっていたことが ソフトウェアテスト の手法の一つであることに気づかされたり、その手法を取った際のメリットなどについて体系的に学ぶことができました。 書籍で紹介されているテスト手法を簡単に紹介していきます。 ソフトウェアテスト 手法 ソフトウェアテスト の手法には、大きく分けて ブラックボックステスト の手法と ホワイトボックステスト の手法があります。 ブラックボックステスト 同値クラス テスト（同値分割） 境界値テスト（境界値分析） デシジョンテーブル ペア構成テスト（オールペア法） 状態遷移テスト ドメイン 分析テスト ユースケース テスト ホワイトボックステスト 制御フローテスト データフローテスト 今回は ブラックボックステスト の一部の項目について紹介します。 ちなみに、 デシジョンテーブル については ラク スのエンジニアがすでに解説している記事がありますので、よろしければこちらもご覧ください。 tech-blog.rakus.co.jp 同値クラス テスト 同値クラス テストとは、期待するテスト結果をグループ分けすることでテストを効率的に行う手法です。 例えば以下のような条件のシステムが存在するとします。 バイトの時給区分を決めるシステム 15歳未満は、雇用不可 15歳以上22歳未満は、学生 22歳以上は、一般 この場合、16歳や20歳の期待値はともに「学生」のはずです。今回のように項目が少なければ全ての歳のパターンをテストすることは可能ですが、これが1500〜1800などのグループで同一のテスト結果が期待である場合、全ての数値をテストすることは難しいですし非効率的です。今回の要件ですと、15〜21の数値のいずれかをテストすれだけで、期待値が「学生」のグループが正しく実装されているかどうかのテストは十分であると言えるでしょう。 同値クラス テストという名称を聞いたことがない、または普段意識していなくても何かをチェックする時は無意識のうちにこの手法が使われています。 境界値テスト 境界値テストは上記の 同値クラス テストと関連が深いです。 同値クラス テストが効率的にテストする手法なのに対し、境界値テストは効果的にテストを行う（バグを見つける）手法になります。上記のシステムですと、「雇用不可」と「学生」の境目は15歳になります。システムの設計者・実装者が少し間違えると境目が16歳になってしまうかもしれません。このようにバグは境界値とその周辺におこりやすいと言われています。この境界値を確認することで効果的にバグを発見することができます。 ペア構成テスト ペア構成テストは組み合わせテストの一つです。 入力項目（フォーム）が一つであればパターンもそんなに多くはなりませんが、項目が2つ3つとなっていくと入力のパターンは2乗3乗と膨れ上がっていきます。例えば0〜2が入力できるフォームが4つあるシステムを考えてみます。パターンは3の4乗で81パターンになります。これら全てのパターンをテストするのは難しいです。また、システムの欠陥の傾向として2つまでのパラメータによる欠陥が全体の欠陥の9割を占めるという話があるようです。そのためペア構成テストでは全ての入力項目のうち2つの入力値を抜き出したさいに全てのペアを網羅するようなテストパターンを作成します。 パターン 入力1 入力2 入力3 入力4 1 0 0 0 0 2 0 1 1 1 3 0 2 2 2 4 1 0 2 1 5 1 1 0 2 6 1 2 1 0 7 2 0 1 2 8 2 1 2 0 9 2 2 0 1 上記の表で全てのペアのパターンが網羅されていることがわかると思います。このペアを作るツールとして、 PICT（Pairwise Independent Combinatorial Testing tool） などが存在します。 最後に このブログを見て、 ソフトウェアテスト の手法のさわりを理解して興味を持っていただけたなら、是非とも紹介書籍を読んでみてください。今回紹介したようなテスト手法だけでなく、なぜテストをするのかといったテストの意義などの根本から順序立てて説明されているので本当におすすめです。実際の業務でのテストと照らし合わせながら読んでみると気づきや発見が出てくるので中々面白いです。私自身一通り読みましたがさらっとしか読めていないので、今度はじっくりともう一周読んでいきたいと思います。また他にもいい書籍を読みましたらご紹介できればと思っています。 参考 qiita.com gihyo.jp

こんにちは。2年目のy_kwmtです。業務でESLintに触れる機会があったので、ESLintについてブログにまとめます。 ESLintとは インストール 実行 エラー、警告の種類 最後に 参考 ESLintとは ESLintは JavaScript のための静的検証ツールです。 ファイル内のバグを見つけたり、括弧やスペースの使い方などのスタイルが統一されているかチェックします。 自分で検証ルールを設定することができるので、プロジェクトに合わせたルールを設定することができます。 インストール ESLintはNode8.10.0以降を利用して実行することができます。 Node.js のパッケージ管理ツールnpmを利用してインストールします。 > npm install -g eslint バージョン確認はこちらから実行することができます。 > eslint -v v6.3.0 実行 ESLintを実行するにあたって以下の2つのファイルを用意します。 hello.js function helloWorld(name) { document .body.textContent = "Hello World. " + nama + "!" } helloWorld( "World" ); .eslintrc { " root ": true , // 親階層を見るか否か " parserOptions ": { // サポートするJavaScript言語オプション " ecmaVersion ": 6 // ES6構文 } , " env ": { " browser ": true , // ブラウザのグローバル変数を有効にするか否か " commonjs ": true , // CommonJSグローバル変数とCommonJSスコープを有効にするか否か " node ": true , // nodeのグローバル変数とnode特有のルールを有効にするか否か " mocha ": true // mochaのグローバル変数を有効にするか否か } , " extends ": [ " eslint:recommended " ] , " rules ": { " array-bracket-spacing ": [ " warn ", " never " ] , // 配列内の括弧の間隔 " arrow-body-style ": [ " warn ", " as-needed " ] , // 矢印関数本体の周りの波括弧の使用 " arrow-parens ": [ " warn ", " as-needed " ] , // アロー関数の括弧の一貫した使用 " arrow-spacing ": " warn ", // アロー関数の矢印の後か前かにスペースを要求するか " brace-style ": [ " warn ", " 1tbs " ] , // ブレーススタイルを適用 " camelcase ": " warn ", // キャメルケース " comma-spacing ": [ " warn ", { " after ": true }] , // カンマ前後のスペース " dot-notation ": " warn ", // ドット表記スタイルの使用の奨励 " eqeqeq ": [ " warn ", " smart " ] , // 型安全でない等価演算子を排除 " indent ": [ " warn ", 2 , { // インデント " SwitchCase ": 1 , // ネストの深さ " FunctionDeclaration ": { " parameters ": 1 } , // 関数宣言のパラメータのインデントレベル " MemberExpression ": 1 , // 複数行のプロパティチェーンのインデントレベル " CallExpression ": { " arguments ": 1 } // 関数呼び出し式の引数のインデントレベル }] , " key-spacing ": [ " warn ", { " beforeColon ": false , " afterColon ": true , " mode ": " minimum " }] , // オブジェクトリテラル・プロパティのキーと値の間の間隔を強制 " keyword-spacing ": " warn ", // キーワードとキーワードの間隔 " no-console ": " off ", // consoleを許可しない " no-empty ": " off ", // 空のブロックステートメントを許可しない " no-multi-spaces ": " warn ", // キーワード間の2つ以上のスペースを許可しない " no-redeclare ": " off ", // 複数回同じ変数を宣言許可しない " no-restricted-globals ": [ " warn ", " Promise " ] , // 指定したグローバル変数を利用しない " no-trailing-spaces ": " warn ", // 行の末尾に空白を入れない " no-undef ": " error ", // 宣言していない変数を使用しない " no-unused-vars ": [ " warn ", { " args ": " none " }] , // 利用していない変数を警告 " one-var ": [ " warn ", " never " ] , // ブロックスコープ内では1度の宣言で必要な変数宣言を行う " padded-blocks ": [ " warn ", " never " ] , // ブロック内のパディングを強制 " object-curly-spacing ": [ " warn ", " never " ] , // 1行でオブジェクト定義する際、波括弧の前後に空白を入れない " quotes ": [ " warn ", " single " ] , // クォート " react/prop-types ": " off ", // propsの値に対してPropTypesを指定していない場合に警告 " react/jsx-no-bind ": " off ", // jsx内でのbindを禁止する " semi ": [ " warn ", " always " ] , // ASIのセミコロンの使用を許可するか否か " space-before-blocks ": [ " warn ", " always " ] , // ブロック前のスペースを許可しないかするか否か " space-before-function-paren ": [ " warn ", " never " ] , // 関数の括弧の前にスペースを許可するか否か " space-in-parens ": [ " warn ", " never " ] , // 括弧内のスペースを許可するか " strict ": [ " warn ", " global " ] // use strict を記述すること } } こちらの.eslintrcのrulesにコーディングのルールを追加、削除することができます。 サンプルコードhello.jsに対して次のコマンドを実行します。 > eslint hello.js(ファイル名) eslintコマンドを実行すると次のような結果が得られます。 合計で7つのエラーが発生しています。左から順に行番号と位置、警告かエラーか、警告とエラーの種類、.eslintrcに追加されているルール名が表示されています。 エラー、警告の種類 Use the global form of 'use strict' 'use strict'を省略しているので、警告が発生しています。 警告を出さないようにするにはファイルの先頭に'use strict'を追記してください。 こちらは「"strict": ["warn", "global"]」でルールを設定、解除できます。 Expected indentation of 2 spaces but found 4 インデントでスペース2個分開ける必要があるのに4個分開けているので警告が発生しています。 警告を出さないようにするにはインデントを修正してください。 こちらは「indent」でルールを設定、解除できます。 Strings must use singlequote シングルクォートを使用しなければいけないが、ダブルクォートを使用しているので、警告が発生しています。 警告を出さないようにするにはシングルクォートを使用してください。 こちらは「"quotes": ["warn", "single"]」でルールを設定、解除できます。 nama is not defined 「nama」という変数が定義されていないと怒られています。 エラーを出さないようにするにはnamaという変数を定義するか、削除してください。 こちらは「"no-undef": "error"」でルールを設定できます。 Missing semicolon 行末に セミ コロンがないので、警告が発生しています。 警告を出さないようにするには セミ コロンを追加してください。 こちらは「 "semi": ["warn", "always"]」でルールを設定、解除できます。 発生した7つの警告、エラーの修正を行い、再度eslintコマンドを実行して問題なければ、何も表示されません。 最後に ESLintで発生した警告の改修を業務で行ったことをきっかけに、ブログにESLintについてまとめました。 JavaScript のコーディングを行う方々の参考になればと思います。 コードを変更する際、コードが読みづらいと理解、変更に時間がかかってしまうので、 他の開発者に迷惑をかけないよう、設定されているコード規約を守り、読みやすいコードを書くことを心掛けていきます。 参考 qiita.com eslint.org エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

私の所属する開発チームで行ったモブプログラミングの様子についてご紹介します。 これからモブプログラミングしようかと考えているが、 ハードル高いなぁと感じているチームリーダーの方 チームに対してモブプログラミグを提案したいと思っているいちメンバーの方   こんな方に一読いただいて、文字だらけで恐縮ですが、イメージが湧いて参考になると幸いです。 きっかけ 巷で噂のモブプログラミング＝通称モブプロ お隣の開発チームがやっていて、うちのチームもやらないといけない空気感に腹をくくる所から始まりました。 きっかけがやや不純ですが、チーム内で商材の知識と商材の実装経験の差が課題だった(商材特有の癖とか)のもありました。 モブプロをチームで体験してみるという目的をもち、巷でメリットと言われてることは本当なのか、身をもって確かめてみることにしました。 準備 やるからには、生半可なことをしてはいけません。 何事も準備で9割は決まると言われています。お隣のチームがモブプロを行った時の反省点や、いくつかモブプロに関するブログを読んで準備をしました。 参考までに https://takaking22.com/2018/mob-advent/ https://qiita.com/TAKAKING22/items/31e027dfb6ea8b1a8d69 https://speakerdeck.com/oohira/why-mob-programming 準備内容 モブプロやります！！宣言 チームメンバーに対して、そして周りに対して。言った以上、やらないわけにはいきません。 モブプロの素材を用意   メリットと言われてる、 暗黙知 の共有や実装しながらコードレビューが出来るなど、すぐに活かせそうということで、通常の機能開発で試すことにした。 例えモブプロがうまくいかなくても、メンバーとその機能の関連するコードについて試行錯誤したことは無駄にはならないだろうという考え。 使い捨て出来るようにあらかじめモブプロ用のbranchを用意しておく。細かい所ですが、お隣のチームの反省点より。   機能のどの部分を作るかを決めておく 　初回は難しい箇所を選ばないことがベター。処理フロー図とかがあればより初回のハードルが下がる。 初回の役割を決めておく 　ドライバー、ナビゲーター、 ファシリテーター （タイムキーパー） ナビゲータの調査用PCを用意 ドライバーのみPCというパターンが多いが、各自好きなタイミングでコードの調査ができるようにあえて用意 ディスプレイがあるもしくはプロジェクターを使える会議室 2時間予約（1時間半はモブプロ、残りの30分は振り返り） Let's モブプロ 開始ものの数分後、やるべき事の認識を合わせてる途中に仕様の曖昧な部分が発覚。 少し考え始めましたが、他部署との調整が必要なことがわかったので、曖昧な部分はモブプロ後に確認し、確実に仕様が決まっている箇所から実装を進めることにしました。 気づけば20分経過。。。 まだ1行もコードを書いていない。 これは、、まずい、そんな空気になりました。 「ここで課題見つかって良かったよね～」 とポジティブな発言で乗り切れるチームでよかったです。 最初こそロスはしたものの、その後気づけば1時間経過。 目的としていた箇所の大枠は実装し終え、挙動の確認ができている状態に。 最初の20分が嘘のようで、アウトプットを出すことができた。 ＜その1時間のまとめ＞ 機能の過去の経緯や背景 共通メソッドの選び方のレクチャー、考え方、 暗黙知 の共有 どういうロジックにするのか、各々案を出す こんなことを話しながら、気づいたら全員で楽しんでいました。普段、個々でもくもくと実装していると決してできない体験ができた。 初回のモブプロを終えて どうやら、巷での噂はホントっぽい。 ＜よかったこと・気づき＞ 暗黙知 の共有はできる 他の人がどの様に考えているかの勉強になった（ベテランのエンジニア同士のモブプロをしたため） 特にエラーの切り分け方とか、若手のメンバーに見せたい内容だった 1人で悩まずに済む 慣れたり、題材によってはコードレビューまで出来そうという前向きな感想も出た 実際にやってみてモブプロに対する不安感、抵抗感が一気にさがった（メンバーも私自身も） またモブプロやりたいと思える会だった 意見交換ができて、充実していた ドライバーは変えなかったが、その場の状況次第で決めればいいと思った 絶対にこうしなければならないということに縛られない方がよい 目的が達成できるなら手段は 臨機応変 に 参考ブログをみると、ナビゲーターの発言の仕方の注意点があったりしたが、そこに困ることはなかった チームで協力する際のメンバーの一面を見ることができた、人の意見に耳を傾けること、無下に案を却下したりしない相手に対してのリスペクト、気遣いができる所を改めていいなぁと思いました 初回に難しい箇所を選ばなかったのは吉 ドライバー（役割）を強要しない(初回は止むを得ず強要しました、ごめんなさい。一度体験すると抵抗はなくなってました) ＜課題感＞ 点でみるとコストをかけすぎな様に見える 手戻りでやり直すコストを抑えられるなら初期投資としてトータルで元はとれるのでは 準備する負担はややかかる 今回1人でやった準備をメンバーで分担すれば負担は軽減できる。が、現状では定期開催、週1回とかは現実的ではない ドライバーは普段使い慣れてないノートPCでやや使いにくかった   ＜今後の展望＞ レビューまで終わらせたい 若手を巻き込んでやってみたい 定期開催したい   まとめ 新しい取り組みを実際に 「やってみる」 、踏み出す一歩は勇気が要りますが、ダメでもともとと思えば(とはいえ、本気で成功させるための準備を決して怠ってはなりません)、 チャレンジすることのハードルは下がるのかもしれません。もちろん、良い面ばかりでもなく課題があるのは事実なので、濁すことも、隠すこともしていません。 その上で一度、騙されたと思ってモブプロをご賞味ください。 得られるものがあると思います。 追伸 先日、今後の展望の レビューまで終わらせたい 若手を巻き込んでやってみたい この2点にチャレンジしてみました。 レビューはなかなか遠いですが、難易度をあげても 何をやるか。 を明確にして準備をしていれば実装の大枠はアウトプットできることがわかりました。 若手(新卒2年目)を2人巻き込んで参加してもらい、 ツールの使い方 1人で悩まなくてもいい 気をつけるべきことをその場で共有できる この辺りにモブプロの良さを感じてくれていました。

初めまして、pbtnhanです。 ラク ス ベトナム から日本へ出向中の ベトナム人 です。はいくる通信の第3回を担当させていただきます。  第3回では、お客様の マーケティング の方法に合わせて選べるメールの配信方法と私たち開発者が意識している多彩な状態変化についてご紹介します。 メールマーケティングの配信の種類 グループ配信 ステップメール配信 A/Bテスト配信 スポットメール配信 トリガーメール配信 メールマーケティングを支える多彩な状態変化 配信の種類ごとに異なる状態変化 配信先ごとの状態変化 開発の特徴 複雑さを受け入れた開発 まとめ お知らせ メール マーケティング の配信の種類 配配メールにはメール マーケティング に合わせた複数の配信方法があります。その種類をそれぞれご紹介します。 グループ配信 ステップメール配信 A/Bテスト配信 スポットメール配信 更に、秋にリリースする予定のトリガーメール配信も少し紹介します。 グループ配信 マーケティング のキャンペーンによって、年齢や性別など、自由な条件でグループを作成できます。それから効果の高いメールを作成して、一斉配信することができます。 配信完了が終わりではなく、顧客の反応効果を測定できる仕組みもあります。メールを 開封 した顧客一覧、リンククリックした顧客一覧等に対して、更に別のメールを配信して継続的な マーケティング を行うことができます。 自由な条件でグループを作成して、メールを一斉配信することができます。 ステップメール配信 お客様のタイミング（メルマガ登録日、誕生日など）を起点として、あらかじめ用意しておいたメールコンテンツを決められたシナリオの通りに自動的に個別メール配信します。 顧客のタイミングで複数ステップで個別メール配信することができます。 A/Bテスト配信 A/Bテストとは、Web マーケティング におけるCRO（Conversion Rate Optimization）の手法の一つです。A/Bテストの目的を簡単に言うと「CVR（コンバージョン率）とCTR（クリック率）」の向上です。 グループメールと同様に一斉配信しますが、２つのメールパターンを用意して、テスト配信率やテスト期間（効果測定期間と呼びます）を指定し、２つのメールパターンを同時に配信します。効果測定期間が終わった時点でお客様反応率が高いメールパターンを自動的に残りの配信リストに配信します。 A/Bテストの配信流れ。画像：hai2mail.jp スポットメール配信 「休業のお知らせ」や「メンテナンスの告知」など、緊急性を要し、且つ全員に送るメールなどのように、一回だけ配信できればいいというときに利用できます。 トリガーメール配信 トリガーメール配信は、秋にリリースする予定の新しいメール マーケティング のメール配信方法です。 マーケティング 業界に最近、MA（ マーケティング ・オートメーション）が流行しています。その中にホット・リード（Hot leads）やコールド・リード（Cold leads）の概念があります。例えば、もし自社のWebサイトに来訪したら、ホット・リードと扱って事前に用意された マーケティング メールを自動的に配信できます。詳しい内容は別の機会でご紹介します。 メール マーケティング を支える多彩な状態変化 配配メールはメール マーケティング のサービスなので配信の状態を細かく管理しています。 配信の種類ごとに異なる状態変化  配信の状態は上記でご紹介した配信の種類によって異なっています。例えばグループメール配信とA/Bテスト配信では次のように状態変化の違いがあります。 グループ配信 「一時保存中」、「配信待ち」、「承認待ち」、「配信中」、「配信停止中」、「配信完了」、「キャンセル」 A/Bテスト配信 「一時保存中」、「配信待ち」、「AB配信中」、「効果測定中」、「Win配信中」、「配信完了」、「キャンセル」 グループ配信のメール状態 配信先ごとの状態変化 配信先のメールアドレスごとの状態も変化します。例えば、配信先のユーザーがメルマガ解除を行った時は「配信停止」になります。この時、システム内の自動同期の仕組みによって、所属している配信グループやステップメールの全てのメールの配信が配信停止になります。既に配信中のメールや配信予定のメールからも除外されます。 配信先状態 開発の特徴 新しい機能を開発したり、実際にメールを配信してテストする時には上記のような多彩な状態変化を理解しておく必要があります。 複雑さを受け入れた開発 私たち開発者にとって、上記のような多彩な状態変化を実現するためには設計が複雑になります。また、配信のテストで状態変化を確認するのも大変です。しかし、お客様が適切なタイミングで配信を行い効果的なメール マーケティング を実現するためには必要なしくみと考えて、この複雑さを受け入れて開発しています。 状態変化のしくみの複雑さを受け入れたうえで、設計の見落としやテスト配信のミスが起きないようにチェックシートなどのドキュメントを整理して活用しています。また、あらかじめ配信状態のテストデータを準備しておき、データの作成を自動化するなどの改善も進めています。秋にリリースする予定のトリガーメール配信もこれらの状態変化のしくみを考慮して開発を進めました。 まとめ メール マーケティング の方法はまだまだ進化しています。配配メールでの配信の種類や関係する機能は今後もどんどん増えていくと思います。 今回はメール マーケティング を支える配信の種類をテーマにして、多彩な状態変化とそのしくみを実現している開発の特徴についてご紹介いたしました。次回もどうぞお楽しみに！ お知らせ 9/18に大阪オフィスでMeetupが開催されます。今回のテーマは『 カイゼン Night 運用トラブル編』です。私は配信したメールのアクセス数やクリック数が急増したトラブルの カイゼン 事例について発表する予定です。よろしければ是非ご参加ください。 rakus.connpass.com

こんにちは、株式会社 ラク スで横断的にITエンジニアの育成や、技術推進、採用促進などを行っている開発管理課に所属している鈴木( @moomooya )です。 前回は個人情報の匿名化とはどういうことなのかについてお話ししました。 tech-blog.rakus.co.jp 今回は個人情報の匿名加工についてどういった状態になっていれば良いのかをお話ししていこうと思います。 連載目次 『全文検索 〜 Elasticsearchとデータ匿名化手法』 『全文検索の探求 Elasticsearch(1) 』: プロジェクト方針およびElasticsearch概要 大量データを検索するサービスでElasticsearchはRDBの代替候補になりうるか？(Elasticsearch vs pg_bigm)』 データ匿名化 第1回：匿名化された個人情報とは何なのか データ匿名化 第2回：個人情報は匿名化しても意味がないのではないか？ ←今読んでいる記事 データ匿名化 第3回：個人情報を匿名化するプロセス データ匿名化 第4回：匿名化のために行うデータ項目の一般化とは データ匿名化 第5回：データ匿名化の指標 データ匿名化 第6回：実際の匿名化 本人が特定できないとは 個人情報が含まれるデー タセット の中からある個人のレコードが特定できない状態であることを「本人が特定できない」とするようです。 なので前回 他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む 氏名など単体で特定できるものに限らず、組み合わせによって特定できる情報も含まれるということです。例えば「〇〇交番の隣に住んでいる」「おじいさん」という組み合わせは「〇〇交番の周囲の住居（住所の範囲）」だけや「おじいさん（性別と年齢の範囲）」だけでは個人を特定できなくても2つの情報が組み合わさったときに特定できる場合はこれも個人情報として扱われることになります（単体で個人を識別できる識別子に対して準識別子と呼ばれる）。 という説明で出てきた 識別子 と 準識別子 ですが、識別子については単体で個人のレコードを特定してしまうため、全て「削除」しなければなりません。なおここでいう「削除」は 当該一部の記述等を復元することのできる規則性を有しない方法により他の記述等に置き換えることを含む。 非可逆な情報で置き換えることでも「削除」として扱われるようです。 と前回説明した通り、 非可逆な方法で置き換えた場合 が含まれます。 問題は上記で説明されている準識別子の扱いです。 準識別子は組み合わせる情報によって2つの観点から見る 準識別子は他の情報と組み合わせて特定できてしまう情報ですが、2段階に分けて考える必要があります。1つは「デー タセット 内の別の情報との照合」、もう1つは「デー タセット 外の情報との照合」です。 デー タセット 内の別の情報との照合 まずは考えやすいデー タセット 内の情報との照合について考えていきます。 住所 年齢 性別 とあった場合、それぞれ 住所：「〇〇町●丁目交番隣」 年齢：80 性別：男性 とあった場合、それぞれの情報ではレコードの特定はされなかったとしても3つの情報を照合して得られるレコードは以下の図のようにAND集合となって絞り込まれます。 複数の準識別子を照合して得られるレコード 照合して求められるレコードが絞り込まれた結果、個人を特定できるような状態だと「匿名化されたデー タセット ではない」という判断がされてしまいます。 この図では準識別子が3つしかない図なので絞り込まれているといってもそれほど影響がなさそうに見えるかもしれませんが、準識別子が2, 3項目で済むということは現実にはあまりないのではないかと思います。 実際のサービスにおいてデー タセット 中の総項目数は100項目以上になることは珍しくないでしょうし、準識別子も数十項目ほどあると考えた方が現実的です。照合される準識別子が増えるとどんどんAND演算が繰り返されて絞り込まれていってしまいます。 たくさんの準識別子が照合されて求められるレコードが絞り込まれている たくさんの準識別子の照合によって絞り込まれるレコードを把握するのは容易ではなく、人力で把握し匿名化されているかどうかを判断するのは困難です。 なのでリスク解析ツールを用いて匿名化の度合いを判定させることをおすすめします。 リスク解析ツールの紹介と使い方については改めて別の記事に紹介しようと思いますが、今回の検証では ARX というツールを利用しました *1 。 デー タセット 外の情報との照合 次にデー タセット 外の情報との照合ですが、そもそも「デー タセット 外の情報」とはどのようなものがあるか紹介します。 人口データ 統計情報 ダンバー数 のような 認知心理学 的な指標値 これらの情報の組み合わせ など これらがどのように影響するかというと、例えば「特定の地域において男性の70%以上が60歳以上である」という統計情報があった場合、デー タセット 内に住所と性別の情報があった場合に年齢が秘匿されていたとしても60歳以上であることが70%の精度で特定できてしまいます。 「70%の精度で特定できる」とは？ 先ほど 年齢が秘匿されていたとしても60歳以上であることが70%の精度で特定できてしまいます。 とお話ししましたが「70%の精度で特定できる」というのはどういうことなのかわかりにくいですよね。「精度が70%なら結構高いし特定できるということなんじゃないか？」「30%は特定できないのだから特定できないのではないか？」など色々意見が出そうですが、これはどちらも間違ってはいませんがどちらも不正確です。 100%の精度で特定できるか、100%特定できない（＝0%の精度）のであれば判断は簡単ですが、基本的には0〜100%の間のどこかになると思います。タイトルのように「100%特定できないようにしないと 意味がないんじゃないか？ 」と思う方もいるかもしれませんが「デー タセット の中に含まれている *2 」という外部情報があるだけでどんなに情報を加工しても の精度で特定可能 *3 なので100%を基準にするのは非現実的です。 本人が特定できるかどうかとは出来る(100%)と出来ない(0%)に二分されるものではなく、どの程度の精度で特定されるのか、また「特定されない」とする場合はどの程度の精度までを許容するのかという話になります。 様々なリスクメトリクス 本人がどの程度特定されるのかという指標値をリスクメトリクスと言います。このリスクメトリクは1つの値ではなく、それぞれのデー タセット に応じて複数の状況を想定して複合的に評価を行います。 データ匿名化手法 ―ヘルスデータ事例に学ぶ個人情報保護 作者: Khaled El Emam , Luk Arbuckle 発売日: 2015/05/23 メディア: 単行本（ソフトカバー） 『データ匿名化手法』のp.48 で挙げられている例だとT1, T2, T3, T4として4つの状況を想定していて T1: データ利用者が故意に再特定する場合 T2: データ利用者が故意ではなく再特定する場合 T3: データが外部に漏れてしまう場合 T4: 攻撃者がデモンストレーション攻撃（どれか1レコードでも再特定できればよい）を行う場合 という状況が挙げられています。 これらはT1〜T3の特定の個人を特定する場合と、T4の誰でもいいから特定する場合で分かれ、それぞれ平均リスクと最大リスクが指標として使われます。 リスクメトリクスの計算 T2とT4を例に具体的な算出方法について紹介します。 T2: データ利用者が故意ではなく再特定する場合 「故意ではない」とはたまたま知り合いのデータに触れることで気づいてしまうケース。 状況として以下を前提とします。 データ利用者の知り合いは 150 人（＝ ダンバー数 *4 ） たまたま知り合いがデー タセット に含まれる確率 0.1% (0.001) と仮定 平均リスク（平均再特定確率）は以下条件の場合だと 0.25 となる 準識別子がすべて同じ値となるレコード数の平均（ 平均同値類数 ）が 4 値の違いによって4件まで絞り込めるという状況 再特定確率は平均同値類数の逆数をとって この場合T2のリスクメトリクスは以下のように計算されます。 T4.攻撃者がデモンストレーション攻撃（どれか1レコードでも再特定できればよい）を行う場合 デモンストレーション攻撃とは攻撃者が再特定可能であることを示すための攻撃。もっとも特定しやすいレコードが1レコードでも特定できればよい。 非特定化したデータを公開データとする場合に考慮するメトリクス。 最大リスク（最大再特定確率）は以下条件の場合だと 0.33 となる 攻撃者はかならず攻撃するため攻撃する確率は 100%(1.0) 準識別子がすべて同じ値となるレコード数の最小値（ 最小同値類数 ）が 3 再特定確率は最小同値類数の逆数をとって この場合T4のリスクメトリクスは以下のように計算されます。 どのくらいの値にすれば良いのか 同著によるとリスクメトリクスは以下が目安とのことですが、実際には匿名化したデータを検証して適切な値を目指すべきだと思います。 リスクメトリクス目安 平均リスクを用いる 0.1 〜 0.05以下 最大リスクを用いる 0.09 〜 0.05以下 ちなみにT2, T4の場合だと、T2は平均リスクを用いる状況なので 0.0375 と 閾値 以下で問題なし、T4は最大リスクを用いる状況ですが 0.33 と 閾値 を超えておりデータの見直しが必要と判断できます。 まとめ 今回は匿名化で個人の特定が出来なくなるのかどうか、またどういう状態を目指すのか、それをどのように計測するのかをお話ししました。 「デー タセット がどの程度匿名化されているのか」を数値化し、比較できなければできているのかどうかは判断できないのでリスクメトリクスの算出は匿名化データについて必須となります。 次回は個人情報を匿名化していくにあたってどのような手順で進めていくのかをお話ししたいと思います。 連載目次 『全文検索 〜 Elasticsearchとデータ匿名化手法』 『全文検索の探求 Elasticsearch(1) 』: プロジェクト方針およびElasticsearch概要 大量データを検索するサービスでElasticsearchはRDBの代替候補になりうるか？(Elasticsearch vs pg_bigm)』 データ匿名化 第1回：匿名化された個人情報とは何なのか データ匿名化 第2回：個人情報は匿名化しても意味がないのではないか？ ←今読んでいる記事 データ匿名化 第3回：個人情報を匿名化するプロセス データ匿名化 第4回：匿名化のために行うデータ項目の一般化とは データ匿名化 第5回：データ匿名化の指標 データ匿名化 第6回：実際の匿名化 *1 : 当初 GCP のData Loss Prevention API : Cloud DLP を利用しようとしていましたが、データの検査は実施できるもののリスク解析がうまく動作させれなかったため断念しました。 *2 : 例えば「〇〇社は△△社の顧客である」という情報など。 *3 : 例えば1万レコードの場合だと、無作為に（当てずっぽうで）選んでも1万分の1の精度で特定できてしまう。 *4 : 個人が良好な関係を維持できるとされる最大人数

こんにちは 楽楽明細開発課の sts -250rrです。 先日Postgres11の入った検証環境に、現在運用中の環境のデータを移行して検証したいという機会がありました。 何点か意外とあるんじゃないかなというポイントがありましたので、Try&Errorの内容をまとめておこうと思います。 ※本記事内でのコマンドはDockerコンテナで作業をイメージしたコマンドを実施しています。 やったこと Try&Error：データベースクラスタをバージョンアップする Try：pg_upgradeはどう使ってやればよいのか ERROR：存在しないPostgres9.4 Try：pg_upgradeで11にバージョンアップ ERROR：postgresユーザで実行しなければならない まとめ やったこと ポイント・イン・タイム・リカバリ (PITR) の方法でデータベース クラスタ (/var/lib/pgsql/data)と アーカイブ ログ(/var/lib/pgsql/data/pg_xlog/)を使って、検証環境にリストアして復元をしようとしました。 ところですっかり忘れていたのですが、現在運用中のデータベースはPostgres9.4なのです。 PostgreSQL はメジャーバージョン間ではデータベース クラスタ の互換性がないため、Postgres11のサーバを起動しようとした時にバージョン不一致でエラーになります。 [root@12d698375565 ~]# service postgresql-11 start An old version of the database format was found. You need to upgrade the data format before using PostgreSQL. See (Your System's documentation directory)/postgresql-11.5/README.rpm-dist for more information. [root@12d698375565 ~]# ここからTry&Errorのスタートです。 Try&Error：データベース クラスタ をバージョンアップする 上述の通りエラーの内容は明白で、移行元と移行先のデータベースのバージョンが不一致であるため、 データベース クラスタ をバージョンアップすれば良いというわけです。 いくつか方法があるようですが、 pg_upgrade でやると簡単そうということまでわかりました。 ただ用語としてpg_upgradeと聞いたことがあっても使ったことはありませんでした。 Tryしていきます。 Try：pg_upgradeはどう使ってやればよいのか 困った時は 公式のドキュメント を確認です。 実行コマンドはこんな感じ pg_upgrade -b oldbindir -B newbindir -d olddatadir -D newdatadir [option...] どうやらpg_upgradeを使うためには移行元と移行先のPostgresのインストール ディレクト リと/dataの ディレクト リが必要なようです。 検証環境側に必要なものはそろっているのでしょうか？ [root@12d698375565 ~]# ls /usr/pgsql-9.4 ls: cannot access /usr/pgsql-9.4: No such file or directory [root@12d698375565 ~]# ・・・・。 ERROR：存在しないPostgres9.4 速やかにインストールします。 （Postgresインストールの詳細については割愛します。） [root@12d698375565 ~]# yum -y install postgresql94-server ・・・ Complete! [root@12d698375565 ~]# service postgresql-9.4 initdb Initializing database: [ OK ] [root@12d698375565 ~]# 念の為、運用中のデータを移行して、9.4の状態でDBを確認しておきます。 [root@12d698375565 ~]# service postgresql-9.4 start Starting postgresql-9.4 service: [ OK ] [root@12d698375565 ~]# su - postgres -bash-4.1$ psql -l List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges -----------+----------+----------+-------------+-------------+----------------------- pg94 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres + | | | | | postgres=CTc/postgres template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres + | | | | | postgres=CTc/postgres (4 rows) -bash-4.1$ 9.4の状態で起動でき、中身も確認できました。 改めて、pg_upgradeに必要な資材があるかを確認して、 [root@12d698375565 ~]# ls /usr/pgsql-9.4 bin lib share [root@12d698375565 ~]# ls /var/lib/pgsql/9.4/data base pg_hba.conf pg_multixact pg_snapshots pg_tblspc postgresql.auto.conf global pg_ident.conf pg_notify pg_stat pg_twophase postgresql.conf pg_clog pg_log pg_replslot pg_stat_tmp PG_VERSION pg_dynshmem pg_logical pg_serial pg_subtrans pg_xlog [root@12d698375565 ~]# ls /usr/pgsql-11 bin lib share [root@12d698375565 ~]# ls /var/lib/pgsql/11/data base pg_hba.conf pg_serial pg_twophase postmaster.opts current_logfiles pg_ident.conf pg_snapshots PG_VERSION postmaster.pid global pg_logical pg_stat pg_wal log pg_multixact pg_stat_tmp pg_xact pg_commit_ts pg_notify pg_subtrans postgresql.auto.conf pg_dynshmem pg_replslot pg_tblspc postgresql.conf [root@12d698375565 ~]# 準備完了です。 Try：pg_upgradeで11にバージョンアップ 満を辞してpg_upgradeを実行していきたいところですが、ドキュメントを見るといくつか下準備が必要なようです。 新しい PostgreSQL クラスタ を初期化 11側のdataが更新されていると移行に失敗してしまいます。initdbで初期化しておきます。 認証の調整 pg_upgradeは古いサーバと新しいサーバに複数回接続するためパスを要求されることがあるようです。 pg_hba.confを適切に設定しときましょう。（今回はtrustにしています。） 両サーバの停止 停止します。 [root@12d698375565 ~]# service postgresql-9.4 stop Stopping postgresql-9.4 service: [ OK ] [root@12d698375565 ~]# service postgresql-11 stop Stopping postgresql-11 service: [ OK ] [root@12d698375565 ~]# 下準備も完了です。 11のpg_upgradeコマンドでいざ実行。 [root@12d698375565 ~]# /usr/pgsql-11/bin/pg_upgrade pg_upgrade -b /usr/pgsql-9.4/bin/ -B /usr/pgsql-11/bin/ -d /var/lib/pgsql/9.4/data/ -D /var/lib/pgsql/11/data/ pg_upgrade: cannot be run as root Failure, exiting [root@12d698375565 ~]# ERROR：postgresユーザで実行しなければならない rootでは実行できませんでした。。。 （ドキュメントにしっかり書いてありました） 気を取り直してpostgresユーザで実行。 [root@12d698375565 ~]# su - postgres -bash-4.1$ /usr/pgsql-11/bin/pg_upgrade pg_upgrade -b /usr/pgsql-9.4/bin/ -B /usr/pgsql-11/bin/ -d /var/lib/pgsql/9.4/data/ -D /var/lib/pgsql/11/data/ Performing Consistency Checks ----------------------------- Checking cluster versions ok Checking database user is the install user ok Checking database connection settings ・・・ Upgrade Complete ---------------- 無事成功しました。 Postgres11で起動して確認して完了です。 [root@12d698375565 ~]# service postgresql-11 start Starting postgresql-11 service: [ OK ] [root@12d698375565 ~]# su - postgres -bash-4.1$ psql -l List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges -----------+----------+----------+-------------+-------------+----------------------- pg94 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres + | | | | | postgres=CTc/postgres template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | postgres=CTc/postgres+ | | | | | =c/postgres (4 rows) -bash-4.1$ 9.4のDBが11からもしっかり見えています。 やっと本筋の検証が進められそうです。 まとめ 今回やったことは旧バージョンをインストールするという手順がありましたが、 基本的にはpg_upgradeを実施しただけです。 それでも個人的には良い勉強になった事象でしたし、 次期バージョンでDBをアップデートするけど検証したいデータはまだ古い。 ということは今後も発生しそうなので、記事にしてみました。 何かの参考になれば幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに こんにちは、新卒3年目エンジニアの @rs_tukki です。先日開発オフィスが移転となり、美味しい昼食を探し求める日々が続いています。 さて、昨年このブログの中でこんな記事を書きました。 tech-blog.rakus.co.jp 振り返りの手法のひとつ「 KPT 法」について説明した記事ですが、今回はその第二弾として「YWT法」について話してみたいと思います。 はじめに 復習-KPT法とは YWT法 Y :やったこと W:わかったこと T:次にやること YWT法のメリット KPT法とどっちがいいの？ おわりに 参考 復習- KPT 法とは まずは KPT 法について再確認しておきましょう。 KPT 法とは、「振り返りの手法」として用いられている枠組みのひとつです。主には アジャイル 開発を採用したプロジェクトで実施することが多いですが、それ以外の現場でもやっていることを改善してよりよい方向を目指すために役立ちます。 今までの取り組みで感じたことを、 K : Keep(継続すべきこと) P : Problem(問題だと思うこと) の二つに分類して挙げてもらい、その中から次回の取り組みで実践することを T : Try(改善していくこと) としてまとめます。 次回の振り返りではTryの内容がまたKeepやProblemに分類され、更なる改善を目指していくこととなります。 YWT法 KPT 法について復習したところで、YWT法について説明します。 YWT法は KPT 法と同じく、振り返りの手法として用いられている枠組みのひとつで、 KPT 法とは異なり Y : やったこと W : わかったこと T : 次にやること という三つのステップに分割されます。 日本発祥の フレームワーク で、 日本能率協会コンサルティング で提唱されたのが始まりだそうです。 Y :やったこと まず初めに、 Y : やったこと として、今までの取り組みの中で文字通り「取り組んだこと」を書き出します。 開発プロジェクトであれば新機能を実装した、特定クラスの リファクタリング をした、テストコードを作成した、などなど。 ルーチンワーク と化しているものはYWTに乗せてもあまり効果がありませんので、上記のように単発の作業を挙げるといいと思います。 W:わかったこと Y : やったことを洗い出したあとは、それを踏まえて W : わかったこと として、やったことの中から何を学んだか、どんなことに気づいたかを書き出します。 例えば、特定クラスの リファクタリング をしたところ、そのクラスの可読性が上がったとします。では、他のクラスで もリフ ァクタリングを実施すれば同じように可読性は向上するでしょうか？ あるいは、新機能実装の過程で 潜在的 なバグがいくつか埋め込まれてしまったとします。バグはどうして生み出されてしまったのでしょうか？それを回避するためにはどうすればいいでしょうか？ このように、一つの事実から原因を深掘りしていくことで、今回やったことを次の機会にも生かせるように学びとして記録していくことがW=分かったことの一番大事な部分です。 T:次にやること 最後に T : 次にやること です。 Wで洗い出した内容を次回に向けてどう生かすかをまとめます。 「 リファクタリング が他のクラスでも行えそう、その結果コード全体の可読性がよくなりそう」ということが分かったので、次から積極的に リファクタリング に取り組む、 「実装の際にレビュー担当者が1人だけだとバグを見逃す可能性がある」ということが分かったので、複雑な機能に対しては二次レビュー担当者を配置する、といったことが挙げられるかと思います。 そして、ここで挙げた「次にやること」は、 KPT 法と同じくそのまま次の振り返りで「やったこと」として記録することができます。 どちらも同じですが、振り返りは一度で終わらず「継続すること」が最も大事だと言えます。 YWT法のメリット 振り返りを実施する時は、実際にそれまでの活動で何があったかを思い出し、上手くいったこと、いかなかったことを振り分けながら考えていくことが重要です。 それをしないまま曖昧な記憶のもとに振り返りを行うと、 KPT 法で言うところのP(Problem)にのみどうしても目がいってしまい、K(Keep)が疎かになってしまいがちです。 YWT法では、まさにその「思い出し」から始める フレームワーク であり、問題点と並んでよかった点も意識せず洗い出すことができます。 そのためKeepに目が行きやすい、という点がYWT法の利点の一つです。 KPT 法とどっちがいいの？ KPT 法とYWT法で明確にどっちがいい、という結論はありません。 強いて言えば、YWT法はやったことを通して学んだことを次に生かす、というコンセプトなので、学習を目的としたプロジェクトで採用しやすいのでないかと思います。 しかし、振り返りに慣れていない人にとっては「わかったこと」を漠然と考えるより、問題点や継続すべき点を洗い出す、というイメージが湧きやすい KPT 法が楽なケースもあります。 また、そもそも手法もこの二つに限りませんので、チームの状況によって柔軟に変えてみる方がいいでしょう。 おわりに 今回は、チームの振り返りの手法として、 KPT 法に次ぐ「YWT法」を紹介しました。 上記の通り、どの方法がいいかはチームの状況によっても変わると思いますので、これらに限らず実際にやってみてしっくりきた方法をとってみるのがいいかと思います。 ぜひ、皆さんのチームでも試してみてください。 参考 ブレスト初心者向けアイデアのまとめツールとして使えるフレームワークをご紹介 KPTとYWTの違いは？～KPTがうまくいかない理由と、YWTの特性を考える - Qiita YWT分析 - ラーニング・ラボ https://www.kikakulabo.com/tpl-ywt/ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに こんにちは、strongWhiteです。 はいくる通信 第2回を担当させていただきます。 はいくる通信 についてはこちら↓ tech-blog.rakus.co.jp 第1回の記事はこちら↓ tech-blog.rakus.co.jp 今回は、弊社のメール配信システム「配配メール」から配信できるメールの種類をご紹介します！ はじめに 様々なプラットフォームに対応するためのメールの種類 テキストメール HTMLメール 絵文字メール/デコメール まとめ 様々なプラットフォームに対応するためのメールの種類 我々のお客様がメール配信を利用して行うメール マーケティング では、メールを読んでもらえるかが重要な要素の1つです。そのためには、メルマガ読者の環境に合わせたメールを配信しなければなりません。 つまり、メールを読む端末に合わせてメールの形式を変える必要があるということです。そのため、配配メールではそれぞれのプラットフォームに対応するためのメールの形式を用意しています。 テキストメール メール マーケティング の黎明期から存在し、現在でも使い続けられているメール形式です。ただ、この形式はメルマガ配信で利用されるケースは多くありません。「年末年始休業のお知らせ」や「店舗改装のお知らせ」などの、定型的な連絡事項を配信する際によく使われているようです。 このようなシンプルな形式のメールでは、お客様がすばやくメールを作れるような画面設計を心がけています。挿入コードなどの付加機能をできるだけ排除し、少ない操作でメールを作成できるように、シンプルな作成画面の実現を意識しています。 HTMLメール 読者へ視覚的な印象を残しやすいことから最もメルマガ配信に利用されるメール形式です。 スマホ の普及にも伴って利用規模が拡大してきたメール形式ですが、その拡大に合わせて多彩な表現が可能になった反面、メールを作成するための手順や必要な知識は複雑化しています。メール マーケティング の主要なメール形式ゆえに、いかに魅力的な情報を詰められるかが重要です。 このメール形式では、HTMLメールの作成に不慣れなお客様でもなるべく思い通りのメールが作成できるような作成画面を提供することを心がけています。そのため、HTMLメール用の専用エディタを提供し、 ドラッグ&ドロップ などの操作で直感的にメールを作成できるようにしています。また、ある程度の知識を得て手順に慣れたお客様には、 スクリプト を埋め込んで動的な表現を実現するなどの、細部にこだわった表現が実現できる多様な機能も準備しています。 絵文字メール/ デコメール 主に非 スマホ （いわゆる ガラケー ）のメルマガ読者に対して、HTMLメールの代替として利用されるメール形式です。HTMLメールよりはシンプルな内容になりますが、テキストメールよりは表現力の高いメールを作成できます。いまだに一定の利用者が存在するため、一部のメール マーケティング では現在でも重宝されています。 この形式のメールでは携帯キャリアごとに表示内容のプレビュー画面を用意して機種依存の表現の問題を発見しやすいように、 プレビュー機能 の使いやすさに心がけています。携帯端末やキャリアによって表示内容がくずれたり、別の文字などに置換されてしまうことが多いため、開発者の我々も機能の実現や表示の確認で苦労の多いメール形式です。 まとめ それぞれのメール形式ごとに、お客様の利用用途に合わせた特徴と、我々エンジニアが開発時に意識していることをまとめてご説明しました。メールの形式ごとに目的が異なるため、それぞれの目的に沿うように気をつけながら開発しています。 はいくる通信では、今後もメルマガ配信の特徴や開発のウラ話についての記事を準備しています。次回もどうぞお楽しみに！

はじめに こんにちは、3年目の id:FM_Harmony です。 今回は、 Cache Busting と呼ばれるブラウザのキャッシュを制御する方法について調べる機会があったので、ブログ記事にまとめてみました。 静的ファイルのURLに一見意味のないクエリパラメータがついていることがありますが、ちゃんと意味があったのだと分かったので、同じような疑問を抱いている方の助けになれば幸いです。 はじめに 調べたきっかけ 静的ファイルのキャッシュ Cache Busting おわりに 参考 調べたきっかけ とある商材の JavaScript コードを改修したときのこと、知見の少ない商材だったので直近の改修をもとに必要な作業を整理していた時でした。 その商材ではHTMLで JavaScript を読み込む際、以下のようにsrc要素に商材のバージョンと同じ文字列がクエリパラメータで指定されており、バージョンアップの度に文字列を更新していました。 // こんな感じ <script type="text/javascript" src="xxxxx.js?ver=1.2.0.0"></script> しかし、 スクリプト 中では渡しているパラメータを利用していませんでした。 そこで、今回の改修でも必要な作業なのか、先輩に相談したところ... 私「 JavaScript のURLに商材のバージョンがついているのですが、今回の改修でURLについているバージョンを更新した方がいいでしょうか。」 先輩「キャッシュ対策であれば、更新したほうがよいでしょうね。」 私「キャッシュって、ブラウザのキャッシュですか？」 先輩「そうです。分からなければ、一度キャッシュについて勉強しなおしてみてください。」 ということで調べてみました。 静的ファイルのキャッシュ 前提として、 JavaScript 、 CSS ファイルなどの 静的ファイル は、読み込んだ際にブラウザがキャッシュします。 そのため、ファイルを更新した後に変更箇所をブラウザ上で確認しても、ブラウザがサーバ側のファイルを読み込まずにキャッシュを読み込んでしまうことがあります。 ブラウザ側で強制リロードさせて更新が反映されるようにもできますが、そんなことをせずとも更新後の静的ファイルをブラウザに読み込ませる方法があります。 それが、 Cache Busting と呼ばれる方法です。 Cache Busting 静的ファイルのURLがキャッシュしているものと異なる場合、ブラウザはキャッシュを利用せずサーバからファイルを取得します。 そこで、ファイル更新に合わせてクエリパラメータを更新することで、ブラウザがキャッシュを読み込むことを防げます。 この方法を Cache Busting と呼びます。 さて、ここまで調べて再び先輩に相談したところ... 私「 JavaScript のURLについているクエリパラメータですが、ブラウザがキャッシュを読み込まないよう更新したほうが良いと思います。」 先輩「分かりました、今回は更新しましょう。」 ということで、無事方針も定まり改修作業を始めることができたのでした。 おわりに 他にも Cache-Control ヘッダを利用してキャッシュの利用を制御できますが、Cache Bustingはクエリパラメータだけでキャッシュの利用が制御できるので、比較的手軽にできる方法だと思います。 キャッシュの制御を行われたい方は、一つの案として検討されてはいかがでしょうか。 参考 CSSファイルやJavaScriptファイルを読み込むときの末尾にあるクエリー文字列は何のためにあるか エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに 8月6日に行われたビアバッシュのご紹介をします。 今回はテーマ縛りなしで思い思いの「技術ネタ」を発表していただきました。 はじめに 発表一覧 個人的に気になった発表 inotifyのはなし 全機能テストの自動化 LT:Firebase Hack!! おわりに 発表一覧 以下のリストが今回の発表の一覧です。 多くの方に発表いただきました！ 自由枠（質問・回答含めて13分） 教育担当をして成長できたこと inotifyのはなし 式志向という考え⽅ The World of PHP (2019 Summer) - Speaker Deck 全機能テストの自動化 Windows のターミナル環境を整える LT枠（5分厳守） GitLab CIを使った定期実行 LT:Firebase Hack!! 全ての発表について触れていきたいところですが、それでは長くなってしまうので、個人的に気になった発表に絞って次項ではご紹介します。 個人的に気になった発表 inotifyのはなし linux の API の1つ、 ファイルシステム イベントを監視する inotify についての発表でした。 Ruby のモジュールを用いたサンプルを交えて紹介していただきました。 面白そうな API だったので個人的に調べて見ましたが、用途でいえば、単にログファイルを監視したり、ファイル改ざんを検知したりというように用いられることが多いようです。特にアプリケーションの運用面では大いに活用できそうだと感じました。運用面以外でも活躍できそう雰囲気はあるのですが、イマイチ思いつかず。。もう少し頑張って考えてみます。 API の詳細は Man page をご確認ください。 全機能テストの自動化 発表者の方が所属する開発チームでリリースごとに実施している全機能テストを自動化したときの内容を発表していただきました。発表者の方はテストで使用している puppeteer に慣れていないためか、試行錯誤の繰り返しでかなり苦労されたようです。 とはいえ、この自動化後は手動の時に比べて半分の時間でテストが実施できるようになったようです。テストが自動化され、実行の手間がかからない状態というのは非常に楽だと思います！ これからはメンテナンスとの戦いになると思いますが、続編の発表として、そのメンテナンスにおける苦労話などを共有いただきければ嬉しいですね。 LT:Firebase Hack!! 5月のビアバッシュよりβ版の運用が始まっている ビアバッシュ専用スマホアプリ の開発者の方から、バックエンドで使用している firebase についての発表でした。 firebaseは機能が非常に多いためすべての機能を使っているわけではないようですが、それぞれの概要についてご紹介いただきました。 中でも個人的に気になったのは Test Lab です。LT枠ということもあり発表ではさらっとしか触れられていなかったので個人的に調査してみました。 Test Labの紹介スライド これは Android や iOS の ネイティブアプリ を Google データセンターにある実機でテストできるというものだそうです。Webアプリに対するテストができれば個人的にはすごく面白いなと思っていたのでちょっと残念ではありました。。 とはいえ、 Android の場合は Robo テスト という、自動でUIを解析してテストしてくれる機能もあるようなので、ネイティブアプリを開発している場合は強力な効果をもたらしてくれそうです。 おわりに 今回は業務外で学習した内容だけでなく、業務でかかわったことも積極的に共有いただけました！開発チーム間での情報の共有は別途行われていますが、こういった場での情報共有は当事者の気持ちが表れやすいので聞いていて面白いです。 また、最近は「自動テスト」が個人的に気になるワードですので、そのあたりの発表があった今回のビアバッシュはいつも以上に興味深いものとなりました。 今後もビアバッシュの内容はブログに掲載していくので、どうぞお楽しみに！！

はじめに こんにちは、strongWhiteです。今回は大阪オフィスで開催された7月ビアバッシュをご紹介いたします。 前回の記事はこちら↓ tech-blog.rakus.co.jp はじめに テーマ発表 『沼へのご招待』 『Healthy Engineer Life』 『気分は南国』 LT発表 『テストカバレッジをあげた話』 『Beautiful Engineer Life 〜Pythonの勉強〜』 『Ansibleを使ってみた』 おわりに 参考 テーマ発表 今回のテーマは Beautiful Engineer Life です。 弊社エンジニアが自身のエンジニア生活をより良くするために心がけていることについて発表していただきました。 ふだんのビアバッシュは技術的なコンテンツを発表し合う場ですが、今回は趣味の話なども発表できる回となりました。 それでは内容をダイジェストでお送りいたします。 『沼へのご招待』 プライベートでハマった 沼 のお話。 発表者は 自転車 の収集にハマっており、街乗り用やツーリング用などの用途別に収集していくうちにハマっていったそうです。 曰く、沼にハマるメ カニ ズムは 小さな成功体験の積み重ね であり、今回の例ですと、良い自転車を手に入れたという 成功体験 が沼の入り口となり、気付けばどんどんハマっていったそうです。 誰しもどんな些細なことでものめり込むと沼にハマっていってしまいますね（笑） 『Healthy Engineer Life』 健康的な生活を送るための体調管理法のお話。 エンジニアは仕事上、どうしても椅子に座りっぱなしになったり、パソコンの画面を見続けっぱなしになることが多いので、全体的な 疲労 感だけでなく頭痛や眼の疲れ、肩こり、腰痛などに悩まされがちです。 これらに関して発表者はまず食生活に気を配り、栄養素に着目して疲れに効くビタミン群を適度に摂取するように心がけておられるようです。曰く、 ほうれん草 は最強らしいです（笑） 他には質の高い睡眠を取るために寝る前に スマホ 画面などの ブルーライト を浴びない、カフェインやアルコールを摂取しない、決まった時間に寝ることで身体が寝る準備を整えられるようにされているようです。 これらは基本的なことではありますが、なかなか毎日継続してできることではないですね。少なくとも筆者はいつか挫折しそうです。。 『気分は南国』 通勤時間に読んだ技術ブログのとある記事のお話。 発表者は通勤時間中の 日課 として、技術的なコンテンツをメールや Twitter 、Qiitaなどから収集されているのですが、その中に面白いタイトルの記事があったので読んで得た知識を共有していただきました。 実際の記事はこちら↓ 動的計画法を実現する代数〜トロピカル演算でグラフの最短経路を計算する〜 トロピカル半環 と呼ばれる代数構造上のトロピカル行列を利用するとグラフの最短経路の距離を計算するという問題が単純な行列積で解けてしまう...という趣旨のお話なのですが、筆者は数学が苦手なのであまり理解できていないです（泣） この記事のお話を参考に、トロピカル半環が日々のお仕事に活かせる日がくると良いですね〜。 LT発表 ふだんはテーマ枠、自由枠、LT枠を確保していますが今回は自由枠を抜き、LT枠のみとしました。 簡単に発表内容を共有していきます。 『テスト カバレッジ をあげた話』 担当商材の PHP のバージョンアップに伴い、品質担保のためテストを書くようにしたお話です。 現状、テストはあるが全網羅ができていないため重要機能に着目してテスト カバレッジ を向上させる取り組みを行われました。 『Beautiful Engineer Life 〜 Python の勉強〜』 LT枠を使ったBeautiful Engineer Lifeです。7月の3連休で Python を勉強されたお話です。 技術的な勉強はネットで検索すれば公式リファレンスや有志のブログなどがヒットしますが、全くのイチから勉強したいときはこれらのコンテンツはある程度前提知識がないと理解しづらいため、ちゃんと勉強するには本で勉強するのが一番とのことです。 『Ansibleを使ってみた』 担当商材の開発機を再起動すると、一部サービスを手動で立ち上げないといけないという問題があったので、Ansibleで実行するようにしたお話です。 Ansibleを簡単に解説すると、 RedHat 社が開発する オープンソース の構成管理ツールで、 接続先ファイル と、 実行すべきタスクのリスト があればエージェントレスに対象のサーバーに対してタスクを実行してくれます（※Ansibleは冪等性を担保するように作られているので、厳密には 何を実行するのか ではなく、 どのような状態があるべき姿なのか をファイルにまとめておきます）。 おわりに エンジニアの皆さんの Beautiful Engineer Life についての発表でした。 エンジニア生活をより良くするためには勉強だけでなく、趣味の時間を大事にしたり、生活習慣を改善し、日常生活に支障が起きないようにしないといけないですね。何事も体が資本なので健康的かつ衛生的が一番です。 筆者もお腹まわりのお肉が気になるので頑張って痩せないといけないです それでは、次回のビアバッシュレポートもご期待ください！ 参考 動的計画法を実現する代数〜トロピカル演算でグラフの最短経路を計算する〜 Ansibleをはじめる人に。 Ansibleとは何か　構成管理ツールの目的〜Ansible導入まで最速で理解する

※公開時から一部訂正しています※ 文中で個人識別符号の例としてクレジットカード番号をあげていましたが、 個人情報保護委員会 から発行されている『 「個人情報の保護に関する法律についてのガイドライン」及び「個人データの漏えい等の事案が発生した場合等の対応について」に関するQ&A 』（PDFへの直接リンクは こちら ）のQ1-22にてクレジットカード番号 単体では 個人識別符号として該当しない旨が記載されていましたので修正しています。 こんにちは、株式会社 ラク スで横断的にITエンジニアの育成や、技術推進、採用促進などを行っている開発管理課に所属している鈴木( @moomooya )です。 今回は社内選抜メンバーで行っている 「 開 （ か ） 発の 未 （ み ） 来に 先 （ せん ） 手をうつプロジェクト（通称：かみせんプロジェクト）」 で、今期取り扱っている「データ匿名化（個人情報の匿名化）」についてお話ししたいと思います。全6回で執筆していますのでお付き合いいただければと思います。 なお、かみせんプロジェクトについてはこちらの記事で紹介していますので、気になる方はこちらも併せてごらんください。 tech-blog.rakus.co.jp 連載目次 『全文検索 〜 Elasticsearchとデータ匿名化手法』 『全文検索の探求 Elasticsearch(1) 』: プロジェクト方針およびElasticsearch概要 大量データを検索するサービスでElasticsearchはRDBの代替候補になりうるか？(Elasticsearch vs pg_bigm)』 データ匿名化 第1回：匿名化された個人情報とは何なのか ←今読んでいる記事 データ匿名化 第2回：個人情報は匿名化しても意味がないのではないか？ データ匿名化 第3回：個人情報を匿名化するプロセス データ匿名化 第4回：匿名化のために行うデータ項目の一般化とは データ匿名化 第5回：データ匿名化の指標 データ匿名化 第6回：実際の匿名化 個人情報の匿名化 2015年に 個人情報保護法 が改正され、世間的にも個人情報の扱いに今まで以上に気を使う機会が増えてきました。エンジニアの目線だと2014年ごろから流行り始めた ビッグデータ の入力となる大量のデータの前処理として注目されるようになったと思います。2014年にはO'reillyから専門書の邦訳版も出版されました *1 。 データ匿名化手法 ―ヘルスデータ事例に学ぶ個人情報保護 作者: Khaled El Emam , Luk Arbuckle オライリージャパン Amazon しかし、個人情報の扱いについては法律に定められているということもあり、具体的にどのように扱えばよいのかわかりにくい部分があると感じています。これについて個人情報の扱いについて最低限どうすればよいのか、それぞれの言葉が何を指しているのか *2 をITエンジニア目線でお話ししていければと思います。なおお約束ですが、私は法律の専門家ではないので記載の内容を自社サービスに適用する場合などは専門家に相談したうえでお願いします。 そもそも個人情報とは 個人情報保護法 で定められていることを記載。 個人情報についての取り扱いは一般論などで定められているわけではなく、平成29年5月30日に施行された 個人情報の保護に関する法律 （略称、新 個人情報保護法 ）によって定められています。 法的な解釈 個人情報 は新 個人情報保護法 第一章 総則の中で以下のように定義されています。 第二条　この法律において「個人情報」とは、生存する個人に関する情報であって、次の各号のいずれかに該当するものをいう。 一　当該情報に含まれる氏名、生年月日その他の記述等（文書、図画若しくは電磁的記録（電磁的方式（電子的方式、磁気的方式その他人の知覚によっては認識することができない方式をいう。次項第二号において同じ。）で作られる記録をいう。第十八条第二項において同じ。）に記載され、若しくは記録され、又は音声、動作その他の方法を用いて表された一切の事項（個人識別符号を除く。）をいう。以下同じ。）により特定の個人を識別することができるもの（他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。） 二　個人識別符号が含まれるもの 『個人情報の保護に関する法律』より引用 このままだとわかりにくいので分解してみます。 当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの その他の記述等 とあるために範囲が特定しがたいですが、比較的わかりやすいと思います。 他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む 氏名など単体で特定できるものに限らず、組み合わせによって特定できる情報も含まれるということです。例えば「〇〇交番の隣に住んでいる」「おじいさん」という組み合わせは「〇〇交番の周囲の住居（住所の範囲）」だけや「おじいさん（性別と年齢の範囲）」だけでは個人を特定できなくても2つの情報が組み合わさったときに特定できる場合はこれも個人情報として扱われることになります（単体で個人を識別できる 識別子 に対して 準識別子 と呼ばれる）。 文書、図画若しくは電磁的記録に記載され、若しくは記録され、又は音声、動作その他の方法を用いて表された一切の事項（個人識別符号を除く。）をいう これは記録の方法がアナログ、デジタルの区別がなく、文字や図案（図、表、写真など）だけではなく音声や動作なども区別もなく該当するということになります。 個人識別符号が含まれるもの 「個人識別符号」というのは聞きなれないですが、以下のように定められています。 ２　この法律において「個人識別符号」とは、次の各号のいずれかに該当する文字、番号、記号その他の符号のうち、 政令 で定めるものをいう。 一　特定の個人の身体の一部の特徴を電子計算機の用に供するために変換した文字、番号、記号その他の符号であって、当該特定の個人を識別することができるもの 二　個人に提供される役務の利用若しくは個人に販売される商品の購入に関し割り当てられ、又は個人に発行されるカードその他の書類に記載され、若しくは電磁的方式により記録された文字、番号、記号その他の符号であって、その利用者若しくは購入者又は発行を受ける者ごとに異なるものとなるように割り当てられ、又は記載され、若しくは記録されることにより、特定の利用者若しくは購入者又は発行を受ける者を識別することができるもの 『個人情報の保護に関する法律』より引用 何を指しているのか少しわかりにくいですが、こちらは 個人情報保護員会 が公開している 個人情報保護の基本 という資料の9ページ目がわかりやすいです。 「個人識別符号」は以下①②のいずれかに該当するものであり、 政令 ・規則で個別に指定 される。 ① 身体の一部の特徴を電子計算機のために変換した符号 ⇒ＤＮＡ、顔、 虹彩 、声紋、歩行の態様、手指の静脈、指紋・掌紋 ② サービス利用や書類において対象者ごとに割り振られる符号 ⇒公的な番号 旅券番号、 基礎年金番号 、免許証番号、住民票コード、 マイナン バー、各種保険証等 『個人情報保護の基本』より引用 (PDF) 匿名化とは これらの個人情報を含む情報を再利用可能な形にすることを一般に匿名化、再利用可能なデータを匿名化データなどと呼びますが、これも同じく新 個人情報保護法 にて定義されています。 法的な解釈 法律上は匿名化データのことは「匿名加工情報」と表現され、個人情報と同じく新 個人情報保護法 第一章 総則の中で以下のように定義されています。 ９　この法律において「匿名加工情報」とは、次の各号に掲げる個人情報の区分に応じて当該各号に定める措置を講じて特定の個人を識別することができないように個人情報を加工して得られる個人に関する情報であって、当該個人情報を復元することができないようにしたものをいう。 一　第一項第一号に該当する個人情報　当該個人情報に含まれる記述等の一部を削除すること（当該一部の記述等を復元することのできる規則性を有しない方法により他の記述等に置き換えることを含む。）。 二　第一項第二号に該当する個人情報　当該個人情報に含まれる個人識別符号の全部を削除すること（当該個人識別符号を復元することのできる規則性を有しない方法により他の記述等に置き換えることを含む。）。 『個人情報の保護に関する法律』より引用 こちらも一つずつ見ていきたいと思います。 第一項第一号に該当する個人情報 こちらは先述した 当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの という個人識別符号以外の部分に該当する情報です。 当該個人情報に含まれる記述等の一部を削除すること。 「記述等の一部を削除」は文字通りのなのでわかりやすいです。例えば住所であれば「東京都渋谷区 千駄ヶ谷 5-27-11」 *3 の後半を削除して「東京都渋谷区」にすればよさそうです。 当該一部の記述等を復元することのできる規則性を有しない方法により他の記述等に置き換えることを含む。 非可逆な情報で置き換えることでも「削除」として扱われるようです。ただし注意しなければならないのは置き換えた後の情報が 他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるもの になっていてはいけないので、置き換えた後も個人情報に該当しないか確認する必要があるでしょう。 第一項第二号に該当する個人情報 こちらは「個人識別符号」に該当する情報についてです。 当該個人情報に含まれる個人識別符号の全部を削除すること こちらは先ほどと異なるのは「個人識別符号の全部を削除」となっている部分です。例えば クレジットカード番号 パスポート番号 *4 であれば「下数桁を置き換える」といった方法ではなく「すべての桁を存在しない番号に置き換える」といった対応が必要なようです。 当該個人識別符号を復元することのできる規則性を有しない方法により他の記述等に置き換えることを含む 個人識別符号についても非可逆な情報で置き換えることでも「削除」として扱われるようです。こちらも同様に置き換え後の情報が個人情報となっていないことは確認する必要があります。 まとめ ここまで法律上の「個人情報」「匿名加工情報」の定義をかみ砕きながら読み解いてきました。 しかし実際の「匿名加工情報」に加工するにあたっては加工対象となるデータに応じてケースバイケースの対応を行っていく必要があります。この連載では実際のデータの加工をどのように進めていくのかを順を追って紹介してみたいと思います。 ただし、ここまで触れてきたとおり個人情報の匿名化には法的解釈があるので、実業務に適用する場合などは専門家に問い合わせて確認してから取り扱っていただければと思います。 この連載では最低限やらないといけないだろうことや、各用語がどういうものを指しているのかをエンジニア視点で解説していきたいと思います。 次回は匿名化した個人情報が本当に個人を特定できないのか、個人を特定できないとはどういうことなのかをお話ししたいと思います。 連載目次 『全文検索 〜 Elasticsearchとデータ匿名化手法』 『全文検索の探求 Elasticsearch(1) 』: プロジェクト方針およびElasticsearch概要 大量データを検索するサービスでElasticsearchはRDBの代替候補になりうるか？(Elasticsearch vs pg_bigm)』 データ匿名化 第1回：匿名化された個人情報とは何なのか ←今読んでいる記事 データ匿名化 第2回：個人情報は匿名化しても意味がないのではないか？ データ匿名化 第3回：個人情報を匿名化するプロセス データ匿名化 第4回：匿名化のために行うデータ項目の一般化とは データ匿名化 第5回：データ匿名化の指標 データ匿名化 第6回：実際の匿名化 *1 : ちなみにこちらの『データ匿名化手法』は序盤が匿名化手法一般の話題で、中盤以降が医療系データでの事例をもとに解説されていますが、序盤の特に2章は何度も繰り返し読み込んだほどよくまとまっているのでオススメです。 *2 : 意外と字面からの想像では正しく理解できない用語もちらほらあります。 *3 : 弊社の住所です。 *4 : 「パスポート番号」の他には「 国民年金 法における 基礎年金番号 」「 道路交通法 における免許証の番号」「 住民基本台帳 法における住民票コード」「被保険者証の番号」などが 政令 『 個人情報の保護に関する法律施行令（平成15年政令第507号） 』において 個人識別符号 として定義されています。他にも「DNAの 塩基配列 」や「指紋」「掌紋」といったものも定義されています。

こんにちは、MasaKuです。 今年も オープンソースカンファレンス が開催されましたので、毎年の恒例行事として参加してきました！ www.ospn.jp 以前参加した際に、興味深かった発表の 記事 を書かせていただいたり、弊社で行っているビアバッシュで発表しました。 tech-blog.rakus.co.jp しかし、そもそも、 オープンソースカンファレンス ってどんなところ？と思われる方も多いのではないでしょうか。 今回は、 オープンソースカンファレンス ならではの楽しさをお伝えし「 参加してみたい！ 」と思って頂けるような記事を書ければと思います。 オープンソースカンファレンス 2019 Kyoto 楽しさポイント１：豊富な発表内容 楽しさポイント２：展示ブース 楽しさポイント３：LT大会 最後に おまけ 参考サイト 楽しさポイント１：豊富な発表内容 「 オープンソース の文化祭」というサブタイトルの通り、 オープンソース に関連する様々なテーマが集まるため、発表内容は本当に多種多様です。 オープンソース のMWに関する最新情報の発表であったり、 オープンソース のツールを利用した業務改善の発表であったり、 オープンソース の歴史についての発表であったり、etc... と本当に様々な発表を聞くことができます。 今回私は二日目に参加したのですが、その際に聴講させていただいた発表は以下の通りです。 アジャイル・多言語開発時代のJetBrains開発環境 Raspberry Pi最新情報アップデート Lisk～JavaScriptで簡単に独自ブロックチェーンを構築～ Powershellで切り開くExcelの更に新しい使い方 平成生まれのためのUNIX&IT歴史講座 ～2000年代前半編～ ライトニングトーク＆閉会式 私が聴講したものでも、本当に様々なテーマがあると思われたのではないでしょうか。 そのほかの発表については コチラ よりご確認いただけると幸いです。 楽しさポイント２：展示ブース オープンソースカンファレンス で最も気に入っているのが「展示ブース」です。 展示ブース レトロPCで Mastodon を起動 展示ブース とは、会場の一部のスペースを利用して、作品の展示や オープンソース の宣伝活動などを行うイベントです。 展示ブースの面白いポイントは、展示されている方とゆっくりと話をすることができる点です。 何となく聞いたことあるなというレベルの知識でも、ブースに近づいていくと出展されている方が話しかけてくださいます。 色々と教えてくださる優しい方ばかりなので、本当に暖かいイベントだと毎回思わされます。 ブースに出店される方も常連の方が多いらしく、なんとなく同窓会のような雰囲気があるのも個人的にはすごく好きなポイントです。 お話が聞けるだけでも有意義だと思いますが、ステッカーやご紹介されている オープンソース の導入資料などのお土産がもらえるブースも存在します。 株式会社サムライズム様より頂いたPhpStormのステッカー 楽しさポイント３：LT大会 オープンソースカンファレンス では、閉会式の前のセッションでLT大会が開催されます。 今回は11名の方が発表されていましたが、発表内容や年代もバラバラで本当に見ごたえのある発表ばかりでした。 様々な年代の方が発表されるため、多種多様なタイプの発表を見ることができ、発表の仕方の勉強にもなりました。 今回のLT大会を聴講して、発表の仕方という面で勉強になったのは以下の通りです。 多くの人に当てはまる「あるある」な部分を具体的な例を提示しながら共感を誘うテクニック 「こんなこと普通はしないですよね～」と言いつつも「自分はやりました！」という意表をつく展開 プレゼンテーションで聴衆を引き込むテクニックとしては定番なものかも知れませんが、あまりよく知らないテーマに関する発表でもグッと引き込まれるほど強力なテクニックだとは思っていなかったので、是非身に着けたいテクニックだと思いました。 最後に いかがでしたでしょうか。楽しそうな雰囲気が伝わって、少しでも興味をもっていただけたら幸いです。 私が勉強会やカンファレンスは参加する際は、事前に雰囲気や発表内容をリサーチしてから参加するかを決めることがあります。 しかし、 オープンソースカンファレンス に関しては「行けば何か楽しいことが見つかりそう！」という期待感が毎回持てます。 今回もたくさんの楽しさを見つけることができましたので、次回も是非参加したいと思っています。 ちなみに、次回は 9/14 - 9/15 に広島で開催予定です。 www.ospn.jp おまけ 参加者アンケートへの回答後にくじ引きをさせてもらえたのですが、見事Tシャツが当たりました！ FOSS4G 2017 のTシャツ 受付の方もビックリされていて、ベルも鳴らされたので結構な確率だったのではないでしょうか。 ※OSCなのにFOSS4GのTシャツ？となりましたが、2017年は私の入社年度でもありますので何かの縁だと思い大切にします 参考サイト オープンソースカンファレンス2019 Kyoto - オープンソースの文化祭！

はじめに favicon を表示させたいことがあったのですが、ブラウザごとの挙動の違いによって以外と苦しめられました。この記事ではタイトルの通り、 favicon が表示されない時に確認することを記載します。 はじめに faviconって何？ 確認したブラウザとそのバージョン faviconの表示方法 確認1：読み込む画像ファイルを疑う 問題の切り分け 確認2：キャッシュを削除してみる 確認3：絶対パスで記述する（IE,Edge） 確認4：証明書まわりを疑う（IE,Edge） 補足：IEとEdgeだけでいいからfaviconを表示したい時 確認5：faviconに関するファイルを削除してみる 補足：何に使われるファイルなの？ おわりに favicon って何？ favicon とはwebサイトのアドレスバーやタブ部分に表示されるアイコンのことです。付けておくことで複数タブを開いた際やブックマークした際に探しやすくなります。 favicon _ブラウザのタブ favicon _お気に入りバー 確認したブラウザとそのバージョン Google Chrome 75.0.37 Firefox 67.0.4 Internet Explore 11.88 Edge 42.17 favicon の表示方法 基本的に favicon 用の画像を用意し、下記のように書いてあげると favicon は表示されます。 type：無くても favicon は表示されるようです。 ico 以外にもjpgや png の指定もできます href： 絶対パス や 相対パス で指定できます < link rel = "shortcut icon" type = "image/x-icon" href = "/img/favicon.ico" /> 参考： qiita.com 確認1：読み込む画像ファイルを疑う 画像ファイルが悪い場合、表示されないことがあるようです。また、調べたところ、 favicon には png やjpgなども使えるようですが、 ico ファイルが一般的なようです。 問題の切り分け 画像が悪いのかそれ以外の原因かを切り分けるには、以下の手順が手っ取り早いと思います。 favicon が表示れる任意のサイトへアクセス 開発者ツールから favicon などで検索 favicon の画像ファイルをダウンロード、自分のサイトでも表示されるか試す → 表示されるなら、自分のサイトの画像が問題であることが分かる 確認2：キャッシュを削除してみる favicon の画像を変えたのに変更が反映されない場合はまず疑うと良いと思います。また、見落とすと中々気づけないのがこのパターンです。 確認3： 絶対パス で記述する（ IE ,Edge） IE 、Edgeでは 絶対パス でないと favicon が表示されないようです。他のブラウザで表示されるにも関わらず、 IE やEdgeで表示されないときはパスや確認4の証明書まわりを疑うと良いと思います。 参考： http://www.seotemplate.biz/free-seo/2195/ www.seotemplate.biz 確認4：証明書まわりを疑う（ IE ,Edge） https 通信をしているサイトでは 絶対パス を https://... と書いても証明書の問題で表示されないことがあります。 オレオレ証明書 を利用していると表示されないようなので注意が必要です。 補足： IE とEdgeだけでいいから favicon を表示したい時 一応、 IE 、Edgeのみに表示させたい場合は、画像のパスのみhttp://と SSL 通信でなくしてあげれば表示させることはできました。ただし、この書き方（ https のサイトで画像のパスのみhttpにする）をした場合 Chrome では favicon が表示されなくなりました。 確認5： favicon に関するファイルを削除してみる ブラウザごとに格納している favicon に関するファイルをクリアしてみる方法です（私が試したときにはこれが原因になることはなかったため、感覚としてはあまり頻発しないパターンだと思います）。 補足：何に使われるファイルなの？ ブラウザごとに格納されている favicon ファイルは、お気に入りなどを表示する際に利用されるものです。そのため、ブラウザからキャッシュを消してもこのファイルは消えません。 下記に Google Chrome での格納場所を例として挙げておきます。 Windows ： Local Settings/Application Data/Google/Chrome/User Data/Default Mac ： Machintosh HD/ユーザ/（ユーザ名）/ライブラリ/Application Support/Google/Chrome/Default 参考： www.japan-secure.com おわりに 今回は favicon が表示されない時に確認することを紹介しました。画像を用意して、HTMLを1行書くだけ…と思っていましたが ややこしい 奥が深いなと感じました。ブラウザやそのバージョンによって苦しめられるということはよくあると思うので favicon で困っている方の一助になっていれば幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

https://www.agilejapan.org/ www.agilejapan.org はじめに 楽楽明細のエンジニアをしている id:eichisanden です。 7/18に行われた Agile Japan 2019のムービースポンサーを弊社の方で務めさせて頂きました。 アジャイル ジャパン2019にムービースポンサーとして参加させて頂いております。 #agilejapan pic.twitter.com/7JmNmuHtZL — 株式会社 ラク ス 開発部 (@DevRakus) 2019年7月18日 ムービースポンサーになると、招待チケット、関係者チケットを1枚ずつ貰えるのでとてもお得だと思います！ 最近チームで スクラム を初めたこともあり初めて参加させてもらいました。 （というか アジャイル のイベント自体が初参加でした！） セッションの合間などに インパク トのある楽楽精算のムービーが流されていました。社名だけでも覚えてもらえたかな。 ムービースポンサーは当日やることないので（笑）１参加者として楽しませてもらいました。 どのセッションも興味深かったですが、一緒に参加した id:radiocat とセッションを2つずつ紹介します。 マネージャー不在の洞窟型組織 report by radiocat AI搭載の家庭用ロボットの ラボット で実践されている スクラム 開発の話でした。 イノベーション において大切な能力は早く試して、早く学ぶことであり、それを「Learning agility」と説明されていました。巨額の投資を受けて、最先端の技術を詰め込んだ製品を短期間で作らなければならないロボット開発の世界なので、 アジャイル 化が進むIT業界の中でも最大限に アジャイル が求められる世界であると想像できます。 LOVOT開発＝生命の進化プロセスを4年の開発期間で再現 - 早く試して、早く学ぶ - スコープがよく変わる #agilejapan — radiocat (@radiocatz) 2019年7月18日 特に大切なのが、未知の領域で不安を解消できる「可視化」とスコープがたびたび変化する中でも疲弊せず職場の活気を生み出せる「自立性」であると説明されていたのも共感できました。 アジャイル に必要な能力⇒見通しの悪いところで遭難しない能力 #agilejapan — radiocat (@radiocatz) 2019年7月18日 また、テレワークは導入しているが「なるべく一箇所に集まって顔を合わせながら仕事をしている」という説明も、 アジャイル に向き合った経験から導き出された学びの1つであると想像できました。 Fun! Done! Learn! 〜 チームの楽しさと学びを成果に結びつく新しい振り返りを体験しましょう！ report by radiocat ふりかえりの手法のひとつである「Fun,Done,Learn」を体験するセッションでした。参加した人10人ぐらいでグループを作って アジャイル ジャパンのふりかえりをFun,Done,Learnで行いました。まずは3つの要素にとらわれずやったことや気づきを付箋に書き、その内容をグループ内で共有して「これはFunだよね」とか「Learnでもあるよね」と、話し合いながら3つの要素のベン図に付箋を貼っていきました。 その時その場に集まった知らない人同士でしたが、付箋をどこに貼るか議論をかわしていくことで思った以上に深い内省に繋げられると感じました。 なぜ始まらない？ アジャイル 開発 アジャイル コーチと考える組織改革 report by eichisanden 今回1番参加したかったセッションです。 うちのチームでは アジャイル コーチを入れずに独学で スクラム をやっていますが、コーチに入ってもらった場合どう変わるのか興味がありました。 セッションは、 アジャイル コーチとコーチを受けた方がパネルディスカッションする形式でした。 最初に選択されたテーマは皆さん気になるようで（私も気になりました）お値段でした（笑）。 いくらかはここには書きませんが（笑）皆さんリアルな数字を暴露していて参考になりました。 どの方も口を揃えて言っていましたが間隔が空くとコーチが状況把握できないので、週に1、２回は入ってもらった方が良いとのことでした。 また アジャイル を初めたばかりのチーム内の温度差は アジャイル コーチ的には問題なくて、むしろ上手くいき始めてからの温度差の方が厄介とのこと。 その場合、単に思い込みだったりする場合も多いので話を聞いてみることが重要。 また近くの席の方とも意見交換したのも有意義でした。 アジャイル コーチを呼ぶことで時間を買うことができる。 意見がまとまらないときに外部の人の意見は貴重（外部のお墨付き） 今回ほとんどのセッションで同時進行でグラレコを書かれていたのが印象的でした。後で内容を見返せるしとても良いですね。 SI出身エンジニアが自己組織型マネジメントに奔走した話 report by eichisanden 私自身もSI出身でキャリアや経験が重なる部分が多く興味深く話を聴かせてもらいました。 リーダーへの依存、リーダーの ボトルネック 化、管理型リーダーの限界を感じたところは正に自分も経験したことでした。 管理型の限界、分かりみ深い #agilejapan — A1 (@EichiSanden) 2019年7月18日 指示ではなく、チームがHOWを考え、 WBS による管理ではなく、チームが自分たちの生産性を管理し、 リーダーによるレビューではなく、チームが品質を高める。 スクラム を導入したことで、チームで計画し、チームで振り返り、チームで成果を出せる状態になった。うちのチームは スクラム を始めたばかりですが、これも私が感じている スクラム の１番のメリットでした。 スクラム を導入して良かったこと自分の感覚も同じやわ。リーダーだけで計画するのではなく、皆んなで計画して皆んなで振り返り改善していくのが良い。 #agilejapan — A1 (@EichiSanden) 2019年7月18日 展示会場 セッションの合間は展示会場で「旅する アジャイル 本棚」をパラパラ読んでました。他にも企業のブースにいる方とお話できますし展示会場も堪能するのが通の過ごし方なのかもしれません（笑） おわりに 思ったよりもエンタプライズな企業の方が多くて、遅れていると言われていますが日本でも アジャイル 開発が確実に普及してきているなと思いました。 アジャイル へのやる気を注入してもらった良い一日でした。