/home/by-natures/dev*

ソフトウェア開発者としての技術的なメモと、たまに普通の日記。

2023/02/04 読んだ記事まとめ(Kafkaユースケース, 音声合成など)

友人が ChatGPT で論文記事を要約して読んでいると聞き、質問をしたりするだけでなくそういった使い方も出来るのかと驚きました。今日は Confluent 社からの長めの記事を読みたかったので ChatGPT も使いながら読みましたが、非常に便利ですね…。記事本文を読み直すにしても、要約から読み直すと頭に入って来やすいです。要約+日本語訳も試してみたんですが、さすがにかなり時間がかかっていて要約精度も少し落ちる印象ですが、それでも概要把握には十分でした。

今調べたら ChatGPT は有料版が発表されていて、月20ドルなら個人でも全然使い続けられるなと感じました。学習が進みすぎた結果パラダイムシフトが起きたと言っている方も Twitter で見かけました。一般でも簡単に機械学習・AIの技術が使えるようになって来ていて、世の中の変化スピードがさらに早くなっている感覚があります。

www.itmedia.co.jp

今回はML系の記事が多かったですが、次はデータマネジメント系の記事をいくつか読む予定です。

QCon: Resilient Real-Time Data Streaming across the Edge and Hybrid Cloud

www.infoq.com

バーチャルカンファレンス QCon Plus に出ていたエントリーで、Confluent社のKai Waehner氏が発表しています。さまざまな業界における Kafka を利用したリアルタイムデータストリームの事例を交えながら、Kafka が耐障害性を高めたり、 RPO (Recovery Point Objective) や RTO (Recovery Time Objective) の改善に役立つことを紹介しています。

例えば記事内では Disney World でのモバイルアプリで AWS の障害によって起こった問題が紹介され、障害耐性を高める重要性が説明されています(Kafka を使って回避した・・・ということではなさそうですが):

japan.cnet.com

他にも船やドローンなどの端末からのデータ連携の方法についても紹介があります。船やドローン、他にも風力発電機などは常にデータ送信できる環境にあるとは限らず、1週間や1ヶ月など長時間に渡って接続ができなくなる状況に陥ることがあります。こうした組み込み機器に Kafka をインストールすることで、接続が回復したタイミングでデータを送ることができます。端末内のデータ容量には限りがあるため、長期間接続不能が続いた場合に端末内でデータの優先順位づけをしたり、事前集計してデータ量を減らすなどの工夫も取ることができます。

マルチリージョンに配置することで、銀行や金融サービスのための耐障害性を保つことも出来ると説明があります。他にも自動車メーカーのBMW、石油産業、小売業、さまざまな業界を紹介しながら、どのようなリアルタイムデータ基盤を構築しているかがそれぞれ紹介されていました。

新しい機能として制限はあるもののトランザクションにも対応し始めているということで、この記事も近々読んでみようと思います:

www.confluent.io

Microsoft Unveils VALL-E, a Game-Changing TTS Language Model

www.infoq.com

Microsoft 社が、音声合成に関する新しいモデル VALL-E を発表しました。

この分野は完全に門外漢なのですが、以下の論文ページではたくさんの音声事例を聞くことができます。3秒ほどの音声サンプルだけでその人の声を模してテキストを読み上げることが出来るようです。このテキスト読み上げ機能(text-to-speech synthesis, TTS)で有名なアルゴリズム LibriSpeech や VCTK との比較も載っていますが、LibriSpeech は機械音声の淡々とぶつ切りに話す感じが残っていますが、VALL-E は抑揚がしっかりしていて、より自然に聞こえました。

https://valle-demo.github.io/

Doordash Introduces ML to Understand the Marketplaces Status

www.infoq.com

こちらは DoorDash 社の機械学習モデルの紹介記事です。DoorDash は Wolt を買収していて、日本では Wolt でブランド統一しているようです。

