いつも記事を読んでいただきありがとうございます！
モブエンジニア（@mob-engineer)です！
今回は2025.04.19（土）に開催したエンジニアの輪 at 東京 青山へ参加しましたので、アウトプットとしてイベントレポートを執筆しました。
初見の方でもサクッと読めるように平易な表現で執筆しておりますので、お気軽にお読みいただければ幸いです。
誤字脱字、わかりづらい表現、認識相違などは極力なくすように心がけています。そのうえで、リアルタイムで執筆しておりますので、誤字脱字、わかりづらい表現、認識相違などがあるかもしれません。
今回私も飛び入りでLT参加しましたがその部分は割愛いたします。
イベントページ
目次
- イベント概要
- トークセッション
- LT概要
- どうするSQS設計
- AI駆動開発で個人開発したら想像以上に未来だった件
- Github Actions Certificationを受けてみよう」
- CTOパネルディスカッション
- 各企業のサービス説明やエンジニア組織の紹介
- 開発チームを運営する上で、特に大事にしていることは？
- エンジニアの成長を促すために、社内で取り組んでいることはありますか？
- 採用の際に、 「これは絶対に見る！」というポイントは？
- エンジニアとして成長するために、若手におすすめの学び方は？
- OST
- まとめ
イベント概要
✅ エンジニア同士の交流を深めたい方
✅ CTOの視点から技術やキャリアについて学びたい方
✅ 技術トレンドや開発現場のリアルな話を聞きたい方
✅ 今後のキャリアパスについて悩んでいる方
✅ CTOやリーダー層と直接話し、相談してみたい方
✅ エンジニアとしての成長のヒントを得たい方
エンジニアの未来を語り、学び、つながる特別な機会。
この20回記念スペシャルで、あなたの技術とキャリアの可能性を広げませんか？ 🚀✨
トークセッション
個人の感想です
- MCPサーバは技術者界隈でも悩みを抱えている
- ユーザストーリー関連は悩みがある
- 私もプロダクト開発でどうやって価値を伝えるか悩みがあるからなぁ
- 自己紹介シートを通じて議論したいこと・SNSなどを事前共有しているのでトークしやすい
- 席替えタイムを入れると他の方とのコミュニケーションが図れそうですね
- トークタイムを通じていろいろ学びが得られますね～
LT概要
どうするSQS設計
- 自己紹介
- 受託企業⇒自社開発を得てフリーランスをされている方
- サービス間のやり取りについて考えている方
- SQS周りの悩み
- オートスケーリングどうするか、SNSを組み合わせるかなど
- 単一サービスと連携であればSQSだけでいい
- 複数サービスと連携するのであればSNSを組み合わせる必要がある
- （個人的意見）メール通知が不要であればSNSはいらないですね
- ECSを活用するのは
- Workerとして常時起動する新規のデプロイフローを採用した
- クラスターはSQS単位で考えた
- クラスター数が多くても対応が可能
- 処理分岐をどうするか
- 単一処理であれば一つの処理のみでいいがECS構築が必要
- 処理分岐であればACTION名で分岐可能＋今後の実装工数が楽になる
- （個人的意見）確かに社内向けであれば処理分岐でいいですね
- 大規模だと単一処理の方がパフォーマンスが出せる
- （個人的意見）小さく始めるで進めているのがいいですね
- （個人的意見）意思決定するために各ステップごとに分割していくのはいいですね
AI駆動開発で個人開発したら想像以上に未来だった件
- 自己紹介
- オーガ名義でSNS発信している
- Goが好きなエンジニアの方
- 作成したプロダクト
- 旅の振り返りサービス
- AI駆動開発でバックエンド・フロントエンド・インフラすべてを開発した
- ダークモード対応も行うことができる
- 利用したAIはGitHub Copilotを利用した
- 所感
- GitHub Copilotを利用して作成した
- MCPなども活用した
- AIを利用するうえで感じた課題はいくつかある
- レイアウトがAI生成っぽい
- うまく利用できない場合も
- 課題に対してプロンプト手法を用いて解決を講じてみた
- マークダウンでコーディングルールを示せるのはうれしいですね
- （個人的意見）試したことをすぐにLTとしてアウトプットするのはいいですね
Github Actions Certificationを受けてみよう」
登壇資料
参考サイト
- 自己紹介
- エーピーコミュニケーションズ所属の方
- Microsoftつよつよの方
- GitHub Certificationsとは
- GitHub製品の専門的な知識を証明する試験
- ざっくり言えば、GitHub Actions管理者として求められる知識が問われる
- 学習方法
- MS Learnによる学習
- （個人的意見）ハンズオン形式なので面白いですよね
- GitHub CI/CD実践ガイド
- （個人的意見）実践でも使えるようにするのがいいですよね
- LinkedIn学習サイト
- 有料なのでハードルが高い
- ghcertified
- GitHub有志による問題集サイト
- 問題集を暗記するのではなく、実際に手を使って覚えてみる
- MS Learnによる学習
- 受験方法
- テストセンター・自宅双方で受験することができる
- 合格点については公開されていない（6割？）
- 問題内容として純粋な知識を問うもの
- （個人的意見）AWS・MCPのようなケーススタディの方が面白いんですよね
- 日本語訳に難ありなので読解が難しい
- 所感
- 普段利用している機能に関する細かい挙動・制約を理解できた
- （個人的意見）実務に生かすのが流石すぎますね
- 普段利用している機能に関する細かい挙動・制約を理解できた
CTOパネルディスカッション
- RYDEさん：シリーズA達成したての企業
- KiteRaさん：資金調達を積極的に行っている企業
- ココペリさん：上場している企業
RYDEさんページ
KiteRaさんページ
ココペリさんページ
各企業のサービス説明やエンジニア組織の紹介
- KiteRaさん
- 安心して働ける世界を実現することをミッションとしている
- ToB向けの労務管理サービスを提供している
- 社会保険労務士と呼ばれる専門家の知識をプロダクトに落とし込んでいる
- （個人的意見）すごく面白いプロダクト！！
- ココペリさん
- 上場して4～5年の企業
- フルスタックエンジニア・SREなどの部門ごとに分かれている
- QAチームでも要件定義から入っていくことがある
- （個人的意見）QAで要件定義から入っていくのは面白いですね
- Nuxt、独自フレームワークなどのコード負債をAI駆動開発を用いて改善しているところ
- RYDEさん
- 創業したての会社のためフラット
- 鉄道・バスなどの移動に関するプラットフォームを管理するアプリを提供している
- （個人的意見）一つのアプリで管理するとなるとAPI設計が大変そうですね
- 最近、技術ブログを投稿し始めた
開発チームを運営する上で、特に大事にしていることは？
- KiteRaさん
- チーム全体で最大限のパフォーマンスを発揮できる組織
- 心理的安全性が担保されていることが重要
- ココペリさん
- カルチャーデックと呼ばれる事業部文化を明文化している
- 早くレビューを行う文化を行う
- レビュアー・レビュイー双方を理解した取り組み
- 継続的な学習を行うこと
- RYDEさん
- 心理的安全性が担保されている組織が重要
- 意味のない開発・タスクを行わない文化を作っていく
- 選択と集中を考えた開発を行うことが大切
エンジニアの成長を促すために、社内で取り組んでいることはありますか？
- KiteRaさん
- コミュニケーションに重きを置いている
- ペアプロ、モブプロなどの手法を利用している
- 禅問答・お互いに学びあう文化を作っていく
- マネージャーだけでなくテックリードとのコミュニケーションできる文化を作っていく
- コミュニケーションに重きを置いている
- ココペリさん
- ペアプロ・モブプロなどの文化醸成は大切
- 自身の市場価値向上を高められるような環境を構築している
- （個人的意見）会社から補助が出る文化はいいですね
- RYDEさん
- 資格取得奨励・勉強会開催などの文化醸成を行っている
- 書籍・ブログシェアを行えるような環境を作っている
採用の際に、 「これは絶対に見る！」というポイントは？
- KiteRaさん
- 立場上最終面談となるため入ってもらうように仕向けている
- 見るべきポイントとして、フルコミット、カルチャーフィットを見ている
- （個人的意見）強すぎず・弱すぎずのちょうどいいスキル感でことですかね
- ココペリさん
- カジュアル面談などで出てきている
- 最近読んだ書籍から話の幅を広げている
- RYDEさん
- 心理的安全性、チームにマッチするかどうか
- シリーズAの働き方（フルスタックに幅広く働けるか）を見ている
- エンジニアとして学習を楽しめているかを見ている
- （個人的意見）全部できるエンジニアは希少性ありますよね！！
エンジニアとして成長するために、若手におすすめの学び方は？
- KiteReさん
- コードを読んだときにアルゴリズムを理解し説明できる能力
- ひたすらコードを読むことが大事
- コードを読んだときにアルゴリズムを理解し説明できる能力
- ココペリさん
- 成長したければ勝手に成長してもらいたい
- 開発手法だけでなく、哲学・社会学などの人文系の知識を持つことが大事
- （個人的意見）分かりみが深い内容ですね
- RYDEさん
- 可処分所得時間が多くあるうちに個人開発を行ったほうがいい
- 何か作ってみることが一番重要なのではないか
- AI任せではなく自分で考えてみることが大事
- （個人的意見）分かりみが深いですね
OST
一個人の意見です
- 議論フェーズ
- 資格に関しては業務に直結するわけではない
- 球が大いに越したことはない
- 技術サイド・マネジメントサイドでも変わってくる
- 360度評価もうまく運用しないといけないですよね
- 事業インパクトをどう考えるかがポイントですね
- （個人的意見）難しいですね
- 資格に関しては業務に直結するわけではない
- 討論フェーズ
- エンジニアとしての業務速度を向上させる
- Devinを用いて並列実行させる
- 自分のコードを執筆しつつ、Devinに任せる部分は任せる
- DevinだけでなくCursorを利用するという手もある
- Devinを用いて並列実行させる
- AI時代のエンジニアスキル
- コーディングに関してはAIに任せるようにする
- 今後のエンジニアスキルとして提案能力が求められる
- スキル評価
- 業績にどれだけインパクトを与えたのか
- ランク付けで評価することがベターではないか
- 技術選定で大切なこと
- エンジニア目線とテックリード目線で考えてみた
- EOL対応時に移行 or アップデートを考えてみた
- エンジニアして：移行
- 移行先の方が学習リソースがそろっている
- 採用時にアピールすることができる
- テックリードしてん：アップデート
- アップデートも移行も費用対効果がかかる
- 現在でなくその先を見据えて考えていくことが大事
- エンジニアして：移行
- 伸びるエンジニア・伸びないエンジニア
- 伸びるエンジニアの特徴として次の通り
- 行動：質問の仕方がうまい、言語化がうまい、やったことないことでもチャレンジする
- マインド：当事者意識をもって行動している、仮説思考を持っている
- 挑戦・熱量があることが重要
- 伸びないエンジニアの特徴として次の通り
- 行動：仕事を抱え込んでしまう、与えられたタスクのみを行っている
- マインド：相手の気持ちを考えない、他責思考
- 伸びるエンジニアの特徴として次の通り
- エンジニアとしての業務速度を向上させる
まとめ
エンジニアの輪に関して今回初参加ですが、普段で会わない業種の方とコミュニケーションを図ることができました。そのうえで、個人開発を行うモチベーションを向上させることができましたので、何かしらのアウトプットを行っていきたいと思いました。
最後まで記事をお読みいただきありがとうございました！！