はじめに

オールアバウトグループの新卒1年目エンジニアが投稿する企画『テックブログ新卒週間2023』。

今回はイシノがお送りします。

私は2022年4月に入社し、6月末まで外部でのエンジニア研修を受けておりました。研修後はメディア開発1Gに所属し業務をしております。

本記事ではメディア開発1Gのメンバーとしてジョインしたのち業務を進めていく中で苦労した点、どうやって改善をしたのかについて紹介していきます。

困っていたこと、どう改善をしたのか

これから社会人一年目の私がぶつかった壁とどうやってそこに向き合って改善をしたのかについて紹介していきたいと思います。

私が困っていたと感じていた点は以下になります。

情報量の多さ
わからない単語、用語の多さ
All Aboutをはじめとしたメディアを取り扱う運用の方々(以下、「事業部の方」とします)とのコミュニケーションの難しさ
メディア開発1Gが保持しているアプリケーションの数が多い
コードが読めない

情報量の多さ

外部での研修を終えた私はこれからどんな開発をしていくのだろうと心を躍らせてチームへとジョインをしました。その中で一番はじめに感じたことは、情報量の多さです。

私のチームは"メディア"と名前がついていることからメディアAll Aboutをはじめとしたメディアを取り扱う運用の方々とのコミュニケーションをとる機会が多々あります。そのため、連絡ツール(弊社ではslack)上で目まぐるしいほどの情報が行き来をしています。何をよく読んだらいいのか、全部認識していないといけないのかと自問自答しながら考えていました。

解決方法として情報の重要度、緊急性を意識するようにしました。その上で自分の中で、今見るべきなのか今日中に見ればいいのか、と優先順位の位置付けを行うようにしました。優先度合いががわからない場合には積極的にチーム内でコミュニケーションを取るようにして、話し合うようにしました。

今は業務自体に慣れてきたこともあり、拾える情報の量も増えていますが、それでも一度に多くの情報が入ってくるタイミングはあるのでまとめて見る時間を確保して情報過多になりすぎないような努力を続けています。

わからない単語、用語の多さ

新卒一年目で入社したタイミングから起きていた問題ではありますが、わからない用語がとても多いです。それも世間一般で使用されているもの、会社固有の用語などもあり初めは会議体での内容もわからないほどでした。

中でもわからない用語が急激に増えたのがチームにジョインしてすぐの1~2週間ほどでした。開発部内ではインフラ構成周りの用語、他チームのシステムの概要に関する用語、一方メディアの事業部での会議体ではメディアの用語に関してがわかりませんでした。

解決方法として、以下を実施しました。

メモをとって、わからないところは先輩に質問する
デジタル単語帳という書籍を用いて学習を行う

会者固有の用語に関しては質問をする以外にはないので時間をいただいて丁寧に回答をしていただけました。

特にメディアに関する用語に関しては、業務中に度々目にする、または利用される場面も多かったため、自分の中で優先度を上げて覚えるように心がけていました。初めはもちろん一番不明なことが多い時期でもありますが、その中でも少しずつ自分の糧として落とし込んでいくことでチームへのジョインもスムーズになりました。

事業部とのコミュニケーションの難しさ

事業部とのコミュニケーションをとる上で難しいと感じていた点はいくつかあります。

技術的な内容をどう噛み砕いて伝えるか
どうやって認識のずれを起こさないようにするか

1. 技術的な内容をどう噛み砕いて伝えるか

技術的な内容中心に仕様に関してのコミュニケーションを取ろうとするともちろん相手に伝わりません。事業部の方々はプログラミングに関しての知識はない方がほとんどなので技術的な内容ではなく事実ベースでのコミュニケーションを心がけました。

事実ベースというのは対応を経て何をしたいのか何ができるのかをベースに話をしていくという意味です。具体的には

広告表示がレイアウト調整などのfront側デザイン修正のような対応に関しては画面のモックを作成して目で見える形にする。
新たにシステム内に仕様を追加するような対応では例としてボタンをクリックしたらどのような挙動をするのか。

などが明確になる形でのコミュニケーションを行いました。その結果デザイン修正に関してはデザインが目でみてわかる形になり、より明確に意思疎通が行えるようになりました。また、仕様など機能追加に関しては事業部の方が想定した挙動ができているのか、使いやすい機能になっているかのフィードバックももらえ、運用の方と開発とで有用的なコミュニケーションをとることもできるようになりました。

2. どうやって認識のずれを起こさないようにするか

簡潔にいうならば綿密にコミュニケーションをとることです。また、不安のある状態でリリースをしないということを徹底しています。

そのため、少しくどいくらいに仕様に関しては質問を心がけるようにしています。広告の表示やデザイン修正などに関しては広告が出ているか出ていないか、デザインが修正されているか、されていないかの差しかないのでそこまで認識のずれは起きづらいと思っています。しかし、特に仕様の追加などに関しては動作検証として実際に動かしてみてもらうというのを行っています。開発側がこれは使いやすいと思って作成したものが運用側にとってはそこまで使いやすくない、または使いずらいなんてことは往々にあると思います。

事業部から提案書をいただく
それをもとに設計し実装をする
運用の方々に触っていただいてフィードバックをいただく
再度実装する

このサイクルを行うことがより良いものを開発側と運用側で作るには欠かせないことだと思います。開発側が使いやすいと思うのはあくまで推測の域を超えないため、綿密なコミュニケーションを心がけて使用を詰めていくことがいいと思います。

メディア開発1Gが保持しているアプリケーションの数が多い

メディア開発Gは他の開発部署に比べて扱うアプリケーションの数がとても多いです。そのためチームジョイン当初はどのアプリケーションがなんと呼ばれるシステムなのか、理解するだけでも一苦労でした。アプリケーションがとても多いので配属されて一年経つ今ですら、システム概要に関しての理解が薄いアプリケーションもあります。

この解決方法として私はよく改修の入るアプリケーションを理解するところから始めました。大きな一つ一つのアプリケーション単位ではなくサービス同士のつながり方を意識して理解することでアプリケーションの点の理解ではなく、線での理解に努めました。その結果一年たった今ではよく改修の入るアプリケーションに関してはシステム自体の理解、構造の理解に関してある程度の知識をつけることができました。

コードが読めない

恥ずかしながらなのですが、入社した当初はコードから実装を理解することに関してとても苦手でした。メソッド単体程度ではある程度読解することができていたのですが、全体を通しての処理の流れの理解ができていませんでした。そのため、チームジョイン当初はメソッドを分割しないで処理の順番で書いてくれたほうが楽なのにくらいに思っていました。

最も今では考え方も変わり1メソッドに1つの役割を意識して実装を心がけています。

こちらに関しては正直慣れていき読めるようになったものもありますが、考え方としてはマクロ的視点を持って読むことだと思います。プログラミングは入力と出力の繰り返しと入社して間もない頃に先輩からアドバイスをいただきましたが今はそのおかげで素早くコードを読むことができています。今まではどの行で何が行われているのかを全て把握しようとして情報量の多さに理解ができていませんでしたが、何を引数でもらって何を出力しているのか、これを見るだけで大体の実装は理解することができるのに気づきました。またショットカットキーなどの理解も増え、実装の内容を追うことに関してはある程度の自信がついてきました。

今後はコードを追うことはできるようになってきたので、そこからのリファクタリングや、改修の際にリーダブルな実装ができるようになりたいと考えております。