2021-04-30

『ITIL はじめの一歩スッキリわかるITILの基本と業務改善のしくみ』を呼んだ

はじめに

ITILとかITSMってよく聞くし、システム開発に携わる者としてはある程度知っておかないとと思って数年が経っていた。
たまに「ITSMとは」とかでググってみるものの、「5つのカテゴリがあって云々」みたいな上辺だけの説明で、つまりどういうこと？？という気持ちだった。
というわけで初心者にもわかりやすい本はないかなーと調べて、この本を読んでみたので感想とメモを書き下す。

ITIL はじめの一歩スッキリわかるITILの基本と業務改善のしくみ

作者:最上千佳子
発売日: 2019/03/11
メディア: Kindle版

読書メモ

全体概要

「ITIL・ITSMって何？」という疑問に対して、ITとは別の業務を通して解説してくれる本。
前半は八百屋だったりとか旅館の業務でITIL的要素を取り込んでみたらどうなる？のストーリー仕立て。
後半はもう少しITILに踏み込んで解説。

自分の言葉でITILの中身をまとめると↓な感じ。あってるかな。
お客様への価値提供を継続的に行うために、サービス提供に関わることすべて（サービスそのもの、将来の計画、お金、サービス提供の仕方、トラブル関連等々）をいい感じに管理すること。そのベストプラクティス。

読みながらとったメモ

ITIL（Information Technology Infrastructure Library）とは「ITサービスマネジメントのベストプラクティスをフレームワークとしてまとめた書籍群」 = 「IT（情報技術）を本当の意味でビジネスに活かすための世界中のノウハウをまとめたもの」
- ITに限らず、「サービス」を提供するものであればなんでも適用できる（多分）
ITILが重視しているのは「お客様に価値を提供し続けること」
- お客様にとって価値のあるものを、継続的に提供できるかどうか
サービス: 顧客が特定のコストやリスクを負わずに達成することを望む成果を促進することによって、顧客に価値を提供する手段
- サービスの価値:
  - 有用性：目的に適していること
  - 保証：使用に適していること
「お客様の求める価値」を提供し続けるためには見える化→PDCAサイクルの流れが必要
- プロダクト（良いモノ）ではなくマーケット（顧客の望むもの）を意識したサービス開発→ヒアリングのサイクルを回す
計画的にサービス提供をするための6つの管理（サービスストラテジ / サービスデザイン）
- 需要管理: 需要予測とか、顧客はどんなモノ（コト）を望んでいるか
- サプライヤ管理: 協力会社とか
- サービスカタログ管理: お客様に提供しているもの（外部向け資料）
- サービスポートフォリオ管理: 自分たちの持つサービス（未来含む）。中長期的な投資対象を見極める（内部向け資料）
- キャパシティ管理: 需要に対してどれくらい供給できるか（量）
- 可用性管理: 需要に対してどれくらい供給できるか（質）
安定したサービス提供をするための7つの管理（サービストランジション / サービスオペレーション）
- インシデント管理: 何かトラブルが発生したときにどうするか
- 問題管理: トラブルの根本原因をどうするか
- 要求実現: 顧客の求めていることはなにか、それをどう実現するか
- リリース管理及び展開管理: 新しいサービスとかをどうやって実装するか
- 変更管理: サービスの何をどう変更するか（多角的な視点で判断する）
- サービス資産管理および構成管理: サービスの構成要素はなにか
- ナレッジ管理: 属人化の排除/チームとしてのノウハウ蓄積
「管理」ってどうしたらええねん
- プロセスを定める（標準化）
- 組織に展開する
- データを集める
- 改善していく
あらゆる組織は「戦略層」「戦術層」「運用層」の3つで構成される。
- 戦略層: 組織の中長期的な方向性とリソース配分を決める層
- 戦術層: 戦略を実現するための具体的な施策（計画）を立案する層
- 運用層: 戦術層で決めた施策を実際に実施して実現する層
ITILはこの3つの層をベースに、サービスライフサイクルを以下の5つに分類している。これを継続的に回す。
- サービスストラテジ
  - 顧客との友好な関係性を築く。お客様（IT部門からしたら事業部門）が何を考えているかを理解する
  - サービスに対する需要を理解する
  - コストを管理する（予実管理、課金）
  - 投資計画を立てる
- サービスデザイン
  - 具体的な計画をたてる
  - サービスレベルを設計して合意する
  - 最新のサービスカタログをメンテする
  - 必要な可用性を定義する
  - キャパシティを定義する
  - リスク・セキュリティを管理する
  - サプライヤを管理する
  - 上記をきちんと調整する
- サービストランジション
  - 新しいもの・変更したものをうまいこと運用に乗せる
  - 変更管理・リリース管理・構成管理
  - 属人化の排除
- サービスオペレーション
  - サービスを実際に提供する
  - 問い合わせとかに迅速に対応
  - インシデント対応
  - 根本解決
  - イベント（正常/異常）管理
  - アクセスを管理する
- 継続的サービス改善
  - PDCA
  - 「目標の設定」「測定項目の定義」「収集」「処理」「分析」「提示」「実施」の7つのステップで、改善活動を推進する
  - CSI（Continual Service Improvement）: 長期的な目標（ビジョン）に対して、構造的に改善プロセスを回す
ITILは進化し続けている。
- 2011年に発表された「ITIL 2011 Edition」から、2019年頃から「ITIL4」に切り替わってる
- ITIL4: DXとかSOR（System Of Record）→SOE（System Of Engagement）への転換などが反映された
- いまもバージョンアップは続いてる

