私が現在開発に携わっている販売管理サービス「楽楽販売」は誕生して15年以上経つプロダクトです。
フロントエンドにフレームワークは利用しておらず、長年にわたり静的に生成されるHTMLの画面部品コードがコピペされ続けており、共通化が行われていない状況に陥っています。
その結果コピペコードは新画面を作成するたびに増殖していき、PhpStormが親の仇の如く「Duplicated Code」を指摘してきます。

この課題を解消するため、私たちは以下の2つの目標を重視し「画面部品のUIコンポーネント化」に取り組みました。
　・新しい画面を作成する際に、コピペする必要がない環境を構築する
　・画面の構成パーツに何があるのかを容易に把握できる仕組みを作る

ゴールは以下２点です。
・複数画面から共通利用可能なUIコンポーネントを作成する
・将来的なコピペを駆逐すること

本セッションでは、取り組みの背景の課題から具体的な解決策、さらに実践例までを詳しくご紹介します。

■お話しすること
　・なぜUIコンポーネント化が必要か
　・どのようにコンポーネント化を進めたか
　・コンポーネント部品を活用してもらうための施策

■想定する視聴者
　・技術負債を解消したい人
　・フロントエンドのフレームワークを利用していない人
　・画面部品のUIコンポーネント化に興味がある人
　・レガシープロダクトから脱却したい人

PHPは1994年に誕生し、現在でも多くのプロジェクトで活用されている歴史ある言語です。
そんな長い歴史を持つPHPには、これまでに多くの「奇妙な歴史的経緯」が存在します。
本セッションでは「PHPマニュアル 日本語版」に記述される「歴史的経緯」について5分で紐解き、その背景を紹介します。

歴史的経緯を知ることは、PHPに対する理解を深め、より良いコードを書ける手助けになるかもしれません。
皆さんはいくつの「歴史的経緯」を知っていますか？

開発をしているときにコメントがあると助かりますよね。
「なるほど、ここはそういう処理をしてるのか！」と、コードの中身を詳しく読まなくとも実装を進めることができます。
しかし、時としてコメントは嘘をつき、あなたを陥れます。
特に古いシステムではこれまでに蓄積され、忘れられ、熟成されたコメントが至るところに散りばめられています。

私が以前開発に関わっていたメール共有サービス「メールディーラー」はリリースから20年以上経過しているサービスであり、熟成されたコメントが多数存在します。
このLTでは私が実際に遭遇したレガシーコードに潜む奇妙なコメントをご紹介し、コメントを盲信することが如何に危険なことであるかを知っていただきます。

コメントを信じるか信じないかはあなた次第です！

※PHPカンファレンス関西2024で発表した内容と同じものです

OpenAPIはAPIの仕様を記述するための仕様で、リクエストやレスポンスの詳細をYAMLまたはJSON形式で記述することができます。これを採用すると、記載内容を統一できる、バージョン管理しやすいなど様々なメリットがあります。
しかし、単なる仕様書と考えていると、徐々に実装との乖離が生まれてしまうリスクがあります。

これを防ぐための仕組みとして、OpenAPIドキュメントを使ってコードを生成したり、実行時に検査をする手法があります。
本セッションでは、Slimフレームワークを採用したシステムにOpenAPIドキュメントを用いたバリデーションとテストを導入した実例をご紹介します。
具体的には以下のような内容を含みます。

• OpenAPIを導入する際のポイントと注意点
• 具体的な実装方法 (league/openapi-psr7-validator)
• 導入の効果と進め方の反省点

Slim以外のフレームワークをお使いの方にも役立つセッションになるはずです。

PHPUnitのデータプロバイダーは、1つのテストメソッドを引数を変えて実行する「パラメタライズドテスト」を実現する仕組みです。
PHPUnit 10以降ではアトリビュートを使って実装しますが、そのときに使えるアトリビュートは実は4種類もあるのをご存知ですか？

このLTでは、これら4種類のアトリビュートを紹介した上で、私自身がどう使い分けてデータプロバイダーを実装しているのかお話しします。

お話しすること

• データプロバイダーとは何か
• データプロバイダーを使う利点
• PHPUnitにおけるデータプロバイダーの実現方法
• 4種類のアトリビュートの使い分け方の提案

想定する観客

• PHPUnitを使っているがデータプロバイダーを知らない人
• #[DataProvider]/@dataProviderしか使ったことがない人

2,147,483,647
これ何の数字か分かりますか？
そうですね！INTの最大値ですね！

