初めまして、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日 展示会場 セッションの合間は展示会場で「旅する アジャイル 本棚」をパラパラ読んでました。他にも企業のブースにいる方とお話できますし展示会場も堪能するのが通の過ごし方なのかもしれません（笑） おわりに 思ったよりもエンタプライズな企業の方が多くて、遅れていると言われていますが日本でも アジャイル 開発が確実に普及してきているなと思いました。 アジャイル へのやる気を注入してもらった良い一日でした。

こんにちは。シカタ( id:d_shr )です。 先月のことですが、弊社で開催した RAKUS Meetup Osaka #3 で発表しました。 今回は発表内容について書きたいと思います。 発表資料 発表レポート 機能開発を担当している「Mail Dealer」でNode.jsのEOLと格闘した2年間について 以下のようなお話をしました。 Node.jsのバージョンアップができなくなったこと 迫りくるEOL、問題とどのように向き合い・解決しようとしたか Node.jsのバージョンアップを実施したこと ミドルウェア の原因追及が正攻法ですが、アプリケーションの改修による解決したことをお話ししました。 同様の問題に向き合われる方へ参考になれば幸いです。 まだまだ課題は残っており現在調査中ですが、根本的な解決に向けて引き続きチャレンジしていければと思っています。 さいごに、個人的な話です。 弊社主催ではありますが、このような技術イベントでの発表は初めての経験でした。 今回チャレンジしてみて自分のためになることがとても多かったです。 今後は外部のイベントへもチャレンジしてみようと思いました。

