「コンピュータは0と1しか処理できない」とよく言われています。
ビット演算があったり、浮動小数点演算があったり、文字コードが16進数だったりと、PHPerのみなさんもなんとなく実感としてはあると思いますが、なぜ「0と1しか処理できない」のでしょうか。

このトークではアナログの世界・電気回路でデジタルの世界・コンピュータ処理がどの様に表現されるのか、私たちがC言語やPHPで書いたプログラムの実行結果がディスプレイやスピーカーで認識できるところまでがどの様にできているかをお話します。

ふだんの活動ではあまり気にすることのないコンピュータの基本的な仕組みの話になりますが、このトークを聞いたみなさんが今までより少し解像度の上がった目でコンピュータを楽しめることを願っています。

DDDの戦術パターンや、複雑化してしまったシステム、
マイクロサービスアーキテクチャなどとうまく付き合うためにはイベント駆動型のシステムが必要不可欠です。
再度ES+CQRSという仕組みに注目されている方も多いのではないでしょうか？

APIベースのアプリケーションではなぜ難しくなってしまうのでしょうか？
なぜES+CQRSなどが必要になっていくのでしょうか。
PHPだけで実現するには複数の手法を組み合わせる必要がありますが、
本セッションでは実際にES+CQRSを導入する際のポイントや、アンチパターン、
ドメインモデルからの落とし込み方、他言語での実装方法なども踏まえて簡単に解説します！

天然の問題の養殖の問題より奇なり。
現場で見つかった驚きの事実を皆様にお送りします。

※フィクションです

エンジニアは開発だけではなく、仲間集めを会社から求められることもあります。
多くの採用フローでは最初にカジュアル面談というステップがあり、候補者に会社について興味を持ってもらう場が存在します。

採用フローの入り口であり、ここを上手くできなければその後の面接に繋がらない大切な会ですが、慣れるまではなかなか上手く行かなかったり、何話したらいいのか分からないことも多いと思います。

自分もここ1年ほどで週1〜3回カジュアル面談を担当しましたが、最初はめちゃめちゃ難しかったです。

この経験を踏まえて、採用におけるカジュアル面談ってどういう準備をして、何を話して、どうやって次の面接につながればいいのかお話します。

ソフトウェア開発において、品質と生産性の向上は常に追求される目標です。
しかし、これらの目標を達成するための手段として、コードレビューの重要性がしばしば見落とされます。

本セッションでは、
・効果的なPRテンプレートの作成方法
・レビューイが良いコードレビューを受けるためのポイント・テクニック
・レビュアーがコードレビューをする上で気をつけるべきポイント・テクニック
などの我々が実際に取り組んできた効果的なコードレビューの実施方法とその重要性について解説します。

「コードレビューをどのように行えばよいかわからない」「他のチームはどのようにコードレビューを行っているのか知りたい」という方々にとって、
本セッションは有益な情報を提供します。

データベースの寿命は、アプリケーションよりも長い。
多くの人が感覚として持っているのではないでしょうか。

この10年間で多くの技術が生まれ、そして変化し、開発の現場も進化してきました。
そんな中、データベースの世界では何十年もRDBMSが活躍しています。

それはなぜでしょうか。
この10年間のRDBMSの変化から開発に必要なことが見えてくるはずです。
そして、そこからこの先の10年を見据えたシステム開発の勘所を紐解きます。

OracleDBやSQL Serverのような商用データベースに対して、MySQLやPostgreSQLのようなOSSデータベースは如何に追従しているのでしょうか。
そしてAmazon AuroraやGCPのCloud Spannerのようにクラウドならではの新しい形のデータベースも次々に生まれています。

これらを題材に今、あなたが新しいサービスを作る時、10年戦えるデータベースの作り方を見つけていきましょう。

WEBアプリケーションを開発するうえでセキュリティは切っても切り離せない重要な事柄です。

WEBセキュリティの情報や教科書はたくさんありますが、全てを勉強するのは大変です。
実際に現場であった事故やコードの例を紹介し、最近のフレームワークを活用したWEB開発で起こりがちなセキュリティ事例をお話しします。

◆対象者
・ある程度PHPでWEBアプリケーション開発をしているジュニアorミドルエンジニア
・チームが書くコードをセキュアにしたいリードエンジニア

◆書くこと
・コードレビューしてたらこんな危ない書き方があった！
・こんな脆弱性があった！
・こんな攻撃を受けた！

WEBアプリケーションを開発するうえでセキュリティは切っても切り離せない重要な事柄です。

WEBセキュリティの情報や教科書はたくさんあります。
皆さんも勉強されていることでしょう。

しかし、セキュリティ事故が起きたら一体どんなことが起きるのでしょうか？
PHPで書かれたWEBアプリケーションが攻撃され、実際にセキュリティ事故が起きた時にとても辛かった思い出を面白おかしく話します。

