データエンジニアがプロダクトマネージャーになることについて考えること

こちら trocco® Advent Calendar 2023 のシリーズ2の11日目の記事です。 qiita.com

データエンジニアからプロダクトマネージャーへのキャリアパス

自分がそうだったという、かなりポジショントークと希望的観測込みの考えではあるが、データエンジニアからプロダクトマネージャーは割と有りなキャリアパスなんじゃないかという気が最近している。

データエンジニアとして満足していたりその専門性をまだまだ突き詰めて行きたいと思っている人はこんなことを考える余地はないかもしれないが、誰かのキャリア検討の一助になれば、とそう思う理由について言語化してみる。ちなみに、ここではSaaSとかインターネットサービスを提供している企業におけるプロダクトマネージャーを想定している。

理由1: データリテラシーが高く技術に強い

データリテラシー、技術に強いことは、プロダクトマネジメントする上でもかなり活きる。プロダクトマネージャーとして、toCでもtoBでも社内のデータを活用して状況を分析したり、プロダクト開発上の仮説を立てるのは日常的なことだ。社内のデータの構造をすぐに把握してSQLを書いてデータを抽出したり、最悪自分でデータを取得する仕組みを作れることは大きな強みになる。

さらに、データリテラシーだけでなく一般的なWeb技術に通じているケースも多い。データを処理するシステムがそういう技術に依拠していたり、データの生成元がそのようなシステムになっていたり、ユーザーが操作するウェブのUIについて考えることも多いためだ(最近はどこもSaaSを使って自前でホスティングするみたいな経験は少なくなっているのかもしれないけれど)。

理由2: 社内のさまざまなステークホルダーとコミュニケーションを取り、プロジェクトマネジメントができる

また、泥臭いプロジェクトマネジメントができることも強みになる。データエンジニアは日々データ利用者のことを考えながら基盤構築のプロジェクトを進めていたり、データセットやデータツールのマイグレーションをしていたり、それらの計画を立てたり、そのためのコミュニケーションをさまざまステイクホルダーと行っていたりする。プロダクトマネージャーにおいてもさまざまな職種の人とコミュニケーションを取ることは必須で、そのプロセスは同様だ。

理由3: 社内のデータに詳しい(ドメイン知識がある)

最後に、社内のデータに詳しくなることを通じて、結果的に業界のドメイン知識に詳しくなるのもプロダクトマネージャーになることには有利に働く。 技術にしか興味ない人やあまりデータ活用レイヤーに業務領域が被らない人はその限りではないのかもしれないが、データエンジニアとしてデータの活用を支援する立場となるとやはりそのデータがどのようなものでどのように活用されるかについての知見は溜まってくるんじゃないかなと思う。

さいごに

データエンジニアの職務領域は各社様々なので、上記の理由に当てはまらないデータエンジニアはいるとは思う(Hadoopクラスターの運用を専門としている人など)。一番ハードルが高そうなのは理由3かな。プロダクトマネージャーになるためにあと必要なのは、ビジネスや組織に対する興味関心とユーザーを喜ばせようとする気持ちとかか。

自分がデータエンジニアからプロダクトマネージャーになったのは、データを使って事業とかプロダクトを良くしたいと思ったときに、自分がPMをやった方が効果的なんじゃないかと思ったからだ。特定のドメイン・プロダクトが好きで、同じような気持ちになったりする人は少なからずいるんじゃないかなーと思ったりするので、そういう人はちょっと検討してみてください。

[PR] troccoというプロダクトのPMを募集しているのでデータエンジニアやってる方でご興味ある方は、お気軽にご連絡ください。

herp.careers

herp.careers

特にエンジニアリングに必須ではない図書40冊 後編

はじめに

前回の続きで、リストアップしていた会社で働いていくなかで役に立ちそうな残りの20冊を紹介する。 satoshihirose.hateblo.jp

特にエンジニアリングに必須ではない図書20冊 仕事編

Snowflake、ServiceNowを率いてきたフランク・スルートマンのとても経営哲学本。プロ経営者としてIT業界の一線を走り続けてきた著者の哲学が経験を元に明快に説明されている。テック業界に居る人なら読んで損はない名著。

