あなたの組織はアジャイルですか！スクラムのフレームワークやXPのプラクティス、スクラムパターンや組織パターンを利用して独自のパターン・ランゲージを構築したりしていますか！！
こう聞かれると、「うちはアジャイルかどうか」を考えたり、あるいは「全然できていないのでは…」「本当のアジャイル教えてよ」なんて少し寂しい想いが湧いてくるかも知れません。
私の身近でも、「私のはアジャイルか」「あなたのはナンチャッテでは」と気を揉む様子が見られる場面があります。

個人的には、「良い事をやろうとしている人は、それだけで自信を持って良いし、幸せでいて欲しい」と思います。自分が取り組んでいることを「まがい物だから」と卑下したり、疑念を抱いて凹んだりして欲しくないのです。
「アジャイルになるぞ」と「アジャイルかどうかは気にしなくて良い」の精神性を両立することが必要だと感じていまず。実際、それは可能なはずです。

私は、独学でアジャイルについて学びを深めたり(コレとかコレとか)、Scrum Allianceの認定研修(CSM、CAL-1)での教育を受ける中で、そして組織の中で考え実践し他者との対話を重ねる中で、「定義や形式に拘り過ぎる必要はない、地に足をついた活動と理想を探求することは矛盾しない」と思うようになりました。

「be agile」へのジャーニーは、一朝一夕で成るものではなく、果てしなく長い終わりのない旅路です。
ましてや、booleanで「である」「ではない」を判断できるものでもないでしょう。

─では、アジャイルを意識して理想に向かい前進しよう！！とする時に、何が大事なのでしょうか。

このトークでは、「アジャイルソフトウェア開発宣言 / 背後にある原則」「XPの価値基準」「スクラムの理論と価値基準」「モダンアジャイルの原則」を改めて眺めてみて、我々が意識すべき「ありたい姿」を探っていきます。
その上で、マインドセットとプラクティスの面で「アジャイルリーダーとして、明日からあなたが取り組めそうなこと」を提言します。

今や、CIを回して静的解析を活用して、コーディング規約の運用は機械で自動化するのが当たり前です！！
カンファレンスや勉強会に参加している皆さんにとっては、きっと「そうだそうだ！」と強く頷いていただける主張なのではないでしょうか。

・・・本当にやれていますか？
現実には、きっとそんな甘くないぜ！と唇を震わせている人もいるのではないでしょうか。
今まで使っていない方法や仕組みを取り入れるのは、心理的な抵抗感や不安も生じますよね。

まずは「ノーコストで入れてみる」という方法をとれないものでしょうか？それが出来れば、導入に向けた障壁が1つ解消しそうです。

このLTでは、実際にそうしたアプローチを実施して、PHP_CodeSnifferを既存プロダクトに導入した際の話＋今後の展望をお話しします。
私の戦略は、「既存コードに影響のないSniffを入れる」「それによって、まずは”CIでスタイルチェックが動いている”状態を作る」「そのために、既存コードの適合状況を機械的に分析する」「自転車置き場の屋根の色の議論を避けるために、トップダウン的にPER Conding Styleをベースにする」「今後の進展のための仕組みを作り、運用・展開を移譲する」などを組み合わせたものでした。

この手立てを使って、「何年もスタイルチェッカーを入れたい声はあったが実現されていなかった、10年以上の歴史を持つプロダクトコード」に対して、今ではCIによるチェックが稼働しています！

PHPにはプリロード(Preload)があります！！パフォーマンスが上がります！
・・・噂は聞いたことがある・存在は知っていても、実際に使ったことはありますか？
何となく難しそうだなぁ。。複雑な事をしなければいけないそう。。そんな風に、遠い存在に感じている人も多いのではないでしょうか

ayesh/composer-preload というパッケージがあります。
see: Packagist

