ck_fm0211のブログ

書きたいことを書く。

『自分でやった方が早い病』を読んだ

はじめに

たまたま見かけたブログ記事を読んで共感し、そこで紹介されていた本を読んだ。 liginc.co.jp

ここ数年はお客様企業にて常駐(現在はリモートワーク)し、その中でお客様・他社メンバーまぜこぜの1チームで活動している。
直近、リーダー格のお客様社員が体調を崩し数日間勤務できない状況があった。
実質No2ポジションだった自分が暫定リーダー的に振る舞う必要があったが、それがまた色々と苦労した。
自分しかできない業務(知識・スキル・権限などいろいろな理由)があったり、チーム内外の質問が自分に集約されたり、最近JOINしたメンバーのオンボーディングのフォローをしたり。
「俺がいないとだめだなあキミタチは」みたいな自尊心の高まりは感じたけど、チームとしては明らかに不健全だなと感じたのでなんとかしなきゃと思い、とりあえず書籍に頼ろうと思ったところでこの記事(本)に出会った。

読書メモ

現場の第一線で活躍してきた人が、いざ部下を持つような立場になったとき陥りがちな「自分でやったほうが早い病」について、

  • その状態が続くと何が困るか/克服するとどんないいことがあるか
  • なぜそんな状態になってしまうのか
  • どうしたら克服できるか/再発しないようにできるか

を解説している本。
「どうしたら克服できるか」について、テクニック的な話というよりはメンタルの持ちようについての記載が多い。
テクニック面は同著者の↓の本に記載されているそうなので、こちらも読んでみたい。

目次は以下。

はじめに 「自分でやったほうが早い」という病の恐ろしさ
第1章 病が進行すると「孤独な成功者」になる
第2章 病を克服すると「幸せな成功者」になれる
第3章 病の根本にある「自分さえ良ければ」という考え方
第4章 「自分でやったほうが早い病」への処方箋
第5章 「自分でやったほうが早い病」が再発しないために
おわりに 「自分でやったほうが早い」の正体は「自分でやったほうが遅い」

読みながらとったメモ

  • キーワードは「利他主義
    • 「自分でやったほうが早い」は「利己主義」である
    • 自分自身が最速で成果を上げることができるだけで、チーム・組織としての成果は小さい
      • プレイヤーとしては良いが、リーダーとしてはいまいち
      • チームでレバレッジを効かせて、1人で1の成果を上げるのではなく、5人チームなら5人で100の成果を上げるのがリーダー・マネージャーの仕事
    • 老子の言葉:「飢えている人に魚をとってあげれば、一日は食べられるけれど、魚のとり方を教えれば、彼は一生食べることができる」
  • イエローハット創業者の鍵山秀三郎氏の言葉:「人間には3つの幸せがある」
    1. してもらう幸せ
    2. 自分でできる幸せ
    3. してあげる幸せ(させていただく幸せ)
    4. 1,2は利己主義。3は利他主義
    5. 誰かの力になる、誰かを助けてあげることで、相手以上に自分自身が幸福を得られるということ
    6. マネージャーは「してあげる幸せ」を知っている人。これは「自分でできる幸せ」よりも大きなものであると実感できるはず。
  • 「任せる」のゴールは「任せたら自分は一切何もしなくていい」状態。
    • この状態に至るには困難がたくさんあるはず。1度任せたから終わりということにはならない。
      • 仕事をこなすことが目的ではなく、仕事を通じて部下の成長を促すのが目的になる。
      • 人に動いてもらう・育てるというのは時間がかかるもの。中長期的な視点をもって取り組まなければならない。
    • ディレクションだけ自分がやり、実作業を周りの人や部下に任せる、というのは「自分でやったほうが早い」状態
      • 必要なのは責任も同時に渡すこと。
  • 「任せる」ためには自分自身の人間的成長が不可欠。テクニックだけではダメ。
    • 部下を変えるのではなく、自分が変わる。我慢ではない。
    • 変わるためには師を得るのが良い。
      • 周りにいなければ有名人・著名人でも良い。その人の考え方に共感できるかどうかが重要。

感想

「自分でやったほうが早い」は「利己主義」である

は衝撃だった。「みんなのために身を粉にして働いているんだ」と思っていたけど、その実は自分のためだったのか。確かにそうかもしれない。
チーム・組織のことを考えると全体のレベルアップを図るほうが良いし、結果的に自分が楽をしたり別のことにチャレンジしたりもできる。

また「任せるのは大変。長い道のりである」というのも、言われてみれば確かにそうだった。
よく、ちょっと任せてみてうまく行かないからあいつに任せるのはやめよう、みたいなことがあったりするけど、それはあまりにも短気だったようだ。
中長期的に人を育てる、という感覚で接する必要がある。
そのためには自分自身が変わる必要がある。変わろうとする必要がある。
先日、職場の方のツテで聞いた↓の話を思い出した。
speakerdeck.com

あとどうでもいいけど、「してあげる幸せ」という話は槇原敬之の「僕が一番欲しかったもの」を思い出した。


www.youtube.com

郵便受けに投函されたらSlack/LINEに通知してみた[Qiita補足]