著名VC、マーク・アンドリーセン・ホロウィッツのベン・ホロウィッツが過去の経験を赤裸々に語っていてその体験の困難さ(ハードさ)に恐れ入るための本。経営者って大変だなという気持ちになる本。

これは昔に書評を書いていた。ベン・ホロウィッツの「HARD THINGS」を読んだ - satoshihirose.log

誰しも転職や異動などキャリアアップしていく際に責任範囲が変わったりして苦労することはあると思うが、そのようなタイミングでどういう心構えでどのような振る舞いをすると良いかが述べられていてとてもためになる。

SaaS製品を伸ばしていく際に必要なメトリックに関する知識や分析事例が整理されていて入門書として最適。

原題はCulture Map。グローバル企業に勤めていたりすると多様な背景を持つ人たちと一緒に働かなきゃいけなくて苦労することもある。読むと自分の認知の仕方が相対的に見られるようになる。

邦題は微妙だが、原題はRadical Candor(徹底的な率直さ)で、このCandorの大事さはBill Campbellの伝記などでも触れられていたりして頻出のキーワードだと思う。改めて自分のコミュニケーションの方法を見直したくなる本。

ストーリー仕立てでうまくいくチームとはどういうものか、そういうチーム作りのプロセスについて説明している本。現実は必ずしもうまくいくばかりではないと思うが、ストーリー仕立てだからこそ感情移入してしみじみ読めてしまう良い本。

マッキンゼーの採用の仕組みについて語っている本。リーダーシップというのは全員に求めて良いものであるというのは自分はAmazonに勤めている時に実感したものだが、本書でもそれが説明されているパートがありそこが良かった。

会社勤めしていると自分の要求を通したい場面は多々あると思う。日本人はネゴシエーションが下手だと言われていたりするが、そういう場面で知っていると使えるかもしれないようなテクニックや考え方が説明されていて勉強になった。

すでにSaaSやっている会社での共通言語になっていると思うのでこのプロセスを採用するかにかかわらず読んでいて損はない。とても効率的だなとは思う一方、やり切るには大変。

自分は営業というロールにはあまり関わってこない人生だったが、どのような営みが行われているかについて学ぶのに良い本だった。

顧客ロイヤリティを上げるには何が必要か、というところを改めて考えさせられる良い本。Effortless Experienceという考え方はSREのToilをなくす的な考え方でもあるなとも感じる。

GainsightのCEOが書いたカスタマーサクセスがこれ一冊で理解できる本。カスタマーサクセスという考え方がなぜ必要になったか普及したかなどSaaSの運営上その背景を含めて理解できる良い本。

SmartNewsで働いていたころから圧倒的にプロフェッショナルだなと思っていた西口さんが顧客起点の経営というテーマを語った本。あらためて顧客起点でビジネスを作っていくってところで襟が正される。

PMFってよく使われる言葉だけど具体的に何?ってのをいちから説明してくれる本。自分は読むまでCPF、PSF、SPFなどプロダクトの他のステータスについては知らなかったので、読んで良かった。

DHHがベースキャンプをどういう哲学で運営しているかが垣間見える本。こういう考え方のもと従業員が働ける会社があっても良いなと思わせてくれる。

Just for Funというタイトルが良い。リナックスがどういう風につくられてきたかの歴史が知れる本。

強い組織カルチャーがある会社ってときに割と言及される高級ホテル運営のリッツ・カールトン。確かにその顧客フォーカスの哲学は学ぶところがあるなと思った本。

東京にもある高級リゾートホテルグループのアマンの創業についての歴史ノンフィクション。仕事とは本当に関係ないけど、ひとは高級ホテルの何に高額を払うのだろうかというところを改めて考えさせられるし、アマン泊まってみたくなる。

最後に、妻に何かおすすめないかと聞いたら教えてくれた本。現代でも通じる読みやすい日本語がどういうものかについて説明されているとのこと。

さいごに

合計40冊紹介した。どれも良い本なので読んでみてください。

特にエンジニアリングに必須ではない図書40冊 前編

はじめに

ITエンジニア必読本10選、みたいな記事は定期的に生まれ、バズる。 みんな興味があり自分の体験や意見がそれぞれあるからかなと思う。現代ではIT技術職の仕事も多岐にわたるので全てのひとのお眼鏡に適うのは難しい。 先週はエンジニアリングの必須図書40冊という記事が盛り上がっていた。

