トーク

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

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

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

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

このトークの対象

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

フロー効率という言葉を最近耳にしたことはありますか？
その対比としてリソース効率が用いられているのを目にしたことはありませんか？

このトークでは「フロー効率」と「リソース効率」という言葉をキーワードに

1. フロー効率が良くなると何が嬉しいの？
2. リソース効率を追求するとどうなるの？
3. 仕事をする上で２つの効率とどう向き合う？

という３つのテーマを使って、我々開発者を取り巻く環境における事例を交えながら人間にとって最も重要な資源である「時間」について深掘りしていきます。

タイトル見て共感した人、このトークのターゲットです。
データベースにおいてインデックスとは超重要な要素の1つです。
適切にインデックスを貼ることで処理を効率よく行うことができます。
「なんかよく分かんないけどじゃあとりあえず全部にインデックス貼っとくか」
これはアンチパターンです。
何故闇雲にインデックスを貼ってはいけないのか、適切にインデックス貼るとはどういうことか
実際に計測したデータを交えながらお話したいと思います。

長年稼働しているサービスのDBを運用途中からマイグレーション管理した話をします。

PHPでマイグレーションを扱うのに、例えばLaravelのマイグレーションの利用を考えると思います。
複数のサービスアプリケーションで接続しているDB、どのアプリケーションでマイグレーション管理が最適なのかと考えました。

いや、、、サービスアプリケーション側でマイグレーションを持たせず、独立したマイグレーションアプリケーションを立ち上げましょう。

その時に最適だったのがCakePHPが公式に採用しているPhinx。

• Phinxを利用した独立したアプリケーション立ち上げ
• 運用途中からDBマイグレーション管理
• GitHub ActionsとECSを利用したRDS環境へのマイグレーション実行
• 実行テスト・ルール設定・テスト環境にマイグレーション利用など運用アレコレ

について話をします。

これまで20年間にわたりPHPで開発したB向けのクラウドサービスを運営してまいりました。
現在はGMO医療予約技術研究所という会社で医療向けDXサービスを開発・運営しています。
今回は、PHPを利用した大規模クラウドサービス運営に関する工夫やノウハウを凝縮して発表したいと考えております。

＜コンテンツ＞
・アーキテクチャ
　→フレームワークの構成
　→インフラアーキテクチャ
　→セキュリティ対策
・キャパシティ管理
　→WEBサーバとメモリの関係、メモリの節約テクニック
　→転送量の対策（WEBブラウザ上のメモリや処理効率対策）
・エラー検知
　→プロセス実行時間や例外の監視と通知
・マインドセット
　→「トラブル時の解決速度」にフォーカス
　→ソースコードはラブレター

私たちのチームでは、サービスのメトリクス監視やパフォーマンス可視化に New Relic を活用しています。
また、開発プロセスの改善や活動量からエンジニアを評価出来る環境作りのために、開発チームのパフォーマンスをNew Relicで可視化、活用しています。
最近では、AIを用いたツールやサービスを使用することで、チームの生産性がどう向上したかを測る指標も追加しました。

本トークでは、サービスのパフォーマンス可視化だけではなく、開発チームのパフォーマンス可視化も行えるNew Relicについて、弊社の活用事例を紹介します。
サービスや開発組織のパフォーマンスの可視化に興味のある方におすすめのトークです！

複数のプロダクトやサービス事業を展開している企業で一度は言われる「共通基盤を作りたい」。
近年、エンジニア側も「よし、共通基盤だ！マイクロサービスを作ろう」と安易に呼応してしまうことがでてきました。このように始まったマイクロサービス開発では、往々にして失敗したマイクロサービスが負債として残り、エンジニアチームは「マイクロサービスはダメだ」という感想を持ってしまいがちです。

「共通基盤だ！」と言い出したとき、本当にマイクロサービスが必要だったのでしょうか？
前職で数年にわたってマイクロサービスを開発・運用し、PHPerKaigiでマイクロサービスを布教したこともある私ですが、現職では「共通基盤だ！」にNOを突きつけています。
共通基盤というマイクロサービスがほしくなる動機を解きほぐし、マイクロサービス採否ジャッジの基準、ニーズをマイクロサービス以外の方法で満たす方法についてもお話しします。

私見ですが、年金は破綻はしないけど、ここに老後を頼れないですよね。一方健康寿命はこれからの20年で10年延びる予想があります。
そして投資で増やしたり、貯金をためても、よほどの金額がないと、くつぶしていく可能性があります。
やはり必要なのは中高年になっても副業や起業で稼げる方法ではないかと思うのです。

