顧客の潜在的な需要を考えられるビジネス寄りのエンジニアでありたい
前職が教師であり、人を喜ばせることが好きです。
個人開発も何度か企画しアプリを作りましたが、使ってもらえないことが悩みでした。
そこから「人に使ってもらえるアプリを作りたい」と思うようになり、現職で使ってもらえる社内ツールを作れたことがとても嬉しかったです。プログラミングを極めるよりも、プロダクトを企画可能なエンジニアになりたいと思いました。
現場に参画初期は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作成、検証、レポート作成まで一人で行った。
普段から営業からちょこまかと調べて欲しいデータの依頼がきていたので、そのたびにクエリを書いたり、他のメンバーに割り振りを可能にしていた。
チームメンバーへの仕事の割り振り。チームメンバーのプルリクレビュー。
チーム内に暇なメンバーがいれば、仕事をbacklogのチケットにまとめ、リモートでも仕事ができる状態まで指示を出すこと。コードの可読性を一定に保ち、属人化を防ぐこと。
自分は八方美人でかつなんでも自分で完結したがる気質があるので、つい営業側の仕事を全て引き受けて自分で処理を行っていた。初期は「仕事は奪うもの」と言われていたので、素直に先回りして業務を行うようにしていた。その結果営業側が甘え始め、チームの負担が増えていった。そこでできそうな仕事を見つけてもまずは連絡が来るまで待ち、連絡がき次第チームリーダーに報告・相談。営業にチケット記入を頼むことを徹底した。簡単なSQLでの調査であれば、コメント付きのSQLを共有し、営業にもSQLを勉強してもらうよう勧めた。また暇な時間があれば自動化できるところを見つけ、実装が得意なメンバーに相談し、できるだけ自分だけで完結しないようにした。自分で完結して属人化を防ぐために、ドキュメント整備も積極的に行い、必要であれば経緯や内容をcacooやパワポでまとめて説明会を開いた。
クラウド技術、コンテナ技術、セキュリティ、ネットワーク。
過度な期待も過小評価もされることなく、
黙々淡々とこなせる環境です。