トーク

ホライズンテクノロジー代表の大谷は、これまで10社以上のCTO/技術顧問を経験してきました。
技術組織においは、フェーズ、体制、プロダクトなど、様々なことに起因する課題が発生します。

どんな課題に対して、どんな対策が有効なのか。そうやって課題を解決していくのか。
エンジニアの立場と経営者の立場、両方を経験したからこそ見えた内容を発表します。

新入社員がテストコードを書けない場合、どのように教えますか？
日頃書く人は感覚的に書けますが、書いたことのない人はコツを掴むまで時間がかかってしまうものと思います。
皆様も経験があるのではないでしょうか？

本セッションでは、そんなテストコードのチュートリアルをpublicリポジトリとして公開・そのリポジトリの利用方法のお話をします。
Dockerを利用することで、Docker環境さえ整っていれば誰でもLaravelフレームワーク内でPHPUnitのテストを書くための問題集にチャレンジできる内容となっております。
全ての操作用のコマンドやREADMEを用意しているので、Dockerの知識がなくてもテストの実行やテスト用DBの中身を確認できます。

これを機にテストコードを書けるようになってみませんか？

対象者：
・テストコードを知りたい方
・育成コストに悩んでいる方

PRのコメントで、「テスト後で書きます！」やコードに「// TODO: テストを追加する。」といったやりとりを一度は見たことあるかと思います。
しかし実際に後でテスト書かれたことはありますか？
また、テストがないことでコードの変更に対する不安が生じ、開発速度が遅くなることもあります。

「テストを後で書く」と決めても、多くの場合それは単なる願望です。
テストを後回しにすることのリスクや、そもそもなぜテストが必要なのかを考え直し、今すぐテストを書くことのメリットを解説します。

話すこと:

• テストを後回しにする・書かないことで何を失っているのか
• テストで得られるもの（テストの価値と、テストの短・長期的な価値について）

日付を扱う際、私たちは時に"存在しない日付"に遭遇・生み出してしまいます。
例えば、2024年2月30日や2024年13月1日のような日付です。
このような日付が生まれると、バグが生じる原因となります。

本トークでは、存在しない日付が生まれる原因と解決策を実際のバグ事例を用いて解説します。

ターゲット:

• 日時操作をコピペしている方
• 文字列操作で日付を生成している方

このトークでは、短期ハッカソンにおける効率的かつ効果的なサーバーサイド開発のためのアーキテクチャ設計について掘り下げます。ハッカソンでクリーンアーキテクチャやレイヤードアーキテクチャを取り入れた私の経験を基に、これらのアプローチのメリットとデメリットを分析し、開発者が遭遇する課題への具体的な解決策を提案します。特に、限られた時間内で可読性、拡張性、保守性を犠牲にすることなく、迅速にプロダクトを構築するための戦略を詳しく紹介します。このトークは、ハッカソンでの成功と技術的な挑戦に取り組む開発者へ、アーキテクチャ設計に新たな視点を提供し、短期ハッカソンにおける私のアーキテクチャに関するベストプラクティスを共有することを目的としています。（本トークではGo言語を用いた実装例を中心に取り上げます。）

SEOとは、検索エンジンを通じてWebサイトへの集客を増やし、成果を向上させるマーケティング手法の一つです。

私はh1タグの改修から新規コンテンツの追加まで、これまで大小関わらずSEO領域の開発に携わってきました。

しかし、あるとき「SEOのためのこのプログラム改修が、システムにとって本当に良い選択なのか？」と疑問を抱いたことがありました。
このトークでは、私の経験から "SEO施策を実行する中で感じたエンジニア的ジレンマ" についてご紹介します。

ビジネス要件をテクニカルな仕様に落とし込む際、
「SEOの考え方」と「最適なプログラム設計」の間で陥った葛藤にどう向き合うことにしたのか。
SEO領域でエンジニアリングするPHPerの考え方の変化を、SEOの魅力とともにお伝えします！

\ 日々葛藤しとるけど、やっぱしSEO好きやけん！みんなに知ってほしいっちゃ〜٩('ω')و //

▼概要

Laravelでは「運営ユーザのみアクセスできる」などの認可をmiddlewareを使って簡単に定義できます。
定義の仕方も「routingファイルに書く」・「Policyを使う」など様々な用途で使い分けができます。 便利ですよね。

しかし、上のような書き方だと、どうしてもroute側かPolicy側が認可の責務を持つことになってしまいます。
もしかしたらValueObject・Entityを使う設計がされているプロダクトではValueObject・Entityごとに対する操作の認可というアプローチもありなのかもしれません！