もちろんエンジニアの方で技術力があれば食べていけると思うのですが、今と同じ見積方法で工数を見積もったり、時間給で金額をいただくのは、契約が途切れるきっかけが多く、常に営業行為が必要になることが多いです。安定した収入を得るためには、極論、営業をしないで稼げる方法が好ましいと考えています。（ネットワークビジネスの話じゃないですよ！）

そこでこのセッションではエンジニア向けに安定した副業や起業で収入を得られる考え方と私自身が成功した実例を解説したいと考えています。

Tests as Documentation！皆さん、テスト書いてますか！書くより読む時間の方が長いですよね、きっと！

どうしたら、読みやすいテストコードになるか…？は、他人の時間を尊重する上で大事なことです
どうしたら、テストコードを思いつきやすくなるか…？は、自分の時間を尊重する上で大事なことです
両者を勝ち得るために、「ユニットテストのコードを書くための引き出し」を増やしておきましょう！

xUnit Test Patternsで紹介されているパターンの中から「理解容易性」「自己文書化」に関連が深いものを取り上げたり
自身の経験を踏まえたりしながら
テストコードを書く際の観点・tipsを紹介するトークです

しない話

• テストの保守性の上げ方
• テストしやすいコードの書き方

こんな人向け

• ユニットテストを書くようにはなったが、まだ難しく感じる場面が多い人

去る 2023-07-10、Brefの作者である Matthieu Napoli さんを招いたミートアップを開催したところ、
Bref(あるいはサーバーレス)に興味を持った方が多く見受けられたので、本プロポーザル提出に至りました。

• サーバーレス・Lambdaのカンタンな説明
• Brefを使って実際に使えるAWS構成
• こんな時はどうする？デバッグやログ

前回(PHP Conference Japan 2022) は AWS CDK を使ってインフラを理解しよう、という話をしましたので、
https://fortee.jp/phpcon-2022/speaker/proposal/view/66d8d2f7-0c5d-4df0-9fe1-cca5501be520
CDKを使って「純粋なPHP」をデプロイし動作させるライブデモを考えています。

このトークでは、データエンジニアとして、アプリケーションエンジニア(PHPer)の皆さんに、データの価値を最大化するために何ができるかを共有します。

アプリケーションが生成するデータベースやログなどの情報は、適切に活用されることでその真の価値を明らかにします。
データエンジニアは、データを処理したり、処理するためのパイプラインを構築することでデータの活用をサポートする役割です。
データエンジニアとアプリケーションエンジニアとの相互理解を深めることで、データの処理や分析がよりスムーズになり、アプリケーションの発展が加速します。

このトークは、両者間のコミュニケーションと協力を促進するための実用的なヒントを提供します。

会社から企画作成を依頼されたり、部門長になったり、会社でやりたいことがあったときに企画書の書き方を知っていると助かることがあります。市販されている企画書の書き方の本を読んでも難しかったりぴんと来ないことが多くないでしょうか？しかし、本来企画書は相手を効率的に説得するためのものなのでシンプルなものがベストです。近年、企画書のロジックを組む際にSWOTなどのマーケティングツールやKGI、KPI、KSFなどの指標を使って定性面と定量面で証明することが求められます。これらのツールを簡単にわかりやすく説明して、具体的な例をもとに20分で、あっこんな風に書けばいいんだということを、マーケティング歴30年の登壇者がズバッと説明します。企画書に興味があるプログラマーの皆さんの参考になれば幸いです。

過去にはセキュリティの文脈で「例えばPHPを避ける」と言われたこともあったり、昨今では速度のためにRustを採用しようという技術選定のモチベーションがあると思います。
しかし、果たしてその技術選定は正しいと言えるのか。デメリットはないのか？

このトークでは私が過去に行った技術選定を紹介するとともに、その技術選定がその後どうなったか。うまく行ったのか行かなかったのか、またそこから得られたものはなにかを話します。
技術選定する際に気をつけていること、考えているポイントなども共有し、今後皆さんの技術選定の際のヒントになれば幸いです。

今まで、フリーランスでいろいろなフレームワークを触ってきましたが、Symfonyが一番得意です。
そんな私が、今年の4月からLaravelの会社に入り、お試し転職の頃から約1年Laravelのプロジェクトに携わっています。Symfonyとはまた違う開発体験を味わっています。
今セッションでは、この1年で感じた魅力やすばらしさ、もどかしさや問題点と、Laravelで開発していく上でどのような試行錯誤を行なっているかをお話しします。

主な内容

• LaravelとSymfonyの簡単な比較
• Laravelで作っていくことの魅力
• Laravelで作っていく時に感じたもどかしさ
• 現Laravelプロジェクトで作っていく上での課題
  • Symfonyだった場合の解決策