zenn.dev

選書は個性が出るから面白い。また、その人と背景が似通っているほど刺さりやすい。 一方、日頃からアンテナを張っていないと、自分に合った良い本を知る機会はあまり無い。

ということで、自分と似た背景を持つ人(30代テック・スタートアップ業界関係者)向けにあまりエンジニアリングに関連しない書籍をおすすめする記事があっても良いなとふと思ったので、自分が過去に読んできた中で面白いと思った本を並べる。

特にエンジニアリングに必須ではない図書20冊

Sci-Fi

普段SF小説を読まない人に一冊おすすめするならこれ。全ての短編が素晴らしい。

仮説と検証を繰り返して問題を解決していく科学的な営みが物語にめちゃくちゃ上手く盛り込まれている。地味だから映像作品では描きにくい要素だと思うので、映像化されるだろうけれど書籍で読むのがおすすめ。

三体の作者による短編集。短編も良い。どれも良いけど、資本主義が進んだ結果その星の全ての資源がひとりの人間に所有された世界がでてくる話が印象に残っている。

全4冊読まないと一区切りしないのでめちゃ長いけど、SFの全てが詰まっている。訳も素晴らしい。

さまざまなテーマをSF作家がどう描いてきたのかってテーマごとに書籍が良い感じ紹介されているので、広くいろんなジャンルのSF小説を知りたい人におすすめ。

投資・金融・経済

日本もデフレから脱却したし、投資は身を守るために必要だ。経済や金融の話がわかればニュースも理解できて世の中の見え方も変わってくる。

どちらも版が重ねられ更新されている株式投資の入門書の定番。投機ではない株式投資がどういうものか、読むとある程度理解できる。

株式投資をするときに企業の価値ってのがどういう風に見積もられているのかって話がなんとなく分かる。

資本主義の限界はずっと叫ばれているが、そのような社会問題に対して経済学がどのようにアプローチして研究されているかが分かって面白い。

資本主義は倫理観点から批判されるが、正しい状況とはどんなものか、どうしたらもっと良くなるのかといかということを改めて考えるきっかけになる。

リーマン・ショックの発生が臨場感豊かに詳細に描かれていて金融ドラマとしてとても面白い。

生活

働きたくない人のための本。まあそういう状況を作り出すためにはもちろん労力が必要なんだけど、その実践が具体的で面白かった本。

新型コロナに罹患したし、そういえばウィルスについて何も知らんなと思って手に取った本。生命と物質の境界線やその奇妙な働きについてわかりやすく説明されていた。

デジタルデトックスしたくなるし、完全に断つのは無理にしてもアテンションエコノミーに自覚的になる本。

あまり日常生活で思いを馳せることのない「実在とは?」みたいな疑問を物理学がどうアプローチするかという話でとても好奇心をそそられる。2022年のノーベル賞をとったベル不等式の破れがなんとなく理解できた気になる本。

体に良い食事はどんなものか、これまでの研究で分かったことをまとめた書籍。歯切れの悪いところも科学的っぽい態度で良い。

死から少しでも逃れるにはどうしたら良いかの研究をまとめた本。寿命は所与のものっぽい考えだったけど、こういう研究があるんだなーって面白かった。

ビル・ゲイツが気候変動による災害に対してわれわれが何をできるかその考えをまとめた書籍。定量的に考えているので自己満足以上の結果を出すための活動はどんなものか説明していて勉強になった。

まとめ

本当は40選ということで40冊選んだんだけれど、紹介するの大変だったので半分に減らしました。誰か興味があれば後半もやります。

もし選書が気に入ったらコーヒーおごってください。Buy Me a Coffee

後編はこちら。 特にエンジニアリングに必須ではない図書40冊 後編 - satoshihirose.log

なぜ使われないダッシュボードが作られるかという話

はじめに

最近、ビジネスダッシュボードの設計・実装ガイドブックという書籍が出版された。今まであまりなかった視点から書かれたデータに関する本で面白く読んだ。

作ったダッシュボードの利用が進まず、虚しさを覚えた経験がある人は多いと思う。どうしてそうなってしまうのか、自分の経験を元にまとめたいなと思ったのでまとめる。

