こつつみ

コツコツ積み上げる

AIの力で変わるコードレビュー:PR-Agentで開発効率アップ!

昨年からAIの進化が目覚ましく、私はChatGPTやGitHub Copilot、Grammarly など、多岐にわたるAIツールを活用しています。その中でも特に注目したいのが、プルリクエストのレビューを助けてくれる「PR-Agent」です。このツールはCodium AIによって開発されたオープンソースプロジェクトで、ChatGPTを核としています。

github.com

導入のきっかけ

私は現在ほとんど1人で開発をしているので、コードレビューは常に頭の痛い問題でした。そんなある日、LayerXが公開した記事を読み、その内容に「これが自分が求めていたものだ!」と思い、次の日に私は会社に導入を提案しました。

同様のサービスであるCodeRabbitも検討しましたが、GitHubスターの数でPR-Agentが上回っていたこと、さらにCodeRabbitがサブスクリプションモデルを採用していたため、将来的にコストが増加する可能性を避け、PR-Agentを選択しました。

主な機能

PR-Agentの最大の魅力は、OpenAIのAPIキーさえあれば、CI環境に簡単に統合できる点です。実際に私はGitHub Actionsを介して導入しました。 APIのコストとしては、先月は2ドルちょっとでした(これは私が個人で開発しているからかもしれませんが)。

簡単な例として、OpenAIのモデルアップデートを利用してPRを作成し、PR-Agentがどのように機能するかを見てみましょう。

設定に応じて、自動的に説明を追加したり、レビューやタグ付けを行ってくれます。私の場合、会社の公用語が英語なので英語に設定していますが、日本語での使用も可能です(詳細は先に紹介したLayerXの記事に記載されています)。

まず、概要を書いてくれます。

その後、PRの分析。 ここでは、レビューにかかる見積もりコストを数値化してくれるので、レビュワーに対しても優しいですね。

そして、自動でレビューを行ってくれます。(自動でする設定をしています)

PR-Agentは、以下のようなコマンドをインラインでのレビューや質問にも対応しており、コードレビューのプロセスを大きく効率化してくれます。

参考までに、GitHub Actionsでやりたい場合、OPENAI_KEYGitHubのRepository secretsに設定し、以下を .github/workflows/pr-agent.yml に配置すれば、自分と同じ動きができるはずです。

OpenAIのモデルについては、 gpt-4-1106-preview を使っていますが、こちらから選ぶことができます。

name: PR-Agent

on:
  pull_request:
    types: [opened, reopened, synchronize]
  issue_comment:
    types: [created, edited]