タイトルの通り。Qiitaを書いたのでその補足とか。

qiita.com

利用サービス

お金回りとかをちょっとまとめてみる。

分類 サービス名 月額料金 資料
IoTデバイス SORACOM LTE-M Button Plus 基本料金: 110 円 / 月
従量課金: 1送信当たり 0.3~0.4円 (月に300回の送信で約80円 = 80円/300回 = 約0.27円)
ご利用料金 - 特定地域向け IoT SIM
よくある問い合わせ - データ通信量はどのくらいですか
プラットフォーム SORACOM Func 無料
※1リクエストあたり0.00198円
※月間 50,000 リクエストまで無料
SORACOM Funk のご利用料金
プラットフォーム GCP Cloud Functions 無料
※200 万回の呼び出しのほかに、400,000 GB 秒、200,000 GHz 秒のコンピューティング時間と、1 か月あたり 5 GB のインターネット下りトラフィック(外向きトラフィック)まで無料
Cloud Functions - 料金

ランニングコストは月200円もしないくらいに落ち着きそう。

ソースコード

GitHubに上げた。

github.com

環境変数でSlackのトークンやチャンネル名、LINEのトークンを指定するようにしてある。 環境変数env.yamlに書いて、デプロイするときにそれを読み込ませている。

FUNCTION_NAME=notify_from_mailbox
gcloud functions deploy ${FUNCTION_NAME} \
--region asia-northeast1 \
--runtime python39 \
--trigger-http \
--allow-unauthenticated \
--env-vars-file=env.yaml \
--memory 128MiB

Slackの通知設定

Qiitaの方では参考サイトをそのまま貼ったけど、こっちではもう少し詳しく書く。リンク先が消えるかもしれないし。

アプリの作成

Slackのアプリ作成ページからCreate New Appを押下。 https://api.slack.com/apps このとき、仕事で使っているWorkSpaceの情報も統合されていて、そっちで作成したアプリが表示されていて焦った。 何を見て判断しているかわからないけど、複数アカウントが紐付けられてしまっている模様。

権限設定

メニューからOAuth & Permissionsを選択。 Scopesから必要な権限を選択。今回はchat:writeだけでOK。

ワークスペースへインストール

メニューからInstall Appを選択し、ワークスペースへインストールする。 そうするとトークンが発行されるので、そのトークンを使って実装すればOK。

LINEの通知設定