感想

ITILってたぶん特別なことではなく、SIerだったら1年目とかの研修とかトレーナーからのアドバイスで知ることだなと思った。たぶんそれをもっと体系化したもののことなんだと理解した。
たぶん自分が新卒で研修を受けていたときは「ITIL」「ITSM」って言葉は使われてなかったように思う（聞いてなかっただけかもしれないけど）。でもリリース管理とか変更管理、問題管理なんて言葉は聞き馴染みがある言葉だった。
ITILに従ってすべてのシステムが運営されてるってことはないし、100%従わなきゃいけないというよりは自分の環境に合わせてある程度カスタマイズするんだろうけど、「これが今考えうるベストプラクティスなのだ！」を理解するのは大切なことだと思う。なのでこの本に限らず継続的に勉強したほうがいいな。
資格制度もあるし、挑戦してみてもいいかもしれない。

また、前半はIT業界で働く人以外でも読みやすいし、学びになることは多そう。妻に勧めたい。

2021-04-11

Professional Data Engineerに合格した

まえがき

GCPの認定資格であるProfessional Data Engineer（PDE）に合格したのでそのレポートを書く。
8月くらいにProfessional Cloud Architect（PCA）に合格してちょっと自信がついたのと、業務でBigDataを扱っているので、PDEもいけるんじゃね？と勢いで受験した。
受けてみて思ったのは、普段の業務とは異なる領域の問題が多く、結構つまづいたということ。
どなたかの参考になれば。

筆者のプロフィール

データ分析基盤の開発・運用（4年くらい）
- Redshift / BigQueryがメイン
運用業務（マート作成ジョブの維持管理とか）がメインのお仕事
たまにパイプライン周りの開発したりする

試験の概要

公式サイト
- Professional Data Engineer
受験料
- $200
受験方法
- テストセンターorリモート試験

勉強内容

大まかに以下の流れで勉強した。

とりあえず公式の模擬試験を受ける
Qwiklabs / Coursera / 本 / 公式ドキュメントで座学&実践
公式の模擬試験でそこそこ取れるようになったらUdemyの試験問題集をやってみる
Udemyでつまずいたところを公式ドキュメントで確認

詳細を書いていく。

公式の模擬試験

GCPの認定資格試験はたぶんだいたい公式の模擬試験がある。なのでこれをまずはやってみる。
PCAのときは全然自信がなかったので本を読むところから始めたけど、今回はBigData周りの業務経験そこそこあるしイケるやろ、の精神で最初にやってみた。
結果は確か6割くらい。まあまあだったと思う。
ここで特に確認したかったのは試験範囲の確認。思ったよりも機械学習系の問題が出ていて、業務でそのあたりはほとんど触らないのでわからないことだらけだった。
あとはHadoop周りとか。BigDataはRedshiftから触り始めたので、Hadoopとかよく知らない。このあたりも弱いなと感じた。

Qwiklabs / Coursera / 本 / 公式ドキュメントで座学&実践

とりあえず触ったことないサービスが色々あるので、Qwiklabsでハンズオンをやった。

Data Engineering
- 他にもやったかもしれないけど忘れた。

Qwiklabsは一通りの操作を学べるので取っ掛かりとしてはとても便利。

Courseraもやった。こっちはハンズオンも少しはあるけど、基本はオンライン講義という感じ。
基本英語なのでスクリプトをDeepL等々で機械翻訳しながら動画を見る感じ。
集中しないとおいていかれるので結構疲れるけど、文字だけだと頭に入りにくい自分としてはかなり役に立ったと思う。

Google Cloud Platform Big Data and Machine Learning Fundamentals
- 本当はData Engineering, Big Data, and Machine Learning on GCP専門講座を全部やりたかったけど疲れたので諦めた

本については以下が特に役に立ったと思う。PDE向けの勉強をしているときに出版されて渡りに船って感じだった。
業務ではリアルタイム連携とかはやってないので、そのへんの知識をこの本で補完できたのが大きい。ウィンドウの考え方とか。

Google Cloudではじめる実践データエンジニアリング入門[業務で使えるデータ基盤構築]

作者:下田倫大,寳野雄太,饗庭秀一郎,吉田啓二
発売日: 2021/02/18
メディア: Kindle版

ck-fm0211.hatenablog.com

試験では「XXXをやりたい。A/B/C/Dどの選択をすべきか？」みたいな問題が出る。
分析ならBigQueryだよね、みたいなみたいな脊髄反射で答えられる一方で、じゃあなんでBigQueryはそんなにいいんだっけ？みたいな疑問に答えてくれる本だと思う。
試験対策としてはさらっと読むくらいでいいけど、きちんと理解する上ではかなり有用だった。

公式ドキュメントは言わずもがなだけど、各サービスのベストプラクティスとか制約事項、BigTableとFirestoreってどう使い分けるんだっけ？みたいなこととかはここで学習・確認した。

Udemy

一通り勉強して、模擬試験でもそこそこ取れるなって状態になったらUdemyで模擬試験を探して受けてみた。
問題数に慣れるっていうことと、いろんなユースケースを見せてくれるので便利。
これも英語がメインなので、Chromeの自動翻訳で日本語に変換して受けた。

Google Data Engineer Certification Practice Exams

