マネーフォワードでは、各サービスが1つの大きなDBに依存している状態を抜け出し、各サービスごとに別々のDBを持つように再構築していくプロジェクト（桃園脱却プロジェクト）が進行しています。
桃園脱却プロジェクトにおいて、私が担当した業務の1つに、Money Forward クラウド経費の会計データ参照の分離がありました。この対応では、サービスの停止やビッグバンリリースをすることなく、共通DBへの依存を切り離せました。
本登壇では、この分離の進め方や採用した技術・手法についてお話します。

話す内容
・桃園脱却とは？
・featureフラグを活用したリリース
・Rubyを使っているMoney Forward クラウド経費上でgRPCを使用した会計データの参照手法
・リモート環境下での、複数人の開発者で分離を進めるためのissueの切り方やコミュニケーション
・コードを書かない選択肢

アジャイルのプラクティスにプランニングポーカーというものがあります。
タスクのストーリーポイントをみんなで見積り、今までのスプリント履歴からベロシティを計算し、今回のスプリントで行う作業を決める。スプリントが終わるときれいにタスクが完了し、デリバリー出来ている。。。本当にそんなにうまく運用できていますか？？
でも、不確実性コーンというものがあって、初期のソフトウェア見積りは、4倍から1/4倍まで工数がブレてしまって信用度が低い。。。本当でしょうか？？
実はよく知られていない不確実性コーンの歴史を紐解き、現代の統計データからどれほどソフトウェア見積りが可能になっているのか？
古典的ソフトウェア見積りを再考した調査結果を発表いたします。

このトークについて

皆さんはPHPのDockerfileを書かれておりますでしょうか。プロジェクトに一人、Dockerfile職人がいらっしゃいませんか？PHPのDockerfileはいろいろな書き方があり、秘伝のタレになっていませんか？秘伝のタレを脱して、自信を持ってかけるようになりたくないですか？

話すこと

• Dockerfileの基本的なコマンドのおさらい
• PHP公式Dockerfile(8.3, Apache系)は何をしていて、何をしていないのか
• プロジェクトにおいて考慮すべき項目について
• 拡張モジュールのインストール方法

対象者

• PHPのDockerfileのコピペを脱出したい人
• 意図してDockerfileをかけるようになりたい人

PHPに限らず、プログラムは繰り返しても劣化しない正確さと速さが持ち味です。人間は繰り返すと集中力が落ち、集中力が落ちると正確さと速さが劣化しがちですよね。
私は素早く開発することを突き詰めた結果、定型的なPHPコードは自分で書くよりPHPに書かせた方が早いと考えるに至り、さまざまなコード自動生成を日々試しています。
まだまだ実験途上の試みではありますが、私がどういう不便を解消したいと考えているのか、その不便を解消するために使っているツールのアップデートの履歴、PHPカンファレンス福岡当日までの成果を発表したいと思います。

私は学生時代から個人開発をはじめ、社会人エンジニアとなった今でも個人でWebサービスを開発・運用し続けています。

その中で一際思い入れが深いサービスが「National Economy Online」です。当時はコロナ禍がちょうど始まった頃で、物理的な交流や遊びができなくなってしまい退屈な生活を送っていました。ボードゲームが趣味の友人とリモートでも楽しく過ごすため、「ナショナルエコノミー」というボードゲームがオンラインで遊べるものを開発しました。今では友人だけでなく多くのユーザーに何千回と遊んでもらっています。

個人開発を通して習得できる技術や審美眼、また実際にPHPでボードゲームが遊べるWebサービスを作る際のテクニックについてご紹介します。

cf.) https://speakerdeck.com/arthur1/hatena-engineer-seminar-number-28

技術選定で「何を選べばいいかわからない」「何が適切なのかわからない」など悩む方も多いのではないでしょうか。私自身もたくさん悩んできました。
一介のエンジニアとして開発に携わった経験，エンジニアリングマネージャーやテックリード，CTO 経験など多くの屍を超えて辿り着いた結論は「答えがない」です。それは，事業のフェーズ，ビジネスモデル，既存プロダクトの状態や既存のエンジニア組織の性格など技術選定において必要なパラメータが多岐に渡るためです。
それでも，技術選定を進めなければプロダクト開発はもちろんのこと，圧倒的な事業への成長に貢献できません。
では，ハードシングスを必要とするようなシーンの技術選定は，どのように行っていけばよいのでしょうか。
本トークでは，どういう視点で技術選定を行えばよいのかを皮切りに，様々な事業の状況を仮定しながら最適な技術選定に近づけるためのノウハウについてお話します。

