いつも記事を読んでいただきありがとうございます！
モブエンジニア（@mob-engineer)です！

今回は2025.02.20（木）に開催した渋谷でビール片手にLT会！ ※初心者大歓迎に参加＋登壇しましたので、アウトプットとしてイベントレポートを執筆しました。

初学者でもサクッと読めるように平易な表現で執筆しておりますので、お気軽に読んで頂ければ幸いです。

誤字脱字、分かりづらい表現に関しては極力なくすように心がけていますが、リアルタイムで執筆しているため、誤字脱字があるかもしれません。

私の登壇セクションに関しては割愛いたします。
（別途、記事を執筆したいと思います）

目次

失敗から学んだチームコミュニケーション

自己紹介
責任者に任命されて
- ライン長としてエンジニアとのコミュニケーション活性化を求められた
- 受託開発と自社開発のエンジニア間でのコミュニケーションが少ない
  - 受託側に関してはプロダクトレベルでもコミュニケーションが少ない
健全なコミュニケーション
- 雑談が多い、ではなく、技術交流を主体的に行えるを目指した
  - 前職のベンチャー経験から
- 「議論が生まれる土台がないのでは」といった仮説立てを行ってみた
活性化施策
- ワークショップの実施
  - 「楽しくなければものづくりじゃない」をテーマに実施
  - 経歴などはバラバラでチーム作りを行ってみた
    - エンジニアの役割に関してもあらかじめしめしてみた
  - フィードバックとして、「意外と○○さんは～～」が多くあった
  - ワークショップをやりすぎて、会社から怒られた
ワークショップを踏まえた仕事へのフィードバック
- 技術選定などでワークショップの結果を反映させてみた
  - （個人的考察）より最適な役割定義、実行かしら
まとめ
- 継続して得られた知見を業務へコミットしていく

自己紹介
- TAIAN所属のエンジニア
- エンジニア歴3年のバックエンド7割・フロントエンド3割の方
- 技術スタックはRails、Reactを触っている
- 趣味は麻雀、カードゲームなど
スクラム開発
- 2024年11月からはじめた
- スクラム開発を通じてビジネス視点を得ることが出来た
  - デイリースクラムなどの取り組みがあるが全てはビジネス視点
- スクラム開発を通じてビジネスサイドとのコミュニケーションが多くなった
スクラム開発のデメリット
- 開発時間が少なくなってしまった
  - スプリントレビューなどコミュニケーションの時間が掛かってしまった
スプリント期間の決め方
- 頻度を取るか、速度を取るかで変わってくる
- リリース頻度重視：スプリント期間を短くする
  - 課題が特定出来ていない場合はベター
- 開発速度重視：スプリント頻度を長くする
  - 課題が特定できている場合はベター
その他の観点
- ビジネスサイド視点以外もあるかもしれない
- バックログの処理などをどうするのか

自己紹介
- RUNTEQで学んでいるエンジニアの方
- 元トラックとライバー、駅員の方
- 最近、ワカサギ釣りに行ってみた
SPAとは
- 単一のWebページでアプリケーションを構築する設計手法
- （個人的考察）Facebookなどが有名ですよね
SPAキャッチアップ
- Ruby on Railsをキャッチアップしていた
- 今回はRubyでSPAを構築してみた
  - APIモードで動作させることが可能
  - 最近だとRails単体でも開発可能
技術スタック
- 保有している技術スタック的には難易度が高そうだがやりがいがありそう
CI/CDパイプライン
- CI：ざっくり言えば、GitHubぺPushする挙動
- CD：ざっくり言えば、Pushした内容を各種アーキテクチャへ反映させる
- 試してみたがデプロイが失敗してしまった
  - 原因としてNode Moduleのアップロードを都度行っていた
  - ignore処理したら上手くいった
AWSコスト
- 4ヶ月で9000円かかったので、使わないリソースは削除しましょう

自己紹介
- ディー・エヌ・エー所属の新卒エンジニアの方
- 現在はRails開発を行っている
- 2000年01月01日生まれの方
- ハッカソン運営なども行っていった
SPAJAM
- 温泉地で開催されるスマホアプリハッカソン
- 24時間でお題に沿ったアプリ開発を行う
  - 予選（6回）で勝ち残ると本戦出場
  - 最優秀賞はシリコンバレー旅行
- 今回はSwiftつよつよ民でチームを組んでJoin
JAM開発
- お題が猫だったため、猫になりたいといった意識で開発
  - ねこぱんちというアプリを開発
- 加速度センサやP2Pなどの高度技術を活用してみた
得た学び
- 作った中で検証をたくさんする
  - 手動で検証してみることで本当に面白いのかどうかを見極められる
  - 予選でのアプリは検証があまり行えず、2位という結果に
- 作ったモノをよりよくしていく
  - 予選の失敗経験を踏まえ、検証作業を多く行うことでより良いアプリ開発がおこなえるようになｔ

今週3本目のLT登壇を実施してみましたが、意外とまだまだやれるなと思ったため、LT登壇含め、今後もチャレンジしていきたいと思いました！

そのうえで、どの登壇も私が知りたい・キャッチアップしたいと思う内容が多かったです。今回得た知見を、自身の言葉でアウトプットしていくことを行っていきたいと思います。

PS：
本日登壇したLT資料です～