DoorDash を使ったことがないので分からないのですが、おそらく UberEats のようなサービスでしょうか。この機械学習モデルでは店舗の営業状況を、過去の配達状況やダッシャー(DoorDashの配達員)からの画像解析などをもとに予測します。もし店舗がすでに閉店している場合、ダッシャーは時間をロスしたということで返金制度があるようで、DoorDash社としても注文を受けたが店舗が閉まっていたという状況を減らしたいようです。

システム連携を通じて確定的に店舗の営業状況を把握するのではなく機械学習のモデルで予測するというのが面白いです。リアルタイムでモデル更新されるかは読み取れませんでしたが、祝日や年末などイレギュラーな営業時間になりやすい場合でも、あるダッシャーから店舗が閉まっていた連絡を受けて自動的にユーザや他のダッシャーへの予測結果に反映されたりすると、配達ロスを最小限に止めることができそうだなと感じました。

2022/02/01 読んだ記事まとめ(Lambda with SQS, Cloud Logging in Google Cloud, OpenAssistant)

気分転換にヘッダを変えてみました。Iittala社のキャンドルホルダーが大好きで、(まだ一応)趣味のカメラと組み合わせてキャンドルを撮影したりしているので、その画像を拝借。冬場にはもちろん、友人が家に来たときなんかに使うと、少しムードが出て良い感じです。


技術記事を読む習慣をつけるために InfoQ の記事を中心に、目に留まったものを紹介します。データエンジニアリング系が中心になると思います。

全然関係ないんですが、DDDの和訳&要約書が InfoQ で無料で読めます。流石にかなり分量が少ないですが、復習によいかもしれません。前職ではこれとユースケース駆動開発についてなど、ソフトウェア開発やデータ関連技術について輪読会が盛んで、今思い返すとエンジニアにとってはとても良い環境でした。新卒入社の方が多かったので、同期同士で学ぶ流れから勉強会が盛んだったのかもしれません。

www.infoq.com

AWS Lambda で SQS をイベントソースにした場合の最大並列数が指定可能に

www.infoq.com

今までは SQS にキューが積まれると Lambda が自動スケールしてしまったようなのですが、最大並列数が指定出来るようになったようです。アカウント x リージョンごとに Lambda の最大並列数(concurrency quota)が設定されていますが、デフォルトは1000のようです:

Lambda quotas - AWS Lambda

今回の機能追加で、この Lambda の最大並列数を特定の Lambda だけが食いつぶさないように出来そうです。

Google Cloud のログ分析機能が正式版へ

www.infoq.com

Azure の Log Analytics, AWS の CloudWatch Insights に似たサービスとのこと。

CloudWatch Insights は Apache のアクセスログ解析に利用したことがありますが、文法がやや特徴的で慣れるのに少し時間が必要だったものの、大量のログから該当条件の日付ごとのログ件数をすぐに可視化してくれて、非常に便利でした。標準的なアクセスログ形式であれば、正規表現などを書かずとも解析してくれるのが助かりました。

OpenAssistant (オープンソース版ChatGPT)

www.infoq.com

ChatGPT のオープンソース版(OpenAssistant)が非営利団体 LAION からリリースされたとのこと。

LAION = the Large-scale Artificial Intelligence Open Network、MLに関する研究開発を行う非営利団体のようです。ただ学習済みモデルは提供しておらず、データと学習コストは別途必要とのこと:

Although these open-source projects include implementations of ChatGPT's training methods, they do not have any trained models currently available. Wang's project FAQ suggests that training might require "millions of dollars of compute + data" to complete.

(後で読む)QCon: Resilient Real-Time Data Streaming across the Edge and Hybrid Cloud

www.infoq.com

バーチャルカンファレンス、QCon Plus に出ていたエントリーで、Confluent社のKai Waehner氏が発表しています。

Confluent 社ということからも分かりますが、記事内の "Kafka" の単語数が非常に多く、ハイブリッドクラウドでの Kafka を利用したストリーミングアーキテクチャの説明のようです。かなり長い記事ですが、発表動画も併せて見てみようと思います。

