オールアバウトナビエンジニアの働き方と一年間振り返り

f:id:allabout-techblog:20210325093837p:plain

はじめに

毎年恒例オールアバウトグループの新卒1年目エンジニアが投稿する企画「テックブログ新卒週間2021」を開催します！今回は、オールアバウトナビ（以下からナビで省略します）システム部の@monpeiがお送りします！

ナビの詳細は下記のリンクからご確認いただけます。

www.allaboutnavi.co.jp

昨年12月のテックブログの記事ではナビに入社から12月までの、業務内容や自分が感じたことについての記事を投稿させていただきました。前回の記事の続編でもあるので合わせて読んでいけると嬉しく思います！

allabout-tech.hatenablog.com

今回の内容は以下のことについてお話します

ナビシステム部の働き方について
配属〜現在まで働いて　振り返り

前回の記事ではナビシステム部の働き方や雰囲気をお伝えできなかったので、ぜひ知っていただきたいです！よろしくお願いいたします。

ナビシステム部の働き方について

ナビシステム部はどんなことをやってるの？

私たちは主に以下のようなことをしています。主に自社で保有している4サービスのサイト及びCMSの運用と保守、定期処理するためのバッチ処理の作成に加え、集計作業の自動化を進めています。最近だとCakePHPで動いているシステムをLaravelへ移行する作業を行っております。移行背景としては既存のコードが複雑になっており、新規機能追加や改修を行う際に非常に変更がしづらい作りになっているためです。また、オールアバウトグループでは主にLaravelでアプリ開発を行っているため、多くの社内エンジニアが改修しやすくしたいという意図もあります。

ナビシステム部コンセプト

ナビシステム部では以下のような取り決めをしております。

「やらなくていいことをやることは、やらないといけないことをやらないより良くない」

少し遠回しで呪文のように見えるかと思いますがこれはあえてです。（笑）意味としては本当にやるべきこととやる必要があるものを精査し、やる必要があるもののみに注力しよう！とういことです。ナビシステム部の開発チームはエンジニア2名とマネージャー1名で構成されております。少人数で開発を行っているため、現状やる必要のないことに注力してしまうと、他の重要なタスクに手をつけられなくなってしまいます。そんなことが起きないように↑のようなコンセプトを基に業務を行っています。しかしながら、業務で困っていて相談にきているのに、開発コストがかかってしまうからと依頼を受けないのは違いますよね。ナビシステム部では↑のコンセプトとは別に親切であることというキャッチフレーズも抱えています。時にはシステムの開発ではなく業務フローの改善を提案をしたりすることで問題を解決します。

システム部外の部署との距離感が近くなった

依頼者に定期的にヒアリングの時間を設けるようにした
システム部への相談や依頼に開発メンバーも参加することが多くなった

上記二つが今年に入ってから変わった点です。開発メンバーも積極的に開発前段階の話し合いに参加するようになりました。背景としては、新しい機能やシステムを作ったけど2,3ヶ月ほどしたら使われなくなってしまうといったケースが多々あったためです。こういうことは良くあることでしょうが、せっかくならお互いが納得のいく良いものを作りたいですよね。現場の業務フローや目標、課題を定期的にヒアリングすることにより、実際に作ったものが後々になっても使ってもらえるように、依頼者とシステム部の認識に差異が出ないようにすることを試みてます。まだ、実践してから日が浅いので開発後に活きてくるかはわかりませんが、どんなことに実際に悩まれているのかを把握することができ、より他部署との信頼関係を築けるようになりました。個人的にもただ開発をするのではなく誰のために何のためにを考えて開発をする方が、仕事へのモチベーションと帰属意識が上がり良いと感じています。

ナビ開発の流れ

基本的にSlackのチャンネルで依頼のやりとりが行われます。マネージャーが依頼に対してレスポンスを返し、開発をするべきと判断した場合はシステム部メンバーにタスクを割り振ったり、処理が多くなりそうなタスクはBacklogにチケットを作成し開発を行います。 2021年になってから開発の流れに少し変化が出てきました。

改善点（タスクが埋もれてしまうことが多くなった）

今年に入ってからタスクが埋もれてしまったり、依頼されたことに認知できていないケースが多々ありました。各プラットフォームごとにSlackのチャンネルを分けていたのですが、様々な情報が行き交い依頼内容が埋もれてしまいました。一つのチャンネルの役割があまりに大きかったため新しくチャンネルを追加し、依頼用、レポート通知用など用途別に分けました。またここ一ヶ月では一つのメッセージに複数の依頼を頂くことが多く、やりとりをしているうちに話題が右往左往し、埋もれてしまっていたケースもありました。

そのため以下のように変更することを決めました。

従来）Slack → 依頼精査 → 開発着手 or Slack → 依頼精査 → Backlog → 開発着手

改善）Slack → Trello → 依頼精査 → Backlog → 開発着手

