トーク

プロジェクトの振り返りは行っていますか？

振り返りにて
「これまでの問題点」
「これから伸ばしていく点」
を発見できるかもしれません。
プロジェクトの結果は技術面だけでなく、人為、経営など、多方面から影響を受けます。
これまでKPT法というフレームワークを用いて行った振り返りmtgで
記憶に残っている体験談をお話しします。

会社員時代、エンジニア同士にて行った振り返りmtg
サブリーダーを担ったプロジェクトにて行った振り返りmtg
案件に参画した際のチームにて行った振り返りmtg

素晴らしいフレームワークを使っても、
全てが有意義な振り返りmtgにはならないこと、
有意義な振り返りmtgには努力が必要であることをお伝えできれば嬉しいです。

近年、PHPプロジェクトの品質を高めるためのツールとしてPHPStanのような静的解析ツールが導入されるケースが増えています。

しかしながら、PHPStanをただ単に導入しただけではバグを完全に潰すには足りません。
PHPStanに新たなルールを加え、更に厳しくするためのPluginがphpstan-strict-rulesです。

PHPには厳密性に欠ける関数が散在します。
例えば、 in_array に第三引数を渡さないと厳密性が損われるので警告を出してくれるといったものです。

phpstan-strict-rulesを普及すれば、誰もが安心して開発できる環境が整うと信じています。

対象

• 既存のPHPStan level maxでは満足できない身体になってしまった人
• PHPStanでは捕捉しきれないバグに遭遇したことのある人
• 型に厳しい別言語から来た人

PHPerのみなさんは金額計算などで、BCMath関数を使ったことがあるのではないでしょうか？
この関数郡は共通して「引数を文字列にする」という特徴があります。

ただし、floatをstringにキャストする際は少し注意が必要なので、正しくキャストするための方法をご紹介します。

本トークで話すこと

• 何故float型を四則演算すると計算結果がずれてしまうのか
• float型を単純に文字列にキャストするのは危険
• 文字列に正しくキャストするにはどうしたらいいのか

コードの問題点は見た目にはなかなか表れません。
長年の経験でピンとくる場合もあるかと思いますが、多くの場合知らず知らずのうちによくないコードが増えていき、気付いた頃にはそれは「レガシーコード」と呼ばれるようなコードになっているかもしれません。

ではどのようにして問題点に気付くことができるでしょうか？？

そのための1つのアプローチがコードを計測することだと考えています。
コードを計測することで得られる情報は多岐にわたります。例えば、コードのサイズ、重複コードの有無、コーディング規約の遵守状況、循環的複雑度、エラーの有無などです。これらの情報を取得することで、コードの状態を明らかにすることができます。

計測した数値はそれ単体で問題点を示すわけではありません。
その他の数値と組み合わせたり、実際にコードと照らし合わせて判断することが必要です。

本トークでは、主にコードをツールで計測することによって得られる結果に着目し、どのようにしてコード改善にアプローチするかをお話しします。

本トークでは主にコードをツールで計測することによって得られる結果に着目しながら、どのようにコードを改善に対してアプローチをすることができるか？をお話しさせていただきます。リファクタリングやコード改善に携わる方々にとっての一助となればと思っております。

Laravelなどのフレームワークを使うと、安全なアプリケーションを素早く作ることができます。
一方で、処理が抽象化されていて簡単に書けてしまう分、よく理解せずに使うと思わぬところで時間を溶かしてしまったり、脆弱性を含むプログラムを書いてしまったりすることも多々あると思います。
そこで、このトークでは脱初心者を目標にLaravelが行っていることを一つひとつ追っていくことで、エラーメッセージを見た時に素早く対応できる状態を目指します。

対象者

• Laravel初心者
• Laravelを使った開発でエラーの解決に時間がかかる方

話すこと

• .htaccess
• index.php
• autoload
• routes/ での処理
• viewの表示の仕組み
• 404などのエラーページ表示の仕組み

話さないこと

• artisanコマンドの実装
  リクエストとレスポンスの部分を主に扱いたいため、開発に使う機能は今回は割愛します

ゴール

• Laravelがリクエストを返すまでの流れがわかる
• エラーメッセージを読んだ時に、どこを修正すれば良いか素早く判断できる

テストコードのプルリクが来て意気揚々とレビューしてみると、こんなテストケースが書かれていたりしませんか？

• テストケース名が test_executeメソッド() としか書かれていない
• ひとつのテストケースの中で、複数のシナリオが確認されている
• なんでもかんでもデータプロバイダー
• テストケースの中にif文がやたら書かれている
• ひとつのテストケースを確認するのに、大量のデータセットが必要
• etc