これはComposer Pluginです。
READMEを見ると Composer Preload is a composer plugin aiming to provide and complement PHP opcache warming. と記述されています。
正に「プリロードを気軽に使ってみよう」を支援するツールであり、私達にとってプリロードを「遠い存在」から「身近な存在」に近づけてくれる可能性があります。

どんなアイディアでそれを実現し、どんな仕組みになっているのでしょうか？
簡単に内部に触れてみましょう。
それによって、「プリロード完全に理解した！」という人を増やすLTになります。

私は、学生時代に地方の大学で技術コミュニティー（サークル）の運営に取り組んできたので、地方大学のコミュニティーについてお話ししたいと思います。

私は新卒のエンジニアですが、昨年まで地方の大学で技術コミュニティの運営に取り組んできました。私が大学生の頃、2019年12月からコロナが流行し、大学はリモート授業になり、サークル活動も対面で行うことが難しくなりました。また、「地方のITコミュニティー」と「大学のサークル」では特性が異なりオンライン化に伴い、それぞれのコミュニティーで苦戦したことがあると思います。

このような環境の中で行ったことや、苦戦したことや上手くいかなかったことについて発表します。また、「大学生のコミュニティー特有の課題」や「地方大学のコミュニティーの課題」についてもお話ししたいと思います。

「学生で参加される方」や「学生コミュニティーに携わっている方」に少しでも多くのことが共有できればと思っています。

Google Apps Script（以下、GAS）とは Google が提供するローコードプラットフォームです。

普段 JavaScript を書くのほぼ同じ感覚でコードを書いて実行できますが、単なる JavaScript 実行環境にとどまらず Google の提供する各種サービス（スプレッドシートやフォーム等）との連携を容易に行えたり、動的な Web ページを表示できたりと、まさに「ローコードプラットフォーム」と呼ぶにふさわしい機能を備えています。

何が正解かわからないビジネスの世界において、誤った方向性でプロダクトを作り込んでしまうことを避けたいもの。
そのためにコストをかけずにプロトタイプを作って仮説を検証するのですが、GAS の備える特性はそのサイクルを回す際に強力な助けとなります。

本トークでは、そんな仮説検証を回すため知っておくと役に立つ

• GAS でできること
• GAS を使うときのコツ、Tips
• GAS の限界、使うべきでないところ

についてお話します。

フロントエンドやバックエンドのような技術的関心事で担当領域を区切るのではなく、プロダクトが価値を提供するために技術面全般へ責任を持つ「フルサイクルエンジニア (full-cycle developer)」という考え方があります。

本トークでは、フルサイクルエンジニアという働き方についての説明と、私がフルサイクル開発者として5年ほど仕事をしてきた中で「良い仕事」をするために意識していることをご紹介します。

対象観客

• フルサイクルエンジニアという考え方に関心があるかた
• フロントエンド/バックエンド/インフラだけを専門的にやっているがこれで良いのか？という悩みを抱えているかた
• プロダクトについてもっと責任を持ちたいと考えているかた

話すこと

• フルサイクルエンジニアとは何か
• フルスタックエンジニアとの違い
• 専門性についての懸念
• どうあれば「良い仕事」と言えるのか
• 「良かった」とフィードバックを貰えた仕事例

コロナ禍をきっかけとして、テレワークを導入した企業は珍しくないでしょう。
もともとソフトウェアエンジニアにとってテレワークは相性が良い部分もあったことから、様々な利点をもたらしてくれました。
その一方で、良いことずくめに思えたテレワークも、新たな問題をもたらしたこともまた事実でした。

従業員どうしの関係性や勉強会等の活発さといった文化をひとつの強みとしていたエンジニア組織は、テレワーク導入直後にはその強みがほとんど見えなくなっていました。
もともと組織には「開発組織活性チーム」というチームが存在しており、テレワーク導入による問題が無視できなくなってきた頃、「失われつつある組織文化を取り戻し、維持すること」を新たなミッションに掲げて活動内容を変化させました。

