皆さん、こんにちは！
FLINTERS データチームに所属しています、西垣と申します。
今回はFLINTERSブログ祭りと題しまして、部署や職種に関係なくチームを組み、それぞれ思い思いの内容でブログを投稿することで会社を盛り上げよう！という企画の一環としてこちらの記事を投稿させていただく運びとなりました。
2023年入社かつ、チームの中で若い、私、西垣がフレッシュな意見で序盤のスタートを切らせていただきますので、お手隙の際にご一読いただけること、また今後の記事に期待を持っていただけますよう頑張らせていただきます。
今回の企画には記事ごとにテーマを設けているため、この記事は
#FLINTERS #データエンジニア #教育
に該当するものになります。
メインテーマはズバリ、業務における私の肩書きとなっているデータエンジニアについてです。去年の7月に配属となり、約1年のまだまだ経験の浅い自分が何か意見を出すのもおこがましいかもしれませんが、気付きや重要なこと、そしてこれからのステップアップのために必要なことなどを、とても当たり前のことかもしれませんが、ある種の備忘録として書いていきたいと思います。
これからデータエンジニアを目指す方、またエンジニアに興味がある方は多いと思いますので、ご参考になれたら非常に嬉しいです。
データエンジニア業務について
前提としてまずは、自分の所属する、ある顧客向けのデータエンジニアチームの業務内容についてざっくりと紹介します。
データチームの役割
大規模データ分析基盤の設計・開発・運用を行い、データを誰でも簡単に分析可能な状態を実現することを目的としています。
具体的には下記をメインに業務を行なっています。
- データの流れの整備
- 広告媒体の広告配信データや顧客データを取得・加工するプログラムの開発・保守
- パフォーマンスの最適化
使用している技術
- バックエンド
- Bash, Python
- インフラ
- Snowflake (Digdag, Embulk)
- DBT (Data Build Tool)
- AWS (S3, RDS, Athena, DynamoDB, AWS Batch, Glue 等)
- BI（ビジネスインテリジェンス）ツール
- Tableau
エンジニアリングはまさに『One for All』
私がデータエンジニアとして働き始めて気付いたことのひとつとして、『保守性の高いコード』が極めて重要である、というのがあります。
私は大学時代、工学をメインに学んでおり、作業の一環としてコーディングを行う機会は多くありましたが、その殆どは自分一人で構築したものです。アウトプットが正常であればよかったのでコードを誰かに見てもらうこともなく、常に自己完結していましたが、いざ社会の荒波に出た時に同じスタンスで作業ができるかと思えば全くそうではありません。
チーム内のエンジニア複数名でデータ分析基盤の設計や修正を行うために、以下のことを常に意識した作業が必要であると思っています。
- 見る相手を意識したコーディングと情報共有
- 所属するチームごとに存在するコーディングや構成のお作法を理解する
- 視野を広く持ち、内容に漏れやエラーを発生させないかを意識する
- もっと可読性の高い書き方はないのかと、常に模索と検討を怠らない
インフラ基盤の保守・開発を担当しているため、業務は常にエラーと隣り合わせです。有事の際には早急に対処しなければ顧客側に影響が出てしまうため、周囲と協力した保守業務を行うにあたって、チーム内外の理解を長引かせるなどの無駄なコストを削減するために保守性の高いコーディングは必ずできなければなりません。
データエンジニアとしていかなる時も『One for All ~ひとりは皆のために~』を心掛けていることが大切だと思っています。
『何でも疑ってかかる』も重要！
これはデータの保守業務において非常に重要な考え方だと思っています。
業務で一度、こんなミスをしてしまいました。
- データ格納処理(対象：データベースA)の一部を修正することとなった
- 修正箇所がズレており、対象以外のデータベースBにも影響が出てしまう状態になっていた
- テストの段階で工数削減のために今回必要のない(と思っていた)処理部分をコメントアウトして実行した
- 実際にはコメントアウトしたことでエラーが起きるべき場所をスルーして処理が成功したため、正常であると誤った判断をした
- 間違っていることに気付かずリリースし、定期実行処理でエラーが発生する原因を作ってしまった
やってはいけない行動の典型例です…
問題はテストの条件で抜け穴を作ってしまったこと以上に、自身の行動に何も疑いがなかったことにあったと思っています。
- 今から行う変更が本当に正しいと断言できるものか？
- 何か判断に不足していることはないか？
- 本当にこの変更で以降の処理に影響は出ないのか？
このように全ての作成物や変更に対して疑問を持ち、一旦立ち止まってこと考えることが問題を避けるための前提条件として非常に重要な役割を担うと実感しています。
保守業務の一環として、利用を停止したデータベースを定期処理から除外する、または削除する作業が必要な時や、AWSやデータプラットフォーム上からリソースを変更する際など一歩間違えると取り返しのつかないことになる作業が多くあるので、この考え方は必須です。
まとめ
以上が私がデータエンジニアとして働き始めて気付いた、大事にしなければいけないことを挙げさせていただきました。
データエンジニアに限らず、どの職種にも当てはまることを述べているだけかもしれませんが、保守を行うデータの番人的な立ち位置にある我々は一層の慎重さと正確さが求められているように感じています。自分はどちらかといえば几帳面なタイプではあると自負しているので、エンジニアとしてより磨きをかけ、社内で有力な人材になれるよう努めさせていただきます！