みなさんこんにちは。フジサワです。今回は、 前回の記事 でご紹介いたしました、「 開 （ か ） 発の 未 （ み ） 来に 先 （ せん ） 手をうつプロジェクト（通称：かみせんプロジェクト）」についての途中経過をレポートさせていただきます。 今年度のかみせんプロジェクトでは、大きく以下の２つのテーマ Elasticsearch データ匿名化手法 について検証を進めており、本記事ではElasticsearchの検証について記載いたします。 連載目次 『全文検索 〜 Elasticsearchとデータ匿名化手法』 『全文検索の探求 Elasticsearch(1) 』: プロジェクト方針およびElasticsearch概要 ←今読んでいる記事 大量データを検索するサービスでElasticsearchはRDBの代替候補になりうるか？(Elasticsearch vs pg_bigm)』 データ匿名化 第1回：匿名化された個人情報とは何なのか データ匿名化 第2回：個人情報は匿名化しても意味がないのではないか？ データ匿名化 第3回：個人情報を匿名化するプロセス データ匿名化 第4回：匿名化のために行うデータ項目の一般化とは データ匿名化 第5回：データ匿名化の指標 データ匿名化 第6回：実際の匿名化 SQL チューニング以外の手段を 弊社が運営しているサービスの開発では、検索処理のパフォーマンス課題に取り組むことがしばしばあり、検索要件への対応範囲を広げたいと考えています。 複数の動的カラムのデータを横断的に検索したい メールなどの大量の文章データを検索したい など、 SQL チューニングでは一筋縄ではいかないようなシーンにおいて、その他の技術的対応手段としての役割を、Elasticsearchに期待しています。 ※Elasticsearchを検証対象とした詳細な経緯については、 前回の記事 をご覧ください。 全文検索 を使える未来を手に入れる Elasticsearchの検証を進めるにあたり、 バックログ の洗い出しを行いました。 チーム全員がElasticearchに関する知見がない状態からのスタートだったため、まずは以下の書籍を各自読み、Elasticsearchの概要を理解するところから始めました。 Elasticsearch実践ガイド Elasticsearch実践ガイド (impress top gear) 作者: 惣道 哲也 インプレス Amazon Elasticsearchについて詳しく知るための調査を開始 Elasticsearchに関する基礎的な情報や、実際に動作させてみた結果などを Wiki にまとめてナレッジの蓄積を行いました。 PHP で動作するサンプルプログラムを作成し、アプリケーションからのElasticsearchの利用方法の検証なども行なっています。 動作確認は、前述の書籍の他に、以下のような情報も参考にして行いました。 Elasticsearc 公式リファレンス 基本的な API の使い方などは、公式リファレンスをなぞって動作確認しました。 国立情報学研究所作成のGithubリポジトリ Elasticsearchに関して、一通り凝縮してまとめられています。 REST API での検索イメージ それでは、調査結果の一部を抜粋してご紹介いたします。 Elasticsearchの概要 オープンソース の分散 全文検索エンジン 自然言語 で記述された大量の文書データの検索を高速に実行可能 文書データを字句解析し、単語などに分割してインデックス化することで実現している 日本語の字句解析に対応した プラグイン （Kuromoji Analysis Plugin）がある Elastic社 が中心になって開発が進められている 検索エンジン のコア部分は Java 製の検索ライブラリ Apache Lucene が使用されている ドキュメント型データベースで柔軟なデータ構造でデータを保存できる ドキュメント型なので、非正規化した状態でデータを持つ必要がある スケーラブルな構成になっており、事前に最大データ量の検討ができていれば、容易にスケールアウトすることが可能 データの分割単位であるシャード数を事前に定義 ノードを増やすと、新しく増えたノードにシャードが分配されスケールアウトできる ただし、シャード数は後から変更できないため、事前に最大データ量を想定した計画が必要になる トランザクション を持たない（検索・参照に特化） 検索やデータの登録だけでなく、 クラスタ の管理やメンテナンス等の、ほぼ全ての操作が、 REST API を用いて実行できる 検索だけでなく、検索結果の分類や集計なども高速に実行できる。Kibanaとの組み合わせにより、データの傾向やパターン分析などの用途でも用いられる Linux , Windows , Mac 等の各OSに対応しており、公式のDockerイメージなども公開されている 基本動作の確認はDockerコンテナ上で実施 Elasticsearchの活用事例 Elascticsearchの活用事例は、Elastic社の 公式ページ に多数掲載されています。 ここでは、いくつか特徴的な用途で使用している事例を抜粋いたします。 GitHub リポジトリ 、ユーザー、Issue、PR、 ソースコード などの大量の情報を高速に検索できる 日本経済新聞社 日経電子版の記事検索機能で活用 LINE 大量のログデータの一元管理とKibana連携による可視化 かみせんElasticsearch検証チームの様子 開発の未来に先手を打つための議論へ Elasticsearchの概要や機能の理解を経た後、今後どのような検証を行うべきかを、チーム内で議論しました。 その際、キーとなったのは、以下のポイント。 「Elasticsearchを調査・検証することで得られるMinimum Value とはなにか？」 そして、私たちが得た結論は、 『検索機能を有する新規サービスの アーキテクチャ 検討段階で、 RDB だけでなくElasticseachが比較検討材料として挙がる状態を作る』 となりました。 「比較検討材料として挙がる状態を作る」ために、Elasticsearchの得意分野である、 自然言語 で記述された文字列データを持つ、大量データを対象にした検索パフォーマンスを検証を行い、 RDB との比較を行うことにしました。 Minimum Value の検討風景 ※この画像は議論の途中経過のもので、最終的に至った結論ではありません SQL チューニングでは解決できない検索要件が生まれる未来に先手を打つための調査と検証に着手 現在、Minumum Value をアウトプットすべく、Elasticsearchのパフォーマンス検証を行っています。 検証対象のデータには、 Wikipediaの日本語版全データ を採用。 検証開始時点のでドキュメント数：2,339,123 件 下記の環境にストアして検証を実施中 Elasticsearch： Amazon Elasticsearch Service RDB ： Amazon RDS for PostgreSQL サーバーのスペック（メモリやノード数など）による変化や検索クエリの当て方など、どのような観点で検証を行うべきかについても議論をしながら進めています。 次回は、検証結果についてレポートさせて頂く予定です。 連載目次 『全文検索 〜 Elasticsearchとデータ匿名化手法』 『全文検索の探求 Elasticsearch(1) 』: プロジェクト方針およびElasticsearch概要 ←今読んでいる記事 大量データを検索するサービスでElasticsearchはRDBの代替候補になりうるか？(Elasticsearch vs pg_bigm)』 データ匿名化 第1回：匿名化された個人情報とは何なのか データ匿名化 第2回：個人情報は匿名化しても意味がないのではないか？ データ匿名化 第3回：個人情報を匿名化するプロセス データ匿名化 第4回：匿名化のために行うデータ項目の一般化とは データ匿名化 第5回：データ匿名化の指標 データ匿名化 第6回：実際の匿名化