機械翻訳なので問題の意味がよくわからなかったり、そもそも回答あってるかこれ？？みたいなものもあるけど、自分の知識・理解が及んでいない部分が明らかになっていくので、理解度チェックの意味で役立った。

上記以外

模擬試験・Udemyを通して機械学習周りの知識が圧倒的に足りてないなと実感した。
せめて各用語はちゃんと理解したほうがいいなということで書籍でも読もうかなと思ったけど、これに気がついたのが試験2日前とかだったので、ひたすらわからない言葉をググり倒して用語集的なものをぱぱっと作る程度しかできなかった。
それでも、例えば「機械学習モデルがテストデータではいい感じだったのに検証データではイマイチな結果を出した。どうする？」みたいな問題に対して「これは過学習！進oゼミでやったやつだ！」みたいなノリが通せるくらいには詰め込んだ。

試験当日

テストセンターで受けた。
リモート試験もやってみたいんだけど、PCだけがある小部屋を用意しなきゃいけない？と聞いていて、結構ハードル高いなと思ってやってない。

試験自体は2時間で50問。1時間で一通り回答して、見直しして1.5hくらいで回答を提出。
その場で合否が分かる感じ。結構自信がなかったけど、なんとか合格した。
Googleから後日ちゃんとした合格通知が来るんだけど、それまでは半信半疑でちょっとビビってた。その様子がTwitterから見て取れる。

4/1だから嘘つくけど、Professional Data Engineer合格した
— C.K. (@ck_fm0211) 2021年4月1日

実際の試験の難易度は 公式模擬試験 < 本番 < Udemy という感じ。Udemyでそこそこ取れてればなんとかなりそう。
とはいえUdemyの問題はどこぞの人が作ったニセモノなので、公式ドキュメント等での知識の補完だったりは必要な感じだった。やっといてよかった。

まとめ

一発合格できてよかった。
というか本当に、タイムリーに参考書が出てくれたのがありがたかった。日本語の本も増えてきているので、今後資格は取りやすくなるかもしれない。
資格の有効期限は2年とかなので、維持するためにはまた2年後に受けなきゃいけない。やる気があれば受けよう。

GCPの資格をこれで2つ手に入れたので、次はAWSとかAzureに手を出すのもありかな。
Azureは触ったこともないので苦労しそうだけど、色んな人に話を聞くと使ってる案件は多そうなんだよなあ。データ分析界隈だとあまり聞かないけど。

2021-03-07

初めてOSSにプルリクエストを出した

OSSにプルリクエストを出したのでそのやり方とか感想とか。
なお出したプルリクエストはこれ。

経緯

業務でS3からBigQueryへ入れる方法を模索していた。
その際に embulk-output-bigquery プラグインを見つけ、使おうかなと思って検証したところ、ジョブの実行プロジェクトとデータロード先のプロジェクトが一致していないと使えないということが判明。
自分のいる環境ではジョブ実行プロジェクトとデータロード先プロジェクトを分けているため、このままでは使えなかった。

結局、業務では別の方式を取ることになったのだけど、プラグインのどこを直せばいいかとかなんとなく見えてたのもあり、せっかくだからとプルリクエストを出してみることにした。

準備

とりあえず「OSS プルリクエスト」とかでググってやり方を調べた。

CONTRIBUTING.mdがあればそれに従えとのことだったが、このリポジトリにはそれがなかった。
なのでとりあえず

Issueを作る
forkしてローカルで開発・テスト
プルリクエストを出す

の流れでやることにした。

Issueを作る

過去のIssueを見ると（当然？）英語で書いてあるのでDeepLを駆使してIssueを作成した。

やりたかったのは実行プロジェクトとデータロード先のプロジェクトをわけること。
「実行プロジェクト」って英語でなんて言えばええんや？と迷い billing project と呼ぶことにした。
これは後に微妙に失敗だったと気づいた。

forkしてローカルで開発・テスト

自分のアカウントにリポジトリをforkしてコードを書き直した。
Rubyは業務でほぼ使ってないし、昔Railsの本を1周したくらいの知識しかないので地味に苦労した。
直すところは明確だったが、環境の作り方とかテストの動かし方で四苦八苦した。
テスト方法はREADME.mdに書いてあったのでそのとおりに進めたのだけど、途中で依存関係のエラーにハマったりと時間がかかった。

テストコードの中身もパッと見でなにやってるかよくわからなかったので、

コード直す
テストコード全部動かす
落ちたところ見てコード直す
2-3を繰り返してテストの流れを把握する
追加したコードに合わせたテストを追記する

の流れで対応した。

ここで一番ハマったのは、どう考えても今回直したものと関係ないところで落ちてるテストがあったこと。
なんだなんだとこねくり回した挙げ句、もしやと思いmasterブランチでテストを実行したところ、何も変えてないのに落ちた。始めからテスト通ってなかった。
なんでやねんと思いつつ、そこは諦めてそれ以外でテストが通ることを確認してプルリクエストを出した。

プルリクエストを出す

ここでもDeepLを頼りに英語を書いた。
今回プルリクエストを出したリポジトリはtravisでCIが組まれていたのでその様子を見守る。
どうも前述の依存関係でコケたようなので追加でcommitしておいた。

感想

意外と簡単だった。
OSS活動（とこれを呼んでいいかはわからんけど）は高尚な活動だから自分なんかが手を出してはいけない、という思いがあったりもしたけど、やってみると意外と簡単なもんだなという感想。
今後も機を見てチャレンジしてもいいなと思った。

