トーク

現在、我々のプロダクトではDDD（ドメイン駆動設計）とレイヤードアーキテクチャを採用しています。
しかしメンバー変更や技術的制約などの背景から、コントローラにビジネスロジックが散らばる・重複判定がDBのキー制約に依存しているなどの課題が発生しています。
これにより、コードの凝集性が損なわれ、責務が不明確になり、保守性や拡張性の低下を招いていました。

本トークでは、「ビジネスルールのうちどこまでをドメインモデルで担保すべきか？」という問いを中心に以下のポイントをお話します。

• ビジネスルールが散らばることでDRYやSOLID原則に反してしまい、結果起こり得るリスクと影響
• ドメインモデルに担保させるべき責務の境界線はどこまでか
• 責務を整理し、ドメインモデルを中心とした設計を再構築するための”Package By Feature”などの具体的なアプローチ

このセッションを通じて、ドメインルール整理の重要性を理解し、設計上の責務分担を考える時の具体的な指針を共有し、皆様のプロジェクトに役立てていただければ幸いです。

概要

私たちのチームが手がけるLaravelで構築されたサービスは、Layered Architectureを採用しており技術ごとにクラスやフォルダを分けていました。
6年以上運用されているこのサービスでは、アプリケーションの拡大に伴いディレクトリ構造が複雑化し、新機能追加時に複数のレイヤーにまたがる変更が必要となるなど、コード修正の困難化や影響範囲の肥大化といった課題に直面していました。

この課題を解決するために、私たちは機能ごとにクラスやフォルダを分離する考え"Package by Feature"という設計手法を採用しました。
本トークでは、術ごとの分離ではなく、機能ごとにコードを分離することで得られるメリットと、その実践例を実際の適用事例を通して共有します。

話す内容

• 機能単位でコードを分離するアプローチの概要とその目的
• 技術単位での分離との比較による利点
• 機能単位でコードを分離することで、他の部分への影響がどのように最小限に抑えられ、テストやデプロイまでがどれほどスムーズになったか
• 直面した具体的な課題と、それに対する解決策
• 複数の"Feature"間でデータやロジックを共有する必要がある場合の具体的な対処法と実例

本トークを通じて、よりスケーラブルで保守性の高いコードベースを構築するための手がかりを共有できたら幸いです。

技術系の資格取得にチャレンジしていますか？
「エンジニアには資格は不要」という声も多い中、資格を取ることの意義について悩む方も多いのではないでしょうか。

本LTでは、営業職から未経験でエンジニアに転身し、さらにEMとしてキャリアを築いた私の経験を踏まえ、資格取得がどのようにキャリアを加速させたのかをお話します。

新たな業界への挑戦や社内で新たな役割を担う際、資格取得を通じて得た知識と自信が、新しい領域へのチャレンジを後押ししてくれました。

このLTを通して、一人でも多くの方が資格取得に興味を持っていただけると幸いです。

対象者

• 資格取得に意義を見出せずにいる人
• キャリアアップや新しい役割に挑戦したい人
• 未経験からエンジニアを目指している人

みなさんテスト駆動開発（TDD）を試したことはありますか？
このLTでは新卒1年目の僕が先輩と一緒にTDDに初挑戦した際の学びや気付きをお話しします！

今回はテストコードがない既存機能に、新しい機能を追加することになりました。
テストコードがない状態からでも、テスト駆動開発を用いることで手戻りコストが大きくなる前に不具合を早期に発見できることや、テストコードを仕様書のように使えるので楽に実装できることを学びました。

このLTがTDDに初挑戦する方の助けになれば幸いです！

「個人主義が根付いたチームをどう変えればいいのか？」
そんな悩みを抱えるリーダーに向けて、一匹狼だった新米リーダーのチーム改善の記録をお届けします。

リーダとして任されたコスト削減プロジェクトは、50%の未達により暗礁に乗り上げ、一時は先が見えない状況に。
追い詰められた中で「毎日の朝会」を導入し、チームの力を結集することで最終的に117%以上の削減に成功しました。

