intro
こんにちは、NE会社で働いておりますきんじょう(@o0h_)がお送りします。
6月23日に福岡・博多で行われたPHPカンファレンス福岡に、趣味で参加してきました。
NEはブロンズスポンサーとして協賛しています。
社内からは、私の他に@asumikamも現地まで遠征していまして、参加レポートを上げています。
先を越されました。
私は今回、有り難いことにプロポーザルを採択していただけました。
その発表については個人ブログにてまとめています。
本題
「NE株式会社の開発ブログ」は公共空間にお邪魔して展開しているものではありますが、少なからず社内メンバーに向けてのメッセージや情報共有の側面もあるかと考えています。
そこで、この記事では「主観で選ぶ！(主に社内向けに)色々な人に観てもらいたい発表セレクション」をお届けしようと思います。
非公式前夜祭で言及のあった「面白いやつをみんなで観る会」も、再び展開される機運はあるかと思いますし、その参考情報という役割も与えつつ。
観点別にまとめていきます。
自分がまだ全ての発表・資料を観られている訳では無いので、あくまで「今見知っている範囲で」という限定にはなりますが、必要に応じて追記していこうかと思います。
全員へ / プログラミングをやる上での一般的な理解を深める・良い開発を行う
制約の力 - 状態を限定する -
プロポーザル: https://fortee.jp/phpconfukuoka-2023/proposal/2c67b2db-9aba-4bad-a795-cef5e84895f0
今回の発表の中で、「須く観て欲しい、誰にでも知って欲しい」としたらNo.1はこちらのshin1x1さんの発表かなと思います。
「制約」とか「型」とかいうとアレルギー反応が出たり、そこまでは行かなくても「ちょっと怖い」「難しそうなもの」と思っている人には、怖がらないで観てほしいです。どんな環境であろうとどんなPHPバージョンを使っていようと、活きてくる話のはずです。
特に、スライド#17 #18の図解については、なるほど〜〜こういう見せ方をするとわかりやすいな！と印象に残りました。
結局のところ「わかりやすくする」「考えなくても理解できるようにする」ための手段として、「制約がある」と良いのです。
「今日の夜は何食べたい？」よりも、「マクドナルドのフィレオフィッシュとモスバーガーのとびきりハンバーグサンド ならどっちが食べたい？」というクローズドクエスチョンの方が、考える負荷が減りますよね。
要するに、制約をつけるとはそういうことなのです。
コレをプログラミングにも適用することで、コンピューターにも人間にも優しいコードが書けるようになりますし、(一般的には)バグも減らせます。
後半にやや発展的な内容も含まれますが、今すぐに全てを理解できなくてもOKで、とにかく前半だけでも読みましょう。
また、この発表が面白かったら、発展的な内容になりますが以前に発表していた型を意識したPHPアプリケーション開発もオススメ。
フレームワークが生み出す負債や複雑さに対して、PHPUnitと付き合っていく
プロポーザル: https://fortee.jp/phpconfukuoka-2023/proposal/e1acbd97-9263-4edc-99b1-ed736b0fad8a
(もう、タイトルが良いですよね・・・)
そもそも「単体テストの考え方/使い方」を全員読んでくれ、そしたら一緒に話そうぜ！！で良ければ助かるのですけども、恐らくそうも参りませんので。
「フレームワークが生み出す負債」という卑近な例を通じて、「どうしてテストが壊れるのか、どんな禁忌があるのか」を整理してくれているような印象を受けました。
我々は「本当は重要でもないモブ登場人物に、話の大筋をぶっ壊されるぜ！」というのが大嫌いですので、そういう「余計な仕事を持ち込んでくる」ような存在に対してはノーセンキューを突きつけたい気持ちになって良いと思いますが、それらはどういった所にどんな形で潜んでいるんだ？に気付かせてくれる内容です。
「何のためにテストを書くのか」というと、一般的な回答は用意できたとしても、なかなか自分で納得感を持つ言葉で説明するのは難しい面もありますよね。「テストを書くことによって、何を得たいか・どう守りたいか」と言い換えると、少しニュアンスを変えて考えられそうでしょうか。
この発表は、正にその「テストをどうしたいか」という言語化に進むヒントをくれるものになっています。
個人的には、「テストについての語彙を揃える、何が”ユニット”かをチームで話し合う」というのは、なるほどな〜素敵だな！と感じた部分で、印象に残っています
その説明、コードコメントに書く？コミットメッセージに書く？ プルリクエストに書く？
プロポーザル: https://fortee.jp/phpconfukuoka-2023/proposal/ae71f3a7-4c3c-4c87-8816-8426bcc8d325
「コミットメッセージをちゃんと書く」というのは、究極どうでもいいことかも知れないのですが(私はめっちゃ拘りますが。)、敢えて強い表現を用いれば「自分が製造したものに、どのように説明責任を果たすか」の一端が「どこにどんな事を書くか」に現れてくると思うのです。
プログラミングにせよ、チーム作業にせよ、どちらも複雑な仕事です。
複雑な仕事に対しては、十分な情報量を提供すること・享受できることが「仕事の品質」に直結するのであり、職業プログラマーとしては「現在・未来に、目の前や少し離れた所にいる相手に、適切な情報を手渡すこと」は責務の1つと言えます。
日頃の仕事から、「その説明、コードコメントに書く？コミットメッセージに書く？ プルリクエストに書く？」を自分の頭で考えられる人が増えて欲しいなと望みます。
プロセス改善や品質改善に意識が向いている人へ
推測しないで、計測し、判断する！ 〜カイゼンのためのステップ考察〜
プロポーザル: https://fortee.jp/phpconfukuoka-2023/proposal/b4816274-d0d4-424d-8b20-f98b78bdfbcb
例えば「今のコードはいじりにくいから、どうにかしたい」「具体的に言うとリファクタしたいんだが」という事を思った時に、「では、何を・どうやって・どのくらいやれば、目的が達成されて十分な効果を得られるか」は重要な訳です。
そこを捨て置いてしまえば、ただ「隣の芝は蒼い」で無限ループに陥ります。「想像していたほど気持ち良いコードにならない」の以前に「求めているはずの理想を、実は具体的に想像なんて出来てなかったでしょ」となり、期待とは呼べない願望・妄想に成り果てます。
せめて、「どこが最も酷いか」「変更をして、実際になにかが変わったのか」は定量的に判断してチームで認識を揃えていきたいです。
という訳で、「感覚や気持ちで動かない」「議論の土台に乗せるためのデータを扱う」をしていけると良いはず、では何を？
・・・そういった課題に対して視野を広げさせてくれる発表です。
資料中でもあるように、面白かったらPHPerKaigi2023の発表内容を次に読んでみる(もしくはアーカイブを観る)のがオススメ。
計測できるレガシーさを捉え、コード改善に対処する / phperkaigi2023 - Speaker Deck
あなたのPHPアプリ、ログはでてますか？あるいはログをだしてますか？
プロポーザル: https://fortee.jp/phpconfukuoka-2023/proposal/b5f7099b-b87b-401d-994e-6cced4cd2aca
「必要なログが出ているか」は重要であり、必要なログとは「仕事を成立させるのに十分なログ」だと思います。
その上、当然のことながら「仕事」というのは「誰」「いつ」といったコンテキストによって変わるものであり、それぞれを掛け算して湧いて出るニーズに対しての「十分さ」が求められます。
そう聞いた上で、改めて普段の開発・設計の場面で「ちゃんとログを書けているか」と問われたとしたら、胸を張って「YES！」と答えられるでしょうか？
もし「NO」なら、まずはこのスライドを読んでみてください、それで気づくこと・ハッとする事があるようだったら、明日から即座に実践しましょう。
あとSoftware Design 2020年2月号で「［短期連載］Webサービスを裏で支える!! バッチ処理設計の勘所」も読んでください、ログの話なので。
The future of tbls and "Documentation as Code"
プロポーザル: https://fortee.jp/phpconfukuoka-2023/proposal/df1faefa-056a-493a-87d3-45934e96ea8c
ナレッジ管理や形式知のチーム的な獲得は、組織の生産性・品質向上の基礎ですので、そういう話を視野の中に納めておくのは重要。
tblsを題材とした発表ですが、資料中「はじめに」にもある通り「もっと抽象的な「ドキュメンテーションのためのツール」をイメージしてほしい」ということであり、ドキュメントの作成・保全活動について思いを馳せるための、ヒントになるような話が詰まっているかと思います。
(そこから踏み込むと、「システムと乖離しないドキュメント」を求めることになるはずで、それは特定ドメインや”Ops"に閉ざした話や、まして「システムやドキュメントの同期管理ツール」といった特定カテゴリの話ではなく、一般的な欲望なのではないかな？と思っています)
なお、この話に興味を感じたらk1LoWさんによる過去発表もオススメ
知らないWebアプリケーションの開発に途中からJOINしたとき、どこから切り込むか？ / PHPerKaigi 2020 - Speaker Deck
負債とかプロジェクトとか
レガシー回避のPHP開発術
プロポーザル: https://fortee.jp/phpconfukuoka-2023/proposal/3c651de4-9926-453a-98d2-69b71bb194e1
膨大・重厚・視座高め、な内容ではありますが。
どういう意識を持っている場合にこの発表に触れるといいか？というと、ご本人の登壇後記事に書いてある記述を読んで、ピンと来たり「おっ」と思う人。あなた方は、是非。
登壇内容自体は、スライドを直接見ていただくか、後日公開されるであろう録画を見てください。言いたかったことは一つだけ、「極端で短絡的な思考に陥らずに、目の前に課題に集中しろ」ということです。テクニカルなトークを期待していた人には申し訳ないのですが、レガシーを回避するために一番必要なのは、現状を正しく理解する言語化能力と、集団での開発におけるコミュニケーションの重要性です。
ここでいう 小手先のテクニック 極端で短絡的な思考というのは、「○○パターンを使えば良いはずだ、なぜなら世の実践力の高い会社やチームは、すでにその方向に進んでいるぞ」とか「〇〇さえやれば上手くいくのに、それが出来ていないから」といった話だと思います。
○○の中に入れる単語は、技術的なツールでもいいし、プラクティスでも良いし、組織設計でも良いと思います。DDDかも知れないし、スクラムかも知れないし、マイクロサービスかも知れないし、Spotifyモデルかも知れないし、スタッフ+かも知れないし、OKRかも知れないし、就業時間後に飲めるアルコールドリンクかも知れないし、卓球台かも知れないし、タクシー券かも知れないし。
(概ね「イケてない・イケてる」軸の判断が伴うときは、そうしたトラップに陥っている気がする)
そうじゃないよね、と。
多くの複雑な問題には「テーラーメイド[1]」が必要であり、教科書通りの実践や形式手法の導入で解決できるものではないので。自分たちが本当に抱えているもの、その源泉がどこにあるのか、それらを丸っと含めて、どこから何をどのように磨き直していくべきか・・？を考える必要があります。
「キラキラしたいだけ」で、新たな問題を連れてくるのを止めたいものです。
発表中に、「みんなでアジャイル」がよく引用されていたので、気になる人は↓のPodcastオススメです。
ソフトウェア設計がプロジェクト管理にどのように影響を与えるか
プロポーザル: https://fortee.jp/phpconfukuoka-2023/proposal/cf470954-7fba-4302-820f-ca21b0928045
まぁ、コレは我田引水なのですが・・・
社内の状況を鑑みるに、何人かにとってはヒントになったり救いになるような話なのではないかな？と思います。
どういう話なの、については個人ブログの「言いたかった(かも？)こと」の節を読んでもらえればと。
組織づくりとか教育に関わる・関わっていきたい人へ
良いプロダクト作りのための組織育成 健全なコードは、 健全な組織・健全なチームから
プロポーザル: https://fortee.jp/phpconfukuoka-2023/proposal/e05f36dd-f862-430c-87dc-ba698073867a
自分もマネジメント業務に関わっている立場であり、教育等も実施しているわけですが、この発表を聞きながら「ここまでやれているだろうか」「こうした理論を知ることで、知の高速道路に乗れそう！」と、ドキドキやワクワクしながら現地で聴いていました。
色々と出来ることがある、まだまだ知るべきことがある！と、そんな感じです。
特に、マネジメント側に立ってから日が浅い人など、「どういう風に接するのが正解なのだろうか」と悩むことも多いかと思います。
(時が流れてもソレ永遠につきまとうかもね、という気もしますが、とにかく「引き出し」への飢えの性質が違うかとも思うので)
そんな時に、こうした「実践者が形式知として展開してくれる」というのは、大きな助けであり慈愛だなぁと感じました。
資料だけでなく、できればアーカイブ動画を観てもらいたい気はします。
また、ここで出てきた理論やテクニックについては、どちらかといえばこの発表を「索引」として使いつつ、本を読んだり調べたりするなどして、自分なりに深掘って咀嚼していくと更に良いのではないでしょうか。
コミュニティ活動や刺激に飢えている人へ
伝えたい！オフラインのカンファレンスに参加するメリットと参加してから200%楽しむために実践してほしいこと
プロポーザル: https://fortee.jp/phpconfukuoka-2023/proposal/89740c79-2aca-440d-94e2-f227de3a6eb4
コレは色んなイベントのオープニングとか前夜祭とかで再演されて欲しいな・・・と感じるくらい、明るくて楽しい話だったな〜と思います。
「カンファレンスの怖さ」みたいなものを払拭していけると、参加した際の楽しさが本当に10倍にも100倍にもなると思うんですよね。
得られるもの、残るものは「200％」で収まらないのではないか〜〜〜とすら感じるわけです。
NEでは、カンファレンスへの関わりを持つ人が増えてほしいなぁと思っているので、そのためには色々な人が色々な入り方・接し方を持ってくれて良いと思っているのですけど、こういう例を1つ、2つ・・と「とりあえずやってみよう！」と動いていけば、段々と自分なりの自然な楽しみ方に繋がっていくのではないでしょうか。
まずは、最初の一歩を踏み出さないことには始まらないので！！！
背中を教えてくれる発表だな〜と感じます。
興味が湧いたりワクワクした人は、次どこかに一緒にいきましょう！
他にも、紹介できなかったけど・・・
個人的に好きなやつetcを貼っておきます
おしまい
以上となります。
私は、前日・翌日の非公式イベントにも参加してきました。
PHPカンファレンス福岡と、それを中心に集まった非公式イベントを含めて、非常にコミュニティの持つ魅力やエネルギーを肌で感じられた3日間となりました！
今後も引き続きカンファレンスに参加して、MPを補充したいな〜〜と感じた次第です。
また機会があったら、どこかでお会いしましょう！！！
NE株式会社のエンジニアを中心に更新していくPublicationです。 NEでは、「コマースに熱狂を。」をパーパスに掲げ、ECやその周辺領域の事業に取り組んでいます。 Homepage: ne-inc.jp/
Discussion