• Laravelでの試行錯誤
• 今思う、Laravelでのプラクティス

アジャイルな組織を目指すと、「価値を届け続けるためには、機能する安定したチームが重要だ」とよく言われています。
例えば、「プロジェクトが終わったら、折角良い感じに呼吸が合ってきたのにチームが解散する」といった辛さに覚えがある人も少なくないのではないでしょうか。

組織全体の底力を上げるために、「良いチームを築き、それを支援・維持できる風土を作る」ことは武器になります。
また、それを妨げるような行為、”べからず”もあるわけです。

どのようにチームを作り、組織全体の価値創生を最大化していけばいいでしょう？
目前のチームのパフォーマンスを最大化し、それを組織全体にスケールしていくことは可能でしょうか？
このトークでは、そのためのヒントとアンチパターンを紹介し、考察していきます。

主な参考書籍

• Dynamic Reteaming
• Project Myopia

会議やワークショップの場をまとめ上げるのが、ファシリテーションです。
通常、他者同士の対話の際には、アジェンダや決定事項といった「コンテント」と、場の空気や参加者の内面を対象とした「プロセス」が同時に存在します。
参加者が深い納得感を得たり、より創造的なアイディアを集めるには、プロセスも適切に扱う事が重要になってくるのです。
(つまり、プロセスへの対処がコンテントの質にも大きく影響します)

退屈で一体感のない会議に悩まされている人に、「プロセス」の概念を補助線にしてちょっと違った視点を提供します

話すこと

• 目に見える=水面より上のコンテント要素と、目に見えにくい=水面下に埋もれる多くのプロセス要素を示した、「氷山モデル」の紹介
• グループの持つプロセスについての要素に基礎的なレベルでの紹介
• プロセスに気づき・向き合うための観点や手法について、実践例を踏まえた紹介

みなさん、バランスとってますか？

世の中にはベストプラクティスやパターン、フレームワークが存在しています。
しかし残念ながら、それに従うだけではお仕事が進みません。
わかっていながらも、アンチパターンを取らざるを得ない状況もあります。
今日もどこかで誰かが、苦渋の決断をしてバランスをとっていることでしょう。

本トークでは、その「苦渋の決断」「バランスをとる」をするための考え方をお伝えします。
【要はバランス】と強い先輩たちは言いますが、その「要」にまとめられているのは一体なんでしょうか？
生活のなかから見いだした善・悪と正・邪を軸に、プロダクトの進化とバランスについて探りましょう。

対象は初心者・初学者の方や、どのようにクラスを分けたらよいのか決められないような脱初心者を目指す方を想定しています。

みなさんは「組み込みエンジニア」と聞いてどんな開発体制を思い浮かべますか？
おそらく想像がつかないというのが多いでしょうが、何となく古い体制での開発・属人化など感じる人が多いのではないでしょうか。

WEBエンジニアとして5年経験した後に、WEB系の開発を始めようとしている組み込みの会社に転職したエンジニアが、どんな課題があり、どういう取り組みをしているかを話します。

▼想定対象者
・組み込みの会社について知りたい方
・新しい技術をどうやって取り込もうか考えている方
・zeroから開発体制に取り組む一例を知りたい方

▼話すこと
・体制に課題が多い時の優先度の付け方の勘所
・新しいことに挑戦することの面白さ

▼このトークで持って帰ってほしいこと
・「変化」を取り入れるのに大事なこと
・自分から「変化」を起こすことの重要性

※メイン開発にPHPはないので、PHPの話しは多分出ません。

みなさん、バグ調査は好きですか？新人の頃にバグ調査がなかなか上手にできなくて手間取っている間に、ベテランの先輩が鮮やかにやりとげるのを見て、落ち込んだ経験のある人も多いと思います。
このトークではPHPer歴そろそろ18年の私の、バグ調査の時の目の付け所・思考過程を解説することで、バグ調査が苦手な方向けにやり方とコツをお伝えします。

Laravelでアプリケーションを開発するとき、デフォルトORM（Object Relational Mapper）であるEloquent（Model）を使うことが多いと思います。しかし、EloquentはPHPの世界の唯一のORMではありません。この機会に普通のModelとは一味違ったORM, Doctrineに入門してみませんか？
特にDoctrineMigrationsの便利さは、Laravelユーザーの皆さんに一度体験してみてほしいです！

• ORMとは何か？
• ORMを使ってデータベースのデータを扱う考え方
• LaravelでDoctrineORMを使う設定方法
• LaravelでDoctrineORMを使ってデータベースのデータを扱う方法
• laravel-doctrine/migrationを使う