ID:39869さん

　現場に参画初期は200TBを超えるBigdataを扱っているにも関わらず、その全体図を誰も把握していなかった。商談のたびに営業が資料データを作るために要件定義を行い、エンジニアがSQLを書いて提出という業務が発生していた。そこで「誰もがいつでも欲しいデータをわかるようなダッシュボードを作る」という可視化プロジェクトが発案された。自分はそのプロジェクトの担当となり、要件定義からSQLの作成、グラフ選定、ダッシュボードのデザイン、バッチ化まで全て一人で実装を行なった。 　リードエンジニアが技術選定を行い、データポータルが採択された。使われそうな分岐のカラムを選定し、最小限のボタン選択で見たいデータの全容が見れるようにデザインを行った。必要なSQLはGitに登録しGCPのサーバーに設置。BQコマンドを使ったシェルスクリプトを実行するだけで毎晩自動でテーブルが更新されるようにRundeckでcron登録を行った。BQのslot量や処理時間にも気を使い、パフォーマンスチューニングを繰り返した。テーブル保存量にもコストがかかっていたために、大きいテーブルを調査の上で削除したりして一月100万ほどのGCPコスト削減に貢献した。 　最初はシニアエンジニアの指示通りに作成していたが、現場のニーズと乖離していたためダッシュボードは使用されないことが課題であった。そこで営業に使ってもらうことを目標に自分で要件定義をし、営業が商談の場で適切なデータを絞り込めるようにダッシュボードを大幅に改変した。全体を見ることよりも、「誰が」「何を」みたいのかを考えながらグラフを作成。30以上あるテーブルの仕様も自分で調べたり他部署の先輩に教えてもらい、使えそうなカラムがあればそれも可視化。データに変化があるたびにslackで報告し、可視化の必要性を地道にアピールした。資料の作り方やデザインも本を読んだり営業の先輩のアドバイスを受け、使いやすいUIを意識した。現在は営業の調査ツールを超え、職場のKPIを表す指標や、新人にデータを説明する資料としても用いられている。

　当時はバッチシステムの監視システムがゆるく、かつリカバリにも手動オペレーションが多いため、問題が多発していた。そこでSQLのコードを読み、バグ原因の分析・調査を行なった。SQLはどれも100行~500行ほどのコードであったが、地道にデバックを行い必要に応じてリファクタリングを行なった。その際にSQLのテスト項目と実施に使うSQLコードを作成し、顧客へ提供するデータの品質向上に寄与した。またTresureDataとBigqueryでのDB基盤移行では最適なクエリの書き方がそれぞれで異なっていたので、パフォーマンスチューニングを頻繁に行い、1時間以上かかる処理を2分以下まで縮めた。 　調査レポートを元に、cacooを使い設計/仕様のドキュメント化を行なった。 　設計を元に監視システム、自動リカバリ機能の実装を行なった。使用した技術はリードエンジニアが定めたdigdag,ShellScript,python,bigqueryである。リードエンジニアが作成した独自フレームワークを参考にしながらpythonやShellでエラーを拾うライブラリや関数を作り、digdag ワークフローで自動リカバリを実施、最後にアラートをslackに通知する仕組みを実装した。リカバリも手動で行なっていたが、変数を決めてコマンド一つでリカバリされる仕組みを作り、オペミスを減少させた。最終的に8ヶ月で13のバッチのリファクタを行なった。

　既存の定常連携のSQLコードに追加の処理をいれることが決定された。決定後、まずコードを追加して提供データの質が変容することで顧客のビジネス毀損を不安視し、問題点をまとめて報告した。加えて複数の顧客に合わせた改変処理を数パターン作り、技術側、営業側、双方の要望を満たすような提案を行った。 　現場の技術側と営業側の要望を汲み取り、妥当案を作成。そのための仮設立案からSQL作成、検証、レポート作成まで一人で行った。 　普段から営業からちょこまかと調べて欲しいデータの依頼がきていたので、そのたびにクエリを書いたり、他のメンバーに割り振りを可能にしていた。