Qiitaの方では参考サイトをそのまま貼ったけど、こっちではもう少し詳しく書く。リンク先が消(ry

アクセストークンの発行

LINE Notifyのページでログイン

https://notify-bot.line.me/ja/

右上からマイページへ移動し、トークンを発行ボタンを押下する。

トークン名と、通知先トークルームを選択して発行ボタンを押下。 ※先に「LINE Notify」とLINE上で友だちになっておき、通知に使いたいトークルームを作成しておくとスムーズ。

これでトークンが発行されるので、そのトークンを使って実装すればOK。

SORACOM LTE-M Button Plusの設定でハマったこと

SIM登録

soracom.github.io

バイスが到着してまずやることとしてSIM登録をしろというのがあった。 言われたとおりにやろうとしたけど、そもそもSIMカードなんてもらってませんけど???となって焦った。

SORACOMのコンソールで登録済みのSIMのページを見たらどうやらすでに登録済みだった模様。なんでやねん。

配線

soracom.jp

離れた時に “ON” (= SORACOM LTE-M Button Plus が動作)する組み合わせ

磁気センサー部の「灰」と「赤」のケーブルを SORACOM LTE-M Button と接続します。これにより、磁気センサーのセンサー部と磁石部が離れた時にセンサーが “ON” となります。

とあったのでその通りに配線してみたけど通知が飛ばず。

近づいた時に “ON” (= SORACOM LTE-M Button Plus が動作)する組み合わせ

磁気センサー部の「灰」と「白」のケーブルを SORACOM LTE-M Button と接続します。これにより、磁気センサーのセンサー部と磁石部が近づいた時にセンサーが “ON” となります。

まさかどっちかのケーブルが断線してる??と思い、試しに逆向きの配線にしてみたら通知が飛んだ。 ということはケーブルは全て生きてる・・・まさか!で「赤」「白」をつないだら通知が飛ぶようになった。 初期不良かドキュメントの間違いか・・・・いずれにしても焦らせやがってこのやろうと悪態をついていた

・・・

という記事を書いているところで気がついたのだけれど、

A: お手元のセンサー部のケーブル色が「赤・白・灰」における動作

B: お手元のセンサー部のケーブル色が「茶・白・灰」における動作

と、コードの組み合わせがそもそも2種類あった模様。そして手元にあるのは「茶・白・灰」のパターン。

B: お手元のセンサー部のケーブル色が「茶・白・灰」における動作

離れた時に “ON” (= SORACOM LTE-M Button Plus が動作)する組み合わせ

磁気センサー部の「茶」と「白」のケーブルを SORACOM LTE-M Button と接続します。これにより、磁気センサーのセンサー部と磁石部が離れた時にセンサーが “ON” となります。

仕様どおりだった。SORACOMさん申し訳ありませんでした。

まとめ

とりあえず運用開始してみたけどどうなるかな。
ポストの中にコードがむき出しで配置されているので、そのうち大きい荷物とか入れられたときに断線しそうな気はしている。 なんらかの対策をしないといけないな。

『データサイエンス100本ノック(構造化データ加工編)』をやってみた(SQL)

データサイエンス100本ノック(構造化データ加工編)をやってみたのでその感想など。
データエンジニアを(一応)名乗っているので、それなりにできないとまずいかなと思い挑戦。
いうてパイプライン作る側の人なのでゴリゴリの分析SQLを投げたりするわけではないのだけれど、分析基盤のユーザーの気持ちを少しでも分かりたいなと思ったので。

ちなみに挑戦したのはSQL版。いずれ他言語もやってみよう。
github.com

準備

READMEに書いてあるとおり、

git clone [Repository URL] ※
cd 100knocks-preprocess
docker-compose up -d --build

でOK。ちなみに止めるときは↓。

# 一時中断のとき
docker-compose stop
# 再開するとき
docker-compose start

# 完全に終わりたいとき
docker-compose down

ローカルPCでやらなくてもGoogle Colabとかでやる方法もある。 qiita.com

感想など

金曜の終業後〜日曜日の計3日間で終わった。結構なボリュームだと思ったが、まあこんなもんか。



普段の業務で「こういうときどうしたらいいんだろう?」みたいなのがたまにあったりするけど、その回答が見つけられたように思う。

例:
- 時系列データに対して日付をずらしながら集計するには?
- カテゴリごとにランダム抽出するには?
- 欠損値はどう扱う?



DBはPostgreSQLなので、方言とか「そんな関数あったんかい!」みたいなのはあるけどまあそこは本質ではないのであまり気にしない。
SQLでどう表現すればいいんだろう?を悩む感じだった。



データ型がまばらなのもリアルでいいなと思った。日付データがINT型だったりVARCHAR型だったり。
実際の業務でもそういうの結構あったりする。
E-R図があるので、設問によっては参照しないとどうしようもなかった。メタデータって重要。



たまに標準偏差とか第一四分位数とか統計用語出てくるあたりはさすがはデータサイエンティスト協会って感じ。
そのへんの知識とか正しい理解とかが足りてないかなと思うところもあるので、いずれ勉強したいなあ。





チームメンバーとかが増えたときとか、これを使ってその人のスキルレベルを測ることもできそうだなと思った。
そうでなくてもオンボーディングに組み込むとかも良さそう。

ちなみにデータサイエンティストのスキルチェックリスト(ビジネス力・データサイエンス力・データエンジニアリング力)もあったりして、これまた有用そうだなと思った。 github.com

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

はじめに

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

読書メモ

全体概要

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業界で働く人以外でも読みやすいし、学びになることは多そう。妻に勧めたい。

Professional Data Engineerに合格した

まえがき

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

筆者のプロフィール

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

試験の概要

勉強内容

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

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

詳細を書いていく。

公式の模擬試験

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

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

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

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

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

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

ck-fm0211.hatenablog.com

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

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

Udemy

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

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

上記以外

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

試験当日

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

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

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

まとめ

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

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

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

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

経緯

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

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

準備

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

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

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

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

Issueを作る

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

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

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

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

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

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

の流れで対応した。

ここで一番ハマったのは、どう考えても今回直したものと関係ないところで落ちてるテストがあったこと。
なんだなんだとこねくり回した挙げ句、もしやと思い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'

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

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

読書メモ

著者略歴を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でデータ分析界隈の人が紹介していたので、マーケティングとかは門外漢だが読んでみた。

章立てとサマリ

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

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

  • 9つのセグメントに顧客を分類し、その1つ1つで特定の顧客(N=1)へ注目する。そこを起点とした深堀りで「アイデア」を導き出す。

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

  • マーケティングにおけるアイデアとは「独自性(Only-One Uniqueness ≒ 差別化)」と「便益」の掛け合わせである。
  • さらに「プロダクトアイデア(商品そのもの)」と「コミュニケーションアイデア(広告・顧客へのリーチ)」が組み合わさる
    • プロダクトアイデア
      • 例1:登場初期のiPhoneは独自性=便益である
      • 例2:風邪薬は共通して「風邪を治す」という便益を提供している。そこに「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(アー)モデル。ユーザー行動を以下の5段階に分け、リアルタイムデータで可視化・分析し、プロダクトアイデア自体を変数の組み合わせとして捉える。
        • A(Acquisition ユーザー獲得)
        • A(Activation 商品使用とユーザー活動の活性化)
        • R(Retention 継続使用)
        • R(Referral 他者への紹介や推奨)
        • R(Revenue 収益化)
    • 顧客の行動分析もリアルタイムにできてしまう世界。
  • 一方で心理分析はデジタルの苦手分野であり、N1分析は今後も有効である。
  • 最重要は変わらずプロダクトアイデアの独自性であり、それは今後さらに顕著になる。
    • 便益やコミュニケーションアイデアはデジタル世界では素早く移り変わる。

感想

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

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


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

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




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




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