ただ、今回プルリクエストを出したリポジトリは長期間動いてなさそうなので、マージされることはないかもしれない。

2021-06-28追記 version 0.6.6にマージされた！うれしい。

Appendix: 依存関係の解消

テスト実行をしたとき、以下のようなエラーが出た。

*******************************************************************************************
Running Embulk version (0.9.23) does not match the installed embulk.gem version (0.10.26).

If you use Embulk v0.9.* without Bundler:
   Uninstall embulk.gem from your Gem path.
   An embulk.gem-equivalent should be embedded in your Embulk's core JAR of v0.9.*.

If you use Embulk v0.9.* with Bundler:
   Try updating your Gemfile as below:
     gem 'embulk', '< 0.10'
   Bundler will find the embulk.gem-equivalent embedded in your Embulk's core JAR of v0.9.*.

If you use Embulk v0.10.*:
   Be aware that v0.10.* is an unstable development series. If you are aware of that,
   upgrade it to the latest v0.10.*, and use exactly the same version of embulk.gem.
   In case you use Bundler, your Gemfile should have 'embulk' as below:
     gem 'embulk', '0.10.XX'  # Exactly the same version of your Embulk's core JAR.

If you use Embulk v0.8.* or earlier:
   Update to the latest v0.9.*. v0.8 or earlier are deprecated.
*******************************************************************************************

なんじゃこりゃあという気持ちだったが、落ち着いてググってみると単なる依存関係の問題だった。
Gemfileを以下のように書き換えることで対応ができた。

- gem 'embulk'
+ gem 'embulk', '< 0.10'

2021-03-01

『たった一人の分析から事業は成長する実践顧客起点マーケティング』を読んだ

この本を読んだ。その感想とメモ。

たった一人の分析から事業は成長する実践顧客起点マーケティング（MarkeZine BOOKS）

作者:西口一希
発売日: 2019/04/08
メディア: Kindle版

読書メモ

著者略歴をAmazonから引用。

西口一希（にしぐちかずき）大阪大学経済学部卒業後、P＆G入社。マーケティング本部に所属、ブランドマネージャー、マーケティングディレクターを歴任。2006年ロート製薬　執行役員マーケティング本部長。スキンケア商品の肌ラボを日本一の化粧水に育成、男性用ボディケアブランドのデ・オウを開発、発売1年で男性用全身洗浄料市場でNo.1に育成するなど、スキンケア、医薬品、目薬など60以上のブランドを担当。2015年ロクシタンジャポン代表取締役。2016年にロクシタングループ過去最高利益達成に貢献し、アジア人初のグローバルエグゼクティブコミッティメンバーに選出、その後ロクシタン社外取締役戦略顧問。2017年にスマートニュースへ日本および米国のマーケティング担当執行役員として参画、累計ダウンロード数5,000万、月間使用者数2,000万人を達成、2019年8月に、企業評価金額が10億ドル（約1,000億）を超える国内3社目のユニコーン企業まで急成長。2019年9月スマートニュースを退社しマーケティング戦略顧問に就任、Strategy Partnersの代表取締役およびM-Force株式会社を共同創業者としてビジネスコンサルタント、投資活動に従事。

本書では著者の成功体験から導き出されたマーケティングフレームワーク「5セグマップ」「9セグマップ」「N1分析」について、事例を交えながら解説。
某Twitterでデータ分析界隈の人が紹介していたので、マーケティングとかは門外漢だが読んでみた。

配信で紹介した書籍です

①顧客起点マーケティング https://t.co/DzXv5DnjcG

②ビッグデータ分析の(略)教科書https://t.co/Mm8gI4DLjx

③データマネジメントが30分でわかる本https://t.co/GKIopI8I4u

④まりこふんの古墳ブックhttps://t.co/tCPiTvFG7m

⑤SOFT SKILLShttps://t.co/P2qFL0NPD2
— ゆずたそ (@yuzutas0) 2021年2月23日

章立てとサマリ

章立てとしては以下の通り。それぞれにかんたんな要約をつけてみる。

序章: 顧客起点マーケティングの全体像

9つのセグメントに顧客を分類し、その１つ１つで特定の顧客（N=1）へ注目する。そこを起点とした深堀りで「アイデア」を導き出す。
- 例：ロート製薬の肌ラボを使用者はどう思っていたか。そのポジティブな感情を訴求ポイントとしてマーケティングできていたか。

第1章: マーケティングの「アイデア」とN1の意味

マーケティングにおけるアイデアとは「独自性（Only-One Uniqueness ≒ 差別化）」と「便益」の掛け合わせである。
さらに「プロダクトアイデア（商品そのもの）」と「コミュニケーションアイデア（広告・顧客へのリーチ）」が組み合わさる
- プロダクトアイデア
  - 例１：登場初期のiPhoneは独自性=便益である
  - 例２：風邪薬は共通して「風邪を治す」という便益を提供している。そこに「oo配合」といった独自性を含めることで訴求できる。
- コミュニケーションアイデア
  - プロダクトアイデアは追従する商品によりコモディティ化する。これを回避するためのアイデア。
  - コミュニケーションアイデアは独自性で注目を集めたとしても、プロダクト自体に魅力（独自性x便益）がないと意味がない。
最重要はプロダクトアイデアの便益である。これが強くないとどんな広告をだしても顧客には響かない。
上記を更に強化するためには「早期認知形成」も重要である。その市場においてはじめに広く認知されることで優位性を持てる
- 例：中国におけるBaidu等。Googleとサービスは似通っているが、Googleの認知が中国内で広まる前にシェアを独占できている。
統計的な調査はあくまでも最大公約数である。突出したアイデアはN=1からこそ得られる。
- N=1から得たアイデアをマクロな視点で検証する