アプリケーション開発で、単に要求に答えるための開発をするだけでなく、
データ分析に関する知識や幅広いドメイン知識が必要となる機会も多いのではないでしょうか？
このセッションではドメインイベントの理解がアプリケーション開発において中心的な役割を果たすかを探求します。

この概念を踏まえることで、分析の段階から境界づけられたコンテキストを明確にし、
如何にデータ分析設計やシステムアーキテクチャの進化に寄与するかを解説します。

このセッションでドメインイベントを中心とした考え方を得ることで、
柔軟なシステム設計・ドメイン理解のための洞察力を養い、
ビジネス要件の迅速な変更に対応し、継続的な成長と進化を実現するアプリケーションの開発が可能になるかもしれません。
発表では具体的な事例とともに、ドメインイベント中心の技術がもたらす可能性についても深く掘り下げていきます。

配列は、柔軟なデータ構造で便利である一方、使い方を間違えるとしばしば不具合の原因となります。

配列は==や===を使って比較することができますが、例えば ['a' => 'aaa', 'b' => 'bbb'] と ['b' => 'bbb', 'a' => 'aaa'] の比較では、 == ではtrueに、===ではfalseになります。

このトークでは、PHPが配列の等しさをどう扱っているのかをphp-srcを読み解きながら深掘りしていきます。

わたしは、かつてPHPカンファレンスやRubyKaigiなどで技術発表を行ってきましたが、近年ではこのカンファレンスのスポンサーも務めているピクシブという事業会社全体の制度作りの一翼を担ってきました。
ジョブチェンジをしたわけではなく、ソフトウェアエンジニア及びその分野のマネジメントの経験から設計スキルを武器として活用しています。

このセッションでは、わたしが実際に行った取り組みをもとに、それらの背景、思考プロセスを紹介し、今後のキャリア選択のフロンティアとしての発展像を示します。

なお取り上げる事例は以下を想定しています。
https://inside.pixiv.blog/2022/10/31/140000
https://inside.pixiv.blog/2023/02/22/115500
https://inside.pixiv.blog/2023/11/28/130000

Webサービスの開発運用においてセキュリティは一つの重要なテーマです。CSP(Content Security Policy)はwebの標準仕様であり、クロスサイトスクリプティングやデータインジェクション攻撃などのような特定の種類の攻撃を検知し、影響を軽減するために追加できるセキュリティレイヤーです。しかし実際にこれをサービスに導入し運用をしているという事例をまだ多くは聞きません。

発表者が所属する組織においてもセキュリティ対策の一環でCSPを導入しプロダクト運用に組み込んでいます。どういった意図で導入し何が発生してそこからどういったことを学んだか、一つの事例として発表を通じて共有したいと思います。

[想定オーディエンス]

• これからCSPについて知りたいと思った方
• CSPの導入を検討しているおり、導入事例に興味関心がある方
• Webサービスの他社運用事例一般に興味関心がある方

どんなに綺麗な仕様書を書いても、コードから離れては生きられない（メンテナンスされず陳腐化して活用されない）。
そんな思いからスキーマ駆動開発でのコードとスキーマの乖離をさせないという理想を追い求めて辿り着いた開発プロセスを紹介したいと思います。
スキーマ駆動開発での悩みポイントにフォーカスし、なぜ今回のプロセスを採用しようと判断したのか？
また段階的にプロセス見直し最終的には他プロジェクトにも適用可能なcomposer化を目指したのか？についてお話します。

クリーンアーキテクチャの同心円で、一番外側にあるデータベース。ドメインのコードはデータベースに依存させないように書きましょうと言われがちです。しかし、果たしてデータベースは本当に常にドメインの外側に置くべきなのでしょうか？
リンケージではLaravelとDoctrineORMを組み合わせてドメインのコードとフレームワークの距離を保ちつつ開発していますが、ドメインとデータベースとの距離については議論がありました。
Doctrineという技術選定、ドメインのコードからORMへの依存を許す決断をした根拠についてお話します。

みなさんは GraphQL を利用したことはありますか?
GraphQL の利点として、クライアントが必要とするデータを API に 過不足なく伝達して取得できる という、 従来の REST API では実現が難しい機能 を実現できます。

GraphQL は さまざまな言語やフレームワークでサポート されており、 PHP でも利用できます。
さらに、 Laravel では、簡易的な API サーバーであれば容易に実装が可能です。

本トークでは、 GraphQL の基礎と、 Laravel で GraphQL サーバーを実装する方法を紹介します。
また、実際に Laravel で GraphQL を利用した事例についてもお話しします。

一緒に GraphQL の基礎を学んで、 GraphQL の便利さを体感してみませんか?