DBを設計していて何となくIDカラムをINT型にしている人、多いのではないでしょうか？
初めのうちはいいのですがサービスの成長と共にレコードが増え、INTの上限値になった場合どうなるのでしょうか？

本セッションでは

• 実際に弊社で起きた事象と対応
• DB設計において気をつけるべき点

をお話できればと思っております！

ソフトウェア開発を行うエンジニアで「『技術的負債』という言葉を知らない」という方は今日においてほとんどいないと思います。その一方で「技術的負債とは何か」を正しく理解し、自信を持って説明できる人はあまり多くないように思います。その相手が非エンジニアであればなおさらです。

また、技術的負債についての理解が不十分なことによる誤解や偏見も散見されます。例えば「技術的負債＝悪」というイメージから無用・無謀なリファクタリングを行ったり、逆に放置しすぎた結果、ビジネスにおけるリスクが表面化してしまうこともあります。

このトークを通じて技術的負債についての理解を深め、技術的負債とどのように向き合えばよいのか、その具体的なアプローチを考えるきっかけにしていただければと思います。

お話しすること

• 技術的負債とはなにか
• 技術的負債はいつ・どうして生まれるのか
• 技術的負債を放置することで発生するビジネス面・技術面でのリスクとは
• 技術的負債を最小限に抑えるいくつかのテクニック
• 技術的負債とどう付き合っていくべきか

現代のソフトウェア開発において、脆弱性への対応は非常に重要な課題です。PHPを使用したウェブアプリケーションにおいても例外ではなく、フレームワークやプログラミング言語、ミドルウェア、OSなど、様々な要素において脆弱性が発見される可能性があります。

このパンフレット記事では、そんな脆弱性情報をどうやって日頃から収集するのか、そしてどのようにして自分のウェブアプリケーションが脆弱性にさらされていないのか確認・検知するのか。
また、実際の対応方法について紹介します。

本記事で記述する内容

• 脆弱性情報の収集方法
• 脆弱性検知の方法
• 検知された脆弱性の対応優先度の決め方
• 実際の対応方法

メンター「力がほしいか、、、？」
私「ほしい！」
メンター「ならばLaravelを写経せよ」
私「？？？」

会社のメンターに実力をつけたいと相談したところ、自分の使っている道具を細部まで知ることによって、誰よりも強くなれると教えられました。
幅広く使ってもらうように作るフレームワークとそのフレームワークを使って作る業務に特化したアプリケーションでは、そもそも作るときの思想が違うのでは？と一度は思った私でしたが、そういう言い訳はやってから言わないといけないと思い、素直に写経を行うことにしました。

そこで写経の際にどのような順番で取り組み、その都度どのようなことを考え、そこで学んだこと、そして写経に意味があったのかどうかという、この挑戦の足跡を伝えていきたいと思います。

様々なサービスがサブスクリプション・SaaS化したことで、企業や開発者の固定支出が増加し始めています。
「サブスク疲れ」というワードは、経営陣からも注目を集めており、もはやサブスクリプションで提供するだけでは選ばれにくい現状が生まれつつあります。

そんな中、サブスクリプションビジネスを成功に導くために意識すべきポイントは何か？
Stripeがサブスクリプションビジネスを運営する企業にヒアリングして集めたデータを元に、
システムの要件として事前に考慮すべき５つのポイントを紹介します。

トピックの例:
・無料トライアルや無料プランは提供すべきか否か？
・どのような料金体系でサービスを提供すべきか？
・売上と解約率の関係、そして解約率を下げるためにやるべきこと、やるべきでないこと

ソフトウェアエンジニアには抽象化の能力が重要と言われます。
では実際に抽象化とはどのような能力なのでしょうか？

実際の事例を交えながら、抽象化を理解し、実務に活かせるようにします。

話すこと

• 抽象化と具体化とは
• 抽象化のメリット
• 現実で身につける抽象化の階層
• 抽象と具象の往復とは
• ソフトウェアと抽象化

話さないこと

• 具体的なソフトウェアの実装における抽象レイヤーの話

概要

ソフトウェア開発は不確実性が高いとされていますが、アウトドアにおける商業ツアーも「大自然」という巨大でコントロール不能な不確実性を相手にゲストに安全に楽しんでもらうための実践知を多数持っています。

このポスターセッションでは、「元ラフティングガイド」という異色の経歴を持つ私が、アウトドアの商業ツアーで日々実践していたリスクマネジメントの手法の具体例と
アジャイルソフトウェア開発で使用される手法の共通点について探求し、そこから見えてきたリスクマネジメントについての見解を発表します。