第2章: 【基礎編】顧客ピラミッドで基本的なマーケティング戦略を構築する

顧客ピラミッド（ロイヤル顧客/一般顧客/離反顧客/認知・未購買顧客/未認知顧客）を作成し、セグメントごとにN1を抽出、インタビューを行う。
RFM分析は現状の分析であり、これはロイヤル・一般購買層が入る。短期的には良いかもしれないが、中長期的には離反・未認知層も含めて分析する必要がある。
- RFM分析: Recency（直近の購買）/Frequency（購買頻度）/Monetary（購買金額）
行動データだけではなく心理データにも注目する。アンケートも有効ではあるが、深層心理まで踏み込むにはN1分析が必須。
- アンケートで好印象を得られたとしても、それがどこから生まれたものなのかを深堀りする。
- 例：肌ラボは「ベタつき=保湿の証拠」であったが、ベタつきを嫌う顧客がいた。
  - 「ベタつき＝保湿の証拠」を強く売り出すことでロイヤルを育て、一方でベタつきが弱いバージョンを作ることでベタつきを好まない人への訴求も行った
  - 心理データ（ベタつきの意味を理解しているか、そもそも好きじゃないか）を分析することで適切なアプローチを行えた
N1分析をしてカスタマージャーニーマップを作成した上で、、セグメントごとに異なる戦略と具体的なマーケティングを立案していく
- 実在しない顧客のジャーニーやペルソナではなく、N=1で実在する顧客から情報を抽出する。
- アイデア=WHATから始まり、WHO=N1を特定、心理データからWHEN/WHERE/HOWを見出す。
分析は自社だけではなく強豪に対しても行う。アンケート等で得られた定量的な情報を自社とのクロスで評価（オーバーラップ分析）することで、カテゴリ自体のチャンスや新規事業開発の兆しを掴むことができる。

第3章: 【応用編】9セグマップ分析で販売促進とブランディングを両立する

顧客ピラミッドの「未認知顧客」以外をブランディング軸でわけ、全部で9つのセグメントに分割する。
9セグマップ分析で販促とブランディングを同時に計測する。
- ブランディング=選好。次もそのブランドを選ぶかどうか。
ブランディングは計測可能であり、時系列でトラッキングする。
- その分析にもN1分析を活用する。
- 顧客は9セグマップの中を移動し続ける。それを見逃さない。

第4章: 【ケーススタディ】スマートニュースのN1分析とアイデア創出

スマートニュースの事例。
- プロダクトアイデアに独自性があることを競合を含めたアンケート調査で確認。
- オーバーラップ分析で狙い目ポイントを特定。
- N1分析でプロダクトの強み・弱みを確認し、アイデアを創出
- これまでの分析で把握した未認知層への訴求のためにTVCMを実施。

第5章: デジタル時代の顧客分析の重要性

デジタル化によりマーケティングのスピードも急速に上がっている。
- プロダクトアイデアを完成させず、磨きながらサービス提供を続ける。
  - 例：AARRR（アー）モデル。ユーザー行動を以下の５段階に分け、リアルタイムデータで可視化・分析し、プロダクトアイデア自体を変数の組み合わせとして捉える。
    - Ａ（Acquisition ユーザー獲得）
    - Ａ（Activation 商品使用とユーザー活動の活性化）
    - Ｒ（Retention 継続使用）
    - Ｒ（Referral 他者への紹介や推奨）
    - Ｒ（Revenue 収益化）
- 顧客の行動分析もリアルタイムにできてしまう世界。
一方で心理分析はデジタルの苦手分野であり、N1分析は今後も有効である。
最重要は変わらずプロダクトアイデアの独自性であり、それは今後さらに顕著になる。
- 便益やコミュニケーションアイデアはデジタル世界では素早く移り変わる。

感想

率直な感想としては「マーケティングって面白そう」。成功事例だからだろうが、パズルみたいで面白そうだなと思った。
自分自身はマーケティングについては門外漢なのでここで紹介された手法が目新しいものなのか、いまさら何いってんのみたいなものなのかはわからないが、周りのサービスに当てはめて考えてみるとなるほどなと思えるものが多かった。

たとえば自分は楽天経済圏で生活している。
楽天経済圏のプロダクトアイデアは「使いやすいポイント」である（と思う）。他のポイント（Tポイント：yahooやポンタポイント：リクルート/au）とは何が違うかを考えてみると、楽天経済圏には生活する上であらゆるサービスが含まれている。EC/リアルの買い物（ペイ）/旅行/クレカ/証券etc...
それらを全部使うとポイントが非常に溜まりやすくなる。さらにそのポイントをどう使うかまで示されている（カードの支払い/ペイでの支払い）。これが楽天ポイントをブランド化しているのではないか？
・・・など。自分が惹かれているサービスは他と何が違うのか、いつからそういうふうになったのかを考えてみるとまた違った世界がひらけそうだなと思った。

また、自分は社内のデータ基盤の開発・運用を行っているが、

そのサービスの社内マーケティング
データ基盤を用いたマーケティング施策