このLTでは、ValueObject・Entityごとに対する操作の認可の実際の書き方・書くことでどういうメリットがあるかをお話します！

自身の書いたコードを誰かに伝わりやすいものにするための補足として、コメントを残すことがあります。
しかし運用や改修を重ねていくと、実装ばかりに気を取られてしまい、気づいたらコメントがすらごついーになっている可能性があります。

本セッションでは、すらごついーコメントアウトを生まないために、コードを書く上で残すべきコメント・残さないべきコメントについてお話します。
また、コメントを残さないようにするためのリファクタリングのテクニックや、コメントとの向き合い方についての考え方を紹介できればと思います。

対象者：
・コメントを添えるのが癖になっている方
・すらごついーコメントを見かけたことがある方

クロスプラットフォームアプリ開発フレームワークのReact Native(RN)はJavaScript(JS)でiOSとAndroidアプリを効率よく開発、早くリリースできるメリットがあります。
一方でPain Pointとしてはメンテナンス性の悪さがあり、RNのアップグレードにはiOS/Androidの設定ファイル（Info.plist/build.gradleなど）やコードの変更が必要で、さらにサードパーティのJSライブラリやネイティブモジュールの更新となると大変です。

Expoによって定義されたContinuous Native Generation(CNG)というコンセプトを取り入れることで、スケーラブルでメンテナンス性に優れたクロスプラットフォームアプリ開発が可能になります。
このトークではCNGの概要、CNGを取り入れたExpoアプリ開発プロセス、導入事例ついてお話します。

みなさんNativePHPはご存じでしょうか？

このNativePHPは、HTML、CSS、JavascriptそしてPHPを用いてデスクトップアプリケーションを開発可能にするフレームワークです。
そう、PHPを使ってデスクトップアプリケーションが書けるのです！

今回はこのNativePHPでスイ◯ゲームもどきを作る/作ってみた話をLTという短い時間の中で精一杯の情熱を込めて発表したいと思います。

話すこと

• NativePHPとは
• 作るときに困ったこと
• デモ

話さないこと

• 詳細な実装方法

みなさんは技術イベントに参加する際、オンラインで参加したことはありますか？
オンライン配信はイベントが開催されるオフラインの現地に足を運ばずともイベントを楽しむことができるというとても優れた手段ではありますが、
その要望に応え、参加者の方が見やすい形で広く提供するためには様々な課題があります。

昨年末から、いきなり「技術カンファレンス」や「技術イベント」などの配信を始めた初心者が、わずか半年で15回もの大小さまざまなオンライン配信をしてきました。
様々な形態の配信をする中で直面したトラブルで得た学びや、オンライン配信を作る側としての面白い裏側の秘密をお届けします！

【実績】
・PHP勉強会@東京
・PHPcon小田原2024（北海道、関西も当日協力）
など

【このトークをおすすめしたい人】
・オンライン配信を自らやる事に興味がある人
・普段、何気なくイベントにオンライン参加している人

私が異業種からITエンジニアを目指した頃は、転職希望者が多くいわば駆け出しエンジニア戦国時代。
その時代の波に揉まれながらエンジニアを目指す旅路は冒険の連続でした。

プログラミングの基礎を学びながら転職活動をするも難航してなかなか決まらず、
当初ITエンジニアとしてのキャリアは積めそうに無い状況にありました。

そんな状況だった私がITエンジニアとしてのキャリアパスをどのように築いていったのか、
それぞれのステップで直面した課題と乗り越えた方法についてお話しします。

道は一直線ではありません。様々な選択肢があり、選んだ道によって結果は大きく変わります。
私の経験がこれからのキャリアを考える皆さんの一助となれば幸いです。

内容:
私の初めての開発はフロントエンドでちょっとしたサービスを作って公開してみたものでした。
あの頃、右も左も分からず書いたコードのレビューをして初心者が初めて開発するときに引っかかりやすい罠や初心者に教える時に気をつけた方がいいことについて話そうと思います。
トークの対象者:
Webプログラミング挑戦中の方
Webプログラミングを人に教えている方
注意:
初心者の頃のよわよわなコードが見られるかと思いますが、優しい目で見てください笑
reactで書いたプロジェクトですが、一般的に気をつけるべきことについて話します！

みなさん、「GraphQL」 使ってますか？
GraphQLはWeb APIを開発するためのクエリ言語であり、
クライアントが本当に必要なデータのみを柔軟に取得できる仕組みとして注目を集めています。