初めまして、MasaKuです。 はいくる通信 第１回を担当させていただきます。 はいくる通信はこれから全４回にわたって記事を投稿していきますのでお楽しみに！ tech-blog.rakus.co.jp 第１回では、先日、弊社で開催した RAKUS Meetup Osaka の発表内容をもう少し掘り下げた記事を書きたいと思います。 rakus.connpass.com 発表資料は コチラ https://speakerdeck.com/masaku_2019/merumagapei-xin-sabisufalseyue-jing-puroziekuto-merudao-da-lu-xiang-shang-hefalsetiao-zhan speakerdeck.com はじめに：「メールが届かない」にはいろんな理由が 「メールが届かない」のパターン ガイドラインを整理してお客様にご提案する コンテンツチェックをしてお客様に修正をご提案する IPレピュテーションを良いスコアに維持する まとめ 参考サイト はじめに：「メールが届かない」にはいろんな理由が 普段なにげなく利用するメールですが、メールは送信すれば必ず届くとは限らず様々な理由で相手先に届かないことがあります。 そのため、メルマガ配信サービスにとって、どれだけメールを届けられるか（メール到達率）は重要な要素の１つです。 しかし、メルマガ配信サービスはメールを届けることだけが課題ではありません。 配信したメールが迷惑メールとして処理されずにメルマガ読者に読まれることも重要な要素の１つ です。 皆さんも、以下のような経験があるのではないでしょうか？ いたって普通の内容のメールが迷惑メールとして処理された 今まで普通にやり取りしていた方のメールが、突然迷惑メールとして処理された 時間をかけて作成したメルマガが迷惑メールになってしまっては本末転倒です。 お客様が望む「メールが届く」とは この課題はメルマガ配信サービスにとって重要な課題ですが、実は配信の仕組みやアプリケーション側の処理だけで解決することが難しい課題なのです。 「メールが届かない」のパターン メールが届かないということでお悩みのお客様には以下のようなパターンがあります。 迷惑メールと判定されるメールになっている 迷惑メールと判定されないように留意しているが、無意識のうちにメール内容が悪くなっている メールの内容も悪くないが、なぜか迷惑メールになってしまう 迷惑メールというと、 公序良俗 に反するような内容のメール（いわゆる スパムメール ）を想像すると思いますが、実はそれ以外の理由で迷惑メールと判定される場合があります。 配配メールではそういった課題をクリアするために、いくつかの施策を行っていますので、本日はそちらについてお話したいと思います。 ガイドライン を整理してお客様にご提案する スパムメール などのコンテンツが不正なメールは迷惑メールとして処理されることはご存じかと思います。 しかし、どのようなメールが迷惑メールになるかは、受信サーバごとに設けられたフィルタに依存するため完璧な対策をとることが難しいです。 そこで、配配メールでは少しでも多くのメールをメルマガ読者に届けるための メールを作成するための ガイドライン をお客様向けに展開しています。 メール到達率向上 ガイドライン 例えば、受信サーバ側でブロックされやすいキーワードは避けてメールを作成していただくことや、配信したメールの信頼性を高めるために SPF や DKIM の設定手順を案内する ガイドライン をご提供しています。 この ガイドライン は配配メールの顧客サポート部署が作成しております。 コンテンツチェックをしてお客様に修正をご提案する メール本文内のコンテンツが悪いと迷惑メールとして処理されることを知っていたとしても、意図せず ガイドライン に違反するメールを作成してしまう場合があります。 配配メールでは、メール本文内の情報を解析し、「迷惑メール」扱いになる可能性のあるグレーな内容を検知する仕組みを導入しています。 例えば、メール本文に「現金」と「稼」というキーワードが含まれたメールが配信されると、システム側で迷惑メールの疑いありと判断し本当に スパムメール かを直接チェックしています。 コンテンツチェックのフロー 迷惑メールになる基準は受信サーバ側の基準によるため、 システムが検知したからといって、直ちに スパムメール と判断せずに、顧客サポートチームが直接お客様へご連絡し、メール内容の修正の相談をしています。 地道な作業ではありますが、重要な課題と認識して、課題解決に取り組んでいます。 IPレピュテーションを良いスコアに維持する 最後に、これまでご説明したことがすべて守られているのに迷惑メールとして処理されてしまうことの対策です。 それが、 IPアドレス の信頼性（レピュテーション）という仕様です。 例えば、 スパムメール を頻繁に配信しているサーバは受信サーバ側から迷惑メール配信を行うサーバとして ブラックリスト に登録されてしまいます。 その結果、そのサーバから配信されるメールがブロックされてしまい、普通のメールすら届かないメールサーバになってしまいます。 迷惑メール配信を放置してはいけない理由 配配メールでは、迷惑メールとなるメールを配信し続けているお客様には、警告のご連絡をした後、それでも改善が見られない場合は別のサーバに移動していただく、という施策をおこなっています。 コンテンツ違反顧客の隔離 この施策により、コンテンツが正常なメールを配信されるお客様のメールが利用されるメール配信サーバの IPアドレス の信頼性は高い状態で維持することができます。 まとめ いかがでしたでしょうか？ メール配信サービスにおける「 メールを届ける 」とは、単純にメールを届けるだけでなく、メルマガ読者に「 読まれる 」ことが重要です。 そのためには、迷惑メールとして処理されないように様々な工夫が必要であることがご理解いただけたら幸いです。 はいくる通信では、これからもメルマガ配信についての記事を掲載していきます！ 次回もどうぞお楽しみに！ 参考サイト メルマガ配信・一斉メール配信サービス「配配メール」 https://speakerdeck.com/masaku_2019/merumagapei-xin-sabisufalseyue-jing-puroziekuto-merudao-da-lu-xiang-shang-hefalsetiao-zhan