AWS Lambdaは、公式ランタイムにPHP対応はありません。
ですが、Matthieu Napoliさんが開発しているBref(ブレフ)を使うことで、PHPを使えるようになります。

このプロポーザルをご覧になっている、カンファレンス支援システムであるfortee(フォルテ)。
PHPerKaigiやiOSDCを主宰している長谷川さん(@tomzoh)が開発しはじめたCakePHPベースのアプリケーションです。
様々な機能があり、数年の歴史が積み重なったアプリケーションであるforteeを、AWS Lambdaと他AWSサービスと組み合わせてデプロイしてみます。

成功するのか？すんなりデプロイできるのか？
失敗するのか？AWS Lambda用に変更対応が必要なのか？
費用はどの程度になるのか？
forteeデプロイで得られたAWS Lambda/Brefの知見をご紹介します。

フルスタックウェブフレームワークであるPHP(独自見解)には、他言語とはことなり、Version 4からはセッションが標準拡張として搭載されています(拡張なんですよ、知ってました？)。便利ですよね、$_SESSION。

しかしPHPのセッションは様々な罠も多く、Easyではありますが、Simpleではない、安易に頼るとしんどい時もあります(個人の主観)。

今回、PHPのセッションのPros/Cons、アンチパターン、避けてみる話やセッションのマイグレーションの話をできればと思います。

エンジニア組織において、「いかに組織全体で学びの機会を増やすか？」というのは至上命題かと思います。
私はこれまで本業では3社を経験し、その3社ではいずれも「組織の学び盛んにすること」を掲げていましたが、
1,2社目では主体的に勉強会の枠組み作りに関わっていましたがうまくいかず、3社目でようやく組織全体に学びの意識が浸透している状況に遭遇しました。

そこで本セッションでは、私の失敗経験と学びがうまく行っている組織を対比しながら、

• 私の失敗談
• "うまくいっている"社内勉強会とはどういう状態なのか？
• 失敗談から学んだ、社内勉強会づくりにあたってのアンチパターン
• 社内勉強会を定着させるために必要な土壌とは？

といった内容をお話しできればと思います。

「良いコード」を目指す為の様々な概念が提唱されています
それらを測定し成功に近づける為の尺度も、色々と開発されています

例えば「凝集(度)」。
"触れた事がある"、"聞き覚えはある"という人は多いでしょう
”前に学んだ”という人も、定義と計算方法を覚えて…から入門すると、堅苦しく難解に感じませんでしたか？(私はyes)

もっと！感覚的に、筋道や意義に触れられたら！怖くないのに！！
その為には！難しく考えない！柔らかく触れ合う！！

大事なのは、定義の暗記ではなく感覚のインストール
凝集度とその測定方式である「LCOM」について、視覚や実例を駆使し、直感的に掴んでいくトークです💪
「良いコード」をちょっと説明できるようになりましょう！

話す事

• 図解でざっくり凝集度
• 凝集している・していないと、どうなるの？
• コードを弄って「良くなった・悪くなった」を目にする体験の提供

PHPカンファレンス福岡2023においてセッション枠に名前がありながら、その枠の終了時に会場につくということをやってしまいました。しかし、きしだは寝坊だったのか？真実をお話しします。
という話よりも、そこで話されたかもしれないオブジェクト指向の話に興味がある人が多いんではないでしょうか。
オブジェクト指向という言葉は、だれも定義できず共通認識のないまま、それでも大切な技術だと語られています。けれども、その指しているものは人によって違います。
「そのオブジェクト指向ってどこで説明されていたもの？」と聞いても出典はあやふやになりがちです。
このセッションでは「オブジェクト指向とは継承であり状態管理技術である」という定義をおいて、どのようにオブジェクト指向が発展したか、どのように流行したか、なぜ混乱が生まれたか、なぜ使われなくなったか、そしてオブジェクト指向はどのように使えるのかを解説します。

昨今リアクティブなウェブアプリケーションが当たり前な世界となっています

そのリアクティブなウェブアプリケーションを支える通信技術に踏み込みたいと考えました

今回はPHPを使ってWebSocketサーバーを構築することで、具体的な手順からWebSocketの基本的な理解を深めます

実際に作ったリアクティブなアプリケーションのデモを通じてWebSocketのが生み出す強力なユーザー体験を、
PHPを通じて学びながら、PHPerとフロントエンドエンジニアを繋ぐ理論について共有が行えると幸いです

• お話すること

  • WebSocketサーバーをPHPで構築する手順
  • 構築したWebSocketとブラウザが通信を行うデモ

• 想定聴講者

  • WebSocketを知りたいPHPerとフロントエンドエンジニア
  • WebSocketを作りたいPHPer