本トークではそこからおよそ 2 年にわたる「開発組織活性チーム」の取り組み内容と、それによって実現できたこと、できなかったことおよびそれらの考察をお話します。

スキーマ駆動開発を行っていくと実装とスキーマが乖離してしまい辛いという話をよく聞きます。

スキーマ定義自体はOpenAPIを利用するケースが多いと思いますが、OpenAPIはエコシステムが充実しているが故にツールの組合せだったり、APIを作成する際の開発手順は様々だと思います。
本セッションでは如何にキーマ定義と実装に乖離が発生しない・させない様に開発フローにまで踏み込んで実現させた事例を紹介したいと思います。

トークの狙い

• スキーマ定義をどの様に扱い開発フローに組み込むと良いか？を理解できる
• 利用するツールとそのテクニックに触れることができる

今年 3 月に開催された PHPerKaigi 2023 にて「いろいろなフレームワークの仕組みを index.php から読み解こう」と題して 4 つの Web アプリケーションフレームワークの共通点から、（PHP の）Web アプリケーションフレームワークと呼ばれるものがどうやって動作するのか、一般に何の役割を担っているのか、というお話をしました（https://fortee.jp/phperkaigi-2023/proposal/e68c1ed6-8fb4-4ff9-9d99-99214d9dba8d）。

ならば今度は「共通点」ではなく「差異」に着目し、各フレームワークが提供しようとしている価値や設計思想の違いについて比較、考察した結果をお話します。
今回は index.php にとどまらず、フレームワークが備える機能やエコシステム、公式ドキュメント等も比較の材料として扱います。

本トークで扱うフレームワークは以下の通りです。

• CakePHP
• Laravel
• Slim
• Symfony

AWS上で構築したWebアプリケーションを開発したとき、PHPをメインに使っていてもフロントエンドから amplify を使って直接サーバーリソースにアクセスすることもあるでしょう。

これまで長らく使われてきた aws-sdk-js（以降 aws-sdk）は v2 から v3 となり、モジュール別のパッケージとして展開されるようになりました。

私も担当しているプロジェクトではサーバーサイド、クライアントサイド共に TypeScript を使っていますが、 aws-sdk v2 が本年中にメンテナンスモードに入ることから v3 への移行作業を行なっています。

そこで蓄積された v3 移行のナレッジや、ハマりポイントなど、v3 移行の現場から生の声を稲妻トークでお届けします。

家を買うべきか、買わないべきか。
買うとしたらマンションか、戸建てか。
勤続年数が浅かったりフリーランスだと住宅ローンの審査が通りにくいという話は本当か。

家の購入って分からないことが多すぎて無限に悩みますよね。

本トークでは、家を購入するに当たって自分自身が調べたことや不動産屋に相談したことからの学びをご紹介します。

対象観客

• 家を買うか買わないかで迷っている
• 転職・独立を考えていて、住宅ローンが組めなくなるのか不安
• 家を買おうと思っているが何を気にするべきか、いくら現金を用意する必要があるか知りたい

話すこと

• 家を買うべきか、買うべきでないか
• 物件を選ぶときに考慮するべきポイント
• 家を購入するのに必要なお金
• 住宅ローンうんちく (金利、返済方法、借りやすい金融機関)

Google App Engine はリリース当初の2009年よりPHPをサポートするPaaS基盤です。
第一世代と呼ばれる言語仕様に制限のあった状態で PHP5.5 のサポートが行われてきました。
その後言語アップデートに関しては無料枠のあるスタンダードエディションから、有料で利用できるFlexエディションで実施されるようになり、次第にGAEの注目度は下がっていたように思います。

しかし2018年、GAEはgVisorベースの第二世代によってPHP7.2をサポートするようになり、それ以来最新の言語バージョンに追従するようになりました。

このセッションでは、GAEをご存知でない方や、第二世代のGAEを利用したことがない方に向けて、PHPアプリケーションをGAEのスタンダードエディション第二世代を動かすための概要やメリットを紹介します。