はじめに こんにちは、新卒2年目のmrym_618です。 最近、 jQuery でスクロール位置の取得する方法を実装しましたが、なかなかうまくいきませんでしたので、そのときのことを書いていきたいと思います。 はじめに jQueryでスクロール位置を取得する方法 うまくいかなかったこと おわりに jQuery でスクロール位置を取得する方法 jQuery でスクロール位置を取得するには、「scrollTop()」メソッドを使用します。 「scrollTop()」メソッドの記述方法は以下の通りです。 対象要素.scrollTop(); ブラウザ全体のスクロール位置を取得するには対象要素に window を指定します。 $(window).scrollTop(); うまくいかなかったこと 今回は、対象要素に body を指定して実装していました。 すると、Edgeと Safari では、正しい値を取得できていましたが、 Chrome と IE と Firefox では、常に0を取得していました。 原因は、以下のサイトの通りブラウザによって「scrollTop()」メソッドが効くタグが違うことでした。 chaika.hatenablog.com そこで、そのサイトを参考にブラウザごとに対象要素を判定するように実装しました。 var ua = navigator.userAgent; var scrollTag; // Edge, Safariの場合 if(ua.indexOf('Edge') !== -1 || (!window.chrome && 'WebkitAppearance' in document.documentElement.style)) { scrollTag = 'body'; // Chrome, IE, Firefoxの場合 } else { scrollTag = 'html'; } おわりに 今回は、 jQuery でスクロール位置を取得するときに困った話について書きました。もし、同じようなことで困っていれば、この記事が参考になれば幸いです。 また、 jQuery には「scrollTop()」メソッド以外にもブラウザによって挙動が異なるメソッドはあると思うので、 jQuery で実装したときはしっかりマルチブラウザでテストすることを心がけていきたいと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは。新卒2年目のbadaikiです。早いもので後輩が配属され、社内の雰囲気がより明るく、より活発になっているように感じます。 目次 目次 はじめに デシジョンテーブルとは デシジョンテーブルの構成 メリット、デメリット 最後に 参考にしたサイト はじめに 今回はテスト手法の デシジョンテーブル について書いていきます。 最近は規模の大きな開発や複雑な仕様の開発を任せていただく機会が増えてきました。そのときに、複数の条件が複雑に絡み合うことによってテストケース作成時に「全パターンを網羅できているのか」が不安になる場面がありました。もちろん100%というのは難しいですが、漏れが起きにくいテストケース、自分が納得のいくテストケースを書くためにはどうすればよいのかを考えました。 まず初めに上記の不安の原因を現状把握も兼ねて分析しました。 同値分割、境界値分析は理解している つもり (単一の条件なら大丈夫) 完成したテストケースを見て網羅できているのかが読み取りにくい 省略したテストケースが本当に省略してよかったのか不安になる(必要なものを誤って省略していないかな…) 上記のような不安の原因になっているものに対して、何か不足している観点がないか、書き方を工夫することで補えないかと考え調べることにしました。そこで着目したのが デシジョンテーブル でした。 デシジョンテーブル とは デシジョンテーブル とは、決定表(JIS X 0125) 1 として規格が定義されています。論理関係を表形式で整理するためのツールで、行方向に条件と動作、列方向にルールを組合せます。プログラムの処理条件やポリシーなどをわかりやすく表現するために利用したり、ソフトウェアのテスト条件を整理するためにも利用されます。 以下を仕様としたときの デシジョンテーブル を例にして考えてみます。 ジムの利用料金の仕様 ・ クーポン持参の場合は10%OFF ・ 平日なら30%OFF ※ 複数の割引は併用できず、よりお得なものが優先される ジム利用料金の デシジョンテーブル デシジョンテーブル の構成 デシジョンテーブル は以下のような要素で構成されています。 条件記述部（condition stub） 条件記述部 考慮すべき条件・原因を列挙する部分です。 動作記述部（action stub） 動作記述部 考慮すべき動作・結果を列挙する部分です。 条件指定部（condition entry） 条件指定部 それぞれの条件・原因を特定の値・意味で指定し、ひとつのルールとして関連付けをします。条件指定部には以下のような書き方をします。 表記 ルールで関連付ける意味 Y（Yes） この行に対応する条件・原因が真であることを意味する N（No） この行に対応する条件・原因が偽であることを意味する 値、語句など この行に対応する条件・原因が記述された値であったり、語句を満たすことを意味する - この行に対応する条件・原因が無関係であることを意味する 動作指定部（action entry） 動作指定部 それぞれの動作・結果を特定の値・意味で指定し、ひとつのルールと関連付けをします。条件指定部には以下のような書き方をします。 表記 ルールで関連付ける意味 X（eXecute） この列に指定された条件・原因の真偽値にすべて適合する場合、この行に対応する動作・結果が生じることを意味する - この列に指定された条件・原因の真偽値にすべて適合する場合、この行に対応する動作・結果が生じないことを意味する 値、語句など この列に指定された条件・原因の真偽値にすべて適合する場合、この行に対応する動作・結果が記述された値であったり、語句を満たすことを意味する 規則 規則 条件・原因の組み合わせと、それに対する動作結果を組み合わせたものです。1つ1つがテストケースになります。 メリット、デメリット メリット 複数の条件が絡みあった組み合わせを明確にすることができる 網羅率が算出できる（ = 実施した規則数 / 全規則数） デメリット 順序を考慮できない 規則（テストケース）数が爆発的に増加する 例えば仕様に「月曜日なら女性は50%OFF（祝日は除く）」という仕様を追加します。 ジムの利用料金の仕様 ・ クーポン持参の場合は10%OFF ・ 平日なら30%OFF ・ 月曜日なら女性は50%OFF（祝日は除く） ※ 複数の割引は併用できず、よりお得なものが優先される ジム利用料金の デシジョンテーブル （仕様追加） すると、途端にケース数が増えることがわかります。ですが、曜日と性別が絡んでいる条件を追加したにも関わらず条件記述部は比較的シンプルなまま維持することができ、さらにテーブルになっているため空でテストケースを並べるよりも網羅性の確認が把握しやすいと感じました。 最後に 今回は デシジョンテーブル についてまとめました。 複数の条件が絡むテストケースでは観点がいくつも存在するため網羅できているのかが不安になります。 デシジョンテーブル を利用することで1つ1つの条件に分解し条件記述部を書くことができ、網羅性も確認しやすくなるため有用ではないかと思いました。ただし、テストケースが膨大になってしまうと作業コストがかかってしまうため、1つの画面の一部に用いるなど工夫が必要だと感じました。 テストの精度を高めるために、今後もツールや方法を学習し、実践し努めていきます。 参考にしたサイト softest.jp www.techscore.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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 規格検索結果 | 日本規格協会 JSA Group Webdesk ↩