◆対象者
・ある程度PHPでWEBアプリケーション開発をしている人

◆話すこと
・前提の状況
・実際に起きたこと
・どんな対応が起きたか
・どれだけ寝れなかったか

チームの成長と改善を促進するために、定期的なふりかえりは重要です。
しかし、「単なる会議に終わってしまう」、「カイゼンが継続しない」、「なんか微妙な雰囲気で終わってしまう」...など、ふりかえり自体がなんだかうまくいかないことってありませんか？
実際に私も上記の経験をしてきました。その失敗たちを元にカイゼンを重ねていったわたしの「最強のふりかえりファシリテーター法」をお話します！

私が大事にしていること

• ポジティブな雰囲気作り
• 気になったもののみを深ぼる、選択と集中
• チームの雰囲気に合わせて手法を選択する
• カイゼンを継続させる

オブジェクト指向プログラミングにおいて重要な概念となる「SOLID原則」 。
本セッションでは、自分が違反して書いてしまったコードを例に、SOLID原則を紹介していきます。

どのSOLID原則に違反しているか

• 違反がもたらす具体的な問題
• 正しい実装
• 多くの書籍でSOLID原則に関する具体例が示されていますが、このセッションでは「実際の失敗例」を通じてSOLID原則を理解していただこうと考えています。

自分がミスってしまった実装例を、時間の許す限り赤裸々に公開します！！

開発って実はお金かかるんです！
え、そんなのは知ってる？

じゃあ、新しい機能を作るとき、どのくらいのお金がどこにかかるか、考えたことあります？
私は詳細まで考えたことはないです。なので今から実際のプロダクトを例に考えてみましょう！

たとえば、PHPだけじゃWebサービスは提供できませんよね。
そのWebサービスがAWSなどの従量課金制のプラットフォームで動いているならアクセス量に応じてお金がかかりますよね。
PHPとそのサービスを動かす仕組み自体にも当然運用コストが乗ってきます。

ところでPHPを書いている人は？仕組みを組み立てている人は？そのサービスはエンジニアだけいれば成り立ちます？
つまり、機能の開発にも運用にもお金がかかるのです。

当然時間もかかるので、綺麗事抜きに、これから作る機能は、そのお金を払ってまでも作る価値はありますか？と問いかけて作っていったほうがいいのはないでしょうか。
その機能を作ることでどれだけの人の労力と時間を削減できるのか、それをお金に換算するといくらなのか、を考えることで
あらためて自分たちが生み出すことができる価値の大きさを知ることができるような気がしています。

「良いプロダクトを作るためにもっとエンジニアとビジネスサイドで協力していきたい！」
その想いを胸に半年前からスクラムを使ってプロダクトを作っています。

それまではエンジニアとビジネスサイドが同じチームで深く関わって仕事をすることがあまりありませんでした。
スクラムを入れる上でコミュニケーションの取り方をガラっと変えたかったのですが、ちょっとハードルが高いかもな、、と感じました。

そのため最初は敢えて「不完全」な形式でスクラムを始めました。
スクラムの良さをチームで実感するにつれて、徐々に「完全」なスクラムになっていきました。
そして今は「チーム全員で良いプロダクトを作っている」という感覚があります。

本トークでは、どのようにスクラムの体制を改善していったのか実体験をベースにして紹介します。

このトークの対象

• スクラムに興味がある人
• 組織的な課題でスクラム導入に悩んでいる人

スクラムでの開発にはレビュー会という、スプリント内で実装した価値をお見せする場がある。
決まっていない部分はダミー実装で後回しにして、Interfaceを切ってIOだけを明確にして、とそこまでは順調だった。

だがしかし、レビュー会までにプロダクトは出来上がらなかった。

不確実なことを抽象のままできるだけ後回しにして実装したのに、詳細の実装が間に合わなくなってしまったのはなぜなのかを実装の進め方とともに振り返ってみようと思う。

みなさん、サーバレスで動かすPHPはお好きですか？ 私は大好きです。
よくサーバレスなマネージドコンテナサービスでWEBアプリを実行しますが、定期実行するジョブもマネージドなサーバレス環境で実行したくありませんか？

そんなあなたのために、3大クラウドそれぞれで定期ジョブ実行するためのポイントやそれぞれのサービスの比較を行い、実際にPHPを動かす際のポイントなどをお話します！

対象

・Dockerなどコンテナについてなんとなく聞いたことがあり、ちょっと動かしてみたい人
・サーバレスでコンテナを使った定期ジョブをしたい方
・サーバレスという言葉に惹かれる人

お話すること

・各社のサーバレス コンテナサービスの比較（特徴や料金体系など）
・実際にトライしてみての気づき