について考えてみるのも面白そうだなと思った。
特に社内マーケティングについては競合（というか似たシステム）があったりして、いずれ自サービスはどこかに吸収されたりするんじゃないかという得も言われぬ不安があったりする。
それらの競合と自サービスは何が違うのか？独自性はどこにあるのか？を考えることで、自サービスの活きる道だったり、より良い追加機能のアイデアにつながるんじゃないかと思った。

言われるがままに詳しくもなんともない分野の本を読んでみたけど、案外たのしめた。
以前、越境体験について（そこそこ）詳しく調べたことがあったけど、これもその一環かなと思う。
自分の専門の勉強ももちろん大切だが、異なる分野について本を1冊読むだけでもなんとなく世界を見る目が変わった気がするので、今後もたまにやってみよう。

1日に2つも読書メモを上げるとは、やる気があるなあ。
今後も週1ペースくらいで読書メモ挙げられたらいいなと思いつつ、ノルマ化すると飽きるのでのんびりやろう。

2021-02-28

『Google Cloudではじめる実践データエンジニアリング入門[業務で使えるデータ基盤構築]』を読んだ

この本を読んだ。

Google Cloudではじめる実践データエンジニアリング入門[業務で使えるデータ基盤構築]

作者:下田倫大,寳野雄太,饗庭秀一郎,吉田啓二
発売日: 2021/02/18
メディア: Kindle版

前の記事の通り、メモりながら読んでみたので、それを参考にしつつ読書メモをブログにも残す。 ck-fm0211.hatenablog.com

読書メモ

この本はBigQueryを中心としたデータ基盤について書かれた本。
BigQueryの強みを紹介しつつ、周辺プロダクトとの連携などもかんたんなハンズオンを交えながら紹介されている。

章立てとサマリ

章立てとしては以下の通り。それぞれにかんたんな要約をつけてみる。

第1章　データ基盤の概要
- 昨今話題のDX（デジタルトランスフォーメーション）とデータ基盤の関係。
- データ基盤とそこに出てくる各要素の言葉の定義、目線合わせ。
第2章　BigQueryのコンセプトと利用方法
- DWHとして利用するBigQueryの基礎知識、使い方の紹介。
- BigQueryの内部構造を解説し、なぜ高いパフォーマンスが出せるのか、他のDWH製品とは何が違うのかを示している。
- また、BigQueryをうまく活用するためのユースケースの紹介。
第3章　データウェアハウスの構築
- BigQueryの可用性について解説。
- BQでマート作成する際のベストプラクティスや、マート作成やDMLを流す際に使える便利機能を紹介。
第4章　データレイクの構築
- データレイクの概念の説明。
- GCPでどのようにデータレイク・ウェアハウスを構成するか。既存のしくみ（Hadoop等）をどのように載せ替えるか・なぜそれができるか（どのようなサービスがGCPに存在しているか）
- また、GCPでこれを構築するメリットはなにか（vs. オンプレ）
第5章　ETL／ELT処理
- ETL/ELTの違い、使い分けについて解説。
- Dataflow/Dataproc/BigQueryでETL/ELTをするときのそれぞれの特徴がまとまってる
第6章　ワークフロー管理とデータ統合
- Cloud Composer/Dataflowの関係性について解説。
  - それぞれの用途とハンズオン
  - ハンズオンはQwiklabsにもありそう
第7章　データ分析基盤におけるセキュリティとコスト管理の設計
- データ基盤の運営を念頭に置いた、GCPにおける基本的な監査・コスト管理の方法
第8章　BigQuery へのデータ集約
- BigQueryへのデータパイプラインを作成する方法の例
  - 単純なデータ転送
  - Dataflowをつかった加工まで実施するパイプライン
  - 他サービスとの連携
第9章　ビジネスインテリジェンス
- BIツールの紹介
  - コネクテッドシート（GoogleSpreadsheet）
  - DataPortal
  - Looker
    - Lookerでの設定方法
- BIツールを使うときのbqの便利機能
  - BI Engine
  - マテリアライズドビュー
第10章　リアルタイム分析
- ストリーミング処理の実装方法
  - サンプルとしてPub/Sub->Dataflow->BigQuery
- ストリーミング処理の概要の説明・ハンズオン
  - ハンズオンはQwiklabsにありそう
第11章　発展的な分析
- BigQuery GISの紹介
- BigQueryで使える機械学習サービスの紹介とそれぞれの特徴使い方の説明
  - BigQuery ML
  - Auto ML Tables
- AI Platformについても少し。

感想

一番タメになったこと

特に序盤のBigQueryの内部構造について解説されている部分がタメになった。
普段の業務でBigQueryを使っているが、内部構造についてあまり踏み込んで理解しておらず、他に利用したことのあるAWS RedshiftやOracle Exadataに比べて「すごく早い！」くらいの感想で済ませていた。
おそらくここで出てくる「インメモリシャッフル機構」がBigQueryをBigQueryたらしめる最重要要素であると理解した。
先週あたり、#bq_sushiのイベントでBigQuery高速化のLTを聞いたが、そのときは「なんでこんなことがわかるん？？」という気持ちだったが、この本を読んで内部構造を理解することの重要性を理解した。

BigQuery Query Optimization クエリ高速化編 from sutepoi

その他タメになったこと

細かい話だが、知らないコマンドや機能・仕様についても書かれており、これらは本番運用の中でもすぐにでも活用できるなと思うものが多かった。一例を以下に挙げる。

bq headコマンドでBigQueryのWebUIと同様のプレビューが参照できる
テーブルへのリストアは2パターン。
- CTAS（CREATE TABLE AS SELECT）
  - タイムトラベルに必要なテーブルメタデータが一度消去されるため、それ以前のタイムトラベルができなくなる