こういったテストコードがレビューで飛んできたとき、自分はちょっといやだなぁと感じてしまいます。

本トークでは、なぜ上記のようなテストコードをいやだなぁと感じてしまうのか、何が問題になるのか、それに対してどのように書き換えればいいのかをコード例を交えながらお話しできればと思います。

PLATEAU(プラトー)というものをご存知でしょうか？
国交省が主導する、日本全国の3D都市モデルの整備・活用・オープンデータ化プロジェクトです。
現在、さまざまな都市の3Dモデルが公開されており、これらを活用して多様な実証実験が実施されています。

本LTでは、これらの3D都市モデルをUnityに取り込み、ちょっとしたゲームを作って遊んでみます。
なんというか、ボールっぽいものを転がして、建物を巻き込んで、カタマリ的なものを作っていくようなタマシイ風のやつです。

私は、10人のメンバーが所属するチームのチームリーダーをしています。
エンジニアリングもする、いわゆるプレイングマネージャーというやつです。

リーダーになったのは約5年前。
当時は、組織改変に伴ってリーダーができそうな雰囲気の人を捕まえて、
「リーダーできる？できるな！？君は次からリーダーだ！いい感じに頑張れ！以上！」
といった具合でリーダーが任命されており、みんな手探りでマネジメント業をやっていました。
あなたの会社も同じような感じだったりしませんか？

リーダーになったからにはマネジメント業に対してもお給料が出ているので、しっかりやりたいところです。
しかし、マネジメント業を学ぼうと思って本を漁ってみると、「がんばらなくていい、自分の色を出して頑張れ！」と書いている心意気の本や、フィードバック手法やらコーチングやら進捗管理やらの具体的なノウハウが書かれた本が目立ちます。

しかし、まず最初に知るべきは「マネジメント業という仕事の本質」です。
自分が何をしようとしているのかを知らずして、さまざまなノウハウを学んでもそれは単なる付け焼き刃なのです。

本セッションでは、私がリーダーになる前に知っておきたかったマネジメント業という仕事の本質を、自身の経験も交えつつ共有できればと思います。

対象者

• 上長がどんなことをしているのかを垣間見たい方
• これからマネジメント業をしようとしている方
• マネジメント業を担っているけどどうしたらいいかわからず迷子になっている方

私は学生時代に学園祭実行委員会に所属し、PHP を用いた学園祭 Web サイトの開発・運用や情シス業務に携わっていました。その頃の経験を振り返り、学園祭 Web 開発の過去と未来に触れつつ、一般のエンジニアでも他人事ではないような話をします。

こんな話を時間の許す限りします

• 学園祭 というドメインならではのチーム・プロダクトの特徴
• PHP での開発をどう学び、後輩に伝承するか
• 現代における学園祭 Web サイトの設計論
• 社会人エンジニアとなった今役立っている経験

参考リンク

関連する内容について、ブログエントリを公開しています：

• 学園祭のWeb開発を語る: 具象編1 講習会と砂場遊びで支える組織
• 学園祭のWeb開発を語る: 具象編2 開発体験・保守性を投げ捨てる
• 学園祭のWeb開発を語る: 抽象編 自分たちの責務をどう絞り、どう委嘱するか

プログラムにおいては処理の結果を何らかの方法で伝達し、成功と失敗を切り分けたいことがないでしょうか。

PHPにおいても、ファイルを読み込む file_get_contents() 関数は string|false のような型宣言になっています。
標準関数においてはそれ以外にもエラーや例外など異常事態を伝えるための機構が組み込まれています。

そのほかにも、成功と失敗を表現するにはその他にも数多くのアイディアがあります。
このトークにおいては、PHPでは馴染みのない手法も含め、事態をより安全に異常と正常を切り分けて扱うための方法を扱います。

キーワード

• エラー・検査例外
• 型安全・静的解析・PHPUnit
• 直和型・ユニオン型・タグ付きユニオン

PHPを使用している方にとっては、PHPの中身に興味がある方も多いと思います。そんな時は、PHPのソースコードを読んだり、改造したりすることで理解が深まることがあります。
PHPを改造した場合、その動作を確認するためには、コンパイルする必要があります。また、PHPをWeb上で表示するためには、Apacheなどのサーバーソフトウェアのインストールも必要になります。
そこで、このトークでは、PHPを実際にコンパイルしてWeb上で表示させる手順について、Dockerfileをお見せしながら解説します。

