トーク

組織、変えていますか！

組織の変化や組織変革を導く行動は、とてもよく研究されている分野です。入門書から専門書まで様々な出版された知見に触れることが出来ます。
裏を返せば、それは知識=プラクティスだけでは立ち行かない難しさの表れでもあります。
が、とにかく何かから始めていかなければ、何も始まらない訳です。
銀の弾が無いからこそ、まず「知ること」は武器になる筈です。

私自身は、エンジニア組織全体を扱うマネジメントに携わった立場や、そこに至る流れの中で、「人を巻き込む事」「組織の雰囲気や目先を変える事」に取り組む場面が多々ありました。
そうした経験から、このセッションでは、以下の3つのキーワードを中心に「変えていき方」を紹介します。

• 何事にも先立つのは「観察」から
• 説得ではなく納得、理解ではなく共感
• 組織・システムを動かすのではなく、自分の立ち位置を「ズラす」

PHPStanを入れる時の話です
既存のプロジェクト・・色々な歴史の重みを抱えるコードベース・・・さて、どうしますか？

よく「低めのLvから始め、教育と理解促進も図りながら徐々にLvを上げる」という手法が紹介されます
非常に健全で真っ当なやり方で、絶対良いです
が、皆さんの現場に於かれましては「そんなに忍耐強くやっていられぬ、いいからとっととやっちまいたい」という感情はないでしょうか？

このセッションは、そんな茨の道、ハードコアなスタイルを自ら選ぶように、”傲慢”・”短気”を包み隠さない人を応援します

ポイント

• 「現状に合わせて」ではなく「何を得たいか」から逆算すると、「まずLv0」は最適解なのか？
• baselineがデカい？そんなの関係ねぇ
• 誰もやらないなら自分で行く、という気持ちで既存コードをどうにかし続ける
• 少しでも気概を見せている人には全力で寄り添う

ここ数年、「(ラボラトリー方式の)体験学習」という概念と出会って、非常に面白いと感じているので紹介したいです
Webエンジニアやアジャイル(或いは志半ばの)チームにとって、学ぶ価値のある領域だと確信しています

例えば、ふりかえり。
「チームで集まって立ち止まる時間をとっている…しかし、次のアクションを出しはするのの、チームの考え方を変える様な気付きは生み出せていない！」
なんて事、ないでしょうか

生身の人間の集合である以上、議論には合理的で安定した判断以外も混ざります。どうしても人間関係や感情・感性が影響を持ちます
そうした内面的なもの・議論の中で言葉として表出され難いものをも含め、参加者同士で認め学び合うのが、体験学習の世界観です
それにより、いつもとは違う視点を引き出します

このセッションでは、体験学習のエッセンスに触れながら、チームの進化に向けたふりかえりの実現を考えていきます

推測するな計測せよ！といっても、”勘”・”一般的な知識”からパフォーマンスの改善に取り組んでいる人も少なくないのでは、と思います。

直感や経験則は非常に強力な武器です。
しかしながら、「計測をしないで手を動かしてします」のは、もしかして「計測をするハードルが高いから、面倒で・・」という事情もありませんか？

ハードルが高いのは、もし普段遣いの道具で簡単に実行できてしまったら、どうにかなる気がしますよね！

Xdebugを導入している環境であれば、「PHPプログラムのプロファイリング」は簡単に実行できます。
そして、PhpStormがプロファイリング結果のGUIビューアとなってくれます！
本LTでは、設定方法・実行方法を紹介した上で、「実際に分析して何かに気づいてみる」というデモまで実施します。

新卒三年目になり、今まで以上に成長したい！強くなりたい！と思い、勉強を始めても自分一人では三日坊主で終わる人生でした。
そんな時、誰かと一緒にやれば続くのかも…！と思い立ち、少人数で定期的に勉強会を始めました。
その結果、継続的に勉強する習慣ができました！

• Xを用いた勉強メモの監視
• 勉強会をスクラムのように回す
• 出席カードの導入
  などの継続をするために工夫した点があります。

そして、一人でも勉強ができるようなったり、カンファレンス視聴や読書の際、「見たこと・聞いたことがある」が増えたりと、個人でも変化がありました。

本LTでは、この勉強会についてより詳しく紹介します。
私たちが設計した最高の勉強会を自慢させてください！

privateメソッドのテストを書くか書かないか問題はよく話題にあがるかと思います。
実は、私もかつてはprivateメソッドのテストをたくさん書いていた時代がありましたが、今はprivateメソッドのテストは書かずにテストを書いています。
自分の思考の整理をするのに繋がった「単体テストの考え方/使い方」という本の内容からも引用しつつ、
実体験をベースに「なぜprivateメソッドのテストを書かないのか」というところをお話します！

トークで話す内容