なぜ使われないダッシュボードが作られるか

なぜ作られたダッシュボードが使われないかと言うと、基本的にはそのダッシュボードがそんなに必要なものではないからだ(社内周知がうまくない、ツールの使い方がわからない人が多いなどの理由もあったりするがここでは無視する)。 必要のないダッシュボードが作られてしまう状況に関しては、以下の原因があると思うのでそれぞれ考えていく。

  1. ダッシュボードがなぜ必要かの理解が不十分なまま作り始めてしまうから
  2. アウトカムより目に見えるアウトプットに人は安心するから
  3. そもそも人のニーズを捉えたプロダクトを作ることは難しいから

1. ダッシュボードがなぜ必要かの理解が不十分なまま作り始めてしまうから

仕事の中でダッシュボードを利用したことがある人は多く、何らかデータが見たいとなった時にそれをダッシュボード化すると便利かもしれないと思う気持ちがうまれるはわかる。一方、ダッシュボードを利用したことある人と比べダッシュボードを作成したことのある人は少なく、そのなんとなくの感覚のままダッシュボードの作成が決定されてしまうことは多い。しかしながら、ダッシュボードというのはデータの分析・可視化にとっての万能ツールではなく、ダッシュボード化すべき対象や状況というというのは限られるため、希薄な目的意識の元では簡単に無用の長物ができあがってしまう。

この失敗はよく語られているところだが、その対策はなぜダッシュボードが必要なのかを明確にする要求定義フェーズをしっかり設けることだ。ダッシュボードに向かない具体的な状況や要求定義をどう進めるかなどについては、前述の書籍に記載があるので参照すると良い。ダッシュボードというものは一般的に何をするためのもので、あなたがしたいことは何で、そのしたいことのために本当にダッシュボードは必要なのかという話をダッシュボードを作る前にステークホルダーの間でしっかりすると良いだろう。すると、ダッシュボードではなく他の何かで十分満たされることが判明することもあるだろうし、不必要なダッシュボードが作られることは減るはずである。

上で述べたようなケースは、データのスペシャリストがダッシュボード活用の性質を理解して適切に利用者の要求を捌ける前提があることに注意が必要だ。 世の中にはデータチームの中でもそこまで知見がある人ばかりではなく、利用者の要求にそのまま従いダッシュボードを作成してしまうことも多い。まあ失敗しても死ぬわけではないし実務を重ねながら学ぶことも多いだろう。

2. アウトカムより目に見えるアウトプットに人は安心するから

また、ダッシュボードの作成依頼を受けた人に専門知識があった上でダッシュボードの必要性に疑義を感じたとしても、要求者の依頼にそのまま従うような場合も十分にあリえる。

なぜなら、データチームにとってダッシュボードを作ることはそれが仕事の一部であり、人を説得してまで作らないという選択をするよりも作る選択をする方が短期的には安全で楽だからだ。依頼者はもちろんそれが必要だと信じているから依頼をしてくるのであり、自分の考えが伝わらないリスクとか面倒なエンジニアだと思われるリスクをとり何のアウトプットもない状況より、例え使われない可能性があるとしてもダッシュボードを作るという選択をして何かしらアウトプットを得ることを選ぶことは、まあ人間として自然な心情かもしれない。

これは、インセンティブとかジョブセキュリティとかの話かと思う。これを防ぐには、使われないダッシュボードを作ることにペナルティを課すとか、全く評価しないとかアウトプットよりアウトカムを評価する、ダッシュボード作成以外の仕事も増やすようにする、とかが考えられるが、まあ組織的な工夫が必要だろう。

3. そもそも人のニーズを捉えたプロダクトを作ることは難しいから

前述の書籍の内容は、クライアントからお金をもらったプロジェクトの話で、そのようなケースではそもそも重要でないプロジェクトは俎上に上がりにくい。一方で、世の中クリティカルな仕事ばかりではないため、やはりそれが作るべきダッシュボードかを見極める力は重要だ。前述のようにダッシュボードの要求定義をして、作成するエンジニア(あなたや私)がまあその要求は妥当だと思ったとして、実際にそのダッシュボードが利用者に響くものかはわからない。依頼者はただのダッシュボード利用者の代表であり(そうでない場合もある)、依頼者の想定が間違っていることも十分にあり得るからだ。