対象者
・PHPをコンパイルしてみたい方

話すこと
・PHPをコンパイルする手順
・PHPとApacheをコンパイル・インストールする上ではまったポイント

話さないこと
・Cコンパイラの選択
・PHPの内部実装

2021 年 11 月、PHP の処理系と言語そのものの開発に一大転機が訪れました。

• PHP の様々な側面での近代化に関わってきたコア開発者 Nikita Popov さんの活動規模縮小
• それを契機とした The PHP Foundation の発足

The PHP Foundation は寄付を募り、PHP 処理系の実装と言語仕様の改善へ取り組むコア開発者へ資金を提供して、日中の仕事として PHP の開発を行えるようにする団体です。寄付が集まるほど PHP の開発が加速し、私達 PHPer がその恩恵を受けられることになります。
https://thephp.foundation/

すでに日本を含めた世界中から多くの寄付が集まり、The PHP Foundation によって雇われた数人の開発者によって、実際に多くの言語改善が成し遂げられました。このような PHP の開発事情をすでによく知っていて、所属会社からも寄付を行っている、という方もいれば、「PHP という言語自体の開発を生身の人間がやっていて、彼等がどう日々のご飯を食べているかが我々のビジネスに強く関係している、なるほどその発想はなかった」という方もいらっしゃるかと思います。

このトークでは The PHP Foundation の成り立ちと意義、これまでの活動内容をあらためて紹介し、「そういうわけで皆も会社のお金で The PHP Foundation に寄付をしよう！」というお話を、The PHP Foundation の関係者でもないのに外野から勝手に力強くやっていきます。

2023年4月時点で、CakePHPは5.0βの開発が進行中です。
およそ3年ぶりのメジャーバージョンアップとなり、PHP7へのサポートを終了する最初のバージョンとなります。
コードネームはChiffon(シフォンケーキ)と言います。

まだまだ機能のスコープは安定しませんが、どんな変化が予想されて、使い勝手はどう変わるのでしょうか？
このトークでは、カンファレンス当日までのなるべく最新の情報を取り込んで、開発状況・個人的な所感や予想について共有します。

話すこと

• CakePHPの4.3辺りからの「どういう変化が起きているか」のおさらい
• CakePHP5.0で計画されている変更点
• それらを総じて、「このFWはどういう方向に向かおうとしているのか」の所感

テスト書いてますかー！と聞けば、書いてますよー！と元気に答えてくれる人って多くなっていそうですよね。
では、得意ですかー！とか、他人に教えられますかー！とかって聞くと・・？難色を示す人も多いのではないでしょうか。

「テストを勘で書いてきたし、書けるようになってきたけど、そろそろ品質とか理論とかを学びたい」という人に向けたトークをします。
ただし、これは非常に深く広大な話題だと思うのですよね。
そこで、単体テストにフォーカスを絞って、「考え方を身に着けたり、引き出しを増やすために役立ちそうな情報はないのか？」に応える「手引き」となるようなトークをします。
どういう課題を持っているか・どういう知識を身に着けたいのかというケース別に、処方箋となりそうないくつかの書籍や情報リソースを紹介します。

想定対象者

• 「普段の仕事では単体テストを書いている」くらいのレベルにはあるけど、自分の書くテストに自信がない人
• 「テスト中級者」よりも手前のレベル感だなぁ、と感じている人
  • 「全く書いたことがない」という人はスコープから外れます！

話すこと

• テストについての(一般化された)知識、理論を学ぶための情報
  • 主に単体テスト
• 日頃から「テストをスラスラと書けるようにする」ための学び方、鍛え方

話さないこと

• PHPUnitなど、特定のテスティングフレームワークの利用者練度を高めるためのtips
• テストの「動かし方」やテスティングフレームワークの内部構造など、実装に関する話

人工知能ってやばいですね！！私はあまり中身については分からないのですが、「きっとヤバいね」という噂をたくさん聞くので、すっごいヤバそうだなという事を知っています。

TestGen AIは、RectorやEasy Coding StandardsといったOSS活動でも有名なTomas Votruba氏のプロジェクトです。
https://testgenai.com/

テスト対象のコードを入力すると、自動的にPHPUnitのテストコードを生成してくれます。
(動作イメージは、↓のツイートなどを見ると分かりやすいかと思います)
https://twitter.com/testgenai/status/1639331232151371804

何をしてくれて、どんな感じに動くのでしょうか？
このLTでは、実際に触ってみて&これからどんな発展の可能性がありそうかを共有します。