当日は、会場で参加者の皆さまの経験や現在直面しているリスク、そしてその対処法についてぜひ皆さまの貴重な経験を共有いただければ幸いです。

ポスターの内容

• ソフトウェア開発における不確実性
  • 内的要因：開発チームと技術課題
  • 外的要因：ステークホルダーと外部環境
• アウトドア業界における不確実性
  • 内的要因：ガイドチームと技術課題
  • 外的要因：ゲストと自然環境
• 両者に共通するリスクマネジメントの考え方
  • リスク評価方法と4つの対応方針
  • 各対応の具体例
• まとめ
  • 不確実性と向き合っていく中で大切なこと

皆さん、昨年度はどのように成長しましたか？
そして、今年度はどのような成長を計画していますか？

このトークでは、以下の方を対象に

• キャリアに悩んでいるジュニア層の方
• 「伸び悩んでいる」と感じている中堅の方

私自身が学習の速さにおいて一定の成果を上げてきた経験をもとに、次のような内容をお届けします。

• 短期的に素早くキャッチアップするために実践してきた具体的な方法
• 中期的に無駄なく成果を上げるために意識している戦術
• 長期的に自身の価値を高め続けるために考えている戦略

このトークを通じて、皆さんが自身の成長を加速させるためのヒントを得られることを願っています。

PHPのInterface、使っていますか？

このトークでは

• PHPはある程度読み書きできるが、オブジェクト指向や設計パターンに不安がある
• 「抽象に依存する」という考えがいまいち理解できていない
• Interfaceの使い方がいまいち腑に落ちていない

といった方を対象にサンプルコードをによる実践的な使い方を通して、
その根底にある原理原則を解説し、言語機能としてのInterfaceへの理解を深めると共に

• Interfaceがどのような場面で有用なのか？
• 良いインターフェースとはどんなものか？
• なぜInterfaceのような抽象的なものが必要になるのか？

を解説します

Interface、コワクナイヨ！

PHPUnitは、いわゆる「xUnitファミリー」といわれるソフトウェア群のいち実装であり、
2024年時点で最新版は11と、とても老舗のプロジェクトと言えます。

時代に適応して変わっている部分はあれど、根底にある思想は共有されているはずです。
昔から変わらない？変わった？じゃあ、クイズの時間ですね！！！

このLTを聞いて、明日からPHPUnit 1 (もしくはPHPUnit 11)にちょっとだけ詳しくなりましょう。

学べること

• 明日から、職場でPHPUnit 1を用いたテストコードを書く際にも、少し自信を持って取り組めるようになります

得られるかもしれないこと

• 長く続くソフトウェアプロジェクトの実例から、「本質的で変わっていないこと」「変化に晒され、淘汰されたもの」について思いを馳せる機会になるかもしれません

発表すること

• まず簡単に、PHPUnit1を実行している様子をお見せします
• 機能や設定を紹介して、「1にある」「11にある」「両方にある」の3択クイズをします
• 特にアサーションメソッドの有無について、多く出題されます
• 同一のメソッドに置いて「どちらの挙動か」を問われるものもあります

例えば、何かのテストケースを1つ実装します。 vendor/bin/phpunit で、テストを実行します。
その後に起こることは何でしょうか？
「CLIの入力を解釈して」「設定ファイルを読み込んで」「実行可能なテストケースを列挙して」「実行対象のテストケースを選別して」「実行順序等のオプションがあればそれも考慮し」・・・

「普段は何気なく使っているPHPUnitも、良く考えたら色々なことをしていそうだ」なんて気持ちになりませんか？

PHPUnitを支える仕組みに、イベントシステム(Observerパターン)があります。
例えば https://github.com/sebastianbergmann/phpunit/tree/11.4.0/src/Event/Events を見てください、こんなに色々なイベントが定義されています！
これにより、複雑に要素が絡み合った「テスト実行」の全体の中で、要所要所の拡張性が高く保たれている訳です。

見方を変えると、PHPUnitの管理するイベントに着目することで、テスト実行のライフサイクルの骨子を掴めます。
つまり「イベントを知る」=「FWの思想に触れる」ための手掛かりになるのです。
また、エクステンションと呼ばれる機構を用いて、任意のイベントを利用した機能拡張も可能です。