また、私も第一世代よりGAEを使って長年個人サービスを運営していますが、このたび2024/1/30をもって第一世代および第二世代のPHP7系ランタイムサポートが終了されるアナウンスがありました。
これにより私の第一世代で運用しているPHP5.5アプリケーションも一気にPHP8.1へジャンプアップする必要性も生じています。
こちらの移行の最新状況や、どのように移行しているかも含めた、GAEに興味がある/使っている人に向けたセッションになります。

テストコードの書き方について説明する資料等は世の中に充実しつつあります。
一方で具体的にテストコードを書いていく様子を説明、実演する資料というのはまだ数が限られています。

そこで今回はソフトウェアテストの領域でよく題材とされる「マイヤーズの三角形問題」の実装を取り上げ、
素朴な PHP コードからはじまり、テストコードを補いながら、ときにつまづきつつ、解くべき問題を捉えたコードへと洗練させていく過程を実演します。

本セッションで扱うテーマ

• テストファーストなアプローチによるコーディング、リファクタリング
• PHPUnit の基本的な使用法と data provider の活用

本セッションで扱わないテーマ

• テスト戦略やテスト設計について

（PHPerKaigi 2023でパンフレットに寄稿させてもらった https://fortee.jp/phperkaigi-2023/proposal/caec413f-384d-415e-8020-59053058a1f6 のトーク版です）

今ではオープンソースソフトウェア（OSS）を使うことは当たり前になっています。このことに異論を挟む人はいないでしょう。

ところで、「OSSへのコントリビュートをするのは敷居が高い」「OSSを作るのはなかなか難しい」とよく聞きます。
確かにそれもOSSの1つの側面かもしれません。

そこで提案です。趣味としてOSSを書くのはどうでしょう？
実はOSSは趣味で書くのもアリなのです。
皆さんの中にも「プログラムが好き」「プロダクトが好き」「モノづくりが好き」という方は少なくないはずです。
そんなあなたは趣味OSSの素質ありです。

筆者は「少し実用的で小さなOSSを書くのが趣味」と公言しています。
あくまで「いち趣味の紹介」としてOSS開発のはじめかたをお伝えできればと思います。

そして、オフライン発表だからこそできる、私の積みOSS（ネタ帳）を全てお見せします！
これは発表資料には含めない予定なのでその場限りの公開になるかもしれませんよ。

PHPのDockerfile、秘伝のタレとなっていませんか？なんとなくのコピペになっていませんか？特定の人だけが触っていませんか？

【この発表のゴールについて】
Dockerfileの書き方を解説し、効率的なPHPのDocker環境を構築を迷いなくできるようになることを目指します。

【発表内容】
PHP8.2の実行環境を構築するということを前提に、以下の内容に触れます。

1. Dockerfileのお作法:
   Dockerfileの機能をおさらいしながら、最新の書き方が出来るよう解説します。

2. ベースイメージの選定方法:
   DockerHubにて公開されている公式PHPイメージにはいくつかの種類があり、タグ付けされています。(例えば8.2.4-alpine, 8.2.4-apache,8.2.4-fpm,8.2.4-cliなど) それらの違いを理解した上で適切なベースイメージを選べるように解説します。

3. PHPの各種拡張機能について:
   公式のPHPDockerイメージだけではアプリケーション開発は難しいです。拡張機能やパッケージを追加する必要があります。公式のPHPDockerfileを読み解きながら、何があり、何が追加で必要なのかを解説します。

【対象者】

• 自信をもってDockerfileをかけるようになりたい人
• PHPの拡張機能について理解を深めて行きたい人

【触れないこと・想定しないこと】

• Docker、Docker composeの詳細な説明やそのメリット・デメリットについて

Github Actionsでworkflowを作成してCI/CDされている方も多いのではないでしょうか？
本セッションでは2022年にリリースされたカスタムアクションで開発者体験が良かったものを紹介したいと思います。
実際にプロジェクトに導入して習慣が変わっていった体験談にも触れたいと思います。
関連してworkflowの作成時のtipsもいくつか紹介したいと思います。