マネジメント、大変ですよね。
マネジメントはいわゆるヒト、モノ、カネや事業、チームに関わる抽象度が高い課題を無限になんとかしていく必要があります。

様々な事業や企業がありますが、ヒトと向き合うところだけはあらゆるところで共通だと思います。
このLTでは、あくまで自分がやることになったマネージャーの仕事を少しして、エンジニアリングマネージャーに興味がある人にこんな仕事だよとお話した上で、エンジニアがとにかく戸惑うであろうヒトのマネジメントについて話します。

将来エンジニアリングマネージャーやってみようかな〜だったり、なんかメンバーや上司、部下との関係上手く行かないな〜って人に聞いてもらえると嬉しいです。

勉強会とかカンファレンスに何回か参加しているとそのうち湧き上がってくる感情があると思います。
それは、自分も登壇する側に立ってみたい！

でも、
発表には憧れてるけど、発表することがない。
自分なんかが発表したって誰にも刺さらないでしょ？
発表したいけど発表ネタが浮かばないから、手を挙げられない。

その一方で、いつも登壇してる人がいるし、なんなら勉強会が決まった後にネタなんて考えればいいでしょ？って人もいるんです。
同じようにネタがないのに発表できる人と発表を尻込みしてしまう人、この違いはなんなんでしょうね？

そこで、ネタがなくて発表を尻込みしちゃっていた自分が、発表ネタを見つけるために心がけたことを話します。
同じように発表したいけど話すネタがなくて困ってる方の背中を押せたら嬉しいなと思います。

なんらかの機能の開発者は、機能を作る際になんども同じ動作を繰り返して正しく動くことを検証すると思います。
一方で開発者だけだと見逃してしまう考慮漏れなどに気づくのに有効なのが別な人がその機能を触っての検証です。

開発者も検証者も検証シナリオを考えたり、実行したりする際に、同じような動作を繰り返します。
その機能のユーザーは開発者や検証者よりは長い時間をかけてその機能を利用するはずですが、
同じような操作を何度もするという点ではあまり相違はないと思います。

つまり、開発者や検証者が面倒だな、複雑だなって感じる部分は、その機能を何度も使うユーザーにとっても面倒で複雑なものになる可能性があるのではないかと思っています。
このことを具体的な機能の例で示します。

友達の目に余る行動、恋人に直して欲しいところ・・・
伝えたいことはたくさんあれど、嫌われたくないと思う気持ち。
しかしオブラートに包むとうまく伝わりません。

このようなご経験のある方はCodeReviewer改め、行動Reviewerと呼ぶべきでしょう。
そんな行動Reviewerなみなさまが一体どのように伝えていくと相手に聞き入れてもらえるか、phpを交えながら面白おかしく発表していきます！

私たちが開発しているPHPサーバーは色々な人から受け継がれ秘伝のタレが継ぎ足され続け、よく分からないバグが稀によく起きます。
これまでその解消の武器をいくつもそろえましたが、最近はオブザーバビリティエンジニアリングという武器を使っています。

オブザーバビリティがあるシステムは新しいコードをデプロイせずともデバッグができるシステムです。
OpenTelemetry はそれを実現できる技術の一つですが、PHPで始めるのはいくつかの障壁と意思決定ポイントがあります。
例えば、collectorやbackendといった登場人物の理解、小さく始めるにはどのotel backendを採用すべきか、計装ライブラリは何を使うべきか、どこに仕込むべきかがあります。

私たちはオブザーバビリティエンジニアリングを実践すべく、OpenTelemetryを導入しました。
しかし満足のいくようなアプリケーションのトレーシングとメトリクスを出すまでに色々な失敗を繰り返しました。
このトークではOpenTelemetryを既存サービスに導入するにあたってどのような選択肢があるかを紹介し、どの選択をした結果どのような失敗をしたかをお話しし、PHPでの計装の事例紹介をしたいです。

public subnet のロードバランサーで受けて、private subnet のアプリケーションで処理して、storage subnet のデータベースに保存する。
これが、自分がこれまで「信仰」していた、クラウドの構成概要でした。

が、最近とある方に、自分にとって Breaking Change な発想を提案されました。"public subnet に全部置いちゃう" というスタイル。
セキュリティグループで通信制御すれば、いいんじゃない？トノコト。

あるコミュニティで話を聞いてみるとわりと既にこのスタイルだったり、実際に NAT Gateway 要らずでコスト効率最高だったり、意外にアリなんだなと思いました。

本トークでは、この角度を実現した２つの事例をご紹介します。

• 3層構成FargateをIaCでコスト最適化構成に"1週末"で作り直した
• 1台のEC2で稼働していた小規模なサービスのネットワークをダウンタイムなしで再編した