成功しないスタートアップが世を占めることからわかるように、使われる製品を作るのはとても難しい。ダッシュボードもデータプロダクトの一種である。アウトカムにこだわるなら一般的なプロダウトマネジメントのプロセスに従ってダッシュボードをマネジメントすることを考えても良いかもしれない。

まとめ

以上、なぜ使われないダッシュボードが作られるかという話をしてみた。使われるダッシュボードを作っていきましょう。

dbt-steampipe を検証した

はじめに

たまたま steampipe のサポートプラグインを見たら、結構充実していた。ちょっと調べたら dbt-steampipe プラグインも作られており、これを使ってクラウドサービス関連のデータ収集が dbt 上で管理できれば便利なんじゃないかと思ったので検証してみた。

Steampipe とは何か

Steampipe はいろんなクラウドサービスの API をラップして SQL でデータ取得できるインターフェイスを用意してくれる OSSSQLインターフェイスPostgreSQL を立てることで提供している。

Steampipe is the universal interface to APIs. Use SQL to query cloud infrastructure, SaaS, code, logs, and more.

GitHub - turbot/steampipe: Use SQL to instantly query your cloud services (AWS, Azure, GCP and more). Open source CLI. No DB required.

Developers | Documentation | Steampipe

ちなみに HCL でダッシュボードを構築・管理する機能も開発されていて割と面白い。

dbt-steampipe を動かしてみる

dbt-steampipe プロジェクトをクローンして、 Getting Started に従って steampipe が動くコンテナを立ち上げる。

docker compose build steampipe
docker compose up

steampipe でクエリできるか確認する。. でコマンドを補完してくれる。無事に起動して steampipe が用意している gcp 用のテーブルは確認できたが、 credential 情報がなかったのでクエリには失敗した。

$ docker compose exec steampipe steampipe query
Welcome to Steampipe v0.16.4
For more information, type .help
> .tables
 ==> gcp
+---------------------------------------------------------+--------------------------------------------------------------+
| table                                                   | description                                                  |
+---------------------------------------------------------+--------------------------------------------------------------+
| gcp_audit_policy                                        | GCP Audit Policy                                             |
| gcp_bigquery_dataset                                    | GCP BigQuery Dataset                                         |
| gcp_bigquery_job                                        | GCP BigQuery Job                                             |
| gcp_bigquery_table                                      | GCP Bigquery Table                                           |
...
+---------------------------------------------------------+--------------------------------------------------------------+

To get information about the columns in a table, run .inspect {connection}.{table}

> select * from gcp_bigquery_table;
Error: rpc error: code = Internal desc = hydrate function listBigQueryDatasets failed with panic /home/steampipe/.config/gcloud/application_default_credentials.json: no such file or dir (SQLSTATE HV000)

gcloud auth application-default login を実行して credential を生成。改めてクエリしたが、次は gcp 上のプロジェクトを指定していなかったので失敗した。

$ docker compose exec steampipe steampipe query
Welcome to Steampipe v0.16.4
For more information, type .help
> select * from gcp_bigquery_table;
Error: googleapi: Error 404: Not found: Project your-project, notFound (SQLSTATE HV000)

steampipe のコネクション情報は dbt-steampipe/conf/config.spc で指定されている。

connection "gcp" {
  plugin      = "gcp"
  project     = "your-project"
  credentials = "/home/steampipe/.config/gcloud/application_default_credentials.json"
}

example の例ではこのようになっているが、 project を書き換えて再度実行する。

$ docker compose exec steampipe steampipe query
Welcome to Steampipe v0.16.4
For more information, type .help

> select * from gcp_bigquery_dataset
+------+-----------------+-------------------------------------------+------------------+----------------------+-------------+--------------------------+---------------------------------+----------->
| name | dataset_id      | id                                        | kind             | creation_time        | description | etag                     | default_partition_expiration_ms | default_ta>
+------+-----------------+-------------------------------------------+------------------+----------------------+-------------+--------------------------+---------------------------------+----------->
...
+------+-----------------+-------------------------------------------+------------------+----------------------+-------------+--------------------------+---------------------------------+----------->

