トーク

昨今では "女性エンジニア" をターゲットとした勉強会が開かれたりサービスが立ち上がったりしています。
その中でも "女性エンジニア" はなぜ少ないのかという様々な記事や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記事。
• 登壇支援制度。大規模カンファレンス登壇は出張扱い。
• 採用ペルソナの「気合いが入ってていいやつ」。
• カジュアル面談がハードル高い問題。
• スカウト媒体運用辛い話。

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

主な内容

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

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

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

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

主な参考書籍

• Dynamic Reteaming
• Project Myopia

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

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

話すこと

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

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

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

狙い

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

対象

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

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

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

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

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

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

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

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

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

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

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

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

PHPアプリケーションのコード品質を上げて、メンテナンス性をあげて、寿命を伸ばすためによく使われるようになったphpstan。
皆さんのプロジェクトのphpstanのlevelはいくつですか？baselineは解消できていますか？
SymfonyやLaravelで作ったアプリケーションに対してlevel:maxを設定してbaselineなし・エラーなしにした経験から、コードを書くときに気をつけること＆phpstanを納得させるテクニックをLTの5分にギュッとまとめてお伝えします。

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