- クエリ結果を別テーブルとして保存し、復旧対象テーブルの該当するデータをDELETEしてからINSERTする
  - タイムトラベルを考慮するとこっちを使ったほうがいい
承認済みビューのクエリのWHERE句で、クエリ実行者のメールアドレスを返すSESSION_USER関数を使用することで、このビューが取得するデータをユーザーに応じて動的に変更できる。これによりユーザーに応じた行レベルのアクセス制御が可能。

反省

この本で紹介される機能はあくまで一例で、基本的には良いことしか書いてない。公式ドキュメントや実際に動かしてみると様々な制約事項などがあり、必ずしもその機能が万能ということではない（当然のことだが）。
たとえばこの本を読んでる最中、BigQueryのマテリアライズドビューの解説があり、それを読んでるとあたかも万能な機能にも思えた。そんなようなことをTwitterでつぶやいたら、ドキュメントをちゃんと読んでいる人（検証している人）からフルボッコにされた。

BQのマテビューって実質、自動更新込みのマート作成機能みたいで最強っぽく見えるけどどうなんだろ。使えない関数とかはあるようだけど。
— C.K. (@ck_fm0211) 2021年2月23日

JOIN、UNNEST がないのと集約関数も大部分は使えないのでマートの置き換えは無理。マートの作成高速化のためにソーステーブルのサマライズや集約を予めマテビューで計算しておくのはアリ。って感想。
— swan (@irotoris) 2021年2月23日

ちゃんとドキュメントは読もう。

この本の使い方

GCPでデータ基盤を構築したい、という人はもちろんだが、「データ基盤を作ったほうがいいと思うけど上司・会社にどう説明したらいいか」のサンプルにもなるなと思った。
特に第一章ではDXの話題からデータ基盤・データ分析の重要性について説いており、この文章はそのまま社内稟議を通すための資料にも使えるんじゃないかと思うほど一般化されていたように思う。
ここだけ引用させてもらって、実際の構築はAWSやSnowflakeなんかを使う使うっていうのもアリだと感じた。

また、GCPにおける各サービスやその中の機能の比較が表・図になってわかりやすくまとまっている。この図をかき集めて社内wikiとかに貼り付けておくだけでもかなり有用な気がする。やってみよ。

2021-02-23

本の読み方のメモ

まえがき

読書の仕方をメモする。
技術書とか啓蒙書とか読んでると、前半はやる気満々で読めるのだが後半で力尽きて目が滑るようになるなあという実感があった。
普段から本を読んでる人はそんなことないの？と思い、少し調べてみたら積極的読書という言葉を見つけた。（参考：http://livelognet.com/how-to-read-a-book/）

ポイントは以下の３つ。

本を読む目的を明確に
書き込む
自分の言葉で説明してみる

これを実践するために以下の方法でやろうと思う。多少ルールがあるので、忘れないようにメモとして残しておく。
なお、最近はもっぱらKindleで読むことが多いのでそれを想定した方法としている。

Kindleの機能を活用する。

Kindleにはハイライト機能とメモ機能が搭載されている。これを活用する。

ハイライト機能：教科書に蛍光ペンで色を付けるみたいな感じで色付けできる。色は４色ある（ピンク・オレンジ・黄色・青）。
メモ機能：気になった文言とか文章にメモを残せる。

やり方は単純で、気になったところ、学びがあるなと思ったところ、あとで調べたいなと思ったところ、いつか自分が文章を書くとき（会社の資料とか）に使えそうだなって思ったところに色を付けて、必要に応じてメモを残す。これだけ。

ハイライトの色分けは以下のルールとする。

ピンク：重要。読んでる本（章）でいちばん重要そうなところ。
黄：そこそこ重要だったり気になったポイント。
オレンジ：あとで使えそうな文言。「ooとはxxということである」みたいなところになりがち。
青：覚えておきたいこと。Tipsとか、重要ってほどではないけど知っておいて損はないなっていうくらいのところ。

とりあえずこのルールを念頭に置いて本を読んでみる。
これをやっておくとあとでブログに本の要約・感想を書くときにも役に立ちそうな気がする。

2021-02-20

『イラストでわかるDockerとKubernetes Software Design plus』を読んだ

この本を読んだメモ。

イラストでわかるDockerとKubernetes Software Design plus

作者:徳永航平
発売日: 2020/12/05
メディア: Kindle版

Docker/Kubernetesは仕事で使っているものの、きちんと勉強したことがないなと思ったので、まわりで評判の良かったこの本を丁寧に読むことにした。

本の感想

Docker使ってると「レイヤ」って言葉を見るけど、そのイメージがついた。イラスト付きでしっかり解説してくれるのはありがたい。
CRIランタイム/OCIランタイムって言葉をよく見かける。こないだも見た。これの意味を理解した。
- CRIランタイム: 高レベルランタイム。kubeletからの命令を受け付ける部分。コンテナ・イメージ・ネットワーク等全般の管理。
- OCIランタイム: 低レベルランタイム。CRIランタイムからの命令を受け付ける。ホストから隔離された実行環境をコンテナとして作り出し、操作可能にする。
コンテナを使う際に何が起きてるのか、ざっとだが理解できたと思う。書いてあるけど理解が追いつかない部分はあるのでまた読み返そう・・
正直、最後の方はついていくのが大変だった。というかついていけなかった気がする。コンピュータの基礎についてちゃんと勉強したほうがいいな。