はじめに こんにちは！今回は6月25日に行われたビアバッシュのご紹介をします。 今回のビアバッシュは翌日に行われたMeetupのリハーサルとLTの2部構成でした。 Meetupについては compass のページをご覧ください。 rakus.connpass.com 対象のMeetupは終了してしまいましたが、定期的にイベントを公開しておりますのでぜひご参加くださいね。 ではでは、LTのご紹介をしていきます。 はじめに 「は」メソッドis何 モナドな約束（Promise） デザインパターン勉強会 PHP7.4 Updates アウトプット駆動読書術実践入門 改善業務「全機能テストの自動化」 おわり 「は」メソッドis何 Scala 好きエンジニアが呟いた、「は」メソッド。「は」メソッドとはなんぞや？ といった疑問について Scala の記法の特徴とともに解説してくださいました。 Scala は省略記法も多く、私のように慣れない人から見るとわかりにくい部分もありますが、このように社内で共有してくださるので勉強が捗ります。 モナド な約束（Promise） モナド を通して、 JavaScript のPromiseの使い方や利用目的をわかりやすく解説してくださいました。 JavaScript で非同期処理を記述する際に、Promiseパターンは必ず目にするとは思いますが、初めてのうちはなかなかとっつきにくい部分があると思います。（少なくとも筆者はそうです） 別のもの（今回は モナド ）に置き換えて理解の助けとすることを、ぜひ自分の勉強の際にも活かしたいものです。 デザインパターン 勉強会 現在大阪で定期的に行われている社内勉強会、 デザインパターン 勉強会に参加した若手エンジニアが、最近学んだSimple Factoryパターンについて発表してくれました。 ベテラン PHP エンジニアのみなさんによって、若手の知識の幅がどんどん広がってきております。 PHP7.4 Updates PHP おじさん お兄さんが、最新のPHP7.4の機能について紹介してくださいました。 個人的にはTyped Properties のプロパティ型指定に興味を惹かれてしまいます。 ラク スの商材は PHP で作られているものも多いので要チェックですね。 アウトプット駆動読書術実践入門 読書内容について自己学習的な実践を行って内省し、その結果をアウトプットすることでコンパクトに経験学習を行える アウトプット駆動で読書することは、非アウトプット駆動な読書を周回遅れにするほどの自己成長を高める効果がある（かもしれない） 知識を 仕入 れてできる気になったはいいものの、いざ仕事に活かしてみると上手くいかないってことが多々あります。 公開されているスライドで発表者が参考にした情報や書籍も記載されているので、気になる方はどうぞ。 speakerdeck.com 改善業務「全機能テストの自動化」 若手エンジニアが、全機能テストの自動化をpuppeteerを用いて頑張っている話をしてくれました。 リリースサイクルを早めるため、テスト時間を短縮するために自動化に取り組んだ際の手法や難しさについて赤裸々に語ってくれました。 おわり 最近ではビアバッシュの発表者も増加傾向にあり、内容も多岐に渡り非常に聴きごたえがあるものとなっています！！ 今後もビアバッシュの内容はブログに掲載していくので、どうぞお楽しみに！！