みなさんはこういった経験が無いでしょうか。

「PHPStanのレベル5まで対応完了！よしっ！」
「つづいて、レベル6っと、ッターン！」

Method xxx() return type has no value type specified in iterable type array.

「ふぁっ！？」

、、、はい。あると思います。
そんなときはArray shapesなりで、ひーひー言いながら対応すると思いますが、泣きながらこう思った人も少なからずいるのではないでしょうか？

「PHPStanはLevel6で何を見ているのだろう」と。

今回のトークでは、そういった疑問をソースコードリーディングを交えながら、みなさんと一緒に解き明かそうと思います。
PHPStanが見ている世界を知ることができれば、PHPStan(ひいては静的解析ツール)ともっと仲良くなれるはず！

■ 話すこと

• PHPStanのレベル6について
• レベル5とレベル6での解析方法の違い
• 字句解析, 構文解析, 評価 について少し

■ ターゲット

• PHPStanの対応(特にレベル6)で苦労したことがある人
• PHPStan(静的解析ツール)と仲良くなりたい人

みなさんはこういった経験が無いでしょうか。

「PHPStanのレベル5まで対応完了！よしっ！」
「つづいて、レベル6っと、ッターン！」

Method xxx() return type has no value type specified in iterable type array.

「ふぁっ！？」

、、、はい。あると思います。
そんなときはArray shapesなりで、ひーひー言いながら対応すると思いますが、泣きながらこう思った人も少なからずいるのではないでしょうか？

「PHPStanはLevel6で何を見ているのだろう」と。

今回のトークでは、そういった疑問をソースコードリーディングを交えながら、みなさんと一緒に解き明かそうと思います。
PHPStanが見ている世界を知ることができれば、PHPStan(ひいては静的解析ツール)ともっと仲良くなれるはず！

■ 話すこと

• PHPStanのレベル6について
• レベル5とレベル6での解析方法の違い
• 字句解析, 構文解析, 評価 について少し

■ ターゲット

• PHPStanの対応(特にレベル6)で苦労したことがある人
• PHPStan(静的解析ツール)と仲良くなりたい人

リアルタイムOSとは特定の事象が発生してから、決められた時間内に処理を実行できるシステムを構築するためのOSです。
多くの場合、組込みシステムで用いられていて、例えば自動車や飛行機、産業制御装置などのシステムに利用されます。

リアルタイムOSには以下のような特徴があります。

・複数の実行コンテキスト(タスク)を持つことができる
・タスクには優先順位を設定でき、優先順位の低いタスクに割り込む形で、優先順位の高いタスクを実行できる
・タスク間でメッセージをやり取りしたり、リソースを排他制御する仕組みがある

本トークではリアルタイムOSの一つであるAmazon FreeRTOSを題材に、タスクの動作や各機能の活用方法、リアルタイムシステムの設計方法についてお話します。

このトークでは、技術同人誌を知らない人や初めて執筆する人に向けて、技術同人誌を頒布するまでのステップを説明します。多くの人が執筆に興味を持ちながら、何から始めれば良いのかわからなかったり、完成までの道のりが遠そうだと感じて二の足を踏んでいたりするかもしれません。

実際には、技術同人誌を製作するのはそこまで難しくはありません。各種ツールを活用することで、つまづきポイントを回避しながら書籍を製作することができます。

私自身、これまでいくつかの技術同人誌を頒布してきました。技術記事を書くことや技術イベントに登壇することとは違った魅力があるため、同じ技術発信でも技術同人誌を作ることをおすすめします。完成した紙の本を手にしたときのワクワク感は、何度でも味わいたいと思えるほどです。

技術同人誌は、書きたいと思ったときに書き始めるべきです。このトークを聞いて、ぜひあなただけの技術同人誌を製作しましょう。