クエリに成功した。

次は dbt-steampipe を使った dbt の実行。まずは dbt の依存性をインストール。

$ pip install -r requirements.txt

中を見ると dbt-postgres を用意している。

dbt-postgres==1.3.0

と思ったら、dbt-core 1.4 以下では python3.11 はサポートされていないようだった。 なので普通に pip で dbt-postgres をインストールして 1.4.5 を入れた。やっと dbt-steampipe の example を実行する。

$ cd steampipe_example
$ dbt seed --full-refresh
...
$ dbt run
13:36:57  target not specified in profile 'default', using 'default'
13:36:57  Running with dbt=1.4.5
13:36:57  Found 2 models, 0 tests, 0 snapshots, 0 analyses, 291 macros, 0 operations, 1 seed file, 427 sources, 0 exposures, 0 metrics
13:36:57
13:36:58  Concurrency: 1 threads (target='default')
13:36:58
13:36:58  1 of 2 START sql table model public.bq_billable_bytes .......................... [RUN]
13:37:01  1 of 2 OK created sql table model public.bq_billable_bytes ..................... [SELECT 0 in 2.88s]
13:37:01  2 of 2 START sql table model public.top_most_expensive_bq_jobs ................. [RUN]
13:37:01  2 of 2 OK created sql table model public.top_most_expensive_bq_jobs ............ [SELECT 0 in 0.18s]
13:37:01
13:37:01  Finished running 2 table models in 0 hours 0 minutes and 3.68 seconds (3.68s).
13:37:01
13:37:01  Completed successfully
13:37:01
13:37:01  Done. PASS=2 WARN=0 ERROR=0 SKIP=0 TOTAL=2

exmaple の profile.yml はローカルの postgres を指しているようだ。

default:
  outputs:
    default:
      type: postgres
      host: localhost
      user: steampipe
      password: steampipe
      port: 9193
      dbname: steampipe
      schema: public
      threads: 1

なので接続して確認する。

$ psql -h localhost -p 9193 -U steampipe -d steampipe
Password for user steampipe:
psql (14.7 (Homebrew), server 14.2)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

steampipe=> \d
                                      List of relations
 Schema |                          Name                           |     Type      |   Owner
--------+---------------------------------------------------------+---------------+-----------
 gcp    | gcp_audit_policy                                        | foreign table | root
 gcp    | gcp_bigquery_dataset                                    | foreign table | root
...
 gcp    | gcp_sql_database_instance_metric_cpu_utilization_hourly | foreign table | root
 gcp    | gcp_storage_bucket                                      | foreign table | root
 public | bq_billable_bytes                                       | table         | steampipe
 public | bq_pricing                                              | table         | steampipe
 public | top_most_expensive_bq_jobs                              | table         | steampipe
(87 rows)

steampipe が用意している gcp 用のテーブル以外に、example プロジェクトで dbt の model として用意されている bq_billable_bytestop_most_expensive_bq_jobs がテーブルとして生成されていることが確認できた。

aws プラグインを使って aws のコストデータを取得する

aws プラグインを試してみる。 例えば aws のコスト管理するような状況を想定して、コストデータを取得してみる。 docker-compose.yml を確認すると、既にインストール対象になっている。credential は ~/.aws/credentials を参照させているようだ。

services:
  steampipe:
    build:
      context: .
      args:
        PLUGINS: aws gcp
    command: ["service", "start", "--foreground", "--show-password"]
    ports:
      - 9193:9193
    volumes:
      - ~/.aws/credentials:/home/steampipe/.aws/credentials:ro
      - "~/.config/gcloud/:/home/steampipe/.config/gcloud/"
      - ./conf:/home/steampipe/.steampipe/config
    environment:
      - STEAMPIPE_DATABASE_PASSWORD=steampipe

conf/config.spc に下記を追加してコンテナ再起動。(ここでprivateは~/.aws/credentialsに追加されているプロファイル名である)

connection "aws" {
  plugin = "aws"
  profile = "private"
}

