特にエンジニアリングに必須ではない図書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冊という記事が盛り上がっていた。
選書は個性が出るから面白い。また、その人と背景が似通っているほど刺さりやすい。 一方、日頃からアンテナを張っていないと、自分に合った良い本を知る機会はあまり無い。
ということで、自分と似た背景を持つ人（30代テック・スタートアップ業界関係者）向けにあまりエンジニアリングに関連しない書籍をおすすめする記事があっても良いなとふと思ったので、自分が過去に読んできた中で面白いと思った本を並べる。
特にエンジニアリングに必須ではない図書20冊
Sci-Fi
普段SF小説を読まない人に一冊おすすめするならこれ。全ての短編が素晴らしい。
仮説と検証を繰り返して問題を解決していく科学的な営みが物語にめちゃくちゃ上手く盛り込まれている。地味だから映像作品では描きにくい要素だと思うので、映像化されるだろうけれど書籍で読むのがおすすめ。
三体の作者による短編集。短編も良い。どれも良いけど、資本主義が進んだ結果その星の全ての資源がひとりの人間に所有された世界がでてくる話が印象に残っている。
全4冊読まないと一区切りしないのでめちゃ長いけど、SFの全てが詰まっている。訳も素晴らしい。
さまざまなテーマをSF作家がどう描いてきたのかってテーマごとに書籍が良い感じ紹介されているので、広くいろんなジャンルのSF小説を知りたい人におすすめ。
投資・金融・経済
日本もデフレから脱却したし、投資は身を守るために必要だ。経済や金融の話がわかればニュースも理解できて世の中の見え方も変わってくる。
どちらも版が重ねられ更新されている株式投資の入門書の定番。投機ではない株式投資がどういうものか、読むとある程度理解できる。
株式投資をするときに企業の価値ってのがどういう風に見積もられているのかって話がなんとなく分かる。
資本主義の限界はずっと叫ばれているが、そのような社会問題に対して経済学がどのようにアプローチして研究されているかが分かって面白い。
資本主義は倫理観点から批判されるが、正しい状況とはどんなものか、どうしたらもっと良くなるのかといかということを改めて考えるきっかけになる。
リーマン・ショックの発生が臨場感豊かに詳細に描かれていて金融ドラマとしてとても面白い。
生活
働きたくない人のための本。まあそういう状況を作り出すためにはもちろん労力が必要なんだけど、その実践が具体的で面白かった本。
新型コロナに罹患したし、そういえばウィルスについて何も知らんなと思って手に取った本。生命と物質の境界線やその奇妙な働きについてわかりやすく説明されていた。
デジタルデトックスしたくなるし、完全に断つのは無理にしてもアテンションエコノミーに自覚的になる本。
あまり日常生活で思いを馳せることのない「実在とは？」みたいな疑問を物理学がどうアプローチするかという話でとても好奇心をそそられる。2022年のノーベル賞をとったベル不等式の破れがなんとなく理解できた気になる本。
体に良い食事はどんなものか、これまでの研究で分かったことをまとめた書籍。歯切れの悪いところも科学的っぽい態度で良い。
死から少しでも逃れるにはどうしたら良いかの研究をまとめた本。寿命は所与のものっぽい考えだったけど、こういう研究があるんだなーって面白かった。
ビル・ゲイツが気候変動による災害に対してわれわれが何をできるかその考えをまとめた書籍。定量的に考えているので自己満足以上の結果を出すための活動はどんなものか説明していて勉強になった。
まとめ
本当は40選ということで40冊選んだんだけれど、紹介するの大変だったので半分に減らしました。誰か興味があれば後半もやります。
もし選書が気に入ったらコーヒーおごってください。Buy Me a Coffee
なぜ使われないダッシュボードが作られるかという話
はじめに
最近、ビジネスダッシュボードの設計・実装ガイドブックという書籍が出版された。今まであまりなかった視点から書かれたデータに関する本で面白く読んだ。
作ったダッシュボードの利用が進まず、虚しさを覚えた経験がある人は多いと思う。どうしてそうなってしまうのか、自分の経験を元にまとめたいなと思ったのでまとめる。
なぜ使われないダッシュボードが作られるか
なぜ作られたダッシュボードが使われないかと言うと、基本的にはそのダッシュボードがそんなに必要なものではないからだ（社内周知がうまくない、ツールの使い方がわからない人が多いなどの理由もあったりするがここでは無視する）。 必要のないダッシュボードが作られてしまう状況に関しては、以下の原因があると思うのでそれぞれ考えていく。
- ダッシュボードがなぜ必要かの理解が不十分なまま作り始めてしまうから
- アウトカムより目に見えるアウトプットに人は安心するから
- そもそも人のニーズを捉えたプロダクトを作ることは難しいから
1. ダッシュボードがなぜ必要かの理解が不十分なまま作り始めてしまうから
仕事の中でダッシュボードを利用したことがある人は多く、何らかデータが見たいとなった時にそれをダッシュボード化すると便利かもしれないと思う気持ちがうまれるはわかる。一方、ダッシュボードを利用したことある人と比べダッシュボードを作成したことのある人は少なく、そのなんとなくの感覚のままダッシュボードの作成が決定されてしまうことは多い。しかしながら、ダッシュボードというのはデータの分析・可視化にとっての万能ツールではなく、ダッシュボード化すべき対象や状況というというのは限られるため、希薄な目的意識の元では簡単に無用の長物ができあがってしまう。
この失敗はよく語られているところだが、その対策はなぜダッシュボードが必要なのかを明確にする要求定義フェーズをしっかり設けることだ。ダッシュボードに向かない具体的な状況や要求定義をどう進めるかなどについては、前述の書籍に記載があるので参照すると良い。ダッシュボードというものは一般的に何をするためのもので、あなたがしたいことは何で、そのしたいことのために本当にダッシュボードは必要なのかという話をダッシュボードを作る前にステークホルダーの間でしっかりすると良いだろう。すると、ダッシュボードではなく他の何かで十分満たされることが判明することもあるだろうし、不必要なダッシュボードが作られることは減るはずである。
上で述べたようなケースは、データのスペシャリストがダッシュボード活用の性質を理解して適切に利用者の要求を捌ける前提があることに注意が必要だ。 世の中にはデータチームの中でもそこまで知見がある人ばかりではなく、利用者の要求にそのまま従いダッシュボードを作成してしまうことも多い。まあ失敗しても死ぬわけではないし実務を重ねながら学ぶことも多いだろう。
2. アウトカムより目に見えるアウトプットに人は安心するから
また、ダッシュボードの作成依頼を受けた人に専門知識があった上でダッシュボードの必要性に疑義を感じたとしても、要求者の依頼にそのまま従うような場合も十分にあリえる。
なぜなら、データチームにとってダッシュボードを作ることはそれが仕事の一部であり、人を説得してまで作らないという選択をするよりも作る選択をする方が短期的には安全で楽だからだ。依頼者はもちろんそれが必要だと信じているから依頼をしてくるのであり、自分の考えが伝わらないリスクとか面倒なエンジニアだと思われるリスクをとり何のアウトプットもない状況より、例え使われない可能性があるとしてもダッシュボードを作るという選択をして何かしらアウトプットを得ることを選ぶことは、まあ人間として自然な心情かもしれない。
これは、インセンティブとかジョブセキュリティとかの話かと思う。これを防ぐには、使われないダッシュボードを作ることにペナルティを課すとか、全く評価しないとかアウトプットよりアウトカムを評価する、ダッシュボード作成以外の仕事も増やすようにする、とかが考えられるが、まあ組織的な工夫が必要だろう。
3. そもそも人のニーズを捉えたプロダクトを作ることは難しいから
前述の書籍の内容は、クライアントからお金をもらったプロジェクトの話で、そのようなケースではそもそも重要でないプロジェクトは俎上に上がりにくい。一方で、世の中クリティカルな仕事ばかりではないため、やはりそれが作るべきダッシュボードかを見極める力は重要だ。前述のようにダッシュボードの要求定義をして、作成するエンジニア（あなたや私）がまあその要求は妥当だと思ったとして、実際にそのダッシュボードが利用者に響くものかはわからない。依頼者はただのダッシュボード利用者の代表であり（そうでない場合もある）、依頼者の想定が間違っていることも十分にあり得るからだ。
成功しないスタートアップが世を占めることからわかるように、使われる製品を作るのはとても難しい。ダッシュボードもデータプロダクトの一種である。アウトカムにこだわるなら一般的なプロダウトマネジメントのプロセスに従ってダッシュボードをマネジメントすることを考えても良いかもしれない。
まとめ
dbt-steampipe を検証した
はじめに
たまたま steampipe のサポートプラグインを見たら、結構充実していた。ちょっと調べたら dbt-steampipe プラグインも作られており、これを使ってクラウドサービス関連のデータ収集が dbt 上で管理できれば便利なんじゃないかと思ったので検証してみた。
Steampipe とは何か
Steampipe はいろんなクラウドサービスの API をラップして SQL でデータ取得できるインターフェイスを用意してくれる OSS。SQL のインターフェイスは PostgreSQL を立てることで提供している。
Steampipe is the universal interface to APIs. Use SQL to query cloud infrastructure, SaaS, code, logs, and more.
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_bytes と top_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としての副業を始めた。支援先と現職とのステージの違いもあり、学ぶことも多い。少しはなんらか貢献できていれば嬉しいが、一方で余剰時間での貢献は不安定でもどかしい気持ちにもなる。余剰時間は本業やプライベートの忙しさや心の余裕なんかに左右されてしまうため、なかなか安定的に副業をするのは難しい。自分の時間管理をしっかりできる人じゃないと向いていないと思うので（自分が向いているとは決して思っていない）、万人にはおすすめ出来ないなと感じる。
勉強会の発表
二件、データ関連のトピックで発表させていただく機会をいただけた。
こちら第14回 #DataEngineeringStudy の発表資料です。Overview of The Modern Data Stack / モダンデータスタック概論 - Speaker Deck https://t.co/k4GK5QQcBq
— Satoshi Hirose / 廣瀬 智史 🐘 (@satoshihirose) June 7, 2022
本日の資料はこちらです。皆様ありがとうございました。Data Product Manager? / データプロダクトマネージャーとは？ - Speaker Deck https://t.co/AtTBnh1oKy #DataEngineeringStudy
— Satoshi Hirose / 廣瀬 智史 🐘 (@satoshihirose) December 14, 2022
2022年読んで良かった本、愛用したもの
2022年読んで良かった本
ServiceNow CEO -> Snowflake CEO の Frank Slootman の経営本。創業者じゃないプロCEOの本は読んだことなかったので面白かった。
2022年のノーベル物理学賞の対象がベルの不等式の破れの実証だったので読んだ。丁寧に議論が進められていたので読みやすかった。量子の非局所的相関にまつわるあれこれ分かれて良かった。自然の真のランダム性が与える自然観は奥深かった。
アンディ・ウィアー、仮説と検証を繰り返して問題を解決していく科学的な営みを物語に盛り込むのがめちゃくちゃ上手い。地味だから映像作品ではおざなりになりがちで、それこそがテキストでしか味わえない良さなんだよな。
— Satoshi Hirose / 廣瀬 智史 🐘 (@satoshihirose) May 2, 2022
2022年に愛用したもの
自宅でチャイが簡単に飲めるようになって良かった。
カルディで見つけたピリ辛ドレッシング。サラダに掛けて無限に食べてる。
よく磨けて気に入って使ってる。
プロダクトをマネージしたい話
先月から某 SaaS スタートアップで Product Manager の副業をさせていただいている。
今月から副業PdMを始めたが果たしてうまくいくか
— 🐘 (@satoshihirose) July 17, 2022
本業でも最近は Product チームと一緒に働いたり、Product Management 領域の仕事をしており、その中でプロダクトをマネージすることに興味が湧いてきている。なので、これまでの経験を活かして Product Manager にトランスファーができるか少しずつ検討している（この意思決定は特段急いではいない）。
Product Manager 業を体験するのに一番早いのは、プロダクトを自分で作ることかなと思ったので、サイドプロジェクトで何か出来ないものかと考え始めている。
億万長者が身分を隠して100ドルの所持金といくつかの持ち物だけで100万ドルを稼ぐチャレンジ番組
— 最速配信研究会 山崎大輔 (@yamaz) April 15, 2022
1. いきなりビジネスをはじめず、生活費のまずは確保
2. 売るものを見つける前に買い手を先に探す
とか参考になりまくる。https://t.co/1I9gjkNc5l
プロダクトを作る前に実際に引き合いがあるかを確認するのには基本のようなので、コンサルとかで入って悩みを聞いたりするのが良いのかなと思い、まずは個人事業用のサイトを作って公開した。
まず個人サイトをnotionで作ってみて出来そうなことを書いてみた。https://t.co/XZdFZmMZTN https://t.co/NVdIv5Iqhq
— 🐘 (@satoshihirose) August 12, 2022
作るプロダクトのテーマとしてはできれば、システム運用を楽にしてひとりのエンジニアにレバレッジをかけられるようなサービスがいいかな。何か新しいことをしようとしているスタートアップは好きだし、SaaS も好き。人手が少ないそういう会社を手助けできれば嬉しい。特に自分の出自周りのクラウドインフラ、データエンジニアリングあたりに関連したもので。
コストやリソースをモニタリングできるだけじゃなくて個別機能のユースケースごとにlinterみたいなことが出来ると良いのになと思っている。自動Technical Account Manager。
— 🐘 (@satoshihirose) August 13, 2022
いまいま考えたアイディアとしては、クラウドリソースのコスト管理やアセスメントができるサービス。例えば、企業によってはAWS のリソースにタグを付けてチームごとコンポーネントごとのインフラコストを算出してコスト管理をしていたりする。きちんとルールを策定して運用できている企業ばかりではないと思うので、その運用やコスト分配の設定を楽にできたり可視化やwarningが自動でできたり、サービスの利用状況や設定を見て適切なインスタントタイプや使い方をサジェストしてくれるようなサービス。無駄なリソースや微妙な設定を見えやすくしてITや開発部の作業時間の削減とシステムコストをスリム化して良いプラクティスを適用する。ってのをAWS以外のクラウドサービスにも対応できたら嬉しそう。
作ったら買っても良いよって人がもしいたらご連絡ください。 もしくは、話を聞きたいよ、困ってることがあって相談したいよ、ってのでも良いのでご連絡ください。