知っているとPHPUnitとちょっとだけ仲良く慣れるかもしれない、どこかで役に立つかもしれない、
そんな仕組みに触れてみませんか？

記事の内容

1. PHPUnitの持つイベントシステムの仕組み(実装観点での概要)
2. 用意されているイベントの紹介
3. 「Extension」入門・実例の紹介

みなさんPHPStanを使っていますか？ PHPStanはオープンソースで開発されているので誰でもソースコードを読んで仕組みを学ぶことができ、理に適った提案であれば取り入れてもらうこともできます。

ところが静的解析ツールはPHPや標準関数の仕様通りに実装すれば完成すればるというわけでなく、さまざまな考慮事項や現実との折り合い付けかたなどがあります。

本トークでは私がこれまでPHPStanに送信したPull Request(※トークプロポーザル時点で未マージ含め49件)について分類して紹介します。

• 取り入れられた提案
• マージされたPR
• マージされなかった
• マージされたが後にrevertされた提案
• 投げ出してしまって完成していないPR

発表者は電子工作をする訳ではないのですが、書籍『雑に作る』が大好きです！
「下手っぴでもいいから、自分なりに動くものを作るのは楽しいよ」と、ものづくりの初期衝動を思い出させてくれる一冊でした。

部品選びから始めてゼロから作るのが難しくても、 「100均の商品を分解して、中身を見てみよう！」「改造できそうなオモチャのパーツを取り出して使ってみよう！」と
簡単に取り掛かれそうなアドバイスが、とてもたくさん書かれています！

部品も既製品も、安全にさえ気をつければどう使っても良し。分解して特定の機能だけを動かしたり、組み立て直すのも楽しい。
色々なモノが動いている仕組みを、そうやって自分の目と手で理解していくことは大きな学びをもたらすでしょう。
本書ではコレを「テクノロジーを自分のものにする」と表現しています。

同じことをソフトウェアでもやってみたら、絶対に楽しいし力がつきそうですよね！
本トークでは、身近なツールを「分解」して、へっぽこガラクタを作って遊んでみた体験を共有します。

こんな人におすすめ

• 普段使っているツールに「詳しくなる」きっかけを探している
• 設計力や実装力などの地力を向上したい・勉強法を探している
• 何かおもしろソフトウェアを作ってみたいが、発明のアイディアがない!!

こんな話をします

• 分解してみる、ガラクタを作ってみるの楽しさ・学習効果
• 「やってみた」話
  • 最初はどこから読めばいいの？どう進めるの？の紹介
  • PHP製のいくつかのツールを例に、どんな「分解」「再構築」を進めていったか
• この学習方法<遊び>で、身につく力
  • コードリーディングの力
  • エッセンスを理解する、抽象的に捉える力

PHPマニュアルって、マジで、マジでめちゃくちゃ読みやすくないですか？
駆け出しだったときにありがたかったし、なんなら今でも本当に感謝するレベルだし。あの丁寧さのおかげで今の私があります。
そんなわたしですが、2024年、はじめてPHPマニュアルの翻訳作業に貢献することができました・・・！

このトークでは、PHPマニュアル翻訳のOSSコントリビューション物語を通じて、「きっかけの掴み方」や「得られたこと」についてお話しします。

• その機能を知るきっかけになり、自分のためになる
• 「このページの一部を作った」という嬉しさ
• さまざまな貢献の仕方があることを実感する

使うものから、みんなで育てていくものへ。
このトークがあなたの素敵な一歩の後押しになることを目指します！

私たちは、プロダクトコードの中でさまざまなコードをtry-catchで囲み、ばしばしエラーを処理しています。
そしてエラー処理にはさまざまな選択肢があることを知ります。
例外を投げっぱなしにする（そもそもキャッチしない）、例外をキャッチして処理する、あるいは例外をキャッチしてうまく戻り値を定義する、など...です。

これまでプロダクトコードのみでの経験だった私は、OSSのコードを見て、「こんなアプローチもあるんだ」と新たな視点を得ることが多くありました。
特に例外処理に関しては、さまざまな場面での使い方や選択肢を知り、自分の考え方が広がりました。
このトークでは、プロダクトコードを書いていく中で実践的に得た知見と、OSSを通じて新たに学んだ例外処理の手法や考え方を深掘りします。

話すこと

• プロダクトコードにみる"例外処理"の扱い方
• OSSにみる"例外処理"の扱い方
• キャッチしたい場面・したくない場面
• 投げっぱなしにしたい場面・したくない場面
• 最適な選択肢をどう選ぶか