この記事はLITALICO Engineers Advent Calendar 2024 カレンダー3の16日目の記事です。15日目の記事は以下となります。
カレンダー1：生成AIと構築する、二律背反を体現するCxOのメンタルモデル by @kamesennin
カレンダー2：エンジニア・デザイナー・QA・PDMの交流会を開いてみた by @nobook
カレンダー3：ユニバーサルマナー検定を受けて学んだ視点 by @itoken1013
また、本日公開の記事は以下です。
カレンダー1：SaaSプロダクトでのユーザーストーリーを活用したQAプロセスのトリセツ by @kazuis
カレンダー2：GASで良い感じの開発体験をしたい by @kgshohei
カレンダー4：はじめましてLITALICO by @shuheie
はじめに
LITALICOでエンジニアとして働いている新卒1年目の@EXcEption2zeroです。（本アカウントは社会人用として転生しています。皆様はじめまして。）
アドベントカレンダーを書くにあたり、今年自分が得たものの中で最も大きいものと考えるとプロのエンジニアとして働くことによる変化が思い当たり、この記事を書くことにしました。
未経験からエンジニアに挑戦される方、また、エンジニアになって日が浅い方へ、足りない点があると思いますが本記事をお役立てください。
背景
趣味グラマーからプログラマーで変化したことといっても前提が異なれば趣味からプロへの差分も変わるので、背景として趣味グラマーであった入社前の私の状態とプログラマーとして働く上での開発環境について書きます。
入社前の私
入社前の私はバイトやインターンといった業務経験はなく、いわゆる未経験でした。
しかし、大学在学中にいろいろ趣味で開発（ex. Windowsアプリケーション、ツール、ゲーム、ハードウェアなど）しており、プログラムで開発するという経験は十分ありました。
また、チームでの開発やOSSでの公開（これは自分が作ったものをソースコードから公開しているだけですが）をしており、多人数での開発も慣れていました。
開発環境
開発チームは数人～十人程度の規模で、使用技術は一般的なWeb系のシステム開発で用いるものと思ってもらえば問題ないです。
コードの管理は Git / GitHub を使用しています。基本的にはリモート勤務でミーティングなどはほぼオンラインで行っています。
より詳細に知りたい方は弊社の会社説明スライドをご覧ください。
趣味と仕事の違い
では、本題の仕事をする上で感じた趣味との違いについて、大きく分けて収入・開発体制・影響範囲の3つをあげます。
収入
仕事として働いているのでもちろん給料をもらえます。その給料は勝手に湧いてくるわけではないので、それに見合うだけの価値を出していかないといけません。
趣味の場合は収益化につなげることは難しく、また、収益性についてはあまり考えないことが多いのではないでしょうか。
開発体制
開発体制として、趣味では自分一人、チーム開発でもメンバーは固定されることが多いかと思います。しかし、業務では（自社開発は流動性が低めであるにせよ）開発するメンバーが変わることは普通にあります。
他の違いとして、ちゃんとしたコードレビューが必須というのがあります。
しっかりした開発環境であればコードレビューがあると思いますが、趣味ではレビューをしてもあまりちゃんと見なかったり、自身のPull Request（以後PRと表記します）をレビューなしでマージするゴリラマージをすることがあると思います。
レビュー自体は次に述べる影響範囲にも関係がありますが、プロダクトのクオリティを保つのに必須です。
影響範囲
単純に趣味と比べて業務では関わる人・金の規模が大きいです。また、プロダクト自体も大きいです。
そのため、不具合があった場合の問題が大きく、趣味で時々やる「ひとまず動いたしこれでええやろ」は許されません。十分に問題がないことを確認する必要があります。（趣味でも影響範囲が大きい場合もありそうですがそれは例外。）
心がけたこと
趣味と仕事の差を受け、仕事をする上で心がけたことについて述べます。
収入
タスクの見積
タスクを行う際は、事前に所要時間の見積を出し、完了後に評価するということをしています。
というのもプロダクトにおいてやりたい施策（タスク）は尽きず、すべてをやることはできないため優先順位をつける必要があります。
その判断をする際に重要なのがタスクの重要度と所要時間で、タスクの所要時間を見積もるのは難しく、精度高く出せるエンジニアは価値が高いと言えます。
作業の価値を最大化
タスクに取り掛かる際はまず、たとえそのタスクはどうすれば実現できるという具体的なことが書かれていたとしても、背景にあるタスクの目的から整理をします。
そうすると、何を実現すべきかというのが明確になり、場合によっては隠れた問題を発見できたり、そもそも取り組まないほうが良いことに気づいたりします。
そのようにタスクの目的を整理することで、する作業の価値を最大限に高めます。
よく見る以下の画像の例ですが、左上の要件をただ聞くのではなく、右下の本当に必要だったものまで探るということです。
タスクにかける時間の短縮
タスクにかける時間とありますが、これは単純に自身がかける時間を減らすだけでなく、コードレビューなどの他人にかける時間も合わせ、総合的に短縮します。
手を動かす前に調査
作業の価値を最大化するのところで述べたことと同じでは？と感じるかもしれませんが、こちらはやることが決まった後、実際に手を動かす前にどう実現するかということを調べるというものです。
遭遇する問題というのはだいたい他の人も経験するものなので、頭の中で実装をイメージできていてもよりよい実装が見つかることも多く、調べた方が良いです。
また、実装を具体化する中で論点が生まれることも十分多く、コードを書いた後修正するより調査の段階で修正した方が手戻りコストを少なくでき、トータルでは時間を短縮できます。
PRをレビューしやすいように
PRのレビューというのは他人の時間を使うということであり、特に複数人レビューが必要な場合には、より多くの時間を削減できます。
また、レビューには知見の共有という側面もあり、レビューしやすいPRというのは効果的に価値を高めやすいものと考えています。
では、具体的にどのようなPRがレビューしやすいかというと、変更が適切な粒度で、コンテキストが十分に記載されたPRが良いです。
適切な粒度の変更というのは、逆にレビューしにくい変更が多すぎる場合や少なすぎる場合をイメージするとわかりやすいです。
変更が多すぎる場合は、単純に見るべき点が多くなり脳内のメモリに乗らなくなり効率が落ちる、論点が複数出て解決に時間がかかる、同じPRがなかなかマージされず居座り精神衛生上よくないというのがあります。
特に1つのPRでマージまでに時間をかけてしまうのが問題で、PRを分割すればそれぞれの部分ごとではあるが順次リリースでき、改善できるのにその改善が遅くなってしまいます。なので、PRを適切に分割しましょう。
目安としては論点になりそうなところが1つ以下となるまとまりぐらいが良いと思います。
変更が少なすぎる場合は、前後のPRのコンテキストを把握するオーバーヘッドが発生し効率を落としてしまうので適切にPRを統合します。
コンテキストの記載というのは、レビューではコードの変更のみを見るだけではなく、目的に対してそのアプローチが適切か、前後のPRを合わせた全体の変更においてそのPRの変更は適切かというのも見ます。
そのため、その判断にコンテキストが必要であり、そのコンテキストをレビューワーが集めるのではなくPR自体に記載もしくは辿れるリンクを貼ることで時間を短縮できます。
また、PRを作成するにあたり考えたことを作成時に適切にコメントをはさむことで聞かれる前に一手先を打つのも有効です。
なお、コンテキストを記載する別の側面として未来へのドキュメントとしての役割もあります。
（単純にレビューしにくいPRは辛いというのもありますが……）
開発体制
読みやすいコード
開発メンバーに流動性があるということは、新規に入るメンバーが多いということで、入りやすいように読みやすいコードにする必要があります。
また、機能の改修などで既存の実装を確認するためコードを読むことがあり、プログラムを書く頻度より読む方が多いです。同じ開発者でも書いたコードの時間が経てば別人が書いたようなものといわれますよね。
そのため、読みやすいコードというのは重要です。
読みやすいコードというのは宗教戦争が起きるので断言はしませんが、私が良いコードと感じるポイントとしては「コードがドキュメントとして読める」「その部分を（その詳細度で）把握するのに別のところへ辿る必要がない」でしょうか。
考えたことを辿れるように
こちらも開発メンバーに流動性があることによるもので、機能改修などで既存実装を変更する際にその変更をしてよいのかという判断をするために必要です。
その実装をした人に聞けばよいと思うかもしれませんが、昔のコードであれば当人でも覚えていない場合もあり、また、実装をした人が既にいないという場合もあります。
なので、どこまで考慮してその判断にしたかやどのような都合があってその実装にしたかということを辿ることができるようにする必要があります。
形式としてはドキュメントという形をとらなくても、コードコメントで補足する、Issueに書くで良いと思います。
十分なクオリティーのPR作成
収入の節にあるPRをレビューしやすいようにとほぼ被っていますが、こちらはクオリティという面に絞ります。
仕事としてのプログラムは、利用される年月の長さによる技術的負債の回避や影響範囲の大きさにより、一定の質を求められます。
そのため、趣味で許されていたこれぐらいでいいやという妥協は大体通らず二度手間になるので、安易な方向に流れず妥協せず十分練り上げてPRを作成します。
何も考えず安易な方向に流れると後々技術的負債となり後悔することになるので自分のためにもなります。
ただし、ここで悩んで時間をかけすぎてもよくないので悩んだら早い段階で周りに助けを求めましょう。
影響範囲
不具合がないことの保証
趣味では、ひとまずやりたいことができたら良く、不具合があれば後で直すでということもとれますが、仕事で扱うプログラムはユーザーが多く、また、使ってもらわないといけないため不具合に対しより慎重になる必要があります。
不具合が多いと、ブランドの毀損にもなります。レビューによるチェックもありますが、あくまでレビューでしかないので不具合がないかは自分で保証すべきです。
不具合を減らすには、不具合がおこりうる状況を想定し確認する、テストを十分に書くということをします。（具体的な方法は調べれば出てくると思います。）
また、リリース後にも不具合がおこりうる状況も含め動作確認やログのチェックを行い、問題ないことを確認します。これによりもし不具合を入れてしまっても被害を最小限に抑えることができます。
影響範囲の確認
仕事（というよりビジネス）では、やらかしをしてしまった際にどれだけのユーザーに影響を与えてしまったというのを明らかにする必要があります。場合によってはユーザーへの謝罪が発生します。
やらかしたときというのは、精神的に非常事態に陥り、そのときになって影響範囲を特定するのは難しいものがあります。そのため、事前に影響範囲を確認することでスムーズに事を運べるようにします。
やらかしたときの事前準備以外にも、影響範囲を確認することで何か異常があった際に原因を特定しやすくなるという側面もあります。
まとめ
この記事ではプロのエンジニアとして働き、趣味の開発からステップアップしたことについて述べました。
趣味と比べ、仕事では主に収入の発生・開発体制・影響範囲の大きさに違いがあることを感じ、それぞれに対して意識することがあるということを述べました。
未経験からエンジニアに挑戦される方、また、エンジニアになって日が浅い方、あくまで私という一例ではありますが、ぜひ参考にしてください。
余談ですが、21日には私のメンターをしていただいた@ti_aiutoさんによるメンター側の視点の記事が公開されます。お楽しみに！
おわりに
久しぶりに記事を書いたな。思ったより文量が多くなった。