読んでてハマったこと

コマンドが書いてあるので一つ一つ模写しながら確認していった。
その中でいくつかハマったのでメモとして残しておく。

前提：検証時の環境

PC: MacBook Pro (13-inch, 2020)
OS: MacOS Catalina(10.15.7)
Docker Desktop(3.1.0)

overlay2のディレクトリが見つからない

2-2-4レイヤ構造のイメージからのルートファイルシステム作成に用いられる要素技術

Docker内のレイヤの重ね合わせの説明で、storage driver「overlay2」の説明がある。
Docker Imageの中で実際にレイヤがどう保存されているかを確認してみよう、というところがある。

/var/lib/docker/overlay2/

しかしこのパスがMacだと見つからない。

% ls /var/lib/docker/overlay2/
ls: /var/lib/docker/overlay2/: No such file or directory

なんでやねん、ということで調べてみると、MacのDocker DesktopはVM上で動いているため、ここで出てくるパスはローカルMacではなくてVM上のパスであるとのこと。たしかにそんなことを聞いたことがある気がする。

じゃあそのVMにはどうアクセスしたらええねん、と続けて調べてみると、以下のコマンドでアクセスできるとのことで試す。

% screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty

が、できない。何も表示されない。
記事によってはttyを入れてないので、そこか？と試す。

% screen ~/Library/Containers/com.docker.docker/Data/vms/0/
[screen is terminating]

ダメ。なんか即切りされる。

screenコマンドに慣れていないので、何かが違うのか？といろいろ調べてみるが、すぐに表示されるはず、らしい。
https://qiita.com/kawanet/items/263acbb870e3d2a842cd

何がおかしいんやと追加でググる。すると以下のissueを見つけた。
https://github.com/docker/for-mac/issues/4822
StackOverFlowにも同じような悩みが。
https://stackoverflow.com/questions/63445657/why-i-am-getting-screen-is-terminating-error-in-macos/63595817#63595817
ということでworkaround1を試す
https://stackoverflow.com/questions/63445657/why-i-am-getting-screen-is-termination-error-in-macos/63595817#63595817

% docker run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh
/ # ls /var/lib/docker/overlay2/
04220f51e5fa4946d9ccc91265931d1ac12a9da8b8ac268eaf4d07d67b890ae2
0da11ec70bdaaecc4f570fc28082ab7ea6a268cf610d842054ff1ef5b30c7e5d
0f9284d24e5a01b131f58917b7177b96dfd9ddc519fdc8952bfd86fc99fca4ed
（後略）

いけた！

このコマンドが何をやっているのかよくわからんので分解してみる。

docker run \
-it \
--privileged \
--pid=host \
debian \
nsenter \
  -t 1 \
  -m \
  -u \
  -n \
  -i \
  sh

基本は Docker-docs-jaから引用。筆者による追記あり。

docker run
- 新しいコンテナを実行する命令
-it
- -i(--interactive): コンテナの STDIN にアタッチ
  - Dockerを起動しているコンソールの標準出力とコンテナの標準入力が繋がる
- -t(--tty): 疑似ターミナル (pseudo-TTY) を割り当て
  - Dockerを起動しているコンソールの標準出力とコンテナの標準出力が繋がる
--privileged: このコンテナに対して拡張権限を与える
- 特権モード。ホスト（ここではMac）のすべてのデバイスへのアクセスが可能になる。
--pid=host
- --pid: 使用する PID 名前空間
  - 指定したコンテナ（ホストも可）とPID名前空間を共有できる。
  - =hostとすることでホスト側のPID名前空間を共有することができる。
debian
- pullするイメージ
nsenter
- debianイメージに入ってるツール。Dockerで作った名前空間（ネームペース:namespace）に入るためのコマンドライン・ツール。
- debianイメージでコンテナを起動して、このツールを起動している。
- https://github.com/jpetazzo/nsenter
-t 1
- nsenterのオプション
- -t, --target <pid>: 名前空間を取得するターゲットプロセス
- ここでは1を指定している。1ってなんやと調べてみると、起動プロセス。まあそうか。

root@3b877f756d3f:/# cat /proc/1/cmdline
/sbin/init

-m
- nsenterのオプション
- -m, --mount[=<file>]: マウント名前空間
-u
- nsenterのオプション
- -u, --uts[=<file>]: UTS名前空間
-n
- nsenterのオプション
- -n, --net[=<file>]: ネットワーク名前空間
-i
- nsenterのオプション
- -i, --ipc[=<file>]: システムV IPC名前空間
sh
- nsenterで上記で指定した名前空間内でshellを起動する。

・・・調べてみたが結局よくわからん。特にnsenterのオプションのところがわからない。
なんとなくわかったような気がするところだけ書くと、

ホスト（Mac）とnamespaceを共有したdebianイメージを特権モードで起動する
起動したコンテナ内でnsenterで別PIDに入り込もうとする。このときPIDに1を指定すると自分自身を指定したことになる（？）ので、ホスト側から見るとDockerコンテナを起動している場所=DockerDesktopのVMへ入ることになる（？）

なのかな、たぶん。-m -u -n -iのところが全然わからないのだけど。

あまり深追いしてもしょうがないと自分に言い聞かせることにした。だれか詳しい人教えてほしい。
とりあえず、上記コマンドでMac上で起動しているDockerDesktopのVMに入ることができる。