オールアバウトの新卒1年目エンジニアが投稿する連載企画「テックブログ新卒週間 2018」の第2弾です！

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

今回投稿するのは、2年目になることにガクガク震えている@y_hideshi です。普段の業務ではAll AboutやAll Aboutまとめなどの運用・サーバのクラウド移行を行なっています。

今回は、1年間の業務を通して得た経験から私が日々心がけていることを2つの分野に分けて紹介したいと思います！

プログラム関連
業務関連

プログラム関連

その時に取れるもっとも良い方法でコードを書く

過去にソースコードのレビューをお願いした際、実装した処理をより綺麗にする方法を教えてもらいました。しかし、その時はスケジュールの都合上「何処かのタイミングで対応させてもらいます！」とだけ返答し、コードを綺麗にすることもなくリリースを行いました。

その後「何処かのタイミング」を伺いつつ仕事を進めてきましたが、結局新しいタスクへの対応などに追われた私はコードを綺麗にすることができず、時が過ぎていきました。

このようなことを繰り返していると汚いコードが大量生産されていきます。大量生産された汚いコードは処理が追いづらくなるなどして自分や他の人の首を締めることになるでしょう。

そのため、できるだけコードが綺麗になるよう他の人にアドバイスをもらいに行き、もっと綺麗に書く方法がないかを時間が許す限り調べてからコードを書くことで、少しでも自分や他の人の負担が少しでも軽くなるようにしています。

すでに生まれてしまった汚いコードはリファクタリングをするしかありませんが、まだ生まれていないコードはできるだけ綺麗な形で生み出すことを常に心がけています。

コメントを手厚く書く

入社してから、私はとにかくコメントを手厚く書くように心がけています。

その理由は、コメントが全くないコードは非常に追いづらいからです。「どうしてこんな実装にしているんだ...」「最終的にどこで使用するためのデータを作成しているんだ...」など、実装者の意図がわかりにくいコードを改修する機会が何度かあり、意図を理解するだけで時間がかかってしまいました。

それに加え、自分の書いたコードは自分よりも他の人の方が読む機会が多いと感じています。他の人がコードが読む時は、割と緊急度が高い時が多い気がします。そんな時、コメントがないことで流れを追うのに時間がかかるコードを読むエンジニアのことを考えると「多少コメントが多くなっても、後から見るエンジニアの負担が少しでも減るように実装しよう」と思うようになりました。

そのため、コメントを書く際は仕様を全く知らない第三者にも実装の意図が伝わることを心がけています。

例

複雑な仕様の時の経緯
- 例：〇〇のため、□□の時は特定のページを表示する
処理が複雑な時(for文がすごく長くなった・複雑な条件式の時)
- 例：××を行うため、〇〇の値を持つレコードのみ抽出する

コードレビューをする時は自分のことは棚に上げる

半年前の自分は、レビューの時こんなことを考えていました。

技術力が全くない新卒の自分がこんなことを言ってしまっていいのだろうか...
自分も過去に同じような実装をしたから指摘しづらい...
ここ気になるけど、こんな小さなことを指摘するのは...

などとうじうじしていましたが、正直、そんなことを言って指摘できることを指摘しないままでいると業務放棄している感覚のほうが強くなってきました。

また、どんなに小さな修正でも、自分が思ったことはきっと他の人も思っているはずですし、中には自分しか気づいていないこともあるはずです。

その結果、レビュー時は自分のことは全て棚に上げて自分が気になったことは躊躇せずコメントするようになりました。もし間違ったことを言ったとしてもきっと他のレビュアーが指摘してくれるので、新卒だから...と恐れず気になったことは言うようにしています。

業務関連

事前にスケジュールを立て、ゴールを設けておく

ゴールが明確になっているものほど行いやすい作業はありません。私はすぐに頭の中がごちゃごちゃになってしまい次に何をやろうとしていたかを忘れてしまうため、事前にスケジュールを立て、ゴールを明確にするようにしています。

私の場合、スケジュールを立てる際には「Trello」と「Google Calendar」を利用しており、下記の通り使い分けています。 Trelloを利用する理由としては、頭の中にあるタスクを全て書き出すためです。Google Calendarは作業の洗い出しに向いていないので、時間管理に使用しています。

例

Trello：タスク洗い出し
- 2週間後のタスク洗い出し：どの日になんのタスクをやるかざっくり決める
  - 例：◯月□□日見積もり締め切り
- 今週分のタスク洗い出し：どの日になんのタスクをやるか確定させる
  - 例：◯月××日タスクAの進捗報告
  - 例：◯月△△日はタスクAの〇〇に着手
- 翌日のタスク洗い出し：なるべく詳細に記載する
  - 例：午前中にタスクAの△△の機能の〇〇部分実装
  - 例：Dさんに◯月××日に行う〇〇のMTG連絡メールを送る
  - 例：午後から手順書作成： 0% → 80%
  - 例：18時から明日の詳細スケジュール作成
Google Calendar：時間管理
- すでに時間が決まっている予定などを入れる
  - 例：16時〇〇のMTG
  - 例：18時スケジュール作成

上記のようにTrelloで作業を洗い出す際、3つの期間に分け期間が短いものほど作業内容を詳細にしてスケジュールを作成します。ポイントとしては、詳細なスケジュールを立てる際は名詞と動詞を入れるようにしています。「タスクAに着手」「メール」といった名詞だけよりも「タスクAの〇〇に着手し、〇〇をする」「Bさんに□□の件でメールする」といった具合に、詳細にスケジュールを作成した方が、当日作業を行う際に作業内容を思い出す時間が少なくて済みます。

作業内容を思い出す時間が少なくなるということは、別作業を行う際の思考切り替え時間が少なくなるということです。この1年を通して思ったことは、思考の切り替え時間は割と時間を消費すると言うことです。

そのため、私は上記のようにスケジュールを作成することで思考の切り替え時間を減らし、1日に行える作業量を増やせるよう心がけています。

推測で喋らない・行動しない

自分が最も気をつけなければならないのは「~だろう」「~のはず」など推測で物事を決めつけることです。極端な例ですが「開発環境だから本番DBは向いていないはず、といった思い込みでデータを投稿したらまさかの本番DBだった」といった事態になったら目も当てられません。(そもそも開発なんだから本番に繋げんな！というツッコミもあると思いますが...)

また、共用の環境を触る際にも同じことが言えます。例えば、誰も触ってないだろうと思い込みのもと、ある共用の開発環境のアプリに変更を加えてみると実は「他の開発者」が使っていて混乱を招くといったことがありました。また、その時加えた変更がエラーを起こした場合「他の開発者」は自分以外が開発環境を利用していることを知らないため、エラーの原因調査などの必要以上の作業をしていまい無駄なコストをかけることになってしまいます。

そのため、「~だろう」「~のはず」といった推測で動くことはやめるようにしています。確認の手間を惜しんで問題を起こすより、時間がかかっても問題がおきずに物事を進めていくほうが断然よいはずです。

また、推測で喋らない・行動しないようにする方法の1つとして常に最悪の自体を考慮する癖をつける ことがオススメです。最悪の自体が非常に怖いものの場合、確認作業をサボる人はいないはずですよね。

一例として、私は共用の環境に変更を加える際はslackなどで周知するようにしています。