トーク

これまで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を紹介するトークです

しない話

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

こんな人向け

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

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

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

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

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

今まで、フリーランスでいろいろなフレームワークを触ってきましたが、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を使う

Laravelで多機能なアプリケーションをモジュラモノリスとして開発・メンテナンスしていこうとする時、Modelの依存は悩ましい点になっていると思います。AモジュールにあるModelがUserを、UserがBモジュールにある別のModelを参照してしまうと、結局疎結合にできず、メンテナンス時に依存を排除できません。
LaravelであってもORMとしてEloquentではなくDoctrineを使うことで、モジュール同士が依存しない、疎結合なモジュールによるモジュラモノリスが実現可能です。
実践的なモジュラモノリスLaravelのサンプルコードとともに、LaravelからDoctrineを使う実装についてご紹介します。

テストを書くとき、テストデータ（テストフィクスチャ）をどのように用意していますか？プロダクションコードを改修するとき、テストフィクスチャにも多数の改修作業が発生してつらくなっていませんか？
私は10年近くテストのある開発をしてきた経験から、テストフィクスチャもオープン（拡張に対して開いている）で、クローズド（修正に対して閉じている）にするのが良いのではないかと思うようになりました。
このトークではまず様々なテストフィクスチャの作り方を概観した後、オープン・クローズドなテストフィクスチャを実現するために現時点でベストだと私が思う方法をお伝えします。

このトークでは、10年近く運用されているサービスにおけるPHPフレームワーク（FuelPHP 1.8.2からFuelPHP 1.9-dev）とPHPのバージョンアップ（PHP 7.3からPHP 8.1）の戦略について語ります。

FuelPHPは2023年7月現在、PHPの最新メジャーバージョンに対応したバージョンを公式にリリースしていません。
開発が完全に止まってしまったわけではありませんが、LaravelやSymfonyなど他のフレームワークと比べるとモダンという印象は持てないかもしれません。

FuelPHPを使っている方はもちろん、それ以外のPHPフレームワークを使っている方も対象に、PHPフレームワークとPHPのバージョンアップの知見を共有します。
様々なトレードオフやハードルを乗り越えるために、どのように計画し、アプローチしたかをお話します。

ソフトウェア設計やアーキテクティングって、とっても難しそうですね
─がしかし、普段のコードを書く時にも我々は「設計について」から逃れられない訳です！
「設計が良い悪い」以前にある筈の「どんなものが気持ちいいのか、求められるのか」を説明できていますか？
知識としての「○○原則」や「○○パターン」で片付けない審美眼を持ちましょう
このトークでは、なるべくやわらかく「そもそも設計って何で必要なんだろう」をシェアします

想定する対象者

• 設計って言葉は聞くけど、それって何だ？と思っている人
• (中級者手前くらい)

話すこと

• 「設計」がもたらすもの、助かる事
• コードを書く時に気をつけておきたい事

持って帰ってもらいたいこと

• SOLID原則やクリーンアーキテクチャの「良さ」に興味を持つ
• 「○○アーキテクチャ」を教条的に取り入れるのをやめる(ちゃんと咀嚼する)