もっとデプロイを増やしましょう。
ここ数年、国内のPHPコミュニティの勉強会やカンファレンスでも、Four keysを始め「開発組織の生産性・健全性」の計測や向上に関心が高まってきているのを感じます。
その源流となるのは、DevOpsのムーブメントでしょう。
「開発と運用が分離されていることが、天井になっているのではないか」というDevOpsの精神は、自ずと「もっと高速にデプロイ出来る、頻度をあげられる、それによってプロダクトの提供価値を増やせるはずだ」という夢を追う事になります。

翻って言ってみれば、それほど「DevとOpsは反対の動機で行動しかねない」というリスクを背負うということです。
すなわち、「安定して、信頼性が高いソフトをデリバリーして欲しい」と願うOpsと、「思い描いた機能を、速やかに出していきたい」と願うDevの対立です。
結果として、「対岸」の怖い人に迷惑を掛けたくないし、あるいは「同じ側」にいる人のためにも信頼を損なうような事をしたくない・・・・「デプロイ恐怖症」のトラップに陥っていきます。

そうした背景が、現実世界には存在する事は想像に難くありません。
ですが、それは突破できると嬉しい世界が広がるはずの、突き破るべき天井です。

私の職場では、この半年〜1年ほどで「デプロイ数を今までに何倍にも出来た」「最近はデプロイするのが怖い！って気持ちが減った」という声を、開発メンバーからチラホラと聞くようになりました。何が起きたのでしょうか？

主に「開発者の心理的な面」の改善・向上に焦点をあてて、その変化をもたらした要因やプラクティスについて共有します

主なトピック

• やっぱりマージまでを早めよう！デプロイの粒度もちっちゃくしよう！は大事
• 「壊れても気付ける」という安全のためのシートベルトを用意していく
• 「もし欠陥があっても対処できる」という自信、「大騒ぎにならずに沈下できる」というanti-緊張感を備える
• 開発に歓びを取り戻すのじゃ！！

仕事をしている時など、「ムッ」とする場面はありませんか？
そうした際に誰かを悪者にしていませんかね。
悪者って、何でしょうか？──自分の目的達成や生存に対して、阻害をもたらす存在だとします。
イラッとすることがある、上手く行かないことがある、それらを「誰かのせい」にすることで、ギクシャクしてしまったり衝突を起こしたり・・・そんな経験はないでしょうか。その多くは、望んで起きた結果ではなく、望まずして生じて避け難かった「事故」のようなものである事も。

「問題の外在化」という技法があります。
これは「(問題を起こした)誰か」や「自分」に疑問を向けるのではなく、「問題を起こさせた要因があるはずだ」と考えることで問題そのものと人とを切り分け、本質的に「問題と向き合いやすくする」というものです。
「スプリントゴールが達成できなかったのは、Aさんの実装が遅かったから(Aさんが悪い)」ではなく「チーム全体でのコミュニケーションが以前より減っていて、アラートに気づけなかったから(チームが悪い)」「コミュニケーションが減っているのは、「執務室で会話を減らせ」と伝達を出してきたから(環境が悪い)」といった形で、問題の構造を変えさせます。

このような視点も含め、「解決したい問題が発見された時に、その背景や出どころに働きかける」という考え方として「システムズ・アプローチ」と呼ばれるアプローチがあります。
「誰か」から「仕組み」に意識の向け先を変更することで、憤りや不満と言ったネガティブな感情を和らげ、それまで「問題の主体」と考えられていた人物も含めた関係者で一体となって「コトに向かう」「他責的に考えず、当事者として解決可能な課題として扱う」ようになりやすいと言われます。

プログラマー職は「問題を解決する」「仕組みでどうにかする」が得意な職種だと思うので、この思考はとても相性が良いはずです。また、自然と「システムの問題として捉える」ができると、効果的な改善施策やアクションが浮かびやすくなります(例えばレトロスペクティブの場面などを想像してみてください)。
結果、深く広い学習のループが進むようになり、強いチームを手に入れられるようになるのです。

本トークでは、そんなシステムズアプローチの世界に触れつつ、「問題をシステムで捉えること」「実践しやすくするための視点・発想法」を共有します

ソフトウェア開発は複数人が関わる事が多く、特に業務の場合は単独の開発者で完結することは少ないでしょう。

人が複数集まると、「組織」となり「社会」が成立します。
そうした集団の力が、うまく活きれば強大なものになり、そうでなければ摩擦や抵抗により低減します。
うまく「チーム」で動いて行きたい、あるいは自分を取り巻くチームを良い方向に動かしていきたい…そう思ったことはありませんか！