aws のコスト関連のテーブルはいくつか用意されているが、今回は aws_cost_usage を incremental に追加するよう sql ファイルを用意する(本当はユーザー定義タグごとに集計したデータも見たかったが、現時点でサポートしていないみたい。PRはあるのですぐにサポートされそうではある)。models/example/aws_cost_usage.sql に下記のようなクエリを追加する(granularityと二つのdimensionは要指定らしい)。

{{
    config(
        materialized='incremental'
    )
}}

select
*
from aws.aws_cost_usage
where granularity = 'DAILY'
and dimension_type_1 = 'SERVICE'
and dimension_type_2 = 'OPERATION'
{% if is_incremental() %}
and period_start > (select max(period_start) from {{ this }})
{% endif %}

dbt runをする。

dbt run
03:04:28  target not specified in profile 'default', using 'default'
03:04:28  Running with dbt=1.4.5
03:04:29  Found 3 models, 0 tests, 0 snapshots, 0 analyses, 291 macros, 0 operations, 1 seed file, 427 sources, 0 exposures, 0 metrics
03:04:29
03:04:29  Concurrency: 1 threads (target='default')
03:04:29
03:04:29  1 of 3 START sql incremental model public.aws_cost_usage ....................... [RUN]
03:05:00  1 of 3 OK created sql incremental model public.aws_cost_usage .................. [SELECT 9617 in 30.90s]
03:05:00  2 of 3 START sql table model public.bq_billable_bytes .......................... [RUN]
03:05:01  2 of 3 OK created sql table model public.bq_billable_bytes ..................... [SELECT 0 in 0.95s]
03:05:01  3 of 3 START sql table model public.top_most_expensive_bq_jobs ................. [RUN]
03:05:01  3 of 3 OK created sql table model public.top_most_expensive_bq_jobs ............ [SELECT 0 in 0.25s]
03:05:01
03:05:01  Finished running 1 incremental model, 2 table models in 0 hours 0 minutes and 32.71 seconds (32.71s).
03:05:01
03:05:01  Completed successfully
03:05:01
03:05:01  Done. PASS=3 WARN=0 ERROR=0 SKIP=0 TOTAL=3

成功した。postgres に繋いで生成されたテーブルを確認してみる。

$ psql -h localhost -p 9193 -U steampipe -d steampipe
Password for user steampipe:
psql (14.7 (Homebrew), server 14.2)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

steampipe=> \d
...
 public | aws_cost_usage                                               | table         | steampipe
 public | bq_billable_bytes                                            | table         | steampipe
 public | bq_pricing                                                   | table         | steampipe
 public | top_most_expensive_bq_jobs                                   | table         | steampipe

steampipe=> \x
Expanded display is on.
steampipe=> select * from aws_cost_usage limit 10;
dimension_1               | Amazon Route 53
dimension_2               | AAAA
granularity               | DAILY
search_start_time         |
search_end_time           |
dimension_type_1          | SERVICE
dimension_type_2          | OPERATION
period_start              | 2022-03-19 00:00:00+00
period_end                | 2022-03-20 00:00:00+00
estimated                 | f
blended_cost_amount       | 0.000136
blended_cost_unit         | USD
unblended_cost_amount     | 0.000136
unblended_cost_unit       | USD
net_unblended_cost_amount | 0.000136
net_unblended_cost_unit   | USD
amortized_cost_amount     | 0.000136
amortized_cost_unit       | USD
net_amortized_cost_amount | 0.000136
net_amortized_cost_unit   | USD
usage_quantity_amount     | 340
usage_quantity_unit       | N/A
normalized_usage_amount   | 0
normalized_usage_unit     | N/A
partition                 | aws
region                    | global
_ctx                      | {"connection_name": "aws"}
...

ということで、steampipe で取得した aws のコストデータがこのように dbt の出力先の postgres にテーブルとして追加されたのを確認した。

さいごに

データの変換は dbt を使って DWH で実行するようになってきているが、 steampipe を使って各種データソースからのデータ取得も dbt 上で管理できるようになったら便利かもしれないと思い、検証してみた。Salesforce、Zendesk、Slack、Jira、Google Sheet などのプラグインはあるのでシンプルな用途では使えそうだが、実際にどんなデータがサポートされているかは要確認かな。Redditとか LinkedIn とかのプラグインがあるのは興味深い。ぱっと見、 steampipe のプラグインは developer 向けのサービスが多いため、real world な用途にはもうちょっとプラグインが拡充されて欲しい気がしなくもない。