そんなGraphQLですが、PHPでもLighthouseというフレームワークを使うことにより、簡単にGraphQL APIを実装することができます。
さらにはこの実装したGraphQL API、少しの工夫を加えるだけでこれまた簡単に、TypeScriptから型安全に呼び出すこともできちゃうんです。

このセッションでは「これからGraphQLに触ってみたい！」という方を対象に、
Laravel + Lighthouse + TypeScriptを用いた"型安全なGraphQL API開発体制の作り方"についてお話しさせていただきます。

QAエンジニアの経験に基づく「勘」や「独自の観点」は、製品の問題点を見つけ出すのに役立つことがあります。
しかし、このような知見は、そのままではチームメンバーに伝達するのが困難です。
結果として、チーム内でのよりよい役割分担が妨げられてしまったり、新しくチームに参加したメンバーに有用な情報を伝えられなかったりすることがあります。
そこで、本トークでは、（あくまで私の経験をベースにして）「QAエンジニアの勘」と呼ばれているものを言語化し、伝達可能にすることを試みようと思います。

わたしは十数年間この業界にいますが、いろいろなサービス層を見てきました。

• DBの処理がごっそり書かれているサービス
• トランザクションスクリプトが詰まったサービス
• いろいろな場所から使われる神サービス
• たくさんのサービスで徒党を組んで仲良くしているサービス
• ドメインレイヤーにおけるサービス
• とりあえずサービス

可愛らしいサービスや憎きサービスがそこにはいました。
そしてこう思うのです「人には人それぞれのサービス層がある」と。

なぜ、人はみなそれぞれのサービス層を作ってやまないのか謎に迫りつつ、

• そもそもサービス層とはなにか
• どのような場面でサービスをつくるべきか
• 憎まれるサービス、愛されるサービスとはなにか
• 理想とするサービスの探求

について、SOLID原則、特にSRP（単一責任の原則）について言及しながらお話できればと思っています。

開発をしていると手が止まることがあります。
実装したい機能を実現するための技術的課題がある場合は当然ですが、そうでないときも手が止まることがあります。
そんなとき何に悩んでいると思いますか？
いざ聞いてみると「そんなの今悩む必要ないよ」と、思いきや実は今悩んでいたほうがいいことがあるんです。というかあると思って悩んで手が止まっています。
N=1ですが、ある開発者の手が止まりポイントを紹介します。
理由を聞いて、何かしら得られることがあるかもしれません（し、そんなこともないかもしれません）。
皆さんの「手が止まりポイント」も聞きたいです。語りましょう。

Rustは高いパフォーマンスとメモリ安全性を両立したプログラミング言語で、最近ではLinuxカーネルの開発に一部取り入れられたことでも話題になりました。

そのRustで、PHPの拡張モジュールを作ることができるのをご存知ですか？
拡張モジュールはC言語で開発されることが一般的ですが、ext-php-rsというライブラリを利用すると、Rustで書いたコードをPHP拡張モジュールとしてコンパイルすることが可能になります。

このセッションでは、Rust初心者であるPHPerの私がPSR-7のライブラリを題材に、以下のことをお話しします。

• Rustとはどんなプログラミング言語か
• PSR-7とは何か
• RustでのPHP拡張モジュールの作り方・デモ
• Rustを使ってみて感じたこと

先輩や上司になにかを相談したり1on1したときにみんなよく言う「メタ認知を鍛えよう」とか「メタ認知力を上げよう」という言葉が何を指しているのでしょうか？
視座とか自分を客観視したときの状態とか難しい言葉が多く、何を意識すればよいのか分かりづらいですよね。
また、成長のために必要だと言われてもいまいち何をすればよいのかイメージも付きません。

このLTでは、「メタ認知」の図解や具体例を交えながらわかりやすく解説しつつ、「メタ認知」を身につけるために有効な方法をご紹介します。

最近のプロダクト開発においてSPAやマイクロサービスといったアーキテクチャを採用しているケースが多く、バックエンドのWeb APIの開発を避けて通れないと思います。

登壇者も近年数多くのAPIの開発を行ってきました。その中でスキーマ駆動開発も取り入れた開発プロセスを取り入れるなど、APIのスキーマ定義・管理方法ついて試行錯誤を重ねてきました。

その中でAPIのスキーマのバージョン管理がコラボレーションを行う上で大変重要であると気づきました。

如何にAPI開発側及び利用者双方の運用負荷を増やさない開発プロセスを考えることが大事です。

• APIのバージョン管理
• API仕様書の静的チェック
• API仕様書を活用してアプリ全体の品質向上
• 仕様書以外でのバージョンの活用
• 円滑なリリースマネジメント

等など、CI/CDまで踏み込んだ実践してきた内容をご紹介いたします。