jobs:
  pr_agent_job:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
      issues: write
      contents: write
    name: Run pr agent on every pull request, respond to user comments
    steps:
      - name: PR Agent action step
        id: pragent
        uses: Codium-ai/pr-agent@main
        env:
          OPENAI_KEY: ${{ secrets.OPENAI_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          CONFIG.MODEL: "gpt-4-1106-preview"
          github_action_config.auto_describe: "true"
          github_action_config.auto_review: "true"
          github_action_config.auto_improve: "true"

総評とAIレビューのメリット

PR-Agentを使ってみて、悪い点を見つけるのは難しいです。唯一、Code Rabbitのようにレビューコメントに直接返信しても反応がない点が挙げられますが、それを差し引いても、このツールの提供する価値は計り知れないです。

AIレビューの大きなメリットは、自分では気付かなかった問題点や改善点に気付けることです。特にセキュリティに関しては、「security concerns」という項目が設けられており、これが非常に役立っています。コードの安全性を高めるための指摘や提案を受けることで、より堅牢なソフトウェア開発が可能になります。

プログラミングの世界でのAIの活用はまだ始まったばかりですが、PR-Agentのようなツールが開発の質と速度をどれほど向上させるか、これからの展開が非常に楽しみです。

2023年の振り返り

昨日で仕事納めをしたので、2023年を振り返りたいと思います。

転職

メーカー企業でエンジニアをしていましたが、6月にスタートアップ企業に転職しました。それにより、環境も大きく変わりました。 元々、新卒時代は大企業が良いという考えがあったため、スタートアップに転職することは勇気がいりましたが、結果的に転職して良かったです。

主な変化

前職では、AWS LambdaとDynamoDBをメインに使ったマイクロサービスの開発をメインで行っていました。APIを作るときはAPI GatewayとLambdaを使っていたので、一般的なWebフレームワークやRDBは実務で使ったことがなかったです。転職して、RDBはもちろん、フロントはNext.js、バックエンドはFastAPI、インフラはAWS ECS周りでTerraterm(Terragrunt)を使うようになりました。

1人開発へ、、

入社時には、自分のプロジェクトには開発メンバーがもう1人いたのですが、自分が入社して1ヶ月で辞めてしまい1人で開発しています(上司はいます)。 使う技術は大きく変わったのですが、個人でVue.jsやFlask, MySQLを触っていたり、簡単な自作RDBMSを作ってみたりしたので、なんとかなっています。インフラに関しては、もう1人にも手伝ってもらっています。

スタートアップかつ1人ということもあり、自分の役割は信じられないくらい広くなりました。良いと思う反面、中途半端になっていたり、これで大丈夫なのか?という不安は常にあります。

自分とAI

1人でやっていることもあり、AIは(セキュリティは気を付けつつ)フル活用しています。GitHub CopilotやChatGPTはもちろん、PR-Agent というAIのレビューを導入して開発しています。

前職では使うことができなかったツールを多く使えて、効率よく開発ができるようになったと感じます。

英語への挑戦

転職して公用語が英語になりました。しかし、会社ではプロジェクトが分かれており、自分の関係者は日本人が多いため普段は日本語でMTGをしています。転職時の面接も全部日本語でした。 とは言ってもslackや、GitHubのPRやタスク管理は全部英語です。

自分は毎年英語を「やろう」と思っては、前職では「使わないからいいや」となってしまい継続ができませんでした。転職するにあたってTOEICを受けてみたところ620点でした。 一緒に同僚とランチをするのですが、いつも「聞き取れない→話の内容がわからないから話せない」という状態になってしまっています。性格的にもお喋りではないので、積極的に話にいけず苦労しています。

現状を打破するために英語を本格的に勉強し始めました。

オンライン英会話

DMM英会話をやっています。最初の頃は、デイリーニュースを見て質問に答えていくみたいな感じでやっていたのですが、スクリプトが用意されており予習時に事前に回答を考えて、それを読むだけになってしまい効果を感じなかったです。

なので、フリートークをするようにしたのですが、負荷が高すぎてサボってしまうことも増えてしまっています。週5で継続してやっていきたい。

1372105493 友達紹介コードです。もし良ければ使ってください。

お友達紹介プログラム - オンライン英会話ならDMM英会話

英語日記

英語日記を書いて、先生に添削してもらうってことをしています。こちらは実際の話で使える内容なので、とても効果を実感できます。 しかし、他の技術の勉強をしたりなどで全然復習をせずにいるので、学んだことを忘れて活かしきれていないです。

色んなことに手をつけてしまっているので、来年はこれをメインに学習して話で使えるように、何回も音読することを繰り返していきたいと考えています。

シャドーイング

リスニングが全ての基本になっていると思っているので、効果があると言われるシャドーイングをやっています。

TOEICの精選模試 リスニングを解いて、シャドーイングするを繰り返し行っています。12月に買ったばかりなので、まだ1つ目の模試も終わっていないです。来年には全部シャドーイングできるようにしていきます。

11月時には、シャドテン をやっていたのですが、流石に月に2万払う価値はないなと思って辞めてしまいました。 2万払っているので、絶対にやらないといけないという気持ちがあったから継続できたとは思うけど。

今年できなかったこと

  • 個人プロダクト作成
    • 自作RDBMSはしたが、Webサービスを作ろうと考えていた
    • Twitter API有料化により断念して、そこから何も作らなかった
  • 登壇
    • 小さいところで良いから、アウトプットをしようとしてしなかった

年間目標を立てるのをやめて、月とか週で目標を立ててやっていこうと考えていました。実際に転職とか予想できなかったこともあり、目標設定しても上手くいったか分からないが、結局月・週で目標を立てることもしなかったので、気の緩みがあったようにも思います。

kotsutsumi.hatenablog.com

ただ、Terakoyaというコミュニティに参加して、オフラインで人に会ったりして、ある程度モチベーションを保って活動できました。

peraichi.com

来年の目標

目標立てることが性格的にあっているみたいので、今年は立てます。

  • 英語で同僚と議論できるようになる
    • TOEIC820点は必ず取る (友達が815点らしいので)
  • アウトプットを増やす
    • 登壇は必ず1回はしたい
  • 完全朝型生活にする
    • 夜は家族との時間を大切にする
  • ワクワクしながら仕事をする

少なくとも上は達成できるようにしたいです。

まとめ

今年は大きい変化がある年でした。自分がした選択を正解にできるように行動していきたいと思います。

Node.jsでISUCON13に参加した

ueshoです。久しぶりにブログ書きます。

2023/11/25に開催されたISUCON13に Buzoimajo と一緒にチーム「slasher」として初めて参加しました。個人では昨年はPython移植作業を担当させていただきましたので、どういうコンテストなのかは分かっていました。 言語はみんなが触ったことのあるTypeScriptであるNode.jsでやりました。

これは、競技中にYouTube配信で流れるチーム紹介のスライドです。期限を忘れて編集ロックかかってしまいました🤣

チーム紹介スライド

事前準備

初参加なので、初動の確認を含めてチームで問題を解くのは、10月末から3時間を4回くらい行いました。 最初の2回くらいはISUCONの説明と初動の確認をして、その後、ISUNARABEを使ってISUCON12予選を解きました。

個人では、private_isu を(Go言語で)20万点まで、ISUCON12予選をNode.jsで解きました。

デプロイ方法等は、チーム「織時屋」のリポジトリから拝借してMakefileで行いました。

初参加ということもあり準備段階でツールの使用方法、Nginx, Mysqlの設定、初動何するかとかを考えることで結構時間を使って過去問解きが少なかったです。

本番当日

Buzoとimajo がアプリケーション担当、自分がインフラ担当という役割分担をしました。(本職はアプリケーションなので、何すれば良いか分からずアプリケーションの改善をしてしまいました) Buzoとimajoでindexを貼ったり、N+1を潰したりをしてもらい結果的に6793点でfinishしました。自分は何もできず終わりました。

ISUCON13 受賞チームおよび全チームスコア : ISUCON公式Blog

自分目線で反省の意味も込めてやったことを記載します。

  • 10:05 初期実装(Go)でベンチを回す。スコア3636点
  • 10:10 リポジトリのセットアップ
  • 10:20 Node.jsに切り替え。mysqlのパラメータ修正。かつ、alp, pt-query-digest, notify_slackのセットアップ完了。ログをとるも何と設定したサーバーが違っていた、、
    • てっきりベンチマーカーの初回の向き先は必ずServer1になると思っていたので、困惑しました。
    • また、ポータルのどこからベンチマーカーの向き先を変えるか分からずServer3をメインで使いました
  • 11:00 ここでやっとセットアップ完了。Node.jsでスコア2642点
  • ~13:00 alpの結果からiconが遅く、かつ、画像がDBに入っていたので、private_isuと同じだ!と思い、nginxから配信するように変更しようとした。アプリケーションマニュアルにあるicon_hashや304をどうすれば良いか分からず、結局断念。
  • ~14:00 DNSmysqlをServer2に移行させようとするが、ベンチがFailで失敗。深追いせずやめ
    • おそらく後述のDBにユーザーを作っていなかったのが原因。
  • ~15:00 moderateのN+1に着手。少し改善したが、SQLの根本的な改善はできず、、、
  • 16:00 そろそろ複数台にってことで、アプリケーションのDBをServer1に移行しようとするも接続できず、、、
    • ISUCON12のようにIPとbind_address = 0.0.0.0設定すればいけたので、それしかやらず
    • 実際には、isucon@localhostなユーザーしかいなかったので、対象のインスタンスにアクセス可能なユーザー作る必要がある

振り返り

過去問だけなぞってやるだけで、ミドルウェアの仕様をちゃんと読んでおくということはしなかったので、こういう結果になってしまったと考えています。詰まった時に、思い至れるようにしておくというの大事です。 Nginxの設定や、コネクションの設定など、やりたかったのにできなかったことも多々あるます。また、DNSは知識がなさすぎて、手をつけられずという状態だったので、しっかり復習をして自分の知識にしたいと思います。

最後に

運営の皆さんありがとうございます。楽しいコンテストだったので、来年も参加します! 誘って参加してくれた Buzo と imajo ありがとう。

「スタートアップでDDDを最大限使いこなすには? ~事業と組織を連携するプロセスづくり~」に参加しました

こちらのイベントに参加して学びがあったので忘れないうちに記録に残します。

loglass-tech.connpass.com

コミューン株式会社さんと株式会社ログラスさんの2社でDDDの活用方法についてパネルディスカッションをする会でした。コミューン株式会社オフィスで開催するオフラインイベントで、自分にとってはコロナ明けて初めてのオフラインイベントでした。

参加の目的

自分は来週新しい会社で働きはじめます。現職はメーカー企業でソフトウェアエンジニアをしており、担当プロジェクトにDDDを導入してきました。

新しい会社はスタートアップ企業で自分が所属するプロジェクトはまだリリースされていない段階です。おそらくDDDは導入していないと思われますが、DDDを導入するかの判断基準や、スタートアップにおけるDDDのメリットを知れればと思い参加しました。

パネルディスカッション

今現在の開発テーマや組織の状況、DDDの取り組み状況について

  • コミューン
    • 去年、軽量DDDをやろうという流れがあり、これからDDDを本格的に取り入れる段階
  • ログラス
    • 開発チーム5個くらいで、どのチームもDDDでモデリングから行なっている
    • エンジニアは既にあるコードを参考に実装する、いわゆる横展開は得意。モデリングは1から作るので最初大変だけど、どのチームもモデリングを行う文化ができている

コミューンさんも話していましたが、軽量DDDにも良さがある一方、やはり複雑な事業でモデリングをしてこそDDDが真価が発揮されるのだなと改めて感じました。

※ 軽量DDD: DDDのValueOvject、Entity、Repositoryなど技術的な部分のみを取れ入れDDDを行うこと

DDDをはじめようと思ったきっかけ

  • コミューン
    • コミュニケーションの齟齬が大きくなってきた
    • チームが機能ごとではなく割と適当に2チームに分かれている。それをしっかりコンテキストを認識して是正したい
  • ログラス
    • ドメインエキスパートであるCEOと共通言語が必要
    • コードはレビューできないが、モデルはレビューできる
    • データモデルだけは変わらないけど、ピボットが何回も起こることを考えてDDDを導入

増田さんから以下の話もありました。※ 勝手に引用すみません

ログラス社の「コードはレビューできないが、モデルはレビューできる」という言葉を聞いて妙に納得できました。

ただ入社してすぐに無理やりDDD導入すると失敗するでしょう。転職先はまだプロダクトもリリースされていないのでDDD導入がまだしやすい時期だと思いますが(?)、増田さんが話されていたようにチーム全体で話し合って必要があれば進めていきたいです。

DDDを導入してから組織に広げていく過程の課題

  • コミューン
    • エンジニアだけで閉じているとうまくいかない
    • PdMにDDDの理解をしてもらう必要がある
  • ログラス
    • 最初はServiceクラスを撲滅して、usecaseに書き換えることから始めた。(実装から入って、モデリングは後でやった)
    • 設計の検討事項やプログラミング言語のこれが良いなどのベストプラクティス集のような設計標準を用意している

ログラスさんのユースケースドメインリファクタリングから始めて、周りにコードの見通しの良さを広めることはどこの会社でもできそうですし有効な手段だなと感じました。その後。新機能の開発からモデリングや集約の設計を行うことは、合理的で実践しやすそうなのでやっていきたいです。

所感

目的であった転職先でのDDD活用は、実際に事業がどれだけ複雑か、共通言語ができていないなど課題があれば前向きに導入を検討したいと感じました。(無理に導入する必要もない)

途中で増田さんが話されていた、モデリングで仮説を出したら、実際に実装をしフィードバックを受ける。そしたら再度モデリングといった 「モデリング→実装→フィードバック→モデリング」を高速で繰り返していくことが何よりも大事だと感じました。

上を実践する上で、松岡さんが話されていた(アート・オブ・アジャイル デベロップメントに記載のある)「リファクタリングは絶え間なくする」は心に刻んでおきたいと思います。

最後に

懇親会ではピザ食べれました🍕ごちそうさまでした。

抜け漏れ、間違いあるかもしれませんが、ご容赦ください。 当日参加されていた方で、明らかな間違いに気づいた点があればコメントください。

自作RDBMSをやってみた

タイトルの通りRDBMSをGo言語で自作してみました。

GitHub - ue-sho/ohako: 自作DBMS

はじめた動機

自分は業務ではNoSQL(DynamoDB)しか使ったことがなく、RDBMSは遊びで触ったことしかなかったです。 それもORMを使っていたため、特に仕組みを詳しく知ることなく扱っていました。 エンジニアとしてそれはまずいと思い、自作RDBMSを作って中身を知っていこうと考えました。

使ってみたい言語だったので実装はGo言語でやっています。

やったこと

最初は簡単な概要を知るために、データベースシステム自作入門を読んで簡単に実装してみました。 著者はセキュリティキャンプのデータベースゼミの講師もしている星野さんで、実際にセキュリティキャンプで使っていた本(?)です。

github.com

この本のおかげである程度DBMSの仕組みを理解することができました。

具体的な実装は、当初はカーネギーメロン大学の以下の資料と動画を見ながら進めました。

15445.courses.cs.cmu.edu

こちらの講義では BusTub という C++ で書かれたDBMSを、受講生が穴埋めで実装していく形式です。 かなり深い内容まであり、正直理解できない部分もかなりありました。

ディスクマネージャーとバッファプールマネージャーを実装して、メイン機能であるBTree+を実装しようと思ったのですが、難しく実装がしんどかったです。 なので、より簡単にできないかと調べていたところWEB+DB PRESS Vol.122に日本語で解説があるということで買ってみました。

gihyo.jp

上記の自作DBMS(Relly)はRustで実装されているのですが、何やっているのかコードを読み解きやすかったです。そのため、方針を変えてアクセスメソッド(BPlusTree)、クエリエクスキューター、セカンダリインデックスの実装はRellyを参考に実装しました。

現在の実装では、Rellyと同じく以下の機能は実装できていないです。

最後に

目的であったRDBMSの大まかな仕組みは理解することができたので良かったです。ただ調べれば調べるほどトランザクション周りは沼と感じます、、、笑

CMUの講義や以下の資料とかもあるので、SQLで操作したり、トランザクションの実装もおこなっていきたいなと思います。

github.com

プログラマー脳を読んだ

自分の観測範囲で絶賛されているプログラマーを読んでみました。

https://www.amazon.co.jp/dp/4798068535

書評

文章が堅苦しくなく読みやすかったです。この書評では自分が心に残ったことを書いていきます。

以下の3パートに分かれて書かれていて、過去に説明した内容をもとに基づいて説明していく箇所もあるので頭から読んでいくのがよいと思います。

  • Part1 コードをよりよく読むために
  • Part2 コードについて考える
  • Part3 よりよいコードを書くために

プログラミングを行うとき、脳内では「短期記憶」「長期記憶」「ワーキングメモリ」の3つのプロセスが動いています。 それぞれでどのような働きをしてコードを読み解いていくのかが説明されており、非常に参考になりました。

Part1では、上をもとにどのようにしてコードを読み解いていくのが効果的かを示しています。 認知的負荷はワーキングメモリが処理をできる量に限界があるために発生します。認知的負荷が大きいと、コードを適切に処理することができなくなります。

プログラマーは仕事の6割は時間コードを読むことに充てていると言われています。そのため、認知的負荷を減らすためにも以下のことを意識したいと感じました。

  • リファクタリングし続ける
  • Why(なぜこうしたのか)のコメント
  • 依存関係グラフや状態遷移表などのドキュメント

Part2では、変数が「ステッパー」「最も重要な値の保持者」などのようにどのような役割を持っているか把握から始まり、メンタルモデル(目の前の問題について推論するために、ワーキングメモリの中で概念を抽象化するもの)を通した考え方など示唆に富んだものが多かった。

最後のPart3では、コードを書く上での方法について説明しています。 プログラミング中に行う作業を「検索」「理解」「転写」「増強」「探索」という5つに分類して、具体的にどういうことを行っているのか、その作業を難しくしている原因のか、それぞれの作業の最適化は異なる特性に基づいて行うことができるなど、難しい部分もあったが面白く振り返るよい機会になりました。

最後に

サブタイトルの通り「優れたプログラマーになるための認知科学に基づくアプローチ」について述べた本でした。

各箇所に演習があり自分の認識を気づかせてくれるのでとても良かったです。 出来るだけ飛ばさず演習をやり、自分の頭で考えることをお勧めします。

メーカー企業のエンジニアが「転職ドラフト」を使ってみた

転職ドラフト経由ではなかったですが転職先は決まって落ち着いてきたので、転職ドラフトを使った感想を記事にします。

転職ドラフトとは

転職ドラフトは、レジュメを登録すると企業から年収付きで指名が届く、エンジニア向けの転職サービス

一般的なエンジニア向け転職サービスにはない大きな特徴がこちら!!

現年収を企業に伝えなくていいので、実力で評価される 内定前に年収がわかって、効率的 企業からの指名で、リアルな市場価値が確認できる

引用:転職ドラフト公式サイトより これで完璧!転職ドラフトの使い方マニュアル!

転職ドラフト参加時の自分

私が転職ドラフト参加したのは2022年12月と2023年2月です。その時のスキル等のスペックは以下でした。

なぜ転職ドラフトをやろうと思ったのか

主に3つの理由がありました。

  • 自分の市場価値を確認したい
  • より顧客に近いWebサービスの開発をしたいと思った
  • サーバーレスではないWebサービスの開発をしたかった

現職では、今後運用保守がメインで小さい機能追加がちらほらあるくらいだと感じたため、3つ目の理由も含めスキル面で不安が大きくあり転職を考えていました。 組み込みからクラウド、業務外では競プロやVue.jsなどのフロントなど色んなことに手を出していて自分の価値がわかっていなかったので転職ドラフトに登録してみました。

転職ドラフト参加してみた結果

2022年12月回では、以下の合計7件の指名をいただきました。 指名額はMAX620万円が1件でした。

  • 550万円~: 3件
  • 600~620万円: 4件

2023年2月回では、600, 620万円の2件いただけました。

実際にこの中から5社カジュアル面談を行い、2社は選考に進ませていただきました。 両方とも最終面接までいきましたが、結果的に落ちてしまいました。面接は通常通り行われて、自分の場合は再度履歴書や職務経歴書を別途出しました。

転職ドラフトの良い点

  • 自分は普通に応募したら書類選考落ちも結構ありましたが、転職ドラフトはすでに自分のことを良いと思っている企業からオファーいただけるのは、かなり心理的にも良かったです。
  • レジュメは別の転職エージェントでOKをいただいたものをそのまま記載しましたが、ダメでした。しっかりレビューしていただいて、どのように改善すれば良いかを詳細に記載していただいたのはとても良かった。
  • 現在の給料を記載しなくて良い。そして、現在の給料より高いオファーをいただけることが多い。(残業40h込み、退職金なしが多い)

レジュメに書いて良かった点

主にオファーいただいた企業からは以下のようなことで評価していただいた。

  • 競技プログラミングやISUCON、個人(チーム)開発を業務外で行っていたので、結果的にそこが一番評価されることが多かった
  • レジュメ上ではうまく示せないですが、ドメイン駆動設計やClean Archtectureなど設計に関することを学んで実践してきたことを書いたこと
  • AWS SAAの資格を評価していただいた企業さんもあった

レジュメを記載するときにやれば良かったと思ったこと

レジュメを記載するときにやれば良かったと思ったことは、3点あります。

1点目は、全てのやったことをレジュメに書かないことです。最初の方で記載した通り自分は研修期間が長かったです。研修についてや、あまり大した内容でないことでも、やったことは全てレジュメに記載していました。しかし、成果を上げた2つくらいに絞ってしっかり書くのが良いと感じました。 実際に友人はGitHubでの活動やQiita等の発信は何もしていなかったですが、2つのプロジェクトだけで年収700万以上のオファーを頂いていました。(PM経験があり)

2点目は、希望年収を記載すること最初からすれば良かったです。記載しない方がバイアスを受けないので、年収が上がりやすいという話があります。実際にそれは正しいとは思いますが、Webでの主要言語(React, Ruby, Golang, PHPなど)の経験がない人は自分は希望年収を書いた方が希望年収でのオファーをいただきやすいと思いました。

3点目は、自分が何をできる人なのかしっかり書くことです。自分の場合、業務ではC言語での組み込み開発、AWS、CI/CD、IaC、フロントエンド開発、コード設計についてなど色んなことを手を出しすぎていて何ができる人なのか分かりづらい部分があったと思います。自分のなりたい姿と、自分が何ができる人なのかを合わせてアピールするのが良いと思います。

転職にあたって感じたこと

  • 主にWeb系企業に絞って転職しようとしていたので、C言語での組み込み開発は活かせないのであまりアピールにはならなかった(そもそも経験年数も短いので)
  • 業務上のAWS Lambda, SNS, SQS, DynamoDBのサーバーレス構成をメインでやっている企業は少なく、あまり評価されない印象を受けた(自分がバックエンドエンジニアとして応募していたので、、)
  • RDBMSを実務で経験していないのはマイナス材料になっていたとも感じた、(自己啓発で自作RDBMSを作っていたので、そこはかなり評価された)
  • 3次面接まであることが多く結構面接に時間かかるので、余裕をみて始めた方が良い

最後に

企業側から年収を先に提示されることは転職ドラフト以外にはなく、とても良いサービスだと感じた。忖度なしに本当に良いサービスだと思います。 自分は別のエージェント経由での転職になりましたが、友人は実施に試しに転職ドラフト登録してみて、結果的に転職することに決めていたので、転職を考えていなくても登録してみるのがおすすめです!!

ちなみに転職ドラフト登録後に、マイページに紹介コード「EIXE」を入力してレジュメ審査を通過しますと、 以下のどれかが転職ドラフト事務局様からプレゼントいただけるので良ければぜひご活用ください!

  • お好きなO’REILLY JAPANの本(税込5500円以内)を1冊
  • 転職ドラフトオリジナル ドラフトビール 6本入り
  • ACTUSギフトカタログ Straw(ストロー)
  • Amazonギフト券 3000円分

キャンペーン詳細

※ こちらの記事は転職ドラフト体験談投稿キャンペーンに参加しています。