• かつて私が書いていたprivateメソッドのテスト(と、その理由)
• なぜそれが良くなかったか？「偽陽性」「偽陰性」の視点から考える
• どのようにテストを書くべきだったか？
• privateメソッドのテストは書かない方がいいのか？(※経験に基づいた持論)

platform.shを知っていますか？
platform.shはherokuやvercelのようなPaaSサービスです。Laravelも使っているSymfonyコンポーネントの作者であるfabpotも参画しており、PHPを動かすのにも最初から対応しています。
何ができるの？どう使うの？日本語対応してるの？料金いくらぐらい？
自腹を切って実際に使ってみた体験記をお話しします。

LaravelにはFacadeというものがあり、

DB::select('select 1');

というように利用することで処理を実行できます。
しかし、よくよく考えるとなぜこれが動くのか、きちんと理解して使っているでしょうか？

このLTでは「Facadeがなぜ動くのか」を理解したうえで、「Facadeは極力使うべきではない」という意見について、「なぜなのか？」を話したいと思います。

第三者を装って個人情報を聞き出そうとするメールに返信してはいけない

常識のごとく語られる内容ですが、スパムメールから機密情報が漏洩したり、フィッシングサイトへ誘導されたりといった事例があとを絶ちません。
そんな昨今の状況を踏まえて、エンジニアが所属する組織内へ向けてスパムメールを送信したとき、果たして全員が返信せずにいられるか？という訓練を行いました。

訓練にあたって、

• どのように訓練を設計したのか？
• 結果はどうだったのか

ということをお話しさせていただければと思います。

Laravel Breezeとgoogle2faを用いた設定を行うにあたってやったことを、実際に作ったものも踏まえてご紹介します。

システム開発を行う上で必ず存在するもの、それは組織です。
そして組織には人の出入りがつきものです。
しかし、入る人間よりも出る人間の方が多いと次第に組織運営は立ち行かなくなってしまいます。

このトークではなぜ人は組織から去っていくのか？を自身の経験＋書籍『エンジニアリングマネージャーの仕事』をもとに考察した結果をお話したいと思います。

具体的な内容

• 自身の経験に基づく、組織を去るときのマインド
• 書籍『エンジニアリングマネージャーの仕事』に基づいた、「エンジニアリングマネージャーが与えるべきもの」
• 自身の経験と書籍『エンジニアリングマネージャーの仕事』で語られる「人が去っていく理由」を照らし合わせた結果

対象者

• 現在進行形でエンジニアリングマネージャーの方
• 長く一緒に働いてくれる同僚を探している方
• 転職を考えている方

世の中には素晴らしいプログラミング言語がたくさんあります。

少ない記述量で豊富な機能を持つもの、洗練された美しい構文で誰でも明瞭なコードが書けるもの、コンパクトで一貫性のある構文と標準関数を提供するもの、簡潔な記述で強力な型を提供するもの… それに引き換えPHPは、一般にとても洗練されていない方のプログラミング言語という風評があります。

このトークにおいてはプログラミング言語としてのPHPの歴史的経緯、そしてなぜ現在でもそんな言語の使用が正当化されるというのか、または私は如何にして心配するのを止めてPHPを愛するようになったかについて語ります。

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

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

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

テスト駆動開発(TDD)はしばしば、現代的な開発における強力なツールとして紹介されます
TDDのバイブルとして、t-wadaさんの再翻訳でもお馴染みの『テスト駆動開発』は外せません

もう1つ、TDDの世界観に立ち新たな開発手法を提案する書籍が『実践テスト駆動開発』です
こちらの書籍では、いわゆる「単体テストの2つの流派」のうち、「ロンドン学派」のスタイルを実践されています
古典派的な「下(中身)から作る」だけではない「上(外)から作る」感覚が身に付くでしょう
───場面に応じてスタイルを使い分ければ、開発が進め易くなります！！

もっと簡単に、もっと自由に開発を進めたくないですか？

このセッションでは、

• 「外側から作る」なTDDの世界に触れてみる
• 普段の開発に軽い気持ちで活かしてみる

を取り上げ、

• 柔軟性を手に入れプログラミングを楽にする

ためのヒントを提供します。

話者はPHPカンファレンス2023にてフレームワークを作成します
その結果のLaravelやSymfony、CakePHPなどのフレームワークに敬意を払わずにはいられない様になりました

作成する中でわかったフレームワークを作る上での勘所や課題を共有します。

フレームワーク作者の思考を、フレームワークを作成する側から覗いてみる事で
少しでもその苦労と知見を共有出来ればと思います。

• お話すること
  • フレームワーク作成時の思考
  • フレームワーク作成で困ったこと
  • フレームワーク作成の楽しさ
  • フレームワーク作者への敬意
• 対象者
  • フレームワークが好きな人
  • フレームワークの中身を見てみたい人

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

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

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

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

このトークの対象

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