はじめに こんにちは、2年目になったyk_itgです。 今回は postgreSQL でindexを利用した時、どれだけ検索速度が上がるのか調べてみよう…としたのですが、うまくindexを使ってもらえませんでした。今回はその時のことを記事にしたいと思います。 なお、この記事では postgreSQL でindexを作成した時のデフォルトであるB-tree indexを使用していることを前提としています。 はじめに 検証バージョン さっそくindexを作ってみた いざ実行 使われない理由 一つ目の理由 二つ目の理由 感想 参考 検証バージョン postgreSQL 11.4 さっそくindexを作ってみた とりあえず、indexを貼るテーブルが必要です。 大量データがないと効果がわからないと思ったので、こちらの記事を参考に100万件のレコードを持つテーブルを作ってみました。 tech-blog.rakus.co.jp CREATE TABLE indexTest ( id integer PRIMARY KEY, name text ) INSERT INTO indexTest (id,name) SELECT i, format('text%s', i) FROM generate_series(1,10000000) as i ; このテーブルにCREATE INDEXしてindexを作ってみます。 CREATE INDEX ON indexTest (id); CREATE INDEX ON indexTest (name); explain_test=# \di List of relations Schema | Name | Type | Owner | Table --------+--------------------+-------+----------+----------- test1 | indextest_id_idx | index | postgres | indextest test1 | indextest_name_idx | index | postgres | indextest (2 rows) いざ実行 では実際にindexを貼ったテーブルに対して検索をかけてみます。 ただ、検索が速くなるといっても目視ではさっぱり違いがわからないのでEXPLAINを使います。 EXPLAINを使うとコストとどんな方法を使って検索しようとしているのか調べることができます。 Indexが利用されている場合には、Index ScanやIndex Only Scanなどのindexを使っていることを示すEXPLAIN 演算子 が実行計画に表示されるはずです。 早速先ほどindexを張ったnameのカラムを検索条件に入れて検索してみます。 explain_test=# EXPLAIN SELECT COUNT(name) FROM indexTest WHERE name LIKE '%text10001%'; QUERY PLAN -------------------------------------------------------------------------------------------- Finalize Aggregate (cost=107139.59..107139.60 rows=1 width=8) -> Gather (cost=107139.38..107139.59 rows=2 width=8) Workers Planned: 2 -> Partial Aggregate (cost=106139.38..106139.39 rows=1 width=8) -> Parallel Seq Scan on indextest (cost=0.00..106138.33 rows=417 width=11) Filter: (name ~~ '%text10001%'::text) (6 rows) あれ？indexが使われていないようですね。 Index Scanではなく、テーブルを順番に見ていくSeq Scanが表示されています。 試しに検索条件をidに変更してみます。 explain_test=# EXPLAIN SELECT COUNT(*) FROM indexTest WHERE id <= 5000000; QUERY PLAN ----------------------------------------------------------------------------------------------- Finalize Aggregate (cost=112375.23..112375.24 rows=1 width=8) -> Gather (cost=112375.01..112375.22 rows=2 width=8) Workers Planned: 2 -> Partial Aggregate (cost=111375.01..111375.02 rows=1 width=8) -> Parallel Seq Scan on indextest (cost=0.00..106138.33 rows=2094672 width=0) Filter: (id <= 5000000) (6 rows) が、やはりindexは使われないようです。 使われない理由 一つ目の理由 一つ目の理由は前方一致以外のLIKEを使って検索しているためです。 B-treeのindexを使用した場合は、文字列の前半についてしか検索を行えません。 なので、前半が検索条件である前方一致の検索ではindexを使用してくれます。 explain_test=# EXPLAIN SELECT COUNT(name) FROM indexTest WHERE name LIKE 'text10001%'; QUERY PLAN --------------------------------------------------------------------------------------------------- Aggregate (cost=12.27..12.28 rows=1 width=8) -> Index Only Scan using indextest_name_idx on indextest (cost=0.43..9.77 rows=1000 width=11) Index Cond: ((name >= 'text10001'::text) AND (name < 'text10002'::text)) Filter: (name ~~ 'text10001%'::text) (4 rows) 実行計画を見てもしっかり Index Only Scanが表示されています。 二つ目の理由 二つ目の理由は検索条件に当てはまる行数が多すぎるためです。 当てはまる行数が多すぎる場合には、indexを使って検索するよりもテーブルを順番にみていくほうが速くなります。 explain_test=# EXPLAIN SELECT COUNT(*) FROM indexTest WHERE id <= 3700000; QUERY PLAN --------------------------------------------------------------------------------------------------------------------------- Finalize Aggregate (cost=110081.60..110081.61 rows=1 width=8) -> Gather (cost=110081.38..110081.59 rows=2 width=8) Workers Planned: 2 -> Partial Aggregate (cost=109081.38..109081.39 rows=1 width=8) -> Parallel Index Only Scan using indextest_pkey on indextest (cost=0.43..105174.50 rows=1562752 width=0) Index Cond: (id <= 3700000) (6 rows) このように検索条件に応じて適切なプランをデータベースは絞り込んでくれます。 感想 indexを使えばどれくらい速くなるのかは検証することができませんでしたが、indexの仕組みや実行計画について触れることが出来ました。 どんどん触れる機会が増えていくと思うので、今後もデータベースの仕組みを学んでいきたいと思います。 参考 [MySQL]WHERE句でLIKEを使っている場合のINDEX | DayByDay PostgreSQLクエリ実行の基礎知識 ～Explainを読み解こう～ 【SQL】インデックスの基本知識まとめ - Qiita B木 - Wikipedia エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

