トーク

会社でマネジメントをやっていまして、エンジニア組織におけるメンバーの目標制度などにも手を出しております
その中で、「ストレッチ目標を立てる」「自分が成長したい姿を意識する」というのを推奨しました。
参考: 過去に書いた記事

これは、組織全体のレベルアップを推し進めたいからであり、その重要なエッセンスである「個人」の成長も仕掛けたいと願ったからです。

実際にやってみて、どうだったでしょうか？
マネージャーでありメンターを担う自分の目線からの手応えや反省・課題と、
実際に目標を設定し取り組んだメンバーの結果(成果、評価)や本人インタビューを織り交ぜて、考察します。

良い点・上手く行かなかった点・難しかった点・合う合わないの話・もっと効果的にするには？のポイント、といったトピックで
実体験をベースに「見えてきたこと」をシェアします

PHP-FIGの定めるオートローディングに関する規約として、「PSR-0: Autoloading Standard」があります
これは、後から出てきた「PSR-4: Autoloader」に役目を譲るようにして、非推奨となりました

一体、なぜ求められ・何を解決し・何が「合わなく」なったのでしょうか？
PHPの言語機能と、PHP利用者のエコシステムの変遷の歴史が、ここにも詰まっています

PSRで扱われるオートローディングの話と、PHPにおけるパッケージ管理について話します

話すこと

• PSR-0の概要
  • PSR-4との比較
• PSR-0登場前夜
  • (set_include_path と require に頼らない)ファイル読み込みの奥義
• その後のPHPのパッケージ管理
  • どうしてPSR-4が出てきたのか、そして役割を交代したのか─

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」をデプロイし動作させるライブデモを考えています。

世の中にはエンジニアコミュニティに参加せず黙々とお仕事をしているエンジニアもいます。PHPカンファレンスの常連になっている皆さんは「もったいないな」と思っていることでしょう。
マネージャーをしていたときに私は2人の新人エンジニアをコミュニティに送り出す作戦を立てて実行し、今年になって成果が出たことを観測しています。
エンジニアがコミュニティに参加することにどんな意味があるかを改めて言語化したうえで、ベテラン側が具体的に何をすると彼や彼女をコミュニティに溶け込ませることができるかについてお話しします。

昨今では "女性エンジニア" をターゲットとした勉強会が開かれたりサービスが立ち上がったりしています。
その中でも "女性エンジニア" はなぜ少ないのかという様々な記事やSNSの投稿を見ますが、憶測であるものも多くあります。

私自身30代に突入し、転職、出産、子育てといくつかのライフイベントを迎えました。
もちろん私生活だけでなくエンジニアとしてのキャリアもどんどん変化をしています。
そんな中で1人の "女性エンジニア" として伝えることができる、これまでと現状、これからの未来についてを話すことで、誰かの希望になれば良いなと思っています。

本トークでは、これからエンジニアを目指す人やエンジニアになりたてで将来に不安を抱えた人に向けて、 "女性エンジニア" という1人のロールモデルとして、これまでのエンジニアとしての生活や変化、これからどうキャリアを形成していくかの話をします。

このトークでは、データの可視化ツールであるRedashについて、「ツライ」ところをご紹介します！

「Redash導入しようと思ってたけど、どんなところがつらいの？」
「俺もRedashがつらいと思っていた！」

そんなあなたにおすすめです！Redashのいい面だけでなく「つらい面」も見てみませんか？

Redashは無料で使えるOSSのBIツールです。データをSQLを使って抽出・加工し、グラフやダッシュボードの形で可視化することができます。
大袈裟なデータ分析基盤を構築せずにデータ分析ができるとても便利なツールです。
このトークでは、Redashの「つらいところ」をお話しします。

このトークでは、データの可視化ツールであるRedashについてサクッと紹介します！
「データを気軽に可視化したいな。でも、大規模なデータ基盤を構築するほどでもないかな……」
そんなあなたにおすすめです！Redashでデータ活用の第一歩を踏み出しませんか？

Redashは無料で使えるOSSのBIツールです。データをSQLを使って抽出・加工し、グラフやダッシュボードの形で可視化することができます。
大袈裟なデータ分析基盤を構築せずにデータ分析ができるとても便利なツールです。
このトークでは、Redashで「できること」をお話しします。

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

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

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

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

打ち捨てられるテックブログが多い中で、弊社M&Aクラウドでは幸いなことに継続できてます。
123件の記事が4年半（2019/10 ~ 2023/5）の間で書かれていました。概ね2週に1記事投稿されている計算です。
弊社におけるテックブログの意義と、続けるための秘訣について共有します。

• テックブログの意義とは
  1. 伝達スキル向上
  2. チーム認知拡大（技術広報）
• 個人ブログとの棲み分け
• 継続とクオリティ担保の仕組み
  • アイディア・ネタがない
  • 構成を考えるのが難しい
  • 文章を書くのが難しい
  • 時間の制約 & トリガーがない

私の所属する株式会社M&Aクラウドではエンジニアの半分がリファラル採用です。
いい人がいい人を連れてくる循環で今までチーム作りをやってきました。
とはいえ、うまくいくことばかりじゃありません。

これまでやってきたことを以下のような内容を織り交ぜてお話しします。

• テックブログ運用。4年半運用で2週に1記事。
• 登壇支援制度。大規模カンファレンス登壇は出張扱い。
• 採用ペルソナの「気合いが入ってていいやつ」。
• カジュアル面談がハードル高い問題。
• スカウト媒体運用辛い話。

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

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

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

主な内容

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

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

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

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

主な参考書籍

• Dynamic Reteaming
• Project Myopia

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

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

話すこと

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

PHP スクリプトがどこでメモリを消費しているのか？
どの参照が意図せず残りメモリがリークしているのか？
何が循環参照を生んでいるのか？

言語としてはもう 30 歳近くになろうとしていますが、 PHP スクリプト内でのメモリの使われ方を知るための選択肢は、意外なほど少ないです。

例えば php-memprof は、PHP 処理系のスクリプト内でのメモリ確保・解放の処理をフックしてリークを見つけ出す素晴らしい拡張です。しかし当然その機構から大きなオーバーヘッドを伴い、本番環境で動作を観察し問題を見つけ出すのには不向きです。

このトークでは PHP 処理系のメモリ管理機構やメモリ使用量計測の事情を解説しつつ、力技の大道芸により PHP で PHP のメモリプロファイラーを実装する取り組みを紹介します。FFI や C 言語レイヤの処理系知識を気軽に使うゲテモノ寄りの話が聞きたい人向けです。

FWの気持ちを理解するのは素敵な事です
では、自作してみるのはどうでしょう？
作れる = 既存FWを読めるようになるという効能もあります

PHPerKaigi 2023で、今風のFWの要件を考察し実装するという発表を行いました
その際に得たFWを例に、実際に動くものを作り上げていく事に主眼を置いて話します
ハンズオンっぽい形やライブコーディング風の説明を多く取り入れるので、是非その場で一緒に手を動かしながら聞いてください

狙い

• FW、怖くない！読める！と思える
  • 普段から気軽にFWのコードリーディングをしちゃう人を増やす
• DIコンテナや、PSR-15/ミドルウェアのイメージを掴む

対象

• FWを(読んで|作って)みたい人
• PSR-7/15やDIについて、聞いた事はある・見かけた事はある人

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

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

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

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

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

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

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

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

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

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