【入社エントリー】データエンジニアが風音屋に入社して6ヶ月で学んだこと
こんにちは。風音屋データエンジニアの妹尾です。入社して早半年が経ちました。ずっと書き損ねていた入社エントリーの記事です。
風音屋に入ってどんな成長ができたかという点を振り返りながら書きました。風音屋への入社にご興味のある方が、「入社後どんな成長ができそうか」「自分の目指す方向性に近い成長ができそうか」をイメージする助けになれば幸いです。
自己紹介
お仕事
ECサイトの開発・運用をする会社でWeb開発エンジニアとして2年
ウェブサービス企業でデータエンジニアとして1年
風音屋に転職
新卒入社した会社では、未経験からエンジニアとしてのキャリアをスタートしました。主にECサイトの開発と運用を担当していました。2年目からは顧客折衝やチームのマネジメント、グローバル規模のシステム移管も経験させていただきました。
データエンジニアに転職したきっかけはスカウトです。クラウドサービスの利用経験があったのと、Pythonを触ったことがある、ということから興味を持っていただきました。
実は、スカウトをもらった段階では「データエンジニア」がどういう職種なのかもあまりよくわかっていませんでした。しかし、スカウトをきっかけにデータ関連の記事を読み漁り、データ領域の将来性やその職種自体の魅力に惹かれ、データエンジニアとしてのキャリアをスタートしました。
趣味
音楽とお酒とお笑いが好きです。あとベースも弾きます。
風音屋に入社して連れていってもらったGoogle Cloud Next '23では、昔から好きだったThe Rootsのコンサートにも参加できて嬉しかったです。
サンフランシスコで知り合ったエンジニアとお酒を飲みながらコンサートを観ました。クエストラブはめちゃくちゃデカかったです。
入社した経緯
弊社社長ゆずたそ（@yuzutas0）がMENTAで提供していた「第二新卒が3ヶ月でデータエンジニアへの転職を目指す講座」（※現在はリニューアル準備中）を受講したことがきっかけです。受講の振り返りは別のエントリーにまとめてありますので、よろしければご一読ください。
K-DECの受講終了時にオファーレターをいただきました。K-DECとカジュアル面談を通して、データエンジニアとして成長するにはこれ以上ない環境だと確信し、入社に踏み切りました。
半年間の振り返り
冒頭に記載の通り、ここからは、「自分がこの半年間で成長ができたと感じていること」についてご紹介します。
風音屋が大事にしている「プロフェッショナル・マニフェスト」の「3つのスキル」の観点から、自分の担当した業務を振り返りながら書きました。
風音屋の制度や文化については、私と同期入社の濱田さんの入社エントリーに詳しく記載されていますので、是非ご一読ください。
風音屋の「3つのスキル」について
風音屋には、「3つのスキル」という指標があり、これらを基に毎月の評価が行われます。つまり我々社員はこの3つのスキルを向上させながら、毎日の業務をこなしていくことになります。
皆様のご関心の高いであろう内容順（「Technical Skill」→「Project Skill」→「Human Skill」）でお話しいたします。
ただ、風音屋ではこれらの3つのスキルに優劣はなく全て重要であるという扱いなので、最後まで読んでいただけると嬉しいです。
Technical Skill
Dataformの知識
GCPのサービスであるDataformに関する知識です。
こういったSQLベースでデータパイプラインを管理するELTツールは、実務でほとんど触ったことがありませんでした。
入社してからDataform導入のプロジェクトを担当しており、風音屋メンバーやアドバイザー陣に助言をもらいながら、かなり実践的な形で新しい技術を学ばせていただきました。
技術選定に必要な調査から、設計、開発、現状の運用をどのように置き換えるのかなど、システム導入の流れも学ばせていただいています。
また、Dataformのsqlxファイルの生成をプログラムを用いて行うようにしたので、Pythonを書く機会もありました。こちらの実装については「INFORMATION_SCHEMAを使用してBigQueryのViewの定義をDataformに移管する」という記事で紹介しています。
また、技術選定時の調査をベースに「dataformのSCDパッケージとdbtのsnapshot機能を比較してみた」という記事も書きました。こちらも是非ご一読いただけると嬉しいです。
データモデリングの知識
データウェアハウスにおけるデータモデリングの知識です。
入社当時は、dbtのBest practice guidesの内容やディメンショナルモデリング、Data Vault 2.0を薄く知っているという状態でした。
データモデリングはデータ領域で一番興味のある分野だったので、それを社長に伝えたところ、データモデリング関連の業務を担当させていただくことになりました。
去年は、元々社内にあった資料でデータモデリングを学び、日々の中間テーブルの設計やSQLを書く業務に活かしてきました。社内には「Data Vault 2.0 が 30分でわかる記事」「中間テーブルのレイヤー名の候補一覧」「ディメンショナルモデリングの実施ステップ」といった資料があり、深く学ぶことができました。
そうやって学んだ知識を、風音屋メンバーやアドバイザーに助言をもらいながら、より実践的なノウハウとしてまとめ直しました。度重なる社内レビューを経て、「30分でわかるデータモデリング」というドキュメントになりました。複数のクライアントへの提供資料としても展開されており、実際にお喜びの声をいただく機会もございました。
他にも風音屋アドバイザーのお力をお借りして「ディメンショナルモデリングでアクセス分析のファクトテーブルをどう設計するか」という記事も書きました。
SQLスキル
ダッシュボード作成に必要となるSQLのスキルです。
私は、前述のMENTA講座「K-DEC」を受講するまで、分析用のSQLをほとんど書いたことがありませんでした。
風音屋に入社してから、ダッシュボード作成やデータに関する調査、データモデリングの設計などで日常的にSQLを書いています。
その経験から、入社前は半日かかっていたようなSQLを書く作業が、今では1、2時間で終わるようになりました。SQL自体の品質も向上したと思っています。
また、今月の私のKaizen Hour（稼働の20％を自主学習にあてる制度）のテーマも「SQLスキルの向上」です。
SQLに関する本を読み、「他のメンバーのSQL業務を奪っていく」「学んだことをノウハウページにまとめる」ということをやって、学習したことを会社に還元していこうと頑張っています。
稼働の20%を「スキルアップ学習」「技術検証」「記事執筆」「OSSコントリビュート」などの斧を研ぐ時間に当てる「Kaizen Hour」制度を設けています。ツール利用料や書籍代は会社が負担します。
ドキュメンテーション能力
言語化、ドキュメント化のスキルです。
入社当時の私はここの課題感が大きく、うまく仕事が進められないことが多くありました。その課題感を社長に伝えたところ、いくつか本を紹介いただいて「文章を整える技術」と「文章力の基本」を読みました。
また、去年の12月はドキュメンテーション能力を向上するために、アドベントカレンダーに参加してTechblogで記事を3つ書きました。
その際、2時間ほど社長とペアワークして自分の書いた記事を添削してもらったり、他の人のアドベントカレンダーの記事執筆のレビューにも積極的に参加しました。
こういった経験を通して、どのように文章を書くのか、推敲するのかを学ぶことができました。今は文章を書くこと、ドキュメントを作成することに対する強い苦手意識はなくなりました。
Project Skill
依頼者の目的を理解する力
開発における目的の理解は、自分の中ではこだわってやっているつもりでしたが、今、入社当時を振り返ると足りてなかったなと思います。
依頼者の目的を本当の意味で理解するためには、ユースケースを具体的なアウトプットイメージとともに整理することが重要です。
これが出来ていなければ、期限内に最低限実現しないといけないことのラインがわからないまま、作業を進めてしまうことになります。
そしてこれは、「スコープ調整ができずに稼働過多になること」や、「オーバーエンジニアリングになり技術的な負債を抱えること」に繋がります。
「仕事は一生懸命やっているのに、クライアントに迷惑をかけてしまう」というまったく報われないケースです。
社長とのペアワークで、社長の作業手順を見て、データのモニタリングの依頼がきた時は、「ダッシュボードイメージを書く」、「そのダッシュボードの構築に必要な要素を書き出す」ということから始めるようになりました。このように整理することで、データソースからユースケースを最短距離で繋ぐSQLを書くことができるようになりました。
他にも、共同代表の竹信さんにプロジェクトマネジメントスキル向上のためのワークショップも行ってもらいました。「プロジェクトやタスクを始める時はDesignDocを書く」ことを心がけることで、依頼者の目的の先にあるビジネスへのインパクトまで意識して仕事ができるようになりました。着手時にDesignDocを書くことで、目的から逸れた行動にコストを割いてしまうことがかなり少なくなったと感じています。
こういったことが少しずつできるようになり、無駄のないプロセスで成果につながるアウトプットを提供できるようになってきました。
イレギュラーに発生する問題への対応力
システム開発・運用に障害（インシデント）はつきものです。
しかし、こういったイレギュラーな事態がプロジェクトのスケジュールを狂わせることになります。そうなったとき、どうやって問題を収束し、スケジュールを立て直すかということが大事です。
例えば、新しいシステムの導入時に既存の不具合を発見した場合は、不具合を無視してシステム導入を進めるべきなのか、既存の不具合の修正を進めるべきなのかを判断する必要があります。
私も最近こういった状況に直面したことがありましたが、不具合による影響調査の報告と、システム導入作業の一時ストップを関係者に説明しながら、プロジェクトを進めることができました。
単なる作業者ではなく、チームの一員として今何をすべきか考え、それを行動に移すことができた点に大きな成長を感じています。
Human Skill
自分の課題を把握して、対策を講じる
今までは、自分ができていないことをぼんやりとしか捉えることができておらず、具体的な解決策を出せないまま、次の仕事に取り掛かってしまっていました。
それは、自分の課題感を言語化できていなかったことに原因があったと感じています。
風音屋では、月に一回の評価のタイミングで、実務を通して発見した自分の課題の言語化をする機会があります。
そしてその課題への対策も考えて、次月の目標を提案します。
そのタイミングでアドバイスがもらえたり、より良い対策について相談しながら目標をフィックスします。
そしてまた評価のタイミングで、どのように成長できたか振り返る機会があります。
このように改善サイクルを回していくことで、着実な成長のステップが踏めるようになっています。
自分のモチベーションを維持する
これについては、特に自分は問題を抱えていたわけではないですが、会社にも大いにサポートいただいているなと思うので記載します。
私は、大学時代に2年ほどオーストラリアに住んでいたことがあり、その経験から「いつでも身一つで海外にいける状態でいたい」というざっくりとした目標を持っています。
エンジニアという職業はその目標を達成するために選んだので、「他の職種の方が自分に合っているのでは」といった迷いがなく、高いモチベーションを保って仕事に臨むことができています。
一方でエンジニアとしての仕事内容についてもこだわりたいと思っており、自分が大事だと思うことや、やりたいことは仕事の中でもなるべくできたらいいなと思っています。
全ての仕事がそうというわけではないですが、風音屋では社長が自分のWillにあった仕事へのアサインを提案してくれることもあります。
そういった意味で、風音屋自体がモチベーションを維持しやすい環境であると私は感じています。
最後に
私が風音屋らしいと感じたエピソードを1つご紹介します。
クライアント提供資料を作成した際に「貴社」という言葉を使用したところ、社長からレビューがきました。
「貴社で」というワーディングは使わなくてOKです！
妹尾さんが勝手に距離を置いているように見えるので。
風音屋では、「作業者」ではなく「クライアントのチームの一員」「プロジェクトの推進者」として仕事をするよう強く求められます。
本当にクライアントにとって意味のあることにしっかり向き合って仕事をしていくという意味で、自分の仕事に誇りを持つことができます。
ただ人から与えられた仕事を実行するのではなく、「本当にクライアントの役に立つのか」「ビジネス的な意味があるのか」「もっとこうした方がいいのではないか」を考えながら仕事ができるので、自分の仕事に納得感があります。個人的には、それが精神衛生上すごくいいなと感じています。
この記事を読んで、「エンジニアなのにそんなところまでしないといけないの？」と思われた方もいると思います。
おそらくそれが風音屋のカルチャーにフィットするかの判断軸の一つになるかなと思います。
私が風音屋のカルチャーに合うと思う人は、ずばり「自己内省力と成長意欲がある人」です。
特に風音屋のレビュー文化は合う合わないがあると思います。風音屋のレビュー文化については、「風音屋のレビュー文化を体現する「183の精神」について」という記事がありますので、是非読んでみてください。
私はこのレビュー文化によって大きな成長ができたと感じています。また、クライアントへの価値提供もこのレビュー文化が大きく下支えしていると思っています。
そういったわけで他人をリスペクトできて、お互いに高め合っていける人がたくさん入社してもらえると最高だなと思っています！
この記事を読んで少しでも興味を持っていただいた方は、カジュアル面談からでも是非ご応募をご検討ください！
この記事が気に入ったらサポートをしてみませんか？