id:radiocat です。 配配メール ／ クルメル の開発チームでは、我々の取り組みを多くの方々に知ってもらうため、 ブログ連 載プロジェクトを発足させました。写真はキックオフの様子です。まずはメンバー同士で期待値をすり合わせるために ドラッカー 風エクササイズなどを行い、その後みんなで投稿テーマのア イデア を出しました。 キックオフの様子 メール配信を支える技術とノウハウをアウトプットしたい メール配信を取り巻く IT技術 やお客様のビジネスはいまだに日々進化を続けています。 迷惑メールなどでネガティブなイメージがあり利用に消極的な声も聞かれるメール配信ですが、現在でも多くの人がメールを見てショッピングするなどの形で生活へ活用しており、ビジネスにも利用されています。また、メール配信の仕組みは複数の通信キャリアやプラットフォームを跨ぐ複雑なシステム基盤上に構築されており、様々なメールの種類と配信方法で成り立っています。 そんな中で、私たちはお客様のビジネスを成功へ導くために、1通でも多くのメールをお届けできるよう日々努力を続けています。社内でも普段はあまり語られることのないメール配信の裏側ついて配配メール／クルメルの開発を担当しているエンジニアが現場から発信することで、メール配信に興味のある人や普段このブログをご覧頂いているエンジニアのみなさんに少しでも興味をもって頂ければと思い、プロジェクトを発足させました。 まずは第一弾として、4人のメンバーが以下のテーマを1つずつ担当し、投稿記事を検討中です。 メールを到達させる カイゼン 業務の取り組み 6/26の『RAKUS Meetup Osaka カイゼン Night』に登壇させていただいた久山です。 メルマガ配信サービスにおいて、メールを配信できたかどうかは非常に重要です。そのため、配配メールにおいてもメール到達率を向上させるために、いくつかの施策を行っています。しかし、開発者が想定しているメール到達率は、お客様が期待している到達率とギャップがあることに気づきました。 私が担当する記事では、先日発表した『RAKUS Meetup Osaka カイゼン Night』の資料をベースに、 システム開発 者の立場では気づきにくい到達率の本質的な側面についてお話できればと思います。 多種多様なプラットフォームに対応するためのメールの種類 中野です。私がお届けするテーマは「メールの種類について」です。 メール配信には、HTMLメールやテキストメール、多言語メールなどの、様々な種類のメールがあります。ふだん皆さまのお手元に届いているメールの種類とそのメールが送られてくる仕組みを知って頂けるように、わかりやすくてライトな記事を執筆していきます。 皆さまにとって有益な情報をお届けできるようがんばりますので、ご期待ください！ メール マーケティング を支える配信方法 ニャンです。2014年に ラク ス ベトナム へ入社しました。 去年の8月に日本に来て配配メールのメンバーと一緒に仕事をしています。 お客様にとって、 マーケティング の方法がいろいろあって、それに合わせた配信方法を選びます。私の投稿では、配配メールでお客様が選べる マーケティング の方法とメールの配信方法をご紹介します。どうぞ楽しみにお待ちください。 キャリアメールの今までと今後 小林です。ディズニーとフュギアをこよなく愛するアラフィフ目前の開発リーダーです。昨今、携帯電話はフューチャーフォンから スマートフォン に変化し、キャリアメールについても変化してきました。 デコメール ・ スマートフォン のHTMLメールなど、今後メールの仕様がどう変わっていくのかを書きたいと考えています。 近日中に順次投稿予定 メール配信に関わる人も、そうでない人も、楽しんで頂けると幸いです。第1回の記事まで、もうしばらくお待ちください。