一方で、各種データソースのためのプラグインは dbt にもそれぞれ存在することもあるので(e.g. dbt-salesforce)、間に steampipe を挟むことのメリット・デメリットをどう捉えるかは議論の余地がある。エコシステムの大きさを考えると dbt プラグインの拡充に期待する方が順当かなどうかなー。

2022年振り返り

PMへの転向

2022年のイベントとして個人的に大きかったのは、プロダクトマネージャーへロールチェンジしたことだ。

6月-7月くらいから具体的に考え始めて元上司に相談して、8月に実際にHiring Managerと話をして社内面接を進めて、9月半ばに結果が出て、10月から異動先で働き始めたって感じのタイムラインだった。所属企業が変わったわけではないので大きな手続きは必要なかった。現職ではCREとして2年くらいデータ活用周りで社内システムのエンジニアリングをやっていたが、その過程で得られた知見をもとに直接的に製品開発に関わってみようと思ったのがざっくりとした異動理由だった。一方で、PMという職種にそこまで強い思い入れがあるわけではなく、現職では自分がやったほうが組織にとって良いやろっていう気持ちがあり、たまたまポジションが空いていたため入れてもらったくらいの認識でいる。そのため、しばらく試行錯誤してもあまりフィットしないようならいつでもエンジニア関連の職種に戻れるだろうというくらいの気持ちではある。

現職のPMチームメンバーは基本USに居て、自分の現在のマネージャーもUSに居る。時差あり少数派リモートワークをしているが、まあ働きやすくはない。日本と勤務時間がかぶるのは午前中の2-3時間程度でミーティングの時間を合わせるのも一苦労だ。さらに今回は新しい職種への挑戦もはらんでしまっているので、なおハードモードだ。リモート時差ありだと仕事を見て盗むということはかなりしにくい。そして、PMは割とプロジェクトベースでアサインされそれぞれ動くことが多く、同僚のPMと協働することが少ないので、そう言う面でも同僚の仕事を真似しにくい。かつ、みな奥ゆかしいからか、オープンなチャットコミュニケーションはあまり活発ではなく、人が何を考えているかわかりにくい。日本で働くエンジニアは多いので、将来的には日本ブランチでdirector立てて独立して動けるPMチームなんかを作っても良いのかもしれない。もしくは移住するか。

これまでの三ヶ月で人と話してきて、技術がわかるPMへの期待とその需要は感じている。市場でも希少でやはり採りにくいのだろう。また、プロダクトとしてのTDをマネジメントする困難さみたいなものも分かってきた。世界的に見て大変な時期でありそれがいつ自分の身に降りかかってくるかもわからないが、少しずつ成果を出しながらみなが成果を出せるよう仕組みも良くしていければなと思う。

副業

夏くらいからPMとしての副業を始めた。支援先と現職とのステージの違いもあり、学ぶことも多い。少しはなんらか貢献できていれば嬉しいが、一方で余剰時間での貢献は不安定でもどかしい気持ちにもなる。余剰時間は本業やプライベートの忙しさや心の余裕なんかに左右されてしまうため、なかなか安定的に副業をするのは難しい。自分の時間管理をしっかりできる人じゃないと向いていないと思うので(自分が向いているとは決して思っていない)、万人にはおすすめ出来ないなと感じる。

勉強会の発表

二件、データ関連のトピックで発表させていただく機会をいただけた。

2022年読んで良かった本、愛用したもの

2022年読んで良かった本

ServiceNow CEO -> Snowflake CEO の Frank Slootman の経営本。創業者じゃないプロCEOの本は読んだことなかったので面白かった。

2022年のノーベル物理学賞の対象がベルの不等式の破れの実証だったので読んだ。丁寧に議論が進められていたので読みやすかった。量子の非局所的相関にまつわるあれこれ分かれて良かった。自然の真のランダム性が与える自然観は奥深かった。

2022年に愛用したもの

自宅でチャイが簡単に飲めるようになって良かった。

www.kaldi.co.jp

カルディで見つけたピリ辛ドレッシング。サラダに掛けて無限に食べてる。

よく磨けて気に入って使ってる。