2023/01/27 Google Cloud Professional Data Engineer に合格しました

去年末のことなのですが、Google Cloud の Professional Data Engineer の資格に合格しました。これで2022年にSlalomに入社してから、Databricks Associate Data Engineer, Snowflake ProCore, Google Cloud Professional Data Engineer の3つのデータエンジニアリングに関する資格を取得することができました。

学びとしてはクラウドベンダーの試験対策としては、模擬試験が非常に重要だということです。IPAの情報技術に関する試験も過去問からの出題はありますが対象範囲が広すぎて全てを網羅することが難しいのに対し、クラウドベンダーの試験だとそもそも試験範囲が広くないため、過去問からの出題率がかなり高い印象がありました。

AWS はまだ取得していないのですが、この3つだとダントツにSnowflake ProCore が難しくて、次点 Google Cloud, Databricks (Associateですが) は基本概念さえ押さえておけば常識的な範囲で絞り込める問題が多かったです。

Google Cloud Professional Data Engineer は社内事情で2022年中に合格する必要があり、バタバタと準備して結構要領よく合格することが出来たので、学習方法などを記録します。何かの参考になれば幸いです。SnowPro Coreに合格した時の記録 もよかったらご覧ください。

Google Cloud Professional Data Engineer 試験概要

正式名称は Google Cloud Certified Professional Data Engineer という資格です。50 ~ 60 問の多肢選択(複数選択)式で、時間は2時間あるので見直しを含めてもたっぷり時間があります。問題は4択や5択だったり、複数選択だったりと、選択式ですが難易度は高いと思います。

cloud.google.com

オンプレとの比較なら Google Cloud のマネージドサービスを選ぶと正解しやすそうな雰囲気があります。オープンソースの Spark, Hadoop, HBase などの知識も出てくるため、Hadoop 基盤上での業務が多かった私にもとっつきやすい問題が多かったです。

BrainPad さんのブログがとても丁寧にまとめられていて分かりやすかったです。

blog.brainpad.co.jp

学習方法

パートナー向け学習資料

私が勤めている Slalom はパートナー向けの学習資料が使えたので、これを利用しました。動画で学びながら、Qwicklabsで実際にGoogle Cloud 上で演習課題に沿って設定を行います。

6週間で学び終わる内容ですがボリュームがすごいのと、Google Cloud Professional Data Engineer の資格合格だけを考えると冗長だったり、試験範囲外のものも多いです。Dataflow, Dataproc, Cloud Composer, Bigtable, Google Spanner, Bigquery など、試験範囲内の製品が何かを理解しながら、特に Dataflow, Bigquery あたりに重点を置いて学ぶとよいかなと思います。

AutoML などの機械学習製品も出題が増えているのですが、模擬試験を解きながら、知らない製品が出てきたら都度調べるぐらいでよいかな、と思います。

partneronair.withgoogle.com

模擬試験

今回は2022年以内に合格するという締め切りがあったため、動画学習もそこそこにして模擬試験を利用しました:

www.udemy.com

50問x3セットで、本番も50〜60問なので本番さながらの内容となっています。上記問題集は2022年2月に作られたものですが、2022年12月に受けたところ、体感2〜3割は全く同じ問題(文章も解答セットも同じ)が出たので、2回・3回と繰り返し解いて、問題と答えを覚えてしまうのが正直手っ取り早いです。模擬試験のレビューを見ると、6〜7割同じ問題が出たというレビューもあるので、新しい模擬問題があったらそちらを利用するとよいと思います。

まとめ

資格合格だけ考えるなら、ある程度のデータエンジニアリングに関する基礎知識を前提にしつつ、2ヶ月あれば十分、しっかり勉強すれば1ヶ月、詰め込むなら1週間〜2週間ぐらいの難易度かなと思います。あまり詰め込むと(私のように)資格取得したそばから忘れていってしまうので、時間がある方はQwicklabsなども交えて実際に手を動かすのがおすすめです。

