フルスタックに働くアトラスのエンジニアは何をしているのか？入社後の業務と働き方のリアル
目次
こんにちは、Confitを開発している新卒2年目エンジニアの内田です。
入社して1年半経ち、様々な領域を任せてもらう機会も増えてまいりました！
今回は、今までどのような事を任せてもらってきたのか、実際の働いている様子を交えながら、「アトラスにおける『フルスタックエンジニア』とは」というテーマでお伝えします。
そもそも「フルスタックエンジニア」とは？
一般的にフルスタックエンジニアとは、アプリケーションの「見た目」を作るフロントエンドから、裏側の処理を行うバックエンド、さらにはデータベースやインフラまで、アプリケーション開発に関わる一連の領域を横断して担当できるエンジニアを指します。
ただ、普段特定の領域に特化して開発されている方や、これからエンジニアを目指す学生の皆さんからすると、「一人で全部やるって、実際どこからどこまで？」「頭の切り替えはどうしているの？」など、その具体的な動き方は少し想像がつきにくい部分があるかもしれません。私も入社するまでは、「全ての領域について扱う」程度の理解しかありませんでした。
アトラスにおける「フルスタック」
実はアトラスにおいては「フルスタックエンジニア」というポジションがあるわけではありません。「エンジニア」というポジションの中で一人ひとりが様々な形で活躍しています。
基本的には全員がフルスタックを目指す方針のため、アトラスにおいては「エンジニア」＝「フルスタックエンジニア」と言ってもいいかもしれません。
しかし、そう言われても「フルスタック」のイメージがつかないと思いますので、ここでは私が実際に入社してから担当してきた業務を具体的にご紹介したいと思います。アトラスにおける「フルスタック」を知っていただければ幸いです。
入社後に主に担当した業務
学術大会アーカイブサイトの開発（※1）（フロントエンド：Next.js / TypeScript）
- 新規4画面の作成（トップ・検索・詳細画面）
- デザイナーが作成したものを用い、画面作成・バックエンド疎通まで担当
モバイルアプリの改修（※2）（モバイルアプリ：Flutter）
- リファクタリング
- データダウンロード処理に関わる依存関係を見直し
- データ更新処理の見直し（ひとつの値が更新された際に関連するデータも関連して更新が入るように依存の見直し）
- お知らせ通知機能のサービス移管（バックエンド・インフラ：Kotlin / AWS Lambda / Amazon SNS）
- 既存のプッシュ通知サービス終了によるサービス移管
- AWSの権限周りの調査なども扱う
リリース作業
- Confit の定期リリースやhotfixリリース（修正版リリース）の担当
エラー通知監視
- 主にモバイルアプリのエラーを監視
※1…学術の世界では過去の発表が蓄積され、振り返って見られることが非常に重要になります。入社後初めて関わったプロジェクトとして、過去の学術大会の内容を横断的に見れるアーカイブ機能の開発を行いました。
※2…学術大会の参加者向けに開発されたモバイルアプリのデータダウンロードの際の処理を見直し、既存のお知らせ通知機能の改修も行いました。
「鬼のマルチタスク？」実際のワークスタイル
これだけ並べると、「毎日これら全てを同時並行で進めているの？」「ものすごいマルチタスクで忙殺されそう」と思われるかもしれません。
ですが、実際は「開発業務」をメインに据えつつ、「運用業務」がスポットで入ってくるというイメージです。 基本的には、上記に挙げたような機能開発やリファクタリングといったメインタスクに腰を据えて取り組んでいます。
アトラスでは、少数精鋭で開発・運用しているので、リリースの担当作業であることもPMが把握しています。複数の上司からタスクが振られ、右も左も首が回らないということもありません。
運用業務における「メリハリ」
こうした体制があるため、一見大変そうに見える運用業務についても、メリハリを持って取り組むことができています。
具体的には、エラー通知監視については、常に監視画面に張り付いているわけではありません。Slackの他のメッセージを確認する際に重大なエラーが発生していないかをチェックし、問題がありそうなものを拾い上げるというスタイルで、日常のルーティーンとして行っています。
また、リリース作業についても同様です。担当になった際は、進行中の開発業務を一度ストップして進めます。「コードを書きながらリリースの手順も確認して…」というような「ながら作業」ではなく、リリースに集中して安全に作業を行います。
そのため、担当する領域こそ広いですが、その時々でやるべきことは明確です。「広い領域に触れるけれど、目の前のタスクには集中できる」そんな環境だと感じています。
フルスタックへの足掛かりに
また、担当する領域は最初から全てを任されるわけではなく、段階的に広がっていきます。今回業務をまとめるにあたって自分でも驚いたほど、少しずつ積み上げてきた結果としていつのまにか業務の幅が広がっていたという印象です。
特に今は、AIの進化によって新しい技術の学習コストが下がってきている時代です。未知の領域であっても、以前より格段に挑戦しやすくなっています。 新卒2年目で様々な領域にチャレンジできている大きな理由だと思います。
視点が広がり、最適解を選べる楽しさ
私の場合は初めはフロントエンドの実装からでしたが、バックエンドまで領域を広げたことで、開発の視点が幅広くなりました。
例えば、フロントエンドの実装をしていてデータの受け渡しが複雑になりそうな時でも、単にフロント側のコードだけで解決しようとするのではなく、「APIのレスポンス自体を調整し、スムーズにデータを渡そう」という発想ができ、選択肢が広がります。
フロントエンドやバックエンドといった区切りを意識しすぎず、システム全体のつながりを理解し、自分の手で全体を最適化できる瞬間は、自分のやりがいを感じる瞬間でもあります。
私自身、「新しいことを知りたい」「もっと広い視野でサービス全体を見渡したい」という想いがあり、AIも味方につけながら柔軟に領域を広げていけるこの環境は、エンジニアとして非常に面白いと感じています。
こうした日々の業務を通じ、「フルスタックエンジニア」についての解像度が上がり、フルスタックエンジニアに一歩ずつ近づいてきた気がしています。最後に私の思う「アトラスにおけるフルスタックエンジニアとは」をまとめます。
まとめ
アトラスにおけるフルスタックエンジニアとは、単にタスクをこなす「便利屋」ではありません。フロントからインフラまで、サービスを形にするための全ての要素にオーナーシップを持てるポジションであり、サービスをよりよくするための手段としての「フルスタック」だと思います。
もちろん、最初から全てを完璧にこなす必要はありません。 私自身もそうだったように、頼れるチームメンバーや整った環境の中で、目の前の開発を一つひとつ楽しんでいけば、自然と技術の「点」が「線」に繋がり、エンジニアとしての視界が開けていくと思います。
ここまで偉そうに語ってしまいましたが、私自身もエンジニアとしてはまだまだ半人前です。 「フルスタック」と胸を張って名乗るには、学ぶべきことや経験すべきことが山のようにあります。
ですが、その「伸びしろ」の多さこそが、今の私のモチベーションでもあります。 これからもこの環境で、新たな知識・技術を学びながら焦らず一歩ずつエンジニアとして成長していきたいと思います。