このセッションでは、一匹狼のリーダーが、個人では解決できなかった課題をチームの知恵と協力で克服した具体的なプロセスをお伝えします。

「どうやってチームメンバーの力と知恵を借りて、目標を達成するのか？」そのヒントが見つかる内容です。
チーム運営に悩むリーダーにこそ聞いてほしい、新米リーダーの泥臭い改善の記録です。

案件や開発について相談する際に、何に困っていて、何を相談したいのか、
頭の中が混乱してしまう経験ありませんか？

このセッションでは、実際の案件でどのような開発メモを活用し、思考の整理に繋がったかご紹介します。
ここでの「開発メモ」とは、単なる作業記録ではなく、現在の状況や課題、解決策を明確にするための記録方法です。

【概要】

• 何がわからないのかわからないが続き、相談できず、失敗・苦労した経験
• 相談する際に、何に困っていて、何を相談したいのか思考をまとめる方法
• 思考を整理する際に、活用した開発メモの項目
• 実施後の変化

【おすすめの人】

• 新卒エンジニア
• エンジニア初学者

LaravelのEloquetにはupsert関数があって便利だなぁ♪
あれ？updateOrCreate？
あれあれ？updateOrInsert？

一体どれを使えばいいんだーーー！！！

本セッションではこんな悩みを解決するために、それぞれの関数の説明とどう使い分けるかについてお話します。

最近の学生エンジニア界隈ではTypeScript, Go言語, Rustを学ぶ人がかなり多くなっており、PHPを現在進行系で学んでいる人は自分の周りではあまり見ません。
(書いたことある！という人は見ます)

私も、もちろんそれらの言語を書き、開発体験が良いと感じることが多くありました。
そんな中、自称関西学生PHPer最後の砦という責任感を持って今でもPHPを書いています。
そんな自分がPHPを書いていて良いなと思った点を言語機能やコミュニティの観点、ソフトウェア開発を学ぶといった様々な観点から色々話します。

学生目線というところが肝です。似たような話にはしません！
自己満LTになりそうですが、面白いトークを目指します。

PHP初心者がPHPを2024年11月下旬からこれまで勉強したことを発表します。
発表内容は以下になります。
・直面した課題とそれらをどう克服したか
・学習に使用したリソースやツール
・学んだ具体的なトピックや技術（例：PHPの基本文法、データベース接続、フレームワークの基礎など）
・今後の学習計画や目標

東京都が主催するオープンデータハッカソンは、プログラミングスキルがなくても誰でも参加できるイベントです。このLTでは、私がこのハッカソンに参加し、運良くファイナリストに選ばれた経験を共有します。

このハッカソンの特徴は、技術的なスキルよりもアイデアや実現性を競う点です。そのため、技術的な話題が中心となることが多いカンファレンスの中で、少しリラックスできるセッションになるかもしれません。

作品についての詳細は、以下のリンクでご覧いただけます:
東京都オープンデータハッカソン作品
https://odhackathon.metro.tokyo.lg.jp/collection/106/

テストを書くことにもだいぶ慣れてきましたが、いまだに嫌で仕方ないものがあります。それがデータプロバイダです。

データプロバイダを書くのは面倒くさい。本当に本当に面倒くさい。
というのもリリース恐怖症の私は、テスト対象のありとあらゆる条件やパスを通したくなります。
「いや〜書かなくても大丈夫だろうけど、怖いし一応書いとくか…」を繰り返すうちに、どんどんテストパターンが増え、データプロバイダが膨大になります。

ここでは、私をそんな無限コピペ地獄から救ってくれた「差分だけデータプロバイダ」をご紹介します。
こちらは【ツールなど使わず手動で】【データプロバイダに】【少しずつ値を変えて大量のパターンを対照実験する】ための方法です。
同地獄に陥っている方の一助となれば幸いです。

⁠対象者

• いつもデータプロバイダが太りがちな方
• ツールなど使わず手動で、大量のパターンをテストしなければいけない方
• データプロバイダを書くのが億劫で仕方ない方