Snowflake のクエリ内変数と、executemany のテーブル指定に identifier が使えない話

Snowflake を Python から利用していて、クエリ文字列に変数をバインドする方法がややこしかったので共有します。クエリ内でプログラムから変数を渡す %s, :1, ? などですね:

Using the Python Connector — Snowflake Documentation

con.cursor().execute(
    "INSERT INTO testtable(col1, col2) "
    "VALUES(%s, %s)", (
        789,
        'test string3'
    ))
もくじ

パラメータスタイルをコネクション生成時に選ぶ必要がある

どんな方法で変数を表現するかを Snowflake へのコネクション生成時に 指定する必要があります。公式ドキュメントにも以下の様に記載されています:

Using the Python Connector — Snowflake Documentation

Snowflake supports the following types of binding:
* pyformat and format, which bind data on the client.
* qmark and numeric, which bind data on the server.

github から enum を見ても、以下の4種類が指定できることが分かります(デフォルトは pyformat

snowflake-connector-python/connection.py at main · snowflakedb/snowflake-connector-python · GitHub

SUPPORTED_PARAMSTYLES = {
    "qmark",
    "numeric",
    "format",
    "pyformat",
}

このため、例えば numeric を指定したコネクションで、%s のような pyformat でクライアント側で処理しなければならないプレースホルダを指定した場合、変数置換されずにそのままクエリ実行しようとしてしまい、構文エラーとなります。

INSERT 時の executemany に、identifier が使えない

次に少しニッチな話ですが、INSERT 文を実行する際にテーブル名などの Snowflake オブジェクトを文字列で与えて、プログラムから動的に与えられるようにした場合の挙動が、executeexecutemany で違う件を共有します。

execute

まずは execute から。これは分かりやすく、クライアントサイド(以下の例はpyformat)でも、サーバーサイド(以下の例はnumeric)でも素直に変数置換されています。

# paramstyle: pyformat -> PASS
con.cursor().execute("INSERT INTO identifier(%s) (col1) VALUES(%s);",
  ('testtable', 'test'))
# paramstyle: numeric -> PASS
con.cursor().execute("INSERT INTO identifier(:1) (col1) VALUES(:2);",
  ('testtable', 'test'))

executemany

次に executemany です。これは変数をリストや配列で渡すことで複数クエリを実行する関数です。しかしクライアントサイドで変数置換しても、サーバサイドで行っても、どちらもエラーとなってしまいます。

executemany, paramstyle: pyformat

クライアントサイド(pyformat)の場合、以下のエラーとなります:

# paramstyle: pyformat -> FAIL
con.cursor().executemany(
    "INSERT INTO identifier(%s) (col1) VALUES(%s);",
    (('testtable', 'test1'), ('testtable', 'test2')))
# -> TypeError: not all arguments converted during string formatting

プログラムを見ると分かるのですが、executemany は何故か VALUES の中のみが置換対象となっていて、最終的には以下のような処理が実行されてエラーとなります:

"%s" % ('testtable', 'test1')
-> TypeError: not all arguments converted during string formatting

プレースホルダが1つなのに対し、2つの変数を置換しようとしているため、エラーとなります。

executemany, paramstyle: numeric

サーバサイド(numeric)の場合もエラーとなりますが、エラー内容が少し異なります:

# paramstyle: numeric -> FAIL
con.cursor().executemany(
    "INSERT INTO identifier(:1) (col1) VALUES(:2);",
    (('testtable', 'test1'), ('testtable', 'test2')))
# -> SQL compilation error: Bind variable for object 1 not set

:1 に対応する変数が設定されていない、という内容のエラーのようですが、引数を見ると分かる通り変数は2つずつ渡されているため、 :1testtable として渡しているはずです。おそらくこちらの処理も、VALUES のみが置換対象となっているように見えます。

結論: (executemany ではテーブル名を動的に変更できない)

結局、executemany では変数部分を動的に変更することしかできないようです。

テーブル名は変数で渡したいけれど、executemany で実行するテーブル名はそれぞれ固定である場合は、文字列内で f"INSERT INTO {table_name} VALUES..." と変数展開するのが早そうですが、Snowflakeへ渡すクエリの自由度が高くなってしまいます。identifier をテーブルに利用して唯一パスしたのが、サーバサイド(numeric)でテーブル名を変数展開するパターンでした:

# paramstyle: numeric -> PASS
con.cursor().executemany(
    """INSERT INTO identifier("{table_name}") (col1) VALUES(:1);""",
    (('test1'), ('test2')))

同じ様な方法でクライアントサイド(pyformat)を試してもエラーとなってしまうため、注意してください:

# paramstyle: pyformat -> FAIL
con.cursor().executemany(
    """INSERT INTO identifier("{table_name}") (col1) VALUES(%s);""",
    (('test1'), ('test2')))

今回、この1つ目の paramstyle の問題と2つ目の executemany の問題が同時に起きていて、原因が分かると難しくないのですが調査に時間がかかってしまいました。。SET文を使って Snowflake 側で宣言した変数を使うとどうなるかなど、まだ試していないことも多いですが、何かの役に立てば幸いです。他にもSQLインジェクションを防ぐ手立てとして、知見がある方がいらっしゃればぜひ教えてください。

2022/11/26 SnowPro Core を取得しました

今の会社 Slalom に転職してそろそろ半年経ちます。Slalom はシアトルに本社を構えるコンサルティングファームで、テック系コンサルと言えばいいんでしょうか。この業界に入ってまだ日が浅いのですが、社内で学ぶことも多く、同僚も知見が深く面白い方ばかりで、楽しく仕事させてもらっています。コンサルティングということでクライアントワークとなり、その時々で仕事の様相がガラっと変わるのが事業会社出身の身としては新鮮です。

そんな社内では Snowflake の話題が上がることが多く、私も業務で使う場面が出てきたので SnowPro Core の資格を取得しました。簡単にですが資格取得のために行なったことをまとめます:

もくじ:

SnowPro Core 概要

現在はこの資格しかなく、上級資格は日本では現在制度準備中のようです。1000点満点中750点で合格、問題は2択(正誤)もしくは4択以上(複数選択含む)で自由記述はありません。

www.snowflake.com

学習方法

実際に触れる

当然ですが座学だけでは定着しないので、実際に Snowflake に触ると学習が捗ります。Snowflake 内のマーケットプレイスでオープンデータも簡単に使えます。私は会社が用意してくれたサンドボックス環境で学習を進められたので助かりましたが、Snowflake のバーチャルウェアハウス(実際にクエリを実行するコンピューティングリソース)は使うときに起動し、(設定次第ですが)使わなければシャットダウンされるので個人で学習もしやすいと思います。

一番小さいウェアハウス X-Small で2022年11月26日現在、AWS東京リージョンで稼働させた場合で1時間あたり$2.85です。これにストレージ料金がかかってきます。マーケットプレイスを介したデータはデータ提供元から移動されないため、ストレージ料金はほぼかからないはずなので、データの準備も必要なく、必要最低限のコストですぐに学習が始められます。

心配であれば料金に対してアラートも設定できるので、ぜひ下の料金表から確認してみてください。

料金体系 | Snowflake 【スノーフレイク】

また無料分のクレジットももらえるようですが、私は試せていないのでご興味ある方はこちらから確認してみてください: Getting Started with Snowflake - Zero to Snowflake

LinkedIn Learning

手始めに、約2時間程度のLinkedIn LearningでSnowflakeの概要を学習しました:

www.linkedin.com

LinkedIn Learning は会社で加入していたので使うことができましたが、Snowflake University という公式の学習教材もあり、こちらの方が最新機能についてもアップデートがあるでしょうから、よいかもしれません:

Tracks | Snowflake University: On-Demand

問題集

SnowPro Core は有料の過去問や、以下にリンクを記載しますが無料の問題集もあります:

www.jpnshiken.com

類似の問題も本番で出題されたので、学習進捗の確認にはよいと思います。ただ無料の問題集は解答の精度が低く、同じ問題でも答えが違っていたり、明らかに違う解答が正しいとされていることも多く、あまりお勧めしません。。Udemy では有料ですが模擬試験もあるので、金銭に余裕がある方はこちらの方がお勧めです:

www.udemy.com

公式ドキュメント

Snowflake の公式ドキュメントも1週間ほどかけて、一通り目を通しました:

docs.snowflake.com

このドキュメントには注釈が多く記載されているのですが、この注釈から問題が作られることが多いように思えます。ざっと読むだけでは足らなくて、「〜のデフォルト設定は何か」「どんなパートナーと連携できるか」などのように細かい部分までをしっかり理解する必要があります。このドキュメントが丸暗記できれば試験としては十分で、その理解を促進するための問題集や動画教材を使うよさそうです。

Cheat Sheat

有志によって主要機能の概要をまとめたものです。理解できるかを確認したり、知らない概念があればそこから公式ドキュメントを読み込むなどの使い方が便利です。私が利用したのは同僚に教えてもらった以下のものですが、検索すると他にもたくさん出てくるので、最新の機能に追従するためになるべく新しいものを使うと良いかと思います:

www.slideshare.net

1度目は落ちて、再試験で合格

実は試験1度目は落ちてしまって、2回目で無事合格できました。不合格からの再試験は特に割引などはないですが、年間に受けられる回数が決まっているため、ある程度期間を開けて学習を積んでから2回目に挑むと良いと思います。

言い訳をすると直前に Databricks の資格試験を受けていて、こちらが割と簡単だったので同じデータウェアハウスサービスの Snowflake も同じノリかな、と思って問題集も特に対策せずに試験を受けてしまいました。。Databricks の試験とかなり傾向が異なっていて、Databricks は実例を出しながらコマンドやクエリの使い方を問う問題、Snowflake は Snowflake というサービスをどこまで理解しているかを尋ねている印象で、オプションや設定のデフォルト値など細かい知識も求められます。この辺りは実際に試験を受けなくても、問題集を通じて傾向が理解できますので、問題集に取り組むのがお勧めです。

コンサルティングファームでは資格取得がしやすい

今回は Snowflake 製品について学びたいという思いから資格試験を受けましたが、コンサルティング業界ではどんな資格を取得しているかが重要なようです。クライアントから見ると、このコンサルタントがどんなスキルを持っているかを知るための一つの判断材料になるんですね。

そのため、今の会社は以前の事業会社での環境と比べると圧倒的に資格取得のための制度や補助が整っています。さすがに再試験の費用は申請していませんが、他は全て会社負担で賄えました。中には特定の資格を取得すると別途手当が支給されるものもあって、これはさすがに驚きました。これは半分推測ですがクラウドベンダーからしたらコンサルティングファームに資格取得者を増やして、そのクラウドサービスの利用を勧めやすくする狙いがあるのだと思います。

実際に業務で使わないと分からない部分も多くあると思いますが、色々なクライアントと話をする立場なので、まずは概念だけでも理解して話ができるような状態にしておくことも重要かもしれません。

ただ個人的には次は春のIPAのネットワークスペシャリストを受けようと思っています。10年以上前に応用情報技術者の資格を取得してから上位資格は挑戦していなかったのですが、そろそろ基礎知識部分もアップデートをしたいのと、ネットワークはいつも苦手意識があるので克服したいなと思っているためです。データエンジニアの肩書きでコンサルタントをしていますが、クライアント企業のネットワーク図だったり、データウェアハウスが運用されているインフラやネットワークを調査することも少なくないので、基礎知識として安定させたいなと思っています。日本の国家資格ですがクライアントは日本企業がほとんどなので、まぁ多分資格としても役に立つと思います。

Slalom ではデータ関連人材を募集しています。どんなことをしているのかご興味あれば、気軽にご連絡ください!

2022/09/24 Data Vault 2.0 輪読会に参加しました

今年の春〜初夏にかけて Data Vault 2.0 についての輪読会に参加しました。途中は退職・転職などでバタバタしていて参加できなかったのですが、Data Vault の概念を理解でき、dbt などの ETL ツールについての話題も多く、とても勉強になりました。色々と感想を書こうとしていたのですが新しい会社で学ぶことが多く、業務後や週末はのんびりしていることが多かったので、雨続きの三連休ですが久しぶりに個人的な勉強をまた始めています。

Data Vault ですが、ディメンショナルモデリングを置き換えるものではないと明言されています。むしろディメンショナルモデリングでデータマートを組みやすいように、前段のデータウェアハウスを管理しておくための技術やモデリング手法のようです。

輪読したのはこちらの本です:

Amazon | Building a Scalable Data Warehouse with Data Vault 2.0 | Linstedt, Daniel, Olschimke, Michael | Library Management

Link, Hub, Satellite など独自概念が多く登場するため、スタースキーマのように一目で分かるものではないのですが、業務システムから連携されたデータを大きく変えずにデータの意味付けだけをしてデータウェアハウスに格納するような印象で、実際に組めればデータウェアハウス以降のデータ処理が行いやすくなりそうです。実際に業務や案件で利用したことがないので、今後ぜひ実務経験を積みたいなと思っています。

Data Vault の概念理解に役立ったのが Kent Graziano 氏の記事でした:

Articles by Kent Graziano | Vertabelo Database Modeler

Graziano 氏は2021年まで Snowflake 社の Chief Technical Evangelist だった方で、氏の Data Vault に関する記事が大変分かりやすく、特にディメンショナルモデリングとの違いを理解する上でとても参考になりました。Dava Vault では Business Vault と呼ばれるレイヤがあり、その理解に少し苦しんだのですが、以下の記事で理解することができました:

vertabelo.com

datatech-jp というコミュニティでは、データエンジニアリングに関するさまざまなトピックがあり、輪読会や勉強会、各種ツールに関する議論などもされています。ご興味あればぜひご覧ください:

datatech-jp コミュニティについて | datatech-jp

余談

今年6月からは とある外資系コンサル企業…テックコンサルというんでしょうか、Slalom(スラロム) にお世話になっており、英語を使う機会も増えました。まだまだ実務で流暢に使いこなせるレベルにはほど遠いのですが、日本支部はまだ立ち上がったばかりでいろんな業界の方が転職してこられています。米国では割と有名なコンサルファームらしいのですが日本はまだ100人に満たない規模で、ベンチャー企業のような雰囲気もありつつ大企業のような制度もあり、戸惑ったり楽しんだりといった日々です。

だんだんと涼しくなってきて、季節の変わり目に見事に体調を崩しましたが、みなさまもどうぞ体調には気をつけてお過ごしください。

2022/05/07 空白期間 振り返り

先月4月末に某ウェブ系企業での最終出社を迎えました。

丸7年務めることとなり、最初3年半は研究部署でビッグデータ基盤の開発とその上で動くBIツールの開発、後ろ3年半はいろいろなサービス部署の方とやりとりをしながら、データ連携を支援する部署にいました。このブログにも書いていますがDMBOKの勉強をして業務に活かしたり、最近は社外の方とのデータエンジニアリングに関する勉強会に参加しています。データ基盤の開発か、その運用かという違いはありましたが、一貫してデータ周りで仕事をすることができました。

同僚にはとても恵まれたと思います。研究部署では経験不足な私をじっくりと見守ってもらって、後半の3年半はチームメンバーに助けてもらってばかりでした。コロナ禍でも普段の関係性があったからこそ、うまくチームとして機能したのかなと思います。

7年での変化ですが、精神的に安定したことが一番大きいかなと思います。いくつか理由はあって、1つ目は大学院で色々と上手くいかなかった心残りが研究部署で働くことで自然と消えていったこと。2つ目は主にJavaでのアプリケーション開発経験を積むことができて、ソフトウェアエンジニアとしてやっていける自信がついたこと。3つ目は最後の約2年半にチームリーダーとして働くことで、チームビルディングの経験ができたことです。

性格的な変化でいうと、とても喋るようになりました。チームリーダーになって否が応でもいろんな人と話さなければいけなかったことや、初めて話す人とも上手く仕事をしなければいけなかったこと、チームの関係性をコロナ禍のリモートワーク下で保たないといけないことなど、いろんな理由がありました。在宅勤務時に1日8時間、文字通りぶっ続けで打ち合わせをして話した日は流石に声が枯れました。笑 性格も明るくなったかもしれません。話すだけではなくて、いかにそこにいる人に話をしてもらうかにも苦心しました。話す時は話して、黙る時は黙る。話したい気持ちを抑えるという感じで、メリハリを大切にしています。

今は転職間の有休消化期間なので家の片付けをしたりしているのですが、昔の写真がこの間でてきました。昔の自分の写真を見ていると、高校から前職までのころより今の方が小学生の自分に似ているかもなと感じました。よく動いてよく喋って、人と話すのが好きで、楽しそうなことを自分で見つけて熱中しているのが、なんだか昔の自分とリンクします。

7年での変化ですが、語学のコンプレックスがなくなったのも大きな変化です。7年前に現職に入るときに「英語ができます」と豪語してしまって、もともと英語は好きでしたが英会話の方はあまり勉強していなかったので慌てて英会話の勉強を始めました。笑 オンライン英会話で学ぶうちに、語学へのコンプレックスとか、留学したかったなという後悔などが一切なくなりました。もちろん留学でしか学べないことはたくさんあると思いますが、僕がコンプレックスを抱いていたのは、留学自体ではなく英語が話せないことだったようで、手段を変えてコンプレックスをクリアできたようです。

きっかけは色々ありましたが、データマネジメントやデータエンジニアリングでキャリアを深めていきたい、けれどマネジメント業務に比重が大きく傾いてしまったので今のポジションでは十分な経験を積むことができないと考えたのが転職の理由の一つです。データ周りの仕事はなんだか面白くて、学ぶことがたくさんあって、新しいようで昔からの研究分野も意外とあって、いろんな会社で腐心している人がいて議論が活発です。この領域でもっと頑張ろうと考えた際の選択肢として、転職を選びました。転職の際にはいろんなエージェントの方や企業の方と話をさせていただいて、どの話も面接も面白くて、面接しているのか議論しているのか分からなくなるときもありました。お時間いただいた皆様、本当にありがとうございました。

いろんなよい変化があって、自信がついた7年でした。自分の扱い方が分かってきた7年、と言えるかもしれません。できないこともまだまだたくさんありますが、それさえも今後の学びの糧にできると思うと楽しみでもあります。

今回の転職にネガティブな理由がないわけではないし、今後もいろいろと上手くいかないことはあると思います。それに私生活で病気のことなどもあり、自分一人で生きているわけではないんだと強く感じた7年でもありました。それでも自分の知識や感性を磨いて、できることを広げて、役に立つ場面があるならどんどん役に立てていきたいし、上手くいかなかったなら振り返って経験として血肉にしたいと思っています。

人にも仕事にも恵まれ、幸せな7年だったと思います。現職で支えてくださった方々、本当にありがとうございました。引き続き精進していきます。

何かの折にまた日記を書きます。お時間あればまたご覧ください。