🎪PHPerKaigi2025に参加してきました🎪
中野セントラルパークカンファレンス & ニコニコ生放送で開催された『PHPerKaigi2025』に参加してきました。
今回は３日間に渡って開催されたのですが、大変残念なことに今回は色んな事情により少ししか参加できませんでした涙
来年こそはフル参加を目指したいと思います...!
ちなみに今回で３回目の参加になります。
毎回ロゴのテイストが変わってて意匠が凝らされていて可愛いです👀
2025のノベルティは...？
今回のTシャツデザインもめちゃくちゃ可愛いかったです！
カラーを選べるようになってたのがツボでした。
私はネイビーにしましたが、個人スポンサーの方のライトグリーン？(何色って言うんだろう、あれ👀)もめちゃくちゃいいなと思いました。
🎪3/22 Day2
最初に書いた通り、今回は諸般の事情により少ししか参加できなかったので主にアンカンファレンスとスポンサーブース周りなどなどをしてきました。
聞きたいトークは本当に沢山ありましたし、後ほど公開されたスライドを見て「あ〜これ生で見たかったー😭」と言うものも色々ありましたが人生いろいろあるので仕方ないよね、と言うことで気持ち切り変えて会場の雰囲気を楽しんでいました。
やっぱり会場着いた途端ワクワクさせる雰囲気が漂っていて、さすがのPHPerKaigiだなと思いました。
そして会場に飾られてた大きなアイコンモザイクボード、@sanogemaruさんに誘っていただいて一緒にアイコンと撮ったのですが、めちゃくちゃいい記念になりました！
また最初に参加した時と違って、色んな人が顔見知りになっていて、お話かけてくださった方とか、こちらから声をかけた方とかもいらっしゃって、大変ありがたいし、嬉しいなと思いました。
🎪非公式懇親会
色んな方とお話しできて嬉しかったです！よくお話しする方とも、初めてお話しする方とも色々お話しできてとても充実した時間でした。
何なら時間が足りなかったくらい！もっとあの話深掘りたかったな〜とか、もっとあの話聞いてみたかったな〜とか後悔が残ったくらいでした。
そしてみんなが3日目に備えて帰る中、登壇を終えて最強タイムに入っていた@k1Low
さんと朝まで高円寺の焼き鳥屋でメガサイズのビール飲みながら色々四方山相談に乗っていただきました。
ありがたいことにこんな若手の相談に優しく朝まで乗っていただき、私も朝が来る頃にはすっかり考えが整理され先を走る先輩から沢山刺激を受けることのできた良い会でした。
色々お話しを聞く中で思ったのは、@k1Lowさんは生き方が自分軸で安定感があるなあと。
視座が高いし、どこでバリューを出すべきなのか、何が大切なのかがちゃんと見えてるんだろうなあ、などとお話しを聞きながら思いました。
そういう人になりたいし、また一人ロールモデルが見つかってしまい、そのキッカケをくれたPHPerKaigiに改めて感謝です。
🎪最後に
今回少ししかいられなかったですがお話ししてくださった皆さん改めてありがとうございました！
そして毎回こんな素敵な出会いをくれたり、仕事のモチベを最強に高めてくれるPHPerKaigiを開催してくださる運営の皆さんにも本当に感謝です！
来年はフル参加目指すぞ〜〜〜！！！
🍤PHPカンファレンス名古屋2025に参加してきました🍤①
※長くなったので①と②に分けて公開します。
2025年2月22日に名古屋駅近くの『ウインクあいち』で開催された『PHPカンファレンス名古屋』に参加してきました。
オープンニングを聞き逃すまいと朝イチの新幹線で名古屋へ行きました。
そういえば、名古屋に行くのは記憶の限り初めてな気がします。
名古屋めしが美味しいという噂はかねがね聞いていたので、今回はカンファレンスだけじゃなく旅行という観点からも満喫してやろうと思っていました。
🍤私の『PHPカンファレンス名古屋』への思い
※ちょっと長いです。🙇
私が初めてカンファレンスというものに参加した『PHPカンファレンス2022』で初めて聞いたトークが、この『PHPカンファレンス名古屋』の副委員長の@77webさんの『フラットなPHPからオブジェクト指向で自動テストのあるPHPへ、そしてフレームワークへ by 菱田 裕美 | トーク | PHP Conference Japan 2022 #phpcon #phpcon2022 - fortee.』というトークでした。
当時はPHPどころかプログラミング自体を始めて1ヶ月も経たないような時期で、どの登壇内容も初心者にはハードルが高そうな中、初心者向けのトークを確か唯一？されていていたのがこのトークでとても助かった記憶があります。
当時「オブジェクト指向ってよくわからん」状態で、でもプログラミングを学ぶにはオブジェクト指向への理解が必須みたいで困っていた時でした。
そんな時にこのトークを聞いたところ、例え話が豊富で(抽象化？)、話も分かりやすく、目から鱗状態になったのをよく覚えています。
また自分で独学であれこれ調べてもよくわからなかった事をこれだけ分かりやすく教えられる人がいて、そんなトークを無料で聞けたこと、そして沢山のエンジニアが同じ時間軸で同じトークを聞き学びを深めていることに、独学でプログラミングを勉強していいた当時の私はとても驚き、カンファレンスというものへの興味が湧きました。
また感想をPostしたらすぐリプとフォロバいただき、あまりのスピーディーさに驚きつつ嬉しかったのもよく覚えています。
オブジェクト指向を用いたphpでの開発、具体的な事例を用いて説明してくださってジョークもありので、めちゃめちゃ分かりやすかった✨#phpcon #phpcon2022 https://t.co/nQ1ApzDhlB
— mp@日本酒を飲むバックエンドエンジニア (@mp_php_1213) 2022年9月24日
ありがとうございます！
— ななうぇぶ (@77web) 2022年9月24日
そういえば今の会社の面接でも弊社CTOの@hamacoさんに77webさんのトークを聞いたっていう話をしたりしてました。
時は経て、どうにかこうにか私もエンジニアになってから初めて参加した『PHPカンファレンス2023』の会場で77webさんを見かけた時は、感動と興奮でいきなり「一緒に写真を撮ってほしい」とお願いするという暴挙に及んだりもしてました。
せっかくのお話できる機会だったのに『つよつよエンジニア』のイメージが強すぎてあまりお話はできず、ただ写真をお願いしただけで終わってしまい、今から思うと「謎な人に映っていたのでは？」と思います。
突然の事に関わらず嫌な顔ひとつせずご対応頂き、とてもありがたかったですし、その時撮った写真は今でも大切にしています。
更に時は流れて『PHPカンファレンス香川』が2024年5月に開催される運びとなり、私はそこで初登壇することになりました。
自分が登壇している時に会場に77webさんの姿を発見して、聞きに来てくださったことに感動してしまいました。
あの時にカンファレンスを好きになるきっかけを下さった77webさんが自分の登壇を聞いてくださっている事がとても嬉しかったのです。
そんなような経緯があり、今回『PHPカンファレンス名古屋』が開催され、その副委員長として77webさんがいらっしゃるとのことで、私としては「行くしかない!!」の機運が高まっていました。
また、個人スポンサーも人生で初めてすることにしました。自分とコミュニティの関係のきっかけをくださったことに少しでも感謝の気持ちからお返しがしたかったからです。
また、実行委員長の@ttskchさんの『PHPカンファレンス小田原2024』でのトーク、『FigmaとPHPで作る、1ミリたりとも表示崩れしない最強の帳票印刷ソリューション by たつきち | トーク | PHPカンファレンス小田原2024 #phpcon_odawara - fortee.jp』も職人魂を感じて、まるでプロジェクトXを見ているかのような気持ちにさせられた印象的なトークでした。
ということで聞きたいトークも満載でワクワクしている気持ちと感謝の気持ちを持って名古屋へGo！してきました。
✊️PHPカンファレンス名古屋へいざ参加
受付とスポンサーブースとAskTheSpeakerともくもくスペースとアンカンファレンスと無限コーヒーなどの飲食物提供の部屋が全て同じだったのですが、それがとても良かったなと思いました。
AskTheSpeakerって普段だったら部屋に入るまでのハードルが高いのですが、周りに人が結構いるのもあり話しかけやすかった気がします。
全体的に部屋がワイワイしていて賑やかでいいなあと思いました。
あと個人的にスタッフの皆さんがとても親切で、困ってそうなのを見ると声をかけてくれたりしたのもとてもありがたかったです。
🎊オープニング
オープニング映像、めちゃくちゃ良かったです。名古屋に来たぞ！という気持ちになれました。
またオープニングトークで実行委員長がお話されていた「参加しただけでも120点」という言葉が参加者に対しての思いやりが溢れててとても素敵だなと感じました。
徹底的に参加者目線にたってお話くださっているのを感じましたし、これだけ目線を参加者視点に保ってお話できることに"人間力"を感じました。
カンファレンスなどのイベントに行くと、「あれができなかった」「これができなかった」と後から色々反省しがちなのですが、確かにまずは参加したことに目を向けるべきだなと思いましたし、参加者の緊張や肩に入った力もほぐれたのではないかなと思います。
🗣️抽象化をするということ - 具体と抽象の往復を身につける
「具体と抽象」については色々と本を読んできたのですが、イマイチ自分の中で噛み砕ききれてない気がしていました。
多くのエンジニアの方がそうだと思うのですが、例に漏れず私も「具体と抽象を行ったり来たりするスキル」「抽象化スキル」を身に着けたいと思っていたので聞きにいくことにしました。
最初から最後まで目から鱗が落ちまくりだったのですが、特に聞けて良かったなと思ったのは以下の話でした。
- 抽象とはグラデーションだ
抽象と具体の二元論ではなく、ある抽象Aを更に抽象化した抽象Bがあったとき、抽象Bから見て抽象Aは具体だ（※この文は自分の解釈です）、というのは確かにそうだよなあと思いました。
誰かと話をしている時に、その人は抽象だと思って話しているけど自分からみてその人の話は具体に感じる、でも確かにその人が抽象だと思って話していることはさらに具象化することもできるから抽象でもある、というようなことが起こった時に、同じレイヤーで話ができるように持って行くためにも、まずは「抽象と具体は二元論ではなくグラーデションである」という知識を持っていることが必要だと思ったため、このトークを聞けて良かったなと思いました。
また個人的に刺さった言葉は
具体を知らないと想像できない
知識は経験に紐づく
経験した情報が知識に昇華する
熟達するには"正しい実践の量"が必要
具体化するところで手を動かすから経験になる
でした。
例えば「仕様を聞いてAIに投げ込んで、よく分からないけど動いた」で学びを止めてしまうと、それは具体化することをサボってるということ。
具体化するところで手を動かすから経験になる。
経験は知識になるし、そういう正しい実践を数多く重ねることによって熟達していく。
自分に足りてないのは具体化した経験なのかもしれないと思いましたし、「あとは正しい量になるまで実践するだけだ」と勇気が貰えました。
🗣️タスク分解の思考錯誤〜レビュー負荷を下げるために〜
タスク分解の方法として、「機能単位」「処理単位」までは聞いたことがありましたが、「レイヤー単位」「補完単位」は聞いたことがなかったです。
それぞれのタスク分解の方法の開発生産性が高まったかどうか見る方法として「箱ひげ図」という方法があることを学びました。
私も仕事で機能単位でタスクを区切ると重たくなりがちだったんので、機能単位で区切ったタスクが重くなりがちなのはとても共感できました。
いつかタスクの区切り方に困った時にタスクの特徴によって適した区切り方ができるようになれると、レビュー負荷が下がってよいなあと思いました。
1年目の私に伝えたい！テストコードを怖がらなくなるためのヒント
「テストケース名は「test_前提条件_期待する結果」で書く」の一文に出会うためだけでも聞けて良かったなと思えたトークでした。
その他にもテストコードを書くときにはAAAパターンを使うと良いなどの知見も得られました。
AAAパターンとは
- Arrange（準備）
- Act（実行）
- Assert（確認）
でテストコードを書いていくことのようです。
詳しくはこちらの記事をご参照ください。
テストコードを書く時に、意味のあるテストコードを書くための実践的な生きた知見が詰まっていて、今後テストを書くときの良い指標が見つかりました。
楽しく向き合う例外対応
本番で障害が起きたときにどんなマインドで、またどんな風に対応しているのかを切り口爽やかに解説されていたトークでした。
個人的に響いた一文は
単発の操作では再現できないとき前後のアクセスログを時系列で並べてみます。
でした。
おくつさんはトークの中で「名探偵になった気持ちで」エラーを再現されているとのことでしたが、とても大事なやり方だなと思いました。
障害が起きた時も、解決を楽しむ「名探偵」マインドを持てるようになりたいなと思いました。
責務と認知負荷を整える！抽象レベルを意識した関心の分離
個人的にめちゃくちゃ刺さったトークです。
『明日からもう変わろう』ぐらいに自分のマインドが変わりました。
プログラムを書いていて、まずやりたいことを日本語にして、それを基に読み手が読みやすいプログラムを書いていく、というのは常日頃から意識していたのですが、なんだかそれでもどこか読みにくいな？と思うコードになってしまっていたのでした。
というのも、日本語にしたときとプログラムにしたときと抽象度が揃っていないせいだと、このトークのおかげで気付かさました。
日本語でやりたいことを書いて、プログラムにした時に、抽象度ちがうな？翻訳が必要だな？となったらそれは抽象度が揃ってないことを示す指標になりそうです。
（※もちろんプログラミング言語である以上翻訳は必ず必要なのですが、表現上そう記載しています）
また意訳できるまでコードを忘れらない
のお話も確かに...!と深く頷きました。
概して読みにくいコードというのは、「全部読むまで何をやりたいのかよく分からない」コードであることが多いなと思いました。
また処理を、
- 別クラスに分けるか
- プライベート関数化するか
- コメント追加するか
のそれぞれのアプローチのフローチャートもお話してくださっており、これを意識していると今後読みやすいコードを書きたい時迷うことが一個減りそうです。
とにもかくにもこれから何度でも読み返したい良いトークでした。
『テスト書いた方が開発が早いじゃん』を解き明かす
去年の『PHPカンファレンス香川』の懇親会でにちようびさんとテストについて色々お話していました。
詳しくは割愛しますが端折って書くと、「環境的にテストコード書かない場所でも、テストコードは書けるよ」というアンサーをその場で頂いたと思います。
それがそんなお話をしていた時の写真⏬️
@o0h_ さんと@smeghead さんと！#phpconkagawa pic.twitter.com/bISnezGCcw
— mp@日本酒を飲むバックエンドエンジニア (@mp_php_1213) 2024年5月11日
その後TLでこんな投稿を見つけてしまい...！
名古屋で話してみる機会をいただいたやつhttps://t.co/yDeZ75f1oH
— 今日も誰かのにちようび(おいしい鮭親子丼) (@o0h_) 2024年11月24日
コレはどっかのタイミングで @pm99763343 さんと話してた時にフワッと種をもらったトピックで(だったはず・・)、今年の福岡にも出してた内容を再度作文したやつです
とてもとても楽しみに聞きに行かせて頂きました！まさかセッションとして改めてお話を聞かさせていただけるとは思わなかったのでとても嬉しかったです...!
結果として、聞き終えた後、テストに対するイメージがかなり変わりました。
プログラミングは複雑・緩慢・曖昧だとして、その難しさを少しでも楽にするのがテストである。
テストは何もPHPUnitだけがテストではなく、書き捨てのコードでも何でも正しい値が返ってくることを確かめられる事が大事。
特に個人的に刺さったのが68枚目のスライドでした。
https://speakerdeck.com/o0h/phpcon-nagoya-2025?slide=69
目的（≒期待する結果）と実装を切り離して考えるのは、抽象的な思考能力も鍛えてくれる=>設計力
テストをしないと、「動いてるじゃん」ぐらいの認識しか自分のコードに対して持てないですが、テストをすると「何が許されて何が許されないのか」「境界値はなにか」「また、なぜ許されてなぜ許されないのか」みたいな所まで自然と深ぼることになるなと思いました。
そうするとコードの目的とするところを明確にする癖が自然とつき、冒頭のスライドでも出てきた「複雑・緩慢・曖昧」を許さないコードにする意識が身につくのでは？などと妄想したりもしました。
またテストの無いコードだと、プロダクトコードだけが正解を知っていることになり、答え合わせの方法がなくなる〜のくだりに関しては首がもげるほど頷きたくなりました。
実装した前任者がいなくなると、何を意図したコードだったのかわからなくなるのはあるあるだと思いましたし、そのような状況で正解を示してくれる役割もテストコードにはあるのだなと勉強になりました。
ひとりでも、PHPUnit使えなくてもテストを書く意味はあるし、テストコードを書くほうが書かないより"早い"の意味が身に染みて知ることのできたセッションでした！
🍤お昼休み
なんだかぼーっとしていたらあんちぼっちランチを逃してしまい、たまたまそこにいてくださったにちようびさんとしめじさんとひつまぶしを食べに行きました。
奇しくも『PHPカンファレンス香川』の懇親会のテーブルと同じ方たちとご飯を食べることになり、不思議な感じでした。
初めて食べるひつまぶしはかなり美味しかったです...!
つづく
👨💻ピセカ〜PHP Sessionless Conference〜に参加してきました👩💻
PHP Session Conference(以下略称：ピセカ)とは？
forteeのTOPページの説明に因ると
PHP Sessionless Conference は『双方向コミュニケーション』をテーマとした、セッションのないカンファレンスです。
また、主催者の@chiroruxxxx さんが出演されていたツナギメエフエム.128 では
「いろんなカンファレンスの廊下での会話の楽しさを再現したかった」
（意訳です。誤読でしたら大変すみません🙇）
とのお話もありました。
ピセカはワークショップしかないカンファレンスで、一般的なカンファレンスのように、登壇者と聴講者のような一方的なコミュニケーションではなく、
ワークショップをする方<->参加する方<->参加する方
みたいな双方向のコミュニケーションが体験できる画期的なカンファレンスです。
私自身いろんなカンファレンスを見聞きしてきましたが、ワークショップのみをテーマにしたカンファレンスは初めてです。
わたしとワークショップの出会い
私が初めてワークショップなるものに参加したのはPHPカンファレンス香川2024の
『XdebugとPhpStormを使って「難しめ」なコードを読んでみよう！LIVE』 が初めてでした。
Xdebug自体には興味があったものの、社内で使ってる人がおらず知見が溜まりにくい・手が出しにくい、みたいな状態でして、
「導入する所からできるのであればハードルが低そう！」
という気持ちで参加しました！
実際参加してみると、様々な発見や気付きがありました。
「Xdebugマスターしたぜ！むふふ」
には、一回触ったぐらいでは当然なれませんでしたが、なんとなく操作イメージが湧いたのは貴重な経験でした。
またところどころ詰まってしまう操作があったり、操作に手間取って説明を聞き逃してしまったりした時に、周りの方に聞いてみると快く教えてくださったりする瞬間もあり、人って優しいなという気持ちになれたりしました。
こういう時に助けてくれるエンジニアさんてその後もずっと忘れることが無いですね。
Xの交換を忘れてしまったのでもう今となっては誰かも分からない香川のエンジニアさんにあの時助けていただいたのは一生忘れられません。（めちゃ丁寧に見てくださった...）
また講師役の@o0h_ さんが用意されていた資料がめちゃくちゃ手が混んでいて、
- 見やすい
- 分かりやすい
- 丁寧
の三秒氏が揃っていてかなりついていきやすかったです。
今Zennで無料で読ませていただくことができたり、追体験が何度でもできるとうのもワークショップの醍醐味かなと思います。
Zennのリンク➡️[WIP]XdebugとPhpStormを使って「難しめ」なコードを読んでみよう！
ワークショップの時は3くらいしかわからなかったけど、後日資料を見返したり再チャレンジして8とか10の習熟度に自分を持っていくこともできる良さがありますね。
ということで、最初に参加したワークショップの体験がとても良かったおかげもあり、私にとってワークショップは『良いもの』なのです。
ピセカ参加前にピセカに対して感じていたこと
ピセカでは、よく各カンファレンスで登壇されているようなエンジニアの方のワークショップに参加することができます。
質問することもできるでしょうし、ワークショップのテーマに絡むことなら普段困ってることに対するアドバイスを聞くこともできるかもしれません。
こんな贅沢なことってありますか？？
また中・上級者向けばかりではなく初級者向けのワークショップもあり、きちんと参加条件などでテーマ分けされているのも、参加者としては安心して参加できるポイントでした。
ということで参加した後の自分の成長に期待していました。
Communication Seal Card
また受付時に名札、アイコンのシール、そして「Communication Seal Card」なるものが配られました。
どうもこの「Communication Seal Card」（※以下ビンゴカード）というビンゴカードのようなものにコミュニケーションを取った相手のシールを貼るというワークが、ワークショップ外であるようでした。
無理なくコミュニーケーションが取れますし、何よりカンファレンスが終わったあとも誰と何の話をしたのかの記念になりますし、とても素敵なアイデアだと思いました。
ピセカきました！
— mp@日本酒を飲むバックエンドエンジニア (@mp_1213) 2025年2月8日
ビンゴ楽しみ！#ピセカ pic.twitter.com/uEbcAS4nVY
Opening
「『Sessionless』 なのに『Opening Session』はおかしいですよね？『Opening Workshop』をしましょう！」
とのことでいきなりビンゴカードのワークをすること！
しかしほとんど話したことがある人ばかりで、あっという間に話したことのない人がいなくなってしまい、にちようびさんとこいほげさんとお話させていただきました。
にちようびさんとは「オススメの技術書を紹介しあう」というワークをさせて頂き、私からは「カオナビ本」をオススメさせて頂きました。
オススメというか推し本？の紹介になってしまったのかな？
できればにちようびさんの知らない技術書をオススメしたかったですが、ぱっと思いつかなかったw
にちようびさんからは私も最近発売されるのを心待ちにしている「ストリートコーダー」をご紹介頂きました。
どんな内容なのか今から楽しみですね。
こいほげさんとは何度かちらっとお話させて頂いたことがありますが、ちゃんと雑談させていただいたのははじめてでした。
「SNSで相互フォローした」というワークをしようと思ったのですが、すでにお互い相互フォローされてることが分かってしまったのですが、それを確認しあったという意味でもシールの交換をさせて頂きました。
こいほげさんは私が参加する「PHPStan型付け体験教室」の裏番組の「PIE(PHP Installer for Extensions)をみんなで試そう」を開催されるとのことでその経緯などをお聞きしました。
PHPStan 型付け体験教室
仕事でPHPStanはレベルMAXで使用させて頂いており、日々PHPStanのエラー潰しをしている関係で、少しでもPHPStanと仲良くなりたい一心で参加しました。
参加者は用意されたコードをPHPStanのプレイグラウンド に貼り付けます。そして出てきたエラーを一個ずつ潰していき、全てのエラーを潰せたら、次のレベルの問題に行く、というのを計4つやっていくというものでした。
私は4つ目の途中までしか行けなかったですが、PHPStanの内部で静的解析している関数の動作を知ることができたりして、とても興味深い経験ができました。
また隣同士になった方と、環境周りを準備する時にどうしたらいいか質問されたりもあり、自然と会話も発生していましたし、その会話の流れでシール交換もできたりと、双方向のコミュニケーションが産まれていました。
みんなでランチ！
シャッフルランチは、くじ引きスタイルでグループ分けされていきました。
私はピセカの「セ」グループでしたので、「セ」グループで近くの「泥人形」というアンティークな洋風のカフェに行きました。
こちらたまたま「セ」グループが入ったときがすんなり入れただけで、人気店なのかお店を出たときには大行列でした。
ということで店内に入り、まずはみんなで自己紹介。
カンファレンス自体が初めての方がいたり、午後のワークショップの『
』を主催予定の岩堀さんがいらっしゃったり、PHP歴が18年のベテランがいらっしゃたり様々な方がいらっしゃいました。
岩堀さんに「そもそもeBPFって最近アツいらしいけどどんな技術なんですか？」ということをお聞きし、岩堀さんがめちゃくちゃ丁寧かつ熱く語ってくださったので75分というランチの時間があっという間に過ぎ去っていきました...!
私はまだ職場でオートメトリクスを使うことはないと思いますが、SREの方は普段こういうことを考えて仕事されているのかあ、違う世界を見せて頂き大変刺激があり勉強になりました。
100分で本番デプロイ！Laravelで作るWebアプリケーション作成
実は業務では本番デプロイしたことがなく、なおかつAWSを触ったこともありませんでした。
でも一人でやるとなると色々不安がありますが、ワークショップ形式でなおかつ先輩エンジニアの皆さんが周りにいらっしゃるので挑戦するにはこれ以上ないもったいないほどの環境ですね。
このワークショップの序盤のアンケートでは7割くらいの方が「デプロイしたことがない」と挙手されていましたし、意外と仲間はいるんだな！と勇気が出ました。
今回のワークショップの良かった点は
- 最初にゴールが示される（「これからあなたたちには最も薄いアプリを作ってもらい、それをデプロイしてもらいます。」）
- 今回やることの難易度のイメージをイラストで示してもらえる（幼稚園生がかいたような馬のイラスト）
- AWSなどの手法について業務とイメージが違う箇所には注釈がもらえる（「本当の業務だとこうしますが、今回はデプロイまでできるようになることが目的なのでこの方法でいきます。」）
なにから何まで丁寧で、初心者を取りこぼさないような配慮に満ちててとてもありがたかったです。
また隣の席の松尾さんには「OSS Gate」に続き、大変助けて頂きました。この場を借りてお礼申し上げます。
私のところだけじゃなく、あらゆるところで助け合いの輪が広がっていてそのおかげもありCDまではいけなかったですが、CIまでは私含め皆さんがいけたようでした。
AWSは初めて触ったのにもかかわらず、サクサク作業を進められたのも結構感動ポイントでした。
時間切れでCD構築までは行けなかったので、今月中にCDまで行って、「Hello Uma!」をデプロイしたいと思います。
前日夜遅くまでワークショップの準備をしてくださっていたようで、本当にありがたい限りです。
ちなみにhanhanさんによってワークショップ内容が公開されたようで、リンクはこちらになります。
hanhan's blog - ピセカのワークショップ内容公開
チームビルディングのためのインプロワークショップ
参加した動機としては、個人的にそろそろ後輩に教える立場になってきたのもあり、自分の「受け身」「空気を読んでしまう」といった弱みを変えるきっかけにしたいと思い参加させていただきました。
結果的には参加できてとても良かったです。
様々なゲームをしそのどれもが学びを与えてくれたのですが、個人的にとても印象深かったゲームをひとつ上げるとするならそれは「社長ゲーム」でした。
これは社長役になった人の所に誰かが
「社長、大変です！〇〇が〇〇になっています！」
というように深刻な（？）報告をします。
それに対し社長が
「よし、それはちょうどいい！〇〇をしよう！」
と解決策を提示すると周りのメンバーで
「さすが社長〜！」
と拍手するというゲームなのですが、なんか飲みゲーみたいに見えて結構良い気付きがありました。
まず、業務をしていて「納期に間に合わないかも」とか「深刻なインシデントが起きたかも」とか大変な状況って沢山あると思うのですが、そういう時って社長の所来たに駆け込み役の人みたいに精神的に焦ってしまっているし、視野が狭くなってしまってますよね。
でもそういう時にその事象に対して「それはちょうどいい！」とポジティブに受け止める思考回路をひとつ持っておくと、余裕ができて視野が広くなるなと思いました。
いつもどんなことが起こっても「それはちょうどいい！」というマインドを持って置けると案外簡単に解決することも多いのかなと気付かされました。
あと、これは余談なのですがかなり沢山動いたのでいい運動になりました笑
Closing
クロージングでは「1-2-4All」という振り返り手法をすることになりました。
これはどのようなものかというと、各テーブルでまず
- 1人で振り返る
- 2人で振り返る
- 4人で振り返る
というふうに段階的に人数を増やして振り返りを行いました。
ぼんやり頭の中に浮かんでた言語化されないアレヤコレヤが、内省を得て、少しずつ人数を増やしながら言語化していくので、最終的には自分の振り返りがはっきり言語化できているという貴重な体験でした。
いきなり「今から振り返ってください！」で人の前で話すのって緊張するし、まだまとまってなかったりするせいで上手に話せなかったりもしますし、今回の「1-2-4All」はとても良かったです。
ピセカに参加後に感じたこと
「思っていた倍以上の濃い経験ができたな」というのが率直な感想でした。
また、カンファレンスあるあるの「ぼっちでさみしい」と感じる時間の割合がかなり少なかったのもびっくりでした。
「ビンゴカードあるし誰に話しかけてもいい」という安心感はすごかったです。
また、これは懇親会（？）の3次会で主催者のちひろさんにも直接お伝えさせて頂いたのですが、「次の目標へのエネルギー値が高い」状態でカンファレンスを終えられているというのがとても良かったです。
普段カンファレンスや勉強会で登壇を聞いて感動したり勉強になったりということはよくあるのですが、それが明日からすぐできるスモールステップにすぐつながるかというとそれは登壇テーマの性質にもよるのですがやっぱり少し少ないかなといったイメージがあります。
目標ができても「いつかはこんなことできるようになりたいなー」とどこか遠くのゴールにおいてしまうことが多い気がします。
それはそれでとても大事なことです。
ですが、ピセカの凄いところは「明日からでもすぐhanhanさんの資料があがったらCDまでやるぞ！」と、「スモールステップの目標がすぐ見つかる」「明日からの目標がすぐ見つかる」といったところなんだと思います。
例えば今回でいうとPHPStan型付け体験教室では、今までPHPStanの関数なんて見たこともないのにエラーを潰してたことに気づけました。
「今度はドキュメントを見て、プレイグラウンドで関数を動かしてみよう」
という目標ができてたりするのですが、それはいつかじゃなくても明日からでもできる目標なのです。
こういう目標がいくつもいくつもできるのがピセカのすごいところだと思いました。
改めてこういう凄い場所を作り上げて濃密な体験をさせてくださったピセカ運営メンバーの皆様とワークショップ主催者の皆様、そして参加者の皆様にこの場を借りてお礼申し上げます。
懇親会
結論からいうと朝の5時まで話してました...w
いろんな方とお話させて頂いたのですが、そのどの話もとても良すぎて自分の芯に響きまくってました。
同世代で優秀な方が普段どうやって仕事に向き合っているのかだったり、ベテランエンジニアの方の意外なキャリア初期のお話だったり、「ソースを読めばいいのでドキュメントはいらない」VS「ドキュメントはいる、ソースを読むよりはやい」のバトルだったり、面白い話が沢山聞けました。
特にこの日自分の中で印象的かつマインドセットを変えてくれたの話は武田さんの話でした。
PHPからプログラミングを始めて、Laravel以外のPHPのFWを触ったことがない自分は「LaravelをマスターすればPHPの良い設計をマスターできる」と思っていました。
でもあくまでLaravelはひとつの思想を表したFWに過ぎず、なんならプログラミング言語自体も課題を解決するだけの手段にすぎず、たくさんの思想がある中でLaravelはどんな課題を解決することに特化したFWなのかを意識してLaravelを使い、学ぶと良いのではないかという発見と学びを得ることができました。
「銀の弾丸はない」というのはよくソフトウェアエンジニア界隈で聞く言葉ですが、どれだけ人気のFWでも「これが正解だ！」というものはないのだなと、自分の視野の狭さに気付かされましたし、逆に視野が広がったこの会に居れたことにとても感謝しています。
まとめ
懇親会まで含めて、自分にとって最高の体験ができたカンファレンスでした...!
半年に一回ぐらいのペースで参加できれば嬉しいので、次回もあることを期待したいと思います。
「エッセンシャル思考」読書メモ
エッセンシャル思考とは？
エッセンシャル思考は、より多くの仕事をこなすためのものではなく、やり方を変えるためのものである。
「やらなくては」→「やると決める」
「どれも大事」→「大事なものはめったにない」
「全部できる」→「何でもできるが、全部はやらない」
エッセンシャル思考の基礎となる３つの考え方
- 選択
YESと言う事に焦りすぎない。
それを引き受ける上で、何が犠牲になるのか熟慮する。
人間の体力や気力は、どんなに優秀な人でも無限ではなく、いつかそのリソースには限界が来る。
人間の人生は有限なので、早いうちから選択と集中を行うこと。
このことについて特にしっくりきた説明は、とある優秀なエンジニアの話だった。
彼は優秀であるが故にいつも沢山のことを同時並列で勉強していたが、全てのことにおいて中途半端で1mmずつしか進んでいないような感覚に置かれていた。
著者であるマキューン氏は彼にこうアドバイスした。
もっとも大事なことを、ひとつだけ選んでみてはどうでしょう？
10つの最優先事項を持っていると、成果が出せない。
上の例でいうと、10つの勉強をして毎年1mmしか進めないよりも、その中から最も大切な最優先事項を1つ決めて、毎年1cm進む方が、目に見える成果としてのreturnは大きい。
ただ、最優先事項を決めるのはとても難しい。
しかし、全てを優先するというのは、全てを優先しないのと同じ結末になる。
みんなを優先するのは、誰も優先しないのと同じだ。
また、自分にとって本質的に大切なことを優先するのは、一時的に見て相手を怒らせたり落胆させることもある。
しかし、長期的に見るとそれは相手からの敬意と尊敬を勝ち取ることなのだ。
例えば、ジョブスはNexT社のロゴを有名グラフィックデザイナーのポール・ランドに依頼した。
「複数のデザイン案を提出してほしい。」
しかし、ランドはこの依頼を蹴った。
「いくつも候補など出さない。」
ジョブスは憤慨した。
ランドは、自分自身の仕事の仕方に信念を持っていた。
最高のデザインを1つ提出するが、それを使うかどうかの判断はそちらでしてくださいと。
結果ランドの出したデザインはジョブスを感嘆させた。
そして結果的にジョブスの敬意を勝ち取ったのだ。
好印象を手に入れたいからと何でも安請け合いしていては、この敬意は手に入れることはできなかっただろう。
2.ノイズ
世の中の大半のものはノイズ。
その中から本質を選び取らないといけない。
本質を選び取るというのは、編集作業と似ている。
本当に必要なところだけを選び取るのだ。
スティーブン・キングの言葉で、以下の言葉が紹介されていた。
書くことは人の仕事だが、編集は神の仕事だ
1であげたような選択ができるようになるためには、何がノイズなのかを注意深く選択しなければならない。
そのために必要なスキルが3番目にあげるトレードオフだ。
3.トレードオフ
例えば、上司に急に差し込みの仕事を依頼されたとする。
この時、部下が抱えている仕事の何かしらは犠牲になる。
差し込みの仕事と、犠牲になった仕事はトレードオフの関係にあると言える。
この時、「どの仕事を後回しにしますか？」
と上司に聞くことで上司にトレードオフを意識してもらうことが出来る。
目の前の仕事を優先した結果、もっと重要な仕事が駄目になるかもしれない。
あるいは、自分自身の問いかけにもこれは使える。
目の前にやらなければいけないことが10個あったとする。
これをやることで自分は何をする時間を犠牲にしているのかきちんと認識するようにする。
人生は常に選択の連続だが、選択したもののみにフォーカスするのではなく、何が犠牲になっているのかを意識することで、結果的に本質的なものだけを選択する判断力が身につくのだと思う。
犠牲になったものを失ってでも、今の自分はこれをしたのだと考えることで、後悔の少ない人生を送ることにもつながる。
逆プロトタイプ
なんのためにその仕事があるのか謎な仕事がある。
例えば毎週作成しなければならないグラフィカルな手の込んだ報告書。
これは一体誰を喜ばせるための仕事なのか？
止めるべきか判断がつかない時には、「逆プロトタイプ」と著者が名付けた方法が役に立つ。
今やっていることを試験的に一定期間やめてみる。
苦情が来なければ、それはやめていい仕事だということだ。
こうして時間をより大切なことに使えるようになる。
仕事を早くする
手当たり次第に進めるのでは、逆に効率は悪くなる。
準備は徹底的にする。
バッファは最悪の事態が起こった時にかかる見積もりの1.5倍載せておく。
ボトルネックを見つける。
この仕事が進まない一番の問題点。
この問題さえ取り除かれれば、一気に仕事が軌道に載る。
そういうボトルネックを見つけること。
本当に必要なところに一度だけメスを入れる。これは問題解決にかぎらず、最上限の努力で最大限の結果を得るための普遍的なやり方である。
準備を徹底的にし概要を把握したら、ゴールを決めること。
「〇〇ができたら達成。」
期日もゴールに入るだろう。ゴールはできるだけ具体的な方が良い。
そして、ゴールが決まったら上述したようにボトルネックを見つけること。
仕事に取り掛かる前に自分に問いかけよう。
この仕事をやり遂げるうえで、邪魔になるものは何か？
仕事の完成を邪魔する要素を全てリストアップする。
そして、優先順位をつける。
そしてもう一度自分自身に問いかける。
これを取り除けばほかの問題も解決するような、大きな障害は何か？
ここまでで、明確にボトルネックが見つかればあとはそれを取り除くだけだ。
最後に
ここにメモしきれないくらい、様々な良いトピックがある本だった。
例え話も多く、文章も明快で分かりやすく、読みやすかったので2日ほどで読み終えることができた。
その割に学びもとても多かった。
エッセンシャル思考を生きる人は、周囲の人と同化しない。
人がイエスとい言うとき、あなたはノーと言う。
人が行動するとき、あなたは考える。
人がしゃべるとき、あなたは耳を傾ける。
人がスポットライトを浴びようと押し合うとき、あなたは陰に立ってしかるべき時期を待っている。
人が見栄えのいい履歴書をでっちあげてインターネットのプロフィールを派手な言葉で飾るとき、あなたは地道に仕事の力をつけている。
人が忙しいと不満 (=自慢)を言うとき、あなたは控えめにただ微笑んでいる。
人がストレスとカオスの渦中にいるとき、あなたは豊かで充実した暮らしを送っている。
この情報と雑音とストレスと虚栄に満ちた世の中にあって、エッセンシャル思考を生きることは、静かな革命である。
PHPerKaigi 2023に参加してきた[レポ]
東京都練馬区で開催された「PHPerKaigi2023」に初参加してきました。
会社が「PHPerKaigi」のために金曜日をお休みにしてくれたので、金土の2日間、オフラインでの参加ができました。
PHP歴は5ヶ月ほどと、まだまだ浅いので楽しめるか不安だったのですが、結論から言うと全くの杞憂でした。
事前にノベルティBOXの中に入っていたパンフレットを見ながら、当日の開催されるトークテーマを見つつ、「TrackAとTrackBのどちらのテーマに参加しようかな」なんて考えて、今度はあっち今度はこっちなんてするのは文化祭感があって良かったです。
また、どのトークテーマもほかではなかなか聞けない話ばかりで、貴重だったのも好奇心がくすぐられましたね‥
普段他社のPHPerさんとお会いする機会はなかなか無いので、一斉に揃った景色を見るのは圧巻でした。
確か累計で300名くらいオフライン参加されていたような気がします。
スポンサーブースもそれぞれ意匠を凝らして独自の企画やノベルティを用意していたりして、普段使ってるサービスってPHPで書かれてたんだ！みたいな発見もあったりして楽しかったです。
あとこれは余談なのですが、PHPマカロンなるものが用意されていたのですが、「無料なの？！」ってくらい大量に用意されていて、なおかつクオリティの高いお味で見た目も可愛く、感動しました‥
また、参加二日目にはTwitterでPHPerKaigi参加者同士でランチの募集があったので、人見知りながらも勇気をだして行ったりしました。
PHPerの知り合いが増えて嬉しかったし、「Awkにハマっている」という面白い話も聞けたりして、良い時間でした。
ご一緒させていただいた方には改めてお礼を申し上げたいです。
また、Twitter上でフォローさせて頂いてる尊敬してる方の姿を生で見れるのも、PHPerKaigiの凄いところでしたね‥
「あ、あの人も知ってる！この人も知ってる！」みたいな感じで、テンション上がりまくりでした。
人見知りのくせに声をかけずにはいられなくなり、厚かましくも一緒に写真を撮っていただきました‥
皆さんこんな得体のしれない人物に、快くOKを下さり、Twitterなどでの掲載許可もくださり、頭が上がりません。
ほんとうにありがとうございました！
一生の宝ものにします！！
トークセッションの合間にLT大会なるものもあり、いろいろな工夫もすごかったなあと印象的でした。
まず、会場の後方にビールやサワーやおつまみが用意されていて、傍聴者はお酒片手にLTを聞けるのです‥！
LT大会が終わる頃には結構酔いが回っており、そのおかげでスポンサーブースで他社のエンジニアさんに話しかけられたりもしたのでアルコールに助けられました笑
あともう一つ印象的だったのが、ペンライトを渡されたことですね。
「何に使うんだろう‥？」と思っていたら、なんと、LT大会登壇者の押し色にペンライトのカラーを変えて、LTの制限時間30秒前になったら傍聴者のみんなで一斉にペンライトを振って、登壇者を応援する？という素敵な試みでした。
まるでコンサート会場のようで、一体感がすごかったです。
最終日には会場で懇親会もあり、食事とお酒を立食形式で楽しみながら、いろんな方とお話しました。
初参加で顔見知りがいなくてどうしようと思っていたら、登壇者の@soudai1025さんが、人を紹介してくださったり、勇気を出してベテランエンジニアさんに話しかけてみたりすると、駆け出しの自分にたくさんの励ましの言葉をくださったり、PHPerコミュニティのあったかさに感動しました。
懇親会ではDMをくださった、同じく駆け出しエンジニアさんとお話して、そのまま朝まで飲んだりして、こんなに頑張ってる優秀な方がいるんだ！と刺激を受けたりで、いろんなPHPerの方とお話できて、みのり多い懇親会でした。
PHPerKaigiの本編は懇親会だとも言われているようです‥笑
ということで、初参加で緊張していましたが、初心者からベテランの方まで楽しめる盛りだくさんのイベントでした！
もっと成長して、来年も参加したいと思います。
2/26 YKMC祭り[設計実践勉強会]振り返りまとめ
- 振り返り会感想
- システムはビジネスに依存していて、ビジネスは価値に依存している
- 蔵書合計計算機をどうして利用者にもたせていいのか？
- 蔵書合計計算機を利用者に持たせるのであれば利用者という名前はおかしいのでは？
- 貸し出し明細の責務がシステムから生えているのはおかしいのでは？
- 実践と点線/コンポジション
振り返り会感想
1月に参加したYKMC主催の設計勉強会で行った、図書館の貸し出し機能のモデリングについての振り返りに参加した。
冒頭から濃い話が沢山出てきて、終わった頃には脳が疲弊しきっていたけど、また沢山の学びがあったので、参加できてよかった。
＊この記事では、主催者の方の許可をもらって、振り返りの中で出てきた図や振り返りの流れをまとめさせていただきました。
システムはビジネスに依存していて、ビジネスは価値に依存している
ドメインエキスパートと一緒にモデリングしていくなどが有効な方法では？
どのコアドメインが一番価値を生み出しているのか検討する。
その上で一番必要なドメインに高い保守性を持たせる。
古いシステムだと、システム依存の構造になってしまう。
本来システムは形を変えていくべきもの。
ビジネスは変化していくのに、システムに依存してしまっている。
特定の言語というリソースに依存しないようにすること。
負債の解消ができていない？
AS-ISで現状の把握を行い、TO-BEの目標地点へのマイルストーンとする。
TO-BEへの経路は複数ある。
蔵書合計計算機をどうして利用者にもたせていいのか？
名前から推論して答えるのは、名前の設計がきちんとしているから出来ること。
「この操作はこの名称のエンティティが持つべき」という観点から置くべき場所を探す
全体の関係を把握した上で、考える。
「この操作はこの属性が必要」という観点から置くべき場所を探す。
利用者が消えた時に貸し出し中手続き中カートとかだけ残るのはおかしい。
利用者がDDDでいう集約であり、外から通信できるクラス。（このパッケージ図の中で）
クラス名から属性を定義する。
属性からクラス名を定義する。
どちらか片方だけではなく、両方の面からチェックする。
複数の視点から見ることで、そのクラスが整合性が保たれているのかチェックする。
蔵書合計計算機を利用者に持たせるのであれば利用者という名前はおかしいのでは？
将来を見据えて汎用性の高い名前を付けると責務が広がりすぎてしまう。
DDD的に言うと、その時の責務に応じた名前を限定してつけましょうというのがある。
なにをどうする概念なのかという観点でのネーミングが望ましい名前設計
開発者の中で視点があっている状態では、（そのクラスの責務に対する理解が揃っている）、抽象度の高い名前にしてもいいかもしれないけど‥
将来的に新しい人が入ってきた場合、抽象度の高い名前にしたが故に、属性がどんどん追加されて、神クラスが出来上がってしまう可能性がある。
貸し出し明細の責務がシステムから生えているのはおかしいのでは？
貸し出しが貸出明細のコンポジションになっている。
参考記事→
貸し出しのみを外部に公開して、貸し出し明細を閉じてしまう。
また、貸し出しからループは生成されるべき。
実践と点線/コンポジション
上記パッケージ図の実線が表しているのは、、貸出クラスの属性（プロパティ）が蔵書クラスを参照しているということ。強い参照。
破線が表しているのは、貸出のメソッドが蔵書クラスを参照しているということ。
メソッドは実行されたら終了するので弱い参照。
