こんにちは、TANOMU開発チームの近藤です。このnoteでは3回にわたって、私がTANOMUに入社したきっかけや開発の進め方、チーム内外でのコミュニケーションなどをお伝えしています。

▼前編はこちら

https://www.wantedly.com/companies/company_339904/post_articles/885009

今回は、TANOMUの開発の仕事内容についてです。1日の仕事の流れやレビューのやり方について詳しく紹介しています。エンジニアとして、これから開発領域を広げたい、新しいことにチャレンジしたいと考えている方はぜひお読みください！

出社は月に一度。どこにいても働きやすい環境

リリース作業を全社員で見守る水曜日

まずは1日の仕事の流れを紹介します。仕事開始は午前10時。午前中は他のエンジニアが書いたコードを確認するレビューを行っています。午後は自分自身がコードを書いて開発に取り組むことが多いです。

1週間の中で最も重要なのは水曜日。TANOMUの新機能をリリースするのが水曜日の14時なので、そのタイミングでオンライン上に全社員が集まるんです。場合によっては、これまでの機能が利用できなくなることもあるので、全員でリリース作業を見守ります。

リリース作業が無事終わると、その流れで定例ミーティングへ。まずは全体会で、経営陣、セールスチームや開発チームから共有事項の話があります。全体会の後には、開発チームのミーティングが行われます。

シンプルな会議体ではありますが、ビジネスサイドの情報をキャッチアップできる機会が定期的にあるので、事業・会社の状態を現場の私たちでもタイムリーに把握できている感覚はありますね。

愛知県でもリモートワーク、月1出社デーには東京へ

入社以来リモートワークを続けていますが、大きな問題にあたったことはありません。業務の効率を考えるとあまり頻繁には出社する必要はないので、今のスタイルは自分にあっていますね。

ただ、TANOMUには、月に一度の出社推奨デーがあります。私は愛知県で暮らしているので、普段は自宅で仕事をしていますが、出社推奨デーには新幹線で東京へ行きます。

やはり人と人が仕事をするので、たまに顔を合わせたり、雑談も含めたコミュニケーションがあったほうが物事が進めやすいのも事実です。単に効率だけを求めるのではなく、情緒的な側面を踏まえた出社推奨デーは自分の考え方にも合っていて、とても働きやすい環境だと感じています。

お客様の要望を受けて、2段階で行われる開発

開発はビジネスサイドからの要望に基づいて行われることが多いです。お客様と直接コミュニケーションを取っているセールスチームのメンバーが、どんどん開発要望を挙げてきます。その要望をもとにチケットを作っていくんです。

チケットには2つの段階があります。第一段階は、開発の青写真を描くもの。

お客様の要望をシステムに起こして大まかなイメージをつくります。そして、第一段階のチケットを見ながら、セールスチームとやり取りをします。新しい機能を出すことでお客様に満足していただけるのか。それを確認し、実際に機能改善を行うことを決めたら、第二段階へと移ります。

第二段階は、開発で実装する際の細かい内容を組み込んだものです。開発者が実際に手を動かすことを想定して、既存の機能との組み合わせでの注意点を精査した上で、どのようなデータ構造にするのかを書いていきます。

私の主な役割は、手を動かして実装をしていくこと。ただ最近は徐々に第一段階の青写真を描くタスクが増えつつあります。「これがこうなれば、こうなってこうなるはずだ」と頭の中で組み立てていくのも楽しいなと。自分にとっては新しいチャレンジなので、面白みを感じています。

より良いプロダクトをつくるため、レビューは妥協しない

実際に手元で動かすことが大切

自分が実装するだけでなく、他のエンジニアが実装したものをレビューするのも重要な仕事です。TANOMUの開発チームでは、メンバー全員がレビューに参加しています。レビューでは、コードを確認してそれに対してコメントを書いていきます。

レビューをするときに気をつけているのは、実際に手元で動かしてみること。Webブラウザでソースコードを確認するだけでなく、必ず自分のパソコンで動かすように心がけています。「あれ、この動きでいいんだっけ？」と感じることも結構あるので。もし少しでも違和感を覚えたらチケットを見に行って、挙動とチケット内容を照らし合わせます。
チケットを見て、動かしてみて、という作業を行ったり来たり。バグをなくすため、レビューにはしっかりと時間をかけるようにしています。

レビューのやり取りでヒートアップすることも

エンジニアあるあるかもしれませんが、レビューの際にチーム内で意見がぶつかることもあります。実装担当は意図を持ってコードを書いたけど、レビュアーからすると「このコードってそういう意図じゃなくない？」みたいな。

お互い真剣に向き合っているからこそ、ときにやり取りがヒートアップすることも。そこで助かるのが、上述した「出社デー」などを通じたチームの信頼関係です。
前提として良い空気の中で仕事ができているので、たとえば相手を嫌いになったり、貶めるような言葉を使う人はいません。逆に相手に遠慮しすぎて発言できない、ということもあまりないと思います。

「指摘」や「議論」って、面倒だし大変なコミュニケーションだと思うんです。それでも、より良いプロダクトをつくるためには「伝える」ことが一番たいせつ。その共通認識があるので、バッと言い合ったあとにはチームメンバーと「話せてよかったね」と振り返っています。もちろん指摘する際には、なるべく柔らかい言葉、リスペクトをもった言葉を使ったり、絵文字を入れてみたりと相手への配慮は忘れないようにしています。