エンジニアになってみて、難しいなって思ったコト

投稿者: | 2019年12月8日

この記事はGMOアドマーケティング Advent Calendar 2019 8日目の記事です。

はじめに

こんにちは。
GMOアドマーケティングのKONCEです。

新卒で入社し1年半以上がたち、右も左も分からない状態だったのが、右ぐらいは分かるようになってきたのではないかと思います。
今回は実際に現場のエンジニアになってみて、個人的に難しいなと思ったコトについて書いていければと思います。


前置き(何を開発しているか)

僕の開発をしているサービスはSSP(サプライサイドプラットフォーム)です。
Webメディアやレコメンドウィジェットからのリクエストを受け、アドネットワークやDSPに対してリクエストを送り、そのレスポンスでオークションを行い、勝者のより高い広告をWebメディアに返すことで、Webメディアの収益向上に貢献することが、SSPの持つ基本的な使命です。

アドネットワーク、DSP、Webメディア、レコメンドウィジェットの中間のサービスゆえに、他チーム(他社)との連携が非常に多いチームで開発を行なっています。


難しいと思ったコト

見積もり

作業の見積もりが重要なことは何もエンジニアに限ったことではないと思いますが、業務を行なっていく上で非常に難しいと思いました。
運用の肥大化、割り込みタスク、技術的負債の蓄積、他チームプロダクトの仕様を知らないなど色々要因はあり得ると思いますが、
まあ一番の要因は経験不足でしょうか。これに対しては一日のTODOを毎日起こして、その進捗を毎日計ることで、徐々に見積もりの精度を高くしていこうと取り組んでいます。

タスクのペンディング

開発を行なってタスクを進めようというタイミングで様々な要因によりそれがペンディングになることは普通にあり得ると思います。(他チームとの連携が多ければ尚更あります。)
これに関して僕が難しいと思った、というか「失敗した」と思ったことは、あるタスクの実装を行い、外部要因により2ヶ月放置したということ。
「鉄は熱いうちに打て」的な感じでしょうか、いざタスクを進めていこうというタイミングで、「2ヶ月前にやっていたことを思い出す」ということにコストを使ってしまいました。
かなり非効率的ですし、ペンディングがある可能性があるなら先にレビューを終えておくとか、そもそもスケジュールを密に詰めるとかやれることはあったので反省です。

影響範囲の大きさ

広告のシステムは1日に何億というリクエストを捌くので、小さな改修でも、影響範囲は大きくなりがちです。
あらゆるケースを想定すること、上から下までの仕様や挙動を知ること、パフォーマンスを考慮すること、影響範囲を小規模に抑えて設計することなどを常日頃から考えている訳ですが、
いつだって難しいと思いますし、それが面白みであるとも思えます。

コミュニケーション

僕は普段の生活は割とロジカルに考えないタイプで、「とりあえず」、「ざっくり」のようなあまり後先考えない感じの話し方をしますが、
エンジニアのメンバーはロジカルな方が多く、その上人それぞれ個性があるので、ディスカッションや仕様の提案をする時などの意見を伝える時は苦戦することが多いです。
トライアンドエラーで慣れていったという感じですね。「あの人はこの辺りを気にするから調べて用意しておこう」的な。足りなくても自分の考慮しきれていない面など得られたりしますので用意し得ですね。
これを繰り返していったことで、営業の方に噛み砕いて説明するといった作業が楽になる、というオマケがあったのでよかったです。


最後に

エンジニアになってみて、プログラミング言語など技術的なことに対して難しさを感じたというよりは、それらを取り巻く環境の方がよっぽど難しいと思えました。
今後はそんな環境をより良くする技術やノウハウなんかもまとめていこうと思います。

明日は、あおんたさんによる「他社様の企業理念を分析してみた話」です。
引き続き、GMOアドマーケティング Advent Calendar 2019 をお楽しみください!

■エンジニア採用ページ ~福利厚生や各種制度のご案内はこちら~
https://www.gmo-ap.jp/engineer/
■Wantedlyページ ~ブログや求人を公開中!~
https://www.wantedly.com/projects/199431
■エンジニア学生インターン募集中! ~就業型インターンでアドテクの先端技術を体験しよう~
https://hrmos.co/pages/gmo-ap/jobs/0000027