Trello及びBacklogの詳細は割愛しますが、一言で言うとプロジェクト管理ツールのことです。

Trello trello.com

Backlog backlog.com

今までだとSlack上で依頼精査し開発着手といった流れでしたが、この精査する段階で依頼が埋もれてしまうケースがあったため、依頼をいただいた場合はシステム部メンバーがTrelloに記載し精査することにしました。ゆくゆくは、依頼者が直接プロジェクト管理ツールに記載し、開発に注力できればと考えています。依頼数や内容の変化が大きいので可変に対応していくつもりです。

配属〜現在まで働いて　振り返り

気持ちの変化を可視化し振り返り

ナビシステム部に本配属されてから今年の3月までの各月の気持ちの変化についてグラフ化しました。

f:id:allabout-techblog:20210317193310p:plain

このグラフを基に振り返りを行いました。

7月〜本配属となり業務がスタートしました。最初の二ヶ月に関しては自社サイトや社内CMSの軽微な修正や改修を担当しました。研修を終えて本格的に仕事ができる高揚感と小さい規模でもアウトプットが出せた時は非常に嬉しかったです。

しかしながら9月,10月と気持ちがやや下がり気味になりました。自分の中で一番大きかったのは一人での作業時間が増え、リモートワークで一日ほとんど誰とも会話せず業務をすることが多々あったことです。初めのうちは中々お互いの関係性を築くのに時間がかかってしまい、仕様の確認や質問を躊躇ってしまうことが多かったです。私の性格上、相手は忙しくないかな？時間を割いてしまうのが申し訳ない、簡単な質問で相手を失望させないかなと疑心暗鬼になることが多かったです。結果として、後々仕様が漏れていたり、開発スピードが遅くなっていました。また気持ちの面でも、早くアウトプットしたいという気持ちと実際の進捗具合に大きな差が出て悪循環が生まれていました。

少し調べてわからないことや疑問はすぐ質問する。後々になって疑問を残したままにしないことが重要だと感じ、この数ヶ月の期間を通してようやく自分の中に落とし込むことができました。気軽に質問や相談にのって下さる先輩方に感謝感謝です🙏

年末から翌年1月にかけて段々とモチベーションが高くなっていきました。エンジニア間で定期的に開催しているワークショップやLT会に発表あるいは参加する機会が多くなりました。また他部署のエンジニアの方とLaravelを用いて自社内の勉強会等のイベントを管理するツールの作成に携わりました。こういった機会が自分の中で抱えていたコミュニケーション不足の解消につながったのと同時に、少しずつですが技術的な知識が増えていきました。また、実装に時間がかかっていたタスクがリリースできたことによる達成感や、社内ツールの大幅改修をペアプロで作業する時間はとても貴重でした。

2月は少し気持ちが下がり気味になってしまったのですが、この要因は私が作成したいくつかのバッチ処理が適切に動作していなかったことです。

対象のバッチはphpで動いており、以下のような処理をしています。

DBに接続し、レコードから正規表現を用いて外部サイトのURLを抜き取る
cURL関数を利用し、クエリパラメータにURLをつけてAPIを叩く
APIを叩いた時のレスポンスステータスコードによってレコードの値書き換え

今回のバッチが上手く動作しなかった原因は、正規表現を用いて外部サイトのURLを抜き取る処理で捕捉できていなかったパターンがあり、URLを正しく取得できなかったことです。

適切に動作していなかったこともよくないですが、それ以前に必要なlogを残していなかったことが一番の失敗でした。取得したURLが実際にどのような値かを記録できていなく、logに残してさえいればもう少し原因が早く見つかったと思い、後悔しました。

また、APIを叩いた時のレスポンスのボディ内容が大量にlogに残ってしまっていて、確認し辛い状況を作っていました。 curl_exec()でリクエストを送信時、オプションで指定しなければレスポンスのボディ内容が標準出力されます。こちらは不具合発覚前に修正しようと思いつつ、処理に直接関係ないからと後回しにしてしまい、他のタスクを優先してしまいました。

結果として大量の不要なlogがある、欲しかったlogがない状況から、バッチが上手く動作しない原因調査に時間がかかってしまいました。当たり前のことですが、適切なlogを残す、不要なlogは大量に残してしまうと欲しい情報が埋もれてしまうため、きちんと整理することが重要だと感じました。

そして現在3月ですが、主に社内CMSの改修や機能追加を編集業務をしている方と相談しながら進めております。他部署から直接ご相談や現状のシステムの動きなどの疑問を多く頂けるようになったことが密かな喜びです😊 また、エンジニアではなく普段集計作業をしている方と一緒にGASを用いて集計作業の自動化を進めたり、勉強会も少しですが行うようになりました。

このコロナ禍でなかなかコミュニケーションが取り辛く関係性が希薄になりがちですが、着実に自分のできることを増やし信頼されるよう心がけたいと思います。