「なぜ他人は動かないのか」「人はどうしたら動くのか」の両方向の力学を知っておくことが、ヒントになるはずです。
私は、マネジメントやリーダーの立場から、いくつかのチーム・個人に対して内外から関わっていく中で、「どのようにして、目の前の他人を前に進ませるか」を探求するようになりました。
本トークでは、チームやコミュニケーションに関する理論や考え方を紹介しつつ、協働するチームを築くための働きかけの技術について紹介します

伝えたいこと

• チームとグループの違い、目的を共有する集まりになることの重要性
• 進みたい方向性を示す・具体化し共有する、ただし他人に何かを「押しつけ」ないようにする
• 人ではなく課題に向き合うようにする
• 他人を尊重する、それと同じくらい自分も尊重する

参考書籍・関連分野

• あなたのチームは、機能してますか？
• なぜ人と組織は変われないのか
• 他者と働く
• プロフェッショナル・ファシリテーター
• ファシリテーター完全教本
• インターベンション・スキルズ
• プロセス・コンサルテーション

【前口上】
ありがとうPhpStorm、寛容で叡智に富んだあなたがいてくれて、私のPHPはどんどん良くなっていく───
コードエディタの領域だけではない、ソフトウェア開発を幅広くサポートする強力なツール・機能群。静的解析ツールやテスティングフレームワークといったPHPコミュニティの資産との力強い連携。そして、あらゆる面でコードのクオリティを底上げしてくれる静的解析機能！！

今日では、こんなにも進歩した相棒によってPHPの開発が支えられております。
便利で馴染み深いツールだからこそ、しっかり使いこなして普段の開発をより心地よく・生産的なものにしたいですよね。

【本題】
そんな事を感じながらも、あなたはPhpStormのInspectionについて、どのくらい把握できていますか？
当たり前のように目にしており、時には自分で調整をしてみるものの、あまり網羅的に内容を観たことがない・・という人も少なくないのではないでしょうか。

本トークでは、PHPについてのInspectionを全体的に眺めてみつつ、現場で実践的に活用するための方法を共有します。

主に話す内容

• PhpStormのInspectionってどんなものがあるの？
• ちょっとした付き合い方のコツ、個人やチームで上手く使う
• 自作のインスペクションを追加する

世の中から「クソコード」は無くせるものでしょうか？
せめて、地球や宇宙の全部とまではいわなくても、「私の身の回りにある世の中」であれば可能でしょうか？

私は、なるべく「クソコードなんて視界に入ってこないで欲しい」と考えています。
一体どうすれば奴らはいなくなるのか。すごく難しそうです。
ですが、「新しくクソを生まないようにしよう」というのは可能でしょう。

そのための一歩として、「クソコードと呼ばないようにする」ことを本トークにて提案したいです。

「心理的安全性が高いチーム」「人として、周りに気を配れる」「社会性フィルター！オン！！」
どれも大事ですね。とても大事です。
ですが、私は、もっと利己的な理屈をもって「クソコードと呼ばない」というムーブメントに取り組んでいます。
「温かい空気を作るため」ではなく、「もっと自分が技術者として成長するため」に、「クソコードなんて言葉は使わないぞ！」と決めたのです。

コードや成果物に対する「批判」は大事です。しかし、それは決して「あげつらう」ことではありません。
共有可能な価値観を提示し、それに照らし合わせて、より適正な在り方を目指す・・・そうした「批判」です。

「なんでこんなコードを書くのだろう」。
その根本にあるのは「コードの書き主が知らないことがある」「自分が見落としている事がある」の何れかです。
ここで「それはクソコードだ」と言ってしまえば、思考は停止してしまうと思います。
もっとダイブ出来るはずです。書き手の気持ちを考えよう。「なぜこの書き方を？」「どういう思考プロセスを経てこの書き方をしたのか？」「自分だったら、どこで”こうじゃない”と気付くはずか？」「単に書き手の技量不足だろうか。その足りない知識は、自分がわかりやすく説明できるだろうか？」クソコードから学べることは多いと考えます。
自分で納得できるまで「そのクソコードの生まれた歴史」を突き詰めていますか。

改めて、クソコードを超越した開発者になりたいと強く念じます。
極めて個人的な主張、理屈になってしまうかも知れません。
ですが、このセッションを通じて、こらからの未来に1回でも多くの「クソコード」発言が減らせたら幸いです。